Database device addressing

A two-byte symbolic device address is required to uniquely address a given DASD device. The 2 high-ordered hexadecimal digits represent the logical channel number of the DASD. The 2 low-ordered hexadecimal 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 1 shows how to interpret the address when a controller services 32 devices. Figure 2 is similar, but is for a 16-device controller and Figure 3 is for a 64-device controller.

To uniquely address each of the 32 (CONFIG (DCUSV=32)) drives on a given controller, the 2 low-ordered hexadecimal digits are divided as follows:
- Logical control unit address (bits 0–2)
- String address (bits 3–4)
- Logical device address (bits 5–7).
The control unit address must start with an even hexadecimal digit in the third position of the 4-digit device address for the first 16 drives, and continue through the next higher odd hexadecimal digit in the third position for the next 16 drives, for example, 0140–014F and 0150–015F.

Figure 1 shows how the DASD address 03A7 is interpreted.

Alternative text description not available. — Figure 1. Example of a 32-device controller

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.

Note:

If the system had been generated to support only 16 drives per control unit (that is, DCUSV=16 in the SIP CONFIG macro), then all CUs would have to be configured so that the CU address is determined by bits 0–3:
- Logical Control Unit Address (bits 0–3)
- String Address (bit 4)
- Logical Device Address (bits 5–7)
The logical control unit address may start with any hexadecimal digit in the third position of the 4-digit device address. The next higher hexadecimal digit in the third position will define another control unit. Notice that this differs from the 32 device example.

Figure 2 shows how the DASD address 03A7 is interpreted.

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.

To uniquely address each of the 64 (CONFIG (DCUSV=64)) drives on a given controller, the 2 low-ordered hexadecimal digits are divided as follows:
- Logical control unit address (bits 0–1)
- String address (bits 2–4)
- Logical device address (bits 5–7).

Figure 3 shows how the DASD address 03A7 is interpreted.

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 several macros to define the following online modules and data sets:

Online disk modules (DASD device types)
General files
General data sets.

The SIP example in Table 1 consists of the macros and macro parameters required to define the following configuration:

Two online 3390s with 6 spares
Two online 3390s with 6 spares
Five DASD general file modules
Two general data sets.

Table 1. Sample SIP parameters for online modules. Only those SIP parameters related to device allocation are included in this example.
SIP input macros	Symbolic module number
IODEV IOADR=02A0,DVTYP=DASD
IODEV IOADR=03A0,DVTYP=DASD
RAM GFMOD=20,NEWGF=YES,GFENS=5,GF SLOTS,GSON=2	20–24, 25, 43–48, 49–50
ONLFIL GDS SLOTS,DEVICEA=3390,PERMA=2,VOLNOA=110,EXTRA=6, DEVICEB=3390,PERMB=2,VOLNOB=2120,EXTRB=6,VSNCHAR=TP	26, 27, 28–33, 34, 35, 36–41

The z/TPF system internally controls the various device types with a set of file status tables. Figure 4 lists the three tables and describes their organization. In general, these tables include slots for the various file devices that are supported by the system that is being generated plus a copy module slot. A copy module slot is a file status table entry reserved for the exclusive use of the module copy system message programs. Module copy provides support for you to copy an entire DASD module from 1 online module to another (copy) module. The system addresses these tables with symbolic module numbers. While it is not necessary to understand these tables to generate a system, it is helpful to understand the concept of symbolic module numbers as it relates to mapping application program file references (FIND, FILE, and others) to physical hardware addresses. For more information, see Module file status table.

Figure 5 provides a sequential list of the symbolic module numbers relating to the SIP example in Table 1. These same symbolic module numbers are included in Table 3.

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 as many as 40,000 online modules per subsystem. The symbolic module numbers in parentheses in Figure 4 indicate the maximum symbolic numbers permitted by the various status tables.

General data set support is specified by the RAM macro NEWGF=YES parameter in the example in Table 1. This function uses the DASD general data set slots to support the general data set modules.

The worksheet in Table 2 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 2. Direct access device worksheet
Channel	Control unit	Device address
* 03	A	0









Note: * For example, a 3390 DASD device.

Table 3 provides an example of the standard z/TPF volume serial number format. The inputs coded in Table 1 generated the example. z/TPF VSNs must contain exactly 6 symbols of the form AANNNN, where:

AA = 2 alphabetical characters
NNNN = 4 hexadecimal 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 online modules and the loader general file; however, the AA portion of the VSN for the copy module can be different. Across subsystems, the AA portion is required to be unique. It follows directly from the format that as many as 65 535 differing VSNs could be coded for any one subsystem; however, the capacity of the module file status table limits the actual number of usable DASDs to 40,000.

Six SIP parameters are used to code z/TPF VSNs. The first five parameters are on the ONLFIL macro; they are VSNCHAR, COPYVSN, DOWNVSN, XVOLNOx, and VOLNOx (where x = A, B, C, or D). The sixth parameter is VOLNLGF and is found on the GENSIP macro. VSNCHAR specifies the AA portion of the VSN for the online modules and the loader general file, COPYVSN specifies the AA portion of the VSN for the copy module, and DOWNVSN specifies the AA portion of the VSN for the offline modules when you enter the ZMCPY DOWN command or the ZAMOD command with the D (down) parameter specified. XVOLNOx and VOLNOx code the NNNN portion for the online modules, and VOLNLGF codes the NNNN portion of the loader general file. Only the starting VSN is needed because 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 if a device failure occurs. SPARVSNx (where x = A, B, C, or D) specifies the first 4 characters of VSNs to be ignored by disk roll call during an IPL. This allows you to attach spare devices to be renamed and copied at a later time. The COPYVSN parameter of the ONLFIL macro also allows you to specify that modules with the same AA portion of the VSN will be ignored during disk roll call during an IPL.

For more information about VSNs and how they are coded, see ONLFIL.

Table 3. Disk online module list example
Symbolic module numbers	Volume serial number	Device type
26	TP0110	3390
27	TP0111	3390
34	TP2120	3390
35	TP2121	3390

Table 4 is provided for recording all online disks. The starting volume serial number for each device type will be listed in the SIP report.

Table 4. Volume serial number worksheet
Symbolic module number	Volume serial number	Device type
02	TP0101	3390





Note: * For example, First 3390 `ONLFIL VOLNOA=101, X VSNCHAR=TP`