gtps4m17 | System Generation |
A two-byte symbolic device address is required to uniquely address a given DASD device. The 2 high-ordered hex digits represent the logical channel number of the DASD. The 2 low-ordered hex digits represent the logical control unit, the string address, and finally the logical device. The maximum number of DASD devices allowed per control unit is 64, but it is also possible to define DASD control units that service 32 or 16 DASD devices. In any case you must code the number of devices that will be attached to each controller on the SIP CONFIG DCUSV parameter. Three examples follow. Figure 17 shows how to interpret the address when a controller services 32 devices. Figure 18 is similar, but is for a 16-device controller and Figure 19 is for a 64-device controller.
Figure 17 shows how the DASD address 03A7 is interpreted.
Figure 17. Example of a 32-Device Controller
where:
3 is the logical channel address
A is the logical control unit address for the lower 16 (0-15) drives
B is the logical control unit address for the upper 16 (16-31)
drives.
In order to define data paths for 32 drives, four IODEV macros must be coded. The following IODEV macro statements define controller 5 on channel 03 with 32 devices:
IODEV IOADR=03A0,DVTYP=DASD IODEV IOADR=03B0,DVTYP=DASD IODEV IOADR=03A8,DVTYP=DASD IODEV IOADR=03B8,DVTYP=DASD
where:
3 is the logical channel address
A is one logical control unit address
B is same as A, but for devices 16-31.
Notes:
Figure 18 shows how the DASD address 03A7 is interpreted.
Figure 18. Example of a 16-Device Controller
where:
3 is the logical channel address
A is the logical control unit address.
In order to define data paths for 16 drives, 2 IODEV macros must be coded. The following IODEV macro statements define controller A on channel 03 with 16 devices:
IODEV IOADR=03A0,DVTYP=DASD IODEV IOADR=03A8,DVTYP=DASD
where:
3 is the logical channel address
A is the sole logical control unit address.
Figure 19 shows how the DASD address 03A7 is interpreted.
Figure 19. Example of a 64-Device Controller
where:
3 is the logical channel address
8 is the logical control unit address for the first 16 (0-15) drives
9 is the logical control unit address for the next 16 (16-31) drives
A is the logical control unit address for the next 16 (32-47) drives
B is the logical control unit address for the last 16 (48-63)
drives.
In order to define data paths for 64 drives, 8 IODEV macros must be coded. The following IODEV macro statements define controller 8, 9, A and B on channel 03 with 64 devices:
IODEV IOADR=0380,DVTYP=DASD IODEV IOADR=0388,DVTYP=DASD IODEV IOADR=0390,DVTYP=DASD IODEV IOADR=0398,DVTYP=DASD IODEV IOADR=03A0,DVTYP=DASD IODEV IOADR=03A8,DVTYP=DASD IODEV IOADR=03B0,DVTYP=DASD IODEV IOADR=03B8,DVTYP=DASD
where:
3 is the logical channel address
8,9,A and B are the logical control unit addresses.
SIP provides the user with a number of macros to define the following online modules and data sets:
The SIP example in Figure 20 consists of the macros and macro parameters required to define the following configuration:
Figure 20. Sample SIP Parameters for Online Modules
TPF internally controls the various device types with a set of file status tables. Figure 21 lists the 3 tables and describes their organization. In general, these tables include slots for the various file devices supported by the system being generated plus a copy module slot. A copy module slot is a file status table entry reserved for the exclusive use of the file copy system operator message programs. File copy allows the system operator to copy an entire disk module from 1 online module to another (copy) module. The system addresses these tables via symbolic module numbers. While it is not necessary to understand these tables to generate a system, it will be helpful to understand the concept of symbolic module numbers as it relates to the mapping of application program file references (FIND, FILE, and others) to physical hardware addresses. TPF Concepts and Structures provides more information on this subject.
Figure 22 provides a sequential list of the symbolic module numbers relating to the SIP example in Figure 20. These same symbolic module numbers are included in Table 9.
Figure 21. Module Status Table Layout Example
Figure 22. Symbolic Module Numbers Example
While the example given includes a variety of device types, only those devices included in a specific generation will require table entries. The one exception is that symbolic module numbers 00 and 01 are always reserved.
The RAM macro GFMOD parameter is used to specify the symbolic module number for the first general file. SIP provides a default value of 230. The example specifies a starting value of 20. The RAM macro's GFENS parameter specifies 5 entries in the general file module table, which means that a maximum of 5 general file data sets can be defined in the system.
Support is provided for up to 3997 online modules per subsystem. The symbolic module numbers in parentheses in Figure 21 indicate the maximum symbolic numbers permitted by the various status tables.
General data set support is specified by the RAM macro's NEWGF=YES parameter in the example in Figure 20. This function uses the DASD general data set slots to support the general data set modules.
The worksheet in Table 8 is provided for recording the valid channel, control unit,
and device addresses for all online and offline (including any expansion)
direct access devices. This data will be used to code the SIP IODEV
macros for direct access devices.
Table 8. Direct Access Device Worksheet
Channel | Control Unit | Device Address |
---|---|---|
* 03 | A | 0 |
|
Table 9 provides an example of the standard TPF volume serial number format. The inputs coded in Figure 20 generated the example. TPF VSNs must contain exactly 6 symbols of the form AANNNN, where:
AA = 2 alphabetical characters
NNNN = 4 decimal numeric characters.
The AANNNN format is mandatory for all online modules, the copy module, and the loader general file. In a subsystem, the AA portion of the VSN will be identical for all the DASD described in the preceding sentence. Across subsystems, the AA portion is required to be unique. It follows directly from the format that up to 10000 differing VSNs could be coded for any 1 subsystem; however, the capacity of the module file status table limits the actual number of usable DASD to 3999.
Six SIP parameters are used to code TPF VSNs. The first 5 are on the ONLFIL macro; they are VSNCHAR and VOLNOx (where x = A, B, C, or D). The sixth parameter is VOLNLGF and it is found on the GENSIP macro. VSNCHAR specifies the AA portion of the VSN for not only the online modules, but also the copy module and the LGF as well. VOLNOx and VOLNLGF code the NNNN portion for the online modules and the loader general file respectively. Only the starting VSN is needed as SIP will sequentially assign ascending numerals based on the number of modules in each device type.
The ONLFIL macro also provides a parameter for specifying the VSNs of spare devices to be used for copying online modules in the event of a device failure. SPARVSNx (where x = A, B, C, or D) specifies the first 4 characters of VSNs to be ignored by disk roll call during IPL. This allows the user to attach spare devices to be renamed and copied at a later time.
For additional information concerning VSNs and how they are coded, see ONLFIL.
Table 9. Disk Online Module List Example
Symbolic Module Numbers | Volume Serial Number | Device Type |
---|---|---|
26 | TP0110 | 3390 |
27 | TP0111 | 3390 |
34 | TP2120 | 3380 |
35 | TP2121 | 3380 |
While AANNNN is the standard format, TPF provides a migration tool to convert VSNs that employ the older format: AAANNN. The old AAANNN format had to be obsoleted when TPF initiated support for over 1000 DASD. The migration tool is activated by SIP ONLFIL macro parameter OLDVSN. OLDVSN accepts the AAA portion of the old format as input. The first 3 characters of the old format VSN must be identical for all online DASD of the same subsystem. Across subsystems, the first 2 characters must be unique.
When OLDVSN is coded, the VSNs generated in keypoint V will be in the new AANNNN format, but a migration driver switch is turned on. The switch alerts the restart programs to convert the VSNs. When the old format is converted to the new format, the third character is changed to zero (for example, AAANNN > AA0NNN). In order for the migration tool to work, it is assumed that the table of online VSNs in the old keypoint V are in a constantly ascending sequence with no gaps in a device type. For additional information about how to code OLDVSN in order to activate the migration driver, see ONLFIL.
Table 10 is provided for recording all online disks. The
starting volume serial number for each device type will be listed in the SIP
report.
Table 10. Volume Serial Number Worksheet
Symbolic Module Number | Volume Serial Number | Device Type |
---|---|---|
02 | TP0101 | 3380 |
|