Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!stm386!clewis
From: clewis@stm386.UUCP (Chris Lewis)
Newsgroups: news.misc
Subject: Re: Messages with >80-character lines
Message-ID: <127@stm386.UUCP>
Date: Wed, 21-Oct-87 11:24:06 EDT
Article-I.D.: stm386.127
Posted: Wed Oct 21 11:24:06 1987
Date-Received: Fri, 23-Oct-87 00:19:53 EDT
References: <7523@g.ms.uky.edu> <21314@ucbvax.BERKELEY.EDU> <7526@g.ms.uky.edu> <4756@oberon.USC.EDU> <7541@e.ms.uky.edu>
Reply-To: clewis@stm386.UUCP (Chris Lewis)
Organization: STM, Toronto, Canada
Lines: 50

Regarding the discussions about 80 character truncations etc...

I haven't actually seen BITNET, but isn't it primarily VM/CMS machines
communicating by RSCS?  (Good 'ol "CP SET PUN ROUTE...", "PUNCH FILE..." 
etc.)  (I used to be a bit of a VM/CMS hacker till I saw the light :-)
That's a little archaic - if you changed the "PUNCH FILE" to "DISK DUMP"
it would be able to transmit any kind of file (read: RECFM V, 
LRECL=anything).  "DISK LOAD" on the other side.  And, it's relatively
easy to have the software figure out itself which to do (to maintain
compatibility with both)  Depending on the software
there might be some things you'd have to do with the article reading
code ("rnews" equivalent).  Mind you, this is hacking - and if you
think that getting people to upgrade their USENET software on UUCP is
hard...

IBM had (3-4 years ago) an internal news system that works sort of similarly -
I believe that it was an ultra-trivial set of EXECs that merely read
incoming "punch" files, figures out which "newsgroup" it was in and
then appended the article to a "newsgroup file".  There was a central
repository where you sent articles, and it broadcast them to all sites
that "subscribed to the net"  The user interface
was merely "link to news disk" and then the user xedit'd the newsgroups
they wanted to see.  Xedit can handle files of any width.  As you can 
well imagine, the traffic wasn't particularly high.

The point I'm trying to make is that, yes, the virtual card punch is
RECFM=F, LRECL=80, but with the standard software available for
handling the PUNCH this is no longer a limitation on what you can 
send.  Must we remain compatible with a limit on a "peripheral network"
that hasn't been a limit on those systems for ages?   (predates VM/SP!)

Yes, lines over 80 columns are a bit of a pain on my VT100, but c'est la 
vie.

Of course, ASCII<->EBCDIC translation is a real b***h with those thingies.
Braces (there are two different pairs of codes for these - depending
on the peripheral), square brackets (is anybody's 3274 GENed to display
these?), tildes (Yes Virginia, there is a tilde in EBCDIC... somewhere),
carets (Weeelll, you can download a font for one...), tabs? (what's a tab?)

Actually, as far as articles originating in ASCII-land is concerned,
I would prefer that BITNET store them totally unchanged (In ASCII, RECFM=U).
Then, when a user wants to see something, BITNET figures out whether
to use its normal article "presenter", or runs it thru a ASCII-EBCDIC
translation when the user wants to see it.  Then, ASCII-land articles
that go to another ASCII-land site via some BITNET site have no changes
whatsoever.  Of course though, I'm dreaming...
-- 
Chris Lewis, International Semi-Tech Microelectronics Inc.
{uunet|utzoo}!mnetor!stm386!clewis