Note: No CA Datacom CICS Services solutions exist to migrate from CTS 3.2 to CTS 4.1. However, follow CICS migration steps. For instructions, see IBM documentation.
A Quasi Reentrant (QR) TCB in CICS along with the dispatcher allow for tasks to be executed in a serialized manner. A QR TCB protects the shared resources from being overridden by concurrently running tasks. If the system is very much QR TCB bound, such as too much demand on the QR TCB, some of the work can be offloaded to L8 or L9 for processing.
For migration purposes, select the option of either OPENAPI=YES or NO, and then assemble the macro DBCVTPR. This allows enablement of the DBNTRY and OPEN/CLOSE TRUEs with API(OPENAPI) or API(CICSAPI) during the CA Datacom CICS Services STARTUP.
This choice is important to be made correctly. If the application is not threadsafe then it begins execution on a QR TCB. When it calls the DBNTRY TRUE, then it would switch from QR to L8. On the way back to the application program it would switch back to QR, and therefore this TCB switching introduces unnecessary overhead.
To determine whether to use the CICSAPI or the OPENAPI, answer two questions at the outset:
Selecting CICSAPI
A CICSAPI program commences execution on a QR TCB. However, programs commence execution on L9 if EXECKEY=USER. DATACOM TRUE runs with EXECKEY=CICS, so it commences execution on L8 if defined as API(OPENAPI). Therefore, to avoid switching back and forth from L8 to L9, it is best to define the DATACOM TRUE and the application as API(CICSAPI).
If the customer application is not threadsafe or the application runs with the EXECKEY=USER even though it might be threadsafe, define the DBNTRY TRUE as API(CICSAPI) since the user application cannot run on the L8 TCB. In this case, CA Datacom CICS Services runs on the same TCB as the application and there is no unnecessary TCB switching.
If you are using third-party vendor software to interface with CA Datacom, get confirmation from the third-party vendor or request a threadsafe version of the product and install it.
The decision of where to run each process or program must be an elaborate decision, thoroughly tested for TCB switching, and verified for efficiency, since many factors are involved in the efficiency of the overall request processing system.
Selecting OPENAPI
To potentially make your transaction processing more efficient, you can commence execution of CA Datacom TRUE, DBNTRY on an OPENAPI TCB such as L8 or L9. This can be especially effective if there are DB2 calls mixed with the CA Datacom calls in the application.
An OPENAPI program commences execution on an OPEN TCB, either L8 if EXECKEY=CICS or L9 if EXECKEY=USER.
If the application is fully threadsafe and can be defined as an API(OPENAPI), then the user may prefer to define the DBNTRY TRUE as API(OPENAPI) as well. The EXECKEY of the application and the EXECKEY of the TRUE must be the same for maximum efficiency.
If the EXECKEY for the two programs are not the same, the control toggles between L8 and L9 which is not the best scenario.
If the customer application uses DB2 calls mixed with CA Datacom calls, then it makes sense to define the DBNTRY TRUE as OPENAPI so the CA Datacom calls run on L8 along with the DB2 calls that must run on L8. Unnecessary TCB switching is avoided if the application is threadsafe.
The MAXOPENTCBS system initialization parameter controls the number of open TCBs permitted for this purpose. Therefore, set the necessary value.The factors that determine this value include the total number of USERS defined in the DBCVTPR macro for all connections in addition to the OTE TCB requirements for other applications that may be running in the same CICS region. Measure the system performance to determine the optimum number. For more information, see the IBM CICS System Definition Guide.
|
Copyright © 2015 CA Technologies.
All rights reserved.
|
|