Examples: Using the QUERY SECURITY command for resource security checking

You can use the two forms of the QUERY SECURITY command in a number of different ways to customize resource security checking within an application. Typically, you can use QUERY SECURITY to check whether a user is authorized to use a particular transaction before displaying the transaction code in a menu. You can also use QUERY SECURITY to control access to data at the record or field level.

Example: Changing the level of security checking

You can use QUERY SECURITY to perform a different level of security checking from that which CICS® would perform for application programs that specify RESSEC(YES) or CMDSEC(YES).

For example, suppose a transaction has RESSEC(YES) and contains a number of EXEC CICS READ FILE commands and a number of EXEC CICS WRITE FILE commands. For each command, CICS performs a security check to ensure that the terminal user has access to the relevant file, even though the same file may be being accessed each time. An alternative to this is to switch off security checking at the transaction level by specifying RESSEC(NO) on the transaction definition and then, when the application starts, execute a command such as: 
EXEC CICS QUERY SECURITY RESTYPE('FILE') RESID(file_name) UPDATE(cvda)
This command allows the transaction to continue without any further calls to RACF®.
Note: Switching resource security checking off, using RESSEC(NO), means that all resource checks—not just of files as in this example—are bypassed.

Example: Checking which transactions to offer a user

You can use the QUERY SECURITY command to check whether a user is authorized to use a particular transaction before displaying the transaction code as part of an introductory menu.

When you use the command for this purpose, you will probably want to avoid logging the checks for users who are not allowed to use certain transactions. To do this, use the NOLOG option.

Example: Controlling access to data at the record or field level

Normal CICS resource security checking for files operates at the file level only. You can use QUERY SECURITY to enable your application to control access to data at the record or field level.

To do this, define resource names (which represent records or fields within particular files) with the appropriate access authorizations for the records or fields you want to control. You could define these resources in an installation-defined RACF general resource class and then use the QUERY SECURITY RESCLASS command to check a terminal user's access to a specific field within a file before displaying or updating the field. (The application logic would determine which field.) For example: 
QUERY SECURITY RESCLASS('$FILEREC') RESID('PAYFILE.SALARY')
RESIDLENGTH(14) READ(read_cvda) NOLOG
where '$FILEREC' is an installation-defined RACF general resource class.