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.
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:
- PRIVATE - volume will be used to contain a dataset only if the volume is specifically designated by volume serial number
- PUBLIC - volume may be used to contain temporary datasets which request allocation by generic device type; volume may also be selected specifically by designation of volume serial number (equivalent of PRIVATE)
- STORAGE - volume may be used to contain permanent datasets which request allocation by generic device type; volume may also contain temporary datasets (equivalent of PUBLIC) or may be selected specifically by volume serial number (equivalent of PRIVATE)
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:
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 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:
- 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.
- 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:
- AAPVT - macros required for assembling individual compiler modules
- AL531 - ALGOL
- AS037 - assembler (IEUASM)
- CB545 - COBOL (F)
- CO503 - COBOL (E)
- FO500/FO520/FO550 - Fortran (G and H)
- LM546 - COBOL library
- NL511 - PL/I (F)
- RG038 - RPG
- SM023 - Sort/Merge
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
AMDMVS Service Aids BLS IPCS (Interactive Problem Control System) HASP JES2 IAT JES3 IBC Stand-alone utilities (DASD Initialization, Dump/Restore, etc.) 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
IMDOS 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:
- create a new member in SYS1.PROCLIB
- copy the contents of the default procedure (IKJACCNT) into the new member
- modify the new member to include your changes and save it
- create a new TSO User ID and specify your new procedure instead of IKJACCNT as the logon procedure
- log on using the new TSO User ID to verify that the procedure functions correctly
- change any other TSO User IDs that you wish to use the new procedure instead of the default.
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 mine 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:
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:
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.
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 July 18, 2008 .