FALSE

Page Nav

HIDE

Grid

GRID_STYLE

CICS FAQ's part8

TRANSIENT AND TEMPORARY DATA QUEUES   1.     Are the sequential files supported by CICS? Yes they are supported as extra partition transient...

TRANSIENT AND TEMPORARY DATA QUEUES

Yes they are supported as extra partition transient data files and not as a part of the File control program.

Transient data is a sequential data in a transient data file.
It is not possible to do so.

Intra partition and extra partition TDQs.

Intra-partition TDQ's are queues for communication within CICS region. CICS stores the Intra-partition TDQ in a dataset 'DFHNTRA' on the Disk.

Extra-partition TDQ's are datasets used for communication between CICS and other CICS/Batch regions.
Extra-partition TDQ doesn't have to be a disk file, it can reside on any device that's a valid QSAM/VSAM. The DCT entry contains the destination-Id, type of TDQ, Destination, Trigger level if needed

WRITEQ TD, READQ TD, DELTEQ TD, ENQ and DEQ.

It is a queue of stored records. It is created and deleted dynamically by an application program without specifying anything CICS control tables.

WRITEQ TS, READQ TS and DELETEQ.
The WRITEQ TS command is used to Write data into a TSQ. The Options used are QUEUE(name), FROM(d-area) , LENGTH(value), ITEM(item-value),
REWRITE and Main/Auxiliary. The last three are optional. The Item value field is to be defined as S9(4) comp.
The READQ TS is used to read the TSQ, its options are QUEUE(name), INTO(data area) ,Length(value), ITEM(item-value)/ NEXT. The Item-value is the number of the TS Record in Q'.


In Temporary Storage Queues Data is read randomly, While in Transient Data Queues data must be read sequentially.
(2) In a TSQ data can be read any number of times as it remains in the queue until the entire Queue is deleted. In TDQ data item can be read once only. To reuse the TDQ it must be closed and reopened.
(3) Data can be changed in TSQ, but not in TDQ.
(4) TSQ can be written to Auxiliary or Main Storage, while TDQ is written to Disk. Temporary storage is a holding place, while Transient data is always associated with destination. The
(5) TSQ name is defined dynamically, while a TDQ name need to be defined in the DCT. Note: An application uses TSQ 's to pass info' from task to task, while a TDQ to accumulate records before processing or send data for external use, such as a print operation or other.
TSQ – Will be 1 to 8 characters long
TDQ-Name will be 1 to 4 characters long

If recovery for the TSQ, is needed. It's entered in TST (Temporary Storage table). Yes in the DFHTST.

TASK control refers to the CICS functions that manage the execution of tasks. Task control commands are SUSPEND ENQ and DEQ.

ENQ

EXEC CICS SYNCPOINT

ENQ –This Command exclusively locks a resource in CICS. The resource cannot be accessed by any other transaction at that time.

DEQ –This command releases lock from the resource and other transactions will be able to access the resource.

CICS does not automatically ensure that only one task writes records to a destination at one time. To control this, CICS provides ENQ and DEQ Task control commands used to make resources serially reusable. ENQ command is specified with RESOURCE (data-area/ DESTID) and LENGTH options to reserve the resource. DEQ is used to release the resource. Even, If the DEQ command is not issued, at the End of the task, the resources are released.

The command is as follows

EXEC CICS DELETEQ
            Queue (TSQ-QID)
END EXEC

This general syntax can be applied to the above case in the question.

TDQ - Can be used in message switching and report print in ATI and it will also be helpful for the communication of two transactions.

 TSQ – It is also helpful in data passing among transactions, review mode in multiple screens and also in report printing.

EXEC CICS READQ
           QUEUE (Queue name)
           INTO (data area)
           LENGTH (length of the message in the queue)
           ITEM(item number)
       END EXEC

Trigger level indicates the number of triggers required initiating an ATI. It is applicable only to intra partition TDQ s.

ATI is automatic transaction initiation .It is to initiate a transaction in the non-conversational mode of CICS. It's used only with Intra partition TDQ 's by specifying the number of records at which ATI occurs is called the trigger level. Not applicable for extra partition TDQ's.

Yes if recovery is needed. It is needed in TST (temporary storage table).

Destination control table. It is a CICS program table to define the TDQs used in CICS.

Whenever we need to copy the contents of a TDQ to TSQ for us to browse the contents in detail then we go for this get option .The command will be the keyword Get followed by the TDQ name. Since a TDQ will be a destructive read we have to put back the contents to the TDQ to make the contents available in TDQ and there we go for a put option. The command will be similar to get option and it will be the keyword put followed by the TDQ name.


Yes. As long as they run in the same region.

An indirect Destination lets a single TDQ be identified by more than one destination Id. The DCT entry for an indirect destination simply specifies the name of the destination defined elsewhere in it. TYPE=INDIRECT option is used during the DCT entry. Ex. DFHDCT TYPE=INTRA, DESTID=L86P, TRANSID=PRTA, TRIGLVL=1 (results in initiating the PRTA transaction after every single entry into TDQ). Ex2. DFHDCT TYPE=INDIRECT, DESTID=PRT1,INDDEST=L86P. The advantage of indirect destinations is to use them when you have to change the destination Id frequently, there is no need for change and compilation of every program associated with it.

Depending on the DCT entry for the destination, the disk space occupied by that record may still be reserved, even though the records are not available. So in order to reclaim this space DELETQ TD command is used.
PRNT. It's usually used to print contents of the TDQ's.

Four.
They are Intra-partition (I/O within CICS system),
Extra-partition (for I/O outside CICS region),
Indirect, and
Remote.
The external dataset defined through DCT can not be a VSAM file as TD can only use sequential files. Note that only Intra-partition TDQ 's can be deleted.
CSPG is an IBM supplied transaction code used to browse, delete and manipulate pages built by PAGING operand. CEMT, CECI, CEBR, CECA, CECS, CEDA, CEDB, CEDC and CEDF, PRNT, MAPS.

RECOVERY AND RESTART IN CICS

SYNCPOINT and ROLLBACK, which are used to commit or back out all the changes made during the Current LUW.

Journal recovery is a recovery of changes made to a file during online processing.If  a file has I/O problems, it is restored from a backup taken before online processing begins and journalled changes are applied. Dynamic transaction backout is the removal of partial changes made by a failed transaction.

At a bare minimum PCT and PPT must be updated.

SYNCPOINT without ROLLBACK option makes all updates to protected resources permanent, with the ROLLBACK option it reverses all updates.

They refer to CICS efficiency techniques. Locality of reference requires that the application program should consistently refer instructions and data within a relatively small number of pages.The working set is the number of program pages needed by a task.

Dynamic log:  A CICS region has a special system area in the main memory called “ dynamic log”. Whenever a record of a recoverable resource such as a VSAM file is changed during the execution of a transaction, CICS automatically writes the “before image” information of the record into the dynamic log for the duration of one LUW of the transaction. The information in the dynamic log is the basis for the resource recovery.

System log: The system log is similar to the dynamic log, except that the system log is kept in the external device, such as tape, recording the “before image” information of all records which are affected by the tasks in the CICS region. This recording process is called “automatic logging”. After a system failure, this system log will be used for recovering the recoverable resources by the CICS recovery and control program.

Forward recovery: In case of recovery form journals, the recoverable file on subject is recovered to the starting state using the backup copy of the file. Then the recovery program reads the corresponding journal forward. Then, it replaces the record in the file with the corresponding record in the journal. This process will be repeated until the file has been fully recovered. Since the file recovery using the journal is achieved by reading the journal forward, this recovery is called “forward recovery”

Backward recovery: If an abnormal end occurs in the transaction, CICS applies the records in the dynamic log backward one by one until all records in the dynamic log related to the transaction have been exhausted. Then, all recoverable resources are restored to the state where the transaction started or the last sync point of the transaction. Since the recovery by DTB is achieved by reading the dynamic log backward, DTB is called “backward recovery”

Cold start: In this start, CICS and system control tables will be completely initialised irrespective of the previous system activities. As a result, CICS will start with the cleanest resources.

Warm start: In this start, CICS will start itself with certain system information and resources carried over from the previous CICS execution, which has been completed normally. The information is kept in the special system file called “warm key points”. Since the warm start uses the information of warm key points without completely reinitialising the system areas and tasks, system start up is much faster than the cold start.

Emergency system restart: If the previous CICS execution has been abnormally terminated, an emergency system restart will take place. The emergency system restart will reposition the system log at the very last record, read the system log backward, and copy the log records of all “in flight tasks” into a restart data set. Then the recovery control program will perform back out of recoverable resources based on the restart data set. Through this backout process, all recoverable resources will be recovered.

When a Transaction terminates abnormally, CICS invoke DTB program that processes the before-images stored in Dynamic Log of the transaction to reverse any changes made to the protected resources. After DTB come to end, it is as if the transaction was never started. Emergency Restart is a procedure used to restart the CICS when it terminates abnormally. First, recovery control processes the system log, which contains a record of every update made during the previous CICS execution. Recovery control reads the system log backwards, determining which updates were made by in-flight tasks (- tasks that were active when the uncontrolled shutdown occurred). Each updated that was made by an in-flight task is copied to the restart dataset, which is then processed by the Transaction Backout program similar to DTB, for restoring the protected resources. The difference is that the transaction backout program updates made by many tasks, while DTB restores updates made by only one task.


TESTING AND DEBUGGING IN CICS

CEMT – It manipulates the CICS environment like transactions, programs, tasks and TSQs
Some of the cics supplied transactions are CEMT, CECI, CEBR, CEDF, CESN and CESF. Their uses are as follows

CEMT – C E Master Terminal.Transaction. which is used to manipulate CICS  environment such as transactions, programs, files, TSQ s  and tasks.
Ex. CEMT SET PROGRAM=(pgmname),NEWCOPY .It's used for variety of supervisory CICS functions. CEMT transaction can be used to force a new program copy as above. To open or close a dataset as Ex2. CEMT SET DATASET(dataset) {OPEN/CLOSED}.(TSQ).To disable a program or transaction or a program as Ex3. CEMT S PR/TRANSACTION(name) {DISABLED/ENABLED}. And even to cancel a task that is running on another terminal. Ex1 tells CICS that you have updated an application program, so it should read a fresh copy of the program from disk. You should issue this command whenever you recompile a program while CICS is running. Otherwise CICS will continue to use the older version. The two CEMT commands in Ex3. Are very useful when a program error forces a pseudo-conversational program into a loop. The only catch is you might have to run the CEMT command from another terminal as this terminal gets locked due to the loop.

CECI – C E Command-level Interpreter.It is a command level interpreter that performs syntax checking of a CICS command. It is also used to read datasets in CICS
We can invoke this transaction by typing the trans-id, optionally followed by the CICS command. CECI checks the syntax of the command and displays a panel telling you it is about to execute the command. When you press Enter, CECI executes the command and displays the result. CECI can be used to update the contents of the files. You use CECI often to display maps, read or write VSAM file records and so on. CECI can use it's five predefined variables namely &DFHC, &DFHW, &DFHR, &LEN and &DATA. To the right of each variable name is the variable length. The various keys used under CECI transaction are F1-HELP, F2-HEX, F3-END, F4-EIB, F5-VAR, F6-User, F9-Message.

CEBR-This transaction is used to browse temporary storage queues.

CESN CICS Execution Sign On. Ex. CESN. Ex2. CESN USER=N6SSAGI,PW=SUNIL1.It's used for logging into the CICS System.
This sign on transaction with external security manager,prompts a screen asking for the user id and pass ward. The pass ward for CESN expires automatically in the specified period through ESM.

CSSF- CICS Execution Sign Off. Ex. CESF. EX2. CESF LOGOFF .It's used for Signing off.This signoff transaction disassociates our CICS user identification from CICS in terms of security.

CEDF - CE Diagnostic Facility. It invokes a debugging aid called EDF. When EDF is activated, you can run a program step by step, checking the completion of each CICS command and examine the content of WS as needed. Other CICS supplied transactions used are MAPS, 

EIBCOPY    
  
Resource control table

Yes

Xpediter  – Used to debug Cobol statements
CEDF –used to debug CICS commands
     

CECI – It is a CICS supplied transaction that acts as a command level interpreter. It performs syntax checking of CICS commands.

CEDF –It is a CICS supplied transaction that acts as a debugging tool.

 No

TRANSLATOR options – SOURCE option prints the program listing.
                                           DEBUG enables EDF
                                           COBOL 2 alerts the system to use the COBOL 2 compiler

COMPILER - XREF prints a sorted data cross-reference.
                       FDUMP prints a formatted dump if the program abends.

RDO –Resource definition online .RDO allows resources (terminals,programs,files and transactions )to be defined interactively when CICS is running.

CECI –It is a CICS supplied transaction that performs syntax checking of a CICS command. If the syntax is satisfied, it will actually execute the command. This may be useful for interactive patching into the application system.

CEBR –It is a CICS supplied transaction that is used to browse the contents of the TSQ.

CEDF- it is a CICS supplied transaction and can be used for debugging purpose.
AEI_  - indicates execute interface program problem.
APCT - occurs when the program could not be found.
ASRA- most common CICS ABEND, indicating a program check, identified by a one-byte code in the program status word in the dump

The ABEND command forces a task to end abnormally. It creates a transaction dump and invokes the dynamic transaction backout.

DB2/IDMS is not up

Yes we can have a CICS code in a copybook. It needs to be pre-processed.

Run away task.

In COBOL 2,issue the CEBR commands and get the offset/instruction.

DB2/IDMS Database is not up.
When CICS is unable to execute a command, it generates an AB-normal task ENDing. When an Abend occurs, CICS issues a 4-char Abend code. This Abend code is sent to terminal running the task and is attached to the Abend dump created by using the Contents in Memory for that task by CICS.
The common CICS Abend codes are
ASRA- System runtime error(Division by 0, subscript over run ...),
ABMO-BMS map not in Mapset,
APCT-Call for nonexistent pgm,
AExx-Exceptional conditions encountered during the run (AEIN-Duplicate records, AEIT-eof).

The HANDLE ABEND command is used to trap and Handle errors. It has 4 possible options and only one of them can be used with this command at a time. The options are Program(...) to transfer control to the program, Label(...) to transfer control to the specified paragraph, Cancel option keeps the earlier Handle Abends from being executed. Reset option will reactivate the Handle Abend commands, which were previously cancelled.

Whenever the program is changed and compiled then new copy is required in the CICS region. The command to make a new copy available in CICS region is
CEMT set new program (program name)

The HANDLE ABEND command is used to interpret an abnormal termination within a program, and to activate, cancel, or reactivate an exit for the ABEND processing. The HANDLE ABEND command is similar to, but different from, the HANDLE CONDITION command that interprets only the abnormal conditions of the CICS command execution.

EXEC CICS HANDLE ABEND
PROGRAM (name)|
LABEL(Label)|
CANCEL
RESET
END-EXEC

PROGRAM or LABEL is used to activate an exit to a program or a paragraph, respectively, for the ABEND processing. CANCEL is used to cancel the previously established HANDLE ABEND request. RESET is to reactivate the previously cancelled HANDLE ABEND request.

Abends can also be caused by ABEND commands in addition to the programs, used to get the system Memory Dumped. The system memory contains the address of the command, which caused the dump, the contents of program variables, and list of other processes being executed by the system. The CICS Dump dataset, created during the Abend could be printed by using the DFHDUP utility.

1st step while reading a dump is to find out the program that caused the Abend. The Relative Address of a command equals to Absolute address - Load address of the module. Actually the Abend Dump will not tell the command which caused the Abend, but the absolute address of the next command which would have been executed, if there is no abend. As your program contains CICS commands, the Link Editor adds an extra control section or CSECT to the front of the program. The Load address given is for CSECT and not the program itself. So Actual program load address = program load address from dump + length of DFHECI.

The beginning of the CICS Dump for a task is identified by Abend Code and task name. You can find the PSW, and the register content immediately after the task name. Now search for 'Program Storage', and make a note of the Program Load address.

Now search for 'Control Section' under this task, to determine the (CSECT) DFHECI length. Add the last two addresses to determine the actual load module address. The Second word of the PSW always contains the next instruction to be executed, so a make a note of it.

Now calculate the Relative address of the Next instruction to be executed before abend by subtraction. Now exit the dump and view the condensed compiler listing of the program, which shows the addresses and line numbers of all Cobol commands, which can be executed. Use this information to determine the
Command that caused the abend.
MRO – This stands for multi region operation, through this, more than one CICS region can communicate.
ISC    - This stands for intersystem communication, through this CICS region of one system can communicate with CICS region of the other system.

No comments