Forward Recovery restores a corrupted file by applying copies of file modifications from the system journal to the file’s backup taken at ...
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 markedDTB=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’s01-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, thePIC 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 asFILLER, 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 HOLDoption 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 byREQID, 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 issueSTART TRANSID(transid) TERMID(termid) FROM(data-area) for the same transidand 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 RETRIEVEcommands. 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 theREQID 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 |
| GETMAIN | NOSTG |
| ENQ | ENQBUSY |
| READQ | QBUSY |
| WRITEQ | NOSPACE |
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 |
| LOAD | HOLD | RELEASE |
| GETMAIN | SHARED | FREEMAIN |
| ENQ | TASK | DEQ |
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:
· QSAM objects such as a file, printer, or internal reader that is defined outside of the CICS region
· I/O operations hold the entire CICS region in a wait state
· Defined as input only or output only to CICS
· No DELETEQ command allowed
Intrapartion TD queues have the following properties:
· All queues stored on VSAM file with ddname DFHINTRA
· Used only for communication within CICS
· Trigger level defined in the DCT permits Automatic Transaction Initiation (ATI)
· Destructive reads; each queue item can be read only one time
· DELETEQ command deletes the entire queue
· Can be defined as recoverable
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:
· All queues of type AUX stored on VSAM file with ddname DFHTEMP
· All queues of type MAIN stored in main storage
· Random access allowed by ITEM parameter
· READQ without ITEM parameter gets the next queue item according to a pointer that belongs to the queue, not the task
· The item numbers of concurrent programs getting the “next” item will be unpredictable
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 FROMmust 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 theGENERIC 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 SENDcommand has left the CICS region.
In order most efficiently to format and output multiple buffers of data with consecutiveSEND commands, the task must use the time that CICS takes disposing of one SENDcommand’s output to format the output for the next. Omitting the WAIT option from theSEND 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 theWAIT 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 aRECEIVE 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. TheSEND 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 storedEIBCPOSN.
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 CONVERSEcommand 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 RECEIVEor 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.
|
| ||||||||||||||||||
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).
02 FILLER REDEFINES MAP-FIELD-F.
03 MAP-FIELD-A PIC X(1).
02 MAP-FIELD-I PIC X(10).
01 MAP-O REDEFINES MAP-I.
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 MAPcommand 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:
EVALUATE TRUE
WHEN MAP-FIELD-L > ZERO
MOVE MAP-FIELD-I TO CA-FIELD
WHEN MAP-FIELD-A = DFHBMEOF
MOVE SPACE TO CA-FIELD
END-EVALUATE.
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 theCURSOR 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
INITIAL='-----------------------------------------------X
--------------------------------'
No comments
Post a Comment