Define SSIGNON SSKEY for PTKTDATA in ACF2

Products

• ACF2

Issue/Introduction

Implementing passticket for an external DB2 application. The application to generate a usable passticket is requesting the 16-byte hex key used to create this entry:

SSIGNON / D02G LAST CHANGED BY xxxxxx ON 07/02/14-09:36
                     NOENCRYPT MULT-USE SSKEY(*SUPPRESSED*)

By design, it's not retrievable. What are the implications of re-defining the above entry with a new SSKEY? Is recycle of the application required?

Some systems have passticket entries with no SSKEY defined: 

SSIGNON / DB2UAT LAST CHANGED BY xxxxxx ON 06/14/17-14:51
                     NOENCRYPT MULT-USE

SSIGNON / DB3PDIST LAST CHANGED BY xxxxxx ON 11/08/17-14:41
                     NOENCRYPT MULT-USE

What are the possible implications of adding an SSKEY to those entries?

 

 

Environment

Release : 16.0

Resolution

The only implication of changing the sskey is to ensure that all applications that are requesting the passticket are using the same sskey.

If there are multiple z/OS LPARs sharing the databases, there should be no problem.
If there are multiple z/OS LPARs that are not sharing the databases, but have their own version of the passticket record, they will also need to be changed. 
If passticket is obtained off platform and not using the ACF2 SSIGNON profile records, then that process will also need to know the new sskey.

There is no need to restart the z/OS applications that need the profile records as each call will issue an extract request and will obtain the latest sskey.

With the profile records that do not have an sskey, these cannot be used for a passticket request.
Adding an sskey and following the same guidelines, as referenced above, will allow these keys to be successfully used.   
NOTE: ACF2 does not now allow an ssignon profile record to be created without an SSKEY.