![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to trouble.txt CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Power 6/32 Unix Tahoe 4.2BSD] / cci / usr / src / usr.bin / bsc / doc|
Return to trouble.txt CVS log | Up to [Power 6/32 Unix Tahoe 4.2BSD] / cci / usr / src / usr.bin / bsc / doc |
1.1 root 1: .RP
2: .TL
3: BSC Troubleshooter's Guide
4: .br
5: or: What To Do When Things Go Wrong
6: .br
7: (cause they will)
8: .AU
9: Risa Galant
10: .AI
11: D. L. Buck and Associates, Inc.
12: .LP
13: The Bisync daemon
14: .I (bscd)
15: normally does its work quietly, without giving any
16: indication as to what it's doing.
17: Problems can and do occur however,
18: some of which the daemon complains about by displaying an error message,
19: some of which have to do with modems and phone lines and such.
20: .LP
21: This guide explains what to look for when any error message from the
22: daemon appears, how to troubleshoot modems and phone lines (or, at
23: least, to be able to tell what the problem
24: .I isn't)
25: problems that may occur when
26: installing
27: .I bscbatch,
28: and how to use the monitoring/trace facilities.
29: .LP
30: Some useful things to have handy are the user manuals for modems,
31: auto-dialers, or other peripheral communications equipment used at
32: your installation, and the
33: .I bscmon(8)
34: document, which includes
35: the BSC protocol states diagram.
36: .NH
37: When the Daemon Complains
38: .LP
39: The daemon mails its error messages to the system administrator,
40: for whom the user id is a specifiable parameter in the host configuration
41: file,
42: If a communications log is being kept, these error
43: messages will also be logged therein.
44: .NH 2
45: Error Message Format
46: .LP
47: The daemon mails its messages in the following format:
48: .DS
49: bscd [<hostname>]: <error message>
50: .DE
51: .LP
52: .I <Hostname>
53: is the name of the host to which the daemon was transmitting or
54: receiving files at the time the error occurred. If the error occurred
55: before contact with any host has been made, a hostname will not be
56: specified.
57: .I
58: <Error message>
59: .R
60: is the actual error message.
61: .NH 2
62: The Error Messages and What To Look For
63: .LP
64: Here are the error messages the daemon may send, and what to check
65: if it does.
66: .IP \(bu 5
67: .I
68: bscd: can't open /usr/lib/bscbatch configuration directory
69: .R
70: .IP
71: The configuration directory
72: .I /usr/lib/bscbatch
73: is where configuration files
74: for all hosts with which communications take place are kept. If it
75: can't be read, no communication is possible with any of them. Check
76: the directory's modes. If they don't include read and execute permissions
77: for everybody, change them so that they do.
78: .IP \(bu
79: .I
80: bscd <hostname>: another bscd process is currently running
81: .R
82: .IP
83: The daemon is, at this very moment,
84: talking with
85: .I <hostname>,
86: .R
87: so you can't.
88: .IP
89: Note:
90: .I bscd
91: thinks this is so because it creates a "lock" file
92: in the spool directory
93: .I /usr/spool/bscbatch/<hostname>,
94: named
95: .I bsclock,
96: when it starts processing for a host, and removes it when it is done.
97: It also creates a lock called
98: .I auditlock,
99: pertaining to the AUDIT trail file.
100: If unusual circumstances cause these files to be left in the directory
101: (a system crash, for example), you may have to manually remove them.
102: .IP
103: This message will also occur if
104: .I bscd
105: was unable to remove a file it
106: had sent. Be sure and check the AUDIT trail via
107: .I bsclog.
108: .IP \(bu
109: .I
110: bscd <hostname>: directory /usr/spool/bscbatch/<hostname> not readable
111: .R
112: .IP
113: This is probably the same problem as the configuration directory problem.
114: Check the directory's modes and change them if necessary.
115: .IP
116: Note: This message will also occur if the directory isn't there.
117: This may happen if a configuration file has been created for a host,
118: but the corresponding spool directory has not been.
119: .IP \(bu
120: .I
121: bscd <hostname>: <devname> cannot be opened for communications; system
122: error <errno>
123: .R
124: .IP
125: The communications device
126: .I <devname>
127: couldn't be opened when the daemon wanted to communicate with
128: .I <hostname>.
129: .IP
130: System error
131: .I <errno>
132: refers to the error number which was returned
133: to the daemon by the system. See INTRO(2) for further information
134: about system error numbers.
135: .IP
136: Possible values for
137: .I <errno>
138: and explanations are:
139: .RS
140: .IP \(bu
141: 16 (EBUSY)
142: .IP
143: Some other process has the communications device; you'll have to wait
144: for it to finish. In the meantime, the daemon will go on to the next
145: host.
146: .IP \(bu
147: 13 (EACCES)
148: .IP
149: This means the file modes are bad. Check the modes for
150: .I <devname>.
151: .RE
152: .IP \(bu
153: .I
154: bscd <hostname>: unrecognized keyword, line <l> in /usr/lib/bscbatch/<hostname>
155: .R
156: .IP
157: While reading the host configuration file
158: .I /usr/lib/bscbatch/<hostname>,
159: the daemon found a configuration keyword it didn't recognize.
160: Somebody probably made a typographical error. The daemon will
161: go on to the next host.
162: .IP \(bu
163: .I
164: bscd <hostname>: invalid parameter for keyword <k> in
165: /usr/lib/bscbatch/<hostname>
166: .R
167: .IP
168: While reading the host configuration file
169: .I /usr/lib/bscbatch/<hostname>,
170: the daemon found that configuration keyword
171: .I <k>
172: had an invalid parameter.
173: This could be due either to a typographical error, or the parameter
174: could be out of range. The daemon will go on to the next host.
175: .IP \(bu
176: .I
177: bscd <hostname>: file system <devname> has less than minimum blocks
178: available. Processing aborted.
179: .R
180: .IP
181: The amount of free space on
182: .I <devname>
183: is below the specified minimum
184: amount. The daemon refuses to receive any files from this host while
185: this condition lasts \(em it continues processing with the next host.
186: Check the MINSPACE parameter in the host configuration file and the
187: amount of free space on the file system. If there really is less
188: space on
189: .I <devname>
190: than the amount specified by MINSPACE, you'll have
191: to make room on it somehow before you can continue.
192: .IP \(bu
193: .I
194: bscd <hostname>: Transmission of <file> aborted: Attempt to send
195: transparent to non-transparent host.
196: .R
197: .IP
198: While sending file
199: .I <file>
200: to
201: .I <hostname>,
202: configured for normal data
203: only (TRANSPARENT = NO specified in the host's configuration file),
204: .I transparent
205: characters were encountered.
206: Certain control characters (SYN, DLE, ETX, ETB, IUS, ENQ) in the transmission
207: code being used cannot be sent as part of a normal data file \(em
208: the file must be sent in a special mode called
209: .I transparent.
210: Check <file> for control characters or typographical errors.
211: Transmision of <file> was aborted.
212: .IP \(bu
213: .I
214: bscd <hostname>: file /usr/spool/bscbatch/<hostname>/<filename>
215: can't be created.
216: .R
217: .IP
218: While attempting to create
219: .I <filename>
220: to hold a file being received,
221: an error was encountered. Check the host's spool directory and/or
222: file's permissions, and change them if necessary. The daemon goes
223: on to the next host.
224: .IP \(bu
225: .I
226: bscd <hostname>: file /usr/spool/bscbatch/<hostname>/<filename> can't
227: be removed.
228: .R
229: .IP
230: The transmission control files and copy files are normally removed
231: from the host's spool directory once the file has been sent. In this
232: case, the daemon had a problem while trying to unlink
233: .I <filename>.
234: The file will be left there, and the daemon will terminate immediately,
235: .I without
236: removing the lock file. This insures that the daemon won't
237: continuously send the unremovable file.
238: .IP \(bu
239: .I
240: bscd <host>: Transmission of <filename> aborted, <reason>
241: .R
242: .IP
243: If the reason is "Transmit timeout error", the usual explanation
244: for this is that the device did not get a transmit clock signal from
245: the modem. This could be due to improper modem option specification,
246: improper cable to the modem from the computer system, or to not having
247: jumpered the MODEM port for external timing (see section 2 on Modems).
248: The daemon will go on to the next host.
249: .NH
250: Modems, Phone Lines, and Cables
251: .LP
252: This section explains something about the kinds of modems, phone lines,
253: and cables involved in communications, and how to troubleshoot them.
254: .NH 2
255: About Modems
256: .LP
257: For general bisynchronous communications (the kind we've been talking
258: about), two synchronous modems are necessary, one on each end of the
259: communications line. They must be compatible or communications are
260: not likely to be successful. "Compatible" refers primarily to their
261: speed and type. If they are of the same manufacture and model, chances
262: are that they're of compatible types. Some of the most popular modems
263: are manufactured by Bell Telephone, and several companies manufacture
264: modems which are Bell-compatible, but not all modems are.
265: You should check
266: that the modems you intend to use are compatible before you install
267: anything.
268: .LP
269: There are three types of synchronous modems supported by this software
270: and manufactured by Bell Telephone \(em the 201C, 208B, and 209A models.
271: 208B is a 4800 baud modem which must be used only with very good phone
272: lines \(em you can't just plug it into a wall and expect it to transfer
273: perfect data over noisy or long distance lines.
274: The same goes for the 209A, 9600 baud modem.
275: The 201 is less fussy, and also slower.
276: It can transmit and receive data at either 2000
277: or 2400 baud over most telephone lines.
278: .NH 2
279: Types of Phone Lines
280: .LP
281: Telephone signals traveling over the wires tend to degrade after only
282: few thousand feet or so. They must either be amplified at regular
283: intervals or reconstructed completely so that they aren't lost.
284: .LP
285: There are two types of phone lines: voice grade,
286: and data (digital) grade.
287: .I "Voice grade"
288: lines have amplifiers every
289: few thousand feet or so which boost the signal and send it along to
290: the next amplifier. This method works quite well, although the amplifier
291: amplifies any noise which exists on the line along with the signal
292: (that's why long distance lines are usually noisy). The data signals on
293: .I "data grade"
294: lines are reconstructed
295: completely. Any noise which exists on a line when the signal arrives
296: at a reconstruction station is eliminated, resulting in more error-free
297: transmissions.
298: .LP
299: Voice grade lines work well enough for humans, who can usually reconstruct,
300: through context, any part of a word lost due to noise on a phone line.
301: Since computers don't recognize things like context when they're transferring
302: bits across the miles, and since thousands of bits can be lost at
303: 4800 baud in the time it takes to lose part of a word on a voice-grade
304: line, data grade lines are usually the best bet for long-distance
305: data transmission. Data lines are available in and between many larger
306: cities (check your telephone representative).
307: .NH 2
308: Switched Lines
309: .LP
310: Switched lines are the conventional phone lines you use every day.
311: They can be
312: .I switched
313: to reach any number of locations, based on the
314: number you dial when you pick up the phone.
315: .NH 2
316: Leased Lines
317: .LP
318: Leased lines are lines which are privately leased from the phone
319: company for use exclusively between two locations. They're also called
320: direct-connect lines, since they connect two points directly \(em no
321: switching is involved. When you pick up a phone which is on a leased
322: line, you won't get a dial tone \(em you'll get the other end immediately.
323: In fact, some installations don't even use a phone with their leased
324: lines.
325: .LP
326: Leased lines are particularly useful for finicky modems like the
327: Bell 208B and 209A, neither of which can handle noisy lines very well.
328: You can't guarantee the quality of a conventional telephone line since
329: you're never sure exactly which one you'll be getting when you dial.
330: But the leased line is, for all practical purposes, yours. You
331: can attempt to make it is as reliable as possible by having it "conditioned."
332: .LP
333: Conditioning is a method the phone company uses to reduce the likelihood
334: of errors by "tuning" a line for a modem. There are different kinds
335: of tuning. The kind you need for your modem will be specified by
336: its manufacturer; check the modem's user manual. Conditioning lines
337: is usually expensive, but the reliability which results from having
338: it done is worth considering.
339: .NH
340: Cables
341: .LP
342: No hardware will ever consent
343: to speak to any other hardware unless it has a suitable cable through
344: which to speak.
345: The 25 pins present on a standard, RS-232 cable each have
346: a special function. The ones in which we're most interested are:
347: .TS
348: center,box;
349: c|c
350: n|l.
351: Pin # Description
352: _
353: 2 Transmitted data (TD)
354: 3 Received data (RD)
355: 4 Request to send (RTS or RS)
356: 5 Clear to send (CTS or CS)
357: 6 Data set ready (DSR or MR)
358: 7 Signal ground
359: 8 Carrier detect (RLSD or CD)
360: 15 Transmit signal timing (TxC)
361: 17 Receive signal timing (RxC)
362: 20 Data terminal ready (DTR or TR)
363: .TE
364: .LP
365: Straight-through cables, in which every wire goes from a specific
366: pin number on one end to the same specific pin number on the other
367: end, are usually just fine for connecting modems to computers. If
368: the distance from computer to modem is short (10 feet or so), the
369: inexpensive flat ribbon cables will usually suffice. Regular asynchronous
370: terminal cables don't work so well because they usually lack connections
371: for pins 15 and 17, which the modem uses to provide transmit and receive
372: signal clocking (one bit of data is transferred per clock tick), and
373: because some of the pins on some terminal cables are wired through to different
374: pins; they sometimes aren't just straight-through cables.
375: .LP
376: .TS
377: center;
378: c s s
379: c s s
380: c c c
381: l c l.
382: .B
383: Common Computer-to-Asynchronous-Terminal
384: Cable Pin Connections
385: .R
386: Computer Async Terminal
387: _ _
388: TxD 2 -------> 3 RxD
389: RxD 3 <------- 2 TxD
390: RTS 4 -------> 8 DCD
391: *DSR 6 <------- 20 DTR
392: GND 7 <------> 7 GND
393: DCD 8 <------- 4 RTS
394: DTR 20 -------> 6 DSR
395: .TE
396: .LP
397: *often ignored
398: .TS
399: center;
400: c s s
401: c s s
402: c s s
403: c c c
404: l c l.
405: .B
406: Common Computer-to-Modem
407: Cable Pin Connections
408: (straight-through cable)
409: .R
410: Computer Modem
411: _ _
412: TxD 2 -------> 2 TxD
413: RxD 3 <------- 3 RxD
414: DCD 8 <------- 8 DCD
415: TxC 15 <------- 15 TxC
416: RxC 17 <------- 17 RxC
417: .TE
418: .LP
419: You should be sure that the cables you intend to use to connect computers,
420: modems, and terminals have the correct pin configurations.
421: .NH
422: Cable, Modem, and Phone Line Related Problems
423: .LP
424: Most problems in this section are caused by modem incompatibilities
425: or conflicts in data transmission codes or speeds. Some are due to
426: unusually noisy phone lines and are remedied simply by hanging up
427: and dialing again. Check the symptoms listed for the problem which
428: most closely resembles the one you're having, and follow the procedure
429: outlined.
430: .LP
431: Many of these situations are easier to check out if you're using
432: the monitor/trace facility (to be discussed). It allows you
433: to see what's happening on your end of the line. e.g. repeated enquiry
434: attempts, trying to send the same file over and over, NAKs, etc. all
435: appear in the trace quite clearly. If you're not sure exactly which
436: problem you're suffering from, use the monitor/trace facility in conjunction
437: with your other troubleshooting to help you determine what ails the
438: communications line.
439: .NH 2
440: When All Is Well, It Looks Like This
441: .LP
442: When everything is going well during a communications session with
443: a remote computer, certain lights on the modem go on:
444: .IP 1. 4
445: TR (Computer ready) when the bisync device has been opened
446: .IP 2.
447: MR (Modem ready) when the phone line connection has been
448: established
449: .IP 3.
450: RS (request to send), CS (clear to send), TD (transmit data) blinks
451: while transmitting
452: .IP 4.
453: CD (carrier detect), RD (receive data) blinks
454: while receiving
455: .LP
456: The TD and RD lights should be blinking on and off alternately as
457: communications continue; they're your primary indications that everything
458: is okay.
459: .NH 2
460: Modem Hangs Up Without Connecting
461: .LP
462: To connect with a remote computer, the modem needs to detect DTR (data
463: terminal ready). This is turned on by the computer when the
464: bisync device is opened; you'll see the TR light turned on. If the
465: modem doesn't detect DTR and the phone rings, it won't answer. If
466: there is no DTR and you try to connect after dialing by pressing the
467: DATA button (or such like), the modem won't hold the line; it will
468: hang up. What probably happened is the daemon wasn't able to open
469: the communications device; you should be sure that you're running
470: the correct operating system and that the proper entries have been
471: made in dfile, config, etc. Check the AUDIT trail via
472: .I bsclog,
473: and perhaps your cables to the modem.
474: .NH 2
475: Connection Made, But Nothing Transmits
476: .LP
477: To transmit, the transmit clock signal must be received by the computer.
478: One bit transmits per clock tick. If nothing goes out for 15 seconds,
479: there's a problem. Check the following possibilities:
480: .IP \(ci
481: LP
482: Synchronous modem being used?
483: .IP \(ci
484: Is the modem set up to generate a transmit clock?
485: Most modems have a (seldom used) option to allow the computer
486: (referred to as a DTE in most modem publications) to generate
487: this clock. The modem must be set up to provide this clock
488: signal on pin 15.
489: .IP \(ci
490: Is your computer system set up properly for synchronous communications?
491: Some require an internal jumper change to switch it from asynchronous
492: to synchronous mode.
493: .IP \(ci
494: Check the cable going from the modem to the computer; does
495: it have pins 15 and 17 on it as required?
496: .NH 2
497: Transmit Looks Fine, But Nothing's Received On Remote End
498: .LP
499: When the TD light appears at your modem, your computer is trying to
500: send. The modem at the other end of the connection should light RD
501: (receive data) at this time. If it doesn't, there's serious trouble.
502: You should check that the signal is strong enough. Some modems have
503: a signal quality indicator which lights when the signal is good.
504: Ask someone on the receiving end to check this. If the modem doesn't
505: have this indicator, try hanging up and calling again in a minute
506: or so.
507: .NH 2
508: You Aren't Receiving, or They Aren't Receiving
509: .LP
510: If the TD indicator is blinking about once every one to three seconds
511: and the session seems to be taking much too long (you may get an "NBID
512: limit exceeded" reason for transmit abort), or the remote computer
513: is sending (the RD indicator is blinking) but you aren't
514: receiving anything (trace shows nothing), check the following:
515: .IP \(ci
516: Make sure that the modems are set to the same speed and are compatible.
517: The 201 modem type usually has two speed capability, set by internal
518: jumpering.
519: .IP \(ci
520: Check that they're transferring data in the same transmission
521: code \(em both should be communicating in
522: .I either
523: ASCII or EBCDIC.
524: .LP
525: One hint: if the phone line you're using is a switched line and you
526: got the electronic tone indicating connection, the remote computer
527: is
528: .I probably
529: up. It's not easy to tell whether the remote computer
530: is up or not when you're going over a leased line, since you don't
531: dial the remote site; you need to call the site and check.
532: .NH 2
533: Too Many NAK'ed Data Transfers
534: .LP
535: Modems must be tuned to each other, or "equalized", to achieve communications
536: sessions as error-free as possible. If the modems aren't equalized,
537: an unusually high percentage of data transfers will be NAK'ed (not
538: acknowledged). If this occurs, the modems probably don't match, or
539: if a switched line is being used, the connection may be poor.
540: Hang up and
541: re-connect.
542: .NH 2
543: Additional Notes \(em What To Do If Re-Dialing Doesn't Work
544: .LP
545: The liklihood of getting a bad line on a conventional switched phone
546: line arrangement increases during peak line use times: 11 a.m. to
547: 12 p.m. and 1 p.m. to 3 p.m., so it's best to try to avoid communications
548: at those times. There's more of a spread if you're trying to dial
549: across time zones.
550: .LP
551: If repeated re-dialing doesn't seem to fix anything, there's a possibility
552: that the modem isn't working correctly. Perform some of the modem
553: tests recommended by the manufacturer (these tests should be described
554: in the modem manual):
555: .IP \(bu
556: Self-Test
557: .IP
558: In this test, the modem transmits of data bits in a recognizable
559: pattern to itself. Something's definitely wrong with the
560: modem if it can't recognize the pattern.
561: .IP \(bu
562: Error Testing
563: .IP
564: If the self-test checked out alright, you'll want to test the
565: path from your site to the remote site. Have the people at
566: the remote site put their modem into loop-back mode so that
567: everything you send out comes right back to you.
568: .IP
569: If the data
570: you send out comes back intact, have the people at the remote
571: site run the same test on their modem.
572: .IP
573: If this test fails for both your modem and the remote modem,
574: and the modems are truly compatible, the phone line is probably
575: at fault. If this is a leased line, check with the phone
576: company. If this test was successful, you'll have to do some
577: fooling around with the modems; try only transmitting from
578: your end to their end, or adjust transmission or reception
579: parameters on the modems to see if anything helps.
580: .IP
581: If only one modem has a problem, suspect that modem. Try
582: connecting to other sites with it, or call your modem repair
583: facility.
584: .IP \(bu
585: If All Tests Were Successful...
586: .IP
587: The problem is likely to be in transmission codes, protocol, or the
588: remote computer just doesn't want to talk to you.
589: .NH
590: The Monitor/Trace Facility \(em bscmon and bsctrace
591: .LP
592: When problems arise on a communications line, it's convenient to able
593: to monitor it and display exactly what's happening.
594: .LP
595: There are two BSC utilities which are used to troubleshoot communications
596: lines --
597: .I bscmon,
598: which monitors the communications link, and
599: .I bsctrace,
600: which interprets the monitored information and displays it in a readable
601: format. This section explains how
602: .I bscmon
603: and
604: .I bsctrace
605: work, how to
606: invoke them, and how to use the information they provide about the
607: communications link.
608: .NH 2
609: Terminology
610: .IP \(bu
611: Protocol State/State Transitions
612: .IP
613: A communications protocol may be defined as a set of states and transitions
614: to be made to other states, depending upon events such as data received.
615: The protocol state changes constantly as communications progress;
616: a separate state is defined for each kind of data transfer, errors
617: encountered, and protocol-related decisions. These changes, called
618: .I transitions,
619: indicate what sort of actions are being taken on the
620: communications link. A protocol state
621: diagram for Bisync is part of the
622: .I bscmon(8)
623: documentation.
624: .IP \(bu
625: Trace Device
626: .IP
627: This is a read-only pseudo-device. The Bisync driver will place information
628: on its state transitions into a buffer while the trace
629: device is open. When a read is done on the trace device, the driver
630: will transfer the buffered information to it. Because there's only so much
631: room in the trace buffer, it's fairly easy to overrun it. The best
632: way to minimize this is to have
633: .Ibscmon's
634: output go directly to a file
635: for processing by
636: .I bsctrace
637: later on, rather than piping its output
638: to bsctrace immediately (see bscmon(8)).
639: .IP \(bu
640: Trace Packet
641: .IP
642: A
643: .I
644: trace packet
645: .R
646: is a unit of information provided to
647: .I bscmon
648: by the
649: trace device which contains information about the state of the line
650: at a particular point in time, and optionally, data which was transferred
651: at that time. The format of this packet is defined in
652: .I /usr/include/bsctr.h.
653: .NH 2
654: How They Work
655: .LP
656: Once invoked,
657: .I bscmon
658: opens the trace device (usually
659: .I /dev/bsctr)
660: and tries to read from it. As soon as there are packets to read,
661: it records the communications state transition information and,
662: optionally, the data transferred, either to a user-specified file
663: or to standard output. Recording continues until communications end
664: (/dev/bsc is closed).
665: .LP
666: .I Bsctrace
667: takes the output from
668: .I bscmon,
669: accessing either the user-specified
670: file or standard input (via a pipe from
671: .I bscmon)
672: and interprets each trace packet.
673: It examines each trace packet's contents and displays
674: what it finds in report format. If the user specifies that
675: explanations of the state transitions from packet to packet are desired,
676: .I bsctrace
677: interprets the meaning of each transition and displays a brief
678: explanation along with the other information. It continues to display
679: the report until it reaches end of file.
680: .NH 2
681: About Communications States and their Transitions
682: .LP
683: States come in several types: send, receive, function, decision, error,
684: and trace overruns (the trace device is sending more packets than
685: .I bscmon
686: can handle), and message class, e.g., acknowledge message, enquiry,
687: or receive timeout.
688: .NH 2
689: Invocation
690: .LP
691: There are two ways to use
692: .I bscmon
693: and
694: .I bsctrace:
695: separately, e.g. running
696: .I bscmon
697: and saving its output in a file, then running
698: .I bsctrace
699: at another
700: time so that information may be checked in a leisurely way, or to
701: pipe
702: .I bscmon's
703: output directly to
704: .I bsctrace
705: as communications are taking
706: place for immediate interpretation. As soon as the communications line becomes
707: active,
708: .I bscmon
709: will begin copying buffered information from the trace device.
710: .LP
711: Their command syntax is as follows:
712: .DS
713: bscmon [\(emdata] [\(emhost=<hostname> \||\| \(emdev=<devname>] [file]
714: bsctrace [\(emdata=<code>] [\(emverbose] [file]
715: .DE
716: .LP
717: As usual, items enclosed in square brackets are optional. Items
718: enclosed in angular brackets will be substituted by actual value.
719: The vertical bar, "\||\|", indicates a choice of options \(em either may
720: be specified, but not both.
721: .NH 3
722: Bscmon's Options
723: .IP \(bu
724: \(emdata
725: .IP
726: Specifying
727: .I \(emdata
728: in the
729: .I bscmon
730: command line indicates to the daemon's
731: driver that you want to look at the actual data which is being transferred.
732: If all you want to check are the protocol items like NAK's and ENQs
733: and whether you're receiving anything, you don't need to specify this
734: option; it'll just slow the monitor down and increase the risk of
735: trace buffer overrun.
736: .IP \(bu
737: \(emhost=<hostname>
738: .IP
739: If this option is specified,
740: .I bscmon
741: will look in the host configuration
742: file
743: .I (/usr/lib/bscbatch/<hostname>)
744: for the parameter
745: .I DEVICE=<devname>.
746: When it finds it, it'll open
747: .I <devname>
748: with "tr" appended rather than
749: .I /dev/bsctr.
750: .IP \(bu
751: \(emdev=<devname>
752: .IP
753: This tells
754: .I bscmon
755: what device to open.
756: This option cannot be specified if the
757: .I -host
758: option has been specified.
759: .IP \(bu
760: file
761: .IP
762: If
763: .I file
764: is specified,
765: .I bscmon
766: will write its output to
767: .I file.
768: Otherwise, it's written straight to standard output. That's fine for a pipe
769: to
770: .I bsctrace,
771: but you may not want the output on your terminal as it's
772: binary data.
773: .NH 3
774: Bsctrace Options
775: .IP \(bu
776: \(emdata=<code>
777: .IP
778: If this option is specified,
779: .I bsctrace
780: will assume two things: that
781: .I bscmon
782: was called with the
783: .I \(emdata
784: option, and that you want the
785: transferred data to be displayed in
786: .I <code>
787: display style.
788: .I <Code>
789: may be ASCII, EBCDIC, or HEX (short for hexadecimal). Only one code display
790: style may be specified per monitor/trace invocation.
791: .IP \(bu
792: \(emverbose
793: .IP
794: This option tells
795: .I bsctrace
796: to display brief explanations of the
797: state transitions. This option is extremely useful, especially to
798: those who don't have a BSC state diagram etched in their memories.
799: It does slow the trace display down, however, increasing the possibility
800: of overruns and lost trace data if you are piping
801: .I bscmon's
802: output directly to
803: .I bsctrace.
804: Again, if you're worried about this, you can
805: use
806: .I
807: bscmon's
808: file
809: .R
810: option to save the monitor's output and run
811: .I bsctrace
812: on the file with the
813: .I \(emverbose
814: option later on.
815: .IP \(bu
816: File
817: .IP
818: If you saved
819: .I bscmon's
820: output to a file, you can tell
821: .I bsctrace
822: to interpret
823: the trace information in that file by specifying its name here.
824: .NH 2
825: Sample Invocations
826: .LP
827: Suppose that you were terribly concerned about overworking the trace
828: device, so you wanted to run the monitor separately from the trace,
829: saving its output in a file named mon.out. Just type:
830: .DS
831: bscmon mon.out
832: .DE
833: .LP
834: Further, suppose that when the communications session is over, you
835: want to look at mon.out and have brief explanations of the state
836: transitions. Type:
837: .DS
838: bsctrace \(emverbose mon.out
839: .DE
840: .LP
841: Or, suppose that you'd like to see what's happening on the line as
842: it's happening, perhaps as part of your installation process to be
843: sure that everything is going well. Type:
844: .DS
845: bscmon | bsctrace \(emverbose &
846: .DE
847: .LP
848: This will cause the monitor to start up in the background. As soon
849: as the daemon begins to work,
850: .I bsctrace's
851: formatted interpretation
852: of the state transitions will begin to display on the terminal.
853: .LP
854: If you'd like to see what the transferred data looks like, just to
855: be sure that you aren't sending or receiving garbage, and you have
856: a particular trace device that you'd like to use named /dev/bsc02tr,
857: try typing:
858: .DS
859: bscmon \(emdata \(emdev=/dev/bsc02tr mon.out
860: .DE
861: .LP
862: Let's say that you're transmitting to remote host 3780. You're not
863: sure which trace device to use, but you know the bsc device is in the
864: 3780 host configuration file.
865: Further, you want to see the data, and you don't
866: care about trace device overruns, so you want to display it in EBCDIC
867: as you go. Type:
868: .DS
869: bscmon \(emdata \(emhost=3780 | bsctrace \(emdata=EBCDIC \(emverbose
870: .DE
871: .NH 2
872: Sample Output
873: .LP
874: While you're looking at the sample output from
875: .I bscmon
876: and
877: .I bsctrace,
878: try following along using the BSC state diagram, then read the session
879: narrative which follows. You'll get a pretty good idea of how the
880: BSC communications protocol works by doing so.
881: .LP
882: When you start communicating with a remote host, try running the monitor
883: and trace facilities and study the output.
884: .NH 3
885: A Communications Session
886: .LP
887: In this session,
888: .I bscmon
889: was piped directly to
890: .I bsctrace,
891: which was
892: running with the
893: .I -verbose
894: option.
895: .LP
896: The following trace types appear:
897: .DS
898: d - decision state
899: s - send state
900: r - receive state
901: c - message class just received
902: o - trace overruns
903: f - function state
904: e - error state
905: .DE
906: .ta 10 20 30
907: .DS
908: BSC State Trace Report
909: 05/31/83
910: ---------------------------------------------------------------------------
911: Time |State | Type | Message
912: ---------------------------------------------------------------------------
913: 09:57:09 | 0 | d |
914: 09:57:09 | 1 | d | Start - Point-to-Point
915: 09:57:11 | 1 | d | Idle
916: 09:57:11 | 2 | s | Initial write system call - send line contention b
917: | | | id (ENQ)
918: 09:57:11 | 3 | r | Wait bid acknowledgement (ACK-0)
919: 09:57:11 | 7 | c | Even acknowledgement
920: 09:57:11 | 4 | d | Bid acknowledged - check host id
921: 09:57:11 | 5 | d | Host ok
922: 09:57:11 | 6 | s | Send text block
923: 09:57:11 | 2 | o | Trace overruns: 2
924: .DE
925: .DS
926: BSC State Trace Report
927: 05/31/83
928: ---------------------------------------------------------------------------
929: Time |State | Type | Message
930: ---------------------------------------------------------------------------
931: 09:57:11 | 7 | r | Wait text ACK
932: 09:57:11 | 8 | c | Odd acknowledgement
933: 09:57:11 | 8 | d | Text acknowledged
934: 09:57:11 | 9 | f | Correct ACK
935: 09:57:11 | 29 | e | Last text block - send EOT
936: 09:57:11 | 13 | s |
937: 09:57:11 | 0 | d | Send EOT, restart from beginning
938: 09:57:11 | 1 | d | Start - Point-to-Point
939: 09:57:12 | 1 | d | Idle
940: 09:57:12 | 30 | r | Initial read system call
941: 09:57:19 | -1 | c | Receive timeout
942: 09:57:19 | 30 | r | ** No bid received - try again
943: 09:57:27 | -1 | c | Receive timeout
944: 09:57:27 | 30 | r | ** No bid received - try again
945: 09:57:34 | -1 | c | Receive timeout
946: .DE
947: .DS
948: BSC State Trace Report
949: 05/31/83
950: ---------------------------------------------------------------------------
951: Time |State | Type | Message
952: ---------------------------------------------------------------------------
953: 09:57:34 | 30 | r | ** No bid received - try again
954: 09:57:36 | 0 | c | Enquiry message
955: 09:57:36 | 31 | f | ENQ received - set odd block expected, even acknow
956: | | | ledgement (ACK-0)
957: 09:57:36 | 32 | d | Check Receive buffer availability
958: 09:57:36 | 35 | s | Receive buffer available - send block acknowledgem
959: | | | ent (ACK0/1)
960: 09:57:37 | 36 | r | Wait for text block (ETB or ETX)
961: 09:57:37 | 4 | c | Text block - not last of series
962: 09:57:37 | 37 | d | Text block received - check CRC/LRC
963: 09:57:37 | 32 | d | Correct CRC/LRC - flip expected block and acknowle
964: | | | dgement (ACK0/1)
965: 09:57:37 | 32 | d | Receive buffer unavailable - delay and retry
966: 09:57:37 | 35 | s | Receive buffer available - send block acknowledgem
967: | | | ent (ACK0/1)
968: .DE
969: .DS
970: BSC State Trace Report
971: 05/31/83
972: ---------------------------------------------------------------------------
973: Time |State | Type | Message
974: ---------------------------------------------------------------------------
975: 09:57:37 | 36 | r | Wait for text block (ETB or ETX)
976: 09:57:37 | 4 | c | Text block - not last of series
977: 09:57:37 | 37 | d | Text block received - check CRC/LRC
978: 09:57:37 | 32 | d | Correct CRC/LRC - flip expected block and acknowle
979: | | | dgement (ACK0/1)
980: 09:57:38 | 32 | d | Receive buffer unavailable - delay and retry
981: 09:57:38 | 35 | s | Receive buffer available - send block acknowledgem
982: | | | ent (ACK0/1)
983: 09:57:38 | 36 | r | Wait for text block (ETB or ETX)
984: 09:57:38 | 4 | c | Text block - not last of series
985: 09:57:38 | 37 | d | Text block received - check CRC/LRC
986: 09:57:38 | 32 | d | Correct CRC/LRC - flip expected block and acknowle
987: | | | dgement (ACK0/1)
988: 09:57:38 | 32 | d | Receive buffer unavailable - delay and retry
989: .DE
990: .DS
991: BSC State Trace Report
992: 05/31/83
993: ---------------------------------------------------------------------------
994: Time |State | Type | Message
995: ---------------------------------------------------------------------------
996: 09:57:38 | 35 | s | Receive buffer available - send block acknowledgem
997: | | | ent (ACK0/1)
998: 09:57:38 | 36 | r | Wait for text block (ETB or ETX)
999: 09:57:38 | 4 | c | Text block - not last of series
1000: 09:57:38 | 37 | d | Text block received - check CRC/LRC
1001: 09:57:38 | 32 | d | Correct CRC/LRC - flip expected block and acknowle
1002: | | | dgement (ACK0/1)
1003: 09:57:39 | 32 | d | Receive buffer unavailable - delay and retry
1004: 09:57:39 | 35 | s | Receive buffer available - send block acknowledgem
1005: | | | ent (ACK0/1)
1006: 09:57:39 | 36 | r | Wait for text block (ETB or ETX)
1007: 09:57:39 | 4 | c | Text block - not last of series
1008: 09:57:39 | 37 | d | Text block received - check CRC/LRC
1009: 09:57:39 | 32 | d | Correct CRC/LRC - flip expected block and acknowle
1010: | | | dgement (ACK0/1)
1011: 09:57:39 | 32 | d | Receive buffer unavailable - delay and retry
1012: 09:57:39 | 35 | s | Receive buffer available - send block acknowledgem
1013: | | | ent (ACK0/1)
1014: 09:57:39 | 36 | r | Wait for text block (ETB or ETX)
1015: 09:57:39 | 4 | c | Text block - not last of series
1016: 09:57:39 | 37 | d | Text block received - check CRC/LRC
1017: 09:57:39 | 32 | d | Correct CRC/LRC - flip expected block and acknowle
1018: | | | dgement (ACK0/1)
1019: .DE
1020: .DS
1021: BSC State Trace Report
1022: 05/31/83
1023: ---------------------------------------------------------------------------
1024: Time |State | Type | Message
1025: ---------------------------------------------------------------------------
1026: 09:57:40 | 32 | d | Receive buffer unavailable - delay and retry
1027: 09:57:40 | 35 | s | Receive buffer available - send block acknowledgem
1028: | | | ent (ACK0/1)
1029: 09:57:40 | 36 | r | Wait for text block (ETB or ETX)
1030: 09:57:40 | 9 | c | Temp. transmit delay
1031: 09:57:40 | 36 | r | Wait for good text block
1032: 09:57:47 | -1 | c | Receive timeout
1033: 09:57:47 | 36 | r | ** Timeout - keep waiting for text block
1034: 09:57:47 | 3 | c | Text block - last of series
1035: 09:57:47 | 37 | d | Text block received - check CRC/LRC
1036: 09:57:47 | 39 | s | ** Incorrect CRC/LRC - send NAK and count as tempo
1037: | | | rary error
1038: 09:57:47 | 36 | r | Wait for good text block
1039: 09:57:55 | -1 | c | Receive timeout
1040: 09:57:55 | 36 | r | ** Timeout - keep waiting for text block
1041: 09:58:02 | -1 | c | Receive timeout
1042: 09:58:02 | 36 | r | ** Timeout - keep waiting for text block
1043: 09:58:10 | -1 | c | Receive timeout
1044: 09:58:10 | 36 | r | ** Timeout - keep waiting for text block
1045: 09:58:17 | -1 | c | Receive timeout
1046: 09:58:17 | 36 | r | ** Timeout - keep waiting for text block
1047: 09:58:25 | -1 | c | Receive timeout
1048: 09:58:25 | 36 | r | ** Timeout - keep waiting for text block
1049: 09:58:32 | -1 | c | Receive timeout
1050: 09:58:32 | 36 | r | ** Timeout - keep waiting for text block
1051: 09:58:40 | -1 | c | Receive timeout
1052: 09:58:40 | 36 | r | ** Timeout - keep waiting for text block
1053: 09:58:47 | 47 | e |
1054: 09:58:47 | 0 | d |
1055: 09:58:47 | 1 | d | Start - Point-to-Point
1056: .DE
1057: .NH 3
1058: Session Narrative
1059: .LP
1060: This session starts out normally, with an enquiry (ENQ, the bid for
1061: control of the line). The host returns the expected acknowledgement,
1062: an ACK-O, and we send a block of text. The trace overruns aren't
1063: a problem, really; we just missed some data. The host again returns
1064: the expected acknowledgement, an ACK-1 this time. We've sent the
1065: last block of the file and have no more files to send, so we send
1066: an EOT to the host, go back to the start, and indicate that we're
1067: ready to receive. We continue trying to receive an ENQ from the host
1068: until we get one (if we didn't get one, we'd time out). We acknowledge
1069: it with an ACK-O. We then check to be sure that we can receive, and
1070: since we can, we send another ACK. We receive a block of text, check
1071: that it's good, and acknowledge it when it proves to be. During this
1072: time, the host tries to send another block. We're busy, so we send
1073: the host a temporary transmit delay (TTD). The host tries again,
1074: we're ready this time, and we receive another block. This process
1075: continues until the host sends us a TTD, meaning that it isn't ready
1076: to transmit and we should wait. We do this by sending a non-acknowledgement
1077: (NAK), which is find in this case. We check that we haven't gone
1078: over the NAK limit. If we had, we'd abort this session due to errors
1079: on the line. As it is, when the host does send a text block, it isn't
1080: a good one. We NAK it and try to receive it again, to no avail.
1081: The host has stopped transmitting, so we time out and disconnect.
1082: .LP
1083: Normally, the host would continue transmitting to us until it had
1084: nothing to send. If we no longer had anything to send, either, we'd
1085: time out and disconnect.
1086: .FS
1087: DLBA Version 1.1
1088: .FE
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.