X.25 defines the relationship between a Date Terminal Equipment (DTE) node and a network's DCE . The CCITT also defines the attachment of asynchronous start-stop devices to the PSDN in recommendations X.3, X.28 and X.29. The asynchronous device is typically a low-cost terminal such as an IBM 3151 or 3152. These terminals lack the intelligence of a full-function node on the network and rely on a device called a packet assembler/disassembler (PAD). A PAD is a protocol converter interfacing asynchronous terminals with an X.25 network or an X.25 network with applications written for asynchronous terminals .
Low-cost asynchronous terminals are connected by the public-switched telephone network to a local public outgoing PAD, often simply referred to as a PAD. The PAD takes the ASCII data stream coming from the terminal, buffers it, converts it into a properly formatted X.25 packet, then sends it over the X.25 PSDN addressed to the desired DTE. Data from the terminal that has been divided into packets and shipped by a PAD to the DTE node must be received by some incoming PAD software (also referred to as an X.29 interface). This incoming PAD unpacks the data and passes it to the application (typically, the TTY driver) for processing as if it were coming from directly attached asynchronous terminals. The other way, data coming from the application is first put into packets by the X.29 PAD then transferred over the network. When the PAD receives a packet addressed to the terminal, it reverses the process. This presents the data in a form that the terminal can accept.
The computer industry has expanded the definition of a packet assembler/disassembler (PAD) to include protocol conversion between X.25 and various teleprocessing protocols, for example, SDLC PADs, BSC-3270 PADs, and so on.
| X.3 | Defines a set of parameters that the PAD uses to identify and control the attached terminals. A complete set of parameters is called a profile, and each DTE-C (Data Terminal Equipment-Character) has its own profile selected or set for use with the PAD. |
| X.28 | Defines the control procedures used to establish the physical connection to the PAD, the commands the user sends to the PAD, and the service signals sent by the PAD to the terminal user. Simply, X.28 defines how a terminal user can control the X.3 PAD parameters. It specifies the command and response formats, and the status indicators. |
| X.29 | Defines the way in which a PAD and a remote DTE (or another PAD) exchange control messages on an X.25 virtual circuit. The messages are formatted as special X.25 packets called qualified data packets (Q-bit). For example, the packet mode DTE may use an X.29 message to change one of the internal X.3 parameters in the PAD. X.29 messages will only be effective when an X.25 call is established. The user at the terminal is not explicitly aware of the X.29 communication between the PAD and the remote DTE. The user at the terminal logs into the host DTE in the same way as the user of an ASCII terminal locally attached to the same host. The following figure illustrates the interaction between X3, X28, and X29. |
| Public PAD | Provided by the Post Telephone and Telegraph (PTT) administration or network provider that you can access by a local call on the public switched network. Once your terminal is connected to the public PAD, you enter the NUA of your host DTE and the PAD establishes the communications. |
| Private PAD | A hardware device with several asynchronous connectors and an X.25 attachment. This commercially available device can be connected to a public or private X.25 PSDN and has the same capabilities as a public PAD. |
| Integrated PAD Software | A software product emulating a PAD and requires a computer supporting an X.25 connection. It generally provides an asynchronous terminal emulator, but can use existing ones such as ATE or CU. With this product, the xspad function performs the asynchronous terminal-emulator role. |
To use the PAD software on the system, configure it through SMIT. See "Managing the Triple-X PAD" for more details. Once the PAD software is enabled on the system, it can be used as a terminal PAD for supporting local terminal users, or as a host PAD to work with remote terminal PADs. Both modes of operation can be run at the same time.
For use as a terminal PAD, each terminal or terminal emulator that requires a PAD session executes the xspad command. The xspad command connects the terminal to an application that provides the standard X.28 interface. See "Using the PAD" for more details on the use of terminal PAD sessions.
When the system is to be used as a host PAD, no user interaction takes place on the system itself. Once the system is configured to enable the PAD, users can connect from terminals connected to remote terminal PADs. The system running the host PAD allows login and application execution similar to any other type of remote ASCII terminal.
Note: PADs support ASCII terminals using 7-bit character set defined in International Alphabet 5 (IA5). PAD supports 8-bit data. The characteristics of the terminal must agree with its configuration data on the system unit it is attached to if using xspad on an ASCII terminal. This is also true for any attached TTY.
