Description
The OPMO control block has been expanded in CA OPS/MVS release 12.3 to include new reporting fields.
Symptoms
If you try to start the OPSMAIN r12.3 Address Space, with OPSLOGs DIV datasets that were created and initialized by any previous supported releases (r12.1 and r12.2), and they used the minimum space required for BROWSEMAX 800000 (per CCLXCNTL member DEFDIV); the task will encounter problems to dynamically allocate them. The following messages will be posted during product startup:
OPS0164I Allocating OPSLOG data set your.OPSLOG (OPLG0001)
OPS9999T BrowseMax used: 800000
IEC070I 203-203,OPSMAIN,OPSMAIN,OPLG0001,2002,volser,
IEC070I your.OPSLOG,
IEC070I your.OPSLOG.DATA,ICF.your.user.catalog
OPS0160W BROWSEMAX value 800000 too large
*OPS0151S DIV MAP of OPSLOG data set failed, RC=X'08', reason code=X'0802'
*OPS0150S Initialization of OPSLOG failed, RC=4
OPS9998I OPSLOG initialization failed OPLG0001 OPSLOG your.OPSLOG
OPS9998I INOPBX 4 No OPSLOG ALET - shutdown
OPS9999T Address Offset +0 . . . +4 . . . +8 . . . +C . . .
OPS9999T 0B207000 00000000 C2D6C4C6 00000080 00800001 00000000 *BODF........... .*
OPS9999T 0B207010 00000010 00000000 00000000 0B207080 00000000 *................*
OPS9999T 0B207020 00000020 00000001 D6D7E2D3 D6C74040 40404040 *....OPSLOGP*
OPS9999T 0B207030 00000030 40404040 D6D7D3C7 F0F0F0F1 C3C1D6D7 * OPLG0001CAO0*
OPS9999T 0B207040 00000040 E2D4E5E2 4BD9F1F2 F24BD4D6 D3C3C5F0 *SMVS.R122.MOLCE0*
OPS9999T 0B207050 00000050 F14BE7C5 F3F84BD6 D7E2D3D6 C7404040 *1.XE38.OPSLOG
OPS9999T 0B207060 00000060 40404040 40404040 000C3500 00000000 * ....... *
OPS9999T 0B207070 00000070 0800A000 00000000 00000000 00000000 *................*
OPS9999T 0B207080 00000080 C2D6C4C6 00000080 00800002 00000000 *BODF........... .*
OPS9999T 0B207090 00000090 00000000 00000000 0B207100 00000000 *................*
OPS9999T 0B2070A0 000000A0 00000000 00000000 00000000 00000000 *................*
OPS9999T ******** Same as last line ********
OPS9999T 0B2070F0 000000F0 00000000 00000000 00000000 00000000 *................*
After 5 minutes, a timeout condition will be driven by the OPSLOG subtask.
*OPS0161S Main task timed out while waiting to be posted by the OPSLOG subtask
OPS5006O TSOP subtask terminating
OPS5006O TSOL subtask terminating
OPS0093I Waiting for server termination to complete
OPS5006O TSOX subtask terminating
OPS5006O AOFX subtask terminating
OPS5006O OPSLOG subtask terminating
*OPS0127S Main task timed out while waiting to be posted by the AutoMate subtask
OPS5006O SHFI subtask terminating
OPS5006O GLVA subtask terminating
OPS5006O MRSV subtask terminating
OPSD5006O MRSV subtask terminating
OPS5006O MREX subtask terminating
OPS0210H MRT TERMINATED
*OPS0077S Main task timed out while waiting to be posted by the EPI initializati
IEA631I OPERATOR OXE38D00 NOW INACTIVE, SYSTEM=XE38 , LU=OXE38D00
IEA631I OPERATOR EXE38D01 NOW INACTIVE, SYSTEM=XE38 , LU=EXE38D01
IEA631I OPERATOR EXE38D02 NOW INACTIVE, SYSTEM=XE38 , LU=EXE38D02
IEA631I OPERATOR EXE38D03 NOW INACTIVE, SYSTEM=XE38 , LU=EXE38D03
OPS0018W storage not released - ECSA X'000040C8' bytes
OPS0017I OPS/MVS-JES2 subsystem OPSD termination complete
A SA03 ABEND followed by two S0C4s exceptions will follow and as a result the OPSMAIN task will stop:
IEA995I SYMPTOM DUMP OUTPUT 969
SYSTEM COMPLETION CODE=A03
TIME=11.16.24 SEQ=00261 CPU=0000 ASID=002E
PSW AT TIME OF ERROR 070C2000 853018D0 ILC 2 INTC 0D
NO ACTIVE MODULE FOUND
NAME=UNKNOWN
DATA AT PSW 053018CA - 58108010 0A0D58E0 02FC58D0
GR 0: 00000000_7F4A1808 1: 00000000_80A03000
2: 00000003_00FC6680 3: 00000000_7F4A2000
4: 00000000_007FF110 5: 00000048_7F4A16A8
6: 00000000_007FF110 7: 00000000_007F00C0
8: 00000000_05302B00 9: 00000048_007F00C0
A: 00000000_007FF088 B: 00000000_007CDE88
C: 00000000_007F00C0 D: 00000000_007F012C
E: 00000000_852F9FDE F: 00000000_85301858
END OF SYMPTOM DUMP
IEA995I SYMPTOM DUMP OUTPUT 971
SYSTEM COMPLETION CODE=0C4 REASON CODE=00000011
TIME=11.16.24 SEQ=00263 CPU=0000 ASID=002E
PSW AT TIME OF ERROR 078C0000 8B150840 ILC 4 INTC 11
ACTIVE LOAD MODULE ADDRESS=0B150710 OFFSET=00000130
NAME=OPESRU
DATA AT PSW 0B15083A - 185158A0 504C5890 A410A7F4
GR 0: 00000006 1: 11986F00
2: 11986F06 3: 00000000
4: 00000000 5: 11986F00
6: 00000000 7: 11986F06
8: 0AF03768 9: 00000000
A: 0A609000 B: 00000000
C: 8B150710 D: 0AF03F70
E: 00FDBE50 F: 0020DDDD
END OF SYMPTOM DUMP
IEA995I SYMPTOM DUMP OUTPUT 973
SYSTEM COMPLETION CODE=0C4 REASON CODE=00000011
TIME=11.16.24 SEQ=00265 CPU=0000 ASID=002E
PSW AT TIME OF ERROR 078C0000 8B150840 ILC 4 INTC 11
ACTIVE LOAD MODULE ADDRESS=0B150710 OFFSET=00000130
NAME=OPESRU
DATA AT PSW 0B15083A - 185158A0 504C5890 A410A7F4
GR 0: 00000006 1: 0EDDAF00
2: 0EDDAF06 3: 00000000
4: 00000000 5: 0EDDAF00
6: 00000000 7: 0EDDAF06
8: 0AF03768 9: 00000000
A: 0A609000 B: 00000000
C: 8B150710 D: 0AF03F70
E: 00FDBE50 F: 0020DDDD
END OF SYMPTOM DUMP
IEF450I OPSC3MN OPSC3MN - ABEND=SA03 U0000 REASON=00000000 974
If you try to use the same OPSLOG datasets with you prior supported versions, the OPSMAIN task will be able to start and use them without problems.
To resolve the ABENDs, you need to reallocate the OPSLOG DIV dataset with at least 790 cylinders as documented in the product manuals for 3390 devices when BROWSEMAX 800000 is used.
The only side effect is that any existing data will be lost (destroyed) and the following message is posted at startup time:
*OPS0154S Any existing OPSLOG Browse data discarded
The message will appear for all the supported releases 12.1, 12.2 and 12.3.
Information
The underlying problem, whereby a properly sized for release 12.3 primary and secondary OPSLOG DIV dataset that has been initialized by a prior release of CA OPS/MVS and the data is destroyed at startup time, can only be circumvented by applying the corrective PTFs available for our supported releases of CA OPS/MVS.
The corrective fixes are as follows:
Product Release Apar #
OPSMVS 12.1 RO80975
OPSMVS 12.2 RO80976
OPSMVS 12.3 RO81045
This is an excerpt of the problem description, symptoms and impact documented on the PTFs:
PROBLEM DESCRIPTION:
The OPMO has been expanded in OPS/MVS 12.3. This fix will prevent the data in incompatible OPSLOGs from being destroyed.
SYMPTOMS:
Starting a 12.3 OPS/MVS using an OPSLOG dataset created in a previous version of OPS/MVS (12.2 and before) will destroy the OPSLOG. Starting an OPS/MVS release older than 12.3 using a 12.3 OPSLOG dataset will destroy the OPSLOG.
IMPACT:
OPSLOG data is lost.
Once these PTFs for all the supported releases are installed and OPSMAIN is started at release 12.3, you still are not going to be able to sue the old OPSLOG. Product will switch automatically to in-storage OPSLOG recording as reported
Release 12.1
OPS0164I Allocating OPSLOG data set your.OPSLOG (OPLG0001)
OPS9999T BOSTTST BOST FIELDS 12.01.00 X'00000180'
*OPS4627S OPSLOG data set failed to activate and will continue as an in-storage replacement.
Release 12.2
OPS0164I Allocating OPSLOG data set your.OPSLOG (OPLG0001)
OPS9999T BOSTTST BOST FIELDS 12.02.00 X'00000180'
*OPS4627S OPSLOG data set failed to activate and will continue as an in-storage
The recommended approach, before an upgrade to release 12.3, is to allocate brand new OPSLOG DIV datasets large enough to cover the minimum requirements documented in the release 12.3 product guides. Please review the CA OPS/MVS release 12.3 Installation Manual on section “Installing”, item “DASD Calculation Chart” under “DASD Requirements for OPSLOG Messages”.
Let’s assume you are using a device type 3390 where you have allocated 2 OPSLOG datasets with 568 cylinders each to accommodate a BROWSEMAX value setting of 800000 (within the OPSLOG DEFINE statements specified in OPSSPA00). Under CA OPS/MVS release 12.3, if you are going to continue using the same device type and BROWSEMAX value, you need to allocate each new OPSLOG dataset with an increased size of 790 cylinders.
When looking at the "DASD Requirements for OPSLOG Messages” chart be advised that the column "# OPSLOG Messages" indicates the number of OPSLOG events you can specify as a value for the BROWSEMAX parameter.
Recommendation
Apply all the corrective fixes where applicable to avoid losing OPSLOG browse data on properly sized OPSLOG DIV datasets. When upgrading to release 12.3, it is highly recommend that you allocate new ones large enough to cover the minimum requirements documented in the installation manual. Make sure you align the OPSLOG datasets size and the BROWSEMAX value to the new release 12.3 requirements.
Considerations
If you do not align the OPSLOG datasets size and BROWSEMAX values to release 12.3 requirements and regardless if you apply or not the corrective fixes, then you will get the ABENDs and the task will fail to startup. Properly sized OPSLOGs from prior releases are still not going to be used by the new release, By applying the corrective PTFs you will prevent losing OPSLOG browse data.
For any unsupported releases (release 12.0 or before), make sure you follow our recommendations to use brand new OPSLOG DIV datasets properly sized. There is no corrective fixes to avoid losing OPSLOG browse data under release 12.0 when properly sized OPSLOG DIV files are used.
Be aware also that attempts to browse a OPSLOG DIV dataset via OPSVIEW option 7.1.1 will produce the following message in your TSO/ISPRF online session:
Unable to display OPSLOG - data is incompatible with the current version of OPS/MVS.
You could also see the following message in the SYSLOG and it depends on how the browse attempt is made:
*OPS0154S Unable to display OPSLOG - data is
* incompatible with the current version of OPS/MVS.
Final and very important note
In case you need to fall back from release 12.3 to any of our previous supported and unsupported releases of CA OPS/MVS, make sure you use the original (older) set of primary and secondary OPSLOG DIV datasets.