## 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. 

