HP 2000F'

The login was of the form HEL-XYYY,<password> for the earlier systems, and later, HEL-XYYY,<password>,<terminal identifier>. The password was usually a combination of non-printing control characters to avoid the password showing up on the teletype printout. X was a letter from A through Z. YYY was 000 through 999. If the last two digits of YYY were 00, then the account was a "group" account, which was available to all members of that group as a library account, for shared files/programs. A000 was indeed the "root" account, which did have access to a few extra commands. Z999 was also an interesting account --- it was the "system overhead" account. All available "free" disk space was available to this account. In 2000C and C' systems, there was a "beature" (a cross between a bug and a feature) where if the "NAM" (name a program) command was issued with an argument of ",", e.g., "NAM-,", the user would get "dropped" into the Z999 account with no password request. It's unclear if this was a "back door" for HP service personnel, or if it was a bug, but it was explicitly noted in the user's manual for the system that "," was an invalid argument to the NAM command. "NAM-," would simply be acknowledged by the TSB system sending a linefeed, indicating that the command had been processed. At this point, it was possible for a user to "crash" the system by asking it to create a file that was so large that it consumed the remainder of free disk space. The timeshare system could also be "locked up" for varying periods of time by creating large files. In TSB, data files had to be pre-allocated to a given size, and all of the blocks were "claimed" as part of the creation process. For example, doing a "CRE-FILE,10000" would create a 10,000 block file. Normal user accounts were limited to perhaps 100 to 200 blocks of storage. Creating a 10,000 block file took the system quite a long time, and during that time, all timesharing operations would cease while the system was locked in "system state", creating the file. This was discovered by a friend and myself in high school. It was quite interesting the first time we tried "NAM-,", simply because the manual said it was invalid, and were quite surprised when the system just accepted the command, but didn't appear to do anything. We then typed "CAT" (shows disk catalog), and it showed an empty directory, with a large number of available blocks. We tried "CRE-FILE,1000" at first, and when we hit RETURN, we noted that there was a period of time where the other three teletypes which were active in our high school computer center stopped typing, or even echoing input, until our command completed, then everything resumed where it left off. We deleted FILE, and then tried CRE-FILE,10000, and the other terminals stopped...dead in their tracks, for a few minutes (most people thought the system had crashed, and turned off their teletypes) while the system was creating this large file. We then did a PUR-FILE (PURge - deleting the file), which again locked things up (for a period of less time) while the system was deleting the file. We then did a "CRE-FILE,1000000", which was in excess of the number of blocks that the "CAT" (CATalog) command showed, and the system "went away", and the computer math teacher soon got a call from the data center saying that the system had crashed for unknown reasons, and that it would be some time before it would come back. We had quite a bit of fun writing little programs which would wait for a specific time (during other people's classes), and then "crash" the system at that time. Eventually, we got caught. We didn't get into too much trouble. How they tracked us down, I'm not sure, but I believe that through the crash dumps that the system generated when it crashed, HP engineers were able to figure out which async mux line was causing the problem, and then tracked it back to our school. A patch was put in place that fixed the problem, resulting in an "ILLEGAL FORMAT" error if NAM-, was entered. This fix was incorporated into all later releases of HP 2000 TSB, including HP 2000F, HP 2000F', and HP 2000/Access. I sure loved these systems. They were wonderful systems to learning the basics of computing through. They weren't as fully featured or flexible as competitor Digital Equipment's RSTS/E timeshare systems (I have other fun stories to tell about finding bugs in RSTS/E), but they HP system were really a lot of fun, especially 2000/Access, which added a lot of neat functions. I'm really happy that Jay has managed to find the various special bits (microcode and mux hardware) that makes it possible to have an operational HP Timeshared BASIC system running as "the real thing". Rick Bensene The Old Calculator Web Museum http://oldcalculatormuseum.com