Article View: comp.text.tex
Article #1913moving DVI files from ASCII to EBCDIC
From: Jim Graham
Date: Tue, 01 Sep 1992 03:12
Date: Tue, 01 Sep 1992 03:12
61 lines
3478 bytes
3478 bytes
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) ------------------------------------------------------------------------------
Technical Details
Message-ID:
<715264965snx@n5ial.chi.il.us>Path:
arc1-ca.pugleaf.net!sparky!uunet!cs.utexas.edu!rutgers!uwm.edu!psuvax1!uxa.ecn.bgu.edu!news.ils.nwu.edu!news.acns.nwu.edu!nucsrl!ddsw1!serveme!n5ial!jimReferences:
<1992Aug28.144526.27967@news.th-darmstadt.de>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!cs.utexas.edu!rutgers!uwm.edu!psuvax1!uxa.ecn.bgu.edu!news.ils.nwu.edu!news.acns.nwu.edu!nucsrl!ddsw1!serveme!n5ial!jim From: jim@n5ial.chi.il.us (Jim Graham) Newsgroups: comp.text.tex Subject: moving DVI files from ASCII to EBCDIC Message-ID: <715264965snx@n5ial.chi.il.us> Date: 1 Sep 92 03:12:05 GMT References: <1992Aug28.144526.27967@news.th-darmstadt.de> Organization: Me? Organized? Hah! :-) Lines: 61