Chapter 2 presents Program Design in a tutorial manner. Experienced CICS users may wish to omit most of this chapter. However, i t is
strongly recommended that such users still read the following topics:
• CICS/OOS/vS Subset option
• Virtual Storage Environment
• Tabular structures
• structured Programming
• Application Built-in Functions
• Program Error Recovery
CICS/VS is a transaction-oriented DB/DC system which uses the techniques of:
• Multitasking
• Quasi-reentrant programming
• Dynamic storage allocation
These techniques are described in the CICS/VS General Information Manual. The design of applicaticn programs to take advantage of them
for efficient online operation will now be discussed. In this discussion, the facilities available to the system design team are
outlined first, followed by a discussion of the various program services provided by CICS/vS. The design facilities available for use are:
• CICS/DOS/vS Subset Option
• Modular programming
• High-level languages
• Tabular structures
• structured programming
• Application functions CICS/DOS/VS SUBSET OPTION
Facilities are provided to generate a subset of CICS/DOS/VS for new CICS/DOS/vS users. It is easy to install and is fully compatible with the complete CICS/DOS/VS system. No changes need be made to application programs when the user generates a complete CICS/DOS/VS system. The subset option identifiesCICS/VS facilities which may be utilized by a CICS/VS user with limited CPU Storage. See "CICS/DOS/VS Subset Option" in Chapter 7 for additional information.
Chapter 2. CICS/VS Program Design 13
CICS/DOS/VS STARTER SYSTEM
A set of object modules, generated using the subset option of CICS/DOS.fVS, is supplied with the CICS/DOS/VS system. The starter system includes precompiled sample application programs and predefined tables, and need only be link-edited into a OOS/VS core image library before UBe.
INSTALLA~rION AND USE
The UBer can install the Fregenerated CICS/DOS/VS system as described above, and expand it as his needs dictate. CICS/VS facilities which are not part of the subset oFtion can be generated when required to support advanced CICS/VS capabilities. These can be achieved by regenera1t:.ing only those CICS/vS management modules and table options required to support the advanced capabilities.
The subset option is described in the Subset User's Guide (OOS) SH 12-540 I~.
MODULAR JROGRAMMING BATCH ENVIRONMENT
Moduliir programming techniques in a batch environment may involve the consolidation of similar progI.·am functions in one program module.
For example, the main execution code used may be incorporated in one module, '~hile exception rout ines may be in another modul e and error routines in other modules. In this way, modular programming enables sections of the program to be written by programmers at different times.
Apart from the advantage of distributing the program workload across several people, another advantage of modular programming is that it generally makes the application program logically easier to follow for someone '~ho is unfamiliar with it.
CICS/vS ONLINE ENVIRONMENT
CICS/VS is oriented around the concept of modular programming.
Transactions received from terminals are analogous to transaction cards read froIn a card reader. A transaction code defines the format and processing required for an online transaction, in the same manner as a card code defines the format and processing of a card.
This 1:ransaction code identifies the CICS/VS application program that will process the transaction. The use of such modular programming
techniquE~s is an integral part of CICS/vS and enables large programs to be broken into smaller logical modules. However, program size and CICS/vS address space availability should be balanced with the
additional overheads involved in passing control between many small modules.
When a transaction is received from a terminal, only that program code relE~vant to the processing of that transaction need be loaded into storage, if it is not already present. As modules tend to be smaller than complete programs, more application program modules may reside in a given address space than may full programs. This enables one copy of each of many different modules to be currently resident in the CICS/VS dynamic storage area. A high degree of multitasking may
thereforE~ be achieved within a limited storage size.
'4 CICS/vS System/Applica tion Design Guide
VIRTUAL STORAGE ENVIEONMENi
using the modular programming techniques discussed above, a CICS/VS application program .odule should include code which is relevant to the processing of the specific transaction.
From the system design point of view, the design team should specify the various application Frograms which are to be written to implement the particular aFplicaticn. They should also idEntify th6se application functions (and hence program coding) which willke frequently used by transactions, and those which will be infrequently used. In this way, the design team is able tc broadly specify the modular program structure of the application, and define the necessary application programs.
The various aFplicaticn programs executing concurrently in the CICS/VS partition, and the demands made by them for CICS/VS servicEs and resources, ccntribute to the total "working set" of CICS/VS. This term is used in a virtual stcrage environment to describe that part of a program which is active over a specific period of time. The CICS/VS working set is influenced hy the sizes of the various concurrently executing application prcgrams, the online transaction load and its use of various application prcgrams, and the degree of multitasking permitted by the CICS/VS master terminal operator. Techniques for varying the working set are discussed in "CICS/VS Working Set" in Chapter 7.
CICS/VS accepts applicaticn programs written in Assembler Language, American National Standard (ANS) COBOL, or PL/I OptimiziDg CODFiler for DOS/VS, OS/VS1, or OS/VS2. In addition, application programs may be compiled with the PL/I F compiler for OS/VS1 cr OS/VS2.
CICS/VS is basically table driven. Tables define the terminal network configuration, data set and data hase specifications, online transaction details, application programs, and output message
destination information. Since CICS/VS is written as a generalized program and is table-oriented, the unique requirements of an
installation can be tailored by sFecifying thcse requirements in the various CICS/VS tables. CICS/VS uses the tabular information in a direct manner to cODFlete the particular functions required. In the event of the installation characteristics changing (such as the addition of more terminals, or extra data sets for example), that change in the installation require.ents can be incorporated into the system by
modifying and reassembling the relevant tables.
The tabular structure of CICS/VS is one of the main factors which enables fast implementation and easy installation growth--two of the significant advantages of CICS/VS.
This same tabular structure concept can be extended to application programs. An example of a tabular structure application is a savings hank and mortgage lean system in the banking industry. Figure 11-7 illustrates a typical savings bank and mortgage loan system.
This application is characterized by a large nu.ber of transaction types with similar transacticn fcrmats, similar processing, and similar output formats. certainly, unique modules may be written to accept each different transacticn, process that ~nformation, and send back an output response. However, the overall IC9ic in the separate aodules is basically identical, with differences appearing only in the
Chapter 2. CICS/VS Frogram Design 15
particular input and output formats. In some caSES certain information is processed by addition (a deposit transaction amount to be added to the current balance), and in ether cases by subtraction (a withdrawal transaction amount to be subtracted frcm the current balance). It is expensive in the initial a~plicaticn programming and subsequent
maintenance to write separate programs for these various similar transactions.
In this banking application, a generalized application program may be written utilizing a tabular structure. A numter of application tables wculd be requ~red in this environment. These are illustrated in Pigure 2-1, and are listed and discussed below:
• Input format table
• Processing rEquirements table
• Output format tatle
Alternatively, the information described in these tables may be consolidated into one cCB~csite table.
On receipt of a transactien from a terminal, that transaction type (Bank Trancode) may be identified in the input fermat table. switches in this tablE specify the locaticn of information within the
transaction. This informaticn is used together with information
obtained from the precessing requirements table which is also accessed based on the transaction type (Bank Trancode). Fer that transaction type, the processing require.ents tatle entry may indicate certain fields of the transactien are to be edited based u~on specific editing criteria, and fiElds are tc be added to or subtracted froa specific applicaticn counters.
Based on the particular transaction type, the relevant entry in the output format tatle may specify the Exact locatien in the eutput message into which certain fields are to be inserted. Besponses may then be sent back to the terminal to update the custome~'s bank passbook based upon the particular input transactien entered.
Use of tabular structurES results in less programming effort. Only one generalized application ~rogram is written, determining the editing and processing required cf transactiens by means of various switches in the relevant tables.
However, the power of this pregram design approach beco.es more apparent when it is necessarl to mcdify the application req~irements.
Typically such application modification may require considerable recoding and testing if a tabular structure is not used. In this
environment, the relevant tatle Entry may be quickly and easily changed to reflect a changed input fermat, changed processing requirements, or a changed output format. In many cases, no modification of the
-generalized application Frogram is rEquired.
The net effect is greater resFonsiveness to the application needs of user departments, as well as the needs of the ccmpany's customers.
The IBft 3600 Finance Communication System, a banking system, consists of an IBft 3601 programmatle controller and several terminals. Some of the functions perfcrmed ty the previeusly descrited tables may be executed in the 3601 contrcller. For example, the terminal input
message Day be cenverted to a standard format input message by the 3601 controller for transmission to CICS/VS with precessing requirement switches inccrporatEd in the input message. Similarly, a standard format output response may be transmitted by CICS/VS back to the
16 CICS/VS System/Application DeSign Guide
controller, which performs any uniquE foraatting ~Equi~ed by the in processing re·Quirements table.
.---.-__ ... > 5. Process input message based on pro·
Specifications > 7. Prepare output message based on
.---.---,.v"" output table specs. L-...L. _ _ -"'-> ~~dit Il Date Illcode I;] Amount Irlll Bal·l no Is 18'1 181 161 91 arlce
Figure 2-1.
8. Transmit output message to teller terminal.
Tabular Program structure in Banking
Teller Terminal
Passbook
Using this aPFroach, the tabular structure concept described in Figu~e 2-1 can also te aFplied tc the application programming performed in the 3601. The functicns cutlined in steps 1 through 4 and 6 through 8 in Figure 2-1 are then executed by the 3601 and only step 5 is
executed by the eIeS/VS apFlication program. See "Virtual Telecommunications Access !ethod" in Chapter 3 fer additional information regarding 3600/CICS/VS oFeration.
structured programming is a modular prog~amming technique which has been developed tc Fermit easier integration cf modules into a working