Previous topic |
Next topic |
Contents |
Contact z/OS |
Library |
PDF
RACROUTE REQUEST=VERIFY: Identify and verify a RACF-defined user z/OS Security Server RACROUTE Macro Reference SA23-2294-00 |
|
The RACROUTE REQUEST=VERIFY macro provides RACF® user identification and verification. The
macro instruction identifies a user and verifies that the user is
defined to RACF and has done
either of the following tasks:
You can protect applications by using profiles in the APPL class along with this macro to control the users able to use applications. For more information about protecting applications, see z/OS Security Server RACF Security Administrator's Guide. A subsystem can use REQUEST=VERIFY and the new keywords to create an ACEE. (For information on VLF considerations for ACEEs, see z/OS Security Server RACF System Programmer's Guide.)If RACF is not active or not installed, SAF, using the new keywords, builds a default ACEE to satisfy the request. The purpose of this use of REQUEST=VERIFY is for job submission and user verification checking. The following order of priority exists for replacing the fields
in the existing TOKEN:
To issue the RACROUTE REQUEST=VERIFY macro, the calling module must be authorized (APF-authorized, in system key 0–7, or in supervisor state) or the NEWPASS, PHRASE, NEWPHRASE, ICRX, ICTX, and IDID keywords must be omitted and the calling module must be in the RACF-authorized caller table and fetched from an authorized library and reentrant. However, the caller does not need to be authorized or in the RACF-authorized caller table when specifying ENVIR=VERIFY on the RACROUTE REQUEST=VERIFY macro. Guideline: If you run programs that issue the RACROUTE REQUEST=VERIFY macro, run those programs APF-authorized. See z/OS Security Server RACF System Programmer's Guide for information on the authorized caller table. The caller cannot hold any locks when issuing RACROUTE REQUEST=VERIFY. Automatic direction of application updates does not propagate RACROUTE
REQUEST=VERIFY requests that update the RACF database;
however, the following ICHEINTY requests issued by RACROUTE REQUEST=VERIFY
are propagated:
The ICHEINTY issued by RACROUTE REQUEST=VERIFY to change the password
in the user's profile is not eligible for propagation by automatic
direction of application updates because it is already eligible for
propagation by automatic password direction.
Note:
|
Copyright IBM Corporation 1990, 2014
|