# Compaq TCP/IP Services for OpenVMS
Sockets API and System Services Programming

Previous | Contents | Index

# Appendix B
IOCTL Requests

The `ioctl()` Sockets API function and the IO$_SENSEMODE/IO$_SENSECHAR and IO$_SETMODE/IO$_SETCHAR I/O function codes used with the $QIO system service perform I/O control functions on a network device (BG:).

Table B-1 lists the IOCTL requests supported by TCP/IP Services, their data types, the $QIO function code to use if using system services, and a description of the operation.

Table B-1 IOCTL Requests
IOCTL Request | Data Type | $QIO Function Code | Description
--- | --- | --- | ---
Socket Operations |  |
SIOCSHIWAT | int | IO$_SETMODE | Set high watermark.
SIOCGHIWAT | int | IO$_SENSEMODE | Get high watermark.
SIOCSLOWAT | int | IO$_SETMODE | Set low watermark.
SIOCGLOWAT | int | IO$_SENSEMODE | Get low watermark.
SIOCATMARK | int | IO$_SENSEMODE | Determines whether you are at the out-of-band character mark. The operation returns a nonzero value if the socket's read pointer is currently at the end-of-band mark or a zero value if the read pointer is not at the out-of-band mark. The value is returned in the integer pointed to by the third argument of the `ioct()` call.
Interface Operations |  |
SIOCSIFADDR | struct ifreq 1 | IO$_SETMODE | Sets the interface address from the `ifr_addr` member. The initialization function for the interface is also called.
SIOCSIFDSTADDR | struct ifreq | IO$_SETMODE | Sets the point-to-point address from the `ifr_dstaddr` member.
SIOCSIFFLAGS | struct ifreq | IO$_SETMODE | Sets the interface flags from the `ifr_flags` member.
SIOCGIFFLAGS | struct ifreq | IO$_SENSEMODE | Returns the interface flags in the `ifr_flags` member. The flags indicate whether the interface is up ( `IFF_UP` ), is a point-to-point interface ( `IFF_POINTOPOINT` ), supports broadcasts ( `IFF_BROADCAST` ), and other flags.
SIOCSIFBRDADDR | struct ifreq | IO$_SETMODE | Sets the broadcast address from the `ifr_broadaddr` member.
SIOCSIFNETMASK | struct ifreq | IO$_SETMODE | Sets the subnet address mask from the `ifr_addr` member.
SIOCGIFMETRIC | struct ifreq | IO$_SENSEMODE | Returns the interface routing metric in the `ifr_metric` member. The interface metric is maintained by the kernel for each interface but is used by the routing daemon ( `routd` ). The interface metric is added to the hop count (to make an interface less favorable).
SIOCSIFMETRIC | struct ifreq | IO$_SETMODE | Sets the interface routing metric from the `ifr_metric` member.
SIOCDIFADDR | struct ifreq | IO$_SETMODE | Deletes an interface address
SIOCAIFADDR | struct ifaliasreq 1 | IO$_SETMODE | Adds or changes an interface alias.
SIOCPIFADDR | struct ifaliasreq | IO$_SETMODE | Sets the primary interface address.
SIOCADDMULTI | struct ifreq | IO$_SETMODE | Adds a multicast address.
SIOCDELMULTI | struct ifreq | IO$_SETMODE | Deletes a multicast address.
SIOCENABLBACK | struct ifreq | IO$_SETMODE | Enables the loopback interface.
SIOCDISABLBACK | struct ifreq | IO$_SETMODE | Disables the loopback interface.
SIOCSIPMTU | struct ifreq | IO$_SETMODE | Sets the interface IP MTU value.
SIOCRIPMTU | struct ifreq | IO$_SENSEMODE | Returns the interface IP MTU value.
SIOCGIFINDEX | struct ifreq | IO$_SENSEMODE | Returns the IF index value.
SIOCGMEDIAMTU | struct ifreq | IO$_SENSEMODE | Returns the value of the media MTU.
SIOCGIFTYPE | struct ifreq | IO$_SENSEMODE | Returns the interface type.
SIOCGIFADDR | struct ifreq | IO$_SENSEMODE | Returns the interface address.
SIOCGIFDSTADDR | struct ifreq | IO$_SENSEMODE | Returns the point-to-point interface address.
SIOCGIFBRDADDR | struct ifreq | IO$_SENSEMODE | Returns the interface broadcast address.
SIOCGIFCONF | struct ifconf 1 | IO$_SENSEMODE | Returns the interface list.
SIOCGIFNETMASK | struct ifreq | IO$_SENSEMODE | Returns the interface subnet address mask.
Routing Table Operations |  |
SIOCADDRT | struct ortentry 2 | IO$_SETMODE | Adds an entry to the routing table.
SIOCDELRT | struct ortentry | IO$_SETMODE | Deletes an entry from the routing table.
ARP Cache Operations |  |
SIOCSARP | struct arpreq 3 | IO$_SETMODE | Adds a new entry to or modifies an existing entry in the ARP table.
SIOCDARP | struct arpreq | IO$_SETMODE | Deletes an entry from the ARP table.
SIOCGARP | struct arpreq | IO$_SENSEMODE | Returns an ARP table entry.

1Defined in the IF.H header file.
2Defined in the ROUTE.H header file.
3Defined in the IF_ARP.H header file.

# Appendix C
Data Types

As part of the OpenVMS common language environment, the TCP/IP system services data types provide compatibility between procedure calls that support many different high-level languages. Specifically, the OpenVMS data types apply to both Alpha and VAX architectures as the mechanism for passing argument data between procedures. This appendix describes the context and structure of the TCP/IP system services data types and identifies the associated declarations to each of the specific high-level language implementations.

# C.1 OpenVMS Data Types

In Chapter 6, the OpenVMS usage entry in the TCP/IP Services documentation format for system services indicates the OpenVMS data type of the argument. Most data types can be considered conceptual types; that is, their meaning is unique in the context of the OpenVMS operating system. The OpenVMS data type `access_mode` is one example. The storage representation of this OpenVMS type is an unsigned byte, and the conceptual content of this unsigned byte is the fact that it designates a hardware access mode and therefore has only four valid values: 0, kernel mode; 1, executive mode; 2, supervisor mode; and 3, user mode. However, some OpenVMS data types are not conceptual types; that is, they specify a storage representation but carry no other semantic content in the OpenVMS context. For example, the data type `byte_signed` is not a conceptual type.

Note The OpenVMS usage entry is not a traditional data type such as the OpenVMS standard data types---byte, word, longword, and so on. It is significant only within the OpenVMS operating system environment and is intended solely to expedite data declarations within application programs.

To use the OpenVMS usage entry, perform the following steps:

1. Find the data type in Table C-1 and read its definition.
2. Find the same OpenVMS data type in the C and C++ language implementation table (Table C-2) and its corresponding source language type declaration.
3. Use this code as your type declaration in your application program. Note that, in some instances, you might have to modify the declaration.
4. For all other OpenVMS data types not listed in Table C-2, refer to Appendix F of the OpenVMS Programming Concepts, Volume 2 manual.

For both Alpha and VAX architectures, Table C-1 lists and describes OpenVMS data type declarations for the OpenVMS usage entry of system services unique to TCP/IP Services.

Table C-1 TCP/IP Services Usage Data Type Entries
Data Type | Definition
--- | ---
`buffer_list` | Structure that consists of one or more descriptors defining the length and starting address of user buffers. On VAX systems, each descriptor is a 32-bit fixed-length descriptor. On Alpha systems, each descriptor can be a 32- or 64-bit fixed-length descriptor. For more information concerning descriptors, see the OpenVMS Calling Standard.
`input_parameter_list` | Structure that consists of one or more `item_list_2` or `ioctl_comm` structures. Each `item_list_2` structure describes an individual parameter that can be set by a service. Such parameters include socket or protocol options as identified by the item's type field. Each `ioctl_comm` structure describes an IOCTL command; its encoded request code and address of its associated argument.
`ioctl_comm` | Quadword structure that describes an IOCTL command's encoded request code and address of its associated argument. It contains two longword fields, as depicted in the following diagram: The first field is a longword containing the IOCTL encoded request code specifying the type of I/O control operation to be performed. The second field is a longword containing the address of a variable or a data structure targeted by this IOCTL command.
`item_list_2` | Quadword structure that describes the size, data type, and starting address of a user-supplied data item. It contains three fields, as depicted in the following diagram: The first field is a word containing the length (in bytes) of the user-supplied data item being described. The second field is a word containing a symbolic code specifying the data type of the user-supplied data item. The third field is a longword containing the starting address of the user-supplied data item.
`item_list_2 descriptor` | An `item_list_2` structure, used as an argument descriptor and containing structural information about the argument's type and the address of a data item. This data item is associated with the argument. The format of this descriptor is unique to TCP/IP Services and supplements argument descriptors defined in the OpenVMS Calling Standard.
`item_list_3` | A 3-longword structure that describes the size, data type, and address of a buffer in which a service writes information. It contains four fields, as depicted in the following diagram: The first field is a word containing the length (in bytes) of the buffer in which a service writes information. The length of the buffer needed depends on the data type specified in the type field. If the value of buffer length is too small, the service truncates the data. The second field is a word containing a symbolic code and specifies the type of information that a service is to return. The third field is a longword containing the address of the buffer in which a service writes the information. The fourth field is a longword containing the address of a longword in which a service writes the length in bytes of the information it actually returned.
`item_list_3 descriptor` | An `item_list_3` structure, used as an argument descriptor and containing structural information about the argument's type and the address of a buffer used to return service information. This buffer is associated with the argument. The format of this descriptor is unique to TCP/IP Services and supplements argument descriptors defined in the OpenVMS Calling Standard.
`output_parameter_list` | Structure that consists of one or more `item_list_3` or `ioctl_comm` structures. Each `item_list_3` structure describes an individual parameter that can be returned by a service. Such parameters include socket or protocol options as identified by the item's type field. Each `ioctl_comm` structure describes an IOCTL command, its encoded request code, and the address of its associated argument.
`socket_name` | Internet domain socket address structure that consists of a internet address and a port number. The layout of socket address structures varies between BSD Version 4.3 and BSD Version 4.4. BSD Version 4.3 specifies a 16-byte socket address structure. It contains four fields, as depicted in the following diagram: The first field is a word identifying a socket address structure as belonging to the internet domain (always a value of 2). The second field is a word containing a 16-bit port number (stored in network byte order) used to demultiplex transport-level messages. The third field is a longword containing a 32-bit internet address (stored in network byte order). The fourth field is a quadword. It is unused but must be initialized to all zeros. BSD Version 4.4 specifies a 16-byte socket address structure. It contains five fields, as depicted in the following diagram: The first field is a byte containing the size of this socket address structure (always a value of 16). The second field is a byte identifying a socket address structure as belonging to the internet domain (always a value of 2). The third field is a word containing a 16-bit port number (stored in network byte order) used to demultiplex transport-level messages. The fourth field is a longword containing a 32-bit internet address (stored in network byte order). The fifth field is a quadword. It is unused but must be initialized to all zeros.
`subfunction_code` | Longword structure specifying the exact operation an IO$_ACPCONTROL function is to perform. This structure has three fields, as depicted in the following diagram: The first field is a byte specifying the network ACP operation. The second field is a byte specifying the network ACP suboperation. The third field is word that is unused but must be initialized to all zeros (MBZ).
`socket_characteristics` | Longword structure specifying the address family, socket type, and protocol of a new socket. This structure has three fields, as depicted in the following diagram: The first field is a word specifying the protocol to be used with the socket. The second field is a byte specifying the socket type. The third field is a byte specifying the address family.

# C.2 C and C++ Implementations

Table C-2 lists the OpenVMS data types and their corresponding C and C++ data type declarations.

Table C-2 C and C++ Implementations
OpenVMS Data Types | C an C++ Implementations
--- | ---
`buffer_list` | User defined 1
`input_parameter_list` | User defined 1
`ioctl_comm` | `struct ioctl_comm { int ioctl_req; /* ioctl request code */ void *ioctl_arg; /* ioctl argument */ }`
`item_list_2` | `struct item_list_2 { unsigned short length; /* item length */ unsigned short type; /* item type */ void *address; /* item address */ }`
`item_list_2 descriptor` | `struct item_list_2 { unsigned short length; /* argument length */ unsigned short type; /* argument type */ void *address; /* argument address */ }`
`item_list_3` | `struct item_list_3 { unsigned short length; /* buffer length */ unsigned short type; /* buffer type */ void *address; /* buffer address */ unsigned int *retlen; /* buffer returned */ /* length address */ }`
`item_list_3 descriptor` | `struct item_list_3 { unsigned short length; /* argument length */ unsigned short type; /* argument type */ void *address; /* argument address */ unsigned int *retlen; /* argument returned */ /* length address */ }`
`output_parameter_list` | User defined 1
`socket_name` | `#include <in.h> struct sockaddr_in`
`subfunction_code` | `struct acpfunc { unsigned char code; /* subfunction code */ unsigned char type; /* call code */ unsigned short reserved; /* reserved */ /* (must be zero) */ }`
`socket_characteristics` | `struct sockchar { unsigned short prot; /* protocol */ unsigned char type; /* type */ unsigned char af; /* address format */ }`

1The declaration of a user-defined data structure depends on how the data will be used. Such data structures can be declared in a variety of ways, each of which is suitable only to specific applications.

Previous | Next | Contents | Index