Why SMP/E exists: SYSMODs and the CSI
A z/OS system is built from tens of thousands of parts supplied by IBM and other vendors. SMP/E records exactly which version of every part is installed and why, so fixes can be added, checked and removed without guesswork. Changes arrive as SYSMODs, and SMP/E keeps its records in a VSAM database called the CSI.
The problem SMP/E solves
A z/OS system contains many thousands of load modules, macros, source members and panels, called elements. IBM and other vendors ship fixes for them constantly. Without a record of what is installed, nobody could answer basic questions: is this fix on our system? Which fix replaced this module? If I install this, what else do I need? SMP/E (System Modification Program/Extended) is the IBM tool that answers them. It installs software and service, checks prerequisites, and keeps an inventory of every element and every change that touched it.
SMP/E is not only for z/OS itself. Most products installed on z/OS, including CICS, Db2, IMS, MQ and many products from other vendors, are packaged for SMP/E. Some vendors use their own installers, so check each product's install guide.
SYSMODs: the units of change
Every change arrives as a SYSMOD (system modification): a package of elements plus modification control statements (MCS) that tell SMP/E what the package is and what it depends on. Each SYSMOD has a seven-character ID.
| Type | What it is | Typical source |
|---|---|---|
| FUNCTION | A product or a new release of a product; the base everything else applies to | A product install package |
| PTF | A tested, generally available fix (program temporary fix), the normal unit of service | IBM or vendor service orders |
| APAR fix | A temporary fix for one reported problem, usually shipped before the PTF that will replace it | IBM support during an open problem |
| USERMOD | A change made by your own site, such as an exit or a modified source member | Your systems programmers |
An APAR (Authorized Program Analysis Report) is IBM's record of a problem. The PTF that resolves it is said to *resolve* that APAR, and it usually *supersedes* any earlier APAR fix for it. SMP/E tracks those relationships, so it knows an APAR fix is no longer needed once the PTF is on.
++PTF(UJ12345)++VER(Z038) FMID(HBB77D0)PRE(UJ11111)SUP(AJ99999)++MOD(XYZMOD01)Each element is owned by exactly one FUNCTION, identified by its FMID. A PTF can only be applied if the FUNCTION it names is installed. The IDs and FMID above are made up for the example.
The CSI and its zones
SMP/E stores its records in a consolidated software inventory (CSI): one or more VSAM KSDS datasets. Inside the CSI, records are grouped into zones:
There is one global zone, but there can be many target and distribution zones. Sites commonly keep separate target zones for each copy of the system libraries they maintain, for example one for the set being prepared and one for the set in production, so maintenance never touches the libraries the running system is using.
How you run SMP/E
SMP/E runs as a batch job (program GIMSMP) with commands in SMPCNTL, or through its ISPF dialogs for queries. A SET BOUNDARY command chooses which zone the following commands work on.
//SMPE EXEC PGM=GIMSMP,REGION=0M //SMPCSI DD DISP=SHR,DSN=SYS1.ZOS.GLOBAL.CSI //SMPCNTL DD * SET BOUNDARY(GLOBAL). LIST SYSMODS. /*
Which SYSMOD type is used for a change written by your own site, such as a customised exit?
Show a hint
It is the user's own modification.
Show the solution
USERMOD. SMP/E then tracks your change like any other, and warns when IBM service touches the same element.
Common mistakes
SMP/E will not know about the change and later service can overwrite it silently. Package site changes as USERMODs.
The APAR is the problem record; an APAR fix is a temporary fix; the PTF is the tested permanent fix. Plan production maintenance around PTFs.
Applying to the wrong zone updates the wrong libraries. Name zones clearly and record which system residence set each one describes.
What you will see at work
- z/OS systems programmers spend a large share of their time on SMP/E: installing products, applying service and answering 'is this fix on?' questions.
- Application and subsystem teams ask the systems programmers whether a particular PTF is installed before opening a vendor problem.
- Auditors and security teams use SMP/E reports to confirm security fixes have been applied.
Key terms
Check your understanding.
Take this lesson's quiz and save your progress. Free.