Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Improved Channel Program Structure

IP.com Disclosure Number: IPCOM000118019D
Original Publication Date: 1996-Aug-01
Included in the Prior Art Database: 2005-Mar-31
Document File: 4 page(s) / 171K

Publishing Venue

IBM

Related People

Carlson, BA: AUTHOR [+6]

Abstract

The existing IBM ESA/390* Input/Output (I/O) Architecture and ESCON* I/O Interface Architecture may be changed by this invention: 1. Sequential nature of the channel program: In the current architecture, an I/O request (channel program) consists of one or more chained Channel Command Words (CCWs) which are sequentially fetched by the channel. The first CCW specifies the command and the first part of the output data or input buffer. Subsequent data-chained CCWs specify additional data or input buffers. To chain requests, the last CCW of one request is command-chained to the first CCW (command) of the next request. The presence of command chaining is indicated in the last data-chained CCW of the request.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 30% of the total text.

Improved Channel Program Structure

      The existing IBM ESA/390* Input/Output (I/O) Architecture and
ESCON* I/O Interface Architecture may be changed by this invention:
  1.  Sequential nature of the channel program:  In the current
       architecture, an I/O request (channel program) consists of
       one or more chained Channel Command Words (CCWs) which are
       sequentially fetched by the channel.  The first CCW specifies
       the command and the first part of the output data or
       input buffer.  Subsequent data-chained CCWs specify
       additional data or input buffers.  To chain requests,
       the last CCW of one request is command-chained to the
       first CCW (command) of the next request.  The presence of
       command chaining is indicated in the last data-chained CCW
       of the request.  This structure presents these problems:
      o  In the presence of data chaining, the earliest the
          control unit can know if command chaining is in effect
          is after the channel fetches the last data-chained
          CCW for the current command.  Further, unless the
          command-chaining information is provided by the channel
          at the start of (as is done in ESCON I/O), or during,
          data transfer of the last CCW of the current command,
          the control unit cannot find out about command chaining
          until it presents status for the current command.  Waiting
          until the control unit presents status prevents certain
          performance optimizations at the control unit, which
          would be possible if it became aware of command chaining
          before it presented status.  Presenting the command
          chaining indication during the last CCW but before the
          control unit presents status adds complexity and perhaps
          (as in the case of ESCON I/O) additional message
          transfers, all of which degrade performance.
      o  With the current structure, it is not possible to read
          a string of records, whose lengths are not known in
          advance to the program, in one channel program when data
          chaining is used.  An incorrect length record terminates
          the channel program rather than permitting chaining to
          the next command.
  2.  Instructing the device:  A typical DASD I/O request
       consists of sending parameters to the device (e.g., the ECKD
       Locate-Record command) followed by data transfer.  With
       today's architecture, the parameters, which are typically
       less than 100 bytes of information, must be sent using a
       data transfer command, thereby incurring the full chann...