A primary function of the SMC is to influence the operating system selection of tape drives during allocation to ensure that acceptable devices are selected in a StorageTek TapePlex and virtual environment. In addition, the SMC creates a preferred list of acceptable devices based on specific volume location, scratch load balancing, and user policies. Although the mechanism by which allocation is influenced differs between JES2 (or JES3 without SETUP) and JES3 with tape setup, the logic that selects the acceptable and preferred devices is the same for all systems.
Generally, SMC allocation cannot add devices to the original list created from the job's JCL. It can only eliminate unacceptable devices and preference the remaining acceptable devices. However, by using the SMC IDAX interface (see "SMC Esoteric Substitution at IDAX") or the SMC DFSMS interface (see "SMC DFSMS Processing"), you can replace the original esoteric in the JCL with any other esoteric, which may have different devices or device types.
The SMC determines the list of drives acceptable for each tape allocation by applying a series of criteria (known as "exclusion levels") to the initial set of devices, removing those drives that do not meet the criteria. This process is known as drive exclusion.
If the SMC attempts to apply a particular exclusion criterion and therefore, all remaining eligible drives are excluded, messages SMC0045 and SMC0046 are displayed indicating that a particular exclusion criterion could not be applied. However, the exclusion process continues, with the SMC applying subsequent criteria if possible.
SMC allocation may intentionally cause a job to fail allocation when it appears that a mount to any of the drives in the available list would fail. For example, a volume with a media STK1R cannot be physically mounted on a 9490 drive, and a nonlabeled tape cannot be virtual.
Additionally, some customers may prefer to fail a job in allocation rather than use undesired scratch media or require a specific volume to be ejected and entered into a different ACS. You can use the SMC ALLOCDEF (or ALLOCJOB) MINLVL parameter to fail jobs in allocation, or conversely, to override the SMC default behavior of failing jobs in allocation.
Setting MINLVL=0 specifies that the SMC should never fail a job in allocation.
The default MINLVL, 2, indicates that jobs should be failed in allocation only for incompatible media or virtual label type.
Customers may set MINLVL to higher values if desired. See "Drive Exclusion" for detailed information about SMC exclusion levels for specific and scratch volumes.
After all exclusion criteria have been applied, the remaining drives are arranged in order of their desirability based on policy, volume location or scratch count, and last mount time. This process is known as drive prioritization. During this process, the SMC also sets flags in MVS control blocks to indicate that the mount should be deferred until OPEN, unless a policy specifies that mounts should not be deferred.
Note:
SMC allocation does not consider the status of the drives (for example offline, busy) when selecting drives eligible for an allocation request. If all SMC-selected drives are unavailable, the job enters allocation recovery.The drive exclusion process includes the following steps:
The SMC examines the initial list of eligible devices for each tape DD in each jobstep (or dynamic allocation), and gathers policy information from various sources, including DFSMS ACS routines, a combination of SMC POLicy commands and TAPEREQ control statements, and user exits.
The SMC uses policy information to select the ”owning TapePlex” for each tape allocation. If a POLICY specifies a TapePlex name, or specifies an esoteric that contains devices controlled by a single TapePlex, then that TapePlex is selected as the owner for allocation.
When multiple TapePlexes are eligible for ownership of the application, the first TapePlex that returns a successful status is selected as the owner. For a specific volume request, a successful response indicates that the volume is in the library or is defined as a virtual volume. For a scratch request, a successful response indicates that the TapePlex has available scratch volumes for the requested media and scratch subpool.
The SMC performs "volume lookup" by communicating with one or more TapePlexes, and gathering information about specific volume characteristics and location, in addition to available scratch volumes. If the SMC cannot obtain this information from a TapePlex, the ALLOCDef FAILnoinfo parameter may be used to control whether the job is allowed to fail in allocation or to proceed based only on available policies.
The SMC applies the information received from volume lookup and policies using an ordered set of levels, with the earliest (lowest numbered) levels applied first and least important levels applied later. For example, level 2 is considered more important, and is applied before level 3.
Whenever application of a particular exclusion would eliminate all drives, the SMC ignores the criterion and continues with the next exclusion level.
Note:
See Chapter 4, "Policy" for a description of SMC Policy specification.
Refer to the ELS Legacy Interfaces Reference for more information about user exits.
For a specific volume allocation, the SMC excludes drives in order from lowest exclusion level to highest, based on the criteria in the following table. The lower the level number, the more important the exclusion criteria.
Keywords associated with each exclusion level are specified in the exclusion criteria displayed in messages SMC0043 and SMC0046.
Table 5-1 Drive Exclusion Levels (Specific Request)
| Level | Specific Volume Criteria | Keyword |
|---|---|---|
|
MultipleTapePlexPre-Req 1 |
Exclude drives not in requested TapePlex Primary source: Secondary source: Specific volume user exit (08/13) TAPEPLEX |
None |
|
MultipleTapePlexPre-Req 2 |
Exclude drives based on ESOTERIC when the esoteric only includes devices in one TAPEPLEX. Primary source: Secondary source: Specific volume user exit (08/13) ESOTERIC |
None |
|
MultipleTapePlexPre-Req 3 |
Exclude drives based on unsuccessful volume lookup. Only drives in the first TapePlex that has a successful volume lookup remain eligible. If no TapePlex has a successful volume lookup, then the first defined TapePlex is used. |
None |
|
1 |
For non-labeled (NL) specific volume requests, exclude all virtual drives.Exclude all Primary source: external volume label Secondary source: The volume media can be obtained from the volume label or from an HSC |
VIRTUALLABEL MEDRECTECH |
|
2 |
For virtual volumes only, exclude virtual drives that reside in an inaccessible VTSS or in a VTSS to which a migrated virtual volume cannot be recalled. This is the default minimum level. |
AVAILVTSS |
|
3 |
Exclude drives based on the required recording technique. Source: |
VOLATTRRECTECH |
|
4 |
Exclude drives based on user location policies. Primary source: Secondary source: Specific volume user exit (08/13) or affinity separation exit (10/12) return codes. |
USERPOLICY |
|
5 |
Exclude drives based on the SMC |
EXTVOLESOT |
|
6 |
Exclude drives based on volume location type (that is, library or nonlibrary). |
LOCTYPE |
|
7 |
Exclude drives based on the ACS location of the volume (for library volumes), and the resident VTSS for virtual volumes. |
ACSORVTSS |
|
8 |
Exclude drives based on the requested recording technique. Primary source: DFSMS data class recording technique. Secondary source: |
POLRECTECH |
The following example illustrates how the SMC applies exclusion levels to influence the allocation of specific volumes.
JCL:
//DDNAME DD DSN=ABC.DEF,DISP=OLD
Policy specification:
POLICY NAME(POL1) VOLTYPE(SPECIFIC) ESOTERIC(A19840B,A19840A) RECTECH(STK1RB) TAPEREQ DSN(ABC.*) POLICY(POL1)
Volume lookup information:
Specific volume VOL123
SMC volume lookup indicates that VOL123 has a media type of STK1R single density in TapePlex HSCLIB ACS 0.
Allocation Exclusion Processing:
Starting at exclusion level 1, the SMC excludes all non-9840 devices (those not compatible with the volume media).
Level 2 has no effect.
The SMC does not exclude any devices at level 3 since there was no HSC VOLATTR to limit the volume to single density drives.
The SMC excludes all drives not in the esoteric A19840B or A19840A.
The SMC does not exclude any devices at level 5 because the volume is in the TapePlex.
The SMC excludes all nonlibrary drives, if any remain.
The SMC attempts to exclude all drives not in ACS 0. However, since the remaining devices at this point include only 9840 drives in ACS1 (based on the esoterics A19840B and A19840A), there are no drives remaining in the EDL after this exclusion.
The SMC then "backs up" to the EDL as it was before the level 7 exclusion and issues messages SMC0045 or SMC0046 specifying ACSORVTSS as the conflicting criterion.
Only drives in esoterics A19840B and A19840A remain eligible, based on exclusion level 4.
Level 8 has no effect.
Allocation preference processing:
During drive prioritization, SMC assigns a higher preference value to drives in esoteric A19840B, and a lower preference value to drives in A19840A.
For a scratch volume allocation, the SMC excludes drives in order from lowest exclusion level to highest based on the criteria in Table 3. The lower the level number, the more important the exclusion criteria.
Keywords associated with each exclusion level are specified in the exclusion criteria displayed in messages SMC0043 and SMC0046.
Table 5-2 Drive Exclusion Levels (Scratch Request)
The following example illustrates how the SMC applies the exclusion levels to influence the allocation of scratch volumes.
JCL:
//DDNAME DD DSN=DEF.GHI,DISP=NEW
Policy specification:
POLICY NAME(POL2) VOLTYPE(SCRATCH) SUBPOOL(SP1) MEDIA(ECART) MODEL(9490) TAPEREQ DSN(DEF.*) POLICY(POL2) SMC ALLOCDEF ZEROSCR(ON)
Scratch user exit returns use SUBPOOL(SP2) and ESOTERIC(XYZ).
Volume lookup information:
SMC volume lookup reports that TapePlex HSCLIB has scratch volumes in subpool SP1.
Allocation exclusion processing:
Starting at exclusion level 1, the SMC excludes drives which have an SMC UNITATTR command specifying MODEL=IGNORE.
Level 2 has no effect.
The SMC excludes all devices that do not support a media ECART.
Because POLicy is specified, the user exit esoteric XYZ is ignored, and level 4 has no effect. Message SMC0197 is issued to indicate this.
The SMC excludes all drives not compatible with the scratch volumes in subpool SP1 (TAPEREQ policy overrides user exit policy).
The SMC excludes all nonlibrary drives.
If scratch volumes for SP1 exist only in a single ACS, the SMC excludes drives in other ACSs.
The SMC excludes all remaining drives that do not have a MODEL of 9490.
The following example illustrates how the SMC applies the exclusion levels to influence the allocation of virtual scratch volumes.
JCL:
//DDNAME DD DSN=GHI.JKL,DISP=NEW
Policy specification:
POLICY NAME(POL3) VOLTYPE(SCRATCH) ESOTERIC(VTSS1) SUBPOOL(VIRT1) MGMTCLAS(MGMT1) TAPEREQ DSN(GHI.*) POLICY(POL3) SMC ALLOCDEF SMS(ON) SMC SMSDEF MGMTPOL(ALL) VTVMGMT(ON)
The DFSMS routine returns Management Class MGMT2.
As MGMT2 is not a valid policy name, it is ignored and the policy from TAPEREQ POL3 is used.
Volume lookup information:
SMC volume lookup returns a list of VTSSs eligible for scratch allocation. In this example the list returned is VTSS2 and VTSS3 based on online VTSSs with access to ACSs and RTD recording techniques compatible with MGMT1.
Allocation exclusion processing:
Starting at exclusion level 1, the SMC excludes drives which have an SMC UNITATTR command specifying MODEL=IGNORE.
The SMC excludes all virtual drives not in either VTSS2 or VTSS3.
The SMC excludes all non-virtual drives because the POLICY esoteric VTSS1 contains only virtual drives.
The SMC excludes all drives not in VTSS1.
Since VTSS1 is not one of those returned by HSC/VTCS, the SMC "backs out" the level 4 exclusion and issues messages SMC0045 or SMC0046, but continues other processing. Only drives in VTSS2 and VTSS3 remain eligible, based on exclusion level 2.
In this example, the remaining exclusion levels have no effect.
Explicit unit affinity is an MVS facility that allows volumes associated with two separate JCL DD statements, or allocation requests, to be mounted serially on the same drive. A request for all generations of a GDG group (GDG ALL chain) can be considered as a GDGALL affinity.
The SMC makes no distinction between these two types of affinity. When processing an affinity chain, the drive exclusion process examines each allocation in the chain separately up to and including the minimum exclusion level. The chain is always separated when the minimum exclusion level processing results in lists of eligible drives, for two or more members of the chain, that do not contain common drives.
For example:
//DD1 DD UNIT=CART,DSN=MY.STK1R.DATASET,DISP=OLD //DD2 DD UNIT=AFF=DD1,DSN=MY.LONGI.DATASET,DISP=OLD
DD1 specifies a data set on 9840 or T9840B media and DD2 specifies a data set on longitudinal media. Drive exclusion level 1 for specific volumes creates a list of eligible drives for each DD according to volume media required. The two lists do not contain a common drive. As a result, the SMC breaks the affinity chain between DD1 and DD2, and the two DD statements no longer represent one drive allocation but two separate allocation requests.
For SMC affinity chain processing, the head of the affinity chain containing only scratch or only specific volumes is the first DD statement in the chain. If an affinity chain contains both scratch and specific volumes, the first specific volume is treated as the head of chain.
After the minimum level of drive exclusion and affinity separation completes, user policy influences the remaining affinity separation decisions.
You can use the ALLOCDef or ALLOCJob SEPLvl parameter to specify that affinity chains not be separated based on the exclusion levels described in this chapter. You can also use user exits 10 and 12 to control affinity separation. Refer to the ELS Legacy Interfaces Reference for more information.
SMC drive priority is assigned based on the following criteria:
For specific volumes, drives in LSMs closest to the volume are preferred. The SMC sets equal priority value for drives that are located the same number of passthrus away from the specific volume.
For scratch volumes, drives in LSMs with the largest number of scratch volumes matching the policy-requested media and recording technique are preferred.
The POLicy ESOTeric list causes drives to be preferred according to the order specified in the esoteric list.
The POLicy PREFer parameter indicates the relative priority of LSM location (location for specific volumes), the esoteric list (esoteric for both scratch and specific volumes) and scratch count (count for scratch volumes) in determining the preference value of each device.
Note:
Refer to the ELS Legacy Interfaces Reference for other prioritization factors.After a final list of drives has been selected for allocation, the preference order of the eligible drives (after considering LSM and drive type preferencing) is selected based on a "last use" algorithm.
To reduce excessive wear on allocated drives, the SMC assigns drive preference values by rotation based on the "last mount time" for each drive. This value is examined for every drive in the final drive list. The drive that had the most recent mount is located, and the drive immediately following it in the list is selected as the most preferred for the current allocation.
Note:
This algorithm does not apply to virtual drives.By default, the SMC defers all automated tape mounts. The SMC ALLOCDef command DEFER parameter can be set to override this default. For optimal performance, it is recommended that you use the default DEFER(ON). Refer to the ELS Command, Control Statement, and Utility Reference for more information about the SMC ALLOCDef command.
Note:
Virtual mounts are always deferred.The SMC does not influence the following types of cartridge tape allocation:
Demand allocation (that is, request for a specific drive(s))
Note:
The SMC performsDEFER processing for demand allocation.Allocations excluded explicitly by entering the ALLOCJob command BYPASS parameter. Refer to the ELS Command, Control Statement, and Utility Reference for more information about the SMC ALLOCDef command.
Allocations where the list of eligible devices contains only devices that are "unknown" (that is, not virtual, not library, and not defined in an SMC UNITAttr command).
DFSMS-managed allocation. An SMS-managed data set is defined as a data set that has a storage class defined. A storage class is assigned when either:
The STORCLAS parameter is specified on the DD statement.
An installation-written ACS routine selects a storage class for a new data set.
The SMC examines all I/O device allocations on a JES2 system to determine whether to process the allocation request.
The SMC uses the MVS subsystem interface (SSI) IEFJFRQ Subsystem Function Request exit to gain control during tape allocation events. The SMC takes control in the JES2 environment for these Subsystem Functions:
SSI55 - DFSMS Interpreter/Dynamic Allocation Exit (IDAX)
SSI24 - common allocation
SSI78 - tape allocation
During MVS JCL interpretation processing, IDAX provides an opportunity to replace the JCL unit parameter, volume count, retention period or expiration date, and other specific JCL attributes for DISP=NEW (and optionally DISP=MOD) data sets.
Note:
This function is optional. See "SMC Esoteric Substitution at IDAX" for information about implementing SMC IDAX processing and specifying IDAX policy attributes.During SSI24 common allocation processing, the SMC performs the following processes to arrive at the best set of eligible drives:
Drive exclusion
Unit affinity separation
Defer processing (when CA1RTS is set to ON)
EDL updated with the drive exclusion results (when MIACOMPAT is set to ON)
The results of the drive exclusion process are not reflected in MVS control blocks until tape allocation time, unless MIACOMPAT or CA1RTS is set to ON.
The results of unit affinity separation are used to update MVS VOLUNIT entries in the SIOT.
During SSI78 tape allocation processing, the SMC performs the following:
Updates to MVS control blocks based on drive exclusion results (unless MIACOMPAT is set to ON)
Drive prioritization
Mount deferral (unless CA1RTS is set to ON)
The SMC sets all unacceptable drives to ineligible status and assigns a priority to each drive that remains eligible for the allocation. The higher the priority, the more likely the device will be chosen for the mount.
The SMC updates the IEFSSTA control blocks for mount deferral, drive exclusion, and prioritization during SSI78 processing.
The following sections describe important JES3 considerations.
If JES3 is not managing any devices and SETUP=NONE has been specified on the JES3 STANDARDS initialization statement, the SMC operates the same as it does in a JES2 environment.
If JES3 is not managing any cartridge drives but is managing other types of devices, specify the J3NOSET parameter on the EXEC statement of the SMC START procedure. See "Creating the SMC START Procedure" for more information. When J3NOSET is specified, the SMC operates the same as it does in a JES2 environment.
If either SETUP=NONE or J3NOSET is specified, no Type 1 modifications need to be installed on your JES3 system.
The SMC supports JES3-managed drives. JES3 manages drives through SETUP processing, which allocates drives identified on SETNAME statements when JOB, HWS (high watermark setup), or THWS (tape high watermark setup) is specified on the SETUP parameter of the JES3 STANDARDS initialization statement. In this environment, JES3 must manage all cartridge drives for the SMC to operate correctly.
SMC support operates during the following MVS subsystem interfaces (SSIs) and JES3 component phases:
SSI55 Interpreter/Dynamic Allocation Exit (IDAX)
JES3 Converter/Interpreter (C/I)
SSI23 JES3 Dynamic Allocation
JES3 Main Device Scheduler (MDS)
SSI24 common allocation
SMC SSI55 processing is identical in JES2 and JES3. See "SSI55 IDAX (Interpreter/Dynamic Allocation Exit)" for more information.
During JES3 C/I POSTSCAN processing, the SMC substitutes an esoteric to eliminate unacceptable drives from the allocation. The SMC performs the following processes to arrive at the best set of eligible drives:
Drive exclusion
Affinity separation
Esoteric unit name replacement to exclude unacceptable devices
At the end of JES3 C/I POSTSCAN processing, the SMC can defer the allocation until the job enters the initiator according to the SMC ALLOCDef command DEFER parameter. Also, at this point of processing, fetch messages can be suppressed according to the ALLOCDef command FETCH parameter.
During SSI23 JES3 Dynamic Allocation processing, the SMC performs the same functions for dynamic allocations that the POSTSCAN C/I processes for common allocations:
Drive exclusion
GDGALL affinity separation
Esoteric unit name replacement
Mount deferral
At the beginning of JES3 MDS processing, the SMC provides the ability to suppress fetch messages for dynamic allocation requests according to the SMC ALLOCDef command FETCH parameter.
During MDS device selection, the SMC sets preference values for drives according to their relative desirability, that is, JES3 selects the available drive with the highest preference value for the allocation.
If a mount has been deferred until the job enters an initiator, during SSI24 common allocation processing, the mount may be deferred further until the data set is opened. The SMC ALLOCDef command DEFER parameter determines whether the mount is deferred.
After drive exclusion and affinity separation successfully complete, each allocation may have a new list of eligible drives. The search begins to find an esoteric containing that exact list of drives. The SMC replaces the original JCL unit name in the Intermediate Job Summary Table (IJS) with this new esoteric.
The search for the "perfect" esoteric begins with the original JCL unit name or the unit name from the catalog entry for that data set. For example, assume the data set being allocated has been cataloged with the unit name 3490. The following table lists all "3490" drives in the system.
| ACS0 | ACS1 | Nonlibrary Location |
|---|---|---|
|
0A10: 9490 |
0C10: 9490 |
0E10: 9490 |
|
0B10: 9840 |
0C11: 9490 |
0E11: 9490 |
JES3 groups devices by XTYPE names and groups XTYPE names by esoterics. The following example shows DEVICE statements coded in the JES3 initialization parameters:
DEVICE,TYPE=TA33490,XTYPE=(ACS09490,CA),JNAME=CA10, JUNIT=(A10,MVS1,TAP,ON),XUNIT=(A10,MVS1,TAP,ON) DEVICE,TYPE=TA33490,XTYPE=(ACS09840,CA),JNAME=CA11, JUNIT=(B10,MVS1,TAP,ON),XUNIT=(B10,MVS1,TAP,ON) DEVICE,TYPE=TA33490,XTYPE=(ACS19490,CA),JNAME=CC10, JUNIT=(C10,MVS1,TAP,ON),XUNIT=(C10,MVS1,TAP,ON) DEVICE,TYPE=TA33490,XTYPE=(ACS19490,CA),JNAME=CC11, JUNIT=(C11,MVS1,TAP,ON),XUNIT=(C11,MVS1,TAP,ON) DEVICE,TYPE=TA33490,XTYPE=(NLIB9490,CA),JNAME=CE10, JUNIT=(E10,MVS1,TAP,ON),XUNIT=(E10,MVS1,TAP,ON) DEVICE,TYPE=TA33490,XTYPE=(NLIB9490,CA),JNAME=CE11, JUNIT=(E11,MVS1,TAP,ON),XUNIT=(E11,MVS1,TAP,ON)
Each unique location and device type pair has a unique XTYPE name. For example, the 9490 drive in ACS0 has a unique XTYPE name because it is the only 9490 in that location. The two nonlibrary 9490 drives share an XTYPE name because they are the same device type in the same location. An XTYPE should always include either a single device type or multiple compatible device types. For example, 9840A and 9840B are compatible device types and may be assigned to the same XTYPE.
XTYPE names are associated with esoteric unit names in the JES3 initialization parameters as shown here:
SETNAME,XTYPE=ACS09490,NAMES=(CART,3490,LIBDRVS,ACS0DRVS,A09490) SETNAME,XTYPE=ACS09840,NAMES=(CART,3490,LIBDRVS,ACS0DRVS,A09840) SETNAME,XTYPE=ACS19490,NAMES=(CART,3490,LIBDRVS,ACS1DRVS,A19490) SETNAME,XTYPE=NLIB9490,NAMES=(CART,3490,NLIBDRVS,NL9490)
Assume that during drive exclusion processing, the SMC determined the volume specified for this allocation resides in ACS0 and requires a 9490 drive. The drive exclusion process eliminates groups of drives by XTYPE.
In the environment defined above, the following XTYPE groups are no longer eligible for the allocation:
ACS09840 - excluded at level 1 because T9840 drives are incompatible with the volume media
NLIB9490 - excluded at level 6 because the volume is in the library and these drives are not
ACS19490 - excluded at level 7 because the volume is in ACS0 and these drives are in ACS1
One XTYPE, ACS09490, remains eligible for allocation at the end of drive exclusion.
SMC esoteric unit name replacement now searches the SETNAME definitions for an esoteric that only contains the XTYPE ACS09490. For this allocation, the SMC selects the esoteric A09490 because it contains only XTYPE ACS09490. The A09490 esoteric replaces the original unit name, 3490, in the Intermediate Job Summary (IJS) table for that job.
If the example required two drives for the allocation (for example, UNIT=(3490,2)) and the first volume to be mounted resides in ACS0, the results of drive exclusion would be as follows:
ACS09840 - excluded at level 1 because T9840 drives are incompatible with the volume media.
NLIB9490 - excluded at level 6 because the volumes are in the library and these drives are not.
Exclusion level 7 fails.
On entry to level 7, three drives remain, two drives defined to XTYPE ACS19490 and the other drive to XTYPE ACS09490. If XTYPE ACS19490 were excluded because of ACS location, only one drive would remain. This allocation requires two drives. Thus, exclusion level 7 does not exclude the drives in ACS1.
Two XTYPEs, ACS09490 and ACS19490, remain eligible for allocation at the end of drive exclusion. The SMC esoteric unit name replacement now determines that XTYPE ACS09490 cannot be used for the allocation.
IBM APAR OW38427 to JES3 introduced the restriction that multi-unit allocations use devices defined in the same XTYPEs. Since XTYPE ACS09490 only contains one drive, it cannot satisfy the allocation requirements. The SMC esoteric unit name replacement now searches the SETNAME definitions for an esoteric that only contains the XTYPE ACS19490. The A19490 esoteric replaces the original unit name, 3490, in the IJS for that job.
After the SMC has updated the IJS, JES3 C/I processing continues. JES3 creates a Job Summary Table (JST) from the IJS table and performs any high watermark setup (HWS) chaining. During HWS chaining, JES3 can also change the esoteric unit name in the JST after the SMC changes the esoteric. The HWSNAME initialization statements define which esoteric unit names are subsets of other esoteric unit names. This allows JES3 to reuse devices in following steps.
See "JES3 Initialization Parameter Considerations" for more information about setting up your installation's JES3 DEVICE, SETNAME and HWSNAME statements.
By the time JES3 C/I processing completes, the IJS becomes the JST that represents the job for the remainder of its existence. The JST reflects the esoteric substitutions made by the SMC and JES3. The next stage for the job is the Main Device Scheduler (MDS).
At the beginning of MDS processing, JES3 begins preparing the job for allocation. Asking the operator to fetch volumes is an optional phase in MDS. JES3 issues a fetch message when a job requires a volume that is not currently mounted and the SETPARAM statement FETCH parameter is set to YES (the default). If the SETPARAM statement also specifies ALLOCATE=MANUAL, jobs are placed on the volume wait queue until the operator retrieves the volume(s) and issues the *START SETUP command.
A customer's installation may not want to receive fetch messages for volumes in the library. To do so for common allocation requests (JCL statement allocation), install the SMC version of the JES3 user exit IATUX09. For dynamic allocation requests, install the SMC Type-1 modification to IATMDFE.
Use the SMC ALLOCDef FETCH parameter to control the issuing of fetch messages. FETCH(OFF) is the default and suppresses fetch messages for any volume that is to be mounted on a library drive. If fetch messages are desired for nonlibrary volumes that are to be mounted on a library drive, FETCH(NONLIB) should be entered.
Note:
FETCH(NONLIB) causes another volume lookup request to the TapePlex, which can affect performance.If your system is running with ALLOCATE=MANUAL as described above, when fetch messages are suppressed for a volume allocation, that allocation does not go onto the volume wait queue.
If your system is running with the SETPARAM statement set to FETCH=NO, or if you prefer to receive fetch messages for all volumes, then the IATMDFE Type-1 modification does not need to be applied to your system. The IATUX09 user exit also performs other functions and should be applied.
The next step in Main Device Scheduler (MDS) allocates the devices required for the job.
The SMC Type-1 modification to IATMDAL provides the SMC with the ability to review the list of drives available for each tape allocation. The list of drives contains drives that are online and available and are members of the group of drives defined in the esoteric placed in the Job Summary Table (JST) after drive exclusion processing.
The TapePlex and nonlibrary drive environment must be defined to JES3 in the initialization deck using the following parameter statements:
DEVICE statements to define drive addresses, device types, and XTYPEs
SETNAME statements to define esoteric names and to associate them with XTYPEs
HWSNAME statements to define the esoteric name relationships used during HWS processing
This section describes these statements and shows how to code them for a sample configuration. This configuration consists of the following drive addresses and esoterics attached to two systems, MVS1 and MVS2.
Table 5-4 Sample Configuration
| Nonlibrary | ACS0 | ACS1 | Virtual |
|---|---|---|---|
|
120-127 3480 |
220-223 4490 |
320-327 9490 |
A20-A5F VTSS1 |
|
140-143 3490 |
240-243 9490 |
440-447 9490 |
A60-A9F VTSS2 |
|
180-189 9840 |
280-289 9840 |
280-289 9840 |
NA |
Note:
The drive addresses and esoterics in this example are not meant to be taken literally but are intended to show how a wide variety of device types can be defined using JES3. Exact JES3 initialization statements are configuration dependent.DEVICE statements define the drives that JES3 can use to satisfy allocation requests. These statements define:
Drive addresses
JES3/MVS systems that can access the drives
Initial drive online status
Device type of the drive
The XTYPE parameter is especially important to SMC allocation. XTYPE connects devices with the same XTYPE value to a group of esoteric unit names. For example:
DEVICE,XTYPE=(DEV0220,CA),XUNIT
(220,MVS1,TAP,ON,220,MVS2,TAP,ON),
NUMDEV=4,...
Devices 220-223 in ACS0 (TABLE 5-4 on page 84) have been associated with the XTYPE name DEV0220. This name allows JES3 to allocate a device from the group 200-223 when any of the esoteric unit names listed on the SETNAME statement associated with XTYPE DEV0220 are specified in JCL or in a catalog entry.
The SMC relies on each XTYPE group to be unique regarding to real drive type and location. In the list of drives for ACS0, the 4490 drives should not be defined with the same XTYPE as the 9490 drives. Also, the T9840 drives located in ACS0 should not be defined with the same XTYPE as the nonlibrary T9840 drives. Devices in different VTSSs should have different XTYPEs.
During SMC initialization, XTYPE groupings are examined to verify these XTYPE restrictions. If an XTYPE contains mixed devices types or mixed locations, the characteristics of the first drive in the XTYPE group defines the remaining drives.
The SMC configuration report utility shows XTYPE, esoteric, and drive information. Refer to the ELS Command, Control Statement, and Utility Reference for more information about the configuration report.
The following example shows how DEVICE statements can be coded for this sample configuration.
Note:
Drives must be defined to MVS before defining them to JES3. Use the Hardware Configuration Definition (HCD) facility to assign MVS unit addresses to the devices in the I/O Configuration.The SETNAME statements define all esoteric unit names and device type names associated with JES3-managed devices. These esoteric unit names and device type names can be specified by the UNIT parameter on a DD statement or as the unit type in a cataloged data set entry.
DEVICE statements associate a set of drives with an XTYPE. The SETNAME statement associates the XTYPE with a group of esoteric unit names.
During SMC esoteric unit name replacement, the relationships among the devices, the XTYPEs, and the esoteric unit names enable the SMC to choose the optimal esoteric unit name.
Note:
During allocation of specific volumes, the SMC attempts to substitute an esoteric containing only drives compatible with the volume. If all esoterics that are a subset of the original esoteric contain some drives not compatible with the volume (except for drives defined asMODEL=IGNORE in an SMC UNITAttr command), the SMC issues message SMC0068 and does not substitute for the original esoteric.Therefore, to ensure the SMC's ability to perform esoteric substitution, you must define at least one esoteric containing only compatible drive types within each TapePlex. For example, if you have a single TapePlex that contains ECART and standard volumes and 9490, 4490 and 4480 drives, you must, at a minimum, define one esoteric containing only drives compatible with the ECART volumes (9490, 4490, and 4480 drives). You can also define other esoterics containing any desired combinations of these drive types.
For best SMC performance, define a unique esoteric for each drive type in each location. For example, an esoteric named A09840 can be defined to contain only the T9840 drives located in ACS0.
The following example shows how SETNAME statements can be coded for this single TapePlex configuration. The esoteric unit names specified in the NAMES parameter value list consist of the following:
CART - All cartridge drives in the environment
NLCART - All cartridge drives not in a library ACS
A0CART - All cartridge drives in ACS0
A1CART - All cartridge drives in ACS1
ALLxxxx - All cartridge drives of the same device type, xxxx, independent of location.
LIBxxxx - All cartridge drives of the same device type, xxxx, in any library location.
yyxxxx - All cartridge drives of the same device type, xxxx, in location yy.
zzzzzzzz - All virtual devices in VTSS zzzzzzzz.
The generic device type names, such as 3480 or SYS3480R, are also specified in the NAMES lists.
* 3480/NONLIBRARY
SETNAME,XTYPE=DEV120,NAMES=(SYS3480R,CART,3480,NLCART,NL3480)
*
* 3490/NONLIBRARY
SETNAME,XTYPE=DEV0140,NAMES=(SYS3480R,SYS348XR,CART,3490,NLCART,
ALL3490, NL3490)
*
* 9840/NONLIBRARY
SETNAME,XTYPE=DEV0180,NAMES=(SYS3480R,SYS348XR,CART,3490,NLCART,
ALL9840,NL9840)
*
* 4490/ACS0
SETNAME,XTYPE=DEV0220,NAMES=(SYS3480R,SYS348XR,CART,3490,A0CART,
A04490,A0DEVT90)
*
* 9490/ACS0
SETNAME,XTYPE=DEV0240,NAMES=(SYS3480R,SYS348XR,CART,3490,A0CART,
ALL9490,LIB9490,A09490,A0DEVT90)
*
* 9840/ACS0
SETNAME,XTYPE=DEV0280,NAMES=(CART,3590-1,A0CART,ALL9840,A09840)
*
* 9490/ACS1
SETNAME,XTYPE=ACS19490,NAMES=(SYS3480R,SYS348XR,CART,3490,A1CART,
ALL9490,LIB9490,A19490)
*
* 9940/ACS1
SETNAME,XTYPE=DEV0460,NAMES=(CART,3590-1,A1CART,ALL9940,A19940)
*
* VIRTUAL DRIVES/VTSS1
SETNAME,XTYPE=DEV0A20,NAMES=(CART,3490,VIRTCART,VTSS1)
*
* VIRTUAL DRIVES/VTSS2
SETNAME,XTYPE=DEV0A60,NAMES=(CART,3490,VIRTCART,VTSS2)
Refer to the appropriate version of the IBM JES3 Initialization and Tuning Reference for more information about esoteric unit name values for the SETNAME statement NAMES parameter.
HWSNAME statements define which esoteric unit names are subsets of other esoteric unit names. Used during JES3 high watermark setup (HWS), these statements determine if a device can be reused from step to step.
The first HWSNAME TYPE parameter specifies the esoteric unit name, known as the major name, used during HWS processing. The following esoteric unit names, called minor names, can be used as an alternate to the major name.
The order of the minor names listed in the HWSNAME statement is the order in which they can be substituted for the major name.
For example:
HWSNAME TYPE=(3490,ALL4490,ALL9490,ALL3490)
and:
//STEP1 EXEC PGM... //DD1 DD UNIT=3490,... //STEP2 EXEC PGM... //DD1 DD UNIT=ALL3490,... //DD2 DD UNIT=ALL4490,...
JES3 HWS processing allocates two drives for this job. The Job Summary Table (JST) for the job after HWS shows the following esoterics for each DD allocation request:
STEP1 DD1 and STEP2 DD2 JST entries contain ALL4490 because ALL4490 appears in the minor name list before ALL3490.
STEP2 DD1 JST entry contains ALL3490.
Another example shows how HWS names are used when allocating across step boundaries:
//STEP1 EXEC PGM... //DD1 DD UNIT=ALL9490,... //DD2 DD UNIT=ALL4490,... //STEP2 EXEC PGM... //DD1 DD UNIT=3490
JES3 HWS begins with DD1 of STEP1 looking for an allocation in STEP2 that can use the same device. DD1 of STEP2 specifies 3490. The HWSNAME above for major name 3490 indicates that ALL9490 is an alternate (or minor) name for 3490. Therefore, STEP1 DD1 and STEP2 DD1 allocate the same drive. The JST entry for DD1 of STEP2 is not updated to reflect a new esoteric. The drive allocated for STEP1 DD2 is freed at the end of STEP1.
The minor names should not contain any devices that are not defined to the major name.
For example:
HWSNAME TYPE=(A0CART,ALL9840,...)
Assume the following:
A0CART contains drives 220-223, 240-243, and 280-289.
ALL9840 contains drives 180-189 and 280-289.
ALL9840 contains drives (180-189) not in A0CART. In this case, volumes inside the TapePlex requesting a T9840 drive may attempt to allocate to a drive outside the TapePlex after HWS processing by JES3. HWS processing occurs after SMC esoteric unit name replacement. Therefore, the HWSNAME definitions can affect the final allocation decision if JES3 also changes the esoteric unit name as in the first example.
The best solution for this situation is to create unique esoteric unit names (by location and device type) so that the SMC can select an esoteric unit name that has no minor name. See the HWSNAME entries in the following example that have been coded for the sample configuration.
* GENERIC MAJOR NAMES
HWSNAME TYPE=(SYS3480R)
HWSNAME TYPE=(SYS348XR)
HWSNAME TYPE=(3480,NL3480)
HWSNAME TYPE=(3490,SYS348XR,
ALL3490,ALL9490,LIB9490,A0DEVT90,
A04490,A09490,A19490,NL3490,NL9840)
HWSNAME TYPE=(3590-1, ALL9940,
A09840,A19940)
*
* ALL DRIVES IN THE COMPLEX
HWSNAME TYPE=(CART,SYS3480R,SYS348XR,3490,3480,3590-1,
ALL3490,ALL9840,ALL9490,ALL9940,LIB9490,
A0CART,A1CART,NLCART,A0DEVT90,
A04490,A09490,A09840,A19490,A19940,
NL3480,NL3490,NL9840)
*
* DRIVES BY DEVICE TYPE
HWSNAME TYPE=(ALL3490,LIB9490,A0DEVT90,A09490,A19490,NL3490,
VIRTCART,VTSS1,VTSS2)
HWSNAME TYPE=(ALL9840,A09840,NL9840)
HWSNAME TYPE=(ALL9490,LIB9490,A09490,A19490)
HWSNAME TYPE=(ALL9940,A19940)
*
* DRIVES BY LOCATION
HWSNAME TYPE=(LIB9490,A09490,A19490)
HWSNAME TYPE=(NLCART,ALL3490,ALL3480,3480,
NL3480,NL3490,NL9840)
HWSNAME TYPE=(A0CART,A04490,A09490,A09840,A0DEVT90)
HWSNAME TYPE=(A1CART,ALL9940,A19940,A19490)
*
* DRIVES BY LOCATION AND DEVICE TYPE
HWSNAME TYPE=(A0DEVT90,A04490,A09490)
HWSNAME TYPE=(NL3480)
HWSNAME TYPE=(NL3490)
HWSNAME TYPE=(NL9840)
HWSNAME TYPE=(A04490)
HWSNAME TYPE=(A09490)
HWSNAME TYPE=(A09840)
HWSNAME TYPE=(A19490)
HWSNAME TYPE=(A19940)
*
* VIRTUAL DRIVES
HWSNAME TYPE=(VIRTCART,VTSS1,VTSS2)
HWSNAME TYPE=(VTSS1)
HWSNAME TYPE=(VTSS2)
The POLicy ESOTeric list allows users to request a higher priority for devices in one esoteric over another.
To enable this processing, define an esoteric that contains all esoterics in the specified list. For example, in the sample configuration, the esoteric A0DEVT90 is used for esoteric substitution for the following policy:
POLICY NAME(P1) ESOTERIC(A09490,A04490)
The DEVTpref parameter of the SMC TAPEREQ statement allows users to request a higher priority for one type of StorageTek 36-track drive during drive prioritization processing. A second or third model of 36-track drive can be specified as alternate choices. This device preferencing is applicable to a TapePlex configuration containing a mixture of 4490, 9490 and 9490EE cartridge drives.
To enable this processing, define an esoteric to include all the desired device types by ACS location or in the entire TapePlex configuration. In the sample configuration, the esoteric, A0DEVT90, serves this purpose for ACS0.
During drive exclusion, if a TAPEREQ indicated DEVT(9490,4490) for an allocation, the SMC could substitute A0DEVT90 for the original unit name if A0DEVT90 is a subset (for example, UNIT=3490).
Note:
JES3 HWS processing can change this esoteric toA09490 or A04490 when reusing drives across steps.When specifying the SMC ALLOCDef command parameter ZEROSCR with a value of ON, create esoteric unit names that span ACS boundaries. As an example, the following esoterics could be added to the sample installation:
CA0A1 - an esoteric containing all drives in ACS0 and ACS1
A0A1X490 - an esoteric containing all 4490 and 9490 drives in ACS0 and ACS1
Assume both ACSs contain scratch volumes.
If the scratch request does not specify media or recording technique, the SMC can substitute CA0A1 for CART.
If the scratch request asked for 36-track recording technique, the SMC can substitute A0A1X490 for 3490.
In this way, both ACSs remain eligible for the allocation.
Note:
Once again, JES3 HWS can alter esoteric unit names after the SMC has selected its choice.The SMC runs on all processors that are active in a JES3 global and local environment. On both global and local processors, start the SMC and any library subsystem(s), the HSC or MVS/CSC(s) before starting jobs requiring cartridge drives.
When the SMC and the library subsystem have initialized on the global processor and are communicating, the SMC performs drive exclusion, affinity separation, esoteric unit name replacement, fetch message suppression, drive prioritization, and mount deferral for both common and dynamic cartridge drive allocations. If the SMC has not completed initialization before jobs enter the JES3 C/I DSP, this processing is not performed. The PROMPT value on the NOSMC parameter of the SMCEHOOK macro delays one C/I DSP if the SMC has not initialized and reminds the operator to start the SMC.
When the SMC and the library subsystem have initialized on the local processor and are communicating, the SMC performs drive exclusion, affinity separation, and esoteric unit name replacement for dynamic cartridge drive allocations.
Note:
Refer to the publication Installing ELS for more information about the SMCEHOOK macro and its parameters.
See Chapter 7, "Monitor Functions and Recovery Procedures" for recovery procedures related to the SMC, library subsystems, and JES3.
Consider the following JES3 constraints:
A timing window exists between C/I processing and MDS processing. A requested volume's location or a scratch subpool count can change during the interval between these two processes. When this situation happens, one or more volumes may need to be ejected from or entered into an ACS.
When a job consists of multiple steps, JES3 HWS processing attempts to minimize the number of devices required. Thus a job consisting of multiple steps, each requesting one tape drive, can be allocated a single drive for the entire job. The following example shows the possible effects on pass-thru processing.
The following figure shows a library configuration containing four LSMs. All drives in the library are online and available.
The following example shows the JCL for the job:
//STEP1 EXEC //DD1 DD DSN=DSN.IN.LSM0,UNIT=3490,VOL=SER=(EX0001,EX0002) //* //STEP2 EXEC //DD1 DD DSN=DSN.IN.LSM1,UNIT=3490,VOL=SER=EX0003 //* //STEP3 EXEC //DD1 DD DSN=DSN.IN.LSM2,UNIT=3490,VOL=SER=EX0004 //* //STEP4 EXEC //DD1 DD DSN=DSN.IN.LSM0,UNIT=3490,VOL=SER=(EX0001,EX0002)
Volumes EX0001 and EX0002 are in LSM0, EX0003 is in LSM1, and EX0004 is in LSM2 and all volumes are the same media and require the same recording technique. The SMC drive exclusion process picked the same esoteric for the allocation.
After the SMC drive exclusion process completes, JES3 HWS analysis determines that the maximum number of drives required for running the job is one. MDS processing allocates the device. Pass-thru processing occurs as follows:
If the allocated drive is attached to LSM0, the number of pass-thrus is two (volume EX0003 moves from LSM1, and volume EX0004 moves from LSM2).
If the allocated drive is attached to LSM1 or LSM2, the number of pass-thrus is three (volumes EX0001 and EX0002 move from LSM0, and either EX0003 or EX0004 moves, depending upon which LSM contains the drive).
If the allocated device is attached to LSM3, the number of pass-thrus is four (all volumes move to LSM3).
The SMC drive prioritization process uses the pass-thru counts when setting a priority for a drive. However, if the "preferred" drive is not available, other available drives can be selected.