When I worked with customers, you could often tell people who were not experienced, and setting up subsystems and applications
“My first JCL”
//STEPLIB DD DSN=ABC120.EG1.SABCAUTH,DISP=SHR /* USER LIB */
// DD DSN=ABC120.SABCANLE,DISP=SHR
// DD DSN=ABC120.SABCAUTH,DISP=SHR
// DD DSN=CEE.SCEERUN,DISP=SHR
...
//FILE1 DD DSN=ABC120.EG1.FILE01,DISP=SHR
//FILE2 DD DSN=ABC120.EG1.FILE02,DISP=SHR
Where the FILE datasets contain user data.
All the ABC120.* datasets were shipped on a volume ABCV12. When the system was updated to a newer service level, the volume ABCV12 was refreshed and put on all systems.
What could go wrong?
The first problem – whoops
With the volume ABCV12 being replaced, all the user data is replaced – Whoops.
Solution: You need to keep your libraries and user data separate. Product libraries on ABCV12, and user data on USRxxx. You might want to make the volume for the product libraries (ABCV12) read only.
The second problem – what is this?
Once you have fixed the problem and separated the data onto different volumes you upgrade to the next version ABCV13.
Now your JCL is
//STEPLIB DD DSN=ABC130.EG1.SABCAUTH,DISP=SHR /* USER LIB */
// DD DSN=ABC130.SABCANLE,DISP=SHR
// DD DSN=ABC130.SABCAUTH,DISP=SHR
// DD DSN=CEE.SCEERUN,DISP=SHR
...
//FILE1 DD DSN=ABC120.EG1.FILE01,DISP=SHR
//FILE2 DD DSN=ABC120.EG1.FILE02,DISP=SHR
People looking at this will be confused and will ask what release are we running, it looks like 1.3, but the data sets say 1.2
Solution: Use a name like ABCUSER.EG1.FILE01 instead of ABC120.EG1.FILE01. These names never change when you migrate to a newer release.
You can enforce which HLQ’s can use which volumes using HSM rules.
You want to do a test upgrade to the next release: – how much work is it!!
Over this weekend, you want to test out the next release and go from release 1.3 to 1.4. You look at all your JCL, use SRCHFOR ABC130. and find all the places where you have ABC130 (wow, lots of places). You will have to change the JCL to run the subsystem at the start of the test, run your test, and change it all back ready for production next week. With all the changes you need to be careful not to make a mistake. (And of course all the change request paper work needs to be approved)
A better way is to use dataset aliases.
DEFINE ALIAS(NAME(ABC.SABCAUTH) RELATE(ABC120.SABCAUTH))
DEFINE ALIAS(NAME(ABC.SABCANLE) RELATE(ABC120.SABCANLE))
etc
So when you use ABC.SABCAUTH under the covers it uses ABC920.SABCAUTH
Your JCL now looks like
//STEPLIB DD DSN=ABCUSR.EG1.SABCAUTH,DISP=SHR /* USER LIB */
// DD DSN=ABC.SABCANLE,DISP=SHR
// DD DSN=ABC.SABCAUTH,DISP=SHR
// DD DSN=CEE.SCEERUN,DISP=SHR
...
//FILE1 DD DSN=ABCUSER.EG1.FILE01,DISP=SHR
//FILE2 DD DSN=ABCUSER.EG1.FILE02,DISP=SHR
You do not need to worry about APF authorising the CSQ.SCSQAUTH. The dataset which is checked is the dataset the alias points to.
To test the next release this weekend, you delete the aliases and define the new ones. You do not need to change your JCL libraries. You run your tests and at the end delete the new aliases and redefine the old one. The JCL will fit on one screen is much easier than changing all your JCL libraries, and less error prone. (And someone else can review the JCL before you make the changes)
An alternative way
You could use system symbolics EGHLQ = ABC120, and refer to it as in //STEPLIB DSN=&EGHLQ..SABCAUTH
Hands up…
If you are guilty of the problems raised in the blog post, you can get round them.
You can implement the alias for the product libraries, and gradually change all references to use the aliases.
Where you have
//FILE1 DD DSN=ABC120.EG1.FILE01,DISP=SHR
//FILE2 DD DSN=ABC120.EG1.FILE02,DISP=SHR
You can define an alias for these and use DSN=ABCUSER.EG1.FILE01. Once you’ve made the change your friends will appreciate the clarity, and the only people who know about the mess you made are the storage administrators.
In the long term you may be able to fix it by copying the datasets to new ones with the proper name, and deleting the old ones.
