Installing MVS 3.8
IPL the Newly Created MVS 3.8
To recap prior steps, you should already have downloaded/installed on your computer -
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 steps of this set of instructions. Fifteen files are required for this step (I only include one each of the create.dasd and condcode scripts in this count):
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.78 minutes], so I have added 20 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 17 minutes and 27 seconds; however, I did not complete the final TSO steps of entering and compiling a COBOL program..
You are ready to IPL the newly generated MVS 3.8 system for the first time, and this time you will be using a very different configuration, because we are leaving the MVS Starter System behind and will be using your newly built MVS 3.8j system. The hardware environment defined in the Hercules' configuration file - mvs.cnf - is:
This configuration matches the devices specified in the Stage 1 deck of the System Generation. There are a great many more device addresses generated into the system for which this Hercules configuration file has not provided attached emulated devices.
The reason you specify many more device addresses during the System Generation process is that it takes a System Generation to add new devices, and you should always minimize the need for doing System Generations, even the relatively simpler IOGEN, by adding all the device types, and device addresses, that you anticipate you may need for expansion.
If you want a reference for all the devices (and device addresses) generated, it is available at http://www.jaymoseley.com/hercules/downloads/pdf/mvs3.8j hardware list.pdf This reference lists all devices by type, all devices by hardware address, and all devices by generic device name.
The configuration file also contains an entry for the alternate console (at device address x'009'), but it is commented out. In a real hardware environment you needed an alternate console defined to be prepared for a failure of the hardware attached for the master console. There is little chance of a 'hardware' failure that would require the use of the alternate console and activating it creates the requirement that a tn3270 client be attached and monitored to ensure that there are no pending messages that might 'hang' the system. So it is simply easier to leave the alternate console device commented out.
Do not comment out the hardcopy console in the configuration file (1403 printer at address x'015'). The MVS system will complain at IPL if this device is not available; besides, you need this in case you want to research a problem by looking at the information printed on the master console, which is captured for you in the host operating system file mvslog.txt.
IPL the MVS System
Open a console window (Linux) or a Command Prompt window (Windows) and start hercules from the mvs directory:
In another window, start a tn3270 client and connect to localhost at port 3270. Note: You must use a tn3270 client for the generated MVS 3.8j console and not a telnet client as we have been using for the starter system console.
In the configuration file, I specify console as the Group name (also known as the LUname) for the console 3277 devices and tso as the Group name for 3277 devices that will be used for TSO. If your tn3270 client doesn't allow you to specify the LUname, you may edit the configuration file to remove the Group names beside the 3277 device definitions. Without the Group names, the tn3270 client session(s) will attach to the 3270 devices defined in the configuration file in ascending address order - x'010', x'400', x'401', etc.
Your tn3270 client screen for the MVS master console should display an identification screen indicating it has connected to Hercules:
Notice that the Device number field shows a value of 0010, which indicates that this tn3270 client session is correctly connected to address x'010', the 3277 designated as the master console.
IPL from the device at address x'150' (the 3350 DASD containing the MVS System Residence volume - dasd/mvsres.3350). In the Hercules command window, type the command ipl 0150 and press ENTER. On the MVS console (the tn3270 client window), you should see:
Since this is the first time the newly generated system has been IPLed, the Link Pack Area that is kept in the paging files must be built. On the MVS console (the tn3270 client window) type r 0,clpa and press ENTER. On subsequent IPLs, unless there is a specific reason you need to rebuild the LPA, you may just press ENTER at this prompt. There will be some messages issued as the IEAPAK00 member from SYS1.PARMLIB is processed:
These are informational messages, indicating that some modules specified in IEAPAK00 have not been loaded. The modules are not required for the operation of the system, so the messages are not a concern.
When all of the parameters specified by member IEASYS00 (in SYS1.PARMLIB) and the subordinate members pointed to from IEASYS00 are processed, you will receive two messages that require an operator response:
The first message (IFB010D), requesting a reason code for the IPL, should be responded to by typing r 0,u and pressing Enter. This prompt allows for entries to be made in the Environmental Error Recording log in the case that hardware errors were the reason for the IPL.
You have seen the second message ($HASP426) each time the MVS Starter System was IPLed; this is a prompt from JES2 to allow you to specify start-up parameters. Since this is the first time this JES2 has been started on this MVS system, you should type r 1,format,noreq and press Enter to instruct JES2 to format the queues on the SPOOL1 volume and then start operation without waiting for requests. JES2 will next issue an error message ($HASP479) requiring a response:
This message occurs because the Checkpoint dataset has never been formatted. You should type r 2,y and press Enter. A second error message ($HASP436) will be displayed by JES2 requiring a response:
You should type r 3,y and press Enter. JES2 formats the spool and processes the automatic commands in SYS1.PARMLIB(JES2PARM).
Your tn3270 client screen will stop updating and appear to be hung:
Notice the message at the lower right of the screen: IEE159E MESSAGE WAITING.
Unlike the line oriented display of the telnet client used with the starter system, the tn3270 client and MVS 3.8j present a console screen divided into two areas. The top area of the screen is where MVS displays messages to the operator, and the bottom area (where the cursor is positioned in the screen capture above) is where input is typed by the operator to enter commands and responses to MVS. With the default console display options in effect when the system first IPLs, if the upper message output area fills up, MVS will not display any new messages until a command is entered by the operator explicitly clearing, or rolling off, the old messages to make room for new ones. By changing the message display options, you can allow MVS to automatically roll off old messages when the output area gets filled.
Fortunately we have already set up a program to define the Program Function Keys for the console, so we have a PFKey set up to issue the command. In the tn3270 client window, press Program Function Key 12. Depending upon your tn3270 client, you may need to first display a panel that will allow you to select from keys that are not frequently used. The command that will be entered when PFK12 is pressed is:
You can see why it is useful to have a PFKey that will enter this command, rather than having to remember and type this long string every time you IPL.
When the console display mode is changed to automatically Roll and Delete messages not requiring responses, MVS will display message IEE163I (below the input area of the console screen on the lower left) indicating this status:
You will have to press PFKey 12 to issue the K S... command after each IPL to set up the messages not requiring attention to roll of the screen. If you don't set the messages to roll off automatically, as soon as the screen fills (and it will do that very quickly), you will not be able to see messages that are awaiting action from you and your system will STOP and WAIT for you, but you won't know why.
You can display the settings for all twelve of the PFKeys for the console by pressing PFK1 in the telnet client window. The commands associated with the PFKeys is set by the member SETPFK00 in SYS1.PARMLIB; you may edit this member to set up additional commands and they will be in effect after the next IPL.
There is an output only console generated in the system at address x'015', so all messages written to the console are written by Hercules to the host Operating System file mvslog.txt (in the mvs directory). So you will always be able to view messages, even after they are rolled off the tn3270 window.
A note about Alternate Console: If you activate the alternate console at device address x'009' (by un-commenting the line defining it in the Hercule configuration line), you will need to set Roll Delete mode on that console also. If you allow messages to back up on any console by not deleting them, essential System Resources will eventually be depleted by the pending messages and the system will stop.
At this time the IPL is complete and MVS is ready to process jobs and respond to operator commands.
There are quite a few MVS operator commands and JES2 commands that you will need to be familiar with to successfully utilize MVS. Volker Bandke has put together a list of MVS operator and JES2 commands at http://www.bsp-gmbh.com/hercules/oscmds.html.
Tommy Sprinkle has a comprehensive reference of JES2 commands available at http://www.tommysprinkle.com/mvs/jes2cmds/index.htm.
Bob Hansen provides a summary of MVS operator commands at http://hansen-family.com/mvs/MVS Commands.htm.
I have also created a document containing a subset of JES2 commands that is available at http://www.jaymoseley.com/downloads/pdf/JES2 Command Subset pdf. Note that I am calling this a Subset, because I have only included the JES2 commands that I think most useful to you under MVS 3.8j and I have even omitted some operands that will only be needed for RJE, shared spool, etc.
Add Language Compilers and Tools Volume
MVS 3.8j only includes ASSEMBLER, so you need to add some compilers for languages like ALGOL, COBOL, FORTRAN, RPG, etc. Fortunately I provide a single DASD volume with those compilers, as well as other useful tools, so that all you need to do is download it, define it on the system and the tools are ready to run.
This volume is more than 'nice to have', because some of the additional steps below rely upon some of the tools on that volume.
So download the image from http://www.jaymoseley.com/hercules/downloads/archives/SYSCPK.tar.gz [11.9 mb MD5: b38ac0345f15b0b62ea24306044abd13]. The archive contains a single file, the 3350 DASD volume image. Unpack it and place it in the same directory with your other DASD volume images. The volume still needs to be integrated with your MVS system, but first we need to add a few more empty DASD volumes, so continue with the next section.
Create Additional DASD Volumes
Although we created several DASD volumes as we went through the process of building the Distribution Libraries and completing the System Generation, there is still a need for several more volumes. In fact, you will probably wish to create even more volumes as you use your system. I have a more detailed page about the specifics of creating DASD volumes at: Adding DASD Volumes. That page covers the entire process in detail from creating the volume image on the host operating system, initializing the image for use by MVS, and building VSAM User Catalogs. However, in order to move ahead here, if you will just follow through the simplified steps below, you will have enough DASD space to get a lot done.
First, we will use create.dasd.bat (the same script we have used before) to create eight additional DASD volumes. The volumes we will create are:
In this step you will:
On a Windows system, open a Command Prompt window and type the command:
and press Enter. The script will execute, creating the ten DASD images: The console output of the script on my system is shown below:
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 'user' to create the eight DASD images.
Alternately you may also issue the commands from a console prompt after changing to the dasd directory:
Remember that DASD volumes created by the Hercules dasdinit utility are not yet formatted for use by MVS, so we next need to submit a job to MVS to initialize and format them.
First the new volumes must be identified to Hercules. I have provided a script to do that. In the Hercules command window, type script conf/mvs.script and press Enter:
Submitting Jobstreams from PC to Hercules (via Socket Reader)
If you intend to mainly work from TSO (and RPF or RFE which we will install below), the jobstreams you will be submitting to MVS by way of an emulated card reader will probably be minimal. But for the next few steps we still need to submit jobs through the card reader and I am going to show you a different method than the one we used while we were building the Distribution Libraries and performing the System Generation. We submitted those jobs by using a command at the Hercules command prompt to initialize the emulated card reader to read a file on the host operating system that contained JCL for a jobstream.
The first emulated card reader in the Hercules configuration file (mvs.cnf in the conf directory) is set up to use a socket reader and is monitoring port 3505 for input. There are several methods for sending the contents (JCL statements) of a file on the host operating system to the socket listening on port 3505; these are discussed in the Hercules reference manual - they include a PERL script, HercRdr (available from Fish at his site: http://www.softdevlabs.com/hercgui.html or from the CBT site: http://www.cbttape.org/~fish/hercgui-index.html) or the netcat program. I have included a Windows version of netcat (nc.exe) and a Windows batch script (submit.bat) in the installmvs.rar archive. I believe that a version of netcat should also be included with most LINUX distributions. I will warn you that your anti-virus program on Windows may complain about netcat, because I have received warnings from several anti-virus programs over the years when I have used it and always must set up an exclusion in my current anti-virus program to be able to use it.
In previous years I used SPF/PC to maintain many of my jobstreams and wrote some programs to allow me to more easily manage the jobstreams, as well as submit them directly from SPF/PC. At that time I created a separate page for those, which you may read at Submitting Jobstreams via Socket Reader. But for now we can just use the submit batch script to submit the remaining few jobs we need to finish customizing the system.
To submit a jobstream from a host operating system file to MVS, in a Command Prompt window type the command:
where <filename> is the name of the file, and optionally the directory, which contains the jobstream. The batch file executes netcat with the following options:
to copy the contents of the file, specified as argument 1 to the batch script, to the listening socket at port 3505.
Initialize and Mount New DASD Volumes
I have included a job - MVS00 (contained in file mvs00.jcl in the jcl directory) - which will initialize the eight new DASD volumes and then submit a command to vary the volumes online.
In a Command Prompt window for your host operating system, type the command submit jcl\mvs00.jcl (from the mvs directory) and press Enter:
You will receive a message (ICK003D) asking you to confirm that you want to initialize/label the DASD volume at address x'180':
Respond r 4,U to proceed. You will receive the same message for each volume to be initialized. Respond U to each of the messages.
When all eight of the new volumes are initialized, job MVS00 will submit another job - also named MVS00 - to the internal reader to be run in CLASS S. This job will Vary the now initialized volumes online and issue Mount commands to set the Volume Attribute for each volume appropriately.
A Brief Summary of Job Classes and Print Classes
During the earlier processes when jobs were run that issued console commands it was necessary for you to approve each command. But I set up the CLASS S initiator to execute commands without confirmation. The commands are logged to the hardcopy console, so there is a record if someone takes advantage of this authority. Class S is intended for use only for Systems Programming type jobs, so if this were a real world environment, someone taking advantage of this authority who was not supposed to would quite likely find themselves without a job.
This is a good time to tell you a bit about some of the parameters that have been set up in the system. This section of my website was created with the dual purposes of helping new Hercules/MVS users to rapidly set up a running system, as well as providing information about how the system is set up. To achieve the former, I have set many system parameters for you in the jobs that were executed during the System Generation phase. But those parameters can always be modified, so once you become more familiar with the system, you may change them to better suit how you wish to operate your MVS system.
Much of the operation of MVS is controlled by JES2 and the parameters that affect JES2 are contained in the member JES2PM00 in SYS1.PARMLIB. The three main functions are job entry (readers), job execution (job classes), and output (printers and punches).
There is one Hercules emulated card reader that is controlled by JES2 - the 2540R at address x'00c'. There are other card readers generated into the system and one of those is also defined in the Hercules configuration file - the 2540R at address x'01c'. There are reasons this additional reader is defined, but it is not intended for submitting jobs to JES2, so we will leave that topic until later.
There are two emulated printers controlled by JES2 - the 1403 at address x'00e' and the 3211 at address x'00f'. The 1403 printer defined at address x'015' is a special case as it defined as, and dedicated to the hardcopy log; it is not controlled by JES2. There are other printers generated into the system, but they are not defined in the configuration file; they are simply 'extra' printers.
There is one emulated card punch that is controlled by JES2 - the 2540P at address x'00d'. There are other card punches generated into the system and one of those is also definied in the Hercules configuration file - the 2540P at address x'01d'. Like the additional card reader defined in the configuration file, we will leave that topic until later.
The JES2 controlled card reader is set up as a socket reader, which I have covered above. When a file of JCL is submitted to the reader, it is copied by JES into the job queue. The CLASS= parameter on the JOB card determines the class that the job is intended to be run in.
There are six initiators defined to JES2, three are not active when MVS is IPLed, but three of them are automatically started. The initiators select a job for execution when the CLASS= parameter on the JOB card matches one of the CLASSES the initiator is set to process. Currently the initiators are set to process these classes (listed in order by highest priority first):
Class S is intended for use for System Programming tasks, so some of the control has been loosened on that class, which is why you don't have to 'approve' embedded console commands. It is not a good idea to simply use S for all of your jobs, however, as there are good reasons for those controls being in place.
The two printers controlled by JES2 are set to select non-held printer output in class A (the 1403 at x'00e') and class M (the 3211 at x'00f').
The card punch controlled by JES2 is set to select non-held punch output in class B.
Some of the parameters for JES2 may be changed from the MVS console and the changes will only remain in effect until the next IPL. Some of the parameters must be changed by altering the JES2PM00 member in SYS1.PARMLIB, then stopping and restarting JES2.
If you are interested in getting into the details of JES2 you should obtain JES2 Installation, Initialization, and Tuning manual (SC23-0046) from one of the Internet sources for IBM manuals.
Add New DASD Volumes to the Hercules Configuration File
All of these new volumes, including the compiler/tools volume (SYSCPK.3350, which you downloaded from my site) have already been included in the VATLST00 member of SYS1.PARMLIB, so that next time you IPL the Volume Attribute will be correct and there will be no need to issue Vary or Mount commands.
So, the new volumes are placed online and job MVS00 continues to complete two additional tasks. First it replaces the JES2 member of SYS1.PROCLIB, adding the dataset SYSC.PROCLIB on the SYSCPK volume into the concatenation of PROC libraries. This change will not take effect until JES2 is restarted, but that is not immediately necessary. Second it imports a User Catalog on SYSCPK into the Master Catalog and sets up an Alias so that the datasets on SYSCPK can be accessed.
The output from the job - MVS00 - will be be printed to the emulated Hercules device and the output will be available in the prt00e.txt file in the mvs directory. You may open the file to examine the output with a text editor or viewer, or you may still use condcode.rexx (or condcode.pl) to check the condition codes. You may have also noticed that one of the usermods we applied - the one that installed the IEFACTRT program - is printing step completion codes on the MVS console. The CCI001C messages are from this program and the information they are displaying is:
MVS00 takes 0.49 minutes to run, although the execution time may be reported as longer if you leave the job awaiting for one of the responses from a message on the console.. The expected completion codes are:
The completion codes shown above are from both jobs named MVS00 - the first four steps from the first job and the last two steps from the submitted job of the same name.
Creating User Catalogs
The VSAM Master Catalog resides on MVSRES and its name is SYS1.VSAM.MASTER.CATALOG. When a job attempts to catalog a dataset, if it is unable to find the mechanism to catalog into a User Catalog, it will default to the Master Catalog. You want to avoid that as much as possible ... always is the ultimate goal.
We are going to create a couple of User Catalogs and a fairly large VSAM Data Space, so we will have a place to create some VSAM clusters (user VSAM data) later on.
We just formatted a 3380 - PUB000 - and an even larger 3390 - PUB001. PUB000 will hold TSO User's datasets and PUB001 will be available for both Non-VSAM user datasets as well as sub-allocated VSAM clusters and data objects. We will define a User Catalog - UCPUB000 - that will reside on volume PUB000 and an Alias that will direct MVS to catalog all datasets with a high level qualifier PUB000 into that User Catalog.
We will also define a VSAM Data Space that utilizes half of the PUB001 volume and sub-allocate a User Catalog - UCPUB001 - from that space, and an Alias that will direct MVS to catalog all datasets with a high level qualifier PUB001 into that User Catalog. I have included a batch job - MVS01 (contained in file mvs01.jcl in the jcl directory) - that will do this for you.
The final step of this job sets the update password for the target system's VSAM Master Catalog (SYS1.VSAM.MASTER.CATALOG on MVSRES) to SYSPROG. This will prevent non-system datasets from being easily catalogued by mistake in the Master Catalog. This is a desirable safeguard, because the Master Catalog is defined with a finite and limited capacity so you should not be cataloging non-system datasets in the Master Catalog. In the next section we will be set up Aliases so that all user datasets for each TSO User ID will automatically be catalogued in the correct User Catalog.
In a Command Prompt window for your host operating system, type the command submit jcl\mvs01.jcl (from the mvs directory) and press Enter.
MVS01 executes for 0.01 minute and the expected return code is:
You will probably want to set up additional DASD volumes and User Catalogs. You may use the scripts and batch jobs we have used to create new volumes and User Catalogs here as examples to create as many volumes as you require.
Adding TSO User IDs
The last step before we start TSO is to create some User IDs. The system comes with a default ID - IBMUSER - but it is very limited and is only intended to be used for emergencies. So I have included a batch job - MVS02 (contained in file mvs02.jcl in the jcl directory) - that may be used to create additional IDs for you. Like the jobstream that we used to create the User Catalogs and Aliases, this jobstream may be used as a model to create as many TSO User IDs as you wish to create. It is currently set to create two IDs - HMVS01 and HMVS02.
In a Command Prompt window for your host operating system, type the command submit jcl\mvs02.jcl (from the mvs directory) and press Enter.
Because the last step of the previous job set an update password on the Master Catalog, you will be prompted to supply that password every time a modification of the Master Catalog is attempted:
Type r 12,sysprog and press Enter:
Once you press Enter, what you typed will disappear from the screen, and, since this was a password request, what you typed will be suppressed not only from this tn3270 display, but from the hardcopy log as well. You need to reply to the second message with 13,sysprog and job MVS02 will end.
There are a lot of steps in the batch job MVS02 - 24 steps for each User ID added - although the job takes only 0.36 minute to execute. The expected return codes are:
For each User ID there are four datasets created:
Starting VTAM and TSO
First you will need to start another tn3270 client session and connect to localhost at port 3270. The Group name, or LU name, for this session should be tso. Your newly opened tn3270 client window should should show the Device number field as 0400, indicating that it is connected to the 3277 device defined at address x'0400':
Because we did all the setup for VTAM and TSO near the end of the System Generation process, there is nothing special to do except issue a single start command. On the MVS console (the tn3270 client window), type the command s net and press Enter:
NET is the cataloged procedure to execute VTAM. You may remember that we added a usermod to automatically start TSO as soon as VTAM is initialized, so TSO will be started also. Your TSO screen (the newly started tn3270 client window) should now display the network solicitor screen:
At the Logon prompt, type logon hmvs01 and press Enter:
Several messages will appear briefly on the TSO session (tn3270 client window), and then the screen will be cleared to display this welcome message and the TSO READY prompt:
The MVS console will also issue a message indicating the successful logon of user HMVS01:
Now that we have TSO up and running, we will add a few TSO tools that will make using it more enjoyable.
RPF: Rob Prins' Programming Facility
RPF is very similar to ISPF and, since we do not have ISPF available, you really should install RPF and see if you don't agree that it is a wonderful tool. As I write this, the current version is V1R5M3 (Version 1, Release 5, Modification 3), and Rob has continued to add features so there may be updates available periodically. The distribution is contained on a Hercules' Emulated tape - rpf153.aws - and is available from Rob Prins website [http://members.quicknet.nl/rn.prins/Rpf_En.htm] or from my site rpf153.tgz [1.3 MB MD5: 7867333254f345da1434b4f4211806fe]. (This archive contains both the installation tape and the RPF Users' Guide as a PDF.) Place the AWS tape image into the tape directory.
I have already retrieved the installation jobstream from the tape and modified it for our configuration. In a Command Prompt window for your host operating system, type the command submit jcl\rpf153.jcl (from the mvs directory) and press Enter.
The first step of the job creates an Alias in the User Catalog for PUB000 for the RPF datasets, so you will need to respond to the prompt for the password for the Master Catalog (remember, it is SYSPROG). Then the job will request a tape mount:
In the Hercules command window, type devinit 100 tape/rpf153.aws and press Enter. You have been used to 'mounting' tapes on a drive at address x'170', but in the system we have built, the tape drives that are defined in the Hercules configuration file are at address x'100', x'101', x'102', and x'103'. MVS will rotate through the addresses as tape mounts are requested.
The job to install RPF will execute for less than a minute and the expected completion codes are:
QUEUE - View and Control JES2 Queues
Even though RPF has a utility panel to allow you to view output in the JES2 queue, the old standby QUEUE is nice to have and, since it is what I am used to using, it is what I prefer. A very nicely updated version of QUEUE is available from Greg Price's website: http://www.prycroft6.com.au/vs2sw/index.html#queue. You may remember that we have already installed a number of usermods that Greg Price created and released for MVS 3.8j. I have already retrieved the jobstream from Greg's site and followed his directions to customize it for our configuration.
In a Command Prompt window for your host operating system, type the command submit jcl\queue38j.jcl (from the mvs directory) and press Enter. This job will create a couple of datasets on PUB001 and load the elements of the QUEUE program into them. You will notice that you did not have to enter the Master Catalog password for this job to create datasets. That is because I changed the high level qualifier for the dataset to PUB001, the volume where the dataset will reside, so MVS used the Alias to select the UCPUB001 User Catalog to place the entry for this dataset.
The job - GREGQ - will require less than a minute to execute and the expected completion code is:
I have also customized the installation jobstream - in the C member of PUB001.QUEUE.ASM - to install QUEUE correctly in our configuration. At the TSO READY prompt (where HMV01 is logged on) type submit 'pub001.queue.asm(c)' and press Enter:
Please note the quotes around the dataset and member operand. The system will respond:
The job - GREGQ - will also require less than a minute to execute and the expected completion code is:
Since the jobname was the same as the job to load the dataset, the condcode script picks up the STEP1 from that job as well in the report above. This job will produce quite a few messages on the MVS console, but they are all expected and are just informational.
You should also expect a notification message to be sent to the TSO session when the job completes:
With QUEUE installed, you can view held output in the JES2 queue, and there is quite a bit just from the short time we have had the system active. Here is the display from the HO command:
To view the output for a specific job, place an 'S' in front of the job and press Enter. There are many commands available for QUEUE, and help for them is available by pressing Program Function Key 1 from any QUEUE display. None of the output for these held jobs is required, other than to satisfy your curiosity about the mechanics behind the jobs/started tasks that have been executing, so place 'P' in front of all the jobs and press Enter to purge them from the JES2 queues.
To terminate QUEUE and return to the TSO command prompt, press PFKey 3.
REVIEW - Full Screen Browser and Editor
Even though RPF is great for editing files and provides many great tools, there are some tasks that are even easier using REVIEW, another product from Greg Price. It is on the same page as QUEUE at Greg's site, in fact, just below the section on QUEUE at http://www.prycroft6.com.au/vs2sw/index.html#review.
As with QUEUE, I have retrieved the latest version from Greg's site (at the time I write this, version 45.3). If you want to update to a later version at any time, retrieve the archive from Greg's site and extract the load modules (LOAD file) and help members (HELP file) and place them into your jcl directory.
Now you will see the purpose for the second card reader on our system that is not managed by JES2. In the Hercules command window, type devinit 01c jcl/LOAD ebcdic and press Enter. The last word in the command - ebcdic - tells Hercules that the contents of this file are not to be translated before processing them and passing them to MVS.
In a Command Prompt window for your host operating system, type the command submit jcl\review1.jcl (from the mvs directory) and press Enter. This job will receive the load modules for REVIEW and place them in SYS2.CMDLIB.
In the Hercules command window, type devinit 01c jcl/HELP ebcdic and press Enter.
In a Command Prompt window for your host operating system, type the command submit jcl\review2.jcl (from the mvs directory) and press Enter. This job will receive the help members for REVIEW and place them in SYS2.HELP.
The expected completion codes for both steps of each of the jobs is 0000. I deliberately left the output as HELD, so if you want to check the codes, start QUEUE by typing q status review at the TSO READY prompt.
Type S in front of each job in turn to browse the output. When you are finished, use P to purge the output from the JES2 queue.
To learn more about using REVIEW and its companion program RFE (Review Front End), at the TSO READY prompt type HELP REVIEW or HELP RFE and press ENTER.
DATE TSO Command
As I was adding TSO Command processors from the CBT tape to my system, I came across one to display the system date and time on the TSO User's terminal. Since it wasn't set up to handle dates with four digit years, I wanted to update that. Then I decided to do a complete rewrite using my own date routines so that I could have a more elaborate output. It now displays an extremely verbose date and the system time:
The jobstream to assemble and link-edit the DATE TSO Command is date.jcl (in the jcl directory). In a Command Prompt window for your host operating system, type the command submit jcl\date.jcl (from the mvs directory) and press Enter. It will also install a simple help text in SYS2.HELP.
That is pretty much up to you, since you now have your own private mainframe. But really quickly, as a last step, we can go through the procedure to enter, compile, and execute a COBOL program.
At the TSO READY prompt, type RPF and press Enter:
At the RPF Option entry field, type 2 and press Enter:
In the bottom half of the screen, type s in front of the first dataset selection line and type hmvs01.source in the dataset name and press Enter:
Since it is a catalogued dataset, you may leave the Volume= field blank.
On the cmd line of the EDIT PDS screen, type s hello and press Enter:
In the empty member editing area, type the statements for the following COBOL program:
In the primary command field (at the top of the window), type save and press Enter:
In the RPF Save menu, simply press Enter with the options presented to save the edited member:
Here is a different way to enter the dataset/member to edit - we will do this for the JCL we must create to submit the job to MVS - on the EDIT PDS panel, type cobucg in the MEMBER= field and hmvs01.cntl in the Dsname= field, then press Enter:
In the empty member editing area, type the following JCL to compile and execute the small COBOL program we just saved:
Now that I have made you type all this JCL, I will tell you that once you shut down your MVS system and bring it back up, you will have access to all the compiler procedures stored in SYSC.PROCLIB on the SYSCPK volume, so you could have achieved this same job with only four lines.
In the primary command field (at the top of the window), type submit and press Enter:
MVS will respond with:
While the job is running, you can save your jobstream by typing save and Enter, followed by pressing Enter on the RPF Save menu (just as you did with the COBOL source member).
Press PFKey 3 three times to exit RPF and return to the TSO READY prompt.
At the TSO READY prompt, type q st hello and press Enter:
Type d in front of the line for the job 'HELLO' and press Enter:
And finally type s in front of the line for SYSOUT and press Enter:
The other output datasets (listed as COB SYSPRINT and GO SYSLOUT) are the COBOL compiler output and loader output, respectively.
Shutting Down TSO and VTAM
I suppose I should tell you how to shut down TSO and VTAM in an orderly manner.
First, if an application is running, such as RPF or QUEUE, you must end those to return to the TSO READY prompt. RPF may be exited by pressing PF3 repeatedly until you have returned to the main RPF menu and then exited to the TSO READY prompt. QUEUE may be exited by pressing PF3 to return to the TSO READY PROMPT.
First you should log off all TSO sessions you have running with the TSO LOGOFF command:
When you log off of TSO the tn3270 client window will again display the Network Solicitor screen:
By the way, you may start up to eight TSO sessions concurrently as the system is currently configured - to have more than eight sessions will require editing the VTAM and TSO parameters and is a fairly advanced topic.
To shut down TSO, on the MVS console, type P TSO and press Enter. If you have properly logged off all TSO user sessions, the shutdown will be quick and without fuss:
To shut down VTAM, on the MVS console, type Z NET,QUICK and press Enter:
You should be familiar by now how to shut down JES2 and MVS in an orderly fashion - $pjes2/z eod/quiesce - so I will not repeat those details here.
After you have shut down the system, you should make a backup of your DASD volumes, so that if any serious errors occur you can always return to this stable point and try again.
After that, it is up to you. I am always seeking ways to make improvements to my Hercules/MVS system; changing something here, installing a program there. After all, if I make a drastic mistake and irreparably damage my MVS installation, it is only myself that is affected; at the very least I have learned something valuable in the event. I am amazed at the number of user developed TSO commands and batch programs that are available to simplify one task or another. Would that I had access to these at some of the vexing moments in the past when I was trying to overcome a seemingly insurmountable obstacle that I now find is almost a non-existent problem when I apply one of the commands or jobstreams I have installed. If you are just starting out with MVS, I have written a short page summarizing some things I have learned about maintaining MVS. It may be viewed at Customizing MVS.
As we have already installed the SYSCPK DASD volume, you have all the compilers available and ready to use, but you might need to look at the Assembling/Compiling page to find answers to questions you have about how to use them.
If you are interested in creating and using VSAM datasets, I have written a tutorial on using VSAM (VSAM Tutorial). And you might check out the VSAM interface routine (VSAM I/O routine) that will allow you to write COBOL and PL/1 programs that access VSAM datasets.
I have also written a tutorial on TSO (TSO Tutorial) that covers all the basic TSO commands as well as extensive coverage of what you need to know to write Command Lists.
Ralf Jonas caught and reported several typographical errors in these instructions. He also suggested I create a page documenting the steps to IPL the completed MVS system, so I have added that as an additional step - Normal Startup of Customized MVS 3.8.
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 March 30, 2020.