In addition to the screen design, we need to take into account some features that are common to transaction processing systems. The main one here is to understand the difference between conversational and pseudo-conversational transactions.
Now that we’ve established guidelines for design, let’s return to the issue of defining the transactions that make up the sample application. Earlier we described the processing required for the various transaction types that the user sees: add, modify, display, and so on. If we were to define our CICS transactions along these functional lines, we can foresee several problems:
There is much repetitive processing, which suggests that we should at least use common programs for some of the transactions, or combine transactions.
Every transaction involves a wait for the user to enter data, and the update transactions contain two such waits. This means that these transactions will be running for a relatively long time, which is a violation of the guideline to keep program duration short.
The modify and delete transactions will be holding on to a one-user-at-a-time resource during one of the waits, contradicting the guideline to minimize the duration of transactions that use such resources.
Because CICS places no restriction on user input, CICS allows the systems programmer to place a limit on the number of concurrent transactions in each CICS address space internally ...