TMSINIT WTOR IEFTMS32 VS ONLY SEEING ICHxxx message, why difference?

Products

• CA 1 Flexible Storage

Issue/Introduction

On one system when command S TMSINIT was issued, the Master password was given to disable CA-1 in batch.  This triggered IEFTMS32, to which  it  was replied and then IEFTMS24 appeared 'IEFTMS24 - USERID/PASSWORD ACCESS DENIED' without any other message (there were no associated RACF messages). What is the issue here?
What level of access is needed, as there are no RACF messages? 

SECWTO as 'YES'.

Using another ID did issue the RACF error messages. 

Why the difference?

 

Environment

Release : 14.0

Component : CA 1 Tape Management

Resolution

The reason the IEFTMS24 vs the ICHxxx messages is issued is because:

If the USERID itself is not defined; the IEFTMS24 without the ICHxxxx message is issued. If the USERID is defined and a bad password is replied;  the ICHxxxx message is issued.. There is no ICHxxxx if it is because of an unknown userid.

 

When SECWTO=YES RACF needs to have defined BATCH -to batch activate, DEACT- to deactivate and REINIT-to reinitialize CA1 defined for access when running TMSINIT.  

See:

RDEFINE CA@APE (BATCH) UACC(NONE)
RDEFINE CA@APE (REINIT) UACC(NONE)-See Note 
RDEFINE CA@APE (DEACT) UACC(NONE) 
 
Note:
You can define user access (UACC) READ for any of the listed resources. We recommend that you define the UACC (READ) for the following common resources:
 
YSVCCOND
 
NLRES
 
NSLRES
 
FORNORES
 
REINIT
 
documented here:

IBM RACF Security Setup
 
 
And here is more:
CA 1 Initialization Processing (INIT)
This feature controls initialization of CA 1. The feature is invoked during the execution of TMSINIT. Control is provided for the reinitialization of CA 1, deactivation of CA 1, and making CA 1 batch active. This security call is not optional.
If CA 1 is activated, then security is not checked during the initial execution of TMSINIT following an IPL. Attempts to de-activate or BATCH activate 
CA 1 following an IPL results in an external security resource verification. Once CA 1 is active, invocations of TMSINIT result in external security resource checking based on the setting of the SECWTO option.
A security resource verification is made on the entities BATCH, DEACT, and REINIT. The class is set to CATAPE. If TMSINIT is run as a started task, the user is still prompted for userid and password. TMSINIT will continue after the operator replies to the message. If TMSINIT is run as a batch job or TSO command, the CA 1 class name of CATAPE must be defined. See the setup documentation of your external security system for more information.  (Optional) You can code and install the TMSXITS (option XITS for the module name) exit to ACCEPT the access to these TMSINIT resources without calling the security system. If this is done, then you do not need to define the class name and resources to your security package. For instructions about how to use TMSXITS, see User Exits and Interfaces.
 
Also see:

Security System Interface

When you changed SECWTO from YES to NO the 1st TMSINIT loads the change and will still prompt for userid/password because the SECWTO=NO is just loaded and not taken effect.

It would take effect on then next run of TMSINIT and at this point SECWTO=NO will not check security

SECWTO set as ‘NO’ will not trigger the WTOR or it will not check the security unless you are changing it from YES to NO the initial TMSINIT run you are still prompted but after that you should not be.

SECWTO=NO can be updated without IPL as well