I wrestled a bit when I was trying to formulate a title for this page. Perhaps a better title would have been Some Thoughts on My Philosophy of Installing and Modifying MVS ... but I decided to stay with the shorter title.
Everybody who installs MVS eventually makes some distinctive change(s) to their system that makes it uniquely theirs. Even if you have downloaded (or ordered a CD-ROM copy of) the Turnkey MVS built by Volker, if you use the system for any significant length of time, you are going to make some changes that result in your installation being unique. However, there are some methods of implementing changes to MVS that have been proven over time to have less desirable results over the long run. The goal of this page is to share some of the knowledge that I have gained from older and wiser Systems Programmers that might help you to avoid some pitfalls.
By this I do not mean you should not apply PTFs or make changes that are necessary to make your MVS system easier to use the way you prefer to use it. What I do mean is that you should seek to make your modifications reside alongside the datasets installed during System Generation rather than make drastic changes, deletions, and/or additions to IBM's datasets. Some examples of doing this are:
Datasets generated to contain IBM load modules, objects, and data are named with the high level qualifier SYS1. As a general rule, when you need to create additional load modules, objects, and data that address a similar function as those in an existing IBM dataset, you should create a new dataset with the same low level qualifiers, but with a high level qualifier of SYS2. Attributes for the datasets you are creating should be the same as the attributes of the corresponding IBM generated dataset. Where necessary, you can then make changes to the requisite system control information to inform MVS that your secondary dataset is also to be searched whenever the IBM generated dataset is searched (ie., SYS2.LINKLIB can be added to the Link List along with SYS1.LINKLIB; SYS2.HELP and SYS2.CMDLIB can be added to the default TSO Logon procedure; etc.). If you do not already know how to set these relationships up, ask in the Hercules' MVS discussion group or send me your question by email.
Following this same general naming convention, any permanent Operating System related datasets you create should have a high level qualifier of SYS2. The use of SYS2 as a qualifier for this type of dataset is a time honored practice of System Programmers. When you see a dataset name in a catalog or VTOC listing beginning with SYS2, it is an immediate signal that the dataset is one which is related to the functionality of the MVS Operating System, although not necessarily originated by IBM.
There are several reasons minimizing change to IBM's datasets is a good rule to follow. The most important are:
If PTFs are applied using SMP, they can be backed out later. But if you make changes to the contents of datasets installed during System Generation directly, it is your responsibility to back up either the entire dataset or the specific objects that are changed before making the changes.
The reason this is a good idea should be obvious - it is so that you can easily recover from a mistake by removing changes you made, simply by restoring the original IBM objects from the back up copy.
When you create supplemental datasets, place them on DASD volumes other than:
The reason for this rule is that if you decide you want to rebuild your MVS Operating System from the distribution tapes (or libraries) it will be much easier if you don't have to worry about losing the contents of datasets that you have created on the volumes which the System Generation process expects to be empty and available exclusively for the use of the MVS system datasets. If the datasets you originate are isolated, after rebuilding MVS from the distribution you can simply recatalog your datasets in the new MVS Master Catalog without having to recreate them.
Of course, if you have followed my instructions for building MVS 3.8j, you know that I do not follow this rule strictly since I create some of my supplemental MVS OS related datasets on MVSRES and SMP000, and MVS000, which is sort of an extension of MVSRES as I have planned the system. But, on my system, I follow Rule #4 to minimize the impact of rebuilding MVS from scratch (something I have done a number of times).
It is certainly not an original idea to maintain a System Notebook wherein you record any changes you make to your Operating System. The term "notebook" can encompass any method to record changes made, and I have seen "notebooks" maintained as members of Partitioned Datasets, in sequential datasets with much embedded formatting directives (ala Script or locally written formatting programs), in VSAM datasets maintained with CICS programs, or in documents maintained on personal computer word processing programs. So, whatever approach you want to take, just make sure that you can utilize the information recorded in your System Notebook to reconstruct your currently executing version of MVS from either the most recent complete backup or from a vanilla system newly emerged from System Generation.
I found myself frequently rebuilding MVS from the distribution tapes; either to learn more about the System Generation process, to improve my instructions for building MVS here on this site, or to change some aspect of MVS that could only be altered during System Generation. So my solution for documenting my customizations to the Operating System was driven by this. I needed a method that not only documented the changes but kept available the many jobstreams (and requisite datasets) necessary to apply the changes. My system has worked well for me and I recommend it as a way of being able to easily reproduce customization to an MVS system.
I created a 3380 DASD image with the volume serial SYSP01 (Systems Programming 01). At the time I wasn't sure I wouldn't be creating volumes 02, 03, etc., but I have found that a single 3380 volume not only holds all my changes, but has plenty of room for future additions and even affords me some occasional work space. I don't use compressed DASD volumes (CCKD), so the size of the image file is 603 megabytes, which conveniently fits on a regular CD-ROM for the purpose of keeping a current backup. I created a User Catalog - UCSYSP01 - on the volume and allocated 30 tracks (2 cylinders) to the Data Space that holds the User Catalog. An alias of SYSP is defined in the Master Catalog related to this User Catalog, and all of the datasets created on the volume have the high level qualifier of SYSP. Therefore, all datasets defined on the volume are catalogued in the User Catalog contained on the volume. This way, when I generate a new MVS system, I simply import this User Catalog into the Master Catalog on the new system and all the contents of SYSP01 are available on the new system just as they existed on the prior system. Of course, that doesn't replicate the changes made to MVS, but this sets up the required environment. The contents of the datasets on SYSP01 are described below.
Since the purpose of the SYSP01 volume is documenting change, it is important that the contents of the volume itself are strictly controlled and documented. The first dataset that appears in a VTOC listing of the volume is SYSP.$INDEX, which is nothing more than a physical sequential dataset (FB, 80, 3120) in which an entry is made describing each dataset contained on the volume. Here is an excerpt of this dataset:
THIS DATASET IS PROVIDED AS A MEANS TO DOCUMENT THE CONTENTS OF THE REMAINING DATASETS ON THIS VOLUME (SYSP01). DATASET CONTAINS ======= ======== SYSP.$INDEX THIS DATASET SYSP.ALGOL.LIB ALGOL LIBRARY UNLOAD (IEBCOPY) SYSP.ALGOL.LOAD ALGOL COMPILER UNLOAD (IEBCOPY) SYSP.ALGOL.PROCS ALGOL COMPILE PROCEDURES UNLOAD (IEBUPDTE) .. REF SYSP.INSTALL.JCL(MVTALGOL) SYSP.CBT.INSTALL.JCL JOBSTREAMS TO INSTALL CBT SOFTWARE SYSP.COBOL.LIB COBOL LIBRARY UNLOAD (IEBCOPY) SYSP.COBOL.LOAD COBOL COMPILER UNLOAD (IEBCOPY) SYSP.COBOL.PROCS COBOL COMPILE PROCEDURES UNLOAD (IEBUPDTE) .. REF SYSP.INSTALL.JCL(MVTCOBOL) SYSP.FORTRAN.LIB FORTRAN LIBRARY UNLOAD (IEBCOPY) SYSP.FORTRAN.LOAD FORTRAN COMPILER UNLOAD (IEBCOPY) SYSP.FORTRAN.PROCS FORTRAN COMPILE PROCEDURES UNLOAD (IEBUPDTE) .. REF SYSP.INSTALL.JCL(MVTFORT) SYSP.FSE.ASM FSE SOURCE & INSTALL JOBSTREAMS SYSP.HERCCMD.LOAD HERCCMD LOAD MODULE UNLOAD (IEBCOPY) SYSP.IEHMAP.OBJECT OBJECT MODULES FOR IEHMAP INSTALLATION .. REF SYSP.CBT.INSTALL.JCL(IEHMAP) SYSP.IND$FILE IND$FILE LOAD MODULES .. REF SYSP.INSTALL.JCL(IND$FILE) SYSP.INSTALL.DOCS DOCUMENTING MY CUSTOMIZATIONS TO MVS 3.8 SYSP.INSTALL.JCL JOBSTREAMS TO CUSTOMIZE MVS 3.8 SYSP.MACLIB MY ADDITIONAL MACROS FOR MVS ASSEMBLER ...
You may notice that I embed some comments following the dataset description lines naming the member of the INSTALL.JCL Partitioned Dataset that is used to access the dataset.
The dataset listed third from the bottom of the list, SYSP.INSTALL.DOCS, is my equivalent of the System Notebook. This Partitioned dataset (FB, 80, 3120) contains members with narrative describing my customizations. It has an index member, similar to the index dataset for the SYSP01 volume which names and briefly describes each member of the library. Here is an excerpt of this member:
In general, each member of this dataset contains a narrative describing the process required to modify/install a single component, including the jobstream to be submitted and any requisite datasets. Although the contents of this member are in alphabetical order by member name, the narrative they contain is not intended to be read in this order. Each member is a self-contained document describing a single task. These "documents" are intended to be printed using an IEBPTPCH jobstream. The jobstream to print the entire document is also contained in the INSTALL.JCL library and prints the entire "System Notebook" in the correct order. I maintain a current hardcopy version of this document, but if everything was lost except the latest CD-ROM containing this volume, even the hardcopy notebook can be easily reproduced. The first logical section of the documentation is contained in the PROLOG member:
The basic assumption for this documentation is that prior to this point a full, normal SMP and System Generation have been completed using the instructions on www.jaymoseley.com/hercules/installmvs. A backup should have been made after shutting down the starter system. The purpose of this documentation is to guide the rapid installation of all local customizations made to the basic MVS 3.8j Operating System that has been installed. As a means of achieving this goal, any time that a change is made to the OS configuration, an entry is made in this documentation and the corresponding JCL, Procedures, Parameters, source, or other required machine readable materials will be placed in the appropriate libraries on the 3380 DASD volume 'SYSP01'. The datasets contained on the SYSP01 volume include, but are not limited to: SYSP.INSTALL.DOCS SYSP.INSTALL.JCL The INSTALL.DOCS PDS contains the documentation you are now reading. The INSTALL.JCL PDS contains jobstreams that you will submit to apply the customization. The jobstreams may require and utilize additional datasets on the SYSP01 volume. TSO is not initially available on the newly generated MVS 3.8j system, so an alternative method must be utilized to submit the jobstreams from the SYSP.INSTALL.JCL PDS. The following jobstream will add a procedure to the SYS1.PROCLIB that will allow you to submit jobstreams from the MVS console: //IEBUPDTE JOB (001),'INSTALL PROC',CLASS=A,MSGCLASS=A //IEBUPDTE EXEC PGM=IEBUPDTE,REGION=1024K,PARM=NEW //SYSUT2 DD DSN=SYS1.PROCLIB,DISP=SHR //SYSPRINT DD SYSOUT=A //SYSIN DD DATA,DLM='><' ./ ADD NAME=SYSMODS,LIST=ALL //SYSMODS PROC MEMBER='********' //IEBGENER EXEC PGM=IEBGENER //SYSIN DD DUMMY //SYSPRINT DD SYSOUT=* //SYSUT1 DD DSN=SYSP.INSTALL.JCL(&MEMBER), // UNIT=3380,VOL=SER=SYSP01,DISP=SHR //SYSUT2 DD SYSOUT=(A,INTRDR) ./ ENDUP >< After running this job, you can submit any of the jobstreams in SYSP.INSTALL.JCL by using this command on the MVS console: s sysmods,member=???????? and substituting the name of the JCL member to be submitted for the question marks (????????)....
Yes, the detail is excessive for a hobby system running under Hercules, but this is the sort of detail I would expect on a real world system, as well as being the level of detail I am used to utilizing and producing, so it is the solution I devised for my system. There have been times when I have not started Hercules/MVS for several months and when I come back after a period of time, I am sometimes glad to have this level of detail available to refresh my memory. For your own system, you may use the level of detail you desire ... I only submit this as an example of what I do and it works well for me.
I keep the DASD image for SYSP01.3380 backed up regularly to CD-ROM. It takes only a few minutes to burn a copy and from this image I can recreate my entire system. Of course, regular backups of all the other DASD images utilized under Hercules/MVS is a good idea, as well. I accidentally preformed a SCRATCH VTOC PURGE on a volume a few weeks ago and was I ever glad I had a recent backup that included the entire hard drive that contains my MVS DASD image files.
I hope that you have found my instructions useful. If you have questions that I can answer to help expand upon my explanations and examples shown here, please don't hesitate to send them to me:
Return to Site Home Page Frequently Asked Questions
This page was last updated on January 17, 2015 .