List of Archived Posts
2006 Newsgroup Postings (11/02 - 11/22)
- The Future of CPUs: What's After Multi-Core?
- Why these original FORTRAN quirks?
- Why these original FORTRAN quirks?
- ssh - password control or key control?
- ssh - password control or key control?
- Are there more stupid people in IT than there used to be?
- The Future of CPUs: What's After Multi-Core?
- The Future of CPUs: What's After Multi-Core?
- The Future of CPUs: What's After Multi-Core?
- The Future of CPUs: What's After Multi-Core?
- The Future of CPUs: What's After Multi-Core?
- SHA-1 code for IBM Mainframe
- Are there more stupid people in IT than there used to be?
- Year-end computer bug could ground Shuttle
- Year-end computer bug could ground Shuttle
- To RISC or not to RISC
- IA64 and emulator performance
- Why so little parallelism?
- Why so little parallelism?
- Why so little parallelism?
- Why so little parallelism?
- Why so little parallelism?
- AOS: The next big thing in data storage
- AOS: The next big thing in data storage
- When did computers start being EVIL???
- Universal constants: world wars
- Assembler question
- Why so little parallelism?
- Assembler question
- To RISC or not to RISC
- Why so little parallelism?
- To RISC or not to RISC
- To RISC or not to RISC
- Assembler question
- Assembler question
- Friday fun - Discovery on the pad and the software's not done
- remote support questions - curiousity
- To RISC or not to RISC
- To RISC or not to RISC
- P390
- New attacks on the financial PIN processing
- Is this true? (Were gotos really *that* bad?)
- New attacks on the financial PIN processing
- New attacks on the financial PIN processing
- waiting for acknowledgements
- waiting for acknowledgements
- waiting for acknowledgements
- New attacks on the financial PIN processing
- New attacks on the financial PIN processing
- Where can you get a Minor in Mainframe?
- Where can you get a Minor in Mainframe?
- Where can you get a Minor in Mainframe?
- Where can you get a Minor in Mainframe?
- What's a mainframe?
- Why these original FORTRAN quirks?
- What's a mainframe?
- Ranking of non-IBM mainframe builders?
- Pedantry (was RE: Shane's antipodes)
- What's The Best Computer and Why
- What's The Best Computer and Why
- Why these original FORTRAN quirks?
- Why these original FORTRAN quirks?
The Future of CPUs: What's After Multi-Core?
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Future of CPUs: What's After Multi-Core?
Newsgroups: alt.folklore.computers
Date: Thu, 02 Nov 2006 08:48:28 -0700
so just for the fun of it ... here is the thread from 2002
(with correction for finger slip from previous post)
http://www.garlic.com/~lynn/2002k.html#18 Unbelievable
http://www.garlic.com/~lynn/2002k.html#19 Vnet : Unbelievable
http://www.garlic.com/~lynn/2002k.html#20 Vnet : Unbelievable
http://www.garlic.com/~lynn/2002k.html#21 Vnet : Unbelievable
http://www.garlic.com/~lynn/2002k.html#22 Vnet : Unbelievable
http://www.garlic.com/~lynn/2002k.html#23 Vnet : Unbelievable
http://www.garlic.com/~lynn/2002k.html#26 DEC eNet: was Vnet : Unbelievable
and the thread from last spring:
http://www.garlic.com/~lynn/2006j.html#34 Arpa address
http://www.garlic.com/~lynn/2006j.html#43 virtual memory
http://www.garlic.com/~lynn/2006j.html#45 Arpa address
http://www.garlic.com/~lynn/2006j.html#46 Arpa address
http://www.garlic.com/~lynn/2006j.html#49 Arpa address
http://www.garlic.com/~lynn/2006j.html#50 Arpa address
http://www.garlic.com/~lynn/2006j.html#53 Arpa address
http://www.garlic.com/~lynn/2006k.html#1 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006k.html#3 Arpa address
http://www.garlic.com/~lynn/2006k.html#6 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006k.html#8 Arpa address
http://www.garlic.com/~lynn/2006k.html#9 Arpa address
http://www.garlic.com/~lynn/2006k.html#10 Arpa address
http://www.garlic.com/~lynn/2006k.html#31 PDP-1
http://www.garlic.com/~lynn/2006k.html#32 PDP-1
http://www.garlic.com/~lynn/2006k.html#40 Arpa address
http://www.garlic.com/~lynn/2006k.html#42 Arpa address
http://www.garlic.com/~lynn/2006k.html#43 Arpa address
http://www.garlic.com/~lynn/2006k.html#53 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006k.html#56 Hey! Keep Your Hands Out Of My Abstraction Layer!
and the current thread:
http://www.garlic.com/~lynn/2006t.html#27 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006t.html#31 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006t.html#32 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006t.html#34 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006t.html#36 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006t.html#41 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006t.html#42 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006t.html#43 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006t.html#49 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006t.html#50 The Future of CPUs: What's After Multi-Core?
Why these original FORTRAN quirks?
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why these original FORTRAN quirks?
Newsgroups: alt.folklore.computers,comp.lang.fortran
Date: Thu, 02 Nov 2006 09:33:12 -0700
jmfbahciv writes:
Of course you can do this. As TW would remark, "All it takes
is a small matter of programming."
or lots of SMOP ... misc. posts mentioning SMOP for
doing relocation
http://www.garlic.com/~lynn/subtopic.html#adcon
Why these original FORTRAN quirks?
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why these original FORTRAN quirks?
Newsgroups: alt.folklore.computers
Date: Thu, 02 Nov 2006 10:12:38 -0700
jmfbahciv writes:
That's wrong. Capital equipment gets written off in a few years.
I'd be more than insulted if a company thought of their
employees as capital equipment. They have it completely upsidedown.
Your employees are supposed to become more valuable to you the longer
they work for you--not less.
in a static or slowly changing environment ... the longer you are with
a company, the more you learn about their operation and the experience
becomes valuable.
in rapidly changing information/knowledge economy ... skills and
knowledge can quickly get stale and/or even obsolete. you now need
people that are continually adaptable/adapting.
in some scenarios this means justifying constant/continuing education
for participants. this does provide opening for the bean counters to
start treating the knowledge/skills analogous to capital
equipment. and in turn, they may start to treat people (with the
knowledge/skills) as equivalent to their knowledge/skills.
you can then fall into the trap that experience hardly counts at all
... and only the latest and greatest new model is worth anything.
ssh - password control or key control?
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: ssh - password control or key control?
Newsgroups: comp.os.linux.security
Date: Thu, 02 Nov 2006 13:56:55 -0700
Ertugrul Soeylemez <never@drwxr-xr-x.org> writes:
With S/Key you wouldn't care, although one possible attack is that the
user hijacks your connection in the background. Probably the most
secure method is still not to login from an untrusted host.
but one of the prime scenario justifications for s/key is where you
aren't carrying anything with you and still supposedly resilient to
replay attacks and man-in-the-middle attacks. however, one mitm-attack
is to inject a number that is much lower than current number of rounds
on file. countermeasure is to validate the server you are talking to
before starting s/key (but again that invalidates one of the major
scenario justifications for using s/key).
standard shared-secret/password requires use of a unique password for
every unique/different security domain. another scenario for s/key is
that a common pass phrase could be used for all security domains
... if different servers used different salts. however any single
server that you deal with could evesdrop and impersonate other
servers, acquire salts used by other servers and then use a much lower
number of rounds in a s/key impersonation (but that invalidates the
assumption that different security domains are secure from each other
using s/key ... but still being able to use the same passphrase).
countermeasure is that the client retain a lot more state information
about previous s/key operations and who they are dealing with. again
that invalidates scenario justifications for using s/key.
by the time you have finished with all the countermeasures ... you
have pretty much invalidated the scenario justifications for s/key (as
opposed to other solutions).
past posts discussion s/key, s/key attacks, and countermeasures
http://www.garlic.com/~lynn/2004b.html#45 Foiling Replay Attacks
http://www.garlic.com/~lynn/2003m.html#50 public key vs passwd authentication
http://www.garlic.com/~lynn/2003m.html#51 public key vs passwd authentication
http://www.garlic.com/~lynn/2003m.html#52 public key vs passwd authentication
ssh - password control or key control?
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: ssh - password control or key control?
Newsgroups: comp.os.linux.security
Date: Thu, 02 Nov 2006 18:11:43 -0700
Ertugrul Soeylemez <never@drwxr-xr-x.org> writes:
The whole sense is that you can login safely from an untrusted host,
such that it can possibly get access to your private key (since you need
a clear-text version of it to authenticate), but they still wouldn't be
able to authenticate fully, because they don't know the next (actually
previous) S/Key hash.
registering shared-secret/password with a host (easily vulnerable to
replay attacks) ... and as countermeasure to hosts in different
security domains impersonating you to hosts in other security domains
... every password has to be unique.
so instead the host gives you a salt and some registration iteration
count ... say 1000. you take you pass phrase and the host specific
salt ... and you repeatedly hash it the number of iteration. that gets
registered (in lieu of shared-secret).
next time you are at some random place ... you contact the host
... the send back their salt and one less than the current on-file
iteration count ... you repeat the process used for registration
... except one less this time. the host gets the iterated hash value
and hash it one more time and compare it to the registered value. if
it matches ... it is you, they store the latest value you calculated
and decrement the iteration count.
this is countermeasure to replay attack ... since the same value is
never used twice ... and an evesdropping can't predict the next value
... since hashes don't work (easily) in reverse.
now is s/key supposed to be resistant to both man-in-the-middle
attacks as well as replay attacks?
however, i'm playing man-in-the-middle, i intercept the host's
transmission of the salt aned the interation count and replace the
count with ONE (instead of 999). you iterate only once, and transmit
the single iteration. i intercept the response and repeat the
iteration the original number of times and send it on. i now leave you
alone.
later i impersonate you ... the host is going to transmit the salt and
some iteration count ... typically some value much larger than one. I
don't have your original pass phrase ... but I can still impersonate
you. All i need is the repeated hash iteration value for some
iteration much less than what the host is currently using. effectively
i have an intermediate hash value interaction ... and all I have to do
it resume the hash iteration at the iteration count I intercepted to
generate the iterated hash value specified by the host.
the original claim for s/key justification was that it was resistant
to both passive evesdropping (and replay attacks) as well as
(non-passive) man-in-the-middle attacks. however, a (non-passive)
man-in-the-middle attack can substituted a lower iteration count
... as decribed in the previous post
http://www.garlic.com/~lynn/2006u.html#3 ssh - password control or key control?
and the other posts:
http://www.garlic.com/~lynn/2004b.html#45 Foiling Replay Attacks
http://www.garlic.com/~lynn/2003m.html#50 public key vs passwd authentication
http://www.garlic.com/~lynn/2003m.html#51 public key vs passwd authentication
http://www.garlic.com/~lynn/2003m.html#52 public key vs passwd authentication
so the countermeasure is to carry around a lot more than memory of
single passphrase ... some sort of hardware dongle that keeps track of
various state ... like the last iteration count that I saw ... and the
next iteration count I'm expecting.
however, that invalidates the original justification assumptions for
s/key. futhermore, if i'm going to be carrying around a hardware
dongle ... why can't it include more than simple memory ... but
actually some processing ... like being able to do a digital signature
w/o exposing the private key.
then you could do ssh digital signature authentication ... w/o needing
digital certificates. misc. past post mentioning certificate-less
operation.
http://www.garlic.com/~lynn/subpubkey.html#certless
you could also have radius authentication environment upgraded to do
digital signature authentication. you register a public key (in place
of an iterated hash) ... and then do digital signature verification
(instead of iterated hash verification). again w/o needing digital
certificates. misc. past posts mentioning radius
http://www.garlic.com/~lynn/subpubkey.html#radius
you could also do certificate-less kerberos digital signature
authentication. the original kerberos pk-init draft for digital
signature started out being certificate-less ... just recording puhlic
key (in lieu of password) and doing public key authentication very
much like ssh does its operation. it was only later that certificate
mode of operation was added to the kerberos pk-init draft. misc. past
posts mentioning kerberos and/or pk-init
http://www.garlic.com/~lynn/subpubkey.html#kerberos
as mentioned in some of the original referenced posts on s/key
attacks, my rfc index:
http://www.garlic.com/~lynn/rfcietff.htm
and select Term (term->RFC#) in the RFCs listed by section. then
select "OTP" in the Acronym Fastpath section. this brings up
one-time password (OTP)
see also password
4226 2444 2289 2243 1938 1760
selecting any one of the RFC numbers, brings up that RFC's summary
in the lower frame. exp:
2289 S
A One-Time Password System, Haller N., Metz C., Nesser P., Straw M.,
1998/02/26 (25pp) (.txt=56495) (STD-61) (Obsoletes 1938) (Refs 1320,
1321, 1704, 1760, 1825, 1826, 1827) (Ref'ed By 2444, 2808, 3552,
3631, 3748, 3888) (ONE-PASS)
clicking on the ".txt=nnn" field in the RFC summary retrieves that
actual RFC.
See 1.0 Abstract, 2.0 Overview, and 3.0 Introduction in the above RFC
for a more detailed description of the operation. However, the
overview does say that it protects against external passive attacks and
eavesdropper (i.e. replay attacks) ... but does not protect against
"active attacks" (i.e. the man-in-the-middle attack I described)
Are there more stupid people in IT than there used to be?
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Are there more stupid people in IT than there used to be?
Newsgroups: alt.folklore.computers
Date: Thu, 02 Nov 2006 19:44:03 -0700
krw <krw@att.bizzzz> writes:
...until management decrees that they be changed every 60 days. It
takes me over half that to train my fingers and they confuse
easily. As soon as I get them trained I'm getting five "your ____
password will expire in nn days" emails every day.
My personal laptop makes finger learning easy. It has a
fingerprint reader. ;-)
shared-secrets/password worked better 30-40 years ago when you only
had one or two ... and used them everyday. when you start having
scores or hundreds ... they become impossible to memorize ... and
changing them every 30-60 days aggravates a bad situation.
then you have complex rules about password characteristics to make
them hard to guess ... which also contributes to making them
impossible to remember.
recent post on some aspects of password issues (and mechanism for
being able to use a single, common passphrase for everything)
http://www.garlic.com/~lynn/2006u.html#3 ssh - password control or key control?
http://www.garlic.com/~lynn/2006u.html#4 ssh - password control or key control?
and old bulletin on changing passwords every month and what can or can't
be a password
http://www.garlic.com/~lynn/2001d.html#51 A beautiful morning in AFM.
http://www.garlic.com/~lynn/2001d.html#52 A beautiful morning in AFM.
supposedly PIN-debit cards are more secure because they represent
two-factor authentication (card as something you have and pin as
something you know) .... i.e. from 3-factor authentication model
http://www.garlic.com/~lynn/subintegrity.html#3factor
• something you have
• something you know
• something you are
multi-factor authentication is supposedly more secure assuming that
the different factors have different vulnerabilities .... aka pin is
countermeasure to lost/stolen card. however some study claimed that
something like 30percent of debit cards have PINs written on them.
the issue presumably is the massive use of shared-secret paradigm
... that it becomes impossible for people to remember them all.
The Future of CPUs: What's After Multi-Core?
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Future of CPUs: What's After Multi-Core?
Newsgroups: alt.folklore.computers
Date: Fri, 03 Nov 2006 09:29:03 -0700
eugene@cse.ucsc.edu (Eugene Miya) writes:
Damning ARPA with faint praise?
re:
http://www.garlic.com/~lynn/2006t.html#36 The Future of CPUs: What's After Multi-Core
http://www.garlic.com/~lynn/2006u.html#0 The Future of CPUs: What's After Multi-Core
possibly just slight historical interest at where the arpanet scalling
limits were. somebody had made satirical comments about arpanet in the
late 70s about IMPs requiring 56kbit interconnect because majority of
the bandwidth could be taken up by inter-IMP administrative chatter
(including all the stuff about figuring out what would be the optimal
path for each packet). reaching 100 nodes by jan83 ... would imply
that scalling limit was starting to be reached with a lot less than
100 nodes in the late 70s.
later the comment was that part of the transition off of IMPs and
arpanet protocol (with the switch-over to internetworking protocol on
1/1/83) was being able to get out from under various of the scalling
limitations.
it probably doesn't a whole lot of difference some 25-30 years later
whether the arpanet scalling limits were 100 nodes or 250 hosts.
past threads where the load of the inter-IMP administrative chatter
was mentioned
http://www.garlic.com/~lynn/2003c.html#42 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003c.html#47 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003d.html#60 Bitnet again was: unix
http://www.garlic.com/~lynn/2003d.html#62 ARPAnet again: Bitnet again was: unix
http://www.garlic.com/~lynn/2003h.html#17 Why did TCP become popular ?
http://www.garlic.com/~lynn/2004o.html#53 360 longevity, was RISCs too close to hardware?
http://www.garlic.com/~lynn/2006e.html#35 The Pankian Metaphor
http://www.garlic.com/~lynn/2006j.html#45 Arpa address
The Future of CPUs: What's After Multi-Core?
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Future of CPUs: What's After Multi-Core?
Newsgroups: alt.folklore.computers
Date: Fri, 03 Nov 2006 10:29:08 -0700
eugene@cse.ucsc.edu (Eugene Miya) writes:
You stay in the late 70s and early 80s
and not the late 60s and early 70s when IBM poopooed it.
re:
http://www.garlic.com/~lynn/2006t.html#36 The Future of CPUs: What's After Multi-Core
http://www.garlic.com/~lynn/2006u.html#0 The Future of CPUs: What's After Multi-Core
http://www.garlic.com/~lynn/2006u.html#6 The Future of CPUs: What's After Multi-Core
"IBM" ... especially SNA organization poo-poo'ed all sorts of
stuff.
as i've mentioned before we constantly battled with them.
and as i mentioned before ... one of the first "internal network" activities
http://www.garlic.com/~lynn/subnetwork.html#internalnet
was between the science center, on the 4th flr, 545 tech sq
http://www.garlic.com/~lynn/subtopic.html#545tech
and endicott. this was software development activity to add "370"
virtual machine support to the cp67 kernel (running on 360/67). this
was before 370s were available ... and their were numerous
architecture differences between virtual memory hardware on 360/67 and
370 virtual memory architecture. the project required putting a lot of
code into the cp67 kernel to recognize the 370 virtual machine
operation and a whole lot of simulating 370 hardware characteristics
that were different than 360/67.
and there were people that cambridge was working with that were doing
arpanet support. for something a little bit different, my rfc index
http://www.garlic.com/~lynn/rfcietff.htm
and select Author in the RFCs listed by section and use browser
find function to get "Winett J." Joel worked on cp67 out at Lincoln
... after cambridge got cp67 up and working, they installed cp67 out
at Lincoln in 1967 (the third cp67 installation was at the university
in jan68, where i was undergraduate).
Winett J.
466 393 183 167 147 110 109
clicking on any RFC number, brings up the RFC summary in the lower frame,
i.e.
109
Level III Server Protocol for the Lincoln Laboratory NIC 360/67
Host, Winett J., 1971/03/24 (12pp)
normally, clicking on the ".txt=nnn" field in the RFC summary will
retrieve the actual RFCs. However, for (old) RFCs that haven't yet
been brought online, there won't be a ".txt=nnn" field.
however, there is also
466
Telnet logger/server for host LL-67, Winett J., 1973/02/27 (8pp) (.txt=17595)
which does have a ".txt=nnn" field.
for misc. old posts about joint cambridge/endicott project adding
370 virtual machine support to cp67 kernel.
http://www.garlic.com/~lynn/2002j.html#0 HONE was .. Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2004b.html#31 determining memory size
http://www.garlic.com/~lynn/2004p.html#50 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2005c.html#59 intel's Vanderpool and virtualization in general
http://www.garlic.com/~lynn/2005d.html#66 Virtual Machine Hardware
http://www.garlic.com/~lynn/2005g.html#17 DOS/360: Forty years
http://www.garlic.com/~lynn/2005h.html#18 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005i.html#39 Behavior in undefined areas?
http://www.garlic.com/~lynn/2005j.html#50 virtual 360/67 support in cp67
http://www.garlic.com/~lynn/2005p.html#27 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
http://www.garlic.com/~lynn/2006e.html#7 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006f.html#5 3380-3390 Conversion - DISAPPOINTMENT
http://www.garlic.com/~lynn/2006l.html#21 Virtual Virtualizers
http://www.garlic.com/~lynn/2006m.html#26 Mainframe Limericks
http://www.garlic.com/~lynn/2006o.html#19 Source maintenance was Re: SEQUENCE NUMBERS
http://www.garlic.com/~lynn/2006q.html#1 Materiel and graft
http://www.garlic.com/~lynn/2006q.html#45 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006q.html#49 Was FORTRAN buggy?
The Future of CPUs: What's After Multi-Core?
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Future of CPUs: What's After Multi-Core?
Newsgroups: alt.folklore.computers
Date: Fri, 03 Nov 2006 10:51:41 -0700
eugene@cse.ucsc.edu (Eugene Miya) writes:
Consider hardware programmable.
A bunch of you guys liked blinken lights.
How about letters, works, etc.?
Not stupid lights which turn off and one behind fixed
plexiglas signs with templated letters.
re:
http://www.garlic.com/~lynn/2006t.html#42 The Future of CPUs: What's After Multi-Core?
circa 76-78? ... and inexpensive enuf that they were starting to
appear on everybody's desk. at the start of this period, there was
requirement that to get 3270 on person's desk required vice-president
sign-off. we put together a business analysis that the 3yr
amortized/depreciated cost of a 3270 terminal was about the same as a
business phone (which was available on everybody's desk as matter of
course).
are we talking stuff that was ubiquitously available that everybody in
a corporation of several hundred thousand people could have one?
and i've frequently contended
http://www.garlic.com/~lynn/subnetwork.html#emulation
it was later that the ibm/pc and 3270 terminal was about the same cost
... so it was a relatively straight-forward transaction to justify an
ibm/pc as a 3270 terminal replacement ... where it was possible to
have both 3270 terminal emulation and some local desktop computing in
a single physical footprint (and same cost) ... that significant
market segment uptake contributed to enormously to wide proliferation
of the the ibm/pc.
as you mentioned in your other post ... are we talking 70s or 80s?
http://www.garlic.com/~lynn/2006u.html#7 The Future of CPUs: What's After Multi-Core?
and is it a commodity thing that can be ubiquitously deployed
world-wide that is generally available for nearly everybody in a large
corporation.
The Future of CPUs: What's After Multi-Core?
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Future of CPUs: What's After Multi-Core?
Newsgroups: alt.folklore.computers
Date: Fri, 03 Nov 2006 11:42:27 -0700
eugene@cse.ucsc.edu (Eugene Miya) writes:
Of course it's not commodity.
Most computer people have never heard of Evans and Sutherland as a firm.
re:
http://www.garlic.com/~lynn/2006t.html#42 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006u.html#8 The Future of CPUs: What's After Multi-Core?
part of old "decnews" email (clipped after mention of evans and
sutherland) ...
also notice DEC going full steam ahead with federal gov's OSI
replacement for internet
To: wheeler
Date: 31 Mar 88 21:43:52 GMT
Digital Information March 88
The quote of the month comes from Shaku Atre, president of Atre Interna-
tional Consultants, Inc. in Rye, N.Y. In discussing how DEC is trying to
make headway into the "mainframe" market; "People shouldn't be trying to
get into the mainframe market right now. What DEC should be doing is
looking to its micros since there hasn't been anything OVER THE RAIN-
BOW".
DEC - SPECIFIC
______________
y Since DEC continues to have problems with their RA70 disk drive,
they are now offering another option to perspective MicroVAX 3500
customers. Now a customer can buy a MicroVAX 3500 with two RD-54
disk drives instead of the RA-70s. DEC previously offered the option
of RA-81 drives, but those big drives are not practical in many of-
fice environments (Digital Review 3/21/88).
y The number of DEC-compatible manufacturers has dropped from 36 three
years ago to about 6 today. Fewer new firms are getting DEC cpu and
microprocessor chips. Three of the remaining six sell ruggedized
versions of MicroPDPs, MicroVAX I & 2 and PDP-11s primarily to the
military (Digital Review 1/25/88).
y DEC's "announced" DESKTOP STRATEGY is to connect "MS-DOS, VAX-based
UNIX and Macintosh systems to DEC VAX/VMS systems, and to extend
services of Decnet/OSI to IBM OS/2 desktops" (Notice the use of the
words "Decnet/OSI". Is there any doubt about DEC's committed resolve
to OSI?) (Computerworld 1/25/88).
y DEC's NAS (Network Application Support) strategy is designed to sup-
port connectivity of different systems in one environment, in effect
creating a common interface across then (i.e., positioning DEC as
being the central control point for the entire network). NAS will
support the following protocols; DAP (the Data Access Protocol in
Decnet); Microsoft's SMB (Server Messgae Block), Sun's NFS (Network
File System); Apple's AFP file sharing Protocol; Adobe Systems'
Postscript for desktop publishing; DDIF (Digital Document Inter-
change Format), DEC's document processing internal standard; and SQL
for DB use
y DEC now includes DECnet/PCSA (Personal Computer System Architecture)
client licenses with VAXmates free of charge while at the same time
reducing VAXmate prices as much as 37%. The VAXmate originally sold
for $4,250.00 with an additional $500.00 charge for DECnet/PCSA
(Digital Review 3/7/88).
DEC - GENERAL
_____________
y Evans & Sutherland now markets an option for the newly-announced
VAXStation 8000 workstations that make it possible to view 3-D im-
ages on the screen "in stereo". The technology includes a time-
multiplexed liquid crystal shutter fitting over the display,
polarizing the display for both the left and right eye. To see the
effect, one must wear a pair of (you guessed it) glasses with
polarized lenses. The option costs $11,500.00 (Digital Review
3/21/88).
... snip ... top of post, old email index
The Future of CPUs: What's After Multi-Core?
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Future of CPUs: What's After Multi-Core?
Newsgroups: alt.folklore.computers
Date: Fri, 03 Nov 2006 12:22:42 -0700
eugene@cse.ucsc.edu (Eugene Miya) writes:
This really says nothing of the firm Ivan started. Sure at this
time, this was about the time of the infamous Computer Division (the
one great hope to compete with Cray, I saved one, it's a good
argument with Gordon Bell). This says nothing of the main meat of
the firm which is high performance real-time graphics for flight
simulation, and other kinds of simulators (cars, tactical, etc.).
re:
http://www.garlic.com/~lynn/2006t.html#42 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006u.html#8 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006u.html#9 The Future of CPUs: What's After Multi-Core?
so the (real) flight simulator are probably a couple million? ... mentioned
on the e&s wiki page
with respect to the following, i got some followup emails commenting
about the "400MIP" number, the actual workstation being only 4-5mips
... and the 400MIP comes from aggregating all the special purpose
graphic chips. I would guess that the $100k is on the low-end of
prices for E&S machines?
the original email goes on quite a bit more about lots more details
from the original announcement.
To: wheeler
Date: 05 Feb 88 18:12:41 GMT
DEC formally announced the VAXstation 8000. Based on their VAX 8250
and MicroVAX II chip sets and the PS390 from Evans & Sutherland, DEC
has developed one of the fastest workstations (over 400 million 32-bit
arithmetic operations per second) with the highest vector drawing
speed (over 500,000 3D vectors/sec) and highest "apparent" resolution
(8192 x 6912) in the industry. This is DEC's first workstation to
offer hi-performance graphics with full 3D functions. In spite of
this, it is still a single-user workstation which lists at almost
$100,000.00, and is limited to 3 RD54 disk drives (total of 477 MB),
obviously expecting customers to use the VAXstation 8000 as a node in
a VAX Local-Area VAXCluster. I was asked why DEC would use 8250 chips
when the new CMOS MicroVAX 3600 chips are available. From a design
standpoint, the 8250 chip was already complete. From a manufacturing
standpoint, the 8250 chips were already manufactured and probably
sitting in a warehouse somewhere, since sales of 8250s have not been
setting the world on fire. And bottom line: I can see the DEC salesman
now - "We already have a 400 MIP workstation, we certainly do not need
any more horsepower at this point".
The following information was downline loaded from the Digital
Electronic Store about the announcement.
DESCRIPTION
High-Performance, 3D, Realtime Graphics Workstation
The VAXstation 8000 is the newest and most powerful member of
Digital's VAXstation family of high-performance graphic workstations.
Developed jointly by Digital Equipment Corporation and Evans &
Sutherland Corporation, the VAXstation 8000 is a high-performance,
full color workstation that can manipulate complex three-dimensional
graphic objects in realtime.
Evans & Sutherland is widely recognized as a leader in computer
graphics technology. The combination of their expertise in computer
graphics with Digital's system and workstation expertise has resulted
in an industry-leading product -- the VAXstation 8000.
The VAXstation 8000 is designed for applications requiring the highest
levels of computer graphics speed and clarity, such as molecular
modeling, fluid dynamics, mechanical computer-aided engineering and
design, manufacturing engineering, command and control, and computer
animation.
With the VAXstation 8000, Digital now extends the range of the
VAXstation family even further, from the low-cost desktop VAXstation
2000, through the VAXstation II/GPX and VAXstation 3200 and 3500, to
the state-of-the-art VAXstation 8000.
HIGH PERFORMANCE GRAPHICS WITH FULL 3D FEATURES
The VAXstation 8000 is a single-user VAXstation based on the VAX 8250
CPU and a high performance graphics subsystem. It is housed in an
compact, desk-side system enclosure. Digital's first system to offer
high-performance graphics hardware with full 3D functions, the
VAXstation 8000 offers the fastest vector drawing speed in the
industry -- over 500,000 3D vectors per second.
By using unique anti-aliasing technologies, the VAXstation 8000
provides an apparent resolution exceeding 8000 by 6000 pixels.
Unlike other very high performance workstations, which require special
programming and application interfaces, the VAXstation 8000 supports
the X Window System version 11 (on both the VMS and ULTRIX operating
systems) and PHIGS standards. These high-level interfaces are
standards in the workstation market and provide a fully compatible
link to the other members of Digital's VAXstation family. VAXstation
8000 workstation windowing software also includes an extensive 3D
graphics library in addition to the X Window System.
VAX PHIGS, Digital's new hierarchically-oriented 3D and 2D graphics
software language, enables application programmers to take advantage
of the power and speed of the VAXstation 8000 by using this standard
high-level graphics programming language.
... snip ... and resume ...
VAXSTATION FAMILY COMPARISON CHART
---------------------------------------------------------------------------
| |VAXstation| VAXstation | VAXstation|VAXstation|VAXstation|
| |2000 | II/GPX | 3200 |3500 |8000 |
---------------------------------------------------------------------------
| CPU/FPU | MicroVAX | MicroVAX | CVAX | CVAX | VAX 8250 |
| | | | | | |
| # Planes | 1 or 4 | 4 or 8 | 4 or 8 | 4 or 8 | 58 |
| | | | | | |
| Monitors | 15 & 19in| 19in | 19in | 19in | 19in |
| | Mono & | Mono & | Mono & | Mono & |Color Only|
| | Color | Color | Color | Color | |
| | | | | | |
| Resolution | 1024x864 | 1024x864 | 1024x864 | 1024x864 | 1024x864 |
| | | | | |Effective |
| | | | | 8192 x 6912|
| | | | | | |
| Backplane | None | Q-bus | Q-bus | Q-bus | BI bus |
| # slots | | 8/12 | 8 | 12 | 6 |
| | | | | | |
|Expansion slots| None | 2/6 | 0/1 | 4/6 | 1 |
| (min/max) | | | | | |
| Ethernet | Thinwire | thick wire | thick wire|thick wire|thick wire|
| Controller | Standard | Standard | Standard |Standard |Standard |
| | | | | | |
| Max Memory | 6 MB | 16 MB | 16 MB | 32 MB | 32 MB |
| | | | | | |
| Disk Cavities | 2 | 1 or 3 | 1 | 2 | 3 |
| | | | | | |
| Min/Max Hard | 42 Mb/ | 71Mb/ | 71Mb/ | 159Mb/ | 159Mb/ |
| Disk Support | 318 Mb | 477 Mb | 318 Mb | 560 Mb | 477Mb |
| | | | | | |
| System | One year | One year | One year | One year | One year |
| Warranty | | | | | |
| | | | | | |
---------------------------------------------------------------------------
... snip ... top of post, old email index
SHA-1 code for IBM Mainframe
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: SHA-1 code for IBM Mainframe
Newsgroups: sci.crypt
Date: Fri, 03 Nov 2006 14:57:46 -0700
"z" principles of operation
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/CCONTENTS?SHELF=DZ9ZBK03&DN=SA22-7832-03&DT=20040504121320
had relatively little to say about the crypto instructions
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/2.3.7?SHELF=DZ9ZBK03&DT=20040504121320
other than minor footnote about virtualization of the facility
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/1.3?SHELF=DZ9ZBK03&DT=20040504121320#SPTCRYBLB
in the section about relationship between "z" and esa/390
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/1.3?SHELF=DZ9ZBK03&DT=20040504121320
here is document describing crypto function (performance) on Z machines
http://www-03.ibm.com/systems/z/security/pdf/Web_z9_Crypto_Rel_01202006_X.pdf
and mentions (System z9 message security assist instructions) KLMD-SHA-1
and KLMD-SHA-256
Are there more stupid people in IT than there used to be?
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Are there more stupid people in IT than there used to be?
Newsgroups: alt.folklore.computers
Date: Fri, 03 Nov 2006 15:55:52 -0700
greymaus writes:
Schneier went over this in "Applied *".. Here we are changing over
to PIN, the card company sent me out their letter with a number on
it, fixed so they can not be read by holding a light aganst the
envelope, so I am asking if I can still sign for purchases, the lady
says yes, but it will be all PIN next (whenever), I can't decipher
the bloody number (failing eyesight), so she says "Get a younger
person to read it for you".. Hello?.. Best hardware outlet in the
area is going over to credit/password website, another bloody
password to remember.
re:
http://www.garlic.com/~lynn/2006u.html#5 Are there more stupid people in IT than there used to be?
there has been some issues with the change over to debit cards that
can be used both with or w/o a pin ... where even if you always used
the debit card w/pin ... if it is lost/stolen ... others would be able
to use it w/o pin.
there is separate issue with chip&pin deployments ... where attacker
could skim the chip authentication information ... potentially using
some nearly identical processes that had been used to skim magstripe
information. the chip authentication information is then injected into
a counterfeit card. in the chip&pin deployments, after the chip had
authenticated to the terminal, the terminal then asked the chip if the
correct pin had been entered. the counterfeit cards were programmed to
always repond YES (regardless of the pin entered). this gave rise to
the label yes card ... some number of past posts discussing yes
card vulnerability:
http://www.garlic.com/~lynn/subintegrity.html#yescard
aka once the chip authentication information had been skimmed ... it
wasn't even necessary to find out the correct pin for use with a
yes card
Year-end computer bug could ground Shuttle
Refed: **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Subject: Year-end computer bug could ground Shuttle
Date: Tue, 07 Nov 2006 05:18:59 -0800
Newsgroups: alt.folklore.computers
Year-end computer bug could ground Shuttle
http://www.theregister.co.uk/2006/11/07/nasa_computer/
Computer glitch may limit next shuttle launch
http://news.com.com/Computer+glitch+may+limit+next+shuttle+launch/2100-11397_3-6133088.html?tag=nefd.top
Computer Date Glitch May Limit Next Shuttle Launch
http://science.slashdot.org/science/06/11/06/2320235.shtml
Computer glitch limits next space shuttle launch
http://today.reuters.com/news/articlenews.aspx?type=scienceNews&storyID=2006-11-06T185421Z_01_N06275670_RTRUKOC_0_US-SPACE-SHUTTLE.xml&WTmodLoc=SciNewsHome_C1_%5BFeed%5D-7
you may have read it first here ... postings that include email from
1984
http://www.garlic.com/~lynn/99.html#24 BA Solves Y2K (Was: Re: Chinese
Solve Y2K)
http://www.garlic.com/~lynn/2000.html#94 Those who do not learn from
history...
http://www.garlic.com/~lynn/2003p.html#21 Sun researchers: Computers do
bad math ;)
http://www.garlic.com/~lynn/2006r.html#16 Was FORTRAN buggy?
Year-end computer bug could ground Shuttle
Refed: **, - **, - **
From: lynn@garlic.com
Subject: Re: Year-end computer bug could ground Shuttle
Date: Tue, 07 Nov 2006 16:17:55 -0800
Newsgroups: alt.folklore.computers
re:
http://www.garlic.com/~lynn/2006u.html#13 Year-end computer bug could ground Shuttle
Al Balmer wrote:
Ah - here's a better article:
http://www.newscientistspace.com/article/dn10459-y2klike-fears-create-shuttle-scheduling-crunch.html
my reference email from 1984 is about custom implementation where one
box rolls over on day 399 and the other box rolls over on day
400. there have been some articles about pieces of shuttle program
have (re)done various stuff with COTS ... which one would expect to roll
over on jan. 1st. the articles seem to imply if they are flying at the
closest in roll over date (which ever components that may be) ... they
would have to temporary "reboot" all boxes ... as if a brand new
mission had started.
To RISC or not to RISC
From: lynn@garlic.com
Subject: Re: To RISC or not to RISC
Date: Wed, 08 Nov 2006 08:18:49 -0800
Newsgroups: alt.lang.asm,comp.arch
Rostyslaw J. Lewyckyj wrote:
But this , I think badly, misses the point, because the improvements
in performance in both cases were not due to the choices of coding
language but to the redesign of the logic of how the tasks were done.
Moving to the HLLs may be considered to have yielded other overall
sustem benefits: ease of understanding the logic, ease of
maintainability, and perhaps portability .
Would recoding the old logic in HLL have yielded performance gains?
Would recoding the new logic in assembler have yielded performance
gains? Obviously the answer in the second case is YES, if you even
only did hot spot recoding.
And yes, I do realize that assembler vs HLL may not have been the
reasong for Mr. Wheeler's posting.
re:
http://www.garlic.com/~lynn/2006t.html#45 To RISC or not to RISC
http://www.garlic.com/~lynn/2006t.html#46 To RISC or not to RISC
http://www.garlic.com/~lynn/2006t.html#47 To RISC or not to RISC
http://www.garlic.com/~lynn/2006t.html#48 To RISC or not to RISC
given constrained skills and resources ... recoding much more complex
logic in assembler represents relatively marginal (performance)
improvement than recoding much more complex logic in HLL ... but at a
significant increase in effort (in some cases HLL providing
off-the-shelf library functions that just aren't found in the
assembler environment)
one could even make the case that the theoritical recoding in
assembler (of the examples given) would never happen because of the
significant additional of resources required (the old standby
... theoritically there is no difference between theory and practice
... but in practice there is).
long ago and far away (spring 76) i released the kernel resource
manager that was all written in assembler. for some operations i
needed triple word integer math precision (96bit) and it was enormous
pain to code it from scratch using 32bit assembler instructions.
part of pl.8 stuff from the mid-70s with the original 801/risc activity
http://www.garlic.com/~lynn/subtopic.html#801
had an underlying theme that doing operating system stuff in higher
level language made a lot of stuff practical that just wouldn't have
happened if done in assembler. I think that the multics
implementation in pli had a similar theme ... i was at the science
center doing a lot of kernel stuff in assembler ... which was on 4th
flr of 545 tech sq
http://www.garlic.com/~lynn/subtopic.html#545tech
while multics was on the 5th flr (of the same bldg).
http://www.multicians.org/multics.html
a lot of the items stated as benefits for HLL ... can be turned around
and the lack of those benefits in assembler can contribute to making
various assembler activities "practrically" impossible.
by analogy, this can be extended to the lack of appropriate
methodologies and paradigms in any language ... can make various
efforts "practically" impossible ... i.e. this could be applicable to
the thread about why so little parallelism. i've written quite a bit
of "parallel" code in the form of modifying kernel to support
multiprocessor operation
http://www.garlic.com/~lynn/subtopic.html#smp
and
http://www.garlic.com/~lynn/subtopic.html#bounce
it is not theoritically impossible to write parallel code in assembler
... but it apparently is practically impossible to write lots of
parallel code in nearly all of the current, commoningly used languages
IA64 and emulator performance
Refed: **, - **, - **
From: lynn@garlic.com
Subject: Re: IA64 and emulator performance
Date: Wed, 08 Nov 2006 09:07:58 -0800
Newsgroups: comp.arch
ranjit_mathews@yahoo.com wrote:
I don't know that there is a SPARC emulator, but there's an IBM
mainframe emulator.
there are a number of commercial mainframe emulator products ... there
is also at least hercules open source implementation
http://www.conmicro.cx/hercules/
which is available on a number of platforms. in some sense, there are
some similarities between the current generations of mainframe
emulators and the majority of the ("real") mainframe implementations in
the 60s, 70s, and thru the 80s ... i.e. microcode engines where the
360/370/390/etc. implementation was microcode running on the microcode
engines.
in fact, one of the early targets for 801/risc processors was a
project to try and consolidate the large variety of internal
microprocessors.
http://www.garlic.com/~lynn/subtopic.html#801
collected past posts mentioning the large variety of internal
microproprocessors and low-level microcoding
http://www.garlic.com/~lynn/subtopic.html#mcode
misc. past posts mentioning hercules
http://www.garlic.com/~lynn/2001n.html#22 Hercules, OCO, and IBM
missing a great opportunity
http://www.garlic.com/~lynn/2001n.html#31 Hercules etc. IBM not just
missing a great opportunity...
http://www.garlic.com/~lynn/2001n.html#32 Hercules etc. IBM not just
missing a great opportunity...
http://www.garlic.com/~lynn/2001n.html#34 Hercules etc. IBM not just
missing a great opportunity...
http://www.garlic.com/~lynn/2001n.html#37 Hercules etc. IBM not just
missing a great opportunity...
http://www.garlic.com/~lynn/2001n.html#67 Hercules etc. IBM not just
missing a great opportunity...
http://www.garlic.com/~lynn/2002d.html#4 IBM Mainframe at home
http://www.garlic.com/~lynn/2002g.html#61 GE 625/635 Reference + Smart
Hardware
http://www.garlic.com/~lynn/2002i.html#31 : Re: AS/400 and MVS -
clarification please
http://www.garlic.com/~lynn/2002i.html#63 Hercules and System/390 - do
we need it?
http://www.garlic.com/~lynn/2002i.html#64 Hercules and System/390 - do
we need it?
http://www.garlic.com/~lynn/2002i.html#69 Hercules and System/390 - do
we need it?
http://www.garlic.com/~lynn/2004g.html#19 HERCULES
http://www.garlic.com/~lynn/2004g.html#29 [IBM-MAIN] HERCULES
http://www.garlic.com/~lynn/2004g.html#48 Hercules
http://www.garlic.com/~lynn/2006c.html#46 Hercules 3.04 announcement
http://www.garlic.com/~lynn/2006d.html#1 Hercules 3.04 announcement
http://www.garlic.com/~lynn/2006d.html#3 Hercules 3.04 announcement
http://www.garlic.com/~lynn/2006d.html#15 Hercules 3.04 announcement
http://www.garlic.com/~lynn/2006d.html#19 Hercules 3.04 announcement
Why so little parallelism?
Refed: **, - **, - **
From: lynn@garlic.com
Subject: Re: Why so little parallelism?
Date: Wed, 08 Nov 2006 12:43:09 -0800
Newsgroups: comp.arch
Eugene Miya wrote:
The mainframes guys like Lynn and others sort of dug their own
trenches. The UK has its own set of problems going back to the
handling of Turing thread yet again in a.f.c., and Alvey, and
Lighthill, and god knows what other mistakes you guys shoot
yourselves in the foot with. Your baggage.
i'm not sure what you are referring to ... possibly the invention of
the compare&swap instruction and the associated semantics in the late
60s and early 70s ... which was shipped as part of mainframe 370
machines in the early 70s. misc. past posts mentioning smp and/or
compare&swap instruction use for various kinds of parallel processing
operations
http://www.garlic.com/~lynn/subtopic.html#smp
minor note ... except finishing off rfc 1044 support in mainframe
product (18 years ago),
http://www.garlic.com/~lynn/subnetwork.html#1044
i haven't done any mainframe work in 20 yrs.
the following reference was a long ways from any mainframe world and
this was started nearly 20 years ago and this particular reference is
to nearly 15 yrs ago related to scaleup work for ha/cmp project
http://www.garlic.com/~lynn/95.html#13
enormous amounts of the high-speed data transport project
done in the early and mid-80s ...
http://www.garlic.com/~lynn/subnetwork.html#hsdt
referenced here .... had little to do with mainframes
http://www.garlic.com/~lynn/2006s.html#50 Ranking of non-IBM mainframe builders
http://www.garlic.com/~lynn/2006t.html#6 Ranking of non-IBM mainframe builders
a lot of it was heavily oriented towards 801/risc
http://www.garlic.com/~lynn/subtopic.html#801
part of the early issue in the ha/cmp cluster scaleup
http://www.garlic.com/~lynn/subtopic.html#hacmp
was that rios had no provisions for cache coherency used in smp
parallel environment ... as a result we had to make design trade-offs
for message passing parallelism in cluster scaleup environments ...
while not precluding being able to also support cache consistent
parallelism.
since none of this was remotely mainframe oriented ... i guess you
must be referring to the mainframe trench created with the invention
of the compare&swap instruction and its deployment on 370 machines in
the early 70s ... which would then place all subsequent hardware
designs that implemented instruction and cache coherency semantics
similar to that of compare&swap semantics ... in the same trench???
Why so little parallelism?
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Subject: Re: Why so little parallelism?
Date: Thu, 09 Nov 2006 12:08:18 -0800
Newsgroups: comp.arch
Del Cecchi wrote:
We have disk drives because of them? Who does this refer to? Certainly
not CDC or Cray (company or man).
for the fun of it ... reference to old posting about original raid
patent (and other stuff)
http://www.garlic.com/~lynn/2006p.html#47 "25th Anniversary of the Personal Computer"
and for even more fun ... random postings from this year mentioning
misc disk history, disk design, disk enginneering, modeling air-bearing
effect for design of original thin-film floating heads, etc
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
http://www.garlic.com/~lynn/2006c.html#8 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006c.html#46 Hercules 3.04 announcement
http://www.garlic.com/~lynn/2006i.html#27 Really BIG disk platters?
http://www.garlic.com/~lynn/2006i.html#41 virtual memory
http://www.garlic.com/~lynn/2006j.html#11 The Pankian Metaphor
http://www.garlic.com/~lynn/2006k.html#57 virtual memory
http://www.garlic.com/~lynn/2006l.html#4 Google Architecture
http://www.garlic.com/~lynn/2006q.html#50 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006r.html#14 50th Anniversary of invention of disk drives
http://www.garlic.com/~lynn/2006r.html#15 50th Anniversary of invention of disk drives
http://www.garlic.com/~lynn/2006r.html#18 50th Anniversary of invention of disk drives
http://www.garlic.com/~lynn/2006r.html#20 50th Anniversary of invention of disk drives
http://www.garlic.com/~lynn/2006r.html#21 50th Anniversary of invention of disk drives
http://www.garlic.com/~lynn/2006r.html#23 50th Anniversary of invention of disk drives
http://www.garlic.com/~lynn/2006r.html#30 50th Anniversary of invention of disk drives
http://www.garlic.com/~lynn/2006r.html#31 50th Anniversary of invention of disk drives
http://www.garlic.com/~lynn/2006r.html#33 50th Anniversary of invention of disk drives
http://www.garlic.com/~lynn/2006r.html#36 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006s.html#23 Why magnetic drums was/are worse than disks ?
http://www.garlic.com/~lynn/2006s.html#30 Why magnetic drums was/are worse than disks ?
http://www.garlic.com/~lynn/2006s.html#32 Why magnetic drums was/are worse than disks ?
http://www.garlic.com/~lynn/2006s.html#42 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006s.html#45 Why magnetic drums was/are worse than disks ?
http://www.garlic.com/~lynn/2006s.html#59 Why magnetic drums was/are worse than disks ?
http://www.garlic.com/~lynn/2006t.html#18 Why magnetic drums was/are worse than disks ?
Why so little parallelism?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Date: Thurs, Nov 9 2006 7:13 pm
Subject: Re: Why so little parallelism?
Newsgroups: comp.arch
Jan Vorbrüggen wrote:
Yes. Or the thing TMC built - what was it called, The Data Vault?
old post by somebody from long ago and far away
Newsgroups: comp.arch
Subject: Re: *big iron*
Date: 28 Sep 89 18:12:07 GMT
Actually, the current DataVaults have 42 drives. Though the bus to
the DV is 64 bits wide, it is broken down into a 32-bit data path
inside the DV. There are 32 data drives, 7 ECC drives, and 3 hot
spares, each of which can be switched into any of the other 39
channels.
We also offer double-capacity DVs with 84 drives; no more bandwidth,
just a 2nd tier of drives off of each channel.
... snip ...
And the following for a lot more drift (although also mentioning
datavault) ....
some background on the Almaden reference can be found here:
http://www.almaden.ibm.com/StorageSystems/Past_Projects/TSM.shtml
which traces its history to CMSBACK which i had originally done more
than ten years earlier:
http://www.garlic.com/~lynn/2006t.html#20 Why these original FORTRAN quirks?; Now : Programming practices
http://www.garlic.com/~lynn/2006t.html#24 CMSBACK
we had funded part of the Unitree product work from our ha/cmp project
(aka reference to rft/lcmp):
http://www.garlic.com/~lynn/subtopic.html#hacmp
From: wheeler
Date: Fri, 8 Mar 91 17:55:16 EST
Subject: LANL Unitree meeting
We just got back from a joint LANL/LLNL/Discos/IBM meeting at Los
Alamos (we also had an earlier Unitree/IBM/ACSC meeting on Tuesday in
LA).
Partly purely as coincidence, on the flight down, I ran into xxxxxx
with two of his people on their way to Tucson to discuss the Almaden
workstation/pc backup/archive facility. It seems to be a coincidence
since one of the things brought up at the LANL meeting was a vendor
that has had a similar product (with a MVS backend) on the market. The
******* comment was that this vendor now has the product ported to an
Unitree (server) backend. Functions appear to be identical, providing
client registration with archive/backup policy requests that are then
scheduled (potentially offshift on a regular basis) ... with the
server "pulling" the files ... not the client pushing the files.
We discussed the RFT/LCMP enhancements for concurrent Unitree
operation on multiple server platforms (sharing same physical disk
drives). Also repeated some of the discussion that we had a couple
weeks ago with ******* research about some possible near-term
technology enhancements. Also has some discussion about the ANT stuff
that ****** did for Univ. of Mich. IFS system and the discussions that
have occured regarding all of their stuff on Unitree/RFTLCMP platform.
Including the advantages of having NFS, AFS3, AFS4 (and possibly other
protocols) all pointing to the SAME IEEE MSS-2 bitmap files. This
(along with automatic Unitree archiving facility) is also what many of
the other major customers are asking for with respect to Andrew/OSF.
We were able to come away pretty much addressing all of their
requirements except for a near-term tape backup for their connection
machine. The HIPPI D2 & tape-array products aren't yet on the
market ... so they have an interim solution that would utilize four
3490s driven in parallel as a logical tape array. Because of the
interim nature of the requirement, it didn't seem to be worthwhile to
address it with software in the RS/6000 (either via a RS/6000 adapter
card emulating 370 control unit or by one of the NSC A51x remote
device adapters ... its been going on eight years since I've done much
NSC A51x remote device programming).
The connection machine is writing data to the data vault (a box with
32-drive disk data array, 7 ECC drives, and 3 spare drives that are
electronically switchable into the configuration). The requirement is
to periodically back data from the data vault (out over the HIPPI
interface) to tape (files that are currently on the order of 10s of
gigabytes, but growing eventually to potentially terabytes).
The proposed solution is that LANL go ahead and write a 3490 parallel
tape driver for MVS that is a Unitree agent. Unitree (running on
rs/6000) would control all standard operations ... but there would be
a new feature added allowing data & control paths to be separated
... with a modified "high-performance" Unitree FTP program running on
the CM's SUN machine (CM external interfaces are controlled thru Sun
machines). It would talk to the Unitree RS/6000 server code, but
requesting parallel tape migration. The RS/6000 would notify the MVS
parallel tape agent ... and there would be a direct HIPPI data path
set up between the data vault to the MVS/3090 for actually moving the
data. In effect, the 3090/MVS system would be operating as a tape
controller for the Unitree/RS6000 system.
As another aside, ********* commented that Convex has given all of
their Unitree high-performance enhancements back to ******* for
incorporation into the standard product.
And for one of my favorite subjects ... that I also brought up when we
were dealing with the NCAR/Mesa possibilities ... was the significant
advantages of using a Semantic Net in the Unitree Nameserver (i.e.
effectively the function that implements the file directory).
******** and some of the other people wanted to specifically follow-up
on that. I related one of the things that we had looked at in the
NCAR/Mesa timeframe regarding all the NASA tapes containing images of
the back side of the moon ... and the difficulty in being able to find
any specific image &/or images that fit specific criteria.
... snip ... top of post, old email index
Why so little parallelism?
Refed: **, - **, - **, - **, - **
From: lynn@garlic.com
Subject: Re: Why so little parallelism?
Date: Thu, 09 Nov 2006 17:31:10 -0800
Newsgroups: comp.arch
Eugene Miya wrote:
This implies Convex was in UniTree's camp. Convex had their very
storage manager CSM which was not a bad system but never caught on.
Too bad it never got along past 2.0.
re:
http://www.garlic.com/~lynn/2006u.html#19 Why so little parallelism?
it wasn't a "camp" thing ... there was proposal from several of the
NSF funded supercomputing centers (CNSF, NCSA, PSC, SDSC) for NSF
funding for evaluation and selection of a common mass storage archive
solution .... which strongly leaned towards Unitree on Convex
platform. Just another one of those things that was happening in the
transition from strictly proprietary software to more open
environment.
We got pulled into situation to push unitree on rs6000 as an
alternative solution.
Why so little parallelism?
Refed: **, - **, - **
From: lynn@garlic.com
Subject: Re: Why so little parallelism?
Date: Thu, 09 Nov 2006 17:43:10 -0800
Newsgroups: comp.arch
Eugene Miya wrote:
Hey Tim Berners-Lee has taken that name now.
re:
http://www.garlic.com/~lynn/2006u.html#19 Why so little parallelism?
I did some of the original implementation (some 10+ years earlier than
the referenced email) ... about the same time that i also worked on
some of the original relational/sql implementation.
http://www.garlic.com/~lynn/subtopic.html#systemr
i've since gone thru a couple complete rewrites from scratch.
http://www.garlic.com/~lynn/index.html
it is what i use for my rfc index
http://www.garlic.com/~lynn/rfcietff.htm
and the merged taxonomies and glossaries
http://www.garlic.com/~lynn/index.html#glosnote
AOS: The next big thing in data storage
Refed: **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Subject: Re: AOS: The next big thing in data storage
Date: Fri, 10 Nov 2006 04:54:44 -0800
Newsgroups: alt.folklore.computers
Tina wrote:
AOS: The next big thing in data storage
Globalization has brought newer business challenges in the enterprise.
Issues like better corporate governance and compliance (be it
Sarbanes-Oxley in the US that requires timely and accurate financial
reporting, or Clause 49 in India) have taken the center stage.
Enterprises are coming under increased pressure to reduce operational
risks; increase business efficiency and create more business value.
http://www.technologyone.blogspot.com/2006/10/aos-next-big-thing-in-data-storage.html
a couple recent sox items:
Former Federal Reserve head riffs on Sarbanes-Oxley
http://www.infoworld.com/article/06/11/09/HNfrbripssarbox_1.html
Alan Greenspan riffs on Sarbanes-Oxley
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9004942&intsrc=hm_list
Sarbanes-Oxley Compliance
http://www.eweek.com/category2/0,1874,1573753,00.asp
and i've been doing my own riff on sox for over a year.
http://www.garlic.com/~lynn/2006.html#12a sox, auditing, finding improprieties
http://www.garlic.com/~lynn/aadsm25.htm#43 Audit Follies - Atlantic differences, branding UnTrust, thunbs on Sarbanes-Oxley, alternates
and then there is basel II and being able to do quantitative (in the
original draft also significant qualitative) documentation .... for
setting risk adjusted capital. misc. refs
http://www.garlic.com/~lynn/aadsm10.htm#smallpay3 Small/Secure Payment Business Models
http://www.garlic.com/~lynn/aadsm10.htm#cfppki19 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm14.htm#50 E-banking is board-level Issue, Says Basel Committee
http://www.garlic.com/~lynn/aadsm14.htm#52 Committee calls for better e-banking security management
http://www.garlic.com/~lynn/aadsm16.htm#7 The Digital Insider: Backdoor Trojans ... fyi
http://www.garlic.com/~lynn/aadsm21.htm#3 Is there any future for smartcards?
http://www.garlic.com/~lynn/aadsm25.htm#14 Sarbanes-Oxley is what you get when you don't do FC
http://www.garlic.com/~lynn/aadsm25.htm#15 Sarbanes-Oxley is what you get when you don't do FC
AOS: The next big thing in data storage
From: lynn@garlic.com
Subject: Re: AOS: The next big thing in data storage
Date: Fri, 10 Nov 2006 06:21:53 -0800
Newsgroups: alt.folklore.computers
Brian Inglis wrote:
It's pretty old suff, actually: 1988 4.3BSD for the IBM PC/RT
http://minnie.tuhs.org/Unix_History/aos
and a couple other posts from this year on aos
http://www.garlic.com/~lynn/2006.html#46 Free to good home: IBM RT UNIX
http://www.garlic.com/~lynn/2006b.html#8 Free to good home: IBM RT UNIX
http://www.garlic.com/~lynn/2006b.html#32 Multiple address spaces
http://www.garlic.com/~lynn/2006c.html#11 Mainframe Jobs Going Away
http://www.garlic.com/~lynn/2006g.html#13 News Release
http://www.garlic.com/~lynn/2006r.html#49 Seeking info on HP FOCUS (HP 9000 Series 500) and IBM ROMP CPUs from early 80's
... and as mentioned in the above ... aos actually started out as the
palo alto acis group doing a port of bsd to 370 ... i helped them find
a 370 C compiler for the port. when the port was retarged from 370 to
romp ... they kept the same C compiler (but had a different backend
implemented)
When did computers start being EVIL???
From: lynn@garlic.com
Subject: Re: When did computers start being EVIL???
Date: Fri, 10 Nov 2006 07:09:24 -0800
Newsgroups: alt.folklore.computers,alt.evil,alt.recipes.babies
Tim Shoppa wrote:
Even before that there was a sense of beauracracies being unable to
manage the complexity/scope/schedule/requirements of large computer
systems. There were at least a couple of big military-industrial
projects (FAA, SAGE, etc.) that had spun out of control and some
reining in was being done by the early 60's.
for a little different drift ... they are planning a wargames sequel:
http://www.moviehole.net/news/20061002_gillard_to_helm_wargames_2.html
http://www.themovieinsider.com/m537/wargames-2-the-dead-key/
a couple past posts mentioning wargames
http://www.garlic.com/~lynn/2003g.html#56 OT What movies have taught us about Computers
http://www.garlic.com/~lynn/2003g.html#57 OT What movies have taught us about Computers
http://www.garlic.com/~lynn/2006m.html#38 Computers in the movies
including mention of the scene where they were taking ferry out to some
island ... and what that ferry is doing now.
in the past, we worked with some of the people that were responsible
for pulling off the FAA 60's atc system. misc. past posts mentioning
atc and/or 9020 systems
http://www.garlic.com/~lynn/99.html#102 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
http://www.garlic.com/~lynn/99.html#103 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
http://www.garlic.com/~lynn/99.html#108 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
http://www.garlic.com/~lynn/2001h.html#15 IBM 9020 FAA/ATC Systems from 1960's
http://www.garlic.com/~lynn/2001h.html#17 IBM 9020 FAA/ATC Systems from 1960's
http://www.garlic.com/~lynn/2001h.html#71 IBM 9020 FAA/ATC Systems from 1960's
http://www.garlic.com/~lynn/2001i.html#2 Most complex instructions (was Re: IBM 9020 FAA/ATC Systems from 1960's)
http://www.garlic.com/~lynn/2001i.html#3 Most complex instructions (was Re: IBM 9020 FAA/ATC Systems from 1960's)
http://www.garlic.com/~lynn/2001i.html#14 IBM 9020 FAA/ATC Systems from 1960's
http://www.garlic.com/~lynn/2001i.html#15 IBM 9020 FAA/ATC Systems from 1960's
http://www.garlic.com/~lynn/2002g.html#2 Computers in Science Fiction
http://www.garlic.com/~lynn/2003m.html#4 IBM Manuals from the 1940's and 1950's
http://www.garlic.com/~lynn/2004.html#7 Dyadic
http://www.garlic.com/~lynn/2004l.html#49 "Perfect" or "Provable" security both crypto and non-crypto?
http://www.garlic.com/~lynn/2005e.html#57 System/360; Hardwired vs. Microcoded
http://www.garlic.com/~lynn/2005m.html#9 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2006q.html#54 Was FORTRAN buggy?
Universal constants: world wars
From: lynn@garlic.com
Subject: Re: Universal constants: world wars
Date: Fri, 10 Nov 2006 07:26:46 -0800
Newsgroups: alt.folklore.computers
Eugene Miya wrote:
Well it's amazing how Chuck was able to glean all those figures in
the Cold War. I just borrow George's copy every now and again.
Chuck used to live in Mountain View where I live, I think he's
further S now (easily web searchable). Pike would likely know.
slight cross over from somebody's reference in b.l.i
Collapsible business lessons
http://www.issurvivor.com/
from above:
Collapse: How Societies Choose to Fail or Succeed analyzes five ancient
societies that imploded horribly, attempting to find insights useful
for the modern, increasingly interconnected world.
....
Businesses being societies too, I thought it would be worthwhile trying
to apply Diamond's conclusions to the world of business (did you wonder
how I was going to justify the tax write-off for this book?
... snip ...
note that Boyd touched on similar parallels in his briefings
http://www.garlic.com/~lynn/subboyd.html#boyd
Assembler question
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Assembler question
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 11 Nov 2006 16:07:58 -0700
Alan_Altmark@ibm-main.lst (Alan Altmark) writes:
Since we, as a group, are unable to agree that XEDIT is the Best
Mainframe Editor Ever (just bait - don't take it), I don't see how
we will agree on what constitutes Good Programming. In any
language. We can all construct programs that everyone will agree
are just fine, and others everyone will agree are horrible.
Naturally the world is filled with programs and programmers that
live in the middle. Big deal. In fact, I HOPE we don't all agree.
If we did, then how would we grow as programmers?
now that you mention it ...
some email exchange with the RED author when i was trying to get
Endicott to release RED (in lieu of XEDIT). Later the Endicott
position was that it was the RED author's fault that he had
implemented RED before XEDIT and had put more features in RED than
were eventually implemented in XEDIT ... and therefore it was the
fault of the RED author that he had done something so bad ... it was
his duty to fixup XEDIT with the additional features that he had put
in RED.
From: wheeler
Date: 03/11/80 08:52:58
To: red author
I have a feeling that I may have done you a disservice. When I was in
Endicott last May I told them they ought to be putting out RED instead
of XEDIT. I went into a lot of detail about how it was faster, more
function, better, etc. (although other people may have also) and left
them with documentation. XEDIT is now announced and is going out.
Since last May they have gone over the RED documents and have added
several of the items to XEDIT but it still isn't as good (except maybe
in the feature of being able to use EXEC2 which would be common
between edit enviornment and others).
When I talked to several people from Endicott at the internal meeting
and Share, they sort of acknowledged the above. My suggestion that
they scrap XEDIT and put out RED was received very lightly. (ignoring
the fact that they should have put out RED instead of XEDIT) their
feeling is that it is the duty of the RED author to enhance XEDIT to
include all RED features. That really floored me, Endicott seems to
have some perverted view of reality. It isn't their fault they put out
XEDIT instead of RED, it is your fault that you put in more features
in RED than were in XEDIT.
... snip ... top of post, old email index
From: wheeler
Date: 03/12/80 09:26:53
To: red author
well, it is obviously your fault that RED has more function than
XEDIT. Since you are responsible for the problem then you should be
the one to rectify it.
... snip ... top of post, old email index
... and then from earlier, not functional, just performance numbers
*EDIT* is the old, cms standby; the first cp67/cms implementation was
strictly disk-to-disk work files ... but fairly quickly was enhanced
to take advantage of virtual memory for its operation.
From: wheeler
Date: 06/06/79 10:25:14
Those are interesting figures on editors ... but I figured that a
better measure of "internal peformance" would involve something more
strenuous than "bottom". So I did a "bottom" by doing a "c / / / * *"
with all seven editors, with the following results:
EDIT CMSLIB MACLIB S 2.53/2.81
RED CMSLIB MACLIB S (NODEF) 2.91/3.12
ZED CMSLIB MACLIB S 5.83/6.52
EDGAR CMSLIB MACLIB S 5.96/6.45
SPF CMSLIB MACLIB S ( WHOLE ) 6.66/7.52
XEDIT CMSLIB MACLIB S 14.05/14.88
NED CMSLIB MACLIB S 15.70/16.52
... snip ... top of post, old email index
recent post mentioning RED and another email
http://www.garlic.com/~lynn/2006n.html#55 The very first text editor
i use to do my own internal system release/distribution with lots of
fixes and enhancements ... bldgs 14&15 refers to the disk engineering
lab and disk product test lab ... misc. postings here
http://www.garlic.com/~lynn/subtopic.html#disk
From: wheeler
Date: 04/29/80 14:03:23
To: world-wide distribution list
current schedule is to ship PLC/LTR 8 CP system next Monday. All (new)
bugs have been identified and fixed. System is currently running in
building 14&15. It is scheduled to be brought up here either tomorrow
or the next day. CP changes includes some conversion to CSL20 & a
number of updates from the current STL release 6 updates. CMS will
include RED 3.4 & XEDIT.
It would be helpful if all locations outside of the San Jose area ship
me a tape and mailing label if possible.
... snip ... top of post, old email index
and one of the internal locations responding to request for forwarding
tape for SJR/VM distribution
From: RCHVM1 (somebody in rochester)
To: wheeler
Date: 05/01/80 12:13:41
Lynn - I just sent you a scratch tape today for CP6 - Thanks
... snip ... top of post, old email index
and for some total different drift on the subject of CMSBACK
http://www.garlic.com/~lynn/2006u.html#19 Why so little parallelism?
http://www.garlic.com/~lynn/2006u.html#21 Why so little parallelism?
... and
http://www.garlic.com/~lynn/2006t.html#24 CMSBACK
which then brings up this recent thread x-posted to alt.lang.asm & comp.arch
http://www.garlic.com/~lynn/2006t.html#45 To RISC or not to RISC
http://www.garlic.com/~lynn/2006t.html#46 To RISC or not to RISC
http://www.garlic.com/~lynn/2006t.html#47 To RISC or not to RISC
http://www.garlic.com/~lynn/2006t.html#48 To RISC or not to RISC
http://www.garlic.com/~lynn/2006u.html#15 To RISC or not to RISC
The following is part of an exchange with the author of RED regarding
creation of a RED shared module (read-only protected shared segment
executable image) on "PAM" disk.
To: wheeler
Date: 11/03/78 13:25:59
From: red author
Lynn,
I got your script file (i haven't read it yet). I couldn't follow
your msg about 64K blocks & what I could do with them. Please
amplify. I have done nothing toward making RED sharable, as it seems
to be a big job.
... snip ... top of post, old email index
I had original started on CMS paged mapped filesystem and shared segment
support with cp67/cms.
http://www.garlic.com/~lynn/subtopic.html#mmap
A very small subset of this function was picked up and released in
vm370 release 3 called DCSS. a few recent posts mentioning DCSS
http://www.garlic.com/~lynn/2006.html#17 {SPAM?} DCSS as SWAP disk for z/Linux
http://www.garlic.com/~lynn/2006.html#18 DCSS as SWAP disk for z/Linux
http://www.garlic.com/~lynn/2006.html#19 DCSS as SWAP disk for z/Linux
http://www.garlic.com/~lynn/2006.html#25 DCSS as SWAP disk for z/Linux
http://www.garlic.com/~lynn/2006.html#28 DCSS as SWAP disk for z/Linux
http://www.garlic.com/~lynn/2006m.html#53 DCSS
http://www.garlic.com/~lynn/2006m.html#54 DCSS
http://www.garlic.com/~lynn/2006m.html#56 DCSS
http://www.garlic.com/~lynn/2006q.html#27 dcss and page mapped filesystem
I had made small extension to control information generated by the cms
"GENMOD" command to include shared segment specifications. This was
automatically used by the cms "LOADMOD" function (when loading a cms
executable image) to map any specified shared segments. Aa part of the
original CMS shared segment changes, I had modified the standard cms
editor and several other routines to be able to execute in read-only
protected shared segment (this changes were included in some of those
picked up as part of DCSS release). This particular exchange with the
author of the RED editor was concerning modifying the RED executable
image to reside in a read-only protected shared segment. old discussion
changes to genmod/loadmod:
http://www.garlic.com/~lynn/2006o.html#53 The Fate of VM - was: Re: Baby MVS???
various collected posts about modifying and/or creating code for
residing in shared segments ... including issues with os/360
convention relocatable address constants creating difficulty for
allowing the same shared segment image to reside concurrently at
different virtual addresses in different virtual address spaces
(i.e. when i was modifying code to reside in read-only protected
shared segment, i also attempted to removed the execution location
dependencies ... most freqently involving os/360 convention
relocatable address constants)
http://www.garlic.com/~lynn/subtopic.html#adcon
A feature that RED editor added early was support for automatically
generating sources changes as CMS update files. When I was an
undergraduate starting out working on cp67/cms, i was making an large
number of source code changes as CMS update files. The CMS update
command convention was similar to IEBUPDATE, "./" replace, insert,
delete, etc, functions ... based on sequence numbers in the original
source file. However, the "new" source had to have the sequence
numbers manually keyed in cols. 73-80. This became quite tedious, so i
created the preprocessor convetion with $ field on the update "./"
control statements. I wrote a preprocessor to the CMS update command
that preprocessed a source update, stripped off the $ and generated
a temporary update working file with all the new source statements
with the sequence numbers automatically added.
The $ convention was later adopted by the multi-level source
update process that was created during the l/h/i effort ... joint
effort between science center and endicott to had 370 virtual
machine support co cp67 kernel (running on real 360/67). recent
posting about that effort:
http://www.garlic.com/~lynn/2006u.html#7 The Future of CPUs: What's After Multi-Core?
eventually the $ field support was merged into the standard CMS
update command (rather than being done separately by pre-processing
function) ... and still later, CMS editors provided direct support for
both applying multi-level updates as part of edit invokation and
generating update files from source changes. misc. past posts discussing
the $ field convention:
http://www.garlic.com/~lynn/2002n.html#39 CMS update
http://www.garlic.com/~lynn/2004b.html#59 A POX on you, Dennis Ritchie!!!
http://www.garlic.com/~lynn/2004g.html#43 Sequence Numbbers in Location 73-80
http://www.garlic.com/~lynn/2005i.html#30 Status of Software Reuse?
http://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2006n.html#45 sorting
Why so little parallelism?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why so little parallelism?
Newsgroups: comp.arch
Date: Sun, 12 Nov 2006 00:27:30 -0700
eugene@cse.ucsc.edu (Eugene Miya) writes:
Sure it was a camp.
These guys were Cray sites who went along with the DOE's CTSS OS and
UniTree as an afterthought. So when Unicos came along and CTSS was not
portable enough it left CTSS basically dead.
I'm sorry, i misunderstood your original comment to be referring to
convex being part of some "camp" vis-a-vis their own proprietrary
solution ... and i thot i was replying that it was my impression that
it wasn't a "camp" thing for convex ... it was something that some
customers may have wanted to use with convex ... and convex was
responding to something their customers wanted.
i didn't mean to imply that there weren't a number of solutions and that
customers might be choosing particular solutions ... and then the
customers might be have preferrences for one solution or another
("camp" if you will) ... aka
http://www.garlic.com/~lynn/2006u.html#20 Why so little parallelism?
where:
Eugene Miya wrote:
This implies Convex was in UniTree's camp. Convex had their very
storage manager CSM which was not a bad system but never caught on.
Too bad it never got along past 2.0.
i was trying to distinquish between the customers may have wanted
something on a convex platform ... vis-a-vis convex taking a position
possibly with respect to what their customers should want. i wouldn't
view convex cooperating with their customers as to a particular
solution necessarily meaning that it was a "camp"/membership thing for
convex (and didn't mean to imply anything at all about whether or
not it might or might not be a "camp" thing for the customers).
for other drift from
http://www.garlic.com/~lynn/2006u.html#19 Why so little parallelism?
....
From: wheeler
Date: Thu Apr 16 11:11:41 1992
Subject: Re: Archiving on large systems
Unitree(/lincs) is basically one of the four that all evolved around
the same time. The other three being CFS(LLNL), Mesa(NCAR), and
NAStore .... reference:
Newsgroups: comp.unix.large
Date: 15 Apr 92 19:18:07 GMT
As it was mentioned in an earlier posting, let me add a couple of
words on NAStore.
NAStore is a system to provide a Unix based, network connected file
system with the appearence of unlimited storage capacity. The system
was designed and developed at NASA Ames Research Center for the
Numerical Aerodynamic Simulation program. The goal was to provide
seemingly unlimited file space via transparent archival (or migration)
of files to removable media (3480 tapes) in both robotic and manual
handlers. Supported files sizes exceed the 2 gigabyte limit on most
systems. Archived data is restored when accessed by the user with
each byte being available as soon as it is restored rather than having
to wait for the whole file as is the case with other archival systems.
The NAStore system has been used here for 3 years and is under ongoing
development. It is based upon Amdahl's UTS and runs upon an Amdahl
5880. We have 200 gigabytes of on-line disk and 6 terabytes of
robotic tape.
If your care for more information, let me suggest the following reading:
1989 Winter Usenix Conference Proceedings, see the article on RASH
the last IEEE Mass Storage Symposium proceedings
If you are still interested, contact Dave Tweten, e-mail tweten@nas.nasa.gov
... snip ... top of post, old email index
past posts mentioning one or more of the four
http://www.garlic.com/~lynn/2001.html#21 Disk caching and file systems. Disk history...people forget
http://www.garlic.com/~lynn/2001.html#22 Disk caching and file systems. Disk history...people forget
http://www.garlic.com/~lynn/2001f.html#66 commodity storage servers
http://www.garlic.com/~lynn/2002.html#10 index searching
http://www.garlic.com/~lynn/2002e.html#46 What goes into a 3090?
http://www.garlic.com/~lynn/2002g.html#61 GE 625/635 Reference + Smart Hardware
http://www.garlic.com/~lynn/2003b.html#29 360/370 disk drives
http://www.garlic.com/~lynn/2003b.html#31 360/370 disk drives
http://www.garlic.com/~lynn/2003h.html#6 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003i.html#53 A Dark Day
http://www.garlic.com/~lynn/2004d.html#75 DASD Architecture of the future
http://www.garlic.com/~lynn/2004g.html#26 network history
http://www.garlic.com/~lynn/2004p.html#29 FW: Is FICON good enough, or is it the only choice we get?
http://www.garlic.com/~lynn/2005e.html#12 Device and channel
http://www.garlic.com/~lynn/2005e.html#15 Device and channel
http://www.garlic.com/~lynn/2005e.html#16 Device and channel
http://www.garlic.com/~lynn/2005e.html#19 Device and channel
http://www.garlic.com/~lynn/2006n.html#29 CRAM, DataCell, and 3850
http://www.garlic.com/~lynn/2006t.html#37 Are there more stupid people in IT than there used to be?
Assembler question
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Assembler question
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sun, 12 Nov 2006 09:14:11 -0700
Brian Inglis <Brian.Inglis@SystematicSW.Invalid> writes:
Most systems seem to have come with more than one editor. Each
editor does some things better than others. People have different
things they do with editors and can pick the one that does their
task best. Why have IBM mainframe systems stuck to the single
systems product editor approach?
re:
http://www.garlic.com/~lynn/2006u.html#26 Assembler question
one might conjecture that it might have something to do with internal
wars that frequently verged on the religious and being able of all
parties to escalate to a higher authority.
EDGAR was the first cms fullscreen editor (that made it out as a
product) ... other than the minor enhancements to the original cms
(line) editor. there then were/came a whole slew of internal editors
that had all sorts of fullscreen features and scripting/macro
capabilities. then came the wars to see which one would be announced
as the (corporate) product ... with the EDGAR faction attempting to
protect their initial position ... and many of the others all jockying
for permission to be announced. Once one had achieved that permission
... then there was constant ongoing battles to stifle any competition.
To some extent, similar wars went on with regard to communication and
networking activity ... as mentioned in various of my comments about
the later days of terminal emulation
http://www.garlic.com/~lynn/subnetwork.html#emulation
and the SAA related activity ... with us on the other end with 3-tier
architecture
http://www.garlic.com/~lynn/subnetwork.html#3tier
and hsdt activity
http://www.garlic.com/~lynn/subnetwork.html#hsdt
and even my wife's much earlier efforts with AWP39 and her other
peer-to-peer stuff when she was in POK in charge of loosely-coupled
architecture
http://www.garlic.com/~lynn/subtopic.html#shareddata
there was also quite a bit of it between the established ("60s")
databases and the original relational/sql effort ... getting it out
and announced as a product
http://www.garlic.com/~lynn/subtopic.html#systemr
even the virtual machine effort, cp67 and vm370 (including cms), had a
nearly constant cloud hanging over them of being terminated because of
being declared "non-strategic" (and competitive) by the "mainstream"
operating system. i've mentioned before the vm370 development group
being periodically told they had made their last product shipment and
their last release. At one point, the whole vm370 product group
location (in burlington mall) was shutdown, and everybody told that
they had to move to POK where everybody would be supporting mvs/xa
development (and one more time, there would be no more virtual machine
operating system).
To RISC or not to RISC
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: To RISC or not to RISC
Newsgroups: alt.lang.asm,comp.arch
Date: Sun, 12 Nov 2006 09:26:14 -0700
"Dunny" <paul.dunn4@ntlworld.com> writes:
Kind of, as I understand it JIT is a process of interpretation which blends
in commonly-executed code chunks as native blocks - a kind of cache. This
behaviour makes it much faster than simple interpretation, but still not as
fast as native code.
I remember this sort of trade-off first being looked at circa 1980
with fort knox. the low/mid range 360/370 had all been implemented in
microcode ... with nearly every model having a completely different
microcode engine. 801/risc was being proposed as a common architecture
to replace the large numbers of microprocessors in use by the
corporation. there then was efforts to look at various JIT techniques
as part of the transition to 801/risc. this effort eventually
floundered for one reason or another ... although the claim could be
made that it sort of re-emerged with the transition of the as/400 from
a cisc engine to a powerpc engine. misc. 801, risc, power, somerset,
etc postings
http://www.garlic.com/~lynn/subtopic.html#801
we had done something earlier in 1975 with ecps ... were major
pathlengths in the (virtual machine) kernel (6000 bytes of code
accounting for something like 70percent of kernel pathlength) was
(statically) recoded in native microcode getting a 10:1 performance
improvement. a few old posts mentioning ecps
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist
http://www.garlic.com/~lynn/94.html#27 370 ECPS VM microcode assist
http://www.garlic.com/~lynn/94.html#28 370 ECPS VM microcode assist
http://www.garlic.com/~lynn/2003f.html#43 ECPS:VM DISPx instructions
http://www.garlic.com/~lynn/2003f.html#47 ECPS:VM DISPx instructions
http://www.garlic.com/~lynn/2003f.html#52 ECPS:VM DISPx instructions
http://www.garlic.com/~lynn/2003f.html#54 ECPS:VM DISPx instructions
http://www.garlic.com/~lynn/2003f.html#56 ECPS:VM DISPx instructions
Why so little parallelism?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why so little parallelism?
Newsgroups: comp.arch
Date: Sun, 12 Nov 2006 09:55:16 -0700
eugene@cse.ucsc.edu (Eugene Miya) writes:
I wonder how the storage war is going to shape up?
Will tape really die as Jim Gray predicts or will tape drives be
relgated to data retrieval devices or one last read off tape?
re:
http://www.garlic.com/~lynn/2006u.html#19 Why so little parallelism
the many times descendent of CMSBACK that i originally implemented and
deployed in the late 70s ... also referenced here
http://www.garlic.com/~lynn/2006t.html#20 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006t.html#24 CMSBACK
http://www.almaden.ibm.com/StorageSystems/Past_Projects/TSM.shtml
has multiple levels that don't need to touch tape at all.
some general collected posts mentioning that activity
http://www.garlic.com/~lynn/subtopic.html#backup
and product page
http://www-306.ibm.com/software/tivoli/products/storage-mgr/
part of the tape issue is packaging/density/convenience/cost ... for
some things datacenter and transmission costs have been reduced to the
point where it is cost effective to have a hot remote/redundant sites
... as opposed to disaster/recovery dependent on offsite backup tapes.
when we were doing our ha/cmp product
http://www.garlic.com/~lynn/subtopic.html#hacmp
we coined the term disaster survivability and geographic survivability
for concurrent operation of remote/redundant sites.
http://www.garlic.com/~lynn/subtopic.html#available
part of this had been outlined by my wife when she had done
peer-coupled shared data architecture when she served her stint in pok
in charge of loosely-coupled architecture.
http://www.garlic.com/~lynn/subtopic.html#shareddata
at that time, she saw very little uptake ... except for the IMS
(database) group for IMS hot standby. not that long ago, we were
talking to one of the major financial transaction operations and they
attributed their 100percent availability over a span of years to
• automated operator
• ims hot standby
where they had triple redundant/remote dataprocessing sites.
misc. past posts mentioning ims hot standby
http://www.garlic.com/~lynn/98.html#35a Drive letters
http://www.garlic.com/~lynn/98.html#37 What is MVS/ESA?
http://www.garlic.com/~lynn/99.html#71 High Availabilty on S/390
http://www.garlic.com/~lynn/99.html#77 Are mainframes relevant ??
http://www.garlic.com/~lynn/99.html#92 MVS vs HASP vs JES (was 2821)
http://www.garlic.com/~lynn/99.html#128 Examples of non-relational databases
http://www.garlic.com/~lynn/2000.html#13 Computer of the century
http://www.garlic.com/~lynn/2000f.html#54 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2001d.html#71 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001k.html#13 HP-UX will not be ported to Alpha (no surprise)exit
http://www.garlic.com/~lynn/2001k.html#14 HP-UX will not be ported to Alpha (no surprise)exit
http://www.garlic.com/~lynn/2001k.html#18 HP-UX will not be ported to Alpha (no surprise)exit
http://www.garlic.com/~lynn/2002o.html#14 Home mainframes
http://www.garlic.com/~lynn/2002p.html#54 Newbie: Two quesions about mainframes
http://www.garlic.com/~lynn/2003l.html#11 how long does (or did) it take to boot a timesharing system?
http://www.garlic.com/~lynn/2004.html#40 AMD/Linux vs Intel/Microsoft
http://www.garlic.com/~lynn/2004m.html#46 Shipwrecks
http://www.garlic.com/~lynn/2004q.html#75 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005d.html#9 intel's Vanderpool and virtualization in general (was Re: Cell press release, redacted.)
http://www.garlic.com/~lynn/2005n.html#7 54 Processors?
http://www.garlic.com/~lynn/2006q.html#26 garlic.com
To RISC or not to RISC
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: To RISC or not to RISC
Newsgroups: alt.lang.asm,comp.arch
Date: Sun, 12 Nov 2006 13:30:18 -0700
"mike" <mike@mike.net> writes:
On both CISC and RISC versions of the AS/400 - Series i all programs
are first converted to an intermediate "W" code which common to the
high level virtual machine of all models. W code is then compiled,
with optimization, to the physical processor instruction set. The
full list of W code is stored along with the actual hardware specific
executable to allow re-compiles as needed. This is how the same
"program object" can run with reasonable efficiency on the 16 bit
Sys/38 the original 32 bit CISC /400 and the latest 64 bit Power
processor. This is not much like JIT.
re:
http://www.garlic.com/~lynn/2006u.html#29 To RISC or not to RISC
it was topic drift ... i didn't claim that the final move of as/400
from cisc to risc was like jit ... i claimed jit was like some of the
stuff that went on for fort knox in the 1980 time-frame ... and that
parenthetically, the (much later) conversion of as/400 from cisc to
risc met some of the original objectives of fort knox ... i.e. moving
to risc based processor (but I didn't claim that the movement of
as/400 from cisc to risc used any of the earlier jit-like stuff that
went on in the 1980 fort knox time-frame ... which were much more
specifically related to 360/370).
however, in the 1980 time-frame for fort knox, the rochester
microprocessor was one of the targets for switch-over to 801 (even if
none of the jit-related activity may have been involved in any of the
possible conversion of rochester microprocessor to 801).
it wouldn't have been directly applicable to as/400 in any case,
since as/400 wasn't introduced until 1988, long after fort knox
effort had been killed ... wiki entry for as/400
http://en.wikipedia.org/wiki/AS/400
references mentioning that fort knox eventually at least partially
succeeded with the as/400 risc
http://www.itjungle.com/tfh/tfh042902-story07.html
and more detail here about fort knox objectives (including more
than rochester microprocessors)
http://www.riteapproach.com/book/ibm.html
for misc. other background ... i had been doing some work with the los
gatos vlsi lab (bldg. 29) in the fort knox time-frame. they were
doing a 32-bit 801 (blue iliad) design (that never shipped). they also
had two people doing a 370 pascal compiler for use in developing
various chip design tools (and which eventually shipped first as the
pascal iup ... and then as the vs/pascal compiler).
i had also written a pli program in the early 70s that analyzed
(360/370) assembler program listings ... creating high level
abstractions of the instructions, recreating control flow, register
useage ... looking for use before set type scenarios ... and generated
a high level psuedo code representation of the assembler program.
some of the people looking at possibly jit-type operations applied to
370 code (using 801 for the followon for 4331/4341) contacted me about
my program ... possibly enabling them to use some of it for what they
were doing (at the time, the primary 801 programming language was
pl.8, a subset of pli). recent posts discussing some of this with
regard to 360/370
http://www.garlic.com/~lynn/2006p.html#4 Greatest Software Ever Written?
http://www.garlic.com/~lynn/2006r.html#24 A Day For Surprises (Astounding Itanium Tricks)
and for the other drift about the 370 pascal compiler, one of the
people in bldg. 29 doing the 370 pascal compiler left and became head
of software at MIPs. after MIPs was bought by SGI, he shows up as
general manager of the SUN business unit that includes JAVA.
the article here
http://www.riteapproach.com/book/ibm.html
even makes reference to 370 emulation on intel platforms ... raised
in this thread:
http://www.garlic.com/~lynn/2006u.html#16 IA64 and emulator performance
... some of which, I believe may have also implemented JIT technology.
for other drift ... doing search engine for as/400 and fort knox also
turns up this article
http://www.cbronline.com/article_cbr.asp?guid=2C99DD1B-6812-46AF-AF95-B6D7E728376A
from above:
The failed Fort Knox project of the early 1980s, meanwhile,
attempted to merge IBM's low-end mainframe and midrange minicomputer
lines into a single family that ran on a variant of IBM's first RISC
processor, the 801.
Many of the architectural ideas behind Fort Knox ended up in the S/38
and AS/400 lines, and those ideas - such as a high-level machine
interface that separates hardware from the operating system (OS) -
have allowed the IBM midrange to be extended for two decades while
providing application software compatibility.
... snip ...
the second paragraph appears to confuse Future System
http://www.garlic.com/~lynn/subtopic.html#futuresys
from the early to mid 70s ... with Fort Knox from 1980 period.
There is lots of folklore that concepts from the failed/canceled
Future System project did show up in S/38 (which predates Fort Knox).
wiki s/38 (introduced in 1978) article
http://en.wikipedia.org/wiki/System/38
For other topic drift, when we were doing ha/cmp product
http://www.garlic.com/~lynn/subtopic.html#hacmp
the executive we reported to, left to head up somerset ... the effort
to take power/801 and do the power/pc (he later left that to become
president of MIPs).
predating somerset/powerpc effort was design for 64bit 801/power
... that went on in conjunction with rochester. however, there was
quite a bit of argument with rochester over the 65th bit ... a
tag-line that they wanted to use for implementing s38/as400 storage
access feature.
and collection of posts mentioning 801, romp, rios, power, power/ps,
somerset, fort knox, etc.
http://www.garlic.com/~lynn/subtopic.html#801
To RISC or not to RISC
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: To RISC or not to RISC
Newsgroups: alt.lang.asm,comp.arch
Date: Sun, 12 Nov 2006 14:24:18 -0700
Anne & Lynn Wheeler <lynn@garlic.com> writes:
even makes reference to 370 emulation on intel platforms ... raised
in this thread:
http://www.garlic.com/~lynn/2006u.html#16 IA64 and emulator performance
... some of which, I believe may have also implemented JIT technology.
re:
http://www.garlic.com/~lynn/2006u.html#29 To RISC or not to RISC
http://www.garlic.com/~lynn/2006u.html#31 To RISC or not to RISC
for even more drift ... recent post
http://www.garlic.com/~lynn/2006p.html#42 old hypervisor email
includes some old email from fort knox days
http://www.garlic.com/~lynn/2006p.html#email801121
above email makes mention to one of the people working on various 801
projects, who then left and went on to work on risc at HP and was
later one of the itanium architects.
and these posts
http://www.garlic.com/~lynn/2003e.html#64 801 (was Re: Reviving Multics)
http://www.garlic.com/~lynn/2006t.html#9 32 or even 64 registers for x86-64?
has copies of some number of old 801 related email ... including email
asking about my PLI program for analyzing assembler listings
http://www.garlic.com/~lynn/2006t.html#email811104
and they were looking at both static translation to 801 .. akin to the
previously mentioned ECPS ... and doing the course of discussion,
JIT-like activity was raised.
Assembler question
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Assembler question
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 13 Nov 2006 08:29:20 -0700
Steve_Thompson_TW@STERCOMM.COM (Thompson, Steve , SCI TW) writes:
But as I said in a prior posting, ALC is a low level language. So
perhaps those of us that have programmed in it for years just think
quite differently (I started on S/360 machines). Don't get me wrong, I
am not interested in GATE/TEST coding -- Macrocode at Amdahl was close
enough to the bare metal.
re:
http://www.garlic.com/~lynn/2006u.html#26 Assembler question
http://www.garlic.com/~lynn/2006u.html#27 Assembler question
for a little different drift, thread that drifts into a program that I
wrote in the early 70s for analyzing 360/370 assembler listings
(creating abstract representation of the instructions, instruction
flow, doing used-before-set analysis on registers, etc) ...
http://www.garlic.com/~lynn/2006u.html#29 To RISC or not to RISC
http://www.garlic.com/~lynn/2006u.html#31 To RISC or not to RISC
http://www.garlic.com/~lynn/2006u.html#32 To RISC or not to RISC
this came up in connection with project that was going to migrate the
plethora of internal microprocessors to 801/risc (including ones used
in low & mid range 370s) ... and the possibility that they might use
some JIT technology ... a dynamic alternative to things like were done
for ECPS (statically migrate high-use kernel pathlength into
microcode).
for other drift ... past posts (& even some really old email)
mentioning amdahl macrocode
http://www.garlic.com/~lynn/2002p.html#44 Linux paging
http://www.garlic.com/~lynn/2002p.html#48 Linux paging
http://www.garlic.com/~lynn/2003.html#9 Mainframe System Programmer/Administrator market demand?
http://www.garlic.com/~lynn/2003.html#56 Wild hardware idea
http://www.garlic.com/~lynn/2005d.html#59 Misuse of word "microcode"
http://www.garlic.com/~lynn/2005d.html#60 Misuse of word "microcode"
http://www.garlic.com/~lynn/2005h.html#24 Description of a new old-fashioned programming language
http://www.garlic.com/~lynn/2005p.html#14 Multicores
http://www.garlic.com/~lynn/2005p.html#29 Documentation for the New Instructions for the z9 Processor
http://www.garlic.com/~lynn/2005u.html#40 POWER6 on zSeries?
http://www.garlic.com/~lynn/2005u.html#43 POWER6 on zSeries?
http://www.garlic.com/~lynn/2005u.html#48 POWER6 on zSeries?
http://www.garlic.com/~lynn/2006b.html#38 blast from the past ... macrocode
http://www.garlic.com/~lynn/2006c.html#9 Mainframe Jobs Going Away
http://www.garlic.com/~lynn/2006j.html#32 Code density and performance?
http://www.garlic.com/~lynn/2006j.html#35 Code density and performance?
http://www.garlic.com/~lynn/2006m.html#39 Using different storage key's
http://www.garlic.com/~lynn/2006p.html#42 old hypervisor email
Assembler question
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Assembler question
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 13 Nov 2006 09:27:16 -0700
m42tom-ibmmain@ibm-main.lst (Tom Marchant) writes:
Macrocode was coded in assembler. It was very similar to millicode on
z/Architecture.
re:
http://www.garlic.com/~lynn/2006u.html#26 Assembler question
http://www.garlic.com/~lynn/2006u.html#27 Assembler question
http://www.garlic.com/~lynn/2006u.html#33 Assembler question
old email from somebody that I worked with on ecps ... discussing
macrocode (he mentions that he had wanted to do something similar for
quite a while)
http://www.garlic.com/~lynn/2006p.html#42 old hypervisor email
more old email discussing 5880 announcement
http://www.garlic.com/~lynn/2006b.html#38 blast from the past ... macrocode
Friday fun - Discovery on the pad and the software's not done
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Friday fun - Discovery on the pad and the software's not done
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 13 Nov 2006 11:45:38 -0700
lists@AKPHS.COM (Phil Smith III) writes:
This is fairly OT, but the key graf is:
"When the shuttle's flight control software was developed in the
1970s, NASA managers did not envision the possibility of flying
missions during the transition from one year to the next. Internal
clocks, instead of rolling over to Jan. 1, 2007, would simply keep
counting up, putting them at odds with navigation systems on the
ground."
recent thread:
http://www.garlic.com/~lynn/2006u.html#13 Year-end computer bug could ground Shuttle
http://www.garlic.com/~lynn/2006u.html#14 Year-end computer bug could ground Shuttle
this is part of (somebody's) old email from 1984 (discussing a number
of calender roll-over problems):
3. We have an interesting calendar problem in Houston. The Shuttle
Orbiter carries a box called an MTU (Master Timing Unit). The MTU
gives yyyyddd for the date. That's ok, but it runs out to ddd=400
before it rolls over. Mainly to keep the ongoing orbit calculations
smooth. Our simulator (hardware part) handles a date out to ddd=999.
Our simulator (software part) handles a date out to ddd=399. What we
need to do, I guess, is not ever have any 5-week long missions that
start on New Year's Eve. I wrote a requirements change once to try to
straighten this out, but chickened out when I started getting odd
looks and snickers (and enormous cost estimates).
... snip ...
where they anticipated roll-over ... but original equipment extended
days in the year out past the end of the year (however, inconsistently
as mentioned to 399, 400, and 999 days).
the issue now appears to be that since 1984, some of the equipment
may have been upgraded to more COTS products ... and which just does
standard roll-over at the end of the year.
the complete copy of the old email was posted in an old y2k thread:
http://www.garlic.com/~lynn/99.html#24 BA Solves Y2K (Was: Re: Chinese Solve Y2K)
http://www.garlic.com/~lynn/2000.html#94 Those who do not learn from history...
http://www.garlic.com/~lynn/2003p.html#21 Sun researcher