The third parameter represents a pointer to an integer flag. A nonzero value sets the socket to generate SIGIO signals, while a zero value sets the socket to not generate SIGIO signals. Note that before the SIGIO signals can be delivered, you must use either the FIOSETOWN or SIOCSPGRP ioctl() request, or the F_SETOWN fcntl() command to set a process ID or a process group ID to indicate what process or group of processes will receive the signal. Once conditioned to send SIGIO signals, a socket will generate SIGIO signals whenever certain significant conditions change on the socket. For example, SIGIO will be generated when normal data arrives on the socket, when out-of-band data arrives on the socket (in addition to the SIGURG signal), when an error occurs on the socket, or when end-of-file is received on the socket. It is also generated when a connection request is received on the socket (if it is a socket on which the listen() verb has been done). Also note that a socket can be set to generate the SIGIO signal by using the fcntl() command F_SETFL with a flag value specifying FASYNC.

If the open instance represented by the descriptor is in binary mode (the open() did not specify the O_TEXTDATA open flag), the open instance CCSID returned is equal to the object CCSID returned.

The third parameter represents a pointer to a signed integer that will contain the process ID or the process group ID to which the socket is currently sending asynchronous signals such as SIGURG. A process ID is returned as a positive integer, and a process group ID is specified as a negative integer. A 0 value returned indicates that no asynchronous signals can be generated by the socket. A positive or a negative value indicates that the socket has been set to generate SIGURG signals.

The third parameter represents a pointer to a signed integer that contains the process ID or the process group ID to which the socket should send asynchronous signals such as SIGURG. A process ID is specified as a positive integer, and a process group ID is specified as a negative integer. Specifying a 0 value resets the socket such that no asynchronous signals are delivered. Specifying a process ID or a process group ID requests that sockets begin sending the SIGURG signal to the specified ID when out-of-band data arrives on the socket.

The third parameter represents a pointer to the structure rtentry, which is defined in <net/route.h>:

      struct rtentry [
         struct sockaddr rt_dst;
         struct sockaddr rt_mask;
         struct sockaddr rt_gateway;
         int rt_mtu;
         u_short rt_flags;
         u_short rt_refcnt;
         u_char rt_protocol;
         u_char rt_TOS;
         char rt_if[IFNAMSIZ];
      ];

The rt_dst, rt_mask, and rt_gateway fields are the route destination address, route address mask, and gateway address, respectively. rt_mtu is the maximum transfer unit associated with the route. rt_flags contains flags that give some information about a route (for example, whether the route was created dynamically, whether the route is usable, type of route, and so on). rt_refcnt indicates the number of references that exist to the route entry. rt_protocol indicates how the route entry was generated (for example, configuration, ICMP redirect, and so on). rt_tos is the type of service associated with the route. rt_if is a NULL-terminated string that represents the interface IP address in dotted decimal format that is associated with the route.

To add a route, the following fields must be set:

• rt_dst
• rt_mask
• rt_gateway
• rt_tos
• rt_protocol
• rt_mtu (Setting the rt_mtu value to zero essentially means use the MTU from the associated line description used when the route is bound to an IFC.)
• rt_if (rt_if can be set to the dotted decimal equivalent of INADDR_ANY, which is 0.)

In addition, the rt_flags bit flags can be set to the following:

• RTF_NOREBIND_IFC_FAIL if no rebinding of the route is to occur when the interface associated with the route fails.
• RTF_NOREBIND_IFC_ACTV if no rebinding is to occur when interfaces are activated or deactivated.

To delete a route, the following fields must be set:

• rt_dst
• rt_mask
• rt_gateway
• rt_tos
• rt_protocol

All other fields are ignored when adding or removing an entry.

The third parameter represents a pointer to an integer flag. If the socket's read pointer is currently at the out-of-band mark, the flag is set to a nonzero value. If it is not, the flag is set to zero.

See SIOCADDRT for more information on the third parameter.

The third parameter represents a pointer to the structure ifreq, defined in <net/if.h>:

      struct ifreq {
         char ifr_name[IFNAMSIZE];
         union {
          struct sockaddr ifru_addr;
          struct sockaddr ifru_mask;
          struct sockaddr ifru_broadaddr;
          short ifru_flags;
          int ifru_mtu;
          int infu_rbufsize;
          char ifru_linename[10];
          char ifru_TOS;
         } ifr_ifru;
      };

ifr_name is the name of the interface for which information is to be retrieved. The i5/OS implementation requires this field to be set to a NULL-terminated string that represents the interface IP address in dotted decimal format. Depending on the request, one of the fields in the ifr_ifru union will be set upon return from the ioctl() call. ifru_addr is the local IP address of the interface. ifru_mask is the subnetwork mask associated with the interface. ifru_broadaddr is the broadcast address. ifru_flags contains flags that give some information about an interface (for example, token-ring routing support, whether interface is active, broadcast address, and so on). ifru_mtu is the maximum transfer unit configured for the interface. ifru_rbufsize is the reassembly buffer size of the interface. ifru_linename is the line name associated with the interface. ifru_TOS is the type of service configured for the interface.

See SIOCGIFADDR for more information on the third parameter.

The third parameter represents a pointer to the structure ifconf, defined in <net/if.h>:

      struct ifconf [
         int ifc_len;
         int ifc_configured;
         int ifc_returned;
         union {
          caddr_t ifcu_buf;
          struct ifreq *ifcu_req;
         } ifc_ifcu;
      ];

ifc_len is a value-result field. The caller passes the size of the buffer pointed to by ifcu_buf. On return, ifc_len contains the amount of storage that was used in the buffer pointed to by ifcu_buf for the interface entries. ifc_configured is the number of interface entries in the interface list. ifc_returned is the number of interface entries that were returned (this is dependent on the size of the buffer pointed to by ifcu_buf). ifcu_buf is the user buffer in which a list of interface entries will be stored. Each stored entry will be an ifreq structure.

To get the interface configuration list, the following fields must be set:

• ifc_len
• ifcu_buf
  
  

See SIOCGIFADDR for more information on the list of ifreq structures returned. For this request, the ifr_name and ifru_addr fields will be set to a value.

Note: Additional information about each individual interface can be obtained using these values and the other interface-related requests.

See SIOCGIFADDR for more information on the third parameter.

See SIOCGIFADDR for more information on the third parameter.

See SIOCGIFADDR for more information on the third parameter.

See SIOCGIFADDR for more information on the third parameter.

See SIOCGIFADDR for more information on the third parameter.

See SIOCGIFADDR for more information on the third parameter.

See FIOGETOWN for more information on the third parameter.

For the SIOCGRTCONF request, the third parameter represents a pointer to the structure rtconf, also defined in <net/route.h>:

      struct rtconf [
         int rtc_len;
         int rtc_configured;
         int rtc_returned;
         union {
          caddr_t rtcu_buf;
          struct rtentry *rtcu_req;
         } rtc_rtcu;
      ];

rtc_len is a value-result field. The caller passes the size of the buffer pointed to by rtcu_buf. On return, rtc_len contains the amount of storage that was used in the buffer pointed to by rtcu_buf for the route entries. rtc_configured is the number of route entries in the route list. rtc_returned is the number of route entries that were returned (this is dependent on the size of the buffer pointed to by rtcu_buf). rtcu_buf is the user buffer in which a list of route entries will be stored. Each stored entry will be an rtentry structure.

To get the route configuration list, the following fields must be set:

• rtc_len
• rtcu_buf
  
  

See SIOCADDRT for more information on the list of rtentry structures returned. For this request, all fields in each rtentry structure will be set to a value.

The third parameter represents a pointer to an integer that is set to the number of bytes yet to be acknowledged as being received by the remote TCP transport driver.

Notes:

1. SIOCSENDQ is used after a series of blocking or non-blocking send operations to see if the sent data has reached the transport layer on the remote system. Note that this does not not guarantee the data has reached the remote application.
   
   
2. When SIOCSENDQ is used in a multithreaded application, the actions of other threads must be considered by the application. SIOCSENDQ provides a result for a socket descriptor at the given point in time when the ioctl()) request is received by the TCP transport layer. Blocking send operations that have not completed, as well as non-blocking send operations in other threads issued after the SIOCSENDQ ioctl(), are not reflected in the result obtained for the SIOCSENDQ ioctl().
   
   
3. In a situation where the application has multiple threads sending data on the same socket descriptor, the application should not assume that all data has been received by the remote side when 0 is returned if the application is not positive that all send operations in the other threads were complete at the time the SIOCSENDQ ioctl() was issued. An application should issue the SIOCSENDQ ioctl() only after it has completed all of the send operations. No value is added by querying the machine to see if it has sent all of the data when the application itself has not sent all of the data in a given unit of work.

See FIOSETOWN for more information on the third parameter.

If you are accessing a remote file through the Network File System, update operations to file permissions at the server are not reflected at the client until updates to data that is stored locally by the Network File System take place. (Several options on the Add Mounted File System (ADDMFS) command determine the time between refresh operations of local data.) Access to a remote file may also fail due to different mappings of user IDs (UID) or group IDs (GID) on the local and remote systems.

If you are accessing a remote file through the Network File System, the file may have been deleted at the server.