Question & Answer
Question
You would like to turn on storage protection, transaction isolation, command protection, and re-entrant program storage protection to avoid storage violations in your CICS Transaction Server for z/OS (CICS TS) regions. Before doing this you would like to know: How will each of the storage protection facilities affect the performance in your CICS TS regions?
Answer
The amount of overhead added by storage protection, command protection, and reentrant program storage protection to your CICS TS region is insignificant. But, there is some performance cost when turning on transaction isolation as documented in section CICS storage protection facilities: performance considerations in the CICS TS V5.1 documentation:
When using transaction isolation, it is necessary to activate pages of storage to the allocated subspace of the task. Before the storage is activated to the subspace, it is fetch protected so that the task cannot access the storage. After the storage is activated to the subspace allocated to the task, the task has read and write access to the storage. CICS must activate user storage to a subspace every time that the user task invokes a GETMAIN command to get a new page of user-key task-lifetime storage. Some performance cost is involved when activating storage to a subspace, so the activity should be kept to a minimum.
Storage below the 16 MB line is activated in multiples of 4 KB. Storage above the line is activated in multiples of 1 MB ...(So a user task that runs completely above the line is more likely to require only one activate operation.)
Link edit your programs by using RMODE(ANY) and define them as DATALOCATION(ANY). All transactions should be defined as TASKDATALOC(ANY), thus reducing the number of storage activations.
When you need to obtain storage below the line, you can improve performance by obtaining all the storage in one GETMAIN request, rather than several smaller GETMAIN requests. This also minimizes the number of storage activate operations.
In addition to an increase in CPU, the transaction isolation facility increases the allocation of some virtual storage. If insufficient real storage is allocated, paging problems can result, which then affect performance.
- As documented under CICS dynamic storage areas, 24-bit storage extents are usually allocated in multiples of 256 KB. However, when transaction isolation is in operation, the UDSA is allocated in 1 MB extents. With the larger extent size, it is likely that the DSALIM value will be reached much more quickly.
- When you are running with transaction isolation off, CICS allocates the EUDSA in 64KB pages. But when you are running with transaction isolation active, CICS allocates the EUDSA in 1MB pages. These 1MB pages can not be shared with other tasks. CICS will allocate 1 MB for a getmain request as small as 500 bytes of EUDSA storage and the storage is owned by the requesting task alone.
To summarize, the following table shows how CICS allocates storage when transaction isolation is active and inactive:
Page Sizes
| TRANISO (NO) | TRANISO (YES) | |
| UDSA | 4K | 4K |
| EUDSA | 64K | 1M |
Extent Sizes
| TRANISO (NO) | TRANISO (YES) | |
| UDSA | 256K | 1M |
| EUDSA | 1M | 1M |
This means when using transaction isolation that you will need to increase the size DSALIM and EDSALIM in your system initialization parameters to account for the increase in the UDSA and EUDSA usage. If you are specifying the DSA sizes, you will also have to increase UDSASZ and EUDSASZE. See Allocation of real storage when using transaction isolation for more information including some guidelines.
Note: In addition to other changes in CICS TS V5.1 to help virtual storage constraint relief (VSCR), the default TASKDATALOCATION for the mirror transaction CSMI has changed from BELOW to ANY. So if running with transaction isolation turned on this could cause a higher peak in EUDSA because any getmain for user storage by CSMI will now be from 31-bit storage with the minimum 1MB, instead of 24-bit storage with the minimum of 4KB. The EDSALIM default was also changed from 48M to 800M in CICS TS V5.1.
Following is an example that shows the affect of turning on transaction isolation in CICS TS V5.1. First, the environment and workload are described. Then the data in the charts, that includes transaction rate (ETR) and CPU usage, provide a comparison between when TRANISO is OFF and when it is ON. The intent is to give an idea of the cost involved in turning on transaction isolation. The cost is unique to this workload and caution must be applied when trying to apply costs to other workloads.
Hardware
- z196 2817-779 model M80
- LPAR with up to 8 dedicated central processors (CPs)
- Separate LPAR with 4 dedicated CPs for Network driver
- DASD DS8800
- Internal Coupling Facility with ICP links
Software
- z/OS V1.13
- CICS TS V5.1
Workload
- COBOL/VSAM
- All transactions were routed from 4 terminal owning regions (TORs) to 30 application owning regions (AORs) using CICSPlex SM
- 50% of transactions issue file control (FC) requests
- All FC requests are VSAM record-level sharing (RLS)
- Average of 6 requests per transaction (all transactions)
- 69% Read, 10% Read for Update, 9% Update,11% Add, 1% Delete
- All temporary storage (TS) requests are TS shared
- MROLRM is Yes so using multiregion operation (MRO) long-running mirrors
- FCQRONLY is YES forcing file control requests to run under the QR TCB
The workload has a very small amount of pure business logic compared to the number of application programming interface (API) calls that it makes. This enables IBM to detect small changes in CICS pathlength from release to release without it being masked by other application code.
Transaction Isolation OFF (TRANISO=NO)
| ETR | CICS % | Real Storage Frames | MS CPU per Transaction |
| 2072.30 | 128.27 | 163292 | 0.618 |
| 2842.24 | 173.21 | 163292 | 0.609 |
| 4130.87 | 245.55 | 163335 | 0.594 |
| 5047.97 | 296.96 | 163335 | 0.594 |
| 5681.45 | 333.29 | 163487 | 0.586 |
Transaction Isolation ON (TRANISO=YES)
| ETR | CICS % | Real Storage Frames | MS CPU per Transaction |
| 2073.25 | 140.49 | 188103 | 0.677 |
| 2842.38 | 190.72 | 188103 | 0.670 |
| 4129.20 | 272.32 | 188138 | 0.659 |
| 5044.09 | 332.28 | 185032 | 0.658 |
| 5676.44 | 371.88 | 185111 | 0.655 |
The only difference between the two tests is that transaction isolation was turned on in one test and off in the other test. With TRANIS=NO the average CPU per Transaction = 0.600 ms and with TRANIS=YES the average CPU per Transaction = 0.663 ms. So, there was a 0.063 ms increase (about 10%) in CPU per transaction with transaction isolation turned on.
Descriptions of the columns in the charts:
- ETR is the total number of transactions per second accumulated.
- CICS % is the total CPU used for the all TORs and AORs expressed as a percentage of the elapsed time. This is reported in RMF at the RPGN level by APPL%. Based on CP processor seconds therefore can exceed 100%.
- Real Storage frames is the total amount of real storage frames used.
- MS CPU per Transaction is the average number of milliseconds (MS) of CPU per transaction calculated by dividing the total CICS address space CPU used by the ETR. It is the sum of TOR, AOR, and FOR CPU divided by the transaction rate.
The following CICS statistics from the highest ETR show the expected increase in DSA and EDSA size.
Related Information
[{"Product":{"code":"SSGMGV","label":"CICS Transaction Server"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Component":"Storage","Platform":[{"code":"PF035","label":"z\/OS"}],"Version":"5.1;4.2;4.1;3.2;3.1","Edition":"","Line of Business":{"code":"LOB35","label":"Mainframe SW"}}]
Product Synonym
CICS/TS CICS TS CICS Transaction Server
Was this topic helpful?
Document Information
Modified date:
15 June 2018
UID
swg21398664