SNAX/HLS Configuration and Control Manual

Step 5. Planning for Programming Standards
Planning the SNAX/HLS Environment
2–30 104705 Tandem Computers Incorporated
It is recommended that the installation construct a standard subroutine, procedure, or
server to process non-RC-OK verb replies. The routine would accept the verb reply,
call CONVERT-ERROR-CODE, perform appropriate logging, and furnish the
RETRY-ACTION-CODE back to the calling procedure. Message texts from
CONVERT-ERROR-CODE would be appropriate to log to the device supported by the
application, the application log, or the system log.
Message texts and display values returned from CONVERT-ERROR-CODE are self-
explanatory. The following discussion is on the RETRY-ACTION-CODE value
returned from CONVERT-ERROR-CODE and appropriate application behavior.
RETRY-ACTION-CODE Values
The RETRY-ACTION-CODE values used by SNAX/HLS are derived from the
message file, HLSMSGS. As distributed, four values are used as suggestions on how
the user should proceed in the face of error. SNAX/HLS neither interprets nor
enforces these values. These values are only suggestive, and have the following
assignments:
0 RA-NOT-APPLICABLE
1 RA-POSSIBLE
2 RA-DEFER
3 RA-NON-RETRYABLE (also known as RA-NOT-POSSIBLE)
RA-NOT-APPLICABLE. If the value is RA-NOT-APPLICABLE, the request completed
with no error. Retrying it would be improper.
RA-POSSIBLE. If the value is RA-POSSIBLE, then the request was blocked by a
transient condition (for example, buffer depletion) that is expected to clear shortly.
The application can immediately retry the request and count successive retries. If the
number of retries exceeds installation standards, a message should be logged and the
session stopped. The situation should be investigated for possible application or
system-resource problems.
RA-DEFER. If the value is RA-DEFER, then the request was a mismatch of session states
between the SNAX/HLS application and the session partner. For example, under an
HDUX-FF bind, the SNAX/HLS application was in the receive state and attempted to
send data. The request causing the error is executable at a later time, once the session
partners resynchronize their states. This might be due to an application logic problem.
However, if the application is capable of deferring the execution of the request, for
example, queuing the send until permission to send is received, the session can
continue without error.