Return to trouble.txt CVS log

Up to [Power 6/32 Unix Tahoe 4.2BSD] / cci / usr / src / usr.bin / bsc / doc

Power 6/32 Unix version 1.21

.RP
.TL
BSC Troubleshooter's Guide
.br
or: What To Do When Things Go Wrong
.br
(cause they will)
.AU
Risa Galant
.AI
D. L. Buck and Associates, Inc.
.LP
The Bisync daemon
.I (bscd)
normally does its work quietly, without giving any
indication as to what it's doing.
Problems can and do occur however,
some of which the daemon complains about by displaying an error message,
some of which have to do with modems and phone lines and such.
.LP
This guide explains what to look for when any error message from the
daemon appears, how to troubleshoot modems and phone lines (or, at
least, to be able to tell what the problem
.I isn't)
problems that may occur when
installing 
.I bscbatch,
and how to use the monitoring/trace facilities.
.LP
Some useful things to have handy are the user manuals for modems,
auto-dialers, or other peripheral communications equipment used at
your installation, and the
.I bscmon(8)
document, which includes
the BSC protocol states diagram.
.NH
When the Daemon Complains
.LP
The daemon mails its error messages to the system administrator,
for whom the user id is a specifiable parameter in the host configuration
file,
If a communications log is being kept, these error
messages will also be logged therein.
.NH 2
Error Message Format
.LP
The daemon mails its messages in the following format:
.DS
bscd [<hostname>]: <error message>
.DE
.LP
.I <Hostname>
is the name of the host to which the daemon was transmitting or
receiving files at the time the error occurred.  If the error occurred
before contact with any host has been made, a hostname will not be
specified.
.I
<Error message>
.R
is the actual error message.
.NH 2
The Error Messages and What To Look For
.LP
Here are the error messages the daemon may send, and what to check
if it does.
.IP \(bu 5
.I
bscd: can't open /usr/lib/bscbatch configuration directory
.R
.IP
The configuration directory
.I /usr/lib/bscbatch
is where configuration files
for all hosts with which communications take place are kept.  If it
can't be read, no communication is possible with any of them.  Check
the directory's modes.  If they don't include read and execute permissions
for everybody, change them so that they do.
.IP \(bu
.I
bscd <hostname>: another bscd process is currently running
.R
.IP
The daemon is, at this very moment,
talking with
.I <hostname>,
.R
so you can't.
.IP
Note:
.I bscd
thinks this is so because it creates a "lock" file
in the spool directory
.I /usr/spool/bscbatch/<hostname>,
named
.I bsclock,
when it starts processing for a host, and removes it when it is done. 
It also creates a lock called
.I auditlock,
pertaining to the AUDIT trail file.
If unusual circumstances cause these files to be left in the directory
(a system crash, for example), you may have to manually remove them.
.IP
This message will also occur if
.I bscd
was unable to remove a file it
had sent.  Be sure and check the AUDIT trail via
.I bsclog.
.IP \(bu
.I
bscd <hostname>: directory /usr/spool/bscbatch/<hostname> not readable
.R
.IP
This is probably the same problem as the configuration directory problem.
Check the directory's modes and change them if necessary.
.IP
Note: This message will also occur if the directory isn't there. 
This may happen if a configuration file has been created for a host,
but the corresponding spool directory has not been.
.IP \(bu
.I
bscd <hostname>: <devname> cannot be opened for communications; system
error <errno>
.R
.IP
The communications device
.I <devname>
couldn't be opened when the daemon wanted to communicate with
.I <hostname>.
.IP
System error
.I <errno>
refers to the error number which was returned
to the daemon by the system.  See INTRO(2) for further information
about system error numbers.
.IP
Possible values for
.I <errno>
and explanations are:
.RS
.IP \(bu
16 (EBUSY)
.IP
Some other process has the communications device; you'll have to wait
for it to finish.  In the meantime, the daemon will go on to the next
host.
.IP \(bu
13 (EACCES)
.IP
This means the file modes are bad.  Check the modes for
.I <devname>.
.RE
.IP \(bu
.I
bscd <hostname>: unrecognized keyword, line <l> in /usr/lib/bscbatch/<hostname>
.R
.IP
While reading the host configuration file
.I /usr/lib/bscbatch/<hostname>,
the daemon found a configuration keyword it didn't recognize.
Somebody probably made a typographical error.  The daemon will
go on to the next host.
.IP \(bu
.I
bscd <hostname>: invalid parameter for keyword <k> in
/usr/lib/bscbatch/<hostname>
.R
.IP
While reading the host configuration file
.I /usr/lib/bscbatch/<hostname>,
the daemon found that configuration keyword
.I <k>
had an invalid parameter.
This could be due either to a typographical error, or the parameter
could be out of range.  The daemon will go on to the next host.
.IP \(bu
.I
bscd <hostname>: file system <devname> has less than minimum blocks
available.  Processing aborted.
.R
.IP
The amount of free space on
.I <devname>
is below the specified minimum
amount.  The daemon refuses to receive any files from this host while
this condition lasts \(em it continues processing with the next host.
Check the MINSPACE parameter in the host configuration file and the
amount of free space on the file system.  If there really is less
space on
.I <devname>
than the amount specified by MINSPACE, you'll have
to make room on it somehow before you can continue.
.IP \(bu
.I
bscd <hostname>: Transmission of <file> aborted: Attempt to send
transparent to non-transparent host.
.R
.IP
While sending file
.I <file>
to
.I <hostname>,
configured for normal data
only (TRANSPARENT = NO specified in the host's configuration file),
.I transparent
characters were encountered.
Certain control characters (SYN, DLE, ETX, ETB, IUS, ENQ) in the transmission
code being used cannot be sent as part of a normal data file \(em
the file must be sent in a special mode called
.I transparent.
Check <file> for control characters or typographical errors.
Transmision of <file> was aborted.
.IP \(bu
.I
bscd <hostname>: file /usr/spool/bscbatch/<hostname>/<filename>
can't be created.
.R
.IP
While attempting to create
.I <filename>
to hold a file being received,
an error was encountered.  Check the host's spool directory and/or
file's permissions, and change them if necessary.  The daemon goes
on to the next host.
.IP \(bu
.I
bscd <hostname>: file /usr/spool/bscbatch/<hostname>/<filename> can't
be removed.  
.R
.IP
The transmission control files and copy files are normally removed
from the host's spool directory once the file has been sent.  In this
case, the daemon had a problem while trying to unlink
.I <filename>. 
The file will be left there, and the daemon will terminate immediately,
.I without
removing the lock file.  This insures that the daemon won't
continuously send the unremovable file.
.IP \(bu
.I
bscd <host>: Transmission of <filename> aborted, <reason>
.R
.IP
If the reason is "Transmit timeout error", the usual explanation
for this is that the device did not get a transmit clock signal from
the modem.  This could be due to improper modem option specification,
improper cable to the modem from the computer system, or to not having
jumpered the MODEM port for external timing (see section 2 on Modems).
The daemon will go on to the next host.
.NH
Modems, Phone Lines, and Cables
.LP
This section explains something about the kinds of modems, phone lines,
and cables involved in communications, and how to troubleshoot them.
.NH 2
About Modems
.LP
For general bisynchronous communications (the kind we've been talking
about), two synchronous modems are necessary, one on each end of the
communications line.  They must be compatible or communications are
not likely to be successful.  "Compatible" refers primarily to their
speed and type.  If they are of the same manufacture and model, chances
are that they're of compatible types.  Some of the most popular modems
are manufactured by Bell Telephone, and several companies manufacture
modems which are Bell-compatible, but not all modems are.
You should check
that the modems you intend to use are compatible before you install
anything.
.LP
There are three types of synchronous modems supported by this software
and manufactured by Bell Telephone \(em the 201C, 208B, and 209A models.
208B is a 4800 baud modem which must be used only with very good phone
lines \(em you can't just plug it into a wall and expect it to transfer
perfect data over noisy or long distance lines.
The same goes for the 209A, 9600 baud modem.
The 201 is less fussy, and also slower.
It can transmit and receive data at either 2000
or 2400 baud over most telephone lines.
.NH 2
Types of Phone Lines
.LP
Telephone signals traveling over the wires tend to degrade after only
few thousand feet or so.  They must either be amplified at regular
intervals or reconstructed completely so that they aren't lost.
.LP
There are two types of phone lines: voice grade,
and data (digital) grade. 
.I "Voice grade"
lines have amplifiers every
few thousand feet or so which boost the signal and send it along to
the next amplifier.  This method works quite well, although the amplifier
amplifies any noise which exists on the line along with the signal
(that's why long distance lines are usually noisy).  The data signals on
.I "data grade"
lines are reconstructed
completely.  Any noise which exists on a line when the signal arrives
at a reconstruction station is eliminated, resulting in more error-free
transmissions.
.LP
Voice grade lines work well enough for humans, who can usually reconstruct,
through context, any part of a word lost due to noise on a phone line.
Since computers don't recognize things like context when they're transferring
bits across the miles, and since thousands of bits can be lost at
4800 baud in the time it takes to lose part of a word on a voice-grade
line, data grade lines are usually the best bet for long-distance
data transmission.  Data lines are available in and between many larger
cities (check your telephone representative).
.NH 2
Switched Lines
.LP
Switched lines are the conventional phone lines you use every day.
They can be 
.I switched
to reach any number of locations, based on the
number you dial when you pick up the phone.
.NH 2
Leased Lines
.LP
Leased lines are lines which are privately leased from the phone
company for use exclusively between two locations.  They're also called
direct-connect lines, since they connect two points directly \(em no
switching is involved.  When you pick up a phone which is on a leased
line, you won't get a dial tone \(em you'll get the other end immediately.
In fact, some installations don't even use a phone with their leased
lines.
.LP
Leased lines are particularly useful for finicky modems like the
Bell 208B and 209A, neither of which can handle noisy lines very well.
You can't guarantee the quality of a conventional telephone line since
you're never sure exactly which one you'll be getting when you dial.
But the leased line is, for all practical purposes, yours.  You
can attempt to make it is as reliable as possible by having it "conditioned."
.LP
Conditioning is a method the phone company uses to reduce the likelihood
of errors by "tuning" a line for a modem.  There are different kinds
of tuning.  The kind you need for your modem will be specified by
its manufacturer; check the modem's user manual. Conditioning lines
is usually expensive, but the reliability which results from having
it done is worth considering.
.NH
Cables
.LP
No hardware will ever consent
to speak to any other hardware unless it has a suitable cable through
which to speak.
The 25 pins present on a standard, RS-232 cable each have
a special function.  The ones in which we're most interested are:
.TS
center,box;
c|c
n|l.
Pin #	Description
_
2	Transmitted data (TD)
3	Received data (RD)
4	Request to send (RTS or RS)
5	Clear to send (CTS or CS)
6	Data set ready (DSR or MR)
7	Signal ground
8	Carrier detect (RLSD or CD)
15	Transmit signal timing (TxC)
17	Receive signal timing (RxC)
20	Data terminal ready (DTR or TR)
.TE
.LP
Straight-through cables, in which every wire goes from a specific
pin number on one end to the same specific pin number on the other
end, are usually just fine for connecting modems to computers.  If
the distance from computer to modem is short (10 feet or so), the
inexpensive flat ribbon cables will usually suffice.  Regular asynchronous
terminal cables don't work so well because they usually lack connections
for pins 15 and 17, which the modem uses to provide transmit and receive
signal clocking (one bit of data is transferred per clock tick), and
because some of the pins on some terminal cables are wired through to different
pins; they sometimes aren't just straight-through cables.
.LP
.TS
center;
c s s
c s s
c c c
l c l.
.B
Common Computer-to-Asynchronous-Terminal
Cable Pin Connections
.R
Computer		Async Terminal
_		_
TxD 2	------->	 3 RxD
RxD 3	<-------	 2 TxD
RTS 4	------->	 8 DCD
*DSR 6	<-------	20 DTR
GND 7	<------>	 7 GND
DCD 8	<-------	 4 RTS
DTR 20	------->	 6 DSR
.TE
.LP
*often ignored
.TS
center;
c s s
c s s
c s s
c c c
l c l.
.B
Common Computer-to-Modem
Cable Pin Connections
(straight-through cable)
.R
Computer		Modem
_		_
TxD 2	------->	 2 TxD
RxD 3	<-------	 3 RxD
DCD 8	<-------	 8 DCD
TxC 15	<-------	15 TxC
RxC 17	<-------	17 RxC
.TE
.LP
You should be sure that the cables you intend to use to connect computers,
modems, and terminals have the correct pin configurations.
.NH
Cable, Modem, and Phone Line Related Problems
.LP
Most problems in this section are caused by modem incompatibilities
or conflicts in data transmission codes or speeds.  Some are due to
unusually noisy phone lines and are remedied simply by hanging up
and dialing again.  Check the symptoms listed for the problem which
most closely resembles the one you're having, and follow the procedure
outlined.
.LP
Many of these situations are easier to check out if you're using
the monitor/trace facility (to be discussed).  It allows you
to see what's happening on your end of the line. e.g. repeated enquiry
attempts, trying to send the same file over and over, NAKs, etc. all
appear in the trace quite clearly.  If you're not sure exactly which
problem you're suffering from, use the monitor/trace facility in conjunction
with your other troubleshooting to help you determine what ails the
communications line.
.NH 2
When All Is Well, It Looks Like This
.LP
When everything is going well during a communications session with
a remote computer, certain lights on the modem go on:
.IP 1. 4
TR (Computer ready) when the bisync device has been opened
.IP 2.
MR (Modem ready) when the phone line connection has been
established
.IP 3.
RS (request to send), CS (clear to send), TD (transmit data) blinks
while transmitting
.IP 4.
CD (carrier detect), RD (receive data) blinks
while receiving
.LP
The TD and RD lights should be blinking on and off alternately as
communications continue; they're your primary indications that everything
is okay.
.NH 2
Modem Hangs Up Without Connecting
.LP
To connect with a remote computer, the modem needs to detect DTR (data
terminal ready).  This is turned on by the computer when the     
bisync device is opened; you'll see the TR light turned on.  If the
modem doesn't detect DTR and the phone rings, it won't answer.  If
there is no DTR and you try to connect after dialing by pressing the
DATA button (or such like), the modem won't hold the line; it will
hang up.  What probably happened is the daemon wasn't able to open
the communications device; you should be sure that you're running
the correct operating system and that the proper entries have been
made in dfile, config, etc.  Check the AUDIT trail via
.I bsclog,
and perhaps your cables to the modem.
.NH 2
Connection Made, But Nothing Transmits
.LP
To transmit, the transmit clock signal must be received by the computer.
One bit transmits per clock tick.  If nothing goes out for 15 seconds,
there's a problem.  Check the following possibilities:
.IP \(ci
LP
Synchronous modem being used?
.IP \(ci
Is the modem set up to generate a transmit clock?
Most modems have a (seldom used) option to allow the computer
(referred to as a DTE in most modem publications) to generate
this clock.  The modem must be set up to provide this clock
signal on pin 15.
.IP \(ci
Is your computer system set up properly for synchronous communications?
Some require an internal jumper change to switch it from asynchronous
to synchronous mode.
.IP \(ci
Check the cable going from the modem to the computer; does
it have pins 15 and 17 on it as required?
.NH 2
Transmit Looks Fine, But Nothing's Received On Remote End
.LP
When the TD light appears at your modem, your computer is trying to
send. The modem at the other end of the connection should light RD
(receive data) at this time. If it doesn't, there's serious trouble.
You should check that the signal is strong enough.  Some modems have
a signal quality indicator which lights when the signal is good. 
Ask someone on the receiving end to check this.  If the modem doesn't
have this indicator, try hanging up and calling again in a minute
or so.
.NH 2
You Aren't Receiving, or They Aren't Receiving
.LP
If the TD indicator is blinking about once every one to three seconds
and the session seems to be taking much too long (you may get an "NBID
limit exceeded" reason for transmit abort), or the remote computer
is sending (the RD indicator is blinking) but you aren't
receiving anything (trace shows nothing), check the following:
.IP \(ci
Make sure that the modems are set to the same speed and are compatible.
The 201 modem type usually has two speed capability, set by internal
jumpering.
.IP \(ci
Check that they're transferring data in the same transmission
code \(em both should be communicating in
.I either
ASCII or EBCDIC.
.LP
One hint:  if the phone line you're using is a switched line and you
got the electronic tone indicating connection, the remote computer
is
.I probably
up.  It's not easy to tell whether the remote computer
is up or not when you're going over a leased line, since you don't
dial the remote site; you need to call the site and check.
.NH 2
Too Many NAK'ed Data Transfers
.LP
Modems must be tuned to each other, or "equalized", to achieve communications
sessions as error-free as possible.  If the modems aren't equalized,
an unusually high percentage of data transfers will be NAK'ed (not
acknowledged).  If this occurs, the modems probably don't match, or
if a switched line is being used, the connection may be poor.
Hang up and
re-connect.
.NH 2
Additional Notes \(em What To Do If Re-Dialing Doesn't Work
.LP
The liklihood of getting a bad line on a conventional switched phone
line arrangement increases during peak line use times:  11 a.m. to
12 p.m. and 1 p.m. to 3 p.m., so it's best to try to avoid communications
at those times.  There's more of a spread if you're trying to dial
across time zones.
.LP
If repeated re-dialing doesn't seem to fix anything, there's a possibility
that the modem isn't working correctly.  Perform some of the modem
tests recommended by the manufacturer (these tests should be described
in the modem manual):
.IP \(bu
Self-Test
.IP
In this test, the modem transmits of data bits in a recognizable
pattern to itself.  Something's definitely wrong with the
modem if it can't recognize the pattern.
.IP \(bu
Error Testing
.IP
If the self-test checked out alright, you'll want to test the
path from your site to the remote site.  Have the people at
the remote site put their modem into loop-back mode so that
everything you send out comes right back to you.
.IP
If the data
you send out comes back intact, have the people at the remote
site run the same test on their modem.
.IP
If this test fails for both your modem and the remote modem,
and the modems are truly compatible, the phone line is probably
at fault.  If this is a leased line, check with the phone
company.  If this test was successful, you'll have to do some
fooling around with the modems; try only transmitting from
your end to their end, or adjust transmission or reception	
parameters on the modems to see if anything helps.
.IP
If only one modem has a problem, suspect that modem.  Try
connecting to other sites with it, or call your modem repair
facility.
.IP \(bu
If All Tests Were Successful...
.IP
The problem is likely to be in transmission codes, protocol, or the
remote computer just doesn't want to talk to you.
.NH
The Monitor/Trace Facility \(em bscmon and bsctrace
.LP
When problems arise on a communications line, it's convenient to able
to monitor it and display exactly what's happening.
.LP
There are two BSC utilities which are used to troubleshoot communications
lines -- 
.I bscmon,
which monitors the communications link, and
.I bsctrace,
which interprets the monitored information and displays it in a readable
format.  This section explains how
.I bscmon
and
.I bsctrace
work, how to
invoke them, and how to use the information they provide about the
communications link.
.NH 2
Terminology
.IP \(bu
Protocol State/State Transitions
.IP
A communications protocol may be defined as a set of states and transitions
to be made to other states, depending upon events such as data received.
The protocol state changes constantly as communications progress;
a separate state is defined for each kind of data transfer, errors
encountered, and protocol-related decisions.  These changes, called
.I transitions,
indicate what sort of actions are being taken on the
communications link.  A protocol state
diagram for Bisync is part of the
.I bscmon(8)
documentation.
.IP \(bu
Trace Device
.IP
This is a read-only pseudo-device.  The Bisync driver will place information
on its state transitions into a buffer while the trace
device is open.  When a read is done on the trace device, the driver
will transfer the buffered information to it.  Because there's only so much
room in the trace buffer, it's fairly easy to overrun it.  The best
way to minimize this is to have
.Ibscmon's
output go directly to a file
for processing by
.I bsctrace
later on, rather than piping its output
to bsctrace immediately (see bscmon(8)).
.IP \(bu
Trace Packet
.IP
A
.I
trace packet
.R
is a unit of information provided to
.I bscmon
by the
trace device which contains information about the state of the line
at a particular point in time, and optionally, data which was transferred
at that time.  The format of this packet is defined in
.I /usr/include/bsctr.h.
.NH 2
How They Work
.LP
Once invoked,
.I bscmon
opens the trace device (usually
.I /dev/bsctr)
and tries to read from it.  As soon as there are packets to read,
it records the communications state transition information and,
optionally, the data transferred, either to  a user-specified file
or to standard output.  Recording continues until communications end
(/dev/bsc is closed).
.LP
.I Bsctrace
takes the output from
.I bscmon,
accessing either the user-specified
file or standard input (via a pipe from
.I bscmon)
and interprets each trace packet.
It examines each trace packet's contents and displays
what it finds in report format.  If the user specifies that
explanations of the state transitions from packet to packet are desired,
.I bsctrace
interprets the meaning of each transition and displays a brief
explanation along with the other information.  It continues to display
the report until it reaches end of file.
.NH 2
About Communications States and their Transitions
.LP
States come in several types: send, receive, function, decision, error,
and trace overruns (the trace device is sending more packets than
.I bscmon
can handle), and message class, e.g., acknowledge message, enquiry,
or receive timeout.
.NH 2
Invocation
.LP
There are two ways to use
.I bscmon
and
.I bsctrace:
separately, e.g. running
.I bscmon
and saving its output in a file, then running
.I bsctrace
at another
time so that information may be checked in a leisurely way, or to
pipe
.I bscmon's
output directly to
.I bsctrace
as communications are taking
place for immediate interpretation.  As soon as the communications line becomes
active,
.I bscmon
will begin copying buffered information from the trace device.
.LP
Their command syntax is as follows:
.DS
bscmon [\(emdata] [\(emhost=<hostname> \||\| \(emdev=<devname>] [file]
bsctrace [\(emdata=<code>] [\(emverbose] [file]
.DE
.LP
As usual, items enclosed in square brackets are optional.  Items
enclosed in angular brackets will be substituted by actual value.
The vertical bar, "\||\|", indicates a choice of options \(em either may
be specified, but not both.
.NH 3
Bscmon's Options
.IP \(bu
\(emdata
.IP
Specifying
.I \(emdata
in the
.I bscmon
command line indicates to the daemon's
driver that you want to look at the actual data which is being transferred.
If all you want to check are the protocol items like NAK's and ENQs
and whether you're receiving anything, you don't need to specify this
option; it'll just slow the monitor down and increase the risk of
trace buffer overrun.
.IP \(bu
\(emhost=<hostname>
.IP
If this option is specified,
.I bscmon
will look in the host configuration
file
.I (/usr/lib/bscbatch/<hostname>)
for the parameter
.I DEVICE=<devname>.
When it finds it, it'll open
.I <devname>
with "tr" appended rather than
.I /dev/bsctr.
.IP \(bu
\(emdev=<devname>
.IP
This tells
.I bscmon
what device to open.
This option cannot be specified if the
.I -host
option has been specified.
.IP \(bu
file
.IP
If
.I file
is specified,
.I bscmon
will write its output to
.I file.
Otherwise, it's written straight to standard output.  That's fine for a pipe
to
.I bsctrace,
but you may not want the output on your terminal as it's
binary data.
.NH 3
Bsctrace Options
.IP \(bu
\(emdata=<code>
.IP
If this option is specified,
.I bsctrace
will assume two things: that
.I bscmon
was called with the
.I \(emdata
option, and that you want the
transferred data to be displayed in
.I <code>
display style.
.I <Code>
may be ASCII, EBCDIC, or HEX (short for hexadecimal).  Only one code display
style may be specified per monitor/trace invocation.
.IP \(bu
\(emverbose
.IP
This option tells
.I bsctrace
to display brief explanations of the
state transitions.  This option is extremely useful, especially to
those who don't have a BSC state diagram etched in their memories.
It does slow the trace display down, however, increasing the possibility
of overruns and lost trace data if you are piping
.I bscmon's
output directly to
.I bsctrace.
Again, if you're worried about this, you can
use
.I
bscmon's
file
.R
option to save the monitor's output and run  
.I bsctrace
on the file with the
.I \(emverbose
option later on.
.IP \(bu
File
.IP
If you saved
.I bscmon's
output to a file, you can tell
.I bsctrace
to interpret
the trace information in that file by specifying its name here.
.NH 2
Sample Invocations
.LP
Suppose that you were terribly concerned about overworking the trace
device, so you wanted to run the monitor separately from the trace,
saving its output in a file named mon.out.  Just type:
.DS
bscmon mon.out
.DE
.LP
Further, suppose that when the communications session is over, you
want to look at mon.out and have brief explanations of the state
transitions.  Type:
.DS
bsctrace \(emverbose mon.out
.DE
.LP
Or, suppose that you'd like to see what's happening on the line as
it's happening, perhaps as part of your installation process to be
sure that everything is going well. Type:
.DS
bscmon | bsctrace \(emverbose &
.DE
.LP
This will cause the monitor to start up in the background.  As soon
as the daemon begins to work,
.I bsctrace's
formatted interpretation
of the state transitions will  begin to display on the terminal.
.LP
If you'd like to see what the transferred data looks like, just to
be sure that you aren't sending or receiving garbage, and you have
a particular trace device that you'd like to use named /dev/bsc02tr,
try typing:
.DS
bscmon \(emdata \(emdev=/dev/bsc02tr mon.out
.DE
.LP
Let's say that you're transmitting to remote host 3780.  You're not
sure which trace device to use, but you know the bsc device is in the
3780 host configuration file.
Further, you want to see the data, and you don't
care about trace device overruns, so you want to display it in EBCDIC
as you go. Type:
.DS
bscmon \(emdata \(emhost=3780 | bsctrace \(emdata=EBCDIC \(emverbose
.DE
.NH 2
Sample Output
.LP
While you're looking at the sample output from
.I bscmon
and
.I bsctrace,
try following along using the BSC state diagram, then read the session
narrative which follows.  You'll get a pretty good idea of how the
BSC communications protocol works by doing so.
.LP
When you start communicating with a remote host, try running the monitor
and trace facilities and study the output.
.NH 3
A Communications Session
.LP
In this session,
.I bscmon
was piped directly to
.I bsctrace,
which was
running with the
.I -verbose
option.
.LP
The following trace types appear:
.DS
d - decision state
s - send state
r - receive state
c - message class just received
o - trace overruns
f - function state
e - error state
.DE
.ta 10 20 30
.DS
                    BSC State Trace Report
                           05/31/83
---------------------------------------------------------------------------
  Time	 |State	|  Type	|  Message
---------------------------------------------------------------------------
09:57:09 |  0	| d	| 
09:57:09 |  1	| d	| Start - Point-to-Point
09:57:11 |  1	| d	| Idle
09:57:11 |  2	| s	| Initial write system call - send line contention b
	 |	|	| id (ENQ)
09:57:11 |  3	| r	| Wait bid acknowledgement (ACK-0)
09:57:11 |  7	| c	| Even acknowledgement
09:57:11 |  4	| d	| Bid acknowledged - check host id
09:57:11 |  5	| d	| Host ok
09:57:11 |  6	| s	| Send text block
09:57:11 |  2	| o	| Trace overruns: 2
.DE
.DS
                    BSC State Trace Report
                           05/31/83
---------------------------------------------------------------------------
  Time	 |State	|  Type	|  Message
---------------------------------------------------------------------------
09:57:11 |  7	| r	| Wait text ACK
09:57:11 |  8	| c	| Odd acknowledgement
09:57:11 |  8	| d	| Text acknowledged
09:57:11 |  9	| f	| Correct ACK
09:57:11 | 29	| e	| Last text block - send EOT
09:57:11 | 13	| s	| 
09:57:11 |  0	| d	| Send EOT, restart from beginning
09:57:11 |  1	| d	| Start - Point-to-Point
09:57:12 |  1	| d	| Idle
09:57:12 | 30	| r	| Initial read system call
09:57:19 | -1	| c	| Receive timeout
09:57:19 | 30	| r	| ** No bid received - try again
09:57:27 | -1	| c	| Receive timeout
09:57:27 | 30	| r	| ** No bid received - try again
09:57:34 | -1	| c	| Receive timeout
.DE
.DS
                    BSC State Trace Report
                           05/31/83
---------------------------------------------------------------------------
  Time	 |State	|  Type	|  Message
---------------------------------------------------------------------------
09:57:34 | 30	| r	| ** No bid received - try again
09:57:36 |  0	| c	| Enquiry message
09:57:36 | 31	| f	| ENQ received - set odd block expected, even acknow
	 |	|	| ledgement (ACK-0)
09:57:36 | 32	| d	| Check Receive buffer availability
09:57:36 | 35	| s	| Receive buffer available - send block acknowledgem
	 |	|	| ent (ACK0/1)
09:57:37 | 36	| r	| Wait for text block (ETB or ETX)
09:57:37 |  4	| c	| Text block - not last of series
09:57:37 | 37	| d	| Text block received - check CRC/LRC
09:57:37 | 32	| d	| Correct CRC/LRC - flip expected block and acknowle
	 |	|	| dgement (ACK0/1)
09:57:37 | 32	| d	| Receive buffer unavailable - delay and retry
09:57:37 | 35	| s	| Receive buffer available - send block acknowledgem
	 |	|	| ent (ACK0/1)
.DE
.DS
                    BSC State Trace Report
                           05/31/83
---------------------------------------------------------------------------
  Time	 |State	|  Type	|  Message
---------------------------------------------------------------------------
09:57:37 | 36	| r	| Wait for text block (ETB or ETX)
09:57:37 |  4	| c	| Text block - not last of series
09:57:37 | 37	| d	| Text block received - check CRC/LRC
09:57:37 | 32	| d	| Correct CRC/LRC - flip expected block and acknowle
	 |	|	| dgement (ACK0/1)
09:57:38 | 32	| d	| Receive buffer unavailable - delay and retry
09:57:38 | 35	| s	| Receive buffer available - send block acknowledgem
	 |	|	| ent (ACK0/1)
09:57:38 | 36	| r	| Wait for text block (ETB or ETX)
09:57:38 |  4	| c	| Text block - not last of series
09:57:38 | 37	| d	| Text block received - check CRC/LRC
09:57:38 | 32	| d	| Correct CRC/LRC - flip expected block and acknowle
	 |	|	| dgement (ACK0/1)
09:57:38 | 32	| d	| Receive buffer unavailable - delay and retry
.DE
.DS
                    BSC State Trace Report
                           05/31/83
---------------------------------------------------------------------------
  Time	 |State	|  Type	|  Message
---------------------------------------------------------------------------
09:57:38 | 35	| s	| Receive buffer available - send block acknowledgem
	 |	|	| ent (ACK0/1)
09:57:38 | 36	| r	| Wait for text block (ETB or ETX)
09:57:38 |  4	| c	| Text block - not last of series
09:57:38 | 37	| d	| Text block received - check CRC/LRC
09:57:38 | 32	| d	| Correct CRC/LRC - flip expected block and acknowle
	 |	|	| dgement (ACK0/1)
09:57:39 | 32	| d	| Receive buffer unavailable - delay and retry
09:57:39 | 35	| s	| Receive buffer available - send block acknowledgem
	 |	|	| ent (ACK0/1)
09:57:39 | 36	| r	| Wait for text block (ETB or ETX)
09:57:39 |  4	| c	| Text block - not last of series
09:57:39 | 37	| d	| Text block received - check CRC/LRC
09:57:39 | 32	| d	| Correct CRC/LRC - flip expected block and acknowle
	 |	|	| dgement (ACK0/1)
09:57:39 | 32	| d	| Receive buffer unavailable - delay and retry
09:57:39 | 35	| s	| Receive buffer available - send block acknowledgem
	 |	|	| ent (ACK0/1)
09:57:39 | 36	| r	| Wait for text block (ETB or ETX)
09:57:39 |  4	| c	| Text block - not last of series
09:57:39 | 37	| d	| Text block received - check CRC/LRC
09:57:39 | 32	| d	| Correct CRC/LRC - flip expected block and acknowle
	 |	|	| dgement (ACK0/1)
.DE
.DS
                    BSC State Trace Report
                           05/31/83
---------------------------------------------------------------------------
  Time	 |State	|  Type	|  Message
---------------------------------------------------------------------------
09:57:40 | 32	| d	| Receive buffer unavailable - delay and retry
09:57:40 | 35	| s	| Receive buffer available - send block acknowledgem
	 |	|	| ent (ACK0/1)
09:57:40 | 36	| r	| Wait for text block (ETB or ETX)
09:57:40 |  9	| c	| Temp. transmit delay
09:57:40 | 36	| r	| Wait for good text block
09:57:47 | -1	| c	| Receive timeout
09:57:47 | 36	| r	| ** Timeout - keep waiting for text block
09:57:47 |  3	| c	| Text block - last of series
09:57:47 | 37	| d	| Text block received - check CRC/LRC
09:57:47 | 39	| s	| ** Incorrect CRC/LRC - send NAK and count as tempo
	 |	|	| rary error
09:57:47 | 36	| r	| Wait for good text block
09:57:55 | -1	| c	| Receive timeout
09:57:55 | 36	| r	| ** Timeout - keep waiting for text block
09:58:02 | -1	| c	| Receive timeout
09:58:02 | 36	| r	| ** Timeout - keep waiting for text block
09:58:10 | -1	| c	| Receive timeout
09:58:10 | 36	| r	| ** Timeout - keep waiting for text block
09:58:17 | -1	| c	| Receive timeout
09:58:17 | 36	| r	| ** Timeout - keep waiting for text block
09:58:25 | -1	| c	| Receive timeout
09:58:25 | 36	| r	| ** Timeout - keep waiting for text block
09:58:32 | -1	| c	| Receive timeout
09:58:32 | 36	| r	| ** Timeout - keep waiting for text block
09:58:40 | -1	| c	| Receive timeout
09:58:40 | 36	| r	| ** Timeout - keep waiting for text block
09:58:47 | 47	| e	| 
09:58:47 |  0	| d	| 
09:58:47 |  1	| d	| Start - Point-to-Point
.DE
.NH 3
Session Narrative
.LP
This session starts out normally, with an enquiry (ENQ, the bid for
control of the line).  The host returns the expected acknowledgement,
an ACK-O, and we send a block of text.  The trace overruns aren't
a problem, really; we just missed some data.  The host again returns
the expected acknowledgement, an ACK-1 this time.  We've sent the
last block of the file and have no more files to send, so we send
an EOT to the host, go back to the start, and indicate that we're
ready to receive.  We continue trying to receive an ENQ from the host
until we get one (if we didn't get one, we'd time out).  We acknowledge
it with an ACK-O.  We then check to be sure that we can receive, and
since we can, we send another ACK.  We receive a block of text, check
that it's good, and acknowledge it when it proves to be.  During this
time, the host tries to send another block.  We're busy, so we send
the host a temporary transmit delay (TTD).  The host tries again,
we're ready this time, and we receive another block.  This process
continues until the host sends us a TTD, meaning that it isn't ready
to transmit and we should wait.  We do this by sending a non-acknowledgement
(NAK), which is find in this case.  We check that we haven't gone
over the NAK limit.  If we had, we'd abort this session due to errors
on the line.  As it is, when the host does send a text block, it isn't
a good one.  We NAK it and try to receive it again, to no avail. 
The host has stopped transmitting, so we time out and disconnect.
.LP
Normally, the host would continue transmitting to us until it had
nothing to send.  If we no longer had anything to send, either, we'd
time out and disconnect.
.FS
DLBA Version 1.1
.FE

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.