Processing dialogs with users

An application may require several interactions (input and output) with the user. CICS® provides two basic techniques for program design for use in such situations. They are conversational processing and pseudo-conversational processing.

Conversational processing

With conversational processing, the transaction continues to run as a task across all terminal interactions, including the time it takes for the user to read output and enter input.

While it runs, the task retains resources that may be needed by other tasks. For example:
  • The task occupies storage, and locks database records, for a considerable period of time. Also, in the event of a failure and subsequent backout, all the updates to files and databases made up to the moment of failure have to be backed out (unless the transaction has been subdivided into units of work).
  • If the transaction uses DL/I, and the number of scheduled PSBs reaches the maximum allowed, tasks needing to schedule further PSBs have to wait.

Conversational processing is not generally favored, but may be required where several file or database updates made by several interactions with the user must be related to each other—that is, they must all be committed together, or all backed out together, to maintain data integrity.

Pseudoconversational processing

In pseudoconversational processing, successive terminal interactions with the user are processed as separate tasks, usually consisting of one unit of work each.

This approach can result in a requirement to communicate between tasks or transactions (see Mechanisms for passing data between transactions) and the application programming can be more complex than for conversational processing.

However, at the end of each task, the updates are committed, and the resources associated with the task are released for use by other tasks. For this reason, pseudoconversational transactions are generally preferred to the conversational type.

When several terminal interactions with the user are related to each other, data for updates must accumulate on a recoverable resource and then be applied to the database in a single task; for example, in the last interaction of a conversation. In the event of a failure, emergency restart or dynamic transaction backout would back out only the updates made during that individual step; the application is responsible for restarting at the appropriate point in the conversation, which might involve recreating a screen format.

However, other tasks might try to update the database between the time when update information is accepted and the time when it is applied to the database. Design your application to ensure that no other application can update the database at a time when it would corrupt the updating by your own application.