The generic data link control (GDLC) interface supports the following ioctl subroutine operations:
|DLC_ENABLE_SAP||Enables a service access point (SAP).|
|DLC_DISABLE_SAP||Disables a SAP.|
|DLC_START_LS||Starts a link station on a particular SAP as a caller or listener.|
|DLC_HALT_LS||Halts a link station.|
|DLC_TRACE||Traces a link station's activity for short or long activities.|
|DLC_CONTACT||Contacts a remote station for a particular local link station.|
|DLC_TEST||Tests the link to a remote for a particular local link station.|
|DLC_ALTER||Alters a link station's configuration parameters.|
|DLC_QUERY_SAP||Queries statistics of a particular SAP.|
|DLC_QUERY_LS||Queries statistics of a particular link station.|
|DLC_ENTER_LBUSY||Enters local-busy mode on a particular link station.|
|DLC_EXIT_LBUSY||Exits local-busy mode on a particular link station.|
|DLC_ENTER_SHOLD||Enters short-hold mode on a particular link station.|
|DLC_EXIT_SHOLD||Exits short-hold mode on a particular link station.|
|DLC_GET_EXCEP|| Returns asynchronous
exception notifications to the application user.
Note: This ioctl subroutine operation is not used by the kernel user since all exception conditions are passed to the kernel user through their exception handler.
|DLC_ADD_GRP||Adds a group or multicast receive address to a port.|
|DLC_ADD_FUNC_ADDR||Adds a group or multicast receive functional address to a port.|
|DLC_DEL_FUNC_ADDR||Removes a group or multicast receive functional address from a port.|
|IOCINFO||Returns a structure that describes the GDLC device manager. See the /usr/include/sys/devinfo.h file format for more information.|
A SAP identifies a particular user service that sends and receives a specific class of data. This allows different classes of data to be routed separately to their corresponding service handlers. Those DLCs that support multiple concurrent SAPs have addresses known as Destination SAP and Source SAP imbedded in their packet headers. DLCs that can only support a single SAP do not need or use SAP addressing, but still have the concept of enabling the one SAP. In general, there is a SAP enabled for each DLC user on each port.
Most SAP address values are defined by IEEE standardized network-management entities or user-defined values as specified in the Token-Ring Network Architecture Reference. Some of the common SAP addresses are:
|Null SAP (0x00)||Provides some ability to respond to remote nodes even when no SAP has been enabled. This SAP supports only connectionless service and responds only to exchange identification (XID) and TEST Link Protocol Data Units (LPDUs).|
|SNA Path Control (0x04)||Denotes the default individual SAP address used by Systems Network Architecture (SNA) nodes.|
|PC Network NETBIOS (0xF0)||Used for all DLC communication that is driven by Network Basic Input/Output System (NetBIOS) emulation.|
|Discovery SAP (0xFC)||Used by the local area network (LAN) name-discovery services.|
|Global SAP (0xFF)||Identifies all active SAPs.|
A link station (LS) identifies an attachment between two nodes for a particular SAP pair. This attachment can operate as a connectionless service (datagram) or connection-oriented service (fully sequenced data transfer with error recovery). In general, there is one LS started for each remote attachment.
When an LS is operating in a connection-oriented mode, it needs to stop the remote station's sending of information packets for reasons such as resource outage. Notification can then be sent to the remote station to cause the local station to enter local-busy mode. Once resources are available, the local station notifies the remote that it is no longer busy and that information packets can flow again. Only sequenced information packets are halted with local-busy mode. All other types of data are unaffected.
Use the short-hold mode of operation when operating over data networks with the following characteristics:
During short-hold mode, an attachment between two stations is maintained only while there is data available for transfer between the two stations. When there is no data to send, the attachment is cleared after a specified time-out period and only reestablished when there is new data to transfer.
To test an attachment between two stations, instruct an LS to send a test packet from the local station. This packet is echoed back from the remote station if the attachment is operating correctly.
Some data links are limited in their support of this function due to protocol constraints. SDLC, for example, only generates the test packet from the host or primary station. Most other protocols, however, allow test packets to be initiated from either station.
To trace a link, line data, and special events (such as station activation, termination, and time outs) can be logged in the generic trace facility for each LS. This function helps determine the cause of certain communications attachment problems. The GDLC user can select either short or long entries to be traced.
Short entries consist of up to 80 bytes of line data, while long entries allow full packets of data to be traced.
Tracing can be activated when an LS is started, or it can be dynamically activated or terminated at any time afterward.
Both SAP and LS statistics can be queried by a GDLC user. The statistics for a SAP consist of the current SAP state and information about the device handler. LS statistics consist of the current station states and various reliability, availability, and serviceability counters that monitor the activity of the station from the time it is started.