You might be asking, "What is left to do? Did we not complete the system in the prior step?" And the answer is that we did complete the System Generation, which builds a complete installation of MVS 3.8j. Then we did some additional steps to apply modifications and add what might be called 'tweaks' to make the resulting system more user friendly. And now, the system is ready to IPL (or load) for the first time.
After we bring the system up for the first time, we still need to complete a few tasks, because as the new system is now, all it has been set up to do is run batch jobs submitted through the card reader. So the tasks we will complete in this step are:
Add a DASD volume with several language compilers and software tools.
Create some new DASD volumes where you may store datasets you create.
Create some TSO User accounts on your system.
Start VTAM and TSO, so that you may log onto a TSO user session.
Add a very comprehensive editor, which is so much more than an editor as it provides many features to allow you to manage your use of a TSO session.
Add a program that allows you to view and manipulate JES2 jobs.
Add another editor, which also offers many more capabilities than just editing datasets.
Enter, compile, link, and execute a simple COBOL program.
Along the way you will learn a little more about using MVS, TSO and other facilities of MVS.
To recap prior steps, you should already have downloaded/installed on your computer -
My installation objects archive (mvsInstallationResources.tar.gz for use on Linux /or/ mvsInstallationResources.zip for use on Windows). You do not need both of these files, only the one appropriate for your Operating System.
You should have created the MVS starter system on two 3330 DASD volumes - START1.3330 and SPOOL0.3330 - located in the dasd directory.
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) - also located in the dasd directory.
You should have created the new MVS 3.8j system on four 3350 DASD volumes: MVSRES.3350, MVS000.3350, SPOOL1.3350, and PAGE00.3350 - also located in the dasd directory.
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:
My installation objects archive (item #3 in the prerequisites list above) contains files used for this and all subsequent steps of this set of instructions. Twenty of the files are required for this step:
For Linux host Operating Systems, mvsInstallationResources.tar.gz:
Extracted to Directory
check.queue.rexx mvs REXX script to verify QUEUE source loaded completely condcode.rexx mvs REXX script to extract/display condition codes for jobs create.dasd.sh mvs bash script that utilizes the dasdinit utility to create empty DASD volumes submit.sh mvs bash shell script that passes jobstream file to socket reader using netcat mvs.cnf conf Hercules configuration file to execute Hercules/MVS 3.8j (the newly generated MVS system) mvs.script conf Hercules command script to add new DASD to configuration date.jcl
jcl Jobstreams (Job Control Language statements) submitted to MVS starter system to build distribution libraries
plus Two load module libraries in XMIT format
rpf184.het tape A collection of macros required for some Usermods
Note: The files listed above are not the complete list of files contained in the archive. They are only the files that are utilized in this step.
For Windows host Operating Systems, mvsInstallationResources.zip:
Extracted to Directory
check.queue.rexx mvs REXX script to verify QUEUE source loaded completely condcode.rexx mvs REXX script to extract/display condition codes for jobs create.dasd.bat mvs Windows bat script that utilizes the dasdinit utility to create empty DASD volumes submit.bat mvs Windows bat script that passes jobstream file to socket reader using netcat mvs.cnf conf Hercules configuration file to execute Hercules/MVS 3.8j (the newly generated MVS system) mvs.script conf Hercules command script to add new DASD to configuration date.jcl
jcl Jobstreams (Job Control Language statements) submitted to MVS starter system to build distribution libraries
plus Two load module libraries in XMIT format
rpf184.het tape A collection of macros required for some Usermods
Note: The files listed above are not the complete list of files contained in the archive. They are only the files that are utilized in this step.
The clock time required to complete the steps below should be approximately 45 minutes. Most of the work in this step consists of tasks that are interactive, so there are not as many batch processes running from which to extract elapsed clock time. 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, but I will assume that at this point you have already installed all the required files during the completion of the previous steps. I am running Linux Mint on a fairly recent, quad core machine; however, as much of this step involves interactive work with the user, the speed of the processor only impacts a few batch jobs. 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.
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 ../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.
Open a terminal window (Linux) or a Command Prompt window (Windows) and start hercules from the mvs directory:
Hercules will load the configuration file and display:
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. If you do not have a tn3270 client, I would suggest Tom Brennan's Vista tn3270 client (https://www.tombrennansoftware.com/) or x3270 (http://x3270.bgp.nu/). The 3270 refers to the port Hercules is listening on, not the fact that this is a 3270 device.
I have been told that Windows 10 will not resolve the localhost alias correctly, so you must instead use 127.0.0.1 as the connection address. Another individual reported the exact same errors on a Mac. I suggested that he try using 127.0.0.1 instead of localhost, which solved his connection problem.
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 (the MVS 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. (The yellow arrow and text was added by me in editing and will not appear on your tn3270 client window.)
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 150 and press ENTER:
When MVS IPLs, some users have noticed that Hercules logs many repetitive messages that seem like an error condition exists. In fact, MVS is testing the memory allocated to it by the emulator to see how much memory is available to it and these messages are a result of those tests. If they are a distraction to you, you may edit the Hercules configuration file and change the OSTAILOR NULL line to read OSTAILOR QUIET. You may also enter the Hercules command OSTAILOR QUIET on the command line, and the change will only affect the current session. Setting OSTAILOR QUIET will suppress all error condition log messages.
On the MVS console 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 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 to rebuild the Link Pack Area:
This image is from an old capture on a Windows host system; the screen passes by so quickly on this system that I could not capture it. 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 initializes using parameters it reads from SYS1.PARMLIB(JES2PM00). Console operator commands are read and processed from SYS1.PARMLIB(COMMND00). Your MVS console 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 MVS console 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:
K S,DEL=RD,SEG=19,RTME=001,RNUM=19,CON=N;K A,10
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 MVS console screen. 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 MVS console screen.
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.
This is just the bare basics for using the MVS console. There is much more to know, and some of the information can make MVS much easier to use and manage. For a thorough understanding of MVS Operator Console operation, you might want to read the IBM manual: Operator's Library: OS/VS2 MVS System Commands. I provide a copy of the manual, in PDF format: http://www.jaymoseley.com/hercules/downloads/pdfs/GC38-0229-1-OSVS2-MVS-System-Commands.pdf [10.8 MB MD5: 949ace4646aa5e16f04223596ece28dc]
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. [July 2020] It was reported that Volker Bandke's hosting and/or domain registration has expired, so I have recovered this content and created a pdf containing it at ../downloads/pdf/Volker Bandke Command Summaries.pdf.
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.
It is difficult to find manuals for this old version of MVS, but several may be found at http://bitsavers.org. Links to some manuals at the site as I am writing this are:
- GC26-3792-8 OS/VS2 System Generation Reference Release 3.8 October 1980 (pdf)
- GC26-3841-3 OS/VS2 Access Methods Release 3.8 October 1980 (pdf)
- GC26-3902-1 OS/VS2 MVS Utilities Release 3.8 September 1983 (pdf)
- GC28-0645-4 OS/VS2 Release 3.8 TSO Terminal Users Guide June 1978 (pdf)
- GC28-0692-5 OS/VS2 MVS JCL Release 3.8 April 1984 (pdf)
- GC23-0007-1 Operators Library OS/VS2 MVS JES2 Commands January 1979 (pdf)
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 [21.2 mb MD5: 59ba0d6654db8419d7b51a8aad3e9a3a]. 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.
Note: Even if you are rebuilding an MVS 3.8j system where you have SYSCPK installed, you should download the current version from the link above. I periodically make updates/additions to the volume and by downloading the current version, you will be sure to have all updates. As I am writing this, the latest version of SYSCPK was uploaded in July, 2020 and some of the changes made at that time were specifically targeted at this September, 2020 update to these MVS 3.8j installation instructions.
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 you may want to read later. 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.
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:
the create.dasd script will:
create a dasd subdirectory if it does not already exist,
change to that subdirectory,
if the eight DASD volumes to be created exist, delete them,
utilize the dasdinit utility (included with Hercules) to create the eight volumes
On a Linux system, open a terminal window in the mvs directory and type the command:
and press Enter. The argument 'user' instructs the script to produce the eight DASD volumes required for this step. The script will execute, creating the eight DASD volumes. The output of the script on my (Linux) system is shown below:
jay@Phoenix ~/mvs $ ./create.dasd.sh user This script creates DASD volumes for MVS 3.8j. Do you want to create compressed DASD images? (y or n)n Changed directory to: dasd dasdinit -a pub000.3380 3380 111111 HHCDU044I Creating 3380 volume 111111: 886 cyls, 15 trks/cyl, 47616 bytes/track HHCDU041I 886 cylinders successfully written to file pub000.3380 HHCDI001I DASD initialization successfully completed. dasdinit -a pub001.3390 3390 222222 HHCDU044I Creating 3390 volume 222222: 1114 cyls, 15 trks/cyl, 56832 bytes/track HHCDU041I 1114 cylinders successfully written to file pub001.3390 HHCDI001I DASD initialization successfully completed. dasdinit -a sortw1.2314 2314 333333 HHCDU044I Creating 2314 volume 333333: 203 cyls, 20 trks/cyl, 7680 bytes/track HHCDU041I 203 cylinders successfully written to file sortw1.2314 HHCDI001I DASD initialization successfully completed. dasdinit -a sortw2.2314 2314 444444 HHCDU044I Creating 2314 volume 444444: 203 cyls, 20 trks/cyl, 7680 bytes/track HHCDU041I 203 cylinders successfully written to file sortw2.2314 HHCDI001I DASD initialization successfully completed. dasdinit -a sortw3.2314 2314 555555 HHCDU044I Creating 2314 volume 555555: 203 cyls, 20 trks/cyl, 7680 bytes/track HHCDU041I 203 cylinders successfully written to file sortw3.2314 HHCDI001I DASD initialization successfully completed. dasdinit -a sortw4.2314 2314 666666 HHCDU044I Creating 2314 volume 666666: 203 cyls, 20 trks/cyl, 7680 bytes/track HHCDU041I 203 cylinders successfully written to file sortw4.2314 HHCDI001I DASD initialization successfully completed. dasdinit -a sortw5.2314 2314 777777 HHCDU044I Creating 2314 volume 777777: 203 cyls, 20 trks/cyl, 7680 bytes/track HHCDU041I 203 cylinders successfully written to file sortw5.2314 HHCDI001I DASD initialization successfully completed. dasdinit -a sortw6.2314 2314 888888 HHCDU044I Creating 2314 volume 888888: 203 cyls, 20 trks/cyl, 7680 bytes/track HHCDU041I 203 cylinders successfully written to file sortw6.2314 HHCDI001I DASD initialization successfully completed. Returning to parent directory Script completed successfully! jay@Phoenix ~/mvs $
If your host Operating System is macOS, I have been told that you need to use the command:
/bin/sh ./create.dasd.sh user
On a Windows system, open a command prompt window in the mvs directory and type the command:
and press Enter. The argument 'user' instructs the script to produce the eight DASD volumes required for this step. The script will execute, creating the eight DASD volumes. The output of the script on a Windows system is shown below:
E:\MVS>create.dasd.bat user This script creates empty DASD volumes building the MVS 3.8j system Do you want to create compressed DASD images? (Y/N)?y Changing to dasd subdirectdory. Creating PUB000 3380 volume. dasdinit -a -z pub000.3380 3380 111111 HHCDU044I Creating 3380 volume 111111: 886 cyls, 15 trks/cyl, 47616 bytes/track HHCDU041I 886 cylinders successfully written to file pub000.3380 HHCDI001I DASD initialization successfully completed. Creating PUB001 3390 volume. dasdinit -a -z pub001.3390 3390 222222 HHCDU044I Creating 3390 volume 222222: 1114 cyls, 15 trks/cyl, 56832 bytes/track HHCDU041I 1114 cylinders successfully written to file pub001.3390 HHCDI001I DASD initialization successfully completed. Creating SORTW1 2314 volume. dasdinit -a -z sortw1.2314 2314 333333 HHCDU044I Creating 2314 volume 333333: 203 cyls, 20 trks/cyl, 7680 bytes/track HHCDU041I 203 cylinders successfully written to file sortw1.2314 HHCDI001I DASD initialization successfully completed. Creating SORTW2 2314 volume. dasdinit -a -z sortw2.2314 2314 444444 HHCDU044I Creating 2314 volume 444444: 203 cyls, 20 trks/cyl, 7680 bytes/track HHCDU041I 203 cylinders successfully written to file sortw2.2314 HHCDI001I DASD initialization successfully completed. Creating SORTW3 2314 volume. dasdinit -a -z sortw3.2314 2314 555555 HHCDU044I Creating 2314 volume 555555: 203 cyls, 20 trks/cyl, 7680 bytes/track HHCDU041I 203 cylinders successfully written to file sortw3.2314 HHCDI001I DASD initialization successfully completed. Creating SORTW4 2314 volume. dasdinit -a -z sortw4.2314 2314 666666 HHCDU044I Creating 2314 volume 666666: 203 cyls, 20 trks/cyl, 7680 bytes/track HHCDU041I 203 cylinders successfully written to file sortw4.2314 HHCDI001I DASD initialization successfully completed. Creating SORTW5 2314 volume. dasdinit -a -z sortw5.2314 2314 777777 HHCDU044I Creating 2314 volume 777777: 203 cyls, 20 trks/cyl, 7680 bytes/track HHCDU041I 203 cylinders successfully written to file sortw5.2314 HHCDI001I DASD initialization successfully completed. Creating SORTW6 2314 volume. dasdinit -a -z sortw6.2314 2314 888888 HHCDU044I Creating 2314 volume 888888: 203 cyls, 20 trks/cyl, 7680 bytes/track HHCDU041I 203 cylinders successfully written to file sortw6.2314 HHCDI001I DASD initialization successfully completed. Returning to original subdirectory. Script completed successfully! E:\MVS>
The DASD volumes that are created are simply raw emulated volumes; they have not been initialized for use by MVS and contain no VTOC (Volume Table of Contents) or control structures. They will be initialized in one of the following steps.
First the new volumes must be identified to Hercules. I have provided a script to do that. On the Hercules console, type script conf/mvs.script and press Enter:
The script will run and the Hercules console will display:
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 the netcat program. I have included a Windows version of netcat (nc.exe) and a Windows batch script (submit.bat) in the mvsResources.zip 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; it has not been updated for a while, as I have not used SPF/PC since moving my desktop machines to Linux, but the page is still available at 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 bash script file executes netcat with the following options:
cat $1 | nc -w1 127.0.0.1 3505
to copy the contents of the file, specified as argument 1 to the bash script, to the listening socket at port 3505.
If your host Operating System is macOS, I have been told that you need to use the command:
/bin/sh ./submit.sh <filename>
On a Windows system, open a command prompt window and type the command:
The Windows script uses the type command instead of cat, but otherwise functions the same.
I have received reports of people who run Windows 10 experiencing a loss of data (either lines dropped from the file being 'submitted' to MVS or premature termination of the file being 'submitted'). I don't have a resolution for that, but if you are running Windows 10 and experience aberrations, this is an area to examine.
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 volumes, which are now initialized, online and issue Mount commands to set the Volume Attribute for each volume appropriately.
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):
Initiator 1 Initiator 2 Initiator 3 Initiator 4
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.
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.
You will need to edit the Hercules configuration file (mvs.cnf in the conf directory) and remove the hash (#) in front of each of the addresses for these new volumes (180, 190, 220, 221, 222, 223, 224, 225, 253); they have already been included in the file, but could not be made active until the volumes were initialized. You must make these changes before you start Hercules again so that the volumes will be available to MVS. This is important to remember to do, because the job step following the one which initialized the new volumes modified the JES2 catalogued procedure and when JES2 is next started, it will require the SYSCPK volume to be available on the system or JES2 will refuse to start.
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 to check the condition codes. However: 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 IEFACTRT messages are from this program and the information they are displaying is:
IEFACTRT SSSSSSSS/PPPPPPPP/CP:UT:IM.EX/WA:LL:TI.ME/CCCCC/JJJJJJJJ where SSSSSSSS is the step name [if step name is omitted: (JS#999), with the step number substituted for 999] PPPPPPPP is the name of the program executed CP:UT:IM.EX is the CPU time elapsed in HH:MM:SS.hh (hours, minutes, seconds, hundredths of seconds) WA:LL:TI.ME is the clock time elapsed in HH:MM:SS.hh (hours, minutes, seconds, hundredths of seconds) CCCCC is the completion code for the step (abends will be indicated with Ucccc for user and S-ccc for system abends JJJJJJJJ is the job name
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:
jay@Phoenix ~/mvs $ ./condcode.rexx prt00e.txt mvs00 Searching prt00e.txt for MVS Job Name mvs00 Job Name Step Name Proc Step Name Completion Code -------- --------- -------------- --------------- MVS00 ICKDSF 0000 MVS00 IEBGENER 0000 MVS00 BACKUP01 0000 MVS00 UPDATE01 0000 MVS00 IEFBR14 0000 MVS00 IDCAMS01 0000 6 steps executed in selected jobs 6 steps received completion code = 0000 jay@Phoenix ~/mvs $
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.
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 several 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.
We will also define a User Catalog on MVS000 - UCMVS000 - and an Alias that will direct MVS to catalog all datasets with a high level qualifier SYSO into that User Catalog. A number of years ago I set this type of organization up primarily to hold the five generations of SMF data that was collected, but it also provides a mechanism to handle other 'Operations' related datasets, hence the high level qualifier of SYSO (SYStem Operations). I don't know why, or when, I dropped back from using this organization, but when I was relocating the user mod that applies the IEFU29 exit, I remembered this and have now re-implemented it. It removes the need to supply the Master Catalog password whenever an SMF collection dataset switch occurs. My original explanation of setting up the User Catalog structure for SMF datasets is still present on this site at: IEFU29 Exit.
I have included a batch job - MVS01 (contained in file mvs01.jcl in the jcl directory) - that will complete setting up all the VSAM Data Spaces, User Catalogs, and Aliases 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. To be clear, you will not be prevented from cataloging datasets into the Master Catalog, but after setting a password on the Master Catalog, any time there is an attempt to add, delete, or update an entry in the Master Catalog, a message is issued on the MVS system console asking for the operator to supply the password before the Master Catalog may be updated.
In the next section we will be setting 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.sh jcl/mvs01.jcl (from the mvs directory) and press Enter:
MVS01 executes for 0.01 minute and the expected return code is:
jay@Phoenix ~/mvs $ ./condcode.rexx prt00e.txt mvs01 Searching prt00e.txt for MVS Job Name mvs01 Job Name Step Name Proc Step Name Completion Code -------- --------- -------------- --------------- MVS01 IDCAMS01 0000 1 steps executed in selected jobs 1 steps received completion code = 0000 jay@Phoenix ~/mvs $
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.
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.sh 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 MVS console screen, 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 - 15 steps for each User ID added - although the job takes only 0.36 minute to execute. The expected return codes are:
jay@Phoenix ~/mvs $ ./condcode.rexx prt00e.txt mvs02 Searching prt00e.txt for MVS Job Name mvs02 Job Name Step Name Proc Step Name Completion Code -------- --------- -------------- --------------- MVS02 DEL01 0000 MVS02 AL02 0000 MVS02 PW03 0000 MVS02 PW04 0000 MVS02 PW05 0000 MVS02 PW06 0000 MVS02 TSO07 0000 MVS02 PW08 0000 MVS02 PW09 0000 MVS02 PW10 0000 MVS02 PW11 0000 MVS02 PW12 0000 MVS02 PW13 0000 MVS02 PW14 0000 MVS02 IDC15 0000 MVS02 DEL01 0000 MVS02 AL02 0000 MVS02 PW03 0000 MVS02 PW04 0000 MVS02 PW05 0000 MVS02 PW06 0000 MVS02 TSO07 0000 MVS02 PW08 0000 MVS02 PW09 0000 MVS02 PW10 0000 MVS02 PW11 0000 MVS02 PW12 0000 MVS02 PW13 0000 MVS02 PW14 0000 MVS02 IDC15 0000 30 steps executed in selected jobs 30 steps received completion code = 0000 jay@Phoenix ~/mvs $
For each User ID there are four datasets created:
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, 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:
The IST025I messages displayed are issued because TCAM is not set up on the system and may be safely ignored. 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:
The TSO system is sophisticated and provides a great tool. Back in the mid-1980's I like to think I was the primary catalyst in convincing IT management at the fairly significant municipal government where I was employed to allow each application programmer to have their own terminal on their desk and to have access to TSO/ISPF to enhance their productivity. If you are unfamiliar with TSO, I urge you to spend some time with my TSO tutorial. One of the first items you should read is the section about PROFILE PREFIX.
You may observe that if you leave your TSO session inactive for a period of time, you will be logged off automatically. The topic: How can I increase the time interval before TSO automatically logs off my session because of inactivity? describes this in detail and suggests methods to change this.
Now that we have TSO up and running, we will add a few TSO tools that will make using it more enjoyable.
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 V1R8M4 (Version 1, Release 8, Modification 4), and Rob has continued to add features so there may be updates available periodically. The distribution is contained on a Hercules' Emulated tape - rpf184.het - and is available from Rob Prins website [http://www.prince-webdesign.nl/index.php/software/]. I have retrieved the installation archive from Rob Prin's site and the tape is in the tapes 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\rpf184.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, so in the Hercules console type devinit 100 tape/rpf184.het 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:
jay@Phoenix ~/mvs $ ./condcode.rexx prt00e.txt rpf184\$1 Searching prt00e.txt for MVS Job Name rpf184$1 Job Name Step Name Proc Step Name Completion Code -------- --------- -------------- --------------- RPF184$1 CLEANUP 0000 RPF184$1 ALLOC 0000 RPF184$1 GENER 0000 RPF184$1 ALLOC 0000 RPF184$1 HELP 0000 5 steps executed in selected jobs 5 steps received completion code = 0000 jay@Phoenix ~/mvs $
Note: the \ before the $1 in the above command is required on Linux systems in order to pass the $ symbol to the script.
We will be using RPF below to enter some COBOL source and some JCL. It may be useful for you to have a copy of the User's Guide for RPF 184.
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.sh 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:
jay@Phoenix ~/mvs $ ./condcode.rexx prt00e.txt gregq Searching prt00e.txt for MVS Job Name gregq Job Name Step Name Proc Step Name Completion Code -------- --------- -------------- --------------- GREGQ STEP1 0000 1 steps executed in selected jobs 1 steps received completion code = 0000 jay@Phoenix ~/mvs $
Since I have received several reports from Windows 10 users that this job terminates prematurely, I wrote a REXX script that reads the MVS SYSOUTs (contained in prt00e.txt) searching for the messages issued by this job as each dataset is loaded. After processing the entire file, the script will report the success, or failure, of each member loaded. To execute the script, use the command: ./check.queue.rexx prt00e.txt or, on Windows: rexx check.queue.rexx prt00e.txt. An example of the expected output from the script, with some deliberately forced errors, is:
jay@Phoenix ~/mvs $ ./check.queue.rexx prt00e.txt $GPDOC successfully loaded $JQT successfully loaded $RENAME successfully loaded $RNBDOC successfully loaded $SP successfully loaded ACTIVE successfully loaded ALLOCATE successfully loaded BLD3270 successfully loaded C successfully loaded CB3270 successfully loaded CHCT successfully loaded CJCT successfully loaded CJOE successfully loaded CJOESP successfully loaded CJQE successfully loaded CKPT successfully loaded COMPILE successfully loaded CPDDB successfully loaded CSAVE successfully loaded CSPIN successfully loaded CTSO successfully loaded DDNAME successfully loaded DISPLAY successfully loaded FILE53 successfully loaded FINDJOB successfully loaded FINDPDDB successfully loaded FORMAT successfully loaded GTTERM successfully loaded HELP successfully loaded HEXBLK successfully loaded HEXDUMP successfully loaded INIT successfully loaded INITS successfully loaded JCL successfully loaded JLOG successfully loaded JMSG successfully loaded LIST successfully loaded LISTDS successfully loaded NEXT successfully loaded PARSE successfully loaded PRINT successfully loaded QCOMMON was not loaded ******** ERROR ******** QHEAD was not loaded ******** ERROR ******** QPRBGEN was not loaded ******** ERROR ******** QSTART was not loaded ******** ERROR ******** QSTOP successfully loaded QTILT successfully loaded QUEUE successfully loaded QUEUECMN successfully loaded READSPC successfully loaded RELINK successfully loaded REPOS successfully loaded SEARCH successfully loaded SYSLOG successfully loaded SYSOUT successfully loaded TABLE successfully loaded TSOHELP successfully loaded XDS successfully loaded jay@Phoenix ~/mvs $
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 job only takes a few seconds to complete, so I waited a bit and pressed Enter to retrieve the notification from MVS that the job ended. This message is in response to an operand on the JOB card: NOTIFY=HMVS01. If you want MVS to notify you when your batch jobs complete, you add the NOTIFY operand with your TSO user id to the JOB cards of the jobs you submit through TSO.
The expected completion codes from the job - GREGQ - are:
jay@Phoenix ~/mvs $ ./condcode.rexx prt00e.txt gregq Searching prt00e.txt for MVS Job Name gregq Job Name Step Name Proc Step Name Completion Code -------- --------- -------------- --------------- GREGQ STEP1 0000 GREGQ ASM Q00 0000 GREGQ ASM Q01 0000 GREGQ ASM Q02 0000 GREGQ ASM Q03 0000 GREGQ ASM Q04 0000 GREGQ ASM Q05 0000 GREGQ ASM Q06 0000 GREGQ ASM Q07 0000 GREGQ ASM Q08 0000 GREGQ ASM Q09 0000 GREGQ ASM Q10 0000 GREGQ ASM Q11 0000 GREGQ ASM Q12 0000 GREGQ ASM Q13 0000 GREGQ ASM Q14 0000 GREGQ ASM Q15 0000 GREGQ ASM Q16 0000 GREGQ ASM Q17 0000 GREGQ ASM Q18 0000 GREGQ ASM Q19 0000 GREGQ ASM Q20 0000 GREGQ ASM Q21 0000 GREGQ ASM Q22 0000 GREGQ ASM Q23 0000 GREGQ ASM Q24 0000 GREGQ ASM Q25 0000 GREGQ ASM Q26 0000 GREGQ ASM Q27 0000 GREGQ ASM Q28 0000 GREGQ ASM Q29 0000 GREGQ ASM Q30 0000 GREGQ ASM Q31 0000 GREGQ ASM Q32 0000 GREGQ ASM Q33 0000 GREGQ ASM Q34 0000 GREGQ ASM Q35 0000 GREGQ ASM Q36 0000 GREGQ ASM Q37 0000 GREGQ ASM Q38 0000 GREGQ LKED 0000 41 steps executed in selected jobs 41 steps received completion code = 0000 jay@Phoenix ~/mvs $
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.
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. In the TSO window, type QUEUE and press Enter to start the QUEUE program. At the QUEUE COMMAND prompt, type HO and press Enter to display the held jobs in the output queue:
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.
A topic the comes up frequently on the Hercules MVS and Turnkey forums is the size of the SPOOL and experiences of the SPOOL filling up and/or JES2 running short of resources. Although I have set up an entire 3350 DASD for the SPOOL dataset, that is not very much space when you factor in the amount of information that is generated by a job: JCL and SYSIN input data, both read from the card reader, messages and logs, and SYSOUT output. It will be a temptation with QUEUE available to leave jobs sitting in the output queue indefinitely, but it is a good practice to regularly review and then print and/or delete jobs from the queue. SYSGEN05 set up a ZTIMER task that runs hourly and will purge all output from the spool that is five days old. This is largely just for an example of how to set up ZTIMER events and an MVS system that is getting heavy use would fill up the spool much sooner than five days. If you are using your MVS system to generate a lot of output, you should add more SPOOL DASD volumes to your system to handle the workload.
[17 September 2020] JES2 Queue Management
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.
If at a later time you want to update to a newer version: retrieve the archive from Greg's site and extract the load modules (REV370LOAD.XMI file), CLIST members (REVCLIST.XMI) and help members (REVHELP.XMI) and place them into your jcl directory, then follow the directions below.
Now you will see the purpose for the second card reader on our system that is not managed by JES2. This may not be the only use for the second card reader, but it is a perfect example of a great use for it. In the Hercules command window, type devinit 01c jcl/REV370LOAD.XMI 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.sh 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. The expected completion codes for the two steps of the job is 0000.
In the Hercules command window, type devinit 01c jcl/REVHELP.XMI ebcdic and press Enter.
In a Command Prompt window for your host operating system, type the command ./submit.sh 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 the two steps of the job is 0000.
In the Hercules command window, type devinit 01c jcl/REVCLIST.XMI ebcdic and press Enter.
In a Command Prompt window for your host operating system, type the command ./submit.sh jcl/review3.jcl (from the mvs directory) and press Enter. This job will receive the CLIST members for REVIEW and place them in SYS1.CMDPROC.
Shortly after the April 2020 revision, I provided an update to integrate the REVINIT CLIST into the TSO logon procedure. In order to incorporate that change during installation I have added a third step to the REVIEW3 job. That step updates the REVINIT CLIST distributed by Greg Price to work correctly with TSO User ID's created by my TSONUSER procedure, so for the REVIEW3 job, submitted above, you will see a third job step. The expected completion code for all three steps of the job is 0000. The change made by this step will not be activated until you log off TSO and log back on, but since the change only affects RFE (the REVIEW Front End program), it is not necessary to log off and back on at this time.
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.
If you want to know more about the process that creates the files with the extension .XMI, I have written a brief explanation in Transmit/Receive.
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.sh jcl/date.jcl (from the mvs directory) and press Enter. It will also install a simple help text in SYS2.HELP. To display the date, use the command date at the TSO READY prompt:
DATE = TUESDAY, JANUARY 13, 2015 (2015/013)
TIME = 15.56.00
That is pretty much up to you, since you now have your own private mainframe. I find that although I don't make a lot of changes to the MVS datasets, I do occasionally make a small change, so you shouldn't feel intimidated if you think you can make your MVS system work better by researching how some settings or load modules can be changed to improve how it works for you. I do tend to isolate my own datasets from the MVS datasets and most of what I change occurs in those spaces. I have a lot more DASD created and populated on my system than we have set up here. That is where I keep third party programs I have installed, along with source code for my own programs, my own private load libraries, and my JCL libraries. Oh, and lots of documentation datasets keeping track of what I have done. I have a philosophy of 'change management' that comes from incorporating ideas of many other people I have worked with over my career. I wrote some of those ideas down several years ago and put it in a document at Customizing MVS. I used that title for the page long before I wrote this one, so it isn't just a rehash of what I have said here.
Also, I don't know quite where to mention this, but I will drop it here and probably figure out another place to say it so that it won't get lost as someone works their way through this. In Stage 1 I set a CTLPRG option to allow for multiple CPUs to be managed by MVS, as that is something that some people in the Hercules/MVS community were interested in. I have not yet ventured there, and don't know if I ever will. But if you want to explore that, you will need to change the Hercules configuration file settings to enable multiple CPU emulation. Go back to www.hercules-390.eu and research the options necessary, then make the changes to your Hercules configuration file - mvs.cnf in the conf directory - and see what works for you on your host Operating System.
So, as a last step before going through the normal shut-down routine, we can go through the procedure to enter, compile, and execute a COBOL program from TSO.
Note: The screen captures below were done in April, 2020 using RPF 1.8.0, but other than the version number on the initial splash screen, there is no difference in the functionality of the brief tutorial below.
At the TSO READY prompt, type RPF and press Enter. At the RPF Option entry field on the main menu, type 2 and press Enter:
On the RPF EDIT screen, Option is already defaulted to 1, so tab down and type s in front of the first dataset line. Enter HMVS01.SOURCE as the dataset name:
Since it is a catalogued dataset, you may leave the Volume= field blank. Press Enter. On the EDIT window, in the Cmd field, type s hello and press Enter:
The 's' is an abbreviation for 'select', and since the member does not exist, it will be created for you, ready to have data typed into it. Type the following short COBOL program:
On the cmd line of the EDIT type save and press Enter:
In the RPF Save menu, simply press Enter with the options presented to save the edited member:
The EDIT panel will now show that you have created a member named HELLO:
Press Program Function Key 3 to return to the RPF Edit screen. Here is a different way to enter the dataset/member name to be edited - we will do this for the JCL we must create to submit the job to MVS. On the RPF Edit panel, type cobucg in the Member= field and hmvs01.cntl in the Dsname= field, then press Enter:
You will be presented a panel with the editing area set to edit the member you specified. As this is a new member, the lines for the data will all be blank. Job Control Language statements are a bit tricky to enter correctly, so in the Cmd field type COLS and press enter. This will add a ruler at the top of the screen to show you the columns you are typing into below the ruler:
Now enter the JCL for the job to compile and run the HELLO COBOL program:
When all the JCL is entered, in the Cmd field, type SUBMIT and press Enter:
While MVS runs the job, you can save your jobstream and exit RPF. Type the command save and press Enter, then press Enter again to confirm the save parameters. The JCL you typed will be saved in your HMVS01.CNTL dataset, COBUCG member.
Press the PFKey three times to exit RPF back to the TSO READY prompt.
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.
At the TSO READY prompt, type q st hello and press Enter; then type d in front of the line for the job 'HELLO' and press Enter:
The panel you will be presented for the d selection code (shown below for a successful execution) shows just the output that is expected from the DD names in your JCL that are to be sent to SYSOUT=* (where * in this case means to any class designation). If there is no number of lines beneath the LINES column header and no class designation letter beneath the CLASS column header, there was a problem in executing your job; i.e. you cannot display output if the job step did not execute. If this is the case, return to the previous panel (PFKey 3) and type s in front of the line for the job named HELLO (rather than d, which requests only the output for DD names assigned to SYSOUT to be displayed). This will select all output produced for the job. Examine the JES2 JOB LOG, JCL listing, and messages (you can use n (next) and p (previous) to page through the different output groups. From the information there you will have to diagnose what problem occurred, resolve it and correct your JCL, and resubmit your job.
If your display looks like the panel below, type s in front of the line for the output that was written to the SYSOUT DD from the job step GO and press Enter:
And here is the output from your COBOL program's execution:
The other output datasets (listed as COB SYSPRINT and GO SYSLOUT) are the COBOL compiler output and loader output, respectively.
So that you will know how to shut down TSO and VTAM in an orderly manner, here are the steps.
First, if an application is running, such as RPF or QUEUE, you must end those to return to the TSO READY prompt. For most TSO applications, PFKey 3 is the key to exit a panel and return to the previous one. So pressing PFKey 3 repeatedly should eventually terminate any application and return you 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.
TSO will terminate. Then to shut down VTAM type Z NET,QUICK and press Enter:
VTAM will terminate. Then to shut down JES2 type $P JES2 and press Enter:
JES2 may take a few seconds to terminate, as it waits for processes it manages to complete. Then to shut down MVS type Z EOD and press Enter:
The 'end of day' processing includes writing final records to the System Management Facility dataset. A switch to the alternate SMF dataset will occur, even though MVS will not write anything to the dataset.
To make certain that MVS writes any data it is holding in memory to datasets, type the command QUIESCE and press Enter:
After quiesce, the system will go into a wait state.
On the Hercules console, enter the command 'quit'.
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.
In this step you have made many changes to your new MVS 3.8j system. It would probably be a good idea to make a backup copy of the files in the dasd directory. If you later damage your system datasets, you can recover to this point by restoring the backup and restarting MVS. You can use any means to store a backup copy of the files - place them in a WinRar, Zip or tar archive; or burn them onto a CD-rom blank.
If you have not already done so, you need to edit the Hercules configuration file (mvs.cnf in the conf directory) and remove the hash (#) in front of each of the addresses for these new volumes (180, 190, 220, 221, 222, 223, 224, 225, 253); they have already been included in the file, but could not be made active until the volumes were initialized. If you do not do this, the next time you IPL the MVS system, JES2 will not start!
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. VSAM support was not present in the MVT COBOL and PL/1 compilers, so you will need to use the VSAM I/O routine to access VSAM objects from programs written in these languages and compiled with the old MVT compilers.
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 November 17, 2020.