Previous Topic: Common ComponentsNext Topic: Special Security Records


CA Top Secret Files

CA Top Secret uses the following files.

Important! GRS and MIM are facilities that control resource serialization. CA Top Secret uses its own queuing and locking mechanism (and does not issue hardware reserves). Therefore, CA Top Secret files should be in GRS exclusion tables, and QNAMES are not necessary for MIM.

Security File

Provides an encrypted security database of security records that contain all user and resource permissions and restrictions. When a user initiates a job or signs on to an online facility in a z/OS environment, CA Top Secret obtains the user's security record from the BDAM security file and places it in the user's address space for the duration of the session.

The security file allows all CA Top Secret security information to be stored in a single shared database for all CPUs. Within the security file, each user is associated with a unique security record that lets CA Top Secret associate access authorizations with users.

VSAM File

Stores digital certificates, keyring records, Kerberos records, Data Classification records, SIGVER records, and IDMAP records.

Mirror Security File

Stores an identical copy of all data that is stored on the BDAM security file.

Mirror VSAM File

Stores an identical copy of all data that is stored on the VSAM security file.

Parameter File

Stores and defines control options at initialization and sets up the product operating environment.

Audit/Tracking File

Records security-related events and can be shared among CPUs. Events include violations, job and session initiation, and resource access. You can designate an optional, alternate Audit/Tracking file to increase the amount of information that can be stored before the file fills and begins to wrap.

Backup File

(If the BACKUP control option is active) Stores the automatic daily backup of the security file to ensure complete integrity of the security environment. The backup file is an exact copy of the security file as it existed at the time of the last backup. If the device containing the security file becomes unavailable, you can use the backup.

Recovery File

Stores recent administrative commands, the extent of which depends on the size of the allocated file. The backup security file, along with the application of select recovery file commands, can completely restore a damaged security file. This is a wraparound file.

$$$LOG$$ File

Contains status messages and information about control option modifications. A DD statement for this file should not be included in the product started task JCL. If CA Top Secret is started under JES, the product dynamically allocates a SYSOUT file with a ddname of $$$LOG$$. If CA Top Secret is started with SUB=MSTR while JES is not active, no $$$LOG$$ file can be allocated. In this case, the $$$LOG$$ file is dynamically allocated when JES becomes active.

Note: If the $$$LOG$$ DD statement is included in the product started task JCL, dynamic allocation is not possible. In that case, there is no $$$LOG$$ file when TSS starts with SUB=MSTR.

Specifically, the file contains the following data:

Command Propagation Files

Consists of two types of files that are associated with the command propagation facility (CPF). These files must be dedicated to a single CPU.

CPF Recovery File

Saves transmitted commands until a response to those commands has been received from remote nodes.

CPF Journal Files

Consists of the following journals for each CPF node to provide a historical record of command traffic to and from the node:

  • RECVCMDS is a receive journal that, for each node, contains commands from all other nodes and responses to all other nodes.
  • node_name is a send journal that can exist for each connected node to record commands that are sent to that node and responses from that node.