Installing MVS 3.8
Performing a System Generation - Building MVS 3.8j
The System Generation Process
System generation is the process that creates an OS/VS2 MVS system control program tailored to both the data processing requirements and machine configuration of an installation.
For a complete system generation, the job stream produced during Stage I is processed during Stage II to create an entirely new MVS system control program.
The two summary statements above are taken from the OS/VS System Generation Reference [GC26-3792].
The system control program referenced in these statements is not a single program, but rather a complete set of datasets, allocated (planned, then defined on one or more DASD volumes, and initialized to receive content), catalogued in a Master Catalog (a VSAM object defined on the primary DASD volume of the system), and then populated with object modules, load modules, tables of parameters, and JCL (Job Control Language) statements. The majority of the material used to populate the datasets will come from the Distribution Libraries built from the IBM product tape, however some of the material is derived from settings chosen during the system design. In a production system in a real world environment, many settings are the result of months or years of fine tuning and modification.
Prerequisites
To recap prior steps, in order to perform a System Generation, you should already have downloaded/installed on your computer -
-
Hercules executables (available from http://www.hercules-390.eu/)
-
The MVS 3.8j product tapes archive (download from my site @ http://www.jaymoseley.com/hercules/downloads/archives/mvs38distTapes.rar)
-
My installation objects archive (download from my site @ http://www.jaymoseley.com/hercules//downloads/archives/installmvs.tgz)
-
You should have created the MVS starter system on two 3330 DASD volumes - START1.3330 and SPOOL0.3330.
-
You should have created the distribution libraries on 3350 DASD volume SMP000.3350 and have two work 3350 DASD volumes (WORK00.3350 and WORK01.3350).
Although not mandatory, this is the structure into which I have MVS related files and these instructions will show commands, output, etc. using this relative structure as a reference point:
The installmvs archive (item #3 in the prerequisites list above) contains files used for this and all previous/subsequent steps of this set of instructions. Fourteen files are required for this step (I only include one each of the create.dasd, condcode, and stage2 scripts in this count):
create.dasd.bat or create.dasd.sh extracted to mvs directory Windows bat script that utilizes the dasdinit utility to create empty DASD volumes bash script that utilitzes the dasdinit utility to create empty DASD volumes
condcode.pl
or
condcode.rexxextracted to mvs directory PERL script to extract/display condition codes for jobs REXX script to extract/display condition codes for jobs
stage2.awk
or
stage2.rexxextracted to mvs directory AWK script to modify stage2 jobstream
REXX script to modify stage 2 jobstreamsysgen.script extracted to conf directory Hercules command script to add new DASD to configuration sysgen.cnf extracted to conf directory Hercules configuration file to execute Hercules/MVS starter system to build target MVS 3.8j fdz1d02.jcl
null.jcl
sysgen00.jcl
sysgen01.jcl
sysgen02.jcl
sysgen03.jcl
sysgen04.jcl
sysgen05.jcl
sysgen06.jclextracted to jcl directory Jobstreams submitted to MVS starter system to build target MVS 3.8j
The clock time required to complete the steps below should be approximately 25 minutes; the actual elapsed time for the jobs to execute was extracted from the jobs' SYSOUT logs [3.57 minutes], so I have added 21 minutes to this estimate for 'user' time and rounded up to 25 minutes.. All times given here should be taken as estimates. The actual time reported for each job depends greatly upon the hardware and host Operating System (Linux/MAC/Windows) upon which Hercules is executing. The time necessary for you to complete the steps may be longer if you have not already gathered all required files and have them restored to the appropriate locations before beginning. For reference, on 22 September 2017 I made some minor changes to the contents of the installmvs archive, so I decided to run through these instructions to verify I had not broken anything. I am running Linux Mint on a fairly recent, quad core machine. Granted I don't have to contemplate the instructions as someone who had not read/followed them previously might, so I am at a distinct advantage; but for me, this step took exactly 13 minutes.
Create additional DASD Volumes
The end result of building the distribution libraries in the prior step was three 3350 DASD volumes, which are located in the dasd directory, along with the two 3330 DASD volumes which contain the starter system.
Now we will use the the create.dasd.bat (the same script we used before) to create four additional DASD volumes required for this step. In this step you will:
-
change to the dasd subdirectory
-
if the four DASD volumes exist, delete them
-
utilize the dasdinit utility (included with Hercules) to create the four volumes
On a Windows system, open a Command Prompt window and type the command:
create.dasd sysgen
and press Enter. The script will execute, creating the four DASD images: The console output of the script on my system is shown below:
The DASD volumes that are created are simply raw emulated volumes; they have not been initialized for use by MVS and contain no VTOC or control structures. They will be initialized in the next step.
On Linux systems: I have also provided a bash version of this script (create.dasd.sh); on Linux systems, execute this script with the single argument 'sysgen' to create the three DASD images.
Alternately you may also issue the commands from a console prompt after changing to the dasd directory:
dasdinit -a mvsres.3350 3350 111111
dasdinit -a mvs000.3350 3350 222222
dasdinit -a spool1.3350 3350 333333
dasdinit -a page00.3350 3350 444444
Checking MVS Completion Codes
Every batch job or started task that executes under MVS returns a completion code (also known as a condition code or return code) at the conclusion of each step (program executed). The value of the completion code is printed in the Job Log section of the SYSOUT listing, following the Allocation messages for each step. It is essential that you examine the output of each job to ensure that the codes you received for each step match those expected. If you receive an unexpected code, it probably means an error has occurred during execution of the job that must be corrected, and the job rerun, before you proceed. The SYSOUT listings can be found in the host Operating System file assigned to the printer device address as specified in the Hercules' configuration file. If you use the configuration files included in the installmvs archive, the file will be located in the mvs directory and will be named prt00e.txt. You can view this file with a text viewer or editor while Hercules is still running. The current version of Hercules protects the files assigned to its emulated devices by making them read-only access. The completion code is listed in a message with the prefix IEF142I, so you can find the completion code by searching for this string. As an alternative, I have included a Perl program in the installmvs archive - condcode.pl - and a REXX program - condcode.rexx - either of which you may use to display the step completion codes for any job; their function is identical, I simply needed the REXX version for a computer on which I did not have PERL installed. Of course you will need Perl or REXX installed on your system to use one of these. The command line syntax for the program is:
{ condcode.pl | condcode.rexx } <print file name> <MVS job name>
If you are following the directory structure I have suggested, the program should be executed from the mvs directory. The output can also be redirected to a file, a printer, or filtered to another program, such as more. Any step with a completion code other than 0000 will be indicated by the inclusion of "<--" to the right of the completion code. Remember that a non-zero completion code may be acceptable for a particular step; all acceptable and expected codes will be listed in these instructions.
IPL the Starter System
Again you will be using a slightly different configuration from before. The hardware environment defined in the Hercules' configuration file - sysgen.cnf - is:
Notice that this graphic doesn't quite match the Hercules configuration file, as distributed, because the four DASD volumes at the bottom are not present in the configuration file. The reason for this is that those are the volumes that we just created and will need to be initialized by a utility executed on the starter system; that utility requires that the volumes be 'offline' and so cannot be present when the starter system is IPLed. Also, you may notice that the five DASD volumes from the previous steps are now located at slightly different unit addresses. The reason for this is that the MVS Starter System does not have 3350 DASD devices generated at seven consecutive unit addresses, so the seven 3350 DASD volumes are split between addresses on channel 1 and channel 2.
The purpose for each of the new volumes is:
- MVSRES (3350 @ x'149') - will be the IPL volume of the target MVS 3.8j system
- MVS000 (3350 @ x'14a') - will contain additional system datasets for MVS 3.8j
- SPOOL1 (3350 @ x'14b') - will contain the JES2 spool queues dataset
- PAGE00 (3350 @ x'14c') - will contain the page datasets
Open a console window (Linux) or a Command Prompt window (Windows) and start hercules by typing the command hercules -f conf/sysgen.cnf and pressing Enter.
Hercules will read the configuration file and wait for the console to connect at address x'01f'.
Start your telnet client and connect to 'localhost', port number 3270; if your client does not store options, remember that you need 'local echo' set on.
On the command line in the console window where Hercules was started, type the command ipl 150 and press Enter.
Since we rebuilt some load modules at the end of the prior step, it would be a good idea to rebuild the Link Pack Area, so for the first prompt - IEA101A SPECIFY SYSTEM PARAMETERS FOR RELEASE 03.70.VS2 - type r 0,clpa and press Enter in the telnet client window.
We do not need to format the JES2 queue this time, so in response to the message - *00 $HASP426 SPECIFY OPTIONS - HASP-II, VERSION JES2 4.0 - type r 0,noreq in the telnet client window and press Enter.
There are three initiators started. It will make things simpler for you to manage if there is only one job executing at a time, so we will stop two of the initiators. On the MVS Starter System console (in the telnet client window), type the command $pi2-3 and press Enter. Initiators 2 and 3 will end.
At this point the system is ready to process jobs and service operator commands. However, the four DASD volumes we created above are not defined in the Hercules configuration file (sysgen.cnf in the conf directory). As with the previous steps where we built the distribution libraries, I have provided a Hercules script to add the drives to the 'active' configuration. On the command line in the console window where Hercules was started, type script conf/sysgen.script and press Enter. Your Hercules command window should look like:
Initialize Target DASD Volumes and Prepare for System Generation SYSGEN00
The first task is to initialize the four DASD volumes that we just created on which the new MVS 3.8j system will be built. The jobstream to complete that task - SYSGEN00 - is contained in the file sysgen00.jcl located in the jcl directory.
On the command line in the window where Hercules was started, type the command devinit 12 jcl/sysgen00.jcl eof and press Enter. The job will begin execution and on the Starter System console (telnet client window) you will see:
The ICK003D message is informing you that an offline volume at address 149 is to be initialized or labeled and the operator is requested to verify that the desired volume is currently mounted at the address. This is expected and acceptable, so you will reply U to proceed. In the telnet client window type the command r 1,U and press Enter. Remember that the response number shown in the screen captures here may differ from the response numbers presented on your system.
You will receive the same message - ICK003D - four times in succession, once for each of the DASD mounted at addresses x'149', x'14a', x'14b' and x'14c' in sequence; you should reply U to each of these messages:
As soon as the four DASD volumes are initialized, SYSGEN00 submits a second jobstream through the internal reader. This job will have the same name - SYSGEN00 - although it is a completely separate job. The first task of this new job is to issue MVS commands to place the new volumes online and set their volume attribute. The MVS Starter System will not execute commands submitted through a job without confirmation, so on the Starter System console you will see message IEF166D asking you to confirm the execution of the first command, which will Vary the four new DASD volumes online:
In the telnet client window type r 5,Y and press Enter to accept (execute) the command. You will receive four additional IEF166D commands in response to the mount commands for the four volumes. Reply Y to each of the messages. The purpose of the mount command is to place each of the new volumes online with a volume attribute of PRIVATE; this ensures that there will be no datasets allocated on the volumes that are not specifically directed to the volume by the jobs we submit.
SYSGEN00 takes 0.25 minutes to complete. Remember there were two jobs named SYSGEN00, so I am including the execution time for both in this total and the expected condition codes for all steps of the two SYSGEN00 jobs are:
The IEHPROGM step of SYSGEN00 attempts to delete some datasets we will be creating in the following steps (in case of a need to restart from this point); the datasets are not there, so the return code 0008 is expected. If they had been present and successfully deleted, then the expected return code is 0000.
The remaining steps are setting the environment to build the new system and must receive return codes of 0000. If you are interested in the details of what each step is doing, I have placed numerous comments in the jobstream explaining the reason for each step.
You may remember from building the distribution libraries, you can also check on the completion of the mount commands:
Stage 1 SYSGEN01
The Stage 1 jobstream - SYSGEN01 (contained in file sysgen01.jcl in the jcl directory) - contains all of the specifications for the hardware configuration of the new MVS 3.8j system to be built.
If you have utilized previous versions of my instructions to build MVS 3.8j, you should note that I have made some changes to the hardware configuration. After all, it has been several years since I made any modifications, so I thought it a wise time to do so. I have incorporated some changes as a result of looking over some additional configurations that have come by my desk, but some of the changes are the result of discussions on the Hercules' community newsgroups. I have added some devices that I am anticipating I might want to use later, even though I might not be ready to use them right away.
If you know of some changes you would like to make, you should feel free to edit the configuration, but be aware that you may create errors that you will need to resolve before you proceed past this step.
On the command line in the console window where Hercules was started, type the command devinit 12 jcl/sysgen01.jcl eof and press Enter.
SYSGEN01 takes 0.25 minutes to complete. Like the previous job, if there are no serious errors, SYSGEN01 submits a second jobstream through the internal reader. This job will have the same name - SYSGEN01 - although it is a completely separate job whose purpose is to punch the output from processing the Stage 1 into card images. Expected condition codes are:
The CLEANUP step attempts to delete the dataset which will hold the output from the job; it is not there when we start, so the return code 0008 is expected. If you need to rerun the job, you should expect a return code of 0000 for this step. You may rerun this job as many times as you desire, or are needed to remove all errors discovered during the assembly. If you are using the jobstream as I have distributed it, there are no errors to be resolved.
If you look at the printed output from this step, in the diagnostics listing from the assembler, you should see a single MNOTE issued at statement 2045. The severity of this error is 0, so it is only an informational message, specifically stating that all tables will be included for the 3800 printing subsystem. This is expected and normal; no corrective action needs to be taken to resolve this.
If you do make changes to the configuration and serious errors occur during the assembly which must be corrected, the assembly will be terminated prematurely and a Stage 2 deck will not be created. If there are serious errors, the secondary job will not be submitted, so you will not even see the steps listed for the IEBGENER and PUNCH steps. The punch step transfers the card images produced when the Stage 1 deck is assembled to the file attached to the emulated card punch at address x'013'; they may be found in the file pch013.txt in the mvs directory.
However, there are some changes that need to be made to the jobstreams before they are submitted.
I am aware that other folks who have done this process have taken the approach to modify the System Generation macros, which results in these changes already being made when the card images are produced. My approach is to leave the macros as they are distributed and make the changes at this point, when the card images have been transferred to a text file on the host operating system (LINUX, Windows, etc.).
You may make the changes manually with your favorite text editor - joe, vi, notepad, etc. - but I have also provided a couple of scripts that will make the changes for you. To make the changes manually, copy pch013.txt to stage2.jcl; then edit the stage2.jcl file to make the changes. If you utilize my scripts (which are described in the highlighted section below), execution of the script will copy the contents of pch013.txt as it makes the changes.
The first two card images in the punched deck, and the last card image in the deck, are job separator cards and should be deleted. The remainder of the file contains the six jobstreams which generate the MVS 3.8 system, each preceded by a JOB card generated during the Stage 1 processing. The following changes need to be made to the jobs before the may be submitted for processing:
For jobs 1 through 5, add a continuation card immediately after the JOB card (add a comma onto the rightmost end of the JOB card and insert a card following the JOB card with // in the first 2 columns). Note that job 6 already has a continuation card for the JOB card.
For jobs 1 through 5, add TYPRUN=HOLD on the newly added continuation card of the JOB card beginning anywhere in columns 2 through 16. Note that job 6 already has TYPRUN=HOLD on the continuation card.
For all jobs, add a comma and TIME=1439 following the TYPRUN=HOLD on the continuation of the JOB card.
For all 6 jobs, insert a new card immediately after the continuation card of the JOB card. Beginning in column 1 of this inserted blank card, enter
/*JOBPARM LINES=100
For jobs 1 through 5, insert another new card immediately after the card just inserted (the JOBPARM card). Beginning in column 1 of this inserted blank card, enter
//JOBCAT DD DSN=SYS1.VSAM.MASTER.CATALOG,DISP=SHR
In job 6, locate STEPY (which is the third from the final step in the deck) and change the program executed from IDCAMS to IEFBR14:
//STEPY EXEC PGM=IEFBR14,REGION=512K
Throughout the jobstreams, whereever there is an EXPDT=99350 parameter on a DD statement, change it to EXPDT=00000.
Depending upon your personal preference, you may add a job terminator statement (//) at the end of the generated deck.
The reasons for these changes are:
the TYPRUN=HOLD on jobs 1 through 6 prevent the jobs from executing until specifically released by you. Each job in the Stage 2 deck must be executed sequentially, one after the other. You must verify that all steps of each job have executed correctly before releasing the next job to run.
On slower computer systems, the lack of TIME=1439 may cause one or more of the jobs to abnormally terminate because the default job time limit is reached before the job has had time to complete. The TIME=1439 eliminates this time restriction.
The JOBPARM card is simply to prevent some warning messages. It eliminates messages displayed on the MVS console by JES2 for jobs which generate very large amounts of printed output. The LINES=100 parameter tells JES2 to expect at least 100,000 lines of output from the job.
The JOBCAT card is required because the datasets the jobs are expecting to find catalogued in the starter system's Master Catalog are in fact catalogued in the User Catalog: SYS1.VSAM.MASTER.CATALOG. Without this card the Starter System, where the jobs will be executing, cannot find the datasets.
STEPY in job 6 exports (deletes from) the User Catalog (in which all the datasets you have been operating on during the System Generation are cataloged) from the Master Catalog of the starter system. This is totally unnecessary for the generated system's correct operation. If you allow this step to run and later need convenient access to the datasets from the starter system, you will have to build and run a job to re-connect the catalog. It is far better to just leave the catalog connected.
The EXPDT=99350, which was generated by the Stage 1 processing, creates all libraries on the target system to be un-expired until the date 99350 (way in the future at the time MVS 3.8 was in commercial use). There is nothing intrinsically wrong with this, except that you will have to reply to about 200 prompts to allow the Stage 2 jobs to write into the datasets as they build the system. Changing the EXPDT to a value of 00000 eliminates these prompts and will make life much simpler for you.
Since there has been some confusion
about these instructions to those unfamiliar with Job Control Language, I have
added a "before" and "after" comparison viewable at: pch013.txt - stage2.jcl.pdf. If you
are unfamiliar with Job Control Language, I strongly recommend that you locate a
good reference/textbook, since a thorough understanding of JCL is required to
successfully utilize MVS. My recommendation would be System/370 Job
Control Language by Gary DeWard Brown, preferably an edition prior to the
fourth, which concentrates far too much on modern facilities and drops
discussion of some of the features which are required on MVS 3.8j. You can
find this and other JCL books at larger university libraries. You local
library may be able to acquire books for you through WorldCat/Interlibrary
Loan. You might
also check for used copies reasonably priced at ABE
books.
I have also written a simple awk script that will make these changes - stage2.awk
- and I recently translated it into a REXX script - stage2.rexx - both are
included in the installmvs.rar archive. If you intend to do anything with MVS after your system is generated
you will need to understand JCL and I recommend you start learning
by making the changes in a text editor.
To use the awk script: gawk -f stage2.awk pch013.txt > stage2.jcl.
To use the REXX script: stage2.rexx.
It is only necessary to execute one of the scripts; either will produce the same
results.
Stage 2
Submit the Stage 2 jobstreams to the reader. On the command line in the console window where Hercules was started, type the command devinit 12 stage2.jcl eof and press Enter.
The jobs will be read in by the Starter System and placed on hold:
To release the first job for processing, on the MVS Starter System console (in the telnet client window) type the JES2 command: $a'sysgen1' and press Enter.
After each job is completed, you must check the output to ensure that there are no significant errors and the completion codes received are those expected. Then release the next job in sequence - sysgen2, sysgen3, sysgen4, sysgen5, and sysgen6 - using the $a command shown above. Since the output from one or more steps in each job is usually required as input in the succeeding job, it is imperative that only one job be processed at a time, that all steps of each job are run, and that there are no unexpected completion codes.
SYSGEN1 takes 0.25 minute to run. The expected completion codes are:
SYSGEN2 takes 0.14 minute to run. The expected completion codes are:
SYSGEN3 takes 0.01 minute to run. The expected completion codes are:
SYSGEN4 takes 0.08 minute to run. The expected completion codes are:
SYSGEN5 takes 0.26 minute to run. The expected completion codes are:
SYSGEN6 takes 0.01 minute to run. The expected completion codes are:
With the exception of STEPZ1 in SYSGEN6, all of the 0004 completion codes indicate warning messages. These are expected warnings, which if you investigate the jobstreams (and printed output) you will see are noted in comments in the Linkage Editor control statements for each of the jobs receiving a 0004 return code. STEPZ1 is attempting to delete a member from a dataset that doesn't exist and therefore receives the 0008 completion code.
When the second step of SYSGEN5 executes you will see a message on the console similar to:
+IFC001I D=3350 N=0B F=00010001 L=00010018 S=0001000102 DIP COMPLETE
which is issued when SYS1.LOGREC is initialized. This does not indicate an error has occurred.
JES2 Generation SYSGEN02
During SMP, the elements of JES2 are loaded into libraries, but it is necessary to use the link editor to build the JES2 load modules. Also, the parameters required for JES2 operation need to be set up in SYS1.PARMLIB and a procedure to execute JES2 must be created in SYS1.PROCLIB.
The jobstream to link JES2 is included in the Base Program Directory document.
Volker Bandke posted a combined jobstream to the Hercules MVS group that includes the two link steps for JES2 from this document, and also sets up both the parmlib and proclib members. Over time I have incorporated changes suggested on the Hercules MVS discussion group into the options included in the SYS1.PARMLIB member; the result is SYSGEN04 (contained in file sysgen02.jcl in the jcl directory).
Tommy Sprinkle has made available the JES2 parameters (and other SYS1.PARMLIB members) he used in a production system. For more information and to download a copy of his parameters, see http://www.tommysprinkle.com/mvs/parmlib.html. If you decide to change some of the parameters for your system his information will be extremely helpful. You might also acquire a copy of the manual SC23-0046, System Programming Library: JES2 Installation, Initialization, and Tuning from a source such as http://bitsavers.trailing-edge.com/.
On the command line in the console window where Hercules was started, type the command devinit 12 jcl/sysgen02.jcl eof and press Enter.
SYSGEN02 takes 0.01 minute to run. The expected completion codes are:
Completing the Target System
Although technically the process of System Generation is complete at this point, the generated system is not really ready to run until a few more basic enhancements are applied.
SYSGEN03
The jobstream SYSGEN03 (contained in file sysgen03.jcl in the jcl directory) performs the following tasks:
- creates member IEASYS00 in SYS1.PARMLIB,
During IPL, the values coded in IEASYS00 are used to customize the MVS 3.8j environment. Several of the parameters contained in IEASYS00 are simply pointers to other members of SYS1.PARMLIB. Many of the parameters may be overridden at IPL time, but the IPL process is greatly simplified if the most frequently desired settings are coded in this member.
- creates member IEAAPFM00 in SYS1.PARMLIB,
IEAAPF00 specifies the load module libraries from which authorized programs may be executed.
- creates member SMFPRM00 in SYS1.PARMLIB,
SMFPRM00 contains parameters related to System Management Facility, which collects and records information about MVS and the programs that are executed under its control.
- creates member IEALOD00 in SYS1.PARMLIB,
IEALOD00 specifies load modules that contain part of the operating code for MVS which are to be loaded and fixed in real storage. These modules are so frequently executed, fixing them in storage can improve the performance of the system.
- creates COMMND00 in SYS1.PARMLIB,
COMMND00 contains operator commands which are to be executed upon the completion of the IPL.
- creates SETPFK00 in SYS1.PARMLIB,
SETPFK00 contains settings for the console Program Function Keys. Commands associated with the PFKeys here may be executed simply by pressing the associated PFK on the MVS console.
- creates LNKLST00 in SYS1.PARMLIB,
LNKLST00 contains load module libraries which are to be automatically searched for load modules executed in batch or under TSO.
- creates VATLST00 in SYS1.PARMLIB,
VATLST00 specifies the Volume Attributes to be associated with all regularly used DASD volumes.
- creates PARMTZ in SYS1.PARMLIB,
PARMTZ specifies the offset from GMT to establish local time. I have set mine up for the Central Time zone in the United States; you may wish to modify this for your geographic location before you submit this jobstream.
- deletes SYS2.LOCAL.LPALIB
This library was created by SYSGEN00 to provide local SVC modules during System Generation. It is no longer needed, so this is a good place to delete it.
- allocates and catalogs SYS2.LINKLIB,
SYS1.LINKLIB is the main load module library and is created during System Generation. However, it is not a good idea to add your own load modules to that library, so we create SYS2.LINKLIB to have a place set up to receive any programs you write locally.
- allocates and catalogs SYS2.PROCLIB,
Likewise, SYS1.PROCLIB is the system's catalogued procedure library, but it is not a good idea to add your own catalogued procedures to that library, so we create SYS2.PROCLIB for local use.
- allocates and catalogs SYS2.CMDLIB,
As SYS1.LINKLIB is to batch load modules, SYS1.CMDLIB is to TSO load modules. SYS2.CMDLIB is created to be a repository for your local TSO load modules.
- allocates and catalogs SYS2.HELP,
And SYS2.HELP corresponds to SYS1.HELP - SYS2.HELP will contain 'help' (syntax and operand usage instructions) for your local TSO load modules.
- creates member JES2 in SYS1.PROCLIB,
Although a basic JES2 catalogued procedure member was created by SYSGEN02, a more customized one is created here, specifically to utilize/incorporate the SYS2.PROCLIB allocated (three bullets) above.
- creates member CLEARDMP in SYS2.PROCLIB,
There are three dump datasets allocated on MVSRES to receive system dumps when a catastrophic error occurs. If all three of these fill up (are used) the system will not be able to be started, so you need to be able to clear these datasets as they are used. This procedure, which may be started from the console, accomplishes that.
- creates member CLEARERP in SYS2.PROCLIB,
When hardware errors occur, an entry is made in SYS1.LOGREC (the environmental error recorder dataset). This dataset will hold a finite number of entries. As it approaches maximum capacity, a message will be displayed on the console to allow you to save the contents (if desired) and then clear the dataset. This procedure, which may be started from the console, clears SYS1.LOGREC.
- creates member COMPRESS in SYS2.PROCLIB,
When library (Partitioned) datasets receive many updates, they frequently become in need of reorganization. If left to the extreme, they may exhaust all of their extents. This procedure, which may be started from the console, can be used to compress any partitioned dataset, reclaiming unused extents.
- creates members SMPASM, SMPASML, SMPAPP, and SMPREC in SYS2.PROCLIB,
These catalogued procedures are used to receive, assemble, assemble/link, and apply user modifications.
- allocates and catalogs SYS1.UMODMAC, SYS1.UMODCNTL, SYS1.UMODSRC, SYS1,UMODOBJ, and SYS1.UMODLIB,
These datasets are used to hold user modifications.
- allocates and catalogs SYS1.CDS, SYS1.CRQ, and SYS1.SMPCDS,
These datasets are used to record and track modifications to the target system.
- initializes SMP for target system's environment.
- allocates and catalogs SYS2.CONTROL,
Some catalogued procedures need control cards, and, since control cards cannot be included in catalogued procedures, we create this library to hold those type of datasets.
- adds CLS TSO command and help text for the command,
CLS is a short program (from CBT 430, file #300) that simply clears the screen for a TSO user. It is compiled into SYS2.CMDLIB with the HELP text placed into SYS2.HELP.
- adds SETPFKEY batch load module and an execution procedure,
This program (from CBT 249, file #295) equates operator console commands to the Program Function Keys on MVS consoles. It is compiled into SYS2.LINKLIB and a procedure to execute the program is placed into SYS2.PROCLIB. In a previous job there was a START command set up for this program in COMMND00 and PFKey definitions were placed into SYS1.PARMLIB(SETPFK00).
- adds ZTIMER batch load module, execution procedure, and parameter member,
This program may be used to display reminders or execute MVS operator commands on a scheduled or periodic basis. It is compiled into SYS2.LINKLIB and a procedure to execute the program is placed into SYS2.PROCLIB. In a previous job there was a START command set up for this program in COMMND00. A set of commands is placed into SYS2.CONTROL(ZTIMER) for use by the STARTed process to periodically clear JES2 queues of non-processed output.
- adds CLIP batch load module and execution procedure,
This program is used from the console to relabel (clip) offline DASD volumes. It is compiled into SYS2.LINKLIB and a procedure to execute the program is placed into SYS2.PROCLIB.
In several cases, the members to be created already exist; in these cases a backup is made of the original member, preserving the existing contents.
On the command line in the console window where Hercules was started, type the command devinit 12 jcl/sysgen03.jcl eof and press Enter.
One change is made by this job to the Starter System - the SMPASM/SMPASML/SMPAPP/SMPREC procedures that are placed in the target system are also copied into the Starter System. That is because they are used several times as we continue to set up the target system. As SYS1.PROCLIB on the Starter System is protected by an expiration date, you will receive message IEC507D when this update is attempted:
Type r 11,U to allow the update.
Like the previous jobs, SYSGEN03 submits a continuation job with the same name. This is because some of the latter tasks that need to be done have as prerequisites some of the earlier tasks listed above and the job would receive JCL errors and fail to execute if the job were submitted as a single jobstream..
SYSGEN03 takes 0.64 minutes to run, which is the sum of the times for both the primary job and the continuation job which has the same name. The expected completion codes are:
SYSGEN04
The jobstream SYSGEN04 (contained in file sysgen04.jcl in the jcl directory) performs the following tasks:
- creates member IKJTSO00 in SYS1.PARMLIB,
This member specifies parameters which control the execution of TSO.
- creates member IKJACCNT in SYS1.PROCLIB,
This member specifies parameters which define the individual TSO Users' address spaces.
- creates member NET in SYS1.PROCLIB,
This procedure is executed to start VTAM.
- creates member TSO in SYS1.PROCLIB,
This procedure is executed to start TSO.
- allocates and catalogues SYS1.VTAMLST,
This library will contain specifications for VTAM.
- creates member ATCSTR00 in SYS1.VTAMLST,
This member specifies VTAM parameters.
- creates member ATCCON00 in SYS1.VTAMLST,
This members specifies the tables to VTAM for TSO applications and local 3270 terminals.
- creates member APPLTSO in SYS1.VTAMLST,
This member specifies the logon table for all local 3270 terminals. (8 defined initially)
- creates member LCL400 in SYS1.VTAMLST,
This member specifies characteristics for all local 3270 terminals. (8 defined initially)
- allocates and catalogues SYS1.VTAMSRC,
This library will contain LOGON tables for VTAM.
- creates member LOGTAB01 in SYS1.VTAMSRC,
This member specifies the LOGON interpret table for VTAM.
- creates member LOGMOD01 in SYS1.VTAMSRC,
This member specifies the characteristics for all variants of local 3270 terminals.
- allocates and catalogues SYS1.CMDPROC,
This library will contain TSO command procedures (CLISTs) available to all TSO users.
- creates member STDLOGON in SYS1.CMDPROC,
Default TSO logon message.
- creates member USRLOGON in SYS1.CMDPROC,
Default TSO logon procedure.
- assembles/links LOGTAB01 and LOGMOD01,
- creates a customized network solicitor module (NETSOL) which is displayed to log onto TSO.
Almost all of the material in this jobstream was used as supplied by Jim Morrison with his 3375/3380/3390 modifications published in April, 2002.
On the command line in the console window where Hercules was started, type the command devinit 12 jcl/sysgen04.jcl eof and press Enter.
SYSGEN04 takes 0.02 minutes to run. The expected completion codes are:
SYSGEN05
Every MVS system I have ever worked on employed an SMF exit to report resource utilization statistics at the end of each job step. Although the information is similar from installation to installation, most installations had some custom modifications applied to their report. The load module called by this exit is IEFACTRT, and I have another page on this site where I have collected several versions of this exit. The first task of SYSGEN05 is to install the version that I use on my own system. Perhaps the most useful feature of this exit is that it displays the step completion codes on the MVS console, allowing you to know if there is a problem with a job without opening and searching through the printed output. If you code the NOTIFY= parameter on your JOB card, it will also send the information to your TSO User ID.
SMF (System Management Facility) collects information constantly (job start, step start, dataset open, dataset close, step end, job end, etc.) as MVS manages your hardware and executes user programs. The amount of information collected will vary depending upon options set up in SYS1.PARMLIB(SMFPRM00). The parameters may be overridden by the operator during IPL or changes may be permanently made by editing this member. The information collected is stored in two datasets created during System Generation - SYS1.MANX and SYS1.MANY. One of the datasets is the active dataset, into which new records are written. When this dataset becomes filled, SMF will automatically switch to the other dataset and issue a message to the MVS console to indicate action needs to be taken to preserve the data in the filled dataset. At the very least, you must clear the records from the filled dataset so that when SMF fills the alternate dataset, it will be able to switch back to the original dataset to continue recording.
As the information collected can sometimes provide interesting insight into MVS operation, I set up a system to retain the latest five sets of SMF data collected. I keep the records in a Generation Data Group on the SMP000 volume. To facilitate the transfer of the records, as well as clearing the SMF datasets after the transfer is complete, I wrote a procedure that is placed in SYS1.PROCLIB. Also, there is a user exit available from the CBT tape that can automate the entire process. For complete information about my Generation Data Group setup, my procedure, and the user exit, you can read IEFU29 here on my site. But for convenience, I collected the required jobstreams and that is the second part of SYSGEN05.
The jobstream SYSGEN05 (contained in file sysgen05.jcl in the jcl directory) installs both of these exits/procedures.
On the command line in the console window where Hercules was started, type the command devinit 12 jcl/sysgen05.jcl eof and press Enter.
SYSGEN05 takes 0.08 minutes to run. The expected completion codes are:
SYSGEN06
During the fourteen years I have been involved with Hercules, and running MVS 3.8j under Hercules, there have been a number of user modifications proposed, submitted, and discussed in the Hercules discussion groups. There are twenty-five user modifications that I regard as pretty mandatory to the orderly and 'user friendly' operation of MVS 3.8j. I have gathered those modifications into a single jobstream - SYSGEN06 (contained in file sysgen06.jcl in the jcl directory).
The twenty-five user modifications included are:
- USERMOD TMVS804 (source: Kevin Leonard)
The System Generation places a START command in MSTRJCL to automatically start JES2 after IPL. That is not always a good place to autostart JES2, so this modification removes the START command (actually leaves it as a comment). Following the user mod there are a couple of steps included to place the START command for JES2 in the COMMND00 member of SYS1.PARMLIB.
- USERMOD AY12275 (source: Kevin Leonard)
SMF accounting statistics are incorrect, as the field TCTRSZ reflects the size of the private storage area, rather than the region requested. This modification corrects the contents of this field.
- USERMOD TTS0801 (source: Kevin Leonard)
Eliminates message IKT012D after TSO is shut down by the operator. This is not a useful message, at least not in our Hercules environment, so eliminating it simplifies the operation of MVS.
- AZ58122 (source: Peter van der Woude)
Eliminates an error message issued to the console whenever a TSO User logs off.
- USERMOD SLB0002 (source: Shelby Beach)
The JOB and EXEC card REGION parameters allow the specification of size in Kilobytes (K). Later version of MVS allowed the specification in Megabytes (M). This modification adds the flexibility of using M to MVS 3.8j
- USERMOD SYZM001 (source: Brian Westerman)
This modification suppresses the inclusion of CN(00) on messages when they originate from a system task. This greatly improves the appearance of JES2 NOTIFY messages.
- USERMOD ZUM0007 (source: Michael Koehne)
Patches the two TSO modules which display incorrect century when TSO is executed under MVS with the system date set to years beyond 1999.
- USERMOD ZUM0001 (source: Volker Bandke)
Adds TSO commands to the TSO authorization table IKJEFTE2.
- USERMOD ZP60001 (source: Greg Price)
Adds a WTO exit to start TSO after VTAM is initialized.
- USERMOD ZP60002 (source: Greg Price)
Modifies TSO TEST to not stop execution after encountering an invalid opcode.
- USERMOD ZP60003 (source: Greg Price)
Modifies IFOX00 to accept blank statements.
- USERMOD ZP60004 (source: Greg Price)
Modification to display action console messages in high intensity so they are more obvious.
- USERMOD ZP60005 (source: Greg Price)
Modifies IOS to always maintain channel and device i/o counts.
- USERMOD ZP60006 (source: Greg Price)
Modifies dataset deallocation to show excp counts on deallocation messages.
- USERMOD ZP60007 (source: Greg Price)
Modifies TSO/VTAM to allow option to be traced by GTF.
- USERMOD ZP60008 (source: Greg Price)
Adds EWA and WSF support for local non-SNA 3270.
- USERMOD ZP60009 (source: Greg Price)
Adds NOEDIT support for TPUT and TGET to TSO/VTAM.
- USERMOD ZP60012 (source: Greg Price)
Adds reporting of interrupt code in event of an ABEND in a TSO session.
- USERMOD ZP60014 (source: Greg Price)
Adds CLIST control variable and built-in function extensions.
- USERMOD ZP60015 (source: Greg Price)
- USERMOD ZP60016 (source: Greg Price)
These two extend the JES2 job search for the STATUS TSO command.
- USERMOD ZP60019 (source: Greg Price)
Causes recording of CPU time when TIME=1440 coded in JCL.
- USERMOD ZP60026 (source: Greg Price)
Adds REUSE operand to the TSO ALLOCATE command.
- USERMOD ZP60032 (source: Greg Price)
Allows GTTERM macro to report the terminal name.
- USERMOD WM00017 (source unknown)
Adds two JES2 commands - $U and $DP.
The name Kevin Leonard appears several times above, so obviously I hold his modifications in high regard. He provides many useful modifications at his site: http://www.j76.org/hercules/ for MVS 3.8, MVT 21.8f, HASP V4, and ASP V3.2 and makes frequent contributions to the Hercules discussion groups.
Greg Price is also a frequent contributor to the Hercules/MVS 3.8j community. His website is also a wonderful place to have bookmarked: http://www.prycroft6.com.au/.
When all twenty-five of these usermods were combined into a single jobstream, they were a bit much for the small JES2 spool of the Starter System. Not to worry, I have divided them into five separate jobs, all contained in the same file. When they are submitted, they will execute serially and everything works out just fine.
On the command line in the console window where Hercules was started, type the command devinit 12 jcl/sysgen06.jcl eof and press Enter.
SYSGEN06 (all five jobs totalled) takes 1.24 minutes to run. The expected completion codes are:
The three steps which receive a return code of 0004 all have link-editor subordinate tasks which have unresolved external links. This is expected and acceptable for these three cases.
FDZ1D02
The final jobstream we will execute to complete the creation of the target MVS 3.8j system is FDZ1D02 (contained in file fdz1d02.jcl in the jcl directory).
The reason for the strange job name is that this is in fact a product element which we did not accept with all the other elements on the product tape. Why not, you may ask. The reason is that FDZ1D02 is Release 13.0 of the Device Support Facilities, or as it is more commonly known, ICKDSF, the DASD initialization program. The version we did install, way back when we built the Distribution Libraries is version 6.
Actually I can think of a couple of questions you may have at this point - Why install version 6 when we have version 13? Why do we need version 13 now? Let's take the last first.
Why do we need version 13 now? If you want to utilize 3375/3380/3390 DASD, you need version 13 to initialize them. Version 6 of ICKDSF knows nothing about device types later than 3350. Of course, you could still utilize the DASDLOAD utility that is supplied with Hercules to create perfectly usable 3375/3380/3390 DASD volumes outside of the MVS environment. But I like to find solutions that allow me to utilize MVS to do everything I need to do related to the operation of the system as it was intended.
Why install version 6 when we have version 13? Well, version 13 has a problem initializing 3350 DASD. So we need both versions of the utility to be able to accomplish everything we might want to accomplish.
I put together FDZ1D02 using the distribution libraries. In fact, the jobstream restores the TLIBs from the product tape, extracts the JCL to link-edit the utility, builds a secondary jobstream and submits it through the Internal Reader to complete the installation. The load module for the utility is placed into SYS1.LINKLIB with the name ICKDSF13, so that it does not replace the original load module which has the name ICKDSF.
This places the responsibility upon you to utilize the correct load module when you are initializing 3375/3380/3390 DASD or any of the earlier models. But I will elaborate on that later on, when we are creating some additional empty DASD volumes to use.
On the command line in the console window where Hercules was started, type the command devinit 12 jcl/fdz1d02.jcl eof and press Enter.
This job will require the product tape, so you will see a IEF238D message on the console (telnet client window):
On the command line in the window where Hercules was started, type the command devinit 170 tape/product.het and press Enter.
On the Starter System console (telnet client window), type r 12,170 and press Enter. Remember, your response number may not be the same as the one seen here in the screen capture from my system.
FDZ1D02 takes 0.34 minutes to run. The expected completion codes are:
Again, there are two jobs that execute with the name FDZ1D02: the first builds the jobstream for the second and submits it, so there are two completely distinct jobs, each with the same name. The first three steps are from the first job and the last two steps are from the second job. All should receive a completion code of 0000, as shown.
Shut Down the Starter System
We have now completed the System Generation and tailoring of the system to the point that it will IPL, so it is time to shut down the Starter System.
It would be a great time to take another snapshot backup. There are now nine DASD volumes in the dasd directory. After you have shut down MVS and Hercules, simply make a copy of them with your favorite archive program - WinZip, PKZIP, tar - or copy them onto a CD-rom blank. Then if you encounter a catastrophic error later, it is simple to come back to this point by restoring your backup copy.
In the telnet client window, type the command $p jes2 and press ENTER. This command instructs JES2 to shut down normally. The following messages will be displayed:
which are issued by JES2 and MVS as JES2 terminates. In the telnet client window, type the command z eod and press ENTER.
This command instructs the MVS operating system to shut down normally. The following message will be displayed:
which indicates the MVS system has reached a point where power down is possible. Note that MVS is still running and additional operator commands might be entered and jobs submitted. But, the object of the "z eod" command is to close all the system files and prepare for an orderly shutdown. In the telnet client window type the command quiesce and press ENTER.
This command instructs the MVS operating system to write any buffers to the DASD devices. This ensures that when you shut down Hercules any information held in memory by MVS is written to the DASD images.
On the command line in the console window where Hercules was started, type the command quit and press ENTER.
Hercules will close all the files for the emulated mainframe devices and terminate. You may close your telnet client.
I strongly suggest that you save the SYSOUT listings from this process, which you have been examining to verify completion codes for each step.
When you proceed with the next step and restart Hercules, the contents of this file will be overwritten. If there were errors that you did not catch
that prevent a successful IPL of the newly built MVS system, having the output from the System Generation process will greatly assist you in
determining the problem and reaching a successful resolution. Simply use the command appropriate for your host Operating System to rename
the file 'prt00e.txt' to some other name, such as 'SystemGenerationSYSOUT.txt'.
The next step is to IPL the newly built MVS system for the first time and do some tailoring that may only be done on the system as it is executing. So, when you are ready, proceed to the next step - Customizing Your New MVS 3.8 System.
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:
This page was last updated on September 22, 2017 .