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.