z/OS is highly customizable using system parameters that are read during startup. z/OS startup is called an IPL, Initial Program Load. Like a PC boot, z/OS IPL locates disk storage that contains the IPLTEXT while a PC locates disk storage that contains the MBR, Master Boot Record. During startup of any operating system, parameters are read from disk files that result in specific behavior of the operating system.
z/OS has more system parameter options than any other operating system due to the 50+ years of technology advancements. These system parameters are available as a result of business demand to shape the behavior of z/OS to meet the specific needs of their business. In addition, the vast majority of these system parameters can be dynamically changed.
The z/OS used in this contest has a system parameter structure that is significantly more complex than most large production systems. Why? Because this z/OS is created from a model which is used to create dedicated z/OS environments for software companies around the world that build and maintain z/OS software products used by large production systems around the world.
Therefore, do not be intimidated by the system parameter structure of this contest system because most other systems have a significantly simplier system parameter structures.
z/OS has many components that are actually a collection of executable modules. All software products such as COBOL, DB2, TCPIP, etc are considered components, and each of these are a collection of executable modules.
A key to understanding z/OS is the "message id". z/OS is very good at providing messages about normal and abnormal activity. Every z/OS core component and software product component has a unique 3 character identifier.
Highly experienced z/OS System Programmers and z/OS System Administrators will read the system log (SYSLOG) for messages when an abnormal situation is reported for them to resolve.
System Programmers and System Administrators look up these messages in manuals to get a full description of message beyond the summary message text written to the system log (SYSLOG) when they are uncertain about "why" a message was written and "what" action to take. If the component message is reporting an abnormal situation, then the full description of the message in the manual will include a recommended action.
Keep in mind that z/OS environments are responsible for the most critical second to second transaction activity required by the world economy. Therefore, being able to identify, manage, and resolve abnormal processing situations quickly is mandatory.
We will just restate again, employers are clamoring to find students with exposure to z Systems technology. They want to pair young people with highly experienced technicians, who are near the end of their careers. These are highly responsible and highly paid jobs for those of you who can prove yourselves capable of managing the responsibilities of these mission-critical operating environments.
In this final challenge of part two, you will:
- learn to recognize z/OS Message IDs.
- read and interpret z/OS Message IDs.
- modify a REXX routine that reads SYSLOG messages written during z/OS IPL.
To begin with, you must learn to identify the z/OS Unix System Services (USS) unique 3 character component identifier.
Your first action is to review a list of the unique 3 character prefixes assigned to the various z/OS and z/OS product components information at the following URL:
The above URL is a list for the majority of the z/OS component unique 3 character prefix identifiers. Locate the z/OS Unix System Services unique 3 character message ID prefix.
This z/OS Message Directory table includes a "Document Title" column. The z/OS Unix System Services component "Document Title" is a specific z/OS MVS System Messages document. This z/OS MVS System Messages document is 1 of numerous volumes for component messages. Select the associated z/OS MVS System Services document and scroll forward to the z/OS Unix System Services messages. Select the 'messages' heading. Locate the entire message ID for FILE SYSTEM name WAS SUCCESSFULLY MOUNTED.
Now that you know the entire z/OS UNIX System Services ""message ID associated with FILE SYSTEM name WAS SUCCESSFULLY MOUNTED., you are ready to complete the challenge.
A copy of the z/OS System Log (SYSLOG) is available that includes system messages written during IPL, Initial Program Load.
REXX code is available to read this SYSLOG which write a simple report about specific IPL activity.
Jump to data set list utility panel =3.4 and edit CC#####.REXX.CLIST
Observe CC#####.REXX.CLIST PDS directory has a number of members. Enter EX to the left of IPLMSG to execute this REXX routine.
Modify the IPLMSG REXX routine to include the number UNIX files successfully mounted.
In the event you want to look at the SYSLOG data set read by the IPLMSG REXX routine, please DO NOT edit the data set. Your ID is unable to make changes to this data set and attempting to edit it will result in other REXX executions to hang waiting for you to exit the edit session. Browse (B) or View (V) the data set instead. In the event that you edit this data set, your session will be cancelled to enable other REXX routines to run. If this occurs, simply log on again.
Each time you attempt a correction, press F3 to save and return to list of directory members where EX to the left of IPLMSG will execute the modified REXX routine.
Format of lines in the z/OS System Log
After adding a count to the last line, submit JCL(IPLMSG). This JCL will execute your IPLMSG REXX routine in batch and create P2.OUTPUT(#16). Member #16 will include the last line with the count.
One final step and you can consider yourself a part two finisher! Go on to the final instructions in the next 'challenge' to score your work.