One of the mainframe's advantages is serviceability. Unlike other platforms, we can apply fixes individually or in groups using SMP/E. Although SMP/E is cursed more than praised, it does ensure each fix is applied in proper sequence and contains hold data to prevent bad maintenance from getting onto our systems.
There are two tricks to this: making sure the hold data is up to date; and being aware of any potential landmines. This column will show how to keep current hold data and an SMP/E report that flags the fixes you have to worry about.
Keeping hold data current
A few years ago we only received hold data in the process of applying preventative maintenance. Now IBM maintains an FTP site offering a file with all the hold data you'd ever want. The following simple job can download and receive hold data in one swoop:
//FTP EXEC PGM=FTP,REGION=5M
//OUTPUT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//INPUT DD *
service.boulder.ibm.com
anonymous
robert.crawford@company.com
cd /s390/holddata
lcd ..
lcd sysp.smpe
get month.txt monthly.holddata (REPLACE
quit
//SMPSREC2 EXEC PGM=GIMSMP,REGION=4M
//SMPCSI DD DISP=SHR,DSN=SYSP.SMPE.GLOBAL.CSI
//SMPHOLD DD DISP=SHR,DSN=SYSP.SMPE.MONTHLY.HOLDDATA
//SMPLOGA DD DUMMY
//SMPPTFIN DD DUMMY
//SMPCNTL DD *
SET BDY(GLOBAL) .
RECEIVE
HOLDDATA
.
If you're unfamiliar with batch FTP, the first step JCL downloads IBM's hold data file /s390/holddata/month.txt into SYSP.SMPE.MONTHLY.HOLDDATA. The second step receives the hold data into the SMP/E environment.
You have to be careful about a couple of things regarding this job. First, SMP/E will only receive the hold data for the FMID's in the global zone. If your company maintains multiple CSI's you must rerun the receive for each SMP/E environment. Second, FTP tends to issue a zero return code even if there's an error downloading the file. Therefore, you should always look at the job's output to ensure the download completed successfully.
Exception SYSMOD report
Once you have the most current hold data you can run an exception SYSMOD report for a quick summary of potential trouble spots. The syntax for the error report is simple, specifying the zones to be included as well as dates and FMID's. For example, these commands
SET BOUNDARY(GLOBAL) .
REPORT ERRSYSMODS ZONES(GLOBAL, TZONE, DZONE) .
generate error SYSMOD reports for three zones. Note that you must be set to the global zone before issuing the report command. Also, remember that IBM creates an Authorized Program Analysis Report (APAR) when they open a problem. The problem is finally "resolved" when IBM issues a Program Temporary Fix (PTF). An example of the resulting report is included below.
EXCEPTION SYSMOD REPORT FOR ZONE DZONE
HOLD SYSMOD APAR ---RESOLVING SYSMOD---- HOLD HOLD
FMID NAME NUMBER NAME STATUS RECEIVED CLASS SYMPTOMS
-----------------------------------------------------------------------
HCI6300 HCI6300 AK36143 UK25675 GOOD YES HIPER IPL
AK39513 UK25917 GOOD YES HIPER PRF
AK40496 UK25231 GOOD YES HIPER PRF
AK40508 UK27354 GOOD NO HIPER FUL
AK48607 UK28920 GOOD NO HIPER IPL
UK16660 AK43690 ***NONE
UK22752 AK46944 UK27426 GOOD YES PE
HCP2300 HCP2300 AK36131 UK27344 GOOD YES HIPER FUL
AK47563 UK26917 GOOD YES HIPER FUL
AK47571 UK26653 GOOD YES HIPER PRF
UK02658 AK47563 UK26917 GOOD YES PE
UK19831 AK51928 UK29060 GOOD NO PE
The individual columns are defined as follows:
- The FMID named in the ++HOLD statement.
- The SYSMOD for which you've received hold data. A blank in this column means the APAR is not associated with a previous SYSMOD.
- The APAR number associated with error creating the hold.
- The SYSMOD resolving the hold error. "***NONE" in this column means a resolution (PTF) is not available yet.
- There are several values for this column. "GOOD," of course, means the resolving SYSMOD is available and not held. "HELD" tells you the resolving fix has problems too. Finally, "ERREL" indicates the resolving SYSMOD is held, but the original problem is more important than why it is in error. This sounds like a judgment call.
- Whether or not you've received the resolving SYSMOD.
- The hold class specified on the ++HOLD statement.
- A description of the held SYSMOD's problem. This can be anything from a sentence to a three byte code. As an example, for the ones shown here:
- FUL – Function loss
- IPL – Requires IPL
- PRF – Performance problem
If any of the resolving SYSMOD's are held there will be a second report showing the same information for it.
Putting It Together
As mentioned before, the exception SYSMOD report is a summary of potential trouble spots. What you do next depends on the maintenance philosophy of your shop. Some shops will run the download and exception report weekly while others will be content to use it during their normal preventative maintenance cycle. Likewise, some will apply the resolving SYSMOD's as soon as they turn up and move them forward on an aggressive schedule. Others tend to take a more thoughtful approach involving some analysis of potential impact and risk assessment. For instance, if you don't use cryptography there's no point in rushing the latest ICSF fixes to production.
While I think downloading IBM's current hold data and getting an exception SYSMOD report is an excellent idea, it's not the entire answer. It does not replace other IBM offerings such as Automatic Software Alert Processing (ASAP), Automatic Status Tracking (AST) or Preventative Service Planning (PSP) buckets. In addition, the exception report will not flag that one PTF that kills your entire Sysplex along with the one next door if IBM fails to mark it as a HIPER. But, how often does that happen?
ABOUT THE AUTHOR: Robert Crawford has been a CICS systems programmer off and on for 24 years. He is experienced in debugging and tuning applications and has written in COBOL, Assembler and C++ using VSAM, DLI and DB2.
