| Re: old pharts, Multics vs Unix vs mainframes [message #426712 is a reply to message #426705] |
Sun, 02 February 2025 16:10   |
Dan Espen
Messages: 3899
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
"Kerr-Mudd, John" <admin@127.0.0.1> writes:
D> On Sun, 2 Feb 2025 00:58:36 -0000 (UTC)
> antispam@fricas.org (Waldek Hebisch) wrote:
>
>> Peter Flass <peter_flass@yahoo.com> wrote:
>>> John Levine <johnl@taugh.com> wrote:
>>>> According to Bob Eager <news0009@eager.cx>:
>>>> > On Fri, 31 Jan 2025 10:24:01 -0500, Dan Espen wrote:
>>>> >
>>>> >>>> IBM is still selling mainframe hardware.
>>>> >>>
>>>> >>> I doubt they’re making any profit on it any more.
>>>> >>
>>>> >> That's something you could look up for yourself.
>>>> >
>>>> > I understand that all the profit has been in software, for many years.
>>>>
>>>> IBM continues to put a lot of effort into their mainframe hardware. If
>>>> you look at their financial reports, they usually have a bullet for "IBM Z"
>>>> which is up some quarters, down others. The most recent slide deck has a
>>>> bullet that says:
>>>>
>>>> z16 our most successful program in history
>>>>
>>>> I agree that mainframes is a legacy business but it's one that still has
>>>> a long life aheade it it.
>>>>
>>>
>>> No one is going to watch to convert 60 years of production software to
>>> another platform. Actually, i take that back. It’s been tried, but never
>>> successfully.
>>
>> I think that there were a lot of successful migrations from
>> mainframes to other systems. It is likely that most succesful
>> cases were gradual, taking substantial time.
>>
>> In Poland during comunist times one of basic machines were
>> domesticaly produced ICL-1900 compatible machines, using ICL
>> operating system. It seems that our manufacturer of those
>> machines stopped production around 1990 (and during eighties
>> production was decreasing). For few years alternative
>> manufacturer offered compatible machines using bit-slice
>> microprocessors. Few years ago supposedly last machine
>> of this family was decomissioned (it was used by railway
>> as part of trafic control).
>>
>> So, it is basically question of time and financial balance:
>> currently mainframe users pay higer prices to mainframe
>> vendors so that users can keep using their systems and
>> avoid migration. But as user population shrinks it may
>> become too small to adequatly support vendors. That may
>> force vendors to limit their offer leading to colapse:
>> limited vendor offer accelerates migration. That seem
>> to happened with several smaller vendors. IBM-compatible
>> world currently looks relatively healthy, but it is not
>> clear for how long. I expect at least 10 more years of use
>> of IBM-compatible mainframes, but it is hard to make
>> prediction for longer time. 10 years may look like
>> long time, but it is short compared to 60 year history.
>>
> No one expected 2 digit year field programs written in 1980 to
> still be in production in 20 years time.
Having started programming in 1964, I beg to differ.
We just expected someone to be around to deal with the problem.
--
Dan Espen
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426713 is a reply to message #426706] |
Sun, 02 February 2025 16:12 |
Dan Espen
Messages: 3899
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
scott@slp53.sl.home (Scott Lurndal) writes:
> "Kerr-Mudd, John" <admin@127.0.0.1> writes:
>> On Sun, 2 Feb 2025 00:58:36 -0000 (UTC)
>> antispam@fricas.org (Waldek Hebisch) wrote:
>>
>>> Peter Flass <peter_flass@yahoo.com> wrote:
>>>> John Levine <johnl@taugh.com> wrote:
>>>> > According to Bob Eager <news0009@eager.cx>:
>>>> >> On Fri, 31 Jan 2025 10:24:01 -0500, Dan Espen wrote:
>>>> >>
>>>> >>>>> IBM is still selling mainframe hardware.
>
>>> So, it is basically question of time and financial balance:
>>> currently mainframe users pay higer prices to mainframe
>>> vendors so that users can keep using their systems and
>>> avoid migration. But as user population shrinks it may
>>> become too small to adequatly support vendors. That may
>>> force vendors to limit their offer leading to colapse:
>>> limited vendor offer accelerates migration. That seem
>>> to happened with several smaller vendors. IBM-compatible
>>> world currently looks relatively healthy, but it is not
>>> clear for how long. I expect at least 10 more years of use
>>> of IBM-compatible mainframes, but it is hard to make
>>> prediction for longer time. 10 years may look like
>>> long time, but it is short compared to 60 year history.
>>>
>> No one expected 2 digit year field programs written in 1980 to
>> still be in production in 20 years time.
>
> At Burroughs, we fully expected 2-digit year field programs
> written in 1968 to be still in production by 2000 when we
> started the Y2K mitigation work in the mid 1980s.
>
> 1960 was used as the dividing line - any two digit year smaller
> was assumed to be 21st century; any larger was assumed to be
> 20th century.
I fixed one of my applications by looking at the current year, then
setting the window accordingly. Fixed forever.
--
Dan Espen
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426714 is a reply to message #426713] |
Sun, 02 February 2025 16:42 |
Peter Flass
Messages: 8608
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Dan Espen <dan1espen@gmail.com> wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
>
>> "Kerr-Mudd, John" <admin@127.0.0.1> writes:
>>> On Sun, 2 Feb 2025 00:58:36 -0000 (UTC)
>>> antispam@fricas.org (Waldek Hebisch) wrote:
>>>
>>>> Peter Flass <peter_flass@yahoo.com> wrote:
>>>> > John Levine <johnl@taugh.com> wrote:
>>>> >> According to Bob Eager <news0009@eager.cx>:
>>>> >>> On Fri, 31 Jan 2025 10:24:01 -0500, Dan Espen wrote:
>>>> >>>
>>>> >>>>>> IBM is still selling mainframe hardware.
>>
>>>> So, it is basically question of time and financial balance:
>>>> currently mainframe users pay higer prices to mainframe
>>>> vendors so that users can keep using their systems and
>>>> avoid migration. But as user population shrinks it may
>>>> become too small to adequatly support vendors. That may
>>>> force vendors to limit their offer leading to colapse:
>>>> limited vendor offer accelerates migration. That seem
>>>> to happened with several smaller vendors. IBM-compatible
>>>> world currently looks relatively healthy, but it is not
>>>> clear for how long. I expect at least 10 more years of use
>>>> of IBM-compatible mainframes, but it is hard to make
>>>> prediction for longer time. 10 years may look like
>>>> long time, but it is short compared to 60 year history.
>>>>
>>> No one expected 2 digit year field programs written in 1980 to
>>> still be in production in 20 years time.
>>
>> At Burroughs, we fully expected 2-digit year field programs
>> written in 1968 to be still in production by 2000 when we
>> started the Y2K mitigation work in the mid 1980s.
>>
>> 1960 was used as the dividing line - any two digit year smaller
>> was assumed to be 21st century; any larger was assumed to be
>> 20th century.
>
> I fixed one of my applications by looking at the current year, then
> setting the window accordingly. Fixed forever.
>
Depends on the application. For something like Social Security you may have
records on someone born this year(parents applied for SSN) to this year
minus 100 or more. For a payments system this works fine, since all you
usually need is last year, this year, and next year.
--
Pete
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426715 is a reply to message #426713] |
Sun, 02 February 2025 17:36 |
Charlie Gibbs
Messages: 5563
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2025-02-02, Dan Espen <dan1espen@gmail.com> wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
>
>> "Kerr-Mudd, John" <admin@127.0.0.1> writes:
>>
>>> No one expected 2 digit year field programs written in 1980 to
>>> still be in production in 20 years time.
>>
>> At Burroughs, we fully expected 2-digit year field programs
>> written in 1968 to be still in production by 2000 when we
>> started the Y2K mitigation work in the mid 1980s.
>>
>> 1960 was used as the dividing line - any two digit year smaller
>> was assumed to be 21st century; any larger was assumed to be
>> 20th century.
>
> I fixed one of my applications by looking at the current year,
> then setting the window accordingly. Fixed forever.
FSVO "forever". My first programming job was at a small
card-only shop in 1970. We did a lot of squeezing to fit
data onto an 80-column card. One way was to only store
the last digit of the year in date fields. My first
assignment was to go through all our programs and change
the digit they inserted from a 6 to a 7.
--
/~\ Charlie Gibbs | Growth for the sake of
\ / <cgibbs@kltpzyxm.invalid> | growth is the ideology
X I'm really at ac.dekanfrus | of the cancer cell.
/ \ if you read it the right way. | -- Edward Abbey
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426716 is a reply to message #426668] |
Sun, 02 February 2025 17:55 |
Anne & Lynn Wheel
Messages: 3254
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Lynn Wheeler <lynn@garlic.com> writes:
> Some of this left over from mid-90s where billions were spent on
> rewritting mainframe financial systems that queued real time
> transactions for processing during overnight batch settlement windows
> (many from the 60s&70s) ... to straight-through processing using large
> number of parallelized killer micros. Some of us pointed out that they
> were using industry standard parallelization libraries that had hundred
> times the overhead of mainframe cobol batch ... ignored until their
> pilots went down in flames (retrenching to the existing status quo).
>
> A major change was combination of 1) major RDBMS vendors (including IBM)
> did significiant throughput performance work on cluster RDBMS, 2)
> implementations done with fine-grain SQL statements that were highly
> parallelized (rather than RYO implementation parallelization), and 3)
> non-mainframe systems having significantly higher throughput.
I got performance gig at turn of century w/financial outsourcer that
handled half of all credit card accounts in the US ... datacenter had
> 40 max configured mainframe systems (none older than 18months) all
running the same 450K statement Cobol app (number needed to finish
settlement in the overnight batch window i.e. real-time transactions
were still being queued for settlement in overnight batch window).
after turn of century got involved with operation that had experience
doing large scale financial production apps for a couple decades and had
developed a fiancial application language that translated financial
transaction specifications into fine-grain SQL statements. It
significantly reduced development effort and showed that it was
significantly more agile responding to things like regulatory changes.
they prepared a number of applications that simulated the 5 or 6 largest
financial operations that then existed, for demos ... showing a six
multiprocessor (four processors each) intel/microsoft system cluster
having many times the throughput capacity of the existing production
operations.
then demo'ed at multiple financial industry organizations that initially
saw high acceptance ... then hit brick wall ... eventually told that
most of their executives still bore the scars from the 90s
"modernization" disasters.
Note the 90s disaster with large number of parallelized killer micros
involved processors with throughput that were small fraction of
mainframe and (effectively) toy parallelization. move to middle of the
1st decade after the turn of the century ... and those systems now had
1) higher throughput (1999 pentium3 single processor chip rated at 2BIPS
while max. configured DEC2000 IBM Mainframe z900 (16 processors) was
only 2.5BIPS aggregate) ... and Intel was still doubling chip throughput
every 18-24months (aided in part with transition to multi-core).
July2005 IBM z9 with max-configured 54processor clocked at 18BIPS
aggregate (333MIPS/processor) ... while Intel single multi-core chip was
at least twice that.
2) significantly higher non-cluster and cluster RDBMS throughput
3) basically both mainframe & non-mainframe were using the same industry
standard fixed-block disks ... giving non-mainframe higher IOPS
advantage with mainframe requiring extra layer providing CKD emulation.
trivia: late 70s an IBM SE on financial industry account with large
number of ATM machines, transactions running on 370/168 TPF machine. He
then re-implemented the ATM transactions on 370/158 VM370 machine
.... and was getting higher throughput (than TPF). He did some hacks to
get the ATM transcation pathlength close to TPF (ATM transaction
processing relatively trivial, typically swamped by disk I/O) ... and
then all sorts of very sophisticated transaction scheduling strategies
to optimize tansactions per disk arm sweep, including looking at account
records on the same arm, evaluating historical transaction patterns
(both by ATM machine and by account) that might include slight delays in
some transactions. This was cluster of virtual machines ... virtual
machines for transaction routing and sceduling along with dedicated
virtual machines for each disk arm.
--
virtualization experience starting Jan1968, online at home since Mar1970
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426719 is a reply to message #426705] |
Sun, 02 February 2025 21:50 |
|
|
Originally posted by: Lawrence D'Oliveiro
On Sun, 2 Feb 2025 18:04:23 +0000, Kerr-Mudd, John wrote:
> No one expected 2 digit year field programs written in 1980 to still be
> in production in 20 years time.
Already in the 1970s there were standards for representing dates and times
that specified a four-digit year. It’s not as though you could say nobody
saw this coming.
|
|
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426721 is a reply to message #426697] |
Sun, 02 February 2025 21:57 |
|
|
Originally posted by: Lawrence D'Oliveiro
On Sun, 02 Feb 2025 06:09:51 GMT, Charlie Gibbs wrote:
> I ported Adventure and Dungeon to OS/3; one of the most difficult tasks
> was getting terminal I/O to work properly.
I remember at a software house where I was working for a while, there was
a Wang mini of some description, that some colleagues were using for
development work.
One of them showed me a “Space Invaders” game running on one of the
terminals. Then he pulled out the cable between the terminal and the main
machine ... and the game kept right on playing.
Effectively, the terminal was a fully programmable computer in its own
right. No “block mode” here -- the game was fully interactive, with all
the interaction happening locally.
|
|
|
|
|
|
| Wang Terminals (Re: old pharts, Multics vs Unix) [message #426723 is a reply to message #426721] |
Sun, 02 February 2025 22:48 |
|
|
Originally posted by: Lars Poulsen
On Sun, 02 Feb 2025 06:09:51 GMT, Charlie Gibbs wrote:
>> I ported Adventure and Dungeon to OS/3; one of the most difficult tasks
>> was getting terminal I/O to work properly.
On 2025-02-03, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> I remember at a software house where I was working for a while, there was
> a Wang mini of some description, that some colleagues were using for
> development work.
>
> One of them showed me a “Space Invaders” game running on one of the
> terminals. Then he pulled out the cable between the terminal and the main
> machine ... and the game kept right on playing.
>
> Effectively, the terminal was a fully programmable computer in its own
> right. No “block mode” here -- the game was fully interactive, with all
> the interaction happening locally.
My second "real" employer was a small bespoke computer engineering shop.
In many ways similar to the one where I work now. This was in 1975.
We mostly helped university labs put specialty peripherals on their
various minicomputers. As part of that we had hooked things up to
som HP lab desktop minis using HP-IB interfaces. Then we came across a
lab that used Wang 2200 (?) minis that looked a lot like the HPs: A
terminal-like thing that had a Basic inerpreter built-in. Having chatted
with the Wang people, they talked us into representing their little
desktops in Denmark, and when they started making word processors, we
took on those as well, and soon that was most of our business.
There were several variations of the same 8-bit mini; the ones we used
for the wordprocessing system used a coax serial bus to talk to the
shared file server. With a different code load, it could be a terminal
for the Wang VS (370/130-like) as a forms-processor, not unlike the IBM
3278 from the perspective of the terminal user.
My first visit to Wang Labs in Lowell, MA, USA was to do a Danish
language localization for the OIS-140 (Office Information System) in
late April 1980.
I also had to battle Wang engineering to get proper font adjustments to
accommodate the extra Danish vowels: æøå/ÆØÅ and get them correctly
placed on the keyboard.
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426724 is a reply to message #426719] |
Sun, 02 February 2025 23:17 |
Charlie Gibbs
Messages: 5563
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2025-02-03, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Sun, 2 Feb 2025 18:04:23 +0000, Kerr-Mudd, John wrote:
>
>> No one expected 2 digit year field programs written in 1980 to still be
>> in production in 20 years time.
>
> Already in the 1970s there were standards for representing dates and times
> that specified a four-digit year. It’s not as though you could say nobody
> saw this coming.
If you were writing mortgage programs doing 20-year amortizations,
you had to have solved the problem by then.
--
/~\ Charlie Gibbs | Growth for the sake of
\ / <cgibbs@kltpzyxm.invalid> | growth is the ideology
X I'm really at ac.dekanfrus | of the cancer cell.
/ \ if you read it the right way. | -- Edward Abbey
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426726 is a reply to message #426714] |
Mon, 03 February 2025 08:55 |
scott
Messages: 4380
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> writes:
> Dan Espen <dan1espen@gmail.com> wrote:
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>
<Y2K mitigations>
>>
>> I fixed one of my applications by looking at the current year, then
>> setting the window accordingly. Fixed forever.
>>
>
> Depends on the application. For something like Social Security you may have
> records on someone born this year(parents applied for SSN) to this year
> minus 100 or more. For a payments system this works fine, since all you
> usually need is last year, this year, and next year.
For SS, even in the 1960's, they'd have to be able to store dates
from the 19th century; two-digit years were never useful in that context.
|
|
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426728 is a reply to message #426624] |
Mon, 03 February 2025 10:03 |
|
|
Originally posted by: Colin Macleod
Dan Espen <dan1espen@gmail.com> posted:
> Lynn Wheeler <lynn@garlic.com> writes:
>
>> however, all 3270s were half-duplex and if you were unfortunate to hit a
>> key same time system went to write to screen, it would lock the keyboard
>> and would have to stop and hit the reset key. YKT developed a FIFO box
>> for 3277, unplug the keyboard from the 3277 head, plug the FIFO box into
>> the head and plug the 3277 keyboard into the fifo box ... eliminating
>> the unfortunate keyboad lock.
>
> Back in the late 60s I finished implementing my first online system on a
> S/360-30 and IBM 2260s.
This reminds me of something when I was a student around 1975. My university's
only computer was an IBM 360/44 and we could use some 2260 terminals. Digging
through some manuals I got the idea that by munging the "carriage control
character" from a Fortran program I might be able to break out of the
restriction of block-mode operation and persuade a 2260 to do animated
graphics.
When tried my proof-of-concept program I did get the terminal to keep
redrawing a very flickery but changing few lines. But while I was watching
this, the other users in the lab started complaining that their terminals were
frozen. Then the operators started running around trying to find out why
the whole mainframe had hung. It appeared that my hack had somehow elevated
the priority of my animation such that nothing else was getting run at all.
I couldn't even interrupt my own program. They had to reboot the machine to
fix it and I was told in no uncertain terms to never do that again!
--
Colin Macleod ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ https://cmacleod.me.uk
Fermented grapes count towards my five-a-day, right?
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426729 is a reply to message #426715] |
Mon, 03 February 2025 11:39 |
Dan Espen
Messages: 3899
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
> On 2025-02-02, Dan Espen <dan1espen@gmail.com> wrote:
>
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> "Kerr-Mudd, John" <admin@127.0.0.1> writes:
>>>
>>>> No one expected 2 digit year field programs written in 1980 to
>>>> still be in production in 20 years time.
>>>
>>> At Burroughs, we fully expected 2-digit year field programs
>>> written in 1968 to be still in production by 2000 when we
>>> started the Y2K mitigation work in the mid 1980s.
>>>
>>> 1960 was used as the dividing line - any two digit year smaller
>>> was assumed to be 21st century; any larger was assumed to be
>>> 20th century.
>>
>> I fixed one of my applications by looking at the current year,
>> then setting the window accordingly. Fixed forever.
>
> FSVO "forever". My first programming job was at a small
> card-only shop in 1970. We did a lot of squeezing to fit
> data onto an 80-column card. One way was to only store
> the last digit of the year in date fields. My first
> assignment was to go through all our programs and change
> the digit they inserted from a 6 to a 7.
Uggh!
Meanwhile, fixes using 4 digit years are setting us up for
the Y9K bug.
--
Dan Espen
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426731 is a reply to message #426729] |
Mon, 03 February 2025 13:00 |
scott
Messages: 4380
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
Dan Espen <dan1espen@gmail.com> writes:
> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>
>> On 2025-02-02, Dan Espen <dan1espen@gmail.com> wrote:
>>
>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>
>>>> "Kerr-Mudd, John" <admin@127.0.0.1> writes:
>>>>
>>>> > No one expected 2 digit year field programs written in 1980 to
>>>> > still be in production in 20 years time.
>>>>
>>>> At Burroughs, we fully expected 2-digit year field programs
>>>> written in 1968 to be still in production by 2000 when we
>>>> started the Y2K mitigation work in the mid 1980s.
>>>>
>>>> 1960 was used as the dividing line - any two digit year smaller
>>>> was assumed to be 21st century; any larger was assumed to be
>>>> 20th century.
>>>
>>> I fixed one of my applications by looking at the current year,
>>> then setting the window accordingly. Fixed forever.
>>
>> FSVO "forever". My first programming job was at a small
>> card-only shop in 1970. We did a lot of squeezing to fit
>> data onto an 80-column card. One way was to only store
>> the last digit of the year in date fields. My first
>> assignment was to go through all our programs and change
>> the digit they inserted from a 6 to a 7.
>
> Uggh!
>
> Meanwhile, fixes using 4 digit years are setting us up for
> the Y9K bug.
A signed 64-bit integer can represent any time value (in seconds)
for a few hundred million years BCE and CE.
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426732 is a reply to message #426729] |
Mon, 03 February 2025 13:21 |
|
|
Originally posted by: Lars Poulsen
"Kerr-Mudd, John" <admin@127.0.0.1> writes:
>>>> > No one expected 2 digit year field programs written in 1980 to
>>>> > still be in production in 20 years time.
scott@slp53.sl.home (Scott Lurndal) writes:
>>>> At Burroughs, we fully expected 2-digit year field programs
>>>> written in 1968 to be still in production by 2000 when we
>>>> started the Y2K mitigation work in the mid 1980s.
>>>>
>>>> 1960 was used as the dividing line - any two digit year smaller
>>>> was assumed to be 21st century; any larger was assumed to be
>>>> 20th century.
On 2025-02-02, Dan Espen <dan1espen@gmail.com> wrote:
>>> I fixed one of my applications by looking at the current year,
>>> then setting the window accordingly. Fixed forever.
Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>> FSVO "forever". My first programming job was at a small
>> card-only shop in 1970. We did a lot of squeezing to fit
>> data onto an 80-column card. One way was to only store
>> the last digit of the year in date fields. My first
>> assignment was to go through all our programs and change
>> the digit they inserted from a 6 to a 7.
On 2025-02-03, Dan Espen <dan1espen@gmail.com> wrote:
> Uggh!
> Meanwhile, fixes using 4 digit years are setting us up for
> the Y9K bug.
Problems are much closer. One of my customers asked us to explain how
out embedded firmware deals with the Y2038 situation.
https://en.wikipedia.org/wiki/Year_2038_problem
I was pleased to be able to explain that our "calendar time" is an
unsigned 32-bit integer (since we never had to deal with pre-epoch
dates. They may have an issue 2106, however.
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426733 is a reply to message #426726] |
Mon, 03 February 2025 16:40 |
Rich Alderson
Messages: 528
Registered: August 2012
Karma: 0
|
Senior Member |
|
|
scott@slp53.sl.home (Scott Lurndal) writes:
> Peter Flass <peter_flass@yahoo.com> writes:
>> Dan Espen <dan1espen@gmail.com> wrote:
>>> scott@slp53.sl.home (Scott Lurndal) writes:
> <Y2K mitigations>
>>> I fixed one of my applications by looking at the current year, then
>>> setting the window accordingly. Fixed forever.
>> Depends on the application. For something like Social Security you may have
>> records on someone born this year(parents applied for SSN) to this year
>> minus 100 or more. For a payments system this works fine, since all you
>> usually need is last year, this year, and next year.
> For SS, even in the 1960's, they'd have to be able to store dates
> from the 19th century; two-digit years were never useful in that context.
Indeed. My greatgrandfather Alderson was born in 1876, and died in 1962; my
greatgrandmother was born in 1885, and died 6 weeks short of her 90th birthday
in 1975.
--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426734 is a reply to message #426731] |
Mon, 03 February 2025 17:21 |
Dan Espen
Messages: 3899
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
scott@slp53.sl.home (Scott Lurndal) writes:
> Dan Espen <dan1espen@gmail.com> writes:
>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>>
>>> On 2025-02-02, Dan Espen <dan1espen@gmail.com> wrote:
>>>
>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>>
>>>> > "Kerr-Mudd, John" <admin@127.0.0.1> writes:
>>>> >
>>>> >> No one expected 2 digit year field programs written in 1980 to
>>>> >> still be in production in 20 years time.
>>>> >
>>>> > At Burroughs, we fully expected 2-digit year field programs
>>>> > written in 1968 to be still in production by 2000 when we
>>>> > started the Y2K mitigation work in the mid 1980s.
>>>> >
>>>> > 1960 was used as the dividing line - any two digit year smaller
>>>> > was assumed to be 21st century; any larger was assumed to be
>>>> > 20th century.
>>>>
>>>> I fixed one of my applications by looking at the current year,
>>>> then setting the window accordingly. Fixed forever.
>>>
>>> FSVO "forever". My first programming job was at a small
>>> card-only shop in 1970. We did a lot of squeezing to fit
>>> data onto an 80-column card. One way was to only store
>>> the last digit of the year in date fields. My first
>>> assignment was to go through all our programs and change
>>> the digit they inserted from a 6 to a 7.
>>
>> Uggh!
>>
>> Meanwhile, fixes using 4 digit years are setting us up for
>> the Y9K bug.
>
> A signed 64-bit integer can represent any time value (in seconds)
> for a few hundred million years BCE and CE.
Hopefully, those 64bit dates will remain an internal representation.
Anything converting a 4 digit year to a 64bit date still has
a Y9K problem.
--
Dan Espen
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426735 is a reply to message #426733] |
Mon, 03 February 2025 17:53 |
scott
Messages: 4380
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
Rich Alderson <news@alderson.users.panix.com> writes:
> scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Peter Flass <peter_flass@yahoo.com> writes:
>>> Dan Espen <dan1espen@gmail.com> wrote:
>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>
>> <Y2K mitigations>
>
>>>> I fixed one of my applications by looking at the current year, then
>>>> setting the window accordingly. Fixed forever.
>
>>> Depends on the application. For something like Social Security you may have
>>> records on someone born this year(parents applied for SSN) to this year
>>> minus 100 or more. For a payments system this works fine, since all you
>>> usually need is last year, this year, and next year.
>
>> For SS, even in the 1960's, they'd have to be able to store dates
>> from the 19th century; two-digit years were never useful in that context.
>
> Indeed. My greatgrandfather Alderson was born in 1876, and died in 1962; my
> greatgrandmother was born in 1885, and died 6 weeks short of her 90th birthday
> in 1975.
One of my greatgrandfathers was born in 1841, immigrated in 1850 and died in
1878 due to the effects of injuries sustained during the civil war.
His wife was born in 1850 and died in 1925. My great grandmother 1881 - 1966.
>
> --
> Rich Alderson news@alderson.users.panix.com
> Audendum est, et veritas investiganda; quam etiamsi non assequamur,
> omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
> --Galen
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426736 is a reply to message #426734] |
Mon, 03 February 2025 18:08 |
scott
Messages: 4380
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
Dan Espen <dan1espen@gmail.com> writes:
> scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Dan Espen <dan1espen@gmail.com> writes:
>>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>>>
>>>> On 2025-02-02, Dan Espen <dan1espen@gmail.com> wrote:
>>>>
>>>> > scott@slp53.sl.home (Scott Lurndal) writes:
>>>> >
>>>> >> "Kerr-Mudd, John" <admin@127.0.0.1> writes:
>>>> >>
>>>> >>> No one expected 2 digit year field programs written in 1980 to
>>>> >>> still be in production in 20 years time.
>>>> >>
>>>> >> At Burroughs, we fully expected 2-digit year field programs
>>>> >> written in 1968 to be still in production by 2000 when we
>>>> >> started the Y2K mitigation work in the mid 1980s.
>>>> >>
>>>> >> 1960 was used as the dividing line - any two digit year smaller
>>>> >> was assumed to be 21st century; any larger was assumed to be
>>>> >> 20th century.
>>>> >
>>>> > I fixed one of my applications by looking at the current year,
>>>> > then setting the window accordingly. Fixed forever.
>>>>
>>>> FSVO "forever". My first programming job was at a small
>>>> card-only shop in 1970. We did a lot of squeezing to fit
>>>> data onto an 80-column card. One way was to only store
>>>> the last digit of the year in date fields. My first
>>>> assignment was to go through all our programs and change
>>>> the digit they inserted from a 6 to a 7.
>>>
>>> Uggh!
>>>
>>> Meanwhile, fixes using 4 digit years are setting us up for
>>> the Y9K bug.
>>
>> A signed 64-bit integer can represent any time value (in seconds)
>> for a few hundred million years BCE and CE.
>
> Hopefully, those 64bit dates will remain an internal representation.
> Anything converting a 4 digit year to a 64bit date still has
> a Y9K problem.
Does it? Let's take the year 10355, for example.
The 64-bit value will be 10335 * (num_seconds_in_year), or
$ printf "%'u\n" $(( 60 * 60 * 24 * 365 * 10335 ))
325,924,560,000
The maximum signed value is
$ printf "%'u\n" $(( (1 << 63) - 1 ))
9,223,372,036,854,775,807
which is almost eight orders of magnitude larger. That supports
a huge number of years both sides of zero with one second
resolution.
As for converting between internal and external representation
taking locale into account:
https://pubs.opengroup.org/onlinepubs/9799919799/functions/s trftime.html
https://pubs.opengroup.org/onlinepubs/9799919799/functions/s trptime.html
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426737 is a reply to message #426736] |
Mon, 03 February 2025 18:50 |
Dan Espen
Messages: 3899
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
scott@slp53.sl.home (Scott Lurndal) writes:
> Dan Espen <dan1espen@gmail.com> writes:
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> Dan Espen <dan1espen@gmail.com> writes:
>>>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>>>>
>>>> > On 2025-02-02, Dan Espen <dan1espen@gmail.com> wrote:
>>>> >
>>>> >> scott@slp53.sl.home (Scott Lurndal) writes:
>>>> >>
>>>> >>> "Kerr-Mudd, John" <admin@127.0.0.1> writes:
>>>> >>>
>>>> >>>> No one expected 2 digit year field programs written in 1980 to
>>>> >>>> still be in production in 20 years time.
>>>> >>>
>>>> >>> At Burroughs, we fully expected 2-digit year field programs
>>>> >>> written in 1968 to be still in production by 2000 when we
>>>> >>> started the Y2K mitigation work in the mid 1980s.
>>>> >>>
>>>> >>> 1960 was used as the dividing line - any two digit year smaller
>>>> >>> was assumed to be 21st century; any larger was assumed to be
>>>> >>> 20th century.
>>>> >>
>>>> >> I fixed one of my applications by looking at the current year,
>>>> >> then setting the window accordingly. Fixed forever.
>>>> >
>>>> > FSVO "forever". My first programming job was at a small
>>>> > card-only shop in 1970. We did a lot of squeezing to fit
>>>> > data onto an 80-column card. One way was to only store
>>>> > the last digit of the year in date fields. My first
>>>> > assignment was to go through all our programs and change
>>>> > the digit they inserted from a 6 to a 7.
>>>>
>>>> Uggh!
>>>>
>>>> Meanwhile, fixes using 4 digit years are setting us up for
>>>> the Y9K bug.
>>>
>>> A signed 64-bit integer can represent any time value (in seconds)
>>> for a few hundred million years BCE and CE.
>>
>> Hopefully, those 64bit dates will remain an internal representation.
>> Anything converting a 4 digit year to a 64bit date still has
>> a Y9K problem.
>
> Does it? Let's take the year 10355, for example.
I think you missed my point...It's going to be difficult to store
10355 in a 4 digit field.
--
Dan Espen
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426738 is a reply to message #426737] |
Mon, 03 February 2025 19:09 |
scott
Messages: 4380
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
Dan Espen <dan1espen@gmail.com> writes:
> scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Dan Espen <dan1espen@gmail.com> writes:
>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>
>>>> Dan Espen <dan1espen@gmail.com> writes:
>>>> >Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>>>> >
>>>> >> On 2025-02-02, Dan Espen <dan1espen@gmail.com> wrote:
>>>> >>
>>>> >>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>> >>>
>>>> >>>> "Kerr-Mudd, John" <admin@127.0.0.1> writes:
>>>> >>>>
>>>> >>>>> No one expected 2 digit year field programs written in 1980 to
>>>> >>>>> still be in production in 20 years time.
>>>> >>>>
>>>> >>>> At Burroughs, we fully expected 2-digit year field programs
>>>> >>>> written in 1968 to be still in production by 2000 when we
>>>> >>>> started the Y2K mitigation work in the mid 1980s.
>>>> >>>>
>>>> >>>> 1960 was used as the dividing line - any two digit year smaller
>>>> >>>> was assumed to be 21st century; any larger was assumed to be
>>>> >>>> 20th century.
>>>> >>>
>>>> >>> I fixed one of my applications by looking at the current year,
>>>> >>> then setting the window accordingly. Fixed forever.
>>>> >>
>>>> >> FSVO "forever". My first programming job was at a small
>>>> >> card-only shop in 1970. We did a lot of squeezing to fit
>>>> >> data onto an 80-column card. One way was to only store
>>>> >> the last digit of the year in date fields. My first
>>>> >> assignment was to go through all our programs and change
>>>> >> the digit they inserted from a 6 to a 7.
>>>> >
>>>> >Uggh!
>>>> >
>>>> >Meanwhile, fixes using 4 digit years are setting us up for
>>>> >the Y9K bug.
>>>>
>>>> A signed 64-bit integer can represent any time value (in seconds)
>>>> for a few hundred million years BCE and CE.
>>>
>>> Hopefully, those 64bit dates will remain an internal representation.
>>> Anything converting a 4 digit year to a 64bit date still has
>>> a Y9K problem.
>>
>> Does it? Let's take the year 10355, for example.
>
> I think you missed my point...It's going to be difficult to store
> 10355 in a 4 digit field.
The problem will be in formatting and printing, and in COBOL PIC
clauses. Fortunately the latter are becoming more rare and hopefully
won't still be used in 9999.
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426739 is a reply to message #426734] |
Mon, 03 February 2025 19:36 |
Charlie Gibbs
Messages: 5563
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2025-02-03, Dan Espen <dan1espen@gmail.com> wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Dan Espen <dan1espen@gmail.com> writes:
>>
>>> Meanwhile, fixes using 4 digit years are setting us up for
>>> the Y9K bug.
>>
>> A signed 64-bit integer can represent any time value (in seconds)
>> for a few hundred million years BCE and CE.
>
> Hopefully, those 64bit dates will remain an internal representation.
> Anything converting a 4 digit year to a 64bit date still has
> a Y9K problem.
s/Y9K/Y10K/
At the year 9000 we'll still have a millennium left to fix it.
--
/~\ Charlie Gibbs | Growth for the sake of
\ / <cgibbs@kltpzyxm.invalid> | growth is the ideology
X I'm really at ac.dekanfrus | of the cancer cell.
/ \ if you read it the right way. | -- Edward Abbey
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426740 is a reply to message #426729] |
Mon, 03 February 2025 19:55 |
|
|
Originally posted by: Lawrence D'Oliveiro
On Mon, 03 Feb 2025 11:39:25 -0500, Dan Espen wrote:
> Meanwhile, fixes using 4 digit years are setting us up for the Y9K bug.
I’m expecting that the Gregorian calendar, with its zero point set to some
arbitrary guess at the birth date of some figure that was mythological
anyway, will not be in use for that long.
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426741 is a reply to message #426734] |
Mon, 03 February 2025 20:03 |
|
|
Originally posted by: Lawrence D'Oliveiro
On Mon, 03 Feb 2025 17:21:50 -0500, Dan Espen wrote:
> Hopefully, those 64bit dates will remain an internal representation.
> Anything converting a 4 digit year to a 64bit date still has a Y9K
> problem.
The ultimate integer representation of time would be in units of the
Planck interval (5.39e-44 seconds, according to Da Wiki). Representing the
current age of the observable Universe would take about 200 bits,
according to this scale.
So I figure a 256-bit integer in this scale (representing a maximum
duration of about 10**16 years) ought to be enough to represent any
duration of time we are ever likely to be physically concerned with. ;)
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426742 is a reply to message #426728] |
Mon, 03 February 2025 20:05 |
|
|
Originally posted by: Lawrence D'Oliveiro
On Mon, 03 Feb 2025 15:03:10 GMT, Colin Macleod wrote:
> I couldn't even interrupt my own program. They had to reboot the machine
> to fix it and I was told in no uncertain terms to never do that again!
Fragile things, mainframes. They were not battle-hardened by exposure to
inquisitive students, the way interactive timesharing systems were.
|
|
|
|
| Re: Wang Terminals (Re: old pharts, Multics vs Unix) [message #426743 is a reply to message #426723] |
Mon, 03 February 2025 20:12 |
|
|
Originally posted by: Lawrence D'Oliveiro
On Mon, 3 Feb 2025 03:48:06 -0000 (UTC), Lars Poulsen wrote:
> Having chatted with the Wang people, they talked us into representing
> their little desktops in Denmark, and when they started making word
> processors, we took on those as well, and soon that was most of our
> business.
I remember I got a glimpse at some Wang assembly code once, and it looked
remarkably like my impressions of IBM 360/370 assembler. I think Dr Wang
may have copied the IBM instruction set. Or at least large parts of it.
The Asianometry channel covered the history of Dr Wang and his company
<https://www.youtube.com/watch?v=MgDZQy0nN-Y>. Obviously a brilliant
engineer, who managed to be an astute businessman as well. But he insisted
on passing control of the company to a son who was not nearly as astute.
> I also had to battle Wang engineering to get proper font adjustments to
> accommodate the extra Danish vowels: æøå/ÆØÅ and get them correctly
> placed on the keyboard.
Now that the technical obstacles to support of such alphabets have
disappeared with the advent of Unicode, you still see a cultural
reluctance among some to acknowledge their existence.
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426744 is a reply to message #426742] |
Mon, 03 February 2025 20:15 |
|
|
Originally posted by: moi
On 04/02/2025 01:05, Lawrence D'Oliveiro wrote:
> On Mon, 03 Feb 2025 15:03:10 GMT, Colin Macleod wrote:
>
>> I couldn't even interrupt my own program. They had to reboot the machine
>> to fix it and I was told in no uncertain terms to never do that again!
>
> Fragile things, mainframes. They were not battle-hardened by exposure to
> inquisitive students, the way interactive timesharing systems were.
Nonsense.
--
Bill F.
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426745 is a reply to message #426741] |
Mon, 03 February 2025 20:27 |
Charlie Gibbs
Messages: 5563
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2025-02-04, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Mon, 03 Feb 2025 17:21:50 -0500, Dan Espen wrote:
>
>> Hopefully, those 64bit dates will remain an internal representation.
>> Anything converting a 4 digit year to a 64bit date still has a Y9K
>> problem.
>
> The ultimate integer representation of time would be in units of the
> Planck interval (5.39e-44 seconds, according to Da Wiki). Representing the
> current age of the observable Universe would take about 200 bits,
> according to this scale.
>
> So I figure a 256-bit integer in this scale (representing a maximum
> duration of about 10**16 years) ought to be enough to represent any
> duration of time we are ever likely to be physically concerned with. ;)
Everybody sing along:
The whole universe was in a hot dense state
When nearly fourteen billion years ago expansion started... wait!
The earth began to cool
The autotrophs began to drool
Neanderthals developed tools
We built a wall (we built the pyramids)
Math, science, history
Unraveling the mystery
That all started with a big bang (BANG!)
You're sitting in my spot.
--
/~\ Charlie Gibbs | Growth for the sake of
\ / <cgibbs@kltpzyxm.invalid> | growth is the ideology
X I'm really at ac.dekanfrus | of the cancer cell.
/ \ if you read it the right way. | -- Edward Abbey
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426746 is a reply to message #426740] |
Mon, 03 February 2025 20:28 |
Charlie Gibbs
Messages: 5563
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2025-02-04, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Mon, 03 Feb 2025 11:39:25 -0500, Dan Espen wrote:
>
>> Meanwhile, fixes using 4 digit years are setting us up for the Y9K bug.
>
> I’m expecting that the Gregorian calendar, with its zero point set to some
> arbitrary guess at the birth date of some figure that was mythological
> anyway, will not be in use for that long.
We'll probably patch it with another rule. If, in addition to the
existing exceptions, any year divisible by 3200 is also not a leap
year, we should be getting pretty close. Of course, by then the
speed of the Earth's rotation might have changed enough to screw
things up. Or maybe the Sun will go supernova, rendering the
whole thing moot.
--
/~\ Charlie Gibbs | Growth for the sake of
\ / <cgibbs@kltpzyxm.invalid> | growth is the ideology
X I'm really at ac.dekanfrus | of the cancer cell.
/ \ if you read it the right way. | -- Edward Abbey
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426747 is a reply to message #426742] |
Mon, 03 February 2025 20:28 |
Charlie Gibbs
Messages: 5563
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2025-02-04, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Mon, 03 Feb 2025 15:03:10 GMT, Colin Macleod wrote:
>
>> I couldn't even interrupt my own program. They had to reboot the machine
>> to fix it and I was told in no uncertain terms to never do that again!
>
> Fragile things, mainframes. They were not battle-hardened by exposure to
> inquisitive students, the way interactive timesharing systems were.
On the other hand, a lot of battle-hardening resulted soon afterwards.
--
/~\ Charlie Gibbs | Growth for the sake of
\ / <cgibbs@kltpzyxm.invalid> | growth is the ideology
X I'm really at ac.dekanfrus | of the cancer cell.
/ \ if you read it the right way. | -- Edward Abbey
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426748 is a reply to message #426744] |
Mon, 03 February 2025 20:45 |
cross
Messages: 55
Registered: May 2013
Karma: 0
|
Member |
|
|
In article <m0d80sFllotU1@mid.individual.net>,
moi <findlaybill@blueyonder.co.uk> wrote:
> On 04/02/2025 01:05, Lawrence D'Oliveiro wrote:
>> On Mon, 03 Feb 2025 15:03:10 GMT, Colin Macleod wrote:
>>
>>> I couldn't even interrupt my own program. They had to reboot the machine
>>> to fix it and I was told in no uncertain terms to never do that again!
>>
>> Fragile things, mainframes. They were not battle-hardened by exposure to
>> inquisitive students, the way interactive timesharing systems were.
>
> Nonsense.
Lol. One of the major compute engines used by undergrads when I
was young was an ES/3090-600S running VM/ESA. It certainly got
tested by inquisitive students.
The troll continues to show his ignorance.
- Dan C.
|
|
|
|
| Re: Wang Terminals (Re: old pharts, Multics vs Unix) [message #426749 is a reply to message #426743] |
Mon, 03 February 2025 21:55 |
|
|
Originally posted by: Lars Poulsen
On Mon, 3 Feb 2025 03:48:06 -0000 (UTC), Lars Poulsen wrote:
>> Having chatted with the Wang people, they talked us into representing
>> their little desktops in Denmark, and when they started making word
>> processors, we took on those as well, and soon that was most of our
>> business.
On 2025-02-04, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> I remember I got a glimpse at some Wang assembly code once, and it looked
> remarkably like my impressions of IBM 360/370 assembler. I think Dr Wang
> may have copied the IBM instruction set. Or at least large parts of it.
>
> The Asianometry channel covered the history of Dr Wang and his company
> <https://www.youtube.com/watch?v=MgDZQy0nN-Y>. Obviously a brilliant
> engineer, who managed to be an astute businessman as well. But he insisted
> on passing control of the company to a son who was not nearly as astute.
The Wang VS system really did copy most of the unprivileged IBM 360
instruction set. But they really did want the customers to program in
RPG-II and derivative "4th generation" programming languages.
On Mon, 3 Feb 2025 03:48:06 -0000 (UTC), Lars Poulsen wrote:
>> I also had to battle Wang engineering to get proper font adjustments to
>> accommodate the extra Danish vowels: æøå/ÆØÅ and get them correctly
>> placed on the keyboard.
On 2025-02-04, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> Now that the technical obstacles to support of such alphabets have
> disappeared with the advent of Unicode, you still see a cultural
> reluctance among some to acknowledge their existence.
Keyboards was the big problem. The Norvegian Wang subsidiary had copied
the DecWriter Norvegian keyboards, which were really badly screwed up.
(And DEC in Denmark had accepted those Norvegian keyboards.) I had some
fun researching /standards/ for office keyboards to get something that
would work for office typists.
Wang also did not understand the concept of /ergonomics/. We found that
the market required detached keyboards, but the only reason I got
anywhere, was because Germany had made it a workplace safety law in
order to reduce RSI and carpal tunnel disabilities.
When I visited the Wang HQ in early 1980, I got a glimpse of how
disconnected they were from my reality. In the lobby, 3-4 receptionist
secretaries in short skirts sat on bar stools in short skirts and high
heels at little round cocktail lounge tables with a terminal teetering
on top. Of course that would not have worked with a detached keyboard,
because the table was too small for that. The whole thing would not
have been tolerated, but have created instant lawsuits as a "hostile
work environment".
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426750 is a reply to message #426744] |
Mon, 03 February 2025 23:05 |
|
|
Originally posted by: Lawrence D'Oliveiro
On Tue, 4 Feb 2025 01:15:08 +0000, moi wrote:
> On 04/02/2025 01:05, Lawrence D'Oliveiro wrote:
>
>> On Mon, 03 Feb 2025 15:03:10 GMT, Colin Macleod wrote:
>>
>>> I couldn't even interrupt my own program. They had to reboot the
machine
>>> to fix it and I was told in no uncertain terms to never do that again!
>>
>> Fragile things, mainframes.
>
> Nonsense.
The very post I was replying to gives the lie to your denial.
There is this persistent myth that mainframes are highly reliable, with
uptimes measurable in years.
Clearly not in this case.
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426751 is a reply to message #426733] |
Tue, 04 February 2025 02:13 |
Bob Martin
Messages: 167
Registered: August 2012
Karma: 0
|
Senior Member |
|
|
On 3 Feb 2025 at 21:40:05, Rich Alderson <news@alderson.users.panix.com> wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Peter Flass <peter_flass@yahoo.com> writes:
>>> Dan Espen <dan1espen@gmail.com> wrote:
>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>
>> <Y2K mitigations>
>
>>>> I fixed one of my applications by looking at the current year, then
>>>> setting the window accordingly. Fixed forever.
>
>>> Depends on the application. For something like Social Security you may have
>>> records on someone born this year(parents applied for SSN) to this year
>>> minus 100 or more. For a payments system this works fine, since all you
>>> usually need is last year, this year, and next year.
>
>> For SS, even in the 1960's, they'd have to be able to store dates
>> from the 19th century; two-digit years were never useful in that context.
>
> Indeed. My greatgrandfather Alderson was born in 1876, and died in 1962; my
> greatgrandmother was born in 1885, and died 6 weeks short of her 90th birthday
> in 1975.
My grandfather was born in 1863.
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426752 is a reply to message #426744] |
Tue, 04 February 2025 02:16 |
Bob Martin
Messages: 167
Registered: August 2012
Karma: 0
|
Senior Member |
|
|
On 4 Feb 2025 at 01:15:08, moi <findlaybill@blueyonder.co.uk> wrote:
> On 04/02/2025 01:05, Lawrence D'Oliveiro wrote:
>> On Mon, 03 Feb 2025 15:03:10 GMT, Colin Macleod wrote:
>>
>>> I couldn't even interrupt my own program. They had to reboot the machine
>>> to fix it and I was told in no uncertain terms to never do that again!
>>
>> Fragile things, mainframes. They were not battle-hardened by exposure to
>> inquisitive students, the way interactive timesharing systems were.
>
> Nonsense.
Everything Lawrence says is nonsense.
If only people would stop responding to him.
|
|
|
|
| Re: old pharts, Multics vs Unix [message #426754 is a reply to message #426742] |
Tue, 04 February 2025 08:09 |
Peter Flass
Messages: 8608
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Mon, 03 Feb 2025 15:03:10 GMT, Colin Macleod wrote:
>
>> I couldn't even interrupt my own program. They had to reboot the machine
>> to fix it and I was told in no uncertain terms to never do that again!
>
> Fragile things, mainframes. They were not battle-hardened by exposure to
> inquisitive students, the way interactive timesharing systems were.
>
Might the problem have been the controller for the 2260s? I recall they
were somewhat kludge, using delay-lines as display buffers.
--
Pete
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426755 is a reply to message #426745] |
Tue, 04 February 2025 08:45 |
Harry Vaderchi
Messages: 772
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Tue, 04 Feb 2025 01:27:59 GMT
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> On 2025-02-04, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>> On Mon, 03 Feb 2025 17:21:50 -0500, Dan Espen wrote:
>>
>>> Hopefully, those 64bit dates will remain an internal representation.
>>> Anything converting a 4 digit year to a 64bit date still has a Y9K
>>> problem.
>>
>> The ultimate integer representation of time would be in units of the
>> Planck interval (5.39e-44 seconds, according to Da Wiki). Representing the
>> current age of the observable Universe would take about 200 bits,
>> according to this scale.
>>
>> So I figure a 256-bit integer in this scale (representing a maximum
>> duration of about 10**16 years) ought to be enough to represent any
>> duration of time we are ever likely to be physically concerned with. ;)
>
> Everybody sing along:
>
> The whole universe was in a hot dense state
> When nearly fourteen billion years ago expansion started... wait!
> The earth began to cool
> The autotrophs began to drool
> Neanderthals developed tools
> We built a wall (we built the pyramids)
> Math, science, history
> Unraveling the mystery
> That all started with a big bang (BANG!)
>
> You're sitting in my spot.
>
I'll raise you the Galaxy song by Monty Py^w^w Eric Idle.
--
Bah, and indeed Humbug.
|
|
|
|
| Re: old pharts, Multics vs Unix vs mainframes [message #426756 is a reply to message #426751] |
Tue, 04 February 2025 08:47 |
Harry Vaderchi
Messages: 772
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On 4 Feb 2025 07:13:37 GMT
Bob Martin <bob.martin@excite.com> wrote:
> On 3 Feb 2025 at 21:40:05, Rich Alderson <news@alderson.users.panix.com> wrote:
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> Peter Flass <peter_flass@yahoo.com> writes:
>>>> Dan Espen <dan1espen@gmail.com> wrote:
>>>> > scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> <Y2K mitigations>
>>
>>>> > I fixed one of my applications by looking at the current year, then
>>>> > setting the window accordingly. Fixed forever.
>>
>>>> Depends on the application. For something like Social Security you may have
>>>> records on someone born this year(parents applied for SSN) to this year
>>>> minus 100 or more. For a payments system this works fine, since all you
>>>> usually need is last year, this year, and next year.
>>
>>> For SS, even in the 1960's, they'd have to be able to store dates
>>> from the 19th century; two-digit years were never useful in that context.
>>
>> Indeed. My greatgrandfather Alderson was born in 1876, and died in 1962; my
>> greatgrandmother was born in 1885, and died 6 weeks short of her 90th birthday
>> in 1975.
>
> My grandfather was born in 1863.
>
Can we presume that your other grandfather is no longer around?
--
Bah, and indeed Humbug.
|
|
|
|
Members
Search
Help
Register
Login
Home
