A couple of things - Since the OPSTART1 can be unique to your shop in determining how you want to initiate the start of OPS/MVS, you may want to keep it in a user unique PDS that is concatenated first within the //SYSPROC of your OPSMVS proc (SYSX.OPSMVS.USER.SYSPROC or whatever). This way you can avoid having to always copy 'your' version over the supplied as you perform maintenance.
You can then modify the logic in OPSTART1 after the OX 'parmlib....' statement that is checking the return code of the OX to set the OPSTART1RESVAL to some value that starts with 'SHUTDOWN'. This will cause OPS to not start in the event something went wrong with triggering the actual startup member. CA can/should make this change to the supplied sample as it would avoid starting of OPS in this 'default' parm mode. After the OX '......' statement, replace the check on &PARMCC to:
IF &PARMCC ¬= 0 THEN +
OPSPARM SET(OPSTART1RESVAL) VALUE(SHUTDOWNNOPARM)
Original Message:
Sent: 12-04-2019 03:17 PM
From: Alan Schwartz
Subject: Prevent OPS from continuing to initialize when the parmlib member is not found
I upgraded one LPAR to CA OPS/MVS 13.5 a few weekends ago.
The step where one copies OPSTART1 from the old release to the new release had a problem so OPSTART1 was not updated. When I restarted OPSMAIN the message was received:
OPS0040I OPS0902E Cannot find program OPSSPA00 in SYS1.PARMLIB
Yet CA OPS?MVS continued to initialize.
I wasn't aware there was a problem until I went to check the STCTBL and the one we use most was missing. It took a while to find the problem which then has a quick fix.
Why didn't CA OPS/MVS fail with a jcl error or something?
My idea for an Enhancement Request is for CA OPS/MVS to exit the initialization with an appropriate error message when this occurs.