IMS command security with ACF2 not working as expected

Products

• ACF2
• ACF2 - MISC
• ACF2 - z/OS

Issue/Introduction

When attempting to implement command security in IMS, there was a recent case of an application programmer that stopped an IMS transaction when they should not have the access to do so.

Things that have been checked:

1. IMS OPTS has MODE(ABORT). It was MODE(LOG). After the change was made, IMS was recycled.
2. $Command class is ICM, that is set to VALIDATE.
3. $KEY(STOP) should not allow access to the userid, yet the commands can be entered successfully.
4. In the ACF2 report, there is a violation, but IMS still allows the command.

Is there anywhere else that should be looked at to make this work?

Resolution

In this situation, the DFSCCMD0 exit was in the SDFSRESL. Removing the IMS exit allowed normal ACF2 validation to occur.

IMS exits DFSCCMD0 or DSPDCAX0 are capable of overriding the denial from ACF2/External Security.

If the culprit exit was ACF2 or ACF2/IMS interface related, look out for a DSPMOD field of PRE-VALD or PST-VALD on the RV report.

To verify that ACF2 is passing a denied return code back to IMS, a SECTRACE can be performed. To do this, set the trace, re-issue the command, and run the ST report.