rrg@hcr.UUCP (Ron Gomes) (12/14/83)
This is being posted for a friend; replies to him and not to me,
please.
--------------------
If anybody has any information concerning the Bisync protocol, possibly
a definitive standard thereof, or, failing that, if there is a Bisync
expert who would be willing to divulge his or her knowledge to us, we
would be extremely grateful for any help received. Any full-blown
documentation would not include IBM GA 27-3004-2 or IBM GA 24-3089, as
the Toronto IBM documentation centre has informed us that
these are obsolete, and have not been replaced.
Please reply by mail to decvax!hcr!gandalf!carr
Dave Carr
Gandalf Data Ltd
Ottawa Ontario
(613) 225 0565 ext 352rpw3@fortune.UUCP (12/16/83)
#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: <SYN><SYN><SOH>addr<STX>data<ETX><CRC><PAD>
(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 <ETX>, <ETB>, or <EOT>, which
you MUST NOT treat as end of frame and you MUST NOT have any free <SYN>
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 94065taylor@ecsvax.UUCP (01/03/84)
Unfortunate though it is, probably the best way to emulate an IBM bisync device is to 'discover' the protocol using a datascope on a working device. I have been attempting for over 3 years to find an exact documentation of the various protocols, and agree with fortune!rpw3 that the only rule is to 'use what works.' Steve Taylor NC Educational Computing Service decvax!duke!mcnc!ecsvax!taylor