Sequential file facilities are provided because of the need to save data from the execution of one transaction, passing it on to another that occurs later. There are two instances of this requirement in the sample application:
The first resulted from the decision to use pseudo-conversational transactions; this arises from the need to save data from one interaction with the terminal user to the next, even though no task exists for that terminal for most of the intervening time. For this you need something to save state, for example, a scratchpad facility.
The second requirement came from the need to log the changes to the account file. Here you require some sort of queuing facility: a way to add items to a list (one in each update transaction) and read them later (in the log-print transaction).
There are several different scratchpad areas in CICS that you can use to transfer and save data, within or between transactions. See Queuing Facilities: Temporary Storage and Transient Data, later in this chapter. The CICS Application Programming Reference gives you a complete list of the commands you can use to get access to these areas:
This is an area used for passing data between both programs within a transaction and transactions at a given terminal. It’s described later in connection with the program control commands in Controlling Programs, later in this chapter. The COMMAREA is the recommended scratchpad area.
The COMMAREA offers an alternative solution to the double updating problem. For example, it would be perfectly feasible for the NACT01 program to pass the contents of the account file record over to the NACT02 program in the COMMAREA. The NACT02 program could then re-retrieve the account record for update and compare it with the version passed in COMMAREA. Any difference would show that some other task had changed the account record.
Although this solution may be easier to code, it isn’t as good from the user’s point of view. You see, with this scheme, you don’t find out about any conflict over the record until you’re ready to update it. Unfortunately, that means you then have to tell one user that his or her update cannot be made, but you can’t tell them until they’ve keyed in all the changed data.
Any transaction can access the CWA, and since there’s only one CWA for each CICS address space, the whole system, the format and use of this area must be agreed upon by all transactions in all applications that use it. Avoid this method; the affinities created cause major problems if groups of transactions have to be split up sometime in the future.
The TWA exists only for the duration of a transaction. Consequently, you can use it to pass data among programs executed in the same transaction (like COMMAREA), but not between transactions (unlike COMMAREA). The TWA isn’t commonly used now (and probably shouldn’t be) as a scratchpad area in modern CICS programs.
An affinity is created when a resource that contains state data of a pseudo-conversation is tied to one instance of a CICS. If the KanDoIT company takes over other companies, they will want to run multiple machines with many CICS regions/address spaces and if the state of one credit card is on one machine and the data on another, the application will not scale up because the transaction may (will) have an affinity to the first machine. The first place that this normally occurs is in the use of a resource that is tied to one CICS region, for example, a CWA. Secondly, it is using temporary storage with a key that uses a resource name that is unique to that CICS, for example, a termid. This is a highly complex subject; see the CICS Application Programming Guide for more information.