Scheduling and terminating a PSB (CICS online programs only)

Before your online program issues any DL/I calls, it must indicate to IMS its intent to use a particular PSB by issuing either a PCB call or a SCHD command. In addition to indicating which PSB your program will use, the PCB call obtains the address of the PCBs in the PSB. When you no longer need a PSB, you can terminate it using the TERM request.

In a CICS® online program, you use a PCB call or SCHD command (for command-level programs) to obtain the PSB for your program. Because CICS releases the PSB your program uses when the transaction ends, your program need not explicitly terminate the PSB. Only use a terminate request if you want to:

• Use a different PSB
• Commit all the database updates and establish a logical unit of work for backing out updates
• Free IMS resources for use by other CICS tasks

A terminate request causes a CICS sync point, and a CICS sync point terminates the PSB. For more information about CICS recovery concepts, see the appropriate CICS publication.

Do not use terminate requests for other reasons because:

• A terminate request forces a CICS sync point. This sync point releases all recoverable resources and IMS database resources that were enqueued for this task.

  If the program continues to update other CICS resources after the terminate request and then terminates abnormally, only those resources that were updated after the terminate request are backed out. Any IMS changes made by the program are not backed out.

• IMS lock management detects deadlocks that occur if two transactions are waiting for segments held by the other.

  When a deadlock is detected, one transaction is abnormally terminated. Database changes are backed out to the last TERM request. If a TERM request or CICS sync point was issued prior to the deadlock, CICS does not restart the transaction.

  Related Reading: For a complete description of transaction restart considerations, see CICS Transaction Server for z/OS® Recovery and Restart Guide.

• Issuing a terminate request causes additional logging.
• If the terminal output requests are issued after a terminate request and the transaction fails at this point, the terminal operator does not receive the message.

  The terminal operator may assume that the entire transaction failed, and reenter the input, thus repeating the updates that were made before the terminate request. These updates were not backed out.