How Concurrent Action Processing Works -- CA

How to Enable Concurrent Action Processing › How to Enable and Secure Concurrent Action Processing › Concurrent Action Processing Overview › How Concurrent Action Processing Works

How Concurrent Action Processing Works

Concurrent Action Processing (CAP) dynamically creates additional server address spaces to process certain actions concurrently. This processing method reduces the elapsed time that is required to process large numbers of actions. Thus CAP speeds the processing of batch jobs and packages.

When Concurrent Action Processing is requested, the request is processed in the following manner:

Any actions that are wildcarded or masked, are expanded and the actions are sorted in type sequence order to create a chain of element action requests.
Note: Only use wildcarding or masking when you are submitting one action (for example, all Add actions) in the same job, to avoid unpredictable results.
Any actions that use an archive file as input, such as RESTORE, LIST from archive file, and TRANSFER, are executed serially in the routing region. These actions always run serially in the routing region.
Before execution of other actions, CA Endevor SCM determines whether CAP is enabled and the user is authorized in the following order:
1. CA Endevor SCM determines whether Global Type Sequencing is enabled.
2. If Global Type Sequencing is enabled, then the request JCL is examined for the presence of an EN$CAP or EN$CAPnn DD card. These parameters indicate whether the JCL requests Concurrent Action Processing.
3. If the JCL requests CAP, then the C1DEFLTS parameters SPAWN and SPAWNCNT values are checked to see if CAP is enabled.
4. A check is made through the External Security Interface to determine whether the user is authorized to request Concurrent Action Processing.
If any of these conditions are not met, then all actions are processed serially.
If CAP was requested and is permitted as verified in step 3, the chain of action requests that remains from step 1 and 2 is examined. Any ADD, UPDATE, or RETRIEVE requests found in the chain are then preprocessed as follows.
1. Any DDNAME is translated to a data set name; that is, the DDNAME is localized. These data set names are created in the following manner.
  - When a CA Endevor SCM server allocates a pseudo-temporary data set name, CA Endevor SCM builds the name using a jobnumber node in the CA Endevor SCM generated name, rather than the jobname. This is necessary to avoid data set contention among the action request regions.
  - In some cases, CA Endevor SCM requests that the system generated names of temporary data sets be unique in the system. This is done to avoid data set contention among servers. Currently, when CA Endevor SCM allocates a temporary data set that is to have a system generated name, it does so by specifying a DALDSNAM text unit. This causes the temporary data set name to have the following form, which may not be unique:
```
    SYSyyddd.Thhmmss.RA000.jobname.dsname.Hnn
```
    However, in an action request region created for Concurrent Action Processing, CA Endevor SCM may eliminate the DALDSNAM for some temporary datasets. This causes a name to be generated with the following form, which is unique:
```
    SYSyyddd.Thhmmss.RA000.jjobname.Rggnnnnn
```
  Note: For temporary data sets created and deleted in the same processor step (that is, allocated with DISP=(NEW,DELETE,DELETE), or with no DISP at all), the DALDSNAM is not eliminated. This means that such data sets are always generated as SYSyyddd.Thhmmss.RA000.jobname.dsname.Hnn, even with Concurrent Action Processing. Therefore, contention is still possible with such data sets.
2. The data set specified (using the DSNAME or DDNAME parameter) is checked to determine if it is a cataloged data set. If any data set refers to an uncataloged file (for example, a SYSIN/SYSOUT data set, a temporary data set or a non-SMS data set with a disposition of NEW), then Concurrent Action Processing cannot be enabled and the actions will be processed serially.
Important: If you use exit 4 programs to alter input and output files before the execution of an ADD, UPDATE, or RETRIEVE action, the data sets specified in the SCL must be cataloged data sets. This requirement applies even if the user has an exit 4 program that changes the data set names.
Action request regions are created equal to the SPAWNCNT value set in the C1DEFLTS table. However, if the SPAWNCNT value was overridden on the job request, that value is used to determine the maximum number of action request regions. The value can be changed for a specific job in the following manner:
- For batch requests, by using the EN$CAPnn DD card on a batch job request JCL.
- For foreground requests, by using the Concurrent Number field on the Submit Package panel or the Batch Options Menu.
Note: If CA Endevor SCM is called from a processor, it will not create any servers. In addition, if an action request region is created during concurrent action processing, it will not create additional servers.
The actions ADD, UPDATE, RETRIEVE, MOVE, GENERATE, DELETE, SIGNIN, and TRANSFER (CA Endevor SCM to CA Endevor SCM) are dispatched to action request regions. Actions that can be processed simultaneously are routed from the routing region of the originating job to the action request regions and processed concurrently.
- The routing region is the batch job, TSO session, or CA CM Enterprise Workbench session that has requested that actions be processed concurrently.
- Action request regions are the started tasks that are created to process the actions. Multiple action request regions are created. They receive individual action requests from the routing region, process them, and send the results back.
CAP uses Global Type Sequencing to determine which actions can be processed at the same time. Global Type Sequencing determines whether actions can be processed concurrently. Elements in the same type sequence can be processed concurrently. Additionally, elements that are not listed in the global type sequence can be processed concurrently with any element. There is no guarantee that actions on elements in the same type sequence (or on elements that are not type sequenced) will be processed in the order in which they appear in the SCL. However, actions against the same element name will be processed serially and in the order in which they appear in the SCL, provided the element names are explicit. One action must complete before the next is dispatched.

Note: If you specify AUTOGEN, SCL requests are fully resolved based on current inventory contents before any actions are processed. For example, suppose that you have a GENERATE action with the AUTOGEN option and several MOVE actions in the same request. The MOVE actions will not include any of the additional elements that are copied back as a result of the GENERATE action.
After all other actions have completed processing, the actions PRINT, ARCHIVE, LIST, and TRANSFER to archive data set are performed serially in the routing region.