 |
» |
|
|
 |
Your program detects errors in two locations. Function Return Values (includes Event
Management (EM) values)
Function Return Values |  |
Function return values indicate whether an error occurred. Function return values return in the
program as integers. These values may occur because of errors on previous
calls. For example, if the first call within a group fails, thereafter
every function within the group fails. The value zero indicates SUCCESS.
Refer to the HP FTAM/9000 Reference Manual
for a list of function return values. Output Errors |  |
Information returned in the inout_dcb fields may be defined
by MAP 3.0 FTAM, HP-UX FTAM, FTAM Protocol Machine (FPM), or the
VFS. Errors detected by the interface, an ftam_init, or an FTAM
responder are mapped to MAP 3.0 FTAM errors and returned to the
user program. The inout_dcb->result.return_code
contains the MAP 3.0 FTAM error. To receive a printable character string and a log
instance, call ft_gperror().
Refer to the HP FTAM/9000 Reference Manual
for a list of MAP 3.0 FTAM errors and possible corrective actions. Errors detected by the interface, an ftam_init, or an FTAM
responder may contain HP-UX FTAM implementation-specific error information
that is returned to the user program. The vendor_code contains both
HP-UX—specific error information (lower 16 bits) and the
log instance (upper 16 bits). The inout_dcb->result.vendor_code
contains the vendor errors; however, not all errors returning in
inout_dcb->result have an accompanying vendor_code. To receive a printable character string and a log
instance, call ft_gperror(). The vendor_code frequently provides additional information
when errors return on HLCF functions.
Many vendor_codes indicate internal errors that require HP
support assistance. Refer first, however, to the HP FTAM/9000
Reference Manual for a list of HP-UX—specific
errors and possible corrective actions. FPM errors are generated in the FTAM protocol machine and
VFS errors are generated in the Virtual Filestore. Both FPM or VFS
errors return an action_result, and may optionally return a state_result
or diagnostic. The action_result reflects the overall success or failure
of the request and returns as either FT_AR_SUCCESS or FT_AR_PERMANENT_ERROR,
respectfully. enum Ft_action_result { FT_AR_SUCCESS=0, FT_AR_TRANSIENT_ERROR=1, FT_AR_PERMANENT_ERROR=2 }; |
The state_result indicates whether the FPM made the regime
change and returns as either FT_SR_SUCCESS or FT_SR_FAILURE. enum Ft_state_result { FT_SR_SUCCESS=0, FT_SR_FAILURE=1 }; |
The diagnostic reflects the information defined by ISO/IS
8571.
The diagnostic may be informational only or it may be error information
that elaborates on the action_result. (Refer to Figure 9-2 “inout_dcb->diagnostic”.) The diagnostic->error_id is the error
identifier that returns in the Ft_diagnostic structure. For a character string describing the error, check
the diagnostic->further_details field for additional information. Multiple ISO errors may be represented by a single
MAP error; more than one diagnostic may return. Multiple FPM errors may occur on one call and are
represented by a linked list of inout_dcb->diagnostic structures.
Refer to the HP FTAM/9000 Reference Manual
for a list of diagnostic->error_ids. struct Ft_diagnostic { struct Ft_diagnostic *next; enum Ft_diag_type diag_type; Uint16 error_id; enum Ft_entity_ref error_observer; enum Ft_entity_ref error_source; Uint16 suggested_delay; char *further_details; }; |
enum FT_diag_type { FT_INFORMATIVE = 0, FT_TRANSIENT = 1, FT_PERMANENT = 2 }; |
enum FT_entity_ref { FT_NOT_CATEGORIZED = 0, FT_INITIATING_FILE_SERVICE_USER = 1, FT_INITIATING_FILE_PROTOCOL_MACHINE = 2, FT_SERVICE_SUPPORTING_FILE_PROTOCOL_MACHINE = 3, FT_RESPONDING_FILE_PROTOCOL_MACHINE = 4, FT_RESPONDING_FILE_SERVICE_USER = 5 }; |
enum Ft_entity_ref { FT_NOT_CATEGORIZED = 0, FT_INITIATING_FILE_SERVICE_USER = 1, FT_INITIATING_FILE_PROTOCOL_MACHINE = 2, FT_SERVICE_SUPPORTING_FILE_PROTOCOL_MACHINE = 3, FT_RESPONDING_FILE_PROTOCOL_MACHINE = 4, FT_RESPONDING_FILE_SERVICE_USER = 5 }; |
|