 | |
#41
 
| |||
| |||
|
Re: Sorry, but... -
01-15-2012
, 07:30 PM
|
I would really question the need for 64 GB or more of RAM, unless there are thousands of connected users. |
Hur...
Quote:
|
Of course, people usually choose the wrong technology. |
:-)
#42
| |||
| |||
|
|
Maybe so, but without DEC and Rdb, most of the technology used in RAC, and RDBMS itself would still be floundering as it did prior to the Rdb purchase which is why Larry bought it in the first place - and then licensed the cluster technology out of Tru64 from HP. I won't "bore" |
before Oracle bought Rdb....
Then they re-badged it "RAC"...
Quote:
|
but, you can start with ethernet(collaborative effort) and 64bit computing. *DEC had marketing problems which showed in their decision- |
Sperry Univac and only much, much later, by DEC... Not deriding the
value of DEC's implementation!
A small list of other "bleeding edge" DEC technologies that really
were not:
.. time-sharing scheduling: Honeywell Bull, Multics and Sperry's
OS1100.
.. true multi-processing: Sperry OS1100, with the 1110 hardware series
(back in the 60s!!!).
.. multi-tasking: IBM OS1 (later VS1)
.. virtualization: IBM VM (later OS/VM)
.. NUMA style multi-processor architecture: Control Data Cyber series.
and so on.
I'm fortunate enough to have cut my teeth in computing with most of
the Sperry and IBM stuff above.
Then Unix started here in Australia, back in 1984. And I was forever
sold!...
Quote:
|
making processes - but had really great engineering - hardware and software - down to their chip design and manufacturing. |
through in performance. And VMS to this day remains one of the best
OSs I've ever worked with. Not the best, but close.
#43
| |||
| |||
|
|
or do the same as temp tablespaces: assign a set of schemas to each. I do multiple temps all the time, one for each application set. Why can't I do the same for undo? |
values (sort of) for the rows. Any transaction with enough privilege to
modify the table can modify the rows in the table, regardless of the
schema that initiated it. There must be the place that RDBMS will look
for the modifications of the table, if it needs a read consistent block
or if rollback is needed. That space cannot depend on the schema, only on
the table. Process owned by SYSTEM schema can delete all rows in the
table SCOTT.EMP. If the schema SCOTT is allowed its own undo tablespace,
where will a process owned by user HR, who incidentally needs the old
rows because of the read consistency, look for the old rows? In the
SCOTT undo tablespace or in the SYSTEM undo tablespace?
Temporary tablespaces are different. If you need to perform a hash
algorithm or a sort algorithm, that's only work space, nobody else will
ever need it.
--
http://mgogala.byethost5.com
#44
| |||
| |||
|
|
or a single j2ee app. Apparently, those need more memory than Ben- Hur... |
hands.....
--
http://mgogala.byethost5.com
#45
| |||
| |||
|
|
They did. The Alpha architecture, although not original, was a break- through in performance. And VMS to this day remains one of the best OSs I've ever worked with. Not the best, but close. |
MVS. I used to hate working on 3278 terminals with passion, even with TSO.
--
http://mgogala.byethost5.com
#46
| |||
| |||
|
|
I would say it was the best I have ever worked with. It certainly beats MVS. I used to hate working on 3278 terminals with passion, even with TSO. |
Technical Support Organisation
..
..
..
MVS was horrible from the user interface point of view. Very efficient
otherwise. TSO was a grafted-on after thought.
The best by far was VS9 from Sperry (ex RCA Spectra). True virtual memory.
Files were treated same as memory. And the file system was the closest thing
I've ever seen to ASM, with volume groups and spanned files! Then again, it had
a proper upbringing with Dijkstra himself having been involved in the original.
I recall using a VS/9 (Univac 90/70) system with a crt terminal in the mid-70s
at the ministry of the interior in Portugal, during my uni days. At a time when
punched cards ruled! VS/9 used crt terminals almost from day one, back in the
late 60s!
OS1100 (Exec II, later EXEC 8, then OS1100) was very easy to use with the same
control language for both batch and interactive - night and day from TSO and
didn't need a separate product for the crt interface - and very efficient.
But Sperry never knew how to market it against IBM so it died - much later,
after the whole lot became Unisys. Actually I think they still market a
Clearpath IX series, a derivative/evolution of the 2200 series.
The "Uni" in Unisys comes from the original "Univac".
#47
| |||
| |||
|
|
Mladen Gogala wrote,on my timestamp of 16/01/2012 3:49 PM: I would say it was the best I have ever worked with. It certainly beats MVS. I used to hate working on 3278 terminals with passion, even with TSO. I used to work with a sales rep who thought TSO stood for Technical Support Organisation . . . MVS was horrible from the user interface point of view. Very efficient otherwise. TSO was a grafted-on after thought. The best by far was VS9 from Sperry (ex RCA Spectra). True virtual memory. Files were treated same as memory. And the file system was the closest thing I've ever seen to ASM, with volume groups and spanned files! Then again, it had a proper upbringing with Dijkstra himself having been involved in the original. |
Burroughs Corporation, as you know the "SYS" part of UNISYS :-)
After building the very first compiler for Algol-60, Dijkstra headed a
project a couple of years later (1965-1966) to write a full/fool proof
operating system for the EL-X8, the successor of the EL-X1 he already
had worked with on the Mathematics Centre in Amsterdam. Now also a
professor at "Technische Hogeschool Eindhoven" (my Alma Mater, called
Eindhoven University of Technology these days), the operating system was
named just: "THE Multiprogramming System". What was remarkable about it,
except for its well-thought of multi-layered architecture, was the fact
that most of it was designed and programmed before the target hardware
(the EL-X8) was even available! [one of the reasons Dijkstra stressed
the necessity of proving mathematically the correctness of every single
(sub)program].
< http://en.wikipedia.org/wiki/Electrologica_X8 >
< http://en.wikipedia.org/wiki/THE_mul...ramming_system >
< http://www.cs.utexas.edu/users/EWD/ewd01xx/EWD196.PDF >
During that same timeframe, Dijkstra got involved with Burroughs because
of their stack based computers that were optimized for Algol-60.
He had a very hard time convincing the THE Board to buy a Burroughs
machine (I think it was a B6500). During the early 70's I had the
privilege of following Dijkstra's classes on Structured Programming
etc., at that time he more or less had rebuild (with students!) the THE
system for the B6700, iirc it was called MULTHE by then. In 1973,
Dijkstra joined Burroughs as its Research Fellow (while staying a
professor at THE).
< http://en.wikipedia.org/wiki/Burroughs_large_systems >
< http://www.cs.utexas.edu/~EWD/MemRes%28USLtr%29.pdf >
Quote:
|
I recall using a VS/9 (Univac 90/70) system with a crt terminal in the mid-70s at the ministry of the interior in Portugal, during my uni days. At a time when punched cards ruled! VS/9 used crt terminals almost from day one, back in the late 60s! OS1100 (Exec II, later EXEC 8, then OS1100) was very easy to use with the same control language for both batch and interactive - night and day from TSO and didn't need a separate product for the crt interface - and very efficient. But Sperry never knew how to market it against IBM so it died - much later, after the whole lot became Unisys. Actually I think they still market a Clearpath IX series, a derivative/evolution of the 2200 series. The "Uni" in Unisys comes from the original "Univac". |
Around 1975, German manufacturer Siemens offered an enhanced version of
TSOS called BS2000 (Betriebs Systeme 2000) for its own line of
mainframes. While VS/9 got dumped in the early 80's, BS2000 is till in
use (as BS2000/OSD) at several European companies.
Cheers!
--
Jeroen
#48
| |||
| |||
|
|
schema that initiated it. There must be the place that RDBMS will look for the modifications of the table, if it needs a read consistent block or if rollback is needed. That space cannot depend on the schema, only on the table. Process owned by SYSTEM schema can delete all rows in the table SCOTT.EMP. If the schema SCOTT is allowed its own undo tablespace, where will a process owned by user HR, who incidentally needs the old rows because of the read consistency, *look for the old rows? In the SCOTT undo tablespace or in the SYSTEM undo tablespace? |
wide one if there isn't a schema level undo. It's really not that
difficult.
I can compartmentalize and apportion what runs under what in a single
instance as well as I can in RAC, so why not? Note that we are not
talking about a general purpose database usecase.
We are talking about running multiple independent applications in a
single instance.
The same way they can be run in multiple instances of the same
database (RAC).
Ie, apportioned and self-contained.
Presumably, one would think they would not share updates to the same
table, for precisely the same reasons that is not a good idea with RAC
if the main concern is nosebleed performance.
If RAC can run multiple undos in the same db (and share updates!) ,
why can't a single instance? The cynical moah says: to sell more RAC
licenses...
Quote:
|
Temporary tablespaces are different. If you need to perform a hash algorithm or a sort algorithm, that's only work space, nobody else will ever need it. |
not.
#49
| |||||
| |||||
|
|
I think you are mistaken here, Dijkstra was involved deeply with the Burroughs Corporation, as you know the "SYS" part of UNISYS :-) |
yours! ;-)
Quote:
|
Eindhoven University of Technology these days), the operating system was named just: "THE Multiprogramming System". What was remarkable about it, except for its well-thought of multi-layered architecture, was the fact that most of it was designed and programmed before the target hardware (the EL-X8) was even available! [one of the reasons Dijkstra stressed the necessity of proving mathematically the correctness of every single (sub)program]. |
the RCA hardware had the required firmware ops to do p and v
operations, at the core of the entire task and queue synchronization
with THE. The whole thing was described in their sales brochures and
pre-sales spiels. I do regret having thrown out all that stuff when I
came to Australia...
RCA based the Spectra series on those principles and used Dijkstra's
code ideas for it. Then they sold to Sperry, who promptly re-badged
it VS/9 and made it run on the 90/70 series (originally the 9700) -
the new name for what was, essentially and for all purposes, the
Spectra...
I've got the book with the THE description and internal workings, as
well as a few other things. It's almost a manual for VS9! McGraw-
Hill. It was part of my "computer science" semesters in uni. Been out
of print for yonks. Most unfortunate: most of it is still very actual!
Quote:
|
During that same timeframe, Dijkstra got involved with Burroughs because of their stack based computers that were optimized for Algol-60. He had a very hard time convincing the THE Board to buy a Burroughs machine (I think it was a B6500). |
inner workings of the whole thing and parts of those episodes. Amazing
mind! I still find most of it actual nowadays. Knut's is good, but
Dijkstra was a level above everyone else.
Quote:
|
VS/9 was a Sperry rename of RCA's original TSOS operating system. Around 1975, |
Sperry.
IIRC, the VS9 moniker - and the 9700 and 90/70 re-badge - was
"created" around 71.
When I first started working with Sperry 9000 and 1100 series hardware
in 1974, VS9 was already well established.
Quote:
|
While VS/9 got dumped in the early 80's, BS2000 is till in use (as BS2000/OSD) at several European companies. |
Wikipedia is notoriously incomplete in that whole area. Some of the
Unisys historical archives are quite good and accurate. I wonder if
Fujitsu keeps any of the past history of those companies?
And the proof of how good TSOS/VS9/BS2000 was is that it is still in
use and available - likely the oldest OS in use anywhere in the world!
:-)
#50
| |||
| |||
|
|
On Sun, 15 Jan 2012 17:30:42 -0800, Noons wrote: or a single j2ee app. *Apparently, those need more memory than Ben- Hur... Most CIOs would only give up J2EE if pried from their cold, dead hands..... |
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.