Path: utzoo!attcan!uunet!lll-winken!ncis.llnl.gov!helios.ee.lbl.gov!pasteur!agate!bionet!csd4.milw.wisc.edu!mailrus!uflorida!gatech!mcnc!duke!romeo!jpe From: jpe@romeo.cs.duke.edu (John P. Eisenmenger) Newsgroups: comp.protocols.tcp-ip Subject: Re: Re: VERY strange behavior at USENET/BITNET gateway Message-ID: <13155@duke.cs.duke.edu> Date: 23 Jan 89 17:37:04 GMT References: <8901151801.AA12681@ucbvax.Berkeley.EDU> Sender: news@duke.cs.duke.edu Reply-To: jpe@romeo.UUCP (John P. Eisenmenger) Organization: Duke University CS Dept.; Durham, NC Lines: 28 In article <8901151801.AA12681@ucbvax.Berkeley.EDU> NJG@CORNELLA.CIT.CORNELL.EDU (Nick Gimbrone) writes: >>> Something which happens (at least with UREP) is that files coming >>> in from BITNET-land have lines which are supposed to be truly >>> empty instead contain some number of blanks. You would think this >>Perhaps some of you would take a hand in convincing IBM that an >>empty line should exist. >This is not an IBM problem. The IBM software has no problem treating >the line of blanks as a "null line". In this case it sounds more like >a UREP problem. It is a UREP problem. If I remember correctly (though I never handled mail with UREP -- just batch jobs, plus I'm now at a different site) files come in using Fortran Carriage control characters. The UREP software doesn't handle this correctly at all, which leads to horrible printouts and such. I traced the problem to the routing rdr uses to con- vert from IBM to UNIX formats. In addition to the blanks on blank lines, you'll find that UREP REQUIRES a 66 line page for printouts, and counts lines internally. It keeps this line count in order to simulate a form-feed by (you guessed it) sending lots of blank-filled lines to output. I rewrote the FCC stuff to (almost) match the output from fpr (I just used \r instead of backspacing for overstrike). This gave us correct printouts and decreased the output file sizes. -John jpe@dukee.egr.duke.edu