Contractual agreements for different products may require multiple site ids.  However, CAS9 will fail if multiple SITE ID cards are coded in a single KEYS member.

• Only one siteid/sitecode per KEYS member
• Each SITE ID may have related products contracted for that site id
  
• SITE ID card must appear first ahead of any related products
  
• First SITE ID card and related product keys will be accepted 
  
• Subsequent SITE ID card(s) and related product keys will fail 
• Will receive the CAS9125E message              

Common Services Release 14.1 or 15.0

The new format for LMP keys is now based upon SITEID vs. CPU

CAIRIM will only accept one SITE ID card per KEYS member

Customers with contractual agreements such as this require a multi-step CAS9 proc.  

• Each step requires a unique KEYS member
• KEYS consist of a single SITE ID card and all products contractually related to that site.
• First step
•      Read in a KEYS member consisting of a unique SITE ID and it's related products   
•      Read in the PARMLIB member consisting of the CAIRIM control cards for each product regardless of site id
• Each subsequent step
•       Only read in a unique KEYS member for a different SITE ID and it's related products   
•      Change the PARMLIB DD to DD DUMMY  

If the KEYS are not formatted correctly, CAIRIM may issue a CAS9125E message for different reasons.

Please refer to the following knowledge articles:

• Article 135156 refers to the individual Product keys which may receive - CAS9125E - CPUID IS NOT 6 CHARACTERS 
• Article 143298 refers to problem if SiteKey is not defined correctly - CAS9125E - INVALID DATA: MISSING KEYWORD: LMPCODE
• Article 142986 refers to problems that will occur if the keys are not coded exactly as received from licensing -  CAS9125E - INVALID DATA: KEY TAMPERING
• DETECTED OR TRANSCRIPTION ERROR

** If applying new keys in a z/VM environment, see Knowledge article # 189417. 

Sample JCL (assuming 3 different site ids:
//CAS9               PROC  CAW0LOAD='your.CAW0LOAD',
//                        CAW0OPTN='your.CAW0OPTN',
//                        RIMPARM=CARIMPRM,
//                        KEYS=SITEKYS1,
//                        AUTOCMD=CAUTOCMD
//*                      USERCMD=CAUSRCMD
//SITEID1          EXEC PGM=CAIRIM,REGION=2M
//STEPLIB         DD  DISP=SHR,DSN=&CAW0LOAD
//PARMLIB        DD  DISP=SHR,DSN=&CAW0OPTN(&RIMPARM)
//KEYS              DD  DISP=SHR,DSN=&CAW0OPTN(&KEYS)
//AUTOCMDS   DD  DISP=SHR,DSN=&CAW0OPTN(&AUTOCMD)
//*                      DD  DISP=SHR,DSN=&CAW0OPTN(&USERCMD)
//*CAIRACF      DD  DISP=SHR,DSN=&CAW0OPTN(RACFLIST) 
//*
//SITEID2         EXEC PGM=CAIRIM,REGION=2M
//STEPLIB        DD  DISP=SHR,DSN=&CAW0LOAD
//PARMLIB       DD  DUMMY 
//KEYS             DD  DISP=SHR,DSN=&CAW0OPTN(SITEKYS2)
//AUTOCMDS  DD  DUMMY 
//*                     DD  DISP=SHR,DSN=&CAW0OPTN(&USERCMD)
//*CAIRACF     DD  DISP=SHR,DSN=&CAW0OPTN(RACFLIST) 
//*
//SITEID3        EXEC PGM=CAIRIM,REGION=2M
//STEPLIB       DD  DISP=SHR,DSN=&CAW0LOAD
//PARMLIB      DD  DUMMY 
//KEYS            DD  DISP=SHR,DSN=&CAW0OPTN(SITEKYS3)
//AUTOCMDS DD  DUMMY 
//*                    DD  DISP=SHR,DSN=&CAW0OPTN(&USERCMD)
//*CAIRACF    DD  DISP=SHR,DSN=&CAW0OPTN(RACFLIST)
//*

----------------------------------------------------------------------------------------------------------------------------------------------------------------

There is also the possibility that for the same SITEID() value there are 2 different associated SITECODEs().

It could happen in fact that only some of the PRODUCT KEYs associated with a SITEID()/SITECODE() are expiring, so the same SITEID() will be linked to a new SITECODE() and the new extended PRODUCT KEYs are associated to this new SITEID()/SITECODE() combination.

In this case there is no need to build a multi-steps CAS9 procedure and the customer can use the new LMP keys with either the "old" or "new" SITECODE value. The old LMP keys will also work with either SITECODE.