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                      
//********************************************************************
//* CLEAR AND INITIALIZE HARDWARE EVENT RECORDER DATASET             *
//********************************************************************
//IFCDIP00 EXEC PGM=IFCDIP00                                          
//SERERDS  DD  DSN=SYS1.LOGREC,DISP=OLD,
//             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:

SID=xxxx

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:

SYSEPOCH 1928

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:

SYSEPOCH 0000

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:

TZOFFSET -0000

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

d,nn

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: http://www.tommysprinkle.com/mvs/parmtz.htm.


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:

    OPI=YES,    PERMIT OPERATOR INTERVENTION           00350000

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:

IEE362A   SMF ENTER DUMP FOR SYS1.MANx ON volser

(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:

//SMFCLEAR JOB (001),'CLEAR SMF DATASET',CLASS=A,MSGCLASS=A
//* ***************************************************************** *
//* CLEAR SYS1.MANX AND SYS1.MANY                                     *
//* ***************************************************************** *
//DUMPX   EXEC PGM=IFASMFDP,REGION=4096K
//SYSPRINT  DD SYSOUT=*
//DUMPIN    DD DSN=SYS1.MAN?,DISP=SHR      <=== CHANGE DSN !!!
//DUMPOUT   DD DUMMY
//SYSIN     DD *
  INDD(DUMPIN,OPTIONS(CLEAR))
/*
//

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     
//IFCEREP1 EXEC PGM=IFCEREP1,REGION=1024K,PARM='CARD'
//SERLOG   DD  DSN=SYS1.LOGREC,DISP=OLD              
//ACCDEV   DD  DUMMY                                 
//TOURIST  DD  SYSOUT=A              
//EREPPT   DD  SYSOUT=A              
//SYSIN    DD  *                                     
  LINECT=060                                         
  TABSIZE=512K                                       
  PRINT=AL                                           
  HIST=N                                             
  ZERO=N                                             
  ACC=N                                              
//                                                   

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 http://www.tommysprinkle.com/mvs/smfprm00.htm).  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
AMA
AMB
AMD
MVS Service Aids
BLS IPCS (Interactive Problem Control System)
DFH CICS
DFS IMS/DLI
HASP JES2
IAT JES3
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
IGI FORTRAN IV G1
IHC FORTRAN IV library
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
IKJ TSO
IKM PL/I Syntax Checker
IKT TSO/VTAM
ILR MVS Auxiliary Storage Management
IMA
IMB
IMD
OS Service Aids
IMC OS Job Queue utilities
IPD FORTRAN IV Syntax Checker
IRA MVS System Resources Manager
IRB MF/1 (Measurement Facility/1)
IST VTAM

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:

PROC 0 CONTROL NOMSG NOFLUSH 
EXEC SYS2.LOGON.CLIST(&SYSUID.) 

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:

PROC 0 CONTROL NOMSG NOFLUSH 
CLS 
WRITE WELCOME TO MVS3.8J TSO 
ALLOC F(SYSUADS) DA('SYS1.UADS') SHR 
ALLOC F(SYSLBC) DA('SYS1.BRODCAST') SHR 

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:

//TSOACCNT PROC 
//TSOACCNT EXEC PGM=IKJEFT01,TIME=1440,PARM='EXEC SYS2.LOGON.CLIST(SYSTEM)' 
//SYSHELP DD DISP=SHR,DSN=SYS1.HELP 
// DD DISP=SHR,DSN=SYS2.HELP 
//DD1 DD DYNAM 
//DD2 DD DYNAM 
 (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 http://www.tsotimes.com/articles/archive/winter03/enablingtsologon.html, 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 http://www.tommysprinkle.com/mvs/netsol/index.htm.

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:

//IEHPROGM JOB (001),'IEHPROGM',CLASS=A,MSGCLASS=X 
//PROGM EXEC PGM=IEHPROGM 
//SYSPRINT DD SYSOUT=* 
//DD1 DD UNIT=3350,VOL=SER=MVSRES,DISP=OLD 
//SYSIN DD * 
  RENAME DSNAME=SYS1.LINKLIB,VOL=3350=MVSRES,MEMBER=IFCRDE03,        C 
               NEWNAME=IFCRDEX3 
// 

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.


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 July 29, 2016 .