CA View - Report Deletion Authority
Article ID: 189532
Updated On:
Products
Deliver
View
Issue/Introduction
An end-user wanted to delete a report in CA View, using the mainframe online, and received panel message:
... --- COMMAND DENIED
Long message: SARSRQUX-YOU ARE UNAUTHORIZED TO USE THE COMMAND
The client has a modified SARSRQUX exit.
In the exit is movement through a UserID table, to validate authority to perform command functions.
They used external security with ALTER access being granted on View REPT resource rules.
Environment
Release : 12.2
Component : CA View
Resolution
On the panel in question, the message "COMMAND DENIED" appears, which was generated by the client's modified SARSRQUX exit.
In this instance, an end-user was denied the ability to delete a report.
The SARINIT parameters had DELETE=YES, which means that View is allowing report deletion, by use of line command "D" or "DD".
To do online deletes was being overridden by the SARSRQUX exit.
For security, SARINIT parameters SECID=VIEW and SECURITY=EXTERNAL were used.
Even with the definition of security rules providing coverage for the REPT resource, it again appeared that the SARSRQUX exit is overriding anything else, in displaying the "DENIED" message.
In the SARSRQUX code, the problem appeared to be with the results of a table lookup.
The code said to see if a "D" is being issued, to then check a table of TSOIDs.
The table check was dropping through, so there was the issuing of the "DENIED" message.
The client added new TSOIDs, of an invalid length, to the table, which caused the problem.
They corrected the code and no longer had the problem of having the DENIED message displayed.
In this instance, an end-user was denied the ability to delete a report.
The SARINIT parameters had DELETE=YES, which means that View is allowing report deletion, by use of line command "D" or "DD".
To do online deletes was being overridden by the SARSRQUX exit.
For security, SARINIT parameters SECID=VIEW and SECURITY=EXTERNAL were used.
Even with the definition of security rules providing coverage for the REPT resource, it again appeared that the SARSRQUX exit is overriding anything else, in displaying the "DENIED" message.
In the SARSRQUX code, the problem appeared to be with the results of a table lookup.
The code said to see if a "D" is being issued, to then check a table of TSOIDs.
The table check was dropping through, so there was the issuing of the "DENIED" message.
The client added new TSOIDs, of an invalid length, to the table, which caused the problem.
They corrected the code and no longer had the problem of having the DENIED message displayed.
Feedback
Yes
No
Powered by
