1974, CERN presented comparison of VM370/CMS and MVS/TSO at SHARE ...
inside IBM the report was classified "IBM Confidential - Restricted" "on
need to know" only (not wanting internal employees see the
comparison). How much better VM370/CMS looked likely was major factor in
the head of POK (high-end 370s) convincing corporate to kill the
VM370/CMS product, shutdown the development group and transfer all the
people to POK for MVS/XA (Endicott lab eventually manages to acquire the VM370/CMS product mission, but had to recreate a development group from scratch).
part of reason that other RDBMS shipping before System/R was opposition
from "IMS" (& then EAGLE)
trivia: old archived post with decade of VAX/VMS numbers ... VM/4341s
sold in approx. same numbers in single or small unit numbers ... big difference were the large orders for hundreds of VM/4341 at a time. https://www.garlic.com/~lynn/2002f.html#0
Lynn Wheeler <lynn@garlic.com> writes:[Deleted]
Kragen
You have a habit of moving discussions from one newsgroup5 months ago
to another, That kills the conversation.
Where did Lynn's article come from?
Where did Lynn's article come from?
Jeroen Belleman <jeroen@nospam.please> writes:
Where did Lynn's article come from?
It came from alt.folklore.computers.
Kragen
On 9/11/26 18:38, Kragen Javier Sitaker wrote:That'll be "he" ...
Jeroen Belleman <jeroen@nospam.please> writes:
Where did Lynn's article come from?
It came from alt.folklore.computers.
Kragen
Thanks, found it.
I was interested because she mentioned CERN
Jeroen Belleman wrote:
On 9/11/26 18:38, Kragen Javier Sitaker wrote:That'll be "he" ...
Jeroen Belleman <jeroen@nospam.please> writes:
Where did Lynn's article come from?
It came from alt.folklore.computers.
Kragen
Thanks, found it.
I was interested because she mentioned CERN
On 9/11/26 20:18, Andy Burns wrote:
Jeroen Belleman wrote:
On 9/11/26 18:38, Kragen Javier Sitaker wrote:That'll be "he" ...
Jeroen Belleman <jeroen@nospam.please> writes:
Where did Lynn's article come from?
It came from alt.folklore.computers.
Kragen
Thanks, found it.
I was interested because she mentioned CERN
Ah, OK.
When I started at CERN in 1981, the principal computer
system was an IBM 360. We used WYLBUR for the editing
environment, with exec files for simple things and batch
processing with JCL for the more serious work.
trivia: old archived post with decade of VAX/VMS numbers ... VM/4341s
sold in approx. same numbers in single or small unit numbers ... big
difference were the large orders for hundreds of VM/4341 at a time.
https://www.garlic.com/~lynn/2002f.html#0
Sad to say, garlic.com seems to have broken your link here. <https://web.archive.org/web/20260310072508/https://www.garlic.com/~lynn/2002f.html#0>
works for now. Your post archive links are extremely valuable, and I
hope you can get your archive back on the live webrCerCorCeand maybe license it under a Creative Commons license so that itrCOs clearly legal for
people to archive.
Where did Lynn's article come from?
When I started at CERN in 1981, the principal computer
system was an IBM 360. We used WYLBUR for the editing
environment, with exec files for simple things and batch
processing with JCL for the more serious work.
It was clumsy, but I didn't know any better at the time.
Kragen Javier Sitaker <kragen@canonical.org> writes:
[Lynn Wheeler wrote:]
https://www.garlic.com/~lynn/2002f.html#0
Sad to say, garlic.com seems to have broken your link here.
... PCs & PC browser seem to work ... it seems to be mostly cellphone
and tablet for which it has disappeared.
This unlikely to be related to which browser yourCOre using, but in caseSimilarly broken Windows 11 firefox 155 and MS Edge
it is, I'm using Firefox 128.3.1esr for Linux.
looks as though their web server no longer recognises /~user for a home directory?
After a lot of late nights and more coffee than IrCOd like to admit, our brand new website is live.
[...]When I worked in Copenhagen at the Niels Bohr Institute and later at
When I started at CERN in 1981, the principal computer
system was an IBM 360. We used WYLBUR for the editing
environment, with exec files for simple things and batch
processing with JCL for the more serious work.
It was clumsy, but I didn't know any better at the time.
[...]
trivia: WYLBUR original came from stanford's virtual memory
system done for 360/67 ... Univ of Michigan had done MTS https://en.wikipedia.org/wiki/Michigan_Terminal_System
and Stanford had done ORVYL
https://en.wikipedia.org/wiki/ORVYL_and_WYLBUR
... later WYLBUR was ported to MVS
Lynn Wheeler <lynn@garlic.com> writes:
Kragen Javier Sitaker <kragen@canonical.org> writes:
[Lynn Wheeler wrote:]
https://www.garlic.com/~lynn/2002f.html#0
Sad to say, garlic.com seems to have broken your link here.
... PCs & PC browser seem to work ... it seems to be mostly cellphone
and tablet for which it has disappeared.
If you send an HTTPS request for "/~lynn/2002f.html" to www.garlic.com (77.37.114.68), it responds, saying, rCLSouth Valley Internet.
Garlic.com. [Check Availability]. The page canrCOt be found. It looks
like nothing was found at this location,rCY and giving the addresses and phone numbers of a company in Morgan Hill, California, rather than your archived posts.
This unlikely to be related to which browser yourCOre using, but in case
it is, I'm using Firefox 128.3.1esr for Linux.
On 9/12/2026 17:47, Lynn Wheeler wrote:
[...]
trivia: WYLBUR original came from stanford's virtual memory
system done for 360/67 ... Univ of Michigan had done MTS
https://en.wikipedia.org/wiki/Michigan_Terminal_System
and Stanford had done ORVYL
https://en.wikipedia.org/wiki/ORVYL_and_WYLBUR
... later WYLBUR was ported to MVS
I wonder why there were so many CRJE systems with almost identical
features:
* WYLBUR (from Stanford)
* WITS (from Waterloo)
* CRJE (IBM's official option for MVT and MVS)
... any that I have forgotten?
Of course, there was also TSO, but it was a dog, performance wise, so
none of the education places I knew would use it. I expect that the IBM develoment sites used it to develop MVS code?
On 9/13/26 10:02, Kragen Javier Sitaker wrote:
Lynn Wheeler <lynn@garlic.com> writes:It works for me. FF155.0.1, Ubuntu 24.04.4 64-bit
Kragen Javier Sitaker <kragen@canonical.org> writes:
[Lynn Wheeler wrote:]
https://www.garlic.com/~lynn/2002f.html#0
Sad to say, garlic.com seems to have broken your link here.
... PCs & PC browser seem to work ... it seems to be mostly cellphone
and tablet for which it has disappeared.
If you send an HTTPS request for "/~lynn/2002f.html" to www.garlic.com
(77.37.114.68), it responds, saying, rCLSouth Valley Internet.
Garlic.com. [Check Availability]. The page canrCOt be found. It looks
like nothing was found at this location,rCY and giving the addresses and
phone numbers of a company in Morgan Hill, California, rather than your
archived posts.
This unlikely to be related to which browser yourCOre using, but in case
it is, I'm using Firefox 128.3.1esr for Linux.
On 2026-09-14, Peter Flass wrote:
On 9/13/26 10:02, Kragen Javier Sitaker wrote:
Lynn Wheeler <lynn@garlic.com> writes:It works for me. FF155.0.1, Ubuntu 24.04.4 64-bit
Kragen Javier Sitaker <kragen@canonical.org> writes:
[Lynn Wheeler wrote:]
https://www.garlic.com/~lynn/2002f.html#0
Sad to say, garlic.com seems to have broken your link here.
... PCs & PC browser seem to work ... it seems to be mostly cellphone
and tablet for which it has disappeared.
If you send an HTTPS request for "/~lynn/2002f.html" to www.garlic.com
(77.37.114.68), it responds, saying, rCLSouth Valley Internet.
Garlic.com. [Check Availability]. The page canrCOt be found. It looks >>> like nothing was found at this location,rCY and giving the addresses and >>> phone numbers of a company in Morgan Hill, California, rather than your
archived posts.
This unlikely to be related to which browser yourCOre using, but in case >>> it is, I'm using Firefox 128.3.1esr for Linux.
You mean you don't get a "The page can't be found" message and you see
Lynn's website?
On 9/13/26 10:02, Kragen Javier Sitaker wrote:
Lynn Wheeler <lynn@garlic.com> writes:
Kragen Javier Sitaker <kragen@canonical.org> writes:
[Lynn Wheeler wrote:]
https://www.garlic.com/~lynn/2002f.html#0
Sad to say, garlic.com seems to have broken your link here.
... PCs & PC browser seem to work ... it seems to be mostly cellphone
and tablet for which it has disappeared.
If you send an HTTPS request for "/~lynn/2002f.html" to www.garlic.com
(77.37.114.68), it responds, saying, rCLSouth Valley Internet.
Garlic.com. [Check Availability]. The page canrCOt be found. It looks
like nothing was found at this location,rCY and giving the addresses and
phone numbers of a company in Morgan Hill, California, rather than your
archived posts.
This unlikely to be related to which browser yourCOre using, but in case
it is, I'm using Firefox 128.3.1esr for Linux.
It works for me. FF155.0.1, Ubuntu 24.04.4 64-bit
This unlikely to be related to which browser yourCOre using, but in case
it is, I'm using Firefox 128.3.1esr for Linux.
I wonder why there were so many CRJE systems with almost identical features: * WYLBUR (from Stanford)
* WITS (from Waterloo)
* CRJE (IBM's official option for MVT and MVS)
... any that I have forgotten?
Of course, there was also TSO, but it was a dog, performance wise, so
none of the education places I knew would use it. I expect that the
IBM develoment sites used it to develop MVS code?
When I worked in Copenhagen at the Niels Bohr Institute and later at
RECKU (the larger academic datacenter at University of Copenhagen)
in the early 1990s, the experimental physicists traveling the
circuit between SUNY Stony Brook, CERN and Copenhagen with their
suitcases full of dusty decks of FORTRAN IV cards, hated the IBM
360-s with a vengeance due to their lack of precision when computing
wave functions. They liked the 36-bit IBM709x and UNIVAC 36-bit
systems much better, but they REALLY loved the CDC 6600s at CERN
(and later Aarhus) because of the 60-bit floating point format.
Before leaving for Boeing. I modified HASP for MVT18 ...
On Sun, 13 Sep 2026 14:56:20 -0700, Lars Poulsen wrote:
When I worked in Copenhagen at the Niels Bohr Institute and later at
RECKU (the larger academic datacenter at University of Copenhagen)
in the early 1990s, the experimental physicists traveling the
circuit between SUNY Stony Brook, CERN and Copenhagen with their
suitcases full of dusty decks of FORTRAN IV cards, hated the IBM
360-s with a vengeance due to their lack of precision when computing
wave functions. They liked the 36-bit IBM709x and UNIVAC 36-bit
systems much better, but they REALLY loved the CDC 6600s at CERN
(and later Aarhus) because of the 60-bit floating point format.
Prof William rCLMr IEEE-754rCY KahanrCOs foreword to the rCLStandard Apple Numerics
ManualrCY had this to say about some of those machines:
For instance, a very Important Bunch of Machines launched in 1964
were found to have two anomalies in their double-precision
arithmetic (though not in single): First, multiplying a number /Z/
by 1.0 would lop off /Z/'s last digit. Second, the difference
between two nearly equal numbers, whose digits mostly canceled,
could be computed wrong by a factor almost as big as 16 instead of
being computed exactly as is normal. The anomalies introduced a
kind of noise in the feedback loops by which some programs had
compensated for their own rounding errors, so those programs lost
their high accuracies. These anomalies were not "bugs"; they were
"features" designed into the arithmetic by designers who thought
nobody would care. Customers did care; the arithmetic was
redesigned and repairs were retrofitted in 1967.
Not all Capriciously Designed Computer arithmetics have been
repaired. One family of computers has enjoyed notoriety for two
decades by allowing programs to generate tiny "partially
underflowed" numbers. When one of these creatures turns up as the
value of /T/ in an otherwise innocuous statement like
if T = 0.0 then Q := 0.0 else Q := 702345.6 / (T + 0.00189 / T);
it causes the computer to stop execution and emit a message
alleging "Division by Zero". The machine's schizophrenic attitude
toward zero comes about because the test for T = 0.0 is carried
out by the adder, which examines at least 13 of /T/'s leading
digits, whereas the divider and multiplier examine only 12 to
recognize zero. Doing so saved less than a dollar's worth of
transistors and maybe a picosecond of time, but at the cost of
some disagreement about whether a very tiny number /T/ is zero or
not. Fortunately, the divider agrees with the multiplier about
whether /T/ is zero, so programmers could prevent spurious
divisions by zero by slightly altering the foregoing statement as
follows:
if 1.0 * T = 0.0 then Q := 0.0 else Q := 702345.6 / (T + 0.00189 / T);
Unfortunately, the Same Computer designer responsible for "partial
underflow" designed another machine that can generate "partially
underflowed" numbers /T/ for which this statement malfunctions. On
that machine, /Q/ would be computed unexceptionably except that
the product 1.0 * T causes the machine to stop and emit a message
alleging "Overflow". How should a programmer rewrite that
innocuous statement so that it will work correctly on both
machines? We should be thankful that such a task is not
encountered every day.
On Sun, 13 Sep 2026 14:56:20 -0700, Lars Poulsen wrote:
When I worked in Copenhagen at the Niels Bohr Institute and later at
RECKU (the larger academic datacenter at University of Copenhagen)
in the early 1990s, the experimental physicists traveling the
circuit between SUNY Stony Brook, CERN and Copenhagen with their
suitcases full of dusty decks of FORTRAN IV cards, hated the IBM
360-s with a vengeance due to their lack of precision when computing
wave functions. They liked the 36-bit IBM709x and UNIVAC 36-bit
systems much better, but they REALLY loved the CDC 6600s at CERN
(and later Aarhus) because of the 60-bit floating point format.
Prof William rCLMr IEEE-754rCY KahanrCOs foreword to the rCLStandard Apple Numerics
ManualrCY had this to say about some of those machines:
For instance, a very Important Bunch of Machines launched in 1964
were found to have two anomalies in their double-precision
arithmetic (though not in single): First, multiplying a number /Z/
by 1.0 would lop off /Z/'s last digit. Second, the difference
between two nearly equal numbers, whose digits mostly canceled,
could be computed wrong by a factor almost as big as 16 instead of
being computed exactly as is normal. The anomalies introduced a
kind of noise in the feedback loops by which some programs had
compensated for their own rounding errors, so those programs lost
their high accuracies. These anomalies were not "bugs"; they were
"features" designed into the arithmetic by designers who thought
nobody would care. Customers did care; the arithmetic was
redesigned and repairs were retrofitted in 1967.
Not all Capriciously Designed Computer arithmetics have been
repaired. One family of computers has enjoyed notoriety for two
decades by allowing programs to generate tiny "partially
underflowed" numbers. When one of these creatures turns up as the
value of /T/ in an otherwise innocuous statement like
if T = 0.0 then Q := 0.0 else Q := 702345.6 / (T + 0.00189 / T);
On 9/14/2026 21:10, Lawrence DrCOOliveiro wrote:
On Sun, 13 Sep 2026 14:56:20 -0700, Lars Poulsen wrote:
When I worked in Copenhagen at the Niels Bohr Institute and later at
RECKU (the larger academic datacenter at University of Copenhagen)
in the early 1990s, the experimental physicists traveling the
circuit between SUNY Stony Brook, CERN and Copenhagen with their
suitcases full of dusty decks of FORTRAN IV cards, hated the IBM
360-s with a vengeance due to their lack of precision when computing
wave functions. They liked the 36-bit IBM709x and UNIVAC 36-bit
systems much better, but they REALLY loved the CDC 6600s at CERN
(and later Aarhus) because of the 60-bit floating point format.
Prof William rCLMr IEEE-754rCY KahanrCOs foreword to the rCLStandard Apple >> Numerics
ManualrCY had this to say about some of those machines:
-a-a-a-a For instance, a very Important Bunch of Machines launched in 1964 >> -a-a-a-a were found to have two anomalies in their double-precision
-a-a-a-a arithmetic (though not in single): First, multiplying a number /Z/ >> -a-a-a-a by 1.0 would lop off /Z/'s last digit. Second, the difference
-a-a-a-a between two nearly equal numbers, whose digits mostly canceled,
-a-a-a-a could be computed wrong by a factor almost as big as 16 instead of >> -a-a-a-a being computed exactly as is normal. The anomalies introduced a
-a-a-a-a kind of noise in the feedback loops by which some programs had
-a-a-a-a compensated for their own rounding errors, so those programs lost >> -a-a-a-a their high accuracies. These anomalies were not "bugs"; they were >> -a-a-a-a "features" designed into the arithmetic by designers who thought
-a-a-a-a nobody would care. Customers did care; the arithmetic was
-a-a-a-a redesigned and repairs were retrofitted in 1967.
-a-a-a-a Not all Capriciously Designed Computer arithmetics have been
-a-a-a-a repaired. One family of computers has enjoyed notoriety for two
-a-a-a-a decades by allowing programs to generate tiny "partially
-a-a-a-a underflowed" numbers. When one of these creatures turns up as the >> -a-a-a-a value of /T/ in an otherwise innocuous statement like
-a-a-a-a if T = 0.0 then Q := 0.0 else Q := 702345.6 / (T + 0.00189 / T);
-a-a-a-a it causes the computer to stop execution and emit a message
-a-a-a-a alleging "Division by Zero". The machine's schizophrenic attitude >> -a-a-a-a toward zero comes about because the test for T = 0.0 is carried
-a-a-a-a out by the adder, which examines at least 13 of /T/'s leading
-a-a-a-a digits, whereas the divider and multiplier examine only 12 to
-a-a-a-a recognize zero. Doing so saved less than a dollar's worth of
-a-a-a-a transistors and maybe a picosecond of time, but at the cost of
-a-a-a-a some disagreement about whether a very tiny number /T/ is zero or >> -a-a-a-a not. Fortunately, the divider agrees with the multiplier about
-a-a-a-a whether /T/ is zero, so programmers could prevent spurious
-a-a-a-a divisions by zero by slightly altering the foregoing statement as >> -a-a-a-a follows:
-a-a-a-a if 1.0 * T = 0.0 then Q := 0.0 else Q := 702345.6 / (T +
0.00189 / T);
-a-a-a-a Unfortunately, the Same Computer designer responsible for "partial >> -a-a-a-a underflow" designed another machine that can generate "partially
-a-a-a-a underflowed" numbers /T/ for which this statement malfunctions. On >> -a-a-a-a that machine, /Q/ would be computed unexceptionably except that
-a-a-a-a the product 1.0 * T causes the machine to stop and emit a message >> -a-a-a-a alleging "Overflow". How should a programmer rewrite that
-a-a-a-a innocuous statement so that it will work correctly on both
-a-a-a-a machines? We should be thankful that such a task is not
-a-a-a-a encountered every day.
Holy shit!! And modern compilers might optimize away the workaround.
Who was the designer? I asked "CoPilot" "Which computer designer
invented partial underflow" and with slight variations in the wording of
the prompt it suggested first Johann Joss, then Charles Babbage and
finally John von Neumann.
I assume the correct answer is either Gene Amdahl (or someone on his
team) or Seymour Cray (or someone on his team) ???
Prof William rCLMr IEEE-754rCY KahanrCOs foreword to the rCLStandard Apple Numerics ManualrCY had this to say about some of those machines:Oh that's wonderfully cheeky =^_^=
On 9/14/2026 21:10, Lawrence DrCOOliveiro wrote:
Unfortunately, the Same Computer designer responsible for "partial
underflow" designed another machine that can generate "partially
underflowed" numbers ...
Who was the designer? I asked "CoPilot" "Which computer designer
invented partial underflow" and with slight variations in the
wording of the prompt it suggested first Johann Joss, then Charles
Babbage and finally John von Neumann.
I assume the correct answer is either Gene Amdahl (or someone on his
team) or Seymour Cray (or someone on his team) ???
This stuff is why I hate floating point.
Later IBM introduced a "commercial" subroutine library for the 1130
with nice stuff like decimal arithmetic, but we didn't have that
yet, so we used floating point, which allowed double precision. If
you've ever tried to do payroll calculations in floating point, my
only piece of advice is DON'T. I did learn a lot about the
nitty-gritties fo FP rounding.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 74 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 03:36:31 |
| Calls: | 1,194 |
| Files: | 1,353 |
| D/L today: |
2 files (1,590K bytes) |
| Messages: | 291,364 |
