28 Apr
2019
28 Apr
'19
6:28 p.m.
On 4/28/19 6:27 PM, Ray Jewhurst wrote:
I already have a Hobbyist License.? I am just
interested in
experimenting with different OSes and different versions of OSes.
ACK
I don't know what VAX hardware VMS 1.5 supported, what VAX hardware that
Simh supports, or what the overlap is between the two.
There's a reasonable chance that someone will chime in with experience.
--
Grant. . . .
unix || die
29 Apr
29 Apr
4:47 a.m.
On 04/28/2019 09:28 PM, Grant Taylor via cctech wrote:
On 4/28/19 6:27 PM, Ray Jewhurst wrote:
You are limited to what the VAX-11/780 system had for peripherals and
typically under 8MB ram (it maxed at 16mb).
I already have a Hobbyist License.? I am just
interested in
experimenting with different OSes and different versions of OSes.
ACK
I don't know what VAX hardware VMS 1.5 supported, what VAX hardware
that Simh supports, or what the overlap is between the two.
There's a reasonable chance that someone will chime in with experience.
6:41 a.m.
On Apr 29, 2019, at 7:47 AM, allison via cctech
<cctech at classiccmp.org> wrote:
On 04/28/2019 09:28 PM, Grant Taylor via cctech wrote:
Does it support MSCP? If not, RP06 would certainly serve for your disks.
paul
On 4/28/19 6:27 PM, Ray Jewhurst wrote:
You are limited to what the VAX-11/780 system had for peripherals and
typically under 8MB ram (it maxed at 16mb). I already have a Hobbyist License. I am just
interested in
experimenting with different OSes and different versions of OSes.
ACK
I don't know what VAX hardware VMS 1.5 supported, what VAX hardware
that Simh supports, or what the overlap is between the two.
There's a reasonable chance that someone will chime in with experience.
7:32 a.m.
On 04/29/2019 09:41 AM, Paul Koning wrote:
I believe its pre MSCP.? V1.5 is pre 1981 if memory serves.? MSCP I
think was introduced
Qbus systems in the 80s just prior to the MicroVAX.
VAX-11/78-- was introduced in '78 and the next generation was around
1980 with the
730 and 750 for the small systems and the 782 and 785 for the larger ones.
On Apr 29, 2019, at 7:47 AM, allison via cctech
<cctech at classiccmp.org> wrote:
On 04/28/2019 09:28 PM, Grant Taylor via cctech wrote:
Does it support MSCP? If not, RP06
would certainly serve for your disks.
paul
On 4/28/19 6:27 PM, Ray Jewhurst wrote:
You are limited to what the VAX-11/780 system had for peripherals and
typically under 8MB ram (it maxed at 16mb). I already have a Hobbyist License. I am just
interested in
experimenting with different OSes and different versions of OSes.
ACK
I don't know what VAX hardware VMS 1.5 supported, what VAX hardware
that Simh supports, or what the overlap is between the two.
There's a reasonable chance that someone will chime in with experience.
8:37 a.m.
On 04/29/2019 06:47 AM, allison via cctech wrote:
On 04/28/2019 09:28 PM, Grant Taylor via cctech
wrote:
Well, for command-line computing (well,
this IS the classic
computing list) you can do a lot.
Our first 11/780 had half a megabyte of memory. Friday
afternoon one memory board went bad, and I pulled it out. A
user group ran a gigantic batch job of mechanical analysis
over the weekend on 256 K! I was amazed, I really thought
it would thrash itself to death on that.
I ran a microVAX-II at home on one meg for years.
But, I never experienced VMS before about version 3.4, I
think. I'd really hate to run any VMS that didn't have
loadable device drivers. Doing the brute force sysgens was
so RSX-11 ish.
I think VMS 1.5 still had a bunch of utilities running in
PDP-11 emulation.
Jon
On 4/28/19 6:27 PM, Ray Jewhurst wrote:
You are limited to what the VAX-11/780 system had for peripherals and
typically under 8MB ram (it maxed at 16mb). I already have a Hobbyist License. I am just
interested in
experimenting with different OSes and different versions of OSes.
ACK
I don't know what VAX hardware VMS 1.5 supported, what VAX hardware
that Simh supports, or what the overlap is between the two.
There's a reasonable chance that someone will chime in with experience.
9:45 a.m.
On 04/29/2019 11:37 AM, Jon Elson wrote:
On 04/29/2019 06:47 AM, allison via cctech wrote:
The typical environment during the DEC years '83-93 was a 780 with a
4-12mb and dozens of users or more.
In 83 that meant 3.2 or later and much of the time was V3.8 or 3.9 till
maybe 86ish then V4 and soon after V5.
The years 83 and 84 I fondly remember V3.6 and later mostly 3.8 and
often the best available machine was
a PDP-11 [PRINCE] and [VIDEO] as the terminals and printers machines
were running RSTS and phase II DECnet.
Others of memory were MILRAT, REX, and ROYALT and later (1989) my own
work box VIDSYS (uVAXII BA123].
If memory serves V4 was the last that ran in 1meg, V5 pushed that higher
as a 4 meg system was more
common then.? However the Qbus uVAX has a RD54[system] and RD52[swap] on
separate MSCP controllers
for performance as thats where they bottlenecked when heavy swapping.
All my uVAXen have run from V4.4 [MicroVaxII/GPX] or later and my
nominal version is 5.4.? Though I have a
RZ56 with V7.2 on it.?? All are physical hardware in the Qbus BA123
realm and M3100 series.?
On 04/28/2019 09:28 PM, Grant Taylor via cctech
wrote:
Well, for command-line computing
(well, this IS the classic computing
list) you can do a lot.
Our first 11/780 had half a megabyte of memory.? Friday afternoon one
memory board went bad, and I pulled it out.? A user group ran a
gigantic batch job of mechanical analysis over the weekend on 256 K!?
I was amazed, I really thought it would thrash itself to death on that.
I ran a microVAX-II at home on one meg for years. On 4/28/19 6:27 PM, Ray Jewhurst wrote:
You are limited to what the VAX-11/780 system had for peripherals and
typically under 8MB ram (it maxed at 16mb). I already have a Hobbyist License.? I am just
interested in
experimenting with different OSes and different versions of OSes.
ACK
I don't know what VAX hardware VMS 1.5 supported, what VAX hardware
that Simh supports, or what the overlap is between the two.
There's a reasonable chance that someone will chime in with experience.
But, I never experienced VMS before about version 3.4, I think.? I'd
really hate to run any VMS that didn't have loadable device drivers.?
Doing the brute force sysgens was so RSX-11 ish.
I think VMS 1.5 still had a bunch of utilities running in PDP-11
emulation.
Jon
Running anything before V3 is painful as it was a build.? Also V1 was
tied the 780 and that did PDP11 emulation
mode for a lot of stuff.? VMS changed a lot from 4.2 to 4.6, long file
names are one that comes to mind as well as
phase III and IV DECnet.
That was a long time ago.
Allsion
9:53 a.m.
On 4/29/19 12:45 PM, allison via cctech wrote:
On 04/29/2019 11:37 AM, Jon Elson wrote:
Unless someone tried to run Ada, then it became a single user system. :-)
bill
On 04/29/2019 06:47 AM, allison via cctech
wrote:
The typical environment during the DEC years '83-93 was a 780 with a
4-12mb and dozens of users or more. On 04/28/2019 09:28 PM, Grant Taylor via cctech
wrote:
Well, for command-line computing
(well, this IS the classic computing
list) you can do a lot.
Our first 11/780 had half a megabyte of memory.? Friday afternoon one
memory board went bad, and I pulled it out.? A user group ran a
gigantic batch job of mechanical analysis over the weekend on 256 K!
I was amazed, I really thought it would thrash itself to death on that.
I ran a microVAX-II at home on one meg for years. On 4/28/19 6:27 PM, Ray Jewhurst wrote:
> I already have a Hobbyist License.? I am just interested in
> experimenting with different OSes and different versions of OSes.
ACK
I don't know what VAX hardware VMS 1.5 supported, what VAX hardware
that Simh supports, or what the overlap is between the two.
There's a reasonable chance that someone will chime in with experience.
You are limited to what the VAX-11/780 system had for peripherals and
typically under 8MB ram (it maxed at 16mb). 
7:55 p.m.
On Mon, Apr 29, 2019 at 12:44 PM allison via cctech
<cctech at classiccmp.org> wrote:
On 04/29/2019 11:37 AM, Jon Elson wrote:
We (by that I mean Software Results) had an 11/750 that started out
with 512K of RAM and quickly upgraded to 2MB. I later bumped it up to
8MB (adding the backplane wire and replacing the memory controller)
and we ran 40+ users on it.
On 04/29/2019 06:47 AM, allison via cctech
wrote:
> On 04/28/2019 09:28 PM, Grant Taylor via cctech wrote:
>> On 4/28/19 6:27 PM, Ray Jewhurst wrote:
>>> I already have a Hobbyist License. I am just interested in
>>> experimenting with different OSes and different versions of OSes.
>> ACK
>>
>> I don't know what VAX hardware VMS 1.5 supported, what VAX hardware
>> that Simh supports, or what the overlap is between the two.
>>
> You are limited to what the VAX-11/780 system had for peripherals and
> typically under 8MB ram (it maxed at 16mb).
The typical environment during the DEC years '83-93 was a 780 with a
4-12mb and dozens of users or more. In 83 that meant 3.2 or later and much of the time was
V3.8 or 3.9 till
maybe 86ish then V4 and soon after V5.
I first encountered VMS in late 1984. I started off a just a user, so
I don't recall the version, but ISTR we upgraded to either V3.4 or
V3.6. We stayed there for a while, but the MicroVAX I we got was
upgraded from, MicroVMS 1.0 to MicroVMS 4.0 as fast as that came out.
Eventually we did the upgrade path to 4.0 and beyond, pausing at 4.6
on that machine in part because we had a SI9900 controller (you had to
patch DRDRIVER.EXE to use all the cylinders of a Fuji Eagle) and in
part because we had customers who were still on V4.X. I put
V5.something on an 11/730 and we used that box to link our product for
newer versions of VMS (after 1988).
When we shut everything down in 1993, we were still running VMS 4.6 on
that 11/750 and never needed to upgrade it past 8MB. It did have
about 1GB on 4 spindles and 2 controllers.
The years 83 and 84 I fondly remember V3.6 and later
mostly V3.8...
I definitely remember V3.6 but I don't think we were on V3.8 for very
long before moving to V4.0.
If memory serves V4 was the last that ran in 1meg, V5
pushed that higher
as a 4 meg system was more common then.
I don't think I ever tried to run V4 in under 4MB (even our MicroVAX I
was maxxed out). Or MicroVAX II had 9MB (and I think we had that one
on V5.4 for a while before moving to V5.5-1). I think our VAX 8200
was on V5.4 for product development (COMBOARD for VAXBI) and it had no
less than 8MB (the total amount varied by how many slots we had to
free up by removing 2MB boards.
However the Qbus uVAX has a RD54[system] and
RD52[swap] on
separate MSCP controllers
for performance as thats where they bottlenecked when heavy swapping.
That sounds like fun - we never had enough hardware to pull that off.
All my uVAXen have run from V4.4 [MicroVaxII/GPX] or
later and my
nominal version is 5.4. Though I have a
RZ56 with V7.2 on it. All are physical hardware in the Qbus BA123
realm and M3100 series.
Cool. I've powered up the MicroVAX II in recent memory, and the VAX
8200 but I haven't fired up the 11/750 since the company folded.
Running anything before V3 is painful as it was a
build. Also V1 was
tied the 780 and that did PDP11 emulation
mode for a lot of stuff.
Like I said, I started with V3.x so I missed out on the "joy".
VMS changed a lot from 4.2 to 4.6, long file
names are one that comes to mind as well as
phase III and IV DECnet.
Yep. Lots of changes, most of them improvements.
That was a long time ago.
It sure was.
-ethan
30 Apr
30 Apr
2:25 a.m.
On 29 Apr 2019, at 21:47, allison via cctech
<cctech at classiccmp.org> wrote:
You are limited to what the VAX-11/780
system had for peripherals and
typically under 8MB ram (it maxed at 16mb).
I know later 780s (probably with an upgraded memory controller) supported 64MB of memory.
I have used VMS 1.6 and started managing VMS systems around the 2.4 timeframe.
I haven?t looked but does the simh 11/780 also provide PDP-11 compatibility mode? You used
to run a very large amount of -11 code in VMS 1.x..
Huw Davies | e-mail: Huw.Davies at kerberos.davies.net.au
Melbourne | "If soccer was meant to be played in the
Australia | air, the sky would be painted green"
1 May
1 May
12:54 p.m.
On 30/04/2019 10:25, Huw Davies via cctalk wrote:
I know later 780s (probably with an upgraded memory
controller) supported 64MB of memory.
I have used VMS 1.6 and started managing VMS systems around the 2.4 timeframe.
I haven?t looked but does the simh 11/780 also provide PDP-11 compatibility mode? You
used to run a very large amount of -11 code in VMS 1.x..
I may have missed some of the thread, so this might be old news ...
The VAX-11/780 was followed by the VAX-11/750 and that needed (iirc) VMS
V2.0.
The VAX-11/730 was next and that needed VMS V3.0.
Then (I think) came the VAX 8600 and that needed VMS V4.0. That (I
think, but I can't find anything to support this right now ...) is when
the last of the PDP-11 compatibility code was finally removed.
So I think that to use anything pre-V4.0 you need compatibility mode
support in SIMH. But that seems to be there.
I've not used anything older than V3.x ... I remember command line
recall arriving, so I expect that happened in V4.0.
I would expect V1.x to feel distinctly clunky in comparison ... to V4.x
and later.
Still a fun exercise though I would think.
Antonio
--
Antonio Carlini
antonio at acarlini.com
2:47 p.m.
On Wed, May 1, 2019 at 1:54 PM Antonio Carlini via cctalk <
cctalk at classiccmp.org> wrote:
Then (I think) came the VAX 8600 and that needed VMS
V4.0. That (I
think, but I can't find anything to support this right now ...) is when
the last of the PDP-11 compatibility code was finally removed.
The VAX 8600 and 8650 were the last VAX models to have PDP-11 compatibility
mode, so if the purpose of VMS 4.0 was to support the 8600, I would expect
it to still contain compatibility mode support. VMS versions at least as
late as 5.2 still supported the 8600. I don't have firsthand experience, as
the only 8600 I used ran BSD.
3:20 p.m.
On 2 May 2019, at 07:47, Eric Smith via cctalk
<cctalk at classiccmp.org> wrote:
The VAX 8600 and 8650 were the last VAX models to have PDP-11 compatibility
mode, so if the purpose of VMS 4.0 was to support the 8600, I would expect
it to still contain compatibility mode support. VMS versions at least as
late as 5.2 still supported the 8600. I don't have firsthand experience, as
the only 8600 I used ran BSD.
I seem to recall that there was a software implementation of compatibility mode to allow
PDP-11 code to be run on VAX hardware that didn?t have it natively.
At one stage I used to manage a very eclectic mix of VAX systems, including 11-780,
11-785, 8650, 8700, 8800, 8820, 8840, 6300, 6600, 7740.
Huw Davies | e-mail: Huw.Davies at kerberos.davies.net.au
Melbourne | "If soccer was meant to be played in the
Australia | air, the sky would be painted green"
3:30 p.m.
On Wed, May 1, 2019 at 2:54 PM Antonio Carlini via cctalk
<cctalk at classiccmp.org> wrote:
I may have missed some of the thread, so this might be
old news ...
We've tossed around the facts from the edges but didn't list them one by one.
So I think that to use anything pre-V4.0 you need
compatibility mode
support in SIMH. But that seems to be there.
I think that's true. MicroVMS 4.0 runs on MicroVAXen, which don't
happen to have compatibility mode, so I think it's safe to say that it
was all worked out by then. I'm pretty sure there was still some
PDP-11 code in the corners of late v3.x.
I would expect V1.x to feel distinctly clunky in
comparison ... to V4.x
and later.
I would agree (I got started with V3.4 or so, so anything V2.0 or
older is going to feel strange to me, I'm sure).
Still a fun exercise though I would think.
No doubt. Definitely a learning experience.
I was just a user for V3.x, then became a System Manager with V4.x
(late 1985 or early 1986), then started doing device drivers in 1988
with the push to add SMP under V5.0, at first driver upgrades, then
later, drivers from scratch. How many times a day can you crash a
VAX? Lots.
-ethan
4:42 p.m.
On May 1, 2019, at 3:54 PM, Antonio Carlini via cctalk
<cctalk at classiccmp.org> wrote:
...
I would expect V1.x to feel distinctly clunky in comparison ... to V4.x and later.
Still a fun exercise though I would think.
I would think so. I was an occasional VMS user at DEC, and I somehow got myself a spot on
an OS Internals course for VMS 1.5. I wasn't in or near VMS at the time, I don't
remember how that came to be. It was interesting to learn how to add a syscall to the
OS.
9.3 names back then, I'm pretty sure. File system still in an ACP (separate process)?
DECnet Phase II ???
paul
7:58 p.m.
On Wed, May 1, 2019 at 7:42 PM Paul Koning via cctalk
<cctalk at classiccmp.org> wrote:
I think those were still true for V3.X. I know we had a problem back
then with our backups where someone elevated the priority of the Tape
ACP over the Disk ACP (because it was faster) that left us with months
of corrupt backups.
-ethan
On May 1,
2019, at 3:54 PM, Antonio Carlini via cctalk <cctalk at classiccmp.org> wrote:
I would expect V1.x to feel distinctly clunky in comparison ... to V4.x and later.
Still a fun exercise though I would think.
I would think so. I was an occasional VMS user at DEC, and I somehow got myself a spot
on an OS Internals course for VMS 1.5. I wasn't in or near VMS at the time, I
don't remember how that came to be. It was interesting to learn how to add a syscall
to the OS.
9.3 names back then, I'm pretty sure. File system still in an ACP (separate
process)? DECnet Phase II ???
2 May
2 May
6:13 a.m.
On May 1, 2019, at 10:58 PM, Ethan Dicks
<ethan.dicks at gmail.com> wrote:
On Wed, May 1, 2019 at 7:42 PM Paul Koning via cctalk
<cctalk at classiccmp.org> wrote:
Wow, that reflects very badly on the engineering involved. Setting priorities wrong might
cause things not to get done, or to take too long, but it cannot ever be an excuse for
data corruption.
paul
...
9.3 names back then, I'm pretty sure. File system still in an ACP (separate
process)? DECnet Phase II ???
I think those were still true for V3.X. I know we had a problem back
then with our backups where someone elevated the priority of the Tape
ACP over the Disk ACP (because it was faster) that left us with months
of corrupt backups.
-ethan
7:49 a.m.
On Thu, May 2, 2019 at 8:13 AM Paul Koning <paulkoning at comcast.net> wrote:
Thinking back 35 years... it was that someone enabled the backup
operator account with SETPRI, allowing the operator to elevate the
priority of the script. What I think was happening was that the
script was grabbing buffers from the disk before they were filled and
slamming them out to tape. It definitely cut minutes off the backup
time, which is why it happened.
I'm sure the VMS wizards hadn't expected a user process to run at
priority 31 (IIRC) because anyone with SETPRI _surely_ had the wisdom
not to elevate above system processes.
Definitely a failure to think of ways users could abuse the system.
-ethan
On May 1,
2019, at 10:58 PM, Ethan Dicks <ethan.dicks at gmail.com> wrote:
I think those were still true for V3.X. I know we had a problem back
then with our backups where someone elevated the priority of the Tape
ACP over the Disk ACP (because it was faster) that left us with months
of corrupt backups.
Wow, that reflects very badly on the engineering involved. Setting priorities wrong
might cause things not to get done, or to take too long, but it cannot ever be an excuse
for data corruption.
9:40 a.m.
On May 2, 2019, at 10:49 AM, Ethan Dicks
<ethan.dicks at gmail.com> wrote:
On Thu, May 2, 2019 at 8:13 AM Paul Koning <paulkoning at comcast.net> wrote:
Thinking back 35 years... it was that someone enabled the backup
operator account with SETPRI, allowing the operator to elevate the
priority of the script. What I think was happening was that the
script was grabbing buffers from the disk before they were filled and
slamming them out to tape. It definitely cut minutes off the backup
time, which is why it happened.
I'm sure the VMS wizards hadn't expected a user process to run at
priority 31 (IIRC) because anyone with SETPRI _surely_ had the wisdom
not to elevate above system processes.
Definitely a failure to think of ways users could abuse the system.
-ethan
More in particular, it is a design failure, relying on timing hacks rather than explicitly
and correctly passing ownership of data from producer to consumer.
paul
On May 1,
2019, at 10:58 PM, Ethan Dicks <ethan.dicks at gmail.com> wrote:
I think those were still true for V3.X. I know we had a problem back
then with our backups where someone elevated the priority of the Tape
ACP over the Disk ACP (because it was faster) that left us with months
of corrupt backups.
Wow, that reflects very badly on the engineering involved. Setting priorities wrong
might cause things not to get done, or to take too long, but it cannot ever be an excuse
for data corruption. 
8 May
8 May
7:47 p.m.
I'm just guessing here but I would suspect this had more to do with the
hardware capabilities of the tape system.
Not all tape drives could just pause to wait for more data then resume. If
the data wasn't being steamed fast enough the tape would have to resync
somehow which could even require rewinding and it's possible that was
either unsupported or just unreliable
On Thu., May 2, 2019, 12:41 p.m. Paul Koning via cctalk, <
cctalk at classiccmp.org> wrote:
On May 2, 2019, at 10:49 AM, Ethan Dicks
<ethan.dicks at gmail.com> wrote:
On Thu, May 2, 2019 at 8:13 AM Paul Koning <paulkoning at comcast.net>
wrote:
>> On May 1, 2019, at 10:58 PM, Ethan Dicks
<ethan.dicks at gmail.com>
wrote:
>> I think those were still true for V3.X.
I know we had a problem back
>> then with our backups where someone elevated the priority of the Tape
>> ACP over the Disk ACP (because it was faster) that left us with months
>> of corrupt backups.
>
> Wow, that reflects very badly on the engineering involved. Setting
priorities
wrong might cause things not to get done, or to take too long,
but it cannot ever be an excuse for data corruption.
Thinking back 35 years... it was that someone enabled the backup
operator account with SETPRI, allowing the operator to elevate the
priority of the script. What I think was happening was that the
script was grabbing buffers from the disk before they were filled and
slamming them out to tape. It definitely cut minutes off the backup
time, which is why it happened.
I'm sure the VMS wizards hadn't expected a user process to run at
priority 31 (IIRC) because anyone with SETPRI _surely_ had the wisdom
not to elevate above system processes.
Definitely a failure to think of ways users could abuse the system.
-ethan
More in particular, it is a design failure, relying on timing hacks rather
than explicitly and correctly passing ownership of data from producer to
consumer.
paul
2054
days inactive
2064
days old
18 comments
10 participants
participants (10)
-
a.carlini＠ntlworld.com -
allisonportable＠gmail.com -
bill.gunshannon＠hotmail.com -
cctalk＠gtaylor.tnetconsulting.net -
elson＠pico-systems.com -
ethan.dicks＠gmail.com -
huw.davies＠kerberos.davies.net.au -
paulkoning＠comcast.net -
spacewar＠gmail.com -
stark＠mit.edu