CA OPS/MVS: OPSLOG DIV VSAM datasets considerations while migrating to release r12.3 - Best Practice

Document ID : KB000031010
Last Modified Date : 14/02/2018
Show Technical Document Details

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 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.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 OPSLOGs DIV VSAM 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 them 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 r12.1, r12.2 and r12.3.

Instructions:

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 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.

If you have a need to access OPSLOG data located only in a OPSLOG DIV VSAM dataset for any release other than r12.3 then proceed to prepare and use a TSO PROC that only allocated the product datasets for that particular old release. Next visit OPSVIEW option 7.1.1 and then you should be able to access the old OPSLOG DIV VSAM file even if the OPSMAIN task is down. Use the instructions documented in the KD TEC463021 so you can copy the information you are looking for into a z/OS dataset for further review if needed

Final and very important note:

In case you need to fall back from release r12.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 VSAM datasets.