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 ...
Chris Bronson
Miami-Dade County