JES3 examples and information
This appendix provides several configuration examples in which multiple tape libraries and tape devices, native devices in an IBM System Storage TS3500 tape library, and virtual devices in an IBM TS7700 are used. This appendix also describes the necessary parameters and considerations that must be installed in a job entry subsystem 3 (JES3) environment.
The following examples are used:
Two libraries with an intermix of native drives of 3592-J1A and 3592-E05 installed
Three libraries with an intermix of 3592-J1A, 3592-E05, 3592-E06/EU6, stand-alone cluster TS7700 Grid, and multi-cluster TS7700 Grid installed
This appendix includes the following sections:
JES3 support for system-managed tape
JES3 tape library support with Data Facility System Management Subsystem (DFSMS) is described in the following sections. The primary purpose of this support is to maintain JES3 resource allocation and share tape devices. For more information, see z/OS JES3 Initialization and Tuning Reference, SA32-1005 and z/OS JES3 Initialization and Tuning Guide, SA32-1003.
DFSMS has support that provides JES3 allocation with the appropriate information to select a tape library device by referencing device strings with a common name among systems within a JES3 complex.
All tape library devices can be shared between processors in a JES3 complex. They must also be shared among systems within the same storage management subsystem complex (SMSplex).
 
Consideration: Tape drives in the TS3500 tape library cannot be used by JES3 dynamic support programs (DSPs).
Define all devices in the libraries through DEVICE statements. All TS3500 tape library drives within a complex must be either JES3-managed or non-JES3-managed. Do not mix managed and non-managed devices. Mixing might prevent non-managed devices from use for new data set allocations and reduce device eligibility for existing data sets. Allocation failures or delays in the job setup can result.
Neither JES3 or DFSMS verifies that a complete and accurate set of initialization statements is defined to the system. Incomplete or inaccurate TS3500 tape library definitions can result in jobs failing to be allocated.
Library device groups
Library device groups (LDGs) isolate the TS3500 tape library drives from other tape drives in the complex. They enable JES3 main device scheduler (MDS) allocation to select an appropriate set of library-resident tape drives. The DFSMS JES3 support requires LDGs to be defined to JES3 for SETNAME groups and high-watermark setup name (HWSNAME) names in the JES3 initialization statements.
During converter/interpreter (CI) processing for a job, the LDG names are passed to JES3 by DFSMS for use by MDS in selecting library tape drives for the job. Unlike a JES2 environment, a JES3 operating environment requires the specification of esoteric unit names for the devices within a library. These unit names are used in the required JES3 initialization statements.
 
Important: Even if the LDG definitions are defined as esoterics in HCD, they are not used in the job control language (JCL). There is no need for any UNIT parameter in JES3 JCL for libraries. The allocation goes through the automatic class selection (ACS) routines. Coding a UNIT parameter might cause problems.
The only need for coding the LDG definition is in HCD as an esoteric name is the HWSNAME definitions in the JES3 INISH deck.
Each device within a library must have exactly four special esoteric names that are associated with it. There is a fifth special esoteric name for a TS7700 distributed library if DAA or SAA is being used, which we describe separately:
The complex-wide name is always LDGW3495. It enables you to address every device and device type in every library.
The library-specific name is an eight-character string that is composed of LDG prefixing the five-digit library identification number. It enables you to address every device and device type in that specific library.
The complex-wide device type, which is listed in Table C-1, defines the various device types that are used. It contains a prefix of LDG and a device type identifier. It enables you to address a specific device type in every tape library.
Table C-1 Library device groups - complex-wide device type specifications
Device type
Complex-wide device type definition
3490E
LDG3490E
3592-J1A
LDG359J
3592-E05
LDG359K
3592-E05 encryption-enabled
LDG359L
3592-E06 encryption-enabled
LDG359M
3592-E07 encryption-enabled
LDG359N
A library-specific device type name, which is an eight-character string, starts with a different prefix for each device type followed by the five-digit library identification number, as listed in Table C-2.
Table C-2 Library device groups - library-specific device types
Device type
Library-specific device type
Content
3490E
LDE + library number
All 3490E in lib xx
3592-J1A
LDJ + library number
All 3592 Model J1A in lib xx
3592-E05
LDK + library number
All 3592 Model E05 in lib xx
3592-E05
LDL + library number
3592 Model E05 encryption-enabled in lib xx
3592-E06
LDM + library number
3592 Model E06 encryption-enabled in lib xx
3592-E07
LDN + library number
3592 Model E07 encryption-enabled in lib xx
It also enables you to address a specific device type in a specific tape library. In a stand-alone grid, or in a multiple cluster TS7700 grid, the previous references to the five-digit library identification number is to the composite library.
To set up a TS3500 tape library in a JES3 environment, complete the following steps:
1. Define LDGs. Prepare the naming conventions in advance. Clarify all the names for the LDGs that you need.
2. Include the esoteric names from step 1 in the hardware configuration definition (HCD) and activate the new Esoteric Device Table (EDT).
3. Update the JES3 INISH deck:
a. Define all devices in the TS3500 tape library through DEVICE statements.
b. Set JES3 device names through the SETNAME statement.
c. Define which device names are subsets of other device names through the HWSNAME statement.
Updating the JES3 INISH deck
To enable JES3 to allocate the appropriate device, you must code several definitions:
DEVICE statements
SETNAME statements
HWSNAME (high-watermark setup) statements
These statements are described in detail.
DEVICE statement: Defining I/O devices for Tape Libraries
Use the DEVICE format to define a device so that JES3 can use it. A device statement (Figure C-1) must be defined for each string of tape library drives in the complex. XTYPE specifies a one-character to eight-character name, which is provided by the user.
There is no default or specific naming convention for this statement. This name is used in other JES3 init statements to group the devices together for certain JES3 processes (for example, allocation). Therefore, it is necessary that all the devices with the same XTYPE belong to the same library and the same device type.
The letters CA in the XTYPE definition indicate to you that this is a CARTRIDGE device, as shown in Figure C-1.
*/ Devices 3592-J1A, 3592-E05, 3592-E06, and 3592-E07 in Library 1 ............/* DEVICE,XTYPE=(LB13592J,CA),XUNIT=(1100,*ALL,,OFF),numdev=4 DEVICE,XTYPE=(LB13592K,CA),XUNIT=(1104,*ALL,,OFF),numdev=4
DEVICE,XTYPE=(LB13592M,CA),XUNIT=(0200,*ALL,,OFF),numdev=4
DEVICE,XTYPE=(LB13592N,CA),XUNIT=(0204,*ALL,,OFF),numdev=4
 
*/ Example for TS7700 ................................................../*
DEVICE,XTYPE=(LB3GRD1,CA),XUNIT=(3000,*ALL,,OFF),numdev=256
Figure C-1 DEVICE statement sample
Tape library drives cannot be used as support units by JES3 DSPs.
 
Exception: When Dump Job (DJ) is used with the SERVER=YES keyword. When this keyword is used, DJ uses MVS dynamic allocation to allocate the device, which uses XUNIT.
Therefore, do not specify DTYPE, JUNIT, and JNAME parameters on the DEVICE statements. No check is made during initialization to prevent tape library drives from definition as support units, and no check is made to prevent the drives from allocation to a DSP if they are defined. Any attempt to call a tape DSP by requesting a tape library fails because the DSP cannot allocate a tape library drive.
SETNAME statement
The SETNAME statement is used for proper allocation in a JES3 environment. For tape devices, it tells JES3 which tape device belongs to which library. The SETNAME statement specifies the relationships between the XTYPE values (coded in the DEVICE Statement) and the LDG names (Figure C-2). A SETNAME statement must be defined for each unique XTYPE in the device statements.
SETNAME,XTYPE=LB1359K,
NAMES=(LDGW3495,LDG
F4001,LDG359K,LDKF4001)
              Complex Library Complex Library
Wide      Specific Wide      Specific
Library Library Device Device
Name Name Name Name
Figure C-2 SETNAME rules
The SETNAME statement has the following rules:
Each SETNAME statement has one entry from each LDG category.
The complex-wide library name must be included in all statements.
A library-specific name must be included for XTYPEs within the referenced library.
The complex-wide device type name must be included for all XTYPEs of the corresponding device type in the complex.
A library-specific device type name must be included for the XTYPE associated with the devices within the library.
 
Tip: Do not specify esoteric and generic unit names, such as 3492, SYS3480R, and SYS348XR. Also, never use esoteric names, such as TAPE and CART.
High watermark setup names
Use the HWSNAME statement to define which device names are subsets of other device names. You must specify all applicable varieties. The HWSNAME command has this syntax:
HWSNAME,TYPE=(groupname,{altname})
The variables specify the following information:
The groupname variable: Specifies a device type valid for a high watermark setup.
The altname variable: Specifies a list of valid user-supplied or IBM-supplied device names. These are alternative units to be used in device selection.
Consider the following example:
HWSNAME,TYPE=(LDGW3495,LDGF4001,LDGF4006,LDG359J,LDG359K,LDG359M,LDG359N,LDJF4001,LDKF4001,LDKF4006)
The LDG HWSNAME statements have the following rules:
The complex-wide library name, LDGW3495, must include all other LDG names as alternates.
The library-specific name must include all LDG names for the corresponding library as alternates. When all tape devices of a type within the complex are within a single tape library, the complex-device type name must also be included as an alternative name.
The complex-wide device type name must include all library-specific device type names. When all devices of one type in the complex are within a single TS3500 tape library, the complex-wide device type name is equivalent to that library name. In this case, you need to also specify the library name as an alternative.
The library-specific device type name must be included. Alternative names can be specified in the following manner:
 – When all drives within the TS3500 tape library have the same device type, the library-specific device type name is equivalent to the library name. In this case, you need to specify the library-specific name as an alternative.
 – When these drives are the only drives of this type in the complex, the complex-wide device type name is equivalent to the library-specific device type name.
Ensure that all valid alternative names are specified.
Example with two separate tape libraries
The first example includes different native tape drives in two separate tape libraries. Figure C-3 shows a JES3 complex with two TS3500 tape libraries that are attached to it. Library 1 has a LIBRARY-ID of F4001 and a mix of 3592-J1A and 3592-E05 drives installed. Library 2 has a LIBRARY-ID of F4006 and only 3592-E05 models installed. In this example, the 3592-E05 drives are not encryption-enabled in either library.
Figure C-3 First JES3 configuration example
LDG definitions necessary for the first example
Table C-3 lists the LDG definitions that are needed in HCD. A total of eight esoterics must be defined.
Table C-3 LDG definitions for the first configuration example
LDG definition
Value of LDG
Explanation
Complex-wide name
LDGW3495
Standard name, appears once
Library-specific name
LDGF4001
LDGF4006
One definition for each library
Complex-wide device type

LDG359J
LDG359K
One definition for each installed device type:
Represents the 3592-J1A devices
Represents the 3592-E05 devices
Library-specific device type

LDJF4001
LDKF4001
LDKF4006
One definition for each device type in each library:
Represents the 3592-J1A in library F4001
Represents the 3592-E05 in library F4001
Represents the 3592-E05 in library F4006
Device statements that are needed for this configuration
These examples use a naming convention for XTYPE that contains the library (LB1, LB2) in the first three digits, and then the device type (see Figure C-4). A naming convention for XTYPE is not mandatory, but it makes it easier to use the JES3 INISH deck.
*/ Devices 3592-J1A and 3592-E05 in Library 1 ............................/*

DEVICE,XTYPE=(LB13592J,CA),XUNIT=(1000,*ALL,,OFF),numdev=4 DEVICE,XTYPE=(LB13592K,CA),XUNIT=(1104,*ALL,,OFF),numdev=4

*/ Devices 3592-E05 Encryption-Enabled in Library 2 ...................../*

DEVICE,XTYPE=(LB23592K,CA),XUNIT=(2000,*ALL,,OFF),numdev=8
Figure C-4 First configuration example - device-type definition sample
SETNAME statements that are needed for this configuration
Figure C-5 includes all of the SETNAME statements for the first configuration example.
SETNAME,XTYPE=(LB13592J,CA),NAMES=(LDGW3495,LDGF4001,LDG359J,LDJF4001)
SETNAME,XTYPE=(LB13592K,CA),NAMES=(LDGW3495,LDGF4001,LDG359K,LDKF4001)
SETNAME,XTYPE=(LB23592K,CA),NAMES=(LDGW3495,LDGF4006,LDG359K,LDKF4006)
Figure C-5 First configuration example - SETNAME definition sample
For this example, you need three SETNAME statements for the following reasons:
One library with two different device types = Two SETNAME statements
One library with one device type = One SETNAME statement
 
Tip: For definition purposes, encryption-enabled and non-encryption-enabled drives are considered two different device types. In the first example, all 3592 Tape Drives are not encryption-enabled.
HWSNAME statement that is needed for this configuration
The HWSNAME definition is tricky, so every statement that is shown in Figure C-6 is explained. If you are not experienced in JES3, read carefully through the explanation.
HWSNAME,TYPE=(LDGW3495,LDGF4001,LDGF4006,LDG359J,LDG359K,LDJF4001,LDKF4001,LDKF4006)1
HWSNAME,TYPE=(LDGF4001,LDJF4001,LDKF4001,LDG359J)2
HSWNAME,TYPE=(LDGF4006,LDKF4006)3
HWSNAME,TYPE=(LDJF4001,LDG359J)4
HWSNAME,TYPE=(LDG359J,LDJF4001)5
HWSNAME,TYPE=(LDG359K,LDKF4001,LDGF4006,LDKF4006)6
Figure C-6 HWSNAME definition sample
The following numbers correspond to the numbers that are shown in Figure C-6:
1. All LDG definitions are a subset of the complex-wide name.
2. LDG359J is a subset of library F4001 (LDGF4001) because the other library has only 3592-E05s installed.
3. All 3592-E05s in library F4006 (LDKF4006) are a subset of library F4006. LDG359K is not specified because there are also 3592-E05s that are installed in the other library.
4. All 3592-J1As (LDG359J) are a subset of the 3592-J1A in library F4001 because no other 3592-J1As are installed.
5. All 3592-J1As in library F4001 (LDJF4001) are a subset of 3592-J1A because no other 3592-J1As are installed.
6. All 3592-E05s in library F4001 (LDKF4001) are a subset of 3592-E05. LDGF4006 (the entire library with the ID F4006) is a subset of 3592-E05 because only 3592-E05s are installed in this library.
Example with three Tape Libraries
Figure C-7 on page 849 shows a JES3 configuration with three TS3500 Tape Libraries attached to it. Library 1 has a LIBRARY-ID of F4001, a mix of 3592-J1A and 3592-E05 drives that are not encryption-enabled, and one TS7700 of a multiple cluster TS7700 grid (distributed library) installed. The multiple-cluster TS7700 grid has a composite library LIBRARY-ID of 47110.
Library 2 has a LIBRARY-ID of F4006 and a mix of encryption-enabled and non-encryption-enabled 3592-E05 drives installed, which is also the reason why you might need to split a string of 3592-E05 drives. Library 2 is also the second distributed library for the multi-cluster grid with composite library LIBRARY-ID 47110.
Library 3 has a LIBRARY-ID of 22051 and only a TS7700 installed with a composite library LIBRARY-ID of 13001. There are no native tape drives in that library.
Figure C-7 does not show the actual configuration for the TS7700 configurations regarding the numbers of frames, controllers, and the back-end drives. Only the drives and frames that are needed for the host definitions are displayed.
Figure C-7 Second JES3 configuration example
LDG definitions that are needed for the second configuration example
Table C-4 lists the LDG definitions that are needed in the HCD of the second configuration example.
Table C-4 LDG definitions for the second configuration example
LDG definition
Value for LDG
Explanations
Complex-wide name
LDGW3495
Standard name, which appears once.
Library-specific name
LDGF4001
LDGF4006
LDG13001
LDG47110
One definition for each library and for each stand-alone cluster TS7700 grid. For a single cluster or multiple cluster TS7700 grid, only the composite library LIBRARY-ID is specified.
Complex-wide device type

LDG3490E

LDG359J
LDG359K
LDG359L
LDG359M
One definition for each installed device type:
Represents the 3490 devices in TS7700
Represents the 3592-J1A
Represents the 3592-E05
Represents the 3592-E05 with Encryption
Represents the 3592-E06
Library-specific device type


LDE13001
 
 
LDE47110
 
 
LDJF4001
 
LDKF4001
 
LDLF4006
LDMF4006
One definition for each device type in each library, except for the multi-cluster TS7700 grid:
Represents the virtual drives in the stand-alone cluster TS7700 grid in library 22051
Represents the virtual drives in the multicluster TS7700 grid in libraries F4001 and F4006
Represents the 3592-J1A in library F4001
Represents the 3592-E05 in library F4001
Represents the encryption-enabled 3592-E05 in library F4006
Represents the 3592-E06 in library F4006
Device statement needed
Figure C-8 lists the device statements for the second configuration example. The comment statements describe to which library the devices belong.
*/ Devices 3592-J1A and 3592-E05 in Library F4001 .............................../*

DEVICE,XTYPE=(LB13592J,CA),XUNIT=(1100,*ALL,,OFF),numdev=8 DEVICE,XTYPE=(LB13592K,CA),XUNIT=(1107,*ALL,,OFF),numdev=8,

*/ Devices 3592-E06 and 3592-E05 in Library F4006................................/*

DEVICE,XTYPE=(LB2359M,CA),XUNIT=(4000,*ALL,,OFF),numdev=8
DEVICE,XTYPE=(LB2359L,CA),XUNIT=(2000,*ALL,,OFF),numdev=8

*/ Devices Stand-alone Cluster TS7700 Grid in library 22051 ........................../*

DEVICE,XTYPE=(LB3GRD1,CA),XUNIT=(3000,*ALL,,OFF),numdev=256

*/ Devices Multi Cluster TS7700 grid in libraries F4001 and F4006................/*
ADDRSORT=NO

DEVICE,XTYPE=(LB12GRD,CA),XUNIT=(0110,*ALL,S3,OFF)
DEVICE,XTYPE=(LB12GRD,CA),XUNIT=(0120,*ALL,S3,OFF)
DEVICE,XTYPE=(LB12GRD,CA),XUNIT=(0130,*ALL,S3,OFF)
DEVICE,XTYPE=(LB12GRD,CA),XUNIT=(0140,*ALL,S3,OFF)
DEVICE,XTYPE=(LB12GRD,CA),XUNIT=(0111,*ALL,S3,OFF)
DEVICE,XTYPE=(LB12GRD,CA),XUNIT=(0121,*ALL,S3,OFF)
DEVICE,XTYPE=(LB12GRD,CA),XUNIT=(0131,*ALL,S3,OFF)
DEVICE,XTYPE=(LB12GRD,CA),XUNIT=(0141,*ALL,S3,OFF)
;;;;;;;
DEVICE,XTYPE=(LB12GRD,CA),XUNIT=(01FF,*ALL,S3,OFF)
Figure C-8 DEVICE statements for the second configuration example
 
 
Consideration: If you code NUMDEV in a peer-to-peer (PTP) IBM Virtual Tape Server (VTS) environment, the workload balancing from the CX1 controllers does not work. Therefore, you must specify each device as a single statement, and specify ADDRSORT=NO to prevent JES3 from sorting them.
The same restriction applies to the virtual devices of the clusters of a multi-cluster grid configuration. If you want to balance the workload across the virtual devices of all clusters, do not code the NUMDEV parameter.
SETNAME statements needed
Figure C-9 shows all of the necessary SETNAME statements for the second configuration example.
SETNAME,XTYPE=LB1359J,NAMES=(LDGW3495,LDGF4001,LDG359J,LDJF4001)
SETNAME,XTYPE=LB1359K,NAMES=(LDGW3495,LDGF4001,LDG359K,LDKF4001)
SETNAME,XTYPE=LB2359L,NAMES=(LDGW3495,LDGF4006,LDG359L,LDKF4006)
SETNAME,XTYPE=LB2359M,NAMES=(LDGW3495,LDGF4006,LDG359M,LDMF4006)
SETNAME,XTYPE=LB3GRD1,NAMES=(LDGW3495,LDG13001,,LDG3490E,,LDE13001)
SETNAME,XTYPE=LB12GRD,NAMES=(LDGW3495,LDG47110,LDG3490E,LDE47110)
Figure C-9 SETNAME statement values for the second example
High-watermark setup name statements
Figure C-10 shows the HWSNAME statements for the second configuration example.
HWSNAME,TYPE=(LDGW3495,LDGF4001,LDGF4006,LDG13001,LDG47110,LDG3490E,
              LDG359J,LDG359K,LDG359L,LDG359M,LDE13001,LDE47110,LDJF4001,
              LDKF4001,LDLF4006,LDMF4006)
HWSNAME,TYPE=(LDGF4001,LDJF4001,LDKF4001)
HWSNAME,TYPE=(LDGF4006,LDLF4006,LDMF4006)
HWSNAME,TYPE=(LDG47110,LDE47110)
HWSNAME,TYPE=(LDG13001,LDE13001)
HWSNAME,TYPE=(LDG3490E,LDE47110,LDE13001)
HWSNAME,TYPE=(LDG359J,LDJF4001)
HWSNAME,TYPE=(LDG359K,LDKF4001)
HWSNAME,TYPE=(LDG359L,LDLF4006)
HWSNAME,TYPE=(LDG359M,LDMF4006)
Figure C-10 High watermark setup statements for the second example
Additional examples
For more examples, see IBM TotalStorage Virtual Tape Server: Planning, Implementing, and Monitoring, SG24-2229.
Processing changes
Although no JCL changes are required, a few processing restrictions and limitations are associated with using the TS3500 tape library in a JES3 environment:
JES3 spool access facility (SPAF) calls are not used.
Two calls, one from the prescan phase and the other call from the locate processing phase, are made to the new DFSMS support module, as shown in Figure C-11 on page 853.
The main device scheduler (MDS) processing phases, system select, and system verify are not made for tape data sets.
The MDS verify phase is bypassed for TS3500 tape library mounts, and mount processing is deferred until job execution.
Figure C-11 on page 853 shows the JES3 processing phases for CI and MDS. The processing phases include the support for system-managed direct access storage device (DASD) data sets.
The following important differences exist between TS3500 tape library deferred mounting and tape mounts for non-library drives:
Mounts for non-library drives by JES3 are only for the first use of a drive. Mounts for the same unit are sent by IBM z/OS for the job. All mounts for TS3500 tape library drives are sent by z/OS.
If all mounts within a job are deferred because there are no non-library tape mounts, that job is not included in the setup depth parameter (SDEPTH).
MDS mount messages are suppressed for the TS3500 tape library.
Figure C-11 JES3 CI and MDS processing phases
JES3/DFSMS processing
DFSMS is called by the z/OS interpreter to perform these functions:
Update the scheduler work area (SWA) for DFSMS tape requests.
Call ACS exits for construct defaults.
DFSMS system-managed tape devices are not selected by using the UNIT parameter in the JCL. For each data definition (DD) request requiring a TS3500 tape library unit, a list of device pool names is passed, and from that list, an LDG name is assigned to the DD request. This results in an LDG name passed to JES3 MDS for that request. Device pool names are never known externally.
Selecting UNITNAMEs
For a DD request, the LDG selection is based on the following conditions:
When all devices in the complex are eligible to satisfy the request, the complex-wide LDGW3495 name is used.
When the list of names contains names of all devices of one device type in the complex, the corresponding complex-device type name (for example, LDG3490E) must be used.
When the list of names contains all subsystems in one TS3500 tape library, the library-specific LDG name (in the examples, LDGF4001, LDGF4006, and so on) is used.
When the list contains only subsystems for a specific device type within one TS3500 tape library, the LDG device type library name (in the example, LDKF4001, and so on) is used.
New or modified data sets
For new data sets, ACS directs the allocation by providing Storage Group (SG), SC, and Data Class (DC). When the SG specified by ACS is defined in the active DFSMS configuration as a tape SG, the request is allocated to a TS3500 tape library tape drive.
DFSMS managed DISP=MOD data sets are assumed to be new update locate processing. If a catalog locate determines that the data set is old by the VOLSER specified, a new LDG name is determined based on the rules for old data sets.
Old data sets
Old data set allocations are directed to a specific TS3500 tape library when the volumes containing the data set are within that TS3500 tape library. For old data sets, the list is restricted to the TS3500 tape library that contains the volumes.
DFSMS catalog processing
JES3 catalog processing determines all of the catalogs that are required by a job and divides them into two categories:
DFSMS managed user catalogs
JES3-managed user catalogs
DFSMS catalog services, a subsystem interface call to catalog locate processing, is used for normal locate requests. DFSMS catalog services are started during locate processing. It starts supervisor call (SVC) 26 for all existing data sets when DFSMS is active.
Locates are required for all existing data sets to determine whether they are DFSMS managed, even if VOL=SER= is present in the DD statement. If the request is for an old data set, catalog services determine whether it is for a library volume. For multivolume requests that are system-managed, a check is made to determine whether all volumes are in the same library.
DFSMS VOLREF processing
DFSMS VOLREF services are started during locate processing if VOL=REF= is present in a DD statement for each data set that contains a volume reference to a cataloged data set. DFSMS VOLREF services determine whether the data set referenced by a VOL=REF= parameter is DFSMS managed. VOL=REF= now maps to the same SG for a DFSMS managed data set, but not necessarily to the same volume. DFSMS VOLREF services also collect information about the job’s resource requirements.
The TS3500 tape library supports the following features:
Identifies the DDs that are TS3500 tape library-managed mountable entries
Obtains the associated device pool names list
Selects the LDG that best matches the names list
Provides the LDG name to JES3 for setup
Indicates to JES3 that the mount is deferred until execution
Fetch messages
When tape library volumes are mounted and unmounted by the library, fetch messages to an operator are unnecessary and can be confusing. With this support, all fetch messages (IAT5110) for TS3500 tape library requests are changed to be the non-action informational USES form of the message. These messages are routed to the same console destination as other USES fetch messages. The routing of the message is based on the UNITNAME.
JES3 allocation and mounting
JES3 MDS controls the fetching, allocation, and mounting of the tape volumes that are requested in the JCL for each job to be run on a processor. The scope of MDS tape device support is complex-wide, unlike z/OS job resource allocation, whose scope is limited to one processor.
Another difference between JES3 MDS allocation and z/OS allocation is that MDS considers the resource requirements for all the steps in a job for all processors in a loosely coupled complex. z/OS allocation considers job resource requirements one step at a time in the running processor.
MDS processing also determines which processors are eligible to run a job based on resource availability and connectivity in the complex.
z/OS allocation interfaces with JES3 MDS during step allocation and dynamic allocation to get the JES3 device allocation information and to inform MDS of resource deallocations. z/OS allocation is enhanced by reducing the allocation path for mountable volumes.
JES3 supplies the device address for the tape library allocation request through a subsystem interface (SSI) request to JES3 during step initiation when the job is running under the initiator. This support is not changed from previous releases.
DFSMS and z/OS provide all of the tape library support except for the interfaces to JES3 for MDS allocation and processor selection.
JES3 MDS continues to select tape units for the tape library. MDS no longer uses the UNIT parameter for allocation of tape requests for tape library requests. DFSMS determines the appropriate LDG name for the JES3 setup from the SG and DC assigned to the data set, and replaces the UNITNAME from the JCL with that LDG name. Because this action is after the ACS routine, the JCL-specified UNITNAME is available to the ACS routine.
This capability is used to disallow JCL-specified LDG names. If LDG names are permitted in the JCL, the associated data sets must be in a DFSMS tape environment. Otherwise, the allocation fails because an LDG name restricts allocation to TS3500 tape library drives that can be used only for system-managed volumes.
 
Consideration: An LDG name that is specified as a UNITNAME in JCL can be used only to filter requests within the ACS routine. Because DFSMS replaces the externally specified UNITNAME, it cannot be used to direct allocation to a specific library or library device type unless SMSHONOR is specified on the unit parameter. For a description of SMSHONOR and changes that are needed for JES3 see z/OS JES3 Initialization and Tuning Guide, SA32-1003, and z/OS MVS JCL Reference, SA32-1005.
All components within z/OS and DFSMS request tape mounting and unmounting inside a tape library. They call a Data Facility Product (DFP) service, Library Automation Communication Services (LACS), rather than sending a write to operator (WTO), which is done by z/OS allocation, so all mounts are deferred until job run time. The LACS support is called at that time.
MDS allocates an available drive from the available unit addresses for LDGW3495. It passes that device address to z/OS allocation through the JES3 allocation SSI. At data set OPEN time, LACS is used to mount and verify a scratch tape. When the job finishes with the tape, either CLOSE or deallocation issues an unmount request through LACS, which removes the tape from the drive. MDS does normal breakdown processing and does not need to communicate with the tape library.
Multi-cluster grid considerations
In a multi-cluster grid configuration, careful planning of the Copy Consistency Points and the Copy Override settings can help avoid unnecessary copies in the grid and unnecessary traffic on the grid links.
Consider the following aspects, especially if you are using a multi-cluster grid with more than two clusters and not all clusters contain copies of all logical volumes:
Retain Copy mode setting
If you do not copy logical volumes to all of the clusters in the grid, JES3 might, for a specific mount, select a drive that does not have a copy of the logical volume. If Retain Copy mode is not enabled on the mounting cluster, an unnecessary copy might be forced according to the Copy Consistency Points that are defined for this cluster in the Management Class (MC).
Copy Consistency Point
Copy Consistency Point has one of the largest influences on which cluster’s cache is used for a mount. The Copy Consistency Point of Rewind Unload (R) takes precedence over a Copy Consistency Point of Deferred (D). For example, assuming that each cluster has a consistent copy of the data, if a virtual device on Cluster 0 is selected for a mount and the Copy Consistency Point is [R,D], the CL0 cache is selected for the mount. However, if the Copy Consistency Point is [D,R], CL1’s cache is selected.
For workload balancing, consider specifying [D,D] rather than [R,D]. This more evenly distributes the workload to both clusters in the grid.
If the Copy Consistency Points for a cluster are [D,D], other factors are used to determine which cluster’s cache to use. The Prefer local cache for fast ready mount requests and Prefer local cache for non-fast ready mounts overrides cause the cluster that received the mount request to be the cache that is used to access the volume.
Cluster families
If there are more than two clusters in the grid, consider defining cluster families. Especially in multisite configurations with larger distances between the sites, defining one cluster family per site can help reduce the grid link traffic between both sites.
Copy Override settings
All Copy Override settings, such as Prefer local cache for fast ready mount requests and Prefer local cache for non-fast ready mounts, always apply to the entire cluster, where the Copy Consistency Points defined in the MC can be different and tailored according to workload requirements.
You can find detailed information about these settings and other workload considerations in Chapter 6, “IBM TS7700 implementation” on page 227 and Chapter 11, “Performance and monitoring” on page 623.
Scratch allocation assistance and device allocation assistance
Unlike the system-managed tape support in the JES2 environment, the JES3 support relies on customer INISH deck setup and special tape-library-related esoteric names: complex-wide name library-specific name, library-specific device name, complex-wide device name, and a new library-specific distributed name for use with the allocation assist support. By default the allocation assist support is disabled in the JES3 environment. The following sections outline what is needed to use the device allocation assist support in a JES3 environment.
The first set of steps is common for device allocation assistance (specific mounts) and scratch allocation assistance (scratch mounts). Device allocation assistance can be used independent of the scratch allocation assistance support and vice versa:
complex-wide name Always LDGW3495. Indicates every device and device type in every library.
library-specific name
An eight character string that is composed of LDG prefixing the five-digit library identification number. Indicates every device and device type in that specific library (for example, LDG12345). In a TS7700, the library-specific name refers to the composite library.
library-specific device name
An eight character string that is composed of LDx prefixing the five-digit library identification number. Indicates every device with device type x in that specific library (for example, LDE12345, where “E” represents all 3490E devices in library 12345). In a TS7700, the library-specific device name refers to the composite library.
complex-wide device name
Contains a prefix of LDG and a device identifier that represents all devices of a particular system and model type in every tape library (for example, LDG3490E for 3490E devices).
library-specific distributed name
An eight character string that is composed of LDX prefixing the five-digit library identification number of the distributed library (or cluster) in a TS7700. Only for use with the TS7700, and only if the device allocation assist functions (DAA, SAA, or both) will be used by JES3.
The library-specific distributed name is used in addition to the previously listed esoteric names that are still needed. Define the LDXxxxxx names only for distributed libraries (or clusters) that have devices that are connected to the host.
Specific allocation assistance enablement considerations
These installation steps must be followed to prevent job failures from occurring:
1. Ensure that all systems in the JES3plex are at z/OS V2R1 (this is needed because pre-execution and job execution can occur on different systems in the JES3plex). However, JES3 itself can be at a lower release level.
2. Make JES3 INISH deck changes as described in the following INISH deck example. The INISH deck changes define the library-specific distributed names that are associated with the distributed libraries clusters in a TS7700. All TS7700 tape drives that are used by JES3 (with devices that are connected to the host) should have the new esoteric names that are defined, regardless of whether the TS7700 is part of a single or a multi-cluster grid.
3. Roll out the JES3 INISH deck changes to all systems in the JES3plex (this roll-out can occur one system at a time). The new esoteric names are not passed to JES3 until the support is enabled through DEVSUPxx.
4. By default, the device allocation assist function is enabled at the library for all specific allocations. However, this support can be disabled either by a tape hardware specialist (PFE) dialing into the library or through the MVS LIBRARY REQUEST command. Verify that the DAA function is enabled at the library by using the following command:
LIBRARY REQUEST,composite-libraryname,SETTING
5. Lastly, enable the support to the host through the DEVSUPxx PARMLIB member by using the JES3_ALLOC_ASSIST=YES keyword (either at IPL or through the SET DEVSUP=xx operator command). The SET DEVSUP=xx operator command can be used to enable this support by routing the command to all systems in the JES3plex. After this support is enabled, the new library-specific distributed names can be returned to JES3. Ensure that steps 2 and 3 are completed before enabling this support.
Otherwise, job failures can occur if JES3 does not understand the new esoteric names being passed (because they were not defined in the JES3 INISH deck). If one of the systems in the JES3plex lags behind (in enablement of this support), all that might occur is that the device allocation assist preferred cluster list might not be acknowledged. JES3 and MVS allocation still see the same list of eligible devices.
Scratch allocation assistance enablement considerations
Complete the following installation steps to prevent job failures from occurring:
1. Ensure that all systems in the JES3plex are at z/OS V2R2 (this is needed because pre-execution and job execution can occur on different systems in the JES3plex). However, JES3 itself can be at a lower release level.
2. Make JES3 INISH deck changes as described in INISH deck example. The INISH deck changes define the library-specific distributed names that are associated with the distributed libraries clusters in a TS7700. All TS7700 tape drives used by JES3 (with devices connected to the host) should have the new esoteric names that are defined, regardless of whether the TS7700 is part of a single or a multi-cluster grid.
3. Roll out the JES3 INISH deck changes to all systems in the JES3plex (this roll-out can occur one system at a time). The new esoteric names are not passed to JES3 until the support is enabled through DEVSUPxx.
4. Enable the support to the host through the DEVSUPxx PARMLIB member by using the JES3_ALLOC_ASSIST=YES keyword (either at IPL or through the SET DEVSUP=xx operator command). The SET DEVSUP=xx operator command can be used to enable this support by routing the command to all systems in the JES3plex. After this support is enabled, the new library-specific distributed names can be returned to JES3.
Ensure that steps 2 and 3 are completed before enabling this support. Otherwise, job failures can occur if JES3 does not understand the new esoteric names being passed (because they were not defined in the JES3 INISH deck).
5. Then, unlike the specific allocation assistance support, the scratch allocation assistance support must be explicitly enabled at the library through the
LIBRARY REQUEST,composite-libraryname,SETTING,DEVALLOC,SCRATCH,ENABLE command (disabled by default), and then policies must be set up at the library (on an MC basis) to request the support for a specific scratch allocation.
Before assigning an MC policy that uses the scratch allocation assistance support (specifies candidate clusters), ensure that step 4 is completed first. This helps ensure that the list of eligible devices that JES3 gets back matches the list of devices that MVS allocation got back during job run time. Even though MVS allocation has retry logic to try to circumvent ABEND05C-309, that retry logic is not guaranteed to succeed.
INISH deck example
Here is an example of an INISH deck for a TS7700 multi-cluster grid that has devices online in two clusters (other clusters whose devices are not connected to the host might exist for replication purposes). In this example, the composite library has library identification number X'12345' and the first distributed library in the grid has library identification number X'10001' and the second distributed library in the grid has library identification number X'10002'.
In this example, each distributed library in the grid has 256 devices for a total of 512. The changes that must be made to the INISH deck to use the optional allocation assist support in JES3 are shown in bold italic text. The INISH deck changes are needed only if the allocation assist functions are to be enabled by specifying JES3_ALLOC_ASSIST=YES in the DEVSUPxx PARMLIB member.
Before you enable the allocation assist functions, ensure that all TS7700 tape drives in the INISH deck are defined with the necessary LDXxxxxx names, even if the TS7700 is a stand-alone configuration consisting of one distributed library. In this example, rather than the device statement representing the composite library (as a whole), the device statements are defined at the distributed (or cluster) level and LDXxxxxx names are added (as needed) for each distributed library in a TS7700 that has devices that are connected to the JES3 host.
Device statements
Replace DEVICE,XTYPE=(CLB12345,CA),XUNIT=(1100,*ALL,,OFF),NUMDEV=512 with the following statements:
DEVICE,XTYPE=(DLB10001,CA),XUNIT=(1100,*ALL,,OFF),NUMDEV=256 DEVICE,XTYPE=(DLB10002,CA),XUNIT=(1200,*ALL,,OFF),NUMDEV=256
These device statements are suggested examples that can be used. However, depending on the contiguous device ranges that are available, more than one device statement can be used to represent all of the devices in a composite library. Also, more than one device statement might be needed to represent the devices in a distributed library (and a device can occur in only one device statement). For example, if there are not 256 contiguous device addresses that start with 1100, the devices might be split as follows:
DEVICE,XTYPE=(DLB10001,CA),XUNIT=(1000,*ALL,,OFF),NUMDEV=128 DEVICE,XTYPE=(DLB10001,CA),XUNIT=(1100,*ALL,,OFF),NUMDEV=128
Also, one of the factors that are used by JES3 in selecting devices for volume mounting is the ADDRSORT parameter on the SETPARAM initialization statement. This parameter specifies that devices are either allocated in the same order as the DEVICE statement defining them (ADDRSORT=NO) or allocated by the order of their device numbers in ascending order (ADDRSORT=YES, which is the default).
In a multi-cluster grid environment today, customers might have used ADDRSORT=NO to distribute their work load across multiple clusters in the grid by defining each device individually and alternating devices across the clusters. With the allocation assist support enabled, because the goal is to direct allocation requests to specific distributed libraries clusters in the grid, ADDRSORT=NO is no longer needed. Within a distributed library (or cluster), it doesn’t matter which device is used and the main purpose of the allocation assist support is to direct the allocation request to appropriate distributed libraries.
SETNAME statements
The following list illustrates the SETNAME statements:
For the 3490E devices in composite library 12345, distributed library (10001):
SETNAME,XTYPE=DLB10001,NAMES=(LDGW3495,LDG12345,LDG3490E,LDE12345,LDX10001)
For the 3490E devices in composite library 12345, distributed library (10002):
SETNAME,XTYPE=DLB10002,NAMES=(LDGW3495,LDG12345,LDG3490E,LDE12345,LDX10002)
High-watermark statements
The following list illustrates the HWSNAME statements:
HWSNAME,TYPE=(LDGW3495,LDG12345,LDG3490E,LDE12345,LDX10001,LDX10002) HWSNAME,TYPE=(LDG12345,LDE12345,LDG3490E,LDX10001,LDX10002) HWSNAME,TYPE=(LDE12345,LDG12345,LDG3490E,LDX10001,LDX10002) HWSNAME,TYPE=(LDG3490E,LDE12345,LDG12345,LDX10001,LDX10002) HWSNAME,TYPE=(LDX10001)
HWSNAME,TYPE=(LDX10002)
 
Note: The DLB10001 and DLB10002 device statement names are used here for illustration purposes. When defining the device statement names, any name (up to 8 characters) can be used.
 
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.226.180.68