Accessor IDs (ACIDs) constitute the basic hierarchical structure of your database. Based on your security policy implementation and required level of protection, ACID records can reach the maximum size. As a result, administrators cannot add attributes and properties to the records, which can impede productivity and response times.
You can increase the maximum size of organizational ACIDs (which let you construct the upper levels of your security hierarchy) or increase the maximum size of all ACIDs. Increasing the size limit avoids the need to redesign the security implementation.
The following illustration shows how a security administrator increases ACID size.
Perform the following tasks to increase ACID size:
- Define a VSAM cluster in the catalog.
- Allocate a security file with a new ACID size.
- Copy the backup security file to the new security file.
Define a VSAM Cluster in the Catalog
The VSAM data set increases the number of records that can be stored by converting the records to VSAM. Before creating the VSAM file, you must define the VSAM cluster that the file that will occupy.
Follow these steps:
Edit the sample JCL in VSAMDEF3 to specify the data set name and volume to be allocated.
Important! Do not run STEP 2 if the security file is not shared.
- Run VSAMDEF3.
The VSAM base cluster file is defined in the catalog. If the security file is shared, the alternate index file and path file are defined.
Allocate a New Security File with a New ACID Size
Allocate a new security file with a new ACID size by increasing the maximum size of ACIDs.
Note: This change can be implemented one security file at a time, does
not affect the size of the security file, and does
not affect system performance.
Follow these steps:
- Determine the required number of blocks for creating the security file:
- Edit TSSMAIND and the SECPARMS portion of TSSMAINS to conform to your site's standards, including the following edits.
The TSSMAIND and TSSMAINS members are in the CAKOJCL0 data set. CAKOJCL0 is available in the yourHLQ.SAMPJCL data set that was installed during product installation (where yourHLQ specifies the data set prefix for the site).
- Specify the name of the dummy run in the SECDUMMY member referenced in TSSMAIND.
A dummy run lets you calculate required blocks without allocating the real security file.
- Set the ID=DUMMY parameter to consist of a maximum of eight characters.
- Execute a dummy run with the JCL in TSSMAIND.
The number of blocks required is returned.
Note: Running TSSMAIND causes an SD37 ABEND or U1520. This result is normal.
- Create the security file:
- Edit the CAKOJCL0 member TSSMAINS.
The CAKOJCL0 data set is available in the yourHLQ.SAMPJCL data set that was installed during product installation (where yourHLQ specifies the data set prefix for the site).
- Set the SPACE parameter on the SECFILE DD statement as recommended in the TSSMAIND output.
The default in the JCL is to use block allocation (rather than cylinders). To use blocks, set the BLKSIZE and BLOCKS parameters properly on the PROC statement. To use cylinders, follow the instructions in the TSSMAINS comments.
- Set VOLSER JCL to the DASD volume serial identifier for your security file.
- Set SECPRIM ID=PRIMARY to identify the name of your security file.
ID supports a maximum of eight characters. The specified characters are placed in the primary security file and distinguish the primary security file from the backup file. We recommend ID=PRIMARY for the primary file and ID=BACKUP for the backup file.
- Set the VSAMFILE DD statement to refer to the VSAM data set that you created when you defined a VSAM cluster in the catalog.
- Set the VSAMAIX DD statement in STEP 2 to refer to the alternate index VSAM data set (if the security file is shared), or remove STEP 2 (if the security file is not shared).
After the VSAM file is created, to copy information from an existing security file, run the TSSXTEND utility. You can copy information from a BDAM-only security file or a security file that uses BDAM and VSAM files.
Specify a MAXACIDSIZE entry (for increasing all ACID size), ORGACIDSIZE entry (for increasing organization ACID size), or both in the TSSMAINS utility job as follows:
Specifies a value between 256 and 1024 that lets all ACIDs reach a size of more than 256 KB. Existing ACIDs do not automatically increase to the new size. However, ACIDs that reach the original limit will adopt the new maximum size.
Specifies a value between 513 and 1024 that lets department organizational ACIDs reach a size of more than 512 KB. Existing department organizational ACIDs do not automatically increase to the new size. However, ACIDs that reach the original limit will adopt the new maximum size.
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.
Run the TSSMAINS job.
The product allocates the file.
Note: If you are using more than one CPU, you can place the security file on a shared DASD volume that is accessible to all systems. In this situation, you specify the control option SHRFILE(YES) on each CPU
Edit the CAKOJCL0 member TSSMAINB.
Important! The SECPARMS contents must remain unchanged from the values used in TSSMAINS. If the backup file has different attributes than the primary file, the product might not be able to copy the primary file into the backup file during a backup process.
Execute the JCL in CAKOJCL0 member VSAMDEF6 to invoke IDCAMS to create a separate backup VSAM file.
Note: Specify the backup VSAM file on the VSAMFILE DD statement.
The product creates a separate backup VSAM file
- Run TSSMAINB to allocate the backup security file.
You now have a new security file with a new ACID size.
Copy the Backup Security File to the New Security File
After allocating a security file that provides a new ACID size limit, copy the old backup security file to the new security file.
To perform this task, you must be a Master Security Control ACID (MSCA) or a user with one of the following authorizations:
- USE access to the TSSUTILITY.TSSXTEND entity in the CASECAUT resource class for any function except ZAP.
- UPDATE access to the TSSUTILITY.TSSXTEND entity in the CASECAUT resource class for using the ZAP function.
Follow these steps:
Use the following JCL to copy the contents of the old backup security file into the new security file:
//jobname JOB USER=msca only
//EXTEND EXEC PGM=TSSXTEND
//MAINTOUT DD SYSOUT=A
//SECFOLD DD DSN=name.of.backup.security.file,DISP=SHR
//SECFNEW DD DSN=name.of.new.security.file,DISP=SHR
//SECNVSM DD DSN=name.of.vsamfile,DISP=SHR for the output (new) VSAM dataset
//SECOVSM DD DSN=name.of.vsamfile,DISP=SHR for the incoming (old) VSAM dataset
//MAINTIN DD *
The OLDKEY and NEWKEY fields must be a 16-character hexadecimal number. You cannot add comments to these fields.
Important! Safeguard your key.
- Change the PROC statements in your JCL procedures (TSS STC, TSSB STC, and backup and recovery procedures) to point to the new security and backup files.
- IPL the system by modifying the TSS procedure in SYS1.PROCLIB to include the new primary and backup security files and VSAM files.
- Start CA Top Secret with the new security file.
Increased ACID size is now available. ACIDs that reach the original limit will adopt the new maximum size. Having an increased size avoids the need to redesign the security implementation and prevents situations in which administrators cannot add attributes and properties to records that have run out of space.