From: jim@n5ial.chi.il.us (Jim Graham)
Newsgroups: comp.text.tex
Subject: moving DVI files from ASCII to EBCDIC
Date: 1 Sep 92 03:12:05 GMT
Organization: Me? Organized? Hah! :-)

NOTE:  I am not exactly an expert on ibm mainframe things, spending
most of my time on UN*X or dos, so I may be way off on this...but.....

In article <1992Aug28.144526.27967@news.th-darmstadt.de>
schrod@iti.informatik.th-darmstadt.de writes:

> That has nothing to do with ASCII or EBCDIC. Most DVI drivers assume
> that IBM mainframes (I assume that they run either MVS or VM/CMS, not
> AIX/370 ;-) store the files in fixed record files.

I'm assuming that by ``record'' you mean a line of text in a plain old
ASCII (errr, EBCDIC) text file.  well, the obvious solution is not to
use fixed-length lines in the file (but then, ibm won't let you, will
they?).  ok, so we're looking at a file where every last line of text
will be precisely the same length, no shorter, no longer.  and we want
to move a DVI file into this format....  shouldn't really be a
problem....

> If a DVI file is transferred (of course, binary) the last record is
> filled up very often, since the length of a UNIX DVI file is not a
> proper multiple of the record length.

ok.  here's the solution.  sometimes, when I send files to the
mainframe at work, I run into a problem because a line or two may
be longer than 80 chars (News/Mail & header lines usually, sometimes
entire posts when the poster doesn't have a CR key).  well, the
immediate result is that ftp informs me that those lines were
truncated. fine.

what people have suggested in the above case, however, and what I
think can be done here in reverse, is a simple change of the length
of a ``record'' as you call it.  they suggest making it very, very
long (100000000000000) and telling ftp to shut up).  I don't know
how to do this, but it's an option under ftp, they tell me.  I did
try it once, and it does seem to work fine.

ok, so why not do the reverse?  set the length of a ``record'' as you
say to 1. no more problems with an uneven fit.... right?  and since
we're not really changing the amount of real data stored in the file
(only *HOW* it is stored), shouldn't make any real difference either
way.

hope I'm not too far off here....

now, for a question:  why did ibm assume that when someone is typing,
that every single line of text that they type will always be PRECISELY
the same length?  wouldn't it just be much simpler to end a line when
a (CR, LF, CR/LF, etc.) was encountered?
   --jim

PS:  if it seems like there are any 'o' chars missing in there, it
would seem that this particular key on my keyboard just decided to
start sticking every now and then.....new keyboard, too....strange.

--
#include <std_disclaimer.h>
------------------------------------------------------------------------------
INTERNET:  jim@n5ial.chi.il.us  |  grahj@gagme.chi.il.us  |  j.graham@ieee.org
ICBM:  41.70N 87.63W                    UUCP:  gagme!n5ial!jim@clout.chi.il.us
AMATEUR RADIO: n5ial@n9hsi (Chicago.IL.US.Earth)              73 DE N5IAL (/9)
------------------------------------------------------------------------------
Xref: sparky comp.text.tex:10892 news.answers:2764