Unable to apply License keys and start CAS9.
search cancel

Unable to apply License keys and start CAS9.

book

Article ID: 113631

calendar_today

Updated On:

Products

Compress Data Compression for MVS Compress Data Compression for Fujitsu OPS/MVS Event Management & Automation

Issue/Introduction

I would like to update the license keys on our systems. 
But I am facing an issue in one system while trying to apply the keys.
I have updated the KEYS member with the new license and when I issue the command: 

S CAS9,,,LMPKEYS

I can see these messages in my joblog: 
OPS1370H SYS1146 X'0000' X'0000' X'0000' SYS1146 300 OPSNOTIFY Start 
request of SSM managed resource CAS9 processed. 
OPSNOTIFY Start request of SSM managed resource CAS9 processed. 
OPS7902H STATEMAN ACTION FOR STCTBL.CAS9: UNKNOWN RULE=SSMSTATE 
TABLE(STCTBL) NAME(CAS9) TYPE(HOOKSTC) JOBNAME(CAS9) DESIRED( 
OPS7902H STATEMAN ACTION FOR STCTBL.CAS9: DOWN_UP EVRULE=SSMRETRY STCTBL 
CAS9,2,300,START UP 
OPS4320H OPSMAIN OPSS *LOCAL* AOF verb ENABLE command ENABLE 
*DYNAMIC.#SR00012 
OPS1000I SSMRETRY: OPS3900O RULE *DYNAMIC.#SR00012 FOR TOD 2018/09/11 
06:20:29 NOW ENABLED 
IEF196I OPS1000I SSMRETRY: OPS3900O RULE *DYNAMIC.#SR00012 FOR TOD 
IEF196I 2018/09/11 06:20:29 NOW ENABLED 
OPS7902H STATEMAN ACTION FOR STCTBL.CAS9: DOWN_UP EVRULE=SSMHOOK DOWN 
CAS9 STCTBL 
 

Why do I have these error messages when I update my license keys and start CAS9? 

Environment

CA Common Services 14.1 - OPS/MVS 12.1 - 12.2 - 12.3 - z/OS supported releases - 

Resolution

There are two solutions to resolve this problem: 

1. Apply PTF RO83805 for OPS/MVS 12.3 
          or PTF RO83804 for OPS/MVS 12.2 
          or PTF  RO83761 for OPS/MVS 12.1
OR 

2. A workaround is to remove the probe check in SSMSTAUX and SSMHOOK for CAS9. 

Here is the explanation: 
The probe check in SSMSTAUX and SSMHOOK for CAS9 needs to be removed or commented out. 
You can also change the jobname to something like CXX9 so that the logic for CAS9 does not get performed. 
This old probe code was good for interrogating storage set by CAS9 (indicates that CAS9 ‘did its thing’) 
but with the introduction of the CAMASTER component (for plex vars) now in newer release of CA Common Services, this code is now being ‘shared’ by CAMASTER. Since CAMASTER comes out of NIP IPL, the probe code
s incorrectly seeing storage set by CAMASTER and not CAS9 , thus CS incorrectly set. 

The quick fix is to change jobname in SSMSTAUX/SSMHOOK. You see ‘if res_name = ‘CAS9’ in SSMSTAUX, 
and …’WHEN JOBNAME = ‘CAS9’ in SSMHOOK…simply change to ‘CXX9’.