david@ms.uky.edu (David Herron -- Resident E-mail Hack) (03/30/88)
Wow, this is the last place I expected to find a flame at BITNET and how to send news across BITNET, but here it is so here it where I'll answer it. I'm answering in public for everyone's (especially the moderators) benefit and because I have 2+ years experience with doing news across BITNET. Also, I'm cross-posting to news.misc with followups directed there. news.misc readers -- the posting that Walter is responding to is one complaining about either a lost source posting, or a mangled one. I forget which. In article <747@ndsuvax.UUCP> ncreed@ndsuvax.UUCP (Walter Reed) writes: >BITNET FLAME ON *** >Alright guys, I've let my sysadmin know about this but so far, nothing has >been done about it yet. Calm down. There's not much he can do about it. >BITNET also wraps lines or just plain truncates >them. Yes. That's because IBM machines see *everything* as a stream of cards. Sometimes the cards are rather wide -- I understand that there's a file format which has cards up to 65k characters wide -- but it's cards (er.. records, sometimes varying length) all the same. >Our site has no choice but to use bitnet due to the fact that it >is an underfunded state university in nowheres ville. >We don't have the >money to call uunet for much (we do mail through it though.) I know. I've been there. I feel for you, *really*! >Maybe files >should be encoded so that they come through un-damaged (I'm talking BITNET >to BITNET and not the whole net.) Now you're talking. As I recall the setup at North Dakota the news arrives at NDSUVM1 before it goes to NDSUVAX. If so there's nothing you can do -- at least not that I know of. Between vaxes you have compatible file semantics and encoding/decoding programs. One of my two BITNET feeds is to a VMS vax cluster at the U of Louisville and I use the following scheme (The other is an IBM): Sending: compress file | btoa | netcopy netnews@ulkyvx03 Receive: atob file | uncompress | rnews The same scheme also worked well going to/from a 3b20 at GaTech. (btoa/atob are part of the v4 compress distribution -- the newest versions of uuencode should also work as well, that is the versions which add the crc to the end of the line which (as a side effect) gaurantees that lines with trailing blanks aren't truncated). This exact scheme won't work if one of the sites is an IBM machine. The IBM machines don't have compress, for instance. Now possibly you could convince something like atob/btoa to run on the IBM machine, but even if you did that the news get's filtered through the file system of the IBM machine and who knows what transformations will be done in the bowels of those high speed card punches? >Why is BITNET so set on PUNCH CARD >technology???? Tabs expanded to spaces, trailing spaces chopped, files >strangely truncated, lines wrapped or cut at 80 columns, this has >GOT to be FIXED. You want a historical lesson too? I think the short answer is that IBM standardized their stuff "too early". They standardized when punched cards were the norm. Sigh, youngsters! :-) >We also lose files! It is REALLY irritating to have >only 2 parts of a 3 part posting make it through this MESS OF A NETWORK. >*** flame off (I've calmed down somewhat.) I have news for you ... Even backbone sites on the internet who use NNTP for the bulk of their news traffic lose things. (i.e. us, hopefully I have that problem fixed :-) ) >Moderators: I wouldn't mind if you posted everything in uuencoded zoo! >It would allow me to get files accurately. There would probably be too much >opposition to this however. How about a vote? This sort of thing has been suggested many many many many many times, the objections include: 1. Compression -- It's a fact that when you compress a file then compress the compressed file that the file gets bigger. One of the Lempel-Ziv gang believes that if it *doesn't* get bigger then there's something wrong with your compression algorithm, that you're not getting as much compression as you could. Anyway, my memory of zoo (I've never used zoo) is that it uses compress in the middle of it. It would not be a good idea to have something compressed going through news because many of the feeds where it matters (i.e. long distance uucp) already compress their news batches. 2. Unreadability -- Somebody sitting in rn seeing this posting of source for something or other can, right now anyway, read down into the posting a ways and find the README and decide then if s/he wants to save this source away. With a uuencoded zoo (or any other archived format) you have to save the posting, hassle with it a few minutes to get it unarchived, THEN you get to read the README or whatever. It's not as convenient. 3. Not everybody has the same archivers -- I don't have a copy of zoo around. I know, look in sources.amiga because the new version is right there (I think). I also don't have it on my Unix machines because I have never had the time to look at it. We also don't have arc on our Unix machines because I've never had the time to track down a working version... We do have tar and cpio :-). -- <---- David Herron -- The E-Mail guy <david@ms.uky.edu> <---- or: {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET <---- <---- I don't have a Blue bone in my body!