MVS Frequently Asked Questions

System Generation/Setup/Modification

How do I clear SYS1.LOGREC?

There have been several posts to the list describing problems when SYS1.LOGREC fills, either during the SMP process, the System Generation process, or during normal operation.  SYS1.LOGREC is the dataset where MVS records information about hardware failures.  

A frequent cause of SYS1.LOGREC filling seems to be when an incorrect name is entered on the Hercules' console to submit a jobstream file to the reader device.  The failure to open the (incorrect) file is reported as an equipment check to MVS, and Hercules loops until a valid file name is entered.  The flood of equipment checks being recorded by MVS can quickly fill the SYS1.LOGREC dataset.

Regardless of why or when your SYS1.LOGREC dataset fills up, the solution is to run IFCDIP00 to clear and re-initialize SYS1.LOGREC.  The following jobstream may be submitted either on the starter system or on the generated MVS 3.8 system to accomplish this.  Note that you may need to change the unit and volser parameters to match the system on which you are submitting this job.

//IFCDIP00 JOB CLASS=A,MSGLEVEL=(1,1),MSGCLASS=A                      
//IFCDIP00 EXEC PGM=IFCDIP00                                          
//             VOL=SER=MVSRES,          <-- CHANGE TO SYSRES VOLSER
//             UNIT=3350                <-- CHANGE TO SYSRES UNIT

How do I change the System ID?

The System ID that appears in SMF records and on the page separators of SYSOUT listings may be set in a couple of places.  Most often the parameter is omitted from the JES2PARM (in SYS1.PARMLIB) so that JES2 uses the value the SMF parameters (SMFPRM00 in SYS1.PARMLIB).  The line:


in SMFPRM00 specifies the four character string that is used for the System ID.  Edit this line in SMFPRM00 and change the value.  The change will become effective after the next IPL.  It is also necessary to format the JES2 SPOOL dataset when the System ID is changed -- when starting JES2, reply 'FORMAT,NOREQ' instead of 'NOREQ', which is the normal response for a WARM start.

How do I change the DASD volumes mounted at IPL time?

Or perhaps more accurately, how do I designate the storage class to which each volume mounted at IPL is to be assigned?

During IPL, the contents of the VATLSTxx member (the Volume Attribute List) in SYS1.PARMLIB determines the storage class to which each DASD volume online at IPL time is assigned.  The default member name used is VATLST00, although that may be overridden by the VAL=xx specification in the IEASYS00 member of SYS1.PARMLIB.

 Each line of the VATLSTxx member specifies the volume serial number of a DASD volume.  If a matching volume serial number is online at IPL time, the storage class of the volume is determined by the values coded in the VATLSTxx member.  The format of each line in the VATLSTxx member is:

Columns Specifies
1 - 6 Volume serial number
8 Mount attribute; where 0 specifies permanently resident and 1 specifies reserved
10 Use attribute; where 0 specifies STORAGE, 1 specifies PUBLIC, and 2 specifies PRIVATE
12 - 19 DASD type; 2311, 2314, 3330, etc.
21 Mount message suppression; where N specifies no message is to be issued if the volume is not online and [blank] or any character other than N specifies that a message requiring operator action is to be issued if the volume is not online.

Any volumes mounted that do not have a corresponding entry in the VATLST member will be assigned to the storage class PUBLIC.

The operational effect of the three storage classes are:

How is the date and time set in Hercules/MVS?

The ultimate source of the date/time is the system clock of the PC on which Hercules is running.  However, the date/time reported by MVS is affected by settings in the Hercules' configuration file and the PARMTZ member in  SYS1.PARMLIB.  Continue reading with the next question ...

Is MVS compatible with dates beyond 2000?

The answer to this one seems to be "yes" and "no", depending upon what experience you are willing to operate with.  In past discussions in the Hercules' groups there has been some concern that there may be some components of MVS and/or third party applications that are unable to correctly interpret dates past 2000.  However, some members of the Hercules' group seem to be successfully using MVS 3.8 with the date set to the current date.

The safe option seems to be to use the SYSEPOCH entry in the Hercules' configuration file to select an origin year that modifies the year portion of the PC date passed to MVS such that the month and day reported to MVS will correspond to the same type of year as a pre-2000 year (leap year or non-leap year).  An entry of:


will cause the year 2000 to be reported to MVS as 1973, year 2001 to be reported as 1974, and so on.  This will result in a correct display of the month and day, as well as correct day of week.  Only the year will be incorrect.  But, all circa 1970's software that you run under MVS 3.8 will be assured of working correctly.  The wonderful thing about Hercules and the guest operating systems that may be installed under it is, it is your own system and you get to make the decisions about how to operate it.  If you wish to run Hercules/MVS 3.8 in the current year, use an entry of:


or change the line to a comment.  Using this setting, you should expect to see some dates in the 1900's.  If you encounter problems running MVS with a current year, I encourage you to post your experiences on the MVS or Tur(n)key MVS discussion lists.

It is possible to specify a time zone offset in the Hercules' configuration file, such that the time reported by MVS will match your geographical timezone.  However, the more correct way to handle the time issue is to specify the Hercules' configuration offset as 0000, and include the PARMTZ member in the SYS1.PARMLIB to set the time zone offset.  Following this scheme, the Hercules' configuration entry will be:


and you need to create SYS1.PARMLIB(PARMTZ) with the format:


where d is the direction of your geographical time zone from GMT (W or E) and nn is the number of hours.  For a complete discussion of this parameter, see the page at Tommy Sprinkle's site:

How can I eliminate the prompt for SMF parameters during IPL?

During IPL, the SMF parameters that are read from SYS1.PARMLIB(SMFPRM00) are displayed on the console and a prompt is made to allow the operator to modify them.  There are rarely changes necessary to these parameters, and the IPL process can be made more convenient by eliminating this unnecessary interaction.  Edit (with TSO) or use IEBUPDTE to modify the line of the SMFPRM00 member which reads:


changing OPI=YES to OPI=NO. Note that there is a comma following the end of the parameter!

How do I clear the SMF dataset(s)?

SMF (System Management Facility) records information about the operation of MVS in two datasets - SYS1.MANX and SYS1.MANY - that were allocated during System Generation.  Depending upon the options set in the SMFPRF00 member of SYS1.PARMLIB, the amount of data collected by SMF and, consequently, the number of records written to the dataset can be none, a relatively small amount, or a very large amount.  

There are two datasets so that when one becomes filled, the system automatically switches to the other and the message:


(where MANx will refer either to MANX or MANY) is displayed on the console so that the operator can submit a job to (optionally save) and clear the dataset that has become filled.  If the dataset which has been filled isn't cleared before the second dataset is filled, and the system needs to automatically switch again, SMF data will be lost.  

If you just want to clear the dataset without regard to what happens to any data collected in the datasets, this jobstream may be submitted:

//* ***************************************************************** *
//* CLEAR SYS1.MANX AND SYS1.MANY                                     *
//* ***************************************************************** *
//SYSIN     DD *

You will need to edit the jobstream and change the ? in the DSN parameter of the DUMPIN DD statement to which ever of the two SMF datasets has been identified in the IEE362A message as being filled.

If you want to set up a user exit to capture the SMF data, as is usually done in a real MVS system, look at my instructions for SMF Exit 29.

How can I print errors logged to SYS1.LOGREC?

The IBM utility program IFCEREP1, included with MVS, can be used to select and print information recorded in the SYS1.LOGREC dataset.  This jobstream will print all records:

//IFCEREP1 JOB (001),'EREP LOG UTILITY',             
//             CLASS=A,MSGLEVEL=(1,1),MSGCLASS=A     
//ACCDEV   DD  DUMMY                                 
//TOURIST  DD  SYSOUT=A              
//EREPPT   DD  SYSOUT=A              
//SYSIN    DD  *                                     

IFCEREP1 may also be used to offload the information collected from SYS1.LOGREC to tape or another disk dataset, and may be subsequently used to produce reports from these datasets.  In a production MVS system, IFCEREP1 would most likely be used once each day or once each shift to offload the contents of SYS1.LOGREC and then clear SYS1.LOGREC.  The details of the parameters that may be specified for IFCEREP1 can be found in the IBM publication:  EREP Users's Guide and Reference. 

How can I increase the time interval before TSO automatically logs off my session because of inactivity?

This question was asked in July, 2002 in the Hercules MVS forum (msg #1846) and was answered by Volker Bandke, Ken Hall, Jay Maynard, and Phil Roberts. To summarize their answers, the interval may be changed by these methods:

  1. Change the JWT value in the SMFPRMxx member of SYS1.PARMLIB (see  Note that this will affect tasks other than TSO users.
  2. Change the TIME parameter on the EXEC statement in the logon procedure in SYS1.PROCLIB.  It is possible to create multiple logon procedures with different TIME values.  The logon procedure utilized is associated with the TSO User ID when it is created by the 'PROCNAME' parameter of the ADD subcommand of the ACCOUNT command.  It may be changed with the CHANGE subcommand of the ACCOUNT command.

Sam Golob wrote an article in Technical Support magazine about this situation in June, 1997 and may be read online at the link: t9706009.pdf.

Where is the source for the MVT Compilers?

The source for the language compilers is contained in the OS360 source archive.  The relevant directory names are:

What determines where a program load module should reside?

The overwhelming consensus of System Programmers seems to hold the first rule of maintaining an Operating System is to never modify or add to the datasets provided by the Operating System manufacturer.  So, the datasets created during the System Generation procedure, for example: SYS1.LINKLIB, SYS1.CMDLIB, SYS1.PROCLIB, should never be modified.

You should instead create your own corresponding versions of the libraries created during system generation into which you may then add your own programs:

Batch programs (load modules) SYS2.LINKLIB
TSO commands SYS2.CMDLIB
Batch procedures  SYS2.PROCLIB
Help text for TSO commands SYS2.HELP

You will also need to add the names of the load module libraries to the active LNKLST member of SYS1.PARMLIB.  

If you plan to link programs that require authorization to execute, you will need to add SYS2.LINKLIB to the active IEAAPF member of SYS1.PARMLIB.

What does r 0,clpa, specified in response to the IEA101A SPECIFY SYSTEM PARAMETERS FOR RELEASE 03.70.VS2 prompt, do?

The Link Pack Area is an area of common main storage that is stored in the page datasets.  It begins with the fixed LPA, if one is present, then the modified LPA, and finally the pageable LPA.  The pageable LPA contains all the members of SYS1.LPALIB and any other libraries that are specified in the active LPALST?? member(s) of SYS1.PARMLIB.  The modified LPA contains those modules listed in the active IEALPA?? member of SYS1.PARMLIB.  The fixed LPA contains those modules listed in the active IEAFIX?? member of SYS1.PARMLIB; these modules are ones which must be kept in fixed storage frames (i.e. cannot be paged out).  

When you specify CLPA at IPL time, MVS clears the contents of the page datasets and loads these modules from their respective datasets.  If you do not specify CLPA, the page datasets are used as they existed at the last MVS shutdown.  Depending upon how many modules you have specified to be loaded into the LPA areas, specifying CLPA may require the IPL to take noticeably more time than omitting CLPA.

Is there a naming convention for IBM components and programs?

The first three, occasionally four, characters of the component/program name identify the program, and usually, serve to identify the error messages issued by the program.  Many of the prefixes originated in the OS/360 era, or earlier, and the origin of the prefix letters is no longer known.  Currently IBM maintains a registry of prefixes assigned both by IBM and by third parties.  Some of the known prefixes are:

ADF TSO Session Manager
AHL MVS Generalized Trace Facility
MVS Service Aids
BLS IPCS (Interactive Problem Control System)
IBC Stand-alone utilities (DASD Initialization, Dump/Restore, etc.)
IBM PL/I library
ICB Mass Storage System Communicator
ICE Sort/Merge 
ICF Power Warning Feature
ICG Mass Storage Control Table Create
ICH RACF (Resource Access Control Facility)
ICK Device Support Facilities
IEA System control (storage/task management, etc.)
IEB Non-privileged utilites (utilities which do not invoke privileged functions)
IEC Data Management, Input/Output Supervisor
IED TCAM (Telecommunications Access Method)
IEE Master Scheduler, Operator's console
IEF Job Management (Master Scheduler, Initiator, Reader, Writer, etc.)
IEG Graphics Management
IEH Privileged utilities (utilities which invoke privileged functions)
IEI System Generation messages
IEK FORTRAN H compiler
IEL PL/I Optimizing compiler
IEM PL/I F compiler
IEN PL/I checkout compiler
IEP COBOL E compiler
IEQ COBOL F compiler
IER MVT Sort/Merge
IES RPG compiler
IEU Assembler F
IEV Assembler H
IEW Program Management (Linkage Editor, Loader, Program Fetch, Overlay Supervisor)
IEX ALGOL compiler
IEY FORTRAN G compiler
IFA SMF (System Management Facilities)
IFB Environmental Recording 
IFC EREP (Environmental Record Editing and Printing)
IFD OLTEP (Online Test Executive Program)
IFE FORTRAN IV H extended compiler
IFO OS/VS Assembler XF
IGC SVC (Supervisor Call) functions
IGF Recovery Management
IGG Open, Close, End-of-Volume transient modules for type 4 SVCs
IHE PL/I F library
IHI ALGOL library
IHJ Checkpoint/Restart
IHL OS Generalized Trace Facility
IKF ANS COBOL compiler and OS/VS COBOL compiler
IKM PL/I Syntax Checker
ILR MVS Auxiliary Storage Management
OS Service Aids
IMC OS Job Queue utilities
IPD FORTRAN IV Syntax Checker
IRA MVS System Resources Manager
IRB MF/1 (Measurement Facility/1)

Original resources for this information are H390-MVS messages (7244, 7256, and 7258) by Peter H., Kevin Leonard, and Tony Harminc.

How can I create a custom TSO Logon Procedure?

During System Generation the default procedure used to initiate a TSO session was created in SYS1.PROCLIB: IKJACCNT.  If you want to modify this procedure, perhaps to include additional DD statements or execution parameters, follow these steps:

It is not good practice to make modifications to the default procedure, especially until you have verified that your changes will function correctly.  Also, leaving the default procedure as it was created during System Generation means that you can always easily revert to the installation standard.

How do I enable a customized TSO Logon EXEC (CLIST)?

There are circumstances when it will be desirable to customize the TSO User's environment by pre-allocating datasets, setting up custom variables for inclusion in CLISTs, or maybe just to provide a character-based graphic to welcome the user to the TSO session.  These can all be accomplished by writing a CLIST and creating a custom TSO Logon Procedure.  First you need to have a custom TSO Logon Procedure set up for your system; for this, see the previous question/answer (directly above). 

You can implement this with a single CLIST that is utilized by all TSO User IDs, but it is more flexible to have a custom CLIST for each TSO User.  If you have some of your TSO User IDs set up with Profile NOPREFIX, this requires an intermediate CLIST that is called by the Logon Procedure, and then it calls the unique CLIST for the TSO User ID being utilized for the Logon.  Here is how I have this set up on my system:

First I allocated a PDS to contain the CLISTs, called SYS2.LOGON.CLIST.  I allocated the dataset on a 3350 volume with the attributes of DSORG=PO, RECFM=VB, LRECL=255, BLKSIZE=9324.  I created a member - SYSTEM - that will be called first by the Logon Procedure:


The Control Variable &SYSUID in the last line will resolve to the TSO User ID that is in the process of logging onto TSO, so the nested EXEC will execute the CLIST contained in the SYS2.LOGON.CLIST dataset designed specifically for that User ID.

Obviously for each TSO User ID I set  up, I create a unique CLIST in the dataset.  For User ID JAY03, the CLIST is:


Finally I edited the custom TSO Logon Procedure (in SYS1.PROCLIB) that I have installed on my Hercules/MVS system to call the CLIST contained in the SYSTEM member.  To do that, I insert a PARM argument on the EXEC statement in the procedure:

 (other statements follow)

The Logon CLIST can be as simple or complex as required.  You can read a detailed account of this type of CLIST at, but remember that this article was written for a later system than MVS 3.8j, so you may need to make allowances for features mentioned in the article that will not function (or function in an unexpected manner) on MVS 3.8j.

How can I create a customized Network Solicitor screen?

When VTAM starts, the screen displayed on all 3270 devices allocated to VTAM will show the Network Solicitor screen.  You can customize this to provide an image (well, a text-based character image) that is unique to your system.  The Network Solicitor is a load module in SYS1.VTAMLIB (ISTNSC00) that is assembled from the expanded macro NETSOL, which is found in your SYS1.MACLIB (it was installed there during System Generation).  Modifying Assembler source that you are not familiar with is not a trivial task, but it isn't impossible.  Tommy Sprinkle has created a web page that explains how to make this modification, so rather than repeat his excellent instructions, I will just provide a link to his page at

Please note his advice about backing up the existing copy of the NETSOL macro.  However, I will add that if you obliterate the original copy of NETSOL, you may recover it by copying NETSOL from SYS1.AMACLIB into SYS1.MACLIB.

How can I suppress the IFB010D message at IPL?

The message: *00 IFB010D ENTER 'IPL REASON,SUBSYSTEM ID' OR 'U', issued at IPL prompts for a reason for the IPL, which is simply recorded to the hardware error log.  This can help diagnose errors on a real system.  The message is issued because of a setting on the CTRLPROG macro during System Generation.  If you want to suppress this message at IPL time, and the reply, the simplest method is to rename a load module (IFCRDE03) in SYS1.LINKLIB.  This method will take effect at the next IPL, does not require CLPA to be specified to make the change effective, and may be reversed by simply naming the module back to the original name.  A jobstream to make the change is:


Note that the C in the first control card must be in column 72 and the first character in the control card continuation must be in column 16.  This solution was supplied by Thomas Armstrong in a discussion on the H390-MVS forum.

Why do I have to enter a Start command for JES2 printers after IPL?

... or some variation on this question, which was asked in the Hercules' MVS discussion group on September 4, 2017.  The discussion is still raging as September comes to a close, and I am not sure there will ever be consensus on a single 'why' or a single 'fix'.  Since the original question was from someone who referenced a system built using my MVS 3.8j installation steps, I thought I would investigate.  I might also add that nobody directed a question specifically to me, which is alright, since these days my time is quite consumed with day-to-day real life family issues and I am glad that nobody was sitting at their computer impatiently waiting for my answer.  But, I have put some time into thinking about this and offer these answers.

First I will say that I have never had any problem issuing the $S (start) JES2 command when the first output print (or punch) job is selected by JES2 for processing, but I can understand that people who have never used a mainframe might prefer not to have to ever think about managing the printer/punch output from their system.  So the problems (in the JES2 parameters) and solutions suggested include:  'STD.' as a form may cause problems with JES2 (character [period] other than alphabetic or numeric in form code), printer control buffer and/or character chain buffer specified differently between the printer definition statement(s) and $T (setup) command, or difference in form code specified in &STDFORM, printer definition, or setup command.

Second I will say that I am only considering these questions for PRINTER tasks and not PUNCH tasks.  Having worked through the era when many production jobs actually produced copious amounts of punched cards, I intend to leave the PUNCH definitions alone.  If anyone is seriously bothered by having to issue a start command for the punch task upon the selection of the first output to be processed by JES2, they can apply these same changes to their punch task specifications in the JES2 parameter file.  I think perhaps I have produced punch output once or twice a year on my Hercules/MVS3.8j system over all the years I have been using it, so it is just not a consideration for me.

So, the changes I made to my system number three:

  1. Change the standard form specification to a designation that does not contain special characters: &STDFORM=STD1

  2. Expand the PRINTER definitions for both printers to include all (or almost all) relevant operands, where previously I had omitted operands that would default to the desired values; so that includes FCB= and FORMS= operands for both printers, and UCS= for the printer that expects, and can handle it.  Both definitions include the AUTO operand

  3. Change the setup ($T) commands so that the FORM operand matches the one used in the PRINTER definition statements.

Now, all of these may be done manually, quite easily.  But I wrote a COBOL program that will read the JES2 parameters [SYS1.PARMLIB(JES2PM00)], back them up to a backup member, and apply the changes.  This jobstream [JES2PMOD] may be run against any system which was built using my instructions and it should make the changes for you, even preserving any additional changes you have made to the JES2 parameters - it is only looking for the &STDFORM, PRINTER definition, $T and $S statements, everything else is left as it is.  This program will require the current version of SYSCPK be installed, because I utilize the routine NCZ93205 which is linked from SYSC.LINKLIB.  Frankly, this program is overkill for changes this simple, but these days I am using GnuCOBOL to address many issues on my own system, so it was nothing for me to put together and backgrade the COBOL code to a level that would compile under the MVT COBOL compiler.

Once these changes are made to the JES2 parameters, the next time JES2 restarts, the printers will begin printing as soon as output is placed in the queue for a class matching that set for the printer task(s).

I have also modified the setup jobs used in my instructions for installing MVS 3.8j to incorporate these changes, so any future Hercules/MVS 3.8j systems that are built using my instructions will already have these changes in place.

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 September 23, 2017 .