![[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.