Installing MVS 3.8
IPL the Newly Created MVS 3.8
And Some Post-System Generation Housekeeping
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. 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. Of course, there are device addresses generated into the system for which this configuration 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 want to minimize the need for doing System Generations, even the relatively simpler IOGEN, by adding all the devices, and device addresses, that you anticipate you may need for expansion.
This initial configuration specifies a primary 3270 console, plus an alternate, and a hardcopy console printer, which is defined as a 1403 printer. There is a card reader and card punch. And there are two printers, a 1403 and a 3211. Since I frequently want to copy from one tape to another, there are two 3420 tape drives. I retained the work 3330 DASD volume from the starter system, and have included the five 3350 DASD volumes built during the SMP and System Generation processes. I have also include three 3270 display terminals if you want to run VTAM and TSO.
You can always add new devices to a running Hercules/MVS system using the Hercules' attach command. If you intend for the devices to become a regular part of your operating configuration, you will probably want to add them into the Hercules' configuration file. A link to instructions for how to create new DASD volumes for your MVS system appears later in the instructions that follow below.
IPL the MVS System
Open a console window (Linux) or an MS-DOS 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. A capability added Hercules is the means to specify a Group name on the 3270 devices in the Hercules' configuration file. This allows you to more closely control to which emulated 3270 device address a particular tn3270 client session will connect. In the mvs.cnf configuration file, I specify console, altconsole, and tso as three distinct groups on the 3270 devices to better control tn3270 client connections. You will need to configure your tn3270 client program to utilize these group names, or edit the configuration files to remove the Group names. If Group names are not utilized, the tn3270 client sessions will attach to the 3270 devices defined in the Hercules' configuration file in ascending address order; that is 010, 011, 0C0, 0C1, and so on.
The tn3270 session connected to the 3270 device at address 010 will be used by the MVS 3.8 system as the primary console. Note: You must use a tn3270 client for the generated MVS, not a telnet client as we have been using for the starter system.
The alternate console defined during System Generation at 3270 device address 011 is not required for operation of the system. Activating it introduces additional levels of complexity in the areas of connecting tn3270 sessions for TSO use and management of pending system messages. Therefore, I have commented out the line in the Hercules' configuration file defining a connection for 3270 device address 011.
If you wish to use TSO, you will need to connect tn3270 client sessions to the 3270 addresses beginning at address 0C0. I have included that discussion with Starting and Terminating VTAM and TSO. You can postpone reading this section until you are ready to start VTAM/TSO; you cannot actually start VTAM and TSO at this time -- they require configuring jobs to be run, which are described in the steps following. Your tn3270 client screen for the MVS main console should display an identification screen indicating it has connected to Hercules:
IPL from device 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. In the tn3270 client window (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. In 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 the SMF (System Management Facility) parameters are read from SYS1.PARMLIB(SMFPRM00), the parameters will be displayed, followed by two messages requiring operator response:
Before replying to either of these messages, it is a good time to make a setting change to the console display options. Unlike the line oriented display of the telnet client used with the starter system, the tn3270 client and MVS 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 is where input is typed by the operator to enter commands and responses to MVS. With the default console display options, if the 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. Since you will need to enter this command every time you IPL, this is also a good place to learn about setting the Program Function Keys for the console.
In this early version of MVS, you have the ability to set the Program Function Keys (PFKeys) 1 through 12 to frequently utilized MVS Console or JES2 commands. The values assigned to the PFKeys persist from IPL to IPL, so once you set a PFKey to a command, it will retain that value until you set it to a different value. Even though you only need to issue the command to modify the console display options once each IPL, it is an excellent candidate to assign to a PFKey, as it is a rather long command. In the command input area, type:
k n,pfk=(12,cmd='k s,del=rd,seg=19,con=n,rnum=19,rtme=001')
and press ENTER. This will assign the command:
K S,DEL=RD,SEG=19,CON=N,RNUM=19,RTME=001
to Program Function Key 12. Now simply pressing PFKey 12 sends this command to MVS as though you typed it into the keyboard and pressed ENTER. This command sets the display options so that messages eligible for deletion (those not requiring response) will be rolled off (erased from) the top of the screen making room for new messages.
Now you need to press PFKey 12. When you entered the command (in red above) you programmed the PFKey, but you need to press PFKey 12 to issue the command before you proceed. When the console display mode is changed to automatically Roll and Delete messages not requiring responses, MVS will display message IEE163I, indicating this status, below the input area of the console screen:
And I want to restate this just to make certain I am clear: the setting of PFKey 12 will persist from IPL to IPL so you do not have to do that again, but 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.
There is an output only console generated in the system at address 012, 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 have activated the alternate console at device address 011 (by un-commenting the line in the Hercule's configuration line for the device address), 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.
The PF Key settings are unique to each console, so the command assigned to PFKey 1 on the main console (device address 010) can be different from the command assigned to PFKey 1 on the alternate console (device address 011).
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: GC38-0229-1-OSVS2-MVS-System-Commands.pdf [10.8 MB MD5: 949ace4646aa5e16f04223596ece28dc] and DjVu format: GC38-0229-1-OSVS2-MVS-System-Commands.djvu [3.97 MB MD5: 37b93b3164ee32619dcb5fa081ddb0bf ]
Now you may respond to the two waiting messages. The first message, regarding SMF parameters, was displayed to allow you to make overrides to the SMF parameters which have been read from the SMFPRM00 member of SYS1.PARMLIB. [A reply number is displayed for any message requiring a reply. The number is incremented by the system each time a response is required, so the number displayed on your console may not always match the number I show in these instructions!] The response to indicate that you are ready for MVS to proceed with bringing up SMF using the parameters given is:
r 0,u
The second message, requesting a reason code for the IPL, likewise should be responded to with:
r 1,u
Additional informational/warning messages will be issued, and JES2 will automatically be started. JES2 will issue message $HASP426, which is asking you to supply startup options:
You have seen this message each time the Starter System was IPLed. Since this is the first time this JES2 has been started on this MVS system, you should respond:
r 2,format,noreq
to instruct JES2 to format the spool area on the SPOOL1 volume and then start operation without waiting for requests. JES2 will next issue the following error requiring a response:
This is normal because the checkpoint dataset (SYS1.HASPCKPT) on the SPOOL1 volume, has never been used. Respond:
r 3,y
and a second error message will be displayed by JES2 requiring a response:
to which you should then reply:
r 4,y
As JES2 formats the spool and processes the automatic commands in SYS1.PARMLIB(JES2PARM), a number of informational messages will be displayed. The screen should be nearly identical to:
at which 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.
Completing the SMP Environment
In order to be able to apply maintenance and modifications to the system you have built using SMP4, you must create some datasets that SMP requires. Information must then be placed in the datasets that define the status of the system as it exists at this point in time, immediately following System Generation. Later, when modifications are applied, SMP4 will use this base information to apply the maintenance.
The jobstreams to set up SMP and load the initial system environment were written by Volker Bandke, and all I have done are package them into a single jobstream here. On the Hercules' console, type the command:
devinit 00c jcl/sysgen05.jcl eof
and press ENTER. This job should take about three minutes to run. The completion codes from the six steps should be 0000. The printed output from the jobs you submit is contained in the file to which Hercules' is writing the output from MVS/JES2 PRINTER2 (the 1403 printer attached to address 00f in the Hercules' configuration file). This is a change from the Starter System, where the output was written to JES2/PRINTER1 at device address 00e. Open the file with a text editor or text viewing program. If you are following my directory structure, the file will be found in the /mvs directory and will be named prt00f.txt. Be careful that you do not alter the contents of the file if you open it with an editor. The lines in the output which indicate this are:
IEF142I SYSGEN05 DELETE - STEP WAS EXECUTED - COND CODE 0000 IEF142I SYSGEN05 ALLOC - STEP WAS EXECUTED - COND CODE 0000 IEF142I SYSGEN05 HMASMP - STEP WAS EXECUTED - COND CODE 0000 IEF142I SYSGEN05 HMASMP - STEP WAS EXECUTED - COND CODE 0000 IEF142I SYSGEN05 CLEANUP - STEP WAS EXECUTED - COND CODE 0000 IEF142I SYSGEN05 ADD - STEP WAS EXECUTED - COND CODE 0000
or, if you use condcode.pl:
Installing a Useful SMF Exit
Every MVS system I have ever worked on employed an SMF exit to report resource utilization statistics at the end of each job step. The load module called by this exit is IEFACTRT, and I have another page on this site that has a couple of versions. But, I include a jobstream here that will install the one that I use. It is totally optional, so if you don't want to install the exit, just skip this step. Perhaps the most useful feature of this exit is that it displays the step completion codes on the MVS console, allowing you to know if there is a problem with a job without opening and searching through the printed output.
On the Hercules' console, type the command:
devinit 00c jcl/sysgen06.jcl eof
and press ENTER. This job should take about one minute to run. The completion codes from the four steps should be:
IEF142I SYSGEN06 CLEANUP - STEP WAS EXECUTED - COND CODE 0000 IEF142I SYSGEN06 ADD - STEP WAS EXECUTED - COND CODE 0000 IEF142I SYSGEN06 ASM ASM - STEP WAS EXECUTED - COND CODE 0000 IEF142I SYSGEN06 HMASMP RECAPP - STEP WAS EXECUTED - COND CODE 0012
or, if you use condcode.pl:
The 0012 completion code in the final step is expected; this step first attempts to delete a prior version of the modification before applying it. Since there is no prior version, the completion code for the step is 0012.
As indicated by the message to the console during the job's execution, you must shut down MVS, re-IPL and specify CLPA for the exit to become active. Do not IPL right now ... continue with the next steps.
Installing Helpful SMF Tools
SMF (System Management Facility) collects information constantly as MVS manages your hardware and executes user programs. The amount of information collected will vary depending upon options set up in SYS1.PARMLIB(SMFPRM00). The parameters may be overridden by the operator during IPL or changes may be permanently made by editing this member. The information collected is stored in two datasets created during System Generation - SYS1.MANX and SYS1.MANY. One of the datasets is the active dataset, into which new records are written. When this dataset becomes filled, SMF will automatically switch to the other dataset and issue a message to the MVS console to indicate action needs to be taken to preserve the data in the filled dataset. At the very least, you must clear the records from the filled dataset so that when SMF fills the alternate dataset, it will be able to switch back to the original dataset to continue recording.
As the information collected can sometimes provide interesting insight into MVS' operation, I set up a system to retain the latest five sets of SMF data collected. I keep the records in a Generation Data Group on the SMP001 volume. To facilitate the transfer of the records, as well as clearing the SMF datasets after the transfer is complete, I wrote a procedure that is placed in SYS1.PROCLIB. Also, there is a user exit available from the CBT tape that can automate the entire process. For complete information about my Generation Data Group setup, my procedure, and the user exit, you can read IEFU29 here on my site. But for convenience, I collected the required jobstreams into a single job that is included in the installmvs archive.
On the Hercules' console, type the command:
devinit 00c jcl/sysgen07.jcl eof
and press ENTER. This job should take about one minute to run. The completion codes from the seven steps should be:
IEF142I SYSGEN07 IDCAMS - STEP WAS EXECUTED - COND CODE 0000 IEF142I SYSGEN07 IEBUPDTE - STEP WAS EXECUTED - COND CODE 0000 IEF142I SYSGEN07 IEBUPDTE - STEP WAS EXECUTED - COND CODE 0000 IEF142I SYSGEN07 CLEANUP - STEP WAS EXECUTED - COND CODE 0000 IEF142I SYSGEN07 ADD - STEP WAS EXECUTED - COND CODE 0000 IEF142I SYSGEN07 ASM ASM - STEP WAS EXECUTED - COND CODE 0000 IEF142I SYSGEN07 HMASMP RECAPP - STEP WAS EXECUTED - COND CODE 0012
or, if you use condcode.pl:
The 0012 completion code in the final step is expected; this step first attempts to delete a prior version of the modification before applying it. Since there is no prior version, the completion code for the step is 0012.
As indicated by the message to the console during the job's execution, you must shut down MVS, re-IPL and specify CLPA for the exit to become active. Do not IPL right now ... continue with the next steps.
Installing a PTF for SMF
If you install an IEFACTRT exit or plan to make any real use of SMF statistics, there is an APAR that you should install that corrects an error in the recording of REGION size for the step. You can download the jobstream to apply the PTF from Kevin Leonard's site http://www.j76.org/vs2/ay12275.zip. The correction alters the value stored in TCTRSZ field; without the PTF the value captured is the Private Area size instead of the Region size requested. This is a minor problem and only matters if you are seriously tracking statistics about your jobs. The condition codes for all three steps of this job should be 0000.
Configuring VTAM and TSO
VTAM and TSO are already installed on the generated MVS system, but if you want to use TSO, and you probably will, you need to install some tables and procedures that govern their operation. For detailed instructions on these procedures, visit Volker Bandke's site:
For convenience, I have put together Volker's jobstream that installs the VTAM source, VTAM/TSO procedures and VTAM/TSO parameter members, along with a final step that assembles and links the two tables into a single jobstream SYSGEN08 and included it in installmvs archive. The only modification I have made to Volker's content is to add the user TSO Help library (SYS2.HELP) to the default TSO procedure (IKJACCNT), which will be useful when you install user written TSO commands to your system.
On the Hercules' console, type the command:
devinit 00c jcl/sysgen08.jcl eof
and press ENTER. This job should take about one minute to run. The final step of this jobstream will submit a secondary job to the internal reader. The completion codes from the six steps of the first job should be:
IEF142I SYSGEN08 CLEANUP - STEP WAS EXECUTED - COND CODE 0008 IEF142I SYSGEN08 TSOKEY - STEP WAS EXECUTED - COND CODE 0000 IEF142I SYSGEN08 VTAMSRC - STEP WAS EXECUTED - COND CODE 0000 IEF142I SYSGEN08 PROCLIB - STEP WAS EXECUTED - COND CODE 0000 IEF142I SYSGEN08 VTAMLST - STEP WAS EXECUTED - COND CODE 0000 IEF142I SYSGEN08 IEBGENER - STEP WAS EXECUTED - COND CODE 0000
The completion codes from the four steps of the second job (submitted through the internal reader) should be:
IEF142I SYSGEN08 ASM BSPLIN01 - STEP WAS EXECUTED - COND CODE 0000 IEF142I SYSGEN08 LKED BSPLIN01 - STEP WAS EXECUTED - COND CODE 0000 IEF142I SYSGEN08 ASM BSPLMT01 - STEP WAS EXECUTED - COND CODE 0000 IEF142I SYSGEN08 LKED BSPLMT01 - STEP WAS EXECUTED - COND CODE 0000
or, if you use condcode.pl:
The condition code 0008 on the first step is expected if you have not run this job before, as the CLEANUP step is deleting prior versions of some libraries that will be created. The final four steps, which assemble and link the BSPLIN01 and BSPLMT01 tables, are in the secondary job that is submitted through the internal reader.
I have written some very brief instructions on Starting and Terminating VTAM and TSO.
Adding DASD Volumes
You will undoubtedly want to add more DASD volumes to your system. The procedure for this is not quite as complex as using the stand alone initialization program - IBCDASDI - which we used to set up the volumes for the target system. However you do need to create and then format the volumes. If they are to be permanent volumes, you need to add them to your VATLST member of SYS1.PARMLIB.
The steps for adding DASD volumes may be found at: Adding DASD Volumes.
Set Up User Catalogs
During the System Generation, a VSAM Master Catalog was created. It resides on MVSRES and the dataset name of the catalog itself is SYS1.AMASTCAT. All datasets that we have created at this point are cataloged in the Master Catalog. Although you can continue to catalog any new datasets you create in the Master Catalog, it is not considered a good practice and would undoubtedly not be allowed in any real world shop.
In my experience, shops set up user catalogs that group datasets either by project - payroll, accounts receivable, budget, etc - or by location, i.e. the DASD volume on which the dataset resides determines the user catalog into which the dataset is catalogued. The structure of catalogs you set up for your system is up to you, but I will describe here the way I have set mine up as a guide. Keep in mind that what I am documenting here is relevant to the status of my system as I am currently rebuilding it (and updating this documentation, as well) and may not exactly match the configuration referred to and/or documented in other pages on this site. Nor will it stay static for me ... it will change and grow as I add volumes. This is only to show you how to go about setting your own system up.
First, I should say that "behind the scenes" I have created the following DASD volumes in addition to those that were created as I went through the SMP/SYSGEN processes:
PUB001 - 3350 primarily for TSO User datasets
PUB002 - 2314 required for MVT sort to work
MVS601 - 3330-11 for system storage
MVS801 - 3380 primarily for VSAM objects
JAY001 - 3330 for private use of TSO User ID JAY001
I decided to create three user catalogs - UCPUB001 into which all datasets created on PUB001 will be cataloged, UCMVS801 into which all VSAM objects created on MVS801 will be cataloged, and UCJAY001 into which all datasets created by TSO User ID JAY001 will be catalogued. As you can see, this leaves some volumes not specifically planned for, but a JOBCAT or STEPCAT card can be utilized to select the catalog explicitly, overriding automatic catalog selection based upon Alias information. The important thing that this process is to accomplish is to set up alternatives to control unchecked use of the Master Catalog for all user datasets. The names I have chosen for the user catalogs reflect mnemonically that they are user catalogs - UC as the first two characters of the name - and indicate the connection to the datasets which will be cataloged within them with the remainder of the name. The user catalogs themselves will be cataloged in the Master Catalog.
This is the jobstream that I used to create the User Catalogs and set up Aliases for them:
/* DEFINE A DATASPACE UTILIZING ONE HALF OF THE AVAILABLE SPACE ON 3380 VOLUME MVS801, SUBALLOCATING A USER CATALOG FROM THE DATASPACE CREATED */DEFINE USERCATALOG ( - NAME (UCMVS801) - VOLUME (MVS801) - TRACKS (9944 0) - FOR (9999) ) - DATA (TRACKS (15 5) ) - INDEX (TRACKS (15) )/* DEFINE A DATASPACE UTILIZING ONE HALF OF THE AVAILABLE SPACE ON 3350 VOLUME PUB001, SUBALLOCATING A USER CATALOG FROM THE DATASPACE CREATED */DEFINE USERCATALOG ( - NAME (UCPUB001) - VOLUME (PUB001) - TRACKS (8324 0) - FOR (9999) ) - DATA (TRACKS (15 5) ) - INDEX (TRACKS (15) )/* DEFINE A DATASPACE TOTALLY ALLOCATED TO A USER CATALOG ON 3330-1 VOLUME JAY001 */DEFINE USERCATALOG ( - NAME (UCJAY001) - VOLUME (JAY001) - TRACKS (15 0) - FOR (9999) )/* DEFINE AN ALIAS TO CATALOG ANY DATASET WITH A HIGH LEVEL QUALIFIER OF 'MVS801' IN USER CATALOG UCMVS801 */DEFINE ALIAS (NAME(MVS801) - RELATE(UCMVS801) )/* DEFINE AN ALIAS TO CATALOG ANY DATASET WITH A HIGH LEVEL QUALIFIER OF 'PUB001' IN USER CATALOG UCPUB001 */DEFINE ALIAS (NAME(PUB001) - RELATE(UCPUB001) )/* DEFINE AN ALIAS TO CATALOG ANY DATASET WITH A HIGH LEVEL QUALIFIER OF 'JAY001' IN USER CATALOG UCJAY001 */DEFINE ALIAS (NAME(JAY001) - RELATE(UCJAY001) )/* //
Again, I will emphasize that I am providing this as a guide to setting up your own User Catalogs. You will have to decide what user catalogs you need for your system and prepare an appropriate jobstream using this example as a guide . If you are unfamiliar with VSAM Catalogs, I have written more about them in my VSAM Tutorial.
The next step is to modify the Master Catalog so that any changes to the catalog, such as adding new entries or modifying existing entries, will require a password. The jobstream I used for that is:
/* ALTER THE MASTER CATALOG TO REQUIRE A PASSWORD IN ORDER TO COMPLETE ANY UPDATE OPERATIONS */ALTER SYS1.AMASTCAT UPDATEPW(SYSPROG)/* //
The password, shown above in blue, may be from 1 to 8 alphanumeric characters of your choice. I want to repeat that adding password protection to the Master Catalog does not prevent you from adding (or deleting) datasets entries from it, but the password must be supplied by the operator (or in the jobstream) in order for the Master Catalog to be updated.
Adding Your Own TSO User ID
Now that I have my user catalogs set up, I added some personal TSO User IDs, since it is not really intended to use the IBMUSER ID that is installed during System Generation for anything other than adding new IDs and emergency procedures. I'm not going to repeat the instructions here, as I really have included everything in the FAQ that you could possibly need to know. So, this link will open a window to that page: How do I add new TSO User IDs?
The User IDs can be pretty much what you want, as long as they are one to seven characters long and start with an alphabetic or national ($, @, #) character. I chose JAY01, JAY02, and JAY03, for obvious reasons.
Since the default high level qualifier for datasets created by TSO Users is the TSO User ID, I needed to define aliases for the new User IDs so that any datasets I happen to create using those User IDs go to an appropriate user catalog. I will describe that process here because it introduces two new concepts that will be useful to you as you use your own MVS under Hercules. I decided that since I now have TSO up and some "working" User IDs, I would create the aliases under TSO rather than go back and modify my previously utilized batch job.
I added my new User IDs while I was logged onto TSO under the IBMUSER ID. Then I logged off and logged back on under JAY01. Why? The IBMUSER ID defaults to a region size of 44K, which is just enough to execute the ACCOUNT command. It is not enough to execute any commands or programs that utilize VSAM, which is what we need to build the aliases.
The great thing about TSO is that all the IDCAMS (that is the Access Method Services program that is the one and only, all inclusive VSAM utility program) commands can be executed directly from a TSO READY prompt. If you are not familiar with IDCAMS, you should probably first at least scan my VSAM Tutorial before you proceed, however you can always type HELP at the TSO READY prompt and the information you get interactively may be enough to get you up to speed. If you glance back at the jobstream that I used to create my user catalogs and set up the aliases to them, you can see the syntax of the commands required to define aliases. So here is the dialog as I typed the commands to create the two new aliases for the second and third new User IDs that I created:
Following the same convention I have been using for what is typed by me (or you), I have shown what I typed in red above and the responses from the system in black.
The first command - profile noprefix - tells TSO not to prepend the User ID under which I am logged on to the names it uses for datasets or, in this case, alias entries in the catalog. This setting will persist from logon to logon, which means if you issue this command to turn off the automatic prefixing, you have to reverse it yourself by using the command - profile prefix. There are other settings in the profile that you may change, and you can learn about them by typing HELP PROFILE at the READY prompt. But to continue ...
The second command line, beginning - define alias - is the required command to create an alias for the high level qualifier JAY01, which it relates to the user catalog UCPUB001. Since the alias itself is cataloged in the Master Catalog, which I set to password protect (when I set up my User Catalogs in the previous instruction above), the system prompts me for the password before it will complete the definition of the alias. I respond by typing in the password, which does not print on the screen and shows up in this captured fragment as a colon (:).
I repeat this command for the other two aliases, relating the User IDs JAY02 and JAY03 with the same user catalog - UCPUB001. And again I am asked to give the password.
So, now I have three unique TSO User IDs of my very own with which I can utilize TSO.
Clear Screen TSO Command
It is a very minor thing, but I really like to be able to clear the TSO screen prior to using a command that is going to produce a lot of output, hoping that the output will all fit on a single screen if I start with a blank screen. Of course, there is always the clear key, but I am so used to being able to type CLS to accomplish the same thing. Not to mention that with a command implementation of the clear screen function, you can also clear the screen in Command Lists that you write (or install). So I wrote a very quick, but only a little dirty, assembler routine to implement the Clear Screen command that I am familiar with under the name CLS. It is available for you here in cls.tgz [MD5: D62D77454BCE10FFEFA0B4EB4F6493C6] - which contains a single jobstream to assemble and link-edit the command into SYS2.CMDLIB and place a small help text into SYS2.HELP. All three steps of this job should receive a condition code of 0000.
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 continues to add features so there will probably continue to be new versions available. The distribution is contained on a Hercules' Emulated tape - rpf153.aws - and is available in the files area of the Hercules' Yahoo groups or from my site rpf153.tgz [MD5: AD0122C047D0301207A2C85482B94BD8]. (This archive contains both the installation tape and the RPF Users' Guide as a PDF.) The jobstream for installing RPF is contained in one of the libraries on the tape, so you will need to use an MVS job to retrieve it.
The jobstream I used may be downloaded from my site - rpfinst.jcl. This jobstream will restore the JCL library to a temporary dataset and then print and punch the installation jobstream using IEBGENER. All three steps of this job should receive condition codes of 0000. When this job completes, you will receive a message on the console from JES2:
The $HASP190 message indicates that there is punched output from the job RPFINST ready to process. In the tn3270 client window, type:
$spun1
to start the PUNCH1 device. The card images will be written to the device attached to device address 00D, which is in the file pch00d.txt in the /mvs directory. Transfer the card images to a new file in your /jcl directory. This jobstream is the one that will actually install RPF on your system. You will need to make modifications to this jobstream to customize it for your installation, specifically which User Catalog to use (or eliminate the RPF Alias if you don't use User Catalogs) and which volume serial number to place the RPF installation files on.
RPF also needs to be authorized, so you will need to modify the IKJEFTE2 table. If you don't have a user modification to do that, you can use ZUM0001.JCL which was written by Volker Bandke or you can use AMASPZAP to modify the existing table. With either approach you will have to re-IPL MVS with the CLPA option in order to made the modified table active before you can fully utilize RPF.
QUEUE
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 in some cases. A very nicely updated version of QUEUE is available from Greg Price's website: http://www.prycroft6.com.au/vs2sw/download/queue38j.zip; however for this version of QUEUE to function correctly, you also need to install two of Greg's modifications that affect TSO screen handling: ZP60008 and ZP60009. It sounds like a difficult task, but it is quite simple when you take it a step at a time:
- Using the links in the paragraph above, download and unpack the three jobstreams from Greg's website - queue38j, zp60008, and zp60009.
- Submit the jobstream for ZP60008. All steps should receive zero completion codes.
- Submit the jobstream fro ZP60009. Expect final step of this job to receive a completion code of 4, caused by expected warnings during linking; all other steps should receive zero completion codes.
- Edit the queue38j jobstream:
- If PDSLOAD is not installed on your system, change the EXEC card from PGM=PDSLOAD to PGM=IEBUPDTE,PARM=NEW, otherwise change the SYSIN DD card name to SYSUT1;
- Modify the DD cards for the GREG.QUEUE.ASM and GREG.QUEUE.OBJ datasets to comply with your system's DASD and catalog (the high-level qualifier GREG probably will need to be different on your system).
- Submit the jobstream for queue38j to create the <hlq>.QUEUE.ASM and <hlq>.QUEUE.OBJ datasets and load the <hlq>.QUEUE.ASM PDS.
- TSO needs to be up for the next two steps, but you can start VTAM and TSO at this time, even if you have not shut down MVS and re-IPLed with CLPA.
- Edit (using either TSO Edit or RPF) the jobstream contained in the member C of the <hlq>.QUEUE.ASM dataset:
- Change all occurrences of the <hlq>.QUEUE.ASM and <hlq>.QUEUE.OBJ dataset names to match the changes you made in the dataset names of the queue38j jobstream;
- Change the dataset name in the SYSLMOD DD card of the last step to point to a valid load library on your system - SYS2.CMDLIB if you have defined it, otherwise SYS1.CMDLIB will work.
- Submit the jobstream contained in the member C of the <hlq>.QUEUE.ASM dataset to assemble and link edit the QUEUE program.. All steps should receive zero completion codes.
- Shut down your MVS system and re-IPL, specifying R 0,CLPA at the prompt IEA101A SPECIFY SYSTEM PARAMETERS FOR RELEASE 03.8 .VS2.
Add TSO Control Variables
Another modification from Greg Price is useful if you intend to write TSO Command Lists (CLISTs). It will add nineteen control variables and extensions to built-in functions, including extra date and time functions, new environmental variables and a facility to allow the trapping of line mode output into CLIST variables. Like Greg's version of the QUEUE command (above), there are some pre-requisite PTFs that will need to be added. But I have already packaged them for you into a single jobstream/tape. So you only need to download Greg's jobstream: http://www.prycroft6.com.au/vs2mods/download/zp60014.zip and the pre-requisite PTFs: preqptfsGP.tgz [MD5: FA0C97EA2B05DCCC92FF0D3548AC7F87] Unpack the archives and then:
- Submit the jobstream - APPLYPTF - and mount the tape image - mvsptfs.het - to apply the fifteen PTFs. Expect a non-zero completion code from the REJECT command (which is there only to in the event you need to rerun the job), a non-zero completion code from the RECEIVE command (some of the corequisite PTFs have been superceded), and zero from the APPLY command.
- Submit Greg's jobstream to apply his modifications - zp60014.jcl. All completion codes from the steps of this job should be zero.
- Shut down your MVS system and re-IPL, specifying R 0,CLPA at the prompt IEA101A SPECIFY SYSTEM PARAMETERS FOR RELEASE 03.8 .VS2.
You can read about the added TSO variables and functions in the preamble text of the ZP60014 jobstream.
DATE TSO Command
As I was adding TSO Command processors from the CBT tape, 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:
date
DATE = TUESDAY, AUGUST 5, 1975 (1975/217)
TIME = 19.28.51
READY
The jobstream to assemble and link-edit the DATE TSO Command is date$.jcl and is in the archive: date.tgz [MD5: A934511FF7EC87E98AB80A1C9A2AF1D1]. It requires my date routines, so if you haven't got them, grab them from Y2k The jobstream to install the date routines will need to be customized for your system; it creates a source library PDS and a load library PDS and assembles the routines into the load library. The date$.jcl jobstream will assemble and link-edit DATE into SYS2.CMDLIB with a simple help text into SYS2.HELP. Make sure the Y2k routines load library PDS where you assemble the Y2k routines matches the SYSLIB DD in the date$.jcl.
If you are a careful observer, you can see from the output in my example above that I run my system with the 1928 EPOCH, since it really isn't that important to me that the year be displayed as 200?. Also, there is a small chance that some obscure piece of code somewhere deep inside MVS, or one of the programs I am running under MVS, will seriously dislike discovering it is running in a post-2000 world. However, if you wish to run in the current year, you will also need to apply a patch to a couple of TSO modules that was provided by Michael Koehne (http://groups.yahoo.com/group/hercules-390/message/13774). You can download the JCL from here - TSOY2K.JCL - or copy/paste it from the message. As noted in the message, you will need to shutdown and re-IPL with the CLPA option before the zapped code becomes active.
JES2 Mod to Add Two Console Commands
I had been lamenting the lack of the ability to "re-queue" JES2 output from one class to another for a long time. I even asked on the lists if anyone knew of a command to do what I wanted, since I simply couldn't believe there wasn't a way to do it. It turns out that on later versions of JES2 there is a way, just not on our more vintage version. So I was delighted when I was going through some old files and found this modification to add a couple of really useful commands to JES2. I haven't been able to find the source of the mod, but the ID is WM00017, and from that I think that it was originated by William Mosteller since I know he produced a lot of widely disseminated JES2 modifications.
Both of the commands are really useful and since adding them to my system, I don't know how I got along without them. The first command adds a new way to display output:
The $DP command lists output for batch jobs, started tasks, and TSO Users. It shows the job/stc/tsu number, which makes using additional JES2 commands to modify the output easier. Plus it shows the number of lines in the job. You can specify a class with the command - $DPa - to limit the output to a single class; without a class specified it defaults to listing all output classes.
The second command gives you the capability to requeue output to a different class:
The job/stc/tsu output to be selected may be specified as a jobname (as in my example above) or by the job/stc/tsu number. If you use a number, you may specify a range of numbers, as in other JES2 commands. The o= operand specifies the class the output is currently queued in, and the c= operand specifies the class to which the output is to be changed.
The jobstream to apply this modification to JES2 is available in jes2mod.tgz [MD5: A492061F350D1D96EE9E7E445A38C29A], and it uses SMP4 to apply the modification. The modification was originally for a version of JES2 without 3800 enhancements (FMID EJE1102), but I verified that the source modified matched our version of JES2 that has the 3800 enhancements (FMID 1103) and it matched perfectly. As usual when applying major modifications to your system, you should backup the entire set of DASD images for your system before applying them.
Once the modification is applied, you will need to bring JES2 down and then restart it before the new commands will be available.
Submitting Jobstreams from PC to Hercules (via Socket Reader)
If you intend to mainly work from TSO and RPF once you get MVS 3.8j set up, the jobstreams you will be submitting to MVS by way of a defined card reader will probably be minimal. However, if you plan to maintain JCL in datasets on your host PC and submit them through a card reader to JES2, you may want to use a system similar to the one I employ. Because of the length of the topic, I have placed it on a separate page: Submitting Jobstreams via Socket Reader.
What Next?
Well, if you made any of the modifications above that need an IPL and have not already done so, this would be a good time. You should know by now how to shut down JES2 and MVS in an orderly fashion - $pjes2/z eod/quesce -, so I will not repeat those details here. After it is properly shut down, re-IPL and specify CLPA to rebuild the LPA. Any modifications you have made that require this for activation will then be functional.
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.
You might look at the Compilers page on my site and add one or more compilers for a language and try writing some programs.
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.
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 19, 2010 .