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 acknowledgments
waiting for acknowledgments
waiting for acknowledgments
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)
https://www.garlic.com/~lynn/2002k.html#18 Unbelievable
https://www.garlic.com/~lynn/2002k.html#19 Vnet : Unbelievable
https://www.garlic.com/~lynn/2002k.html#20 Vnet : Unbelievable
https://www.garlic.com/~lynn/2002k.html#21 Vnet : Unbelievable
https://www.garlic.com/~lynn/2002k.html#22 Vnet : Unbelievable
https://www.garlic.com/~lynn/2002k.html#23 Vnet : Unbelievable
https://www.garlic.com/~lynn/2002k.html#26 DEC eNet: was Vnet : Unbelievable

and the thread from last spring:
https://www.garlic.com/~lynn/2006j.html#34 Arpa address
https://www.garlic.com/~lynn/2006j.html#43 virtual memory
https://www.garlic.com/~lynn/2006j.html#45 Arpa address
https://www.garlic.com/~lynn/2006j.html#46 Arpa address
https://www.garlic.com/~lynn/2006j.html#49 Arpa address
https://www.garlic.com/~lynn/2006j.html#50 Arpa address
https://www.garlic.com/~lynn/2006j.html#53 Arpa address
https://www.garlic.com/~lynn/2006k.html#1 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006k.html#3 Arpa address
https://www.garlic.com/~lynn/2006k.html#6 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006k.html#8 Arpa address
https://www.garlic.com/~lynn/2006k.html#9 Arpa address
https://www.garlic.com/~lynn/2006k.html#10 Arpa address
https://www.garlic.com/~lynn/2006k.html#31 PDP-1
https://www.garlic.com/~lynn/2006k.html#32 PDP-1
https://www.garlic.com/~lynn/2006k.html#40 Arpa address
https://www.garlic.com/~lynn/2006k.html#42 Arpa address
https://www.garlic.com/~lynn/2006k.html#43 Arpa address
https://www.garlic.com/~lynn/2006k.html#53 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006k.html#56 Hey! Keep Your Hands Out Of My Abstraction Layer!

and the current thread:
https://www.garlic.com/~lynn/2006t.html#27 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006t.html#31 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006t.html#32 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006t.html#34 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006t.html#36 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006t.html#41 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006t.html#42 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006t.html#43 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006t.html#49 The Future of CPUs: What's After Multi-Core?
https://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
https://www.garlic.com/~lynn/submain.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
https://www.garlic.com/~lynn/2004b.html#45 Foiling Replay Attacks
https://www.garlic.com/~lynn/2003m.html#50 public key vs passwd authentication
https://www.garlic.com/~lynn/2003m.html#51 public key vs passwd authentication
https://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
https://www.garlic.com/~lynn/2006u.html#3 ssh - password control or key control?

and the other posts:
https://www.garlic.com/~lynn/2004b.html#45 Foiling Replay Attacks
https://www.garlic.com/~lynn/2003m.html#50 public key vs passwd authentication
https://www.garlic.com/~lynn/2003m.html#51 public key vs passwd authentication
https://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.
https://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
https://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
https://www.garlic.com/~lynn/subpubkey.html#kerberos

as mentioned in some of the original referenced posts on s/key attacks, my rfc index:
https://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)
https://www.garlic.com/~lynn/2006u.html#3 ssh - password control or key control?
https://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
https://www.garlic.com/~lynn/2001d.html#51 A beautiful morning in AFM.
https://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
https://www.garlic.com/~lynn/subintegrity.html#3factor
something you havesomething you knowsomething 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:
https://www.garlic.com/~lynn/2006t.html#36 The Future of CPUs: What's After Multi-Core
https://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
https://www.garlic.com/~lynn/2003c.html#42 difference between itanium and alpha
https://www.garlic.com/~lynn/2003c.html#47 difference between itanium and alpha
https://www.garlic.com/~lynn/2003d.html#60 Bitnet again was: unix
https://www.garlic.com/~lynn/2003d.html#62 ARPAnet again: Bitnet again was: unix
https://www.garlic.com/~lynn/2003h.html#17 Why did TCP become popular ?
https://www.garlic.com/~lynn/2004o.html#53 360 longevity, was RISCs too close to hardware?
https://www.garlic.com/~lynn/2006e.html#35 The Pankian Metaphor
https://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:
https://www.garlic.com/~lynn/2006t.html#36 The Future of CPUs: What's After Multi-Core
https://www.garlic.com/~lynn/2006u.html#0 The Future of CPUs: What's After Multi-Core
https://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
https://www.garlic.com/~lynn/subnetwork.html#internalnet

was between the science center, on the 4th flr, 545 tech sq
https://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

https://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.
https://www.garlic.com/~lynn/2002j.html#0 HONE was .. Hercules and System/390 - do we need it?
https://www.garlic.com/~lynn/2004b.html#31 determining memory size
https://www.garlic.com/~lynn/2004p.html#50 IBM 3614 and 3624 ATM's
https://www.garlic.com/~lynn/2005c.html#59 intel's Vanderpool and virtualization in general
https://www.garlic.com/~lynn/2005d.html#66 Virtual Machine Hardware
https://www.garlic.com/~lynn/2005g.html#17 DOS/360: Forty years
https://www.garlic.com/~lynn/2005h.html#18 Exceptions at basic block boundaries
https://www.garlic.com/~lynn/2005i.html#39 Behavior in undefined areas?
https://www.garlic.com/~lynn/2005j.html#50 virtual 360/67 support in cp67
https://www.garlic.com/~lynn/2005p.html#27 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
https://www.garlic.com/~lynn/2006e.html#7 About TLB in lower-level caches
https://www.garlic.com/~lynn/2006f.html#5 3380-3390 Conversion - DISAPPOINTMENT
https://www.garlic.com/~lynn/2006l.html#21 Virtual Virtualizers
https://www.garlic.com/~lynn/2006m.html#26 Mainframe Limericks
https://www.garlic.com/~lynn/2006o.html#19 Source maintenance was Re: SEQUENCE NUMBERS
https://www.garlic.com/~lynn/2006q.html#1 Materiel and graft
https://www.garlic.com/~lynn/2006q.html#45 Was FORTRAN buggy?
https://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:
https://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
https://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 ibm/pc.

as you mentioned in your other post ... are we talking 70s or 80s?
https://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:
https://www.garlic.com/~lynn/2006t.html#42 The Future of CPUs: What's After Multi-Core?
https://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

Date: 31 Mar 88 21:43:52 GMT
To: wheeler

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 RAINBOW".

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:
https://www.garlic.com/~lynn/2006t.html#42 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006u.html#8 The Future of CPUs: What's After Multi-Core?
https://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.

Date: 05 Feb 88 18:12:41 GMT
To: wheeler

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:
https://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:
https://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
https://www.garlic.com/~lynn/99.html#24 BA Solves Y2K (Was: Re: Chinese Solve Y2K)
https://www.garlic.com/~lynn/2000.html#94 Those who do not learn from history...
https://www.garlic.com/~lynn/2003p.html#21 Sun researchers: Computers do bad math ;)
https://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:
https://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:
https://www.garlic.com/~lynn/2006t.html#45 To RISC or not to RISC
https://www.garlic.com/~lynn/2006t.html#46 To RISC or not to RISC
https://www.garlic.com/~lynn/2006t.html#47 To RISC or not to RISC
https://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 ... theoretically 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
https://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
https://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
https://www.garlic.com/~lynn/subtopic.html#smp
and
https://www.garlic.com/~lynn/submain.html#bounce

it is not theoretically 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.
https://www.garlic.com/~lynn/subtopic.html#801

collected past posts mentioning the large variety of internal microproprocessors and low-level microcoding
https://www.garlic.com/~lynn/submain.html#mcode

misc. past posts mentioning hercules
https://www.garlic.com/~lynn/2001n.html#22 Hercules, OCO, and IBM missing a great opportunity
https://www.garlic.com/~lynn/2001n.html#31 Hercules etc. IBM not just missing a great opportunity...
https://www.garlic.com/~lynn/2001n.html#32 Hercules etc. IBM not just missing a great opportunity...
https://www.garlic.com/~lynn/2001n.html#34 Hercules etc. IBM not just missing a great opportunity...
https://www.garlic.com/~lynn/2001n.html#37 Hercules etc. IBM not just missing a great opportunity...
https://www.garlic.com/~lynn/2001n.html#67 Hercules etc. IBM not just missing a great opportunity...
https://www.garlic.com/~lynn/2002d.html#4 IBM Mainframe at home
https://www.garlic.com/~lynn/2002g.html#61 GE 625/635 Reference + Smart Hardware
https://www.garlic.com/~lynn/2002i.html#31 : Re: AS/400 and MVS - clarification please
https://www.garlic.com/~lynn/2002i.html#63 Hercules and System/390 - do we need it?
https://www.garlic.com/~lynn/2002i.html#64 Hercules and System/390 - do we need it?
https://www.garlic.com/~lynn/2002i.html#69 Hercules and System/390 - do we need it?
https://www.garlic.com/~lynn/2004g.html#19 HERCULES
https://www.garlic.com/~lynn/2004g.html#29 [IBM-MAIN] HERCULES
https://www.garlic.com/~lynn/2004g.html#48 Hercules
https://www.garlic.com/~lynn/2006c.html#46 Hercules 3.04 announcement
https://www.garlic.com/~lynn/2006d.html#1 Hercules 3.04 announcement
https://www.garlic.com/~lynn/2006d.html#3 Hercules 3.04 announcement
https://www.garlic.com/~lynn/2006d.html#15 Hercules 3.04 announcement
https://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
https://www.garlic.com/~lynn/subtopic.html#smp

minor note ... except finishing off rfc 1044 support in mainframe product (18 years ago),
https://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 scale-up work for ha/cmp project
https://www.garlic.com/~lynn/95.html#13

enormous amounts of the high-speed data transport project done in the early and mid-80s ...
https://www.garlic.com/~lynn/subnetwork.html#hsdt
referenced here .... had little to do with mainframes
https://www.garlic.com/~lynn/2006s.html#50 Ranking of non-IBM mainframe builders
https://www.garlic.com/~lynn/2006t.html#6 Ranking of non-IBM mainframe builders

a lot of it was heavily oriented towards 801/risc
https://www.garlic.com/~lynn/subtopic.html#801

part of the early issue in the ha/cmp cluster scale-up
https://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 scale-up 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)
https://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
https://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
https://www.garlic.com/~lynn/2006c.html#8 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006c.html#46 Hercules 3.04 announcement
https://www.garlic.com/~lynn/2006i.html#27 Really BIG disk platters?
https://www.garlic.com/~lynn/2006i.html#41 virtual memory
https://www.garlic.com/~lynn/2006j.html#11 The Pankian Metaphor
https://www.garlic.com/~lynn/2006k.html#57 virtual memory
https://www.garlic.com/~lynn/2006l.html#4 Google Architecture
https://www.garlic.com/~lynn/2006q.html#50 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006r.html#14 50th Anniversary of invention of disk drives
https://www.garlic.com/~lynn/2006r.html#15 50th Anniversary of invention of disk drives
https://www.garlic.com/~lynn/2006r.html#18 50th Anniversary of invention of disk drives
https://www.garlic.com/~lynn/2006r.html#20 50th Anniversary of invention of disk drives
https://www.garlic.com/~lynn/2006r.html#21 50th Anniversary of invention of disk drives
https://www.garlic.com/~lynn/2006r.html#23 50th Anniversary of invention of disk drives
https://www.garlic.com/~lynn/2006r.html#30 50th Anniversary of invention of disk drives
https://www.garlic.com/~lynn/2006r.html#31 50th Anniversary of invention of disk drives
https://www.garlic.com/~lynn/2006r.html#33 50th Anniversary of invention of disk drives
https://www.garlic.com/~lynn/2006r.html#36 REAL memory column in SDSF
https://www.garlic.com/~lynn/2006s.html#23 Why magnetic drums was/are worse than disks ?
https://www.garlic.com/~lynn/2006s.html#30 Why magnetic drums was/are worse than disks ?
https://www.garlic.com/~lynn/2006s.html#32 Why magnetic drums was/are worse than disks ?
https://www.garlic.com/~lynn/2006s.html#42 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006s.html#45 Why magnetic drums was/are worse than disks ?
https://www.garlic.com/~lynn/2006s.html#59 Why magnetic drums was/are worse than disks ?
https://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:
https://www.garlic.com/~lynn/2006t.html#20 Why these original FORTRAN quirks?; Now : Programming practices
https://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):
https://www.garlic.com/~lynn/subtopic.html#hacmp

Date: Fri, 8 Mar 91 17:55:16 EST
From: wheeler
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 occurred 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:
https://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:
https://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.
https://www.garlic.com/~lynn/submain.html#systemr

i've since gone thru a couple complete rewrites from scratch.
https://www.garlic.com/~lynn/index.html

it is what i use for my rfc index
https://www.garlic.com/~lynn/rfcietff.htm

and the merged taxonomies and glossaries
https://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.
https://www.garlic.com/~lynn/2006.html#12a sox, auditing, finding improprieties
https://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
https://www.garlic.com/~lynn/aadsm10.htm#smallpay3 Small/Secure Payment Business Models
https://www.garlic.com/~lynn/aadsm10.htm#cfppki19 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm14.htm#50 E-banking is board-level Issue, Says Basel Committee
https://www.garlic.com/~lynn/aadsm14.htm#52 Committee calls for better e-banking security management
https://www.garlic.com/~lynn/aadsm16.htm#7 The Digital Insider: Backdoor Trojans ... fyi
https://www.garlic.com/~lynn/aadsm21.htm#3 Is there any future for smartcards?
https://www.garlic.com/~lynn/aadsm25.htm#14 Sarbanes-Oxley is what you get when you don't do FC
https://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
https://www.garlic.com/~lynn/2006.html#46 Free to good home: IBM RT UNIX
https://www.garlic.com/~lynn/2006b.html#8 Free to good home: IBM RT UNIX
https://www.garlic.com/~lynn/2006b.html#32 Multiple address spaces
https://www.garlic.com/~lynn/2006c.html#11 Mainframe Jobs Going Away
https://www.garlic.com/~lynn/2006g.html#13 News Release
https://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
https://www.garlic.com/~lynn/2003g.html#56 OT What movies have taught us about Computers
https://www.garlic.com/~lynn/2003g.html#57 OT What movies have taught us about Computers
https://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
https://www.garlic.com/~lynn/99.html#102 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
https://www.garlic.com/~lynn/99.html#103 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
https://www.garlic.com/~lynn/99.html#108 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
https://www.garlic.com/~lynn/2001h.html#15 IBM 9020 FAA/ATC Systems from 1960's
https://www.garlic.com/~lynn/2001h.html#17 IBM 9020 FAA/ATC Systems from 1960's
https://www.garlic.com/~lynn/2001h.html#71 IBM 9020 FAA/ATC Systems from 1960's
https://www.garlic.com/~lynn/2001i.html#2 Most complex instructions (was Re: IBM 9020 FAA/ATC Systems from 1960's)
https://www.garlic.com/~lynn/2001i.html#3 Most complex instructions (was Re: IBM 9020 FAA/ATC Systems from 1960's)
https://www.garlic.com/~lynn/2001i.html#14 IBM 9020 FAA/ATC Systems from 1960's
https://www.garlic.com/~lynn/2001i.html#15 IBM 9020 FAA/ATC Systems from 1960's
https://www.garlic.com/~lynn/2002g.html#2 Computers in Science Fiction
https://www.garlic.com/~lynn/2003m.html#4 IBM Manuals from the 1940's and 1950's
https://www.garlic.com/~lynn/2004.html#7 Dyadic
https://www.garlic.com/~lynn/2004l.html#49 "Perfect" or "Provable" security both crypto and non-crypto?
https://www.garlic.com/~lynn/2005e.html#57 System/360; Hardwired vs. Microcoded
https://www.garlic.com/~lynn/2005m.html#9 IBM's mini computers--lack thereof
https://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
https://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.

Date: 03/11/80 08:52:58
From: wheeler
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 environment 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, but it is your fault that you put in more features in RED than were in XEDIT.


... snip ... top of post, old email index

Date: 03/12/80 09:26:53
From: wheeler
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.

Date: 06/06/79 10:25:14
From: wheeler

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
https://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
https://www.garlic.com/~lynn/subtopic.html#disk

Date: 04/29/80 14:03:23
From: wheeler
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

Date: 05/01/80 12:13:41
From: RCHVM1 (somebody in rochester)
To: wheeler

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
https://www.garlic.com/~lynn/2006u.html#19 Why so little parallelism?
https://www.garlic.com/~lynn/2006u.html#21 Why so little parallelism?

... and
https://www.garlic.com/~lynn/2006t.html#24 CMSBACK

which then brings up this recent thread x-posted to alt.lang.asm & comp.arch
https://www.garlic.com/~lynn/2006t.html#45 To RISC or not to RISC
https://www.garlic.com/~lynn/2006t.html#46 To RISC or not to RISC
https://www.garlic.com/~lynn/2006t.html#47 To RISC or not to RISC
https://www.garlic.com/~lynn/2006t.html#48 To RISC or not to RISC
https://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.

Date: 11/03/78 13:25:59
To: wheeler
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.
https://www.garlic.com/~lynn/submain.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
https://www.garlic.com/~lynn/2006.html#17 {SPAM?} DCSS as SWAP disk for z/Linux
https://www.garlic.com/~lynn/2006.html#18 DCSS as SWAP disk for z/Linux
https://www.garlic.com/~lynn/2006.html#19 DCSS as SWAP disk for z/Linux
https://www.garlic.com/~lynn/2006.html#25 DCSS as SWAP disk for z/Linux
https://www.garlic.com/~lynn/2006.html#28 DCSS as SWAP disk for z/Linux
https://www.garlic.com/~lynn/2006m.html#53 DCSS
https://www.garlic.com/~lynn/2006m.html#54 DCSS
https://www.garlic.com/~lynn/2006m.html#56 DCSS
https://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:
https://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)
https://www.garlic.com/~lynn/submain.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:
https://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:
https://www.garlic.com/~lynn/2002n.html#39 CMS update
https://www.garlic.com/~lynn/2004b.html#59 A POX on you, Dennis Ritchie!!!
https://www.garlic.com/~lynn/2004g.html#43 Sequence Numbbers in Location 73-80
https://www.garlic.com/~lynn/2005i.html#30 Status of Software Reuse?
https://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3
https://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
https://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 distinguish 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
https://www.garlic.com/~lynn/2006u.html#19 Why so little parallelism?

....

Date: Thu Apr 16 11:11:41 1992
From: wheeler
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

https://www.garlic.com/~lynn/2001.html#21 Disk caching and file systems. Disk history...people forget
https://www.garlic.com/~lynn/2001.html#22 Disk caching and file systems. Disk history...people forget
https://www.garlic.com/~lynn/2001f.html#66 commodity storage servers
https://www.garlic.com/~lynn/2002.html#10 index searching
https://www.garlic.com/~lynn/2002e.html#46 What goes into a 3090?
https://www.garlic.com/~lynn/2002g.html#61 GE 625/635 Reference + Smart Hardware
https://www.garlic.com/~lynn/2003b.html#29 360/370 disk drives
https://www.garlic.com/~lynn/2003b.html#31 360/370 disk drives
https://www.garlic.com/~lynn/2003h.html#6 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
https://www.garlic.com/~lynn/2003i.html#53 A Dark Day
https://www.garlic.com/~lynn/2004d.html#75 DASD Architecture of the future
https://www.garlic.com/~lynn/2004g.html#26 network history
https://www.garlic.com/~lynn/2004p.html#29 FW: Is FICON good enough, or is it the only choice we get?
https://www.garlic.com/~lynn/2005e.html#12 Device and channel
https://www.garlic.com/~lynn/2005e.html#15 Device and channel
https://www.garlic.com/~lynn/2005e.html#16 Device and channel
https://www.garlic.com/~lynn/2005e.html#19 Device and channel
https://www.garlic.com/~lynn/2006n.html#29 CRAM, DataCell, and 3850
https://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:
https://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
https://www.garlic.com/~lynn/subnetwork.html#emulation
and the SAA related activity ... with us on the other end with 3-tier architecture
https://www.garlic.com/~lynn/subnetwork.html#3tier
and hsdt activity
https://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
https://www.garlic.com/~lynn/submain.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
https://www.garlic.com/~lynn/submain.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
https://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
https://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist
https://www.garlic.com/~lynn/94.html#27 370 ECPS VM microcode assist
https://www.garlic.com/~lynn/94.html#28 370 ECPS VM microcode assist
https://www.garlic.com/~lynn/2003f.html#43 ECPS:VM DISPx instructions
https://www.garlic.com/~lynn/2003f.html#47 ECPS:VM DISPx instructions
https://www.garlic.com/~lynn/2003f.html#52 ECPS:VM DISPx instructions
https://www.garlic.com/~lynn/2003f.html#54 ECPS:VM DISPx instructions
https://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:
https://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
https://www.garlic.com/~lynn/2006t.html#20 Why these original FORTRAN quirks?
https://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
https://www.garlic.com/~lynn/submain.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
https://www.garlic.com/~lynn/subtopic.html#hacmp

we coined the term disaster survivability and geographic survivability for concurrent operation of remote/redundant sites.
https://www.garlic.com/~lynn/submain.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.
https://www.garlic.com/~lynn/submain.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
https://www.garlic.com/~lynn/98.html#35a Drive letters
https://www.garlic.com/~lynn/98.html#37 What is MVS/ESA?
https://www.garlic.com/~lynn/99.html#71 High Availabilty on S/390
https://www.garlic.com/~lynn/99.html#77 Are mainframes relevant ??
https://www.garlic.com/~lynn/99.html#92 MVS vs HASP vs JES (was 2821)
https://www.garlic.com/~lynn/99.html#128 Examples of non-relational databases
https://www.garlic.com/~lynn/2000.html#13 Computer of the century
https://www.garlic.com/~lynn/2000f.html#54 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
https://www.garlic.com/~lynn/2001d.html#71 Pentium 4 Prefetch engine?
https://www.garlic.com/~lynn/2001k.html#13 HP-UX will not be ported to Alpha (no surprise)exit
https://www.garlic.com/~lynn/2001k.html#14 HP-UX will not be ported to Alpha (no surprise)exit
https://www.garlic.com/~lynn/2001k.html#18 HP-UX will not be ported to Alpha (no surprise)exit
https://www.garlic.com/~lynn/2002o.html#14 Home mainframes
https://www.garlic.com/~lynn/2002p.html#54 Newbie: Two quesions about mainframes
https://www.garlic.com/~lynn/2003l.html#11 how long does (or did) it take to boot a timesharing system?
https://www.garlic.com/~lynn/2004.html#40 AMD/Linux vs Intel/Microsoft
https://www.garlic.com/~lynn/2004m.html#46 Shipwrecks
https://www.garlic.com/~lynn/2004q.html#75 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005d.html#9 intel's Vanderpool and virtualization in general (was Re: Cell press release, redacted.)
https://www.garlic.com/~lynn/2005n.html#7 54 Processors?
https://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:
https://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
https://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/tfh120709-story08.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 usage ... 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 follow-on 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
https://www.garlic.com/~lynn/2006p.html#4 Greatest Software Ever Written?
https://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:
https://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
https://www.garlic.com/~lynn/submain.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
https://en.wikipedia.org/wiki/System/38

For other topic drift, when we were doing ha/cmp product
https://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.
https://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:
https://www.garlic.com/~lynn/2006u.html#16 IA64 and emulator performance

... some of which, I believe may have also implemented JIT technology.


re:
https://www.garlic.com/~lynn/2006u.html#29 To RISC or not to RISC
https://www.garlic.com/~lynn/2006u.html#31 To RISC or not to RISC

for even more drift ... recent post
https://www.garlic.com/~lynn/2006p.html#42 old hypervisor email

includes some old email from fort knox days
https://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
https://www.garlic.com/~lynn/2003e.html#64 801 (was Re: Reviving Multics)
https://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
https://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:
https://www.garlic.com/~lynn/2006u.html#26 Assembler question
https://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) ...
https://www.garlic.com/~lynn/2006u.html#29 To RISC or not to RISC
https://www.garlic.com/~lynn/2006u.html#31 To RISC or not to RISC
https://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
https://www.garlic.com/~lynn/2002p.html#44 Linux paging
https://www.garlic.com/~lynn/2002p.html#48 Linux paging
https://www.garlic.com/~lynn/2003.html#9 Mainframe System Programmer/Administrator market demand?
https://www.garlic.com/~lynn/2003.html#56 Wild hardware idea
https://www.garlic.com/~lynn/2005d.html#59 Misuse of word "microcode"
https://www.garlic.com/~lynn/2005d.html#60 Misuse of word "microcode"
https://www.garlic.com/~lynn/2005h.html#24 Description of a new old-fashioned programming language
https://www.garlic.com/~lynn/2005p.html#14 Multicores
https://www.garlic.com/~lynn/2005p.html#29 Documentation for the New Instructions for the z9 Processor
https://www.garlic.com/~lynn/2005u.html#40 POWER6 on zSeries?
https://www.garlic.com/~lynn/2005u.html#43 POWER6 on zSeries?
https://www.garlic.com/~lynn/2005u.html#48 POWER6 on zSeries?
https://www.garlic.com/~lynn/2006b.html#38 blast from the past ... macrocode
https://www.garlic.com/~lynn/2006c.html#9 Mainframe Jobs Going Away
https://www.garlic.com/~lynn/2006j.html#32 Code density and performance?
https://www.garlic.com/~lynn/2006j.html#35 Code density and performance?
https://www.garlic.com/~lynn/2006m.html#39 Using different storage key's
https://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:
https://www.garlic.com/~lynn/2006u.html#26 Assembler question
https://www.garlic.com/~lynn/2006u.html#27 Assembler question
https://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)
https://www.garlic.com/~lynn/2006p.html#42 old hypervisor email

more old email discussing 5880 announcement
https://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:
https://www.garlic.com/~lynn/2006u.html#13 Year-end computer bug could ground Shuttle
https://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:
https://www.garlic.com/~lynn/99.html#24 BA Solves Y2K (Was: Re: Chinese Solve Y2K)
https://www.garlic.com/~lynn/2000.html#94 Those who do not learn from history...
https://www.garlic.com/~lynn/2003p.html#21 Sun researchers: Computers do bad math ;)
https://www.garlic.com/~lynn/2006r.html#16 Was FORTRAN buggy?

remote support questions - curiousity

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: remote support questions - curiousity
Newsgroups: bit.listserv.ibm-main
Date: Mon, 13 Nov 2006 13:15:34 -0700
the other viewpoint was that the software was designed as dedicated, disconnected tabletop operation ... and allowed numerous applications (games, etc) to take over the whole machine. a little later the software was extended to support desktop operations with some local area business network (non-hostile and non-adversary). it was designed very well to do what it was intended to do (and in fact a great deal of countermeasures to machine take-over would have been counter productive to its original target market).

it was when those pesky users started attaching the product (originally designed for totally stand-alone operation) to open (and potentially extremely hostile) networks, that you started having problems. it is somewhat like taking a Model T and asking why it doesn't have crush zones, safety belts, airbags, rollbars, safety glass, padded dashes, headrests, etc.

for slight drift ... in the mid to late 90s, a lot of the threats were buffer overflow related to the use C language programming conventions ... lots of past posts discussing buffer overflow issues
https://www.garlic.com/~lynn/subintegrity.html#overflow

then automatic scripting (much of which had been originally targeted at closed, non-hostile, cooperative environments) exploits started to drastically increase until buffer overflow exploits and automatic scripting exploits were about equal. the potential for automatic scripting vulnerabilities was something that had been identified on the internal network in the 70s.

a couple years ago, there was an estimate that 1/3rd of the exploits were buffer overflow related, 1/3rd automatic scripting related, and 1/3rd social engineering related.

for other drift ... recent lengthy discussion on open networks and SSL related vulnerabilities
https://www.garlic.com/~lynn/aadsm26.htm#1

the latest seems to be a big upswing in phishing ... which can be considered a form of *social engineering* ... i.e. convincing victim to do something for the attacker (frequently involves divulging sensitive information).

lots of past posts related to fraud, exploits, vulnerabilities, and threats
https://www.garlic.com/~lynn/subintegrity.html#fraud

and as a complement ... some number of past postings related to assurance
https://www.garlic.com/~lynn/subintegrity.html#assurance

a major objective of phishing attacks is to obtain sensitive information that is frequently used in something you know authentication (that can be turned around and used by the attacker in replay and/or impersonation exploits).

from 3-factor authentication model
https://www.garlic.com/~lynn/subintegrity.html#3factor

something you have
something you know
something you are

this is particularly applicable to pins, passwords something you know shared-secret authentication
https://www.garlic.com/~lynn/subintegrity.html#secrets

or account numbers ... where attackers can turn around and use the account numbers in transactions requiring little or no additional information ... misc. posts mentioning account number harvesting for fraudulent transactions
https://www.garlic.com/~lynn/subintegrity.html#harvest

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: Mon, 13 Nov 2006 22:00:57 -0700
"Del Cecchi" <delcecchiofthenorth@gmail.com> writes:
With great trepidation I must correct Lynn. Fort Knox was more like 1990 since the processor was to be Iliad. And AS400 was born from the wreckage of Fort Knox as a descendent of S/38 and "platform" that allowed S/36 code to run on S/38 like machine. See the book "Silver Lake" or anything by Frank Soltis.

there were a number of Iliads .... misc. reference from the early 80s.

Date: 04/20/83 20:01:51
From: wheeler

....

I also spent some time with one of xxxxx's Iliad design people on Monday. He is attempting to tackle an on-chip virtual cache. Problem was how to resolve synonyms ... same real storage addressed by different virtual addresses.


... snip ... top of post, old email index

also endicott started work with some 801 that predated Iliad ...

this post
https://www.garlic.com/~lynn/2006t.html#9 32 or even 64 registers for x86-64?

has copy of old endicott email from 11/4/81 mentioning working with Atlantic (801 processor from yorktown)

here is some old email that implied that Fort Knox was over and well buried by 1988 (topic was specifically about rochester part of fort knox ... i.e. moving rochester systems on to 801).

Date: 16 March 1988, 10:39:41 CST
To: wheeler

HI, In Fort Knox we went round and round about what layers should be outboard and which should be inboard. The real answer was flexability to do both such as the gain in our IOPs.


... snip ... top of post, old email index

So in previous post
https://www.garlic.com/~lynn/2006u.html#31 To RISC or not to RISC

references this article
http://www.cbronline.com/article_cbr.asp?guid=2C99DD1B-6812-46AF-AF95-B6D7E728376A

where the as/400 came out in 1988 after *fort knox* was killed/canceled.

the previous post also cites this article "IBM: Fort Knox Fails, but Silverlake Shines"
http://www.riteapproach.com/book/ibm.html

from above:
The goal of Fort Knox was to unify the hodgepodge of smaller IBM computers then on the market and put DEC and its imitators on the run. Following IBM's then rigid development process, the specifications for creating this computer grew more complex as each day passed. By 1985 it became obvious that the development team was years away from a workable product, and the project was canceled.

... snip ...

as an aside, Endicott had abandoned the strategy to use 801 for the follow-on to 4341 even earlier.
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP4381.html

so in your statement "Fort Knox was more like 1990" ... are you referring to that by 1985 (when it was killed), it was realized that the scope creep(?) in Fort Knox met that nothing would be available before 1990?

my references was to stuff going on in the early days of when the project started (circa 1980) ... and not to when it was eventually might be expected to ship (and, in fact, i don't make any claims as to knowing when it might have shipped).

the other references imply that Fort Knox was more than just Rochester ... and that it started in the early 80s. Endicott use of 801 for follow-on to 4341 was abandoned at least by the time 4381 was announced in 1983. I contributed to white paper that helped Endicott decide to abandoned the 801 for the 4341 follow-on.

so i don't see what in your post refers to contridicting something in my post?

previous post
https://www.garlic.com/~lynn/2006u.html#31 To RISC or not to RISC

also cited the wiki pages for s/38 and as/400
https://en.wikipedia.org/wiki/System/38
https://en.wikipedia.org/wiki/AS/400

here is also the wiki page for silverlake
http://wiki.midrange.com/index.php/Silverlake

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: Mon, 13 Nov 2006 22:20:22 -0700
"Del Cecchi" <delcecchiofthenorth@gmail.com> writes:
With great trepidation I must correct Lynn. Fort Knox was more like 1990 since the processor was to be Iliad. And AS400 was born from the wreckage of Fort Knox as a descendent of S/38 and "platform" that allowed S/36 code to run on S/38 like machine. See the book "Silver Lake" or anything by Frank Soltis.

re:
https://www.garlic.com/~lynn/2006u.html#29 To RISC or not to RISC
https://www.garlic.com/~lynn/2006u.html#31 To RISC or not to RISC
https://www.garlic.com/~lynn/2006u.html#32 To RISC or not to RISC
https://www.garlic.com/~lynn/2006u.html#37 To RISC or not to RISC

oh, and from somewhere else long ago and far away ...

Date: 04/22/81 13:55:03
To: wheeler

Re: processors in small spaces...

Iliad goes to mfg feb 82 for 1st pass parts. Level of confidence in parts being good is about 95%.


... snip ... top of post, old email index

but as per lots of references, the design/scope kept getting more and more complex ... and the rochester effort was finally killed in 85.

P390

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: P390
Newsgroups: bit.listserv.ibm-main
Date: Wed, 15 Nov 2006 06:53:43 -0700
timothy.sipples@US.IBM.COM (Timothy Sipples) writes:
I posted an item at The Mainframe Blog (http://mainframe.typepad.com) today with a discussion of what's currently involved in obtaining a "home mainframe" (which might be personal or might be shared among a group of developers). The post might spur some interesting comments, and anyone is welcome to comment.

for a little drift ... over in comp.arch a thread on "To RISC or not to RISC" drifted into the old Fort Knox project ... which then also drew some references to current day mainframe software emulators.
https://www.garlic.com/~lynn/2006u.html#29 To RISC or not to RISC
https://www.garlic.com/~lynn/2006u.html#31 To RISC or not to RISC
https://www.garlic.com/~lynn/2006u.html#32 To RISC or not to RISC
https://www.garlic.com/~lynn/2006u.html#37 To RISC or not to RISC
https://www.garlic.com/~lynn/2006u.html#38 To RISC or not to RISC

and a slightly earlier thread also in comp.arch
https://www.garlic.com/~lynn/2006u.html#16 IA64 and emulator performance

New attacks on the financial PIN processing

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: New attacks on the financial PIN processing
Newsgroups: sci.crypt
Date: Wed, 15 Nov 2006 07:25:40 -0700
uri writes:
JR wrote: > http://www.arx.com/documents/The_Unbearable_Lightness_of_PIN_Cracking.pdf

This paper describes crypto attacks on the protocols and standards for financial ATM PIN processing.

The results show an inherent flaw with the way ATM PINs are encrypted and conveyed on the international financial networks. One of the most disturbing results is that instead of just having to trust that your own issuer bank has good control over insider fraud, every other financial institution in the network must be trusted as well - an insider at another bank can crypto-crack your ATM PIN if you withdraw money from any of their ATMs.


for quite some time, the conventional wisdom has been that insiders are the greatest source of fraud, data breaches, identity theft, etc.

supposedly PINs represent two-factor authentication ... from 3-factor authentication model
https://www.garlic.com/~lynn/subintegrity.html#3factor

something you have
something you know
something you are

where a PIN represents something you "know authentication. supposedly multi-factor authentication is considered more secure because the different factors are selected to have independent vulnerabilities/expoits i.e. a PIN is countermeasure to lost/stolen card. ignore for a moment that, in part, because of the proliferation of something you know authentication ... supposedly something like 30percent of debit cards have the PIN written on them ... lots of past posts about shared-secret based something you know authentication
https://www.garlic.com/~lynn/subintegrity.html#secrets

for a couple decades there have been exploits/attacks on terminals that skim authentication information. this collects both the (static data) magstripe information (that represents something you have authentication) and pin at the same time (something you know). this represents a common vulnerability to debit card multi-factor authentication ... negating any assumption about multi-factor authentication being more secure. compromise of terminals can be either insider or outsider exploit, although outsider exploits seem to be what makes the news. lots of past posts about harvesting static, authentication information:
https://www.garlic.com/~lynn/subintegrity.html#harvest

recent post earlier this year in this news group on related topic
https://www.garlic.com/~lynn/2006e.html#21 Debit Cards Hacked now
https://www.garlic.com/~lynn/2006e.html#22 Debit Cards Hacked now
https://www.garlic.com/~lynn/2006e.html#23 Debit Cards Hacked now
https://www.garlic.com/~lynn/2006e.html#24 Debit Cards Hacked now
https://www.garlic.com/~lynn/2006e.html#30 Debit Cards Hacked now

a whole lot of posts (from last spring and summer) regarding yes card skimming attack on chip&pin payment cards ... dating back to nearly their original introduction in the 90s:
https://www.garlic.com/~lynn/subintegrity.html#yescard

the following has some discussion of PINs and 2984 atm machine done at the los gatos lab (where for a time i had a nearly one wing of offices) and the demolition of the los gatos lab
https://www.garlic.com/~lynn/2006q.html#5

as well as 3624 and the introduction of PIN block format ... and the referenced wiki article
https://en.wikipedia.org/wiki/Personal_identification_number

which also mentions a vulnerability discovered in the 3624 pin block format in 2002.

Is this true? (Were gotos really *that* bad?)

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is this true? (Were gotos really *that* bad?)
Newsgroups: alt.folklore.computers
Date: Wed, 15 Nov 2006 08:29:27 -0700
"John Coleman" <jcoleman@franciscan.edu> writes:
Before structured programming methods developed, code was often written in a "spaghetti" style, so called because of the lack of clear block structure. Goto and other branch statements were used, causing the program flow to jump from one place to another, which produced code that was a tangled mess to everyone but the original author.

part of it was dependencies ... complex/convoluted logic was hard to modify ... but the complex/convoluted logic could be highly efficient

in failure analysis and postmortem dumps part of the issue is reconstructing sequence of events that resulted in the failure. convoluted/complex spaghetti code ... with lots of GOTOs that converge on the same place ... could make it difficult to reconstruct the execution path that resulted in arriving at failure point.

as i've posted a lot in the past ... for assembler code ... frequent failure mode was unusual code thread that resulted in register use that hadn't been correctly initialized.

misc. past posts about failure analysis program that i had implemented and was used widely inside the corporation
https://www.garlic.com/~lynn/submain.html#dumprx

and some recent posts about a PLI program that I wrote to analyse (360/370) assembler listings, attempting to create an abstract representation of the execution, reconstruct all possible code paths ... and also look for things like possible register use before set.
https://www.garlic.com/~lynn/2000c.html#41 Domainatrix - the final word
https://www.garlic.com/~lynn/2004d.html#21 REXX still going strong after 25 years
https://www.garlic.com/~lynn/2005u.html#45 IBM's POWER6
https://www.garlic.com/~lynn/2006r.html#24 A Day For Surprises (Astounding Itanium Tricks)
https://www.garlic.com/~lynn/2006s.html#53 Is the teaching of non-reentrant HLASM coding practices ever defensible?
https://www.garlic.com/~lynn/2006u.html#31 To RISC or not to RISC

for totally other drift ... one of the first conferences that i attended after graduating and joining a science center
https://www.garlic.com/~lynn/subtopic.html#545tech

included a talk by Harlen Mills ... misc. past references
https://www.garlic.com/~lynn/2000b.html#20 How many Megaflops and when?
https://www.garlic.com/~lynn/2000b.html#24 How many Megaflops and when?
https://www.garlic.com/~lynn/2003k.html#20 What is timesharing, anyway?
https://www.garlic.com/~lynn/2004k.html#36 Vintage computers are better than modern crap !
https://www.garlic.com/~lynn/2005b.html#16 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005d.html#51 Thou shalt have no other gods before the ANSI C standard

New attacks on the financial PIN processing

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: New attacks on the financial PIN processing
Newsgroups: sci.crypt
Date: Wed, 15 Nov 2006 08:31:47 -0700
Sebastian Gottschalk <seppi@seppig.de> writes:
No. PINs represent something you know. A smartcard with a PINs add a something you have.

re:
https://www.garlic.com/~lynn/2006u.html#40 New attacks on the financial PIN processing

sorry, finger slip ... hopefully was evident in subsequent discussion about pin being something you know

New attacks on the financial PIN processing

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: New attacks on the financial PIN processing
Newsgroups: sci.crypt
Date: Wed, 15 Nov 2006 08:59:24 -0700
re:
https://www.garlic.com/~lynn/2006u.html#40 New attacks on the financial PIN processing
https://www.garlic.com/~lynn/2006u.html#42 New attacks on the financial PIN processing

in approx. the same timeframe as the on the inception of the work for what led to the yes card
https://www.garlic.com/~lynn/subintegrity.html#yescard

the x9a10 financial standard working group was formed and given the requirement to preserve the integrity of the financial infrastructure for all retail payments
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

part of the threat analysis was the extensive occurance of skimming exploits and/or data breaches ... and attackers (either insiders or outsiders) being able to utilize the acquired static information in a form of replay attacks.

so part of x9.59 was to eliminate replay attacks .... using skimmed/acquired/harvested for replay attacks
https://www.garlic.com/~lynn/subintegrity.html#harvest

part of this effort was recognizing that transaction and account information is used in dozens of business processes ... and even if the planet was buried under miles of encryption ... it still wouldn't be able to prevent transaction/account leakage (whether it involved insiders or outsiders).

so part of the x9.59 financial standard was to eliminate the usefullness of transaction/account information to the attackers ... i.e. even with all the transaction/account information they couldn't use it directly for (replay attack) fraudulent transactions that go on today; aka x9.59 didn't do anything to eliminate data breaches (or skimming) ... it just eliminated the usefullness of the data breaches (and skimming) to the attackers.

several postings in thread on "naked transactions" ... that were somewhat the outgrowth of the extended discussion on yes card vulnerability
https://www.garlic.com/~lynn/aadsm24.htm#5 New ISO standard aims to ensure the security of financial transactions on the Internet
https://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#9 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#10 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#12 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#14 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#22 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#26 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#41 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#42 Naked Payments II - uncovering alternates, merchants v. issuers, Brits bungle the risk, and just what are MBAs good for?

waiting for acknowledgments

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: waiting for acknowledgments
Newsgroups: comp.protocols.tcp-ip
Date: Wed, 15 Nov 2006 12:11:41 -0700
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> writes:
Some time ago (several years, probably) I had some questions regarding our TCP/IP vendor and the fact that they would seem to always wait for an ACK before sending the next packet. I think it was pretty much agreed upon here that this was fairly non-standard (though not necessarily "forbidden" by any relevant RFC), and would also result in longer transmission times. The vendor argued that it is done in the name of 'data integrity'. Others argued, of course, that even though the receiving TCP acknowledged a packet that does not necessarily mean that the packet had been forwarded to the receiving application, or even if it was if the receiving application had handled it successfully. I could never seem to convince the vendor, though.

remember that SNA had been pretty much half-duplex protocol ... which met continually waiting for the link to turn around. there was even a document about attempts to implement lu6.2 on top of a tcp/ip layer and the horrible problems trying to get half-duplex lu6.2 to deal with asynchronous, full-duplex tcp/ip transmission layer.

the original vm/mvs tcp/ip product was implememted in vs/pascal and got something like 44kbytes/sec aggregate thruput and consumed a 3090 processor doing it. i had added rfc 1044 support to the product .. and in testing at cray research between a cray and a 4341-clone ... was getting 1mbyte/sec aggregate thruput using only a portion of the (4341-clone) processor.
https://www.garlic.com/~lynn/subnetwork.html#1044

one of the protocols used was NAK and selective-resend for missing packets and/or packets in error.

for high-speed local area network .. it might not be much of an issue ... but one of the things we did as part of the hsdt project
https://www.garlic.com/~lynn/subnetwork.html#hsdt

was a high-speed backbone for the internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet

that included some number of full-duplex T1 satellite links ... full-duplex asynchronous operation could easily have twenty 4k-byte packets outstanding simultaneously in both directions on a link. with approx. 22k miles to orbit ... or 4*22k miles for complete round-trip ... comes out to approx. half-second round-trip latency. half-duplex synchronous operation would have been two packets/sec thruput ... while the rate-based pacing and selective resend that was implemented could drive a full duplex T1 at nearly media speed (about 300kbytes/sec or 75 4k-byte packets/sec).

for additional data integrity ... the outboard satellite link also included 15/16 reed-solomon forward error correcting.

a few recent posts discussing various aspects of hsdt effort
https://www.garlic.com/~lynn/2006e.html#36 The Pankian Metaphor
https://www.garlic.com/~lynn/2006l.html#4 Google Architecture
https://www.garlic.com/~lynn/2006s.html#42 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006s.html#50 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006t.html#6 Ranking of non-IBM mainframe builders?

waiting for acknowledgments

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: waiting for acknowledgments
Newsgroups: comp.protocols.tcp-ip
Date: Wed, 15 Nov 2006 12:36:53 -0700
Anne & Lynn Wheeler <lynn@garlic.com> writes:
was a high-speed backbone for the internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet


re:
https://www.garlic.com/~lynn/2006u.html#44 waiting for acknowledgments

actually the selective resend didn't do a lot of good early on. all the links that left corporate facilities (including satellite links) had to be encrypted (at one point somebody claimed that the internal network had over half of all the link encryptors in the world).

in any case, early on, we had to settle for some (essentially) off-the-shelf T1 link encryptors ... when things got too garbled the link encryptors retrenched to initial synchronization mode ... which could last long enuf (especially on sat. link) that the software would think the link had dropped and would automatically recycle it. fortunately the 15/16 reed-solomon forward error correcting helped minimize the number of times that happened.

later i was involved in designing an inexpensive crypto board that minimized the crypto resynchronization problem (that was also targeted at being able to handle a couple megabytes/sec ... bytes not bits).

waiting for acknowledgments

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: waiting for acknowledgments
Newsgroups: comp.protocols.tcp-ip
Date: Wed, 15 Nov 2006 12:58:16 -0700
"Skybuck Flying" <spam@hotmail.com> writes:
You raise a very good question:

When is an acknowledgment sent back for TCP ?

Some possible answers:

1. The stack receives and queues the packet. The stack acknowledges the packet even though the user has not yet "picked up" the packet.

2. The stack receives and queues the packet. The stack does not acknowledge the packet until the user has "picked up" the packet.

Answer 2 is unlikely because the sender would then keep retransmitting the data until the user finally picks up the packet and the stack sends back an acknowledgment.

TCP was designed with network efficiency in mind.

I would be surprised if in reality TCP uses answer 2.

In reality TCP probably uses answer 1.


re:
https://www.garlic.com/~lynn/2006u.html#44 waiting for acknowledgments
https://www.garlic.com/~lynn/2006u.html#45 waiting for acknowledgments

note that the possibility would still exist that an application could fail to pickup a packet even in a half-duplex synchronous scenario ...

if you are looking to deal with that fault scenario ... the application would need some higher level logic regardless of which scenario that tcp/ip used (synchronous 1 block at a time, or some N-blocks outstanding asynchronous). if tcp/ip acks a packet before the application signals that it has completely processed the packet ... there is still all sorts of opportunities for things to go wrong ... whether it is a single packet outstanding or 100 packets outstanding.

New attacks on the financial PIN processing

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: New attacks on the financial PIN processing
Newsgroups: sci.crypt
Date: Wed, 15 Nov 2006 20:13:55 -0700
"Joseph Ashwood" <ashwood@msn.com> writes:
B) Slap $100 worth of equipment onto random ATM machine, harvest data via Wi-fi so you never have to touch it again.

from today's news (made off with 200,000 pounds so far):

ATMs hacked using MP3 player
http://news.com.com/2061-10789_3-6135905.html

from above:
The gang targeted freestanding cash dispensers and would tap the phone line between the ATM and a wall socket by placing a two-way adapter on it and connecting an MP3 player, according to the newspaper.

... snip ...

and some other comments here:
https://www.garlic.com/~lynn/aadsm26.htm#5 ATMs hacked using MP3 player

New attacks on the financial PIN processing

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: New attacks on the financial PIN processing
Newsgroups: sci.crypt
Date: Thu, 16 Nov 2006 06:31:03 -0700
uri writes:
Note that the bad guys here did not take money out of ATMs using the recorded info (they couldn't bacuase they could not decrypt the PINs), they just shopped - which is a classic credit card fraud.

i.e. current generation of debit cards (typically carrying association logo) can be used in either PIN-debit or signature-debit mode. you have to specially request a card that is PIN-debit only.

a few past posts mentioning signature-debit
https://www.garlic.com/~lynn/aadsm22.htm#22 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/2005u.html#14 AMD to leave x86 behind?
https://www.garlic.com/~lynn/2005u.html#16 AMD to leave x86 behind?
https://www.garlic.com/~lynn/2006e.html#4 When *not* to sign an e-mail message?
https://www.garlic.com/~lynn/2006e.html#21 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006e.html#24 Debit Cards HACKED now

Where can you get a Minor in Mainframe?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Where can you get a Minor in Mainframe?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 17 Nov 2006 08:24:54 -0700
Daniel_McLaughlin writes:
Due to a little interruption called Viet Nam didn't actually start twiddling bits until December 73.

in the early 80s, i sponsored a number of Boyd briefings inside the company ... some of my past postings mentioning Boyd
https://www.garlic.com/~lynn/subboyd.html#boyd
and numerous URLs from around the WEB mentioning Boyd
https://www.garlic.com/~lynn/subboyd.html#boyd2

various of his biographies mention that he ran NKP in Thailand.

for the summer of '69 (between semesters), I was con'ed into being full-time employee at Boeing, helping setup new dataprocessing for recently formed BCS (earlier in the spring, I had been con'ed into teaching a 40hr computer class to BCS technical staff during spring break).

For a long time, I thought that the Renton datacenter was one of the largest in the world ... however there was some rumor that NKP may have been larger (one of the biographies mentions that NKP represented a $2.5B windfall to IBM).

Where can you get a Minor in Mainframe?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Where can you get a Minor in Mainframe?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 17 Nov 2006 12:01:57 -0700
Anne & Lynn Wheeler <lynn@garlic.com> writes:
For a long time, I thought that the Renton datacenter was one of the largest in the world ... however there was some rumor that NKP may have been larger (one of the biographies mentions that NKP represented a $2.5B windfall to IBM).

re:
https://www.garlic.com/~lynn/2006u.html#49 Where can you get a Minor in Mainframe?

what i remember was that renton datacenter was several hundred million ... which would have made NKP possibly 5-6 times larger?

i do have a slight caveat and thread drift with respect to this post (from comp.arch thread)
https://www.garlic.com/~lynn/2006u.html#17 Why so little parallelism?

while i haven't worked on a mainframe in a long time ... this post mentions analysing the performance of a mainframe 450k line cobol program.
https://www.garlic.com/~lynn/2006s.html#24 Curiosity: CPU % for COBOL program

where i did all the multiple regression analysis of the COBOL application activity counters using a PC-based application.

the 14percent wasn't trivial since the application ran in datacenter across $1.5B of mainframe equipment (primarily sized for this one application). However, it was 2000 dollars instead of the 1970s dollars quoted for renton and NKP.

again, collected past posts mentioning boyd
https://www.garlic.com/~lynn/subboyd.html#boyd

misc. past posts mentioning NKP
https://www.garlic.com/~lynn/94.html#8 scheduling & dynamic adaptive ... long posting warning
https://www.garlic.com/~lynn/2005t.html#2 Dangerous Hardware
https://www.garlic.com/~lynn/2005t.html#5 Dangerous Hardware

misc. past posts mentioning BCS:
https://www.garlic.com/~lynn/99.html#32 Roads as Runways Was: Re: BA Solve
https://www.garlic.com/~lynn/99.html#130 early hardware
https://www.garlic.com/~lynn/2000f.html#66 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
https://www.garlic.com/~lynn/2001b.html#8 "HAL's Legacy and the Vision of 2001: A Space Odyssey"
https://www.garlic.com/~lynn/2001b.html#9 "HAL's Legacy and the Vision of 2001: A Space Odyssey"
https://www.garlic.com/~lynn/2001b.html#23 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
https://www.garlic.com/~lynn/2001g.html#56 YKYBHTLW....
https://www.garlic.com/~lynn/2001l.html#32 mainframe question
https://www.garlic.com/~lynn/2001m.html#55 TSS/360
https://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
https://www.garlic.com/~lynn/2002f.html#30 Computers in Science Fiction
https://www.garlic.com/~lynn/2002j.html#22 Computer Terminal Design Over the Years
https://www.garlic.com/~lynn/2002j.html#43 Killer Hard Drives - Shrapnel?
https://www.garlic.com/~lynn/2002l.html#64 10 choices that were critical to the Net's success
https://www.garlic.com/~lynn/2002n.html#71 bps loader, was PLX
https://www.garlic.com/~lynn/2002n.html#72 bps loader, was PLX
https://www.garlic.com/~lynn/2002o.html#30 Computer History Exhibition, Grenoble France
https://www.garlic.com/~lynn/2002p.html#56 cost of crossing kernel/user boundary
https://www.garlic.com/~lynn/2002p.html#64 cost of crossing kernel/user boundary
https://www.garlic.com/~lynn/2003l.html#34 Thoughts on Utility Computing?
https://www.garlic.com/~lynn/2003l.html#37 Thoughts on Utility Computing?
https://www.garlic.com/~lynn/2003m.html#32 SR 15,15 was: IEFBR14 Problems
https://www.garlic.com/~lynn/2004.html#53 Mainframe not a good architecture for interactive workloads
https://www.garlic.com/~lynn/2004d.html#55 If there had been no MS-DOS
https://www.garlic.com/~lynn/2004f.html#46 Finites State Machine (OT?)
https://www.garlic.com/~lynn/2004o.html#58 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2005e.html#8 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005e.html#19 Device and channel
https://www.garlic.com/~lynn/2005f.html#10 Where should the type information be: in tags and descriptors
https://www.garlic.com/~lynn/2005s.html#47 Gartner: Stop Outsourcing Now
https://www.garlic.com/~lynn/2006.html#40 All Good Things
https://www.garlic.com/~lynn/2006.html#43 Sprint backs out of IBM outsourcing deal
https://www.garlic.com/~lynn/2006k.html#29 PDP-1
https://www.garlic.com/~lynn/2006k.html#30 PDP-1
https://www.garlic.com/~lynn/2006m.html#29 Mainframe Limericks
https://www.garlic.com/~lynn/2006n.html#11 Not Your Dad's Mainframe: Little Iron
https://www.garlic.com/~lynn/2006o.html#13 The SEL 840 computer
https://www.garlic.com/~lynn/2006q.html#44 The not-so-little shop of 747s

Where can you get a Minor in Mainframe?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Where can you get a Minor in Mainframe?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 17 Nov 2006 12:42:25 -0700
Brian Inglis <Brian.Inglis@SystematicSW.Invalid> writes:
As in (from Wikipedia): "Nakhon Phanom Royal Thai Air Force Base (NKP) is a Royal Thai Navy facility. During the Vietnam War it was a front-line base of the United States Air Force."

the entry
https://en.wikipedia.org/wiki/Nakhon_Phanom_Royal_Thai_Air_Force_Base

doesn't even mention the datacenter w/$2.5B in ibm mainframes

in this biography: BOYD The Fighter Pilot Who Changed the Art of War
https://www.amazon.com/Boyd-Fighter-Pilot-Who-Changed/dp/0316796883/

the chapter on Boyd running NKP is "Spook Base".

re:
https://www.garlic.com/~lynn/2006u.html#49 Where can you get a Minor in Mainframe?
https://www.garlic.com/~lynn/2006u.html#50 Where can you get a Minor in Mainframe?

Where can you get a Minor in Mainframe?

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Where can you get a Minor in Mainframe?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 17 Nov 2006 17:10:24 -0700
sarn756@ibm-main.lst (Steve Arnett) writes:
What ever happened to the Virtual Universe Operating System that was announced back in the late 70s? Or did IBM keep that one for themselves?

ref posts in thread:
https://www.garlic.com/~lynn/2006u.html#49 Where can you get a Minor in Mainframe?
https://www.garlic.com/~lynn/2006u.html#50 Where can you get a Minor in Mainframe?
https://www.garlic.com/~lynn/2006u.html#51 Where can you get a Minor in Mainframe?

the programming announcement OS/VU
http://www.cbttape.org/funny/ttosvu.pdf
also discussed here
http://mcraeclan.com/Links/Computers/IBMMainframeHistory/mvsosvu.htm

for slight drift, here is old posting of "Gen A Sys" from july '79
https://www.garlic.com/~lynn/2001f.html#38 Ancient computer humor - Gen A Sys

there is this ...


THE CONDEMNED
*
WHEN THE EARTH WAS CREATED, THE POWERS ABOVE
GAVE EACH MAN A JOB TO WORK AT AND LOVE.
HE MADE DOCTORS AND LAWYERS AND PLUMBERS AND THEN -
HE MADE CARPENTERS, SINGERS, AND CONFIDENCE MEN.
AND WHEN EACH HAD A JOB TO WORK AS HE SHOULD,
HE LOOKED THEM ALL OVER AND SAW IT WAS GOOD.
*
HE THEN SAT DOWN TO REST FOR A DAY,
WHEN A HORRIBLE GROAN CHANCED TO COME IN HIS WAY.
THE LORD THEN LOOKED DOWN, AND HIS EYES OPENED WIDE -
FOR A MOTLEY COLLECTION OF BUMS STOOD OUTSIDE.
"OH! WHAT CAN THEY WANT?" THE CREATOR ASKED THEN
"HELP US," THEY CRIED OUT, "A JOB FOR US MEN."
"WE HAVE NO PROFESSION," THEY CRIED IN DISMAY,
"AND EVEN THE JAILS HAVE TURNED US AWAY."
SAID THE LORD, "I'VE SEEN MANY THINGS WITHOUT WORTH -
BUT HERE I FIND GATHERED THE SCUM OF THE EARTH!"
*
THE LORD WAS PERPLEXED - THEN HE WAS MAD.
FOR ALL THE JOBS, THERE WAS NONE TO BE HAD!
THEN HE SPAKE ALOUD IN A DEEP, ANGRY TONE ---
"FOR EVER AND EVER YE MONGRELS SHALL ROAM.
YE SHALL FREEZE IN THE SUMMER AND SWEAT WHEN ITS COLD -
YE SHALL WORK ON EQUIPMENT THATS DIRTY AND OLD.
YE SHALL CRAWL UNDER RAISED FLOORS, AND THERE CABLES LAY -
YE SHALL BE CALLED OUT AT MIDNIGHT AND WORK THROUGH THE DAY.
YE SHALL WORK ON ALL HOLIDAYS, AND NOT MAKE YOUR WORTH -
YE SHALL BE BLAMED FOR ALL DOWNTIME THAT OCCURS ON THE EARTH.
YE SHALL WATCH ALL THE GLORY GO TO SOFTWARE AND SALES -
YE SHALL BE BLAMED BY THEM BOTH IF THE SYSTEM THEN FAILS.
YE SHALL BE PAID NOTHING OUT OF SORROW AND TEARS -
YE SHALL BE FOREVER CURSED, AND CALLED FIELD ENGINEERS!"
*

.... snip ...

and then there is this ...

In the first few months of the year that System 360 Operating System came to a full stop, all signs appeared normal and there was no indication of an impending disaster. The SDD Manager of Programming Systems stated at the spring SHARE meeting that the F Level of FORTRAN V would definitely be implemented and would at least equal the speed of the E Level FORTRAN V subset, provided it was run on a Model 75 or greater. There was no truth, he asserted, to the rumor that IBM was dropping FORTRAN in favor of PL/3. Option 89, or MVC (multiprogramming with a variable number of CPU's), which had been released in System Release 101.8 was hailed by a large number of users as the ultimate in operating systems. Representatives of a major government agency which had been running a Model 91 with 8 million bytes using a modified BPS supervisor, lodged a mild protest, but were shouted down by the majority.

On April 1, an announcement by the Management Information Department of DPD caused quite a stir. Their Management Action Optimization (MAO) program would be written using the new Linear Interpretation Nucleus (LIN), part of DOS extended. This occurred, it was rumored, in spite of persistent efforts by the Marketing Verification Department (MVD) to persuade them to use OS. This department is charged with the "purification" of TYPE II programming standards.

There were indications, however, that something was in the air. The OS Internals Workshop was extended from 13 weeks to 26 weeks. A resident psychiatrist was installed to try to cut down on nervous breakdowns, defections, and AWOL's. A blue letter advised salesmen that "throughput" and "turnaround time" were not to be used. The byword was to be "full utilization of system resources." At all costs, customers were to be discouraged from asking, "But when will my job be completed?"

Release 91.0 contained a module of the nucleus that stopped the software clock during system overhead time. Murmurs about the difference between meter time and time accounted for led to the removal of all meters and a shift from a 176 hour base to 264 hours per month. Dissatisfaction was increasing, however; one large scientific/engineering/commercial customer announced his intention to switch to a competitor, but after two years was unable to do so because he was unable to discover exactly what his system was doing.

The end finally came in mid-October. System Release 110.7 was distributed, which converted everyone to MPSS (Multiple Priority Scheduling System), which combined the following control program options:

Multiprogramming with a Valuable Number of Tasks
Multijob Initiation
Multiple Priority Secection
Multiprocessing with a Variable Number of CPU's

SYSGEN was accomplished with little difficulty in 504 system hours. Expectantly, customers IPLed and initiated their job streams.


Nothing Happened
Nothing.

When it slowly dawned on everyone that nothing was going to happen, now or later, a flood of anguished telephone calls swamped the branch offices. At Poughkeepsie, in turn, all extensions, all twenty-five thousand of them, were busy. Unauthorized vehicles were turned away at the entrance roads. The Director of Programming Systems could not be found.

At last a brave customer engineer fought his way through the crowd around his system and obtained a dump. As he scanned the hex, the horrible truth came home to him. All of core, as far as the eye could see, was filled with control blocks, each containing pointers to other control blocks. DADSM was allocating and suballocating, searching DSCB's and building new ones. Job Management was initiating new jobs, task management was creating tasks and ATTACHING and LINKING, data management was opening data sets, and building WTG tables, DCB's, DEB's, ECB's, and IOB's. It was finding TIOT's from tasks dispatched by task management, which pointed to JFCB's. But no programs were being executed. No data was being read or written or processed. Operating System had taken over all the system resources and was entirely occupied with issuing supervisor calls, saving registers, restoring registers, chaining forwards and backwards, and following pointers all over core. Every pointer led to some other pointer. Operating System, after several years of effort by thousands of programmers, had finally become a completely closed system.

The great dilemma was solved only through the intervention of the Chairman of the Board, who personally issued a black_boardered Blue Letter announcing the withdrawal of Operating System. A large bonfire was built in the Poughkeepsie parking lot in which a huge mountain of OS documentation was burned, while the local high-school band played a funeral dirge. Users all over the world wearily set to the task of rewriting using the BPS assemble. A new programming system was announced for delivery in two years, to be called Assembler Stacked Support (ASS). And everyone breathed a great sigh of relief and became happy for a time.



                    OS IS NOT TO REASON WHY . . .

(To the dune of "Everglades" and "The MTA", and with apologies to the
Kingston Trio, which does not necessarily include IBM.)

(sparkling guitar intro)

I. I was born and raised around Poughkeepsie, A programmer is what I had
to be; But IBM and its programming team Have turned me into a
debugging machine.

Running all my jobs under MVT.

CHORUS: Where a job can run and never be found, And all you see are
discs goin' 'round; And when you get your output the results are nil:
If the JCL don't get you then the systems will.

II. I put my job in the input queue.  And watched in awe as the system
blew.  When I reran the job, I felt really crushed; I saw on my
listing: INPUT STREAM DATA FLUSHED.

Running all my jobs under MVT.

CHORUS

III. I reran the job and ran out of space;
I reran the job with a step out of place;
I reran the job with priority 10 ... (pause)

"Will it ever return, no, it'll never return, And its fate is still
unlearned, It may hide forever in SYS1.LINKLIB..."

(pause)

Running all my jobs under MVT.

                                CHORUS

IV. Well, I couldn't get a job past the JCL hump,
So I never got a chance to read an ABEND dump,
    If I could get one through, I'd have debugging fun,
'Cause the job was in the language known as PL/I.

CHORUS

Getting lots of grief from this MVT.
Running line a thief 'way from MVT.
Getting round this mess via DOS.

(rousing guitar finale)


... snip ...

What's a mainframe?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What's a mainframe?
Newsgroups: bit.listserv.ibm-main
Date: Sat, 18 Nov 2006 07:09:21 -0700
phil@ISHAM-RESEARCH.FREESERVE.CO.UK (Phil Payne) writes:
There used to be a rule:

a) If you push it and it doesn't move, it's a mainframe.

b) If you push it and it moves, it's midrange.

c) If you can pick it up and steal it, it's a PC.

Now:

d) If it's a major source of p/r egg-on-face for a bank and causes a Financial Services Authority investigation, it's a hot laptop.
http://news.bbc.co.uk/2/hi/programmes/moneybox/6160054.stm


and

e) if its used to hack a ATM machine ... its an MP3 player
https://www.garlic.com/~lynn/aadsm26.htm#5 ATMs hacked using MP3 player
slightly related
https://www.garlic.com/~lynn/aadsm26.htm#6 Citibank e-mail looks phishy

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: Mon, 20 Nov 2006 09:09:57 -0700
"Terence" <tbwright@cantv.net> writes:
"Relocating code" is what any linker does with your Fortran subroutine and function object code. It's very easy to dump a module and work out how the compiler stores the resulting mixture of code, entry points and segmentation information. I always thought taking things apart help learn hjow to put stuff together.

recent posts in this thread mentioning the issue of relocable address constants
https://www.garlic.com/~lynn/2006t.html#30 Why these original FORTRAN quirks?
https://www.garlic.com/~lynn/2006t.html#39 Why these original FORTRAN quirks?
https://www.garlic.com/~lynn/2006u.html#1 Why these original FORTRAN quirks?

the issue in the os/360 paradigm (which has been carried on thru today) is that the relocatable objects are called *relocatable address constants* which tend to be liberally distributed thru the executable image. the loader/linker function requires fetching the executable image into the address space and then running thru that image, swizzling the relocatable address constants to correspond to the address the image was loaded.

this is one of the big issues that i faced doing paged map filesystem enhancements for cms in the early 70s ... misc. past posts
https://www.garlic.com/~lynn/submain.html#mmap

... all the pages mapped to virtual address space that contained relocatable address constants first had to be prefetched and modified before execution could even begin ... then the operating system then had the additional overhead of dealing with the modified pages ... even tho the executable image was nominally otherwise unchange.

the next issue was attempting to treat page mapped executable images as shared, read-only code ... the same (physical) copy appearing simulataneously in different address space ... possibly at unique address in each address space. unless there is some quantum effects where a relocable address constant can simultaneously take on a large number of different values ... and the appropriate value is automagically provided for the address space that is currently executing ... then it broke down.

lots of past posts about dealing with problem of relocatable address constants in a shared segment (same physical copy in different address space ... at potentially different addresses) paradigm.
https://www.garlic.com/~lynn/submain.html#adcon

basically, i had to rewrite the code to remove use of relocatable address constant in programs targeted for such shared segments. other infrastructures that supported such operations out of the box, would have collected all the relocable address constants in a different control structure ... not part of the executable image. each address space would have its own unique instruction address and set of registers. one of the registers would be used to address the control structure containing the appropriately adjusted relocable address constants.

What's a mainframe?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What's a mainframe?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 20 Nov 2006 09:33:13 -0700
m42tom-ibmmain@YAHOO.COM (Tom Marchant) writes:
Mainframes have been client/server for thirty years.

Remember when a "dumb terminal" was a 2741 or a tty? And a smart terminal was a 3270.

We had 370 --> 3705 --> 3274 --> 3270. Three tier client/server.


four tier hierarchical control structure?

previous ref:
https://www.garlic.com/~lynn/2006u.html#53 What's a mainframe?

my wife had co-authored AWP39 peer-to-peer networking in the early days of SNA ... which was oriented towards managing huge numbers of dumb terminals. she took a lot of grief .. and in fact, in most of the world, peer-to-peer is implicit in the term networking. SNA had co-opted networking to mean massive terminal communication environment ... so it became a requirement that when dealing with SNA oriented operations ... to prefix networking with peer-to-peer when talking about regular networking (as opposed to SNA).

later she was con'ed into going to POK to be in charge of loosely-coupled (mainframe) architecture. while there she originated Peer-Coupled Shared Data architecture (again notice the requirement for the term peer-to-peer when dealing with an SNA entrenched environment ... where in the rest of the world, peer-to-peer would be implicit).
https://www.garlic.com/~lynn/submain.html#shareddata

she didn't last long and left ... Peer-Coupled Shared Data not getting a lot of uptake (except for IMS hot-standby) until parallel sysplex came along.

i do claim that one of the reasons behind relatively rapid ibm/pc uptake was business customers being able to get dumb (3270) terminal emulation on ibm/pc. for about same cost as a 3270, an ibm/pc provided a single desk footprint with both dumb terminal emulation and some amount of local computing capability.
https://www.garlic.com/~lynn/subnetwork.html#emulation

however, in the later 80s, real client/server with PCs was starting to emerge. and we had come up with 3-tier architecture and were out making customer executive presentations. the mainstream was pushing something called SAA ... which could be construed as trying to cram the client/server genie back into the bottle (and return to dumb terminal emulation). we took a lot of grief from the SAA crowd for being out there pushing 3-tier architecture.
https://www.garlic.com/~lynn/subnetwork.html#3tier

we also took some grief for hsdt project
https://www.garlic.com/~lynn/subnetwork.html#hsdt

recent posting with some old EMAILs trying to do some stuff for NSFNET backbone (the operational precursor to the modern internet)
https://www.garlic.com/~lynn/2006t.html#6
6may85,
30sep85,
7apr86
https://www.garlic.com/~lynn/2006s.html#50
17apr86,
15may87

Ranking of non-IBM mainframe builders?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Ranking of non-IBM mainframe builders?
Newsgroups: alt.folklore.computers
Date: Mon, 20 Nov 2006 10:32:17 -0700
Anne & Lynn Wheeler <lynn@garlic.com> writes:
note that it was external visibility like this that got hsdt into political problems with the communication group ... in part, because there was such a huge gap between what they were doing and what we were doing.
https://www.garlic.com/~lynn/subnetwork.html#hsdt


other old email
https://www.garlic.com/~lynn/2006t.html#6 6may85, 30sep85, 7apr86
https://www.garlic.com/~lynn/2006s.html#50 17apr86, 15may87

past post with email from 1may86 discussing some of the same information
https://www.garlic.com/~lynn/2005d.html#13

more from long ago and far away

Date: 05/05/86 07:19:20
From: wheeler

re: hsdt; For the past year, we have been working with Bob Shahan & NSF to define joint-study with NSF for backbone on the super-computers. There have been several meetings in Milford with ACIS general manager (xxxxx) and the director of development (xxxxx). We have also had a couple of meetings with the director of NSF.

Just recently we had a meeting with Ken King (from Cornell) and xxxxx (from ACIS) to go over the details of who writes the joint study. ACIS has also just brought on a new person to be assigned to this activity (xxxxx). After reviewing some of the project details, King asked for a meeting with 15-20 universities and labs. around the country to discuss various joint-studies and the application of the technology to several high-speed data transport related projects. That meeting is scheduled to be held in June to discuss numerous university &/or NSF related communication projects and the applicability of joint studies with the IBM HSDT project.

I'm a little afraid that the June meeting might turn into a 3-ring circus with so many people & different potential applications in one meeting (who are also possibly being exposed to the technology & concepts for the 1st time). I'm going to try and have some smaller meetings with specific universities (prior to the big get together in June) and attempt to iron out some details beforehand (to minimize the confusion in the June meeting).


... snip ... top of post, old email index, NSFNET email

part of the visibility thing was that not too long after the above ... we found that somebody in the company was calling up and canceling meetings that we had scheduled with outside parties. somewhat related
https://www.garlic.com/~lynn/2006u.html#55 What's a mainframe

with such concerted opposition mounting inside the company, there wasn't a whole lot left we could do to continue with HSDT project.

one of the last HSDT gasps ... I figure they were planning on showing us .. we were asked to be the red team for the NSFNET2 backbone (upgrade from T1 to T3) and the blue team was something like 20-30 people from seven labs around the world. at the final review in corporate hdqtrs, it possibly didn't go exactly as they planned ... and resulted in what could be called the garbage truck manifesto for NSFNET2. a few previous posts mentioning the NSFNET2 garbage truck
https://www.garlic.com/~lynn/2000d.html#77 Is Al Gore The Father of the Internet?^
https://www.garlic.com/~lynn/2005d.html#13 Cerf and Kahn receive Turing award
https://www.garlic.com/~lynn/2005u.html#53 OSI model and an interview
https://www.garlic.com/~lynn/2006e.html#38 The Pankian Metaphor

we then got diverted into doing ha/cmp product and cluster scale-up ... one of the results
https://www.garlic.com/~lynn/95.html#13

the next time we were doing much internet stuff was when we were asked to do some consulting with a small client/server startup that wanted to do payment transactions on their server ... and two of the people from the meeting mentioned in the above post ... were now responsible for something called commerce server at the startup.
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

other posts in this thread
https://www.garlic.com/~lynn/2006s.html#40 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006s.html#41 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006s.html#42 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006s.html#43 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006s.html#51 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006t.html#6 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006t.html#11 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006t.html#12 Ranking of non-IBM mainframe builders?

Pedantry (was RE: Shane's antipodes)

Refed: **, - **, - **, - **
From: lynn@garlic.com
Subject: Re: Pedantry (was RE: Shane's antipodes)
Newsgroups: bit.listserv.ibm-main
Date: 20 Nov 2006 14:00:19 -0800
Zani, Alaimo , Bruno wrote:
As for a citizen of the UK, he or she is normally referred to as "Inglese" or "Britannico", interchangeably. For more accuracy, one can also use "Scozzese" (from Scotland, "Gallese' (from Wales), "Nord-Irlandese', (from Nord-Ireland), "Londinese" (from London), etc...

about a year ago, we visited Edinburgh.

Shortly before the visit, we had bought a BBC DVD on the history of Great Britian. The BBC show supposedly wasn't very popular in England because it supposedly told much of the history as it actually was ... rather than how it was rewritten to make England look better. they listed some number of the slaughters that England did on the scotts ... wiping out whole areas (similar stuff in Ireland).

the Edinburgh castle military museums seem to have taken the cleaned up English history.

the BBC show had the English wiping out whole areas, taking all the land and leaving most of the remaining people w/o property ... and about the only occupation left for males was various branches of the military or immigration. the military museum didn't mention any of that ... just that all the young men signed up for the military because they were so patriotic and brave.

the Edinburgh castle military museum listed the men killed at Gillipoli but not much else. the BBC show made much about how the English commanders were so incompetent and managed to kill huge numbers of irish, scotts, australians, etc. there was some mention that possibly one reason that Ireland tried to stay neutral in ww2 was the slaughters perpetrated on the Irish by British commanders in ww1 at places like gillipoli

after we got back, I was watching an old (ww1 flavor) Black Adder show ... one of (Mr Beans) lines was ... when we see an man in a skirt, we run him through and nik his land.

and for some other scottish drift
https://www.garlic.com/~lynn/2006r.html#47
https://www.garlic.com/~lynn/2006b.html#30
https://www.garlic.com/~lynn/2005n.html#14

What's The Best Computer and Why

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What's The Best Computer and Why
Newsgroups: alt.folklore.computers
Date: Wed, 22 Nov 2006 11:25:13 -0700
Roland Hutchinson <my.spamtrap@verizon.net> writes:
What: Lisp Machine

Why: In addition to its elegant architecture, you get the whole computer to yourself.


copies of old email mentioning lisp machine and 801
https://www.garlic.com/~lynn/2003e.html#65 801 (was Re: Reviving Multics
https://www.garlic.com/~lynn/2006c.html#3 Architectural support for programming languages
https://www.garlic.com/~lynn/2006o.html#45 "25th Anniversary of the Personal Computer"
https://www.garlic.com/~lynn/2006t.html#9 32 or even 64 registers for x86-64?

What's The Best Computer and Why

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What's The Best Computer and Why
Newsgroups: alt.folklore.computers
Date: Wed, 22 Nov 2006 15:58:42 -0700
"Charlie Gibbs" <cgibbs@kltpzyxm.invalid> writes:
What: VM/370

Why: Okay, maybe not quite so elegant an architecture, but you get a convincing impression that you have the whole computer to yourself.


and what about cp67?, i got to start play with it jan68.

Why these original FORTRAN quirks?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why these original FORTRAN quirks?
Newsgroups: alt.folklore.computers,comp.lang.fortran
Date: Wed, 22 Nov 2006 18:44:41 -0700
jmfbahciv writes:
And didn't IBM develop a philosophy of nailing down physical addresses before anything can get started? This makes sense if your sysetm is a data processing production system. You do not want to start a job that needed a resource which doesn't exist before the job is started.

I'm not saying this is "wrong". I'm saying that it's a different approach that has different side effects than waiting until the second the resource is needed to provide it.

My background is operating systems that had the "just in time" philosophy about resources; this deeply affects when relocation happens to code.


os/360 linker/loader resolved (relocatable address constant) addresses at the time the application was loaded (originally "real" addresses, but later on, applications were executed in virtual address space rather than real).

my complaints with the os/360 convention wasn't particularly the resolving ... it was that the convention had the relocation address constants distributed thruout the executable image. that caused problems when i did paged mapped filesystem for cms in the early 70s, it wasn't possible to just page map the executable image and then start execution ... the executable image had to be page mapped and then the linker/loader had to run thru (essentially) random locations in the executable image .... swizzling the relocatable address constants. this requires that some (nearly random) number of pages have to be prefetched by the link/loader and modified (before application execution can be begin). misc. past posts about doing page mapped filesystem support for cms
https://www.garlic.com/~lynn/submain.html#mmap

furthermore, it made impossible the page mapping of the same executable image into different virtual address spaces at different virtual addresses. misc. past post about trying to support page mapping the same executable image into different virtual address spaces at potentially different virtual addresses
https://www.garlic.com/~lynn/submain.html#adcon

other aspects of os/360 was that physical disk storage tended to be pre-allocated before the application started execution. on the other hand, from the start, the cms filesystem would dynamically each physical disk record as it was required. os/360 filesystem tended to get very good file locality ... while the cms mechanism could result in nearly random location for a file's physical records. when i did the cms filesystem enhancement for page mapping, i also added some semantics for supporting a degree of contiguous allocation.

for lots of other drift .... old email discussing r/o protection of shared images ... in the following "BNR" refers to Bell Northern Research

This is discussing "new" method for "protecting" shared segments introduced with release 3 of vm370. Originally, CMS had been reorganized to take advantage of the 370 "segment protect" feature. when that feature was dropped from 370 (as part of helping 370/165 meet schedule for retrofitting virtual memory), vm370 had to revert to the key-protect games used by cp67 for shared page protection.

The vm370 release 3 changes allowed, eliminated protection. instead, there was a page scan whenever there was task switch ... to check if the previous task had modified any shared pages. if a shared page had been found to be modified, it was discarded (and any subsequent reference would cause a page fault and retrieve of an unmodified copy from disk).

with multiprocessor support, they then had to add a unique copy of shared pages for every running processor.

the email also mentions performance enhancement to not bother with protection ... allowing any application in one address space to corrupt (shared) executable images potentially in use by large number of other applications.

Date: 04/05/79 20:40:23
From: wheeler

FYI; BNR has done some testing on what the release 3 changed page checking is costing them. A 4-5 segment program moved into a discontiquous shared system was requiring about 10% more CPU to complete than running as a module (the changed page checking more than offset any reduction in CPU gained by not doing as much paging and not doing the I/O to load the module). The release 6 not checking code appears to worse than useless for most users (who ever thot of it in the 1st place). Most of the people who are in the tightest CPU bind also have the most users (possibly 200+ plus), it wouldn't take very many incidents of accidental, unpredictable segment modification to completely blow away all possible thru-put gains of using it. Maybe that could be minimized by having a timer driven routine which would run around once every 2-3 minutes checking for any changed pages (which were not be checked for) and abend CP (SVC 0). That would bring the system down and back-up again clean with a minimum of service disruption to the users. The other alternative is for 15-30 minutes to elapsed where everybody got the fealing that something was wrong, but nobody could quite fiqure out what. Hopefully a system programmer would be along to get them out of the mess (also PTR could even abend faster if a shared, changed page was ever selected). This also eliminates all the nasty buGs associated with DMKVMA and unsharing. You get a nice, clean abend that nobody has to worry about fixing (could even change CP so that it even bypasses taking a dump).

I haven't heard of anybody yet who is planning on using the release 6 feature to save the overhead of checking for changed pages in CMS. Maybe some installation that doesn't have very many people dependent on CMS (Of course in that case why are they worrying about the performance?).


... snip ... top of post, old email index

past posts about the vm370 release 3 change for "protecting" shared pages
https://www.garlic.com/~lynn/2005e.html#53 System/360; Hardwired vs. Microcoded
https://www.garlic.com/~lynn/2005f.html#45 Moving assembler programs above the line

https://www.garlic.com/~lynn/2005f.html#46 Moving assembler programs above the line
https://www.garlic.com/~lynn/2005j.html#54 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
https://www.garlic.com/~lynn/2006.html#13 VM maclib reference
https://www.garlic.com/~lynn/2006m.html#26 Mainframe Limericks
https://www.garlic.com/~lynn/2006m.html#54 DCSS
https://www.garlic.com/~lynn/2006u.html#26 Assembler question

Why these original FORTRAN quirks?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why these original FORTRAN quirks?
Newsgroups: alt.folklore.computers,comp.lang.fortran
Date: Wed, 22 Nov 2006 23:10:18 -0700
The first problem with taking an existing application and setting it up for common, shared executable across multiple virtual address spaces involved making sure that the executable image would work in read-only, protected storage. A lot of the applications from the period tended to have a lot of temporary working storage spread through-out the program. Portions of the code typically had to be rewritten to convert it for use in read-only, protected execution.

I had originally done the CMS paged mapped filesystem support and the shared execution support in the early 70s. A very small subset of that support was included in release 3 under the label "DCSS" (or discontiguous shared segments).

I had support that could take shared executable image directly from the CMS (paged mapped) filesystem. However, not only was there the relocatable address constant issue ... discussed in the previous posts
https://www.garlic.com/~lynn/2006u.html#54 Why these original FORTRAN quirks?
https://www.garlic.com/~lynn/2006u.html#60 Why these original FORTRAN quirks?

but also modifying existing application code that made used of internal working storage. Recent post that has quite a bit of RED editor discussion
https://www.garlic.com/~lynn/2006u.html#26 Assembler question

included an email from
3nov78 that makes a passing reference to modifying RED editor for execution in shared, protected storage.

this refers to RED having the necessary modifications between 3nov78 and 23may79. the "re-genmoding" (in the following email) refers to the CMS command with the modifications that supports automatically invoking the shared execution invokation from paged mapped filesystem.

NED is another (internal) editor from the period. APL is the APL interpreter. DSM is the "script" document format application ... i.e. supporting both script "dot" formating commands as well as GML (generalized markup language) format commands ... misc. past posts mentioning GML, SGML, HTML, XML, etc
https://www.garlic.com/~lynn/submain.html#sgml

Date: 05/23/79 19:14:12
From: wheeler

I've setup up the following and checked for storage alterations

RED NED
APL
and DSM

just by loading and re-genmoding them. RED and NED have been regen'ed with just segment 2 shared (RED has another 5-6 pages and NED has another 2-3 pages). APL was gen'ed with segments 2, 3, and 4 shared (it has another 1 or 2 pages). DSM was gen'ed with segments 2 and 3 shared (it has another 14-15 pages, it would be worthwhile to obtain the original DSM text decks and dummy the ending module location up to the next segment boundary so that segment 4 could also be shared). EDGAR is just slightly under 16 pages. It will also be necessary to obtain the original text for it so that its ending address is rounded up to a segment boundary so that it will have a shared segment. That takes care of the immediate modules that I know about that can be shared.

--

also re: APL; the APL we are running is 2.1 from PID. Talking to the science centers it was suggested that we obtain LA's APL for our production system. Among its other enhancements, their comment was that at least with LA's APL we would receive support as compared to the PID version (I assume they mean to imply PID version isn't answering and/or correcting any bug reports).


... snip ... top of post, old email index

misc. past posts mentiong DCSS:
https://www.garlic.com/~lynn/2001c.html#2 Z/90, S/390, 370/ESA (slightly off topic)
https://www.garlic.com/~lynn/2001c.html#13 LINUS for S/390
https://www.garlic.com/~lynn/2001i.html#20 Very CISC Instuctions (Was: why the machine word size ...)
https://www.garlic.com/~lynn/2002o.html#25 Early computer games
https://www.garlic.com/~lynn/2003b.html#33 dasd full cylinder transfer (long post warning)
https://www.garlic.com/~lynn/2003f.html#32 Alpha performance, why?
https://www.garlic.com/~lynn/2003g.html#27 SYSPROF and the 190 disk
https://www.garlic.com/~lynn/2003n.html#45 hung/zombie users ... long boring, wandering story
https://www.garlic.com/~lynn/2003o.html#42 misc. dmksnt
https://www.garlic.com/~lynn/2004d.html#5 IBM 360 memory
https://www.garlic.com/~lynn/2004f.html#23 command line switches [Re: [REALLY OT!] Overuse of symbolic
https://www.garlic.com/~lynn/2004l.html#6 Xah Lee's Unixism
https://www.garlic.com/~lynn/2004m.html#11 Whatever happened to IBM's VM PC software?
https://www.garlic.com/~lynn/2004o.html#9 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2004o.html#11 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2004p.html#8 vm/370 smp support and shared segment protection hack
https://www.garlic.com/~lynn/2004q.html#72 IUCV in VM/CMS
https://www.garlic.com/~lynn/2005b.html#8 Relocating application architecture and compiler support
https://www.garlic.com/~lynn/2005e.html#53 System/360; Hardwired vs. Microcoded
https://www.garlic.com/~lynn/2005f.html#45 Moving assembler programs above the line
https://www.garlic.com/~lynn/2005g.html#30 Moving assembler programs above the line
https://www.garlic.com/~lynn/2005j.html#54 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
https://www.garlic.com/~lynn/2005t.html#39 FULIST
https://www.garlic.com/~lynn/2006.html#10 How to restore VMFPLC dumped files on z/VM V5.1
https://www.garlic.com/~lynn/2006.html#13 VM maclib reference
https://www.garlic.com/~lynn/2006.html#17 {SPAM?} DCSS as SWAP disk for z/Linux
https://www.garlic.com/~lynn/2006.html#18 DCSS as SWAP disk for z/Linux
https://www.garlic.com/~lynn/2006.html#19 DCSS as SWAP disk for z/Linux
https://www.garlic.com/~lynn/2006.html#25 DCSS as SWAP disk for z/Linux
https://www.garlic.com/~lynn/2006.html#28 DCSS as SWAP disk for z/Linux
https://www.garlic.com/~lynn/2006f.html#2 using 3390 mod-9s
https://www.garlic.com/~lynn/2006i.html#23 Virtual memory implementation in S/370
https://www.garlic.com/~lynn/2006i.html#43 virtual memory
https://www.garlic.com/~lynn/2006j.html#36 The Pankian Metaphor
https://www.garlic.com/~lynn/2006m.html#53 DCSS
https://www.garlic.com/~lynn/2006m.html#54 DCSS
https://www.garlic.com/~lynn/2006m.html#56 DCSS
https://www.garlic.com/~lynn/2006o.html#53 The Fate of VM - was: Re: Baby MVS???
https://www.garlic.com/~lynn/2006q.html#27 dcss and page mapped filesystem
https://www.garlic.com/~lynn/2006s.html#17 bandwidth of a swallow (was: Real core)
https://www.garlic.com/~lynn/2006t.html#39 Why these original FORTRAN quirks?




previous, next, index - home