After an IPL, the default for message handling is "manual deleting"; all messages remain on the MVS console screen until the operator issues a command to delete them. A more usable solution is to have MVS automatically scroll (delete) older messages that do not require operator response in order to make room for newer messages. In the MVS command input area, type the command:
which will cause MVS to echo to the command input area the command:
Change DEL=N to DEL=RD (specifies that messages not requiring operator action are to be automatically rolled off the console screen), CON=Y to CON=N (cancel conversational message deletion), and RTME=046 to RTME=001 (set the interval between message updating to 1 second), and press ENTER to set the new parameters in effect.
You can set any of the Program Function Keys to valid MVS console commands, so that frequently used commands may be entered simply by pressing the appropriate Program Function Key. The command:
K N,PFK=(n,CMD='command text'),CON=N
where n specifies the PFKey number (1, 2, 3, ... 12) and command text specifies the command to be sent to MVS when the PFKey is pressed (the single quotation marks are required). The PFKey settings will persist from IPL to IPL, so it is not necessary to set the same PFKey again unless you wish to assign a different command text to it.
To display the current settings, use the command:
You can also use the program SETPFKEY to set your console PF Keys at IPL time.
To display all DASD volumes currently offline (which will include the device addresses where DASD may be mounted), use the command:
The display you will receive will be similar to:
IEE450I 14.36.41 UNIT STATUS FRAME 1 F E 1A UNIT TYPE UNIT TYPE UNIT TYPE UNIT TYPE UNIT TYPE UNIT TYPE UNIT TYPE 121 2314 122 2314 123 2314 124 2314 125 2314 126 2314 127 2314 132 3330 133 3330 134 3330 135 3330 136 3330 137 3330 140 3340
To display all DASD volumes currently online, use the command:
The display you will receive will be similar to:
IEE450I 14.41.33 UNIT STATUS FRAME 1 F E 1A UNIT TYPE STATUS VOLSER VOLSTATE UNIT TYPE STATUS VOLSER VOLSTATE 120 2314 O PUB002 PUB/RSERV 130 3330 O WORK01 PUB/RSERV 131 3330 O JAY001 PRIV/RSERV 150 3350 S MVSRES PRIV/RSDNT
Under STATUS, the values that may appear are: O (online), S (system, or IPL volume), or A (active). The values that may appear under VOLSTATE relate to the entries coded in the VATLST or that were entered when the MOUNT command was issued; the first value may be: PUB (public), PRIV (private), or STRG (storage); the second value may be RSERV (reserved), or RSDNT (permanently resident).
To display all TAPE volumes, use the command:
IEE450I 15.03.33 UNIT STATUS FRAME 1 F E 1A UNIT TYPE STATUS VOLSER VOLSTATE UNIT TYPE STATUS VOLSER VOLSTATE 310 3400 O /REMOV 311 3400 O /REMOV 312 3400 OFFLINE 313 3400 OFFLINE
Under STATUS, the values that may appear are: O (online), or OFFLINE (offline, of course). The values that appear under VOLSER and VOLSTATE are shown only for units on which AWS tape volumes are mounted and are derived from the entries in JCL and the tape VOL1 label.
The above commands will probably yield several pages of output, with the entries displayed in ascending UNIT address order. To display the next page of output, use the command:
To terminate the display and erase the area the output occupied, use the command:
Volker Bandke has put together a great list of this and other MVS console and JES2 commands at http://www.bsp-gmbh.com/hercules/oscmds.html.
Answers supplied by Phil Roberts and Jack Schudel in the Hercules MVS forum:
r 00,dump to produce a system dump r 00,snap to produce a snap dump r 00,purge
to shutdown JES2
You must connect a tn3270 client to each of the terminal addresses that you intend to use for VTAM/TSO prior to IPL, or you may experience this. Also, sometimes after logging off a TSO session, VTAM will "lose" the terminal. Either of these is indicated if you do not see the Network Solicitor message on the terminal:
THIS TERMINAL IS LOGGED ON TO THE NETWORK SOLICITOR
On the MVS console, enter these two commands:
substituting the correct last digit of the terminal's hardware address for the x. The terminal should then show the Network Solicitor message and be available to log on to TSO.
This message is issued whenever JES2 is approaching 100% utilization of one of its resources and may be one of several. The particular resource is indicated in the text of the message, such as:
JQE - Job Queue Elements
JOE - Job Output Elements
SMFB - System Management Facilities buffers
It is not a good idea to allow JES2 to completely exhaust resources, as that will often result in a deadlock situation, i.e.. the shortage will prevent you from resolving the shortage and your only recourse is to re-start JES2 with a cold-start, losing any jobs that are in process.
The amount of each of JES2 resources to provide is specified in the JES2 parameters, which is in the SYS1.PARMLIB(JES2PARM) if you have built your system utilizing my instructions. To verify the location of your JES2 parameters, locate the HASPPARM DD statement in the JES2 procedure in SYS1.PROCLIB, which points to the location of the active JES2PARM.
Edit the member, either with TSO edit or with IEBUPDTE, to increase the allocation for the resource which is nearing full utilization and cycle JES2 - shut down JES2 and restart it.
You can immediately alleviate the shortage in JQE and JOE by purging some of the jobs from the queue. Use the $DN, $DF, or $DP commands to view jobs awaiting output and then use $P to purge unneeded jobs. You can also use the QUEUE command under TSO to review and selectively delete jobs from the queue.
To delete all output from TSO User sessions, enter $PT1-9999. To delete all output from started tasks, enter $PS1-9999. If you are sure there is no batch job output on the queue that you need, you can delete all output from batch jobs by entering $PJ1-9999.
This fairly nasty looking message is issued following the entry of the z eod command on the MVS console and is the result of the IEFU29 user exit being applied to the system. The short explanation is that the exit is attempting to start a job in the background but since the system has just been shut down (z eod is the command issued to initiate an orderly system shutdown at end of shift/workday/etc) the job cannot allocate needed resources. There is no way to prevent this message and have the advantages the user exit provides, so the only recourse is to cringe and ignore the message. No harm will be done and no data will be lost. On the next IPL, SMF will continue to write new records into the same dataset. When the dataset does fill up, the SMF dataset switch will be performed, the system won't be in the process of shutting down, and the job will run to save the SMF data properly. You can read more about the IEFU29.
Update 08/2004 - There is a fix for this that is applied to the code for IEFU29 now available at the IEFU29 link.
It means that there are so many console messages pending that 80% of the buffers allocated for Write To Operator messages are in use. It is doubtful that you could have operated MVS with messages pending on the master console (the 3270 attached to device address 010) long enough to fill 80% of the buffers, so a good assumption is that the alternate console has not be set up to roll delete messages not requiring attention. Switch to the tn3270 client attached to the alternate console (device address 011) and press the PFKey to which you assigned the command to set the message display to roll delete.
If you continue submitting jobs without attending to this right away, you could find the system halted because all of its WTO buffers are full.
Sometime around version 3.00 of Hercules, the behavior of tape devices under MVS changed. Tape devices defined in the configuration file were marked as "offline" by MVS 3.8j during IPL. The first time a job requires a tape device, in a series of messages will be displayed similar to this:
IEF244I TAPEMAP TAPEMAP - UNABLE TO ALLOCATE 1 UNIT(S) AT LEAST 1 OFFLINE UNIT(S) NEEDED. IEF489I TAPEMAP - 1 UNIT(S) NEEDED FOR SYSUT1 IEF247I TAPEMAP - 310,311,312,313,314,315,316,317 OFFLINE *03 IEF238D TAPEMAP - REPLY DEVICE NAME OR 'CANCEL'.
Of course, you can resolve this by issuing a VARY command to bring one (or more) of the configured tape drives online and then respond to the outstanding message with the address of the now available drives. In fact, you can simply respond to the outstanding message with the address of an offline, but otherwise available, drive. A more practical solution is to setup your MVS initialization to bring the configured drives online at IPL automatically.
There are two places the commands to accomplish this task may be placed.
The first is the COMMND?? member of SYS1.PARMLIB. If you do not already have this member set up, you will need to edit two members of the SYS1.PARMLIB partitioned dataset. The member IEASYS00 needs to contain a line pointing to the COMMND?? member:
CMD=00, AUTO COMMANDS: COMMND00
CMD=00 specifies that the command member suffix is 00, resulting in the full name of the command member: COMMND00. Note the comma, which indicates that there are additional commands following this one in the IEASYS00 member. During IPL, lines are processed from this member until a line is encountered which is not terminated with a comma, so you must be careful in editing the IEASYS00 member to avoid having an MVS that will not IPL. Everything following the space after the comma is treated as a comment. If you already have a CMD= statement in your IEASYS00, all you need do is edit the existing COMMND?? member, adding your commands to any already existing.
Create (or edit) the COMMND?? member pointed to from the IEASYS00 member and insert a VARY command:
inserting the address of one or more tape drives defined in your configuration file between the parentheses. In my system, the two tape drives I have defined are 310 and 311, as shown in the VARY command above.
The second place that the VARY command may be placed, and the one I prefer, is in the JES2 parameters. Locate the JES2 parameter file being utilized by your system. To ensure that you edit the active set of parameters, look at the JES2 member in SYS1.PROCLIB and locate the dataset name in the HASPPARM DD statement. That is the dataset, and member, you need to edit. On my system, it is the JES2PM00 member of SYS1.PARMLIB. Locate the automatic operator commands, which are usually segregated together near the end of the member. Insert a VARY command:
again substituting the address(es) of your defined tape drives in the command.
Once you set up this automatic command, your tape drives will be online following each IPL.
Grzes Plucinski has written a program to do this (see message posted on Hercules-390 discussion list: http://groups.yahoo.com/group/hercules-390/message/37861). You will need to complete four steps to implement this on your system:
Here is an IEBCOPY jobstream that will restore the load module to SYS2.LINKLIB (if you don't have SYS2.LINKLIB defined, you may alter the JCL to use SYS1.LINKLIB):
//IEBCOPYR JOB (001),'RESTORE HERCCMD',CLASS=A,MSGCLASS=A //RELOAD EXEC PGM=IEBCOPY,REGION=1024K //SYSPRINT DD SYSOUT=* //TAPEIN DD UNIT=TAPE,DISP=OLD,DSN=GRZES.HERCCMD, // VOL=SER=DHRCMD,LABEL=(,SL) //LIBOUT DD DISP=SHR,DSN=SYS2.LINKLIB //SYSUT3 DD UNIT=SYSDA,SPACE=(80,(60,45)),DISP=(NEW,DELETE) //SYSIN DD * COPY INDD=TAPEIN,OUTDD=LIBOUT /* //
Here is an IEBUPDTE jobstream that will catalog the procedure to execute the HERCCMD program as a Started Task from the MVS console:
//IEBUPDTE JOB (001),'HERCCMD PROC',CLASS=A,MSGCLASS=A //IEBUPDTE EXEC PGM=IEBUPDTE,REGION=1024K,PARM=NEW //SYSUT2 DD DISP=SHR,DSN=SYS2.PROCLIB //SYSPRINT DD SYSOUT=* //SYSIN DD DATA,DLM='$$' //HERCCMD PROC CMD=MISSING //HERCCMD EXEC PGM=HERCCMD,PARM='&CMD' ./ ENDUP $$ //
You need to add a line to your Hercules' configuration file to enable DIAG 8 commands:
You should also be aware of the security ramifications of enabling this feature of Hercules:
When set to enable, commands issued through diagnose 8 will be executed by hercules as hercules commands. When set to disable, commands issued through the diagnose 8 interface will be ignored. The default is disable. Note that when this feature is enabled, systems running under hercules can even issue host commands through the hercules sh command. Enabling this feature may have security consequences.
An example of the use of the command - when a tape mount is requested, you can issue an MVS Start command to execute the catalogued procedure to send a devinit command to Hercules:
*IEC501A M 311,000001,BLP,6250 BPI,TAPEMAP,TAPEMAP
S HERCCMD,CMD='devinit 0311 tape/cobol.het'
$HASP100 HERCCMD ON STCINRDR
$HASP373 HERCCMD STARTED
HERCCMD - CMD : devinit 0311 tape/cobol.het
HERCCMD - SECURITY PRODUCT UNAVALIABLE, UNABLE TO CHECK AUTH
HERCCMD - RESP : Mounted tape tape/cobol.het
HERCCMD - RESP : HHCTA998I Device 0311 : tape/cobol.het is a Hercules Formatted Tape
HERCCMD - RESP : HHCPN098I Device 0311 initialized
$HASP395 HERCCMD ENDED
You could also insert into a jobstream a step executing HERCCMD to pre-mount a required tape before a step in which the tape is to be used.
Although it is not always the case, there are some JES2 options (specified either through the MVS console or through the parameter member contained in SYS1.PARMLIB pointed to by the JES2 JCL procedure) which affect the allocation of the SPOOL file (the primary dataset where JES2 stores job information). When these parameters are changed, it is necessary to FORMAT the SPOOL dataset before JES2 can be started. If you attempt to start JES2 without specifying FORMAT or COLD and parameters have been changed requiring FORMAT, JES2 will assume that you intended to do a COLD START and message $HASP436 will be issued asking you to confirm that you wish to format the SPOOL dataset. Since JES2 will be unable to start without formatting the SPOOL dataset, you have little option other than to proceed, but note that formatting the SPOOL dataset will cause the loss of any held SYSOUT data or jobs held awaiting execution.
Most of the questions similar to this asked on the Hercules' forums arise from problems encountered when JES2 is first starting after an IPL of MVS.
First some background about JES2 initiation. JES2 is initiated near the end of the IPL process. The exact format of the Start command issued "under the covers" to initiate JES2 will vary depending upon how your system was generated, but regardless of the command issued, a procedure that resides in SYS1.PROCLIB is executed as a started task to initiate JES2. This procedure is usually stored in the member SYS1.PROCLIB(JES2), but like almost everything about an MVS installation, it may be altered to suit an individual installation. Many of the parameters which govern the operation of JES2 are read from a "card image" dataset when JES2 is first initiated. To determine the name of this dataset in your installation, examine the JCL stored in the SYS1.PROCLIB(JES2) member. The DD name for the parameter dataset is HASPPARM. On my system it is necessary to do some substitution of symbolic variables of the cataloged procedure in order to determine that the dataset from which the parameters is read is SYS1.PARMLIB(JES2PM00). It is also evident that there is no default PARM value supplied in the catalogued procedure.
If the problem you are attempting to recover from is caused by a damaged spool or checkpoint dataset, you can usually start JES2 manually from the system console with an override parameter to format the spool, thereby resulting in a usable JES2 system. Note that the contents of the spool (unprocessed and held jobs, print and punch output) will be lost. If it is still executing, you must first terminate the JES2 that encountered the problem, which may require a reply of 'TERM' or 'PURGE'. Then enter the command:
to start JES2 and have it format the spool dataset(s) and begin execution with no further prompts to the console.
If you have changed values for some of the parameters in the dataset pointed to by the HASPPARM DD to invalid values and failed to backup the working set of parameters, you will need to use a standalone editor, such as ZZSA, to correct the erroneous values. Of course, the proper way to make changes to the JES2 parameters avoids this and allows you a recovery path in case of errors. To safely make changes to the JES2 parameters, make a copy of the current JES2 parameters in another member of SYS1.PARMLIB (or the dataset which holds the parameters in your MVS installation). Make the changes to the copy you have created, not to the original. Shut down all executing jobs and then JES2, then execute JES2 with an override to access the modified copy of the parameters. For example, on my system if I copied the parameters to SYS1.PARMLIB(JES2PM01), I would use the command:
to restart JES2 and use the newly modified parameters by overriding the default member name (specified by the symbolic variable M). If everything works satisfactorily I can then replace the contents of SYS1.PARMLIB(JES2PM00) with the contents of SYS1.PARMLIB(JES2PM01) and the next time MVS is IPLed, the new version of the parameters will be read without needing an override from the console. Note that the exact command used to override the value of the parameter dataset on your system may not be the same as on my system. Check the contents of the catalogued procedure used to initiate JES2 on your system before proceeding.
If you are making frequent changes to the JES2 parameters, you probably should keep a series of members utilizing a naming scheme that will allow you to associate each properly functioning set with a particular member. That would allow you to always revert to a former functional point by specifying a particular member name from a start command issued from the console -- simply substitute the correct member name in the M= value in the start command.
This is a question I received in an email:
I took a job off the internet that someone else had built and submitted it without changing the class to something that I actually and initiators for. Since I couldn't figure out what was wrong, I submitted it again. And again. And, well, again. Finally, I figured out what my problem was but now I'm stuck with four identically named jobs sitting with CLASS=Y and I can't make them go away. If I type $c'jobname' it comes back and lists the 4 jobs and says 4 jobs found. Duh! How do I cancel these jobs?
Since there are also other ways to end up with jobs with duplicate names submitted to an MVS system, this is a good question to know the answer to. Before you can do anything about jobs with duplicate names, you have to know the job number JES2 assigned to each of the jobs. In order to get that, you use the following command:
which modifies the manner in which JES2 presents information about jobs on the console. Specifically, it causes JES2 to include the job number in the messages regarding jobs displayed on the console. Note that this is a console specific command ... that is, the c1 in the command indicates that this change is to affect only the output to the main console (c1). Here is snapshot showing the effect of this command:
After issuing the set command ($t ...) the JES2 job number will be included on the left side of any message regarding a JES2 job, as you can see in the second response to the $d command above. Now you can cancel any or all of the duplicate jobs by using the JES2 job number in a cancel command, such as:
Or, if the problem is that the class on the job card doesn't match an active initiator on your system, you can alter the class of the job by using the command:
I recently received a question from someone who was attempting to access an AWS tape image under MVS 3.8 and they received this message when they varied the emulated drive online (V cuu,ONLINE). Their Hercules' configuration file had been modified to add a line for the emulated 3420 tape drive, Hercules was started, and the Hercules' DEVINIT command was used to assign an AWS tape image file to the address established in the Hercules' configuration file. When the VARY command was issued on the MVS console, the IEE3131I message was issued and MVS refused to have anything to do with either the drive or the AWS tape image "mounted" thereon.
MVS, or for that matter any of IBM's mainframe Operating Systems, require that all devices that are to be present during IPL, or that are attached and varied online after IPL, be defined during the System Generation process that installed the load modules for the Operating System. It is not acceptable to simply pick an address out of the air and set the emulated device up in Hercules for that address. Yes, Hercules will accept the definition, either from the configuration file or via the attach command, and a devinit command will show that Hercules can open the specified file. But MVS will not know how to handle the device and you will receive IEE3131I.
Regardless of whether you generated your own MVS 3.8 and have forgotten the devices you set up or you are running an MVS 3.8 that you acquired from someone else, you can use the D U console command to display the addresses generated for the running MVS 3.8 system for a particular device class. For tape devices, use D U,TAPE:
d u,tape IEE450I 16.02.36 UNIT STATUS FRAME LAST F E 1A UNIT TYPE STATUS VOLSER VOLSTATE UNIT TYPE STATUS VOLSER VOLSTATE 310 3400 O-NRD /REMOV 311 3400 O-NRD /REMOV 312 3400 OFFLINE 313 3400 OFFLINE 314 3400 OFFLINE 315 3400 OFFLINE 316 3400 OFFLINE 317 3400 OFFLINE
and for disk devices, use D U,DASD:
d u,dasd IEE450I 16.04.16 UNIT STATUS FRAME 1 F E 1A UNIT TYPE STATUS VOLSER VOLSTATE UNIT TYPE STATUS VOLSER VOLSTATE 120 2314 O PUB002 PUB/RSERV 121 2314 OFFLINE 122 2314 OFFLINE 123 2314 OFFLINE 124 2314 OFFLINE 125 2314 OFFLINE 126 2314 OFFLINE 127 2314 OFFLINE 130 3330 O WORK01 PUB/RSERV 131 3330 A JAY001 PRIV/RSERV 132 3330 OFFLINE 133 3330 OFFLINE 134 3330 OFFLINE 135 3330 OFFLINE 136 3330 OFFLINE 137 3330 OFFLINE
Any of the device addresses indicated to be OFFLINE are generated in the system and available to have Hercules emulated devices attached in order to access data files.
There are several Display commands - example: d u,dasd - that will result in the messages already visible on the console to be shifted upward so that a pagable display area is created on the lower portion of the console screen. Frequently these display commands will result in more information than it is possible to view in that output area. In order to display the next page in the display, use the command:
When you are finished viewing the output produced by the Display command, you should clear the lower portion of the screen in order to return the full screen for use in displaying system/program messages by using the command:
I hope that you have found my instructions useful. If you have questions that I can answer to help expand upon my explanations and examples shown here, please don't hesitate to send them to me:
Return to Site Home Page
This page was last updated on January 17, 2015 .