System Modification Program/Extended (SMP/E), the proprietary version of System Modification Program (SMP), "is a tool designed to manage the installation of software products on [a] z/OS system and to track the modifications" to those products.[1]: 1 [2][3][4][5]
SMP/E manages multiple software versions, helps apply patches and updates (PTFs), facilitates orderly testing and, if necessary, reversion to a previous state, allows a "trial run" pseudo-installation to verify that actual installation will work, keeps audit and security records to assure only approved software updates occur, and otherwise provides highly evolved, centralized control over all software installation on z/OS.
Although it is possible to design and ship software products that install on z/OS without SMP/E, most mainframe administrators prefer SMP/E-enabled products, at least for non-trivial packages. Using SMP/E typically requires some working knowledge of Job Control Language (JCL), although most products supply sample JCL. The rigorous software management discipline associated with SMP/E typically extends to product documentation as well, with IBM and other vendors supplying a standardized "Program Directory" manual for each software product that precisely aligns with the SMP/E work processes. The Program Directory provides detailed information on pre-requisites and co-requisites, for example.
Use of SMP/E to manage system updates helps ensure system integrity, by making sure that the system is in a consistent state and that changes to that state are properly audited.[6]
IBM introduced SMP in OS/360 and OS/VS[7] to replace semi-manual processes involving tools such as IEBEDIT[8] and IMAPTFLE.[9] IBM introduced 3 subsequent free releases of SMP, with significant changes between releases, especially from SMP3 to SMP4.[10] All four releases store tracking data in partitioned data sets (PDSs).
IBM introduced SMP/E[11] for OS/VS; however, SMP/E Release 2 is the last release to support OS/VS1. SMP/E stores tracking data in VSAM datasets rather than the PDSs that SMP release 1 through 4 use. While originally a separate product, SMP/E is bundled with z/OS.
IBM ultimately introduced similar tools for other operating systems, e.g., Maintain System History Program (MSHP) for DOS/VS, Virtual Machine Serviceability Enhancements Staged (VM/SP SES), (now VMSES/E), for VM/SP through z/VM.[12]
All IBM and most non-IBM software is assigned at least one seven character FMID (Function Modification ID) that identifies the piece of software and its release number. This first FMID is called the Base FMID. For Example DB2 Version 9's Base FMID is HDB9910. Separately installable features also have FMIDs (called Dependent FMIDs) that relate in some way to the base product – DB2 English language panels for Version 9's Dependent FMID is JDB9910.
A software package is composed of elements, individual components such as object files (MOD), macros (MAC), sample programs (SAMP), etc.[1]: p.37
The CSI (Consolidated Software Inventory) is a dataset containing the information that SMP/E needs to track the contents of the distribution and target libraries. The CSI contains "metadata" identifying the installed FMIDs and elements, the ID of the most recent update, and pointers to the associated libraries.
A SYSMOD (System Modification) is any modification to the system. This includes:[1]: p.38
Each SYSMOD is assigned a seven character SYSMOD ID to uniquely identify it. When the SYSMOD is installed this ID is recorded in the CSI entry for the element being added or replaced, and is called the RMID (replacement module id).
A simple declarative language called MCS (Modification Control Statements) provides the information to SMP/E identifying the SYSMOD and providing information on how to install it. Each SYSMOD is prefixed with a number of MCS statements that, for example, identify it as an APAR fix or PTF, supply the SYSMOD ID, identify the applicable FMID, etc.[13] : pp.5ff
Prerequisites or prereqs are SYSMODS that are required to be installed before a second can be installed. Corequisites or coreqs are two or more SYSMODS that must be installed together, none can be installed without the others. A SYSMOD supersedes, or sups another if its functionally replaces the first. This prereq, coreq, and sup information is provided in the MCS. A requisite chain is the "sequence of SYSMODs that are directly or indirectly identified as requisites for a given SYSMOD," for example, if A is a prereq for B, and B is a prereq for C, then A and B are the requisite chain for C and both need to be installed before C, although not necessarily in a separate run of SMP/E.[1]: pp.231, 226, 236, 232 Requisite chains can frequently become extremely involved and comprise hundreds of SYSMODS.
HOLDDATA is a set of MCS statements that indicate that specific SYSMODS contain errors or require manual processing outside the scope of SMP/E before they can be installed.[1]: p.229 The user is required to take action to fix the problem, if possible, before installing held SYSMODS.
SMP/E manages two types of libraries. Target libraries (TLIBS) contain the executable code and other information used to run the system. Originally there were a limited number of target libraries: SYS1.LINKLIB for executable programs, SYS1.MACLIB for standard macros, etc., but as of 2012 each software product usually has its own set of target libraries. Distribution Libraries (DLIBS) contain the master copy of each element for a system. Each product (FMID) has its own set of distribution libraries which are normally used only by SMP/E. Libraries in OS/360 and successors, unlike directories in unix, usually contain only one type and format of data. A software package may have object libraries (MOD), ISPF panels (PNL), macro libraries (MAC) and many more.
SMP/E is a single large program which runs as a batch job. A series of ISPF panels can be used to interactively build the SMP/E job stream based on user input.
One common sequence of steps is called RECEIVE-APPLY-ACCEPT from the commands used for each step.
The SMP/E RECEIVE command processes SYSMODs from a source outside of SMP. Previously this might have been a PUT tape distributed by IBM roughly monthly. More recently it might be a collection of SYSMODS downloaded over the internet. The RECEIVE process uses the MCS to create an entry in the CSI for each SYSMOD, marking its status as "RECEIVED", and stores the MCS information and the actual SYSMOD data.
The REJECT command can be used to delete SYSMODS in "RECEIVED" status.
The APPLY command installs one or more received SYSMODS into the appropriate target libraries. The SYSMODS to be applied can be selected by various criteria, for example a single SYSMOD can be selected by SYSMOD ID, all SYSMODS received in a group can be selected by SOURCEID, or all un-applied SYSMODS that have been received can be applied. The requisite chains for the specified SYSMODS are checked and SYSMODS without the proper requisites, in hold status, or that have been superseded are flagged as errors and are not installed. Commonly SMP/E is instructed to also automatically apply any requisites in "RECEIVE" status to minimize these errors. SYSMODS installed have their status changed to "APPLIED" in the CSI. APPLY CHECK can be used to check the SYSMODS to be installed without actually performing the installation.
The RESTORE command can be used to remove an applied SYSMOD that has not been accepted.
The ACCEPT command installs SYSMODS permanently into the distribution libraries and marks their status as "ACCEPTED" in the CSI. Normally ACCEPT is done once the SYSMODS are known to be performing correctly before the next APPLY of service. There is no way in SMP/E to undo an ACCEPT operation except to delete all installation libraries including the CSIs (and to start installation again).
SMP/E is a large, complex program; features and datasets are added with every release. The major SMP/E datasets are:[1][13]
