ddfa(7)ddfa(7)NAMEddfa - Data Communications and Terminal Controller (DTC) Device File
Access (DDFA) software
The Data Communications and Terminal Controller (DTC) Device File
Access (DDFA) software allows access from HP-UX system utilities and
user applications to terminal servers using standard HP-UX structures.
DDFA provides an interface to remote LAN-connected terminal server
ports that is similar to the interface for local directly-connected
The basic principle is that a daemon is created for each configured
terminal server port based on information in a configuration file (a
Dedicated Ports file). When the daemon is spawned, it takes a from the
pool and creates a device file with the same major and minor number as
the slave. The device file is known as the "pseudonym" and utilities
and applications use the pseudonym to access the terminal server port
by exercising standard HP-UX system functions and The daemon listens on
the until an application does an on the pseudonym. It then sets up and
manages the connection to the terminal server port until the applica‐
tion does a on the pseudonym. The end result is that the terminal
server port is addressed via a device file, but the mechanism that
makes it happen is transparent to the user. A second configuration
file (a port configuration file) contains information to profile the
terminal server port.
DDFA consists of the following items:
Dedicated Ports file.
This text file contains the information that DDFA
needs to set up and manage a connection between a
pseudonym and a terminal server port.
The file is parsed by the Dedicated Port Parser
which spawns an Outbound Connection Daemon for
each outbound connection specified in the file.
The file is also used by the HP-UX Telnet daemon
to identify incoming connections from a DTC and
map them to a pseudonym (the Telnet port identi‐
Port Configuration File.
This text file is used by DDFA to profile the
terminal server port. The generic name of the
template file is A port configuration file is
referenced by an entry in the Dedicated Ports
Dedicated Port Parser.
This command parses the Dedicated Ports file and
spawns an Outbound Connection Daemon for each
valid entry in the file. It can be run from the
shell or it can be included in a system initial‐
ization script to automatically run the DDFA
software each time the system is booted.
Outbound Connection Daemon.
This daemon manages the connection and data
transfer to the remote terminal server port.
Normally, it is spawned by the Dedicated Ports
Parser (but it can be run directly from the
As it starts, it creates its pseudonym for the
connection. As it terminates normally, it
removes the pseudonym. If the pseudonym is
removed while it is running, will terminate with
an error condition.
Outbound Connection Daemon debug mode.
This is a special version of that contains debug‐
ging code. It must be run from the shell.
There are two basic steps to configuring the DDFA software:
· Enter information in the file.
· Enter information in the port configuration files.
Configuring the dp File
The file contains one line for each outbound connection that is to be
established and one line for each incoming connection request. A
default file should be copied to a new file and the copy edited as
needed. It is recommended that a directory be created to hold the file
and the port configuration files.
Each line of the file must contain the location of the terminal server
port and the location of the pseudonym. In addition, for an outbound
connection, the port configuration file must be specified and a logging
level may be specified.
Configuring the Port Configuration Files
A port configuration file is used to configure individual terminal
server ports. A master port configuration file is In practice, it is
renamed for each port that needs different configuration values and the
values are altered appropriately for the device attached to the port.
It is recommended that a directory be created to hold the port configu‐
ration files and the file.
Each line of a port configuration file must consist of a name of a
variable and its value. The variable-value pairs contain information
on how to open a connection to a terminal server port, how to close a
connection to a terminal server port, and how to manage the data trans‐
fer to a terminal server port.
Configuring a System Initialization Script
DDFA can be run at boot time by including a reference to in a system
initialization script. It is recommended that the option be used when
running in this environment.
Note that should be killed using Do not use for this purpose as it does
not remove the device file. verifies the validity of an existing pseu‐
donym before trying to use it. and use data stored in the file to ver‐
ify whether a process still owns a pseudonym before taking it over. If
finds an unowned pseudonym, it uses it.
When receives a serious error condition, such as when the LAN goes
down, it transmits the error condition to the application by closing
the Any or to the pseudonym returns the error condition If the pseudo‐
nym is the controlling terminal for the group to which the application
belongs, is sent to all the processes in the group, including the
Not all functionality is available, due to the lack of a protocol that
allows the transmission of such commands over the LAN to the remote
termio Attribute Limitations
The main restrictions on attributes (see termio(7)) include modem sig‐
nal control and parity checking. The following are not available:
ioctl() Request Limitations
The following request limitations apply:
DTC only supports one stop bit.
DTC only supports 8 bits per character.
Value cannot be modified.
DTC offers static configuration to handle even or odd parity.
It also handles auto parity detection for
even or odd parity.
Enabling/disabling done via static configuration.
No programmatic interface supplied.
No way to separate input from output parity features.
Cannot be configured on DTC.
Bad characters are forwarded to the system without marking them
with OFFH or OH.
Speed is part of static configuration.
Flow control is enabled if the DTC static configuration
specifies an ASCII access mode. If binary
is selected, no flow control is provided.
Pacing of output to a terminal via a programmatic interface
is enabled when ASCII mode is selected in
static port configuration and disabled when
binary mode is selected.
DTC does not offer the ability to restart output
on any character received if XOFF was previ‐
DDFA does not support the hanging up of modem signals
on the last close of the device file. If
the modem signals used on the DTC drop, the
connection is closed.
not supported by Telnet port identification
Part of static configuration is done in DTC Manager by selecting
If switching is enabled, binary can be
selected at user interface level. There is
no way to automatically negotiate binary
mode when proper termio flags are reset when
using Binary/ASCII switching is possible
with DDFA. The DTC cannot support large
reads in pure binary mode, so transferred
blocks of data should not be more than 256
bytes. If half-duplex with remote acknowl‐
edgement is implemented, binary applications
can be supported.
ioctl() System Call Requests
The following system call limitations apply:
The ability to send a break
without waiting for previous data to be sent
is not provided at the system level in or
DDFA. Receiving a Telnet break command in
the DTC allows it to generate a break on
The DTC output queue cannot be flushed.
Hardware handshake request
Not supported on DTC.
Local handshake cannot be disabled on DTC.
There is no way to separately set modem lines of a DTC port.
Modem timers, CD timer, connect timer, and disconnect cannot be
CCITT simple, and direct call-in/call-out modes
DTC cannot handle simple mode because there
is programmatic interface for modem signals.
Call-in mode cannot be simulated if the port
is opened, because modem signals (or the
call) must be present within 2 minutes or
the connection is cleared.
No way to get device adapter information.
No programmatic call to download the DTC.
No programmatic interface to get such info.
In order to ensure that commands (such as ps) display the cor‐
rect device file name (that is, the pseudonym), all pseudonyms
should be placed into the directory If pseudonyms are not speci‐
fied for placement in this directory, the correct display of
device file names with many commands is not guaranteed.
In addition, in order to ensure that commands (such as and work cor‐
rectly, each pseudonym must be unique in its first 17 characters
(including the directory prefix If pseudonyms are not unique in their
first 17 characters, the correct functioning of many commands is not
Also, in order to reliably handle timing mark negotiations (and ensure
that files printing on a printer attached to a terminal server have
been completely flushed to that printer), the following line must be
added near the end of each printer interface script for printers
attached to a terminal server:
The printer interface scripts reside in the directory The line must be
added just prior to the final command in each printer interface script.
If this line is not added as specified, the printing reliability of
printers attached to a terminal server is not guaranteed.
FILESSEE ALSOdpp(1M), ocd(1M), ocdebug(1M), ioctl(2), dp(4), pcf(4), ioctl(5),