The RS-232C standard defines numerous pins, but only three are
needed to directly connect a serial device to an MPE system:
pins 2 (transmit data), 3 (receive data),
and 7 (signal ground).
The most common cabling problem
is a mismatch of pins 2 and 3. Some devices
expect these pins to be wired straight through; others expect them to be
crossed over. If you get no response on your device, insert a Modem
Eliminator Cable (also called a Null Modem Cable).
This cable crosses over pins 2 and 3, 4 and 8, plus 6 and 20,
with pin 7 wired straight through to pin 7.
Warning:
To connect a modem using a cable with only 3 pins,
configure the modem to ignore DTR (that is, pretend it is present
and high), don't enable hardware handshaking in your software
(since you don't have RTS and CTS), and don't try to connect it to
an HP 3000 modem port (since you are missing DCD and DSR).
Parity
"Parity" is a method of computing a simple checksum for
a character sent over a communication link.
Characters can have 7 data bits, plus a parity bit.
The parity is computed by checking the total number of 1 bits in
the character, then setting the eighth bit so that the count is
always odd or always even. A terminal can compute parity in
five ways:
Odd parity | = | (make sum of the bits odd) |
Even parity | = | (make sum of the bits even) |
Mark parity | = | (parity bit is always 1, select
"1's" on some terminals)
|
Space parity | = | (parity bit is always 0;
"O's" on some terminals,
"0" on 262x, "None" on 264x)
|
None/8 | = | 8 bits used for data, no parity computed |
MPE/iX defaults to None/8, no parity, with 1 start bit and 1 stop bit,
which allows you to transmit 8-bit extended characters,
instead of just the
128-character ASCII character set.
MPE V senses your parity when
you press Return during logon; MPE V supports None/8,
but defaults to 1 start bit,
1 parity bit, 1 stop bit (2 stop bits slows
throughput by 10 percent), and 7
data bits (UART chips are actually capable of 5, 6, 7 or 8 data bits,
in addition to parity, not
just 7). UNIX expects 7
data bits with Parity, but HP-UX can be configured to accept
None/8. Because many UNIX systems are configured for 7 bits,
you may find it difficult or impossible to transfer extended
characters over a TELNET or serial connection.
Reflection, for example, has a 7 bit Transfer Link option
which we use whenever transferring files to, from, or through
any type of UNIX system.
ASCII Versus Binary File Transfers
Transfers of non-text files should always be done in
Binary mode (the actual command is Type Image in the FTP standard).
The problem has to do with interpretation of received data, not just
parity. ASCII transfers, for instance, usually attach great
significance to embedded CRs and LFs. For instance, if you send an
executable application using XMODEM from one UNIX system to another,
and you don't specify Binary mode,
any two-byte sequence that looks
like CR+LF is converted to just LF on the receiving side. XMODEM
(and Kermit for that matter) convert ASCII data to a standardized
transport format, converting UNIX new-lines (LFs) to CR+LF before
sending. The receiving system performs the reverse operation,
converting CR+LF to LF, wherein lies the problem.
This can burn you with FTP as well.
Many, if not most, FTP servers default to ASCII mode
for transfers, unless you or your FTP client select Binary mode.
Some FTP clients may have no facility for specifying Binary
mode to the server. Thus, downloading things like compressed archives
sometimes doesn't work.
Binary is not the default with FTP-- it
may appear to be, but each client/server has its own
values. When in doubt, specify Binary.
Handshake
One way to control the speed of transmission between
two devices is through a handshake,
an exchange of characters between a transmitter and a receiver
that postpones transmission until the receiver is
ready to receive the data.
For example, XON/XOFF and ENQ/ACK flow control are
handshakes.
Flow Control
Whenever you have two devices communicating over
the network you have the problem of what to do if one
transmits data faster than it can be received by the other.
So you need flow control, the pacing of
data in a transmission to ensure that the receiver
can process what has already been sent before transmitting more.
The goals of flow control are data integrity and
transmission throughput.
XON/XOFF flow control is the most common method
for serial connections. XON/XOFF, also called Dc1/Dc3
and ^Q/^S, is used on MPE and
HP-UX. If data is coming too
fast, you send
an XOFF character (decimal 19, aka DC3 or Control-S).
The sender stops sending until you send it an XON character
(decimal 17, aka DC1 or Control-Q). Of course there are a
few corner cases that make it more complicated, but that is
the essence of XON-XOFF flow control.
If the sender
misses the XOFF, data overrun occurs.
If the sender misses the XON, the communication port is hung.
On HP terminals you
can enable XON-XOFF for "Receive Pacing" and "Send Pacing."
To
enable XON/XOFF for data transmitted by your HP-UX port,
do stty ixon
.
For XON/XOFF on received data, do stty ixoff
.
You can use XON/XOFF to manually pause transmission to your screen.
Press ^S to
stop the output, then ^Q later to resume it.
Hardware Flow Control. Most serial communications uses software Flow Control, but there is an alternative: hardware handshaking. For example, the clear-to-send signals on the RS-232 line are often used to slow the data flow from a modem to a PC. Specifically, RTS is used by a DTE to stop the DCE and CTS is used by the DCE to stop the DTE.
One pressing reason for selecting hardware handshaking is that some modems cannot deal correctly with binary data streams that contain characters which look like DC1/DC3. Hardware handshaking is also known as Out-of-Band flow control, because the signals are generated and observed outside the flow of the data.
Care must be taken when enabling hardware handshaking. Both parties have to agree and be compatibly configured before you start. Software flow control is re-active. Things proceed normally until one party says "Stop!". Hardware flow control is pro-active. You do not start transmitting until you receive the Go signal. If you never get it, you never start. Fortunately, with most modems the hardware handshake rules are not turned On until a connection has been established. You can do most AT commands regardless of the handshake rules in effect--otherwise how would you enable or disable hardware flow control?
ENQ/ACK is a proprietary method of flow control
used on Classic MPE V systems
and is still built-in to most HP terminals and enabled by default.
The transmitter sends an ENQ (Enquiry, decimal 5, Control-E)
every 80 characters (or so).
When the receiver is ready for more data, it replies with an ACK
(Acknowledge, decimal 6, Control-F).
If there is no reply in 10 seconds, MPE V resumes printing
printing (Term Type 10). If you disable ENQ/ACK on your
terminal, you will see output interspersed with pauses. MPE/iX
and HP-UX normally use XON/XOFF Flow Control instead of ENQ/ACK.
HP's Serial Read Trigger: The Host Prompt
In character mode, the MPE FREAD intrinsic sends a DC1
(decimal 17, XON) to the terminal when it is ready to receive
data. It expects the terminal to suspend transmission after
sending a Return and wait for another DC1.
The user is not supposed
to start typing until the DC1 has been received, which is
invisible. On a slow system, users discover that they
can sometimes type
several characters between the appearance of the program
prompt and the receipt of the XON by the terminal.
On HP-UX and when MPE typeahead is enabled, the DC1 trigger is not essential. If the user types when the system is not ready for input, the host system saves the characters in a buffer for the next read request. When the host program can handle them, the saved characters are processed (whether they are echoed to the terminal at that time is an option).
Some HP-compatible terminals, terminal emulators, and black-box builders have taken advantage of HP's DC1 read trigger to implement typeahead external to the host system. If the user types before the DC1 trigger is received, the external typeahead mechanism saves the characters and transmits them when it sees the DC1. Randy Medd explains it thus:
The DC1 (XON) used by MPE isn't, strictly speaking, a flow control mechanism, since it isn't matched with a DC3. There is an implied DC3 (XOFF) whenever the FREAD terminates, usually on receipt of a carriage Return (CR). That's how our Type Ahead Engines and Attachmate type-ahead work. If you turn this upside-down and sideways, you can see the similarity between the DC1/CR pair and ENQ/ACK. In the steady state, when data is flowing from the HP 3000 to a terminal, the ACK works much like the DC1 - the system won't start transmitting to the terminal until it sees the ACK. The system transmits data up to, and including, the ENQ, at which point it stops, awaiting the next ACK "trigger." Similarly, in the other direction, the terminal doesn't (usually!) start transmitting (typing) until it sees the DC1. The terminal then transmits data up to, and including, the CR, at which point it stops, awaiting the next DC1.
When switching between MPE and HP-UX systems on the same
terminal or emulator, you can have problems. If you enable
"Use Host Prompt" for the MPE system, you hang on the
HP-UX system. If you disable it, you can type ahead on the HP-UX
system, but your Reflection type ahead mechanism no
longer works (because it is no longer expecting a DC1 trigger). Of
course, MPE now has an internal type ahead method that you
can enable with set hptypeahead true
.
HP's Block-Mode Protocols
Block mode causes a special flow
control problem because the terminal sends a large amount of data
as fast as it can. If the system does not have enough buffer
space, some data will be lost. MPE V and HP-UX use a special
DC1/DC2/DC1 Handshake for Block mode transfers while MPE/iX
counts on the terminal to use
XON/XOFF Transmit Pacing.
In the Classic DC1/DC2/DC1 handshake, the host system sends an
DC1 (decimal 17, ^Q, XON) when input is allowed. When the user
depresses a function key or the block-send key (Enter), the
terminal sends a DC2 (decimal 18, ^R) to signal a pending input
block. The terminal then waits for the system to allocate
buffers for the transfer. When the host is ready, it
sends an Escape sequence to home the cursor and lock the keyboard,
followed by another
DC1 (XON) to trigger the terminal into sending
the block of data. If the
second DC1 is
never received, the port hangs. The G and H straps of the HP
terminal control transmit handshaking. When using the
DC1/DC2/DC1 handshake, they should look
something like this: InhHndShk(G) NO. Inh DC2(H) NO
.
Since
these are "inhibit" straps, NO actually means "yes, do the
handshake". Surprisingly, HP-UX supports this
classic MPE V handshake (for details, type man blmode
).
MPE/iX on the PA-RISC systems
doesn't use
the DC1/DC2/DC1 handshake. Instead, the host enables a
feature of the HP
terminal which automatically does the HomeUp and Lock when
the user presses Enter, then sends the block of data, whether
the host is ready or not. If the host DTC (terminal controller)
runs out of buffer space, it sends an XOFF to slow things down.
For this to work, the terminal G and H straps must be set to inhibit handshaking:
InhHndShk(G) YES. Inh DC2(H) YES
.
And of course you must have "Xmit Pacing: YES"
.
Packets
A packet is the unit of data transmitted on a network.
It consists of the data, of course, plus control information
that allows the computers on the network to determine
whether to receive the data. For example, a packet header
would contain origin, destination, length, and other information.
Packet switching is the process of routing and
transmitting addressed packets over a network, or network
of networks such as the Internet. Data packets headed for
many different destinations can travel on the same network
and are assembled in sequence at the receiving end.
This is different from circuit connections, such as the
telephone system, which connect locations on demand and
gives them the exclusive use of a data circuit until they
are done.
TCP/IP
TCP and IP are actually two separate
protocols, with separate responsibilities. Together with
a few other protocols, TCP/IP
constitutes the Internet Protocol Suite, the method by
which the Internet can transmit data reliably anywhere in
the world.
TCP stands for Transmission Control Protocol. This is a transport-level protocol that sits on top of IP. It provides a reliable full-duplex byte stream between processes, whether they reside on the same machine or different machines. TCP is responsible for things like ensuring that the packets it transmits are received in the same order in which they were sent out, and reconstructed into the original byte stream. This is important, since two adjacent packets could take different routes to the same destination. Also, remember that TCP is concerned only with delivering a stream of bytes. Any meaning associated with those bytes, such as organization into lines or files, must be handled by a higher-level protocol.
IP stands for Internet Protocol and is a public standard network layer protocol. That means it is responsible for getting data from one machine to another, but isn't responsible for the assembling of that data for the receiving process. IP is a lower-level protocol than TCP.
Berkeley Sockets
A socket is an interface between an application
and a network transport layer. It allows communication
between processes on different host systems.
Berkeley Sockets is an API developed at UC Berkeley.
It is used as a standard socket interface to
TCP/IP, although there are several
flavors of sockets. It is sometimes also known as TCP Sockets.
The Sockets API allows a process to listen on a
port for requests for connection from processes on
other machines (or the same machine). Then a connection
can be negotiated and full-duplex communication can begin.
Sockets is the basis for popular Internet services such
as the World Wide Web.
Windows Sockets is a standard API which allows a process to communicate with another process using Berkeley Sockets. Windows Sockets comes packaged on Windows 3.1 as a winsock.dll file. There are many competing winsocks, which differ in speed, reliability, convenience, and even features (in spite of the standard!).