This section contains the following topics:
Performance Related Statistics
Acid Index Performance Setting
File Sharing and the Coupling Facility
CICS Performance Considerations
To expedite a resolution for performance related issues, CA requests you automatically issue the TSS MODIFY(STATS) command on an hourly basis.
The output of the command lists the current statistics (at the time the command was issued):
INIT Job initiations validated. XREQ Cross memory requests processed. SMF SMF security records logged. CHNG Number of changes made to the security file. AUD Number of Audited events recorded in the ATS. READ Number of Secfile reads. WRIT Number of Security file writes #REQ Number of Requests pending execution HWM High water mark is the highest amount reached for waits on the queue. LOCK Number of times lock was requested LWT Number of times we couldn’t get the lock Divide LWT by LOCK = Percentage of time waiting for the lock.
In addition, CA will want to see RMF Reports against the device the security file is on. Benchmark several transactions for response time and volume trends. Usually, performance problems creep up because of some added workload or system configuration change. Having a significant history of benchmark data available will:
You can set up CA Top Secret to gather statistics for the:
The collected statistics are written to SMF at defined time intervals. You can then:
To collect statistics
TSS MODIFY STATSLOG(DSNAME)
Specifies the name of a pre-allocated dataset statistics are written to. The dataset must with the format of RECFM=FB, LRECL=100, DSORG=PS.
Default: SMF
TSS MODIFY STATREC(statrec)
Specifies the statistics to be collected. Valid entries are CACHE, CPF, RACROUTE, SYSPLEX, COMMAND, WORKLOAD, IOSTATS, SECCACHE, and ALL.
Default: ALL
TSS MODIFY STATGINT(nn)
Specifies the time interval (in minutes) where statistics are gathered and SMF records are created.
Default: 15 minutes
TSS MODIFY STATG(ON)
Statistics gathering is activated.
Upon de-activation, a final statistics update occurs. To deactivate statistics gathering, enter the command:
TSS MODIFY STATG(OFF)
CPF related event statistics are collected for the number of:
To display CPF related event statistics, enter:
TSS MODIFY(STATS)
Note: CPF Statistics are displayed only if CPF is active and the control option STATG(ON) is specified.
Isolate the security file on a device with nothing else on the disk. This device should be high performance DASD. Fill the remaining DASD space on the volume with a dummy dataset to prevent someone with access to the volume utilizing the free space. Protect this data from access. If isolating the security file is not an option, make sure that any other data placed on the device is not utilized during prime time business hours.
The recovery file should not be put on the same volume as the system catalogs or any other system files. A reserve on volume could cause a “system hang” situation resulting from a deadly embrace. This is also true for the audit file.
Avoid putting the RECOVERY file on the same spindle as the SECFILE. If you lose the single device, you will lose both of these files.
The CA Top Secret address space acts as a file server for other address spaces to access the security file. This includes address spaces beyond the z/OS operating system such as LINUX. The CA Top Secret database is accessible, both inbound and outbound, from any LDAP compliant directory.
Communication between address spaces uses CSA and ECSA. The amount of memory utilized is dependent on how you configure CA Top Secret.
Data integrity must be maintained in a multi-CPU environment. The security file and ATF serialize using the same logic. This logic involves the use of a LOCK record that is stored in the SECFILE. The LOCK record assures that the updating system has complete control of the SECFILE. CA Top Secret does not use a MVS hardware reserve. The Lock record is stored in HDR1 (Header Record One) of the Security File.
Best performance from the security file is achieved when SHRFILE(NO) is set in the CA Top Secret parm file.
Important! Only set SHRFILE(NO) when the security file and audit tracking file are not shared among systems. SHRFILE(NO) causes CA Top Secret to obtain the LOCK record from HDR1 and place it in memory until CA Top Secret is quiesced. With the lock record in memory, CA Top Secret will not need to obtain the lock record before accessing the security file. This could reduce I/O to the security file by as much as 66 percent.
The CA Top Secret ACID index is a directory of the users defined on the security file. It identifies the location of the security record on the SECFILE for each ACID defined to the database. When CA Top Secret initializes, the index is read into memory. Any time an ACID record is updated using an administration command, the index is refreshed.
The AINDXPER, activated via the SHRFILE control option, provides a file I/O performance improvement when the security file is shared between multiple systems and security administration is being done.
For example, if three systems are sharing a security file and the administrator changes or creates a new ACID, it causes the index on that system to be updated both in core and on the file and to set flags that the file has changed. When the other systems attempt to access this file, if AINDXPER is not set, it will have to read the entire index. For larger systems, CA Top Secret reads one or two tracks rather than several cylinders.
The coupling facility is part of the SYSPLEX technology. CA Top Secret allows you to store all or a portion of the security file in an XES structure. Performance is improved because the coupling facility is faster than DASD access.
CA Top Secret OPTIONS(61), allows maintaining the security file lock record in coupling facility. Instead of having to go out to the SECFILE to read the lock record, CA Top Secret uses the faster access speed available with the coupling facility.
The CA Top Secret CACHE reduces I/O against the security file and increases system performance. The CACHE control option can be modified on the fly or through a permanent update in CA Top Secret PARMS. This includes setting the cache size, turning the cache off, clearing the cache, and listing out the cache statistics.
To determine the approximate size for the CACHE and CF XES structure use the TSSFAR UTILITY. When TSSFAR is run with the SFSTATS parameter, the recommended sizes for both the CACHE and XES is listed.
You may need to adjust the size. For instance, if message TSS1301I CACHE HAS BEEN CLEARED occurs too often, increase the cache size.
To determine if the CACHE has cleared, issue a TSS MODIFY CACHE(STATUS). The output line TSS1307I CLEARED (nnnnn) increments once each time the cache is cleared. This value is cleared when you recycle CA Top Secret.
The coupling facility XES structure gets cleared when the structure becomes 95% full. A message is sent to the console when the structure hits 75% full. The message is resent every additional 5%.
SECCACHE provides a cache for CA Top Secret security records that reflect the status of a user following a RACROUTE VERIFY request. The cache is managed in a common data space that can be accessed from all address spaces.
Use SECCACHE to:
To recover unused space, SECCACHE record entries can be set to automatically expire at regular intervals or they can be force purged by command. The longer a record remains in SECCACHE, the more future requests it can handle. The percentage of requests satisfied by SECCACHE indicates how well the SECCACHE is performing.
Once activated, the SECCACHE data space remains intact during a temporary shutdown and restart of the security manager address space. This preserves the security records already cached.
Use the status display to monitor both your data and index area usage. Set a threshold full warning level during initialization that automatically attempts to recover space by clearing expired entries. The warning level applies to both the data and index areas independently. If the automated recovery process cannot recover sufficient space a warning message is sent to the operator console and remains there until sufficient space is recovered, the SECCACHE is deactivated, or the security address space is terminated. Records can be added to SECCACHE until the areas become 100% full.
The SECCACHE control option can be modified online or through permanent update in the CA Top Secret PARMS. This includes setting the SECCACHE initialization options, turning SECCACHE off, clearing records from SECCACHE, and listing SECCACHE statistics.
The caching of security records in an data space improves system performance by re-using the security records on subsequent user log ons.
To activate the security record cache, enter:
TSS MODIFY SECCACHE(nnnn)
Specifies the number of megabytes of available memory allocated as a data space for security record caching.
Maximum: 2 gigabytes
To deactivate the security record cache, enter:
TSS MODIFY SECCACHE(OFF)
SECCACHE requires virtual storage in the form of a common data space. The maximum size of the SECCACHE is 2 gigabytes. Start with less and use the status display to tune the size. To estimate the optimum size for SECCACHE use the formula:
SECCACHE Size = 1.01 * (ACID#(AVGRECSZ + 16))
The number of user ACIDs that "log on".
The average record size from the SECCACHE(STATUS) display.
Example: calculating SECCACHE size
In this example, the number of ACIDs is 25,000 and the average record size is 4200:
1.01 * (25,000(4200 + 16 )) = 102 megabyte
In a shared security file environment, it is important that policy changes made on one system are reflected within any in-core processing tables on all remote systems as soon as possible. This is accomplished internally when a security file I/O is performed on the remote system, for example when a user logs on.
The SECCACHE control option eliminates much of the security file I/O associated with a user log on event. To improve the synchronization an internal processing event performs any in-core table refresh, if required, at the end of two TIMER cycles. This keeps the tables up to date even though the security file has not been accessed. You can manually synchronize the in-core tables with the MODIFY SYNCH control option. This allows you to immediately see the effects of remote changes to selected SDT records with the TSS LIST command.
The Command Propagation Facility (CPF) provides synchronization of Security Files across the enterprise. This lets you take advantage of the performance benefit you get when not sharing the Security File.
Running with the SHRFILE control option set to NO eliminates lock file contention.
Notes:
The facility control option LOCKTIME assigns the amount of time in minutes after which a terminal connected to a specific facility will lock if CA Top Secret does not detect activity.
When running with LOCKTIME active and LTLOGOFF set to NO, the USER remains active in the CICS region taking up CICS resources.
The recommended setting for PCLOCK is:
TOR - PCLock = YES AOR/FOR = PCLock = NO - eliminates exit point
Set your TOR to PCLOCK = YES. This ensures that the TOR locktime is Pseudo conversational. Since the AOR and FOR types are not terminals, we recommend PCLOCK = NO. This eliminates the exit point needed to manage lock time.
Conversational CICS TCA slot is tied up until password is entered Pseudo conversational does not tie up CICS resources waiting for a reply. Replace with an CA Top Secret task freeing up the CICS TCA slot.
CICS signons are sub tasked. Five signon subtasks are allocated by default. CA Top Secret allocates five subtasks when the CICS facility is initialized.
To determine the maximum number of signon subtasks controlled by CA Top Secret facility parms setting use:
MAXSIGN (10, retry) - facility defaults
Extra subtasks (6 through 10) are allocated as needed automatically until the MAXSIGN is hit. Specifying RETRY means that Signon/Signoff requests that exceed threshold are requeued.
Notes:
The shared profile table allows CA Top Secret profile sharing in multi‑user address space environments such as CICS and IMS. CA Top Secret validates authorization checks without leaving the region’s address space. PROFILE sharing is only available at the facility level. To activate or deactivate this option, specify the facility control option SHRPRF or NOSHRPRF.
The number specified in the PRFT Facility Option is in PAGES. Each page holds 256 profiles that are stored in above the line storage storage.
Limit profile administration to off-peak hours for profiles you expect to be shared. Excessive administration for profiles in the table during peak use of the facility can result in having multiple copies of the same profiles stored in the table. The following message is posted when profile table is full:
For example, a region supporting 250 users, each sharing three common profiles, where each user also has one unique profile, must have a shared profile table with no less than 253 entries: PRFT=1.
The default is PRFT=3. It supports profile sharing of up to 768 unique, active profiles within the region. If this value is changed using the TSS MODIFY command, the region must be recycled for the change to take effect.
The userid used when CICS accesses DB2 is determined by the setting of AUTHTYPE parm in the RCT or CSD:
The DB2 subsystem has two CICS exit points for authorization routines:
|
Copyright © 2014 CA Technologies.
All rights reserved.
|
|