2007 Newsgroup postings (05/13 - 05/25) Lynn Wheeler

2007 Newsgroup Postings (05/13 - 05/25)

IBM Unionization
VLIW pre-history
John W. Backus, 82, Fortran developer, dies
IBM Unionization
IBM Unionization
IBM Unionization
VLIW pre-history
VLIW pre-history
IBM Unionization
IBM Unionization
IBM Unionization
IBM Unionization
IBM Unionization
IBM Unionization
Some IBM 3033 information
Data Areas Manuals to be dropped
John W. Backus, 82, Fortran developer, dies
John W. Backus, 82, Fortran developer, dies
Another "migration" from the mainframe
Another "migration" from the mainframe
John W. Backus, 82, Fortran developer, dies
John W. Backus, 82, Fortran developer, dies
Another "migration" from the mainframe
Another "migration" from the mainframe
IBM Unionization
IBM 360 Model 20 Questions
user level TCP implementation
user level TCP implementation
IBM 360 Model 20 Questions
Even worse than UNIX
IBM Unionization
DEC and news groups
SSL Security
Even worse than UNIX
IBM Unionization
DEC and news groups
DEC and news groups
DEC and news groups
John W. Backus, 82, Fortran developer, dies
VLIW pre-history
DEC and news groups
DEC and news groups
IBM Unionization
John W. Backus, 82, Fortran developer, dies
Why Ping Requires RAW Sockets?
10 worst PCs
John W. Backus, 82, Fortran developer, dies
John W. Backus, 82, Fortran developer, dies
John W. Backus, 82, Fortran developer, dies
VLIW pre-history
John W. Backus, 82, Fortran developer, dies
IBM Unionization
John W. Backus, 82, Fortran developer, dies
My Dream PC -- Chip-Based
John W. Backus, 82, Fortran developer, dies
My Dream PC -- Chip-Based
My Dream PC -- Chip-Based
John W. Backus, 82, Fortran developer, dies
3350 failures
John W. Backus, 82, Fortran developer, dies
3350 failures
My Dream PC -- Chip-Based
3350 failures
My Dream PC -- Chip-Based
Even worse than UNIX
Non-Standard Mainframe Language?
The top 10 dead (or dying) computer skills
Non-Standard Mainframe Language?
John W. Backus, 82, Fortran developer, dies
The top 10 dead (or dying) computer skills
IBM System/360 signs above control panels - different styles - why?
The top 10 dead (or dying) computer skills
The top 10 dead (or dying) computer skills
Non-Standard Mainframe Language?
Non-Standard Mainframe Language?
John W. Backus, 82, Fortran developer, dies
My Dream PC -- Chip-Based
The top 10 dead (or dying) computer skills
John W. Backus, 82, Fortran developer, dies
John W. Backus, 82, Fortran developer, dies

IBM Unionization

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Unionization
Newsgroups: alt.folklore.computers
Date: Sun, 13 May 2007 12:22:47 -0600

re:
http://www.garlic.com/~lynn/2007e.html#48 time spent/day on a computer
http://www.garlic.com/~lynn/2007j.html#74 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#75 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#77 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#83 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#94 IBM Unionization

in the middle of my discussions with HR ... i had sent an email to one of my first managers after joining, asking about the issue. there was some attempt to charaterize the situation as an issue with HR involving wage/price controls.

supposedly the first raise after joining was a token raise ... the real substantial raise was the 2nd after joining. unfortunately my 2nd raise was scheduled a week or two after wage/price freeze went into effect. when the freeze was lifted ... things were still limited to what was specified by the govs. wage/price control. those three data points (initial pay and 1st two raises) hypothetically established a pay raise curve/slope that HR was going to follow for the rest of my life ... regardless of any accomplishments or experience. turns out that curve was much lower than the avg. increase in starting pay for new hires ... so a hypothetical case could be made that i was being increasingly penalized for experience and/or any accomplishments (i.e. the discrepancy between what i was paid and what they were offering new hires was increasing over time).

there was this science fiction story about a society based on workers with brain imprints that occurred at a specific chronological age ... approximately on reaching "maturity". the highest paid workers were the newest ... since they had the most recent and most technologically advanced brain imprints. as workers got older ... their brain imprints became more & more technologically outdated (nothing in society provided for experience and/or learning ... all knowledge supposedly was directly derived from brain imprints that could only occur once in a lifetime at a young age).

in this particular incident, there was a correction involving a series of pay raises that brought pay level up to the same as what was being offered new hires (that i had been interviewing to work under my direction ... partially negating any hypothetical pay/compensation penalty for having experience and/or having made accomplishments) ... aka as per prior posts, i found i was interviewing new hires that would be working at my direction and they were being offered starting offers 1/3rd more than i was earning (after more than a decade with the company); my initial enquiry into HR/management was met with reply that I was making exactly what I was supposed to be making; it was only later, when i showed that i knew what they were offering the new hires, that any action was taken (to bring me up to the same level as what they were offering the new hires that i had been interviewing).

again all this happened in supposedly one of the best managed corporations in the country.

VLIW pre-history

Refed: **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: VLIW pre-history
Newsgroups: alt.folklore.computers,comp.arch
Date: Sun, 13 May 2007 12:41:37 -0600

Quadibloc <jsavard@ecn.ab.ca> writes:
The meaning of VLIW includes *superscalar*: unless you are independently executing separate microcode streams for fields in your source instruction, or generating microcode on the fly - in which case, it isn't microcode anymore, you have a decoupled microarchitecture, which _can_ be superscalar - it's pretty hard for a conventionally microcoded machine to be superscalar.

re:
http://www.garlic.com/~lynn/2007j.html#84 VLIW pre-history
http://www.garlic.com/~lynn/2007j.html#95 VLIW pre-history
http://www.garlic.com/~lynn/2007j.html#96 VLIW pre-history
http://www.garlic.com/~lynn/2007j.html#97 VLIW pre-history

for some other pre-history ... one of the primary itanium wide-word architects is mentioned in this recent posting with cornell/hasp reference:
http://www.garlic.com/~lynn/2007j.html#79 IBM 360 Model 20 Questions

misc. past references on the same subject:
http://www.garlic.com/~lynn/2006.html#39 What happens if CR's are directly changed?
http://www.garlic.com/~lynn/2006e.html#1 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006o.html#67 How the Pentium Fell Short of a 360/195
http://www.garlic.com/~lynn/2006u.html#32 To RISC or not to RISC

John W. Backus, 82, Fortran developer, dies

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Sun, 13 May 2007 13:33:04 -0600

Greg Menke <gdmnews@toadmail.com> writes:
I think "runnable" means "ready to run", meaning whatever event the task was waiting on has signalled, or some other system activity awoke the task. Essentially, the task descriptor being in the queue of tasks that can be scheduled vs the queue of tasks that are "asleep" for some reason.

aka ... in cp67 and vm370 ... runnable was that there were no events blocking execution ... except possibly the availability of cpu resources .... i.e. all tasks that were actively executing and/or could execute (pending the availability of cpu resources) were "runnable". if the avg. number of runnable tasks were far in excess of the avg. number of executing tasks, that could be considered an indiciation of cpu constrained/bottlenecked environment.

then there were "eligible" ... all tasks that were otherwise runnable except there weren't sufficient real memory resources available to devote to their execution. "runnable" tasks were typically moved to "eligible" as a means of throttling page thrashing. the transition to "eligible" may or may not have involved something akin to swapping (aka removal of all of a tasks virtual pages from real storage) based on additional resource constraint considerations.

misc. past posts about resource manager & scheduling
http://www.garlic.com/~lynn/subtopic.html#fairshare
misc. past posts about page replacement algorithms, page thrash controls, etc
http://www.garlic.com/~lynn/subtopic.html#wsclock

IBM Unionization

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Unionization
Newsgroups: alt.folklore.computers
Date: Sun, 13 May 2007 13:38:21 -0600

Anne & Lynn Wheeler <lynn@garlic.com> writes:
again this happened in supposedly one of the best managed corporations in the country.

re:
http://www.garlic.com/~lynn/2007e.html#48 time spent/day on a computer
http://www.garlic.com/~lynn/2007j.html#74 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#75 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#77 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#83 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#94 IBM Unionization
http://www.garlic.com/~lynn/2007k.html#0 IBM Unionization

for slightly other drift:

misc. past posts about being told that the best we could hope for was to not be fired and be allowed to do it again:
http://www.garlic.com/~lynn/2003h.html#21 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003i.html#71 Offshore IT
http://www.garlic.com/~lynn/2007.html#22 MS to world: Stop sending money, we have enough - was Re: Most ... can't run Vista
http://www.garlic.com/~lynn/2007.html#26 MS to world: Stop sending money, we have enough - was Re: Most ... can't run Vista
http://www.garlic.com/~lynn/2007e.html#48 time spent/day on a computer

misc. past posts referencing being told they could have forgiven me for being wrong but they were never going to forgive me for being right
http://www.garlic.com/~lynn/2002k.html#61 arrogance metrics (Benoits) was: general networking
http://www.garlic.com/~lynn/2002q.html#16 cost of crossing kernel/user boundary
http://www.garlic.com/~lynn/2003i.html#71 Offshore IT
http://www.garlic.com/~lynn/2004k.html#14 I am an ageing techy, expert on everything. Let me explain the
http://www.garlic.com/~lynn/2007.html#26 MS to world: Stop sending money, we have enough - was Re: Most ... can't run Vista

and, of course, there is Boyd's quote from the dedication of Boyd hall at Nellis AFB:
http://www.garlic.com/~lynn/2007.html#20 MS to world: Stop sending money, we have enough - was Re: Most ... can't run Vista
http://www.garlic.com/~lynn/2007h.html#74 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007j.html#61 Lean and Mean: 150,000 U.S. layoffs for IBM?

IBM Unionization

Refed: **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Unionization
Newsgroups: alt.folklore.computers
Date: Sun, 13 May 2007 14:23:15 -0600

John Byrns <byrnsj@sbcglobal.net> writes:
We had similar curves, but they didn't follow you for the rest of your life, I think you jumped to a different curve when you received a promotion. The curves were supposed to take experience into account, and IIRC were called "experience curves", accomplishments were assumed to be covered by promotions. I also remember a big push at one point to adjust some "wages" to insure that people were on the curve, I think this was related to the new hire issue you are talking about.

i don't believe that those curves were suppose to follow you the rest of your life either ... but that was a hypothetical explanation/story of why after nearly 15yrs, they were offering new hires 1/3rd more than i was making (i.e. because my pay never got adjusted????, these new hires that i was interviewing to work under my direction). The career history spanned a variety of different managers, organizations and HR depts ... it was nobody's responsibility and/or fault ... it was the fault of the nebulous, anonymous "system".

and the reason why HR came back after the first round of written exchanges and claimed that they had investigated my whole career and pay raises ... and I was making just exactly what i was suppose to; was that because nobody left in HR (at that time) had any institutional memory regarding the early 70s????

and also that the people in HR were totally incapable of comparing what I was currently making with the 1/3rd more they were offering new hires (which I was interviewing to work under my direction)????????

until i detailed it in writing during the 2nd round of (written) exchanges.

IBM Unionization

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Unionization
Newsgroups: alt.folklore.computers
Date: Sun, 13 May 2007 14:49:29 -0600

John Byrns <byrnsj@sbcglobal.net> writes:
IIRC even though the wage/price controls lasted approx. three years, they only affected one raise cycle, at least where I worked, and I think we also got a catch up raise to cover that after it was all over. Also the controls didn't cover wage increases that were the result of a promotion, I received a significant promotion during the wage control era, which pretty much mooted the issue for me.

i was relative new hire ... so there was no promotion until the late 70s ... long after the initial wage/price freeze and the subsequent wage/price control period ... and didn't result in any significant effect on overall pay.

the small exception in all this was a corporate award for having done the resource manager
http://www.garlic.com/~lynn/subtopic.html#fairshare

which in addition to bringing to mind the Boyd scenario ... seen in the quote from the dedication of Boyd hall at Nellis AFB:
http://www.garlic.com/~lynn/2007.html#20 MS to world: Stop sending money, we have enough - was Re: Most ... can't run Vista
http://www.garlic.com/~lynn/2007h.html#74 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007j.html#61 Lean and Mean: 150,000 U.S. layoffs for IBM?

reminded me of the pencils made up by the processor engineering manager in POK ... with election spoof on running for job of POK lab director with a platform promising promotions or raises ... but not both. past posts/references
http://www.garlic.com/~lynn/2000b.html#60 South San Jose (was Tysons Corner, Virginia)
http://www.garlic.com/~lynn/2000d.html#38 S/360 development burnout?
http://www.garlic.com/~lynn/2006m.html#22 Patent #6886160
http://www.garlic.com/~lynn/2007j.html#66 Help settle a job title/role debate

or the line about the best could hope for was to not be fired and be allowed to do it again.
http://www.garlic.com/~lynn/2007k.html#3 IBM Unionization

VLIW pre-history

Refed: **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: VLIW pre-history
Newsgroups: alt.folklore.computers,comp.arch
Date: Sun, 13 May 2007 22:24:00 -0600
Quadibloc <jsavard@ecn.ab.ca> writes:

Actually, even with the high-speed multiply feature, it only retired 12 bits of the multiplier at a time - just like the 360/91, from whence it came - but keeping *multiple functional units* fully busy on computations related to the problem isn't possible in that kind of classic microcoded architecture, no matter how horizontal the microcode. No more than one instruction - one basic operation - per cycle.

it would appear that the original question/issue is being changed in real time????

so now with a great deal of such confusion and obfuscation then take itanium wide-word and call it VLIW ... unless somebody happen chance to port one of the i86 370 emulators to itanium ... and used it to (also) emulate (non superscaler) 370 instruction ... and then forever forth it would no longer be permissable to claim itanium wide-word was VLIW.

the original issue was whether or not the horizontal microcode capability used in various highend 370 processors, various mainframe channel units, and mainframe disk controllers, could be considered equivalent to VLIW with its highly parallel execution.

the original issue had nothing at all to do with specific machines where horizontal microcode was used to emualtion 370 instructions .... and/or whether or not those 370 instructions emulated appeared to be superscaler.

then there was description of horizontal microcode which meets the definition.

now it appears that if the horizontal microcode was used to emulate 370 opcodes ... and if the emulated 370 execution wasn't superscaler ... then the parallel, superscaler operations performed by the horizontal microcode couldn't meet the definition of VLIW.

what happens if the same/similar horizontal microcode for implementing highly parallel operations other than emulation of 370 instruction ... for instance integrated channel i/o operation and/or disk controller units doing highly parallel operation?????

So the situation now appears that if horizontal microcode was used to emualte 370 instructions ... and the 370 instructions didn't meet somebody's definition of parallel, superscaler ... then the horizontal microcode capability that was used in the implementation ... also couldn't be considered parallel, superscaler.

However, if the same exact microcode engine ... with the same exact horizonal microcode instructions capability was used to implement highly parallel operations that weren't 370 instruction execution emulation ... but other types of parallel superscaler operations ... would it be allowed that operational horizontal micrcode be VLIW??????

at which point ... would it then be that horizontal microcode would be equivalent to VLIW when it was used in a program to do something other than 370 instruction execution ... but the same horizontal microcode engine/instructions would not be equivalent to VLIW when the horizontal micrcode program was emulating 370 instructions.

To some extent the limitation on the execution of 370 superscaler ... wasn't so much a limitation of the superscaler capability of the horizontal microcode ... but a limitation of the hardware resources that were available to the horizontal micrcode programer for the emulation of 370 instructions.

i.e. my understanding was that the original issue was whether or not the horizontal microcode used in these various hardware engines were VLIW ... as opposed to whether or not a specific application (370 instruction emulation) implemented with horizontal micrcode might be considered VLIW.

re:
http://www.garlic.com/~lynn/2007j.html#84 VLIW pre-history
http://www.garlic.com/~lynn/2007j.html#95 VLIW pre-history
http://www.garlic.com/~lynn/2007j.html#96 VLIW pre-history
http://www.garlic.com/~lynn/2007j.html#97 VLIW pre-history
http://www.garlic.com/~lynn/2007k.html#1 VLIW pre-history

VLIW pre-history

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: VLIW pre-history
Newsgroups: alt.folklore.computers,comp.arch
Date: Sun, 13 May 2007 23:22:15 -0600

Anne & Lynn Wheeler <lynn@garlic.com> writes:
so now with a great deal of such confusion and obfuscation then take itanium wide-word and call it VLIW ... unless somebody happen chance to port one of the i86 370 emulators to itanium ... and used it to (also) emulate (non superscaler) 370 instruction ... and then forever forth it would no longer be permissable to claim itanium wide-word was VLIW.

re:
http://www.garlic.com/~lynn/2007k.html#6 VLIW pre-history

some itanium references possibly being considered VLIW

Inventing Itanium: How HP Labs Helped Create the Next-Generation Chip Architecture
http://www.hpl.hp.com/news/2001/apr-jun/itanium.html

Itanium is Intel's future
http://www.infoworld.com/article/04/09/10/37OPcurve_1.html

Analysis and Characterization of Intel Itanium Instruction Bundles for Improving VLIW Processor Performance
http://portal.acm.org/citation.cfm?id=1136267

about a decade ago we had a look at some of the issues of porting i86 370 emulator to itanium ... and while itanium may be considered vliw ... the 370 emulated execution on itanium wasn't vliw &/or superscaler.

IBM Unionization

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Unionization
Newsgroups: alt.folklore.computers
Date: Mon, 14 May 2007 08:37:23 -0600

jmfbahciv writes:
Project leaders didn't do the manager stuff.

re:
http://www.garlic.com/~lynn/2007j.html#94 IBM Unionization

project leaders never interviewed new project members and/or had any say in who got assigned to project???

IBM Unionization

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Unionization
Newsgroups: alt.folklore.computers
Date: Mon, 14 May 2007 09:16:55 -0600

jmfbahciv writes:
Oh, he would go walkabout. :-) It wasn't unusual for a manager to be hiring a technical person making more. When you headed that project, were you responsible for writing the performance and salary reviews? At DEC, this was a management task and you would have been classified as a manager, not a technical leader.

Project leaders didn't do the manager stuff.

this was never any mention about whether or not managers hiring technical person that might make more, i've never claimed it was ... (as repeatedly stated) it was a project leader interview prospective new project members and to (accidently) find out that the new hires were being offered starting salary 1/3rd more (new hires that i was interviewing to work under my direction)

it had nothing at all to do with management tasks ... it was extremely common for lead technical people to interview new hires. part of the issue was that many managers wouldn't have the in-depth technical background to assess the technical quality of the interviewee. it is probably in only extremely cookie-cutter positions that non-technical people were (solely) responsible for interviews (since it probably could be done with standardized questionaire and checklist and not required any qualified judgement).

I don't see where this constant confusion with doing new-hire interviews and the other kinds of administrative and management duties keeps croping up. there was never any mention of performance and salary reviews.

unless possibly i jump to a conclusion that DEC never bothered to have any qualified people involved in assessing the in-depth capability of potential new-hires ... and the confusion arises because DEC always restricted assesement of qualifications of interviewees to administrative and management types that were typically not qualified to make that judgement.'

IBM Unionization

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Unionization
Newsgroups: alt.folklore.computers
Date: Mon, 14 May 2007 11:09:33 -0600

hancock4 writes:
Are the balloon payments clearly written into the contract and understandable by sub-prime borrowers? I doubt it.

re:
http://www.garlic.com/~lynn/2007j.html#80 IBM Unionization

this followup posts reference to analysts seems to believe that it was ... with both the lenders and the home buyers being irresponsible ... turning blind eye(s) to future consequences.
http://www.garlic.com/~lynn/2007j.html#81 IBM Unionization

the TV news shows I've seen interviewing such (irresponsible) home buyers ... tend to all have them making some statement about having been foolish and ignoring the consequences (implying that they knew but ignored the information).

all the advertisements i've seen clearly state that the subprime introductory terms are for a specific limited period ... after which they revert to a normal loan. it is possible that there could be a case made that sufficiently functionally illiterate home buyers wouldn't be capable of understanding. maybe congress could be petitioned for special FTC legislation protecting the functionally illiterate and people not capable of even middle school arithmetic (special class between that of minors and adults).

things like points, escrow, etc ... tend to make the upfront closing costs more complex (but there tends to still be a standard bottom line)... modulo 1) upfront points reducing normal mortgage lending rate (which wouldn't tend to apply in subprime mortgages) and 2) upfront closing costs are added to total loan amount eliminating borrowers needing upfront cash. This is more complex than adding two numbers but it is on par with middle school arithmetic involving adding columns involving several numbers.

Note that second item is also on par with interest-only loan payments. however, there eventually tends to be a bottom line ... introductory period monthly payments and after introductory period monthly payments. the irresponsible lenders may tend to influence the irresponsible home buyers by pointing out that they can worry about what happens after the introductory period when it comes to it. other posts in the subprime mortgage subthread:
http://www.garlic.com/~lynn/2007j.html#48 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#82 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#92 IBM Unionization

posts in the functionally illiterate subthread:
http://www.garlic.com/~lynn/2007g.html#7 U.S. Cedes Top Spot in Global IT Competitiveness
http://www.garlic.com/~lynn/2007i.html#24 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#79 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007j.html#31 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#51 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#80 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#85 IBM Unionization

IBM Unionization

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Unionization
Newsgroups: alt.folklore.computers
Date: Mon, 14 May 2007 11:33:56 -0600

Dave Garland <dave.garland@wizinfo.com> writes:
Yeah, large cars were a mindset, but not so much due to actual physical needs, more due to the corporate marketing. I don't think unions cared one way or the other, so long as they were the ones to build the cars. The issues of robots and work rules and such don't have much to do with how big the cars are.

modulo there tended to be higher profit margin on (mass produced) bigger cars ... which tended to be one of the bargining chips in union negotiations (nearly everybody involved would have preferred higher profit margin).

this is somewhat related to the old article calling for 100percent unearned profit tax on the domestic car makers after import quotas were put in place. past posts with references
http://www.garlic.com/~lynn/2000f.html#41 Reason Japanese cars are assembled in the US (was Re: American bigotry)
http://www.garlic.com/~lynn/2001d.html#43 Economic Factors on Automation
http://www.garlic.com/~lynn/2004b.html#52 The SOB that helped IT jobs move to India is dead!
http://www.garlic.com/~lynn/2004h.html#22 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2005s.html#2 Internet today -- what's left for hobbiests
http://www.garlic.com/~lynn/2006.html#23 auto industry
http://www.garlic.com/~lynn/2006g.html#14 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#17 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#20 The Pankian Metaphor
http://www.garlic.com/~lynn/2006m.html#49 The Pankian Metaphor (redux)
http://www.garlic.com/~lynn/2007j.html#33 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#72 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#88 IBM Unionization

IBM Unionization

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Unionization
Newsgroups: alt.folklore.computers
Date: Mon, 14 May 2007 13:30:58 -0600

hancock4 writes:
It seems that every month my credit card carrier issues a new "policy", consisting of a booklet of fine print complicated text. I suppose if I had an evening to kill I could study and it figure it all out, but I don't have the time. Their last change was to average prior month's purchases into the finance charge, obviously to increase it. (I pay in full every month.) I think the cash advance rate is 24%, plus all sorts of transaction fees, and I probably could do better with the guy in the Cadillac parked at the dock.

the subprime mortgage companies have tended to be different than the financial institutions involved in payment cards. the reference mentioned in this post ... not only talks about both lenders and home buyers being irresponsible in the subprime market ... but also that something like 50 subprime lenders have gone out of business in the last two yrs.
http://www.garlic.com/~lynn/2007j.html#81 IBM Unionization

some past posts mentioning that US financial institutions get nearly 40percent of their bottom line from payment transactions.
http://www.garlic.com/~lynn/aadsm23.htm#35 3 of the big 4 - all doing payment systems
http://www.garlic.com/~lynn/2007c.html#38 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007i.html#71 Free Checking

in payment cards sort of are (modulo some of the merchant stored-value/gift cards):

• pin-debit • signature debit • credit card

the biggest revenue stream is in the credit card business with both consumer financial institutions benefiting (interest on accounts that carry month to month balances) and merchant financial institutions (significant discount on what actually goes to merchants). a couple posts that discount is the single largest expense for c-stores
http://www.garlic.com/~lynn/aadsm23.htm#37 3 of the big 4 - all doing payment systems
http://www.garlic.com/~lynn/2006e.html#26 Debit Cards HACKED now
http://www.garlic.com/~lynn/2006k.html#23 Value of an old IBM PS/2 CL57 SX Laptop
http://www.garlic.com/~lynn/2007.html#27 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#38 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007i.html#47 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#72 Free Checking

however, over the past 10yrs or so, there has been significant consumer shift to debit cards ... much of it at the expense of credit card transactions ... as well as reduction in the numbers carrying month-to-month credit balances.

signature-debit transactions effectively affects the revenue stream for consumer financial institutions (because there is no more month-to-month balance being carried). however the merchant financial institutions see approx. the same revenue as from credit transactions. a large part of the merchant discount fee is based on the infrastructure vulnerability to fraud, with signature debit and credit having similar fraud vulnerabilities and therefor similar discount rate charged merchants. some past references:
http://www.garlic.com/~lynn/aadsm22.htm#22 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/2006e.html#21 Debit Cards HACKED now
http://www.garlic.com/~lynn/2006e.html#24 Debit Cards HACKED now
http://www.garlic.com/~lynn/2007i.html#59 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007j.html#15 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007j.html#60 John W. Backus, 82, Fortran developer, dies

Study: Signature Debit Fraud Runs 15 Times Higher Than on PIN Debit
http://www.digitaltransactions.net/newsstory.cfm?newsid=738

pin-debit transactions affects revenue stream for both consumer and merchant financial institutions because there is both 1) no month-to-month balance being carried and 2) the fraud vulnerability is significantly less (and therefor the merchant discount is also significantly less).

from consumer stand-point, there is some advantages (liability and fraud resolution) to using credit (vis-a-vis signature-debit) and have the discipline to not carry month-to-month balance

IBM Unionization

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Unionization
Newsgroups: alt.folklore.computers
Date: Mon, 14 May 2007 13:53:47 -0600

re:
http://www.garlic.com/~lynn/2007k.html#12 IBM Unionization

note that in the references about nearly 40precent of US financial institutions' bottom line comes from payments ... it is less than ten percent for european financial institutions ...
http://www.garlic.com/~lynn/aadsm23.htm#35 3 of the big 4 - all doing payment systems
http://www.garlic.com/~lynn/2007c.html#38 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007i.html#71 Free Checking

which possibly helps account for some of the activity referenced in the following URLs (reducing payment card costs might have less of a bottom line impact on european financial institutions) ... for other topic drift ... possibly more (recent references) than you ever wanted to know:
EU banks in secret debit card talks
http://biz.yahoo.com/rb/070511/banks_payments_eu.html?.v=1
EU banks in secret debit card talks
http://business.scotsman.com/latest.cfm?id=730292007
European Banks Plotting Rival Debit Card Scheme?
http://www.epaynews.com/index.cgi?survey=&ref=browse&f=view&id=1179138211213202189192&block=
EU lawmakers back cheaper cross-border payments
http://www.neurope.eu/view_news.php?id=73543
Payment Services Directive pushed through by Parliament
http://www.euractiv.com/en/financial-services/parliament-waives-payment-services-directive/article-163368
European Business Guide: Payment Services Directive: Parliament adopts the proposal
http://www.businessupdated.com/shownews.asp?news_id=2391&cat=Payment+Services+Directive:+Parliament+adopts+the+proposal
Competitive Forces Shaping the Payments Environment: What's Next?
http://www.chicagofed.org/news_and_conferences/conferences_and_events/2007_payments_agenda.cfm
FRB: Speech, Kroszner--The Future of Payments: Challenges and Opportunities
http://www.federalreserve.gov/boarddocs/speeches/2007/20070510/default.htm

Some IBM 3033 information

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Some IBM 3033 information
Newsgroups: alt.folklore.computers
Date: Mon, 14 May 2007 17:54:07 -0600

who

1) was credited with dual-address space on the 3033?

2) worked on fort knox ... 801/risc starting circa 1980 to replace the myriad of existing corporate microcode engines?

3) was one of the prime architects of itanium/wide-word?

lots of past posts mentioning 801, risc, fort knox, iliad, romp, rios, etc
http://www.garlic.com/~lynn/subtopic.html#801

misc. past posts mentioning wide-word architects
http://www.garlic.com/~lynn/2006.html#39 What happens if CR's are directly changed?
http://www.garlic.com/~lynn/2006e.html#1 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006o.html#67 How the Pentium Fell Short of a 360/195
http://www.garlic.com/~lynn/2006r.html#24 A Day For Surprises (Astounding Itanium Tricks)
http://www.garlic.com/~lynn/2006u.html#32 To RISC or not to RISC
http://www.garlic.com/~lynn/2006w.html#14 IBM sues maker of Intel-based Mainframe clones
http://www.garlic.com/~lynn/2007j.html#97 VLIW pre-history
http://www.garlic.com/~lynn/2007k.html#1 VLIW pre-history
http://www.garlic.com/~lynn/2007k.html#6 VLIW pre-history
http://www.garlic.com/~lynn/2007k.html#7 VLIW pre-history

Data Areas Manuals to be dropped

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Data Areas Manuals to be dropped
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 14 May 2007 19:09:41 -0600

steve writes:
What is 'OCO' ? Thanks

there were several "OCO-wars" threads/discussion on vmshare. it was somewhat more of an issue in vm culture ... since source maintenance was standard and there were extensive amount of customer source changes available from waterloo/share library.

tymshare had provided online computer conferencing for share called vmshare starting in mid-70s; in part, because tymshare offered vm-based commercial timesharing service (later tymshare would also offer pcshare online computer conferencing) ... lots/misc posts about vm-based online commercial timesharing services
http://www.garlic.com/~lynn/submain.html#timeshare

vmshare archives here:
http://vm.marist.edu/~vmshare/

following is sample by doing a search on "oco war" in browse mode against all memo, note, and prob files.

OCO's 10th b'day
http://vm.marist.edu/~vmshare/browse.cgi?fn=OCO:BDAY&ft=MEMO

OCO & source business
http://vm.marist.edu/~vmshare/browse.cgi?fn=OCOBUS&ft=MEMO

issue sort of dates back to 23jun69 unbundling announcement with start to charge for application software. misc. past posts mentioning unbundling
http://www.garlic.com/~lynn/submain.html#unbundle

initially only application software was charged for ... using an excuse that kernel/system software was required for operation of the hardware.

later various circumstances precipitated decision to start charging for system software. this was about the time that my resource manager was going to be released ... so it got selected to be initial guinea pig for policty/practices related to kernel software charging.
http://www.garlic.com/~lynn/subtopic.html#fairshare

change to charging for software eventually also evolved into Object-Code-Only (i.e. OCO, no source).

recent post also mentioning 23jun69 unbundling announcement .... resulted in start charging for SE services.
http://www.garlic.com/~lynn/2007j.html#65 Help settle a job title/role debate

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Tue, 15 May 2007 07:59:24 -0600

ArarghMail705NOSPAM writes:
Well, that's not true. IBM had a drive, 2301?, that was a head per track drive. 4 platters, IIRC.

2303 and 2301 were head-per-track "drums". 2303 & 2301 were nearly identical, except the 2301 read/write four heads in parallel so had four times the data transfer rate of the 2303. 2301 picture
http://www.columbia.edu/cu/computinghistory/drum.html

later 2305-1 & 2305-2 were head-per-track, fixed-head disks, 2305 picture and specs:
http://www-03.ibm.com/ibm/history/exhibits/storage/storage_2305.html

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Tue, 15 May 2007 08:20:51 -0600

jmfbahciv writes:
When I met my first drum, they weren't fast and were used to swap in/out as a last resort; shuffling was the first attempt to make room for an incoming segment.

when cp67 was first installed at the university when i was an undergraduate ... the 2301 drum was used for demand paging. the device drivers weren't very sophisticated, they always did a single page transfer at a time, so there was an half revoluation latency on every transfer ... which hit a bottleneck around 80 page transfer operations/sec (with virtual memory hardware, individual pages didn't have to be contiguous and/or require that the be moved in any specific way).

recent head-per-track post
http://www.garlic.com/~lynn/2007k.html#16 John W. Backus, 82, Fortran developer, dies

i redid the drum driver so that it could chain together all queued requests into a single channel program ... arrainging the requests to maximize amount transferred per revolution (the 2301 channel program allowed for "switching" head selection on the fly ... so rotational sequential transfers didn't have to be on the same physical track). This increased 2301 page transfer capacity to 300/sec (from 80/sec).

the disk drivers also serviced requests FIFO ... and also didn't do any chained channel programs. I redid the general disk driver to support ordered seek queuing ... for all requests ... both paging and non-paging. This improved peak transfer of 2314 disks ... but also made for much more graceful degradation under heavy load. Also, for demand page disk i/o operations, I also did a chained request strategy (similar to drum strategy), except that could only chain requests for tracks at the same cylinder/arm position.

lots of past posts about page replacement algorithms, page i/o implementation, etc
http://www.garlic.com/~lynn/subtopic.html#wsclock

Another "migration" from the mainframe

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Another "migration" from the mainframe
Newsgroups: bit.listserv.ibm-main
To: <ibm-main@bama.ua.edu>
Date: Tue, 15 May 2007 09:00:10 -0600

Bob.Richards@ibm-main.lst (Richards.Bob) writes:
I wonder if they will reveal the costs of extra hw/sw for high-availability and business continuance associated with this migration. Probably not.

when we were doing the ha/cmp product, they were one of the customers we called on
http://www.garlic.com/~lynn/subtopic.html#hacmp

also, I had been asked to write a section in the corporate continuous availability strategy document. most of my writing got pulled because both Rochester and POK complained (that at the time, they couldn't meet what we were doing in ha/cmp).

it was also in this period that we coined the terms disaster survivability and geographic survivability (to differentiate from disaster/recovery)
http://www.garlic.com/~lynn/submain.html#available

for other drift, old email about what we had been doing about ha/cmp scaleup
http://www.garlic.com/~lynn/lhwemail.html#medusa

Another "migration" from the mainframe

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Another "migration" from the mainframe
Newsgroups: bit.listserv.ibm-main
To: <ibm-main@bama.ua.edu>
Date: Tue, 15 May 2007 09:33:21 -0600

howard@ibm-main.lst (Howard Brazee) writes:
I'd also like to see that with politics, but politician's pay is power, and that cannot be deferred. But it is more important for a President's policy to work for the long term than for a CEO's policy. Neither should be measured by "not on my term", but both should be measured by leaving a legacy that lasts. Build for the future - when the other guys are running the company/country.

i think that the comptroller general has suggested something similar for legislation ... that metrics are defined associated for any claimed benefits justifying some legislation ... and if the results fail to meet the metrics ... poof, its gone.

however, in speeches that the comptroller general has given over the past yr or so on some aspects of medicare/medicaid legislation ... he has commented that he doesn't believe any congressman in the last fifty yrs has been capable of middle-school arithmetic.

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Tue, 15 May 2007 10:37:02 -0600

Frank McCoy <mccoyf@millcomm.com> writes:
I was under the impression this newsgroup wasn't just about DEC.

some topic drift ... recent post about online computer conferencing provided by Tymshare starting in the mid-70s:
http://www.garlic.com/~lynn/2007k.html#15 Data Areas Manuals to be dropped

and thread about starting some computer conferencing stuff in the late 70s on the internal network ... followed by toolsrun ... which included mailing list as a subset ... but also could be configured to work more like usenet. somewhat a clone of the mailing list function evolved on bitnet ... and is responsible for the "bit.listserv" hierarchy that appears on some news servers (and currently there are various variations of listserv available and in-use on a number of different platforms)
http://www.garlic.com/~lynn/2007j.html#50 Using rexx to send an email
http://www.garlic.com/~lynn/2007j.html#54 Using rexx to send an email
http://www.garlic.com/~lynn/2007j.html#70 Using rexx to send an email

other posts mentioning bitnet and/or its european cousin earn:
http://www.garlic.com/~lynn/subnetwork.html#bitnet

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Tue, 15 May 2007 10:51:38 -0600

Frank McCoy <mccoyf@millcomm.com> writes:
The bottom platter had 32 heads riding on it permanently. The other five or ten (80meg/160meg) platters had single movable heads on them; and yes, about 700 tracks. The fixed heads needed lots of room between each of them for each head. Besides, heads were *expensive*.

another kind of head ... sort of alternative (and/or in addition) to horizontal and veritical recording ...
http://www.garlic.com/~lynn/2006s.html#email871230
in this post
http://www.garlic.com/~lynn/2006s.html#30 Why magnetic drums was/are worse than disks ?

from period when i was allowed to play disk engineer
http://www.garlic.com/~lynn/subtopic.html#disk

but also getting to play some 801/risc (and other) chip stuff
http://www.garlic.com/~lynn/subtopic.html#801

some old 801 specific email
http://www.garlic.com/~lynn/lhwemail.html#801

oh, and the person that wanted me to go with him regarding the head with 16+2 r/w surfaces (mentioned in the above email reference) was the person that was also responsible for 801.

Another "migration" from the mainframe

Refed: **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Another "migration" from the mainframe
Newsgroups: bit.listserv.ibm-main
To: <ibm-main@bama.ua.edu>
Date: Tue, 15 May 2007 11:05:33 -0600

re:
http://www.garlic.com/~lynn/2007k.html#18 Another "migration" from the mainframe
http://www.garlic.com/~lynn/2007k.html#19 Another "migration" from the mainframe

as an aside ... all the vendors that support server farms at least in the form of blade/GRID technology have done significant amounts of work on energy and cooling efficiency.

in fact, cooling was one of major concerns working on ha/cmp scaleup related to these old emails
http://www.garlic.com/~lynn/lhwemail.html#medusa

small sample re blade/grid energy efficiency

CIO Challenge: Energy Efficiency
http://www.wallstreetandtech.com/showArticle.jhtml?articleID=192202377

from above:
Like Fidelity, Wachovia has been targeting energy efficiency initiatives for the last 12 to 18 months or so. The initial spur was a move by the firm's traders in January to a new building in New York. "The three trading floors have relatively low ceiling heights, where it was not possible to put in a lot of air distribution, which meant we had to think creatively to ensure we don't have an unhealthy environment for the traders,"

... snip ...

and:

IBM Unveils New Energy-Efficient Blades
http://www.hpcwire.com/hpc/1379801.html IBM to focus on energy efficiency
http://www.bladewatch.com/2007/05/10/ibm-to-focus-on-energy-efficiency/
Blade innovations highlight energy efficiency opportunities
http://www.it-director.com/business/content.php?cid=9135
IBM defends blades' energy efficiency
http://green.itweek.co.uk/2006/10/ibm_defends_bla.html
IBM Data Center and Facilities Strategy Services - high density computing data center readiness assessment
http://www-935.ibm.com/services/us/index.wss/offering/its/a1025605

Another "migration" from the mainframe

Refed: **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Another "migration" from the mainframe
Newsgroups: bit.listserv.ibm-main
To: <ibm-main@bama.ua.edu>
Date: Tue, 15 May 2007 11:53:26 -0600

re:
http://www.garlic.com/~lynn/2007k.html#18 Another "migration" from the mainframe
http://www.garlic.com/~lynn/2007k.html#19 Another "migration" from the mainframe
http://www.garlic.com/~lynn/2007k.html#22 Another "migration" from the mainframe

lots of old posts mentioning working on our ha/cmp product ... and/or some loosely-coupled (dating back to at least when my wife had been con'ed into going to POK to be in charge of loosely-coupled architecture)
http://www.garlic.com/~lynn/subtopic.html#hacmp

when she was in POK, in charge of loosely-coupled architecture, she developed Peer-Coupled Shared Data architecture, which didn't see a lot of uptake (except for ims-hot standby) until parallel sysplex
http://www.garlic.com/~lynn/submain.html#shareddata

and a little followup of financial industry using blades/grids at the high-end ... including enabling them to do "real-time" trading algorithms ... something that they haven't been able to do before

Lots of Blade Server articles
http://www.eweek.com/category2/0,1874,1658862,00.asp

IBM Grid Computing Solutions - financial industry
http://www-03.ibm.com/grid/solutions/by_industry/financial.shtml

from above:
Optimized Analytic Infrastructure Drive higher margins and revenue growth by: • Turning creative quantitative insight into tested, supported, tradable investment products • Achieving near real-time and intraday decision making for on demand valuations and complex risk reporting in minutes • Reducing costs and enhancing standardization of existing analytic infrastructures

... snip ...

Grid Computing for Financial Services 2007
http://www.iqpc.com/cgi-bin/templates/genevent.html?topic=233&event=12603&

from above:
"70% of firms now deploy enterprise grids in key business areas" to maximise CPU power and business capability -- but are you really driving its development forward in your IT strategy?

... snip ...

Grid computing: Accelerating the search for revenue and profit for financial markets
http://www-03.ibm.com/industries/financialservices/doc/content/landing/973028103.html

IBM Unionization

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Unionization
Newsgroups: alt.folklore.computers
Date: Tue, 15 May 2007 16:11:08 -0600

Dave Garland <dave.garland@wizinfo.com> writes:
Or is this a nomenclature problem, are people really meaning that large (more expensive) cars have higher profits (though the percentage of profit may remain the same).

smaller cars tended to be sold into "economy" market segment ... and therefor they also tended to cut the profit margin as part of selling based on price

the large car scenaro/market tended to sell less on price ... and therefor the premium (and profit margin) could be higher

it is along the same lines that after the import quota that the foreign imports realized that they could sell the quota in "luxury" cars (at the high-end) with significantly larger profit margin ... than selling the same number at the low/economy end of the market.

the exception to small cars focusing on the economy market were some small cars in the luxury and/or specialty car category.

however, part of the claim for the 100 percent unearned profit tax was that the import quota was suppose to curtail the downward price pressure from the (economy) imports ... improving domestic profit which they would then spend on remaking the industry into much more competitive operation. however, when the increased profit was instead spent on wages, bonuses, and dividends ... there was the call for 100 percent unearned profit tax.

the whole thing was further aggravated by the fact that not only were the number of imports cut, reducing downward price pressure on domestic car prices ... but then the imports also totally changed the type of car they were selling (moving from the economy end to the luxury end) ... which supposedly allowed domestic car makers to nearly double the price of effectively the same automobile over a period of a few years.

IBM 360 Model 20 Questions

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 360 Model 20 Questions
Newsgroups: alt.folklore.computers
Date: Tue, 15 May 2007 18:50:05 -0600

John Byrns <byrnsj@sbcglobal.net> writes:
The BAS and BASR mnemonics were used for similar instructions added to the later 370 models, does anyone have a later system/370 program reference card who can tell me if these instructions used the same OP codes on the later 370s as were used on the Model 20?

360/370 BAL & BALR saved 24-bit instruction address and the 1byte cc/mask from the PSW in 32bit register. SPM instruction (04) would restore the cc/mask and then BR would return to the "calling" instruction (i.e. BAL/BALR typically used to call subroutines).

360/67 BAS & BASR saved 32bit instruction address from the PSW in 32bit register (i.e. 360/67 allowed for both 24bit and 32bit addressing modes). from 360/67 "blue card" ... parts posted here
http://www.garlic.com/~lynn/2001c.html#15 OS/360 (was LINUS for S/390)


BASR - 0D
BAS  - 4D

....

370 only had 24bit addressing and didn't need BAS/BASR

370-xa added 31bit addressing mode and BAS/BASR were re-introduced.

i've done a q&d conversion of the old gcard ios3270 to html
http://www.garlic.com/~lynn/gcard.html

instruction op-code table
http://www.garlic.com/~lynn/gcard.html#11


BASR - 0D
BAS  - 4D

user level TCP implementation

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: user level TCP implementation
Newsgroups: comp.protocols.tcp-ip
Date: Tue, 15 May 2007 23:18:15 -0600

"robertwessel2@yahoo.com" <robertwessel2@yahoo.com> writes:
When a user process does I/O, it usually prepares a channel program (using virtual addresses), and then uses an OS API (varies by OS, of course) to execute it. What the OS then does is paste in the page translation data (IDAWs), and issues the SSCH on the user program's behalf. Of course it validates that the user program is allowed to access the requested device in there somewhere. When the I/O operation completes (or otherwise generates an interrupt), the OS posts a semaphore back to the user application.

some additional mainframe i/o background and tcp/ip topic drift:

CP40 had been done by the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

for a custom modified 360/40 modified with virtual memory hardware. when standard 360/67 with virtual memory hardware became available, the science center morphed cp40 into cp67.

CP67 had a routine called CCWTRANS that would scan the address space virtual channel program (CCWs) and translate them into a "shadow" copy containing the real addresses in place of the virtual address space virtual addresses (at the same time "pinning" the virtual pages to the real addresses). the issue is that the channel transfer operations are all done with "real" addresses.

one of the problems that CP67 could run into on 360/67 were some timing problems. The "channel" operations were done synchronously, one CCW at a time, and the channel was not allowed to prefetch a CCW from processor memory ... until it was about to execute the CCW. In order to simulate a channel program that transferred data that crossed a virtual page boundary ... the translated channel program had to do data chaining (take one virtual CCW that specified one contiguous address transfer and break it into two separate CCWs that specified non-contiguous addresses for two contiguously addressed virtual pages and non-contiguous real addresses). the problem could be that fetching the 2nd CCW and decoding it ... while in the middle of data transfer ... get run into timing/overrun conditions.

for 370, IDAWs were introduced. a CCW rather than directly pointing at the real data transfer address ... would optionally point at a list of IDAWs (data transfer addresses). The difference between data-chaining CCWs and IDAWs was that while the channel architecture didn't allow prefetching the next CCW, channel architecture allowed for prefetching IDAW list ... mitigating the potential problem being able to perform non-contiguous data transfers.

now, when the i/o completes, the channel program has to be rescanned and the associated virtual pages "unpinned" from their real addresses.

as part of general available of virtual memory on 370 processors ... cp67 morphed into vm370 ... and other mainframe operating systems were modified to also support virtual memory. the original incantation of MVS, OS/VS2, started out as modified MVT operating system with some minimal support for single virtual address space and a copy of CP67's CCWTRANS crafted into the side (to provide translation of channel program CCWs with virtual addresses to real addresses).

Now, the original mainframe TCP/IP implementation was done in vs/pascal for vm370 (running in a virtual address space, latest nomenclature for such implementations is virtual appliance). It had some pathlength and bottleneck issues ... and could burn nearly a whole 3090 processor getting 44kbyte/sec aggregate thruput. I did the modifications for rfc 1044 support ... and in some testing at Cray Research between a Cray and a 4341-clone was getting aggregate 1mbyte/sec transfer using only a modest amount of the 4341-clone processor (i.e. around a factor of 500 times improvement in the bytes transferred per instruction executed). misc. past posts mentioning rfc 1044 support
http://www.garlic.com/~lynn/subnetwork.html#1044

for a little other drift, Coyotos is a Secure Operating System microkernel project that has worked on TCP/IP stack done outside the kernel
http://www.coyotos.org/

Coyotos is outgrowth of EROS
http://www.eros-os.org/
and CapROS
http://www.capros.org/

which trace back to KeyKOS system done for 370 mainframe
http://cap-lore.com/CapTheory/upenn/

Tymshare ... a vm370-based commercial time-sharing system ... misc. past posts
http://www.garlic.com/~lynn/submain.html#timeshare

had started GNOSIS operating system project in the late 70s for 370s. When Tymshare was bought by MD ... GNOSIS was spun off in Key Logic startup as KeyKOS (random trivia, I was brought in from the outside to do a audit/review of GNOSIS as part of that spin-off).

user level TCP implementation

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: user level TCP implementation
Newsgroups: comp.protocols.tcp-ip
Date: Tue, 15 May 2007 23:40:46 -0600

"robertwessel2@yahoo.com" <robertwessel2@yahoo.com> writes:
There's an older mechanism called the "Dual Address Space Facility," which is still supported, but only allows an application to access two address spaces at once, and with considerable restrictions as to which one is being used for what.

re:
http://www.garlic.com/~lynn/2007k.html#26 user level TCP implementation

recent post mentioning that the person responsible for dual-address space facility, also worked on 801/risc processors and then later was one of the primary itanium wide-word architects.
http://www.garlic.com/~lynn/2007k.html#14 Some IBM 3033 information

i.e. dual-address space facility was introduced in 3033.

part of the issue was that most of the corporation's effort had been directed to the future system project
http://www.garlic.com/~lynn/submain.html#futuresys

and much of the 370 oriented stuff had fallen by the way-side. when FS project was killed ... there was a rush to get stuff back into the 370 product line. now normally, it took 7-8 yrs to do a complete new generation ... and with the distraction caused by FS ... they would essentially be starting from scratch. while the full-blown new generation was put into process ... 303x was also a half-way stop-gap project to try and get something out in 3-4 yrs.

dual-address was part of that half-way stop-gap on 303x.

the "problem" was that the traditional batch operating system had an ingrained pointer-passing convention (left over from real address heritage when the kernel and all applications programs occupied a single address space). 370 was limited to 24-bit/16mbyte virtual address space ... recent comment:
http://www.garlic.com/~lynn/2007k.html#25 IBM 360 Model 20 Questions

the batch operating descendent, "MVS" would allow each application a 16mbyte virtual address space ... however, in large part because of the pointer-passing heritage, the MVS kernel was mapped into 8mbytes of each of those application 16mbyte virtual address spaces (leaving only 8mbytes for application). Also, OS/360 heritage had some number of "subsystem" services outside the kernel that were called/used by applications.

In the MVS world, subsystems were moved into their own private (application) virtual address space ... however, this created a problem for application to pass a pointer to such a subsystem and have the subsystem access the data. To resolve this, the COMMON segment was invented ... initially/nominally a 1mbyte shared area in every virtual address space where applications can stuff data, and pass a pointer to a subsystem service running in a different address space ... nominally leaving only 7mbytes in each virtual address space for application use. However, on large systems with lots of subsystem services ... the COMMON segment had to be expanded to five (or more) mbytes. This would leave only 3mbytes (or less) for application use ... in each virtual address space.

dual-address space (was sort of mini access register implemenation) and a way of an application passing a pointer to a subsystem service ... w/o first having to stuff the data into a common segment area. this helped control common segment size growing to infinity at customer installations with growing number of subsystem services

IBM 360 Model 20 Questions

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 360 Model 20 Questions
Newsgroups: alt.folklore.computers
Date: Wed, 16 May 2007 10:55:11 -0600

John Byrns <byrnsj@sbcglobal.net> writes:
The "IBM Journal Of Research And Development" reports that the BASR & BAS instructions had been added to the 370 instruction set prior to the release of 370-XA & 31-bit addressing mode.

re:
http://www.garlic.com/~lynn/2007k.html#25 IBM 360 Model 20 Questions

... but apparently in conjunction with dual-address space support.

padags paper (may '83)
http://www.research.ibm.com/journal/rd/273/ibmrd2703B.pdf

says BASR/BAS were "introduced recently in system/370"

and this reference for SLAC H-assembler (20Jul83)
http://gsf-soft.com/Documents/SLAC-MODS.shtml

from above:
All the mnemonics listed in GA22-7000-7 (1981, the edition of the System/370 Principles of Operation relevant to the 3081) are now defined in the opcode table. The added opcodes include: BAS, BASR, CLRCH, CONCS, DISCS, EPAR, ESAR, IAC, IPTE, IVSK, LASP, MVCIN, MVCK, MVCP, MVCS, PC, PI, SAC, SSAR, TB and TPROT.

... snip ...

so there were more than just BAS/BASR added.

this gives a history of changes in various editions of GA22-7000 (and instructions introductions)
http://www.research.ibm.com/journal/rd/273/ibmrd2703G.pdf

indicating BAS/BASR in same edition that introduced dual-address space support ... originally introduced late in 3033 product cycle ... some 3033 dates ... dual-address space shipped jun81:
http://www.garlic.com/~lynn/2000e.html#58

a recent post discussing dual-address space introduction for 3033
http://www.garlic.com/~lynn/2007k.html#27 user level TCP implementation

some trivia ... IPTE (also introduced late in 3033) had been in the original 370 virtual memory architecture (along with numerous other instructions and features) and was dropped as part of making up six month schedule slip retrofitting virtual memory hardware to 360/165, recent refs
http://www.garlic.com/~lynn/2007f.html#7 IBM S/360 series operating systems history
http://www.garlic.com/~lynn/2007f.html#14 more shared segment archeology
http://www.garlic.com/~lynn/2007f.html#16 more shared segment archeology

for other drift, padags paper says that 370-xa was started in 75 ... aka after future system was killed
http://www.garlic.com/~lynn/submain.html#futuresys

however for most of the "lifetime", 370-xa was known as "811" for the series of documents (and carried the security designation "confidential - restricted", each copy numbered and signed for ... and had to be kept under special lock & key).

Even worse than UNIX

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Even worse than UNIX
Newsgroups: alt.folklore.computers
Date: Wed, 16 May 2007 11:28:03 -0600

Michael Widerkrantz <mc@hack.org> writes:
I wasn't there either, but I've heard about the Knight TV terminals, which were hooked up to PDP-11s driving the terminals and then to a PDP-10 running the user applications, if I understand things correctly.

Of course, after that came the Lisp machines and their spaced out keyboards with lots of modifier keys. I've heard people joke about EMACS == ESC Meta Alt Control Shift.

there were the cord keyboards ... augment basically had something that was something of truncated piano keyboard.

there were some more sophisticated built internally, something that was something like a large mouse ... half-spherical that had depressions for the fingertips to fit into ... with racker switches under the fingertips. claim was that somebody used to doing 80wpm on qwerty would be able to do 120wpm on this keyboard. some old email
http://www.garlic.com/~lynn/2006v.html#email800401
http://www.garlic.com/~lynn/2006n.html#email800703

misc. past posts mentioning cord keyboards:
http://www.garlic.com/~lynn/2000g.html#31 stupid user stories
http://www.garlic.com/~lynn/2002g.html#4 markup vs wysiwyg (was: Re: learning how to use a computer)
http://www.garlic.com/~lynn/2004q.html#55 creat
http://www.garlic.com/~lynn/2005.html#47 creat
http://www.garlic.com/~lynn/2006n.html#50 stacks: sorting
http://www.garlic.com/~lynn/2006n.html#51 stacks: sorting
http://www.garlic.com/~lynn/2006v.html#22 vmshare

IBM Unionization

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Unionization
Newsgroups: alt.folklore.computers
Date: Wed, 16 May 2007 12:09:58 -0600

"Charlie Gibbs" <cgibbs@kltpzyxm.invalid> writes:
Someone recently pointed out to me that these people actually can read; they just can't write. Upon thinking about it, I realized that this is true. Such people can read a well-written sentence - but they couldn't create one themselves. I suppose writing is becoming like music - most people can recognize good music, but the actual performance of music can only be done well by a small number of people who are practiced in the art (karaoke singers notwithstanding).

i think the (1990) census was that (half of high school graduate aged individuals were) functionally illiterate was read/comprehend below some threshhold having to do with functioning in society.

one of the articles from the period made some point of increasing complex society was raising the "functionally illiterate" bar ... even if the education system were not to worsen over extended period ... and remained relatively static in the people they turned out ... that complexity increases with technology and society in general ... would result in an increasing percentage of society being functionally illiterate.

part of the concern was highlighted in the world comparable literacy study done in the 90s ... with the US coming in at or near the bottom of industrialized countries.

quick use of search engine for census and functionally illiterate ... turns up other references to the study done in the mid-90s with some discussion of what it actually means

for instance "level 1" not being able to read instructions on a bottle of medicine:
http://www.wsws.org/news/1998/oct1998/ill-o14.shtml

27percent of army enlistees can't read manuals written at the 7th grade level; US literacy ranks 49th among 156 UN countries.
http://www.covinaliteracy.org/facts.htm

90 million people in America who are functionally illieterate ... and only 22percent of current workforce have skills for the 21st century
http://www.roadtoreading.org/personal/dyk_facts.html

DEC and news groups

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: DEC and news groups
Newsgroups: alt.folklore.computers
Date: Wed, 16 May 2007 12:28:55 -0600

Frank McCoy <mccoyf@millcomm.com> writes:
Heck, MS-DOS was a direct steal of CP/M just reassembled to work on an 8086 (or 8088) based machine; swapping assembly-code for another instruction-set. Why not grab a *real* OS to work with instead of that?

and what was part of cp/m heritage? past references ...
http://www.garlic.com/~lynn/2004b.html#5 small bit of cp/m & cp/67 trivia from alt.folklore.computers n.g. (thread)
http://www.garlic.com/~lynn/2004e.html#38 [REALLY OT!] Overuse of symbolic constants
http://www.garlic.com/~lynn/2004h.html#40 Which Monitor Would You Pick??????
http://www.garlic.com/~lynn/2007d.html#41 Is computer history taugh now?

and this reference about origin of cp/m name ...
http://www.khet.net/gmc/docs/museum/en_cpmName.html
http://web.archive.org/web/20071011100440/http://www.khet.net/gmc/docs/museum/en_cpmName.html

and using cp67/cms at npg school.

SSL Security

Refed: **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: SSL Security
Newsgroups: microsoft.public.security
Date: Wed, 16 May 2007 12:44:58 -0600

Arne <Arne@discussions.microsoft.com> writes:
IS x.509 certificate the same as Public/private key pair?

identity x.509 digital certificates from the early 90s were frequently overloaded with personal information and eventually realized to represent a significant privacy and liability hazard.

digital certificates were introduced to solve a problem in the OFFLINE, electronic world ... somewhat analogous to the letters of credit/introduction from the sailing ship days (and before) where the relying party had no prior information about the party they were dealing with and no way of directly contacting any responsible party.

an example of the offline, electronic scenario is the email environment from the early 80s ... where there would be a dial-up to local electronic post-office, exchange email, and then hang-up. then when dealing with first time email from total stranger, the recipient had no way of determining what they were dealing with. digital certificates could provide trusted distribution of information about the stranger.

one of the pieces of trusted information distributed in this offline environment could be the stranger's public key ... allowing the recipient to verify any digital signature that had been generated by the stranger (with their private key).

another proposal from the early 80s for means of (real-time) trusted distribution of public key can be found in this old email:
http://www.garlic.com/~lynn/2006w.html#email810515

other discussions about real-time distribution of public key (and other information) can be found in these collected posts referencing a catch-22 situation for the SSL digital certificate certification authority industry (something they need to improve their integrity, but at the same time could result in obsoleting the need for them)
http://www.garlic.com/~lynn/subpubkey.html#catch22

and other collected past posts about SSL digital certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcert

Even worse than UNIX

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Even worse than UNIX
Newsgroups: alt.folklore.computers
Date: Wed, 16 May 2007 13:37:13 -0600

re:
http://www.garlic.com/~lynn/2007k.html#31 Even worse than UNIX

for some other cp67/cms topic drift from the period

comment about MIT student working at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

doing implementation for part of the original cp67/cms multi-level source update function:
http://www.garlic.com/~lynn/2001e.html#71 line length (was Re: Babble from "JD" <dyson@jdyson.com>)
http://www.garlic.com/~lynn/2002n.html#39 CMS update
http://www.garlic.com/~lynn/2003f.html#1 History of project maintenance tools -- what and when?
http://www.garlic.com/~lynn/2006o.html#19 Source maintenance was Re: SEQUENCE NUMBERS

having to do with attempting to merge multiple parallel source update sequences.

now these comments about most standardized security protocols are too heavy
http://www.garlic.com/~lynn/2007j.html#55 John W. Backus, 82, Fortran developer, dies

with reference to this thread in financial cryptography blog
http://www.garlic.com/~lynn/aadsm27.htm#0 H6.2 Most Standardised Security Protocols are Too Heavy
http://www.garlic.com/~lynn/aadsm27.htm#1 H6.2 Most Standardised Security Protocols are Too Heavy

now part of the above touches on proposal somewhat backed by the SSL domain name certification authority industry to improve the integrity of DNS, which they are dependent on with regard to establishing the true domain name owner and who is allowed to apply for SSL domain name certificates. mentioned in this recent post:
http://www.garlic.com/~lynn/2007k.html#32 SSL Security

however, there is a catch-22 that the solution could also obsolete the need for having the domain name certification authority industry
http://www.garlic.com/~lynn/subpubkey.html#catch22

relying on something more akin to what is mentioned in this old email
http://www.garlic.com/~lynn/2006w.html#email810515

the trivia x-over was that the MIT student (that worked on the merge of parallel updates) was later responsible for the internet DNS system
http://alum.mit.edu/ne/noteworthy/profiles/mockapetris.html

IBM Unionization

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Unionization
Newsgroups: alt.folklore.computers
Date: Wed, 16 May 2007 15:40:35 -0600

misc ...
http://www.garlic.com/~lynn/2007j.html#51 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#58 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#85 IBM Unionization
http://www.garlic.com/~lynn/2007k.html#30 IBM Unionization

based on functionally illiterate and other similar studies might conclude that our k12 education system is now the worst among industrial nations and our work force is hardly competitive for the 21st century, even with emerging and 3rd world countries.

DEC and news groups

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: DEC and news groups
Newsgroups: alt.folklore.computers
Date: Wed, 16 May 2007 16:50:28 -0600

Peter Flass <Peter_Flass@Yahoo.com> writes:
Wang?

then they got out of the hardware business ... marketing rs/6000, ps/2, and as/4000

Wang Joins I.B.M. in a Marketing Alliance
http://query.nytimes.com/gst/fullpage.html?res=9D0CE6DA113AF93AA25755C0A967958260

i seem to remember some number of people joining wang from austin when that happened.

about the same time ... honeywell/bull also relogo'ed rs/6000
http://febcm.club.fr/english/unix_and_bull.htm
http://findarticles.com/p/articles/mi_m0SMG/is_n14_v8/ai_7319525

some histories of computing ... from quicky search that found the above items
http://www.cyberstreet.com/hcs/museum/chron.htm
http://febcm.club.fr/english/information_technology/information_technology_4.htm

for slightly other honeywell/bull connection ... their world-wide support and services center in billerica, mass
http://www.bull.us/bull_services/index.html

was one of the HA/CMP early adopter installations (needing 7x24 high available operation)
http://www.garlic.com/~lynn/subtopic.html#hacmp

DEC and news groups

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: DEC and news groups
Newsgroups: alt.folklore.computers
Date: Wed, 16 May 2007 17:16:55 -0600

Frank McCoy <mccoyf@millcomm.com> writes:
Not to mention Burroughs, National Cash Register and even ... (Damn ... My memory is slipping ... What's the name of that company who became almost synonymous with word-processing for almost a decade?)

re (wang):
http://www.garlic.com/~lynn/2007k.html#35 DEC and news groups

NCR acquired teradata, one of the early "database machines" ... misc. past posts about early generation of database machines, teradata, britton-lee, etc (many of the same people show up in various database machine companies and the later rdbms companies):
http://www.garlic.com/~lynn/2000e.html#49 How did Oracle get started?
http://www.garlic.com/~lynn/2002.html#0 index searching
http://www.garlic.com/~lynn/2002.html#16 index searching
http://www.garlic.com/~lynn/2003c.html#75 The relational model and relational algebra - why did SQL become the industry standard?
http://www.garlic.com/~lynn/2003c.html#78 The relational model and relational algebra - why did SQL become the industry standard?
http://www.garlic.com/~lynn/2004p.html#0 Relational vs network vs hierarchic databases
http://www.garlic.com/~lynn/2005b.html#1 Foreign key in Oracle Sql
http://www.garlic.com/~lynn/2007e.html#63 FBA rant
http://www.garlic.com/~lynn/2007f.html#44 Is computer history taught now?

AT&T bought NCR. A lot of the OSF (open software foundation) was in reaction to sv4 licensing threats involving sun/att (and then ncr)

NCR timeline (acquired by AT&T, 1991)
http://www.thocp.net/companies/ncr/ncr_company.htm

NCR wiki (acquired by AT&T, 1991 and later spun off)
https://en.wikipedia.org/wiki/NCR_Corporation

teradata wiki (NCR announced plans to spin off this yr)
https://en.wikipedia.org/wiki/Teradata

OSF, apollo, bull, dec, hp, ibm, nixdorf, siemens, philips, hitachi ... wiki
https://en.wikipedia.org/wiki/Open_Software_Foundation

for the rdbms drift ... misc. past posts mentioning original relational/sql implementation
http://www.garlic.com/~lynn/submain.html#systemr

DEC and news groups

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: DEC and news groups
Newsgroups: alt.folklore.computers
Date: Wed, 16 May 2007 17:23:00 -0600

krw <krw@att.bizzzz> writes:
With the RAS of a mainframe? I doubt it.

slightly related recent thread from mainframe n.g.
http://www.garlic.com/~lynn/2007k.html#18 Another "migration" from the mainframe
http://www.garlic.com/~lynn/2007k.html#19 Another "migration" from the mainframe
http://www.garlic.com/~lynn/2007k.html#22 Another "migration" from the mainframe
http://www.garlic.com/~lynn/2007k.html#23 Another "migration" from the mainframe

mentions some stuff about ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp

and availability
http://www.garlic.com/~lynn/submain.html#available

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Wed, 16 May 2007 17:58:57 -0600

John Ahlstrom <AhlstromJK@comcast.net> writes:
What made the 2303 and 2301 "drums" and the 2305-1 and 2305-2 "disks"

re:
http://www.garlic.com/~lynn/2007k.html#16 John W. Backus, 82, Fortran developer, dies

take a look of the pictures ...

2303 & 2301 were physically drums with the magentic material covering the surface of the drum.

this is picture of 2301 ... you can sort of make out the geometry of the drum ... but the actual surface of the drum is somewhat obfuscated by all the r/w head assembly
http://web.archive.org/web/20060620002221/www.cs.ncl.ac.uk/events/anniversaries/40th/images/ibm360_672/slide12.jpg

this reference from the earlier posts doesn't show the drum area quite as clearly
http://www.columbia.edu/cu/computinghistory/drum.html

2305s were physically "disks" with multiple platters ... but instead of moving arm ... they had head-per-track on every surface.

this picture from the previous posting ... you can barely make out the platters:
http://www-03.ibm.com/ibm/history/exhibits/storage/storage_2305.html

wiki entry for hard disk and hard disk platter ... with some pictures (although showing moveable arm ... instead of head-per-track)
https://en.wikipedia.org/wiki/Hard_disk
https://en.wikipedia.org/wiki/Hard_disk_platter

i.e. fixed-head drum (2303/2301) had magnetic material on the surface of a physical "drum" (cylinder shapped object) and fixed-head disk (2305) had multiple flat disk platters.

the 2301 was nearly the same as 2303 except it read/wrote four heads in parallel for four times the data transfer rate.

for a little drift on disk technology ... this post
http://www.garlic.com/~lynn/2007k.html#21 John W. Backus, 82, Fortran developer, dies

a disk head with 16+2 read/write areas ... being able to get significantly higher density of tracks (i.e. reduce the space between tracks) ... getting much higher area bit density on disk surface ... from old email
http://www.garlic.com/~lynn/2006s.html#email871230

in this post from last year
http://www.garlic.com/~lynn/2006s.html#30 Why magnetic drums was/are worse than disks ?

another old email (in the same post) from the same period discusses (DASD operational characteristics) spacing required between tracks
http://www.garlic.com/~lynn/2006s.html#email871122

VLIW pre-history

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: VLIW pre-history
Newsgroups: alt.folklore.computers,comp.arch
Date: Wed, 16 May 2007 19:38:39 -0600

Quadibloc <jsavard@ecn.ab.ca> writes:
And, of course, the channels were *so* independent that they operated under autonomous control. Their operations were not controlled by the microcode in the CPU, as that microcode was busy handling whatever System/360 instruction the current program was executing at the time.

past refs:
http://www.garlic.com/~lynn/2007j.html#84 VLIW pre-history
http://www.garlic.com/~lynn/2007j.html#95 VLIW pre-history
http://www.garlic.com/~lynn/2007j.html#96 VLIW pre-history
http://www.garlic.com/~lynn/2007j.html#97 VLIW pre-history
http://www.garlic.com/~lynn/2007k.html#1 VLIW pre-history
http://www.garlic.com/~lynn/2007k.html#6 VLIW pre-history
http://www.garlic.com/~lynn/2007k.html#7 VLIW pre-history
http://www.garlic.com/~lynn/2007k.html#14 Some IBM 3033 information

lots of 360 & 370 processors had "integrated channels" ... nearly all of the low-end processors with vertical microcode ... same engine, one set of microcode that did the 370 instruction function ... and running on the same engine ... a set of microcode that did the channel function.

370/158 was horizontal microcode engine ... that had both 370 emulation horizontal microcode and integrated channel horizontal microcode ... running on the same horizontal microcode engine.

as pointed out several previous times ....for 303x ... the integrated channel and 370/158 (horizontal) microcode engine was repackaged into separate box called (303x) "channel director" (w/o the 370 emulation horizontal microcode).

the 3031 was a 370/158 (horizontal) microcode engine with only the 370 emulation (horizontal) microcode and w/o the integrated channel (horizontal) microcode ... and paired with a "channel director" box (i.e. a 370/158 horizontal microcode engine only running the integrated channel horizontal microcode).

the 3032 was 370/168 repackaged to use separate 303x "channel director"

the 3033 started out being 370/168 wiring diagram mapped to newer chip technology ... and packaged with one or more 303x "channel directors"

DEC and news groups

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: DEC and news groups
Newsgroups: alt.folklore.computers
Date: Wed, 16 May 2007 20:15:52 -0600

krw <krw@att.bizzzz> writes:
I taught a 6800 class (many times - what a bloody racket) within IBM, using 680Bs for labs. I'm quite familiar with them (built a couple from kits). I wish I could have salvaged one when it ended but they were watched like a hawk. They knew I was around.

mention of 6800 in 3101/topaz ...
http://www.garlic.com/~lynn/2006y.html#4 Why so little parallelism?
including old email
http://www.garlic.com/~lynn/2006y.html#email800311
http://www.garlic.com/~lynn/2006y.html#email800312
http://www.garlic.com/~lynn/2006y.html#email800314

DEC and news groups

Refed: **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: DEC and news groups
Newsgroups: alt.folklore.computers
Date: Thu, 17 May 2007 08:38:25 -0600

re:
http://www.garlic.com/~lynn/2007k.html#37 DEC and news groups

little more recent update

NY Stock Exchange Moves To Linux
http://linux.slashdot.org/linux/07/05/17/139256.shtml
NYSE undertakes IBM mainframe migration to Unix and Linux
http://searchdatacenter.techtarget.com/originalContent/0,289142,sid80_gci1254860,00.html

...

i.e. we spent some time talking to SIAC back when we were doing ha/cmp product
http://www.garlic.com/~lynn/subtopic.html#hacmp

NYSE buys out SIAC (i.e. www.siac.com is redirected to NYSE web site)
http://www.finextra.com/fullstory.asp?id=16076

slightly other drift, and then we were doing some work with NCSS ... and one of their people did AADS draft for NACHA trials ... since we weren't NACHA members
http://www.garlic.com/~lynn/nacharfi.htm
and
http://www.garlic.com/~lynn/x959.html#aads

NCSS part of DTCC
http://www.dtcc.com/AboutUs/affiliates.htm

IBM Unionization

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Unionization
Newsgroups: alt.folklore.computers
Date: Thu, 17 May 2007 13:17:54 -0600

hancock4 writes:
This is very true. It is very sad that in some areas kids still drop out of high school in large numbers. They are doomed to a life of failure. (Yes, I know there will be one dropout who becomes a millionaire, but 99.9% of the rest will suffer.)

The "bar" is much higher than the past. Many years ago there were factory or construction jobs for laborers. Dig a ditch. Put the wheel on and tighten the bolt. There'd be a forman to explain a fairly simple task and that was it. But so much of that very basic work has been mechanized or moved offshore. (Women could find similar work although their pay was a lot less).

re:
http://www.garlic.com/~lynn/2007k.html#30 IBM Unionization

in some of the same reports from the early '90s there not only was mention of half of the high school graduate aged individuals being "functionally illiterate" ... there was also comments about half the US workers/jobs were subsidized ... in effect the economic value of the work was less than the total benefits received (i.e. salary and any other benefits).

re:
http://www.garlic.com/~lynn/2007k.html#34 IBM Unionization

as the bar for functionally "literate" is raised, as society and technology becomes more complex (along with any futher decline in the US education system) ... it would seem that the percentage of workers that would have to be subsidized would increase (and/or see a decline in their standard of living).

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Fri, 18 May 2007 08:46:03 -0600

Brian Boutel <fake@fake.org> writes:
Does anyone remember the circumstances of IBM's first "decommit"?

the first time i heard it was for tss/360 ... they actually decommuted tss/360 a couple of times ... and it then continued to survive on into tss/370 and was used in AT&T special bid for hosting unix.

tss/360 was the official "time-share system" with virtual memory for 360/67 ... some of the early ctss, project mac, cp40, cp67, 360/67 (and tss/360 with decommits) history can be found in melinda's virtual machine history here
http://www.leeandmelindavarian.com/Melinda#VMHist

I was undergraduate when 3 people came out last week jan68 from science center
http://www.garlic.com/~lynn/subtopic.html#545tech

to install cp67 at the university. then i got sent to the spring (68) SHARE meeting in Houston where they "officially" announced cp67. that put cp67 in direct competition with tss/360 for customers with 360/67.

at one of the late night SHARE SCID sessions that week ... one of the main tss/360 developers and i almost got into a little more than strictly verbal altercation.

misc. past ssup (stripped down tss/370 kernel with unix services layered on top) posts
http://www.garlic.com/~lynn/2004q.html#37 A Glimpse into PC Development Philosophy
http://www.garlic.com/~lynn/2005b.html#13 Relocating application architecture and compiler support
http://www.garlic.com/~lynn/2005c.html#20 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005d.html#61 Virtual Machine Hardware
http://www.garlic.com/~lynn/2005s.html#34 Power5 and Cell, new issue of IBM Journal of R&D
http://www.garlic.com/~lynn/2006f.html#26 Old PCs--environmental hazard
http://www.garlic.com/~lynn/2006g.html#2 The Pankian Metaphor
http://www.garlic.com/~lynn/2006m.html#30 Old Hashing Routine
http://www.garlic.com/~lynn/2006p.html#22 Admired designs / designs to study
http://www.garlic.com/~lynn/2006t.html#17 old Gold/UTS reference
http://www.garlic.com/~lynn/2007.html#38 How many 36-bit Unix ports in the old days?
http://www.garlic.com/~lynn/2007b.html#3 How many 36-bit Unix ports in the old days?

Why Ping Requires RAW Sockets?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why Ping Requires RAW Sockets?
Newsgroups: comp.protocols.tcp-ip
Date: Fri, 18 May 2007 12:18:59 -0600

Jim Logajan <JamesL@Lugoj.com> writes:
Because the older edition of his book dealt with more than just the sockets API and morer than just the TCP/IP protocol, it was able to provide some genuine context for design decisions made in the APIs due to the alternate protocols that were still viable at the time.

OSI was being agreed to in ISO at about the same time that internetworking protocol was being formulated. the big difference was that OSI was a traditional single networking protocoal ... and the work on internetworking protocol was realization that it would be necessary to connect/internetwork lots of different networks.

OSI was never really viable ... it was just mandated by some number of govs. ... including in the states where there was a gov. directive to eliminate the internet and replace it with OSI ... along with stuff like GOSIP that continued (at least) into the early 90s.

there were numerous issues. ISO standards operation hasn't a requirement to demonstrate any operational or feasable implementation in order to be passed as standard ... while IETF has required demonstration of multiple, different, interoperable implementations.

ISO compounded the OSI problems with rules that there couldn't be any networking standards work on anything that violated OSI.

there was an attempt to get some high-speed protocol standardization work done in the ISO chartered ANSI X3S3.3 (US body responsible for networking standards). Work was declined because it violated OSI:

1) it supported LAN/MAC interface which violates OSI because the LAN/MAC interface sits somewhere in the middle of OSI layer 3.

2) it supported internetworking protocol which violates OSI because it is a non-existent layer (in the OSI model) that sort of sits between (OSI) layer 3 and (OSI) layer 4

3) it provided for going directly form transport/layer4 interface direct to LAN/MAC interface ... violating OSI by bypassing the interface between OSI layers 3&4.

10 worst PCs

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 10 worst PCs
Newsgroups: alt.folklore.computers
Date: Fri, 18 May 2007 12:52:41 -0600

charles hobbs <cph1776@gmail.com> writes:
> 4. Apple III (1980-1984) The "business" version of the Apple II. It had compatibility issues (wouldn't run all Apple II software), overheating and poor mechanical design (reportedly, you could "fix" a misbehaving III by lifting it off the desk by about a foot, then dropping it...

some other apple drift, lisa ... from some old email
http://www.garlic.com/~lynn/2007b.html#email830213
in this post
http://www.garlic.com/~lynn/2007b.html#56 old lisa info

somewhat related to this recent post in crypto mailing list discussing DRM and piracy
http://www.garlic.com/~lynn/aadsm27.htm#9 Enterprise Right Management vs. Traditional Encryption Tools

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Fri, 18 May 2007 18:51:24 -0600

Frank McCoy <mccoyf@millcomm.com> writes:
Did "decommit" come first, or "downsize"?

downsizing was in early 90s ... a couple past refs (starting with "flattening" management hierarchy)
http://www.garlic.com/~lynn/2007b.html#29 was: How many 36-bit Unix ports in the old days?
http://www.garlic.com/~lynn/2007e.html#18 Is computer history taught now?

... leading into being in the red in the 92 (and some real downsizing), some mention
http://www.garlic.com/~lynn/2006v.html#8 In Search of Stupidity
http://www.garlic.com/~lynn/2007j.html#20 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#91 IBM Unionization

the recent post about tss/360 decommit was in the late 60s ...
http://www.garlic.com/~lynn/2007k.html#43 John W. Backus, 82, Fortran developer, dies

in the middle of the big uptake of 360 and 370 and significant corporate growth.

part of this sort of can be seen in some commits that amdahl made at a talk he gave at mit in the early 70s ... when somebody in the audience asked what logic/argument did he use with the VC people to back his new company. he made some reference to there already being something like a couple hundred billion spent on 360 application softare ... and even if ibm were to totally walk away from 360/370 architecture (which possibly can be taken as veiled reference to future system project), that application software base would be enuf to keep him in computer business thru the end of the century.

collected posts mentioning future system project
http://www.garlic.com/~lynn/submain.html#futuresys

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Sat, 19 May 2007 23:27:28 -0600

blmblm@myrealbox.com <blmblm@myrealbox.com> writes:
However, as I understand it considerable progress has been made in the area of -- I think the current buzzword is virtualization -- having the machine running one operating system as the "real" o/s, and then being able to run one or more virtual machines on top of that, and have different o/s's running on the virtual machines. This may be more complex to set up -- and that's potentially a problem -- but avoids the need for reboots.

there was quite a lot of progress in virtualization between 1965 and 1969 ... along with the transition of cp40 to cp67; possibly not a whole lot of real changes in virtualization tho in the last 40yrs.

some of this can be see in melinda's history
http://www.leeandmelindavarian.com/Melinda/
http://www.leeandmelindavarian.com/Melinda#VMHist

lots of posts about science center at 545tech sq, including cp40, cp67 and numerous other activities
http://www.garlic.com/~lynn/subtopic.html#545tech

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

John W. Backus, 82, Fortran developer, dies

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Sun, 20 May 2007 08:18:29 -0600

Andreas Eder <andreas_eder@gmx.net> writes:
But you can have that already. You can run Windows in a virtual machine with vmware, qemu, virtualbox etc. And with newer processors supporting virtualizaion in hardware you can even run it under xen. All this runs beautifully under linux, or *BSDs. You can have that now! And it is not even difficult to setup. And shutting down a Windows running e.g. under vmware in linux without shutting down the pc always amazes the unwashed masses. :-)

re:
http://www.garlic.com/~lynn/2007k.html#47 John W. Backus, 82, Fortran developer, dies

past couple yrs, virtualization has been touted as countermeasure to lots of the compromises that have been affecting desktop machines, originating from their internet connections.

part of the issue is that a lot of the desktop machines evolved from a totally disconnected paradigm ... so they didn't need to have orientation that needed a fundamental metaphor (pemeating all aspects of the implementation) of constant defense (from the open and hostile internet connection). in fact, a lot of the market that grew up (like game market) adapted to being able to take-over all resources of the machines.

then trying to use the same implementation to address both the original market (somewhat assuming that all resources were freely accessable and available) and the extreme hostile and anarchy of the internet ... creating fundamental, diametrically opposing objectives.

the virtualization scenarios have a "padded cell" virtual machine, recent reference:
http://www.garlic.com/~lynn/2007i.html#26 Latest Principles of Operation

.... first done by the commercial cp67 & vm370 based commercial timesharing services in the late 60s and early 70s
http://www.garlic.com/~lynn/submain.html#timeshare

being created (even automagically) on the fly ... with extremely limited scope and an isolated browser being used for internet connectivity. when the internet session is completed, the whole environment is dissolved and anything that happened during the session is discarded. while the "native system" operation may have little or no defenses against hostile penetration from the internet ... the defenses and armoring comes from the isolation provided by the virtual machine boundary (and the subsequent total collapse/dissolve of whatever went on within that boundary).

old reference about the properties being used in the late '60s (again originally found in melinda's history)
http://web.archive.org/web/20090117083033/http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml

another "new" virtualization invention is the stuff sometimes referred to as virtual appliances ... which were originally called service virtual machines (again from the late 60s and early 70s).

VLIW pre-history

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: VLIW pre-history
Newsgroups: alt.folklore.computers,comp.arch
Date: Sun, 20 May 2007 08:30:32 -0600

"Jonathan Thornburg -- remove -animal to reply" <J.Thornburg@soton.ac-zebra.uk> writes:
The OED dates the term "pipe-line" to 1883, referring to both oil and water lines.

current day natural gas appears to have quite a bit of pipelinning ... including multiple day latency ... lots of weather modeling. if they don't start pumping in more gas, days before a cold snap ... they can have inadequate gas at the consumer end. if they are wrong and the cold snap doesn't occur ... they can have (over) pressure problems at the consumer end (infrastructure with pipelines stretching hundreds of miles from origin to destination).

most consumer water lines don't have quite the same long haul supply distances (any long haul typically having lots of intermediary staging areas).

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Sun, 20 May 2007 10:43:58 -0600

Anne & Lynn Wheeler <lynn@garlic.com> writes:
past couple yrs, virtualization has been touted as countermeasure to lots of the compromises that have been affecting desktop machines, originating from their internet connections.

re:
http://www.garlic.com/~lynn/2007k.html#48 John W. Backus, 82, Fortran developer, dies

slightly related posts in crypto mailing list and
http://www.garlic.com/~lynn/aadsm27.htm#12 Owned .gov machines (was Re: Russion cyberwar against Estonia?)
financial crypto blog
http://www.garlic.com/~lynn/aadsm27.htm#13 Is this Risk Management's Waterloo?

IBM Unionization

Refed: **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Unionization
Newsgroups: alt.folklore.computers
Date: Sun, 20 May 2007 13:31:31 -0600

re:
http://www.garlic.com/~lynn/2007k.html#12 IBM Unionization
http://www.garlic.com/~lynn/2007k.html#13 IBM Unionization

slight other topic drift:
When banks turn evil
http://articles.moneycentral.msn.com/Banking/BetterBanking/WhenBanksTurnEvil.aspx
The Stop Unfair Practices in Credit Cards Act
http://www.paymentsnews.com/2007/05/the_stop_unfair.html
CREDIT CARDS; Increased Complexity in Rates and Fees Heightens Need for More Effective Disclosures to Consumers
http://www.gao.gov/new.items/d06929.pdf
The Banking Crisis of the 1980s and Early 1990s: Summary and Implications
http://www.fdic.gov/bank/historical/history/3_85.pdf
The Profitability of Credit Card Operations of Depository Institutions
http://www.federalreserve.gov/boarddocs/rptcongress/creditcard/2006/default.htm
Report to the Congress on the Disclosure of Point-of-Sale Debit Fees
http://www.federalreserve.gov/boarddocs/rptcongress/posdebit2004.pdf
Differences in Capital and Accounting Standards among the Federal Banking and Thrift Agencies
http://www.federalreserve.gov/boarddocs/rptcongress/differences/2003.htm

... snip ...

this old, long winded post
http://www.garlic.com/~lynn/aepay3.htm#riskm The Thread Between Risk Management and Information Security

mentions the S&L situation from the 80s ... as well as citibank almost going under in the mid-80s ... basically from inadequant analysis of the effects/implications of variable rate mortgages (aka risk management, risk analysis, risk mitigation, etc).

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Mon, 21 May 2007 09:24:28 -0600

krw <krw@att.bizzzz> writes:
It can happen. VM doesn't know it's running under VM. Even MVS runs under VM without being able to tell it's being virtualized. Same with VM and MVS under LPAR. Linux under...

while there hasn't been much changes in the concept of virtualization from the beginning 40yrs ago
http://www.garlic.com/~lynn/2007k.html#47 John W. Backus, 82, Fortran developer, dies

one of the things that went on in the 70s and 80s was moving more & more of the virtualization down into the "hardware" (for efficiency). in effect LPARs are a subset of the virtualization software (doesn't do paging and a couple other things) moved into the hardware platform.

one of the current things that virtualization is being touted for is compensating processes for the security and integrity gaps in many current systems
http://www.garlic.com/~lynn/2007k.html#48 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007k.html#50 John W. Backus, 82, Fortran developer, dies

however, there can be issues with various of the signature scanning countermeasures ... i.e. software looking for evidence that the platform has already been compromised. the scenario is if the compromise has already happened at the level of the virtualization software ... then the scanning countermeasures aren't going to be able to detect the compromise.

at one end ... virtualization can be used as sort of a "virtual" airgap ... attempting to nullify any penetration and compromises (compensating processes for the lack of adequate countermeasures in the native systems). at the other end ... virtualization can be utilized by the bad guys as countermeasure to compromise scanning software.

there has been some cases of security software being touted as being able to provide adequate protection for secure transactions ... even on public machines (say found in libraries or internet cafes). however, if such public machines have compromized virtualization software ... all integrity checking/scanning software can be fooled.

for slight security/assurance topic drift
http://www.garlic.com/~lynn/aadsm27.htm#9 Enterprise Right Management vs. Traditional Encryption Tools

the early/original cp67 didn't provide for running cp67 under cp67 ... i.e. it provided for running virtual 360s ... but not for virtualization of virtual memory hardware ... although that was fairly quickly rectified ... recent thread/discussion
http://www.garlic.com/~lynn/2007i.html#14 when was MMU virtualization first considered practical?
http://www.garlic.com/~lynn/2007i.html#15 when was MMU virtualization first considered practical?
http://www.garlic.com/~lynn/2007i.html#16 when was MMU virtualization first considered practical?

My Dream PC -- Chip-Based

Refed: **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: My Dream PC -- Chip-Based
Newsgroups: alt.folklore.computers
Date: Mon, 21 May 2007 09:54:29 -0600

Charlton Wilbur <cwilbur@chromatico.net> writes:
But having an industrial-grade computer and firewall in every household won't help this. At some point, if you want to pay a bill, you need to instruct the bank to send money somewhere else, and at that point you still have the same problems of authentication and authorization. Or you'll want to download your statement from the bank, and you have the same problems.

a lot of existing compromises are evesdropping/skimming of "static" information that can turn around and used in replay attacks.
http://www.garlic.com/~lynn/subintegrity.html#harvest

quite of bit of this is discussed in the "naked" transaction/payment (and related) threads.
http://www.garlic.com/~lynn/subintegrity.html#payments

we had been called in to consult with small client/server startup that wanted to do some payment transactions on their server ... old reference
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

which has since come to frequently be referred to as electronic commerce.

subsequently we did some work in the x9a10 financial standards working group that in the mid-90s had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments.

part of the process was doing a in-depth, end-to-end vulnerabilty and threat assessement. the result was x9.59 financial standard
http://www.garlic.com/~lynn/x959.html#x959

related activity was that in the mid-90s there were a lot of comments floating around regarding infrastructures only being able to afford insecure chips for hardware tokens ... because secure chips were way too expensive ... some other activity from the same period
http://www.garlic.com/~lynn/subintegrity.html#yescard

... somewhat topic drift looking at the issue much earlier
http://www.garlic.com/~lynn/aadsm27.htm#9 Enterprise Right Management vs. Traditional Encryption Tools

in any case, i somewhat facetiously said that i was going to take a $500 milspec part and aggressively cost reduce it by 2-3 orders of magnitude while improving on the security and integrity. the result was the aads chip strawman
http://www.garlic.com/~lynn/x959.html#aads

... there were also some number of patents in the US and internationally, disclaimer: all assigned from the start and we have no rights/ownership
http://www.garlic.com/~lynn/aadssummary.htm

part of x9.59 financial standard was essentially "armoring" every transaction in such a way that no information from transactions could be used in replay attacks; aka each transaction could be public and it wouldn't provide sufficient information for an attacker to generate a fraudulent transaction.

from the security PAIN acronym

P ... privacy (or sometimes CAIN and confidentiality)
A ... authentication
I ... integrity
N ... non-repudiation

in effect, the earlier work (commoningly now called electronic commerce) involved something called SSL and privacy/confidentiality was used to "hide" transactions (as countermeasure to replay attacks). We've commented that electronic commerce is probably the largest application of SSL in the world today.

x9.59 effectively subsitutes "authentication" and "integrity" for "privacy" to meet the requirement to preserve the integrity of the financial infrastructure for all retail payments. as a result SSL is no longer required for hiding transactions as a countermeasure to replay attacks ... the x9.59 standard effectively "armors" every transaction, eliminating the replay attack vulnerability.

John W. Backus, 82, Fortran developer, dies

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Mon, 21 May 2007 10:39:42 -0600

Anne & Lynn Wheeler <lynn@garlic.com> writes:
one of the current things that virtualization is being touted for is compensating processes for the security and integrity gaps in many current systems
http://www.garlic.com/~lynn/2007k.html#48 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007k.html#50 John W. Backus, 82, Fortran developer, dies

re:
http://www.garlic.com/~lynn/2007k.html#52 John W. Backus, 82, Fortran developer, dies
Expert: IT industry has failed in desktop security
http://news.zdnet.com/2100-1009_22-6185295.html

also
http://www.garlic.com/~lynn/aadsm27.htm#11 Is this Risk Management's Waterloo
http://www.garlic.com/~lynn/aadsm27.htm#12 0wned .gov machines (was Re: Russian cyberwar against Estonia?)
http://www.garlic.com/~lynn/aadsm27.htm#13 Is this Risk Management's Waterloo

My Dream PC -- Chip-Based

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: My Dream PC -- Chip-Based
Newsgroups: alt.folklore.computers
Date: Mon, 21 May 2007 13:18:36 -0600

re:
http://www.garlic.com/~lynn/2007k.html#53 My Dream PC - Chip-based

... oh, and misc. past posts mentioning that after-market addons and security point-solutions ... with only superficial cosmetic changes; w/o attempting to fundamentally improve the integrity and security of the underlying infrastructure
http://www.garlic.com/~lynn/aadsm17.htm#56 Question on the state of the security industry
http://www.garlic.com/~lynn/aadsm21.htm#16 PKI too confusing to prevent phishing, part 28
http://www.garlic.com/~lynn/aadsm26.htm#64 Dr Geer goes to Washington
http://www.garlic.com/~lynn/aadsm27.htm#8 Leadership, the very definition of fraud, and the court of security ideas
http://www.garlic.com/~lynn/2001j.html#42 Big black helicopters
http://www.garlic.com/~lynn/2001k.html#7 hot chips and nuclear reactors
http://www.garlic.com/~lynn/2002h.html#39 Oh, here's an interesting paper
http://www.garlic.com/~lynn/2004q.html#17 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005d.html#42 Thou shalt have no other gods before the ANSI C standard
http://www.garlic.com/~lynn/2005s.html#2 Internet today -- what's left for hobbiests
http://www.garlic.com/~lynn/2005t.html#25 Why does my address appear as part of my name?
http://www.garlic.com/~lynn/2006v.html#14 In Search of Stupidity
http://www.garlic.com/~lynn/2007b.html#10 Special characters in passwords was Re: RACF - Password rules
http://www.garlic.com/~lynn/2007e.html#12 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007i.html#66 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007j.html#67 open source voting

i.e. x9.59 not only obsoleted this technology called SSL, originated by this small client/server started, the dominant use of which is frequently now referred to electronic commerce, for hiding information that could be used in replay attacks for fraudulent financial transactions ... having done a detailed, end-to-end vulnerability and threat analysis (not only on numerous protocols ... but the underlying business processes) ... it also addresses the harvesting/skimming attacks related to security breaches and data breaches ... again being able to use "static" information for future fraudulent transactions (in replay attacks).
http://www.garlic.com/~lynn/x959.html#x959

reference to hardware token complimentary technology for x9.59 financial standard protocol
http://www.garlic.com/~lynn/x959.html#aads

and investigation into similar technology in the time-frame when the ibm/pc was originally being introduced
http://www.garlic.com/~lynn/aadsm27.htm#9 Enterprise Right Management vs. Traditional Encryption Tools
http://www.garlic.com/~lynn/2006p.html#41 Device Authentication - The answer to attacks lauched using stolen passwords?
http://www.garlic.com/~lynn/2007b.html#59 Peter Gutmann Rips Windows Vista Content Protection

what were were looking at in the time-frame of the original ibm/pc introduction was later revisited with the various trusted computing and TPM activities ... various past posts ...
http://www.garlic.com/~lynn/aadsm5.htm#asrn4 assurance, X9.59, etc
http://www.garlic.com/~lynn/aepay10.htm#40 AADS Chip Strawman & aSuretee
http://www.garlic.com/~lynn/aepay11.htm#55 FINREAD ... and as an aside
http://www.garlic.com/~lynn/aadsm12.htm#14 Challenge to TCPA/Palladium detractors
http://www.garlic.com/~lynn/aadsm12.htm#18 Overcoming the potential downside of TCPA
http://www.garlic.com/~lynn/aadsm12.htm#19 TCPA not virtualizable during ownership change (Re: Overcoming the potential downside of TCPA)
http://www.garlic.com/~lynn/aadsm13.htm#18 A challenge
http://www.garlic.com/~lynn/aadsm21.htm#3 Is there any future for smartcards?
http://www.garlic.com/~lynn/aadsm22.htm#41 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm23.htm#54 Status of SRP
http://www.garlic.com/~lynn/aadsm23.htm#56 UK Detects Chip-And-PIN Security Flaw
http://www.garlic.com/~lynn/aadsm24.htm#19 Use of TPM chip for RNG?
http://www.garlic.com/~lynn/aadsm24.htm#21 Use of TPM chip for RNG?
http://www.garlic.com/~lynn/aadsm24.htm#22 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#23 Use of TPM chip for RNG?
http://www.garlic.com/~lynn/aadsm24.htm#26 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#27 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#28 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#46 More Brittle Security -- Agriculture
http://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#4 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#44 TPM & disk crypto
http://www.garlic.com/~lynn/aadsm26.htm#13 Who has a Core Competency in Security?
http://www.garlic.com/~lynn/2002i.html#71 TCPA
http://www.garlic.com/~lynn/2002j.html#40 Beginner question on Security
http://www.garlic.com/~lynn/2002j.html#55 AADS, ECDSA, and even some TCPA
http://www.garlic.com/~lynn/2002m.html#44 Beware, Intel to embed digital certificates in Banias
http://www.garlic.com/~lynn/2002n.html#18 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2004j.html#35 A quote from Crypto-Gram
http://www.garlic.com/~lynn/2004p.html#20 Systems software versus applications software definitions
http://www.garlic.com/~lynn/2005g.html#36 Maximum RAM and ROM for smartcards
http://www.garlic.com/~lynn/2005o.html#3 The Chinese MD5 attack
http://www.garlic.com/~lynn/2006h.html#31 Intel vPro Technology
http://www.garlic.com/~lynn/2006p.html#48 Device Authentication - The answer to attacks lauched using stolen passwords?
http://www.garlic.com/~lynn/2006s.html#34 Basic Question
http://www.garlic.com/~lynn/2006v.html#26 Fighting Fraudulent Transactions
http://www.garlic.com/~lynn/2006w.html#37 What does a patent do that copyright does not?
http://www.garlic.com/~lynn/2007b.html#30 How many 36-bit Unix ports in the old days?
http://www.garlic.com/~lynn/2007c.html#44 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007g.html#61 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007g.html#63 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007i.html#5 John W. Backus, 82, Fortran developer, dies

My Dream PC -- Chip-Based

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: My Dream PC -- Chip-Based
Newsgroups: alt.folklore.computers
Date: Mon, 21 May 2007 13:36:02 -0600

Steve O'Hara-Smith <steveo@eircom.net> writes:
WEP is a broken useless heap of junk, but AFAICT WPA is secure and considered uncrackable provided you don't choose weak keys.

Wireless a security risk, expert warns (16May07)
http://www.zdnetasia.com/news/security/0,39044215,62013307,00.htm

from above:
WEP encryption can today be broken within seconds and though WPA security fixed a lot of things, it forgot to rotate keys, making it susceptible to a ''replay'' attack. Today, the only wireless security that works is WPA2. However, it can be a bit complicated to set up and many people assume that because WEP and WPA are still available, it is enough for home use.

... snip ...

Cracks in the air; Justice security expert shows how easy it can be to defeat wireless security (7May07)
http://www.gcn.com/print/26_10/44213-1.html

from above:
Cracking the WEP encryption scheme took only a few minutes after capturing relatively few packets. Breaking the Advanced Encryption Standard encryption used in WPA/2 is much more difficult, so Del Gaizo attacked the passphrase exchange during the connection process instead.

"All I need is a four-way handshake, and then I can walk away" to run a dictionary attack against it, he said.

... snip ...

John W. Backus, 82, Fortran developer, dies

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Mon, 21 May 2007 16:39:25 -0600

Peter Flass <Peter_Flass@Yahoo.com> writes:
Yes, it knows. 'FF'x in first byte of CPUID. Mostly, no one cares, but we've got some code in JES2, for example, that does different things with spool files if it's running in a VM.

re:
http://www.garlic.com/~lynn/2007k.html#47 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007k.html#48 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007k.html#52 John W. Backus, 82, Fortran developer, dies

however, that is primarily if you want it to know.

this sort of started with cms ... and special "diagnose I/O" and a few other things ... depending on whether cms was running on a real 360 or in a virtual machine with some optimizations/features to improve cms efficiency.

however, in the morph from cp67 to vm370 ... they crippled cms's ability to operate on the real hardware.

in the JES2 case ... if JES2 is printing to a "real" printer ... there is no issue ... but if JES2 happens to be talking to a virtual machine emulated printer (where there is essentially double spooling ... the spooling provided by JES2 ... and the spooling provided by the virtual machine software) ... then JES2 wants to (at least) signal the virtual machine software at the end of each JES2 spooled print output ... so they are treated as separate printed outputs by the virtual machine software (instead of accumulating all JES2 printing into one large spool file and waiting for some operating action to indicate that the virtual machine software should actually start physical printing).

3350 failures

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 3350 failures
Newsgroups: bit.listserv.ibm-main
Date: Mon, 21 May 2007 21:31:56 -0600

Patrick.Falcone writes:
IBM 3880 - 1 or 2 (IBM DASD and Control Units Facts Folder G520-3075-2)

old email with reference to finding bug in the 3350 support in 3880 controller (and possibility of same bug having been in 3830 controller)
http://www.garlic.com/~lynn/2007b.html#email800402
in this recent post
http://www.garlic.com/~lynn/2007b.html#28 What is "command reject" trying to tell me?

above post also references early 3380/3880 MVS RAS testing in this post
http://www.garlic.com/~lynn/2007.html#2 "The Elements of Programming Style"

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Tue, 22 May 2007 07:50:26 -0600

jmfbahciv writes:
Didn't we call this "stuff", that did the virtualization, microcode?

re:
http://www.garlic.com/~lynn/2007k.html#52 John W. Backus, 82, Fortran developer, dies

a lot of it was "hardware" microcode ... it was part of the machine and below the software layer. but that was hardware abstraction. in 360 terms ... there use to be two modes for instruction operation, supervisor/priviliged and problem/non-privileged. cp67 would execute a virtual machine in problem state ... and any "privileged" instructions would trap into the cp67 kernel. later work sort of added a 3rd state to instruction execution ... virtual machine mode ... and the hardware instruction unit would execute the instruction according to virtual machine mode "rules". obviously if execution of the instruction was a microcode function ... then execution of instruction virtual machine mode would also be a virtual machine function.

in addition to executing virtual machine "privilege" instructions, there were also various requirements for administrative and resource sharing functions (across multiple virtual machines). in transition to LPARs ... in addition to direct virtual machine instruction execution ... some amount of the administrative and resource sharing functions also had to migrate into the "hardware".

some of the administrative and resource sharing functions included configuration functions ... setting up the definition and characteristics of the different LPARs. in some cases, rather than microcode on the processor "engine" ... this might also involve execution of a separate "service" processor ... which frequently handled administrative and configuration interface for the processor complex.

for other topic drift ... part of the precursor leading up to LPARs was the "SIE" instruction introduced with 370-xa on 3081. this is old discussion of some of the difference in operational optimization between 3081 and 3090 for "SIE" instruction use; the issue being was that part of the microcode on the 3081 was "paged" (i.e. read from piccolo FBA disk) ... and therefor there was significantly latency with some of the "SIE" instruction function (on 3081) ... vis-a-vis non-paged operation on 3090 (as well as trade-off between "silicon/chip" implementation and microcode implementation):
http://www.garlic.com/~lynn/2006j.html#27 virtual memory
http://www.garlic.com/~lynn/2006j.html#31 virtual memory

for other drift ... old post about study of vm370 kernel for selecting (6k bytes) of software kernel code to be moved into microcode of the 370/148
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist
http://www.garlic.com/~lynn/94.html#27 370 ECPS VM microcode assist
http://www.garlic.com/~lynn/94.html#28 370 ECPS VM microcode assist
http://www.garlic.com/~lynn/2003f.html#43 ECPS:VM DISPx instructions
http://www.garlic.com/~lynn/2003f.html#47 ECPS:VM DISPx instructions
http://www.garlic.com/~lynn/2003f.html#52 ECPS:VM DISPx instructions
http://www.garlic.com/~lynn/2003f.html#54 ECPS:VM DISPx instructions
http://www.garlic.com/~lynn/2003f.html#56 ECPS:VM DISPx instructions

3350 failures

Refed: **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 3350 failures
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
To: <ibm-main@bama.ua.edu>
Date: Tue, 22 May 2007 08:07:11 -0600

eamacneil@YAHOO.CA (Ted MacNEIL) writes:
I started with 3330's. And, I remember when STK (STC) showed us their first ICEBERG, and the size of the device was that of a standard conference table, weighed less and had the capacity of an order (or 2) of magnitude larger than the 3330 farm I first tended.

That 3330 farm was less than 50 GB, and we were considered a medium to large site. (Running on a 3081-D)

re:
http://www.garlic.com/~lynn/2007k.html#58 3350 failures

silicon valley area had at least three fairly large vm370 customer datacenters with good sized disk farms ... there was SLAC (lots of collection from the accelerator) and both Tymshare and internal HONE operation ... both extensive online, timesharing services
http://www.garlic.com/~lynn/submain.html#timeshare

HONE had somewhat started out with a number of cp67 installations to provide "hands-on" virtual machine use for branch office SEs. recent reference:
http://www.garlic.com/~lynn/2007j.html#65 Help settle a job title/role debate

It then transitioned to vm370 and lots of online, interactive APL applications supporting sales & marketing ... i.e. at some point early in 370 timeframe, there was transition where machine orders couldn't even be submitted w/o having first being processed by a HONE configuration.

In the mid-70s, the various (US) HONE datacenters were consolidated in silicon valley area ... with what was possibly the largest single-system configuration in the world at the time (large datafarm with load balancing across large number of processors in loosely-coupled configuration).
http://www.garlic.com/~lynn/subtopic.html#hone

another large datacenter in silicon valley was Lockheed's DIALOG (online library titles and abstracts which has gone thru a number of owners since that time) ... which had something like 300(?) 3330-clones in their data farm (the basic service was MVS ... but lots of it was run under VM ... on clone processors).

My Dream PC -- Chip-Based

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: My Dream PC -- Chip-Based
Newsgroups: alt.folklore.computers
Date: Tue, 22 May 2007 09:52:47 -0600

Steve O'Hara-Smith <steveo@eircom.net> writes:
For online purchasing (as distinct from banking) I have to pass my card details to the merchant (or use paypal).

re:
http://www.garlic.com/~lynn/2007k.html#53 My Dream PC -- Chip-Based
http://www.garlic.com/~lynn/2007k.html#55 My Dream PC -- Chip-Based
http://www.garlic.com/~lynn/2007k.html#56 My Dream PC -- Chip-Based

for a little drift ... recent post in crypto mailing list discussing some of the threat/vulnerability issues
http://www.garlic.com/~lynn/aadsm27.htm#15 307 digit number factored

3350 failures

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 3350 failures
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
To: <ibm-main@bama.ua.edu>
Date: Tue, 22 May 2007 10:07:32 -0600

Patrick.Falcone writes:
I don't remember any 3350 problems as this device type was my first performance charge with doing internal pathing/volume placement based on performance metrics at timeshare NVIP back in the early 80's. I do however remember the 3350 to 3380 migration project which turned ugly when we were informed, post migration, that we needed plenum replacements on our 3380 E's/K's. IIRC the plenum connected to 2 different HDA's but I could be wrong on this point. Lots of long weekends with the media folks deciding how to play musical chairs with strings of DASD.

re:
http://www.garlic.com/~lynn/2007k.html#58 3350 failures
http://www.garlic.com/~lynn/2007k.html#60 3350 failures

old email
http://www.garlic.com/~lynn/2007b.html#email800402

talks about problem executing HIO/HDV to 3350 when (3880) control unit was busy (which may have also existed in 3830) ... and software fix was to i/o supervisor to "not do that".

one of the 3350 to 3380 migration issues was that the 3380 had more data under each arm (proportional in excess to any increase in 3380 thruput improvement).

internally we had some performance monitoring and modeling tools that would identify what 3350 data to move to what 3380 .... and some recommendations (in heavily loaded environment) to leave 3380 10-20 percent empty/idle (in order to have same thruput as 3350 configuration).

there was a facetious proposal (even discussed at SHARE) for a special 3380 "feature" in the 3880 controller ... that would define extra priced 3380 drives that were "faster" (by reducing the number of cylinders that could be accessed). This was for shops where the administrators couldn't resist completely filling a 3380 as cost effective measure (however, they would feel comfortable with paying extra for feature that prevented them from completely filling a 3380).

misc. past posts about getting to play dasd engineer in the disk engineering lab (bldg. 14) and the disk product test lab (bldg. 15).
http://www.garlic.com/~lynn/subtopic.html#disk

My Dream PC -- Chip-Based

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: My Dream PC -- Chip-Based
Newsgroups: alt.folklore.computers
Date: Wed, 23 May 2007 15:25:10 -0600

re:
http://www.garlic.com/~lynn/2007k.html#61 My Dream PC -- Chip-Based

for even more drift:
http://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored
http://www.garlic.com/~lynn/aadsm27.htm#15 307 digit number factored
http://www.garlic.com/~lynn/aadsm27.htm#16 dnssec?
http://www.garlic.com/~lynn/aadsm27.htm#17 dnssec?

mentioned in the above and my ietf rfc index
http://www.garlic.com/~lynn/rfcietff.htm

... references to new IETF RFC:
New antiphishing, antispam specifications unveiled
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9020940
IETF approves new weapon to fight spam, phish
http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1256125,00.html

other recent posts with some reference
http://www.garlic.com/~lynn/2007k.html#32 SSL Security
http://www.garlic.com/~lynn/2007k.html#33 Even worse than UNIX

Even worse than UNIX

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Even worse than UNIX
Newsgroups: alt.folklore.computers
Date: Wed, 23 May 2007 15:38:06 -0600

jeffj@panix.com (Jeff Jonas) writes:
You avoided the IBM mindset/indoctorination that reading core dumps after an ABEND was 'the one true way' to find the error. My dad was a mainframe coder for most of his career and even with interactive terminals, it was a batch environment. "Abend-aid" was apparently the interactive editor to format and peruse the core dump. I suspect he never used interactive or symbolic debuggers.

past references to having done DUMPRX:
http://www.garlic.com/~lynn/submain.html#dumprx

done in REX ... before REX shipped as product and was renamed REXX. at one point it was in use in majority of internal datacenters and by nearly all customer service "PSRs" (i.e. service people that were charged with handling dumps/problems from customers).

it could run off CP (i.e. vm370) kernel "dumps" ... or the live CP kernel ... as well as CMS "dumps" and live "CMS" storage.

it could take DSECTs (from MACLIBS) and LISTINGS for "symbolic" interpretation.

one of the biggest uses was that I had started a study of typical failure characteristics ... and began building a library of automated processes that would examine storage (dump or live core) for known, identifiable failure/problem and/or various anomolous/unusual characteristics.

the interactive tool in use at the time was called DUMPSCAN (limited solely to core dumps) ... written in something like 20k-40k lines of assembler. I undertook to do DUMPRX, partially as a demonstration of the power of REX ... with stated objective that in half-time over a period of 3mths, I would implement ten times the function (of DUMPSCAN) with ten times the performance (of DUMPSCAN) in (interpreted) REX.

Non-Standard Mainframe Language?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Non-Standard Mainframe Language?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 23 May 2007 17:20:37 -0600

gerhard@ibm-main.lst (Gerhard Postpischil) writes:
Back in the seventies I was in charge of the systems group at a service bureau. One of our customers was from a local university, running an APL application that tracked students vs. classes, and a few other things. It was gold mine - whenever it ran, the CPU went 100% busy and stayed that way for a long time. The same thing written in another language might have cost one or two percent as much.

recent post mentioning world-wide hone system
http://www.garlic.com/~lynn/2007.html#30 V2X2 vs. Shark (SnapShot v. FlashCopy)
http://www.garlic.com/~lynn/2007.html#31 V2X2 vs. Shark (SnapShot v. FlashCopy)
http://www.garlic.com/~lynn/2007.html#46 How many 36-bit Unix ports in the old days?
http://www.garlic.com/~lynn/2007b.html#51 Special characters in passwords was Re: RACF - Password rules
http://www.garlic.com/~lynn/2007d.html#39 old tapes
http://www.garlic.com/~lynn/2007e.html#38 FBA rant
http://www.garlic.com/~lynn/2007e.html#41 IBM S/360 series operating systems history
http://www.garlic.com/~lynn/2007f.html#12 FBA rant
http://www.garlic.com/~lynn/2007f.html#20 Historical curiosity question
http://www.garlic.com/~lynn/2007g.html#31 Wylbur and Paging
http://www.garlic.com/~lynn/2007i.html#34 Internal DASD Pathing
http://www.garlic.com/~lynn/2007i.html#77 Sizing CPU
http://www.garlic.com/~lynn/2007j.html#65 Help settle a job title/role debate
http://www.garlic.com/~lynn/2007k.html#60 3350 failures

HONE ("hands-on") started out in the US with cp67 ... sort of to allow branch office SEs to have "hands-on" with various operating sysetms (running in virtual machines). prior to 23jun69 unbundling announcement
http://www.garlic.com/~lynn/submain.html#unbundle

a lot of SEs got much of their "hands-on" experience in their customer accounts. after the unbundling announcement, SE time was being charged for ... and not a lot of customers were interested in paying to have SEs learn.

however, the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

in addition to doing virtual machines, cms, inventing GML (precursor to SGML, HTML, XML, etc)
http://www.garlic.com/~lynn/submain.html#sgml

and the internal networking technology
http://www.garlic.com/~lynn/subnetwork.html#internalnet

which was also used in bitnet and earn
http://www.garlic.com/~lynn/subnetwork.html#bitnet

also did a port of apl\360 to cms (cms\apl). apl\360 had its own monitor, scheduler, workspace swapping, terminal handler, etc ... all of which could be discarded in the port for cms\apl. also in moving from the 16kbyte (sometimes 32kbyte) "real" workspace sizes .... to CMS ... where the workspace size could be all of virtual memory ... the whole way that APL managed storage had to be reworked (the real storage stategy resulted in enormous page thrashing).

part of cms\apl was also the ability to access system services (things like read/write files) ... something that apl didn't previously have. the combination of really large workspace sizes and the access to system services ... opened up APL for a lot of real-world problems. A lot of modeling off all kinds was done ... as well as a lot of stuff that these days are implementing with spreadsheets.

One of the early "big" APL uses (at cambride) were a number of business planners from corporate hdqtrs in armonk. they forwarded a tape to cambridge with all of the most sensitive corporate customer business data ... and would do significant amount of business modeling and planning. this created an interested "security" scenario for the service at cambridge since there were a lot of non-employees using the system from various educational institutions in the cambridge area.

one instance is this slightly related DNS trivia topic drift ... more than a decade before DNS
http://www.garlic.com/~lynn/2007k.html#33 Even worse than Unix

Before long there were a significant number of CMS\APL applications written that supported sales & marketing and deployed on the HONE system ... effectively taking over its whole use for sales & marketing (and eliminating the original "hands-on" use for SEs). Before long, sales couldn't even submit customer orders that hadn't been processed by some CMS\APL application. HONE transitioned from cp67 to vm370-based platform and from cms\apl to apl\cms (enhancements done by the palo alto science center ... including the 370/145 apl microcode assist) ... and clones of (US) HONE system were sprouting up all over the world (some of the early ones i even got to handle ... like when EMEA hdqtrs moved from the US to Paris).

lots of other posts mentioning HONE and/or APL
http://www.garlic.com/~lynn/subtopic.html#hone

in the mid-70s, the US HONE datacenters were consolidated in silicon valley. The large customer base (all US sales and marketing) drove the requirement for large disk farm ... and the heavy APL processor requirements helped contribute to it (probably) being the largest single system image installation in the world at the time ... aka large number of loosely-coupled processors with front-end that would route new logins based on availability and load.

later the silicon valley HONE datacenter was replicated first in Dallas and then a 3rd replica in Boulder (with availability and fall-over across the three datacenters).

the science center had also done a lot of performance tuning and modeling ... including much of the stuff leading up to capacity planning. a sophisticated science center performance model written in APL was made available on the HONE system as the performance predictor ... where sales & marketing could provide workload and configuration characterizations of a customer installation and ask "what-if" questions about what happen when workload &/or configuration changes were made.

when i was getting ready to release my resource manager ... besides getting selected to be guinea pig for charging for kernel software ... I had developed a bunch of automated benchmarking processes. there was something like a 1000 benchmarks defined that covered a broad range of configurations, workload, and performance tuning parameters. as each benchmark was run ... the results were fed into a specially modified version of the performance predictor. then the performance predictor was programmed to start selecting various tuning, configuration and workload specifications ... for something like another 1000 benchmarks (predicting what should happen in each benchmark and then verifying the results). the 2000 benchmarks took something like 3mnths elapsed time to run ...
http://www.garlic.com/~lynn/submain.html#bench
leading up to the release of the resource manager.
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock

The top 10 dead (or dying) computer skills

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: The top 10 dead (or dying) computer skills
Newsgroups: alt.folklore.computers
Date: Wed, 23 May 2007 22:12:04 -0600

The top 10 dead (or dying) computer skills
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9020942

from above:


1. Cobol
2. Nonrelational DBMS
3. Non-IP networks
4. cc:Mail
5. ColdFusion
6. C Programming
7. PowerBuilder
8. Certified NetWare Engineers
9. PC network administrators
10. OS/2

... snip ...

Non-Standard Mainframe Language?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Non-Standard Mainframe Language?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 24 May 2007 09:34:14 -0600

Chris.Craddock@CA.COM (Craddock, Chris) writes:
I never actually met a processor with the (mythical?) APL assist feature. However, I did write mountains of APL throughout the 1980s. APL was always thought of as a resource hog. IMHO it could be very efficient or grotesque, depending on your data structures and algorithms. If you wrote programs in the style of 3 GLs, it was typically a dog.

re:
http://www.garlic.com/~lynn/2007k.html#65 Non-Standard Mainframe Language?

APL microcode assist was done for the 370/145 by the Palo Alto Science Center ... sort of as part of their doing APL\CMS. This was also made available on 370/148.

As mentioned, the Cambridge Science Center had originally done the port of APL\360 to CMS for CMS\APL (i.e. back when it was Cambridge Monitor System for CP67; as part of the morph of CP67 to VM370 they "renamed" CMS the Conversational Monitor System).

APL microcode assist gave APL\CMS applications on 370/145 about the same processor thruput as same APL\CMS application running on 370/168 (nearly ten times thruput increase).

When the HONE datacenters were consolidated in silicon valley (actually across the back parking lot from the Palo Alto Science Center) ... they looked at whether they could take any of their APL application intensive workload and move them off 168s to 145s. The problem was not only were their applications quite processor intensive (which 145 microcode assist would have given about equivalence) but also real storage and I/O intensive (which would have severely degraded if they had moved from 168 to 145/148).

For nearly 15 yrs, i provided highly modified/customized versions of cp67 kernel and later vm370 kernels for HONE (and large number of other internal datacenters). I also periodically got involved in reviewing various APL applications from performance tuning standpoint ... aka majority of the applications that provided world-wide support for sales and marketing were implemented in APL running on CMS. Lots of past posts mentioning HONE and/or APL
http://www.garlic.com/~lynn/subtopic.html#hone

Eventually there was a APL language development group formed in STL which picked up APL\CMS responsibility as well as making it available on MVS ... renaming it VS\APL (and later APL2).

Trivia ... in the early to mid 80s, the manager of the APL group in STL transferred to Palo Alto to head up a new group doing a port of BSD Unix to 370. I got to attend some of the design sessions and also help obtain a 370 C compiler for the effort. Before that specific implementation shipped, the group had their BSD porting efforts retargeted to the PC/RT ... eventually shipping "AOS" (the C compiler vendor being used had to retarget the backend from 370 to ROMP).

misc. past posts mentioning 801/ROMP as well as risc, Iliad, RIOS, rs/6000, power/pc, etc
http://www.garlic.com/~lynn/subtopic.html#801

The APL microcode assist was not made available on other processors. The 145/148 microcode engine was a vertical microcode engine and executing approx. 10 microcode instructions per every 370 instruction (some of the modern i86-based 370 simulators have similar ratio characteristics).

The 370/165 had a horizontal microcode engine ... and achieved an avg. of 2.1 machine cycles per 370 instruction ... which was improved to avg 1.6 machine cycles per 370 instruction for 168 (and hit nearly 1:1 with 3033). Since 370 instructions were executing very close to hardware speed on the high-end processors ... there was frequently very little performance benefit of doing a 1-for-1 translation of 370 instruction into native hardware. The exception was virtual machine microcode assists on the high-end processors ... however these weren't the 1:1 translation of 370 instructions to native instructions. In the virtual machine assists, the instruction emulation for privilege instruction was modified to directly perform the privilege operation while in problem state (but according to virtual machine execution rules ... sort of a "3rd" machine state). This avoided the interrupt into the kernel, having to save registers and other state change overhead ... redecode the instruction in software and perform the necessary operation, and then switch back to virtual machine problem state execution.

In addition to stuff like APL microcode assist done for 145/148 ... there was the VM kernel assist "ECPS" done for both 138 & 148. This took about 6k bytes of vm370 370 kernel code and moved it into native microcode of the machines (again getting about 10:1 thruput improvement).

some old posts about how we went about selecting what parts of the kernel code were moved into microcode (some of the initial work involved help from some of the same people involved in doing the 145 APL microcode assist)
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist
http://www.garlic.com/~lynn/94.html#27 370 ECPS VM microcode assist
http://www.garlic.com/~lynn/94.html#28 370 ECPS VM microcode assist

and lots of past posts discussing all sort of vertical and horizontal native machine microcode
http://www.garlic.com/~lynn/submain.html#mcode

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Thu, 24 May 2007 10:33:17 -0600

Frank McCoy <mccoyf@millcomm.com> writes:
Many stick with the "Big Name", whether it works or not. That's how the IBM PC won the market. It was FAR from the best Personal Computer at the time. All it had really, was the IBM name. "Nobody ever got fired for suggesting buying IBM."

the other part was that there was easy big market uptake with commercial companies switching from buying 3270 terminals (from IBM) to buying IBM/PC (about the same price, same desktop footprint, and could do both 3270 terminal emulation as well as some local computing). It was as much a name ... but possibly more significant the business case justification on the part of the buyers were "no-brainers" ... since they were already buying huge numbers and the money was already allocated.

this market momentem then created large install base that sort of snowballed ... large install base would attract new software developers and large number of new application would attract incremental purchase justification ... i.e. buyers/customers that had to make incremental financial justification to buy the machine ... i.e. those where it wasn't already a no-brainer decision.

the ibm/pc initially won large market share because in the 3270 terminal emulation ... since it didn't require any effort to justify the decision (using money that was already going to be spent on 3270 terminals anyway). then the market share increased significantly because it had large number of applications ... because it had large market install. except for some techie market niche ... it wasn't about being the "best" computer ... it was having large number of applications (including terminal emulation).

in the early 80s i had brother that was regional apple marketing rep (claimed to have the largest physical region in continental US). he would periodically come to town and i would get invited to dinners with various apple people. during one period (before the mac had been announced) i would get into this argument with some of the mac developers (about being able to acquire large market install base). the mac guys were sort of claiming that the mac was going to be the "volks" computer ... home table top only ... and never would a business or commercial application be allowed to touch it.

various posts mentioning terminal emulation
http://www.garlic.com/~lynn/subnetwork.html#emulation

The top 10 dead (or dying) computer skills

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The top 10 dead (or dying) computer skills
Newsgroups: alt.folklore.computers
Date: Thu, 24 May 2007 11:20:41 -0600

"mensanator@aol.com" <mensanator@aol.com> writes:
1. Cobal

mispelled

re:
http://www.garlic.com/~lynn/2007k.html#66 The top 10 dead (or dying) computer skills

oops, finger twitch ... wasn't even spelling ... was purely transcribing letters directly from the article ... for some reason I frequently have typed cobol as cobal w/o even paying attention.

... my impression is that the article is somewhat focused on new-hire (and growth) market segments. it isn't necessarily that they are actually dead or dying ... it is that they aren't looking to hire a growing number of new people (which doesn't necessarily equate with dead/dying).

for some other topic drift ... misc. posts on original relational/sql implementation system/r
http://www.garlic.com/~lynn/submain.html#systemr

there have been some relatively recent articles saying that there is still more data under management in the pre/non relational databases than in relational. post/reference
http://www.garlic.com/~lynn/2006w.html#27 Generalized approach to storing address details

relational tends to be somewhat more in the academic and consumer market segment because it is easier to deal with and understand (i.e. a big part of SQL language was to drastically simplify dealing with DBMS so that significant lower skill levels were required).

IBM System/360 signs above control panels - different styles - why?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM System/360 signs above control panels - different styles - why?
Newsgroups: alt.folklore.computers
Date: Thu, 24 May 2007 11:25:42 -0600

nostalgictechnophile <kstumpf@geosign.com> writes:
Above the control panel of each model in the System/360 family was a metal sign. It was either a 2-tone, black and gray sign, or an all black sign.

Please tell me why and when the signs change from the original 2-tone sign to the all black?

somebody on the web had been investigating a lot of this ... including the number of lines & possibly slant in the letters (I vaguely remember claims about a corporate department in armonk that went around internally to make sure that the slant of the letters exactly corresponded to the corporate standard).

check out this webpage and others at this website
http://www.ibm-collectables.com/gallery/view_album.php?set_albumName=album79

The top 10 dead (or dying) computer skills

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The top 10 dead (or dying) computer skills
Newsgroups: alt.folklore.computers
Date: Thu, 24 May 2007 12:08:25 -0600

_firstname_at_lr_dot_los-gatos_dot_ca_us writes:
A few years ago, IBM announced (without great fanfare) that IMS had a particularly good year, with large revenue growth, much more than DB2. If my foggy memory serves me right (big if!), IMS might have had the highest growth of any software product that year. In the meantime, I accasionally hear about great new additions to IMS, like it can now be integrated with SOA.

For those that don't know: IMS is a hierarchical database (that's what came before relational databases, such as System R, Oracle, DB2, Tandem, Digital RDB, and all the copycats). To my knowledge, IMS only runs on mainframes (370-class machines), but I might be wrong there.

re:
http://www.garlic.com/~lynn/2007k.html#66 The top 10 dead (or dying) computer skills
http://www.garlic.com/~lynn/2007k.html#69 The top 10 dead (or dying) computer skills

a couple old emails mentioning IMS
http://www.garlic.com/~lynn/2007.html#email801016
http://www.garlic.com/~lynn/2007c.html#email830125

recent post referencing one of the original IMS people and early IMS history
http://www.garlic.com/~lynn/2007e.html#41 IBM S/360 series operating systems history

The top 10 dead (or dying) computer skills

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The top 10 dead (or dying) computer skills
Newsgroups: alt.folklore.computers
Date: Thu, 24 May 2007 12:14:20 -0600

_firstname_at_lr_dot_los-gatos_dot_ca_us writes:
Along the same lines: IBM's TPF operating system (a specialized operating system for mainframes, designed very much around transaction processing) also still exists, and is going strong. Last I heard, it had been integrated with web services (MQ series or WebSphere), and the Apache web server had been ported to it. Which is sort of astonishing, given that TPF's API is very much not like POSIX.

originally ACP (airline control program) ... for airline res systems. it provided for horizontal cluster support ... but didn't support SMP until rather late. then they found some number of the financial networks also using it ... which prompted renaming from ACP to TPF.

my wife did a short stint as chief architect for AMADEUS (european res system) somewhat built off eastern's system/one (other trivia, ran on 370/195). she didn't last long ... she was backing x.25 as communication infrastructure ... which upset the SNA forces ... which helped precipitate her untimely departure. AMADEUS went x.25 anyway.

Non-Standard Mainframe Language?

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Non-Standard Mainframe Language?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
To: <ibm-main@bama.ua.edu>
Date: Thu, 24 May 2007 16:42:00 -0600

shmuel+ibm-main@ibm-main.lst (Shmuel Metz , Seymour J.) writes:
Dont forget APL Shared Variables.

re:
http://www.garlic.com/~lynn/2007k.html#67 Non-Standard Mainframe Language?
http://www.garlic.com/~lynn/2007k.html#70 Non-Standard Mainframe Language?

yes, i skipped over some of the intermediate folklore.

there was a big uproar created with the phili science center apl\360 group when the cambridge science center did cms\apl and added "system services calls" ... the claim was that it totally violated spirit of apl language ... although as i've referenced before, removing the trivial workspace size limits of apl\360 and providing for access to system services (like being able to do file read/writes) ... really opened up being able to use cms\apl for real world applications.

Eventually, APL shared variables was the effective come-back from the APL language purists on how to be able to access system services ... w/o corrupting the purity of the APL language.

Non-Standard Mainframe Language?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Non-Standard Mainframe Language?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
To: <ibm-main@bama.ua.edu>
Date: Thu, 24 May 2007 17:01:54 -0600

shmuel+ibm-main@ibm-main.lst (Shmuel Metz , Seymour J.) writes:
The were also assists for OS/VS1 and MVS/SE, to say nothing of the infamous ECPS:VSE.

re:
http://www.garlic.com/~lynn/2007k.html#67 Non-Standard Mainframe Language?
http://www.garlic.com/~lynn/2007k.html#70 Non-Standard Mainframe Language?
http://www.garlic.com/~lynn/2007k.html#73 Non-Standard Mainframe Language?

the 145/148 ... for lots of typical kernel instruction paths ... there was approximately a one-for-one byte translation from 370 into microcode. 145 allowed for scavanging part of processor memory for microcode. that was changed in 148 ... and after the OS/VS1 microcode assist was done for 148 ... there was only 6kbytes left in dedicated 148 microcode storage for VM370 ECPS.

This somewhat contributed to us doing a significantly better job of choosing the highest used vm370 instruction paths (vis-a-vis the vs1 effort) for dropping into microcode. basically all the instruction paths thru the vm370 kernel were carefully profiled and then ranked as per use ... and then the top 6k bytes were chosen for migration to 148 m'code ... refs:
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist
http://www.garlic.com/~lynn/94.html#27 370 ECPS VM microcode assist
http://www.garlic.com/~lynn/94.html#28 370 ECPS VM microcode assist

MVS/SE microcode assist would have been much more problamatical since it was applied to the high-end horizontal m'code machines ... where there was already nearly one-for-one between 370 execution and microcode execution; it wouldn't have been possibly to pick up the 10:1 improvement that you found in the low & mid-ranged microcoded machines (and in some cases, trying to do straight-forward one-for-one movement of blocks of 370 instructions to horizontal microcode, would actually increase processing time).

The place where the vm370 virtual machine microcode assists worked across the whole machine line ... was being able to eliminate the priv. op interrupts into the vm370 kernel ... that 370 supervisor state instruction emulation, when running in special virtual machine problem state ... executed the instructions directly. This wasn't a one-for-one movement of kernel instructions to microcode instruction ... this was the total elimination of the interrupt processing, context switch, and a bunch of other kernel overhead stuff.

This was further demonstrated when Amdahl implemented hypervisor in their "macrocode" ... a sort of 370 instruction set running in special hardware mode. The response was PR/SM on the 3090 (which was a much more difficult undertaking since it was native horizontal microcode programming).

John W. Backus, 82, Fortran developer, dies

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Thu, 24 May 2007 17:22:30 -0600

Peter Flass <Peter_Flass@Yahoo.com> writes:
No, but a CPOE we do laws, etc using DCF/Script.

The "G" in GML started out lawyer and got into inventing gml
http://www.garlic.com/~lynn/submain.html#sgml

at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

for handling of legal documents. Document formating GML tag processing was then added to the cms script command (which had originally been implemented with runoff like "dot" commands). Of source, "M" & "L" standards for two other individuals at the sciecne center ... it then was a task to come up with "generalized markup language" to correspond with the initials of their last name.

gml then morphed in sgml (ansi/iso standard) and then html, xml, and variety of other MLs.

My Dream PC -- Chip-Based

Refed: **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: My Dream PC -- Chip-Based
Newsgroups: alt.folklore.computers
Date: Thu, 24 May 2007 22:55:44 -0600

jmfbahciv writes:
Do you honestly expect banking to be wireless using off the shelf hard/software? Do you expect to have a nice warm feeling if Vista comes with that hairy hand that powers up and boots itself so it can get on the internet and be patched?

when we asked to come in and consult with this small client/server startup that wanted to do payment transactions on their server ... and had this stuff call SSL ... SSL got used for hiding the transaction information while it was being transmitted. the stuff subsequently was referred to as electronic commerce
http://www.garlic.com/~lynn/subnetwork.html#gateway

we've also periodically claimed that it may have been the original SOA.

however, later when we were doing some work in the x9a10 financial standard working group ... we did detailed end-to-end processing vulnerability and threat analysis. part of the findings was that the transaction information was needed for some period of time ... but there were extremely conflicted requirements in the existing paradigm: 1) information needed to readily available for some time for numerous business processes and 2) information could never, ever be divulged since it could be used in fraudulent transaction replay attacks.

this was somewhat given rise to our periodic comment that even if the planet were buried under miles of information hiding crypto, it still wouldn't prevent information leakage.

in the mid-90s, the x9a10 financial standard working group had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments ... and the result was the x9.59 financial standard.
http://www.garlic.com/~lynn/x959.html#x959

in the pain security acronym

P ... privacy (or sometimes CAIN, confidentiality)
A ... authentication
I ... integrity
N ... non-repudiation

the existing paradigm has been attempting to solely rely on privacy/confidentiality and the hiding of the information. we've somewhat characterized this as the naked payment/transaction methaphor
http://www.garlic.com/~lynn/subintegrity.html#payment

in x9.59 financial standard, basically each transaction is "armored" ... effectively using "authentication" and "integrity" (in lieu of "privacy/confidentiality") as a means of preserving the integrity of the financial infrastructure for all retail payments.

with x9.59 financial strandard, transaction information can be exposed w/o the danger/threat of fraudulent transaction replay attacks. It appears that the major use of SSL is electronic commerce for the purpose of hiding transaction information as countermeasure to fraudulent transaction replay attacks (being able to use exposed information). With x9.59 financial standard, that danger/threat has been eliminated ... and with it, one of the major justifications for the use of SSL.

A little x-over thread from crypto mailing list
http://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored
http://www.garlic.com/~lynn/aadsm27.htm#15 307 digit number factored
http://www.garlic.com/~lynn/aadsm27.htm#16 dnssec?
http://www.garlic.com/~lynn/aadsm27.htm#17 dnssec?
http://www.garlic.com/~lynn/aadsm27.htm#19 307 digit number factored
http://www.garlic.com/~lynn/aadsm27.htm#20 307 digit number factored
http://www.garlic.com/~lynn/aadsm27.htm#21 307 digit number factored

and a x-over thread from financial crypto blog
http://www.garlic.com/~lynn/aadsm27.htm#0 H6.2 Most Standardised Security Protocols are Too Heavy
http://www.garlic.com/~lynn/aadsm27.htm#1 H6.2 Most Standardised Security Protocols are Too Heavy

The top 10 dead (or dying) computer skills

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The top 10 dead (or dying) computer skills
Newsgroups: alt.folklore.computers
Date: Fri, 25 May 2007 09:27:00 -0600

Peter Flass <Peter_Flass@Yahoo.com> writes:
I believe it's mostly C. OS/2 1.x had lots of assembler, but I believe most of that was rewritten in C for version 2.x. IIRC, some people here tried OS/2 PPC, I haven't, so I can't comment on how it was doing, but I think the port wasn't completed due to typical IBM mess-ups.

BTW, what's the minimum age for "folklore". OS/2 is now over 20 years old, does it qualify?

recent post
http://www.garlic.com/~lynn/2007i.html#60 John W. Backus, 82, Fortran developer, dies

with some old "OS2" email from dec87
http://www.garlic.com/~lynn/2007i.html#email871204
http://www.garlic.com/~lynn/2007i.html#email871204b

along with URLs to several OS2 timeline webpages (os2 1.0 release dec87)

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Fri, 25 May 2007 09:41:12 -0600

jmfbahciv writes:
The virtual machine software has to ship before the OS that runs under it. If MS' goal is to be the distributor of all software, do you honestly believe that they will allow another OS to run above them on the systems they are selling services to? That implies giving control to some other entity; this is not in any psychology of Billyboy nor MS' corporate folklore.

To us engineers, it would be perfect common sense to allow the vitualization, but when did MS do anything that had regard for the common good of all computing platforms, including their competition? They don't so any design has to take this fact into account. I am not moralistic nor demanding political intervention; I am stating that this is how the biz operates and designing has to take the MS behaviour and methods into account.

the virtual machine software has to eventually ship and be installed ... but hercules (done in the last decade) which is a i86-based virtual machine software that provides 360 virtual machines is able to run os/360 operating systems from the 60s (OSs that predate i86 chips by a couple decades and predate existance of hercules by even more).

so some of the software that provide i86 virtual machines for running windows ... could even be "after market" installed on machines where windows was installed at the factory. just fixup a partition on a disk that the virtual machine software can be installed and booted ... once it is up and running, it can simulate the bios boot of the windows partition into a virtual machine.

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Fri, 25 May 2007 12:22:26 -0600

Roland Hutchinson <my.spamtrap@verizon.net> writes:
It's a certificate authority.

actually it is "certification authority" ... for some reason it got popularized in shorten form as "certificate authority" ... what they are suppose to actually do is certify something and then issue a digital certificate as a representation of that certification (analogy to physical licences, credentials, certificates).

possibly one of the reason for the shorten form is that many of the operations disclaim all responsibility and liability related to the certification ... effectively leaving only the "digital certificate" (with possibly little or no actual meaning).

the technology basis is asymmetric cryptography with business processes represented by public/private key (i.e. a business process where one of the asymmetric key pair is selected to be private and is kept confidential and never divulged ... and the other is "published"). old email reference proposing use for public/private key business process:
http://www.garlic.com/~lynn/2006w.html#email810515
in this post
http://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network

the "digital certificate" business process is sort of an electronic analogy for offline, but electronic operation ... from the letters of credit/introduction dating back to the sailing ship days (and before). the relying party was dealing with complete stranger for the first time and had no other mechanism for obtaining reliable information. The modern motivation is sort of the offline email paradigm from the early 80s where somebody dialed their local, electronic postoffice, exchanged email, hung up ... and now had to deal with first time communication from total stranger.

in the early 90s this somewhat showed up as x.509 identity digital certificates. however, they tended to be grossly overloaded with personal information and by the mid-90s most institutions began to realize that this represented an enormous privacy and liability problem ... and transitioned to what they called relying-party-only digital certificates ... lots of past post discussing the "RPO" digital certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo

however, at the time, we were repeatedly able to show that RPO digital certificates were redundant and superfluous.

the other event from the mid-90s that contributed to proliferation of certification authorities was done in conjunction with something now frequently referred to as electronic commerce. we had been called in to consult with a small client/server startup that wanted to payments on their servers and they had this technology called "SSL". misc. posts about that activity
http://www.garlic.com/~lynn/subnetwork.html#gateway

we even sometimes refer to it as the original SOA.

As part of getting all those business processes working we had to do business audits and walk-thrus of these emerging operations called "certification authorities" doing domain name certifications ... and issuing domain name certificates (in support of SSL). lots of past posts referring to SSL and domain name digital certificates from that period
http://www.garlic.com/~lynn/subpubkey.html#sslcert

however, a problem with the integrity of the whole SSL and digital certificate operations quickly developed. The basic "security" assumption in SSL was that the individual entered a URL and the browser then used the webserver's digital certificate to check whether the webserver (that the browser was talking to) corresponded with the URL that the person entered (the webserver that the person thot it was talking to was actually the webserver that the person was talking to).

The issue became that the merchant servers quickly found that the use of SSL was cutting their thruput by up to 90percent ... and they quickly retrenched to just using SSL for the payment process. Now what happens is the person clicks on a button (provided by the webserver) that generates a URL ... and SSL now checks that the SSL provided by the webserver corresponds with the digital certificate provided by the webserver. There is now a major disconnect since the original webserver connection (URL provided by the user) is no longer validated. If the user got routed to a fraudulent website in the initial operation ... then a fraudulent website is likely to be capable of using a URL for which it has some valid digital certificate.

This is also the root of a lot of the phishing, spoofing and man-in-the-middle attacks. There are even active man-in-the-middle attacks that have the traffic redirected to a fraudulent website that uses two pairs of (SSL) sessions ... one spoofing the valid website to the client and the other spoofing the client to the valid website. misc. past posts mentioning various kinds of man-in-the-middle attacks
http://www.garlic.com/~lynn/subintegrity.html#mitm

A big issue in the original SSL deployment was requirement that the person's knowledge provided a tight binding between the website (that the person wanted to talk to) and the URL of that website. SSL then provided a tight binding between the URL and the actual website. For the SSL-based infrastructure to actually work, both pieces of the integrity chain are required. Today, most people have little awareness between the website they think they are talking to and the URL for that website ... breaking the integrity chain assumption required for SSL security to be valid ... and is the source of a lot of attacks and fraudulent activity. lots of past posts mentioning fraud, exploits, vulnerabilities, threats:
http://www.garlic.com/~lynn/subintegrity.html#fraud

previous, next, index - home