Addressing OLTP Solutions with CICS: The Transaction Server ... - Ibm

More documents

Recommendations

Info

152 CICS for AIX as the Transaction Server 10.7.1.3 Choosing between Pseudo Conversational and Conversational Design There are four major issues to consider in choosing between pseudo conversational and conversational programming. The first of these is the effect of the transaction on contention resources, such as storage and processor usage. Storage is required for control blocks, data areas, and programs that make up a transaction, and the processor is required to start, process, and terminate tasks. Conversational programs have a very high impact on storage, because they last so long, relative to the sum of the transactions that would comprise an equivalent pseudo conversational sequence. However, there is less processor overhead, because only one transaction is initiated instead of one for every input. The second issue is the effect on the use of exclusive resources such as records in recoverable files, recoverable transient data queues, and enqueue items. Again, a conversational transaction holds on to these resources for a very much longer time than the corresponding sequence of nonconversational transactions. From this point of view, pseudo conversational transactions are better for quick responses, but recovery and integrity implications may force you to use conversational transactions. CICS ensures that changes to recoverable resources (such as files, external database, transient data, and temporary storage) made by an LUW will be made completely or not at all. An LUW is equivalent to a transaction, unless that transaction issues EXEC CICS SYNCPOINT commands, in which case, the EXEC CICS SYNCPOINT marks the end of one LUW and the start of the next. When a transaction makes a change to such a resource, CICS makes that resource unavailable to any other transaction that wants to change it until the original transaction has completed. In the case of a conversational transaction, the resources in question may be unavailable to other terminals for relatively long periods. For example, if one user tries to update a particular record in a recoverable file, and another user tries to do so before the first one finishes, the second user′s transaction is suspended. This has advantages and disadvantages. You would not want the second user to begin updating the record while the first user is changing it, because one of them will be working from what is about to become an obsolete version of the record, and these changes will erase the other user′s changes. However, you also do not want the second user to experience the long, unexplained wait that occurs when that transaction attempts to read for update the record that is being changed. If you use pseudo conversational transactions, the resources are only very briefly unavailable (that is, during the short component transactions). However, unless all recoverable resources can be updated in just one of these transactions, recovery is impossible because LUWs cannot extend across transactions. So, if you cannot isolate updates to recoverable resources in this way, you must use conversational transactions. The above example poses a further problem for pseudo conversational transactions. Although you could confine all updating to the final transaction of the sequence, there is nothing to prevent a second user from beginning an update transaction against the same record while the first user is still entering changes. Therefore you need additional application logic to ensure integrity. You can use some form of enqueuing, or you can have the transaction compare the original version of the record with the current version before actually applying the update.
10.7.2 Data Operations The third issue concerns the relative performance profiles of the two transaction types. Although it is better for overall throughput to design your transactions to be pseudo conversational, conversational transactions use less processing power. The reasons are: • It may be necessary for an application server to be created to run the transaction. This involves a large amount of processing because CICS must create an environment for the transaction that is persistent across failures. You should try to avoid application server creation by setting the value of the RD stanza attribute Minservers to a value appropriate for your expected workload. • When each pseudo conversational transaction starts, the server has to be initialized for it. This initialization may include having to load the CICS program for it if it is not already loaded in shared memory. The fourth issue is the delicate balance of transaction throughput and response times. In a heavily loaded system, once a conversational transaction is running, it will give more predictable response times than a pseudo conversational one. When the user presses an attention identifier (AID) key in the latter case, no application server may be available to process it, and the limit on the number of servers may have been reached. Conversely there should be better transaction throughput in the pseudo conversational case. There are factors other than performance overhead to consider when choosing between pseudo conversational and conversational design for CICS applications, as described below. The method you choose can affect how you write the application programs. You may need extra CICS requests for pseudo conversations, particularly if you are updating recoverable files. Once you have done this, however, operational control (performance monitoring, capacity planning, recovery, system shutdown, and distributing system messages) may be much easier. 10.7.1.4 CICS Program Design Having decided whether your transaction is best written to be conversational or pseudo conversational, your next task is to design it. Most organizations mandate a modular approach of some sort to this design task, and a primary consideration here is your choice of CICS on Open Systems, operating system, and programming language facilities. The CICS file services API is designed to allow access to data files whose size can range from small to large, in a variety of file organizations and access methods, and which are usually of a more permanent nature. The transient data and temporary storage service API commands allow access to sequential and random access queues. The journal services API allows you to write journal records for audit trails or other purposes for offline processing. In addition, CICS allows access to relational databases that provide a programmable interface through EXEC SQL commands in one of the supported CICS programming languages. Chapter 10. Application Design Considerations 153
Page 1:
Addressing OLTP Solutions with CICS
Page 4 and 5:
Take Note! Before using this inform
Page 6 and 7:
iv CICS for AIX as the Transaction
Page 8 and 9:
9.4 Security Issues on the Internet
Page 10 and 11:
viii CICS for AIX as the Transactio
Page 12 and 13:
x CICS for AIX as the Transaction S
Page 14 and 15:
xii CICS for AIX as the Transaction
Page 16 and 17:
The Team That Wrote This Redbook xi
Page 18 and 19:
xvi CICS for AIX as the Transaction
Page 20 and 21:
2 CICS for AIX as the Transaction S
Page 22 and 23:
1.2 Complex OLTP Business Environme
Page 24 and 25:
Figure 2. OLTP Complex for XYZ Insu
Page 26 and 27:
By using common application program
Page 28 and 29:
1.5 OLTP Market 10 CICS for AIX as
Page 30 and 31:
Figure 5. OLTP Market Segmentation
Page 32 and 33:
14 CICS for AIX as the Transaction
Page 34 and 35:
2.1 IBM Software Servers 2.1.1 Lotu
Page 36 and 37:
2.2.1 CICS Clients V1.1.0 A Transac
Page 38 and 39:
2.2.4 CICS Internet Gateway for AIX
Page 40 and 41:
3.1 Services CICS for AIX is a very
Page 42 and 43:
3.1.2 CICS API 24 CICS for AIX as t
Page 44 and 45:
3.1.3.1 Terminal Users and CICS Reg
Page 46 and 47:
3.2 Implementation 3.2.1 Components
Page 48 and 49:
3.2.2 Processes 3.2.1.3 Application
Page 50 and 51:
3.3.1 DCE RPC 3.3.2 TCP/IP 32 CICS
Page 52 and 53:
Figure 9. Interconnection Using Enc
Page 54 and 55:
connect to a PPC Gateway server mac
Page 56 and 57:
Figure 12. Interconnection Using TC
Page 58 and 59:
3.4.3 Configuration 3.4.4 Managing
Page 60 and 61:
3.4.6 Intersystem Communication CIC
Page 62 and 63:
3.4.8 Data Location 44 CICS for AIX
Page 64 and 65:
3.4.11 Operations plan to cope with
Page 66 and 67:
3.5 Summary 48 CICS for AIX as the
Page 68 and 69:
Figure 13. Application Server Model
Page 70 and 71:
4.2.1 CICS External Call Interface
Page 72 and 73:
By means of mapping files, you can
Page 74 and 75:
4.3 Versions 56 CICS for AIX as the
Page 76 and 77:
4.4 Sample Network Configurations 4
Page 78 and 79:
4.5.1 CICS Client for OS/2 60 CICS
Page 80 and 81:
4.5.2 CICS Client for DOS 62 CICS f
Page 82 and 83:
4.5.5 CICS Client for AIX CICS Clie
Page 84 and 85:
Page 86 and 87:
4.6 Summary 68 CICS for AIX as the
Page 88 and 89:
5.1.1 DCE Threads 5.1.2 Remote Proc
Page 90 and 91:
The GDS is based on the CCITT X.500
Page 92 and 93:
egion or server it is looking for.
Page 94 and 95:
Page 96 and 97:
6.1.2 Encina Toolkit Server Core 6.
Page 98 and 99:
Page 100 and 101:
is also necessary to use native AIX
Page 102 and 103:
Page 104 and 105:
7.1 X/Open XA Interface 7.1.1 X/Ope
Page 106 and 107:
Page 108 and 109:
Communication between the transacti
Page 110 and 111:
Page 112 and 113:
7.2.2 Single-Phase and Two-Phase co
Page 114 and 115:
Page 116 and 117:
Figure 28. Switching Access among D
Page 118 and 119:
Page 120 and 121: Figure 30. CICS Access to Remote DB
Page 122 and 123: emote DRDA database. Information ab
Page 124 and 125: As the COMMAREA has an allowable ma
Page 126 and 127: 7.5 Summary 108 CICS for AIX as the
Page 128 and 129: 110 CICS for AIX as the Transaction
Page 130 and 131: 8.2 Workload Management 112 CICS fo
Page 134 and 135: 8.4.2 System Management Application
Page 136 and 137: Figure 36. The CICS SM GUI 8.4.6 Di
Page 138 and 139: Figure 37. CICS SM Component Distri
Page 140 and 141: Figure 38. Combining Resources 122
Page 142 and 143: 8.5.2 The Reference System 124 CICS
Page 146 and 147: 8.6 Planning Considerations for CIC
Page 152 and 153: 9.1 Some Terminology 9.2 Services 1
Page 154 and 155: Figure 41. CICS Internet Gateway fo
Page 156 and 157: 9.3.3 Data Integrity The Web was or
Page 158 and 159: 9.3.5 High Availability The drawbac
Page 160 and 161: or employee records, eavesdropping
Page 164 and 165: • Type, size, and quantity of rec
Page 166 and 167: 10.3.3 Writing ECI and EPI Applicat
Page 168 and 169: The ANIMATOR debugging tool enables
Page 172 and 173: 10.8 Summary 154 CICS for AIX as th
Page 176 and 177: 11.1 The Big Picture 158 CICS for A
Page 178 and 179: 11.2 User Access 160 CICS for AIX a
Page 180 and 181: Figure 44. Access to Various DB2 Da
Page 184 and 185: takes place over TCP/IP or SNA comm
Page 186 and 187: provide greater protection in the u
Page 194 and 195: How Customers Can Get ITSO Redbooks
Page 198 and 199: design. The process of composing a
Page 200 and 201: A year later ISC gave SQL formal in
Page 204 and 205: designing efficient applications 15
Page 206: IBML ® Printed in U.S.A. SG24-4752
show all

Addressing OLTP Solutions with CICS: The Transaction Server ... - Ibm

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?