Performance and resource use should be as much a design consideration as program function when developing a CICS application. CICS transactions must share all of the resources within a region (ie: memory, CPU, etc..). The CICS regions at CNS are shared by many different applications belonging to the various CICS Development Groups. In order to encourage everyone developing applications for CICS to be "good CICS citizens" and not waste the available resources needed by others, a set of resource usage guidelines for applications was established in an attempt to provide optimum performance for CICS regions at CNS. Almost any well-designed CICS application should be able to conform to these guidelines, if resource usage is considered during the design phase. The CICS systems programmer routinely checks the available statistics prior to installing any new or changed application into production. Applications which greatly exceed these guidelines will likely be delayed or disapproved for installation into production.

The most crucial elements of a transaction are the disk I/O, terminal I/O, virtual storage used, and CPU utilization. These are the factors used in calculating the charge for a CICS transaction, and are the resource consumption numbers looked at by the CICS systems programmer when evaluating the performance of an application about to be installed into production. This means that by following the guidelines, not only will you have a well performing application, but it will also be cheaper to run (for whoever is paying the bill).

The resource usage guidelines for CICS applications at CNS are as follows:

• Maximum of 200 milliseconds of CPU per transaction (without InterTest).
• Maximum of 300 file requests per transaction.
• Maximum of 6144 bytes of terminal I/O per transaction.
• Maximum of 100 K-bytes of main storage used per transaction (not including program storage).
• Maximum program size of 64 K-bytes per program.

In addition to controlling resource consumption, CNS has a couple of other restrictions which are placed on programs being developed for use in CICS.

• Conversational programs will not be accepted.
• All programs must be fully re-entrant.

Conversational vs Pseudo-conversational programs

A conversational program is one that writes to a terminal and then goes into a terminal-control wait until the operator enters data on the screen and presses ENTER or one of the other AID keys, causing data to be transmitted to the CICS program. An alternative to the conversational progamming technique is called pseudo-conversational programming, which looks the same to the end user as a program which is coded conversationally. A pseudo-conversational task, however, terminates itself while waiting for the operator to enter data. This allows the CICS resources owned by that task to be freed up. A conversational task is holding critical CICS resources while it waits for the terminal operator.

Application programmers often ask (when notified that their program looks conversational according to CICS statistics), "What should I look for to correct the situation?" There are several possibilities. Explicit waits are caused by the use of the EXEC CICS CONVERSE command. This should NEVER be used. An EXEC CICS SEND / EXEC CICS RECEIVE sequence within a program also generates an explicit terminal-control wait. As a general rule, a RETURN TO CICS should always be done immediately after a SEND to the terminal. An implied wait can also be caused if there are two occurences of EXEC CICS RECEIVE commands in a single task. The most common way that this happens is when an XCTL or LINK command has transferred control from one program to another program and the invoked code contains an EXEC CICS RECEIVE command. If an earlier program in the CICS task has already performed an EXEC CICS RECEIVE to map in data from the terminal, the second one will constitute a "conversational" wait. The symptoms at the terminal are usually a "hung" condition that goes away when the terminal operator finally hits the RESET key and then ENTER. The use of CEDF during the testing phase is the best way to detect this situation.

Re-entrant programs

Re-entrant programs are programs which DO NOT modify themselves or store data within themselves. Re-entrancy allows CICS to keep just one copy of a program in real storage no matter how many people are using it. Data which must be saved should be placed in dynamic storage, such as a commarea or temporary storage queue. An additional benefit to coding re-entrant programs is that CICS loads them into READ ONLY memory, thus protecting the program from being overlaid by some other errant CICS program. Re-entrancy is forced for all CICS application programs at CNS, since all programs are linked with the REENTRANT option, which tells CICS to load them into READ ONLY storage. Then if the program tries to write into itself, an ASRA 0C4 ABEND will be generated.

Use of MVS Services

One difference between CICS and batch programming is that CICS provides interfaces which should be used in lieu of the equivalent MVS services. The CICS services should always be used. The use of MVS services which invoke SVCs is not permitted in CICS programs at CNS. This includes, but is not limited to, MVS Getmain and COBOL "MOVE CURRENT DATE" and "ACCEPT FROM DATE" functions. Programs which are being monitored by CA-InterTest will abend (or breakpoint) when use of an SVC is detected. In addition, the COBOL programs should be compiled using the "WORD(CICS)" compiler option, which will disallow the use of COBOL verbs which invoke MVS services. The use of CA-InterTest and the WORD(CICS) COBOL option should be sufficient to insure that applications do not inadvertently introduce MVS SVCs into your code.