hartung@amos.ling.ucsd.edu (Jeff Hartung) (05/27/89)
In article <24928@agate.BERKELEY.EDU> vojta@math.berkeley.edu (Paul Vojta) writes:
#It is available via anonymous ftp from:
# wsmr-simtel20.army.mil [26.2.0.74] file pd1:<msdos.editor>vi-19a.arc,
# or
# grape.ecs.clarkson.edu [128.153.13.196] file /c/bin1/pv_vi109.arc
#
#Remember to set "tenex" mode before transferring. And, it's free software, not
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
#shareware.
#
#--Paul Vojta, vojta@math.berkeley.edu
Actually, that is only true of SIMTEL20. If you download from grape, you'll
need to set the "binary" mode, NOT the "tenex" mode, as is also true about
almost every ftp site BUT SIMTEL20.
--Jeff Hartung--
Disclaimer: My opinions only, etc., etc., BLAH! BLAH! BLAH!...
ARPA - hartung@amos.ucsd.edu
UUCP - ucsd!amos.ucsd.edu!hartungked@garnet.berkeley.edu (Earl H. Kinmonth) (05/27/89)
>Actually, that is only true of SIMTEL20. If you download from grape, you'll >need to set the "binary" mode, NOT the "tenex" mode, as is also true about >almost every ftp site BUT SIMTEL20. Not only must you use tenex mode for downloads, you must switch to ascii mode in order to do a directory listing or to download files that are not in arc, compressed, or whatever format. This strikes me as a singularly half-assed arrangement, especially since the system detects when you try to do a dir with the tenex mode on. If the damn software can detect this situation, why can't it flip the toggle itself? I suppose complaining about SIMTEL20 falls into the category of looking a gift horse in the mouth (or some other portion of its anatomy), but given its apparent function, TOPS20 must be near, if not dead on, the poorest OS choice for the system that could have been made. Could it be that this system was acquired through the same mechanism that gives us 800 mega-buck planes that can be shot down by one misguided bird and other triumphs of Pentagon procurement?
MRC@WSMR-SIMTEL20.ARMY.MIL (Mark Crispin) (05/29/89)
Earl -
Speaking as one of many individuals who have used the PDP-10 computer
(which is what TOPS-20 runs on) for *decades*, I can assure you that there are
excellent reasons why we are fond of the hardware and software architecture.
There is a reason why, for example, the Japanese use TOPS-20 systems as a
central facility in their AI and 5th Generation labs. It is not for price or
performance reasons!!!
The people who throw bricks at TOPS-20 are either irrational or merely
don't know. Since I know you from Usenet, I have reason to believe you're in
the latter category. I'm going to try to enlighten you, and perhaps help you
in getting the situation improved at your end.
The basic problem is in the FTP protocol itself. An FTP server is a
slave to the instructions of the FTP client. In your case, the FTP server is
running on a DEC-20 and your FTP client is an old version of the Unix client.
FTP's default is ASCII. This means that on the network the data is a
stream of 7-bit characters in 8-bit bytes, with new lines indicated by a
carriage return character followed by a line feed character. On Unix, this
requires the replacement of a Unix new line character with the carriage
return/line feed pair. On the DEC-20, this involves unpacking successive
7-bit bytes from 36-bit words, 5 bytes per word. [Yes, one bit is wasted
every 5 characters on the DEC-20, but on Unix one bit is wasted each
character. C'est la vie].
Image mode means data from the file as a bitstream taken 8 bits at a
time with no character substitution. On an 8-bit byte based machine (such as
most but by no means not all Unix systems!) this means a byte-by-byte transfer
of data. On the DEC-20, this means taking four 8-bit bytes from the high
order 32-bits of a word, a byte from the low order 4-bits of that word and
the high-order 4 bits of the next word, and four 8-bit bytes from the low
order 32-bits of that next word -- for a total of 9 bytes per pair of words.
This would be fine and good, except that this is an unnatural way to
store 8-bit data on the DEC-20. A more natural form is to store it as 4
8-bit bytes per word, in the high order 32-bits of each word. SIMTEL20 stores
its data in that format, which "wastes" 4 bits but is significantly easier to
deal with (since you can easily grab 32-bit quantities).
The "tenex" command to the Unix FTP client tells the server to use "your
local 8-bit image type" as opposed to "binary type". This, in itself, isn't
objectionable. In fact, there is no reason why Unix FTP servers can't
implement the exact same binary mode as an alias for image mode. They should
if they don't -- then you'd only have a single command to memorize.
So much for different data modes. As long as you accept the idea that
some computers may want to use other data formats than a stream of 8-bit bytes
you have to accept the idea of data format conversion. It's a shame that Unix
has promulgated 8-bit thinking -- we are in serious danger of becoming wedged
in that mode. It certainly does not give us any growth for the future. Japan
uses a 14-bit character set. Some people think that successive powers of two
are the way to go, keeping the basic structure of 8-bit bytes. The problem
is, some computers store bytes in backwards order (e.g. VAX) while most
computers (even the PDP-10/DEC-20) stores bytes in forwards order. If you
take 32-bit data from one machine -- even one Unix -- to another you often
have to have the bytes of binary data swapped!!!!!
Now, to turn to your problem. You have a very old version of the Unix
FTP client. Modern versions will automatically switch from "local 8" (the
so-called "Tenex" type) to "ASCII" when doing a directory command. Alas,
the server is *forbidden* by the protocol from unilaterally doing this. If
the FTP client says "give me a directory in local 8 mode" the server really
has no idea of what to do.
We *could* make the server pretend it is in ASCII mode and *perhaps* your
client will work, but there is no guarantee that it will -- or, that if we
make it work for you that it would work for someone else (perhaps on a machine
whose bytes are swapped from yours). So, whenever possible, we encourage
users who have this problem to get on your system programmers' case until they
update your FTP software.
I guess another way of putting it is -- we are following the FTP protocol
as it is set out. We don't like it, and we agree it is stupid at times. We
are, however, quite afraid of deliberately introducing a violation at our end
to compensate for a violation at another end -- even a common violation --
since it may cause problems down the line.
If I can assist you in locating a better version of Unix FTP, please let
me know. I for one would not tolerate such a broken Unix FTP on *my* Unix
workstation (a NeXT).
On a side note, if you've had performance problems in getting to
SIMTEL20, that is not the fault of the operating system but rather of the
network topology in which SIMTEL20 lives. That *is* being worked on.
-- Mark --
Systems Programmer, SIMTEL20
-------WANCHO@WSMR-SIMTEL20.ARMY.MIL ("Frank J. Wancho") (05/29/89)
Earl, I have not seen the original message(s) which prompted your message. So, quite possibly the answers below are out-of-context. Nonetheless, they beg for comment and explanation... >If you download from grape, you'll need to set the "binary" mode, >NOT the "tenex" mode, as is also true about almost every ftp site >BUT SIMTEL20. The key word is "almost." You MUST use tenex (type l 8) *command* between hosts which do not have the same byte ordering within words or bit ordering in bytes or have word sizes which are not 32 bits. The tenex command guarantees correct retrieval and storage for 8-bit binary data. you must switch to ascii mode in order to do a directory listing... If the damn software can detect this situation, why can't it flip the toggle itself? A properly implemented user ftp should always keep track of the current settings and temporarily change the settings for certain commands which it knows require certain settings, such as a dir command, and restore the original settings on completion. The ftp server must not change any modes unless commanded by the remote end to do so. given its apparent function, TOPS20 must be near, if not dead on, the poorest OS choice for the system that could have been made. SIMTEL20 was originally purchased as a network host to run simulation and graphics FORTRAN programs transferred from local 36-bit machine. At the time, the DECsystem-20 and its TOPS20 operating system met those key criteria. Most of the machines on the net were TOPS20 or TENEX hosts; the VAX VMS machines did not have network software, and only a small handful of Unix machines, mainly PDP-11s, and some Berkeley VAX Unix machines were on the net. The primary purpose of SIMTEL20 is to function as a very reliable mail host for various Army and other federal agencies and their contractors. It must be said, from my point of view of exposure to many different operating systems in various capacities in almost 30 years, that TOPS20 is still by far THE best I have ever had the pleasure to use and maintain. SIMTEL20 fell into its current *secondary* function as an archive host when the organization which ran the original archive host was dissolved (almost six years ago), and SIMTEL20 had some otherwise unused disk space. We could have run another OS on this machine, but the filenames would have been severely contrained, among other limiting factors. Could it be that this system was acquired through the same mechanism that gives us 800 mega-buck planes that can be shot down by one misguided bird and other triumphs of Pentagon procurement? No. This was an off-the-shelf, competitive procurement, not a design-and-build to spec procurement. I suppose complaining about SIMTEL20 falls into the category of looking a gift horse in the mouth (or some other portion of its anatomy),... Probably so. We certainly do not claim any exclusive right as an archive host. In fact, there are *many* other archive hosts to use; most of them are Unix machines. Moreover, we have no plans to switch over to another machine and/or OS; we are quite satisfied, for our *primary* purposes, to continue as we have been and for quite some time to come, and to add additional (cheap) mass storage to support the archives as the need arises and the funds become available. Frank Wancho System Manager SIMTEL20
ked@garnet.berkeley.edu (Earl H. Kinmonth) (05/29/89)
In article <WANCHO.12497726106.BABYL@WSMR-SIMTEL20.ARMY.MIL> WANCHO@WSMR-SIMTEL20.ARMY.MIL ("Frank J. Wancho") writes: >Earl, > >I have not seen the original message(s) which prompted your message. >So, quite possibly the answers below are out-of-context. Nonetheless, >they beg for comment and explanation... Marc Crispin has given a detailed response. Part of the problem is apparently an archaic version of ftp that is on the SUN I use. > given its apparent function, TOPS20 must be near, if not dead on, > the poorest OS choice for the system that could have been made. > >Berkeley VAX Unix machines were on the net. The primary purpose of >SIMTEL20 is to function as a very reliable mail host for various Army >and other federal agencies and their contractors. Key word in my posting is apparent. In terms of gaining access to material for downloading to **IX and **DOS environments, a system with a file structure similar to **IX or **DOS would be far more congenial. uunet.uu.net is easier to work with. >TOPS20 is still by far THE best I have ever had the pleasure to use >and maintain. I'm curious: why does TOPS20 seem to be going nowhere or am I mistaken in this impression? >unused disk space. We could have run another OS on this machine, but >the filenames would have been severely contrained, among other >limiting factors. Compared to BSD **IX? Although there are other considerations in a file system, case insensitivity hardly seems a plus.
astieber@csd4.milw.wisc.edu (Anthony J Stieber) (05/30/89)
Is storage limited on Simtel20? Would it be wise to refrain from submitting new programs to Simtel or to just submit to multiple sites? By the way how much storage is there? -- Tony Stieber astieber@csd4.milw.wisc.edu
WANCHO@WSMR-SIMTEL20.ARMY.MIL ("Frank J. Wancho") (05/30/89)
Tony, There is some space remaining - not a whole heck of a lot. Continue to submit here until we ask you to hold off. We expect more disk drives to be installed in late Fall. --Frank
WANCHO@WSMR-SIMTEL20.ARMY.MIL ("Frank J. Wancho") (05/30/89)
In terms of gaining access to material for downloading to **IX and
**DOS environments, a system with a file structure similar to **IX
or **DOS would be far more congenial.
Agreed. Most of the "inconvenience" is in the str:<dirname.subdir>
part of the syntax, and our FTP server at least allows you to do a
pseudo-connect which simply defaults that part of the pathname.
Although not high on our To-Do list, but on the list nonetheless, is
to add the mapping of Unix-style pathnames to TOPS20 pathnames. That
should ease the pain.
I'm curious: why does TOPS20 seem to be going nowhere or am I
mistaken in this impression?
It isn't going anywhere, and it doesn't matter. It works.
>We could have run another OS on this machine, but
>the filenames would have been severely contrained, among other
>limiting factors.
Compared to BSD **IX? Although there are other considerations in
a file system, case insensitivity hardly seems a plus.
The alternate OS for this machine was ITS. Its filename syntax is
dsk:dir;fn1 fn2 with the space and each field limited to six
characters. Each field in a TOPS20 filename is limited to 39
characters.
Your comment about case insensitivity applies to MSDOS as well, which
may not necessarily make it a minus, reference your congeniality
comment above.
--Frankandy@mks.UUCP (Andy Toy) (05/31/89)
In article <MS-C.612396113.2035015474.MRC@wsmr-simtel20.army.mil> MRC@WSMR-SIMTEL20.ARMY.MIL (Mark Crispin) writes: > If I can assist you in locating a better version of Unix FTP, please let >me know. I for one would not tolerate such a broken Unix FTP on *my* Unix >workstation (a NeXT). FYI, if you don't read comp.protocols.tcp-ip, here is an announcement for the latest and greatest FTP software for UNIX. Path: watdragon!watmath!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!UUNET.UU.NET!rick >From: rick@UUNET.UU.NET (Rick Adams) Newsgroups: comp.protocols.tcp-ip Subject: Re: FTP continuation lines. Message-ID: <8905092231.AA07176@uunet.uu.net> Date: 9 May 89 22:31:40 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 34 The latest, greatest versions of ftp and ftpd (for UNIX) can be obtained from uunet.uu.net in networking/ftp.tar.Z and networking/ftpd.tar.Z These are newer versions than those on the Berkeley networking tape. If you are seriously using ftp or running an ftp server (under UNIX), then you really want to get these versions. They run on SUN SunOs3.5, SunOS4.0, Sequent Dynix 3.0.12 and most recent BSD vax/tahoe releases. The portability problems are mainly missing includes, etc and are quite easy to fix for other systems. These programs have had a lot of work put into them. Among the many changes are: Fully rfc959 and host requirements draft compliant Support for determining system type, restarting partial transfers in image or ascii mode, determining the size or last modification time of a file (via SIZE and MDTM which will be documented in the next version of the FTP rfc) ftp automatically puts you into binary mode if the remote server is of the appropriate type (no more user complaints about getting compressed files in ascii mode). Support for default logins via the .netrc. E.g. you could put a line in your .netrc that looked like: default anonymous rick@uunet.uu.net and ftp would automatically log you in as username anonymous with password rick@uunet.uu.net (of course this can be overridden) many others. Sites running ftp archives are especially encouraged to run this version of ftpd. It's been running on uunet and the ucb machines for weeks and is stable. ---rick -- Andy Toy, Mortice Kern Systems Inc., Internet: andy%mks@watmath.UWaterloo.ca 35 King Street North, Waterloo, UUCP: uunet!watmath!mks!andy Ontario, CANADA N2J 2W9 Phone: 519/884-2251 FAX: 519/884-8861
dhesi@bsu-cs.bsu.edu (Rahul Dhesi) (05/31/89)
In article <24994@agate.BERKELEY.EDU> ked@garnet.berkeley.edu in comp.binaries.ibm.pc.d (Earl H. Kinmonth) writes: >I'm curious: why does TOPS20 seem to be going nowhere or am I mistaken >in this impression? In one sense TOPS-20 is going nowhere: DEC is supporting the DECsystem-20 family very, very reluctantly, and only because there are a lot of people who like the machine very much. Most of DEC's efforts in developing new software are directed towards VAX/VMS. TOPS-20 is a powerful operating system hidden behind a powerless command interpreter and relatively poor language support. However, there is so much third-party software available for TOPS-20 (including language translators, text editors, mail software, and modified versions of the command interpreter) that the whole package, properly configured, is very usable. People greatly like the command prompting feature of TOPS-20: At any point in a partially-typed command line you can ask TOPS-20 to complete a filename for you, or ask it to list possible things you can type at that point. Some of Columbia's implementations of Kermit, and some of the extras in today's csh and tcsh shells, are based on the TOPS-20 model. So while officially TOPS-20 can be considered to be obsolete and no longer being supported (not much, anyway), unofficially it seems likely to live on for a while. Its death will probably come when DEC stops providing maintenance for the hardware it runs on. Unfortunately the DEC-20 was really designed for assembly language programming and not for supporting high-level languages. It has a fairly orthogonal instruction set but has some funny features (like no condition flags, infinite levels of indirection, variable byte sizes, and a 36-bit word size) that might not make things easy for a compiler writer. At one time a machine called the Jupiter was widely publicized as DEC's successor to the DEC-20. This kept people from moving to other vendors while the VAX was developed. Some interesting insights into the DEC-20 architecture are described in one of the chapters of the book "Computer Engineering: A DEC View of Hardware Systems Design," by Bell, Mudge, and McNamara. (Aside: This is a slightly *biased* DEC view. As Tracy Kidder points out in "The Souls of a New Machine" about De Castro, the designer of the PDP-8, who was impertinent enough to leave DEC and go to work for Data General: "They expunged De Castro." The PDP-8 section in the book doesn't mention his name at all.) (Followups to comp.os.misc.) -- Rahul Dhesi <dhesi@bsu-cs.bsu.edu> UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi Career change search is on -- ask me for my resume
nelson@sun.soe.clarkson.edu (Russ Nelson) (05/31/89)
I also encourage everyone to get Rick Adam's FTP client off of uunet (networking/ftp.tar.Z). I have added continuation lines to the c.b.i.p archives' FTP server, and that confuses some broken FTP clients. -- --russ (nelson@clutx [.bitnet | .clarkson.edu]) I'm a right-to-lifer -- everyone has a right to earn a living sufficient to feed himself and his family.
MRC@CAC.WASHINGTON.EDU (Mark Crispin) (06/01/89)
To answer your question about "why does TOPS-20 seem to be going nowhere",
it has nothing to do with the quality (or lack thereof) of the system, but
rather the fact that it runs on a single hardware platform that was discontinued
by its manufacturer in 1983. No matter how good an operating system may be,
this is a powerful concern. It is the reason why many of the TOPS-20 systems
in the world have (reluctantly) migrated to Unix. Those applications and
users who remain dependent on TOPS-20 have moved to a few key systems, e.g.
SIMTEL20.
Some of us find case independence to be a plus.
-------