|
|
|
|
This appendix describes the primary return codes (and, if applicable, secondary return codes) that are common to several APPC verbs.
Verb-specific return codes are described in the documentation for the individual verbs.
Common return codes are described in the following sections.
The primary and secondary return codes are:
Possible values are:
The conversation cannot be allocated because of a permanent condition, such as a configuration error or session protocol error. To determine the error, the System Administrator should examine the error log file. Do not attempt to retry the allocation until the error has been corrected.
The conversation could not be allocated because of a temporary condition, such as a link failure. The reason for the failure is logged in the system error log. Retry the allocation, preferably after a timeout to allow the condition to clear.
The partner LU or TP does not support the conversation type (basic or mapped) specified in the allocation request.
The allocation request specified PIP data, but the partner TP did not accept it. This may be because the partner TP does not require this data, because it is using an APPC implementation which does not support receiving PIP data, or because the partner is a CPI-C application (CPI-C does not support PIP data).
The partner TP requires PIP data; but the allocation request specified either no PIP data or an incorrect number of parameters.
The user ID or password specified in the allocation request was not accepted by the partner LU.
The partner TP does not support the sync_level
(
The partner LU does not recognize the TP name specified in the allocation request.
The remote LU rejected the allocation request because it was unable to start the requested partner TP. The condition is permanent. The reason for the error may be logged on the remote node. Do not retry the allocation until the cause of the error has been corrected.
The remote LU rejected the allocation request because it was unable to start the requested partner TP. The condition may be temporary, such as a timeout. The reason for the error may be logged on the remote node. Retry the allocation, preferably after a timeout to allow the condition to clear.
The remote LU rejected the allocation request due to a protocol violation.
The remote LU rejected the allocation request because the password provided is no longer valid.
The remote LU rejected the allocation request because the password is not valid.
The remote LU rejected the allocation request because the user ID is no longer valid.
The remote LU rejected the allocation request because the user ID is not valid.
The remote LU rejected the allocation request because a user ID was not specified but is required.
The remote LU rejected the allocation request because a password was not specified but is required.
The remote LU rejected the allocation request because the group is not valid.
The remote LU rejected the allocation request because the user ID is no longer in the group.
The remote LU rejected the allocation request because the user ID is not in the group.
The remote LU rejected the allocation request because the user ID is not authorized to start this TP at the remote LU.
The remote LU rejected the allocation request because the user ID is not authorized to start this TP from the local LU.
The remote LU rejected the allocation request because the user ID is not authorized to start this TP.
The remote LU rejected the allocation request because it failed to install a required exit.
The remote LU rejected the allocation request because of a processing failure at the remote LU.
Because providing detailed information about security failures is a potential security flaw, it is possible to turn off support for these AP_SEC_BAD_* return codes. If this is done, all of these errors are reported to the application as AP_SECURITY_NOT_VALID. See the define_defaults command in the SNAP-IX Administration Command Reference and DEFINE_DEFAULTS NOF verb in the SNAP-IX NOF Programmer's Guide for details.
|
|
|
|
|