bglenden@mandrill.cv.nrao.edu (Brian Glendenning) (08/23/90)
Does anyone have any advice on how one can get a .dvi file from a Sun
(in my case) to a VMS VAX in a non-mangled fashion - i.e. so that the
file can be generated on the Sun but printed on the Vax? (We
have ftp/binary - I presume the problem is in byte orderings etc? Is
the problem even tractable?). Thanks.
--
Brian Glendenning - National Radio Astronomy Observatory
bglenden@nrao.edu bglenden@nrao.bitnet (804) 296-0286zhou@linac.fnal.gov (Ping Zhou) (08/23/90)
In article <BGLENDEN.90Aug22195536@mandrill.cv.nrao.edu> bglenden@mandrill.cv.nrao.edu (Brian Glendenning) writes:
Does anyone have any advice on how one can get a .dvi file from a Sun
(in my case) to a VMS VAX in a non-mangled fashion - i.e. so that the
file can be generated on the Sun but printed on the Vax? (We
have ftp/binary - I presume the problem is in byte orderings etc? Is
the problem even tractable?). Thanks.
I used binary ftp to transfer the .dvi and never had any problems. Yes, it
is from a SUN 4 to VAX/VMS. Then QTEX and print the .Q file (in my case).cschreur@ruunsa.fys.ruu.nl (Toine Schreurs) (08/23/90)
In <BGLENDEN.90Aug22195536@mandrill.cv.nrao.edu> bglenden@mandrill.cv.nrao.edu (Brian Glendenning) writes: >Does anyone have any advice on how one can get a .dvi file from a Sun >(in my case) to a VMS VAX in a non-mangled fashion - i.e. so that the >file can be generated on the Sun but printed on the Vax? (We >have ftp/binary - I presume the problem is in byte orderings etc? Is >the problem even tractable?). Thanks. No, The problem is not byte ordering. The problem is the carriage control parameter of the file on the VAX. I think you should CONVERT the file to a file with fixed length records. I don't know how, because I always need experiments to get a CONVERT ok. We had about the same problem, but at our site we created two solutions that may be impossible for you: 1) We installed TEX on the VAX 2) We have a UNIX machine talking DECNET. When the file is copied TO THE VAX, it's ok, when the file is copied FROM UNIX we have the same problems that you have. -- Rob Hooft.
dhosek@hmcvax.claremont.edu (Hosek, Donald A.) (08/23/90)
In article <ZHOU.90Aug22221749@linac.fnal.gov>, zhou@linac.fnal.gov (Ping Zhou) writes... >In article <BGLENDEN.90Aug22195536@mandrill.cv.nrao.edu> bglenden@mandrill.cv.nrao.edu (Brian Glendenning) writes: > Does anyone have any advice on how one can get a .dvi file from a Sun > (in my case) to a VMS VAX in a non-mangled fashion - i.e. so that the > file can be generated on the Sun but printed on the Vax? (We > have ftp/binary - I presume the problem is in byte orderings etc? Is > the problem even tractable?). Thanks. >I used binary ftp to transfer the .dvi and never had any problems. Yes, it >is from a SUN 4 to VAX/VMS. Then QTEX and print the .Q file (in my case). The problem is probably due to the fact that the Sun treats the DVI file as a stream of bytes while VMS looks at the DVI file as a series of 512-byte records. Most DVI drivers for VMS assume that the file has RMS blocking of F512 (although some C drivers I've looked at force stream access so the blocking doesn't matter). So, if your file isn't F512, you might have problems. The next problem that could occur is that in creating the F512 file, FTP will bad out the last record with x00's. Intelligent drivers ignore this, but, unfortunately not all drivers are intelligent. It should be possible to write a C program to insure that all blocking, padding etc. of the DVI file is correct after file transfer, but I've never bothered to do it myself. -dh --- Don Hosek TeX, LaTeX, and Metafont support, consulting dhosek@ymir.claremont.edu installation and production work. dhosek@ymir.bitnet Free Estimates. uunet!jarthur!ymir Phone: 714-625-0147 finger dhosek@ymir.claremont.edu for more info
lgy@phys.washington.edu (Laurence G. Yaffe) (08/24/90)
dhosek@hmcvax.claremont.edu (Hosek, Donald A.) writes: [ Stuff about how some VMS dvi processers require 512 byte padding. ] >It should be possible to write a C program to insure that all >blocking, padding etc. of the DVI file is correct after file >transfer, but I've never bothered to do it myself. It's even easier to write a C program which will correctly pad a DVI file to a multiple of 512 bytes BEFORE transferring it. I wrote such a filter ages ago when I had to deal with a VMS machine; even though its only 35 lines, I'm reluctant to waste net bandwidth posting it. I'll be happy to send it to anyone wishing a copy. -- -------------------------------------------------------------------------- Laurence G. Yaffe Internet: lgy@newton.phys.washington.edu University of Washington Bitnet: yaffe@uwaphast.bitnet
chris@mimsy.umd.edu (Chris Torek) (08/24/90)
In article <BGLENDEN.90Aug22195536@mandrill.cv.nrao.edu> bglenden@mandrill.cv.nrao.edu (Brian Glendenning) writes: >Does anyone have any advice on how one can get a .dvi file from a Sun >(in my case) to a VMS VAX in a non-mangled fashion - i.e. so that the >file can be generated on the Sun but printed on the Vax? (We >have ftp/binary - I presume the problem is in byte orderings etc? Is >the problem even tractable?). Thanks. The problem is not bit or byte ordering. DVI files have an exactly defined byte order, and any machine with 8-bit bytes has the same bit order as any other machine *at the byte level* (which is where all communication takes place). The problem is, quite simply, VMS. More specifically, it is the fact that VMS has file formats. (`These concepts fill a much-needed gap in other operating systems.' [Thompson]) There is no such thing as `a file' in VMS: rather, there is `a fixed block file', `an ISAM file', `a stream-LF file' (relatively new), and so forth. The first step is to figure out what file format(s) the TeX on the VMS VAX uses. The best format would be stream-LF files, but because these are new it may use fixed 512-byte records. In any case, the next step is to find out whether the DVI interpreter software on the VMS VAX makes any special requirements. For instance, with 512-byte records, the last record may have to be padded with DVI filler bytes (code 223 decimal) to make it a multiple of 512 bytes. Once you have this information, you can decide whether DVI files from the Sun must be altered (typically by padding with filler bytes) before they can be printed---TeX pads with four to seven bytes only, so as to make the file size a multiple of four; you may need 4 to 515---and if so you must decide where to put this step (on the Sun or the VAX). Finally, you must find out how to control the FTP software on the VMS machine so as to have it write out the proper kind of file. Chances are this consists of telling it to write a `binary' file or maybe a `structured' file (but this will depend on whose FTP software you have). If you are lucky, the VMS VAX will have and use stream-LF files, the FTP software will use these for `binary' transfers, and you will be able to do something like this: foosun% ftp foovax [log in sequence] ftp>bin [acknowledgement] ftp>put foo.dvi [succeeds] ftp>quit [close down] foosun% If you are not lucky, the easiest solution is probably to write a special program on the Sun that pads the DVI file, connects to the FTP server, sends the appropriate control commands, and then sends the file. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris