Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site fortune.UUCP Path: utzoo!linus!philabs!seismo!hao!hplabs!hpda!fortune!rpw3 From: rpw3@fortune.UUCP Newsgroups: net.dcom Subject: Re: BISYNC info wanted - (nf) Message-ID: <2005@fortune.UUCP> Date: Thu, 15-Dec-83 19:03:39 EST Article-I.D.: fortune.2005 Posted: Thu Dec 15 19:03:39 1983 Date-Received: Mon, 19-Dec-83 00:08:53 EST Sender: notes@fortune.UUCP Organization: Fortune Systems, Redwood City, CA Lines: 69 #R:hcr:-55400:fortune:3100002:000:3473 fortune!rpw3 Dec 15 15:37:00 1983 I think this is worth posting, but will also mail to your friend: -------- The problem with BSC ("bisync") is, there is NO standard that was ever implemented by any hardware. Wait! let me explain...not a flame, history. On the one hand, we have the BSC spec itself, which I believe is one of the obsolete/out-of-print documents you referred to. This is really an overall architecture document, and was not either precise enough to implement to (by itself) nor restrictive enough to ensure compatibility. [No such things as internets in those days.] It basically described the frame format of the physical link level, and a few options. It can be summarized as: addrdata (plus polls, ACK/NAKs, EOTs, etc) On the other hand, there were the individual hardware products made by IBM (and others) which manifested some interpretation, extension, restriction, violation, twisting, or bending "just a little" of that general overall spec. You had to read those reference manuals (2780, etc.) VERY carefully to understand what to implement. For example, even though the BSC spec said "clearly" how to pack link control characters into text (you have to use transparent mode), some models of 3270's, while operating in NON-transparent mode, allowed absolute binary characters in certain cursor control operations, said characters looking sometimes just like an , , or , which you MUST NOT treat as end of frame and you MUST NOT have any free characters between... Ooops! Well, uh, I guess your BSC link-level state machine had to know that the higher-level protocol was a 3270, no? The situation was simply that people didn't use the techniques we have now -- clean layering, state machines, uninterpreted type-fields, etc. Each "protocol designer" for each new product (generally a hardware type) did whatever was needed to get their particular device to accomplish its mission. That was permitted since the BSC spec was never really broken "badly". That's why many companies, when they wanted to find a "bisync" spec, picked a piece of physical hardware that they were willing to emulate (2780/3780/3741/3274/327x), got its reference manual from IBM and that older BSC manual (to fill in the holes), and started reading. Oh, and by the way, just exactly which IBM operating system does it have to talk to and with which access mathod on that O/S? DOS/BTAM? /TCAM? OS/VSE/VTAM? (apologies if I have scrambled some of those letters.) The watchword was: "Emulate hardware, not software. The hardware won't change out from under you." (Later, it did.) Sorry if it doesn't sound like I'm helping, but the whole problem was so massive that literally thousands of programmers were employed (in such companies as Data-100, Memorex, Comten, and many others) just keeping up with "bisync compatibility". Prediction -- the recent announcements be IBM concerning 327x & PC's REALLY means that IBM has finally selected a network virtual terminal protocol, and it's (no, not Telnet) the SNA 3274 (at the RS-232 level). Other protocols will be supported only as back-compatibility emulations of that. (That actually helps, to have one standard which all of the others deviate from.) My guess is we will see (IBM-style) internet routing of 3270 PU's very soon. Rob Warnock UUCP: {sri-unix,amd70,hpda,harpo,ihnp4,allegra}!fortune!rpw3 DDD: (415)595-8444 USPS: Fortune Systems Corp, 101 Twin Dolphins Drive, Redwood City, CA 94065