Service Group Application Reference

Service Group Application Reference

How an Application Should Test the Response Code

How an Application Should Test the Response Code

It is recommended that applications initialize the error number portion of the full response code, or the 2-byte response code depending on the Service, to a value of ’90’ prior to a Call to SSA-NAME3.
This allows the condition to be detected where SSA-NAME3 was Called, but was either not properly invoked or did not get a chance to set the response code before returning. SSA-NAME3 will never itself use a value of ’90’, although it does use values in the range ’91’ to ’99’.
On return from a Call to SSA-NAME3, the program should check the error number, or the 2-byte response code. If it is ’00’, then it can be assured the Call to the Service was successful and the application may continue processing. If a value greater than or equal to ’90’ is found, this is a fatal error and the program should be aborted.
An error number greater than or equal to ’90’ will not have set the rest of the response code, so there is no point in checking the severity for these cases.
If the error number is not ’00’ and it is not greater than or equal to ’90’, then the application should check the severity of the response code. If the severity is greater than or equal to ’2’, then the program should abort. If the severity is ’1’, the program may elect to continue processing, or to abort depending on the response code. It may also elect to continue processing for some response codes and abort for others.
For example, an error number of ’02’ with a severity of ’1’ usually means that a name has no valid components after processing from which to build a key or do matching. An error number of ’32’ with a severity of ’1’ usually means that one or more fields being matched has a null value.
Remember, if the application does abort, the full response code should be saved to a file, displayed to a screen, or printed to allow proper debugging.
Following is sample pseudo code for interrogating a response-code.
VARIABLE DECLARATIONS. . . . . SSA-NAME3-RESPONSE-CODE CHAR 20 REDEFINE SSA-NAME3-RESPONSE-CODE SSA-NAME3-ERROR-NUMBER CHAR 2 SSA-NAME3-ERROR-REASON CHAR 2 SSA-NAME3-ERROR-MODULE CHAR 2 SSA-NAME3-ERROR-SEVERITY CHAR 1 SSA-NAME3-ERROR-UNUSED CHAR 3 SSA-NAME3-SECONDARY-RESPONSE-CODE CHAR 10 . . . SSA-NAME3-WORK-AREA CHAR 99999 REDEFINE SSA-NAME3-WORK-AREA SSA-NAME3-WORK-FIRST CHAR 42 SSA-NAME3-EXTENDED-RC CHAR 20 . . . . MAIN CODE. . . . . MOVE ’90’ TO SSA-NAME3-ERROR-NUMBER CALL ’N3SGUS’ USING SSA-NAME3-SERVICE, SSA-NAME3-RESPONSE-CODE, . . . . IF SSA-NAME3-ERROR-NUMBER NOT = ’00’ IF SSA-NAME3-ERROR-NUMBER >= ’90’ PERFORM SSA-NAME3-ERROR-ABORT END-IF MOVE SSA-NAME3-EXTENDED-RC TO SSA-NAME3-RESPONSE-CODE
The above line is only required if the Service does not use the 20-byte Response-code field in its parameter list.
IF SSA-NAME3-ERROR-SEVERITY >= ’2’ PERFORM SSA-NAME3-ERROR-ABORT END-IF IF SSA-NAME3-ERROR-SEVERITY = ’1’ PERFORM SSA-NAME3-WARNING-PRINT END-IF END-IF . . . . SSA-NAME3-ERROR-ABORT. PRINT ’\ssaproduct{} RESPONSE CODE: ’ SSA-NAME3-RESPONSE-CODE ABORT SSA-NAME3-WARNING-PRINT PRINT ’\ssaproduct{} RESPONSE CODE: ’ SSA-NAME3-RESPONSE-CODE CONTINUE
The
SSA-NAME3-WARNING-PRINT
function may be something to do during the testing stages of an application. If it is established that a certain warning can be ignored, then the appropriate code can be put into the response code checking. For example,
IF SSA-NAME3-ERROR-SEVERITY = ’1’ IF SSA-NAME3-ERROR-NUMBER = ’02’ OR ’32’ CONTINUE ELSE PERFORM SSA-NAME3-WARNING-PRINT END-IF END-IF
In the above example,
SSA-NAME3-EXTENDED-RC
is always moved into
SSA-NAME3-RESPONSE-CODE
regardless of the Service. This simply makes the code more standard, as even the Services which use the full response code in the parameter list have the full response code repeated in the Work-area.

0 COMMENTS

We’d like to hear from you!