CA IDMS Reference 19.0

PDF
English

Controlling Abend Processing

Contents
idmscu
Contents
A program can abnormally terminate in the following ways:
  • DC
     terminates a program upon encountering a processing error (for example, a program check).
  • The
    program
     terminates itself upon discovering a situation that would result in invalid results.
DC allows you to specify abend exits, which are invoked upon a system or a user abend request. These exits specify a program to be invoked in the event of an abend; you can include an abend exit program for each level of a task. Abend exits allow you to determine the cause and severity of the abend. Based on that information, you can return control to the task, return control to the next-higher abend exit, or terminate the program.
Terminating a Task
When your program encounters data that indicates errors have occurred, you should terminate processing. Typically, the IDMS-STATUS routine discovers processing errors and abends your program. You should also terminate processing if a situation exists that makes it impossible to ensure valid results (for example, if you are unable to reaccess a previously obtained database record).
To abnormally terminate a task, issue an ABEND statement that specifies a user-defined abend code. Optionally, you can write a formatted dump to the log file and specify whether previously established abend exits should be invoked or ignored.
For more information on abend exits, see Performing Abend Routines.
Handling db-key Deadlocks
You can include logic in your program that is invoked if your run unit is terminated because of a db-key deadlock. This enables your program to maintain the terminal session and save any data that was previously entered on the screen.
At that point, your program can do one of the following:
  • Ask the user to resubmit the transaction.
  • Automatically restart the run unit, establish currency, and try again.
What Happens When a Deadlock Occurs
When a run unit is terminated because its request would cause a deadlock condition, the DBMS:
  1. Rolls back the database transaction and terminates the run unit
    . The rollback operation releases all locks held by the aborted run unit.
  2. Writes the following message to the log
    :
    
TASK: 
    task-code
     PROG: 
    program-name
    

SUBS: 
    subschema-name
     SSCSTAT: 
    subschema-status
    

RUN-UNIT 
    run-unit-id
     ROLLED OUT.'
  3. Returns control to the issuing task
     with a status code of
    nn
    29, which indicates that a deadlock has occurred.
What To Do
You can continue a terminal session in the event of a deadlock by having your program resubmit a transaction in response to a minor status code of
nn
29. How you do this is largely a site-specific decision. Typically, you resubmit a transaction in one of two ways:
  • Inform the user of the deadlock and request the user to resubmit the transaction
  • Programmatically resubmit the transaction
Automatically Restarting the Run Unit
If your program automatically restarts the run unit and retries the transaction, it must:
  1. Rebind the run unit by:
    1. Reinitializing the ERROR-STATUS field in the IDMS communications block to the value 1400
    2. Issuing the appropriate BIND/READY sequence
  2. Reestablish the appropriate currencies before retrying the transaction that originally caused the deadlock.
If You Don't Check for the Minor Code
If your program fails to check for a minor code of
nn
29, you can expect the following results:
  • If AUTOSTATUS is in effect
    , your program takes the action specified in the site-specific IDMS-STATUS routine.
  • If AUTOSTATUS is not in effect
    , your program responds as specified in the program code that checks status codes.
    If your program does not contain any generic error-checking logic (such as the IDMS-STATUS routine) and, after receiving a minor code of
    nn
    29, continues to issue database requests without reestablishing a run unit, the DBMS returns a database status of
    nn
    77 (run unit not bound).
'COBOL'. COBOL programs must redefine the ERROR-STATUS field of the IDMS communications block to access the minor code value.
Example of Resubmitting the Transaction
The program excerpt below informs the user of a database minor code of
nn
29 and requests that the transaction be resubmitted:

 WORKING-STORAGE SECTION.
 01  SUBSCHEMA-CTRL.
    03  PROGRAM-NAME           PIC X(8) VALUE SPACES.
    03  ERROR-STATUS           PIC X(4) VALUE '1400'.
           .
           .
    03 SUBSCHEMA-CTRL-END      PIC X(4).
 01  SSC-REDEF REDEFINES SUBSCHEMA-CTRL.
    03  FILLER                 PIC X(8) VALUE SPACES.
    03  ERRSTAT-REDEF.
      05  ERRSTAT-MAJ          PIC XX.
      05  ERRSTAT-MIN          PIC XX.
          88 DEADLOCK        VALUE '29'.
    03  FILLER                 PIC X(292).
*
 01  MESSAGES.
     05 DBKEY-DEADLOCK-MESSAGE  PIC X(80) VALUE
        'REQUESTED RECORD IN USE.  PLEASE RESUBMIT TRANSACTION'.
 .
 .
 .
 PROCEDURE DIVISION.
 .
 .
 .
 IDMS-ABORT.
     IF DEADLOCK
       THEN
          MODIFY MAP TSKMAP01 TEMPORARY
             FOR ALL FIELDS NOMDT
          MAP OUT USING TSKMAP01
             MESSAGE IS DBKEY-DEADLOCK-MESSAGE LENGTH 80
          DC RETURN NEXT TASK CODE 'UPDATASK'.
 IDMS-ABORT-EXIT.
     EXIT.
     COPY IDMS IDMS-STATUS.
******************************************************************
 IDMS-STATUS                                             SECTION.
********************* IDMS-STATUS FOR IDMS-DC ********************
         IF DB-STATUS-OK GO TO ISABEX.
         PERFORM IDMS-ABORT.
         MOVE ERROR-STATUS TO SSC-ERRSTAT-SAVE
         MOVE DML-SEQUENCE TO SSC-DMLSEQ-SAVE
         SNAP FROM SUBSCHEMA-CTRL TO SUBSCHEMA-CTRL-END
                    ON ANY-STATUS NEXT SENTENCE.
         ABEND CODE SSC-ERRSTAT-SAVE
                    ON ANY-STATUS NEXT SENTENCE.
 ISABEX. EXIT.
 DMCL-DC-GEN-GOBACK SECTION.
     GOBACK.
Performing Abend Routines
You can establish linkage to an abend routine to which DC passes control if the issuing task terminates. Optionally, you ca CAncel linkage to a previously established abend routine. Each level in a task can have one abend exit in effect at any given time; if more than one abend exit has been established for a level, DC recognizes the last abend exit requested.
Executing Abend Exits
When a task terminates abnormally (following a processing error or an ABEND request), abend exits for the program that was executing at the time of the abend and for all higher-level programs will be executed before the task is terminated. You can prevent DC from executing abend exits automatically by coding the EXITS IGNORED clause in an ABEND request (explained above) or by specifying the abort or continue options in the abend routine's DC RETURN statement. DC RETURN requests are typically handled as follows:
  • Normal
     termination passes control to an abend exit at a higher level or to DC:
    
DC RETURN.


    Abort
     termination passes control directly to DC, bypassing any other exit programs:
DC RETURN ABORT.
SET ABEND EXIT Statements
To establish linkage to an abend exit, which will be invoked if the issuing task terminates, issue a SET ABEND EXIT statement that specifies the program to be called in the event of an abend.
To cancel any previously requested abend exits for the issuing task level, issue a SET ABEND EXIT OFF command.