Each generic data link control (GDLC) provides problem determination data that can be used to isolate network problems. Four types of diagnostic information are provided:
Status information can be obtained for a service access point (SAP) or a link station (LS) using the DLC_QUERY_SAP and DLC_QUERY_LS ioctl subroutines to call the specific DLC kernel device manager in use.
The DLC_QUERY_SAP ioctl subroutine obtains individual device driver statistics from various devices:
The DLC_QUERY_LS ioctl subroutine obtains LS statistics from various DLCs. These statistics include data link protocol counters. Each counter is reset by the DLC during the DLC_START_LS ioctl subroutine and generally runs continuously until the LS is terminated and its storage is freed. If a counter reaches the maximum count, the count is frozen and no wraparound occurs.
The suggested counters provided by a DLC device manager are listed as
follows. Some DLCs can modify this set of counters based on the
specific protocols supported. For example, the number of rejects or
receive-not-ready packets received might be meaningful.
| test commands sent | Contains a binary count of the test commands sent to the remote station by GDLC, in response to test commands issued by the user. |
| test command failures | Contains a binary count of the test commands that did not
complete properly due to problems such as:
|
| test commands received | Contains a binary count of valid test commands received, regardless of whether the response is completed correctly. |
| sequenced data packets transmitted | Contains a binary count of the total number of normal sequenced data packets transmitted to the remote LS. |
| sequenced data packets retransmitted | Contains a binary count of the total number of normal sequenced data packets retransmitted to the remote LS. |
| maximum contiguous retransmissions | Contains a binary count of the maximum number of times a single data packet has been retransmitted to the remote LS before acknowledgment. This counter is reset each time a valid acknowledgment is received. |
| sequenced data packets received | Contains a binary count of the total number of normal sequenced data packets correctly received. |
| invalid packets received | Contains a binary count of the number of invalid commands or responses received, including invalid control bytes, incorrect I-fields, and overflowed I-fields. |
| adapter-detected receive errors | Contains a binary count of the number of receive errors reported back from the device driver. |
| adapter-detected transmit errors | Contains a binary count of the number of transmit errors reported back from the device driver. |
| receive inactivity timeouts | Contains a binary count of the number of receive time outs that have occurred. |
| command polls sent | Contains a binary count of the number of command packets sent that requested a response from the remote LS. |
| command repolls sent | Contains a binary count of the total number of command packets retransmitted to the remote LS due to a lack of response. |
| command contiguous repolls | Contains a binary count of the number of times a single command packet was retransmitted to the remote LS due to a lack of response. This counter is reset each time a valid response is received. |
Each DLC provides entries to the system error log whenever errors are encountered. To call the kernel error collector, use the errsave kernel service.
The error conditions are reported by the system-product error log using the error log daemon (errdemon).
The user can obtain formatted error-log data by issuing the errpt command. When used with the
-N DLCName flag, the errpt command produces a
summary report of all the error log entries for the resource name indicated by
the DLCName parameter. Valid values for the
DLCName parameter include:
| SYSXDLCE | Indicates a Standard Ethernet datalink. |
| SYSXDLCI | Indicates an IEEE 802.3 Ethernet datalink. |
| SYSXDLCT | Indicates a token-ring datalink. |
| SYSXDLCS | Indicates an synchronous data link control (SDLC) datalink. |
The format of each required alert vector can be found in Appendix A of SNA Format and Protocol Reference Manual: Management Services (SC30-3346).
For more information on the error log facility, refer to Error Logging Overview in Messages Guide and Reference.
GDLC provides optional entries to a generic system trace channel as required by the system product Reliability/Availability/Serviceability (RAS). The default is trace-disabled, provides maximum performance, and reduces the number of system resources used. For information on additional trace facilities, see LAN Monitor Trace.
The operating system supports up to seven generic trace channels in operation at the same time. Before starting an LS trace, a user must allocate a channel with the DLC_START_LS ioctl operation or the DLC_TRACE ioctl operation. Begin the trace sessions with the trcstart and trcon subroutines.
Trace activity in the LS must be stopped either by halting the LS or by issuing an ioctl (DLC_TRACE, flags=0) operation to that station. When the LS stops tracing, the channel is disabled with the trcoff subroutine and returned to the system with the trcstop subroutine.
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 via configuration, or it can be dynamically activated or terminated via ioctl at any time afterward.
The user can obtain formatted trace log data by issuing the trcrpt command with the appropriate file name, such as:
trcrpt /tmp/link1.log
This example produces a detailed report of all link trace entries in the /tmp/link1.log file, provided a prior trcstart subroutine specified the /tmp/link1.log file as the -o name for the trace log.
For each trace entry, GDLC generates the trcgenkt kernel service to the kernel generic trace.
Each of the local area network data link controls (DLCETHER, DLC8023, DLCFDDI, and DLCTOKEN) provides an internal monitor trace capability that can be used to identify the execution sequence of pertinent entry points within the code. This is useful if the network is having problems that indicate the data link is not operating properly, and the sequence of events may indicate the cause of the problems. This trace is shared among the LAN data link controls, and inactive is the default.
The LAN monitor trace can be enabled by issuing the following command:
trace -j 246
where 246 is the hook ID to be traced.
Tracing can be stopped with the trcstop command and a report can be obtained with the following command:
trcrpt -d 246
where 246 is the hook ID of the trace for which you want a report.
Note: Exercise caution when enabling the monitor trace, since it directly affects the performance of the DLCs and their associates.
For information on additional ways to use trace facilities, see Managing DLC Device Drivers.