Create the Security File

Starting Your Product › How to Complete Configuration With CA CSM › Creating the Security File › Create the Security File

Create the Security File

You can use the TSSMAINS utility to create the security file for your system. The security file contains all security-related information about users, profiles, departments, divisions, zones, and resources.

Follow these steps:

Use the number of blocks calculated by TSSMAIND to determine the size of the security file in cylinders:
```
CYLS = 1 + BLOCKS / (BLKS_PER_TRK * TRKS_PER_CYL)
```
BLKS_PER_TRK

Specifies the number of physical blocks with the block size you specified that can be placed on a track.

TRKS_PER_CYL

Specifies the number of physical tracks per cylinder.

The size is determined.
Edit the CAKOJCL0 member TSSMAINS:
1. Specify the security file parameters, line by line, to satisfy your site standards:
  ACCESSORS=nnnn
  Specifies the maximum number of user, profile, department, division, and zone ACIDs defined to CA Top Secret. The value that you enter for nnnn determines the amount of security file space that is allocated to hold ACID‑related security information.
  
  Default: 5000
  
  The following formula determines the actual number of allocated ACIDs:
```
   (((# accessors requested * 16) / blksize(quotient only, no remainder)) +1) * (blksize / 16))
```
  Example:
```
   ACCESSORS=7000
   BLKSIZE=8192
   (((7000 * 16) / 8192) +1) * (8192 / 16))
   ((112000 / 8192) +1) * 512
   (13 + 1) * 512
```
  The number of allocated accessors would be 7168 (not 7000).
  AESENCRYPT
  
  (Optional) Activates AES encryption for passwords and password phrases.
  
  Important! The AES encryption option is specific to CA Top Secret r14 and later; this option is not backwards compatible. If you attempt to start a single r12 system with an r14 or later security file with AES enabled, CA Top Secret does not initialize.
  
  BLOCKSIZE=nnnn
  
  Overrides the default values for the block size of the security file. The nnnn value must be a multiple of 256 and a minimum of 8192.
  
  MAXACIDSIZE=nnn
  
  (Optional) Specifies the maximum allowed ACID size (in kilobytes).
  
  Maximum value: 512
  
  Minimum value: 256
  
  Default: 256
  
  ORGACIDSIZE=nnnn
  
  (Optional) Specifies the maximum allowed department organizational ACID size (in kilobytes).
  
  Important! Use this parameter only if you must support an department organizational ACID size that is greater than the MAXACIDSIZE value. CA Top Secret ignores any ORGACIDSIZE value that is less than the MAXACIDSIZE value.
  
  Maximum value: 1024
  
  Minimum value: 513
  
  Default: None
  
  MLSBLOCKS=nnnn
  
  (Optional) Specifies the number of blocks reserved in the security file to hold the MLS index. This index allows quick access to individual MLS record elements.
  
  If you do not specify this keyword, TSSMAINT calculates that two MLS entries are needed for each ACID that is requested on the ACCESSORS keyword.
  
  Note: For more information about MLS security policy support, see the CA Top Secret Multilevel Security Planning Guide.
  
  PIEBLOCKS=nnnn
  
  (Optional) Specifies the number of blocks reserved in the security file to hold the PIE index. This index allows quick access to owners of prefixed resources.
  
  If you do not specify this keyword, TSSMAINT calculates that two PIE entries are needed for each ACID that is requested on the ACCESSORS keyword. If you are defining many ACIDs, this calculation significantly increases the number of defined index blocks. The PIEBLOCKS keyword reduces that value, allowing for a smaller security file. Each owned prefix index entry requires one 35-byte entry in the index.
  
  RESBLOCKS=nnnn
  
  (Optional) Specifies the number of blocks allocated to hold the general resources index. Each owned general resource prefix requires one 16-byte entry in the index; thus, each index entry points to the owner of the general resource entity.
  
  Default: 10
  
  SDTBLOCKS=nnn
  
  (Optional) Specifies the number of blocks for holding definitions for Static Data Table (SDT) records. An SDT record is a special system ACID that stores various user-defined static data definitions.
  
  Note: For more information about SDT record elements, see the CA Top Secret User Guide.
  
  Valid numbers: 2 to 256
  
  SCA=msca_name/password
  
  Supplies the name and password of the Master Central Security Administrator (MSCA).
  
  msca_name
  
  Specifies a one- to seven-character name for the MSCA.
  
  password
  
  Specifies a four- to eight-character password assigned to the MSCA. The password expires upon initial signon.
  
  Default: SCA=TSSSEC/TORONTO
  
  VOLUMES=nnnn
  Specifies the number of volumes and prefixes defined to CA Top Secret. The value that you enter for nnnn determines the amount of security file space allocated to hold volume‑related security information.
  
  Default: 1000
  
  The following formula determines the actual number of allocated volumes:
```
   (((# volumes requested * 16) / blksize(quotient only, no remainder)) +1) * (blksize / 16))
```
2. Set the VOLSER JCL parameter with the DASD volume serial identifier for your security file.
3. Set the CYLS parameter.
4. Set the SECPRIM ID=PRIMARY parameter to identify the name of your security file.
  The ID has a maximum of eight characters. Your entry (or the default, PRIMARY) is placed in the master security file and distinguish the master security file from the backup file. CA Technologies suggests ID=PRIMARY for the master file and ID=BACKUP for the backup file.
5. Set the VSAMFILE DD statement to refer to the VSAM data set that you previously created.
6. Edit step 2 of the sample JCL by performing one of the following actions:
  - To use the VSAM/r15 data set with a shared security file, set the VSAMAIX DD statement to refer to the alternate index VSAM data set.
  - If the security file is not shared, remove step 2 from the JCL.
The member is customized.
Run the TSSMAINS utility job.
When the job finishes running, security file creation is complete.
(Optional) Perform the following steps if you are using more than one CPU:
1. Place the security file on a shared DASD volume that is accessible to all systems.
2. Specify the control option SHRFILE(YES) on each CPU.
  This control option setting specifies for files that CA Top Secret uses to be shared among other operating systems, CPUs, or both.