rickb at bensene.com
Wed Dec 20 14:57:16 CST 2006
> Rick wrote....
> > Z999 was also an interesting account --- it was the "system
> >overhead" account.
> I'm not so sure about this (and I have the source). There are
> no "default"
> accounts present when a 2000/Access system is loaded. There
> isn't even an A000 account. All accounts must be manually
> created and none are supplied on initial distribution tapes.
> There were general conventions put forth like some accounts
> were not to be created because they were reserved for HP
> products, but that wasn't coded into the OS anywhere that I
> am aware of. I have never heard of a "system overhead"
> account. If there is, I've certainly learned something new. I
> will go back and dig for confirmation on this. Off the top of
> my head, I think the Z999 account was reserved for containing
> the text files of the source of the operating system (if you
> had purchased the source), or maybe for the BASIC system
> diagnostics (initial system confidence test). Of course, I'm
> much more familiar with 2000/Access than 2000F, so perhaps
> this is something that only existed on F and no others. I
> dunno. Wierd.
I believe that the NAM-, and Z999 thing were part of 2000C and 2000C'.
I may have accidentally implied that this existed in 2000F and beyond.
It didn't. We tried.
> > 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.
> Generally true, but that depends on the file type ;)
Again, this likely was under 2000C or C', which I believe only supported
text file types.
> > Normal user accounts were limited to perhaps 100 to 200
> blocks of storage.
> "Normal" user accounts were limited to whatever the system
> administrator typed in as the account block limit when
> creating the account in question.
> It could be anything. The limit you could specify for each
> account had a maximum of 65535 blocks. You could not issue a
> CRE command for a file larger than that as a result.
When the NAM-, trick was pulled, the 64K block size limit seemed to be
removed. The system would try to create a file of any size specified.
My recollection is that in normal cases, the space on disk had to be
contiguous, so if there wasn't enough contiguous space to create the
file, the create would fail. But, in the case of the "overhead"
account, it appears that this restriction was lifted, and it'd hunt all
over the disk for unused blocks and claim them, which really slowed the
system down, and, if too large a filesize was specified would cause the
system to crash, as it'd run out disk space. When we did the NAM-,
trick, then did a "CATalog" command, the account was listed as Z999, and
not the account we were logged into originally.
There seemed to be no way to "escape" back to the original login account
without logging off, and dialing back in. Interestingly enough, if we
did a big file CREation, we could just shut off the teletype, and the
CREate would continue to run (as evidenced by the other teletypes
stopping I/O activity) until complete, then the login would be
terminated. It appeared that the carrier loss interrupt on the IOP, or
the communications between the IOP and executive were "tied up" during
the CREate process. Whatever the case, it's clear that the "CREate"
operation was a blocking operation.
The installation we had at our high school (actually, the system was
owned by what was called the
Multnomah County (Oregon) Intermediate Education District, which served
a number of middle schools and high schools in East Multomah County.
Since the system served a lot of users, disk space was limited to 100 or
200 blocks. Usually Freshman and Sophomore students got 100 blocks, and
Junior and Senior students got 200, because the projects were larger. A
local community college (Mt. Hood Community College) had their own
2000/Access system, and user accounts were given significantly more disk
blocks than we were allowed.
As you said, it's all site-dependent in terms of the amount of disk
space allocated for each account.
I visited the data center at MCIED at one point in time. At the time, I
believe that they were running 2000C.
There were two CPU's, one that ran the TSB executive, and another that
did I/O. The machine had a multi-platter "washing machine" style disk
drive (top load), and an HP 9-track tape drive. I believe it had 32
phone lines attached to it. The modem bank was in a back room, and
consisted of a bunch of Bell 103 datasets (later upgraded to 1200-baud
datasets, I think once 2000F came around). The CPUs I believe were
2100's, and there was a paper tape reader/punch unit. There was also
the "fixed head" disk, and one could use the
SANctify (as A000) command to make a program resident on the fixed head
disk for much faster access. Swapping activities also occurred on the
fixed head disk. I know that it existed, because the fixed disk
"crashed" a few times, resulting in multi-day outages. Once 2000F came
around, the fixed head disk wasn't needed, and reliability increased
quite a bit. At first we had only ASR-33 teletypes, but once 2000F
rolled around we started getting some DECWriter II's that could do 1200
baud. What a difference that made. Downside was that the DECWriters
didn't have paper tape, so we had to resort to loading programs
pre-punched on tape (we had a bunch of offline ASR33's for tape
preparation) on one of the online ASR-33's to load new programs, then
migrate to the DECWriters for test/debugging.
> You can pretty much forget trying to get up 2000A or 2000B.
> They required fixed head disks which just aren't to be found.
Seems to me that it might be possible to build a pretty simple emulator
for the fixed head disk device using either Battery-Backed static RAM,
or perhaps fast flash memory. The tough part would be emulating the DMA
> For 2000E, you need just one cpu, paper tape reader, and 7900
> disc drive.
> Neither firmware nor mag tape required. Need that 12920/21 mux though.
We never had 2000E, nor 2000A/B. On 2000/E, without a tape drive, how
were backups done?
The service bureau started with 2000C, and upgraded along the line to
C', F, then added a second system that was running 2000F', then both
systems were upgraded to 2000/Access over a period of time. Sometime in
the early '80's, with the advent of microcomputers, schools started
building up their own systems with BASIC (our high school built an IMSAI
kit, and a Sol-20 while I was there), and started using these with
8K-BASIC to supplement the timeshare systems. I believe sometime around
'84 or '85, the TSB systems were decommissioned, and offered for sale.
Some acquaintences I know tried to pool financial resources to acquire
them, but the IED wanted a LOT of money for them, even though they were
quite antiquated by that time. To my knowledge, they sat for quite some
time, and then were sold to a scrapper, who mercilessly destroyed the
systems to reclaim the gold. I kept in touch with my teacher for a
period of time after I graduated, and they had started using Apple II's
as the primary teaching machines. Last I saw him, they had a Corvus
shared disk drive connected to "networked" Apple II's. I then lost
touch with him after the school district re-organized, and I've tried
many times to try to find him, but to no avail.
> For 2000/Access, you need two cpus, 7900/7905/7906/7920
> drive, 7970 tape, firmware, and 12920/21 mux. If your cpus
> are 2100's, then you also must have a paper tape reader.
> The IOP firmware has been located for 2100, 21MX/M, and
> 21MX/E. These can be copied, so that isn't the huge deal it
> used to be. The 12920 muxes are still hard to find, the
> 7900's are somewhat hard to find. The rest is fairly easily
> obtainable these days.
I'd love to find the pieces to put a system together, but given the
scarcity of parts, and the costs involved, it's probably way beyond my
means. Worse yet, as time goes by, the stuff becomes more and more
scarce. Probably have to settle with memories of those fun times.
More information about the cctech