Jump to content

SMP/E

From Alfawiki
System Modification Program/Extended (SMP/E)
Company typeProprietary software
IndustrySoftware installation and maintenance
FounderIBM
Headquarters
United States
Area served
z/OS platforms
ProductsSMP/E software for software installation and modification tracking on z/OS
OwnerIBM

System Modification Program/Extended (SMP/E) is the proprietary evolution of the original System Modification Program (SMP), engineered to oversee software installation and modification tracking on z/OS platforms.[1][2][3][4][5]

SMP/E facilitates management of various software versions, implements patches and updates (PTFs), supports testing phases and rollback procedures, enables "trial run" pseudo-installations to confirm actual deployment, maintains audit trails and security logs, and centralizes control over all software installations within z/OS environments.

Although it is possible to install software on z/OS without utilizing SMP/E, the majority of mainframe administrators opt for SMP/E-enabled solutions when handling complex software suites. Mastery of Job Control Language (JCL) is typically necessary to operate SMP/E effectively, with most vendors providing sample JCL scripts. The rigorous software management approach embedded in SMP/E extends to product documentation; IBM and third-party suppliers furnish standardized "Program Directory" manuals that align with SMP/E methodologies. These guides specify prerequisites and co-requisites for installations.

Using SMP/E for system maintenance promotes system consistency by preserving stable states and accurately auditing all modifications.[6]

History

IBM initially introduced SMP within OS/360 and OS/VS environments to replace semi-automated methods relying on utilities like IEBEDIT and IMAPTFLE. Four free versions of SMP were released, with notable advancements occurring especially between SMP3 and SMP4. All these versions stored tracking information in partitioned data sets (PDSs).

SMP/E was developed for OS/VS systems; its Release 2 represents the final version compatible with OS/VS1. Unlike SMP versions 1 through 4, SMP/E stores tracking data in VSAM datasets. Initially distributed separately, SMP/E is now integrated as a component of z/OS.

IBM also created analogous tools tailored for other operating systems, such as Maintain System History Program (MSHP) for DOS/VS, and Virtual Machine Serviceability Enhancements Staged (VM/SP SES)—currently known as VMSES/E—for VM/SP through z/VM platforms.

Concepts

Each IBM software product—and most non-IBM packages—is assigned a unique seven-character identifier called an FMID (Function Modification ID), which denotes the specific software and its version. The primary FMID is referred to as the Base FMID; for instance, DB2 Version 9’s Base FMID is HDB9910. Additional features that can be installed separately have associated Dependent FMIDs, such as JDB9910 for DB2 English language panels.

A software product comprises multiple elements, which are individual components like object modules (MOD), macros (MAC), sample programs (SAMP), among others.

The CSI (Consolidated Software Inventory) is a dataset that records the contents of distribution and target libraries. It holds metadata identifying installed FMIDs and elements, tracks the most recent update applied, and contains references to related libraries.

A SYSMOD (System Modification) represents any change applied to the system, including:

  • Function SYSMODS, which install new products or releases.
  • PTF SYSMODS, official fixes issued by IBM.
  • APAR FIXES, which are less formal IBM corrections.
  • USERMODS, user-created modifications such as site-specific exits.

Each SYSMOD carries a unique seven-character identifier known as the SYSMOD ID. Upon installation, this ID is logged in the CSI as the RMID (replacement module ID).

SMP/E uses a declarative syntax called MCS (Modification Control Statements) that precedes each SYSMOD to provide identification details and installation instructions. MCS statements specify SYSMOD type, ID, applicable FMIDs, and other relevant information.

Prerequisites (prereqs) denote SYSMODS that must be installed before another; corequisites (coreqs) are SYSMODS required to be installed simultaneously; when one SYSMOD functionally replaces another, it is said to supersede it. These prerequisite, corequisite, and supersession relationships are defined within MCS statements. A requisite chain encompasses all direct or indirect requirements linked to a SYSMOD, often involving hundreds of related SYSMODS.

HOLDDATA refers to MCS directives marking SYSMODS that contain errors or require manual intervention before installation. Users must address these issues before proceeding with installation of held SYSMODS.

SMP/E differentiates between two library categories: Target libraries (TLIBS), which house executable code and runtime resources—originally limited but now commonly product-specific—and Distribution Libraries (DLIBS), which store master copies of elements primarily utilized by SMP/E itself. Unlike UNIX-style directories, IBM libraries generally contain only one type of data per library. Software products may include object libraries (MOD), ISPF panels (PNL), macro libraries (MAC), among others.

Use

SMP/E operates as a single extensive program executed as a batch job. Users interactively construct the SMP/E job stream through a sequence of ISPF panels, which guide input collection.

A typical workflow follows the sequence RECEIVE-APPLY-ACCEPT.

The SMP/E RECEIVE command handles SYSMODs obtained from external sources, traditionally from IBM-distributed PUT tapes and more recently from downloaded packages. Using the MCS, RECEIVE creates CSI entries for each SYSMOD, marking them as "RECEIVED" and storing their associated data.

SYSMODs in the "RECEIVED" state can be removed using the REJECT command.

The APPLY command installs one or multiple received SYSMODs into designated target libraries. Selection criteria include SYSMOD ID, SOURCEID, or all uninstalled received SYSMODs. The system checks requisite dependencies; any SYSMOD lacking necessary requisites, flagged as on hold, or superseded will not be applied. To minimize errors, SMP/E frequently auto-applies requisites that are still in "RECEIVE" status. Once installed, SYSMODs are updated to "APPLIED" status within the CSI. The APPLY CHECK option allows validation of installations without actually applying changes.

If a SYSMOD has been applied but not yet accepted, the RESTORE command can be used to remove it.

The ACCEPT command finalizes the installation by moving SYSMODs into distribution libraries and marking them as "ACCEPTED" in the CSI. This step usually follows confirmation that the SYSMOD functions correctly. Within SMP/E, this action is irreversible unless all installation libraries and CSIs are deleted to restart the process.

SMP/E datasets

SMP/E’s complexity grows with each release. Important datasets include:

CSI Consolidated Software Inventory
Maintains records of distribution and target library details.
PTS PTF Temporary Storage
Stores received PTFs temporarily.
MTS Macro Temporary Storage
Contains macros present only in distribution libraries, allowing their use during APPLY assembly processes.
STS Source Temporary Storage
Holds source modules exclusive to distribution libraries for assembly during APPLY.

See also

Sources

SMP

SMP4

SMPE

SMPEREF

External links

  1. ↑ Cite error: Invalid <ref> tag; no text was provided for refs named UsersGuide
  2. ↑ Cite error: Invalid <ref> tag; no text was provided for refs named KleinLong2011
  3. ↑ Cite error: Invalid <ref> tag; no text was provided for refs named Moeller2005
  4. ↑ Cite error: Invalid <ref> tag; no text was provided for refs named TechnicalSupport1988
  5. ↑ Cite error: Invalid <ref> tag; no text was provided for refs named TechnicalSupport1989
  6. ↑ Cite error: Invalid <ref> tag; no text was provided for refs named SharpMosby1992
Retrieved from "https://www.alfawiki.org/index.php?title=SMP/E&oldid=28107"