TCP/IP Programming Manual

the text message associated with the current error to the standard C error file (the file named
stderr).
The text message description of each routine lists most error numbers that can be returned in errno
on a call to the particular routine. A complete list of socket errors and their meanings is given in
Appendix B (page 243). You must interpret the meaning of each error according to the type of call
and the circumstances in which your program issues the call. For more information, see Asynchrony
and Nowaited Operations (page 34).
NOTE: The perror function is not supported for TAL sockets.
Nowait Call Errors
The nowait versions of the routines return an error in the file-system variable. Call FILE_GETINFO_
procedure after calls to either AWAITIOX or FILE_AWAITIO64_ to get the error. You must set
this error in the errno variable in the application.
NOTE: When you initiate a nowait call, errno is set to reflect any error detected upon initiation.
If errno is nonzero after initiation, your program should not call the AWAITIOX procedure because
the operation is not successfully initiated.
Socket error numbers are in the range reserved by the NonStop operating system for
application-defined errors. These do not conflict with the range the operating system has reserved
for file-system errors. However, it is possible to get regular NonStop operating system file-system
errors that pertain to interprocess I/O, because the socket routines are built on NonStop operating
system interprocess I/O. For descriptions of these interprocess I/O errors, refer to the Guardian
Procedure Calls Reference Manual.
The gethostbyname, gethostbyaddr, host_file_gethostbyname, and
host_file_gethostbyaddr support routines indicate an error value in another external variable,
h_errno. If you bypass the Domain Name resolver code, the only possible nonzero (error) value
of h_errno is HOST_NOT_FOUND(1). If you use the resolver code, four error values are possible.
These errors are described with the functions gethostbyaddr and gethostbyname, in this
section.
Interfacing TAL Programs to the Socket Library
NOTE: For more information about socket library support for TAL and pTAL applications, see
TALDOCUM in $system.ztcpip.
A program is considered a TAL program if its MAIN section is written in TAL. A program that has
a C main section but calls TAL procedures is not bound by the requirements given in this subsection.
The topics covered include:
• Implications of the C socket library
• Startup considerations
• Bind considerations
• CRE considerations
Any experience writing C language socket code is applicable to writing TAL socket code. All the
functions, parameters, data structures, and return codes are the same in TAL as they are in C. The
differences are only a matter of TAL syntax.
NOTE: Use the Common Run-Time Environment (CRE) when developing TAL socket applications.
CRE is described in the CRE Programming Manual.
86 Library Routines