Most impressive VAX installations
urbancamo
I was flicking through the VAX Architecture Reference Manual earlier
and it got me wondering about the ratio between physically installed
memory in a VAX setup and the maximum theoretical limit of 4 GB. As
far as I'm aware for VAXen the physical never to close to the virtual.
I remember when 64MB was an astronomic amount of memory, which was
around the time of the last VAXes, so I'm asking - how much RAM did
you see crammed into the latest or greatest of the VAXen (and what
else was interesting about the setups, for example maximum number of
users, storage etc)
Or just tell me to get a life ;)
Mark.
urbancamo
Richard B. Gilbert
I don't know of ANY VAX that actually supported four GB of memory. I
don't recall the largest VAX memory I ever encountered but I doubt if it
was more than 128 MB.
RISC processors, such as the Alpha need a great deal more memory for the
executable code, about four times as much as a VAX. With the Alphas, a
GB or more was not only reasonable but also possible! But only if you
were very rich! ;-)
Arne Vajhøj
FrankS
wrote:
> I don't know of ANY VAX that actually supported four GB of memory. I
> don't recall the largest VAX memory I ever encountered but I doubt if it
> was more than 128 MB.
I have a client with VAX 6000 series that contain 1.25gb of memory. I
was at the Sungard facility in PA this past week and they have a VAX
7630s with over 2gb+ installed. The spec for the VAX 7000 says 3.5gb
maximum.
Tom Linden
Just curious why they continue running theses as opposed to, say, ES47?
--
PL/I for OpenVMS
www.kednos.com
Michael Moroney
for a bugfix where a byte field was being treated as a negative number
if it exceeded 127. That byte field was the number of nodes in a cluster,
and it was found by a customer (I think I know who), not internal testing.
Also the test followed a decrement of that field, meaning a node left the
cluster, so the bug wouldn't have been seen unless there were 129 or
more nodes in the cluster at some point. (Supported limit was/is 96)
VAXman-
Perhaps because an ES47 is an Alpha and not a VAX?
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM
... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)
Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
Richard B. Gilbert
With what Sungard charges, I suppose they can afford it! Was that the
Philly office? Been there, awesome collection of hardware!!
Richard B. Gilbert
In the case of Sungard, it's necessary in order to support their
clients. Sungard offers a disaster recovery site for companies that
need such. If you have a contract with them and something horrible
happens to your data center, you let them know, grab your backup tapes,
go there, and restore your backups on their hardware. It ain't cheap
but it does keep you up and running when lightning zaps your substation
or or a 747 tries to land on your roof.
They have an awesome collection of hardware over there! It's probably
both bigger and faster than what you have because they have to support
the largest customer with a contract at that site. They have a UPS that
has to be seen to be believed. There are diesel generators in the back
yard that they can fire up before the batteries run down.
JF Mezei
I ran an all mighty Microvax 2 with 8 megs of RAM and a 154meg drive to
support 8 users runing WPS-Plus. The success of the project lead the
MVII to be upgraded to 16 meg of RAM to support 12 users.
This was circa 1987.
Arne Vajhøj
And today a single word processing user is using a PC
with 4 MB L2 cache, 2 GB RAM and 320 GB disk ...
HW has changed !
Arne
Richard B. Gilbert
It has gotten a lot cheaper!
When someone builds a faster computer, someone else will write slower
software to run on it!
rd...@spamcop.net
Impressive, but look back and read what OS/8 was able to do!
Michael Unger
> And today a single word processing user is using a PC
> with 4 MB L2 cache, 2 GB RAM and 320 GB disk ...
>
> [...]
Don't forget the 256 MB of RAM for the graphics card ... ;-)
Michael
--
Real names enhance the probability of getting real answers.
My e-mail account at DECUS Munich is no longer valid.
Steven Underwood
System Memory Resources on 1-NOV-2008 18:17:01.31
Physical Memory Usage (pages): Total Free In Use Modified
Main Memory (2048.00Mb) 4194304 3855692 275650 62962
H Vlems
>
> - Tekst uit oorspronkelijk bericht weergeven -
One of my VAXstation 4000-90A's has 128 MB main memory. Which is its
configuration maximum IIRC.
Hans
Michael Kraemer
> One of my VAXstation 4000-90A's has 128 MB main memory. Which is its
> configuration maximum IIRC.
Mine too. And yes, it maxes out at 128MB. But that was
an impressive (and expensive) amount of memory back then.
Dennis Boone
> I remember when 64MB was an astronomic amount of memory, which was
> around the time of the last VAXes, so I'm asking - how much RAM did
> you see crammed into the latest or greatest of the VAXen (and what
> else was interesting about the setups, for example maximum number of
> users, storage etc)
Astronomical is relative to era, class of system and personal
perception. I'm pretty sure the 780 I worked on in the '83 time frame
had 64 MB of RAM, and supported (more or less :) 60+ simultaneous
logged in users all madly editing and compiling. That was a long way
from the end of the VAX era, and quite a ways from astronomical for such
a system.
De
FrankS
> Just curious why they continue running theses as opposed to, say, ES47?
Many years of poor decisions.
FrankS
wrote:
> Was that the
> Philly office? Been there, awesome collection of hardware!!
Yes, the Philadelphia office.
H Vlems
That is absolutely true Michael, When hardware prices wouldn't have
come down as they have then we'd all be running SIMH....
Tom Linden
> In article <op.ujxxc...@murphus.hsd1.ca.comcast.net>, "Tom Linden"
> <t...@kednos.company> writes:
>> On Sat, 01 Nov 2008 05:00:33 -0700, FrankS <sapi...@noesys.com> wrote:
>>
>>> On Oct 31, 9:15 pm, "Richard B. Gilbert" <rgilber...@comcast.net>
>>> wrote:
>>>> I don't know of ANY VAX that actually supported four GB of memory. I
>>>> don't recall the largest VAX memory I ever encountered but I doubt if
>>>> it
>>>> was more than 128 MB.
>>>
>>> I have a client with VAX 6000 series that contain 1.25gb of memory. I
>>> was at the Sungard facility in PA this past week and they have a VAX
>>> 7630s with over 2gb+ installed. The spec for the VAX 7000 says 3.5gb
>>> maximum.
>>
>> Just curious why they continue running theses as opposed to, say, ES47?
>
>
> Perhaps because an ES47 is an Alpha and not a VAX?
Well, I thinkl you know what I meant, i.e., what specifically was missing
precluding a port. For example one space mission that I am familiar with
written in PL/I requires H-Float.
VAXman-
BINGO! There still are sites that have not bothered to port their apps to
Alpha or Itanium. If H-float is needed, I'd wager that a library could be
developed to provide it and, on faster hardware, it may even best perform-
ance on VAX.
VAXman-
Isn't Billzebub's bloatware just wonderful?
Micro$oft...
... keeping Moore's Law in check by several factors for over 20 years!
Michael Kraemer
Found a historical quote (as of 1990):
2x4MB for a VS3176 for close to 3000 DEM (approx $1500 back then).
And that's already the cheaper OEM price, not the original DEC one.
I think VS4000 memory wasn't that much cheaper.
John Reagan
$ write sys$output f$getsyi("hw_name")
VAX 7000-820
$ show memory/physical
System Memory Resources on 2-NOV-2008 14:20:19.63
Physical Memory Usage (pages): Total Free In Use Modified
Main Memory (2304.00Mb) 4718592 4374674 337265 6653
Of the physical pages in use, 294903 pages are permanently allocated to
OpenVMS.
John
Arne Vajhøj
> In article <490ca76d$0$90264$1472...@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= <ar...@vajhoej.dk> writes:
>> JF Mezei wrote:
>>> At the opposite scale of things...
>>>
>>> I ran an all mighty Microvax 2 with 8 megs of RAM and a 154meg drive to
>>> support 8 users runing WPS-Plus. The success of the project lead the
>>> MVII to be upgraded to 16 meg of RAM to support 12 users.
>>>
>>> This was circa 1987.
>> And today a single word processing user is using a PC
>> with 4 MB L2 cache, 2 GB RAM and 320 GB disk ...
>
> Isn't Billzebub's bloatware just wonderful?
>
> Micro$oft...
> ... keeping Moore's Law in check by several factors for over 20 years!
It is not just MS. IBM, Oracle, SUN, SAP, Borland etc. all let
HW requirements follow current hardware.
Arne
Arne Vajhøj
Considering that the VAX'es most likely emulate H-floating then
absolutely.
If I remember correctly then only VAX 7xx, 8xxx and 9xxx implemented
H-floating in HW.
And I would expect the VAX'es still running to be 6xxx, 7xxx, 4xxx
and 3xxx.
Arne
Richard B. Gilbert
DEC could not, or would not, sell anything cheaply! That's one of the
many reasons DEC is no more; their competitors could and did sell things
cheaper than DEC did.
Richard B. Gilbert
Funny! I do word processing on a PC with ONLY 1 GB of RAM and only 40
GB of disk! I don't recall how much "Level X" cache it has; If anyone
cares, it's an HP DC5750 with W/XP SP2.
I can do the same sorts of things on a Sun Ultra 10 Creator-3D
workstation with as little as 128 MB of RAM. More RAM gives better
performance of course.
I still use my PC because I'm more familiar with Word than with "Star
Office" and the help function is more helpful.
Richard B. Gilbert
Arne,
Did you drop an "x" up there? VAX 7xx???? I hope you meant 7000
because the 700 series VAXen did not have H-floating point!
ed696
We used to run 4gb ram with max cpus in ayo mnfg to "burn-in" both
cpus and mem modules before shipping , gave us the opportunity to try
out interleave configs and let us run some custom memory pattern
testing under Sitp
johnwa...@yahoo.co.uk
wrote:
It's not strictly true to say that DEC could not or would not sell
anything cheaply. Their early stuff was presumably a bargain judging
by the way it sold, as were VAXes in their heyday. Low end alphas
towards their end of life weren't priced that badly in hardware terms,
and if anyone had wanted to build "clone" motherboards at interesting
prices the technology and support was there for them to do it.
But the marketing wasn't there, and nor (courtesy of MS) were the
apps. The AlphaPowered program had a go but in general it was too
little too late.
Those in HQ had for too long ignored the "you gotta eat your own lunch
before someone else eats it for you" (?) rule; there was too much
emphasis from HQ on "upselling" and not enough on retaining (let alone
growing) market share by being competitively priced feature for
feature.
Yes there were lots of competitors that could and did sell "stuff"
cheaper than DEC did, but it often wasn't, and often still isn't,
really comparable "stuff", especially in sectors where VMS was/is
relevant.
Unfortunately Palmer and others post-Olsen "bought the WNT Kool-
Aid" (?) from MS, and as is typical with MS, "business partner" =
"organ donor" (eg just ask the companies who bought into PowerPC and
MIPS NT-box vision). Hence, as Kerry just mentioned, no proper non-
debug versions of NT/Alpha software, to name but one example.
By the time people outside HQ realised that WNT wasn't (and was never
really going to be) VMS++, and that OSF/1/Tru64 was going nowhere fast
vs Solaris and AIX despite being technically very competent indeed,
the corporate damage had been done. Then the remaining DEC hardware
and software crown jewels were given to Intel in the ten year
agreement which was part of the DEC/Intel patent dispute settlement,
and we know where that led to.
My 2p. Ymmv.
Arne Vajhøj
> because the 700 series VAXen did not have H-floating point!
I thought the 700 series did have H-floating.
I just checked some numbers - it seems as if you are correct - only the
785 has H-floating in HW.
Arne
Michael Kraemer
>
> It's not strictly true to say that DEC could not or would not sell
> anything cheaply. Their early stuff was presumably a bargain judging
> by the way it sold, as were VAXes in their heyday. Low end alphas
> towards their end of life weren't priced that badly in hardware terms,
> and if anyone had wanted to build "clone" motherboards at interesting
> prices the technology and support was there for them to do it.
>
> But the marketing wasn't there, and nor (courtesy of MS) were the
> apps. The AlphaPowered program had a go but in general it was too
> little too late.
Until the alpha systems arrived,
DEC left a price/performance gap open for about 3 years,
from 1990 to early 1993,
not counting the detour to the Mips based systems.
Richard B. Gilbert
I'm thinking of the Rainbow that I bought second hand for $900 or so.
New, when they first hit the streets, they were about $5,000.00. IBM
clones were less than half that. DEC wanted about $700.00 US for 256 KB
of memory. I bought third party memory for $30! It worked perfectly!
This was the same box that supposedly could not format its own floppy
disks; something every other PC, PC clone, and McIntosh could do with
ease! DEC sold formatted floppies for $5 US each. I bought mine for
$0.50 each and formatted them using third party software. The 20MB hard
disk was $2200.00 US. I bought brand X (Seagate) for $300 and it worked
perfectly. I could go on for hours but I hope you get the idea; DEC's
prices were nothing sort of highway robbery!
Then there was the Micro 11/23 that my boss bought for huge bucks. We
bought a hard disk and interface from Emulex because DEC wanted four or
five times what Emulex did. Was the Emulex product just as good?
There's no way to tell, now, twenty years later. It did work and worked
for a couple of years until the boss could afford a VAX 8200.
At one DECUS symposium I attended, a speaker got a huge laugh by saying;
"I got a phone call from a terrorist last week; of course HE thinks he's
a DEC salesman!"
andy/christine
> To anyone listening!
>
> I was flicking through the VAX Architecture Reference Manual earlier
> and it got me wondering about the ratio between physically installed
> memory in a VAX setup and the maximum theoretical limit of 4 GB. As
> far as I'm aware for VAXen the physical never to close to the virtual.
>
> around the time of the last VAXes, so I'm asking - how much RAM did
> you see crammed into the latest or greatest of the VAXen (and what
> else was interesting about the setups, for example maximum number of
> users, storage etc)
>
>
> Mark.
The biggest VAXcluster I had anything to do with, had the VAX8500
and HSC50 on the fifteenth floor, four STARcoupler cables run down
the cable riser to the ninth floor, the STARcoupler in the cloak
cupboard next door to the riser (with a sign asking the wet stuff
NOT be hung above it) and two STARcoupler cables going down to
the computer room on the first floor where the VAX8800 sat.
(The 8820 was the same beast except it had a MicroVAX II console.)
Fourteen floors high, it was big! :-)
We had a VT220 on the fifteenth floor connected via 4 wire modem
as the secondary console to the VAX8800s PRO380.
It could do everything but power on/off.
The problems why it was so far spread were political mainly.
(And floor loading). I was the person to suggest running
the cables, as a joke. To my surprise, they built it!
(but guess which idiot ran it :-).
Andy Stewart.
Neil Rieck
wrote:
> urbancamo wrote:
> > To anyone listening!
>
> > I was flicking through the VAX Architecture Reference Manual earlier
> > and it got me wondering about the ratio between physically installed
> > memory in a VAX setup and the maximum theoretical limit of 4 GB. As
> > far as I'm aware for VAXen the physical never to close to the virtual.
>
> > I remember when 64MB was an astronomic amount of memory, which was
> > around the time of the last VAXes, so I'm asking - how much RAM did
> > you see crammed into the latest or greatest of the VAXen (and what
> > else was interesting about the setups, for example maximum number of
> > users, storage etc)
>
> > Or just tell me to get a life ;)
>
> > Mark.
>
> don't recall the largest VAX memory I ever encountered but I doubt if it
> was more than 128 MB.
>
> executable code, about four times as much as a VAX. With the Alphas, a
> GB or more was not only reasonable but also possible! But only if you
>
> - Show quoted text -
We are currently running 3 GB of memory in our AS-DS20e. IIRC, each
gig was $700 which seemed reasonable at the time. One unexpected
surprise is that most of our RMS database is cached in memory.
Neil Rieck
Kitchener/Waterloo/Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/
johnwa...@yahoo.co.uk
wrote:
Yeah, some of the prices were ridiculous (though DEC commodity memory
eventually arrived vaguely in the land of sanity), but it's still
helpful to compare like with like. Rainbow with PC clone isn't quite
like with like.
Rainbows came out at a time when it wasn't obvious whether CPM or
MSDOS was the way forward, and when CPM had a relatively reasonable
installed base. Rainbows had a Z80 for CPM and an x86 (well, 8088) for
MSDOS. Flexibility? Investment protection?
Iirc, PC clones only did MSDOS and not CPM (no Linux back then, though
there would soon be Venix/x86 as well as Venix/11 etc). And thus began
the never-ending PC upgrade-and-discard cycles we all know (and which
some folks love).
Bob Koehler
> To anyone listening!
>
> I was flicking through the VAX Architecture Reference Manual earlier
> and it got me wondering about the ratio between physically installed
> memory in a VAX setup and the maximum theoretical limit of 4 GB. As
> far as I'm aware for VAXen the physical never to close to the virtual.
Since the 11/780 had a 30 bit backplane and following systems were
20 bit or smaller, most VAXen can't handle more than 30 bits worth
of RAM.
But eventually the hardware architecture was extended to 32 bits and
systems were qualified with a 4GB of RAM. I don't recall which
models.
Richard B. Gilbert
RAM is a LOT cheaper these days! In the days I was writing about, RAM
was anything but cheap; especially if you bought it from DEC.
Bob Koehler
> At the opposite scale of things...
>
> I ran an all mighty Microvax 2 with 8 megs of RAM and a 154meg drive to
> support 8 users runing WPS-Plus. The success of the project lead the
> MVII to be upgraded to 16 meg of RAM to support 12 users.
>
> This was circa 1987.
One of our earliest 11/780 had 1MB of RAM, because that was the smallest
DEC would sell at the time. I'm not sure if my first 11/780 had 1 or
only 1/2 MB, but whatever was the minimum for VAX-11/VMS 1.x is what it
had.
Anyone have the SPD for 1.x in 1978?
Bob Koehler
>
> BINGO! There still are sites that have not bothered to port their apps to
> Alpha or Itanium. If H-float is needed, I'd wager that a library could be
> developed to provide it and, on faster hardware, it may even best perform-
> ance on VAX.
Did any Alpha ever actually implement X-float? It was in my early
Alpha architecture books, fully desribed, but documented as not
implemented.
Does Itanium do X-float?
There were calculations we did on our almighty MV II that were
trivial to code up because the Fortran compiler fully supported
H-float.
Bob Koehler
>
> If I remember correctly then only VAX 7xx, 8xxx and 9xxx implemented
> H-floating in HW.
VAX 11/780 implemented H-float (and G-float) only in optional
microcode. I once had 300,000 lines of code compiled with G float
and trapping to the emulator just to get some result comparisons
with D-float (which was in the FP780).
Bob Koehler
>
> Funny! I do word processing on a PC with ONLY 1 GB of RAM and only 40
> GB of disk! I don't recall how much "Level X" cache it has; If anyone
> cares, it's an HP DC5750 with W/XP SP2.
And I recall getting a Mac with a 603e chip. The 603e was designed
for laptops but had a major performance problem. So it only shipped
On desktops where the problem was solved with a big primary cache.
My system shipped with 8MB RAM and 4MB cache.
But it still ran faster than the models my friends ordered with the
previous chip so they could avoid the 603e performance problem.
Bob Koehler
>
> Did you drop an "x" up there? VAX 7xx???? I hope you meant 7000
> because the 700 series VAXen did not have H-floating point!
The 11/780 did, as an option. You had to buy both an optional user
writeable control store, and the optional microcode to be loaded into
it. I remember doing testing on my second 11/780 to see if it was
worth it.
IIRC, the 11/782 and 11/785 had the same options. I think the 11/750
shipped with the H- and G-float microcode, but I don't recall how
it was handled on the 11/730 and 11/725.
Bob Koehler
>
> DEC could not, or would not, sell anything cheaply! That's one of the
> many reasons DEC is no more; their competitors could and did sell things
> cheaper than DEC did.
Yeah, right. Just go back the the 1960s and 1970s and compare prices
between any DEC PDP-x and IBM 360 series.
IBM was not into competing with DEC desktop PDP-8. Granted, the
PDP-8 took the whole desktop.
Bob Koehler
>
> Since the 11/780 had a 30 bit backplane and following systems were
> 20 bit or smaller, most VAXen can't handle more than 30 bits worth
> of RAM.
Typo. That should read "30 bit or smaller".
rd...@spamcop.net
> Rainbows came out at a time when it wasn't obvious whether CPM or
> MSDOS was the way forward, and when CPM had a relatively reasonable
> installed base. Rainbows had a Z80 for CPM and an x86 (well, 8088) for
> MSDOS. Flexibility? Investment protection?
>
> Iirc, PC clones only did MSDOS and not CPM (no Linux back then, though
> there would soon be Venix/x86 as well as Venix/11 etc). And thus began
> the never-ending PC upgrade-and-discard cycles we all know (and which
> some folks love).
PCs and PC clones could (and did) run CP/M-86. So, I guess, could the
Rainbow. But the Z80 ran CP/M (the 8 bit version), so that was really as
a migration path rather than an alternative. A transparent one, too.
If CP/M-86 had taken off, it would have 'just run'.
At a time when many people bypassed DOS and used BIOS calls (as they had
to on the PC), the incompatible BIOS of the Rainbow was a major
drawback. Of course, the hardware was *completely* different!
John Reagan
"Bob Koehler" <koe...@eisner.nospam.encompasserve.org> wrote in message
> Did any Alpha ever actually implement X-float? It was in my early
> Alpha architecture books, fully desribed, but documented as not
> implemented.
The Alpha books describe the format of X-floating. There was never any
intention of adding instructions to manipulate them that I can remember.
They are completely implemented in software (mostly written in Macro-64).
>
> Does Itanium do X-float?
Also in software (Macro-64 parts reimplemented in Itanium assembly).
John
Richard B. Gilbert
My first VAX was an 11/750. I do not recall it having H-floating point.
IIRC it had 32 bit and 64 bit floating point data types and
instructions. I was just massively relieved not to have to deal with
sixteen or eighteen bit address spaces any longer and didn't get really
excited about the floating point since nothing we were doing really
needed more than 32 bits.
Richard B. Gilbert
My VAX experience dates from early 1984! Before that, my DEC experience
was limited to having seen and touched a PDP-8. I didn't administer or
program the PDP-8.
By 1984 DEC was charging top dollar for just about everything. Even
with a 50% educational discount, their prices were out of sight!
Somehow I don't think that the PDP-8 was comparable, in any way, to the
IBM System/360! They were both digital computers and there the
resemblance ended.
Ed Wilts
responsibility for. 6 VAXes, over 3,300 simultaneous users running
All-in-1, RDB, and a bunch of over stuff. We even had a screaming
solid state disk - 20MB if I remember correctly (mirrored, of course,
talking a full rack). We pulled out multiple pallets of SDI cables
when we migrated from HSC to HSJ-40 controllers.
We had fun stuff like dealing with maximum process count - I remember
we maxed it out and DEC had to update VMS to allow a bigger number. I
think it was 1024 that we maxed out on.
I haven't seen this cluster in nearly 11 years so I don't know what it
looks like today, but I do know the cluster is still there -0 I don't
know if any Vaxes are there or if they've migrated everything to
Alpha. The admin positions are about to be outsourced to HP (EDS) -
the existing staff have been offered jobs with EDS.
.../Ed
Tybalt> write sys$output f$getsyi("cluster_ftime")
30-MAY-1999 07:28:07.05
JF Mezei
> There were calculations we did on our almighty MV II that were
> trivial to code up because the Fortran compiler fully supported
> H-float.
Out of curiosity, what sort of calculations could H-float do that IEEE
floating point can't do ?
JF Mezei
> Yeah, right. Just go back the the 1960s and 1970s and compare prices
> between any DEC PDP-x and IBM 360 series.
And therein lies Digital's fatal problem. And it should have known.
DEC grew because it was the new kid on the block with lower prices and
which IBM didn't take seriously. IBM would still charge an arm and a
leg, arguing its software was more sophisticated and for serious
applications. DEC was able to capture a huge new market with its lower
prices, relegating IBM to large businesses only.
In the 1980s, the "PC" and Sun grew in the exact same way: they came in,
offered lower prices, and DEC dismissed them as not serious enough for
real business and DEC continued to charge a premium for its product.
DEC's market shrunk to a handful of customers who still had to buy the
overpriced DEC gear and software.
Richard B. Gilbert
There is frequently a great reluctance to change something that works.
If it ain't broke, don't fix it!
Suddenly it's 2001 and you've got 1980's technology! Can't compete any
longer? Too bad!!
Those folks in California are selling workstations for a quarter of what
we charge? They can't be any good. . . .
Right! Goodbye DEC, hello Sun Microsystems. And Silicon Graphics, and
. . . .
Bob Koehler
>
> Somehow I don't think that the PDP-8 was comparable, in any way, to the
> IBM System/360! They were both digital computers and there the
> resemblance ended.
There were some very small, very low capability, models in the 360
series. Systems like the 360/20 were mostly used to do things like
duplicate card decks. Most folks remember systems like the 360/75,
a multi-user mainframe about the size of a small house and priced a
few orders of magnitude higher. The 360/20 I saw would use just a
little more floor space than a basic 11/780 with one expansion
cabinet.
Bob Koehler
H-float is a VAX specific format with about the same number of bits,
but slightly different definition, as IEEE X-float. H-float has
twice as many bits as VAX D-float or G-float. X-float has twice as
many bits as IEEE T-float.
In C speak, float would be done in VAX F-float or IEEE S-float, or
similar. double would be done in VAX D- or G-float, or IEEE T-float.
I don't know of any C compiler that supports VAX H-float or IEEE
X-float.
In Fortran, REAL or REAL*4 would be F-float or S-float. DOUBLE
PRECISION or REAL*8 would be D-, G-, or T-float. REAL*16 would
be H- or X-float. I don't know of any Fortran compiler that
supports X-float.
The extra precision of H-float was usefull in an algorithm that
converted D-float floating point values to 48 bit fixed point.
Just keeping everything in D-float would drop low bits during the
algorithm, leading to an inaccurate result.
We were given the algorithm, coded for Fortran REAL*8 on another
system by someone who didn't realise its limitations. Changing
to REAL*16 was a trivial edit to solve the problem.
Bob Koehler
>
> In the 1980s, the "PC" and Sun grew in the exact same way: they came in,
> offered lower prices, and DEC dismissed them as not serious enough for
> real business and DEC continued to charge a premium for its product.
> DEC's market shrunk to a handful of customers who still had to buy the
> overpriced DEC gear and software.
In the 1980s DEC was trying to overtake IBM and never looked back at
the new kids on the block.
Richard B. Gilbert
I remember the 360/20. Princeton University used them as Remote Job
Entry (RJE) terminals. You read in your deck of punched cards, waited
while the 360/91 in the computer center crunched your numbers, and when
it was done your printout and maybe freshly punched cards came back.
If you wanted it to do something difficult you had to be prepared to
wait a LONG time! ISTR that the 360/20 used half bytes (4 bits) for
some things; they were christened "nybbles".
The 360/20 was the closest thing in the 360 line to the PDP-8.
Physically it was bigger than a PDP-8. I couldn't say if it was any
faster or smarter.
They made great RJE terminals. It's hard to imagine them doing anything
else!
Arne Vajhøj
> In article <00A82051...@SendSpamHere.ORG>, VAXman- @SendSpamHere.ORG writes:
>> BINGO! There still are sites that have not bothered to port their apps to
>> Alpha or Itanium. If H-float is needed, I'd wager that a library could be
>> developed to provide it and, on faster hardware, it may even best perform-
>> ance on VAX.
>
> Did any Alpha ever actually implement X-float? It was in my early
> Alpha architecture books, fully desribed, but documented as not
> implemented.
AFAIK not in HW.
But VMS does emulate it.
> Does Itanium do X-float?
>
> There were calculations we did on our almighty MV II that were
> trivial to code up because the Fortran compiler fully supported
> H-float.
VMS Fortran still support REAL*16 !
Arne
Arne Vajhøj
None.
Because IEEE has X-float with the same precision.
But in some cases 128 bit floating point (H or X) can fix
numerical problems in 64 bit float (D/G/T).
Arne
Steven Underwood
news:490e...@news.mel.dft.com.au...
> We had a VT220 on the fifteenth floor connected via 4 wire modem
> as the secondary console to the VAX8800s PRO380.
> It could do everything but power on/off.
I assume you mean power off the Pro380 as I believe powering off the 8800
was done from the console (only worked on 1 8800 in my field service
experience).
Glen Herrmannsfeldt
(snip)
> In C speak, float would be done in VAX F-float or IEEE S-float, or
> similar. double would be done in VAX D- or G-float, or IEEE T-float.
> I don't know of any C compiler that supports VAX H-float or IEEE
> X-float.
The convention is that it would be (long double), though I don't
know which systems have compilers that implement it.
-- glen
Glen Herrmannsfeldt
(snip)
> The 11/780 did, as an option. You had to buy both an optional user
> writeable control store, and the optional microcode to be loaded into
> it. I remember doing testing on my second 11/780 to see if it was
> worth it.
I don't know this one at all.
> IIRC, the 11/782 and 11/785 had the same options. I think the 11/750
> shipped with the H- and G-float microcode, but I don't recall how
> it was handled on the 11/730 and 11/725.
Around then I worked in a place with three 11/750's and one 11/730.
It was well known that the 730 was faster for H-float, as it was
emulated on the 750. It might be, though, that the 750 had both
G-float and D-float microcode, if that was an option.
As I understood it at the time, it was standard on the 730.
-- glen
Dr Ivan D. Reid
wrote in <490ca76d$0$90264$1472...@news.sunsite.dk>:
> JF Mezei wrote:
>> At the opposite scale of things...
>> I ran an all mighty Microvax 2 with 8 megs of RAM and a 154meg drive to
>> support 8 users runing WPS-Plus. The success of the project lead the
>> MVII to be upgraded to 16 meg of RAM to support 12 users.
>> This was circa 1987.
> with 4 MB L2 cache, 2 GB RAM and 320 GB disk ...
> HW has changed !
Not everybody has a single-user PC, tho'.
[ireid:~] > top
top - 08:16:57 up 55 days, 13:54, 75 users, load average: 2.23, 0.95, 0.72
Tasks: 648 total, 1 running, 643 sleeping, 3 stopped, 1 zombie
Cpu0 : 1.7% us, 1.0% sy, 0.0% ni, 96.9% id, 0.0% wa, 0.0% hi, 0.3% si
Cpu1 : 0.0% us, 0.3% sy, 0.0% ni, 0.0% id, 99.7% wa, 0.0% hi, 0.0% si
Cpu2 : 0.0% us, 0.3% sy, 0.0% ni, 99.7% id, 0.0% wa, 0.0% hi, 0.0% si
Cpu3 : 0.0% us, 0.7% sy, 0.0% ni, 0.0% id, 95.6% wa, 0.3% hi, 3.4% si
Mem: 8162216k total, 7465120k used, 697096k free, 811288k buffers
Swap: 16771520k total, 136920k used, 16634600k free, 4377612k cached
...
[ireid:~] > cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Xeon(R) CPU 5160 @ 3.00GHz
stepping : 6
cpu MHz : 2992.598
cache size : 4096 KB
...
There'll be more users later in the day of course. I'm not sure
how many machines are actually in the lxplus cluster; at least four.
This is at CERN, natuerlich.
[ireid:~] > uname -a
Linux lxplus235.cern.ch 2.6.9-78.0.1.EL.cernsmp #1 SMP Tue Aug 5 11:01:13 CEST
2008 x86_64 x86_64 x86_64 GNU/Linux
--
Ivan Reid, School of Engineering & Design, _____________ CMS Collaboration,
Brunel University. Ivan.Reid@[brunel.ac.uk|cern.ch] Room 40-1-B12, CERN
KotPT -- "for stupidity above and beyond the call of duty".
John Reagan
> similar. double would be done in VAX D- or G-float, or IEEE T-float.
> I don't know of any C compiler that supports VAX H-float or IEEE
> X-float.
"long double" on OpenVMS Alpha or OpenVMS I64 should get you X-float. I
don't think the VAX compiler knows about H-float however.
>
> In Fortran, REAL or REAL*4 would be F-float or S-float. DOUBLE
> PRECISION or REAL*8 would be D-, G-, or T-float. REAL*16 would
> be H- or X-float. I don't know of any Fortran compiler that
> supports X-float.
REAL*16 on OpenVMS Alpha and OpenVMS I64 should get you X-float.
And for those of you keeping score at home, the QUADRUPLE datatype in Pascal
gives H-float on VAX, and X-float on Alpha and I64.
John
Bob Koehler
>
> "Bob Koehler" <koe...@eisner.nospam.encompasserve.org> wrote in message >
>> similar. double would be done in VAX D- or G-float, or IEEE T-float.
>> I don't know of any C compiler that supports VAX H-float or IEEE
>> X-float.
>
> don't think the VAX compiler knows about H-float however.
What about if I'm not compiling with IEEE on my Alpha. Will "long
double" get me H-float?
VAXman-
>In article <JL-dnRv2IPYFLo3U...@earthlink.com>, "John Reagan" <johnr...@earthlink.net> writes:
>>
>> "Bob Koehler" <koe...@eisner.nospam.encompasserve.org> wrote in message >
>>> similar. double would be done in VAX D- or G-float, or IEEE T-float.
>>> I don't know of any C compiler that supports VAX H-float or IEEE
>>> X-float.
>>
>> don't think the VAX compiler knows about H-float however.
>
> What about if I'm not compiling with IEEE on my Alpha. Will "long
> double" get me H-float?
If it does, it would be emulated in or provided by some library.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM
... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)
Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
Arne Vajhøj
DEC C 6.5 on Alpha has long double = X-float.
Arne
Arne Vajhøj
No. Always X on Alpha.
Arne
Arne Vajhøj
> In article <ZELneM...@eisner.encompasserve.org>, koe...@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>> In article <JL-dnRv2IPYFLo3U...@earthlink.com>, "John Reagan" <johnr...@earthlink.net> writes:
>>> "Bob Koehler" <koe...@eisner.nospam.encompasserve.org> wrote in message >
>>> In C speak, float would be done in VAX F-float or IEEE S-float, or
>>>> similar. double would be done in VAX D- or G-float, or IEEE T-float.
>>>> I don't know of any C compiler that supports VAX H-float or IEEE
>>>> X-float.
>>> "long double" on OpenVMS Alpha or OpenVMS I64 should get you X-float. I
>>> don't think the VAX compiler knows about H-float however.
>> What about if I'm not compiling with IEEE on my Alpha. Will "long
>> double" get me H-float?
>
> If it does, it would be emulated in or provided by some library.
It is X. But that is also emulated.
Arne
John Reagan
"Bob Koehler" <koe...@eisner.nospam.encompasserve.org> wrote in message
>
> What about if I'm not compiling with IEEE on my Alpha. Will "long
> double" get me H-float?
>
As Arne mentioned, you'll always get X. Other than binary compatibility
with VAX, H doesn't buy you anything that X doesn't provide.
On Alpha and I64, you can pick between
F/D/X
F/G/X
S/T/X
for real, double, long double, respectively. Only the defaults have changed
from Alpha to I64 [and the comparative speeds since F/D/G on I64 involve
converting to/from S/T].
John
Glen Herrmannsfeldt
(snip)
> On Alpha and I64, you can pick between
> F/D/X
> F/G/X
> S/T/X
> for real, double, long double, respectively. Only the defaults have changed
> from Alpha to I64 [and the comparative speeds since F/D/G on I64 involve
> converting to/from S/T].
As I understand it, F, D, and G on Alpha also involve conversion to S/T,
but the conversion is done in hardware. The load/store instructions load
F, D , or G from memory into S or T form in registers, and do the reverse
on store instructions.
-- glen
Tim E. Sneddon
F/G and S/T both look the same in registers and are very
similar in memory format also. Field sizes are all the same,
it's just a question of order. All are supported natively.
Limited D support is offered by using a LDG (LoaD G_floating)
to get the D value into a register and then using the CVTDG
and CVTGD instructions to convert between the two. So, you
get D, but less three bits of precision.
Tim.
Bob Koehler
>
> As I understand it, F, D, and G on Alpha also involve conversion to S/T,
> but the conversion is done in hardware. The load/store instructions load
> F, D , or G from memory into S or T form in registers, and do the reverse
> on store instructions.
No, D is converted to/from G on store/load, but F and G operations
are implemented.
John Reagan
"Glen Herrmannsfeldt" <g...@ugcs.caltech.edu> wrote in message
news:get3qq$5n2$1...@aioe.org...
> As I understand it, F, D, and G on Alpha also involve conversion to S/T,
> but the conversion is done in hardware. The load/store instructions load
> F, D , or G from memory into S or T form in registers, and do the reverse
> on store instructions.
As Tim and Bob have already mentioned, the register format isn't any of the
memory formats of F/D/G/S/T. The load/store instructions know how to swap
bits around. The various instruction formats essentially control rounding,
precision, etc. So I suppose you can say that Alpha only knows one
floating format since all the operate instructions only work on registers.
The register format is essentially T format.
I64 is the same way. The I64 floating register is 82-bits wide. The
various instruction forms and FPSR bits control the precision, rouding,
shuffling of bits to/from memory, etc.
John
Glen Herrmannsfeldt
(I wrote)
>>As I understand it, F, D, and G on Alpha also involve conversion to S/T,
>>but the conversion is done in hardware. The load/store instructions load
>>F, D , or G from memory into S or T form in registers, and do the reverse
>>on store instructions.
> As Tim and Bob have already mentioned, the register format isn't any of the
> memory formats of F/D/G/S/T. The load/store instructions know how to swap
> bits around. The various instruction formats essentially control rounding,
> precision, etc. So I suppose you can say that Alpha only knows one
> floating format since all the operate instructions only work on registers.
> The register format is essentially T format.
Tim and Bob don't seem to mention that the byte order
is completely different. It seems strange to call them 'similar'
or 'implemented' given the differences.
-- glen
Tim E. Sneddon
Below is cut-n-paste from my post:
F/G and S/T both look the same in registers and are very
similar in memory format also. Field sizes are all the same,
it's just a question of order. All are supported natively.
------------------------^^^^^
I suppose I could have been clearer. You are correct. They are
in different byte order in memory. However, in registers they
are exactly the same.
On the Alpha this is handled by the LD[G|F] instruction. On I64
the AEST translator loads/stores F/G/D float with the use of of
the mux2 instruction (followed or preceeded with a setf/getf) to
achieve the same result.
Tim.
Keith Parris
> Not a single system, but I came across comments in the disk shadowing code
> for a bugfix where a byte field was being treated as a negative number
> if it exceeded 127. That byte field was the number of nodes in a cluster,
> and it was found by a customer (I think I know who), not internal testing.
>
> Also the test followed a decrement of that field, meaning a node left
the
> cluster, so the bug wouldn't have been seen unless there were 129 or
> more nodes in the cluster at some point. (Supported limit was/is 96)
SYSMAN once had a hard-coded limit of 128 nodes, but that limit was
fixed in 5.5-1.
$MOUNT/CLUSTER once had a hard-coded limit of 96 nodes, but that was
fixed in 5.5-2.
I worked with a customer who built a cluster which peaked at 151 nodes
(150 VAXes plus 1 Alpha). See
http://www.geocities.com/keithparris/decus_presentations/biglavc_article.ps
I've heard rumors of even larger clusters than that.
Volker Halle
$B_ONLCNT) exceeded 127. This caused a MSCPSERV crash. You had to have
more than 127. nodes in the cluster all mount the same disk. Been
there, seen that ;-)
Volker.
Phillip Helbig---remove CLOTHES to reply
(Michael Moroney) writes:
> Not a single system, but I came across comments in the disk shadowing code
> for a bugfix where a byte field was being treated as a negative number
> if it exceeded 127. That byte field was the number of nodes in a cluster,
> and it was found by a customer (I think I know who), not internal testing.
>
> Also the test followed a decrement of that field, meaning a node left the
> cluster, so the bug wouldn't have been seen unless there were 129 or
> more nodes in the cluster at some point. (Supported limit was/is 96)
As you point out, there are reasons why that's the supported limit.
Phillip Helbig---remove CLOTHES to reply
<M.Kr...@gsi.de> writes:
> Found a historical quote (as of 1990):
> 2x4MB for a VS3176 for close to 3000 DEM (approx $1500 back then).
> And that's already the cheaper OEM price, not the original DEC one.
> I think VS4000 memory wasn't that much cheaper.
I remember pricing RISC machines about 1994 or so. We figured on
roughly DM 100 per MB. Today, a 4-GB memory card for a digital camera
costs about EUR 10. Factor 20,000 in 14 years.
johnwa...@yahoo.co.uk
remove CLOTHES to reply) wrote:
> In article <gekukb$les$0...@news.t-online.com>, Michael Kraemer
>
> <M.Krae...@gsi.de> writes:
> > Found a historical quote (as of 1990):
> > 2x4MB for a VS3176 for close to 3000 DEM (approx $1500 back then).
> > And that's already the cheaper OEM price, not the original DEC one.
> > I think VS4000 memory wasn't that much cheaper.
>
> I remember pricing RISC machines about 1994 or so. We figured on
> roughly DM 100 per MB. Today, a 4-GB memory card for a digital camera
> costs about EUR 10. Factor 20,000 in 14 years.
Memory has indeed got a lot cheaper, but you're comparing flash memory
for a digital camera with memory for a server, which generally makes
little sense.
For 4GB of server memory (buffered, ECC) I'd expect to pay very
roughly $150 from someone like Kingston, or a bit more (but maybe not
the huge amount more which some people may be thinking) if you want a
Compaq-badged "original" part.
Not quite so recent memory (eg PC100 buffered ECC memory) might well
cost you closer to $1000 for 4GB in eight 512KB sticks;older memory is
starting to get expensive again.
Same goes for older camera memory too; I'm still using SmartMedia in
mine; 128MB is EUR20 or so (and a year or so ago, it seemed worryingly
like it had actually become unavailable).
Meanwhile a Windows licence isn't noticeably cheaper today than it was
when Win3.11 first came out in the mid 90s [1] (around $100 or so?),
and if you want today's "high end" non-cut-down Windows, it's
substantially *more* expensive than in the early days, especially for
any individuals foolish enough to pay full retail (Vista Ultimate
GBP230) rather than OEM (Vista Ultimate GBP120). Is that impressive,
or what?
Pedantically yours,
John
Richard
johnwa...@yahoo.co.uk spake the secret code
<3c395fbc-074b-419b...@q9g2000yqc.googlegroups.com> thusly:
>Meanwhile a Windows licence isn't noticeably cheaper today than it was
>when Win3.11 first came out in the mid 90s [1] (around $100 or so?),
This is as silly as the memory comparison. You're not buying a Win 3.11
license when you put out that $100 today. You're getting a *lot* more
software and functionality for that same $100. Remember that 3.11
doesn't even include TCP/IP.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Rich Jordan
> [Please do not mail me a copy of your followup]
>
> <3c395fbc-074b-419b-9562-482b0b6fe...@q9g2000yqc.googlegroups.com> thusly:
>
> >Meanwhile a Windows licence isn't noticeably cheaper today than it was
> >when Win3.11 first came out in the mid 90s [1] (around $100 or so?),
>
> This is as silly as the memory comparison. You're not buying a Win 3.11
> license when you put out that $100 today. You're getting a *lot* more
> software and functionality for that same $100. Remember that 3.11
> doesn't even include TCP/IP.
> --
> "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
> <http://www.xmission.com/~legalize/book/download/index.html>
>
> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
But you are buying the 'top of the line' desktop product from that
vendor in both cases. Their version of the Eddie Bauer edition Ford
Explorer. The 1990 model cost X$, the 2008 model costs Y$, you're
probably getting 'a lot more' in 2008 but its the same thing selling
to the same group of people with the same (adjusted for time)
expectations; only the difference in the real value of the dollar
really matters. What do you "need" in a desktop system. Then (for
some) it was 3.11. Now (for some) its Vista Ultimate. It is the same
product adjusted for time, just more features made standard due to
market forces.
Keith Parris
Reasons, but not any good reasons, IMHO.
The design limit for OpenVMS Clusters was 256 nodes, hence the presence
of all those 8-bit-wide fields in the cluster internals and data structures.
The supported cluster node count has varied over time, with values of
13, 26, and 42 at various points in time. The supported limit at present
is still 96. That number was based on a bug in $MOUNT/CLUSTER way back
in VMS version 5.2 that caused crashes at above 96 nodes, when C.W.
Hobbs (of Cluster Wide Process Services, or "CWPS" fame) cobbled
together enough systems to test that many. And although that bug has
long since been fixed (5.5-2), the supported number has never been raised.
Qualification and test expense, coupled with a lack of customer pressure
for higher supported numbers, is why larger configurations haven't been
supported since then. It's not based on any inability of the product
itself -- any known limits at 96 or 128 nodes (and even one at 224
nodes) have been removed.
Perhaps with virtualization it may become practical to economically test
OpenVMS Clusters with as many as 255 nodes.
Richard
Rich Jordan <jor...@ccs4vms.com> spake the secret code
<3423f919-20c7-4e7a...@35g2000pry.googlegroups.com> thusly:
>On Nov 12, 8:49 pm, legalize+jee...@mail.xmission.com (Richard) wrote:
>> [Please do not mail me a copy of your followup]
>>
>> johnwalla...@yahoo.co.uk spake the secret code
>> <3c395fbc-074b-419b-9562-482b0b6fe...@q9g2000yqc.googlegroups.com> thusly:
>>
>> >Meanwhile a Windows licence isn't noticeably cheaper today than it was
>> >when Win3.11 first came out in the mid 90s [1] (around $100 or so?),
>>
>> This is as silly as the memory comparison. You're not buying a Win 3.11
>> license when you put out that $100 today. You're getting a *lot* more
>> software and functionality for that same $100. Remember that 3.11
>> doesn't even include TCP/IP.
>> --
>> "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
>> <http://www.xmission.com/~legalize/book/download/index.html>
>>
>> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
>
>But you are buying the 'top of the line' desktop product from that
>vendor in both cases.
No, you are not. "Top of the line" back then would have been Windows NT
(probably 3.something) and today it would be Windows Server 2008.
>some) it was 3.11. Now (for some) its Vista Ultimate. It is the same
>product adjusted for time, just more features made standard due to
>market forces.
"more features", which is why its not the same.
Bart...@gmail.com
or VAX 10000 configurations!
I agree that a cluster of a whole lot of 6/7/8000 class machines looks
impressive (of course with accompanying lot of HSC and RA storage, and
TA/TU tapedrives), but a 9000 is different!
In 1998 I had the honor of managing a VAX 9000-210 (the smallest
configuration that I know of) and that was impressive!
Regards,
Bart Zorn
On Nov 1, 12:49 am, urbancamo <m...@wickensonline.co.uk> wrote:
> To anyone listening!
>
> I was flicking through the VAX Architecture Reference Manual earlier
> and it got me wondering about the ratio between physically installed
> memory in a VAX setup and the maximum theoretical limit of 4 GB. As
> far as I'm aware for VAXen the physical never to close to the virtual.
>
> I remember when 64MB was an astronomic amount of memory, which was
> around the time of the last VAXes, so I'm asking - how much RAM did
> you see crammed into the latest or greatest of the VAXen (and what
> else was interesting about the setups, for example maximum number of
> users, storage etc)
>
> Or just tell me to get a life ;)
>
> Mark.
etms...@yahoo.co.uk
> Phillip Helbig---remove CLOTHES to reply wrote:
>
But would that make it a real VMScluster or a virtual one? ;o)
Mark Daniel
> It surprises me that nobody in this thread has mentioned any VAX 9000
> or VAX 10000 configurations!
>
> I agree that a cluster of a whole lot of 6/7/8000 class machines looks
> impressive (of course with accompanying lot of HSC and RA storage, and
> TA/TU tapedrives), but a 9000 is different!
>
> In 1998 I had the honor of managing a VAX 9000-210 (the smallest
> configuration that I know of) and that was impressive!
We took delivery of a VAX 9000 420VP 256MB (IIRC), circa 1991. First or
second in the southern hemisphere (depending on whose mythology you
subscribe to). Vector Processors were USA State Dept munitions grade
export at the time. Of course any NVIDIA GPU puts them to shame these
days - and COTS! The node name incorporated the acronym JAV - Just
Another VAX.
It integrated seamlessly into our existing 30-odd node cluster of the
time (which eventually grew to some 70-odd VAX and Alpha systems before
shrinking back down to our current 2 Alphas). Of course physically it
was anything but Just Another VAX! Enormous!! Power-hungry. And a
footprint that would put Sasquatch to shame. Impressive in all
dimensions. But VMS didn't discriminate. It just ran!
Had the 9000 series been delivered five years earlier it would have been
an astounding system. By the early nineties it was an anachronism. It
was supplemented by a VAX 7000 620 512MB (again IIRC) shortly
thereafter. Better performance in a footprint (all-round) that must
have been 20% of the 9000. Mind you the early Alphas we took delivery
of shortly thereafter were nothing to write home about either.
I still have an 9000 MCU and torque-wrench adjusted, inter-backplane
'ribbon' connector in my office bookcase. Of course, at decommissioning
the VPs were (ostensibly) returned to mainland USA (a condition of the
original license).
C'est la vie!
Galen
> It surprises me that nobody in this thread has mentioned any VAX 9000
> or VAX 10000 configurations!
>
I didn't manage or even use it, but I did see an installation where
there were two VAX 9000 systems in a cluster. The details are very
foggy since I never really worked with those systems.
Actually almost no one ever touched these two systems. They were in a
secure and very restricted access area at Onizuka Air Force Base in
Sunnyvale. The government put a pile of money into them for a program
that got cancelled before it ever really got off the ground, and yet
there they sat for at least a couple of years, with DEC Field Service
coming in every so often to PM them because the support contract was
all prepaid.
ISTR at least a few RA60's in that installation, so that they could be
removed and locked up when the systems were down--which was pretty
much all the time, whenever I was in and out of that area.
Arne Vajhøj
> It surprises me that nobody in this thread has mentioned any VAX 9000
> or VAX 10000 configurations!
My impression is that the 9000's came in and went out within
a few years while the 6000's were kept for a decade (or two !).
Arne
Tom Linden
Arne Vajhøj
> On Fri, 14 Nov 2008 17:27:24 -0800, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>
>> Bart...@gmail.com wrote:
>>> It surprises me that nobody in this thread has mentioned any VAX 9000
>>> or VAX 10000 configurations!
>>
>> My impression is that the 9000's came in and went out within
>> a few years while the 6000's were kept for a decade (or two !).
>
I believe so.
Arne
Arne Vajhøj
> Arne Vajhøj wrote:
>> VAXman- @SendSpamHere.ORG wrote:
>>> =?ISO-8859-1?Q?Arne_Vajh=F8j?= <ar...@vajhoej.dk> writes:
>>>> JF Mezei wrote:
>>>>> At the opposite scale of things...
>>>>>
>>>>> I ran an all mighty Microvax 2 with 8 megs of RAM and a 154meg
>>>>> drive to
>>>>> support 8 users runing WPS-Plus. The success of the project lead the
>>>>> MVII to be upgraded to 16 meg of RAM to support 12 users.
>>>>>
>>>>> This was circa 1987.
>>>> And today a single word processing user is using a PC
>>>> with 4 MB L2 cache, 2 GB RAM and 320 GB disk ...
>>>
>>> Isn't Billzebub's bloatware just wonderful?
>>>
>>> Micro$oft...
>>> ... keeping Moore's Law in check by several factors for over 20 years!
>>
>> It is not just MS. IBM, Oracle, SUN, SAP, Borland etc. all let
>> HW requirements follow current hardware.
>
> Funny! I do word processing on a PC with ONLY 1 GB of RAM and only 40
> GB of disk! I don't recall how much "Level X" cache it has; If anyone
> cares, it's an HP DC5750 with W/XP SP2.
That is an OS from 2002.
From what year is your Word ?
Arne
Richard B. Gilbert
It's ANCIENT! I just looked and it says it's "Word 2000".
It gets the job done! I'm not what you'd call a heavy user of Word and
I may still be using it ten years from now! I'm certainly not going to
spring for an upgrade at Microsoft's prices!
Arne Vajhøj
>
> It gets the job done! I'm not what you'd call a heavy user of Word and
> I may still be using it ten years from now! I'm certainly not going to
> spring for an upgrade at Microsoft's prices!
I am sure that it gets the job done.
But it is not a good argument for what HW modern SW requires.
Arne
Richard B. Gilbert
I'd say it's a scathing criticism of modern bloatware! In ten years are
we going to need a 100GB of RAM and a terabyte or two of disk just to
boot Windows? Maybe YOU are, but not I!