Siemens distributes several types of upgrades to
Invision and the implications of applying
these can vary, depending on the particular upgrade.
Download from a single tape:
//SISTDAPL JOB 1,RLS,MSGLEVEL=(1,1),MSGCLASS=H
//SINGLE EXEC SISTDAPL,VOLSER=Xnnnnn
Download from multiple tapes:
//SISTDAPL JOB 1,RLS,MSGLEVEL=(1,1),MSGCLASS=H
//MANY EXEC SISTDAPL,VOLSER=Xnnnnn,OVOL='Xnnnnn,Xnnnnn'
Xnnnnn = volser of tape(s) - always start with 'X'
This job creates (for example):
Documentation of the updates - print for analysts.
JCL to apply the updates.
We make copies of the appropriate members of this library and modify the copies, never touching the original members.
PRODDBHL - copy Prod updates from tape to disk
TESTDBHL - copy Test updates from tape to disk
CPY2PROD - apply updates to Prod
CPY2TEST - apply updates to Test
SIXSC$$$ - compare new Prod data to old
SIYSC$$$ - compare new Test data to old
(copy as PRODDOWN/TESTDOWN/PCOPY074/TCOPY074 for example)
As delivered, these jobs refer to filenames PLSMS.PLSMS.**, PDSMS.PDSMS.**, TLSMS.TLSMS.** and TDSMS.TDSMS.**. Rarely, there is also a PLSMS.PLSYS.**
We change the 2nd qualifier to something unique and indicative of the particular update. This allows us to have multiple updates downloaded and being worked on concurrently. For example, we might have:
PLSMS.SUT03K.** - November 2003 updates
PLSMS.SUT034.** - 4th Quarter 2003 updates
PLSMS.SUTREG2.** - updates for 2003
PLSMS.MCOLE2.** - TIF Special for Marge Cole
PLSMS.PLSMS.** - HHE or DS updates
Also remove VOL=REF statements in any JCL
NOTE: Watch for datasets PLSYS.** which are sometimes delivered. Changing all PLSMS.PLSMS. to PLSMS.xxxxxxxx. would miss these files.
In the case of the rare HHE and DS updates, we never have more than one of these in-progress at any given time. We leave the dataset names as delivered (PLSMS.PLSMS.**, etc.) because while all other updates are done by manually running jobs, the DS/HHE updates are major re-engineering of the system and are driven by a special 'job controller' (similar to the Dayend Job Controller). This mechanism and the CLISTs which support it all expect 'PLSMS.PLSMS.**'. While we could repackage the updating procedure, it's more trouble than it's worth and runs a significant risk of error, so we run it as delivered.
We usually run the SIXSC$$$/SIYSC$$$ which compare the newly-delivered data against the current data. This is useful tool, but differences must still be eyeballed and handled on an item-by-item basis.
We often have cases in which we have modified the data delivered by Siemens. This is most common in the SYSJOBS and PROC libraries, but sometimes occurs in the VDEF and various SYSIN libraries. When the files have been downloaded from tape by running PRODDBHL/TESTDBHL, we will see which libraries are being changed.
We browse these new libraries to see which members have been changed. At the same time, we browse the existing libraries. If our current member has never been altered, we will accept the new version without looking deeper. However, if Siemens is delivering a new copy of something we have altered, we compare the new version to the current version to see what the differences are.
In the PROC and SYSJOBS libraries, the most common changes are for us to set REGION=0K in the JOBcard or to increase SPACE allocations. We also remove any VOL=REF when allocating to DASD.
Any changes to VDEF are resolved by common sense. Reconciling differences in the SYSIN libraries must sometimes be done in concert with the Analysts.
Changes are made to the new libraries so that the Apply process will replace the current version.
For example: Newly-delivered PAP19A7$ would be modified to include our changes as appropriate.
In addition to the PLSMS.** libraries, we run the following from PMHH.JCL:
TRNSERVV (clone of PCDCSA7V)
VBHCDM1 (clone of FDXY4A7V)
VBHCDM3 (clone of PAX94A7V)
VBHSERV1 (clone of OOXSVDGV)
VBHSERV2 (clone of PCD07A7V)
If one of these is redelivered, we may need to change our clones.
We have also copied CHPPRT01 from xLSMS.SMOSM00L.P0000.LOAD to xLSMS.SMSCUSTL.P0000.LOAD
and zapped this module per Siemens ticket 4858932. Future deliveries of CHPPRT01 to
xLSMS.SMOSM00L.P0000.LOAD must be reconciled.
Loadlib changes for A2KTEST go directly into TLSMS.xxxxxxxx.P0000.LOAD but for A2K, there are 'semi-temp' libs PLSMS.xxxxxxxx.E0000.LOAD. These libs are concatenated ahead of the P0000 libs and updates are put into the E0000 libs by the Apply process. Before doing an Apply to A2K, we copy the E0000 libs to the P0000 libs and empty the E0000 libgs. To back out a SUT from A2K, you just have to empty the E0000 libs. (You may have to to other changes, associated with updates to the PDSMS datsets - always contact Siemens first).
Updates go to PLSMS.SMOSM00L.E0000.LOAD
Copy PLSMS.SMOSM00L.E0000.LOAD to PLSMS.SMOSM00L.P0000.LOAD
Empty PLSMS.SMOSM00L.E0000.LOAD (delete/reallocated?)
Do Apply, which copies to PLSMS.SMOSM00L.E0000.LOAD
Monthly SUTs - 03.A = January 2003, 03.J = October 2003, etc.
These generally affect Dayend and/or Demand jobs and do not require an outage, although there are exceptions and each SUT must be closely examined. Verification consists of monitoring the Dayend jobstream. These generally do not have any Apply instructions, but sometimes they require special procedures.
Quarterly SUTs - 03.1 = 1st quarter 2003, 03.3 = 3rd quarter 2003, etc
These almost always involve changes to the online system and hence require an outage, usually less than one hour, after which the updated system must be 'verified' by analysts before being given back to the users. This verifcation may take 30 minutes to an hour. These updates always have a SAP (Apply instructions) specific to that update.
Regulatory SUTs - 03.REG1, 03.OREG1, 03.REG2, etc
These usually involve changes to online code and require an outage, but once in a while we get lucky. Verification generally consists of monitoring the Dayend jobstream, but sometimes Analysts have to perform certain tasks or make changes to the way we use Invision. Some have special Apply instructions.
Miscellaneous updates - Various labels, no standard naming convention.
These may or may not involve an outage, depending on what is being updated. Verification procedures depend on the update. Some have special Apply instructions.
DS or HHE upgrades - Labelled 'DS 25', 'HHE 25', etc.
These always require a significant outage and significant verification as well as monitoring the Dayend jobstream. Always has a SAP.
Before applying a major SUT, we make backups of the current libraries being updated by the SUT. This is for recovery purposes if the SUT has to be backed off.