More and more functions within CICS are exploiting the OTE architecture. The latest at CICS TS 3.1 is OPENAPI.
We do not intended to provide a whole paper on this topic at this time since we see that people like Russ Evans are hard at work locating best practices examples for threadsafe applications (see CICS-L archives from fourth quarter of 2005.) Russ continues to provide leadership in the CICS world for OTE and threadsafe architecting.
What we will do is simply provide you some pointers to the latest papers and Redbooks you will need to familiarize yourself with over the coming year.
What is meant when it is said an application is threadsafe? A threadsafe program is defined as a program that uses appropriate serialization techniques, such as compare and swap, or enqueue, when accessing any shared resource(s). It must be capable of running concurrently on multiple TCBs, and must not rely on quasi-reentrancy to serialize access to shared resources and storage.
For a CICS DB2 application to meet these conditions and threadsafe, the application must incorporate threadsafe application logic (which means, the native language code in between the EXEC CICS commands must be threadsafe and the EXEC CICS APIs must be threadsafe), and be defined to CICS as threadsafe. Remember that when you define an application to CICS as threadsafe, you are simply making a contract with CICS that you guarantee the application is threadsafe. CICS does nothing to enforce threadsafe operations.
There are four main drivers for migrating to threadsafe applications and exploiting OTE:
1. |
|
|
Improve performance
|
2. |
|
|
Reduce cost
|
3.
4. |
|
|
Future positioning
|
Customers who should benefit most from migrating to a threadsafe environment are those who experience poor response times for any of the following reasons:
1. The CICS QR TCB is CPU constrained.
2. |
Application tasks are waiting excessively for the QR TCB
|
3. |
The CICS region in general is CPU constrained. |
CICS users who wish to exploit current z/OS APIs might do
so now under OTE.
For many customers, the financial cost incurred running their applications is related to the amount of CPU consumed. Under these circumstances, the CPU savings gained by migrating appropriate applications to a threadsafe environment can equate to a financial saving.
Full
implementation OTE in CICS will be implemented in three stages, over several releases of
CICS Transaction Server.
|
Stage 1 - OTE function introduced: Delivered in CICS TS 1.3 |
|
Stage 2 - TRUEs can exploit OTE: Delivered in CICS TS 2.2 |
|
Stage 3 - Full application use of open TCBs: Delivered in CICS TS 3.1 |
Applications that can be defined as threadsafe today will be able to exploit future CICS enhancements with minimum migration effort. It is a recommendation from IBM that all new application programs are to be written to threadsafe standards.
The most comprehensive document available on achieving threadsafe applications is the IBM Redbook, Threadsafe Considerations for CICS. This book was authored at CICS TS V2 level and will need some updating for CICS TS V3 but it gives an excellent starting point for achieving threadsafe applications. Click here to go to the document.
The next two major pieces of work available on threadsafe and CICS is the SHARE papers presented by J. Tilling at the Spring Session 2005 in Anaheim.
To download “What Does It Mean to be Threadsafe in CICS TS?”, click here.
To download “CICS Open Transaction Environment (OTE)”, click here.