List of Archived Posts

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

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
offerring new hires was increasing over time).

there was this science fiction story about a society based on workers
with brain imprints that occured 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

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

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

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.

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
http://www.garlic.com/~lynn/2007k.html#3 IBM Unionization

IBM Unionization

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

other posts in the thread:
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
http://www.garlic.com/~lynn/2007k.html#4 IBM Unionization

VLIW pre-history

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.

 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/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

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.

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

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

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.`

past posts in this thread:
http://www.garlic.com/~lynn/2007e.html#48time spent/day on a computer
http://www.garlic.com/~lynn/2007j.html#74IBM Unionization
http://www.garlic.com/~lynn/2007j.html#75IBM Unionization
http://www.garlic.com/~lynn/2007j.html#77IBM Unionization
http://www.garlic.com/~lynn/2007j.html#83IBM Unionization
http://www.garlic.com/~lynn/2007j.html#94IBM Unionization
http://www.garlic.com/~lynn/2007k.html#0IBM Unionization
http://www.garlic.com/~lynn/2007k.html#4IBM Unionization
http://www.garlic.com/~lynn/2007k.html#5IBM Unionization
http://www.garlic.com/~lynn/2007k.html#8IBM Unionization

IBM Unionization

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 arithmatic
(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 arithmatic 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

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

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#3 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

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#3 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

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

misc. past posts mentioning 3033 dual-address space support
http://www.garlic.com/~lynn/2002g.html#17 Black magic in POWER5
http://www.garlic.com/~lynn/2002g.html#18 Black magic in POWER5
http://www.garlic.com/~lynn/2002l.html#57 Handling variable page sizes?
http://www.garlic.com/~lynn/2003d.html#53 Reviving Multics
http://www.garlic.com/~lynn/2003d.html#69 unix
http://www.garlic.com/~lynn/2003g.html#13 Page Table - per OS/Process
http://www.garlic.com/~lynn/2003m.html#29 SR 15,15
http://www.garlic.com/~lynn/2004f.html#53 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004n.html#26 PCIe as a chip-to-chip interconnect
http://www.garlic.com/~lynn/2004n.html#54 CKD Disks?
http://www.garlic.com/~lynn/2004o.html#18 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004o.html#57 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005.html#3 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005b.html#53 The mid-seventies SHARE survey
http://www.garlic.com/~lynn/2005c.html#63 intel's Vanderpool and virtualization in general
http://www.garlic.com/~lynn/2005d.html#62 Misuse of word "microcode"
http://www.garlic.com/~lynn/2005f.html#7 new Enterprise Architecture online user group
http://www.garlic.com/~lynn/2005f.html#57 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005p.html#18 address space
http://www.garlic.com/~lynn/2005p.html#19 address space
http://www.garlic.com/~lynn/2005q.html#41 Instruction Set Enhancement Idea
http://www.garlic.com/~lynn/2005q.html#48 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2006.html#39 What happens if CR's are directly changed?
http://www.garlic.com/~lynn/2006b.html#25 Multiple address spaces
http://www.garlic.com/~lynn/2006b.html#28 Multiple address spaces
http://www.garlic.com/~lynn/2006e.html#0 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006i.html#33 virtual memory
http://www.garlic.com/~lynn/2006p.html#10 What part of z/OS is the OS?
http://www.garlic.com/~lynn/2006r.html#26 A Day For Surprises (Astounding Itanium Tricks)
http://www.garlic.com/~lynn/2006r.html#32 MIPS architecture question - Supervisor mode & who is using it?
http://www.garlic.com/~lynn/2006s.html#42 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006t.html#23 threads versus task
http://www.garlic.com/~lynn/2006x.html#23 Multiple mappings
http://www.garlic.com/~lynn/2006y.html#39 Multiple mappings
http://www.garlic.com/~lynn/2007g.html#59 IBM to the PCM market(the sky is falling!!!the sky is falling!!)

Data Areas Manuals to be dropped

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/subtopic.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?fn=OCO:BDAY&ft=MEMO

OCO & source business
http://vm.marist.edu/~vmshare/browse?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/subtopic.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

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/acis/history/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

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

misc. past posts mentioning 2301s and/or 2305s
http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door
http://www.garlic.com/~lynn/95.html#8 3330 Disk Drives
http://www.garlic.com/~lynn/95.html#12 slot chaining
http://www.garlic.com/~lynn/98.html#12 S/360 operating systems geneaology
http://www.garlic.com/~lynn/98.html#17 S/360 operating systems geneaology
http://www.garlic.com/~lynn/99.html#6 3330 Disk Drives
http://www.garlic.com/~lynn/99.html#104 Fixed Head Drive (Was: Re:Power distribution (Was: Re: A primeval C compiler)
http://www.garlic.com/~lynn/2000.html#92 Ux's good points.
http://www.garlic.com/~lynn/2000d.html#7 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#52 IBM 650 (was: Re: IBM--old computer manuals)
http://www.garlic.com/~lynn/2000d.html#53 IBM 650 (was: Re: IBM--old computer manuals)
http://www.garlic.com/~lynn/2000g.html#42 4M pages are a bad idea (was Re: AMD 64bit Hammer CPU and VM)
http://www.garlic.com/~lynn/2000g.html#45 4M pages are a bad idea (was Re: AMD 64bit Hammer CPU and VM)
http://www.garlic.com/~lynn/2001.html#17 IBM 1142 reader/punch (Re: First video terminal?)
http://www.garlic.com/~lynn/2001b.html#18 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
http://www.garlic.com/~lynn/2001c.html#15 OS/360 (was LINUS for S/390)
http://www.garlic.com/~lynn/2001c.html#17 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001h.html#26 TECO Critique
http://www.garlic.com/~lynn/2001h.html#36 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#37 Credit Card # encryption
http://www.garlic.com/~lynn/2001j.html#3 YKYGOW...
http://www.garlic.com/~lynn/2001l.html#53 mainframe question
http://www.garlic.com/~lynn/2001l.html#57 mainframe question
http://www.garlic.com/~lynn/2001l.html#63 MVS History (all parts)
http://www.garlic.com/~lynn/2001m.html#23 Smallest Storage Capacity Hard Disk?
http://www.garlic.com/~lynn/2002.html#22 index searching
http://www.garlic.com/~lynn/2002.html#31 index searching
http://www.garlic.com/~lynn/2002b.html#8 Microcode? (& index searching)
http://www.garlic.com/~lynn/2002b.html#11 Microcode? (& index searching)
http://www.garlic.com/~lynn/2002b.html#20 index searching
http://www.garlic.com/~lynn/2002b.html#23 Infiniband's impact was Re: Intel's 64-bit strategy
http://www.garlic.com/~lynn/2002b.html#24 Infiniband's impact was Re: Intel's 64-bit strategy
http://www.garlic.com/~lynn/2002b.html#31 bzip2 vs gzip (was Re: PDP-10 Archive migration plan)
http://www.garlic.com/~lynn/2002c.html#52 Swapper was Re: History of Login Names
http://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?
http://www.garlic.com/~lynn/2002i.html#16 AS/400 and MVS - clarification please
http://www.garlic.com/~lynn/2002i.html#17 AS/400 and MVS - clarification please
http://www.garlic.com/~lynn/2002i.html#42 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#47 AS/400 and MVS - clarification please
http://www.garlic.com/~lynn/2002j.html#70 hone acronym (cross post)
http://www.garlic.com/~lynn/2002l.html#40 Do any architectures use instruction count instead of timer
http://www.garlic.com/~lynn/2002m.html#73 VLSI and "the real world"
http://www.garlic.com/~lynn/2002n.html#54 SHARE MVT Project anniversary
http://www.garlic.com/~lynn/2002o.html#3 PLX
http://www.garlic.com/~lynn/2003.html#70 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#6 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#7 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#9 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#10 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#15 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#17 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#18 Card Columns
http://www.garlic.com/~lynn/2003c.html#36 "average" DASD Blocksize
http://www.garlic.com/~lynn/2003c.html#37 "average" DASD Blocksize
http://www.garlic.com/~lynn/2003c.html#53 HASP assembly: What the heck is an MVT ABEND 422?
http://www.garlic.com/~lynn/2003c.html#55 HASP assembly: What the heck is an MVT ABEND 422?
http://www.garlic.com/~lynn/2003f.html#13 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#19 Disk prefetching
http://www.garlic.com/~lynn/2003m.html#6 The real history of comp arch: the short form
http://www.garlic.com/~lynn/2003m.html#42 S/360 undocumented instructions?
http://www.garlic.com/~lynn/2003o.html#62 1teraflops cell processor possible?
http://www.garlic.com/~lynn/2004.html#6 The BASIC Variations
http://www.garlic.com/~lynn/2004.html#44 OT The First Mouse
http://www.garlic.com/~lynn/2004c.html#61 IBM 360 memory
http://www.garlic.com/~lynn/2004d.html#73 DASD Architecture of the future
http://www.garlic.com/~lynn/2004d.html#74 DASD Architecture of the future
http://www.garlic.com/~lynn/2004e.html#16 Paging query - progress
http://www.garlic.com/~lynn/2004f.html#21 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004f.html#54 [HTTP/1.0] Content-Type Header
http://www.garlic.com/~lynn/2004g.html#18 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004l.html#2 IBM 3090 : Was (and fek that) : Re: new computer kits
http://www.garlic.com/~lynn/2004n.html#22 Shipwrecks
http://www.garlic.com/~lynn/2004o.html#9 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005b.html#13 Relocating application architecture and compiler support
http://www.garlic.com/~lynn/2005c.html#3 The mid-seventies SHARE survey
http://www.garlic.com/~lynn/2005d.html#62 Misuse of word "microcode"
http://www.garlic.com/~lynn/2005e.html#5 He Who Thought He Knew Something About DASD
http://www.garlic.com/~lynn/2005h.html#7 IBM 360 channel assignments
http://www.garlic.com/~lynn/2005j.html#51  Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2005o.html#43 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005r.html#0 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#51 winscape?
http://www.garlic.com/~lynn/2005s.html#22 MVCIN instruction
http://www.garlic.com/~lynn/2005s.html#23 winscape?
http://www.garlic.com/~lynn/2005s.html#41 Random Access Tape?
http://www.garlic.com/~lynn/2005t.html#50 non ECC
http://www.garlic.com/~lynn/2006.html#2 Average Seek times are pretty confusing
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
http://www.garlic.com/~lynn/2006.html#41 Is VIO mandatory?
http://www.garlic.com/~lynn/2006c.html#1 Multiple address spaces
http://www.garlic.com/~lynn/2006c.html#8 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006c.html#46 Hercules 3.04 announcement
http://www.garlic.com/~lynn/2006e.html#46 using 3390 mod-9s
http://www.garlic.com/~lynn/2006g.html#0 IBM 3380 and 3880 maintenance docs needed
http://www.garlic.com/~lynn/2006i.html#27 Really BIG disk platters?
http://www.garlic.com/~lynn/2006i.html#41 virtual memory
http://www.garlic.com/~lynn/2006j.html#11 The Pankian Metaphor
http://www.garlic.com/~lynn/2006k.html#57 virtual memory
http://www.garlic.com/~lynn/2006m.html#5 Track capacity?
http://www.garlic.com/~lynn/2006q.html#1 Materiel and graft
http://www.garlic.com/~lynn/2006q.html#32 Very slow booting and running and brain-dead  OS's?
http://www.garlic.com/~lynn/2006r.html#23 50th Anniversary of invention of disk drives
http://www.garlic.com/~lynn/2006r.html#30 50th Anniversary of invention of disk drives
http://www.garlic.com/~lynn/2006r.html#36 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006s.html#23 Why magnetic drums was/are worse than disks ?
http://www.garlic.com/~lynn/2006s.html#30 Why magnetic drums was/are worse than disks ?
http://www.garlic.com/~lynn/2006s.html#32 Why magnetic drums was/are worse than disks ?
http://www.garlic.com/~lynn/2006s.html#33 Why magnetic drums was/are worse than disks ?
http://www.garlic.com/~lynn/2006s.html#42 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006s.html#45 Why magnetic drums was/are worse than disks ?
http://www.garlic.com/~lynn/2006s.html#48 5692 and 6SN7 vs 5963's for computer use
http://www.garlic.com/~lynn/2006s.html#59 Why magnetic drums was/are worse than disks ?
http://www.garlic.com/~lynn/2006t.html#18 Why magnetic drums was/are worse than disks ?
http://www.garlic.com/~lynn/2006v.html#31 MB to Cyl Conversion
http://www.garlic.com/~lynn/2006w.html#3 IBM sues maker of Intel-based Mainframe clones
http://www.garlic.com/~lynn/2006w.html#7 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2007c.html#0 old discussion of disk controller chache
http://www.garlic.com/~lynn/2007e.html#38 FBA rant
http://www.garlic.com/~lynn/2007e.html#59 FBA rant
http://www.garlic.com/~lynn/2007e.html#60 FBA rant
http://www.garlic.com/~lynn/2007e.html#64 FBA rant
http://www.garlic.com/~lynn/2007g.html#31 Wylbur and Paging
http://www.garlic.com/~lynn/2007g.html#33 Wylbur and Paging
http://www.garlic.com/~lynn/2007h.html#34 GA24-3639
http://www.garlic.com/~lynn/2007i.html#16 when was MMU virtualization first considered practical?

Another "migration" from the mainframe

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/subtopic.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

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 arithmatic.

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: 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

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

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

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/subtopic.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

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.

past posts mentioning call for 100 percent unearned profit tax on
domestic car builders:
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
http://www.garlic.com/~lynn/2007k.html#11 IBM Unionization

IBM 360 Model 20 Questions

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

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://www.cis.upenn.edu/~KeyKOS/

Tymshare ... a vm370-based commercial time-sharing system ... misc.
past posts
http://www.garlic.com/~lynn/subtopic.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).

various past posts mentioning GNOSIS
http://www.garlic.com/~lynn/2000f.html#69 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000g.html#22 No more innovation?  Get serious
http://www.garlic.com/~lynn/2001b.html#73 7090 vs. 7094 etc.
http://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001g.html#35 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001n.html#10 TSS/360
http://www.garlic.com/~lynn/2002f.html#59 Blade architectures
http://www.garlic.com/~lynn/2002g.html#4 markup vs wysiwyg (was: Re: learning how to use a computer)
http://www.garlic.com/~lynn/2002h.html#43 IBM doing anything for 50th Anniv?
http://www.garlic.com/~lynn/2002i.html#63 Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002j.html#75 30th b'day
http://www.garlic.com/~lynn/2003g.html#18 Multiple layers of virtual address translation
http://www.garlic.com/~lynn/2003h.html#41 Segments, capabilities, buffer overrun attacks
http://www.garlic.com/~lynn/2003j.html#20 A Dark Day
http://www.garlic.com/~lynn/2003k.html#50 Slashdot: O'Reilly On The Importance Of The Mainframe Heritage
http://www.garlic.com/~lynn/2003l.html#19 Secure OS Thoughts
http://www.garlic.com/~lynn/2003l.html#22 Secure OS Thoughts
http://www.garlic.com/~lynn/2003l.html#26 Secure OS Thoughts
http://www.garlic.com/~lynn/2003m.html#54 Thoughts on Utility Computing?
http://www.garlic.com/~lynn/2004c.html#4 OS Partitioning and security
http://www.garlic.com/~lynn/2004e.html#27 NSF interest in Multics security
http://www.garlic.com/~lynn/2004m.html#29 Shipwrecks
http://www.garlic.com/~lynn/2004m.html#49 EAL5
http://www.garlic.com/~lynn/2004n.html#41 Multi-processor timing issue
http://www.garlic.com/~lynn/2004o.html#33 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005.html#7 How do you say "gnus"?
http://www.garlic.com/~lynn/2005b.html#6 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005c.html#67 intel's Vanderpool and virtualization in general
http://www.garlic.com/~lynn/2005d.html#43 Secure design
http://www.garlic.com/~lynn/2005d.html#50 Secure design
http://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new?
http://www.garlic.com/~lynn/2005k.html#30 Public disclosure of discovered vulnerabilities
http://www.garlic.com/~lynn/2005s.html#12 Flat Query
http://www.garlic.com/~lynn/2006k.html#37 PDP-1
http://www.garlic.com/~lynn/2006m.html#34 PDP-1
http://www.garlic.com/~lynn/2006p.html#13 What part of z/OS is the OS?
http://www.garlic.com/~lynn/2006s.html#7 Very slow booting and running and brain-dead OS's?
http://www.garlic.com/~lynn/2006w.html#42 vmshare
http://www.garlic.com/~lynn/2006y.html#11 Multiple mappings
http://www.garlic.com/~lynn/2006y.html#16 "The Elements of Programming Style"

lots of past posts mentioning CP67's CCWTRAN
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist
http://www.garlic.com/~lynn/2000.html#68 Mainframe operating systems
http://www.garlic.com/~lynn/2000c.html#34 What level of computer is needed for a computer to Love?
http://www.garlic.com/~lynn/2001b.html#18 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
http://www.garlic.com/~lynn/2001i.html#37 IBM OS Timeline?
http://www.garlic.com/~lynn/2001i.html#38 IBM OS Timeline?
http://www.garlic.com/~lynn/2001l.html#36 History
http://www.garlic.com/~lynn/2002c.html#39 VAX, M68K complex instructions (was Re: Did Intel Bite Off More Than It Can Chew?)
http://www.garlic.com/~lynn/2002d.html#31 2 questions: diag 68 and calling convention
http://www.garlic.com/~lynn/2002g.html#61 GE 625/635 Reference + Smart Hardware
http://www.garlic.com/~lynn/2002j.html#70 hone acronym (cross post)
http://www.garlic.com/~lynn/2002l.html#65 The problem with installable operating systems
http://www.garlic.com/~lynn/2002l.html#67 The problem with installable operating systems
http://www.garlic.com/~lynn/2002n.html#62 PLX
http://www.garlic.com/~lynn/2002p.html#49 Linux paging
http://www.garlic.com/~lynn/2002p.html#51 Linux paging
http://www.garlic.com/~lynn/2003.html#60 MIDAS
http://www.garlic.com/~lynn/2003b.html#0 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003g.html#13 Page Table - per OS/Process
http://www.garlic.com/~lynn/2003g.html#14 Page Table - per OS/Process
http://www.garlic.com/~lynn/2003k.html#27 Microkernels are not "all or nothing". Re: Multics Concepts For
http://www.garlic.com/~lynn/2004.html#18 virtual-machine theory
http://www.garlic.com/~lynn/2004c.html#59 real multi-tasking, multi-programming
http://www.garlic.com/~lynn/2004d.html#0 IBM 360 memory
http://www.garlic.com/~lynn/2004e.html#40 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#50 Chained I/O's
http://www.garlic.com/~lynn/2004m.html#16 computer industry scenairo before the invention of the PC?
http://www.garlic.com/~lynn/2004n.html#26 PCIe as a chip-to-chip interconnect
http://www.garlic.com/~lynn/2004n.html#54 CKD Disks?
http://www.garlic.com/~lynn/2004o.html#57 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005b.html#23 360 DIAGNOSE
http://www.garlic.com/~lynn/2005b.html#49 The mid-seventies SHARE survey
http://www.garlic.com/~lynn/2005b.html#50 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005f.html#45 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005f.html#47 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005j.html#17 Performance and Capacity Planning
http://www.garlic.com/~lynn/2005p.html#18 address space
http://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005q.html#41 Instruction Set Enhancement Idea
http://www.garlic.com/~lynn/2005s.html#25 MVCIN instruction
http://www.garlic.com/~lynn/2005t.html#7 2nd level install - duplicate volsers
http://www.garlic.com/~lynn/2006.html#31 Is VIO mandatory?
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
http://www.garlic.com/~lynn/2006b.html#25 Multiple address spaces
http://www.garlic.com/~lynn/2006f.html#5 3380-3390 Conversion - DISAPPOINTMENT
http://www.garlic.com/~lynn/2006i.html#33 virtual memory
http://www.garlic.com/~lynn/2006j.html#5 virtual memory
http://www.garlic.com/~lynn/2006j.html#27 virtual memory
http://www.garlic.com/~lynn/2006m.html#25 Mainframe Limericks
http://www.garlic.com/~lynn/2006o.html#27 oops
http://www.garlic.com/~lynn/2006r.html#39 REAL memory column in SDSF
http://www.garlic.com/~lynn/2007e.html#19 Cycles per ASM instruction
http://www.garlic.com/~lynn/2007e.html#27 IBM S/360 series operating systems history
http://www.garlic.com/~lynn/2007e.html#46 FBA rant
http://www.garlic.com/~lynn/2007f.html#0 FBA rant
http://www.garlic.com/~lynn/2007f.html#6 IBM S/360 series operating systems history
http://www.garlic.com/~lynn/2007f.html#33 Historical curiosity question
http://www.garlic.com/~lynn/2007f.html#34 Historical curiosity question

user level TCP implementation

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/subtopic.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

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/subtopic.html#futuresys

however for most of the "lifetime", 370-xa was known as "811" for the
series of documents bearing the date nov78 (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

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 compareable 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

misc. past posts mentioning functionally illiterate
http://www.garlic.com/~lynn/2002k.html#45 How will current AI/robot stories play when AIs are real?
http://www.garlic.com/~lynn/2003i.html#28 Offshore IT
http://www.garlic.com/~lynn/2003i.html#45 Offshore IT
http://www.garlic.com/~lynn/2003i.html#55 Offshore IT
http://www.garlic.com/~lynn/2003p.html#33 [IBM-MAIN] NY Times editorial on white collar jobs going
http://www.garlic.com/~lynn/2004b.html#42 The SOB that helped IT jobs move to India is dead!
http://www.garlic.com/~lynn/2004d.html#18 The SOB that helped IT jobs move to India is dead!
http://www.garlic.com/~lynn/2004h.html#18 Low Bar for High School Students Threatens Tech Sector
http://www.garlic.com/~lynn/2005e.html#48 Mozilla v Firefox
http://www.garlic.com/~lynn/2005g.html#43 Academic priorities
http://www.garlic.com/~lynn/2006g.html#20 The Pankian Metaphor
http://www.garlic.com/~lynn/2006l.html#63 DEC's Hudson fab
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
http://www.garlic.com/~lynn/2007k.html#10 IBM Unionization

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 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

and using cp67/cms at npg school.

SSL Security

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

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

lots of past posts mentioning creation of cp67/cms multi-level source
update infrastructure
http://www.garlic.com/~lynn/2003e.html#66 History of project maintenance tools -- what and when?
http://www.garlic.com/~lynn/2003j.html#14 A Dark Day
http://www.garlic.com/~lynn/2003j.html#45 Hand cranking telephones
http://www.garlic.com/~lynn/2004b.html#59 A POX on you, Dennis Ritchie!!!
http://www.garlic.com/~lynn/2004g.html#43 Sequence Numbbers in Location 73-80
http://www.garlic.com/~lynn/2004m.html#30 Shipwrecks
http://www.garlic.com/~lynn/2005i.html#30 Status of Software Reuse?
http://www.garlic.com/~lynn/2005i.html#39 Behavior in undefined areas?
http://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005r.html#5 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005r.html#6 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2006b.html#10 IBM 3090/VM Humor
http://www.garlic.com/~lynn/2006e.html#7 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006f.html#5 3380-3390 Conversion - DISAPPOINTMENT
http://www.garlic.com/~lynn/2006f.html#25 Over my head in a JES exit
http://www.garlic.com/~lynn/2006f.html#38 Over my head in a JES exit
http://www.garlic.com/~lynn/2006n.html#45 sorting
http://www.garlic.com/~lynn/2006o.html#14 SEQUENCE NUMBERS
http://www.garlic.com/~lynn/2006o.html#27 oops
http://www.garlic.com/~lynn/2006q.html#45 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006u.html#26 Assembler question
http://www.garlic.com/~lynn/2006w.html#42 vmshare
http://www.garlic.com/~lynn/2006w.html#48 vmshare
http://www.garlic.com/~lynn/2007f.html#12 FBA rant

IBM Unionization

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.gar