With proper planning, you can share a terminal among several processes by assigning each a separate partition. You cannot have more than one task in progress at once at a terminal, of course, but you can interleave the component tasks of several pseudoconversational transaction sequences at a partitioned terminal.
To take a very simple example, suppose you decide to improve response time for an existing pseudoconversational data entry transaction by letting the operator enter data in two partitions (see Data entry). You could modify the application to work on two records at once, or you could simply modify it to send to the same partition from which it got its input. Then you could run it independently from each partition.
You can establish the partitions with the PARTITIONSET option in the TRANSACTION definition (all of the transactions involved, if there are several in the sequence). As noted earlier, BMS does not reload the partitions as long as each transaction has the same PARTITIONSET value. Alternatively, you could establish the partitions with a preliminary transaction (for example, one that displayed the first entry screen in both partitions) and use a PARTITIONSET value of KEEP for the data entry transactions. Whenever you share a partitioned screen, whether among like transactions or different ones, you need to ensure that one does not the destroy the partition set required by another. Also, if two different CICS® systems may share the same screen, they should name partition sets in common, so that BMS does not reload the partitions when it should not.
If the hypothetical data entry transaction sequence uses the TRANSID option on the RETURN command to specify the next transaction identifier, you would need to make another small change, because the option applies to the whole terminal, not the partition. One solution would be to place the next transaction identifier in the first field on the screen (turning on the modified data tag in the field definition) and remove the TRANSID from the RETURN. CICS would then determine the next transaction from the input, as described in How tasks are started.
[[ Contents Previous Page | Next Page Index ]]