CA OPS/MVS

Expand all | Collapse all

Tech Tip: OPSLOG considerations while migrating to CA OPS/MVS R12.3

  • 1.  Tech Tip: OPSLOG considerations while migrating to CA OPS/MVS R12.3

    Posted 07-20-2015 01:49 PM

     

    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.



  • 2.  Re: Tech Tip: OPSLOG considerations while migrating to CA OPS/MVS R12.3

    Posted 08-20-2015 03:50 AM

    Cesar, you are referring to "Please review the CA OPS/MVS release 12.3 Installation Manual on section “Installing”, item “DASD Calculation Chart” under “DASD Requirements for OPSLOG Messages”"

     

    Unfortunately that doc cannot be located anywehre in CA-support. How can we achieve a copy of that, prior to install of 12.3 ?


    Then a second question: how are the old pre 12.3 OPSLOG archives affected by this? Can they still be restored in a 12.3 DIV? We must be certain that old archives will still be accessible after this upgrade.


    Thanks,


    Marcel van Ek

    Atos



  • 3.  Re: Tech Tip: OPSLOG considerations while migrating to CA OPS/MVS R12.3

    Posted 08-20-2015 09:30 AM

    Hello Marcel,

     

    The CA OPS/MVS release 12.3 INC00 Installing manual section is located only in our Wiki page at wiki.ca.com.

    Feel free to visit this web site and look for it.

     

    OPSLOG Archives that were created using prior releases can still be restored using the new release 12.3 software.

    Just make sure you allocate a OPSLOG DIV VSAM file large enough to accommodate the archive data on it based on the new documented space requirements.

    Also, if you are planning to run two concurrent releases be aware that data restored using release 12.3 can only be browsed using the new release.

     

    I was already planning create a separate Tech Tip to inform to the rest of the community about your second question. I am glad you asked on this one.

     

    Regards, Cesar



  • 4.  Re: Tech Tip: OPSLOG considerations while migrating to CA OPS/MVS R12.3

    Posted 08-20-2015 10:25 AM

    So as we go to 12.3  to avoid any errors is to create new opslog DIV datasets before (under 12.2) with the proper allocations.

    Then in parmlib member (OPSSPA00)  the allocate at startup, point to the new OPSLOG Div datasets? 

    ADDRESS OPSCTL                                            

    "OPSLOG DEFINE(OPSLOGM) DSNAME("NEW_PRIMARY_12_3_OPSLOG_DSN")",    

               "BROWSEMAX("PRIMARY_OPSLOG_BROWSEMAX")"       



  • 5.  Re: Tech Tip: OPSLOG considerations while migrating to CA OPS/MVS R12.3

    Posted 08-20-2015 11:14 AM

    Hello Randy,

     

    Your understanding is correct.

    If you are planning to use the installation provided CCLXCNTL(DEFDIV) REXX EXEC simply adjust up the space so the allocation is large enough to support your browsemax setting in your OPSSPA00 init deck.

    Upon first OPSMAIN Address Space startup we will initialize the newly created OPSLOG DIV file and will write out to it a BOST record with the browsemax value you choose.

    The first OPSLOG DIV dataset that you activate, using the following line of code in OPSSPA00, will be become your primary OPSLOG DIV file in your system: 

     

    address Opsctl          

    "OPSLOG Activate(OPSLOG)"

     

    Hope this clarifies this further Randy.

    Feel free to ask other questions related to this subject in this post.

     

    Regards, Cesar