System for repositioning an I/O device to a predetermined position to retry a program without knowledge of which part of the program caused the retry

[0002] This application contains subject matter which is related to the subject matter of the following applications, each of which is assigned to the same assignee as this application and filed on the same day as this application. Each of the below listed pending applications is hereby incorporated herein by reference in its entirety:

[0003] “METHOD OF REPOSITIONING AN INPUT/OUTPUT DEVICE WITHOUT KNOWLEDGE OF CURRENT POSITIONING OF THE DEVICE” by Dahman et al., Ser. No. 09/181,744; and

[0004] “PROGRAM PRODUCTS FOR REPOSITIONING AN INPUT/OUTPUT DEVICE WITHOUT KNOWLEDGE OF CURRENT POSITIONING OF THE DEVICE,” by Dahman et al., Ser. No. 09/181,966.

[0005] This invention relates, in general, to recovery techniques for programs executed on position sensitive input/output devices and, in particular, to repositioning an input/output device in order to retry a program.

[0006] A requirement of any robust computing environment is to be able to recover from errors, such as device hardware errors (e.g., mechanical, electrical) or recording media errors. In order to recover from some device or media errors, it is necessary to restart a program, either from the beginning or from some other point within the program. The restarting of a program, however, poses certain challenges, especially when the input/output device in which the program is executed is position sensitive.

[0007] Conventionally, with position sensitive devices, such as magnetic tape units, the position of the device when the programming error occurred is needed in order to restart the program. This position, however, is difficult to determine for some programs.

[0008] For example, when an error is encountered in a channel program that allows pipelining, it is difficult to know where the device was positioned when the error occurred. A channel program includes one or more channel command words. Some channel programs that have a plurality of channel command words allow pipelining of those channel command words. This means that a number of the channel command words may be initiated prior to receiving a response for any one of the command words. Thus, if an error has been detected for a second channel command word, as one example, but the control unit is already processing the fifth channel command word, then the device is positioned past the error and the position within the device of where the error occurred is unknown.

[0009] Thus, a need exists for a capability that enables an input/output device to be repositioned, even when the position of the input/output device when the error occurred is unknown. Further, a need exists for a capability that enables an input/output device to be repositioned without any knowledge of current positioning within the device. A further need exists for an enhanced capability that enables programs to be restarted, even when the program has been modified or the last known block-id representing the position of the input/output device is invalid.

[0010] The shortcomings of the prior art are overcome and additional advantages are provided through the provision of a system of repositioning within an input/output device. The system includes, for instance, means for ascertaining that a program, that was executing on an input/output device sensitive to positioning, is to be retried; and means for repositioning the input/output device to a predetermined position in order to retry the program. The means for repositioning lacks knowledge of current positioning within the input/output device.

[0011] In one embodiment of the present invention, the system further includes means for determining the predetermined position. In one example, the means for determining includes means for scanning a previously executed program for a command; means for adjusting a position identifier of the input/output device based upon a type of the command; and means for repeating the scanning and the adjusting until a prespecified limit is reached. The position identifier then represents the predetermined position.

[0012] In a further embodiment of the present invention, the means for adjusting includes means for incrementing the position identifier when the command is an Add type; means for decrementing the position. identifier when the command is a Delete type; and means for invalidating the position identifier when the command is in Invalidate type.

[0013] In a further embodiment of the present invention, the program is a channel program including one or more channel command words, and the means for repositioning lacks knowledge of which channel command word of the channel program failed.

[0014] In a further aspect of the present invention, a system of repositioning within an input/output device is provided. The system includes, for example, means for determining a position, within an input/output device sensitive to positioning, that is to be used to retry a program; and means for repositioning the input/output device to the position in order to retry the program. The means for determining uses a first address representative of where a channel associated with the input/output device stopped processing the program and a second address representative of where a control unit associated with the input/output device stopped processing the program.

[0015] In another aspect of the present invention, a system of repositioning within an input/output device is provided. The system includes, for example, a processor adapted to reposition an input/output device, sensitive to positioning, to a predetermined position in order to retry a program. The processor is adapted to perform the repositioning without knowledge of current positioning within the input/output device.

[0016] In accordance with the principles of the present invention, a repositioning capability is provided that enables an input/output device to be repositioned without knowing the current position of the device or where an error occurred within the device. The repositioning capability of the present invention allows for enhanced error recovery on various interface types (e.g., parallel Original Equipment Manufacturers' Information (OEMI), Enterprise Systems Connection Architecture (ESCON), Fiber Connection (FICON) and internal tape) for various input/output errors. The capabilities of the present invention allow the operating system to improve the reliability of input/output devices on errors where the ending channel command word cannot even be determined and which previously had to be treated as a permanent error (e.g., interface control check or channel control check with an invalid CCW address). Further, the repositioning capability of the present invention is applicable to any device where the software depends on media positioning to be able to recover from errors.

[0017] Additional features and advantages are realized through the techniques of the present invention. Other embodiments and aspects of the invention are described in detail herein and are considered a part of the claimed invention.

[0018] The subject matter which is regarded as the invention is particularly pointed out and distinctly claimed in the claims at the conclusion of the specification. The foregoing and other objects, features, and advantages of the invention will be apparent from the following detailed description taken in conjunction with the accompanying drawings in which:

[0019] FIG. 1 depicts one example of a computing environment incorporating and using the capabilities of the present invention;

[0020] FIG. 2 depicts one example of a Unit Control Bock used accordance with the principles of the present invention;

[0021] FIG. 3 depicts one embodiment of the logic associated with starting a channel program, in accordance with the principles of the present invention;

[0022] FIG. 4 depicts one embodiment of the logic associated with processing a First Level Interrupt Handler when the channel program of FIG. 3 completes, in accordance with the principles of the invention;

[0023] FIG. 5adepicts one example of an Interruption Response Block used in accordance with the principles of the present invention;

[0024] FIG. 5bdepicts one example of the fields of an extended status word of the Interruption Response Block of FIG. 5a, in accordance with the principles of the present invention;

[0025] FIG. 6 depicts one embodiment of the logic associate with a device dependent trap exit called when a channel program-completes, in accordance with the principles of the present invention;

[0026] FIG. 7 depicts one embodiment of the logic associated with determining a position identifier within an input/output device to be used to restart a program, in accordance with the principles of the present invention;

[0027] FIG. 8 depicts one embodiment of the logic associated with completing a channel program, in accordance with the principles of the present invention; and

[0028] FIG. 9 depicts one embodiment of the logic associated with performing error recovery for a channel program, in accordance with the principles of the present invention.

[0029] In accordance with the principles of the present invention, a capability is provided for repositioning an input/output device in order to retry a program. The repositioning is performed without any knowledge of current positioning within the input/output device or of any knowledge of where the program previously completed. That is, the repositioning capability of the present invention is irrespective of and independent of current device positioning.

[0030] One embodiment of a computing environment 100 incorporating and using the repositioning capability of the present invention is depicted in FIG. 1. Computing environment 100 is based, for instance, on the Enterprise Systems Architecture (ESA)/390 offered by International Business Machines Corporation. ESA/390 is described in the following references: “Enterprise Systems Architecture/390 Principles of Operation”, IBM Publication No. SA22-7201-04, June 1997; and “Enterprise Systems Architecture/390 Common I/O Device Commands”, IBM Publication No. SA22-7204-02, August 1995, each of which is hereby incorporated herein by reference in its entirety.

[0031] As one example, computing environment 100 includes a main storage 102, one or more central processing units (CPU) 104, a storage control element 106, a channel subsystem 108, one or more control units 110 and one or more input/output (I/O) devices 112, each of which is explained below.

[0032] Main storage 102 stores data and programs which are input from input devices 112. Main storage 102 is directly addressable and provides for high-speed processing of data by central processing unit(s) 104 and channel subsystem 108. In one example, main storage 102 includes a customer storage area and a system area (not shown).

[0033] Central processing unit 104 is the controlling center of computing environment 100. As is known, central processing unit 104 executes at least one operating system 105, which is used to control the operation of the computing environment by controlling execution of other programs, controlling communication with peripheral devices and controlling use of the computer resources. Further, in accordance with the principles of the present invention, operating system 105 is enhanced with the repositioning capabilities of the present invention.

[0034] One example of an operating system, which includes the capabilities of the present invention, is the OS/390 or Multiple Virtual Storage (MVS)/ESA operating system offered by International Business Machines Corporation.

[0035] Central processing unit 104 is coupled to storage control element 106 via a bidirectional bus or a unidirectional bus 114. The storage control element is further coupled to main storage 102 via a bus 116 and to channel subsystem 108 via a double word bus 118. Storage control element 106 controls, for example, the queuing and the execution of requests made by CPU 104 and channel subsystem 108.

[0036] Channel subsystem 108 is further coupled to each of the control units via a serial link 120. Channel subsystem 108 directs the flow of information between input/output devices 112 and main storage 102. It relieves the central processing unit(s) of the task of communicating directly with the input/output devices and permits data processing to proceed concurrently with input/output processing. The channel subsystem uses one or more channel paths 122 as the communication links in managing the flow of information to or from input/output devices 112. As a part of the input/output processing, channel subsystem 108 also performs the path-management function of testing for channel path availability, selecting an available channel path and initiating execution of the operation with the input/output device.

[0037] Each channel path 122 includes a channel 124 (located within the channel subsystem), one or more control units 110 and one or more connections 120. As examples, connections 120 may be serial links based on the Enterprise Systems Connection Architecture (ESCON) (described in detail in “Enterprise Systems Architecture/390 ESCON I/O Interface”, Form No. SA22-7202-02 (August 1992), which is hereby incorporated herein by reference in its entirety); parallel OEMI attachments (described in detail in “Enterprise Systems Architecture/390, System/360 and System/370 I/O Interface Channel to Control Unit Original Equipment Manufacturers' Information”, Document Number GA22-6974-10 (September 1992), which is hereby incorporated herein by reference in its entirety); a fiber channel (FICON) bridge or other fiber channel attachments.

[0038] In another example, it is also possible to have one or more dynamic switches as part of the channel path. A dynamic switch is coupled to a channel and a control unit and provides the capability of physically interconnecting any two links that are attached to the switch.

[0039] Also located within channel subsystem 108 are subchannels (not shown). One subchannel is provided for and dedicated to each input/output device accessible to the channel subsystem. A subchannel provides the logical appearance of a device to the program. Each subchannel provides information concerning the associated input/output device 112 and its attachment to channel subsystem 108. The subchannel also provides information concerning input/output operations and other functions involving the associated input/output device. The subchannel is the means by which channel subsystem 108 provides information about associated input/output devices 112 to central processing unit(s) 104, which obtain this information by executing input/output instructions.

[0040] The subchannel consists of internal storage that contains the information in the form of a channel command word (CCW) address, channel path identifier, device number, count, status indications, and input/output interruption subclass code, as well as information on path availability and functions pending or being performed. Input/output operations are initiated with device 112 by executing input/output instructions that designate the subchannel associated with the device.

[0041] Each control unit 110 provides the logic to operate and control one or more input/output devices and adapts, through the use of common facilities, the characteristics of each input/output device to the link interface provided by the channel. The common facilities provide for the execution of input/output operations, indications concerning the status of the input/output device and control unit, control of the timing of data transfer over the channel path and certain levels of input/output device control.

[0042] Each control unit 110 is attached via a bus 126 to one or more input/output devices 112. In one embodiment, each control unit may be attached to up to 256 input/output devices. Input/output devices 112 receive information from or store information in main storage 102. Examples of input/output devices include card readers and punches, magnetic-tape units, direct-access storage devices, displays, keyboards, printers, teleprocessing devices, communication controllers, sensor-based equipment, and other storage media.

[0043] The writing of data from main storage to the input/output devices or the reading of data from the input/output devices to main storage is accomplished by executing input/output operations. The execution of input/output operations is accomplished by the decoding and executing of channel programs by the channel subsystem and the input/output devices. In particular, it is the decoding and executing of the one or more channel command words of each of the channel programs.

[0044] In one embodiment, the processing of each channel command word is completed before the processing of the next channel command word begins. That is, a command and any associated data is sent from the channel to the control unit and an appropriate response is received from the control unit before a new command can be sent. However, in another embodiment, the processing of a number of channel command words may be initiated before any response is received from the control unit. This is referred to as pipelining of the processing of channel command words, which is further described in U.S. Pat. No. 5,526,484, Casper et al., entitled “Method and System For Pipelining The Processing of Channel Command Words,” issued on Jun. 11, 1996 and assigned to International Business Machines Corporation, which is hereby incorporated herein by reference in its entirety.

[0045] In accordance with the principles of the present invention, a program can be retried in the event the program did not end successfully, the program ended prematurely or for any other reason that retry is desired. One example of such a program is a channel program either with or without pipelining.

[0046] In the particular embodiment described herein, the programs are stored on position sensitive input/output devices, such as tape devices, as one example. Thus, in order to retry the program, the input/output device is repositioned to, for instance, the beginning of the channel program. This repositioning is performed without having any knowledge of the current positioning within the input/output device. Further, in the case of channel programs, the repositioning of the input/output device occurs without any knowledge of which channel command word was last executed or which channel command word caused the failure of the program. One embodiment of how this is accomplished is described below.

[0047] The particular embodiment described herein references a channel program stored on a tape device. However, the invention is not limited to such programs or devices. The invention may be used with any type of program that is to be restarted or retried for any purpose, and with any type of devices, especially any devices that are position sensitive.

[0048] In order to provide the repositioning capability of the present invention, the operating system employs control blocks, referred to as Unit Control Blocks (UCB), each of which is associated with an input/output device. The Unit Control Blocks are constructed by the operating system (e.g., the Input/Output Supervisor (IOS) of the MVS operating system) using the self-description data from the I/O devices, and stored in memory. One example of a Unit Control Block (UCB) is depicted in FIG. 2.

[0049] Unit Control Block 200 is used to represent the state of an input/output device 112 and is constructed, for instance, as three components: a Component 202, which includes a Unit Control Block Device Class Extension Area 204; a Component 206, which includes a Unit Control Block Prefix Area 208 and an I/O Supervisor UCB Extension Area 210; and a Component 212, which includes a Unit Control Block Common Extension Area 214, a UCB Common Area 216, and a UCB Device Dependent Segment 218.

[0050] UCB Device Class Extension Area 204 includes, in accordance with the principles of the present invention, a block-id 220, which indicates a physical position on the input/output device; and a state field 222, which specifies the state of the block-id. The valid states include current indicating that the block-id is current; last known value, not current specifying that the block-id is the last valid value, but it is not current; and invalid indicating that the block-id cannot be relied upon.

[0051] UCB Prefix Area 208 includes an I/O Request First Field (IOQF) 224 that points to a first I/O request block 226 in a chain of I/O request blocks; and an I/O Request Last Field (IOQL) 230 that points to the last I/O request block in the chain. There is an I/O request block for each I/O request (e.g., each channel program) that has been initiated.

[0052] Each I/O request block 226 points to a corresponding I/O Supervisor Block (IOSB) 232, which points to a list of the channel command words 234 associated with the I/O request or channel program.

[0053] I/O Supervisor UCB Extension Area 210 indicates state information used by the IOS component for managing the I/O operation.

[0054] UCB Common Extension Area 214 also includes an I/O request pointer 236 to the list of active I/O requests. Further, UCB Common Area 216 and UCB Device Dependent Segment 218 include pertinent information for the specific device associated with the UCB.

[0055] The Unit Control Block, and in particular, the block-id and state fields within the UCB Device Class Extension Area of the UCB are referenced and updated during the processing of the present invention, as described below with reference to FIGS. 3-9.

[0056] FIG. 3 describes one embodiment of the processing that occurs when a channel program is started for an input/output device. It is during this processing that the state of the position identifier (e.g., the block-id) is initialized.

[0057] Referring to FIG. 3, when a channel program is started for a device, a device dependent Start I/O exit (SIO) is invoked, STEP 300. During this exit, a determination is made as to whether the channel program is allowed to be prefixed, INQUIRY 302. This determination is made by checking an IOSBYP field stored within IOSB 232 (FIG.2). If the channel program prefix is to be bypassed, then block-id 220 is marked as invalid in the UCB corresponding to the device, STEP 304. Processing then returns to IOS to start the channel program, STEP 306. (In another embodiment, the block-id is not invalidated.)

[0058] On the other hand, if the I/O Requester does not require the channel program prefix to be bypassed, then a check is made to determine if the current block-id is valid, INQUIRY 308. If the current block-id is not valid, then the user channel program is prefixed with a read block-id command in order to place a valid block-id in the UCB, STEP 310. In particular, a channel command word is constructed that includes a command to read the current block-id of the channel program.

[0059] Thereafter, or if the current block-id is valid, then the channel program prefix is completed by constructing a modeset command and branching (via a transfer in channel (TIC)) to the user channel program, STEP 312. The modeset command is used to define certain parameters of execution for the channel program. In one embodiment, the modeset command may be required to be first in the chain of commands. If so, the modeset command is constructed first, and then the read block-id command is chained to it. Subsequently, processing is returned to IOS to start the channel program, STEP 306.

[0060] When the channel program completes, an I/O interrupt is received by the operating system from the I/O device, STEP 400 (FIG. 4). Upon receipt of the I/O interrupt, an I/O First Level Interrupt Handler (FLIH) receives control in order to process the interrupt, STEP 402. In the ESA architecture, the interrupt identifies the device (subchannel) and returns a programming parameter that is used by OS/390 to locate the Unit Control Block that represents that device in the operating system.

[0061] Thereafter, the operating system obtains a lock on the UCB in order to serialize processing for the device, STEP 404. Subsequent to obtaining the lock, the operating system retrieves the status of the channel program and stores that status, STEP 406. In one example, the status is retrieved by issuing a Test Subchannel (TSCH) instruction, which stores the status in the form of an Interruption Response Block (IRB). The IRB contains detailed information about the channel program, any errors that may have occurred, and the address of the channel command word where the channel ended processing. For FICON attached devices, it may also include the address of the CCW last executed by the control unit.

[0062] One example of an Interruption Response Block is depicted in FIG. 5a. Interruption Response Block 500 includes, for instance, a subchannel status word 502, which provides information regarding the status of a subchannel and its associated device; an extended status word 504, which provides additional status information about the subchannel and its associated device, as described further below with reference to FIG. 5b; and an extended control word 506, which provides additional information to the program describing conditions that may exist at the channel subsystem, subchannel or device.

[0063] Extended status word 504 includes, for instance, a subchannel logout field 508 (FIG. 5b) that provides detailed model-dependent information relating to a subchannel and describes equipment errors detected by the channel subsystem; an extended report word 510 that provides information to the program describing specific conditions that may exist at the device, subchannel or channel subsystem; a failing storage address 512 that indicates the address of the failing channel command word (as seen by the channel); and a secondary channel command word address that identifies, in accordance with the principles of the present invention, the point in the channel program execution achieved by the control unit when termination occurred.

[0064] Returning to FIG. 4, subsequent to storing the status in the Interruption Response Block, the I/O FLIH performs its traditional IRB analysis, processes errors and interacts with device support code and the I/O requester (or driver), as needed, STEP 408. Thereafter, a determination is made as to whether the ending status for the channel program included a unit check indicating that the control unit or device detected an unusual condition, INQUIRY 410. In one example, this determination is made by checking the status stored in the IRB.

[0065] If a unit check is present, then the sense data is retrieved from the device and control is passed to a conventional device dependent End-of-Sense (EOS) exit, STEP 412. When the I/O FLIH has finished processing the interrupt, the enabled I/O completion processing is scheduled, STEP 414. The completion processing includes notifying the I/O requester of the completion and performing any error recovery processing, if needed.

[0066] However, if unit check status is not returned for the channel program, INQUIRY 410, then the interrupt handler calls a device dependent trap exit, STEP 416. It is during this trap exit that the block-id representing the current position within the I/O device is calculated, in accordance with the principles of the present invention. Further details concerning the trap exit and how to determine the current media position are described below with reference to FIGS. 6-7.

[0067] Subsequent to processing the trap exit and when the I/O FLIH has finished processing the interrupt, the enabled I/O completion processing is scheduled, as described above, STEP 414. Processing of the First Level Interrupt Handler is then complete, STEP 418.

[0068] As mentioned above, the device dependent trap exit is called whenever a channel program completes and there is no unit check in the device status, STEP 600 (FIG. 6). Initially, the trap exit checks to see if any errors have occurred, INQUIRY 602. In one embodiment, this is accomplished by checking an alert status field located within the subchannel status word of the Interruption Response Block. If an error has occurred, then processing ends, STEP 604, and control is returned to the I/O FLIH (STEP 414 of FIG. 4).

[0069] However, if no errors occurred, then the trap exit makes a determination as to whether the channel program is complete at both the channel and the device, INQUIRY 606. This determination is made by checking a primary status field and a secondary status field within the subchannel status word of the Interruption Response Block. When the channel program is complete at the channel end, then the primary status field is set, and similarly, when the channel program is complete at the device end, then the secondary status field is set.

[0070] If the operation is complete at the channel end, but not at the device, then a further determination is made as to whether a CCW standalone rewind instruction has been initiated. This instruction tells the operating system to do a rewind of the tape, ensure the job is complete and then, unload the tape. If such an instruction is initiated, then it is not desirable to wait for the device to complete. Thus, processing continues with STEP 612. However, if this instruction is not initiated, then processing waits until the device ends, STEP 610.

[0071] When the device ends (e.g., IOQMERGE indication set in a return code), or when there is no standalone rewind, INQUIRY 608, or when the channel program is complete at both the channel end and the device end, INQUIRY 606, then the channel program is scanned to calculate the new block-id within the I/O device representing past the ending position of the channel program, STEP 612. It is this block-id that represents the beginning of the next channel program and is used to restart the next channel program, should the next channel program need to be retried.

[0072] One example of how to determine the new block-id is described with reference to FIG. 7. In this embodiment, it is assumed that the channel command word is a Format-1 (31-bit addressing) channel command word. However, the same logic is used for Format-0 channel command words. Format-1 and Format-0 channel command words include the same information, but the fields are arranged differently.

[0073] Initially, a variable referred to as CCWPTR is set equal to IOSRST, which is the real address of the channel program that just completed, STEP 700. Thereafter, a determination is made as to whether command chaining is off or data chaining is on for the first channel command word of the channel program, INQUIRY 702. In one example, this determination is made by checking the chain data and chain command fields of the channel command word. If command chaining is off or data chaining is on, then the process is complete, STEP 704.

[0074] On the other hand, if command chaining is on and data chaining is off, then a load using real address instruction is issued to obtain the opcode of the first channel command word of the channel program, STEP 706. If the opcode is a transfer in channel (TIC) (i.e., a branch within the channel program), INQUIRY 708, then another load using real address instruction is issued, STEP 710. This time the real address of the first channel command word is loaded in the variable referred to as CCWPTR. Thereafter, flow returns to INQUIRY 702 for the next channel command word of the channel program.

[0075] Returning to INQUIRY 708, if the opcode is not a transfer in channel, then checks are made to determine whether the block-id is to be incremented, decremented, unchanged or invalidated. An opcode array is used for these determinations. For example, the opcode array includes a list of possible commands and for each command, there is a one byte entry. Each one byte entry has four bits, one for add (A), decrement (D), do nothing (N), and invalidate (I). One example of the array is as follows:

[0076] Initially, a determination is made as to whether the opcode of the channel command word represents a command that causes the block-id to be incremented, INQUIRY 711. If it is such a command (e.g., a read or a write), then the block-id is incremented by one, STEP 712. However, if the opcode represents a command that causes the block-id to be decremented, INQUIRY 714, then the block-id is decremented by one, STEP 716.

[0077] If the block-id is not to be incremented or decremented, then a determination is made as to whether the command should cause no change in the block-id, INQUIRY 718. If so, then nothing is done to the block-id, STEP 720. However, if the command does not cause an add, decrement or do nothing to the block-id, then the block-id is invalidated, STEP 722. Thereafter, the CCWPTR is incremented (e.g., by 8) to point to the next channel command word of the channel program, STEP 724. Processing then continues with INQUIRY 702.

[0078] At the completion of the scan through the channel program, the status of the block-id is known. It is either invalid or representative of the beginning of the next channel program to be executed. This status is stored in the IRB.

[0079] After the channel program is complete, the status analyzed and all dependent exits invoked (FIG. 1), the I/O requester is notified of the completion of the channel program from the enabled backend processing (IOS Post Status processing), which is described with reference to FIG. 8.

[0080] Initially, a determination is made as to whether the device error recovery procedure (ERP) is already in control, INQUIRY 800. If it is not in control, then the device status, located in the Interruption Response Block, is checked to see if any error occurred, INQUIRY 802. If no errors occurred the I/O requester is notified that the I/O completed normally by entering the driver normal end exit, STEP 804. After the driver normal end exit has finished processing, IOS cleans up resources that may have been obtained for the channel program and enters a driver termination exit, STEP 806. Processing then terminates, STEP 808.

[0081] If an I/O error has occurred, INQUIRY 802, then the driver abnormal end exit is entered in order to handle the abnormal end, STEP 810. The abnormal end exit determines whether the error needs to be processed, INQUIRY 812. If the error is of a type that it does not need to be processed, then control passes to the normal end exit, STEP 804. However, if the abnormal end exit confirms that the error needs to be processed, then control is given to the device error recovery procedure, STEP 814, which is described in detail below with reference to FIG. 9.

[0082] Further, returning to INQUIRY 800, if the device error recovery procedure is already active, then control is returned to the error recovery procedure, STEP 814. This happens, for example, after a retry of a channel program has completed.

[0083] If the device error recovery procedure determines that the channel program can be retried, INQUIRY 816, then a STARTIO service is invoked to initiate the retry, STEP 818. In accordance with the principles of the present invention, in order to retry the channel program, the I/O device is repositioned to the block-id calculated above.

[0084] However, if the error is to be considered permanent, or a previous retry was successful, then the I/O driver is notified, STEP 820, and processing terminates, STEP 808.

[0085] One embodiment of the device error recovery procedure called in the above logic is described below with reference to FIG. 9. When the device error recovery procedure (ERP) is entered, it first checks to see if it is being called with the results of a previous retry, INQUIRY 900. If so, resources obtained for the purpose of the retry are freed and control is returned to the IOS post status process, STEP 902, which was described with reference to FIG. 8.

[0086] If, however, the ERP has not been entered for the results of a previous retry, processing continues by checking to see whether the I/O requester has indicated that the channel program has been modified by the program during execution, INQUIRY 904. The I/O driver specifies this by setting a specific indicator (IOSXCPNM) in an IOS request block.

[0087] If the channel program was not modified during execution, then a determination is made to see if the block-id saved in the UCB is currently valid, as determined by the device trap exit, INQUIRY 906. If the block-id is valid, then the retry channel program is built, STEP 908. In particular, the retry channel program includes a Locate Block command to reposition the input/output device to the position at the start of the failing channel program. Further, it includes a transfer to the original user channel program (e.g, a TIC to IOSRST) to attempt the request again. Control is then returned to IOS with an indication to issue the retry channel program, STEPS 910, 902.

[0088] However, if the block-id is not valid, INQUIRY 906, or if the channel program may have been modified by the driver, INQUIRY 904, then the recovery is attempted by examining the ending channel program address, STEP 912. In particular, the interrupt status of the IRB is examined to determine if the ending CCW address is valid or not. There may be two ending CCW addresses with FICON attached devices. The traditional ending CCW address represents where the channel stopped processing the program (e.g., at which CCW). The second CCW address, if present, indicates where the control unit stopped processing the program (again, at which CCW). If the ending CCW addresses are not valid, the error is considered permanent, STEP 914, and processing terminates, STEP 902.

[0089] On the other hand, if the ending CCW addresses are valid, then the ERP determines how to reposition the input/output device and retry the failing CCW. If there are two different ending CCW addresses, then the channel program is scanned from the first failing CCW address to the second failing CCW address, STEP 916. During the scan, it calculates the number of records to be used in repositioning the input/output device. Consider the following example:

[0090] In the above example, the ERP sees that the 2nd CCW address points to the (5) read, and the channel points to the (3) read. The ERP scans the channel program to see that there are 3 commands between the two CCW addresses, (3), (4), and (5). The ERP backspaces three blocks before resuming the channel program.

[0091] If there is a single failing CCW address, the ERP determines whether to move the input/output device forward or backward a single record, based on traditional processing of the interrupt status.

[0092] Thereafter, a retry channel program is built to reposition the input/output device, STEP 918. For example, the channel program is built by using Back-Space-Block (BSB) commands and a TIC to the failing CCW. The Back-Space-Block commands tells the media how much to back up.

[0093] Subsequently, control is returned to IOS to retry the failing channel program from the point of failure, STEPS 910, 902.

[0094] Described in detail above, is a mechanism for repositioning I/O devices in order to retry programs, such as channel programs. In one example, the I/O device is repositioned without any knowledge of where the failing program ended. Additionally, in the case of a channel program, the I/O device is repositioned without any knowledge of which channel command word was the last to execute. Further, in other limited circumstances, such as where there is an invalid block-id or the program has been modified, a position identifier is determined by using one or more addresses associated with the failing program (e.g., one or more CCW addresses). This allows some errors that were once considered permanent, to be recovered therefrom.

[0095] The computing environment described above is only one example of a computing environment that can incorporate and use the repositioning capability of the present invention. The capability of the present invention is equally applicable to other architectures, as well as other types of environments. For example, in another environment, the storage control element can be eliminated and instead, both the main storage and the central processing unit(s) are directly coupled to the channel subsystem. Other variations are also possible without departing from the spirit of the present invention.

[0096] The present invention can be included in an article of manufacture (e.g., one or more computer program products) having, for instance, computer usable media. The media has embodied therein, for instance, computer readable program code means for providing and facilitating the capabilities of the present invention. The article of manufacture can be included as a part of a computer system or sold separately.

[0097] Additionally, at least one program storage device readable by a machine, tangibly embodying at least one program of instructions executable by the machine to perform the capabilities of the present invention can be provided.

[0098] The flow diagrams depicted herein are just exemplary. There may be many variations to these diagrams or the steps (or operations) described therein without departing from the spirit of the invention. For instance, the steps may be performed in a differing order, or steps may be added, deleted or modified. All of these variations are considered a part of the claimed invention.

[0099] Although preferred embodiments have been depicted and described in detail herein, it will be apparent to those skilled in the relevant art that various modifications, additions, substitutions and the like can be made without departing from the spirit of the invention and these are therefore considered to be within the scope of the invention as defined in the following claims.