HOME
THE FIRM
Why BCS?
CLIENT LIST
Capabilities
Expertise
Proven Services
SUCCESS STORIES
ARTICLES
PRESENTATIONS

 

Structuring Your System 
For ServerPac

By Jim Schesvold and Glen Tessmer
Copyright © 2003 Best Customer Solutions, Inc.

The ease and simplicity of installing, upgrading, and operating your z/OS-based information system can be greatly affected (good or bad) by how the system is structured. Some key components of this structuring are:

  • Use of System Symbols.
  • Concatenated PARMLIB and PROCLIB.
  • Contents of Master Catalog, and implementation of User Catalogs.
  • Data set naming, including 3rd Party products.
  • Data set layout, including 3rd Party products.
  • Setup of SMP/E maintenance and migration environment.

One area where the above variables can have a dramatic effect is in the installation or upgrading of IBM mainframe systems software, such as z/OS, OS/390, CICS, or DB2. All of these products can be installed through an offering called ServerPac, which dramatically reduces the installation effort compared to previous methods. ServerPac eliminates the need for SMP/E installation steps, and when a system is structured properly, it can be integrated into an existing system without the need to change any non-IBM objects or related configuration aspects. This installation method is called a Software Upgrade (as opposed to a Full Replace), and is the simplest and easiest way to perform an upgrade.

Here are some aspects to consider when structuring your system for ServerPac, as well as an example configuration:

Use System Symbols To Reduce Naming Dependencies.

  • System Symbols serve as variables that provide substitution text in: (1) PARMLIB members, (2) the Master Catalog, (3) JCL for Started Tasks and TSO Logons (but not batch JCL), (4) system commands, (5) programs, and (6) dynamic allocations. This allows different LPARs requiring different PARMLIB settings to share the same PARMLIB members. As a general rule, the more PARMLIB members that can be shared, the better.
  • System Symbols should be specified for the second system residence volume and both distribution volumes to allow for indirect cataloging in the master catalog.
  • Define a system environment symbol (TEST or PROD) to allow for correct allocation of IBM subsystem and Vendor software run-time libraries in started procedures, logon procedures and PARMLIB member specifications.

Use Concatenated PARMLIB/PROCLIB To Separate ServerPac Entities.

  • Concatenated PARMLIB allows the use of up to 10 data sets, searched in first-to-last sequence, to be used to store PARMLIB members and parameters for a specific LPAR. The concatenation is called a logical PARMLIB.
  • Concatenated PARMLIB can be used to:
    • Share PARMLIB members between multiple systems.
    • Isolate and separate PARMLIB members/parameters by: (1) LPAR, (2) ServerPac vs. other IBM products vs. 3rd Party products vs. applications, (3) etc., etc. based on your system configuration.
  • Specify the following as a minimum PARMLIB concatenation, with data sets in the order listed. In most environments, this will be all the concatenation you need. Don’t create additional PARMLIB data sets unless compelling reasons exist.
  1. ‘SYS1.&SYSNAME..PARMLIB (this PARMLIB contains all customized members).
  2. ‘SYS1.PARMLIB’ (as distributed with ServerPac).
  3. ‘CPAC.PARMLIB’ (as distributed with ServerPac).
  4. ‘SYS1.IBM.PARMLIB (as distributed with ServerPac).

See the sections on IPLPARM System Library, PARMLIB System Libraries, and PROCLIB System Libraries, under Data Set Placement, below, for more specifics on how a concatenated PARMLIB is set up.

Minimize Non-ServerPac Data Sets In Master Catalogs.

Setup.

  • Define individual master catalogs for each LPAR on the corresponding IODF volume.
  • Use a data set name something like ‘CATALOG.&SYSNAME..MASTER’, whereby you use System Symbols to distinguish master catalogs from different LPARs.
  • The master catalog should only contain:
    • ServerPac-delivered data sets.
    • Customized z/OS operational data sets.
  • Indirectly catalog all ServerPac-delivered TLIB and DLIB data sets using System Symbols.
  • Directly catalog all customized operational data sets.
  • Either directly catalog the SMP/E data sets in the Test LPAR master catalog, or place them in a user catalog.
    • Keeping SMP/E data sets in the Test LPAR master catalog will reduce possibility of unintentional SMP processing on Production LPARs (if that is desired).
    • SMP/E data sets can also be restricted from certain LPARS by not cataloging the SMP/E user catalog on them.
    • A user catalog offers easier accessibility from multiple LPARs/processors.
    • If using a usercat, assign SMP/E data sets to it during ServerPac Dataset Layout, and Defining HLQ-to-Catalog Relationships steps. See ServerPac: Using the Installation Dialog, Chapter 8: Modifying the System Layout, at http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/CPP2UD40/8.0 and Chapter 9: Defining HLQ-to-Catalog Relationships, at http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/CPP2UD40/9.0.

Cleanup.
  • If you have applied a SYS1 prefix to data sets that do not come that way from IBM, try to find a way to remove SYS1 from the prefix so you can move the data sets to a user catalog. One situation where a goodly number of data sets may have been renamed to SYS1.** is for disaster recovery purposes (so an IPL can be performed at the disaster recovery site with only the master catalog restored), but in most cases there are alternatives (which in this case was to create a user catalog containing all products required during an IPL, that was restored right after the master catalog volume). Renaming these data sets can require some effort, especially if a lot of JCL is involved, but since upgrading software is an ongoing process, it’s usually worth the time.
  • If you have non-SYS1 data sets that don’t have specific requirements to be there, move them to a user catalog.
  • Restrict update ability (and in most cases, read access) to master catalog high level qualifiers, and eliminate the ability to create new high level qualifiers which are not defined to your security system.

Data Set Naming.

ServerPac Data Sets.

  • Target and distribution libraries defined during ServerPac installation should be left as delivered from IBM.
  • OS/390 system operational data sets should follow these naming conventions:
    • hlq.&SYSNAME..** (where hlq = ‘SYS1’, ‘PAGE’, etc… ).
    • For example:
    • ‘SYS1.&SYSNAME..**’.
    • ‘PAGE.&SYSNAME..**’.
    • ‘CATALOG.&SYSNAME..MASTER’.
  • OS/390 subsystem and component operational datasets should follow these naming conventions:
    • hlq.&SYSNAME..** (where hlq = ‘SYS1’, ‘FFST’, ‘TCPIP’, etc… ).

IBM Subsystem (CICS, DB2, etc.) Data Sets.

  • Use IBM-supplied data set names as delivered via CBPDO or ServerPac for installation data sets.
  • IBM subsystem software run-time data sets should follow these naming conventions:
    • ‘hlq.&ENVIR..**’ for required run-time data sets.
    • Where hlq = ‘SYS2’, ‘SYS3’, etc…, and &ENVIR = system symbolic (‘TEST’ or ‘PROD’).
  • Unique middle level qualifiers will be required for different variations of a subsystem running on the same LPAR (i.e. TEST, DEVELOPMENT, MODEL OFFICE, PROD, etc…).

3rd Party Product Data Sets.

  • 3rd Party software installation data sets should follow these naming conventions:
    • ‘hlq.product-id.version.**’ for all installed data sets.
      • Where hlq = ‘SYS2’, ‘SYS3’, etc…, product-id = ‘CA11’, ‘FILEAID’, etc… and version = installed version number (i.e. ‘V510’).
  • 3rd Party software run-time data sets should follow these naming conventions:
    • ‘hlq.product-id.&ENVIR..**’ for required run-time data sets.
      • Where hlq = ‘SYS2’, ‘SYS3’, etc…, product-id = ‘CA11’, ‘FILEAID’, etc… and &ENVIR = system symbolic (‘TEST’ or ‘PROD’).
  • Unique data set names will be required for different variations of a subsystem running on the same LPAR (i.e. TEST, DEVELOPMENT, MODEL OFFICE, PROD, etc…).

Data Set Placement.

IPLPARM System Library.
  • A customized IPLPARM library should be created on each LPAR’s IODF volume with the following naming convention: ‘SYS1.IPLPARM’.
  • The IPLPARM library should only contain the LOADxx member(s) specified in the Hardware Management Console activation profile(s) for each LPAR image.
  • Considerations for LOADxx:
  • Specify the following PARMLIB concatenation:
    1. ‘SYS1.&SYSNAME..PARMLIB’ (customized PARMLIB).
    • Note: Do not use the ‘&SYSNAME‘ system symbol in the LOADxx member. Specify the appropriate data set name for the customized PARMLIB created for the LPAR.
    1. ‘SYS1.PARMLIB’.
    2. ‘CPAC.PARMLIB’.
    3. ‘SYS1.IBM.PARMLIB’.
  • Specify the IEASYMxx PARMLIB member found in the customized PARMLIB that contains the system symbol definitions for the LPAR image being IPL’ed.
  • Only one LOADxx member is needed for the Test LPAR to specify the test IEASYMxx PARMLIB member.
  • Two LOADxx members will be needed for the Production LPAR; one will specify the normal production IEASYMxx PARMLIB member and one will specify the maintenance IEASYMxx PARMLIB member.
  • Do not code SYSPARM to allow WTOR prompting for the ‘SPECIFY SYSTEM PARAMETERS’ prompt. This will allow for fallback to previous IEASYSxx PARMLIB member specifications.

PARMLIB System Libraries.
  • A customized PARMLIB should be created on each LPAR’s IODF volume with the following naming convention: ‘SYS1.&SYSNAME..PARMLIB’.
  • This PARMLIB only contains members requiring customization.
  • Member naming conventions should follow established suffix rules:
    • Example: IEFSSN00 for current and IEFSSNFB ('FB' = fallback) for previously used member.
  • Considerations for specific members:
    • IEASYMxx:
      • Specify the following LPAR-specific System Symbols:
        • &SYSR2 – identifies the second system residence volume.
        • &ENVIR - identifies the system environment used in IBM Subsystem and Vendor Software runtime library naming conventions. (i.e. TEST and PROD).
      • Specify the following Common System Symbols:
        • &SYSD1 - identifies the first system distribution volume.
        • &SYSD2 - identifies the second system distribution volume.
      • Only one IEASYMxx member is needed for the Test LPAR to specify the test system residence volumes.
      • Two IEASYMxx members will be needed for the Production LPAR; one will specify the normal production system residence volumes and one will specify maintenance system residence volumes.
  • IEASYSxx:
    • The use of multiple PARMLIB members with different suffixes concatenated together is not recommended. This practice introduces significant complexity with limited operational benefits.
    • After changing any members in PARMLIB, create an IEASYSFB member with pointers to ‘FB’ suffixed members to allow for fall back to your previous PARMLIB configuration.
  • MSTJCLxx:
    • Do not specify an IEFPARM DD statement. The PARMLIB concatenation found in LOADxx will be used.
    • Specify the following PROCLIB concatenation in the IEFPDSI DD:
    1. ‘SYS1.&SYSNAME..PROCLIB’ (customized PROCLIB).
    • Note: Do not use the ‘&SYSNAME‘ system symbol in the MSTJCLxx member. Specify the appropriate data set name for the customized PROCLIB created for the LPAR.
    1. ‘SYS1.PROCLIB’.
    2. ‘CPAC.PROCLIB’.
    3. ‘SYS1.IBM.PROCLIB’.
  • The following IBM PARMLIBs should be left as delivered during the ServerPac installation process on the system residence volumes (&SYSR1 and &SYSR2):
    • ‘SYS1.PARMLIB’.
    • ‘CPAC.PARMLIB’.
    • ‘SYS1.IBM.PARMLIB’.

PROCLIB System Libraries.
  • The system PROCLIB concatenation is specified in the MSTJCLxx PARMLIB member described above.
  • A customized PROCLIB should be created on each LPAR’s IODF volume with the following naming convention: ‘SYS1.&SYSNAME..PROCLIB’.
    • Only contains OS/390 started procedures requiring customization and started procedures required by IBM Subsystem and Vendor Software installations.
  • The following IBM PROCLIBs should be left as delivered during the ServerPac installation process on the system residence volumes (&SYSR1 and &SYSR2):
    • ‘SYS1.PROCLIB’.
    • ‘CPAC.PROCLIB’.
    • ‘SYS1.IBM.PROCLIB’.

System Volume Configuration – An Example.
  • A system volume contains either (1)Target Libraries, (2) Distribution Libraries, (3) SMP/E data sets, or (4) z/OS operational data sets (MVS, JES, VTAM, DFSMS, TCP/IP, etc.).
  • Data set placement within a specific TLIB or DLIB system volume can be greatly simplified by using the IBM Recommended System Layout during ServerPac installation. For details on how to do this, see ServerPac: Using the Installation Dialog, Chapter 8.1: Creating the Recommended System Layout, at http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/CPP2UD40/HDRRSLDIV.
  • Target Libraries (TLIBs) are placed on the following volumes:
    • Test LPAR Volumes-1 set of runtime volumes.
    • Target libraries (TLIBs) on the following volumes:
    • TLIB volume 1 (REST01) – System Residence Volume 1 (System Symbol &SYSR1).
    • TLIB volume 2 (REST02) – System Residence Volume 2 (System Symbol &SYSR2).
      • Also include all CPAC.** data sets delivered in OS/390 ServerPac installation.
  • Production LPAR Volumes – 1 set of runtime volumes, 1 set of maintenance volumes.
    • Production Target libraries (TLIBs) on the following volumes:
    • TLIB volume 1 (RESP01) – System Residence Volume 1 (System Symbol &SYSR1).
    • TLIB volume 2 (RESP02) – System Residence Volume 2 (System Symbol &SYSR2).
    • Maintenance Target libraries (TLIBs) on the following volumes:
    • TLIB volume 1 (RESM01) – System Residence Volume 1 (System Symbol &SYSR1).
    • TLIB volume 2 (RESM02) – System Residence Volume 2 (System Symbol &SYSR2).
  • Distribution Libraries (DLIBs) are placed on the following volumes:
  • DLIB volume 1 (DLIB01) – System Distribution Volume 1 (System Symbol &SYSD1).
  • DLIB volume 2 (DLIB02) – System Distribution Volume 2 (System Symbol &SYSD2).
    • Note: If SMP/E jobs are to be restricted to the Test LPAR, the DLIB data sets should only be cataloged on the Test LPAR.
  • OS/390 or z/OS SMP/E data sets are placed on one volume (SMPE01).
    • This includes all SMPE*.** delivered with the z/OS or OS/390 ServerPac.
      • Note: If SMP/E jobs are to be restricted to the Test LPAR, the SMP/E data sets should only be cataloged on the Test LPAR.
  • Customized operational data sets are placed on the IPL volume (SYSP01):
  • Master catalog.
    • Data set name: ‘CATALOG.&SYSNAME..MASTER’.
  • Page data sets (PLPA, COMMON and LOCAL).
    • Data set name: ‘PAGE.&SYSNAME..PLPA’.
    • Data set name: ‘PAGE.&SYSNAME..COMMON’.
    • Data set name(s): ‘PAGE.&SYSNAME..LOCAL1 to LOCALn’.
  • JES2 or JES3 checkpoint data sets:
    • JES2 data set name 1: ‘SYS1.&SYSNAME..HASPCKPT’.
    • JES2 data set name 2: ‘SYS1.&SYSNAME..HASPCKP2’.
    • JES3 data set name 1: ‘SYS1.&SYSNAME..JES3CKPT’.
    • JES3 data set name 2: ‘SYS1.&SYSNAME..JS3CKPT2’.
  • JES2 or JES3 spool data set – TEST LPAR only:
    • Sized for TEST LPAR
    • JES2 data set name: ‘SYS1.&SYSNAME..HASPACE’.
    • JES3 data set name(s): ‘SYS1.&SYSNAME..dsname1-nn’.
  • Customized PARMLIB (‘SYS1.&SYSNAME..PARMLIB’).
  • Customized PROCLIB (‘SYS1.&SYSNAME..PROCLIB’).
  • SYS1.UADS (if used).
  • VTAM datasets:
    • Data set name: SYS1.&SYSNAME..VTAMLST.
    • Data set name: SYS1.&SYSNAME..VTAMLIB.
  • SYS1.BRODCAST.SYS1.IODFnn.
  • SYS1.IPLPARM.
  • SYS1.DAE data set.
  • SYS1.DUMP01-DUMP0n data sets.
  • SYS1.MAN1-SYS1.MANn data sets.
  • STGINDEX data sets (if used).
    • Data set name: ‘SYS1.&SYSNAME..STGINDEX’.
  • LOGREC data set:
    • Data set name: ‘SYS1.&SYSNAME..LOGREC’.
  • Subsystem control data sets :
    • Control data sets for SMS, HSM, TCP/IP, FFST, etc….
  • OS/390 installation documentation/JCL library.
  • Production JES2 or JES3 spool volume (SPLP00) – Production LPAR only.
    • JES2 data set name: ‘SYS1.&SYSNAME..HASPACE’.
    • JES3 data set name(s): ‘SYS1.&SYSNAME..dsname1-nn’.
  • HFS volume (OMVS01):
    • All HFS data sets defined for Unix System Services should use ‘OMVS’ as the high level qualifier.
    • Should be SMS managed but not required.
  • IBM Subsystem (CICS, DB2, IMS, etc.) volume(s) (SYSIxx):
    • User catalog(s) for associated HLQ’s.
    • All related SMP/E data sets.
    • Target and distribution libraries as delivered (release specific).
    • Copies of required run-time libraries (Load, ISPF, etc…) using established naming conventions.
  • Vendor Software volume(s) (SYSVxx):
    • User catalog(s) for associated HLQ’s.
    • All related SMP/E data sets.
    • Target and distribution libraries as delivered via SMP/E (release specific).
    • Non-SMP/E installed libraries (release specific).
    • Copies of required run-time libraries (Load, ISPF, etc…) using the following naming convention:
      • ‘hlq.product-id.TEST.**’ for use on Test LPAR.
      • ‘hlq.product-id.PROD.**’ for use on Prod LPAR.
      • Allows for use of library copy utilities and provides a staging environment when installing maintenance or new releases.
      • Eliminates the need to update PARMLIB, PROCLIB, Logon Proc’s with release specific data set names when installing new releases.

Maintenance and Migration Using The Above Configuration.

Hardware Management Console Setup.

  • Define use of current IOCDS in the RESET activation profile.
  • Create IMAGE activation profiles for the TEST LPAR, PROD NORMAL LPAR and PROD MAINTENANCE LPAR.
    • PROD NORMAL LPAR uses normal, Production Target volumes.
    • PROD MAINTENANCE LPAR uses Maintenance Target volumes.
  • Establish operational procedures for IPLing PROD NORMAL and PROD MAINTENANCE images.

Installing and Migrating Maintenance or a New Release.

  • SMP/E QUERY and RECEIVE may be performed on any LPAR with SMP/E capability.
  • SMP/E APPLY and ACCEPT should be performed on the Test LPAR to update only the SMP/E, Target and Distribution libraries. Migration to maintenance and normal production volumes will be performed after testing is completed.
  • Review SMP/E HOLDDATA for any actions required after application of maintenance PTF’s.
  • All system operational data sets should be reviewed for attribute changes during maintenance and migration to new releases.
  • Use DFSMS/DSS to perform a full-volume physical copy of the TEST system residence volumes to the maintenance system residence volumes.
  • Make changes to the production system configuration identified in the installation or maintenance process after providing fall back copies of data sets, members, etc…
  • IPL the production LPAR using the Hardware Management Console IMAGE activation profile that contains the maintenance system residence volume 1 and the correct LOADxx member in SYS1.IPLPARM on the production IODF volume.
  • After successful IPL and trial period is complete, use DFSMS/DSS to perform a full-volume physical copy of the maintenance system residence volumes to the normal production system residence volumes.
  • IPL the production LPAR using the Hardware Management Console IMAGE activation profile that contains the normal production system residence volume 1 and the correct LOADxx member in SYS1.IPLPARM on the production IODF volume.
  • For a new release:
    • Review new ServerPac delivered IPLPARM, PARMLIB and PROCLIB library members for changes or additions by comparing to libraries on the production system residence volumes.
    • OPERATIONAL DATA SETS
      • Define new operational data sets on the appropriate volume.
      • Review existing operational data sets for attribute changes and update or redefine as necessary.

For More Information.

1. z/OS V1R4.0 MVS Initialization and Tuning Reference – http://publib.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/iea2e230/CCONTENTS.

2. ABCs of OS/390 System Programming, Volume 2 – http://www.redbooks.ibm.com/pubs/pdfs/redbooks/sg245652.pdf.

3. Getting Started With PARMLIB – http://www.share.org/proceedings/sh96/data/S2820.PDF.

4. Giving OS/390 The Boot! – http://www.share.org/proceedings/sh91mo/data/S2891.PDF.

5. Recommended Data Set Layout For OS/390 – http://www.share.org/proceedings/sh91mo/data/S2859.PDF.

Disclaimer.

The opinions in this article are solely those of the authors, and the information herein is to be taken "as-is".

Back Up Next

Send mail to solution@mainframehelp.com with questions or comments about this web site.
Copyright © 2006 Best Customer Solutions, Inc.
Last modified: 06/13/2006