Programming languages like COBOL, PL/I and assembler were primarily not designed for on-line use. All the above languages have their roots in batch processing and as a result none of them is ideally suited for CICS. So batch programming conventions and standards, when used to on-line situation may not produce the same results, because it is a totally different ball game. Some of the guidelines discussed in this section should be only used after considering all the implications. Because in the quest for improving performance, the maintainability and reusability of one component the others may suffer. So before taking a decision all the alternatives must be considered.

For example, if we consider only the performance aspect, the applications written using non-structured techniques will generally be more efficient than structured programs. This is because the flow of a structured program will tend to deviate more often from a sequential flow and increase the probability of paging. But this benefit in performance must be weighed against the advantages and savings in application development and program maintainability that are to be had by employing structured techniques.

So when structured techniques are used, try to make the subroutine more substantial than it would be if the program were written for batch execution. Attempt to place the subroutines in the order of probability of usage, with those most often used closest to the main line to increase the probability of occupying the same virtual storage page. Try to avoid having subroutines that branch to other subroutines. Strictly from a performance standpoint, CICS programs should follow as sequential a path as possible. Abnormal or error processing should be in either separate programs or in in-line subroutines. If you are determined to write structured code, be a little less rigid in your approach. Because for creating your own error handling you will need complex routines, which will be subject to considerable changes in subsequent releases of CICS and might have to be thrown away.

Regarding the program size there are no hard and fast rules and the functionality of an application should be the limiting factor on size. Ideally, one should aim for a relationship of one program to one terminal interaction. It is generally considered a better performance option to have bigger programs and increased storage demands than to incur the overheads involved with more frequent XCTLs and LINKs. If your CICS system is dedicated to one application, it will be of much less importance than if you are running a large variety of different applications. With just one application running, you could have a program whose size would be considered absurdly high in a different environment. But if your system contains a large number of different applications, it would be wise to break them down into several quite small programs.

When transferring control from one program to another, if you have a choice, it is far better to use XCTL than LINK. An XCTL only uses about a half of the CPU time of a LINK. In addition, the dynamic work area of any program that issues a LINK command remains in the storage while it is freed in the case of XCTL Another overhead incurred by LINKed programs is the requirement for a Register Save Area (RSA) to be generated. Therefore, if there is no need to return control to the original program, always use XCTL. An alternative to this is to issue a CALL statement. This uses no CICS services and is the most efficient way of transferring control between programs. The main disadvantage of this method is that, the CALLed program must be linked into the program that calls it. This means that the program must be re-linked if the subroutine changes.

If you are writing command level programs, it is much better from a performance standpoint, to code constants or literals within your EXEC CICS commands rather than coding variables. Greater efficiency is gained by having the data closer to where it is going to be used and thereby reducing the likelihood o*' paging. So if the constants and literals are coded as variables, and if many users are simultaneously executing the same transaction, the overhead can be quite considerable, because for each task there will be a copy o*' the working storage. But here also, there is a trade-off of more efficient programs for more readable and maintainable programs. The likelihood of paging will be greatly reduced, if you wait until you are about to use an area of data before initializing it rather than doing it at the beginning of the program.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

IBM Mainframe Topics