CA IDMS

Expand all | Collapse all

AllowUserKeyCSA(NO) implementation

Jump to Best Answer
  • 1.  AllowUserKeyCSA(NO) implementation

    Posted 04-02-2019 02:42 PM

    How are folks implementing AllowUserKeyCSA(NO)? We tried APF Authorizing our entire IDMS LOADLIB but that causes certain batch programs like USNDRVR to abend with S0C4-04. Are folks simply moving RHDCOMVS, RHDCTCKR, and RHDCCKUR to a special APF authorized library or are they making a full copy of their LOADLIB and having one that is APF authorized? Either of thee makes me a bit uncomfortable since I will need to change a bunch of production JCL.

     

    Or maybe there is a way where only my CV's address space JCL needs changed?



  • 2.  Re: AllowUserKeyCSA(NO) implementation

    Posted 04-02-2019 02:52 PM

    Hello,

    Have you performed these setup instructions?  IDMS CV setup for ALLOWUSERKEYCSA(NO) clarificatio - CA Knowledge 



  • 3.  Re: AllowUserKeyCSA(NO) implementation

    Posted 04-02-2019 02:53 PM
      |   view attached

    Here is the official doc (at least the most recent that I have)

     

    Chris Hoelscher

    Technology Architect, Database Infrastructure Services

    Technology Solution Services

    Humana Inc.

    123 East Main Street

    Louisville, KY 40202

    Humana.com

    (502) 476-2538 or 407-7266



  • 4.  Re: AllowUserKeyCSA(NO) implementation

    Posted 04-02-2019 02:54 PM

    Hi Paul,

       This is documented in System Operations 

     

    https://docops.ca.com/ca-idms/19/en/administrating/administrating-ca-idms-system-operations/z-os-specific-features/storage-key-considerations-for-z-os-csa-subpools 

     

    Basically you need to run your IDMS CVs in primary Protect key 4. 

     

    Also a knowledge doc that has basically the same info: 

     

    https://comm.support.ca.com/kb/idms-cv-setup-for-allowuserkeycsa-no-clarification/kb000117597 

     

      Not sure what gets 0C4 or why.  Perhaps a case would make more sense.

     

    I have been running two CVs in Key(4) for quite a few years as our sysprogs went to AllowUserKeyCSA(NO) several years ago.  

    In our case we have RHDCOMVS defined in PPT to run in KEY(4) and the CAGJLOAD lib is APF authorized.

     

    Top of my startup JCL

     

    //PHILTEST EXEC PGM=RHDCOMVS,REGION=0M,
    //         PARM='S=1900,DMCL=DMCL1900,FREESTG=2048,WTO=P160WTOX,MT=Y,
    //                STEP=Y,ZIIP=Y'
    //STEPLIB DD DSN=MY.CAGJLOAD,DISP=SHR



  • 5.  Re: AllowUserKeyCSA(NO) implementation

    Posted 04-02-2019 02:54 PM

    We made a copy of the IDMS load library and authorized it. We followed each and every step as described in the link below and it worked perfectly. We did have to update the production CV JCL to ensure that only the authorized library was in STEPLIB (we had libraries in STEPLIB that didn't need to be there). 

     

    https://docops.ca.com/ca-idms/19/en/administrating/administrating-ca-idms-system-operations/z-os-specific-features/storage-key-considerations-for-z-os-csa-subpools



  • 6.  Re: AllowUserKeyCSA(NO) implementation

    Posted 04-02-2019 03:33 PM

    I followed the steps in the following doc (SFranzon's link) -> Storage Key Considerations for z/OS CSA Subpools - CA IDMS - 19.0 - CA Technologies Documentation 

     

    1. Instead of moving RHDCOMVS, RHDCTCKR, and RHDCCKUR to a separate LOADLIB, I APF Authorized the LOADLIB with all 2788 members in it.

    2. I authorized the LOADLIB

    3. I updated SYS1.PARMLIB(SCHEDxx) as directed.

     

    PPT PGMNAME(RHDCOMVS)
    KEY(4)
    NOSWAP

     

    4.See step 5

     

    5. I changed my startup JCL as follows:

     

    //RHDCOMVS EXEC PGM=RHDCOMVS,REGION=0M,TIME=180,
    // PARM='S=4,STEP=Y,DMCL=GLBLDMCL,WTO=WTOEXIT,SVC=253,FSTG=7000,ZIIP=Y'
    //STEPLIB DD DSN=IDMS.LOADLIB,DISP=SHR

     

     

    Now my CV4 runs ok but USNDRVR and other programs fail in batch with: 

    COMPLETION CODE      SYSTEM = 0C4      REASON CODE = 00000004

     

    The JCL is:

     

    //ANALYZER EXEC PGM=USNDRVR,REGION=5000K,TIME=600,COND=EVEN
    //STEPLIB DD DSN=IDMS.USERLIB,DISP=SHR
    // DD DSN=IDMS.LOADLIB,DISP=SHR

     

    Perhaps it is loading something from USERLIB that it shouldn't but USNDRVR is not in USERLIB.

     

    Paul



  • 7.  Re: AllowUserKeyCSA(NO) implementation

    Posted 04-02-2019 03:39 PM

    Not familiar with USNDRVR  but  if all of the loadlibs in the batch STEPLIB are APF,  perhaps USNDRVR is linked RENT/REUS and is trying to update itself.   Add a non-APF lib in the batch STEPLIB to see if that allows it to run.  Might need to see the 0C4 details such as PSW, regs and data at PSW



  • 8.  Re: AllowUserKeyCSA(NO) implementation

    Posted 04-02-2019 03:36 PM

    This is only a concern for CV JCL. You do not have to do this with batch JCL. We made made no changes to any batch JCL.



  • 9.  Re: AllowUserKeyCSA(NO) implementation

    Posted 04-04-2019 10:39 AM

    Thanks for the help. The doc on CA's site is a little unclear.

     

    Am I right to say that my CV startup JCL only needs 3 modules in it's STEPLIB (RHDCOMVS, RHDCTCKR, and RHDCCKUR) along with any aliases I may have defined for those modules such as IDMSDC? The remainder of IDMS loads from the CDMSLIB DD which will have a library in the concatenation that has all of the 2800 modules delivered by CA (including the 3 above).

     

    I was uncomfortable running my CV with just those 3 modules in my STEPLIB.

     

    SUCCESS!

    I have put those 3 modules in a special STEPLIB and APF authorized it. IDMS is running properly this way. I can also run IDMS utilities (including USNDRVR) and reports, etc using the loadlib with the 2800 modules in it - that is not APF authorized.

     

    BUT...

    Doing it this way prevents me from using zIIP because IDMS seems to want other modules loaded from an APF authorized library --> "IDMS DC016106 ZIIP=N forced. Module RHDCNTRY was loaded from an unauthorized library." I get this message for 150 different modules when I try to enable zIIP. 

     

    Paul



  • 10.  Re: AllowUserKeyCSA(NO) implementation
    Best Answer

    Posted 04-04-2019 10:54 AM

    Paul,

      Here is the doc for  zIIP exploitation

     

    zIIP Exploitation - CA IDMS - 19.0 - CA Technologies Documentation   

     

    specifically the eligibility section  zIIP Exploitation - CA IDMS - 19.0 - CA Technologies Documentation  

     

    Sounds like you removed APF authorization from the CAGJLOAD  which you now have only in CDMSLIB.

    The Eligibility doc explains which modules must be loaded from an APF loadlib.  These loadlibs are defined in CDMSLIB.  zIIP eligibilty does NOT require that all loadlibs in CDMSLIB be APF,  but it does require that the listed modules br loaded from an APF loadlib.

     

    What you have done with the single STEPLIB loadlib containing only those 3 modules is OK although not necessary as I know my CVs have run in Key(4) for years and I have no problems  with batch jobs as their STEPLIB contains multiple loadlibs and only CAGJLOAD is APF.



  • 11.  Re: AllowUserKeyCSA(NO) implementation

    Posted 04-04-2019 11:09 AM

    Thanks. That is what I needed. I'll figure out my problems with zIIP later.



  • 12.  Re: AllowUserKeyCSA(NO) implementation

    Posted 04-04-2019 10:58 AM

    Were you running with zIIP enabled before?

     

    You still need to following the rules for zIIP enablement -

    https://docops.ca.com/ca-idms/19/en/administrating/administrating-ca-idms-system-operations/z-os-specific-features/ziip-exploitation

     

    RHDCOMVS and nucleus modules need to be in an authorized library or in LPA. How did you achieve this before?



  • 13.  Re: AllowUserKeyCSA(NO) implementation

    Posted 04-04-2019 11:21 AM

    Something in my environment prevents me from having ALLOWUSERKEYCSA(NO) and zIIP at the same time.

     

    I never really had zIIP working. In my sandbox I can get zIIP to work when I APF authorize the STEPLIB with all 2800 members of CAGJLOAD in it. But then, for some reason, I can't run a some of the utilities (including ANALYZER - USNDRVR). I assume this is because I have some overlap between my CUSTOM loadlib (which is in the concatenation ahead of CAGJLOAD for batch) and the CAGJLOAD (or something else USNDRVR tries to run.) 

     

    I'm going to have to put in some effort to see why APF authorizing the full 2800-member CAGJLOAD causes my ANALYZER jobs to abend. I really don't like having to split those 3 modules out into a separate APF authorized lib.

     

    -Paul



  • 14.  Re: AllowUserKeyCSA(NO) implementation

    Posted 04-04-2019 11:28 AM

    Paul,

      As mentioned you can open a case and provide the 0C4 dump but I suspect when CAGJLOAD is APF and certain batch jobs abend 0C4 that the batch STEPLIB contains only loadlibs that are APF.  

      To run zIIP=Y the CAJLOAD in CDMSLIB must be APF, as well as loadlibs containing the other modules mentioned in the eligibility doc. 



  • 15.  Re: AllowUserKeyCSA(NO) implementation

    Posted 04-04-2019 11:39 AM

    When you run your analyzer job, do you have at least one non-authorized load library in STEPLIB? 

     

    We have CAJGLOAD authorized, but it is just the supplied CAJGLOAD (actually it's a copy of it, but it is identical in content). All our batch jobs also need our "DBA" load library, the one that contains the DMCL, DBTtable, SRTT etc and that library is not authorized. That means all batch runs without an authorized STEPLIB as not all libraries in it are authorized. 

     

    So only our CV's run with just the authorized CAJGLOAD in STEPLIB. 



  • 16.  Re: AllowUserKeyCSA(NO) implementation

    Posted 04-04-2019 03:49 PM

    I wonder if anyone is putting the 3 modules (RHDCOMVS) in the APFLIB that is used for the IDMSINFO processing. CA may have that APFLIB recommended only for the IDMSINFO, I don't know, but seems a logical place to put stuff that needs to be APF authorized since it is already there.

     

    -Paul