Create a single volume SYSRES? Are you Crazy?

Kevin Miner
Theropod
Published in
7 min readJul 12, 2024

πŸ–₯πŸ–₯πŸ–₯πŸ–₯

For the past several months I have been noticing the participants on the Webex/Microsoft Teams calls appear to be getting younger and younger. As I listened to the conversations and, and intelligent questions, the thought occurred to me β€œWhat is a change we could make to our z/OS configuration that would make it easier for them to understand z/OS?” I pondered this question as we were in the midst of building our z/OS 2.4 base system to roll out to all of our other systems running z/OS 2.4 and below. Our current rollout plan was to use three DASD devices. Each being about 58 GB of space. Thinking about this the idea occurred to me β€œcould we do this with a single volume?”. The benefits of a using a single volume would be:

  • Simpler to understand.
  • Fewer volumes to deploy, although the same volume of data would be deployed.
  • The z/OS system and supporting SMPE environment would be on the same volume, which would allow some of the SMPE data sets currently being managed by SMS to be removed. This would free more SMS space for application use.

To do this would require the single volume to be an Extended Attribute Volume (EAV), which is a device greater than 58 GB, to be used as a sysres volume. EAV devices are divided into two types of managed space, Track Managed Space (TMS) and Extended Addressing Space (EAS), also known as Cylinder Managed Space (CMS). To my knowledge no one has documented or published the restrictions of IPLing a z/OS server with an EAV device. Said restrictions would document which, if any, of where the data sets must reside on the sysres volume.

  1. If SYS1.NUCLEUS is allocated in CMS the IPL will fail with a 0010000e wait state.
    a - IPL cannot locate the SYS1.NUCLEUS data set or the system nucleus member of the SYS1.NUCLEUS data set on the system residence volume or the SYS1.NUCLEUS data set is described by a format 8 DSCB.
  2. The PARMLIB entries in the LOADxx member, including the default of SYS1.PARMLIB must be allocated in TMS. Allocating these data sets in CMS will result in an IEA345A SYS1.MESA.PARMLIB.EAV NOT USED (OPEN FAILED) β€” PRESS ENTER TO CONTINUE
  3. MSTJCLxx and JES2 supported allocating data sets in EAS on an EAV IPL volume.

To prove all of this my cohort in this endeavor, Donald Bearden in DFSMS Device Services, provisioned a 262,668 cylinder EAV device. He then,

1. Set the SMS BreakPointValue (BPV) to zero to allow any allocations to pass the size threshold for EAS allocation.

2. Used ADRDSSU with the SET PATCH 5B = FF to copy data sets from a non-EAV IPL volume to our test EAV IPL volume.

a. These two actions allowed all data sets to be allocated in EAS on the test EAV device.

The net of this testing is the data sets which must be in TMS on an EAV IPL device are,

1. The volume VTOC

2. The volume index VTOC

3. The volume VVDS

4. Any parmlib data sets used in the LOADxx used during the IPL.

5. SYS1.NUCLEUS

Now that we have shown it is possible to use an EAV device for a sysres. What are the logical steps one would use to set it up?

Step 1 β€” INIT the device and add IPL text. To INIT the device one would use JCL similar to this,

//* β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€”
//* Initialize the volume.
//* β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€” β€”
//INITVOLS EXEC PGM=ICKDSF,COND=(0,LT)
//SYSPRINT DD SYSOUT=*
//SYSIN DD *,SYMBOLS=EXECSYS
INIT UNIT(E88C) VOLID(IPLA40) VERIFY(IPLA40) PURGE -
VTOC(0,1,135) NOVERIFYOFFLINE
/*
//*
//IPLTEXT EXEC PGM=ICKDSF,REGION=4M
//IPLDEV DD DISP=OLD,UNIT=3390,VOL=SER=IPLA40
//TRK0TEXT DD DISP=SHR,DSN=SYS1.SAMPLIB(IEAIPL00)
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
REFORMAT DDNAME(IPLDEV) NOVERIFY IPLDD(TRK0TEXT)
/*

Notice the location and size of the IXVTOC is intentionally not specified. The reasons for not specifying the IXVTOC information are documented here.

Step 2 β€” Copy non-VSAM data sets from a non-EAV sysres to cylinder managed space (CMS) on an EAV sysres.

Note 1 β€” the use of the ADRDSSU SET PATCH 5B = FF command as this will set the DS1EATTR flag in the data set DSCB being copied to OPT, which will allow said data set to be allocated in CMS.

Note 2 β€” the use of ADRDSSU ((DSORG,NE,VSAM),(FSIZE GE 285) commands. This will copy all non-VSAM data sets greater than or equal to 285 tracks into CMS on the target volume, assuming 285 tracks in larger than the SMS BreakPoint (BPV), which defaults to 150 tracks. [CS1]

//EXPORT1 EXPORT SYMLIST=(*)
//SETIN SET INVOL=’IPLA10' INPUT VOLSER
//SETOU SET OUTVOL=’IPLA40' OUTPUT VOLSER
//*
//COPYALL EXEC PGM=ADRDSSU,REGION=4M
//SYSPRINT DD SYSOUT=*
//DASDIN DD UNIT=3390,DISP=SHR,VOL=SER=&INVOL
//DASDOUT DD UNIT=3390,DISP=SHR,VOL=SER=&OUTVOL
//*
//* COPY ALL NON-VSAM, NON-ZFS DATASETS
//*
//SYSIN DD *,SYMBOLS=EXECSYS
SET PATCH 5B = FF
COPY DATASET(BY((DSORG,NE,VSAM),(FSIZE GE 285)) -
NCLUDE( -
*.**, -
), -
EXCLUDE( -
SYS1.NUCLEUS, -
SYS1.PARMLIB, -
)) -
LIDD(DASDIN) -
OUTDD(DASDOUT) -
TGTA(SRC) -
PROCESS(SYS1) -
BYPASSACS(**) -
NMC -
NSC -
TOL(ENQF) -
SHR
/*
//*

Step 3 β€” Repeat the ADRDSSU copy by removing the SET PATCH 5B = FF and set FSIZE LT 285. This will copy all non-VSAM data sets smaller than 285 tracks into TMS on the target volume. One would also remove the entire EXCLUDE() ADDRDSSU parameter.

Step 4 β€” Repeat the ADRDSSU copy without the SET PATCH 5B = FF and the FSIZE parameters. Add and modify the following parameter. Modify to include any of your parmlib data sets defined in your LOADxx member that will be on your EAV sysres.

INCLUDE( -
SYS1.NUCLEUS, -
SYS1.PARMLIB, -
))

If these data sets were created without the EATTR=OPT parameter or are smaller than your SMS BPV they will be allocated in track managed space on your EAV sysres.

Step 5 β€” Repeat the ADRDSSU using DSORG,NE,VSAM to copy SMPE DLIB non-VSAM data sets onto the EAV sysres by using the INCLUDE(SMPE.**). Change this parameter to control which SMPE non-VSAM data sets are copied to the EAV sysres.

Step 6 β€” Repeat the ADRDSSU using DSORG,EQ,VSAM to copy any SMPE VSAM data sets onto the EAV sysres by using the INCLUDE(SMPE.**). Change this parameter to control which SMPE VSAM data sets are copied to the EAV sysres.

Step 7 β€” Repeat the ADRDSSU using DSORG,EQ,VSAM to copy any OMVS ZFS data sets onto the EAV sysres by using the INCLUDE(OMVS.**). Change this parameter to control which OMVS ZFS data sets are copied to the EAV sysres.

Step 8 β€” Update the LOADxx used for this test. This was done to test using the PARMLIB data set in CMS on the EAV sysres. As documented above this created an error. The[CS2] LOADxx listed below shows a parmlib data set on the IPLA40 sysres, allocated in track managed space.

SYS1.IPLPARM(LOADDB)
LPARNAME SSGMESA
INITSQA 0002M 0002M
IODF D2 DEVTEST SSGMESA 00 Y 0
NUCLEUS 1
PARMLIB SYS1.MESA.PARMLIB.EAV.NONEAS IPLA40
SYSCAT M0ACAT14 SYS1.ICFMCAT.MES0A
* Use IEASYM00 & display list of members used in message IEA009I at IPLIEASYM (00,8D,L)
SYSPARM (8D,L)

Step 9 β€” If necessary, update SYS1.PARMLIB.EAV(MSTJCLxx) to use your SYS1.PROCLIB data set residing in cylinder managed space on your EAV sysres.

SYS1.MESA.PARMLIB.EAV(MSTJCL55)
/
/MSTJCL55 JOB MSGLEVEL=(1,1),TIME=1440
// EXEC PGM=IEEMB860,DPRTY=(15,15)
//STCINRDR DD SYSOUT=(A,INTRDR)
//TSOINRDR DD SYSOUT=(A,INTRDR)
//*This following is a test d.s as it is not normally on the sysres.
//IEFPDSI DD DISP=SHR,DSN=SYS1.MESA.PROCLIB.EAV
// DD DISP=SHR,DSN=SYS1.PROCLIB
//SYSUADS DD DISP=SHR,DSN=SYS1.UADS

Step 10 β€” Update the JES2 proc, this was for the purpose of testing system data sets allocated in CMS on an EAV.

SYS1.MESA.PROCLIB.EAV(JES2)
//JES2 PROC M=JES2D55,LOCAL=SYS1.MESA,
// PRM=’WARM,NOREQ’,TYPE=’IPL’
//*
//IEFPROC EXEC PGM=HASJES20,TIME=1440,DPRTY=(15,15),PARM=’&PRM’
//HASPLIST DD DDNAME=IEFRDER
//*
//HASPPARM DD DISP=SHR,DSN=&LOCAL..PARMLIB.EAV(&M)
// DD DISP=SHR,DSN=&LOCAL..PARMLIB.EAV(JES2&TYPE)
//*
//ST DD DISP=SHR,DSN=SYS1.PARMLIB(JES2BERD)
//*
//* PROCLIB DD statements provided in SYS1.MESA.PARMLIB(JES2D55)
//* Use $DPROCLIB to display and $TPROCLIB to change.
//PROC00 DD DISP=SHR,DSN=&LOCAL..PROCLIB.EAV
//PROC01 DD DISP=SHR,DSN=&LOCAL..PROCLIB.EAV
//*
//STEPLIB DD DISP=SHR,DSN=SYS1.LINKLIB
//*

Step 11 β€” Update the JES2 parms, again this was for the purpose of testing system data sets allocated in CMS on an EAV.

SYS1.MESA.PARMLIB.EAV.NONEAS(JES2D55)
PROCLIB(PROC00) DD(1)=(DSNAME=SYS1.MESA.PROCLIB.EAV,VOLSER=IPLA40),
DD(2)=(DSNAME=SYS1.PROCLIB,VOLSER=IPLA40),
DD(3)=(DSNAME=SYS1.LOGON.PROCLIB,VOLSER=IPLA40),
DD(4)=(DSNAME=D55TST.VISION.SYSTEM.PROCLIB,VOLSER=RV9901),
DD(5)=(DSNAME=D55TST.VISION.SYSTEM.USER.PROCLIB,VOLSER=RV9901)

PROCLIB(PROC01) DD(1)=(DSNAME=SYS1.MESA.PROCLIB.EAV,VOLSER=IPLA40),DD(2)=(DSNAME=SYS1.PROCLIB,VOLSER=IPLA40),

DD(3)=(DSNAME=D55TST.VISION.SYSTEM.PROCLIB,VOLSER=RV9901),
DD(4)=(DSNAME=D55TST.VISION.SYSTEM.USER.PROCLIB,VOLSER=RV9901)

Steps 5, 6 and 7 we got a bit creative by copying SMPE zones and ZFS data sets onto the EAV sysres. By doing this we now have a single sysres volume that has the SMPE global and target zones, the SMPE target and DLIB data sets and the ZFS data sets. A single volume capable of supporting a z/OS system. Please note, there is a difference between supporting and running a z/OS system. This EAV sysres does not have the required RACF, I/O and network configuration or middleware components which may be required to run a z/OS system.

Yet we do have a single volume we can use to deploy, clone and update to maintain a z/OS system.

It has been said that a picture is worth a thousand words. Below is a partial allocation map of the EAV sysres we used for this test. The focus of this picture being the data sets in track managed space on this volume.

A huge thank you to Donald Bearden, DFSMS Device Services, for providing the environment to perform this test. Donald also created and ran all the jobs to create the EAV sysres volume we used for our test.

--

--

Kevin Miner
Theropod
Writer for

Currently in IBM DFSMS Device Services Test. System programmer since 1983. Worked for a large zOS customer 1983–1999 then IBM 1999 β€” current.