20 Dec
2006
20 Dec
'06
2:31 p.m.
Rick wrote....
Yeah, in high school I had S000 (student personal accounts were S001-S999)
and was limited to 500 blocks or so. Suffice it to say I take a little
nostalgic glee that I'm not hampered by that any longer ;)
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.
I don't think the two are related is what I'm
saying. The NAM- command
existed in all TSB systems to my knowledge (except A and or B perhaps). In
Access, there was nothing special about Z999, nor did it exist, unless some
administrator happened to create an account that they happened to decide to
call Z999. Maybe this is "an F thing".
Again, this likely was under 2000C or C', which I
believe only supported
text file types.
You know, I think you're right. I don't think 2000C
supported ascii or
device files, just basic formatted files.
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.
I believe that's correct - at least during the
create process.
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.
Wierd! I shall have to dig in to
that. I have never seen a version of TSB
that showed you what account you were on as a result of the CAT command.
Whatever the case, it's clear that the
"CREate"
operation was a blocking operation.
I think that's true on access too, I
don't recall for sure.
As you said,
it's all site-dependent in terms of the amount of disk
space allocated for each
account. We never had 2000E, nor 2000A/B. On 2000/E, without a
tape drive, how
were backups done?
2000E took a rather different view of the disc drives than one
would expect
if you are familiar with the other versions. On 2000E a tape drive was not
required and backups were done disc to disc (or on tape if you had it).
There was lots of swapping of removable media, data backed from fixed to
removable platters, it was a rather odd affair. It sort of made more sense
actually, the fixed vs. removable platters were (somewhat) treated as
separate drives. On 2000/Access (and I suspect C and/or F) drives that had
fixed & removable platters were just treated as one drive - the removable
media must always be present and it wasn't useful to swap/remove it (you
couldn't address them separately in an intelligent way).
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.
Eh, perhaps. Two
things to consider. First, SIMH has a working simulation of
HP2000/Access. So if you want to run it in emulation, it works and is a
blast. Second, in the few bits of spare time that I manage to acquire here
and there - I have projects afoot to make HP2000/Access able to run on MUCH
easier to find hardware (but still vintage HP hardware). You'd still need a
21MX/E cpu (but those are common as dirt). I think there may be a way to get
rid of the requirement for the IOP firmware, and get rid of the requirement
for muxes altogether, as well as work with more easily available hard
drives. In addition, I'd like to utilize DMS to access more than the 32K TSB
normally will see. The hope is to also only require one cpu. Even if two
cpu's are required, I was wondering if the processor interconnect kit (a lot
of boards) could be removed and a direct interface via the MPP port could be
utilitized. This would bring it into the range of able to being able to run
on HP1000 systems that are still pretty common and easy to get ahold of
these days.
Jay