[comp.os.vms] Summary: FTP vs BITNET, DVI for QMS, and IO redirection

RALPH@UHHEPG.BITNET.UUCP (08/11/87)

Date:  9-AUG-1987 22:32:06.32
From: Ralph Becker-Szendy RALPH AT UHHEPG
To:   B_INFOVAX,RALPH
Subj: Summary: FTP vs BITNET, DVI for QMS, and IO redirection
Hi there in Netland,

Here, as promised, the summary of responses to my questions about FTP on
BITNET and TeX DVI drivers: Thanks a lot for all the help i got; it's really
amazing how many people had usefull hints. My mailbox runneth over ...

1. Can one access files on Internet nodes (where Internet := Arpa + NSFnet)
   via FTP (File Transfer Protocol) from a node connected only to BITNET ?

   NO. FTP is a part of the (DoD defined) protocol called TCP/IP, which
   is not at al compatible with the IBM RSCS protocol used on BITNET. One needs
   a physical connection to Internet. The basic difference is: TCP/IP is
   a packet switching network, with an application layer allowing remote
   logins, file and mail transfer, while RSCS is just a file transfer protocol.

   TCP/IP packages are available from Wollongong ($$), Fusion ($$$) and
   Tektronix / CMU (for free !); it seems they differ not only in price,
   but also in performance; there may be others, and i have no idea which
   ones are good and which ones aren't.
   A solution for our site (remember: we are in Hawaii, a lonely,
   uncivilized (computerwise) island in the pacific) would be
   - Get a TCP/IP package,
   - find a mainland Internet host willing to connect to us,
   - establish a connection using a serial line (like long-distance phone
     and two modems) using SLIP (Serial Line IP),
   but the phone bills would just be too nice ! BTW, there are 9600 baud modems
   which can pretend to have two 4800 baud or even four 2400 baud channels,
   but still using just one phone line. So, it may be possible to split the
   9600 baud line connecting us to BITNET (via a leased satellite link) for
   use with BITNET and with Internet.
   Summary: looks difficult and expensive. Seems that i don't have any chance
   to get access to all the beautiful public domain software which sits around
   on Arpa; but, on the other hand, it's my own fault to work in Hawaii ...

2. We are just beginning to set up a nice TeX environment. For graphics,
   we have several Tektronix 401x compatible terminals. We use a Talaris 800
   laser printer (QMS compatible, maybe even QMS built), and we bought the
   Talaris Font Manager, and their TeX support package. The support package
   includes a nice selection of fonts (but nothing extraordinary), and a
   DVI driver (called QTEX), which seems to be quite stupid (no graphics file
   include, no support for other fancy printing options, quite slow).
   Talaris does not include any previewers in their package: they want to
   sell their Laser-Printer compatible graphics terminals ! So, i asked
   for help on getting / making more fonts, help on a better DVI driver
   for QMS-type printers, and help on DVI previewers for use with Tektronix-type
   terminals or even regular alphanumeric terminals (for very crude, quick
   previewing). Let's go through it, one by one:

   - Creating fonts: use Metafont, which is on the Stanford TeX tape,
     available through Maria Code or through Kellerman & Smith ($$).
     Unfortunately, i haven't found the tool to convert the Metafont-generated
     .PK and .TFM files into the Talaris .FXX and .FXY formats. Someone out
     there claimed to have it, but did not answer any help requests. I'll
     keep trying. This tool will also be available from Talaris (with their
     MetaFont package, now in beta test).
     BTW, expect to use a lot of CPU time for generating fonts: some people
     told me they gave up after one week of CPU time !

   - Getting fonts: the Stanford TeX distribution tape (see above) contains
     a lot of fonts, too. But the problem of converting them to .FXx format
     still applies.

   - A DVI-driver for Talaris or QMS: that's a tough one.
     There is a whole family of DVI drivers, written by Nelson Beebe
     (Beebe@Science.Utah.Edu), but none of them is for QMS; but, with a week
     of heavy C programming, one of them could be converted to QMS.
     Alec Dunn at the University of Sydney supposedly wrote a QMS driver,
     but i was not able to contact him.
     On the UNIX TeX Distribution there is an "old" MIT QMS driver, probably
     not very usefull for VMS sites. I heard of one site unsucessfully trying
     to use it for seven months, and then buying one ...
     ArborTexT and n^2 consultants sell QMS drivers, both are in the $1000
     range.
     The only light in the desert: the system manager of a particular site
     claims they brought up TeX on a Talaris printer entirely with public
     domain software. Unfortunately, i have not been able to contact their
     TeX support programmer, but i'll continue trying. Stay tuned ...

   - A previewer for Tektronix: DVITOVDU, available from DECUS (program
     tape VAX135), or on the Stanford TeX tape. According to some it's full
     of bugs, others claim to use it successfully all the time.
     One naturally has to live with quite bad resolution, and the pixel
     files have to be transformed into short vectors for display (which
     makes everything very slow), but some claim to get fine results ...

   - Previewers for ASCII terminals: the 24x80 resolution does not
     allow wonders, but for quick checking:
     Some previewer like this is also on the Stanford TeX tape.
     There is DVITTY, written by Svente Lindahl (enea!ttds!zap@seismo.css.gov)
     in Pascal and C for Unix systems. It does not require any special macros,
     and some people seem to use it very sucessfully.
     Then there is DVIDOC (available through the LaTeX style collection
     at Rochester). It is a macro package and a modified DVITYPE; it redefines
     fonts and format, therefore the page breaks are different from a running
     TeX on a "real" output device.
     Last but not least: R M Damerell (damerell@Cs.Ucl.AC.UK) has CRUDETYPE,
     which transforms the DVI into a regular text file, which you "preview"
     with any editor.

If more info comes up, i'll post part two of a summary later.

BTW, concerning the answers to my two questions about input/output redirection
while a program runs (like switchable command input / list output): also,
thanks a lot for the help. Unfortunately, half the help offered told me
things i did know very well, and the other half does not solve the problem.
It all stops at a "feature" (read: "sloppy programming", i.e. bug) of VMS:
LIB$GET_INPUT, LIB$PUT_OUTPUT and friends open their files at their first
invocation, and they never notice if you reassign their files with
LIB$SET_LOGICAL. All the fixes offered would involve a lot of stupid work
in the bowels of RMS. I came up with the following solution (here for the
input redirection, output works the same way): i extract LIB$GET_INPUT from
STARLET.OLB, and rename it to LI0$GET_INPUT.OBJ. I change all occurences of
LIB$GET_INPUT inside it to LI0$GET_INPUT (using a binary editor). Then i
wrote my own LIB$GET_INPUT (in FORTRAN), which usually just passes the
arguments and return values to LI0$GET_INPUT. Whenever it finds a "@file"
command in the input stream, it opens this file, and reads from that file
instead (using regular FORTRAN IO), until it gets an EOF: then it switches
back to using LI0$GET_INPUT (which really is nothing else than a cloaked
LIB$GET_INPUT). There is just one (very bad) catch: i don't really know what
happens when we get a new VMS release. I haven't found the source of those
routines yet (the microfiches have been thrown out), so i don't know whether
they do any un-kosher system-dependant tricks. Quite unelegant hacking, but
it works, and it is not much work ... i am not proud of it.

Ralph Becker-Szendy
University of Hawaii / High Energy Physics Group

Disclaimer: The views expressed here are probably not endorsed by my
employer. I hardly ever actually speak to my employer. Even our system manager
stops smiling when i come by. I am in no position to recommend or advise
against any program mentioned here.