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.2.2 Processes<br />
3.2.1.3 Application <strong>Server</strong>s<br />
An application server is a multithreaded <strong>CICS</strong> process that provides a complete<br />
environment for running a <strong>CICS</strong> transaction. An application server obtains work<br />
in one of two ways: (1) the transaction scheduler signals that there are<br />
transactions to be processed, or (2) at the end of processing its current<br />
transaction it looks to see whether there is any outstanding work on the work<br />
queue.<br />
If a transaction is conversational, it is processed by one application server,<br />
which is used by the transaction for the life of the transaction. Thus, if a<br />
transaction were waiting for terminal input and the user went for coffee, it would<br />
hold the application server, then the application server, making it unavailable to<br />
process other work. Conversational programming is not a good programming<br />
model to use. See 3.4.5, “Application Design” on page 41.<br />
If the transaction is pseudo conversational, each transaction in turn can be<br />
processed on a different application server. When you configure <strong>CICS</strong>, you<br />
specify the minimum and maximum number of application servers for the region.<br />
<strong>The</strong> application manager always ensures that the minimum number is present.<br />
Application servers can be created and destroyed up to the maximum number<br />
defined, depending on the workload of the <strong>CICS</strong> system. All application servers<br />
have to be allocated on the same machine. <strong>The</strong> machine does not have to be<br />
the same machine as the client process, however. Application servers<br />
communicate <strong>with</strong> each other through signals and shared memory and use RPCs<br />
to communicate <strong>with</strong> other components of the system.<br />
3.2.1.4 <strong>CICS</strong> Queue and File Management<br />
<strong>CICS</strong> queue and file management is the function <strong>with</strong>in <strong>CICS</strong> that manages the<br />
physical files, auxiliary temporary storage queues, intrapartition transient data<br />
queues, and locally managed, queued, automatic initiation requests. With the<br />
introduction of <strong>CICS</strong> for AIX V2.1, it is now possible to use a DB2 Version 2<br />
database instead of an Encina SFS for queue and file management. <strong>The</strong> same<br />
API is used for both the Encina SFS and DB2 cases.<br />
3.2.1.5 PPC Gateway <strong>Server</strong><br />
A <strong>CICS</strong> for AIX region can use one or more PPC Gateway servers to access SNA<br />
hosts. As <strong>with</strong> Encina SFS, an application server becomes a client of the PPC<br />
Gateway.<br />
In this section we take a look at the actual <strong>CICS</strong> processes under AIX. Table 2<br />
lists the <strong>CICS</strong> processes and briefly describes their functions.<br />
Table 2 (Page 1 of 2). <strong>CICS</strong> for AIX Process Names and Functions<br />
Component Name Function<br />
cics Main <strong>The</strong> first process invoked<br />
cicsas Application server<br />
30 <strong>CICS</strong> for AIX as the <strong>Transaction</strong> <strong>Server</strong><br />
<strong>The</strong> process on which an<br />
application runs. Typically<br />
there are a number of these<br />
processes.