How CECI runs

There are several things you should know about how the interpreter works, in order to use it properly. These include:

CECI sessions

The interpreter runs as a transaction, using programs supplied by CICS®. It is conversational, which means that everything you do between the start of a session (entering CECI) and the end (PF3) is a single logical unit of work in a single task. This means that locks and enqueues produced by commands you execute remain for the duration of your session. If you read a record for update from a recoverable file, for example, that record is not available to any other task until you end CECI.

Abends

CECI executes all commands with the NOHANDLE option, so that execution errors do not ordinarily cause abends.

CECI also issues a HANDLE ABEND command at the beginning of the session, so that it does not lose control even if an abend occurs. Consequently, when you get one, CECI handles it and there is no resource backout. If you are doing a series of related updates to protected resources, you need to be sure that you do not do some of them and then find you cannot complete the others. If you find yourself in this situation, you can execute a SYNCPOINT ROLLBACK command or an ABEND command with the CANCEL option to remove the effects of your earlier commands on recoverable resources.

Exception conditions

For some commands, CECI may return exception conditions even when all specified options are correct. This occurs because, on some commands, CECI uses options that you do not specify explicitly. For example, the ASSIGN command always returns the exception condition INVREQ under CECI. Even though it may return the information you requested correctly, it will have attempted to get information from other options, some of which are invalid.

Program control commands

Because the interpreter is itself an application program, the interpretation of some program control commands may produce different results from an application program executing those commands. For example, ABEND command is intercepted, as noted above, unless you use the CANCEL option.

If you execute a LINK command, the target program executes, but in the environment of the interpreter, which may not be the one expected. In particular, if you modify a user display during a linked-to program, the interpreter will not be aware of the changes.

Similarly, if you interpret an XCTL command, CECI passes control to the named program and never gets control back, so that the CECI session is ended.

Terminal sharing

When the command being interpreted is one that uses the same screen as the interpreter, the command interpreter manages the sharing of the screen between the interpreter display and the user display.

The user display is restored:

Thus, when a SEND command is followed by a RECEIVE command, the display sent by the SEND command appears twice, once when the SEND command is processed, and again when the RECEIVE command is processed. It is not necessary to respond to the SEND command, but, if a response is made, the interpreter stores it and redisplays it when the screen is restored for the RECEIVE command.

When the interpreter restores the user display, it does not sound the alarm or affect the keyboard in the same way as when a SEND command is processed. This is similar to EDF (see Using EDF in single-screen mode for more information).

Start of change

Shared storage: ENQ commands without LENGTH option

Normally, when you use the EXEC CICS ENQ command without the LENGTH option, the effect is to specify as the resource a data area with a specific location (address) in storage. Multiple tasks can enqueue on this resource and must refer to the same location in storage. CECI is not able to emulate this behavior, because it uses its own working storage, rather than shared storage.

If you execute an ENQ command in CECI without the LENGTH option, CICS enqueues on an address within storage owned by the CECI task. Other tasks, whether CECI or not, cannot enqueue on this same storage. CECI does not provide support for using shared storage for its variables.

It is not possible to emulate the desired behavior by specifying the storage address as the RESOURCE option, and adding the LENGTH option, when the ENQ command is executed in a CECI task, then specifying the same storage address without the LENGTH option in another CECI or non-CECI task. When the LENGTH option is specified, CICS enqueues on the value of the resource rather than on its location. CICS therefore regards the enqueues with and without the LENGTH option as different enqueues, and the tasks are not serialized as intended.

When the LENGTH option is specified for the same ENQ command issued from multiple tasks, the enqueue works as expected, because the location of the data area (whether in storage owned by CECI or in other storage) does not matter when the LENGTH option is specified.

End of change [[ Contents Previous Page | Next Page Index ]]