C H A P T E R 3 - Abnormal Termination of Regions and Transactions

C H A P T E R 3

Abnormal Termination of Regions and Transactions

This chapter provides suggestions for diagnosing and handling the abnormal termination of regions and transactions. It includes the following topics:

Abnormal Terminations

Restarting After a Region Terminates Abnormally

Abnormal Terminations

This section describes the causes of abnormal terminations. See also Restarting After a Region Terminates Abnormally.

Sun MTP Crash

Abnormal termination of Sun MTP can happen either in an orderly manner or by an abort, also referred to as an abend. If the termination is orderly, the following events occur:

All processors terminate

The ABORT.prt file is written to the $KIXSYS directory

All shared memory, semaphores, and queues used for communication between processors are freed

If the termination is not orderly, execute the kixsnap utility.

Note - If you log in using a new terminal because your terminal was locked by an abort, you must reset all Sun MTP environment variables (including $KIXSYS), and verify that $UNIKIX/bin is in your path, before you run kixsnap.

The kixsnap utility creates several files in either the $KIXSYS/debugkix directory or in the directory you defined in the KIXSNAPDIR environment variable. The snapshot.timestamp file includes all the information contained in ABORT.prt, as well as information about the entire system, including users and processes, at the time of the abnormal termination.

The two other files kixsnap creates are snapshot.vsam and snapshot.trace. Because the output can be difficult to interpret, save the files and contact your authorized service provider. Support engineers will either ask you to email, mail, or ftp the snapshot information.

Refer to the Sun Mainframe Transaction Processing Software Reference Guide for information about kixsnap.

Application Transaction Abort

Two types of errors can cause an application transaction abort:

An exception condition returned by an EXEC CICS command when the error was not previously handled by a HANDLE or IGNORE command

An error detected by the application runtime code

When a transaction aborts with an EXEC CICS command exception condition that was not handled, and debug mode is not in effect, a message is displayed on line 23 of the screen. The message provides the transaction ID, the name of the EXEC CICS command, and the name of the exception condition. For example:

Tran KTBM has abended: Function WRITEQ TD Condition QIDERR

Sometimes, a condition that does not have a corresponding return code can cause the abort, such as a program or mapset that was specified in the Program Control Table (PCT), but was not found on disk. This causes a text message to display on line 23 of the screen. You might find additional information, such as the relative address of the abort, in the unikixmain.err file in the $KIXSYS directory. You might also find the address on a listing file of the program that aborted. Sun MTP starts a new transaction server to replace the one that aborted.

In addition, if the formatted application dump facility is enabled (the default condition), Sun MTP generates a formatted dump file named for the transaction. See also Enabling and Disabling the Dump Facility and Identifying Where the Transaction Abended.

If your system is in debug mode and an abort occurs while a transaction is processing, the Debug Facility screen is displayed with the error message. FIGURE 3-1 shows an example of an abort. The information in the middle of the screen gives the error condition and the program in which the error occurred.

FIGURE 3-1 Debug Facility Screen--Abort Error

Screen shot showing the Debug Processor screen. In the middle of the screen, a box surrounds information including the error message, the program name, and the CID number.

To Recover From an Abort While in the Debug Facility

1. Press PF4.

A screen is displayed prompting you to verify the cancellation.

2. Press Enter to cancel the transaction, or PF3 to return to the Debug Facility.

If you cancel the transaction, the screen is restored to its state at the time of the abort.

If the screen is one on which you can enter a transaction, you can do so. Otherwise, press Clear to clear the screen.

Restarting After a Region Terminates Abnormally

When a region terminates abnormally, you must perform clean-up operations and verify the structure of the region's VSAM files. Otherwise, you might not be able to start a new Sun MTP server.

To Clean Up After an Abnormal Termination

1. Open a shell window and source the setup file for the region that terminated.

2. At the prompt, run the kixclean -a command to complete the termination process.

3. Run the ipcs command to verify that all shared memory processes were released.

The command displays all semaphores, queues, and shared memory that are in use on the host. If other programs that use shared memory are running, the output from ipcs can be difficult to read. Use the following command to view only those areas of shared memory that are related to the user ID of the user who started the region:

$ ipcs | grep userid

If shared memory processes still exist, use the ipcrm command to remove them. If the same user ID has multiple regions, there might be multiple entries. If there are, delete entries of type D (defunct/dead). See the man page for the ipcrm(1) command.

4. Run kixverify -r ALL to reset the activity counts for the VSAM clusters.

If you do not execute kixverify, the Sun MTP region displays messages such as the following, and aborts during startup:

Error accessing Catalog, file is open to another Sun MTP system currently or it was not closed properly

Activity count error on cluster %s, override status to deferred open

5. Run kixstart to restart the region and enable rollbacks to run.

To Verify File Integrity or to Validate the Structure of VSAM Files

1. After you restart the region, which enables rollbacks to run, stop the region using the kixstop command.

2. Run kixvalfle to validate the structure of the VSAM files in the cluster.

3. If kixvalfle reports problems, run kixsalvage, which scans and dumps all salvageable data to a new file or files.

Refer to the Sun Mainframe Transaction Processing Software Reference Guide for complete information about the commands and all their options. See also Chapter 5 for information about data corruption and recovery. If you continue to experience problems, contact your authorized service provider.