We have made major changes to the processes for performing both maintenance updates and initial product installs:
- WRT initial installs, we have completely done away with the use of SMP/E. Now the process is a straightforward unTERSE of an XMITs collection library followed by an XMIT-RECEIVEs job to create the several Product Libraries.
- WRT maintenance updates, these now do full replacements of all Product Library content.
This means that the product shipment package for both initial installs and maintenance updates is the identically the same file for both purposes.
Externally, the download page remains quite similar. But now when you select the DOWNLOAD FILES button, you will get three files:
- A TERSE'd file containing a full product replacement at the most current maintenance level.
- A $XDCUTRS job that will extract an XMITs collection library out from the TERSE'd file.
- A $README with detailed instructions for performing either a maintenance update or an initial product (re)install.
If you choose the FTP to Mainframe option for the download, a job named $XDCPULL will be sent to you that will FTP all three files directly into DBCOLE.XDCZ22.INSTALL.whatever datasets on your z/OS system.
You can then use those files to do either an initial product install or a maintenance update, whichever you prefer. Just follow the instructions in the $README file.
Overall, this new process makes maintenance updates both safer and easier:
- SAFER: There is a new pair of jobs... One ($XDCBKUP) can be used to checkpoint the Permanent Product Libraries prior to updating them. The other ($XDCUNDO) can be use to restore from the checkpoint if things go south.
- EASIER: There also is a new job ($XDCMPAR) that maintenance updaters can use to identify what product elements have changed. This provides a guide for determining what does and does not need to be reintegrated into your z/OS system.
- EASIER: Recognizing that most shops already create local copies of the Product Libraries under their own High Level Qualifier (HLQ), the new Maintenance Update process embraces that idea with the following changes:
- The classic DBCOLE.XDCZ22.* libraries are now considered to be the Temporary Product Libraries. They are used during the Maintenance Update process, but can be discarded when done.
- Your hlq.XDCZ22.* libraries are now considered to be the Permanent Product Libraries.
- The Maintenance Update process now recognizes that the Permanent Product Libraries might be integrated directly into your z/OS, so it now always references them via DISP=SHR.
- The Maintenance Update process now has a new clist ($XDCSUBM) for submitting jobs for execution. This clist allows you to provide both a custom job card and your local HLQ as inputs. It then uses that information to modify the job on the fly during submission. This minimizes substantially the changes you may need to make to our maintenance update jobs.
So why did we do this? Well, the main reason is we wanted to unify the Initial Product Installation process with the Maintenance Update process. The two processes now use the identically same Shipment Package. They differ only in the jobs that need to be run to perform the installation or update. The $README file completely guides both processes.
The benefits for Maintenance Updates have already been mentioned (safer and easier).
The benefits for Initial Product Installs are several:
- The process no longer involves SMP.
- The process no longer starts with the ancient 2016 level of z/XDC.
- The process no longer requires a Maintenance Update run to bring that toad up to current level.
Feedback: From experience, we have learned that few people have been able to use our older process right out of the box. They have had to make customizations that vary considerably from one customer to another. This update is our attempt to reduce that need as much as possible!
We now think we know how most of our customers apply our maintenance, and we've already heard from three of you about about this. Two of you essentially confirmed that we were on the right track, but another had a wrinkle in their methods that led us to make revisions that we hope he will find helpful.
So we'd welcome your feedback! Did we get it right? Is there something we can do better? Please let us know.
Thanks,
Dave Cole
This email address is being protected from spambots. You need JavaScript enabled to view it..
