gtps4m0x | System Generation |
The TPF system requires tape support for online and offline processing. Depending on your installation, your tape configuration and options may vary. The following information will help you:
The total number of tape drives required by the online system depends on the configuration of the system and the characteristics of the application programs being run. At a minimum, you need the following real-time tape drives for online use:
Additionally, you should provide a minimum of 3 general tapes for utility functions. These tapes can be used for either input or output.
IBM recommends that you provide at least 8 tape drives, switchable between 2 control units, to prevent a system stoppage in the event of a tape drive or control unit failure. There is a degree of flexibility allowed when specifying tape drive requirements, but fully evaluate the proposed system operation before trying to minimize the number of required tape drives. When designing the tape configuration, take into account the need to do a switchover to another physical processor. Design a configuration that allows both the online and the backup processor to have a path to the same control units.
For loosely coupled users of the HPO feature, treat the requirements for tape drives and control units for each processor in the LC complex as if each processor was a uniprocessor. The exception to this is that a control unit may be shared by more than 1 processor in the complex. The tape devices themselves are then assigned to a particular processor via command (ZTVAR). This assignment may be changed dynamically when no processor is physically using a particular device. The LC user, in addition to the uniprocessor requirements for switchover, must also take into account tape configuration when expanding and collapsing the LC complex.
SIP macro IODEV is used to configure channel and control unit information that is used to generate program segment COSY (Tape Control Unit Cross-Reference Table). The tape control unit cross-reference table (TCXR) is required by the restart and reconfiguration functions. The table is read into storage during tape restart.
The following parameters of SIP macro IODEV (device characteristics) relate to tape support:
For more information about the IODEV macro see IODEV. For a list of supported devices, models, and features, see the TPF Migration Guide: Program Update Tapes.
The device numbers specified in the I/O Configuration Program (IOCP) source deck represent logical channels, control units, or device addresses. Therefore, the IOCP source must be created in such a way that devices in the same logical control unit range are in the same physical control unit range and physical channel path ID (CHPID). Similarly, devices on the same CHPID and in the same physical control unit range must be specified as being in the same logical control unit range when assigning device numbers to them. Tape restart will then be able to check the device numbers obtained from the channel subsystem during system initialization against the logical channel and control unit definitions produced by the IODEV macro.
SIP generates keypoint record A (CTKA), which contains bit switches for test mode operation (normal vs. test) and real-time tape operation (normal vs. merge to RTA). The default settings for both of these bits are normal. To change these settings, the assembled keypoint record must be modified via patching.
The following tape options are allowed by modifying the field that maps to CPMOPT in SKCTKA. The proper field modification is listed by each option.
This option is intended for use by test systems and, if used in a production system, should not be changed once the system is generated.
The system treats these as undefined-length format tapes.
Notes:
You can control whether TPF monitors stalled tape module queues and how many seconds may elapse before a stalled queue is reported through the ZCTKA command. In setting the timeout value, you might start by setting the value to 10 seconds and then determine if that amount of time is adequate for detecting stalled tape module queues on your system. If the timeout value is too low, the system overhead increases. If the timeout value is too high, the stalled tape module queue may not be detected quickly enough to recover before a problem causes a system outage.
TPF-supported tape units contain buffers that are used to increase I/O performance. Devices with buffers can receive errors that require the records in the control unit to be retrieved and written to a new tape. The process of retrieving the records and writing them to a new tape is referred to as dynamic device reconfiguration (DDR). TPF supports two modes of DDR: first-in-first-out (FIFO) and last-in-first-out (LIFO). See the TPF Migration Guide: Program Update Tapes to determine which tape units and licensed internal code are required to support FIFO control unit buffer recovery.
If all tape drives in a system are capable of FIFO recovery, there is no need to allocate any additional working storage for DDR. If there are some tape drives in a system that are not capable of FIFO control unit buffer recovery, it is recommended to allocate at least 1-1/2 times the maximum number of blocks required to recover the control unit buffer (including the SWBs necessary for requeuing the records) for each block type in addition to normal allocation. This will allow for two buffer recoveries to take place, one after the other.
TPF supports the tape library dataserver through the ZTPLF command. If the ZTPLF RESERVE and ZTPLF RELEASE commands are not supported for your version of the tape library dataserver, default categories (categories into which volumes are moved after they have been used by the TPF system) are defined in TAPEQ. One value is assigned for each processor in the complex as shown in the following:
Processor 0 - X'1000' tag name DEFLTPR0 Processor 1 - X'1100' tag name DEFLTPR1 Processor 2 - X'1200' tag name DEFLTPR2 Processor 3 - X'1300' tag name DEFLTPR3 Processor 4 - X'1400' tag name DEFLTPR4 Processor 5 - X'1500' tag name DEFLTPR5 Processor 6 - X'1600' tag name DEFLTPR6 Processor 7 - X'1700' tag name DEFLTPR7 Processor 8 - X'1800' tag name DEFLTPR8 Processor 9 - X'1900' tag name DEFLTPR9 Processor 10 - X'1A00' tag name DEFLTPR10 Processor 11 - X'1B00' tag name DEFLTPR11 Processor 12 - X'1C00' tag name DEFLTPR12 Processor 13 - X'1D00' tag name DEFLTPR13 Processor 14 - X'1E00' tag name DEFLTPR14 Processor 15 - X'1F00' tag name DEFLTPR15 Processor 16 - X'2000' tag name DEFLTPR16 Processor 17 - X'2100' tag name DEFLTPR17 Processor 18 - X'2200' tag name DEFLTPR18 Processor 19 - X'2300' tag name DEFLTPR19 Processor 20 - X'2400' tag name DEFLTPR20 Processor 21 - X'2500' tag name DEFLTPR21 Processor 22 - X'2600' tag name DEFLTPR22 Processor 23 - X'2700' tag name DEFLTPR23 Processor 24 - X'2800' tag name DEFLTPR24 Processor 25 - X'2900' tag name DEFLTPR25 Processor 26 - X'2A00' tag name DEFLTPR26 Processor 27 - X'2B00' tag name DEFLTPR27 Processor 28 - X'2C00' tag name DEFLTPR28 Processor 29 - X'2D00' tag name DEFLTPR29 Processor 30 - X'2E00' tag name DEFLTPR30 Processor 31 - X'2F00' tag name DEFLTPR31
For tape library dataservers that do not support the ZTPLF RESERVE and ZTPLF RELEASE commands, the CORB segment uses a table, created from the TAPEQ values, to determine the correct default category. Users can change default categories by changing TAPEQ values and reassembling CORB, or by adding code to the CORU user exit.
When you issue the ZTPLF FILL command, the tape library dataserver keeps a tape device filled with volumes from a specified FILL category. To prevent you from running out of the FILL category tapes, use CMMNBRV to predefine the minimum number of tapes allowed for the FILL category. (CMMNBRV sets the minimum tape number value in CK1VOLS in CTKA. CK1VOLS is defined in CK1KE.) If the number becomes less than the predefined minimum, the operator is notified of the condition by a system message.