Addressing OLTP Solutions with CICS: The Transaction Server ... - Ibm
Addressing OLTP Solutions with CICS: The Transaction Server ... - Ibm
Addressing OLTP Solutions with CICS: The Transaction Server ... - Ibm
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
3.4.8 Data Location<br />
44 <strong>CICS</strong> for AIX as the <strong>Transaction</strong> <strong>Server</strong><br />
are not always clearly defined. It is a case of looking at all of the options and<br />
choosing the best one for your environment.<br />
3.4.7.2 <strong>Transaction</strong> Routing<br />
<strong>Transaction</strong> routing does not have several alternatives like function shipping has.<br />
So the case for using this method is more straightforward. If you need access to<br />
a remote transaction, use transaction routing. With this facility, you do not have<br />
to implement the application and data in two places or access two systems.<br />
3.4.7.3 Asynchronous Processing<br />
With asynchronous processing the remotely started transaction does not affect<br />
the application that started it. This facility is useful when it is necessary to start<br />
a transaction <strong>with</strong>out delaying the local transaction at all.<br />
3.4.7.4 DPL<br />
DPL is best used where there is a large amount of data to be manipulated on a<br />
remote system. <strong>The</strong> DPL program has local access to the data, performs the<br />
necessary manipulation, and returns the result. This process can be<br />
considerably more efficient than having to function ship each item of data.<br />
3.4.7.5 DTP<br />
DTP is the most flexible intercommuncation facility. <strong>The</strong> programs can send and<br />
receive as much data to each other as required. It is the most complex to set<br />
up, however, as the originating program is responsible for setting up the<br />
communications <strong>with</strong> the remote system, sending and receiving the data, and<br />
closing the communications down when it is finished.<br />
As a general rule, no matter where the data is located for an application, it is<br />
wise to keep the number of recoverable resources to a minimum. This reduces<br />
the amount of logging that has to be done to protect the updates to the<br />
recoverable resources. Reducing the number of recoverable resources may also<br />
reduce the number of participants involved in any syncpoint processing, thereby<br />
improving performance.<br />
Application data can be held in Encina SFS, in an RDBMS, in <strong>CICS</strong> queues, or in<br />
a remote system. <strong>The</strong>re are significant performance considerations for each of<br />
these methods. <strong>The</strong> choice is not always a free one and may to a large extent<br />
depend on where data is currently held. If is not feasible to move data from one<br />
platform to another, the data has to be accessed remotely.<br />
Encina SFS: Data held <strong>with</strong>in an Encina SFS has often been migrated from an<br />
IBM mainframe environment where the data was held in VSAM. <strong>The</strong> Encina SFS<br />
can be located on the same system as that of the <strong>CICS</strong> for AIX region. <strong>The</strong><br />
advantage of doing this is that the fast local transport (FLT) method can be used<br />
between the <strong>CICS</strong> application server and the Encina SFS. This method provides<br />
a performance improvement over the use of the DCE RPC.<br />
If the Encina SFS and <strong>CICS</strong> systems are distributed, it may be possible to use<br />
two smaller machines to provide the necessary processing power. As long as<br />
the Encina SFS and the <strong>CICS</strong> region are <strong>with</strong>in the same DCE cell, there is no<br />
problem in distributing the components.<br />
Note: Distributing the components may impact the performance of accesses to<br />
<strong>CICS</strong> files or queues held <strong>with</strong>in the Encina SFS.