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.
[July 2020] If you are using an MVS system built following my instructions/tutorial to build an MVS 3.8j system, there is a procedure installed in SYS2.PROCLIB(CLEARERP) that will accomplish this as a started task. From the MVS console, enter the command: s clearerp, to run this procedure and clear the Environmental Log Record.
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.
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:
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 ...
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.
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: https://www.tommysprinkle.com/mvs/parmtz.htm.
[July 2020] At this time, using the SYSEPOCH setting in the Hercules configuration file is deprecated. It seems that most people are running MVS with the date set to the current date. Many areas where the system date is used in MVS have been patched to be post-Y2k compliant.
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!
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.
[July 2020] If you are using an MVS system built following my instructions/tutorial to build an MVS 3.8j system, the SMF Exit 29 is already installed and will correctly handle switching your SMF dataset when it fills and will copy the records from the filled SMF dataset to a Generation Dataset that is set to hold five generations of SMF data.
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.
This question was asked in July, 2002 in the Hercules MVS forum 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:
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.
The source for the language compilers is contained in the OS360 source archive. The relevant directory names are:
[July 2020] The sources for all of the MVT compilers have been loaded to a DASD image and are available for download from my site, see MVT Compilers from Source.
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.
[July 2020] If you are using an MVS system built following my instructions/tutorial to build an MVS 3.8j system, the libraries SYS2.LINKLIB, SYS2.CMDLIB, and SYS2.PROCLIB are already created and integrated into the Link List.
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.
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) 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
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 (which are no longer available after Yahoo Groups' demise) by Peter H., Kevin Leonard, and Tony Harminc.
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.
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:
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 ../downloads/pdf/TSO_times_enablingtsologon.pdf, 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. Note: This article was formerly available at http://www.tsotimes.com/articles/archive/winter03/enablingtsologon.html, but is no longer available, so I have retrieved the content from Internet Archive and provide the pdf from my site.
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 https://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.
[July 2020] Also, see How can I change the Network Solicitor Logon screen?.
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.
[July 2020] You may download a copy of the jobstream to apply this change from: ../downloads/IFB010D.jcl.
... 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:
Change the standard form specification to a designation that does not contain special characters: &STDFORM=STD1
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
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 recently saw this discussed on the Hercules' MVS forum, and then had it brought to me as a direct question by Achim Woellgens and Joshua Kurtenbach; so all three events together spurred me to lock my 20 month old son in the bathroom for the time I needed to fix this. Kidding about locking my son in the bathroom; certainly everyone knows this would have just resulted in a larger disaster in the bathroom, not to mention it would have been impossible to concentrate if he were in the bathroom crying because he had been abandoned.
I looked at the origin of the NET procedure in my installation instructions (it is provided in the SYSGEN04 jobstream in installmvs.tgz) and see that it originated a very long time ago and has had no modifications since I incorporated the NET procedure into my system. The problem is that when VTAM (and/or MVS and/or Hercules) terminate abruptly and without a normal shutdown, the working dataset that VTAM uses to keep information about the current network configuration remains as an uncatalogued dataset on the STORAGE class DASD volume where it is allocated. There are two STORAGE class DASD volumes in the configuration if you have followed my instructions to build MVS. So the first time this occurs a dataset is left on one of the volumes, probably WORK00. The next time VTAM (NET) is started, MVS allocation will see that there is a duplicate named dataset on WORK00 and it will move on to the next available STORAGE class DASD volume, which is WORK01. The third time this occurs, there are no additional STORAGE class DASD volumes available and you will see a series of messages like this:
s net $HASP100 NET ON STCINRDR $HASP373 NET STARTED IEF403I NET - STARTED - TIME=18.04.32 IEF244I NET NET UNABLE TO ALLOCATE 1 UNIT(S) AT LEAST 1 OFFLINE UNIT(S) NEEDED. IEF489I NET 1 OFFLINE UNIT(S) NEEDED. IEF247I NET 154,155,156,157,254,255,256,257,350,351,352,353 OFFLINE IEF247I NET 354,355,356,357 OFFLINE *02 IEF238D NET - REPLY DEVICE NAME OR 'CANCEL'.
The immediate fix to get up and running is to reply CANCEL here and submit a batch job to delete the datasets on the two storage volumes, then issue the 's net' command again to proceed. But the permanent fix is to modify the NET PROC to make sure this doesn't happen ever again. Gerhard Postpischil responded to the post in the Hercules' MVS forum with the most logical solution, which is to change the dataset name to the annotation that directs MVS to create a temporary dataset. I have modified the NET procedure in the SYSGEN04 jobstream to do just this. I have also written a very short jobstream that will replace the NET procedure in any system built using my instructions with the modified procedure. The jobstream is available as newnet.jcl, which is a plain text file containing the jobstream. Submit this job to your running MVS system to replace your NET procedure in SYS1.PROCLIB. The existing procedure (in member NET) will first be renamed to NET99, but note that if you submit this job again, it will replace the NET99 member with the contents of NET, so the backup function will only produce the desired result on the first execution. It will not matter if VTAM (NET) is executing when you submit this jobstream, as the updated procedure will take effect the next time VTAM is terminated and restarted.
[July 2020] If you are using an MVS system built following my instructions/tutorial to build an MVS 3.8j system, this change has been incorporated.
I just watched Matthew Wilson's video series on installing MVS 3.8j under Hercules following my instructions/tutorial ... a bit late as I just finished the major revision of these instructions. However, he had a valid point about the absurdity of the Network Solicitor screen emphasizing Hercules, rather than MVS and TSO. It has been this way for a long time (many years) and I no longer remember exactly why or the absolute origin of this screen design. But it is simple to change and I have designed a replacement:
You can download the jobstream to install this Network Solicitor logon screen from netsol.jcl. Submit the job to MVS - expect all steps to complete with 0000 completion code. Logoff TSO, Stop NET (VTAM), and restart NET. If you don't like my design, it is simple to replace the constants in the jobstream to install your own design.
And if you want to watch a video tutorial on how to install MVS 3.8j under Hercules, go watch Matthew Wilson's series on YouTube.
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 15, 2020 .