philipp@GMUVAX2.GMU.EDU (Philip Prindeville) (01/19/88)
Hi. I need to know whatever happened to the ad hoc tn3270 group -- did they ever produce and RFC and if so where can it be FTPd from? Also, is there a formal description of SUPDUP that doesn't presume PDP-10 assembly language programming (or indeed, NCP and 9 bit bytes)? I've never hacked on a PDP-10 (I guess I've been unlucky :-), and I'm using TCP (aren't we all?). Thanks, -Philip
DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) (01/20/88)
Date: Mon, 18 Jan 88 17:54:05 est
From: philipp@gmuvax2.gmu.edu (Philip Prindeville)
Hi.
I need to know whatever happened to the ad hoc tn3270
group -- did they ever produce and RFC and if so where can it
be FTPd from? Also, is there a formal description of SUPDUP
that doesn't presume PDP-10 assembly language programming (or
indeed, NCP and 9 bit bytes)? I've never hacked on a PDP-10
(I guess I've been unlucky :-), and I'm using TCP (aren't
we all?).
SUPDUP is RFC734. It does not use 9-bit bytes for transmission; it uses
8 bit bytes and works today over TCP and CHAOS (and any other 8-bit
meduim). (It took me all of two hours to convert the ITS SUPDUP server
and/or user to TCP from NCP.) Many of the definitions look like they
deal with 12 or 36 bit quantities, but view them as logical fields
instead of parts of a 36 bit word. I have written and maintained user
ends of SUPDUP for PDP-11s (many years ago) so things aren't really that
PDP-10/ITS specific.MRC@PANDA.PANDA.COM (Mark Crispin) (01/20/88)
Philip Prindeville -
I wrote the SUPDUP RFC (RFC 734) 10 years ago. It doesn't
require any knowledge of PDP-10 assembly language programming,
although it was written in a day when PDP-10 conventions were
more widely understood. Today, I would probably write it a bit
differently.
However, it isn't that difficult to understand octal numbers
or even the n,,m format. n,,m is a way of specifying a 36-bit
quantity, where n is the more significant 18 bits and m is the
least significant 18 bits. PDP-10's are big-endian, so the number
120,,54 is equivalent to 00012000054 bit is easier to understand.
36-bit quantities are only used in the terminal code registers
sent at startup. They're sent as 6-bit bytes (in our example, as
00 01 20 00 00 54) and on a byte-oriented machine I'd store them
in the least significant 6 bits of 6 consecutive 8-bit bytes.
If you bothered to read the RFC, you'd realize that there
are no NCP dependencies at all; the connections are 8-bits. A
9 and 12-bit character set for keyboard INPUT are possible for
operating systems which swallow them. The rules for folding
such characters down are well defined in the RFC, and if a
client SUPDUP doesn't want to send such characters it doesn't
have to (all it has to do is not set the bit saying it has such
a keyboard).
People who have never seen a line of PDP-10 assembly code
have read, understood, and implemented Unix code based on the
SUPDUP RFC. Give it a try.
-- Mark --
-------braden@VENERA.ISI.EDU (01/21/88)
Some people think SUPDUP is a swell protocol. Why doesn't one of them take the time to write a reasonable protocol RFC on SUPDUP, without assuming 36-bit machines. Then the rest of the Internet world can find out how wonderful SUPDUP is. Bob Braden
DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) (01/21/88)
Date: Wed, 20 Jan 88 09:37:35 PST
From: braden@venera.isi.edu
Some people think SUPDUP is a swell protocol. Why doesn't one of them
take the time to write a reasonable protocol RFC on SUPDUP, without
assuming 36-bit machines. Then the rest of the Internet world can
find out how wonderful SUPDUP is.
As MRC said, SUPDUP does not assume 36-bit machines. Depending on what
level of abstraction you choose to take, the RFC either does or does not
assume 36 bit machines. What the RFC does is abstract various
quantities into 36 bit words and uses some PDP-10 notation conventions.
That's an abstraction, one of many possible abstractions, and in many
senses just as valid as any other abstraction (e.g., one that assumes
Vaxen or 68000s) one might use to (re)write the RFC with.
Maybe what you are asking for is an appendix which describes how to
pack, unback and interpret the 36-bit quantities for "normal" machines?MRC@PANDA.PANDA.COM (Mark Crispin) (01/22/88)
Page 3 of RFC 734, "INITIALIZATION", in the very first paragraph describes completely how to pack, unpack, and interpret the 36-bit quantities in terms of 8-bit bytes. The SUPDUP protocol itself uses 8-bit bytes in transmission over the network. I doubt the critics of the SUPDUP RFC have ever bothered to read it; it's so much easier to criticize based on hearsay and the dread sequence "PDP-10". -------
PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville") (01/22/88)
Some people think SUPDUP is a swell protocol. Why doesn't one of them
Yes, I think supdup is a great protocol. That is why I asked. However,
I didn't realize I was opening up Pandora's box when I asked...
take the time to write a reasonable protocol RFC on SUPDUP, without
assuming 36-bit machines. Then the rest of the Internet world can
find out how wonderful SUPDUP is.
As MRC said, SUPDUP does not assume 36-bit machines. Depending on what
level of abstraction you choose to take, the RFC either does or does not
assume 36 bit machines. What the RFC does is abstract various
quantities into 36 bit words and uses some PDP-10 notation conventions.
That's an abstraction, one of many possible abstractions, and in many
senses just as valid as any other abstraction (e.g., one that assumes
Vaxen or 68000s) one might use to (re)write the RFC with.
Given that is a networking protocol, the most reasonable representation
would be how the bits (bytes, or octets) appear 'on the wire', not how
they pack into a particular machine's word.
In view of the number of RFCs in print, we should know by now how to
express an idea without reverting to assembly language (for any processor,
whether esoteric or commonplace)...
-PhilipDCP@QUABBIN.SCRC.Symbolics.COM (David C. Plummer) (01/22/88)
Date: Fri, 22 Jan 88 00:44:08 EST
From: "Philip A. Prindeville" <PAP4@AI.AI.MIT.EDU>
Given that is a networking protocol, the most reasonable representation
would be how the bits (bytes, or octets) appear 'on the wire', not how
they pack into a particular machine's word.
In view of the number of RFCs in print, we should know by now how to
express an idea without reverting to assembly language (for any processor,
whether esoteric or commonplace)...
I think MRC was right. Have you read the RFC, or are you making attacks
based on hearsay? There is no, absolutely no, assembly language in the
RFC. As for your "on the wire" argument, TCP and IP don't even do that.
TCP and IP abstract the bytes into headers which are displayed and
discussed in the RFC as headers, not bytes on a wire. They describe how
those headers appear on the wire, just as the SUPDUP RFC describes how
the 36 bit quantities appear on the wire. I'm really trying to avoid
making disparaging remarks about people's inability to convert between
abstractions.MRC@PANDA.PANDA.COM (Mark Crispin) (01/23/88)
Please read the goddamn RFC before flaming any further. There is NO "reversion" to assembly language. SUPDUP was first implemented for a particular operating system. It transmitted a few of that operating system's registers from client to server. Those registers are 36-bit quantities. As transmitted on the wire, each register is 6 bytes, with the most significant two bits zero in each byte. The first byte contains the most signifiant 6 bits, the second the next, ... The registers themselves are described as 36-bit values. That is because that is what they are. You could think of them as a series of bytes, but that obscures their original representation. Furthermore, these registers are dealt with ONCE -- at startup -- in the entire SUPDUP transaction and are used nevermore. 99.9% of the time these registers will contain constants wired into the program, with the possible exception of screen width and height. The intellectual laziness expressed by certain individuals (who obviously have not read the RFC beyond a fleeting glimpse) is a prime example of why the Japanese and the Koreans are taking over America's markets. -------