CICS Notes

Forward Recovery restores a corrupted file by applying copies of file modifications from the system journal to the file’s backup taken at system start-up time.  This is often called Journal Recovery and the file’s FCT entry must specify journalling.

Backward Recovery restores the coordination of multiple files that were being updated by a single interrupted in-flight task.  CICS Restart/Recovery handles this in the event of a system crash.  Dynamic Transaction Backout (DTB) handles an individual task that has failed on its own.  In both cases, the transaction’s entry in the PCT must be marked DTB=YES.  This directs CICS to build, for each such executing task, a dynamic storage log in which to store a before-image of each protected file.  A protected resource is one for which CICS recovery is requested; its entry in the FCT must be marked LOG=YES.

CICS multitasking occurs because CICS uses the I/O wait time of one task to dispatch another task.

MultiRegion Operation (MRO) facilitates communication between two CICS regions in the same machine.

InterSystem Communication (ISC) facilitates communication between two CICS regions in different machines.

The three major IBM telecommunications methods are:

       BTAM - Basic Telecommunications Access Method
       TCAM - Telecommunications Access Method
       VTAM - Virtual Telecommunications Access Method

Under BTAM, the CICS Terminal Control Facility manages the telecommunications network.  The TCAM or VTAM access method runs in its own region and manages the network.

A task is a CICS internal unit that begins and ends with the allocation and deallocation of the Task Control Area (TCA), the control block that CICS uses to recognize and control the task.

A transaction is a functional unit initiated by a transid, involving a terminal operator session of one or multiple screens, which may invoke multple tasks.

A quasi-reentrant or serially reusable program is a load module that alters itself during execution but restores its original state prior to each invokation of CICS.

A reentrant program is a load module that never alters itself during execution.

A CICS program must be one of the above types to allow multiple tasks to serially execute through a single copy of the load module - a process called multithreading.  Each task releases control only by invoking CICS.

In a CICS Command Level COBOL load module, the Data Division is not utilized.  Each task that executes the program is dynamically allocated a copy of the Data Division and is passed the address of the Working Storage area in register 6.

In a CICS Macro Level COBOL load module, the Data Division is accessible to the executable code and, if modified, must be restored to its original state before CICS is invoked.  Each task receives no dynamically allocated Data Division, but can utilize, for dynamic storage, a user appendage to the TCA called the Transaction Work Area (TWA) whose size is specified in the PCT.

The object code of the Linkage Section of a COBOL program consists only of storage reserved for BLL cells, consecutive fullwords that each may address a parcel of storage external to the program, spanning up to 4096 bytes.  A batch CALLed program uses them for addressing areas named in the USING clause that were passed by the CALLing program.  A CICS program uses them for addressing storage dynamically acquired by File Control or Storage Control.

CICS does not use BBL 1 and BLL 2.  The other BLL cells address the Linkage Section’s 01-level areas, in sequence.  BLL 3 addresses the EIB, BLL 4 the Commarea, BLL 5 the BLL cell list, BLL 6 the first user-defined area, etc.  In the BLL cell list, the PIC S9(8) COMP fields mask the subset of BLL cells that address the list itself and the user-defined areas that follow.  Therefore, the first field, which is usually defined as FILLER, masks BLL 5, the second item masks BLL 6, etc.

To address an 01-level longer than 4096 bytes requires multiple, consecutive BLL cells containing addresses of consecutive 4096-byte areas.

Older versions of the COBOL compiler require that a CICS command or COBOL statement that sets the BLL cell for a Linkage Section 01-level area must be followed by the command: SERVICE RELOAD 01-level-name.

The LOAD command locates a named PROGRAM in storage, loads it if necessary, then returns the address of the module’s load point to the requesting task in the SET field.  This is usually done to gain addressability to an incore table.  For an executable module, the address of the entry point, which may be different from the load point, is returned in the optional ENTRY field.  The LOAD command increments the module’s resident use count by one.  When the task ends, the use count is decremented by one, unless the HOLD option was coded.  This allows the count to stay above one to prevent CICS from reclaiming the module’s storage.

Each execution of the RELEASE command decrements by one the resident use count of a named PROGRAM.  Multiple executions will reduce the count to zero, allowing CICS to reclaim the storage of a module loaded by prior LOAD commands with the HOLD option.

The task control command, SUSPEND, causes the task to surrender control to the CICS task dispatcher, like all other CICS commands, but with no request for services.  This command is used to interrupt long-running application processing so that CICS will not abend the task as a runaway task.

The interval control command, DELAY INTERVAL(0), produces the same effect.  Its usual purpose is to suspend the task for a short interval, awaiting an anticipated event.  The default time is 0.

The interval control commands, START, DELAY, and POST, accept the parameters, INTERVAL, and REQID.  CICS assigns default INTERVAL(0), and places a default request identifier in EIBREQID for the START, and POST commands.

The CANCEL REQID(reqid) command alters the effect of the command identified by REQID, that has been issued by another task, if the effect has not yet occurred.

REQID of     Altered Effect                                                                  
START prevents the task being invoked
DELAY aborts the delay and allows the task to resume
POST expires the time limit and immediately posts the ECB

The POST and WAIT EVENT commands work together to synchronize a task to an event triggered by an elapse of time or by deliberate action.  The POST command returns the address of a 4-byte timer-event control area (ECB), initialized to binary zeros, which upon expiration of the specified interval, is to be set to the value, X'40008000', thus “posting the event”.  The event may be caused to post earlier by the CANCEL command issued by another task, or by manual manipulation of the ECB.  The CANCEL command issued by the same task will prevent the posting.

The WAIT EVENT command delays a task until an event has posted.  To synchronize a task’s processing with processing that occurs in another task, or with an elapse of time, a section of code may be sandwiched between POST and WAIT EVENT commands.

For multiple tasks to invoke a single new task and transmit data records to it for sequential processing, each of the tasks must issue START TRANSID(transid) TERMID(termid) FROM(data-area) for the same transid and termid, to attach the new task to a terminal.  Only a task that is attached to a terminal, may process more than one data record by issuing consecutive RETRIEVE commands.  Only data records stored by START commands that have expired since the new task was initiated are available, and they are obtained in expiry sequence.  The termid must be defined, and the terminal must be available.  The ENDDATA condition is raised by a RETRIEVE command if no data record is available.

If the transid is defined as RESTART(YES), the expirations of START commands that occur after the new task has finished the RETRIEVE loop, but before it has terminated, will schedule another new task to be invoked when the first new task has terminated and the terminal is freed.  Otherwise, the data records will be discarded.

The RETRIEVE WAIT command will suppress the ENDDATA condition and cause the new task to enter a wait state lasting until an expired START command passes another data record.

Each START command without the TERMID option will invoke a separate new task that is not attached to a terminal and that can RETRIEVE only the single data record it was passed.

The data records are stored in temporary storage, and each one is identified by the REQID of the START command that stored it.

The NOSUSPEND option of various commands directs CICS not to hold the task in suspense, waiting for an unavailable resource, but instead to return control to the task and raise an error condition without performing the requested action.

Command     Error Condition

Various CICS commands take options that permit the command’s effect to survive the end of a LUW, requiring another command to cancel it.

Command     Option      Canceled by

When the START command with the PROTECT option is issued, the new task will not be initiated until the issuing task has completed a LUW.

Transient Data queues must be defined in the DCT.  No record updates are permitted.

Extrapartion TD queues have the following properties:

Intrapartion TD queues have the following properties:

Temporary Storage queues are defined dynamically and need only be defined in the TST if special properties are required, such as recoverability.  Update operations are allowed.

TS queues have the following properties:

A COBOL program can access a file defined by an FD, if the CICS run JCL contains the DDNAME specified in the ASSIGN clause.  However, this will cause the entire CICS region to wait while the I/O is performed.  This will also occur for COBOL statements that require operating system intervention such as: ACCEPT, DISPLAY, CURRENT-DATE, and TIME.

The CICS File Control Facility supports two file formats: VSAM and BDAM.  During update processing, the access-method always maintains exclusive control on the I/O segment it transfers to Virtual Storage, which for VSAM is the control interval (CI), and for BDAM is the block.  The access method releases control after the final I/O command in the update sequence.  However, for a protected file, CICS maintains exclusive control on the updated record for the duration of the logical unit of work (LUW).  This record lock is necessary to prevent another, concurrent task from performing an update that would be lost if the first task failed and then DTB performed backward recovery.

In a WRITE command, the I/O key named by RIDFLD and the record area named by FROM must be separate, nonoverlapping fields.  The value of the record key in the record area must equal the I/O key.

The DELETE command coded with a RIDFLD performs a random-access delete requiring no pointer to be preset by READ for UPDATE.  A single DELETE command coded with the GENERIC and KEYLENGTH options can delete multiple records.  The optional NUMREC option stores the count of deleted records in a binary halfword field.

The REQID(id-name) option may be attached to the browse commands to uniquely name a browse among multiple browses of the same file in a program.  However, such multiple browses are highly inefficient since each browse obtains a file string.

If a program executes STARTBR and the RIDFLD is not on the file, the NOTFND condition will be raised if the EQUAL option was specified.  If the GTEQ option was specified, a pointer will be set before the record with the next higher key.  Then, if the program executes READPREV, the NOTFND condition will be raised.

As an exception however, to browse backward from the last record on the file, a program can execute STARTBR with RIDFLD equal to high-values, and then execute READPREV.

The DUPKEY condition is raised when reading a VSAM file by an alternate index returns a record having an alternate key that exists within multiple records on the file.

The DUPREC condition is raised when attempting to write a VSAM record having either: a primary key that already exists on the file; or an alternate key, of an AIX defined as unique, that already exists on the file.

To perform I/O through an AIX, the program must specify the FCT entry for the path.

The WAIT TERMINAL command suspends a task until the data output by a prior SEND command has left the CICS region.

In order most efficiently to format and output multiple buffers of data with consecutive SEND commands, the task must use the time that CICS takes disposing of one SEND command’s output to format the output for the next.  Omitting the WAIT option from the SEND command allows the task to regain control without waiting for CICS to dispose of the output.  Then, the task can format the next output buffer and then issue the WAIT TERMINAL command to pause execution, if necessary, until CICS is ready for the next SEND command.

A conversational program SENDs output to a terminal, printer, or other device; issues a RECEIVE command and remains resident waiting for a response; and then processes the response.  The CONVERSE command does the work of successive SEND, WAIT TERMINAL, and RECEIVE commands.

A pseudoconversational transaction is one composed of separate tasks, each of which ends shortly after SENDing a screen, thus freeing the CICS region to execute another user’s task during the pause before the user’s response - a process called multitasking.  Each program ends with the RETURN TRANSID command.

If the first-time processing of a pseudoconversational transaction differs greatly from subsequent processing, it makes sense to code separate programs for each phase.  The first-time program would then RETURN TRANSID(trancode) the trancode of the next-time program.

The RECEIVE command inputs the native mode contents of the terminal buffer.  The SEND command outputs the same.  Therefore, a program can use these commands to store and redisplay a map in order to swap it with a help screen.  However, the cursor position must be redisplayed by a separate SEND CONTROL command from the stored EIBCPOSN.

The RECEIVE MAP command with the FROM(data-area) option maps the native-mode contents of data-area into a symbolic map.  This command is issued after a CONVERSE command in a conversational program that uses symbolic mapping.

It is most efficient to use the INTO option of the RECEIVE command, since this copies into Working Storage the data from the terminal input buffer and then allows CICS to reuse the buffer.  Using the SET option holds the buffer for the task and sets a pointer to it.

Using the SET option of the RECEIVE MAP command, causes CICS to GETMAIN an input map area.  Although CICS does not hold the TIOA, this method is still less efficient because it fragments storage.

Although the AID key is known at the beginning of the task, the HANDLE AID branch occurs only upon execution of a CICS command requesting screen input, such as RECEIVE or RECEIVE MAP.  This differs from how HANDLE CONDITION works; the branch occurs when the condition is raised.

Pressing a PF key or the ENTER key will activate a task and transmit a screen’s data.  Pressing a PA key or the CLEAR key will activate the task, but send no data; after which a RECEIVE MAP command would raise the MAPFAIL condition.

An attribute byte preceeds every field displayed on a BMS screen.  Its bits are flags that indicate the field’s display attributes such as protection from overtyping, numeric shift of the keyboard, and intensity of brightness.  Its final bit is the modified data tag (MDT), which signals whether CICS should transmit the field to the host.  Overtyping a map field sets its MDT on.

Bit 0123 4567
Not Used Protection
& Shift
Intensity Must
equal 0

Every terminal has a buffer that stores data, in native mode, representing the image displayed on the screen.  Only keyboard input or program output can change the data in the buffer.

The symbolic map provides storage for the data transmitted between BMS and the program.  It represents every map field defined by a named DFHMDF macro.

An example of a symbolic map having a single 10-byte alpha field is:

01  MAP-I.
    02  FILLER                  PIC  X(12).
    02  MAP-FIELD-L             PIC S9(4) COMP.
    02  MAP-FIELD-F             PIC  X(1).
        03  MAP-FIELD-A         PIC  X(1).
    02  MAP-FIELD-I             PIC  X(10).
    02  FILLER                  PIC  X(12).
    02  FILLER                  PIC  X(3).
    02  MAP-FIELD-O             PIC  X(10).

The MAP-I group fields receive screen data inbound to the program.  The length field, MAP-FIELD-L, holds the number of bytes transmitted for the field.  For inbound processing, the flag/attribute field, MAP-FIELD-A, holds a flag that is set to X'80' when an erase-eof keystroke at the beginning of the field, has erased it all, filling it with low-values.  BMS will not transmit low-values, inbound or outbound.  Therefore, the length field will equal zero.  The input field, MAP-FIELD-I, holds the field’s contents.

The MAP-O group fields hold data outbound to the screen.  For outbound processing, the flag/attribute field, MAP-FIELD-A, holds the output attribute byte.  The output field, MAP-FIELD-O, holds the output field.

Minimum data transmission from screen to host occurs when CICS uploads only the map fields that have been overtyped.  Over the course of a transaction, once a field is modified and its MDT is turned on, the MDT remains on, even if the field is further unmodified, and CICS continues to retransmit the field, unless CICS is directed to turn the MDT off.  The CTRL=FRSET option of the DFHMSD or DFHMDI macro directs the SEND MAP command to turn off the MDTs of all map fields.

To maintain a complete picture of the screen when only the newly modified fields are transmitted each time around, the program must first test the input fields for modification, and then save them in the commarea.  Care must be taken to store spaces for a screen field that has been erased by an erase-eof keystroke.

The following code loads a screen field to a commarea field:

         MOVE SPACE        TO CA-FIELD

The ATTRB=FSET option of the DFHMDF macro turns on the field’s MDT so that it will always be resent to the host regardless of whether it has been overtyped.

In the DFHMDF macro, the PICIN option specifies a COBOL picture clause value for the field in the input symbolic map.  This can be used to define an implied decimal point in a numeric input field.  The PICOUT option does the same for the field in the output symbolic map.  This can be used to define a floating dollar sign in an output field.

On the screen, the default cursor position is the top left-hand corner, or the beginning of the map field having the ATTRB=IC option in its DFHMDF macro.  However, the program may direct the cursor to a different position.

Coding the CURSOR parameter in the SEND MAP command with an absolute address field, a binary halfword valued between 1 and 1920, sets the cursor to a precise row and column position that is unrelated to the position of any map field.

Symbolic cursor positioning (SCP), setting the cursor position at the beginning of a field defined in the symbolic map, is accomplished by three coding actions: setting the length field in the symbolic map to X'FFFF' by setting its numeric value to -1; coding the CURSOR parameter in the SEND MAP command without an address value field; and coding the MODE=INOUT parameter in the mapset’s DFHMSD macro.

In BMS, a long literal is continued in column 16 of the second and subsequent lines, in the same way as all assembler macros:

         DFHMDF POS=(5,1),                                             X
               LENGTH=79,                                              X
               ATTRB=ASKIP,                                            X