If you are planning or actively working on SSI cluster 730 system upgrades and need, or
intend, to apply service as part of any post-upgrade actions, make note of the information
that follows.
As noted in the z/VM: 730 Installation Guide, it is possible to apply service to a
first-upgraded, SSI member 730 system in an SSI cluster, before any other member systems
are upgraded. However, when this is done, specific actions can be required for certain
z/VM components that have been updated with the applied RSU or PTF service. The
components to which this consideration applies are: DirMaint, ICKDSF and
(possibly) Language Environment (LE)
When service is applied that affects these components, the systemname $PRODS files
that are produced for non-upgraded members — after having run the SERVICE
command on the 730-upgraded member system — need to be adjusted. However, the need
to do so currently is not documented.
The information needed is provided here, in supplemental form, as an update for:
z/VM: 730 Installation Guide
Chapter 21. Finish your upgrade installation
Step 7. Perform post-upgrade tasks; Item 8
It is possible that with the upgrade of this system, you want or need to install
additional service for the new z/VM level. Possible reasons for doing so are:
-
to include service that exists on your previous z/VM level, which also is available for
the new release.
-
to install service that is recommended in the Product Support bucket (PSP bucket) for the
new release.
-
to install a newer RSU for the new release.
You might have used the CHKAPARS utility (see Chapter 12, Step 4, substep "6" on page 115)
to identify the service that you need to install. If you did not use CHKAPARS, you should
review the service you have installed on your z/VM 7.1 or 7.2 system (since z/VM 7.3
became available), to see if your z/VM 7.3 system requires additional service.
If you intend to install additional service, you should obtain that as you normally would,
and then log on to MAINT730 on your upgraded system to install it. After the service is
installed, you can run PUT2PROD to put the new service into production on your upgraded
system.
Note that in an SSI cluster, if the service you install includes PTFs for DirMaint and/or
ICKDSF, and possibly LE, the SERVICE command will create records to put that service into
production for all systems in your SSI cluster — including those that haven't yet
been upgraded. This is because DirMaint is upgraded on all members of the SSI when the
first system is upgraded, ICKDSF runs at the same release level on all current levels of
VM, and LE on z/VM 7.1 and 7.2 is maintained using a single product level.
If service was applied for any of these products, this will be evident in the SERVICE
message log, by the presence of message VMFSRV1233I (visible when VMFVIEW SERVICE
is used), which cites those components updated with service.
If any of the DirMaint, LE or ICKDSF components were serviced, special handling of their
put into production records (in the systemname $PRODS file) is needed, for those
systems that are still running the old release of VM. A utility exec (UG$PRMOD UTLSAMP)
is provided for this purpose.
To make use of the UG$PRMOD utility, do the following:
-
Download a binary copy of the UG$PRMOD BIN sample file.
-
Log on to the MAINTvrm user ID for the old release of VM (710 or 720), on the
system that hasn't been upgraded
-
Place a copy of the UG$PRMOD BIN file on the MAINTvrm 191 disk through appropriate
means (for example, FTP), such that a FIXed-format, LRECL 1024 file is created.
-
Confirm the 191 disk-resident UG$PRMOD BIN file has the correct attributes:
listfile ug$prmod bin a (isodate
The listed file should be reported as:
FILENAME FILETYPE FM FORMAT LRECL RECS BLOCKS DATE TIME
UG$PRMOD BIN fm F 1024 nn nn yyyy-mm-dd hh:mm:ss
If the BIN file is a FIXed-format, LRECL 80 file, reformat the file accordingly
using this CMS PIPELINE command:
pipe < ug$prmod bin a | fblock 1024 00 | > ug$prmod bin a f 1024
Again, confirm the 191 disk-resident UG$PRMOD BIN file has the correct attributes, using
the previously used LISTFILE command.
-
After the subject file has the correct format, copy this file to create a UG$PRMOD EXEC
file:
copyfile ug$prmod bin a = exec = (unpack olddate replace
-
Invoke the UG$PRMOD utility; specify the new z/VM level as an input operand:
ug$prmod 730
Make a note of any errors or warnings produced and resolve any problems. Upon completion
of the utility, if a current systemname $PRODS file was present, it will have been
modified for use on the current system, and a systemname $PRODUGX file may have
been created for later (post-upgrade) use on this same system. Note that the creation of
both such files is dependent on the particular service that has been applied on the
already-upgraded first member system.
-
If a systemname $PRODS file now still exists, it has records for only components
that pertain to the old release of VM. You should run PUT2PROD while logged on this
system, to process these outstanding records.
-
Log off the MAINTvrm user ID.
Note:
Until all members of this SSI cluster are upgraded to the new z/VM level, you will
need to repeat the above process for every system that has not been upgraded, whenever you
install service for the new level of VM.
As you upgrade the additional members of your SSI cluster, any service that you installed
on the new release will be moved to the newly upgraded systems automatically —
except for ICKDSF and possibly LE. To move that service into production on the systems as
they are upgraded, when you complete the upgrade for each system you should:
-
Log on the MAINT730 user ID on that system
-
Access the 41D disk as filemode Z
-
Check for a systemname $PRODUGX file on the Z disk.
If this file exists, you should rename it to systemname $PRODS Z and then run
PUT2PROD. This will process the records that you had previously saved using the UG$PRMOD
utility.