CA OPS/MVS: OPSLOG DIV VSAM datasets considerations while migrating to release r12.3, 13.0 or 13.5
Article ID: 31010
Updated On:
Products
Issue/Introduction
The OPMO control block used for many message queues has been expanded almost double in size (from 384 to 640 bytes) in release 12.3 to include new reporting fields. As a result of this expansion, more storage is required to run the OPSMAIN task compared to prior releases.
Symptoms:
If you try to start the OPSMAIN r12.3, 13.0 or 13.5 Address Space, with OPSLOGs DIV VSAM datasets that were created and initialized by any previous supported releases (r12.1 or r12.2), and they were allocated using 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.PMFKEY*
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=XXXX , LU=OXE38D00
IEA631I OPERATOR EXE38D01 NOW INACTIVE, SYSTEM=XXXX , LU=EXE38D01
IEA631I OPERATOR EXE38D02 NOW INACTIVE, SYSTEM=XXXX , LU=EXE38D02
IEA631I OPERATOR EXE38D03 NOW INACTIVE, SYSTEM=XXXX , 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
Environment
Component:
Cause
Resolution
If migrating from a CA OPS/MVS release 12.2 or older to release 12.3 or newer make sure:
1) You allocate a new, empty, OPSLOG dataset with the space requirements from the "DASD Requirements for OPSLOG Messages" section of the CA OPS/MVS 13.5 documentation
2) The data from the previous release can not be copied to the new OPSLOG. The OPSLOG must be empty.
Dasd requirements:
Additional Information
The underlying problem, whereby a properly sized for release r12.3 OPSLOG DIV VSAM datasets that have been initialized by a prior release of CA OPS/MVS and the data is destroyed at startup time, can only be circumvented by applying corrective PTFs available for all of our supported releases of CA OPS/MVS.
The corrective fixes are:
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 supported releases are installed and deployed OPSMAIN will be able to start at release r12.3. You still are not going to be able to use the old data stored in the OPSLOG. Product will switch automatically to in-storage 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 r12.3, is to allocate brand new OPSLOG DIV VSAM datasets large enough to cover the minimum requirements documented in the release r12.3 product guides. Please review the CA OPS/MVS release r12.3 Online Documentation here and visit 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 DIV VSAM 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 r12.3, if you are going to continue using the same device type and BROWSEMAX value, you need to allocate each new 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.
Apply all the corrective fixes where applicable to avoid losing OPSLOG browse data on properly sized OPSLOG DIV VSAM datasets. When upgrading to release r12.3, it is highly recommended that you allocate a new set large enough to cover the minimum requirements documented in the online documentation. Make sure you align the OPSLOG DIV VSAM datasets size and the BROWSEMAX value to the new release r12.3 requirements.
Considerations:
If you do not align the OPSLOG DIV VSAM datasets size and BROWSEMAX values to release r12.3 or higher requirements regardless if you apply or not the corrective fixes, 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 r12.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 for releases r12.0 and prior even when properly sized OPSLOG DIV VSAM datasets are used.
Be aware that attempts to browse a OPSLOG DIV VSAM dataset via OPSVIEW option 7.1.1 will produce the following message in your TSO/ISPF 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 r12.3 or higher 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 VSAM datasets.
Feedback
