Where I work we switch SVCs when we upgrade IDMS. We have two SVCs reserved for IDMS, and when we upgrade we change the SVC number for the upgraded systems. I suspect this goes back to a time when the IDMS SVCs were not backwards compatible, or maybe there are other reasons that have been forgotten as people have left the company.
How do you do the SVC maintenance? There are in my opinion several ways to do it.1. One SVC per environment, when the environment is upgraded, so is the SVC2. One SVC per CV, it is upgraded when the CV is upgraded3. Only one SVC for all IDMS regions, upgrade it when the new release comes in
4. Have two SVCs switch the SVCs between releases
5. Maybe you have another process
Will you be willing to share what you do, as well as sharing the experiences, good and bad?We may be changing how we do it here and would like to get some input from those who are doing it differently or the same way.
I can't tell you what other clients do but the best recommendation is to have all IDMS CVs in a given LPAR use the same SVC and that SVC should always be from the most recent release of IDMS. The IDMS SVC is always compatible with all previous releases of IDMS so the simplest practice is to have all CVs on the LPAR use the same SVC and that SVC is always upgraded to the latest release you are running.
If there are multiple releases of IDMS using a given SVC the CAIRIM job that installs or refreshes that SVC needs to have statements that will "register" the SVC for multiple releases.
For example we will say that you have three CVs in the LPAR all specifying SVC 176 in Sysgen and in the SRTT. This SVC (IGC176) is the 18.5 SVC and the library used by CAIRIM contains only the modules from the 18.5 APFLIB created during configuration. CV-A runs 18.5 software, CV-B runs 18.0 and CV-C runs 17.0.
The CAIRIM Parmlib input must have one statement that installs the SVC as 18.5 and two statements to "register" the SVC for 18.0 and 17.0 use.
PRODUCT(CA IDMS) VERSION(GJI5) INIT(GJI5INIT) PARM(SVC=176)
PRODUCT(CA IDMS) VERSION(GJI0) INIT(GJI5INIT) PARM(REFRESH(SVC=176)) PRODUCT(CA IDMS) VERSION(GJH0) INIT(GJI5INIT) PARM(REFRESH(SVC=176))
The VERSION parameter updates a table to indicate the versions (releases) of IDMS that can use this SVC. The first statement loads the SVC and all other related modules from the APFLIB and the other two statement simply update the table to indicate that versions 18.0 and 17.0 can validly use this SVC.
Thank you Brian.
As Brian suggested – I use one SVC per LPAR, except that I havce a sandbox CV on the same LPAR as our test/QA CVs – and I have a separate SVC for that CV
When I new release comes in – and I have everything downloaded – o roll the SVCs in to sandbox/test/prod far in advance of the actual release – (months?) – just to eliminate one point of failure – has always worked for me
Technology Architect | Database Infrastructure Services
Technology Solution Services
123 East Main Street |Louisville, KY 40202
(502) 476-2538 – office
(502) 714-8615 - blackberry
Keeping CAS and Metavance safe for all HUMANAty
I have read Brian's reply and will need to reevaluate how we to it, but we have two svc's assigned to IDMS for each lpar. One svc (175) for our test cv's and one svc (176) for our production cv's. If I need to rerun the rim job to apply maintenance I can test it before the changes are introduced to prod. During our upgrade phase we have 4 svc's, ie a test & prod for each release R170 (173,174) & R180 (175, 176). Overkill?
I think two SVCs per lpar is the way to go, that way you can stage things in without affecting running systems.
Previously the two svc method was used here, the applications here also code the IDMS SVC. So multiple SVC changes.
When it was suggested upgrading the SVC to a higher version while retaining the same number as an early code process, folks replied “We can do that?”
This R18.5 upgrade was completed in 3.5 months, with not one back out/application change. This does include three scheduled “upgrades and back outs” with QA regions.
I was told the R16/R17 upgrades each took > 1 yr, due to SVC coordination.
So credit for the reduced duration belongs to CA’s Brian Brendlinger, whom direct me to single SVC method.
I use two SVC's per LPAR as well, one is the lastest release and the other is one release back.
We, too, have 2 SVCs per LPAR. One SVC is the "current" release and the other is one release back.
The second CV is only used if a back out is necessary when moving to a new release. Once the CVs in the LPAR are all running on the "current" SVC, the second SVC sits idle until we start the process of rolling a new release.
Thank you all for responding.I must say, I am surprised at how many people do it the same way as we do, i.e. an SVC per release.
We have decided to go with Brian's recommendation, which has backing by Chris H, and possibly roll the updated SVC in as suggested by Chris, well in advance of upgrading.
We traditionally have gone with the SVC per release approach. We experimented with the single SVC approach when installing V18 but eventually decided to keep the SVC per release.
What bothered us is that the CAIRIM IDMS initialization program loads several companion programs along with the SVC. In V18 these modules are RHDCSSFM, IDMSMSVA and CAIXDOA$.
While you can have multiple SVCs per LPAR, you can only have one set of companion modules per LPAR.
Our current approach is driven by our environment. We have 9 production CVs running on 3 production LPARs.
We have 7 development CVs and 2 DBA CVs running on a single development LPAR.
Development and production LPARs share a JES spool and within certain constraints local mode batch can run on any LPAR.
We install new releases by environment; first DBA, next development, and finally production.
CAS9 on the production LPARs has 2 IDMS initialization steps: production release followed by development release.
For the duration of a mixed release environment, production CVs and production local mode running on the production LPARs will use the production SVC and production companion modules.
Development local mode running on the production LPARs will use the development SVC and the production companion modules.
We did not want, and would not be allowed, to expose production work to new release modules in advance of the scheduled upgrade of the production environment to the new release.
CAS9 on the development LPAR has 3 IDMS initialization steps: DBA release followed by development release followed by production release.
Sharing an LPAR between DBA and development forced us to compromise on exposing development CVs and local mode to the new release companion modules when the DBA environment is upgraded to a new release.
If it should happen (never has) that production local mode running on the development LPAR is adversely affected by the new release companions, we would modify the initiator setup to keep production batch off development until the problem was resolved.
The SVC used by local mode is determined by the SVC number specified in RHDCSRTT in the release library it is running on, while the companion modules used are determined by the LPAR the job is running on.
Running in a mixed SVC/companion module environment is not pretty but we live with it for the duration.
It was tempting to just bring in the new release SVC and companions on day 1 on all LPARs and save a lot of bother but in the end it was old dogs, new tricks.
Perhaps the neatest approach would be to roll in the new release SVC/companions LPAR by LPAR until all are upgraded, then roll in the new release environment by environment: DBA, development and production.
Maybe in 18.5 ...