There are a number of ways that you can control the operation of your system's communications controller from a program. Programs may be considered to be of two forms:
The management functions usually involve determining protocol statistics which are available to users through the nma library.
In addition to the facilities for moving data, Netcom II provides the following additional control and information gathering capabilities to programs:
The on-line X.25 parameter reconfiguration facility reduces the impact on users of a multi-link system when one link needs to be reconfigured. Restarting the X.25 communications software with x25net disconnects all conversations in progress, on all the links connected to a given controller. You can use the reconfiguration capability to change X.25 parameters on a single link, disrupting fewer users than if reconfiguration required a complete restart.
The X25daemon which is part of the Netcom II product release, is a table-driven utility for handling incoming Switched Virtual Circuit calls. However, if it does not address some part of your requirement for incoming call handling, you can write a custom incoming call handler or obtain source for TSG's X25daemon under license to address your needs.
Netcom II collects statistical and call setup information on all X.25 Switched Virtual Circuit calls, making it available to an application when the call is cleared. The information includes both traffic statistics as well as data on how and where the call originated - facilities granted, remote address, and so on. You can use the X25_CALLINFO_REQ ioctl to obtain information such as the calling X.25 address.
As well as traffic and accounting statistics, Netcom II maintains counts of important protocol events at various levels such as CRC errors, the state of EIA lines, and so on.The X25_STATS ioctl command is provided for obtaining this information.
If your application requires close control of X.25 protocol, there is an interface library. The library uses Streams programming constructs to provide programs with X.25 services. The underlying operating system construct is a putmsg() call, which does not return protocol status information. Therefore, library programmers should use the poll() or select() system call to check for operational status between successive calls which send packets. poll() and select() block the calling process until an event occurs which the process needs to be informed about. The alternative is a busy loop, which is not recommended for multi-user/multi-tasking computer systems.
Netcom II virtual circuits are accessed by separate devices. Normally, one process controls one virtual circuit. This allows the scheduler to control the sharing of the CPU between virtual circuits, as it would for standard async login, or for login over Netcom II X.25 devices.
If your application wishes to operate multiple virtual circuits, "status looping" (testing each virtual circuit in turn for an event) is a possible alternative. It is not recommended that you use status loops to control multiple virtual circuits, as your looping X.25 handling process will have a detrimental effect on the performance of the system. For these applications, the poll() or select() verbs can be used to wait for events on any number of virtual circuits. Support for select varies with the operating system you are using, so refer to the operating system documentation for details. If select is unavailable, or not suitable for your purposes, you can use poll() in conjunction with the application interface library.
Copyright © 1997-2003 The Software Group Limited. All Rights Reserved.
® Netcom is a registered trademark of The Software Group Limited.