Moving a system dataset was a challenge

As part of configuring the IO on my z/OS system using HCD, I needed to create a dataset on the IPL volume. This was a challenge, but I got there, the long way.

When I used the HCD to create a SYS1.IODFxx dataset, I specified the DASD volume I wanted to put it on. Unfortunately, because SMS got in the way and overrode my the volume I had specified, and picked a different one!

I could have changed the SMS definitions to say do not play with dataset beginning with SYS1, but I thought it would be easy to move it. After a while I got the following JCL to work

//IBMIODF JOB   ACCOUNTING INFORMATION,REGION=NNNNK 
//STEP1    EXEC  PGM=ADRDSSU,REGION=0M 
//SYSPRINT DD    SYSOUT=A 
//DASD1    DD    UNIT=3390,VOL=(PRIVATE,SER=USER00),DISP=OLD 
//DASD2    DD    UNIT=3390,VOL=(PRIVATE,SER=A4SYS1),DISP=OLD 
//SYSIN    DD    * 
 COPY DATASET(INCLUDE('SYS1.IODF88.CLUSTER')) SPHERE - 
  PROCESS(SYS1)  - 
   BYPASSACS('SYS1.IODF88.CLUSTER') - 
   NULLSTORCLAS - 
  LOGINDDNAME(DASD1) OUTDDNAME(DASD2) DELETE CATALOG 
/* 

Notes:

1. I had to specify the name with its cluster name. Without this I got message ADR383W code 05.
2. Although I had specified the target volid of A4SYS1, it was moved to A4USR1! I had to specify
   1. PROCESS(SYS1) I think it gives an extra layer of security. For example many people can have access to DFDSS to move data sets, around, but only a few people would want to move SYS1.** data sets around.
   2. BYPASSACS(…) to bypass SMS and not use ACS routines to allocate the volume. I had to specify the dataset name, using “*” did not move it to the required volume.
   3. NULLSTORCLASS to tell SMS not to use a storage class.