Dave's MVS Tips

A human being should be able to change a diaper, plan an
invasion, butcher a hog, conn a ship, design a building, write a
sonnet, balance accounts, build a wall, set a bone, comfort the
dying, take orders, give orders, cooperate, act alone, solve
equations, analyze a new problem, pitch manure, programme a
computer, cook a tasty meal, fight efficiently, die gallantly.
Specialization is for insects. --Heinlein, Time Enough For Love

Here are my tips for maintaining a MVS system. These tips work for me at my shop. They may work for you at your shop or may not. I don't claim these are original but these are things I do at my shop:

Use the CVTVERID field for SYSRES copy info
JES2 Initialization Parameters
Document your IPL configuration
Keep track of your SMF records
Speed up your IPL by starting VTAM SUB=MSTR
Started Task JCL
Static end markers for your parmlib
Keep track of every SVC
SUB=MSTR JCL
Protect against and recover from JES2 PROCLIB problems
Keep track of your CA products in your LMP keys member
Another "Rescue" system option: your OS/390 install packs
Using symbols for the operating system level [2007-08-27]

There isn't an absolute right way of doing any of this stuff. You will do things the way you are the most comfortable with. These tips show how I like to maintain MVS. Pick and choose how you like.

While other platforms might command the media spotlight, they are usually immature technologies. MVS is computing for grownups.

Think of this page as my "MVS for Smarties" page. ;-)

Use the CVTVERID field for SYSRES copy info

Last Modified: 1997-12-10

There is a 16 byte field in the CVT prefix control block called CVTVERID that IBM has left aside for installation use. From my SYS1.MACLIB(CVT):

CVTVERID DC    CL16'                '
*                            OPTIONAL USER PERSONALIZATION OF
*                            SOFTWARE SYSTEM VERSION.

When I clone my SYSRES, I zap this field with the maintenance level and copy date. This is performed on the new SYSRES and NOT the SMP SYSRES! Here is my JCL that does this:

//*
//* *
//* *  CHANGE SOFTWARE LEVEL - THE SHOWTSO COMMAND USES THIS
//* *
//*
//VERID   EXEC PGM=AMASPZAP
//SYSPRINT DD  SYSOUT=*
//SYSLIB   DD  DSN=SYS1.NUCLEUS,DISP=SHR,UNIT=3390,VOL=SER=newres
//SYSIN    DD  *
 NAME IEANUC01 IEAVCVT
 IDRDATA CLONERES
 VER 0028 40404040,40404040
 REP 0028 D7A4A3F9,F6F0F84E        "Put9608+"
 VER 0030 40404040,40404040
 REP 0030 F1F061F0,F461F9F7        "10/04/97"
//*------> 1 0 / 0  4 / 9 7 <-------------------------------

By specifing IDRDATA, It is easier to verify this zap using the PDS command on the CBT tape or even better the StarTool product from Serena. Here is sample output from the PDS 'SYS1.NUCLEUS' HIST IEANUC01 command:

** HISTORY  IEANUC01
PDS061I AMASPZAP UPDATE HISTORY BY CSECT -
IEAVCVT      10/04/97    CLONERES

If the CVTVERID is blank, IBM displays the MVS release at IPL time. But if the CVTVERID is not blank, you will see this message with the CVTVERID contents:

IEA247I USING IEASYSxx FOR Put9608+10/04/97

Here is a sample REXX exec that displays the contents of the CVTVERID field with the format I zap it with:

/* REXX - Show installation CVT VERID */
CVT    = STORAGE(10,4)                        /* Locate CVT */
DCVT   = C2D(CVT)                             /* Convert to dec. */
CVTPFX = DCVT - X2D(100)                      /* Locate CVTFIX */
SPREL  = STORAGE(C2X(D2C(CVTPFX+X2D(D8))),8)  /* MVS SP release */
VERID  = STORAGE(C2X(D2C(CVTPFX+X2D(E8))),16) /* Get VERID */
say "MVS "strip(sprel)" is at "substr(verid,1,8)
say "SYSRES was copied on "substr(verid,9,16)
exit

At IPL time you know the copy date of the SYSRES that you are IPLing when you use this technique. You could also put the change request number instead of the two fields I put in the 16 byte area.

Automate the CVTVERID update
Mark Jacobs sent me his Assembler program called IDNTSYSR.TXT

(28-Jun-1998 - fixed ver/rep offset) that creates AMASPZAP control cards containing the current date and then invokes the AMASPZAP utility to modify the CVTVERID field. It can be invoked using the following JCL:

//*
//** Create AMASPZAP control cards and invoke AMASPZAP to update
//** the CVTVERID field.
//*
//VERID   EXEC PGM=IDNTSYSR,PARM='9806'   <- MVS PUT level or other 4 digit field
//STEPLIB  DD  DISP=SHR,DSN=your.load.lib
//SYSPRINT DD  SYSOUT=*
//SYSLIB   DD  DSN=SYS1.NUCLEUS,DISP=SHR,UNIT=3390,VOL=SER=newres
//SYSIN    DD  UNIT=VIO,SPACE=(TRK,(1,1)),DISP=(,PASS)

JES2 Initialization Parameters

Last Modified: 1997-12-10

Separate your JES2 parameters into functional members to make your life easier for Disaster Recovery and Multi-Access Spool. As seen in my JES2 JCL, I have my JES2 initialization parameters separated into these SYS1.PARMLIB members:

JESMASxx - JES2 Multi-Access Spool definitions. This member contains only the statements needed for MAS and is different for each system. I only have these parameters in this member:
- MASDEF
- CKPTDEF
- SPOOLDEF
JESNETxx - JES2 Network definitions. This member has the Network definitions need for this system only. This would include SNA RJEs, lines and NJEs.
JESPRMxx - JES2 primary definitions. This member has the bulk of the JES2 definitions. These are the JES2 statements that are common to every MVS system at my shop.
JESUCBxx - JES2 UCB definitions. This member has all of the JES2 statements that have UCB references including printers and BSC lines. I have three members which are used as needed:
- JESUCBDR - Used at Disaster Recovery
- JESUCBxx - Normal production
- JESUCBNO - Has no UCBs statements (consists of comment lines only)

I can then start JES2 with different combinations of JES2 initialization parameters. Sample start:

S JES2,UCB=DR,MAS=01

I got this technique from Bob Hobbs.

Document your IPL configuration

Last Modified: 1997-12-10

In my 'SYS1.PARMLIB(COMMNDxx)' member, I issue a lot of display commands that are useful later for knowing how the system was configured at IPL time.

See Building a Self-Documenting MVS/ESA System by Mark S. Hahn for a more information on why you should do this.

Here are the commands I have in COMMNDxx which includes some OS/390-specific commands:

COM='D T'                Very first one. Use to be recommended for SDSF
COM='D ASM'
COM='TRACE STATUS'
COM='D TRACE'
COM='D M=CPU'
COM='D M=STOR'
COM='D M=ESTOR'
COM='D D,O'
COM='D D,S'
COM='D OPDATA'
COM='D IPLINFO'
COM='D PARMLIB'
COM='D SSI,ALL'
COM='D SLIP'
COM='D IOS,CONFIG(ALL)'
COM='D IOS,MIH,TIME=ALL'
COM='D PROG,EXIT'
COM='D PROG,APF'

You would also want to modify/verify your IEASYSxx member to list the startup values. Here are some samples:

LNK=(00,L),
LPA=(00,L),
MLPA=(00,L),
PAGE=(PAGE.systemid.PLPA,
      PAGE.systemid.COMMON,
      PAGE.systemid.LOCAL,L),

I also have created a started task called CAS9INFO which gets started after CA90 Services is initialized. CAS9INFO invokes the CA90 services trivia programs. I kick off my CAS9INFO by having it included in my CA90 services PPOPTION automatic commands member CAUTOCMD. Here is my JCL for the CAS9INFO started task:

//CAS9INFO PROC
//*-----------------------------------------------------------------***
//*                                                                 ***
//* DISPLAY ALL OF THE CA90S INFORMATION WE CAN TO THE CONSOLE      ***
//*                                                                 ***
//*-----------------------------------------------------------------***
//*
//** INVOKE  THE  CAI  RESOURCE INITIALIZATION MANAGER UTILITY.
//** CAIRIMU  DISPLAYS  THE  CURRENT  STATUS OF ALL INSTALLED CAI
//** PRODUCTS.
//*
//CAIRIMU  EXEC PGM=CAIRIMU
//*
//** INVOKE  THE  CAI  DYNAMIC  SMF  DATA  INTERCEPTOR UTILITY.
//** CAISMFU  DISPLAYS  THE  CURRENT  STATUS OF ALL INSTALLED  CAI
//** SMF INQUIRY AND MANAGEMENT ROUTINES.
//*
//CAISMFU  EXEC PGM=CAISMFU
//*
//** INVOKE  THE  CAI   SUBSYSTEM  INTERFACE  UTILITY.  CAISUBU
//** DISPLAYS  THE  CURRENT   STATUS  OF  ALL SUBSYSTEMS INSTALLED VIA
//** CAIRIM. OUTPUT IS ISSUED
//*
//CAISUBU  EXEC PGM=CAISUBU

Here is my REXX exec to see this information from TSO:

/* REXX: Show CA90 Services information */
"TSOEXEC CAIRIMU"
say " "
say "Hit the Enter key for more..."
pull it
"TSOEXEC CAISMFU"
say " "
say "Hit the Enter key for more..."
pull it
"TSOEXEC CAISUBU"
say " "
say "Hit the Enter key to end"
pull it

Started Task JCL

Last Modified: 1997-12-10

Most of the started tasks that I support have the program name as the symbolic &ENTRY. This allows me to test the JCL via IEFBR14. See my JES2 JCL for an example. Here is my JCL for testing started task JCL with IEFBR14 as batch jobs:

//jobcard here
// EXEC JES2,ENTRY=IEFBR14

//jobcard here
// EXEC NET,ENTRY=IEFBR14

//jobcard here
// EXEC CAS9,ENTRY=IEFBR14

Since I ran my modified JES2 proc through C/I and actually executed a sucessful batch job, I won't see the dreaded JCL error message at JES2 startup time. This is only half of the verification. You don't know until a dataset is opened whether it is actually on the pack. I use my DA$PDSR program with the JES2 JCL and have it process all of the JES2 proclibs. Using the parm PREFIX=PROC, DA$PDSR will read all DDNAMEs starting with PROC. An MVS OPEN and reports on the members found are made. Here is a sample job: JCL:

//jobcard here
//*
//** ENSURE THAT THE JES2 PROCLIBS ARE OKAY BY EXECUTING THE
//** DA$PDSR PROGRAM WITH THE JES2 JCL.
//*
//SOURCEC  EXEC JES2,ENTRY=DA$PDSR,TIME=5,
//         PARM='PREFIX=PROC'
//*
//STEPLIB  DD DISP=SHR,DSN=ibmuser.DA.LOAD
//SYSPRINT DD SYSOUT=*
//REPORT   DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//ABNLDUMP DD DUMMY

Static end markers for your PARMLIB members

Last Modified: 1997-12-10

I place end markers in various PARMLIB members so I know about all dynamic updates since the IPL.

My APFLSTxx (now PROGxx) has a last entry as:

       APF ADD
           DSNAME(ZZZZZZZZ.ZZZZZZZZ.ZZZZZZZZ.ZZZZZZZZ)
           VOLUME(ZZZZZZ)

When I do a "D PROG,APF", I can easily see the datasets added after the IPL:

       CSV450I hh.mm.ss PROG,APF DISPLAY
       FORMAT=DYNAMIC
       ENTRY VOLUME DSNAME
          1  SYS1R1 SYS1.LINKLIB
          2  SYS1R1 SYS1.SVCLIB
        ...
        259  SYSM01 SYS9P.OLS.STM231.VTPLOAD
        260  ZZZZZZ ZZZZZZZZ.ZZZZZZZZ.ZZZZZZZZ.ZZZZZZZZ
        261  PP2002 SYS3P.SYS.INFOPAC.JCL.LOAD
        262  CIRCUS BOZO.CLOWNLIB

My IEFSSNxx member also has end of list entry:

       SUBSYS SUBNAME(ZZZZ)

When I issue a "D SSI" command, I see some subsystems that were dynamically added since the IPL:

       IEFJ100I  hh.mm.ss  SSI DISPLAY
       SUBSYS=JES2 (PRIMARY)
          DYNAMIC=YES     STATUS=ACTIVE       COMMANDS=REJECT
       SUBSYS=MSTR
          DYNAMIC=NO      STATUS=ACTIVE       COMMANDS=N/A
       ...
       SUBSYS=ZZZZ
          DYNAMIC=YES     STATUS=INACTIVE     COMMANDS=REJECT
       SUBSYS=CA$K
          DYNAMIC=NO      STATUS=INACTIVE     COMMANDS=N/A
       SUBSYS=TMS
          DYNAMIC=NO      STATUS=ACTIVE       COMMANDS=N/A

Keep track of your SMF records

Last Modified: 1997-12-10

I keep track of our shop's SMF records as comments in the 'SYS1.PARMLIB(SMFPRMxx)' member. When a new SMF record is needed, I refer to this source, update it with an available one and hand it out. For example:


/*-------------------------------------------------------------------*/
/* KNOWN INSTALLATION SMF RECORD USAGE:                              */
/*                                                                   */
/* 028 - NPM (REPLACED BY NETSPY)                                    */
/* 150 - NETSPY (LEGENT)                                             */
/* 199 - ORACLE                                                      */
/* 202 - EDI (TI)                                                    */
/* 203 - ROSCOE                                                      */
/* 205 - IXFP (RAMAC VIRTUAL ARRAY)                                  */
/* 210 - OMEGAMON FOR MVS II V350 - EPILOG @28-JAN-1997              */
/* 211 - OMEGAMON FOR MVS II V350 - SECURITY @28-JAN-1997            */
/* 230 - CA-ACF2                                                     */
/* 240 - CA-IDMS                                                     */
/* 242 - FT/EXPRESS (FILE TRANSFER FROM TSO)                         */
/* 243 - A2B SIM3270 (TCPIP TELNET)                                  */
/* 244 - PMDC (IDMS MONITOR)                                         */
/* 245 - EMC (DASD PERFORMANCE - UTILITY PARM=F5                     */
/* 246 - OMEGAMON/CICS                                @14NOV1995     */
/* 253 - HOURGLASS 2000 (CSW2 ONLY)                   @01OCT1997     */
/* 254 - FOCUS MSO (EDA) USAGE - STARTED TASK FOCNET1 @25AUG1993     */
/*                                                                   */
/*-------------------------------------------------------------------*/
     ACTIVE
     DSNAME(SYS1.SMF.MANX,
            SYS1.SMF.MANY,
            SYS1.SMF.MANZ)
     ...

Periodically you should monitor your SMF dump output and ensure that your list is complete. For example:

RECORD       RECORDS         PERCENT      AVG. RECORD
  TYPE          READ        OF TOTAL           LENGTH
     2             0
     3             0
     4           992           .85 %           215.01
     5           278           .24 %           157.56
     6           157           .13 %           263.95
   ...
   202            42           .04 %           223.00
   203           409           .35 %           278.87
   205           777           .66 %           317.77
   230         9,399          8.01 %         1,152.64
   244         6,039          5.15 %         3,850.24
   246        40,293         34.34 %           350.27
   254            10           .01 %           136.80
   255           108           .09 %           276.07

Here I see that somebody is writing SMF255 records which I don't have in my SMF record database.

Speed up your IPL by starting VTAM SUB=MSTR

Last Modified: 1997-12-10

Most shops start the VTAM address space (usually called NET) under JES2. You can speed up your IPL by starting VTAM as a SUB=MSTR started task in your SYS1.PARMLIB(COMMNDxx) member:

COM='S NET,,,(LIST=xx),SUB=MSTR'

At my shop, VTAM completely initializes before JES2 has completed the warm start. As with all SUB=MSTR started tasks, all datasets should be in the master catalog or you will need UNIT= and VOL=SER= to be able to locate them. Here is an example NET proc:

//NETWORK  PROC ENTRY=ISTINM01,
// SL01U=3390,SL01V=PPXA14,SL01D='SYS2.SSPLIB',
// LS01U=3390,LS01V=PPXA14,LS01D='SYS2.VTAMLST',
// LI01D='SYS1.VTAMLIB',
// LI02U=3390,LI02V=PPXA14,LI02D='SYS2.VTAMLIB',
// LI03D='NETVIEW.V3R1M0.SCNMLNK1',
// NC01U=3390,NC01V=PPXA12,NC01D='SYS2.NCPLIB'
//********************************************************************
//NET    EXEC  PGM=&ENTRY,
//             REGION=8M,                 UP FROM 6000K - DGA-23SEP94
//             DPRTY=(15,15),
//             TIME=1440,
//             PERFORM=9
//* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
//STEPLIB   DD DISP=SHR,DSN=&SL01D,          SSPLIB
//             UNIT=&SL01U,VOL=SER=&SL01V
//* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
//VTAMLST   DD DISP=SHR,DSN=&LS01D,          SYS2.VTAMLST
//             UNIT=&LS01U,VOL=SER=&LS01V
//* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
//VTAMLIB   DD DISP=SHR,DSN=&LI01D           SYS1.VTAMLIB
//          DD DISP=SHR,DSN=&LI02D,          SYS2.VTAMLIB
//             UNIT=&LI02U,VOL=SER=&LI02V
//          DD DISP=SHR,DSN=&LI03D           NETVIEW.V3R1M0.SCNMLNK1
//* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
//NCPLIB    DD DISP=SHR,DSN=&NC01D,          SYS2.NCPLIB
//             UNIT=&NC01U,VOL=SER=&NC01V

Keep track of EVERY SVC

Last Modified: 1997-12-10

You probably think you have all of your SVCs defined in your 'SYS1.PARMLIB(IEASVCxx)' member, but do you really? I put every SVC in my IEASVCxx including the ones added by CA90s and installation ESR SVCs as comments, for example:


/* ---> 199 <--- INSTALLED BY CAS9 -----------> CA-C RUNTIME (CA) */
SVCPARM 215,REPLACE,TYPE(6),EPNAME(DFHHPSVC) /* CICS V4.1 HPO       */
SVCPARM 216,REPLACE,TYPE(3),EPNAME(DFHCSVC)  /* CICS V4.1 SRB       */
SVCPARM 237,REPLACE,TYPE(4),EPNAME(VMCFAPF)  /* VPS                 */
SVCPARM 239,REPLACE,TYPE(3),EPNAME(DVGMCSVC) /* NETVIEW FTP         */
/* ---> 241 <--- INSTALLED BY CAS9 -----------> TMS (CA1) X SVC */
/* ---> 242 <--- INSTALLED BY CAS9 -----------> TMS (CA1) Y SVC */
SVCPARM 243,REPLACE,TYPE(4)                  /* S2K                 */
SVCPARM 244,REPLACE,TYPE(3),EPNAME(PMDCSVC)  /* PMDC (IDMS)         */
/* ---> 249 <--- INSTALLED BY CAS9 -----------> IDMS 12.0 */
/* ---> 250 <--- INSTALLED BY CAS9 -----------> IDMS 14.0 */
/* ---> 251 <--- INSTALLED BY CAS9 -----------> IDMS 12.0 GL9707 */
SVCPARM 252,REPLACE,TYPE(3)                  /* SYNCSORT 2.5D       */
SVCPARM 253,REPLACE,TYPE(3)                  /* ACF2 (VALIDATE)     */
SVCPARM 254,REPLACE,TYPE(3)                  /* ACF2 (ALTER)        */
SVCPARM 255,REPLACE,TYPE(3)                  /* FOCUS               */
/*------------------------------------------------------------------*/
/*                             THE REMAINDER ARE ESR SVCS           */
/*------------------------------------------------------------------*/
/* ===> 109-200 IGX00200 <===================> SAS           */
/* ===> 109-250 IGX00250 <==== 30-DEC1996 ===> SYNCSORT 3.6D */
/* ===> 109-251 IGX00251 <==== 18-SEP1997 ===> FILEAID 8.0.1 */
/* ===> 109-252 IGX00252 <==== 06-NOV1997 ===> SYNCSORT 3.6E */
/*------------------------------------------------------------------*/

Hints:

If you have the option, use an ESR 109 SVC instead of a non-ESR SVC for the program products that support ESR 109 SVCs.
Use EPNAME(name) for SVCs when you can. A real name beats a IGC00xxx module name any day.
Double check your SVC usage via a tool like SHOWMVS.

SUB=MSTR JCL

Last Modified: 1997-12-10

All SUB=MSTR JCL should have EVERY dataset name, unit name and volser parameter coded via symbolics. This will ensure that you can always start JES2, NET, CAS9 or whatever critical started task and override dataset specifications for deleted or moved files. Here is an example of our JES2 JCL

//JES2    PROC ENTRY=HASJES20,
//        P='WARM,NOREQ',
//        PRM=00,MAS=10,NET=10,UCB=10,
//        UPRM=3380,VPRM=XA1CAT,DPRM='SYS1.PARMLIB',           PARMLIB
//        U00A=3380,V00A=XA1CAT,D00A='SYS1.PROCLIB',           PROC00
//        U00B=3390,V00B=PPXA12,D00B='SYS2.PROCLIB',           PROC00
//        U00C=3390,V00C=PPXA12,D00C='SYS3.PROCLIB',           PROC00
//        U00D=3390,V00D=PPXA12,D00D='DIVISION.PROCLIB',       PROC00
//        U01A=3390,V01A=PPXA12,D01A='SYS4.PROCLIB'            PROC01
//*********************************************************************
//IEFPROC  EXEC PGM=&ENTRY.,TIME=1440,DPRTY=(15,15),PARM='&P'
//HASPLIST DD DDNAME=IEFRDER
//*
//HASPPARM DD DISP=SHR,DSN=&DPRM.(JESPRM&PRM.),
//            UNIT=&UPRM.,VOL=SER=&VPRM.
//         DD DISP=SHR,DSN=&DPRM.(JESNET&NET.),
//            UNIT=&UPRM.,VOL=SER=&VPRM.
//         DD DISP=SHR,DSN=&DPRM.(JESMAS&MAS.),
//            UNIT=&UPRM.,VOL=SER=&VPRM.
//         DD DISP=SHR,DSN=&DPRM.(JESUCB&UCB.),
//            UNIT=&UPRM.,VOL=SER=&VPRM.
//*
//PROC00   DD DISP=SHR,DSN=&D00A,UNIT=&U00A,VOL=SER=&V00A
//         DD DISP=SHR,DSN=&D00B,UNIT=&U00B,VOL=SER=&V00B
//         DD DISP=SHR,DSN=&D00C,UNIT=&U00C,VOL=SER=&V00C
//         DD DISP=SHR,DSN=&D00D,UNIT=&U00D,VOL=SER=&V00D
//*
//PROC01   DD DISP=SHR,DSN=&D01A,UNIT=&U01A,VOL=SER=&V01A

I see a condition only once every 5 years or so where JES2 gets an I/O error trying to read a PROCLIB member. IBM may have already fixed this with later releases of JES2, but if not you sometimes need to switch PROCxx to correct a JES2 I/O error. Here is a sample job that does this:

//jobcard here
//*
//**   USE THIS JOB IF //PROC00 IN JES2 GETS AN I/O ERROR VIA MESSAGE
//**
//**     IEFC417I PROCLIB DEVICE I/O ERROR READING FOR JOB xxxxxxxx
//**
//**   OPENING ANOTHER //PROCXX WILL CAUSE JES2 TO REOPEN PROC00
//*
/*JOBPARM PROCLIB=PROC01
// EXEC procedure.in.//PROC01

After running this job, you shouldn't see any more IEFC417I messages.

Protect against and recover from JES2 PROCLIB problems

Last Modified: 1998-03-14

This was posted on the IBM-MAIN newsgroup/mailing-list:

   We had a problem today, like this. One of the dataset which was
concatenated to JES2 proc was accidentally deleted and only one guy
has logged in the System. Later every logon was rejected, stating a
JCL error.

   We finally edited the JES2 proc and disabled the particular dataset
concatenation and recycled JES2. Then the logon problem was solved. I
would like to know what are the precautionary measures to be taken to
come out of this sort of situation.

   For ex., If nobody can logon to TSO due to some problem, how it can
be alleviated. As I am new to the MVS System area, kindly suggest some
solutions.

K.Viswanathan.

Giliad Wilf responed with this post:

Aside from protecting PROCLIBs against unauthorized access, we have
additional measures, and I'm thinking about a third:
1. Every common proclib DD in the JES2 procedure is defined this way:
   //  DD DISP=SHR&DISASTR,DSN=SYS1.PROCLIB         col. 72 -->  X
   //     DSN=hlq.dsname
   The default value of &DISASTR is ', ' and this causes the next
   line to be taken. When a proclib common to several systems is
   damaged, we only have to restart JES2 as follows:
   S JES2,DISASTR=
   The null value makes only SYS1.PROCLIB be considered, while all
   secondary lines are ignored. Since every system has its own
   SYS1.PROCLIB, there is always a way to start JES2 somewhere and
   carry out a recovery action.
2. Zapping IKJEFLC's ATTACH parmlist to make it specify JSTCB=YES.
   You have to prepare a special NET, TSO, and logon procedures whose
   names will also be listed as subsystem names in IEFSSNxx, and
   place them in SYS1.PROCLIB. They must not contain any JES2-managed
   dataset. This will enable NET, TSO, and a user whose name is to be
   identical to the name of the logon procedure, to start as subsystems
   and do whatever recovery is required.
3. Write IFG0EX0B that will prevent a destructive backmerge to the
   DSCB during OPEN. This will also bar inexperienced sysprogs from
   stumping on a directory of a proclib, or any other vital PDS.
I'm sure there are several more measures..

Also see my discussion about hints for SUB=MSTR JCL. If you have TCP/IP and FTP running, an alternative would be to fire up FTP to MVS and replace the SYS1.PROCLIB(JES2) member without the missing dataset, hot start JES2, logon to TSO and restore the deleted JES2 proclib.

Keep track of your CA products in your LMP keys member

Last Modified: 1998-02-01

Make keeping track of your Computer Associates product easier by putting product information as comments in your CA90s KEYS PPOPTION member. By spacing the comment product code on the same column as the PROD(??) line, it will stay with the line when you sort your KEYS member. For example:

*---------------------> Start of member=KEYS
*--> 00=OS/EasyTrieve?
Prod(00) Date(31AUG00) CPU(9021-962 /123456) LMPCODE(?)
*--> 6F=CA-Easytrieve Plus
Prod(6F) Date(30JUN04) CPU(9021-962 /123456) LMPCODE(?)
*--> 7E=CA-EasyTrieve Plus IDMS/R option
Prod(7E) Date(30JUN04) CPU(9021-962 /123456) LMPCODE(?)
*--> B6=ONE/Viewpoint
Prod(B6) Date(30MAR00) CPU(9021-962 /123456) LMPCODE(?)
*--> B8=ONE/COPYCAT
Prod(B8) Date(30MAR00) CPU(9021-962 /123456) LMPCODE(?)
*--> BA=Intertest W/XA-ESA
Prod(BA) Date(31DEC99) CPU(9021-962 /123456) LMPCODE(?)
*--> F5=CA-IDMS/JOURNAL ANALYZER
Prod(F5) Date(29JUN99) CPU(9021-962 /123456) LMPCODE(?)
*--> FE=CA-ADS/ONLINE
Prod(FE) Date(30JUN04) CPU(9021-962 /123456) LMPCODE(?)
*--> FG=CA-IDMS ONLINE QUERY
Prod(FG) Date(30JUN04) CPU(9021-962 /123456) LMPCODE(?)
*--> FK=CA-IDMS/CULPRIT
Prod(FK) Date(30JUN04) CPU(9021-962 /123456) LMPCODE(?)
*--> FL=Library of Routines
Prod(FL) Date(29SEP98) CPU(9021-860 /071122) LMPCODE(?)
*--> G8=CA-IDMS/LOG ANALYZER
Prod(G8) Date(30JUN04) CPU(9021-962 /123456) LMPCODE(?)
*--> GI=CA-MICS Base set
Prod(GI) Date(30JUN04) CPU(9021-962 /123456) LMPCODE(?)
*--> GJ=CA-IDMS/CORE (DB+IDD+CV)
Prod(GJ) Date(30JUN04) CPU(9021-962 /123456) LMPCODE(?)
*--> GP=CA-IDMS DC
Prod(GP) Date(30JUN04) CPU(9021-962 /123456) LMPCODE(?)
*--> GQ=CA-IDMS DC
Prod(GQ) Date(30JUN04) CPU(9021-962 /123456) LMPCODE(?)
*--> GT=CA-IDMS SQL EXTENDED ARCHITECTURE
Prod(GT) Date(30JUN04) CPU(9021-962 /123456) LMPCODE(?)
*--> GX=IDMS Presspack
Prod(GX) Date(30JUN04) CPU(9021-962 /123456) LMPCODE(?)
*--> GY=CA-IDMS PERFORMANCE MONITOR
Prod(GY) Date(30JUN04) CPU(9021-962 /123456) LMPCODE(?)
*--> H5=CA-IDMS/MASTERKEY
Prod(H5) Date(30JUN04) CPU(9021-962 /123456) LMPCODE(?)
*--> H8=CA-IDMS/ONLINE LOG DISPLAY
Prod(H8) Date(30JUN04) CPU(9021-962 /123456) LMPCODE(?)
*--> I5=CA-IDMS/SCHEMA MAPPER
Prod(I5) Date(30JUN04) CPU(9021-962 /123456) LMPCODE(?)
*--> J6=JCLCHECK
Prod(J6) Date(30JUN04) CPU(9021-962 /123456) LMPCODE(?)
*--> L0=ONE (TMS/CA1)
Prod(L0) Date(31DEC99) CPU(9021-962 /123456) LMPCODE(?)
*--> L9=CA-IDMS/DB AUDIT
Prod(L9) Date(30JUN04) CPU(9021-962 /123456) LMPCODE(?)
*--> LG=CA-IDMS/TASK ANALYZER
Prod(LG) Date(30JUN04) CPU(9021-962 /123456) LMPCODE(?)
*--> LI=CA-IDMS/DB ANALYZER
Prod(LI) Date(30JUN04) CPU(9021-962 /123456) LMPCODE(?)
*--> LJ=LIBRARIAN (base)
Prod(LJ) Date(30JUN04) CPU(9021-962 /123456) LMPCODE(?)
*--> LU=LIBRARIAN (TSO/SPF Support)
Prod(LU) Date(30JUN04) CPU(9021-962 /123456) LMPCODE(?)
*--> MA=CA-IDMS/DB REORG
Prod(MA) Date(30JUN04) CPU(9021-962 /123456) LMPCODE(?)
*--> MB=CA-IDMS/DML ONLINE
Prod(MB) Date(30JUN04) CPU(9021-962 /123456) LMPCODE(?)
*--> OQ=DADS/PLUS
Prod(OQ) Date(30JUN04) CPU(9021-962 /123456) LMPCODE(?)
*--> PM=CA/IDMS/ADS ALIVE
Prod(PM) Date(26DEC97) CPU(9021-962 /123456) LMPCODE(?)
*--> RO=Roscoe 
Prod(RO) Date(30JUN04) CPU(9021-962 /123456) LMPCODE(?)
*--> U5=EasyTrieve Plus
Prod(U5) Date(30JUN04) CPU(9021-860 /123456) LMPCODE(?)
*--> UO=UCANDU 
Prod(UO) Date(01DEC98) CPU(9021-860 /071122) LMPCODE(?)
*--> X1=ACF2 
Prod(X1) Date(31DEC99) CPU(9021-962 /123456) LMPCODE(?)
*--> XS=CA-IDMS SERVER
Prod(XS) Date(30JUN04) CPU(9021-962 /123456) LMPCODE(?)
*---------------------> End of member=KEYS

On benefit of having the product name saved as comments is that you can easily figure out which product has a bad LMP key when the operator call you.

Hint: Take the comment lines above and put in your LMP key file and then sort on the PROD(xx) column (assuming you have LMP entries that are only 1 line).

Also: As seen above, I put "* START OF member" and "* END OF member" comments in all of my CA90s services RIM members for easy identification in the SYSLOG.

Another "Rescue" system option: your OS/390 install packs

Last Modified: 1999-03-05

When I install OS/390, I take the "Full System Replacement" option which creates an IPL-able system. I run my first IVP's under this "vanilla" version of OS/390. There are minimal installation changes like SYS1.PARMLIB(CONSOLxx), an IODF and VTAMLST support (No RACF!). The first non-IBM program I run after the IVPs is, by tradition, Gilbert Saint-flour's SHOWMVS. I print the SHOWMVS and SYSLOG output and see what's new.

After I run the IVPs, I leave this system alone (with the exception of new IODFs). I never intend to use this new master catalog or other support datasets on a production system. All new SYSRES datasets get added manually as needed.

So, my OS/390 install packs have another function: a Rescue system.

Here is my OS/390 volume layout method (shown at the R6 level):

Logical Volume	Physical volume	Comments
CATxxx (MVSCAT)	OSV26A	Contains CATALOG.OS390R6M (Master), CATALOG.OS390R6U (User), CustomPac ISPF dialog datasets, JES2 SPOOL and support, etc.
IPLVOL RESxxx	OSV26B	The Traditional SYSRES datasets catalogued to ******
RESxxx	OSV26C	The rest of the SYSRES datasets for products I don't use at my shop like DFSORT, RACF, BDT, etc. All new products get pushed over here and cataloged to &SYSR2.
DLBxxx	OSV26D	Half of the DLIB stuff. I'm not emotionally attached to what goes where for DLIBS.
DLBxxx	OSV26E	Other half of the DLIB stuff. At OS/390 1.2, this all fit on a single 3390-3!
n/a?	OSV26F	HFS volume At OS/390 1.2, my SMPE.SMPPTS (the largest PDS in the SHOP!) grew and grew so it got moved from the "A" volume to the SMS-managed (for HFS) OS/390 install volume.

Dave Welch was kind enough to send me his JCL that creates a Single Pack Rescue System. I have modified it for OS/390 R6.

Dave's Pros and Cons:

OS/390 Install packs Rescue System
- Pros:
  - A complete OS/390 system that is already on spinning DASD
  - Maybe already on your system and ready for use now!
  - Good to have around in case you want to check something out on a "vanilla" version of the Operating System which has NO VENDOR HOOKS!
- Cons:
  - Maybe the User-Friendly-Wait-State was caused by new maintenance which is over here as well.
Single Pack Rescue System
- Pros:
  - Shielded by new maintenance. This is an already tested system that should come up.
- Cons:
  - An additional 3390-3 - Maybe a small price to pay though for system availability.

Using symbols for the operating system level

Last Modified: 2007-08-27

The LOADxx member points to a specific IEASYMxx member for each operating system level with the IEASYM keyword:

IEASYM   Z8

In the IEASYMxx member (in this case IEASYMZ8), I have two symbols for the operating system level, one meant for datasets and a shorter one for parmlib suffixes:

SYSDEF SYMDEF(&OSLEVEL.='ZOS18')   /* OPERATING SYSTEM LEVEL */       
       SYMDEF(&OSLVLS.='Z8')       /* OPERATING SYSTEM LEVEL SHORT */

My PROGxx member has a dataset near the top of the LNKLST that has overrides for this operating system level like JES2 exits which must match the OS level.

LNKLST Add Name(LNKLST01)                 
       Dsname(SYS2.&OSLEVEL..LINKLIB)

Return to the Planet MVS home page.