List of Archived Posts

2007 Newsgroup Postings (03/08 - 03/27)

FBA rant

IBM S/360 series operating systems history

FBA rant

FBA rant

ISAM and/or self-modifying channel programs

FBA rant

IBM S/360 series operating systems history

IBM S/360 series operating systems history

Securing financial transactions a high priority for 2007

IBM S/360 series operating systems history

Beyond multicore

Is computer history taught now?

FBA rant

Why is switch to DSL so traumatic?

more shared segment archeology

Designing database tables for performance?

more shared segment archeology

Is computer history taught now?

What to do with extra storage on new z9

Is computer history taught now?

Historical curiosity question

The Perfect Computer - 36 bits?

The Perfect Computer - 36 bits?

The Perfect Computer - 36 bits?

The Perfect Computer - 36 bits?

The Perfect Computer - 36 bits?

The Perfect Computer - 36 bits?

The Perfect Computer - 36 bits?

The Perfect Computer - 36 bits?

The Perfect Computer - 36 bits?

The Perfect Computer - 36 bits?

Is that secure : <form action="https" from a local HTML page ?

A database theory resource - ideas

Historical curiosity question

Historical curiosity question

"MVS Experience"

Silly beginner questions

Is computer history taught now?

IBM System z9

Silly beginner questions

The Perfect Computer - 36 bits?

time spent/day on a computer

Is computer history taught now?

Is computer history taught now?

Is computer history taught now?

The Perfect Computer - 36 bits?

The Perfect Computer - 36 bits?

Is computer history taught now?

Is computer history taught now?

John W. Backus, 82, Fortran developer, dies

The Perfect Computer - 36 bits?

Is computer history taught now?

Is computer history taught now?

Is computer history taught now?

John W. Backus, 82, Fortran developer, dies

Is computer history taught now?

Is computer history taught now?

Is computer history taught now?

Securing financial transactions a high priority for 2007

virtual machines, the new, old thing (again)

Certificates

Is computer history taught now?

What happened to the Teletype Corporation?

The interactive experience on yesterday's Unix?

John W. Backus, 82, Fortran developer, dies

History - Early Green Card

IBM System z9

The Perfect Computer - 36 bits?

Securing financial transactions a high priority for 2007

What happened to the Teletype Corporation?

Is computer history taught now?

The interactive experience on yesterday's Unix?

Securing financial transactions a high priority for 2007

Is computer history taught now?

The interactive experience on yesterday's Unix?

Securing financial transactions a high priority for 2007

Working while young

John W. Backus, 82, Fortran developer, dies

What happened to the Teletype Corporation?

The Perfect Computer - 36 bits?

The Perfect Computer - 36 bits?

FBA rant

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: FBA rant
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 08 Mar 2007 13:49:58 -0700

DASDBill2@ibm-main.lst wrote:

Right.  And what device, other than the 2321, ever had meaningful  non-zero
values for the bb part of bbcchh?  In other words, if there  had never been any
2321, why would we have needed the extra 2 bytes for the bb  in seek and
search addresses?

re:
http://www.garlic.com/~lynn/2007e.html#64 FBA rant

for other drift ... if the geometry characteristics were to be ignored
then you could treat the six byte seek argument as the track number
(allowing the device to interpret the physical characteristics
... somewhat similar to what FBA does in the locate command for the
record number).

i.e. CKD seek command is six byte field
http://www.garlic.com/~lynn/gcard.html#26.1

treated as purely a 2**48 bit numeric would allow for nearly 300 trillion tracks

and FBA locate command
http://www.garlic.com/~lynn/gcard.html#26.2

is eight byte number, which could allow for 2**64 512-byte records
(i.e. 2**9 times 2**64 bytes, 2**73 bytes per device)

for something complete different, quicky search engine use turned up
this (IBM) patent reference on mapping tof CKD to native FBA hardware
http://www.patentstorm.us/patents/6112277-description.html

and title of above:

Method and means for reducing device contention by random accessing
and partial track staging of records according to a first DASD format
but device mapped according to a second DASD format

... snip ...

The above patent also references another patent:

Reference should be made to Menon, U.S. Pat. No. 5,301,304, "Emulating
Records in One Record Format in Another Record Format", issued Apr. 5,
1994. Menon exemplifies the state of the art in format conversion disclosing
an emulation method for rapidly accessing CKD records in which the CKD records
are stored on a disk drive in FBA format.

... snip ...

now as suggested in previous post
http://www.garlic.com/~lynn/2007e.html#46 FBA rant

what would be the difficulty in modifying whatever MVS calls its current
incantation of CCWTRANS ... to morph application space EXCP CCWs that
are still doing things like multi-track VTOC/PDS search into FBA operations
... aka there are hardware control units and hypervisor software that
perform such morphing ... then if the original VS2 started out with
(cp67's) CCWTRANS moved into the VS2 kernel ... why can't more current
hypervisor technology be moved directly into the VS2 kernel

here is decade-plus old descriptive narative of ECKD (from vm mailing list)
... basically discussing the retrofitting FBA-like channel commands to
CKD architecture:
http://listserv.uark.edu/scripts/wa.exe?A2=ind9604&L=ibmvm&T=0&P=9321

from above:

ECKD channel programs completely describe the nature and scope of data
transfer operation before the first data transfer command is executed.
These "predictive" channel programs "remove all possible surprise" from
the storage subsystem during data transfer operations. Like Fixed-Block
Architecture (FBA) DASD, ECKD uses the DEFINE EXTENT channel command to
delimit the range of tracks which may be affected by a channel program.
ECKD is still CKD: each record can contain Count, Key, and Data areas.
However, the count need not be CCHHR, as on conventional CKD DASD; one
could number the records sequentially, like FBA blocks.

... snip ...

as opposed to post
http://www.garlic.com/~lynn/2007e.html#40 FBA rant
with my nearly 25yr old email commenting on ECKD
http://www.garlic.com/~lynn/2007e.html#email820907

slightly older random email reference to CALYPSO and ECKD ... in the
following DMKTRD is the vm370 kernel module responsible for cp
"trace" command related to tracing virtual machine i/o and ccws.


To: wheeler
Date: 10/10/80  15:28:17

Lynn,

The new DMKTRD will trace CALYSPO' new Define Extent and Locate Record
CCW's. A 16 byte argument is displayed on the trace, immediately below the
trace of the CCW itself

Fix was tested virtual VM under VM and will go on 31B at STL by next
Tuesday.

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

IBM S/360 series operating systems history

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM S/360 series operating systems history
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 08 Mar 2007 16:27:46 -0700

Patrick O'Keefe wrote:

I remember 3 different BPSloaders - 3-card, 7-card, and 12-card versions.
There very well could have been a 6-card loader, too.  I have no idea what
the differences were but I bet the 3-card loader didn't uspport REP cards.

IPL does a "02" read operation of 24 bytes at location zero

followed by TIC CCW to location "8" (assuming it is a CCW) and when
the I/O operation completes does a LPSW on location zero.

for three card loader, you would have

first card read by IPL button with 24 bytes containing

8 byte PSW
8 byte READ CCW for 80 bytes of 2nd card, command chained to
8 byte READ CCW for 80 bytes of 3rd card

with TIC operation to +8, the first read CCW.

you now have a 160byte program+data and the PSW is setup to start with
the first instruction just read. this small program would loop reading
(following) cards until it got to last card and then branch to the
start of the program just read.

all of this came out of BPS. In fact, the CP67 kernel process was to
collect all the CP67 kernel TXT files and slap BPS loader on the
front. The BPS loader resolves all the ESD symbols and when finished
branchs to the address/symbol in the LDT card ... which pointed to the
"SAVECP" entry point. SAVECP would take the freshly loaded
core/storage image and write it to disk.

The CCWs were compatible between cards and tape ... so you could have
actual physical cards ... and/or have placed card image on tape and
performed the IPL operation on tape drive (instead of card reader).

in cp67 and vm370, the 3card loader was used to slap on the front of
single module "stand alone" utilities (like DDR, physical tape<->disk
copy routine).

3card loader could handle card deck containing single assemble, TXT
file.

BPS loader could handle card deck with multiple TXT decks ... needing
to resolve ESDs adcons between TXT decks

a couple old posts mentioning 3card loader:
http://www.garlic.com/~lynn/99.html#135 sysprog shortage - what questions would you ask?
http://www.garlic.com/~lynn/2001c.html#87 "Bootstrap"

CP67 didn't originally ship with source for the BPS loader (although
it shipped with source for everything else). One of the modifications
I made at the university involved changes to support "paging" portions
of the (fixed) cp67 kernel ... the process I used created a quite a
few new ESD entry symbols. Basic BPS loader provided with CP67 only
supported 256 ESD symbols ... which I managed to exceed. It was real
pain trying to deal with the number of ESD limitation until i found a
copy of the BPS loader source that i could fix/modify.

The simplest way then to create a "new" BPS loader was to assemble the
source and slap a 3card loader on the front of the BPS TXT file.

Even easier was to include 3 assembler "PUNCH" statements in the
source of the stand-alone utility (including the BPS assembler source)
that punched hex image for the 3card loader (in front of the TXT deck
being generated).

this has discussion of 3card loader in conjunction with DDRXA
http://www.cbttape.org/~jjaeger/cdrom.html

FBA rant

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: FBA rant
Newsgroups: bit.listserv.ibm-main
Date: Thu, 08 Mar 2007 16:58:15 -0700

DASDBill2 writes:

Please be more specific.  There are about 100 articles on that web  page.

I'm not sure I understand your reference ... with respect to post
... copy here at
http://www.garlic.com/~lynn/2007f.html#0 FBA rant

there is
http://www.garlic.com/~lynn/index.html

that has a number of URLs in different categories

including a pointer to html file:
http://www.garlic.com/~lynn/2007e.html

this particular HTML file has index with 66 articles (numeric labels
0-65)

the specific URL I was referencing in the post was
http://www.garlic.com/~lynn/2007e.html#64

most browsers would position within the file at label "64". If your
browser isn't capable of handling a URL that includes positioning
within a file ... then the index at the front of file
http://www.garlic.com/~lynn/2007e.html

has 66 entries and "64" is the next to the last index entry (numbered
from zero).  I'm not sure that will do you any good though ... since
if your browser can handle the original URL with relative position
... it also can't handle the relative URL in the index either.

Now there is another possibility that you may be having. I recently
updated file
http://www.garlic.com/~lynn/2007e.html

with most recent posts. If your browser has a earlier version of
2007e.html cached, that was obtained before the last couple postings
were added to the file ... then it would not be able to find the new
relative position (within the file as specified) and just position you
at the front of the file.

It also depends on how you may have configured your browser cache
settings ... some browsers have an option to check on consistency of
what is in the cache and the original either once per file after each
startup or check for consistency on every reference.

In any case, you usually can synchronize what might be in your browser
cache and the original file by hitting the reload button.

Now you repeat your same comment with respect to "there being 100
articles on that web page" ... and have used the comment both with
respect to
http://www.garlic.com/~lynn/2007e.html#64
and
http://www.garlic.com/~lynn/gcard.html#26.1

Looking at the body of your post ... there seems to be some issue with
whatever you are using that has trailing underscore on some flavors of
URL ... I don't know whether your browser processor is adding that
trailing underscore or not ... it doesn't exist in the original.

Now, I can see where your browser might have a stale cached copy of
2007e.html ... and not being able to find relative href/name "64"
within the file ... but the file gcard.html has had href/name of
"26.1" since it was first made available ... so it would seem unlikely
that you would have stale caching problems with both
http://www.garlic.com/~lynn/2007e.html#64
and
http://www.garlic.com/~lynn/gcard.html#26.1

not being able to find the relative position in both files. Possibly
you are having browser problems? Other possibility is possibly you
have some DNS cache poisoning and your browser isn't actually getting
to my real web pages at all?

FBA rant

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: FBA rant
Newsgroups: bit.listserv.ibm-main,alt.foiklore.computers
Date: Thu, 08 Mar 2007 18:25:42 -0700

DASDBill2@ibm-main.lst wrote:

You still have not gotten the point.  The problem I have is not with
my browser or any of your fine articles that you have posted.  My
problem is that you keep ignoring or missing my one and only question.
So here it is again in slow motion:

If IBM had never invented the 2321, why would we have ever needed the
bb part of the bbcchh seek address?

Please do not answer this question by pointing me to urls.  Please
summarize the answer in a very few words.

reference posts:
http://www.garlic.com/~lynn/2007e.html#64 FBA rant
http://www.garlic.com/~lynn/2007f.html#0 FBA rant
http://www.garlic.com/~lynn/2007f.html#2 FBA rant

i don't know. as implied in this post ... where i raised the question
about a number of code names
http://www.garlic.com/~lynn/2007e.html#38 FBA rant

including 2321 ... somebody then posted an answer providing what they thot to
have been the 2321 original project code name. that answer as to the 2321
code name then appeared to initiate some additional topic drift with respect
to 2321.

I then subsequently posted that the univ. where i was undergraduate had
obtained a 2321 as part of an ONR library automation grant and needed to
make sure it ran with both CICS and cp67
http://www.garlic.com/~lynn/2007e.html#51 FBA rant

I also happened to mention here
http://www.garlic.com/~lynn/2007e.html#63 FBA rant

that i happened to run into an engineer many years later that claimed
to have been part of the original 2321 development team.

i apologize that i've not done what you have instructed me to do.
maybe you should also try ordering some number of other people to also
answer your questions.

i apologize that i've not done what you have instructed me to do.
maybe you should also try ordering some number of other people to also
answer your questions.

ISAM and/or self-modifying channel programs

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: ISAM and/or self-modifying channel programs
Newsgroups: bit.listserv.ibm-main
Date: Thu, 08 Mar 2007 21:40:11 -0700

Art Celestini wrote:

Today, true, self-modifying channel programs would require the use of a Start
I/O driver since it is the real (not virtual) channel program that actually
executes.  The closest thing I've seen to that in MVS are specialized drivers
that use PCIs to monitor the progress of a channel program and then maybe make
an on-the-fly change to a CCW depending on some status or item of input data.
Such programs always have to allow for the possibility that the CCW to be
modified may have already been pre-fetched from storage by the IOP (thus the
change may not be in time).  Typically the change is simple, like changing a
NOP to a TIC, and if the change doesn't get made in time, the NOP just ends
the channel program.

i remember something about VTAM specifying virtual=real under MVS
.... so vtam application channel programs were directly executed. vtam
would allocate additional buffers and update/modify channel program in
a PCI interrupt appendage.

under vm there is diagnose x'98' ... real i/o that allows similar
capability, for virtual machine to do lock, unlock and real ccw
execution.

description here:
http://publibz.boulder.ibm.com/epubs/pdf/hcse5b11.pdf

from above:

The subfunctions of DIAGNOSE code X'98' are LOCK, UNLOCK, and
SSCH-Real.  The requested subfunction is identified by a code in the
Rx register. The LOCK subfunction locks a single 4 KB page of virtual
machine storage in host real storage. In addition, it returns to the
virtual machine the absolute storage address of the frame used to lock
the guest page. The UNLOCK subfunction unlocks a single 4 KB page of
virtual machine storage that was previously locked by DIAGNOSE code
X'98'.

... snip ...

recent posts self-modifying channel program
http://www.garlic.com/~lynn/2007e.html#14 Cycles per ASM instruction
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

FBA rant

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: FBA rant
Newsgroups: bit.listserv.ibm-main,alt.foiklore.computers
Date: Thu, 08 Mar 2007 23:17:27 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:

i apologize that i've not done what you have instructed me to do.
maybe you should also try ordering some number of other people to also
answer your questions.

reference:
http://www.garlic.com/~lynn/2007f.html#2 FBA rant
http://www.garlic.com/~lynn/2007f.html#3 FBA rant

part of the reason that i don't really know the definitive answer to
your question is that BB in BBCCHH may have been planned for a number
of related products ... besides the 2321.  i have some vague
recollection of discussions related to 1360/pdss which may have also
motivated the inclusion of BB in 360 ckd dasd architecture; i.e. even
if 2321 hadn't shipped ... the decision to include BB may have been
made assuming a variety of products that might use it.

in this 1360/PDSS reference
http://en.wikipedia.org/wiki/IBM_1360

it mentions having a total capacity of 2,250 "cells" possibly helping
motivate two digit BB field (as opposed to ten 2321 cells) under some
assumption that such devices might also eventually appear attached to
360 channels.

this may have also contributed to the DASD acronym for direct access
storage device ... because of the variety of storage technologies that
were being used in the period (not just disk and not just magnetic).

the above article implies that 1360 saw limited deployment, in part
because of various follow-on magnetic related storage devices like
3850 (however, it doesn't mean that the senior engineers hadn't
originally anticipated that such devices might be attached to 360
channels).

3850 reference
http://en.wikipedia.org/wiki/IBM_3850

there is mention in the above that the tape cartridges originally were
to be directly addressed ... possibly also using BB specification
... but it was eventually changed to the virtualized 3330
implementation. So there is possibility that 3850 originally was
envisioned as (also) being much more of a 2321 kind of operation
(having up to 4720 cartridges ... possibly also fitting into the BB
specification).

other past posts in this thread mentioning 2321:
http://www.garlic.com/~lynn/2007e.html#38 FBA rant
http://www.garlic.com/~lynn/2007e.html#51 FBA rant
http://www.garlic.com/~lynn/2007e.html#63 FBA rant
http://www.garlic.com/~lynn/2007e.html#64 FBA rant
http://www.garlic.com/~lynn/2007f.html#0 FBA rant

part of the issue is all of the senior people that would have likely
been involved in thinking about justification for including "BB" as
part of the standard architecture were gone by the time i showed
up. the senior people having moved on was also the excuse given for
periodically calling me in to play disk engineer ... recent posts
mentioning periodically getting called in to play disk engineer:
http://www.garlic.com/~lynn/2007b.html#28 What is "command reject" trying to tell me?
http://www.garlic.com/~lynn/2007e.html#40 FBA rant
http://www.garlic.com/~lynn/2007e.html#63 FBA rant

lots of past posts mentioning getting to play around in dasd
engineering lab (bldg 14) and dasd product test lab (bldg 15) ... sort
of across the street from sjr in bldg. 28.
http://www.garlic.com/~lynn/subtopic.html#disk

IBM S/360 series operating systems history

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM S/360 series operating systems history
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 09 Mar 2007 09:41:25 -0700

Mark H. Young wrote:

Seymour, was SVS and/or VS1 what you ran on a 360 or 370 processor with a
DAT box?  Or did MVT or MFT run native on those systems with a DAT box?

SVS prototype started out as adding virtual tables and CCWTRANS (from
cp67) cut into the side of MVT ... with otherwise minimumal changes to
how MVT otherwise operated (i.e. minimum amount of work and effort to
get MVT running with virtual memory turned on). So nearly all EXCP
channel programs had to get translated via CCWTRANS ... very much as
if MVT was running in virtual machine.  Lots of MVT kernel was fixed
so that kernel code didn't have to worry about page
faults. Application page faults were handled at very low level with
least amount of disturbance to the application ... again almost as if
MVT was running in a virtual machine. Recent post mentioning Ludlow
working on SVS prototyping ... somewhat hacking various pieces from
CP67 into MVT kernel.
http://www.garlic.com/~lynn/2007e.html#27 IBM S/360 series operating systems history

so you could sort of say that MVT ran native with a DAT box with a
bunch of stuff from CP67 hacked into the MVT kernel ... but they
changed its name to SVS.

Something similar but different had been done earlier to MVT by some
customers ... but running in virtual machine under CP67 called "hand
shaking" ... CP67 would present a page fault interrupt to MVT under
certain conditions (i.e. virtual problem state, non-key-zero)
... which allowed MVT to perform a task-switch. Later when missing
page had been fetch ... MVT would be presented a new kind of interrupt
as indication that missing page was now in real storage.

Later the VM370 and VS1 would have similar modifications as part of
VS1 "handshaking" support. In this case, something like a 4mbyte
virtual machine would be defined for VS1. VS1 would then build a
4mbyte virtual address space table ... where there was a one-for-one
mapping between each VS1 virtual page and the virtual machine page. In
effect, VS1 would no longer have any paging responsibility ... having
turned it all over to the VM370 kernel. VM370 would present page
interrupt to VS1, allowing VS1 to perform task switch ... while
waiting for vm370 to perform the page operation. when the page
operation was complete, vm370 would present a psuedo page i/o complete
interrupt to vs1. For a lot of workloads ... this (and misc. other
stuff) allowed VS1 to run faster in a vm370 virtual machine than it
did running directly on the hardware w/o vm370 ... at least on
processors with the ECPS VM microcode assists (started with 370 138s
& 148s) ... old post discussing ECPS
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist

There actually had been an earlier modification to MVT release 13 done
by Boeing Huntsville running on 360/67 SMP ... (I believe partitioned
running as two uni-processors). MVT had virtual address space the same
size as real storage (slightly analogous to the VS1 configuration)
... and did no paging and/or page fault operations. The issue was to
handle storage fragmentation.  MVT had horrendous problem with storage
fragmentation ... especially with long running applications. Boeing
Huntsville machines were primarily being used for long-running 2250
display/design applications ... would would experience large amounts
of storage fragmentation. The use of virtual address space ... wasn't
to make it look like there was more memory than really available
... but to re-arrange storage locations to appear contiguous. recent
posting mentioning Boeing Huntsville hack to MVT-13.
http://www.garlic.com/~lynn/2007b.html#45 Is anyone still running

IBM S/360 series operating systems history

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM S/360 series operating systems history
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 09 Mar 2007 12:16:35 -0700

Rick Fochtman wrote:

MVT and MFT never knew anything about DAT boxen. IIRC, the only 360 with
a DAT box was the 67, mainly for running CP67/CMS, the predecessor to
VM. The early 370 machines, 155 and 165 had no DAT box but they could be
upgraded to 155-II and 165-II by adding a DAT box, along with some other
features.

recent post in this thread:
http://www.garlic.com/~lynn/2007f.html#6 IBM S/360 series operating systems history

DAT Hardware for 165-II was especially big hit ... there was bunch of
stuff in 370 virtual memory architecture (i.e. "redbook" was cms
script file, depending on the options set, it either produced the full
architecture redbook or the subset 370 principle of operations). at
one point there was an escalation meeting where the 165 engineers
proposed dropping a bunch of stuff from the DAT architecture on the
grounds that they could get virtual memory hardware out six months
earlier if they didn't have to do all the extra stuff. It was
eventually agreed to ... and then all the other products that already
had full 370 virtual memory architecture implemented ...  had to go
back and remove all the stuff dropped to help 165 improve their
delivery schedule.

360/67 was originally for something called tss/360 ... which never
really got out of development ... there were all these release 0.xx
something in customer shops ... but the performance was really
horrible (among other issues). cp67/cms started as bootlegged project
at the cambridge science center
http://www.garlic.com/~lynn/subtopic.html#545tech

and eventually found customer installation at a lot of places that had
orderd 360/67 for tss/360. another project that saw some amount of
installations was MTS (michigan terminal system) done at UofM ... that
made use of the 360/67 dat box.

The morph from cp67 to vm370 had barely made it into customer
installations and POK discovered that it had enormous problem with
MVS/XA development schedule.  POK was able to convince corporate to
kill off the vm370 product and have all of the vm370/cms development
group transferred to POK to help with MVS/XA development. At the last
minute, Endicott managed to salvage a little of the vm370 product
development mission and acquire a small part of the development staff
... in order to keep the product going.

for a lot more on the early 360/67 period, including science center
implementing early virtual machine cp40 & cms on a custom modified
360/40 (with virtual memory hardware added) before 360/67 machines
became available ... see Melinda's history
http://www.princeton.edu/~melinda

Securing financial transactions a high priority for 2007

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Fri, 09 Mar 2007 13:32:20 -0700

jmfbahciv writes:

The same thing that happened to phone calls has not happened to
checks.  I cannot control the amounts extracted.  The extractor can
now take any amount it wants and doesn't need a number with my OK
any more.  At the moment, everytime I write a check, I open wide
their access to all my cash assets.  I am no longer the "operator"
of the amounts to be transferred.

re:
http://www.garlic.com/~lynn/2007e.html#65 Securing financial transactions a high priority for 2007

consider the issues that gave rise to the federal "do not call" list.

junk faxes got so bad at one point that we don't turn the fax on
unless we get a (regular) phone call saying that a fax is coming in.

one of the things in the x9.59 financial standard was that every
transaction required (strongly) authenticated authorization.
http://www.garlic.com/~lynn/x959.html#x959

IBM S/360 series operating systems history

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM S/360 series operating systems history
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 09 Mar 2007 15:05:56 -0700

Bob Halpern wrote:

Tss was implemented at Computer Scieces Corp

ref:
http://www.garlic.com/~lynn/2007f.html#7 IBM S/360 series operating systems history

at one time there was this joke about there possibly being 1200 people
in mohansic working on tss/360 and total of 12 people at the cambridge
science center working on cp67/cms (and aggregate productivity of the
science center exceeding the aggregate productivity of the 1200 people
in mohansic).

tss/360 did have a few loyal customers that hung on ... like GM
research ... and after tss/360 product was canceled there was enuf
interest for keeping a small group in place supporting some existing
customers, including doing a conversion to 370.

tss/370 saw some return to life at AT&T where there was a UNIX kernel built on
top of a stripped down tss/370 kernel (only available for internal AT&T)

at some point, IBM Germany looked at putting out a similar tss/370
mainframe unix product and put in place an official (new) product
group ... bringing some number of the tss/370 people over from the
states ... however this never made it out the door.

There were also number of vm-based unix projects under way in the
early to mid 80s which also never made it out the door.

There was effort started to do BSD offering on vm370 ... but part way
thru, it got retargeted to the PC/RT and released as a product for the
PC/RT called AOS (not to be confused with the AOS SVS prototype).

What finally made it out the doors was (unix-like) UCLA's "LOCUS"
offered as AIX/370 (under VM) and AIX/PS2 ... providing
single-system-image type operation, not only across mainframe systems
... but also between mainframes and PS2s (sort of what SAA from the
period claimed to aspire to).

Beyond multicore

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Beyond multicore
Newsgroups: comp.arch
Date: Sat, 10 Mar 2007 09:28:31 -0700

nmm1@cus.cam.ac.uk (Nick Maclaren) writes:

If I recall, it was somewhere between those positions.  My memory says
that it started out being called a 360/195 but sort-of turned into the
370/195.  I am pretty certain that this was more happenstance than
planned.

i got called into participate in looking at doing dual i-stream
370/195 i.e. dual i-stream, dual PSW, dual set of registers, etc
... but same/single pipeline, work in the pipeline had single bit A/B
flag as to which i-stream the work belonged to.  project never
actually shipped a product. the issue was that most codes ran about
half peak thruput because most branches would drain the pipeline. dual
i-stream had some probability of keeping pipeline filled.

past posts with any mention of smp activity (including 195 dual
i-stream)
http://www.garlic.com/~lynn/subtopic.html#smp

comment that I remember (vaguely, long ago and far away) being told
was that biggest transition from 360/195 to 370/195 was some of the
new fangled instruction retry that was showing up in 370s. claim was
that 195 had large number of components and along with the rate that
195 operated, the mean-time-between (soft) failure of some component
was on the order of ? (small number of) weeks (2-8?), which could be
masked by new fangled hardware instruction retry logic (besides the
couple new instructions announced with original 370 ... predating any
of the 370 virtual memory announcement).

SJR continued to operate 370/195 service running MVT until '78 (when
it was replaced with 168-3 & MVS)


To: wheeler
Date: 12/18/78  08:33:18

lynn--

Now that the /195 is gone, vm has acquired another printer (address
001) for class y output. Somehow, no one bothered to do a sysgen to
add the new printer. XXXXXX knows about this, but i doubt he knows
what to do. Could you see to it that the gen is done?

Now for some good news, the vm 168 has been approved along with the
additional head count. Question now is, when will it arrive?  Mgmnt
trying to establish a firm ship date (tenative date is in
July). Obviously, they are trying to move up that date.

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

And for a whole lot of topic drift, SJR had been running a vm 158 in
the datacenter and the computer science group had an additional vm
145.
http://www.garlic.com/~lynn/subtopic.html#systemr


From: wheeler
Date: 01/17/80  08:12:39

There are/were three different projects. A long time ago and far away,
some people from YKT come up to CSC and we worked with them on the 'G'
updates for CP/67 (running on a 67) which was to provide virtual 4-way
370 support. Included as part of that was an additional 'CPU' (5-way)
for debug purposes which was a super set of the other four and could
selectively request from CP that events from the 4-way complex be sent
to the super CPU for handling (basically it was going to be a debug
facility). All of this was going to be for supporting the design &
debug of a new operating system. When FS started to get into trouble
the YKT project was canceled (something like 50 people at its peak)
and the group was moved over to work on FS in hopes that they might
bail it out.

2) One or two people from that project escaped and got to SJR. Here,
primarily Vera Watson, wrote initial R/W shared segment support for VM
(turns out it was a simple subset of the 'G' updates) in support of
System R (relational data base language). Those updates are up and
running and somewhat distributed (a couple customers via joint studies
and lots of internal sites).

3) Independent of that work, another group at SJR has a 145 running a
modified VM with extremely enhanced modifed timer event support.  The
objective is to allow somebody to specify what speed CPU and how fast
the DASD are for a virtual machine operator test. VM calculates how
fast the real CPU & DASD are and 'adjust' the relative occurance of
all events so that I/O & timer interrupts occur after the appropriate
number of instructions have been executed virtually. These changes do
not provide multiple CPU support

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

Turns out that at least one of the other people involved in the "G"
cp67 activity was 195 engineer (and I believe was the vector that got
us involved in the 195 dual i-stream stuff, again, long ago and far
away)

and of course lots of past posts mentioning FS (future system)
http://www.garlic.com/~lynn/subtopic.html#futuresys

and of course by the time of the above email, Vera had already found
her resting place on Anapurna ... old post
http://www.garlic.com/~lynn/2002g.html#60 Amiga Rexx

other references:
http://lomaprieta.sierraclub.org/lp0012_TheSeventies.html
http://www.mcjones.org/System_R/SQL_Reunion_95/sqlr95-Vera.html

Is computer history taught now?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is computer history taught now?
Newsgroups: alt.folklore.computers
Date: Sat, 10 Mar 2007 09:52:04 -0700

a 370/195 archeological reference recently posted in comp.arch
http://www.garlic.com/~lynn/2007f.html#10 Beyond multicore

includes old email
http://www.garlic.com/~lynn/2007f.html#email800117

that raises connections between:

virtual 370 work done on cp67 at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

multiprocessor support
http://www.garlic.com/~lynn/subtopic.html#smp

future system project
http://www.garlic.com/~lynn/subtopic.html#futuresys

relational database
http://www.garlic.com/~lynn/subtopic.html#systemr

and lisp and computer AI
http://www.mcjones.org/System_R/SQL_Reunion_95/sqlr95-Vera.html

then for other drift ... connections between electronic commerce, DBMS, transactions:
http://www.garlic.com/~lynn/2007d.html#8 Jim Gray is Missing
http://www.garlic.com/~lynn/2007d.html#37 MAC and SSL

and an old post mentioning other kinds of connections between loosely-coupled,
sysplex, cluster, supercomputers and electronic commerce
http://www.garlic.com/~lynn/2001i.html#52

part of the above involves ha/cmp and medusa ... old emails
http://www.garlic.com/~lynn/lhwemail.html#medusa

specific mention of database scaleup
http://www.garlic.com/~lynn/2006x.html#email920129
in this post
http://www.garlic.com/~lynn/2006x.html#3

and electronic commerce work involving several of the people in this meeting
http://www.garlic.com/~lynn/95.html#13
http://www.garlic.com/~lynn/96.html#15
indirect reference
http://www.garlic.com/~lynn/2001n.html#83

commented on in these posts
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

FBA rant

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: FBA rant
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 10 Mar 2007 13:33:30 -0700

Anne & Lynn Wheeler wrote:

the above article implies that 1360 saw limited deployment, in part
because of various follow-on magnetic related storage devices like
3850 (however, it doesn't mean that the senior engineers hadn't
originally anticipating that such devices might be attached to 360
channels).

3850 reference
http://en.wikipedia.org/wiki/IBM_3850

there is mention in the above that the tape cartridges originally were
to be directly addressed ... possibly also using BB specification
.... but it was eventually changed to the virtualized 3330
implementation. So there is possibility that 3850 originally was
envisioned as (also) being much more of a 2321 kind of operation
(having up to 4720 cartridges ... possibly also fitting into the BB
specification).

re:
http://www.garlic.com/~lynn/2007f.html#5 FBA rant

for other topic drift ... this post started out as a question about
the difference between 360/195 and 370/195 in comp.arch
http://www.garlic.com/~lynn/2007f.html#10 Beyond multicore

and it wanders off into mentioning 195 engineer that had worked on the
"G" cp67 updates. In this old email (in the above referenced post)
http://www.garlic.com/~lynn/2007f.html#email800117

it mentions that group getting shanghaied to help bail out the
floundering FS project ... and Vera Watson escaping to SJR (to work on
system/r). The 195 engineer escaped to Boulder and I believe did some
of the work on 3850.

this followon posts mentions some of the connections between various
efforts
http://www.garlic.com/~lynn/2007f.html#11 Is computer history taught now?

including some obscure connection between system/r, lisp and computer AI.

and a referenced footnote
http://www.mcjones.org/System_R/SQL_Reunion_95/sqlr95-Vera.html#fn2

on VM/370 modifications to support system/r development

[3] J.N. Gray and V. Watson. A Shared Segment and Inter-Process
Communication Facility for VM/370. IBM Research Report RJ1579. San
Jose, California (May 1975).

now appears to have both authors lost; Vera on Anapurna and now Jim
appears to have been lost at sea
http://www.garlic.com/~lynn/2007d.html#4 Jim Gray Is Missing
http://www.garlic.com/~lynn/2007d.html#6 Jim Gray Is Missing
http://www.garlic.com/~lynn/2007d.html#8 Jim Gray Is Missing
http://www.garlic.com/~lynn/2007d.html#17 Jim Gray Is Missing
http://www.garlic.com/~lynn/2007d.html#33 Jim Gray Is Missing

for other drift ... some engineers from endicott had come out to the
science center
http://www.garlic.com/~lynn/subtopic.html#545tech

for joint project to modify cp67 to provide 370 virtual machines
... including support for (unannounced) 370 virtual memory. These were
the "H" updates to cp67. Then came the "I" updates to cp67
... modifying the cp67 kernel to run in 370 virtual machine
(i.e. instead of in a 360/67 virtual machine or on real 360/67).  The
"cp67-i" system was in regular operation a year before the first
engineering 370 machine with virtual memory support was even
operational (and then, cp67-i for a long time was the only operating
system that ran on real 370 machines with virtual memory).

The cp67 "G" level updates (to provide virtual 4-way 370 smp support)
were built ontop of the cp67 "H" updates (providing 370 virtual
machines). for other drift ... past posts mentioning mutliprocessor
support and/or compare&swap instruction
http://www.garlic.com/~lynn/subtopic.html#smp

The project for "L", "H", "I" (and "G") cp67 source updates ... also
spawned the CMS multi-level source update process.

misc. past post mentioning project to do cp67 support for 370 virtual
machines:
http://www.garlic.com/~lynn/2002h.html#50 crossreferenced program code listings
http://www.garlic.com/~lynn/2002j.html#0 HONE was .. Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002j.html#70 hone acronym (cross post)
http://www.garlic.com/~lynn/2004.html#44 OT The First Mouse
http://www.garlic.com/~lynn/2004b.html#31 determining memory size
http://www.garlic.com/~lynn/2004d.html#74 DASD Architecture of the future
http://www.garlic.com/~lynn/2004h.html#27 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2004p.html#50 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2005c.html#59 intel's Vanderpool and virtualization in general
http://www.garlic.com/~lynn/2005d.html#58 Virtual Machine Hardware
http://www.garlic.com/~lynn/2005d.html#66 Virtual Machine Hardware
http://www.garlic.com/~lynn/2005g.html#17 DOS/360: Forty years
http://www.garlic.com/~lynn/2005h.html#18 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005i.html#39 Behavior in undefined areas?
http://www.garlic.com/~lynn/2005j.html#50 virtual 360/67 support in cp67
http://www.garlic.com/~lynn/2005p.html#27 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
http://www.garlic.com/~lynn/2006e.html#7 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006f.html#5 3380-3390 Conversion - DISAPPOINTMENT
http://www.garlic.com/~lynn/2006l.html#21 Virtual Virtualizers
http://www.garlic.com/~lynn/2006m.html#26 Mainframe Limericks
http://www.garlic.com/~lynn/2006o.html#19 Source maintenance was Re: SEQUENCE NUMBERS
http://www.garlic.com/~lynn/2006q.html#1 Materiel and graft
http://www.garlic.com/~lynn/2006q.html#45 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006q.html#49 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006w.html#3 IBM sues maker of Intel-based Mainframe clones
http://www.garlic.com/~lynn/2007b.html#20 How many 36-bit Unix ports in the old days?

Why is switch to DSL so traumatic?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why is switch to DSL so traumatic?
Newsgroups: alt.folklore.computers
Date: Mon, 12 Mar 2007 10:17:23 -0600

"Joe Morris" <j.c.morris@verizon.net> writes:

I've also got in my files some of the letters we exchanged IBM when it
reneged on its explicit promise to provide us with the source to the PP
version of PROFS -- which resulted in our staying with a very heavily
modified version of the PRPQ, and our eventual removal of all IBM mainframes
from my shop.

one of the irksome problems for the PROFS group was that they had
co-opted a very early test version of VMSG (source) for PROFS mail
processing ... and then attempted to severely obstruct the VMSG
author ... even alluded to in MIP Envy
http://www.garlic.com/~lynn/2007d.html#email800920

in one of the escalation arguments on whether PROFS group had written
the email processing in PROFS or had borrowed VMSG source ... the VMSG
author was able to point out that his initials appeared at the end of
every network tag comment field for every email sent by PROFS (or
VMSG).

misc. past posts mentioning vmsg
http://www.garlic.com/~lynn/99.html#35 why is there an "@" key?
http://www.garlic.com/~lynn/2000c.html#46 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2001k.html#35 Newbie TOPS-10 7.03 question
http://www.garlic.com/~lynn/2001k.html#39 Newbie TOPS-10 7.03 question
http://www.garlic.com/~lynn/2001k.html#40 Newbie TOPS-10 7.03 question
http://www.garlic.com/~lynn/2002f.html#14 Mail system scalability (Was: Re: Itanium troubles)
http://www.garlic.com/~lynn/2002h.html#58 history of CMS
http://www.garlic.com/~lynn/2002h.html#64 history of CMS
http://www.garlic.com/~lynn/2002j.html#4 HONE, ****, misc
http://www.garlic.com/~lynn/2002p.html#34 VSE (Was: Re: Refusal to change was Re: LE and COBOL)
http://www.garlic.com/~lynn/2003b.html#45 hyperblock drift, was filesystem structure (long warning)
http://www.garlic.com/~lynn/2003j.html#56 Goodbye PROFS
http://www.garlic.com/~lynn/2004p.html#13 Mainframe Virus ????
http://www.garlic.com/~lynn/2005t.html#43 FULIST
http://www.garlic.com/~lynn/2005t.html#44 FULIST
http://www.garlic.com/~lynn/2005u.html#4 Fast action games on System/360+?
http://www.garlic.com/~lynn/2006n.html#23 sorting was: The System/360 Model 20 Wasn't As Bad As All That
http://www.garlic.com/~lynn/2006t.html#42 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2007d.html#17 Jim Gray Is Missing

more shared segment archeology

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: more shared segment archeology
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers
Date: Mon, 12 Mar 2007 13:21:48 -0600

One of the reasons the vm development group picked up so much from the
science center
http://www.garlic.com/~lynn/subtopic.html#545tech

to ship in the (vm370 product) release 3/4 time-frame was a lot of
the resources had been diverted to FS ... similar to the reference in
this post
http://www.garlic.com/~lynn/2007f.html#10 Beyond multicore
in this old email
http://www.garlic.com/~lynn/2007f.html#email800117

and some followup to the above
http://www.garlic.com/~lynn/2007f.html#11 Is computer history taught now?
http://www.garlic.com/~lynn/2007f.html#12 FBA rant

and lots of past posts mentioning future system project
http://www.garlic.com/~lynn/subtopic.html#futuresys

and then there was a relatively short window between the demise of FS
(and return of the diverted resources) and when POK convinced
corporate to completely shutdown VM and move all the people to POK to
support MVS/XA development ... as part of trying to get MVS/XA out the
door (everybody was scrambling to make up for lost time because of
FS). The reference in this post to POK convincing corporate about VM
shutdown and all the people diverted to MVS/XA (and Endicott salvaging
some of the VM mission) ... glosses over the period with lots of
resources diverted to work on FS
http://www.garlic.com/~lynn/2007f.html#7 IBM S/360 series operating systems history

In addition to development group having to play catch-up (by picking
up stuff from the science center for product ship; because of period
when a lot of resources were diverted to FS), there were also some
amount of stuff that had been dropped in the morph from cp67 to
vm370. I continued to work on cp67 during this period and then when
the science center got a 370/155-II ... ported a bunch of stuff to
vm370. Old communication from 1973 about porting/enhancing a bunch of
science center stuff from cp67 to vm370
http://www.garlic.com/~lynn/2006v.html#email731212
in this post
http://www.garlic.com/~lynn/2006v.html#36 Why these original FORTRAN quirks?

and related email from 1975 ... creating an "enhanced" vm rel2 system
for shipment to internal accounts:
http://www.garlic.com/~lynn/2006w.html#email750102
in this post
http://www.garlic.com/~lynn/2006w.html#7 Why these original FORTRAN quirks?
and
http://www.garlic.com/~lynn/2006w.html#email750430
in this post
http://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?

One of the items was whole restructuring for what I called virtual
memory management ... which included a bunch of bells and whistles
related to virtual memory segments as well as being integrated with
page mapped filesystem changes for CMS.

Much of the internal restructuring for handling virtual memory
segments was picked up as part of release 3 DCSS ... however only a
small subset of the function that utilized that restructuring was
actually shipped as part of release 3 DCSS.

I had also gotten roped into doing a lot of the ECPS work for Endicott,
old reference here
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist
http://www.garlic.com/~lynn/94.html#27 370 ECPS VM microcode assist
http://www.garlic.com/~lynn/94.html#28 370 ECPS VM microcode assist

and at the same time various SMP work ... old VAMPS email from 1975
http://www.garlic.com/~lynn/2006w.html#email750827
in this post
http://www.garlic.com/~lynn/2006w.html#10 long ago and far away, vm370 from early/mid 70s

lots of other posts mentioning VAMPS (5-way SMP project)
http://www.garlic.com/~lynn/subtopic.html#bounce

and lots of posts making general mention of SMP and/or
compare&swap instruction
http://www.garlic.com/~lynn/subtopic.html#smp

Another shared segment "feature" was a line item called DWSS that was
part of system/r technology transfer from SJR to Encidott for SQL/DS
product ... which allowed for shared segments that were "writable"
(i.e.  not r/o protected). A big issue with DWSS was what to do about
ECPS microcode already in the field that supported "r/o protection"
games for all segments identified as shared.

This was another downstream fall-outs of letting the 165 hardware
engineers gain six months in the vritual memory hardware change
schedule for 165-ii ... by letting them drop various features from the
370 virtual memory architecture. recent references
http://www.garlic.com/~lynn/2007f.html#6 IBM S/360 series operating systems history

One of the features dropped was the hardware segment table
"protection" bit ... which allowed specification of hardware r/o
protection for virtual memory segments on a virtual address space
basis (i.e.  some address spaces could be allowed r/w segment storage
operation while other address spaces were not allowed to change the
same shared segment). This also caused a big retrofit hit to vm370
since cp&cms had already been re-organized to take advantage of the
feature ... when it was dropped ... a real cludge was created ... also
referenced here
http://www.garlic.com/~lynn/2007d.html#32 Running OS/390 on z9 BC

effectively the original basis leading to the conflict with ECPS
and DWSS ... work referenced in this old email (also above)
http://www.garlic.com/~lynn/2007f.html#email800117

mentions shared segment extensions done initially at SJR in the
mid-70s for support of system/r (DWSS) ... original relational/sql ...
various posts mentioning system/r
http://www.garlic.com/~lynn/subtopic.html#systemr

This post (also mentioned above)
http://www.garlic.com/~lynn/2007f.html#12 FBA rant

references a san jose research report from May '75 ... about shared
segment and inter-processor communication for vm370 in support of
system/r effort. also mentioned in this SQL reunion item:
http://www.mcjones.org/System_R/SQL_Reunion_95/sqlr95-Vera.html#Index5

something similar also mentioned being shipped in this internal
release2 plc15 system (besides the virtual memory management stuff)
was also the (POK) SPM (which had originally been implemented by the
Pisa Science Center on cp67 and later converted to vm370)
http://www.garlic.com/~lynn/2006w.html#email750430

other posts mentioning DWSS:
http://www.garlic.com/~lynn/2000.html#18 Computer of the century
http://www.garlic.com/~lynn/2000b.html#55 Multics dual-page-size scheme
http://www.garlic.com/~lynn/2002g.html#59 Amiga Rexx
http://www.garlic.com/~lynn/2004f.html#23 command line switches [Re: [REALLY OT!] Overuse of symbolic
http://www.garlic.com/~lynn/2004f.html#26 command line switches [Re: [REALLY OT!] Overuse of symbolic
http://www.garlic.com/~lynn/2006t.html#16 Is the teaching of non-reentrant HLASM coding practices ever defensible?
http://www.garlic.com/~lynn/2006t.html#39 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006w.html#11 long ago and far away, vm370 from early/mid 70s
http://www.garlic.com/~lynn/2006y.html#26 moving on

Designing database tables for performance?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Designing database tables for performance?
Newsgroups: comp.databases.theory
Date: Mon, 12 Mar 2007 13:33:08 -0600

Bob Badour <bbadour@pei.sympatico.ca> writes:

Hi Lynn,

The above post sat in my newsreader marked unread for quite a while to
remind me I wanted to dig deeper when I was better rested. I did some
spelunking through the links above and other links at garlic.com

Some of the Boyd stuff is really interesting and thought-provoking.

ref:
http://www.garlic.com/~lynn/2007e.html#1 Designing database tables for performance

I had sponsored Boyd at corporate seminars in the early 80s.

misc. past posts mentioning Boyd
http://www.garlic.com/~lynn/subboyd.html#boyd
and various URLs from around the web with Boyd references
http://www.garlic.com/~lynn/subboyd.html#boyd2

now for something different, an obscure archeological relationship between
rdbms, lisp, and computer ai ... mentioned in this post
http://www.garlic.com/~lynn/2007f.html#11 Is computer history taught now?
the result of a little topic drift about 370/195
http://www.garlic.com/~lynn/2007f.html#10 Beyond multicore

and here:
http://www.mcjones.org/System_R/SQL_Reunion_95/sqlr95-Vera.html

more shared segment archeology

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: more shared segment archeology
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers
Date: Tue, 13 Mar 2007 09:28:09 -0600

jmfbahciv writes:

Without doing any of my homework, and just reacting with my gut,
this sounds like a very stupid decision to have made.  Now,
this is based on our OS philosophy about security.  Part of
security was to be able to not allow any writing, especially by
the bugs.

Also note that our file protection scheme included execute-only
and was settable by the owner of the file.

re:
http://www.garlic.com/~lynn/2007f.html#14 more shared segment archeology

370 virtual memory had/has two level tables for virtual memory
... each address space had a segment table with segment table entries
pointing to individual page tables (for each segment). Shared segments
was achieved by having different segment tables entiries point at the
same page table.

the original 370 virtual memory architecture had a flag in the segment
table entry indicating whether there was r/w or r/o access (by a
virtual address space) to a segment. this got dropped from 370 virtual
memory architecutre (before ever shipping to customers) as part of
improving schedule for 165-11 virtual memory by six months.

as a result, vm had to go back and create a cludge for supporting
protection of shared segments (actually a couple generations of
cludges). a flavor of this protection involved some amount of kernel
code ... which also got copied into the ECPS microcode assist (a 10:1
performance improvement in code that was moved from kernel 370
instructions into machine microcode ... or at least 10:1 improvement
for some heavily microcoded machines). lots of past post mentioning
machine microcoding
http://www.garlic.com/~lynn/subtopic.html#mcode

system/r effectively had semi-privilged "shadow" processes for doing
database work (running in their separate virtual address space
... slightly analogous ... but different to setuid root process).
these "shadow" processes needed to be able to have r/w access to
common shared memory (across all processes operating on the same
database).  lots of past post mentioning original relational/sql
http://www.garlic.com/~lynn/subtopic.html#systemr

this requirement for shared r/w access to common shared memory created
a product ship issue conflicting with standard kernel support. If it
was just software kernel ... then just ship new kernel with the
necessary changes ... however there were already quite a number of of
machines in customer shops where parts of the kernel were now part of
the machine microcode. The ECPS microcode created a (significant)
"service" expense issue to make sure that a field engineer updated the
machine microcode at the same time the new kernel for system/r
operation was installed. For instance who was to absorb the expense of
this field engineer microcode update coordination ... even the expense
to sending all possible field engineers to update class ... or even
developing the field engineer documentiation.

for other topic drift ... system/r related post in comp.databases.theory
http://www.garlic.com/~lynn/2007f.html#15 Designing database tables for performance

Is computer history taught now?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is computer history taught now?
Newsgroups: alt.folklore.computers
Date: Wed, 14 Mar 2007 11:02:27 -0600

pechter@pechter.dyndns.org (William Pechter) writes:

Wrong... the early business was both with Novell doing software and
hardware (they actually did servers the network cards, 3com did servers
and network cards)

But Novell, 3Com, and IBM's lan server market came in with client/server
stuff and killed the RSTS/E market.  It all wasn't single user
non-connected markets.  It was the 11/34 market, the 11/23 market that
was lost first.  Single user PC's weren't a big deal on the medium sized
business stuff until later.

there was a sanjose disk division project in the early 80s for lan
server implementation called DataHub ... part of which was outsourced
to a group in Provo, Utah under a work-for-hire contract. One of the
people involved was traveling almost weekly from San Jose to Provo.

For some reason, it was decided to cancel the project and the group in
Provo was allowed to retain rights to what they had been implementing
... I never knew the reason why ... and it seems to have been too early
to be the results of the political forces related to terminal emulation
that saw some number of projects canceld later in the 80s ... misc.
post mentioning terminal emulation and some of the political aspects
http://www.garlic.com/~lynn/subnetwork.html#emulation

misc. past posts mentioning DataHub project:
http://www.garlic.com/~lynn/96.html#4a John Hartmann's Birthday Party
http://www.garlic.com/~lynn/2000g.html#40 No more innovation?  Get serious
http://www.garlic.com/~lynn/2002f.html#19 When will IBM buy Sun?
http://www.garlic.com/~lynn/2002g.html#79 Coulda, Woulda, Shoudda moments?
http://www.garlic.com/~lynn/2002o.html#33 Over-the-shoulder effect
http://www.garlic.com/~lynn/2003e.html#26 MP cost effectiveness
http://www.garlic.com/~lynn/2003f.html#13 Alpha performance, why?
http://www.garlic.com/~lynn/2004f.html#16 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2005p.html#23 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005q.html#9 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005q.html#36 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2006l.html#39 Token-ring vs Ethernet - 10 years later
http://www.garlic.com/~lynn/2006y.html#31 "The Elements of Programming Style"

What to do with extra storage on new z9

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What to do with extra storage on new z9
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 14 Mar 2007 13:46:46 -0600

Mark Bodenstein wrote:

Thanks to everyone that replied.  We'll look into using additional
storage for CICS and VSAM buffers, and possibly for DFSORT.  We don't
run any Java at this point.  We may also add some additional XSTORE to
z/VM.

this somewhat descends into the area of system being able to more dynamically adapt
to different requirements with global infrastructure and basic assumptions related
to "LRU" (least recently used) replacement algorithms related to managing
caches, paging, buffers, etc).

LRU replacements algorithms basically tend to assume that storage used
in the recent past will assumed to be used in the near future (and
therefor replace storage that has been least recently used). This is
supported by studies that have observed program behavior with respect
to "recently" used storage. The issue is that its usefulness for
predicting future storage use patterns can significantly degrade as
the history interval becomes too large (i.e. no longer represents
"recent" behavior). A lot of reference use algorithms tends to
approximate LRU by resetting a storage reference bit ... on a
frequency that is proportional to both the amount of storage and the
demand for storage (if the reset frequency drops below some threshold,
the information can become useless).

so various issues to go to static partition allocation offsetting the
benefits of optimized global dynamic allocation

1) resource management doesn't know how to deal with global storage
infrastructure with lots of different kinds of competing demands

2) different competing uses may benefit from application specific
policies for replacement

3) partitioning storage is more likely to increase the frequency of
various reference use reset intervals ... improving the quality of the
subsequent replacement decisions.

With respect to #3, one of the characteristics of "two-handed" clock
replacement algorithm was to not make resetting of reference
information exactly synchronous with the testing of the reference
information. the "hand" doing the reference reset was offset from the
"hand" doing the reference testing. The degree of offset would be
adjusted to compensate for "large" storage sizes that resulted in the
reset frequency dropping below useful threshold.

I had implemented global LRU clock-like replacement algorithms as
undergraduate in the 60s ... lots of posts mentioning replacement
algorithms
http://www.garlic.com/~lynn/subtopic.html#wsclock

Also, various old email mentioning global LRU and replacement algorithms
http://www.garlic.com/~lynn/lhwemail.html#globallru

In the early 80s, there was some issues raised with somebody working
on global LRU replacement algorithms for Stanford PHD ... and I was
asked to provide supporting detail from my work when I was an
undergraduate in the 60s ... old communication on the subject
http://www.garlic.com/~lynn/2006w.html#email821019
in this post
http://www.garlic.com/~lynn/2006w.html#40 The Future of CPUs: What's After Multi-Core?

previous posts touching on the subject that a well-implemented dynamic
adaptive resource management should be able to outperform a
partitioned operation ... in discussion/threads mentioning whether it
is better to partition between XSTORE and normal storage ... or have
everything as single, unpartitioned storage.
http://www.garlic.com/~lynn/95.html#15 multilevel store
http://www.garlic.com/~lynn/2001m.html#25 ESCON Data Transfer Rate
http://www.garlic.com/~lynn/2001m.html#53 TSS/360
http://www.garlic.com/~lynn/2002c.html#53 VAX, M68K complex instructions (was Re: Did Intel Bite Off More Than   It Can Chew?)
http://www.garlic.com/~lynn/2002e.html#26 Crazy idea: has it been done?
http://www.garlic.com/~lynn/2002e.html#32 What goes into a 3090?
http://www.garlic.com/~lynn/2003j.html#2 Fix the shuttle or fly it unmanned
http://www.garlic.com/~lynn/2003p.html#41 comp.arch classic: the 10-bit byte
http://www.garlic.com/~lynn/2003p.html#46 comp.arch classic: the 10-bit byte
http://www.garlic.com/~lynn/2005.html#17 Amusing acronym
http://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new?
http://www.garlic.com/~lynn/2005j.html#13 Performance and Capacity Planning
http://www.garlic.com/~lynn/2006.html#16 Would multi-core replace SMPs?
http://www.garlic.com/~lynn/2006l.html#43 One or two CPUs - the pros & cons
http://www.garlic.com/~lynn/2006r.html#35 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006r.html#36 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006s.html#16 memory, 360 lcs, 3090 extended store, etc
http://www.garlic.com/~lynn/2006s.html#17 bandwidth of a swallow (was: Real core)
http://www.garlic.com/~lynn/2007c.html#23 How many 36-bit Unix ports in the old days?

Is computer history taught now?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is computer history taught now?
Newsgroups: alt.folklore.computers
Date: Thu, 15 Mar 2007 07:52:48 -0600

jmfbahciv writes:

Is this coincidence?  Maybe this was that hump that manufactures
had to get over---errmmm...similar to switching the product
line to put out radial tires rather than wagon wheels.

re:
http://www.garlic.com/~lynn/2007f.html#17 Is computer history taught now?

and what provo, utah lan server company was formed shortly later (hint:
starts with the letter "N")?

a possible conjecture might have been that some decisions was made
about not spreading out into disk business other than CKD mainframe
(i.e. mainframe as the server ... not promoting proliferation of other
kinds of servers) the flyer for non-CKD disk from the 70s could be
considered FBA 3310 (piccolo) and 3370 (NFP) ... misc. recent posts
about FBA:
http://www.garlic.com/~lynn/2007e.html#35 FBA rant
http://www.garlic.com/~lynn/2007e.html#38 FBA rant
http://www.garlic.com/~lynn/2007e.html#39 FBA rant
http://www.garlic.com/~lynn/2007e.html#40 FBA rant
http://www.garlic.com/~lynn/2007e.html#42 FBA rant
http://www.garlic.com/~lynn/2007e.html#43 FBA rant
http://www.garlic.com/~lynn/2007e.html#46 FBA rant
http://www.garlic.com/~lynn/2007e.html#51 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#63 FBA rant
http://www.garlic.com/~lynn/2007e.html#64 FBA rant
http://www.garlic.com/~lynn/2007f.html#0 FBA rant
http://www.garlic.com/~lynn/2007f.html#2 FBA rant
http://www.garlic.com/~lynn/2007f.html#3 FBA rant
http://www.garlic.com/~lynn/2007f.html#5 FBA rant
http://www.garlic.com/~lynn/2007f.html#12 FBA rant

of course the later battles over restricting mainframe access to
terminal emulation could be considered to have helped accelerate
other types of servers
http://www.garlic.com/~lynn/subnetwork.html#emulation

Historical curiosity question

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: re: Historical curiosity question
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers
Date: Fri, 16 Mar 2007 02:06:01 -0600

"McKown, John" wrote:

This is not important, but I just have to ask this. Does anybody know
why the original designers of VM did not do something for "minidisks"
akin to a OS/360 VTOC? Actually, it would be more akin to a "partition
table" on a PC disk. It just seems that it would be easier to maintain
if there was "something" on the physical disk which contained
information about the minidisks on it. Perhaps with information such
as: start cylinder, end cylinder, owning guest, read password, etc. CP
owned volumes have an "allocation map", this seems to me to be an
extention of that concept.

CP67 had a global directory ... that was indexed and paged ... so it
didn't need individual volume index.

it also avoided the horrendous overhead of multi-track search that
os/360 used to search the volume VTOC on every open. lots of past
posts mentioning multi-tract paradigm for VTOC & PDS directory was
io/memory trade-off ... os/360 target in the mid-60s was to burn
enormous i/o capacity to save having in-memory index.
http://www.garlic.com/~lynn/subtopic.html#dasd

that resource trade-off had changed by at least the mid-70s ...  and
it wasn't ever true for the machine configurations that cp67 ran on.

the other characteristic was that both cp67 and cms treated disks as
fixed-block architecture ... even if they were CKD ... CKD disks would
be formated into fixed-blocks ... and then treated as fixed-block
devices ... and avoid the horrible i/o performance penalty of ever
doing multi-track searches for looking up location and/or other
information on disk.

recent thread in bit.listserv.ibm-main
http://www.garlic.com/~lynn/2007e.html#35 FBA rant
http://www.garlic.com/~lynn/2007e.html#38 FBA rant
http://www.garlic.com/~lynn/2007e.html#39 FBA rant
http://www.garlic.com/~lynn/2007e.html#40 FBA rant
http://www.garlic.com/~lynn/2007e.html#42 FBA rant
http://www.garlic.com/~lynn/2007e.html#43 FBA rant
http://www.garlic.com/~lynn/2007e.html#46 FBA rant
http://www.garlic.com/~lynn/2007e.html#51 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#63 FBA rant
http://www.garlic.com/~lynn/2007e.html#64 FBA rant
http://www.garlic.com/~lynn/2007f.html#0 FBA rant
http://www.garlic.com/~lynn/2007f.html#2 FBA rant
http://www.garlic.com/~lynn/2007f.html#3 FBA rant
http://www.garlic.com/~lynn/2007f.html#5 FBA rant
http://www.garlic.com/~lynn/2007f.html#12 FBA rant

the one possible exception was loosely-coupled single-system-image
support done for HONE system. HONE mini-disk volumes had an in-use
bitmap directory on each volume ... that was used to manage "LINK"
consistency across all machines in the cluster. it basically used
a channel program with search operation to implement i/o logical
equivalent to the atomic compare&swap instruction ... avoiding having
to do reserve/release with intervening i/o operations. I have some
recollection talking to the JES2 people about them trying a similar
strategy for multi-system JES2 spool allocation. post from above
mentioning HONE compare&swap channel program for multi-system
cluster operation
http://www.garlic.com/~lynn/2007e.html#38 FBA rant

HONE was vm-based online interactive for world-wide sales, marketing,
and field people. It originally started in the early 70s with a clone
of the science center's cp67 system
http://www.garlic.com/~lynn/subtopic.html#545tech

and eventually propagated to several regional US datacenters ...  and
also started to propagate overseas. I provided highly modified cp67
and then later vm370 systems for HONE operation for something like 15
yrs. I also handled some of the overseas clones ... like when EMEA
hdqtrs moved from the states to just outside paris in the early 70s.
In the mid-70s, the US HONE datacenters were consolidated in northern
cal. ... and single-system-image software support quickly emerge
... running multiple "attached processors" in cluster operation.  HONE
applications were heavily APL ... so it was quite compute intensive.
With four-channel controllers and string-switch ... you could get
eight system paths to every disk. Going with "attached processors"
... effectively two processors made use of a single set of channels
... so you could get 16 processors in single-system-image ... with
load-balancing and failure-fallover-recovery.

Later in the early 80s, the northern cal. HONE datacenter was
replicated first in Dallas and then a third center in Boulder ... for
triple redundancy, load-balancing and fall-over (in part concern about
natural disasters like earthquakes).

lots of past posts mentioning HONE
http://www.garlic.com/~lynn/subtopic.html#hone

At one point in SJR after the 370/195 machine ... recent reference
http://www.garlic.com/~lynn/2007f.html#10 Beyond multicore
http://www.garlic.com/~lynn/2007f.html#11 Is computer history taught now?
http://www.garlic.com/~lynn/2007f.html#12 FBA rant

was replaced with mvs/168 system ... and vm was running on 370/158 ...
there were multiple strings of 3330 dasd ... with whole strings
supposedly dedicated to vm and other strings dedicated to mvs. there
were "rules" that mvs packs should never be mounted on vm "strings"
(because of the horrendous vtoc & pds directory multi-track search
overhead hanging channel, control units, string switches, and drives).

Periodically it would happen .. in specific instances ... users would
be calling the operator within five minutes claiming vm/cms
interactive response and totally deteriorated. Then it would require
tracking down the offending MVS pack.  One of the events, the MVS
operator refused to take down the pack and move it ...  because some
long running application had just started. So to give them a taste of
their own medicine ... we brought up a highly optimized VS1 system in
a virtual machine on the (loaded) vm/158 with a couple packs on MVS
string and proceeded to start some operations that brought MVS to its
knees ...  drastically inhibiting the long running MVS application
from getting any useful thruput (and effectively negating its
debilitating effect of vm/cms interactive response). The MVS operator
then quickly reconfigured everything and aggreed that MVS would keep
its packs off VM disk strings.

some old posts retelling the sjr mvs/168 and vm/158 response story:
http://www.garlic.com/~lynn/94.html#35 mainframe CKD disks & PDS files (looong... warning)
http://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)
http://www.garlic.com/~lynn/2002.html#10 index searching
http://www.garlic.com/~lynn/2002d.html#22 DASD response times
http://www.garlic.com/~lynn/2002f.html#8 Is AMD doing an Intel?
http://www.garlic.com/~lynn/2002l.html#49 Do any architectures use instruction count instead of timer
http://www.garlic.com/~lynn/2003.html#15 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003b.html#22 360/370 disk drives
http://www.garlic.com/~lynn/2003c.html#48 "average" DASD Blocksize
http://www.garlic.com/~lynn/2003f.html#51 inter-block gaps on DASD tracks
http://www.garlic.com/~lynn/2003k.html#28 Microkernels are not "all or nothing". Re: Multics Concepts For
http://www.garlic.com/~lynn/2003m.html#56 model 91/CRJE and IKJLEW
http://www.garlic.com/~lynn/2003o.html#64 1teraflops cell processor possible?
http://www.garlic.com/~lynn/2004g.html#11 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#51 Channel busy without less I/O
http://www.garlic.com/~lynn/2004l.html#20 Is the solution FBA was Re: FW: Looking for Disk Calc
http://www.garlic.com/~lynn/2004n.html#52 CKD Disks?
http://www.garlic.com/~lynn/2005r.html#19 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005u.html#44 POWER6 on zSeries?
http://www.garlic.com/~lynn/2006s.html#15 THE on USS?

The Perfect Computer - 36 bits?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Perfect Computer - 36 bits?
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 16 Mar 2007 02:17:02 -0600

John Ahlstrom <AhlstromJK@comcast.net> writes:

IBM had been getting 2**24 bit memory and 24 bit addresses
with 12 bit displacements in instructions since 1964 (announcement)
or 1965 (delivery).  Granted they had a base register as well
as an index register in their effective address calculation,
but that could always have been done in a previous instruction
in a 10-like machine with 35-bit addresses and 18 bit displacements.

360/67 ... had two virtual memory modes ... one was 24-bit addressing
and the other was 32-bit addressing.

360/67 functional characteristics (dated 1967, from bitsavers):
http://www.bitsavers.org/pdf/ibm/360/funcChar/A27-2719-0_360-67_funcChar.pdf

in transition to 370 virtual memory, only 24-bit addressing was
supported.

370-xa re-introduced virtual addressing larger than 24-bits ... but it
was only 31-bits (instead of 32-bits) ... and operating system had to
support 24-bit applications, 31-bit applications, and mixed-mode
applications. things got a lot more complicated when 64-bit addressing
was introduced ... and having to support three different addressing
modes.

recent principles of operations
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/CCONTENTS?SHELF=DZ9ZBK03&DN=SA22-7832-03&DT=20040504121320

from above ... 1.1.5 Trimodel Addressing
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/1.1.5?SHELF=DZ9ZBK03&DT=20040504121320

The Perfect Computer - 36 bits?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Perfect Computer - 36 bits?
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 16 Mar 2007 06:47:47 -0600

re:
http://www.garlic.com/~lynn/2007f.html#21 The Perfect Computer - 36 bits?

then there was ROMP in the early 80s. It was 801/RISC running CP.r and
PL.8 compiler. There was claim that ROMP had 40-bit addressing.

The issue was that there was 32-bit addressing ... however, there was
no protection domain. Virtual memory was inverted tables ...  with
segmented address space. Top 4 bits of 32-bit virtual address would
index 16 "segment registers". A segment register was 12bits which was
combined with the remaining 28-bits of the virtual address ... for
40-bit effective value for doing TLB lookup ... to find the real
address.

PL.8 supposedly would only generate correct code and CP.r would only
load correct/valid PL.8 generated code for execution. As a result
there was an assumption that applications could change a segment
register value as easily as applications could change general
registers used in addressing. The implication was that applications
had complete control over general register values as part of
addressing as well as complete control over segment register values
for addressing. Therefor "applications" had full access to "40-bit"
addressing (i.e. up to 4096 different "segments" that are 2**28
each).

All of this was joint research/opd (office product division) project
for follow-on to displaywriter. When that got killed, there was some
investigation what could be done to avoid killing the whole
operation. There was this "new" thing UNIX ... and lots of places were
shipping hardware w/o having to invent/create an operating system from
scratch (which was getting to be more expensive that creating the
hardware). The idea was to retarget ROMP to the unix workstation
market ... hiring the company that had done the unix port for pc/ix to
do one for ROMP.

The issue now was that UNIX paradigm had protection domain between the
kernel and applications ... and applications weren't allowed to
directly change virtual memory segment values. This effectively
restricted unix romp application paradigm to straight 32-bit
addressing.

For RIOS (power/rs6000), the segment register size was doubled to
24bits. Early rs6000 technology documents continued to talk about the
"52-bit" addressing (as continuation of the ROMP 40-bit addressing)
... even tho system paradigm had long changed from CP.r to UNIX.

misc. "old" email mentioning 801, iliad, romp, etc
http://www.garlic.com/~lynn/lhwemail.html#801

including these mentioning figuring out how to simulate a larger
number of "small" shared segments (rather than being restricted to
sixteen 28-bit segments).
http://www.garlic.com/~lynn/2006y.html#email841114c
http://www.garlic.com/~lynn/2006y.html#email841127

and any past posts happening to mention 801, iliad, romp, rios,
somerset, power/pc, etc
http://www.garlic.com/~lynn/subtopic.html#801

The Perfect Computer - 36 bits?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Perfect Computer - 36 bits?
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 16 Mar 2007 07:05:38 -0600

jmfbahciv writes:

There were many sane ways to move customers from the one product
line to the other, IF that was a goal.  The choice was the  most
insane method.  This was part of the IBM thinking that was
injected (sorry, Lynn) into middle management.  IBM customers
were used to being ordered around "for their own good".  DEC
customers had always been severely allergic to this kind of
treatment; this allergy was why they bought DEC instead
of IBM in the first place.

don't apologize to me ... circa '90 and early 90s, picking up a bunch
of former middle managers ... was about when there were a significant
number of middle managers were let go as part of trying to "flatten"
the organizations.

also the larger bureaucracy, the more you might have individuals
afflicted with Boyd's characterization about rigid, top/down
command and control ... recent posts
http://www.garlic.com/~lynn/2007e.html#45 time spent/day on a computer
http://www.garlic.com/~lynn/2007e.html#55 time spent/day on a computer

and as i've previously mentioned, there were quite a few that
I might not have been particularly partial to ... misc. references
http://www.garlic.com/~lynn/2007.html#22 MS to world: Stop sending money, we have enough
http://www.garlic.com/~lynn/2007.html#26 MS to world: Stop sending money, we have enough
http://www.garlic.com/~lynn/2007b.html#29 How many 36-bit Unix ports in the old days
http://www.garlic.com/~lynn/2007e.html#48 time spent/day on a computer

The Perfect Computer - 36 bits?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Perfect Computer - 36 bits?
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 16 Mar 2007 09:00:50 -0600

krw <krw@att.bizzzz> writes:

...and those managers (in the early '90s) were exactly the ones who
most needed flattening. DEC couldn't have done any worse with the
entire senior management team.  They almost took IBM under.

re:
http://www.garlic.com/~lynn/2007f.html#23 The Perfect Computer - 36 bits?

and you took a lot more heat if you were predicting such stuff in the mid-80s,
a couple past posts
http://www.garlic.com/~lynn/2005j.html#32 IBM Plugs Big Iron to the College Crowd
http://www.garlic.com/~lynn/2005s.html#16 Is a Hurricane about to hit IBM ?
http://www.garlic.com/~lynn/2006.html#21 IBM up for grabs?
http://www.garlic.com/~lynn/2006.html#22 IBM up for grabs?
http://www.garlic.com/~lynn/2006l.html#17 virtual memory

The Perfect Computer - 36 bits?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Perfect Computer - 36 bits?
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 16 Mar 2007 09:47:27 -0600

John Ahlstrom <AhlstromJK@comcast.net> writes:

See:

Virtualizing the VAX architecture
Preliminary Design of a VAX-I1 Virtual Machine Monitor Security
Kernel. Technical Report DEC TR-126, Digital Equipment Corporation,
Hudson, MA, ...
portal.acm.org/citation.cfm?id=115952.115990 - Similar pages

A Retrospective on the VAX VMM Security Kernel
45 {45} P. A. Karger, "Preliminary design of a VAX-11 virtual machine
monitor security kernel," Digital Equip. Corp., Hudson, MA,
Tech. Rep. ...
portal.acm.org/citation.cfm?coll=GUIDE&dl=GUIDE&id=123459 - Similar pages
[ More results from portal.acm.org ]

may have been somewhat/totally coincidental ... but when POK convinced
corporate that the vm370 development group (at the time, located in
the old SBC bldg. in burlington mall) had to be shutdown (including
the product) and everybody moved to POK help get MVS/XA out the door
... some number of people didn't moved ... and several round up at
DEC (workng on what was to become vax/vms)

Endicott managed to salvage some of the mission and keep the product
from totally being canceled.

a few recent posts mentioning the event:
http://www.garlic.com/~lynn/2007.html#23 How to write a full-screen Rexx debugger?
http://www.garlic.com/~lynn/2007e.html#41 IBM S/360 series operating systems history
http://www.garlic.com/~lynn/2007f.html#14 more shared segment archeology

The Perfect Computer - 36 bits?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Perfect Computer - 36 bits?
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 16 Mar 2007 12:47:55 -0600

Peter Flass <Peter_Flass@Yahoo.com> writes:

Maybe in some respects, but many would say the reason for IBM's
success was that it always tried to maintain backwards-compatibility.
A program from the earliest 360 days (executable, not just source)
will run the same today on the most recent version of the hardware and
OS.  That's 42 years of compatibility!

the big new thing in the early to mid 70s was going to be "FS" (future
system), it would have been radically more different from 360 than
360 had been what had gone before
http://www.garlic.com/~lynn/subtopic.html#futuresys

i've commented several times that when FS was finally killed ... there
was big scramble to catch-up for all the years of lost time ...  one
could claim that POK convincing corporate to kill-off VM ... so that
all the VM development people could be moved to POK to help
get MVS/XA out the door. some recent comments:
http://www.garlic.com/~lynn/2007.html#23 How to write a full-screen Rexx debugger?
http://www.garlic.com/~lynn/2007e.html#41 IBM S/360 series operating systems history
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#25 The Perfect Computer - 36 bits?

I've also commented that it may have not only indirectly contributed
to the clone processor business (i.e. distracted the company from
bread&butter legacy systems with all attention focused on turning out
this fabulous new FS thing) but also possibly directly
contributed. I've commented before that at a talk that Amdahl gave in
large MIT auditorium in the early 70s ...  he was asked how he was
able to make the business case for starting a clone processor company
... his comment was something about there already being so much
customer application software ... that even if ibm was to totally walk
away from 360 (possibly vieled reference to FS), there was enough
customer application software to keep him in business thru the end of
the century. recent posts mentioning amdahl
http://www.garlic.com/~lynn/2007.html#11 vm/sp1
http://www.garlic.com/~lynn/2007.html#14 vm/sp1
http://www.garlic.com/~lynn/2007.html#38 How many 36-bit Unix ports in the old days?
http://www.garlic.com/~lynn/2007.html#44 vm/sp1
http://www.garlic.com/~lynn/2007b.html#1 How many 36-bit Unix ports in the old days?
http://www.garlic.com/~lynn/2007d.html#3 Has anyone ever used self-modifying microcode? Would it even be useful?
http://www.garlic.com/~lynn/2007e.html#5 Is computer history taugh now?
http://www.garlic.com/~lynn/2007e.html#41 IBM S/360 series operating systems history
http://www.garlic.com/~lynn/2007e.html#42 FBA rant
http://www.garlic.com/~lynn/2007e.html#48 time spent/day on a computer

supposedly the justification for FS was all the clone controller and
device business ... I had worked on one such when I was an
undergraduate in the 60s ... and some article was written blaming us
(at least in part) for the clone controller (and clone device)
business. misc past post
http://www.garlic.com/~lynn/subtopic.html#360pcm

but then the sidetrack into Future System project significantly
aided the clone processor business. posts with some specific comments
http://www.garlic.com/~lynn/2006r.html#36 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006w.html#2 IBM sues maker of Intel-based Mainframe clones
http://www.garlic.com/~lynn/2007f.html#10 Beyond multicore
http://www.garlic.com/~lynn/2007f.html#11 Is computer history taught now?
http://www.garlic.com/~lynn/2007f.html#12 FBA rant

i have vague recollection that so much money and resources went into
the failed FS project ... that if it had been any other company
... they would have quickly gone under

i've also conjuctured that a lot of 801/risc was possibly also
reaction to FS ... attempting to go to the exact opposite extreme from
FS hardware complexity. lots of past 801/risc related posts
http://www.garlic.com/~lynn/subtopic.html#801

The Perfect Computer - 36 bits?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Perfect Computer - 36 bits?
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 16 Mar 2007 19:06:00 -0600

Peter Flass <Peter_Flass@Yahoo.com> writes:

Ironic.  Someone, possibly you, mantioned that the AS/400 (iSeries)
boxes were a scaled down version of what FS was supposed to be, and
now they're running on top of RISC CPUs.

re:
http://www.garlic.com/~lynn/2007f.html#22 he Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007f.html#26 he Perfect Computer - 36 bits?

the small business computer s/38 ... implemented some number of FS
features (as well as 48bit addressing):
http://en.wikipedia.org/wiki/System/38

there was some discussion that as part of fort knox ... the myriad of
corporate microprocessors would be moved to 801/risc (iliad); low-end
and mid-range 370s, s/38 followon and many others. in thread last fall,
iliad ran into all sorts of schedule problems ... a couple refs:
http://www.garlic.com/~lynn/2006u.html#37 To RISC or not to RISC
http://www.garlic.com/~lynn/2006u.html#38 To RISC or not to RISC

and rochester quickly did a cisc processor for as/400. later rochester
got involved with somerset/powerpc ... and finally did move to a
variety of that risc.
http://en.wikipedia.org/wiki/AS/400

from above:

The AS/400 and its successors survive since their instruction set
(called TIMI for "Technology Independent Machine Interface" by IBM)
allows the operating system and application programs to take advantage
of advances in hardware and software without recompilation. TIMI is a
virtual instruction set; it is not the instruction set of the
underlying CPU. All user-mode programs are stored as TIMI
instructions, which means that it is not possible for them to use the
instruction set of the underlying CPU, thus ensuring hardware
independence. This is conceptually somewhat similar to the virtual
machine architecture of programming environments such as Smalltalk,
Java and .NET. The key difference is that it is embedded so deeply
into the AS/400's design as to make all applications and even the bulk
of its operating systems binary-compatible across different processor
families.

.. snip ..

misc. old email and other posts mentioning iliad and/or fort knox
http://www.garlic.com/~lynn/2006r.html#24 A Day For Surprises (Astounding Itanium Tricks)
http://www.garlic.com/~lynn/2006r.html#26 A Day For Surprises (Astounding Itanium Tricks)
http://www.garlic.com/~lynn/2006t.html#7 32 or even 64 registers for x86-64?
http://www.garlic.com/~lynn/2006u.html#29 To RISC or not to RISC
http://www.garlic.com/~lynn/2006u.html#31 To RISC or not to RISC
http://www.garlic.com/~lynn/2006u.html#32 To RISC or not to RISC
http://www.garlic.com/~lynn/2006u.html#39 P390
http://www.garlic.com/~lynn/2006v.html#6 Reasons for the big paradigm switch
http://www.garlic.com/~lynn/2006v.html#20 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006x.html#0 What's a mainframe?
http://www.garlic.com/~lynn/2006x.html#21 "The Elements of Programming Style"
http://www.garlic.com/~lynn/2006y.html#36 Multiple mappings
http://www.garlic.com/~lynn/2006y.html#40 Multiple mappings
http://www.garlic.com/~lynn/2007b.html#16 V2X2 vs. Shark (SnapShot v. FlashCopy)
http://www.garlic.com/~lynn/2007b.html#44 Why so little parallelism?
http://www.garlic.com/~lynn/2007b.html#57 "The Elements of Programming Style"

other posts in this thread:
http://www.garlic.com/~lynn/2007f.html#21 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007f.html#23 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007f.html#24 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007f.html#25 The Perfect Computer - 36 bits?

The Perfect Computer - 36 bits?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Perfect Computer - 36 bits?
Newsgroups: comp.arch,alt.folklore.computers
Date: Sat, 17 Mar 2007 09:31:17 -0600

jmfbahciv writes:

All of this cancelling stuff...when did this happen?  I don't want
a year; I want a contect of the state of the economy at the time.
(I don't know a better way to write the question).

re:
http://www.garlic.com/~lynn/2007f.html#25 The Perfect Computer - 36bits?

early '76 ... the issue on cancelling vm370 and moving the resources
to getting mvs/xa out the door ... wasn't particularly tied to the
general economy ... it was that the corporation had been so focused on
turning out FS (as a 360/370 replacement) ... that the 360/370 product
pipeline was bare.

wiki article mentioning first VAX (11/780) was introduced on 25OCT77.
http://en.wikipedia.org/wiki/OpenVMS

the sidetrack into FS, (also) helped (360/370) clone processors to
gain foothold.

then when FS was finally cancelled, there was a realization that
several years of "lost time" (in 360/370 product area) had to be made
up.
http://www.garlic.com/~lynn/2007f.html#26 The Perfect Computer - 36bits?

lots of past posts mentioning FS
http://www.garlic.com/~lynn/subtopic.html#futuresys

one of the final nails in the FS coffin was report by the Houston
Science Center ... something about if you took ACP/TPF running on
370/195 and moved it to equivalent FS machine (made out of fastest
hardware then available) ... the thruput would appprox. be that of
running ACP/TPF on 370/145 (i.e. something like 20 to 30 times
slower).

a few other refereces to FS ... which i've previously posted, can be
found here:
http://www.ecole.org/Crisis_and_change_1995_1.htm

from above:

IBM tried to react by launching a major project called the 'Future
System' (FS) in the early 1970's. The idea was to get so far ahead
that the competition would never be able to keep up, and to have such
a high level of integration that it would be impossible for
competitors to follow a compatible niche strategy. However, the
project failed because the objectives were too ambitious for the
available technology.  Many of the ideas that were developed were
nevertheless adapted for later generations. Once IBM had acknowledged
this failure, it launched its 'box strategy', which called for
competitiveness with all the different types of compatible
sub-systems. But this proved to be difficult because of IBM's cost
structure and its R&D spending, and the strategy only resulted in a
partial narrowing of the price gap between IBM and its rivals.

... snip ...

i.e. focusing on high-level of integration as countermeasure to
the clone controllers & device business ... as previously
mentioned, I've been blamed for helping start (project worked on as
undergraduate in the 60s).
http://www.garlic.com/~lynn/subtopic.html#360pcm

The decision to shutdown the burlington mall group and move everybody
to POK had been made, but it appeared that the people weren't going to
be told until just before they had to be moved ... leaving people with
little or no time to make the decision and/or make alternative plans.

Then there was a "leak" ... and a subsequent "witch hunt" attempting
to identify the source of the leak ... this created a very chilling
effect walking down the halls of the old SBC bldg (which had been
emptied and the people moved after the settlement with CDC ... before
the vm370 development group moved in). previous post mentioning the
"witch hunt"
http://www.garlic.com/~lynn/2006o.html#51 The Fate of VM - was: Re: Baby MVS???

part of filling the gap in 360/370 (hardware) product pipeline was the
303x processors. as i've mentioned before, the 303x "channel director"
was repackaged 370/158 engine with the 370/158 integrated channel
microcode (and w/o the 370/158 370 microcode) as independent
processor. Then the 3031 was a repackaged 370/158 (with only the 370
microcode and no integraged channel microcode) coupled with a
(external) "channel director". The 3032 was repackaged 370/168 coupled
with one (or more) channel directors. The 3033 started out as 370/168
wiring diagram mapped to chips that were faster (than the ones used in
the 168). The chips were about 20% faster which would have made the
3033 about 20% faster than 168. The chips also had a lot more
circuits/chip ... which originally were to go unused. Somewhere in the
cycle there was targeted effort to redesign critical pieces of logic
to make better use the denser circuits (doing more "on-chip" in each
chip).  This eventually resulted in the 3033 shipping out at about 50%
faster than 168-3 (instead of only 20% faster)

some earlier posts mentioning 303x channel director
http://www.garlic.com/~lynn/2007b.html#18 How many 36-bit Unix ports in the old days?
http://www.garlic.com/~lynn/2007d.html#21 How many 36-bit Unix ports in the old days?
http://www.garlic.com/~lynn/2007d.html#62 Cycles per ASM instruction
http://www.garlic.com/~lynn/2007e.html#32 I/O in Emulated Mainframes

The Perfect Computer - 36 bits?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Perfect Computer - 36 bits?
Newsgroups: comp.arch,alt.folklore.computers
Date: Sat, 17 Mar 2007 09:57:02 -0600

krw <krw@att.bizzzz> writes:

Predictions of doom and gloom weren't hard to come by.  Akers was
running the company into the ground by, among other things, borrowing
money to pay the dividends. It wasn't too hard to see where that was
going.

Oh, and it's easy making such unfavorable statements when you're
golden.  ;-)

re:
http://www.garlic.com/~lynn/2007f.html#24 The Perfect Computer - 36 bits?

are you referring to me?

maybe datamation had an article mentioning something to that effect
...  however, i never saw any such stuff. it possibly more was a
situation that after demonstrating some immunity to not having career,
promotions and/or raises ... there wasn't a lot left that they could
do (except out and out fire you).

it was more akin to Boyd's quote ... in this post
http://www.garlic.com/~lynn/2007.html#20  MS to world: Stop sending money, we have enough - was Re: Most ... can't run Vista

except I appeared to have been afflicted long before I met Boyd.

another related reference:
http://www.garlic.com/~lynn/2007e.html#48 time spent/day on a computer

The Perfect Computer - 36 bits?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Perfect Computer - 36 bits?
Newsgroups: comp.arch,alt.folklore.computers
Date: Sat, 17 Mar 2007 10:39:34 -0600

re:
http://www.garlic.com/~lynn/2007f.html#29 The Perfect Computer - 36 bits?

oh, and during the hey day of FS ... i wouldn't join in with the rest
of the crowd and the stampede ... indirect reference:
http://www.garlic.com/~lynn/2007f.htmL#14 more shared segment archeology

i had even made unflattering references with comparison to a
long-playing (decade plus) cult film playing down in central sq
... and something about the inmates being in charge of the
institution.

recent posts in this thread mentioning future system project
http://www.garlic.com/~lynn/2007f.html#26 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007f.html#28 The Perfect Computer - 36 bits?

other posts mentioning panning FS as career enhancing move
http://www.garlic.com/~lynn/99.html#100 Why won't the AS/400 die? Or, It's 1999 why do I have to learn how to use
http://www.garlic.com/~lynn/2000f.html#16 [OT] FS - IBM Future System
http://www.garlic.com/~lynn/2001f.html#33 IBM's "VM for the PC" c.1984??
http://www.garlic.com/~lynn/2003b.html#8 Card Columns
http://www.garlic.com/~lynn/2005f.html#1 System/360; Hardwired vs. Microcoded
http://www.garlic.com/~lynn/2005f.html#19 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005j.html#32 IBM Plugs Big Iron to the College Crowd
http://www.garlic.com/~lynn/2005p.html#39 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005s.html#16 Is a Hurricane about to hit IBM ?
http://www.garlic.com/~lynn/2005u.html#5 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2006d.html#15 Hercules 3.04 announcement
http://www.garlic.com/~lynn/2006h.html#52 Need Help defining an AS400 with an IP address to the mainframe
http://www.garlic.com/~lynn/2006i.html#33 virtual memory
http://www.garlic.com/~lynn/2006m.html#44 Musings on a holiday weekend
http://www.garlic.com/~lynn/2006p.html#50 what's the difference between LF(Line Fee) and NL (New line) ?
http://www.garlic.com/~lynn/2007e.html#48 time spent/day on a computer

Is that secure : <form action="https" from a local HTML page ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is that secure : <form action="https" from a local HTML page ?
Newsgroups: comp.security.misc
Date: Sat, 17 Mar 2007 14:25:13 -0600

Volker Birk <bumens@dingens.org> writes:

I don't understand what you're complaining.

Encryption has *TWO* responsibilities here:

- the encrypted transport (via TLS, HTTPS) of the form itself makes you
safe from getting a compromized version, which was modified by a MITM

- the encrypted form POST makes you safe from an attacker getting your
password data by being MITM

Of course, both only will work, if you're checking certificates
assiduously.

the original assumption in SSL was that the person typed in the URL
(knowing the relationship between the webserver and the URL).  The
browser then validated that the webserver contacted was the webserver
for that URL (via checking for a valid domain name certificate and the
domain name in the URL corresponded to the domain name in the
certificate) ... aka the webserver you think you are talking to is
actually the webserver you are talking to is actually the webserver
you think you are talking (you knew the connection between the
webserver and the URL, the browser validated the connection between
the webserver's URL and the webserver's domain name certificate).

this was quickly subverted by most electronic commerce deployments
when they discovered that using SSL cut their thruput/performance
by 80-90 percent ... a couple past post mentioning consulting for
a small client/server startup that wanted to process payments on
their servers ... they had this technology called SSL and it needed
to be applied to real business processes ... it frequently is now
referred to as electronic commerce
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

the default became you typed in (non-https) URL and did all your
shopping online (no MITM countermeasure) and then the webserver
provided a button that you clicked on that got you an SSL connection
to the payment process. Since the individual no longer had any
awareness of the relationship between the URL and the payment website
... and no longer provided the URL ... the subsequent certificate
checking was only validating that the website had a valid
certificate. The scenario about the website, that you thought you were
talking to, is actually the website you are talking to, was broken.  The
only thing now being proven was that the website corresponded to the
website URL that the website claimed to be. lots of past posts about
SSL domain name certificates (many referring to early days of SSL
deployments and original assumptions)
http://www.garlic.com/~lynn/subpubkey.html#sslcert

A bogus MITM-website could be handling all the shopping (since that
part wasn't being checked) ... and then it handed it off to a bogus
"payment" URL (for some website that the attackers were able to obtain
a valid certificate). Again, the whole scenario about are you really
talking to the website that you thot you were talking to ... has been
compromised.

Later email phishing took advantage of this same disconnect by having
people click on a URL in the phishing email. The email claimed that
the URL was for something else than what the URL actually was
(i.e. original SSL assumption based on the person knowing the
connection between the website and the URL was circumvented). The
attackers could have the provided URL be an SSL connection to a
website for which they had a valid certificate (since the browser is
only checking the correspondance between the domain name in the
provided URL and the domain name in the certificate).

Bascially SSL was designed as MITM countermeasure to ip-address
hijacking and/or stuff like DNS cache poisoning (attacking the
correspondance/mapping between a domain name and an ip-address).  To
actually have SSL serve as a generalized MITM countermeasure required
that the user know the correspondance between the website/URL, that
they thot they were talking to, and the website/URL, that they actually were
actually talking to. When that was lost ... lots of attacks were
possible in the infrastructure. An MITM-attack could even provide a
valid SSL URL (via email) for connection to their website ... which
then transparently established a second SSL connection to the "real"
website.

The problem with phishing using bogus impersonation websites
(regardless of whether SSL was used or not) become prevalent enuf to
justify some institutions looking at other countermeasures to website
impersonation (i.e. additional website identification mechanisms so
the user had additional confidence that the website, that they thot they
were talking to, was actually the website they were talking
to). However, these mechanisms typically haven't had any
countermeasures to MITM-attacks ... aka phishing points
to a MITM, bogus website that transparently creates a connection to
the "real website". some posts in recent threads touching on the
subject:
http://www.garlic.com/~lynn/aadsm26.htm#25 EV - what was the reason, again?
http://www.garlic.com/~lynn/aadsm26.htm#26 man in the middle, SSL
http://www.garlic.com/~lynn/aadsm26.htm#27 man in the middle, SSL
http://www.garlic.com/~lynn/aadsm26.htm#28 man in the middle, SSL
http://www.garlic.com/~lynn/aadsm26.htm#30 man in the middle, SSL
http://www.garlic.com/~lynn/aadsm26.htm#31 man in the middle, SSL
http://www.garlic.com/~lynn/aadsm26.htm#40 PKI: The terrorists's secret weapon
http://www.garlic.com/~lynn/aadsm26.htm#41 PKI: The terrorists's secret weapon (part II)

lots of other posts mentioning MITM attacks
http://www.garlic.com/~lynn/subintegrity.html#mitm

so after consulting for this small client/server startup (that had
this technology they called SSL) on what was to become what is now
called electronic commerce, we spent some time in the x9a10 financial
standard working group. In the mid-90s, the x9a10 financial standard
working group had been given the requirement to preserve the
integrity of the financial infrastructure for all retail
transactions. the result was the x9.59 financial standard.
http://www.garlic.com/~lynn/x959.html#x959

x9.59 transactions now have end-to-end authentication armoring ... as
countermeasure to attackers using any information (from previous
transaction for replay attacks) for generating new, fraudulent
transactions. This eliminates the risk of evesdropping/replay attacks
... and therefor there is no pressing need to actually encrypt the
transaction and/or hiding the information during transmission (which
is the current major, wide-spread electronic commerce use for SSL in
the world today). The x9.59 standard also eliminates the risk in the
majority of the data breaches and security breaches where the
attackers are able to turn around and use the information to generate
fraudulent transactions (it doesn't eliminate such data breaches and
security breaches, it just makes most of the information useless to
the attackers ... eliminating majority of the financial motivation for
the bad guys for performing the breaches). some topic drift about
security proportional to risk around many of the breaches
http://www.garlic.com/~lynn/2001h.html#61

this somewhat involves the security acronym "PAIN"

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

... in effect, X9.59 is using end-to-end au