Each tty port must be set up before attaching any input/output device. Before a tty device is created, several factors concerning its functionality should be determined. This section discusses those factors and their importance. Topics covered in this section are the:
Requirements for the physical port to which a modem is connected are dependent on the server and its serial adapters. The system and adapter must support (at least) the following modem control signals to be fully functional on all asynchronous software applications: RxD, TxD, RTS, CTS, SG, DCD, and DTR.
A server typically has two built-in serial ports. Additional multiport adapter cards or terminal servers can be installed on the server to allow the configuration of more serial devices. The following optional adapter cards and base units are supported on the server:
The above adapters and terminal server support the required modem control signals except the 16-port adapter. The 16-port asynchronous adapter does not provide support for the RTS and CTS signals. It is therefore impossible to use hardware flow control with this adapter.
If a binary file is to be transferred using a modem on the 16-port adapter, a transfer protocol that detects incorrect data and resends the missing data (for example, Xmodem, Zmodem, Kermit, and UUCP) should be used.
Review the associated chapter for each of the previously mentioned serial adapters for more information.
There are several important factors to take into consideration when planning the port baud rate:
If the remote system is going to be forced to connect at a single speed, that speed should be specified in the BAUD rate field of the SMIT TTY Setup menu of the local system. The modem must be set to connect at that same speed.
The MultiTech MT932 MultiModem II has programmable variables controlling the two separate communication speeds:
$SB=9600 $MB=38400See illustration Planning Port Baud Rate.
The $SB value is the serial baud rate between the modem and the server. The $MB value is the modem baud rate between the two modems themselves. With the above settings, the modem would communicate to the server at 9600 bps while at the same time communicating with another modem at 38400 bps.
Note: To avoid incompatibility problems between modems due to nonstandardized implementation of high-speed protocols, it is advisable to use the same make and model of modems at both ends of the connection.
The parity, bits-per-character, and stop bits for a serial device are interrelated and require a basic knowledge of serial communications. Most modern serial communications devices (modems, terminals, etc.) use a 10-bit transmission character:
The following table shows all the valid combinations.
| Bits-per-character | Start | Stop | Parity |
| 8 | 1 | 1 | none |
| 7 | 1 | 1 | 1 |
| 7 | 1 | 2 | 0 |
When a port is used for bidirectional communication (both dial-in and dial-out or connect-in and connect-out), it should be set up to enable a login on the port while still allowing other users to dial-out. This bidirectional capability can be accomplished by using the System Management Interface Tool (SMIT) to change the tty's Enable LOGIN field to either share or delay.
With the tty's Enable LOGIN field set to share, the /etc/getty command, which controls the login process, will start up on the port and wait for the modem to turn on a carrier signal.
When the modem turns the carrier signal on, the getty command attempts to lock the port so that no other processes can use it. If another program (for example, cu or ate) has already locked the port for dial out, the getty command waits until the port is freed by that process before attempting to open it again. If the port is not locked, the getty command locks it and sends out a login herald, thus allowing a login to take place on the port.
With the tty's Enable LOGIN field set to delay, /etc/getty waits until the remote system sends a character to the local tty before locking the port and sending a login herald.
Note: The share and delay settings lock the port as soon as the getty process starts. This is because the carrier signal is already up on a direct tty connection.
When LOGIN is set to delay, the getty command monitors the input buffer of the terminal device for a character. When a character is found, it attempts to lock the port, exactly like the shared port.
A variety of applications and system functions are tailored to specific terminal types such as the DEC VT100, IBM 3151, or Wyse 50. Each terminal type requires its own special emulation to function properly under AIX. Without proper emulation settings, terminals may display incorrect characters or change the functions of specific keys on the terminal keyboard.
Terminal emulation can be set from the AIX command line by using the TERM= environment variable (for example, TERM=ibm3151 <enter> ) or in SMIT by altering the TERMINAL type variable for a tty.
Note: For most modems used for both dial-in and dial-out connections, a TERMINAL type of dumb is sufficient. This value allows users dialing in to set their own terminal type (using TERM=) after logging in. If logins occur more frequently from a single, known terminal type, users can setup the TERMINAL type field when defining the tty from SMIT.
The supported terminal types are located in the /usr/lib/terminfo directory and subdirectories.
