Pervasive encryption of a PDSE, sequential datasets, and large datasets fails in ACF2 after applying IBM PTF OA60485
search cancel

Pervasive encryption of a PDSE, sequential datasets, and large datasets fails in ACF2 after applying IBM PTF OA60485

book

Article ID: 206594

calendar_today

Updated On:

Products

ACF2

Issue/Introduction

After IBM PTF OA60485 was applied, any user trying to do pervasive encryption of a PDSE, sequential dataset, or large dataset failed with error message:

IGD17156I xxxxxx.xxxxxxx.xxx , KEY LABEL IS IGNORED  

Environment

Release : 16.0

Component : CA ACF2 for z/OS

Resolution

Prior to OA60485, IBM made a RACROUTE AUTH call that a rule like this would be used.

 $KEY(STGADMIN) TYPE(FAC)
  SMS.ALLOW.PDSE.ENCRYPT UID(XXXVVB) SERVICE(READ) ALLOW
  - UID(*) PREVENT

This caused problems with Top Secret, so IBM changed the call to a RACROUTE EXTRACT.  The PTF added these three calls:

REQUEST=EXTRACT.  
  FACILITY(STGADMIN.SMS.ALLOW.PDSE.ENCRYPT)
  FACILITY(STGADMIN.SMS.ALLOW.DATASET.SEQ.ENCRYPT)   
 
The SAF call also added MATCHGN=NO as a parameter so generic rules would not be allowed.  Since that is the case, to allow a user in ACF2 after the PTF a rule like this is needed for a PDSE:

$KEY(STGADMIN.SMS.ALLOW.PDSE.ENCRYPT) TYPE(FAC)
$USERDATA(ALLOW_XXXVVB_ONLY)    <==== a $USERDATA card is required also.  Contents are not important
  UID(XXXVVB) ALLOW
  UID(*) PREVENT

The entire name must be in the $KEY, and what users to be allowed are added as a rule line.  No SERVICE should be on the rule line.  If all users are to be allowed, then change the last line to ALLOW instead of PREVENT.

Rules for sequential datasets would look like this:

$KEY(STGADMIN.SMS.ALLOW.DATASET.SEQ.ENCRYPT) TYPE(FAC)
$USERDATA(ALLOW_XXXVVB_ONLY)    <==== a $USERDATA card is required also.  Contents are not important
  UID(XXXVVB) ALLOW
  UID(*) PREVENT