0% found this document useful (0 votes)
160 views12 pages

SMP/E Installation and Upgrade Guide

The document outlines the process of upgrading z/OS from version 2.3 to 2.5, including the upgrade of Maniview from v6.3 to v7.1, and details the steps for software installation and management using SMP/E. It explains the various components involved in the installation process, such as FMIDs, PTFs, APARs, and the roles of different zones in the SMP/E environment. Additionally, it covers pre-installation checks, installation procedures, and post-installation management of software fixes.

Uploaded by

Richard Benjamin
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
160 views12 pages

SMP/E Installation and Upgrade Guide

The document outlines the process of upgrading z/OS from version 2.3 to 2.5, including the upgrade of Maniview from v6.3 to v7.1, and details the steps for software installation and management using SMP/E. It explains the various components involved in the installation process, such as FMIDs, PTFs, APARs, and the roles of different zones in the SMP/E environment. Additionally, it covers pre-installation checks, installation procedures, and post-installation management of software fixes.

Uploaded by

Richard Benjamin
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd

In one of the clients, we are moving from zos 2.3 to 2.5.

A part of that upgrade I did Maniview upgrade


from v6.3 to v7.1. Roadmap is to show to customer. Task name will be MVSPAS.
We will go to dataset which has OZI to invoke OZI installer and OZI latest is v4.5. BMCINSTL we will
invoke by giving ex.
For the new install we need to give option 2. Project name, description and jcl dataset
Install and config jcl we will get
Then we need to create CSI creation, zone creation, DDDEF, allocate job
DDDEF – is to define the target and DLIB zones lib are defined to our respective zone through DDDEF.
Allocate job – will map all the dataset in
In dataset last qualifier is in A means DLIB lib
In dataset last qualifier is in B, C or depends on product are Target lib.
Then we need to run RECEVIE job and it make FMID to sit in Global zone
Then we will run APPLYCHECK job and we will check all the are in place
In RECEIVE in GLOBAL, APPLYCHECK SET BDY(TARGET) and in APPLY SET BDY(TARGET),
ACCEPT in DLIB. ACCEPT will take backup and remove it from TARGET.
Only we will take target lib to client environment.
In Applycheck we need to check how many sysmods,
If you’re installing for first time ACCEPT we will do…It take a backup copy of a product in Target zone
and it will be DLIB zone. When we run accept job it will go from global zone.
We wont run Accept in maintenance. In base install APPLY and ACCEPT.
Now we are ready to config
Inside config dataset we will have readme member and it will have instruction.
IVP job we can run when we are ready for live.
SMPPTS full achuna then we need create with high space and need to map with DDDEF. spill dataset.
multi sys, hiper, userid we shouldn't bypass.
Introducing SMP/E
SMP/E:
System Modification Program Extended (SMP/E) is software that runs on z/OS and is used to manage the
installation of other z/OS software products and fixes.
Software Elements:
z/OS products can consist of many different types of elements. Possible elements include program
modules, REXX, CLISTs, ISPF panels, macros, source, and [Link] files. A single z/OS product may
have hundreds of these elements. Managing these elements when installing software can be a very large
task. SMP/E simplifies this task.
Fixes:
z/OS products can also have many fixes - fixes being modifications made after the software was released.
A fix can modify as little as one software element, or hundreds of different elements. Some z/OS products
can have hundreds of fixes installed. SMP/E simplifies the task of installing and managing these fixes.
Types of SYSMODS
FMID:
A z/OS software product is packaged as a function modification ID(FMID). Some software products may
be divided into several different FMIDs. Every software version and release will have a unique FMID.
PTF:
Fixes, changes or patches applied to software after it is installed by vendors are called program temporary
fixes (PTF). Every PTF must have a parent FMID. The FMID of the software that the PTF changes. A
PTF can only modify one FMID.
APAR:
Vendors sometimes supply a temporary fix to a problem. This may be provided to quickly get a product
running or to confirm that a change fixes a problem. This is called an authorized program analysis report
(APAR). Every APAR must have a parent FMID. The FMID of the software that the APAR changes. Like
PTF, an APAR can only affect one FMID. Vendors usually release a PTF to replace an APAR once it has
been confirmed and tested.
USERMOD:
Sometimes a product will need to be modified by the installer code may be changed, parameter or options
specified, or other functions may add. These changes can be packaged by the installer as a special SMPE
SYSMOD called a user modification or USERMOD. Like APAR and PTF, USERMOD must have a
parent FMID describing the software product that the USERMOD changes. A USERMOD can only
change one FMID.
Pre-Installation
Previously Installed:
In SMPE we can check if the product is installed or not.
 If the current version is higher version installed already then if we try to install the lower version
SMPE will cancel the installation.
 If the current version is higher version installed already then if we try to install the same version
SMPE will either re-install or cancel the installation depending on user preference.
 If the current version is lower version installed, then if we try to install higher version SMPE will
installation new version.
Requisite SYSMODs:
Prerequisite SYSMODs - other software or fixes that must be previously installed or installed at the
same time.
Corequisite SYSMODs - SYSMODS that require each other to operate properly. Normally installed at
the same time.
Pre-Installation
Before software can be installed, all software components must be packaged and available. As SMPE
manages these components, it can ensure that all are available before installation. Some software will
require fixes to be installed on other products before installation that is Prerequisite fixes. SMPE can
confirm these prerequisites and prevent installation if all prerequisites are not met.
During installation
Bind or link edit module - During installation, load module and program object are usually bound or
link-edited with system libraries and module.
Compile source code - Some products may be distributed as source code. This code may be compiled
during the product installation.
Copy libraries - Software components may need to be copied to specific libraries, HFS directories and
datasets.
Execute Scripts - Software components may require additional steps to execute z/OS UNIX scripts.
Install requisite software - SMPE can automatically install any requisite software that is not currently
installed.
Post-Installation
Fixes:
SMP/E features continue even after a software product is installed. Once installed, software may be
periodically updated with PTFs or APARs. These may fix a problem, add additional features, or prepare
the software product for use with new versions of other software. SMP/E can automate many of the tasks
that must be performed to install a PTF or APAR.
 Check that the fix is not already installed.
 Check that the parent software product is installed.
 Check that the requisite fixes are installed.
 Check that all fixed components exist.
 Install the fix.
Installing Software with SMP/E
Input Files:
All software products that can be SMP/E installed must be packaged in SMP/E format datasets. This
format is a group of related datasets called relative files, or RELFILEs. The first RELFILE dataset holds
SMPE statement and that is called SMPMCS. In MCS statements, the FMID will be stored.
Beginning an Install:
When installing a software product, the first step is to obtain all required RELFILEs. In the past,
RELFILEs were sent by mail on a tape. Today, RELFILEs can be downloaded from the internet, or even
provided by vendors in an email. For SMP/E to use these RELFILEs, they must be on a disk or tape that
can be accessed from z/OS.
RECEIVE:
 Once the RELFILEs are ready, SMP/E must perform preliminary processing before installing a
software product. This preliminary processing is called RECEIVE processing.
 The user instructs SMPE to receive the software with RECEIVE job. More than one FMID can be
received at the same time.
 SMPE checks that the product has not already been received. If so, it can be re-received or
RECEIVE processing can be cancelled.
 SMPE copies MCS statements from the first RELFILES to SMPPTS dataset which are PTF
temporary storage.
 SMPE verifies the syntax of the MCS statements in the SMPPTS.
 SMPE copies the other RELFILES to SMPTLIB dataset.
CSIs:
 SMP/E stores information about installed software products and their elements, fixes, and other
information in a special database called a consolidated software inventory (CSI).
 A CSI is one or more VSAM KSDS datasets that are used by SMPE to store information about
software products such as their version, status, elements and fixes.
 A single CSI can store information for many different products.
 A z/OS system can also have several separate CSI. A software product and its fixes must be
stored in a single CSI.
 A CSI is divided into sections called zones.
Global Zone: The most important SMPE zone is the global zone. This zone stores information from
receives processing. The global zone will hold information on every SYSMOD received, including every
element in the SYSMOD, Prerequisite and Corequisite. A CSI can only have one global zone.

APPLY:
 Once a software product has been received, it is ready for installation. The SMP/E install process
is called APPLY processing.
 We can apply for the product using the APPLY job. We need to specify the FMID to be applied.
Many FMIDS can be applied at the same time.
 It will check that FMID has already been received successfully.
 It will check that the current or more recent version of the FMID has not already been installed.
 SMPE will check the SMPE CSI to confirm that any prerequisite and corequisite SYSMOD have
been installed. If not, SMPE can be instructed to install them.
 SMPE will install software from the SMPPTS MCS statement and SMPTLIB datasets. The
datasets where this software is installed are called target libraries.
Target Zone:
 When software is applied, SMP/E does not store information in the CSI global zone. Instead, it
stores the information in another CSI zone called the target zone.
 When a SYSMOD is applied, its information is stored in the target zone. This can be in the same
VSAM dataset as the global zone or another.
 There can be one or more target zones in a CSI. Different zones could be used to separate
different products or even different versions of the same product.
 One target zone can store many different products.
 When a product is applied, the target zone to be used is specified before the APPLY command
using the SET BOUNDARY (TARGET) command.
 The global zone records all target zones in the SMPE CSI.
 When a SYSMOD is applied, its information in the global zone is not removed. It is modified to
note that the SYSMOD has been applied.
SYSMOD Elements:
A SYSMOD has one or more elements. Different elements require different installation processing.
 MOD: During installation, load module and program object are usually bound or link-edited with
system libraries and module.
 Program: Program is an executable module. When installing a program, it is copied to a load or
program library.
 SRC: It is assembler source code. The source code is copied to a target source library.
 MAC: It is a Macros, and it can be used during install processing of SRC elements.
 HFS: Software components may require additional steps to execute z/OS UNIX scripts.
 JAR: These are created using Java Jar.
 Data elements: These are elements that require no processing and copied directly to target
libraries. Several elements including REXX and CLISTs.
Target Libraries:
During APPLY processing, SYSMOD elements are installed into target libraries. These target libraries
hold the modules and other data needed for a software product to run. Because these libraries may be in
use by users or other processes, z/OS administrators never install directly into active target libraries.
Rather, SMP/E is used to install software products into an unused or inactive copy of the target libraries.
These can then be switched into use as appropriate.
ACCEPT:
 Once a software product has been applied, it can be backed up. This allows later SMP/E changes
to be backed out. This backup processing is called ACCEPT processing.
 Software products are not usually accepted until they are stable: when they have been running
successfully for some time. Some sites only accept SYSMODs just before applying for new ones.
 We need to run the ACCEPT job to the specific FMID to be accepted.
 It will check that the SYSMOD has been applied successfully.
 It will copy the software elements in a way like APPLY processing into backup datasets call
Distribution libraries (DLIBs)
 SMPPTS member and SMPTLIB datasets relating to the software are removed. RELFILES on
disk are also removed.
 Once a product has been accepted values in the distribution libraries can be used to backout later
software changes or fixes.
Distribution Zone:
 When software is accepted, SMP/E does not store information in the CSI global zone or the target
zone. Instead, it stores the information in another CSI zone called the distribution zone, or DLIB
zone.
 When a SYSMOD is accepted, its information is stored in DLIB. This can be in the same VSAM
dataset as the global zone or another.
 There can be one or more distribution zones in a CSI. There must be one corresponding DLIB for
every target zone.
 When a product is accepted, the distribution zone to be used is specified before the APPLY
command using the SET BOUNDARY (TARGET) command.
 The global zone records all distribution zones in the SMPE CSI.
 When a SYSMOD is accepted, its information is removed from the global zone but retained in
the target zone.
-------------------------------------------------------------------------------------------------------------------------------
Managing Software
APARs and PTFs:
After a software product has been installed, it will often require additional fixes: either permanent fixes
(PTFs) or temporary fixes (APARs). Sometimes PTFs and APARs are called software maintenance. In
many cases, PTFs will be shipped with a new software product, and installed as the product is installed.
Fix Input Files:
Software products (FMIDs) are packaged in a group of relative files, or RELFILEs. PTFs and APARs are
different and are usually packaged in a single sequential dataset or PDS member, merging MCS and
elements.

Fix Receive Processing:


PTFs and APARs are received in the same way as FMIDs. However, as they do not have RELFILEs, they
do not store information in SMPTLIBs. All information is saved in the SMPPTS.
APPLY and ACCEPT:
 PTFs and APARs are installed using the same SMP/E APPLY and ACCEPT processing as
FMIDs.
 Apply and install PTF/APAR in target libraries. Add SYSMOD to target zone.
 Accept and back up PTF/APAR in DLIB. Add SYSMOD to DLIB. Remove SYSMOD from
global and SMPPTS.
HOLDDATA:
 Vendors may prepare SYSMODS (FMIDs, PTFs, or APARs) that require additional processing or
planning which cannot be done automatically by SMP/E. For example, a PTF may require a z/OS
IPL, or a restart of a started task or component.
 To notify the user installing the SYSMOD, vendors can attach a special SMP/E object to a
SYSMOD: HOLDDATA.
 A PTF may require processing outside of SMPE before or after it is applied. In this case
HOLDDATA notifies the user installing the PTF that additional processing is required.
 Like SYSMODs, HOLDDATA consists of SMPE MCS statements. HOLDDATA MCS
statements specify the SYSMOD that the HOLDDATA related to and the reason for it.
 HOLDDATA can be resolved by another SYSMOD. SMPE treats the resolving SYSMOD as a
prerequisite. HOLDDATA will be bypassed if the resolving SYSMOD is applied or can be
applied at the same time.
 HOLDDATA can be manually bypassed during APPLY. This could be done once required
processing has been performed or planned.
 Once bypassed SMPE continues to apply the SYSMOD as normal.
HOLDDATA and PTFs:
HOLDDATA can also be released by vendors for a SYSMOD even after the SYSMOD has been released.
For example, a problem may be found with a PTF, which then needs fixing.
In this case, the HOLDATA cannot be packaged with the SYSMOD as the SYSMOD is already released.
Instead, it is packaged separately. This HOLDDATA is called external HOLDDATA. HOLDDATA
packaged with a SYSMOD is called internal HOLDDATA.
HOLDDATA Types:
DB2BIND:
A DB2 rebind must be performed after the SYSMOD is applied. The HOLDDATA will explain the
rebinds that are required.
DOC:
This is a SYSMOD that changes documentation or messages. The HOLDDATA will include information
on the documentation changes.
ENH:
This is a SYSMOD that enhances a software product. The HOLDDATA includes information about the
enhancements.
IPL:
An IPL is a SYSMOD that requires an IPL to become effective.
Error:
This means that a SYSMOD is in error and should not be installed. A later SYSMOD may resolve this
error.
HOLDDATA is received into the SMP global zone. When the SYSMOD is applied or accepted, SMP
check for any HOLDDATA for that SYSMOD in the global zone. HOLDDATA is not applied or accepted.
HOLDDATA Processing:
The vendor will include internal HOLDDATA in a SYSMOD or create external HOLDDATA for a
SYSMOD. The HOLDDATA is received into the SMPE global zone. When the SYSMOD is applied or
accepted, SMPE checks for any HOLDDATA for that SYSMOD in the global zone. HOLDDATA is not
applied or accepted.
Element:
SMPE SYSMODs perform an operation on an element. Elements can be many things, including modules,
source, macros and data elements.
Element actions:
A SYSMOD can create, replace, update or delete one or more elements.
Apply:
When a SYSMOD is applied, an entry is created in the target zone for every element in the SYSMOD. If
there is already an element entry, it is updated.
When a SYSMOD is accepted, an element entry is created in the distribution zone for every element in
the SYSMOD. If there is already an element entry, it is updated.
FMID:
For each element in the target and distribution zones, SMPE records the ID of the SYSMOD that created
it. This record is called the FMID. It is usually the FMID of the software product but can also be a PTF or
APAR.
RMID:
SMPE also records the ID of the SYSMOD to replace each element.
UMID:
SMPE records the ID of the last SYSMOD to update each element.

REJECT:
 SMP/E can back-out a SYSMOD receive for all SYSMOD types: FMIDs, PTFs, APARs, and
USERMODs. This process is called rejecting a SYSMOD.
 A SYSMOD can be rejected if it has been received but not applied or accepted.
 The user instructs SMPE to reject the SYSMOD.
 All SYSMOD information is removed from the SMPPTS.
 Any SMPTLIB for the SYSMOD are deleted. If the SYSMOD was packaged as RELFILES.
 The SYSMOD is removed from the CSI global zone.
Global Zone Cleanup:
SMP/E reject can also be used to clean up an SMP/E global zone by removing uninstalled SYSMODs,
SYSMODs that have been accepted - and not removed from the global zone - and SYSMODs that are not
related to installed FMIDs. REJECT can remove unneeded SYSMOD from the SMPE global zone.
RESTORE:
 SMP/E can also un-install software. This process is called restoring a SYSMOD. It backs-out a
SYSMOD apply, restoring elements from the distribution libraries.
 A SYSMOD can be restored if it has been applied and a previous SYSMOD that it modifies has
been accepted.
 The user instructs SMPE to restore the SYSMOD.
 SYSMOD elements in target libraries are restored from the most recent elements in the
distribution libraries.
 The SYSMOD is removed from the CSI target zone.
 The element entries are updated to reflect the backout of the SYSMOD.
Creating CSIs:
SMP/E CSIs are VSAM datasets. These datasets must be created and formatted before they can be used.
All SMP/E data can be stored either in one CSI within one VSAM dataset, one CSI in several VSAM
datasets, or several CSIs.
Creating Zones:
 Once a SMP/E CSI has been defined, the zones must be defined. This is done using a SMP/E
command called UCLIN.
 Global zone options are also specified using UCLIN.
 The name of the target and distribution zone and their VSAM datasets are also defined to the
global zone.
 UCLIN is used to specify options for the target zone. The name of the corresponding DLIB zone
must also be specified.
 UCLIN is used to specify options for the distribution zone. The name of the corresponding target
zone must also be specified.
Creating Datasets:
 SMP/E uses many different datasets other than the CSIs. These datasets can be allocated
manually, or SMP/E can be defined to automatically create them as they are required.
 Stores MCS and other information after RECEIVE. Store of RELFILEs after RECEIVE.
 Log of SMPE processing. Temporary store of macro elements used for assembling source
elements.
 Temporary backup of entries modified during APPLY processing. This is used during RESTORE
processing.
 Temporary store of source elements used for assembling source elements. SMPE works with
datasets for temporary data.
DDDEF:
Like any other task, SMP/E must allocate a dataset before it can be used. During a software install, it is
possible that SMP/E will need to allocate over a hundred different datasets.
These datasets can be defined in each SMP/E zone as an entry called a DD definition (DDDEF). A
DDDEF will hold the DD Name, dataset name, and any other information needed to allocate the dataset.
It can also hold parameters used to allocate a new dataset if it does not already exist, such as space,
format, block size, and so on. The same DDDEF entry can be in more than one zone.
SMP/E uses information in the DDDEF to automatically and dynamically allocate a dataset when it is
required.
UCLIN:
SMP/E UCLIN commands are administration commands for SMP/E. They are used to modify records in
the SMP/E CSI. You have already seen how they are used to create CSI zones. However, UCLIN
commands can do much more than that.
UCLIN ADD MOD(MOD001) FMID(FMID001) -> Commands such as this one can add, update or
remove an SMPE CSI element.
UCLIN ADD DDDEF(SMPWRK1) -> Command such as this one can add, update or remove a DDDEF
entry.
UCLIN DEL TARGETZONE(TGT001) -> Commands such as this one can add, update or remove an
SMPE CSI target zone entry in the global zone.
UCLIN DEL DLIBZONE(DLB001) -> Commands such as this one can add, update or remove an
SMPE CSI DLIB zone entry in the global zone.
UCLIN ADD OPTIONS COMPACT(YES) -> Commands such as this one can add, update or remove
global zone options.
Working with Zones
UNLOAD (UNLOAD SYSMOD(FMID001)):
This feature will dump one or more entries from a target or DLIB zone to a sequential dataset. UNLOAD
dumps entries in UCLIN format, which could be used to recreate the entries.
ZONECOPY (ZONECOPY (TGT001) INTO(TGT002)):
The ZONECOPY feature will create a copy of a target or DLIB zone.

ZONEDELETE (ZONEDELETE TARGETZONE(TGT001)):


This feature will remove a target or DLIB zone.
ZONEEDIT (ZONEEDIT DDE. CHANGE SYSOUT('*',A). ENDZONEEDIT.):
With this feature you can change multiple entries at the same time. This is the same as UCLIN but
performs mass changes in one statement.
ZONEEXPORT (ZONEEXPORT (TGT001) OUTFILE(EXPORT1).):
The ZONEEXPORT feature will back up a global, target or DLIB zone. This command creates a
sequential file. This sequential file can be used by the ZONEIMPORT command to recreate or restore a
zone.
ZONERENAME (ZONERENAME (TGT001) TO(TGT002) SAMEDATASET.):
This feature will rename a target or DLIB zone.
SMPE Reports
SYSMOD Status:
This report is automatically produced after any APPLY, ACCEPT or RESTORE processing. It shows the
status of every SYSMOD, the success or failure of each and any reason for error.
Bypass HOLD reason:
This is automatically produced after any APPLY or ACCEPT processing. It lists all HOLDDATA that was
bypassed.
Element summary:
This report is automatically produced after any APPLY, ACCEPT or RESTORE processing. It lists the
status of all elements affected by SYSMODs processed.
LIST:
The SMPE LIST command is used to list entries in the SMPE CSI zones. In this example, information
from the SYSMOD FMID001 is listed.
EXCEPTION SYSMOD:
The REPORT ERRSYSMOD command produces a list of all installed SYSMODs with unresolved
HOLDDATA. These SYSMOD may have been installed before HOLDDATA was received.
SMP/E and the Internet:
To obtain PTFs, users usually must order a tape with the PTFs, APARs, and HOLDDATA including any
requisites, or manually download them from a web page. SMP/E can directly RECEIVE PTFs, APARs,
and HOLDDATA from IBM servers over the internet. This facility is called Internet Service Retrieval.
Once set up, a special format of the RECEIVE command will order, download, and receive any PTFs,
APARs, and HOLDDATA required. These files can be delivered in the form of a GIMZIP package and be
extracted using a GIMUNZIP service routine and then processed using the SMP/E RECEIVE command.
Many sites regularly run a job to receive all closed PTFs and HOLDDATA for installed products.
Pre-req miss
re-work level one ptf iruku next ptf apply
link edit la error sysprint dataset storage
during apply check we need to make sure enough space

Sometimes USS path issue mount point issue few module will update in the zfs path.
while receive SREL value SMPTLIB
DDDEF correct allocation. 1.1 zone select option 2 it will show

program directory
product vanganum
unpack pananum
jcl eduthu rec, appl check and apply
configuration - in the sense what we need to add like apf, lnklst

Common questions

Powered by AI

SMP/E manages HOLDDATA by integrating notifications about required manual interventions or additional processes that cannot be automated. These notifications are attached as special objects within a SYSMOD, indicating if further actions such as a rebind, reboot, or documentation updates are necessary. During the APPLY process, SMP/E checks for HOLDDATA associated with each SYSMOD in the Global Zone and ensures it is addressed either by deferring the application of the SYSMOD or by allowing its bypass once necessary preparations are confirmed. HOLDDATA may be internal or external and needs to be resolved by another SYSMOD or manually, depending on the situation .

UCLIN commands in SMP/E are used to meticulously manage the CSI zones by adding, updating, or removing elements, DDDEF entries, zone entries, and global zone options. By performing these meticulous operations, UCLIN ensures that the software environment is configured correctly and consistently, preventing errors or conflicts in software installations. This control and precision maintain the integrity of the CSI, ensuring that it accurately reflects the system's configuration and status. The advantage of using UCLIN is that it allows administrators to fine-tune the software environment, enabling systematic and structured updates and optimizations .

The APPLY and ACCEPT processes in SMP/E serve distinct roles in software management. APPLY is responsible for the installation of SYSMODs into target libraries, effectively placing the software in a state where it can be actively used and tested. During APPLY, records are added to the target zone, helping maintain a log of changes for each software product. ACCEPT, on the other hand, signifies process stabilization; SYSMODs are backed up into Distribution Libraries (DLIBs), and entries are made in the Distribution Zone, signifying that these software changes are now part of the standard system and can be used to back out subsequent changes if needed. While APPLY focuses on operational deployment, ACCEPT ensures long-term retention and stability of these applied changes .

Distribution Libraries (DLIBs) in SMP/E enhance software installation and backout processes by serving as backup locations for software elements and ensuring that configurations can be reverted if necessary. When a SYSMOD is accepted, its software components are copied to the DLIBs, allowing these libraries to act as a stable reference point. This enables the restoration of the system to a previous state if future changes introduce errors. By maintaining these libraries separately from active target libraries, administrators can ensure that software elements are preserved for rollback purposes, thus maintaining the integrity and reliability of the application's environment .

SMP/E facilitates software version and update management on a z/OS system through its use of Consolidated Software Inventories (CSIs). A CSI stores information about installed software, including their versions, SYSMODs, elements, and any fixes. It is divided into zones—such as Global, Target, and Distribution zones—which support different stages of the software lifecycle, from receiving to applying and accepting updates. This structured approach ensures that dependencies are met and that configurations are consistent across the systems. Moreover, CSIs allow multiple products and versions to be maintained separately, minimizing conflicts and facilitating rollback or restoration if necessary .

The 'REJECT' function in SMP/E is designed to remove an uninstalled SYSMOD from the Consolidated Software Inventory (CSI) and its associated datasets, effectively backing out a received SYSMOD that has not been applied or accepted. This process involves deleting any related SYSMOD information from the SMPPTS, removing SMPTLIB datasets if they were created, and cleaning up the Global Zone by removing references to uninstalled or unrelated SYSMODs. By using REJECT, z/OS administrators can ensure that only desired software elements are present in the system, reducing system clutter and avoiding the potential conflicts of unneeded SYSMODs .

The Global Zone is central to the SMP/E installation process because it stores information about all received SYSMODs, including every element, prerequisite, and corequisite. This is significant as it ensures that all software dependencies and requirements are tracked and managed consistently. A Consolidated Software Inventory (CSI) can only have one Global Zone, emphasizing its unique role in managing the installation metadata that impacts subsequent installation steps like APPLY and ACCEPT. The Global Zone also influences the recording of related SYSMODs across other zones, facilitating efficient management of software updates and dependencies .

The RECEIVE process in SMP/E is crucial as it initializes the installation by verifying and preparing the software packages for subsequent installation steps. RECEIVE involves examining the syntax of MCS statements, storing these statements and associated RELFILEs into their respective datasets (SMPPTS and SMPTLIB), and ensuring that the software product has not been previously received. It prevents redundant installations and sets the stage for a smooth installation process by resolving all preparation-related issues before the actual software is applied to the system .

HOLDDATA types such as DOC, ENH, and IPL play a pivotal role in SMP/E’s maintenance protocol by informing administrators about special considerations or requirements that accompany certain SYSMODs. DOC HOLDDATA indicates documentation changes, ENH provides information on enhancements to the software, and IPL denotes that a system restart is necessary. These types ensure that all necessary actions are accounted for beyond straightforward automated installation, serving as critical checkpoints for administrators to address organizational documentation, take advantage of new features, or manage system changes like IPLs. They ensure a more seamless update process and help mitigate risks associated with deploying new software or fixes .

SMP/E's capacity to handle multiple SYSMODs simultaneously greatly enhances software maintenance efficiency on z/OS by allowing the batching of related updates, such as PTFs and APARs, alongside the main software modifications provided in FMIDs. This capability streamlines the process of keeping software up to date, as dependencies and prerequisites can be installed in tandem, reducing the administrative overhead of sequential installation processes. Consequently, it minimizes downtime and ensures coherent updates across multiple products or versions, thereby optimizing operational efficacy and system stability .

You might also like