List of Archived Posts

2001 Newsgroup Postings (09/02 - 09/11)

E-commerce security????

Off-topic everywhere [was: Re: thee and thou

E-commerce security????

YKYGOW...

I hate Compaq

E-commerce security????

Losing our culture.

No Trusted Viewer possible?

PKI (Public Key Infrastructure)

E-commerce security????

PKI (Public Key Infrastructure)

PKI (Public Key Infrastructure)

OT - Internet Explorer V6.0

Parity - why even or odd (was Re: Load Locked (was: IA64 running out of steam))

Parity - why even or odd (was Re: Load Locked (was: IA64 running out of steam))

Parity - why even or odd (was Re: Load Locked (was: IA64 running out of steam))

OT - Internet Explorer V6.0

I hate Compaq

I hate Compaq

I hate Compaq

OT - Internet Explorer V6.0

Parity - why even or odd (was Re: Load Locked

Title Inflation

OT - Internet Explorer V6.0

Parity - why even or odd (was Re: Load Locked

Parity - why even or odd (was Re: Load Locked

Help needed on conversion from VM to OS390

Pentium 4 SMT "Hyperthreading"

Title Inflation

Title Inflation

Title Inflation

Title Inflation

Whom Do Programmers Admire Now???

Big black helicopters

Title Inflation

Military Interest in Supercomputer AI

Proper ISA lifespan?

Proper ISA lifespan?

Big black helicopters

Big black helicopters

Big black helicopters

Big black helicopters

Big black helicopters

Disaster Stories Needed

Does "Strong Security" Mean Anything?

OT - Internet Explorer V6.0

Big black helicopters

OT - Internet Explorer V6.0

Pentium 4 SMT "Hyperthreading"

Are client certificates really secure?

Title Inflation

Big black helicopters

Are client certificates really secure?

Are client certificates really secure?

Does "Strong Security" Mean Anything?

E-commerce security????

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: E-commerce security????
Newsgroups: comp.security,comp.security.pgp,alt.computer.security,alt.security,comp.security.unix,comp.security.linux
Date: Sun, 02 Sep 2001 22:44:52 GMT

Norm writes:

Why should the vendor keep the credit card information Forever?
If you do not keep it online forever, then the risk is reduced
significantly. You still have employee risk, but that will
always be a problem. Any time you "trust" someone you accept the
risk of getting burned.

Trust - giving someone enough information to damage/harm you.

If the vendor merely deletes the data after the transaction is
completed the outside and inside cannot get to it but for a
limited time frame.

first off the business rules (aka the credit card associations have
rules that merchants must follow) have things about stuff like
charge-backs and the merchant having the records associated with same
(i.e. a customer may be able to dispute for 90-180 days ... and the
material provided to the merchant may be as little as account# and
date ... so merchant must keep records at least as long as there is
possibility of chargeback &/or other dispute).

the initial translation of credit card (aka electronic commerce) to
internet was relatively straight-forward since there was already
provisions for non-face-to-face MOTO (mail-order/telephone-order)
transactions ... ref to this effort:
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

however, because account number is effectively shared-secret, there
are all kinds of exploits ... not just limited to the internet. As a
result, the financial standards body developed the X9.59 standard for
ALL account-based payments (not just limited to internet but can be
done at point-of-sale also and other types of environments).  refs to
debit implementation
http://www.garlic.com/~lynn/nacharfi.htm
http://internetcouncil.nacha.org/Projects/ISAP_Results/isap_results.htm
http://web.archive.org/web/20020204041928/http://internetcouncil.nacha.org/Projects/ISAP_Results/isap_results.htm

refs: to X9.59 mapping to iso8583 (aka international message standard
used by both credit and debit networks):
http://www.garlic.com/~lynn/8583flow.htm

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

Off-topic everywhere [was: Re: thee and thou

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Off-topic everywhere [was: Re: thee and thou
Newsgroups: alt.folklore.computers,sci.lang,alt.usage.english
Date: Mon, 03 Sep 2001 00:59:24 GMT

Ric Werme writes:

While I agree with pretty much all the comments about card catalogs in
libraries, note that in the future (i.e. now) people will search for
information on the WWW.  I often try to find something on Google and
wind up distracted for half an hour by various other things Google
comes up with.  Conversely, most of my WWW site is devoted to abuse of
families by Child "Protective" Service agencies.  I have a Web counter
that logs the referring URL, which often includes search engine search
strings.  A lot of people, looking for something else, have either had
their eyes opened or think my wife and I are crackpots.

the (online) national library of medicine card catelogue had reached
state of many current web search engines by the late '70s. It tended
to be extremely bi-model on searches. For boolean search with 6-8
terms, it tended to switch from hundred of thousands of "hits" to zero
"hits" with only minor refinements to the search.

In the early '80s an apple application called grateful med saw
wide-spread deployment. It saved searches and interacted with the
(online) query just by getting counts of hits. People would use
grateful med to try searches that resulted in reasonable number of
its.

The holy grail has been to come up with methodology to get hits in the
tens or hundres ... rather than the bi-model tendency of switching
from hundreds of thousands to zero hits ... with only minor changes to
the search.

Part of the approach is attempting to migrate more intelligence of the
indexing scheme out into the front-ends ... allowing more awareness of
how medical knowledge is structured. Part of that is referred to as
UMLS or unified medical language system.

When we worked in the area a couple years ago ... there were something
like 40,000 medical librarians world-wide trained in searching NLM.  A
typical scenerio would be a doctor spends 3-4 hrs with the medical
librarian who then goes off for a couple days doing queries and then
gets back to the doctor with the most likely responses.

NLM now has web interface ... but the mechanics of the searching still
is pretty much the same. I don't know if it has changed recently
... but a couple years ago, the index was still a large BDAM database
designed in the late '60s (and despite large amounts of efforts
investigating newer technologies thru-out the 80s & 90s ... there was
still nothing that could beat it).

some random refs:
http://www.garlic.com/~lynn/94.html#26 Misc. more on bidirectional links
http://www.garlic.com/~lynn/2001c.html#67 What ever happened to WAIS?
http://www.garlic.com/~lynn/2001i.html#27 History of Microsoft Word (and wordprocessing in general)

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

E-commerce security????

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: E-commerce security????
Newsgroups: comp.security,comp.security.pgp,alt.computer.security,alt.security,comp.security.unix,comp.security.linux
Date: Mon, 03 Sep 2001 02:13:39 GMT

Norm writes:

Generally you have 60 days to dispute a charge from the time you
get a statement. So that would imply at least 90 days for the
business to keep transaction data. Does that data need to be on
a server connected to the Internet. No. It could be archived
to an offline server that is a peice of junk but has lots of
storage capacity. Only a few employees, those that handle disputes
need access. In the CD Universe case a Russian attacker stole
300,000 credit cards. Some of the people had not had a transaction
in 2-4 years. There really is no need to keep it forever is
my point. This seems to be the mindset: never archive anything
and hold on to all data on users as long as possible. This makes
risk for the user increase. You could burn it to optical disks
and have it stored offsite at a secure facility. Anyway, if it
doesn't exist it is impossible to steal.

there are all sorts of things that can be done ... but have
shared-secret account numbers is the fundamental problem ... x9.59
eliminates the account numbers as exploit/fraud objectives
... i.e. the account number no longer can be used in non-authenticated
transactions.

as in the discussion about security proportional to the risk ... the
basic problem is that the degree of risk of account numbers in
unauthenticated transactions bears little or no relationship to the
risk/benefit scenerio at the merchant business i.e. the account number
risk is significantly larger than any amount of merchant business at
risk, and therefor there is no correlation between the amount of
business & revenue that a merchant is doing and the amount of risk &
security associated with the existing account numbers.

There are lots of security things that can be done proportional to the
amount of risk represented by the account number file .... however, in
principle, the amount of business a merchant is doing should be
proportional to the risk the merchant is dealing with ... and therefor
is able to fund/underwrite risk proportional to their
business. However, the account number file tends to far exceed the
risk in the merchant business and bears little or no correlation with
that business

i.e.
http://www.garlic.com/~lynn/2001h.html#61 security proportional to risk

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

YKYGOW...

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: YKYGOW...
Newsgroups: alt.folklore.computers
Date: Mon, 03 Sep 2001 15:47:27 GMT

bill@wjv.com (Bill Vermillion) writes:

But it didn't rotate very fast.  And old engineer told me that on
machine they had years ago that the data was on head track four
times to make up for rotational latency.  This was in a process
control environment.

the ibm count-key-data (CKD) disks tended to have same number of bytes
on each track ... but you can physically format the records on each
track. for random access arm efficiency there tended to be some games.

An example is original 3330. 19 tracks per cylinder (i.e. arm
position, 19 heads, one head per track, actually a 20th head&track for
position sensing). You could format three 4k records per track plus a
little left over.

The standard I/O sequence involved channel command words or CCWs. A
typical record access CCW program (for 4k pages) might look like:

Seek (cylinder)
set sector
search-id equal
tic -8
read/write 4k
nop

if you formated each track the same ... you knew the approximate
rotational angle of each record ahead of time and could specify it in
the "set sector" command. The "search-id equal" was a CKD command that
allowed some pretty fancy outboard record searching operations ... but
the trivial case is you knew the record number and just wanted it.
The "tic -8" was a branch if the search was not succesful. Then the
read/write command.

It was also possible to "chain" sequences together for records on the
same track or cylinder ... basically changing the "nop" to a
tic/branch command to the start of the next CCW package (i.e. seek
command).

The original design had the CCW sequences (and the CCW arguments, like
the parameters for the seek, set sector and search-id commands) all
stored in main processor memory and the "channel" processor
sequentially retrieving each CCW one at a time and interpreting it.
Note that all the time the "channel" processor was retrieving and
interpreting the channel commands (and their parameters), disks were
rortating. If the channel was slow enuf, it was possible (when doing
sequential record processing) that the next sequential record had
rotated passed the disk head while the channel was still processing
the CCW command sequences. To compensate for this, disks were
sometimes formated with short, dummy "filler" records between the
normal data records (and assigned IDs that wouldn't be normally used
by search-id commands).

In the 3330, 4k page record case, 50-byte dummy filler records were
standard. This allowed the channel extra latency while processing
normal CCW sequences to get to the search-id for the next sequential
record before it had rotated passed the head; at least for sequential
records on the same track. However, for "sequential" records on the
same cylinder, but different track, there was also extra channel &
disk controller latency that resulted in the next sequential record to
rotate past the head (even with 50-byte dummy filler records).

With 4k-byte data records, the maximum sized dummy filler records was
110-byte before exhausting the maximum track length capacity on 3330s.
Things now got processor and controller sensitive. Some processor
channels and some PCM (plug compatible manufactur) 3330s were fast
enuf that they could process the switch head operation before the next
sequential data record had rotated past the head (using 110-byte dummy
filler records); and some combinations had too much processing latency
and would result in a "rotational miss" and have to go around an extra
time.

In general 4341 & 370/168 channels were fast enough that they could
sequentially access data records on adjacent tracks. 370/158s channels
weren't normally fast enuf ... although some PCM 3330 controllers in
combination with 158 channels could process the next (rotational)
sequential data record on adjacent tracks (same cylinder, different
track).

When the 303x machines were introduced, all of them exhibited the 3330
rotational access characteristic of the 370/158. The 370/158 had
"integrated" channels where the 158 native (horizontal microcoded)
processor engine was shared between emulating 370 instructions and
emulation CCW I/O instructions. The 4341 had integrated channels, but
were sufficient fast enuf implementation that it wasn't a problem.
The 168 had dedicated, outboard hardware "channels".

3330 filler record discussion
http://www.garlic.com/~lynn/2000d.html#7 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#12 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#44 Charging for time-share CPU time
http://www.garlic.com/~lynn/2001b.html#69 Z/90, S/390, 370/ESA (slightly off topic)

Something similar was done on the 2305 fixed-head disk that was
normally used as a dedicated paging device and was formated with dummy
filler/spacer records. The 2305 also had eight "logical" addresses. It
was possible to schedule (queued) requests on all eight "logical"
addresses and have the hardware manage which requests to service. The
normal, ibm channel sequence was that after the previous CCW operation
had finished, there was a series of events involving hardware
interrupts, software processing, and other latency introducing events
before the next queued request was (re-)driven on the I/O interface
(all the time the disks were rotating).

misc. 2305 discussion
http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door
http://www.garlic.com/~lynn/95.html#8 3330 Disk Drives
http://www.garlic.com/~lynn/99.html#6 3330 Disk Drives
http://www.garlic.com/~lynn/99.html#104 Fixed Head Drive (Was: Re:Power distribution (Was: Re: A primeval C compiler)
http://www.garlic.com/~lynn/2000d.html#7 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#52 IBM 650 (was: Re: IBM--old computer manuals)
http://www.garlic.com/~lynn/2000d.html#53 IBM 650 (was: Re: IBM--old computer manuals)
http://www.garlic.com/~lynn/2000g.html#42 4M pages are a bad idea (was Re: AMD 64bit Hammer CPU and VM)
http://www.garlic.com/~lynn/2001c.html#17 database (or b-tree) page sizes

redrive latency discussion
http://www.garlic.com/~lynn/94.html#24 CP spooling & programming technology
http://www.garlic.com/~lynn/95.html#12 slot chaining
http://www.garlic.com/~lynn/96.html#19 IBM 4381 (finger-check)
http://www.garlic.com/~lynn/99.html#183 Clustering systems
http://www.garlic.com/~lynn/2000c.html#75 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000g.html#45 4M pages are a bad idea (was Re: AMD 64bit Hammer CPU and VM)
http://www.garlic.com/~lynn/2001b.html#69 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001h.html#28 checking some myths.

For the 303x line of machines, they took the processing engine from
the 158 and created a "channel director" ... i.e. an outboard
dedicated box that only performed CCW channel operations. The 303x
channel directors (on all processor models) all shared the same
channel director implementation (a somewhat repackaged 370/158
engine).

The 3031 was a revamped 370/158 where there was a dedicated processing
engine for executing 370 instructions and the same processing engine
outboard in a "channel director" dedicated for doing I/O. The 3031 had
faster 370 processing execution (than the 370/158) ... but the channel
director exhibited the same processing latency as the 370/158.

misc. 158/3031 processor comparison
http://www.garlic.com/~lynn/2000d.html#0 Is a VAX a mainframe?

The 3032 was essential a 370/168 that was configured to use the 303x
outboard channel directors rather than the 370/168 outboard channel
boxes.

The 3033 started out being a 370/168 wiring diagram remapped to faster
chip technology (as well as using 303x channel directors) ... but was
enhanced along the way to improve its performance.

misc. 303x discussions
http://www.garlic.com/~lynn/93.html#14 S/360 addressing
http://www.garlic.com/~lynn/94.html#7 IBM 7090 (360s, 370s, apl, etc)
http://www.garlic.com/~lynn/95.html#3 What is an IBM 137/148 ???
http://www.garlic.com/~lynn/97.html#20 Why Mainframes?
http://www.garlic.com/~lynn/98.html#50 Edsger Dijkstra: the blackest week of his professional life
http://www.garlic.com/~lynn/99.html#7 IBM S/360
http://www.garlic.com/~lynn/99.html#74 Read if over 40 and have Mainframe background
http://www.garlic.com/~lynn/99.html#75 Read if over 40 and have Mainframe background
http://www.garlic.com/~lynn/99.html#103 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
http://www.garlic.com/~lynn/99.html#110 OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
http://www.garlic.com/~lynn/99.html#112 OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
http://www.garlic.com/~lynn/99.html#187 Merced Processor Support at it again . . .
http://www.garlic.com/~lynn/99.html#188 Merced Processor Support at it again . . .
http://www.garlic.com/~lynn/99.html#190 Merced Processor Support at it again . . .
http://www.garlic.com/~lynn/2000.html#78 Mainframe operating systems
http://www.garlic.com/~lynn/2000b.html#37 How to learn assembler language for OS/390 ?
http://www.garlic.com/~lynn/2000b.html#65 oddly portable machines
http://www.garlic.com/~lynn/2000c.html#35 What level of computer is needed for a computer to Love?
http://www.garlic.com/~lynn/2000c.html#44 WHAT IS A MAINFRAME???
http://www.garlic.com/~lynn/2000c.html#69 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#75 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#83 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000d.html#0 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000d.html#7 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#12 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#21 S/360 development burnout?
http://www.garlic.com/~lynn/2000d.html#61 "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)
http://www.garlic.com/~lynn/2000d.html#82 "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)
http://www.garlic.com/~lynn/2000e.html#57 Why not an IBM zSeries workstation?
http://www.garlic.com/~lynn/2000e.html#58 Why not an IBM zSeries workstation?
http://www.garlic.com/~lynn/2000g.html#11 360/370 instruction cycle time
http://www.garlic.com/~lynn/2000g.html#28 Could CDR-coding be on the way back?
http://www.garlic.com/~lynn/2000g.html#29 Could CDR-coding be on the way back?
http://www.garlic.com/~lynn/2001.html#63 Are the L1 and L2 caches flushed on a page fault ?
http://www.garlic.com/~lynn/2001b.html#37 John Mashey's greatest hits
http://www.garlic.com/~lynn/2001b.html#39 John Mashey's greatest hits
http://www.garlic.com/~lynn/2001b.html#69 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001b.html#83 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001c.html#1 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001c.html#3 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001d.html#54 VM & VSE news
http://www.garlic.com/~lynn/2001d.html#55 VM & VSE news
http://www.garlic.com/~lynn/2001e.html#9 MIP rating on old S/370s
http://www.garlic.com/~lynn/2001i.html#13 GETMAIN R/RU (was: An IEABRC Adventure)

getting blamed for originating the 360 plug compatable manufactur
(PCM) business:
http://www.garlic.com/~lynn/subtopic.html#360pcm

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

I hate Compaq

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: I hate Compaq
Newsgroups: comp.arch,comp.os.vms,alt.folklore.computers
Date: Mon, 03 Sep 2001 16:11:47 GMT

Kilgallen@SpamCop.net (Larry Kilgallen) writes:

Note that the DEC SVS A1 virtual monitor system (that never made it to
market) was written in Pascal in order to allow the security proofs.
The software running under that was ordinary VMS (the only OS they
tried).  To me this proves that writing lower level code in a higher
level language is quite viable.

(For those who don't remember, the project was cancelled when DEC
marketing discovered that the market for A1 systems was not what
they had thought it was going to be.)

I did something different. All of the CP virtual machine kernel (both
CP/67, VM/370, etc) was written in assembler. Some of the services
were questionably actually needed in the low-level kernel
... especially for security reasons like much of unit record
simulation and the corresponding spooling infrastructure (aka
effectively standard CP kernel already provided virtual monitor
infrastructure that made a number of security-related paradigms
standard).

I rewrote the spooling infrastructure in Pascal running in a virtual
machine address space with upcalls out of the kernel into the spool
machine to handle unit record/spool operations on behalf of other
virtual machines.

The original purpose (of the effort) was to improve the performance of
the spooling infrastructure by at least an order of magnitude for the
HSDT (high-speed data transport) project i.e. turns out that local
node network support depended extensively on the spooling
infrastructure (which had become the major thruput bottleneck for
high-speed network operations). The objective was an order of
magnitude performance improvement ... even taking into account that
assembler code was being replaced with Pascal and the code was
migrated out of the kernel into virtual address space (both
introducing numerous kinds of additional overhead).

Basically, a number of things were done (none of them that couldn't
really have been done with kernel assembler code) 1) semantics for
asynchronous spool I/O interface was implementated, 2) numerous
sequential search operations were replaced with "tree-based"
operations, 3) spool records were enhanced to signficantly improve
availability and recoverability, 4) kernel was insulated from numerous
kinds of spool related errors that previously would have resulted in
system failure.

this was deployed on parts of the internal network (the internal
network was larger than the whole internet/arpanet for much of its
lifetime).

hsdt, networking
http://www.garlic.com/~lynn/subtopic.html#networking
http://www.garlic.com/~lynn/internet.htm

misc hsdt & spool file rewrite discussion
http://www.garlic.com/~lynn/94.html#22 CP spooling & programming technology
http://www.garlic.com/~lynn/94.html#23 CP spooling & programming technology
http://www.garlic.com/~lynn/94.html#25 CP spooling & programming technology
http://www.garlic.com/~lynn/94.html#31 High Speed Data Transport (HSDT)
http://www.garlic.com/~lynn/94.html#33a High Speed Data Transport (HSDT)
http://www.garlic.com/~lynn/94.html#33b High Speed Data Transport (HSDT)
http://www.garlic.com/~lynn/98.html#49 Edsger Dijkstra: the blackest week of his professional life
http://www.garlic.com/~lynn/98.html#50 Edsger Dijkstra: the blackest week of his professional life
http://www.garlic.com/~lynn/99.html#34 why is there an "@" key?
http://www.garlic.com/~lynn/99.html#115 What is the use of OSI Reference Model?
http://www.garlic.com/~lynn/99.html#201 Middleware - where did that come from?
http://www.garlic.com/~lynn/2000b.html#43 Migrating pages from a paging device (was Re: removal of paging device)
http://www.garlic.com/~lynn/2000b.html#69 oddly portable machines
http://www.garlic.com/~lynn/2000c.html#68 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink)
http://www.garlic.com/~lynn/2000f.html#31 OT?
http://www.garlic.com/~lynn/2001.html#72 California DMV
http://www.garlic.com/~lynn/2001c.html#66 KI-10 vs. IBM at Rutgers
http://www.garlic.com/~lynn/2001e.html#64 Design (Was Re: Server found behind drywall)
http://www.garlic.com/~lynn/2001f.html#11 Climate, US, Japan & supers query
http://www.garlic.com/~lynn/2001f.html#49 any 70's era supercomputers that ran as slow as today's supercompu
http://www.garlic.com/~lynn/2001g.html#29 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001h.html#13 VM: checking some myths.
http://www.garlic.com/~lynn/2001h.html#29 checking some myths.
http://www.garlic.com/~lynn/2001h.html#44 Wired News :The Grid: The Next-Gen Internet?
http://www.garlic.com/~lynn/2001i.html#31 3745 and SNI
http://www.garlic.com/~lynn/2001i.html#41 Withdrawal Announcement 901-218 - No More 'small machines'
http://www.garlic.com/~lynn/2001i.html#52 misc loosely-coupled, sysplex, cluster, supercomputer, & electronic commerce

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

E-commerce security????

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: E-commerce security????
Newsgroups: comp.security,comp.security.pgp,alt.computer.security,alt.security,comp.security.unix,comp.security.linux
Date: Mon, 03 Sep 2001 23:15:10 GMT

Norm writes:

I think you are missing my point. The credit card number should not be
kept forever. This is why I periodically cancel all credit cards.
Because I don't want to have to worry about the security of all the
people I do business with. If they delete the data and/or archive it
off-line, crackers cannot get to because it doesn't exist. The only
reason they keep these large lists is marketing and impulse buying
reasons. It really serves me little purpose to have buy.com store my
address 10 years from now. If I am constantly doing business with
them then great. But  a lot of the time I buy once, because some
site has a much lower price, and never again. Why keep that data
forever? No data should be kept forever.

when we were working on the credit card transaction stuff (now frequently referred
to as electronic commerce):
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

we tried to get various security measures specified:

• physical security for the data processing room, motion detecters, guards, etc
• multiple layers of firewalls & packet filtering routers
• actual financial transactions performed on backroom dataprocessing
  equipment away from the actual web server
• fbi background checks for all employees
• security audits
• minimum business & security certification levels.

... didn't happen, oh well.

so faced with the prospect that there might someday be 20,000,000 or
so e-commerce servers world-wide and all of them had to be implemented
absolutely perfectly, none of them ever having the slightest security
lapses with either technology or people ... the next choice seemed to
be to eliminate the major source of risk ... i.e. account numbers as a
risk.
http://www.garlic.com/~lynn/2001h.html#61 security proportional to risk

i.e. with security supposedly proportional to risk ... if it wasn't
going to be easy to get ubiquitous security actually proportional to
the risk (with real live security audit and certification for all such
sites) ... then the next choice would be to change the associated risk
...  aka the x9.59 solution ... which was done in such a way that it
is applicable to ALL account-based transactions (not just credit, and
not just internet).
http://www.garlic.com/~lynn/

the issue isn't just that even simple things could be done to improve
the situation ... the consumer also has no way of telling what sites
have implemented what levels of security (even if some sites were to
implement even partial measures to improve the situation ... the
customer has no way of determining who has implemented what).

some discussion regarding tieing information security implementation
into business risk management and associated business rating
(i.e. analogous to credit risk rating)
http://www.garlic.com/~lynn/aepay3.htm#riskm
http://www.garlic.com/~lynn/aepay3.htm#riskaads
http://www.garlic.com/~lynn/aepay3.htm#x959risk1
http://www.garlic.com/~lynn/aepay3.htm#x959risk2
http://www.garlic.com/~lynn/aepay3.htm#x959risk3
http://www.garlic.com/~lynn/aepay3.htm#x959risk4

longer list of risk & security related discussions
http://www.garlic.com/~lynn/subtopic.html#fraud

general x9.59 financial standard discussions
http://www.garlic.com/~lynn/subtopic.html#privacy

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

Losing our culture.

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Losing our culture.
Newsgroups: alt.folklore.computers
Date: Mon, 03 Sep 2001 23:28:56 GMT

"John Homes" writes:

Relying on GO TO instead of properly nested code structures encourages
sloppy design, and that is the problem with GO TOs. Properly designed code
can be implemented with GO TO (as someone in this tread has pointed out,
compilers do just that generating the executable) and the result is still
good code.

in the early '70s, I wrote a large application (in PL/1) that would
read assembler code and perform a lot of analysis ... register useage,
process flow, use-before-initialized graphs for registers, bunch of
other stuff. I also generated a "higher-level" language level
representation of the assembler code that included all sorts of
non-GOTO process flows (since the low-level assembler just used
various kinds of branching instructions). Even with various kinds of
break and trap conditions ... there were still a number of assembler
programs that had sections that were quite elegent in the original and
were really terribly complex in nested & non-GOTO representation.

Part of the GOTO issue is in some sort of failure/fault situation
being able to backtrack the program. Nested conditionals tended to
make the process flow more obvious based on the associated
conditions/variables i.e. process flow directly dependent on some
other explicit language construct ... which isn't present in a simple
branch/GOTO. The trick then was placing something in the process flow
that made it obvious what paths might have been taken when attempting
to backtrack from a failure/fault (even when GOTOs and/or other
unconditional branch operations were involved).

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

No Trusted Viewer possible?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: No Trusted Viewer possible?
Newsgroups: comp.security.misc,comp.security.pgp.discuss
Date: Tue, 04 Sep 2001 02:23:07 GMT

skeptic <Use-Author-Supplied-Address-Header@[127.1]> writes:

Digital signatures are more secure than paper signatures.

while, once created securely ... digital signatures may be more
difficult to counterfeit ... there is less obvious correlation between
a person's intention and some computer mathematical calculations
... as compared to a paper signature ... where if you watch a person
writing their signature, it is usually pretty obvious they intended to
write it.  it is much harder to show that the computer mathematical
calculations (resulting in a digital signature) is being done exactly
with the understanding and under the direct control of a specific
human and can only be done at the specific direction of that human
(and is otherwise totally impossible for the computer to perform those
mathematical calculations).

the use of digital signatures as part of message authentication is
much less problematical ... i.e. assuming that it was correctly
originated, then there is little likelyhood that any alteration goes
undetected.

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

PKI (Public Key Infrastructure)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PKI (Public Key Infrastructure)
Newsgroups: sci.crypt
Date: Tue, 04 Sep 2001 16:30:52 GMT

"Novice" writes:

client A of the PKI system wants to send an encrypted message to client B.
A makes a request of his CA (Certificate Authority or more appropriately a
Certification Authority) for the public key of user B - this request could
potentially be digitally signed by A to ensure that the request cannot be
read by another user.  The CA then replies with a message (digital
certificate) that is digitally signed by the CA and contains the public key
of user B.  A then decrypts/deencrypts the message from the CA in order to
obtain the public key of User B.  A then encrypts his message using B's
public key.  He then sends that message to B.  B is then able to
decrypt/deencrypt the message using his private key.

PKIs were designed for offline operations (model is the "offline" email
world from the early '80s; people called up, downloaded email, & then
hung up; then digital signatures on email had to be validated while
offline).

A, B, ... all have a root-key loaded somewhere. "A" requests a
certificate for their associated public-key from a CA (that is signed
by the root-key ... or have secondary certificate eventually signed by
some root-key). "B" requests a corresponding certificate for their
associated public-key.

"A" generates a message and digital signs the message. "A" then
creates a package of the message, the digital signature and "A's"
certificate and sends it to "B".

"B" receives the package, validates "A's" certificate with the
root-key (so that it can trust "A's" public key), then it validates
the message digital signature using public key from "A's" digital
certificate.

here is sample of root-keys/certificaets preloaded into browsers:
http://www.garlic.com/~lynn/aepay4.htm#comcert14
http://www.garlic.com/~lynn/aepay4.htm#comcert16

note that for the majority of the deployed infrastructures ... they
aren't full PKIs ... they are subset certificate manufacturing
... full PKIs imply that the certificates are managed and
administrated ... aka infrastructure in place so that all possible
clients in the world can be notified with regard to revoked &/or
compromised certificates.

more discussion on SSL=related certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

discussion of client/server digital signature authentication w/o certificates
http://www.garlic.com/~lynn/subtopic.html#radius

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

E-commerce security????

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: E-commerce security????
Newsgroups: comp.security,comp.security.pgp,alt.computer.security,alt.security,comp.security.unix,comp.security.linux
Date: Tue, 04 Sep 2001 17:19:12 GMT

Anne & Lynn Wheeler writes:

the initial translation of credit card (aka electronic commerce) to
internet was relatively straight-forward since there was already
provisions for non-face-to-face MOTO (mail-order/telephone-order)
transactions ... ref to this effort:

the other part of MOTO that we translated to e-commerce was AVS
... address verification transaction; a simple form of authentication,
basically matching name & address with mailing name & address on file;
aka MOTO-transactions want name&address of record for AVS
authentication.

this further (unnecessarily) propagates (more) privacy information.

X9.59 substitutes AVS with digital signature authentication which
eliminates that bit of additional privacy information (in addtion to
eliminating account number as a shared-secret exploit).

Hardgood shipments may still require some name&address (although
softgoods & various other online services wouldn't) and there are a
half-dozen or so hardgood shipment strategies that also eliminates
merchant needing to know name&address for shipping.

now, there is an issue of point-of-sale ... and upgrading the
magstripe cards with the addition of chips and deploying the
readers. some of that is already going on ... but note that the same
x9.59 transaction is defined for debit, credit, internet,
point-of-sale, etc. Part of the driving force for magstripe card
upgrade is that technology advances have been it extremely inexpensive
to counterfeit large numbers of magstripe cards. The addition of a
chip, significantly raises the bar.

misc. refs:
http://www.garlic.com/~lynn/subtopic.html#privacy
http://www.garlic.com/~lynn/subtopic.html#fraud

random specifics
http://www.garlic.com/~lynn/ansiepay.htm#cardsteal Stealing cards easy as Web browsing
http://www.garlic.com/~lynn/ansiepay.htm#breach Security breach raises questions about Internet shopping
http://www.garlic.com/~lynn/ansiepay.htm#theory Security breach raises questions about Internet shopping
http://www.garlic.com/~lynn/aepay6.htm#fraud Online Card Fraud Thirty Times That Offline
http://www.garlic.com/~lynn/aepay6.htm#ccfraud latest credit scam puts plastic in peril ... is your credit card being cloned?
http://www.garlic.com/~lynn/2001f.html#31 Remove the name from credit cards!
http://www.garlic.com/~lynn/2001f.html#35 Security Concerns in the Financial Services Industry
http://www.garlic.com/~lynn/2001f.html#40 Remove the name from credit cards!
http://www.garlic.com/~lynn/aepay6.htm#ccfraud2 "out of control credit card fraud"
http://www.garlic.com/~lynn/aepay6.htm#ccfraud3 "out of control credit card fraud"

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

PKI (Public Key Infrastructure)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PKI (Public Key Infrastructure)
Newsgroups: sci.crypt
Date: Tue, 04 Sep 2001 19:19:43 GMT

"Novice" writes:

Ahh but the scenario you are describing is digitally signing a message using
public key encryption.  That is yet another perfectly valid scenario in a
PKI system, but I believe mine is also valid.  What if I didn't want to
bother digitally signing my message.  In that case, I could just encrypt the
message with the public key of the recipient of the message, send the
message and then the recipient could decrypt/deencypt the message with their
private key, correct?

it can either be digitally signing or totally encrypting the message.

if encrypting the message, the sender obtains the recipient's public
key from the recipient's digital certificate which the recipient had
previously transmitted to the sender in a digital signed message
(i.e. the previous description).

using the recipeint's public key (from the recipient's digital
certificate, from a previously digitally signed message), the sender
typically will encrypt a random secret key and then use the random
secret key to actually encrypt the message. The sender will package up
the publickey-encrypted random-secretkey and the secretkey-encrypted
message and transmit it to the recipient. Typically, the sender may
also digital sign the message (before encrypting) .. as prior previous
posting.

Above is similar to the most common deployed existing certificate
manufacturing infrastructure (aka PKI-subset) ... SSL domain name
server operation.

However, there are lots of other ways of deploying public key
operations ... PGP being one such example.

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

PKI (Public Key Infrastructure)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PKI (Public Key Infrastructure)
Newsgroups: sci.crypt
Date: Tue, 04 Sep 2001 22:01:45 GMT

"Novice" writes:

Don't all users obtain the public key of another user through the CA?  I
mean what you are describing is that user A would obtain the public key of
user B from user B.

Also I believe the operation of encrypting a symmetric key using an
asymmetric key was originally conceptualized by Diffie Hellman, correct?

PGP doesn't require a CA.

CA stands for "certification authority" ... they typically generate a
certificate that represents some attribute (like identity) that they
certify as having some relationship to a public key.

With PGP ... I can append my public key to my email and the recipient
possibly uses some method to verify that the email with the public key
actually came from me.

This is in fact, effectively what a CA (certification authority) is
doing when it obtains a person's public key from the person (before
any certificate is manufactured). This may be referred to as the
registration part of the certification authority business process.

However, as in the PGP example, everybody could be their own
registration authority ... and a certificate need never, ever be
manufactured.

Effectively this is similar to the RADIUS and banking scenerios where
"registration authority" of a public key is performed in much the same
way that passwords and/or PINs are registered today.

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

OT - Internet Explorer V6.0

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OT - Internet Explorer V6.0
Newsgroups: bit.listserv.ibm-main,comp.lang.cobol
Date: Wed, 05 Sep 2001 18:34:23 GMT

"Editor" writes:

Have you seen some of the newest Unisys "Mainframes?"  32 wide Intel Itanium
processors with shared memory bus running Win2000.  A fraction of the cost
and maintenance expense for the same or better power as Unisys current
"mainframes".  And you don't even have to reboot them anymore, every time
you install new software :-).

i believe that some number of the Unisys "mainframes" have at various
times been logo'ed Sequent machines ... which has been doing scalable
smp intel processors since the 80s (I think they started with national
chip tho) ... and who has since bought Sequent?

we attempted to do various things with SCI standard in the very early
90s but didn't get very far at the time.

random refs:
http://www.garlic.com/~lynn/96.html#8 Why Do Mainframes Exist ???
http://www.garlic.com/~lynn/96.html#25 SGI O2 and Origin system announcements
http://www.garlic.com/~lynn/98.html#40 Comparison Cluster vs SMP?
http://www.garlic.com/~lynn/2001b.html#39 John Mashey's greatest hits
http://www.garlic.com/~lynn/2001b.html#85 what makes a cpu fast
http://www.garlic.com/~lynn/2001f.html#11 Climate, US, Japan & supers query

misc. other
http://www.garlic.com/~lynn/subtopic.html#smp
http://www.garlic.com/~lynn/subtopic.html#hacmp

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

Parity - why even or odd (was Re: Load Locked (was: IA64 running out of steam))

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Parity - why even or odd (was Re: Load Locked (was: IA64 running out of steam))
Newsgroups: comp.arch,alt.folklore.computers
Date: Thu, 06 Sep 2001 13:53:36 GMT

jcmorris@mitre.org (Joe Morris) writes:

Most mainframe systems since the mid-60s had some degree of internal
fault detection, and often fault recovery or at least a mechanism to
record the details of the failure.  (Some of the IBM systems included
the ability for the CPU to automatically place a service call, which
inevitably resulted in "E.T. Phone Home" jokes.)

note also that standard policy that a machine could be "scoped" in the
field. when machines got too complex &/or other issues (like TCMs) for
scoping, then there was a boot-strap scoping procedures; a "service
processor" that could be scoped (for diagnosing problems in the
service processor), and then the service processor has all sorts of
probes and diagnostic capability into the "real" machine.

The 3081 had a UC.5 (a particular microprocessor also used in a number
of other places, 8100, 3705, etc) as a "service processor". The 3090
had a pair of 4361s (small 370s, running a special version of vm/370
release 6) as the service processor (aka the service processors were
redundant). One of the 4361 service processor would be the one to
phone home.

I believe the 3090 had 64/80 ECC memory ... detect all 16 bit errors
and correct all 15 bit errors.

misc. refs:
http://www.garlic.com/~lynn/96.html#41 IBM 4361 CPU technology
http://www.garlic.com/~lynn/99.html#61 Living legends
http://www.garlic.com/~lynn/99.html#62 Living legends
http://www.garlic.com/~lynn/99.html#63 System/1 ?
http://www.garlic.com/~lynn/99.html#106 IBM Mainframe Model Numbers--then and now?
http://www.garlic.com/~lynn/99.html#108 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
http://www.garlic.com/~lynn/99.html#239 IBM UC info
http://www.garlic.com/~lynn/2000b.html#50 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000b.html#51 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000b.html#66 oddly portable machines
http://www.garlic.com/~lynn/2000b.html#69 oddly portable machines
http://www.garlic.com/~lynn/2000b.html#79 "Database" term ok for plain files?
http://www.garlic.com/~lynn/2000c.html#76 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000d.html#26 Superduper computers--why RISC not 390?
http://www.garlic.com/~lynn/2001b.html#75 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001b.html#83 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001f.html#44 Golden Era of Compilers
http://www.garlic.com/~lynn/2001h.html#2 Alpha: an invitation to communicate

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

Parity - why even or odd (was Re: Load Locked (was: IA64 running out of steam))

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Parity - why even or odd (was Re: Load Locked (was: IA64 running out of steam))
Newsgroups: alt.folklore.computers
Date: Thu, 06 Sep 2001 15:14:27 GMT

jcmorris@mitre.org (Joe Morris) writes:

Nope, 600 usec core memory (IBM 2365, for a 360/65).  Each 256 KB on
the /65 was housed in its own box, IIRC 6' high, 7' long, 30in wide,
and requiring 208 VAC 3-phase power.

the ibm memory for the 65/67 was 750usec core memory (my understanding
was that the 30, 40, 50, 60, 62, 70 designations were the original 360
model designations ... with 60, 62, 70 having something like 1000usec
memory and the 65, 67, 76 model designation was for the faster,
improved 750usec memory).

The 67 was effictively a 360/m65 with addition of virtual memory
hardware and a fully associative TLB (table lookaside buffer) for
hardware virtual memory address resolution. When running in virtual
memory mode, the TLB look-up added 150us to all address cycles
(virtual memory mode on 360/m67 turned it into 900us machine).

A lot of the 360m67s spent much of their time running in 360m65 mode
(for the most part, os/360 ran identical on 360m67 & 360m65).

The 360m67 SMP was a different beast tho from the 360m65. The 360m65
SMP was basically two 360m65 uniprocessors bolted together so that
they had common addressing for all memory (or could be partitioned two
uniprocessor and each processor had half the real memory).

The 360m67 SMP had special tri-ported memory and a channel director.
The tri-ported memory gave each processor and the I/O channel director
independent paths to memory. The tri-ported memory introduced
something like an extra 10% latency in memory operations (i.e. 750us
to 825us or so, my memory is little weak on this value).

It was also possible to split 360m67 SMP into approximately two
independent uni-processors ... however there was still the hardware
memory latency difference between the normal 65/67 and a SMP 67 (i.e.
numerical intensive operations ran slower on SMP 67 whether it was
configured as a up or a SMP ... compared to 65 (uniprocessor or smp)
or a uniprocessor 67. However, in workload mix that was 100% cpu and
heavy i/o activity ... a "half-duplex" 67 had higher thruput than a
uniprocessor 65/67. The standard memory bus with single port resulting
in memory bus contention between the processor and I/O (slowing down
the processor). The "duplex" memory bus while having slightly higher
initial latency resulted in much lower memory bus contention when
concurrent I/O and CPU accesses were involved.

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

Parity - why even or odd (was Re: Load Locked (was: IA64 running out of steam))

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Parity - why even or odd (was Re: Load Locked (was: IA64 running out of steam))
Newsgroups: alt.folklore.computers
Date: Thu, 06 Sep 2001 18:55:57 GMT

Neil Franklin writes:

Do I get that right? 600 or 750 microseconds for one memory access?
That is about 1200 to 1300 memory access per second.

If you had said 6.00 or 7.50 usec (= 6000 or 7500 nsec) I would believe it.

Even a "cheap" PDP-8/E had something like 1.2 usec machine cycle (so
memory must be less time that that).

360/m65/m67, etc nanoseconds ... 750 nanoseconds ... 8byte-wide interleaved.

360m50 was 2microseconds ... 2byte-wide

bulk (add-on) memory (8mbytes) from Ampex that could be attached to
360m50, 360m65, etc was 8microsecond memory.

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

OT - Internet Explorer V6.0

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OT - Internet Explorer V6.0
Newsgroups: bit.listserv.ibm-main,comp.lang.cobol,alt.folklore.computers
Date: Thu, 06 Sep 2001 19:33:16 GMT

Charles writes:

I think the real strength of microsoft is you can buy a PC and install a program
or an application with very little knowledge about Hardware, files or memory
management.  A trained monkey could be taught to use a PC.  We use VSE/CICS with
over 200 users hitting the mainframe, at our school and even more from the
internet.  Security of Data is also a key reason we still use the mainframe. It
takes hundreds of PC's to access one mainframe so Microsoft PC's and IBM and
other manufacturer's mainframes are good for each other, along with the servers
and the network software it takes to access the mainframe.  This is a Symbiosis
going on here not necessarily direct competition.

In the early '80s before Apple Mac was announced, I would periodically
have dinner with some of the Mac developers. We would have this
argument about whether the Mac (then) was ever going to be
profitable. I would somewhat characterize the Mac group at targeting
the box for the kitchen table and they found the idea that it might
ever be used in any other environment (especially any sort of business
context) as an anathema.

My counter-argument was that the vast majority of the IBM/PC sales
were into business (i.e. for a whole slew of reasons, personal
computing wasn't really ready from the general, novice consumer
market) .... possibly by a ratio of 10:1. A big factor in that was
having mainframe terminal emulation on the PC ... so there was a
single desk footprint ... aka with a single screen, keyboard, box, a
person could both do local computing as well as do their mainframe
accesses (aka a big factor in early IBM/PC market penetration was that
it had at least some local computing capability and also could act as
an ibm mainframe terminal). Being able to establish a (then) huge
install base on the basis of single keyboard on the desk (capable of
both mainframe & local computing) .. that created critical mass for
motivating more applications to be written for the IBM/PC ... which
started the snowball effect; once the initial base was established,
then more applications were written, which increased the value
proposition for having a PC, leading to further increases in the
install base, motivating even more application development.

This characteristic allowed some graceful transition from mainframe
centric operation to incremental local applications. The problem by
the late '80s was the migration was starting to accelerate for both
processor-centric applications as well as data-centric applications.

This was creating a horrible bind in corporate america ... the local
computing processing power was a transient type of activity ... but
when some of the corporate jewels (like finance data) started
migrating to PCs & PC disks there were some serious episodes of disk
failure and lost data that seriously impacted business operations.

At the same time, there was an internal corporate battle going on.
The disk storage division generated a report that the head of the
communication division was going to be personally responsible for the
demise of the disk storage division. The 2nd level detail was that the
disk storage division had come up with a number of very effective
solutions that supported PC accessing mainframe resident data. The
communication division was non-concurring on all such offerings
... effectively attempting to maintain that all PC mainframe access
had to be channeled thru the communication division's terminal
(emulation) products. The lack of bandwidth and function of the
communication division's terminal (emulation) was accelerating the
migration of data off the mainframe. That migration was also
significantly increasing the risks & business continuity exposures of
corporate american (since critical corporate assets were now resident
on platforms that lacked any business continuity &/or disaster
recovery scenerios).

Siding with the communication divison was the mainframe processor SAA
strategy which could be interpreted as 1) all application could
executed at either the mainframe or the PC ... and once that was
achieved 2) some of the mainframe->PC processor migration could be
reversed. The shortcoming was that there was some really valid reasons
for much of the mainframe->PC processing migration; but an optimal
business strategy would be to do it in such a way that critical
business assets (aka information & data) could continue to reside at
the mainframe.

The shortcoming is that once the PC began using the terminal emulation
interface as a graceful migration & market penetration ... it later
became a nearly impossible (internal) business problem to offer
something that would take business away from the division responsible
for terminal emulation (even if that limitation eventually resulted in
significant, overall loss of business to the company).

From corporate america standpoint, I believe in the mid-90s there was
some study that said that companies that had (non-backed up) disk
failures with critical corporate assets, 50 percent went bankrupt
within the first month (corporate assets could be billing file,
accounts receivable, etc ... which could seriously impact a month's
cash flow).

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

I hate Compaq

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: I hate Compaq
Newsgroups: comp.arch,alt.folklore.computers
Date: Thu, 06 Sep 2001 20:53:56 GMT

name99@mac.com (Maynard Handley) writes:

Hmm, Nick, you need to keep your exaggerations self-consistent.

A few posts ago you were telling us that MP was "widely available" sonce
the 70's, yet hadn't led to widespread MP software.

Now you're telling us that actually MP HW that works is sufficiently hard
to make useful that it wasn't really available till maybe the early 90's

60s & 70s had relatively wide-spread two-processor SMP support. The
cached machines had very strong consistent caches ... that introduced
a 10-15% performance penalty (in cycle time) compared to uniprocessor.

In the 70s, the "normal" machines were uniprocessor and two-processor
SMPs had the 10-15% performance (i.e. a two processor was rated at
best at 1.8times the instruction rate of a uniprocessor, not two
times, all of this was due to cache consistency).

One could make the argument that one majors issue of the 801/risk
architecture from the 70s that lacked cache consistency provisions
... was a re-action to the experience in designing cache-consistent
mainframes.

So we cycle up to the start of the '80s with the 3081. The 3081 was
going to only be available in 2-way (and 4-way; a pair of 3081s in a
3084 configuration).

However, there was some relatively important (but not widely deployed)
operating system at the time ... which was ACP/TPF ... i.e. transaction
processing factility aka airline control program which didn't have SMP
support. It tended to be a few highly tuned, extremely high
transaction rate, processor bound environment ... that carried the
majority of the world's airline reservations (as well as supporting
misc. other high transaction rate oriented businesses).

An ACP/TPF running on a 3081 in uniprocessor mode ... still had the
15% cache consistency performance penalty. The issue wasn't so much
the cost of the unused hardware that led to the 3083 ... it was that
ACP/TPF needed the additional 15% performance boost that came with
eliminating the cache consistency cycles. The lack of SMP support in
ACP/TPF giving rise to the 3083 is (at least) partially orthogonal to
mainframes getting really scalable cache consistency implementations.

The very strong memory consistency and the distances between the
caches ... made it hard to even limit the 3084 4-way to just a 15%
performance penalty (in part, they ran the cache hardware cycle at
faster than the machine cycle). This all further aggravated the
801/risc tendency towards avoiding cache consistency protocols all
together.

The skunk works that my wife and I ran was both involved in SCI for
scaleable SMP support as well as I/O-based clustering (including
fiber-channel) ... the problem we had in the late '80s & early '90s is
that the 801/POWER chips were so far over on not supporting cache
consistency that there was no possible implementation (live oak was a
4-way RSC/.9 POWER ... but side-stepped the cache consistency issue by
be able to mark segments as non-cachable ... i.e. if it was necessary
to share data between processors ... don't cache it at all).

random refs:
http://www.garlic.com/~lynn/subtopic.html#smp
http://www.garlic.com/~lynn/subtopic.html#hacmp
http://www.garlic.com/~lynn/99.html#54 Fault Tolerance
http://www.garlic.com/~lynn/99.html#68 The Melissa Virus or War on Microsoft?
http://www.garlic.com/~lynn/99.html#71 High Availabilty on S/390
http://www.garlic.com/~lynn/99.html#128 Examples of non-relational databases
http://www.garlic.com/~lynn/99.html#152 Uptime (was Re: Q: S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#182 Clustering systems
http://www.garlic.com/~lynn/99.html#183 Clustering systems
http://www.garlic.com/~lynn/99.html#184 Clustering systems
http://www.garlic.com/~lynn/99.html#185 Clustering systems
http://www.garlic.com/~lynn/99.html#186 Clustering systems
http://www.garlic.com/~lynn/2000.html#31 Computer of the century
http://www.garlic.com/~lynn/2000.html#64 distributed locking patents
http://www.garlic.com/~lynn/2000.html#78 Mainframe operating systems
http://www.garlic.com/~lynn/2000b.html#65 oddly portable machines
http://www.garlic.com/~lynn/2000c.html#4 TF-1
http://www.garlic.com/~lynn/2000c.html#9 Cache coherence [was Re: TF-1]
http://www.garlic.com/~lynn/2000c.html#14 thread scheduling and cache coherence traffic
http://www.garlic.com/~lynn/2000c.html#19 Hard disks, one year ago today
http://www.garlic.com/~lynn/2000c.html#56 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#68 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000d.html#31 RS/6000 vs. System/390 architecture?
http://www.garlic.com/~lynn/2000e.html#7 Ridiculous
http://www.garlic.com/~lynn/2000e.html#8 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000e.html#9 Checkpointing (was spice on clusters)
http://www.garlic.com/~lynn/2000e.html#22 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000e.html#49 How did Oracle get started?
http://www.garlic.com/~lynn/2000g.html#27 Could CDR-coding be on the way back?
http://www.garlic.com/~lynn/2000g.html#38 4M pages are a bad idea (was Re: AMD 64bit Hammer CPU and VM)
http://www.garlic.com/~lynn/2000g.html#43 4M pages are a bad idea (was Re: AMD 64bit Hammer CPU and VM)
http://www.garlic.com/~lynn/2001.html#26 Disk caching and file systems. Disk history...people forget
http://www.garlic.com/~lynn/2001.html#33 Where do the filesystem and RAID system belong?
http://www.garlic.com/~lynn/2001.html#36 Where do the filesystem and RAID system belong?
http://www.garlic.com/~lynn/2001.html#38 Competitors to SABRE?
http://www.garlic.com/~lynn/2001.html#40 Disk drive behavior
http://www.garlic.com/~lynn/2001.html#64 Are the L1 and L2 caches flushed on a page fault ?
http://www.garlic.com/~lynn/2001b.html#11 Review of the Intel C/C++ compiler for Windows
http://www.garlic.com/~lynn/2001b.html#14 IBM's announcement on RVAs
http://www.garlic.com/~lynn/2001b.html#15 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
http://www.garlic.com/~lynn/2001b.html#35 John Mashey's greatest hits
http://www.garlic.com/~lynn/2001b.html#60 monterey's place in computing was: Kildall "flying" (was Re: First OS?)
http://www.garlic.com/~lynn/2001c.html#66 KI-10 vs. IBM at Rutgers
http://www.garlic.com/~lynn/2001c.html#69 Wheeler and Wheeler
http://www.garlic.com/~lynn/2001d.html#26 why the machine word size is in radix 8??
http://www.garlic.com/~lynn/2001d.html#70 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001d.html#71 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001e.html#2 Block oriented I/O over IP
http://www.garlic.com/~lynn/2001e.html#4 Block oriented I/O over IP
http://www.garlic.com/~lynn/2001e.html#5 SIMTICS
http://www.garlic.com/~lynn/2001e.html#14 Climate, US, Japan & supers query
http://www.garlic.com/~lynn/2001f.html#21 Theo Alkema
http://www.garlic.com/~lynn/2001f.html#39 Ancient computer humor - DEC WARS
http://www.garlic.com/~lynn/2001f.html#60 JFSes: are they really needed?
http://www.garlic.com/~lynn/2001g.html#43 The Alpha/IA64 Hybrid
http://www.garlic.com/~lynn/2001g.html#44 The Alpha/IA64 Hybrid
http://www.garlic.com/~lynn/2001g.html#46 The Alpha/IA64 Hybrid
http://www.garlic.com/~lynn/2001g.html#49 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001g.html#52 Compaq kills Alpha
http://www.garlic.com/~lynn/2001h.html#26 TECO Critique
http://www.garlic.com/~lynn/2001h.html#59 Blinkenlights
http://www.garlic.com/~lynn/2001h.html#76 Other oddball IBM System 360's ?
http://www.garlic.com/~lynn/2001i.html#41 Withdrawal Announcement 901-218 - No More 'small machines'
http://www.garlic.com/~lynn/2001i.html#43 Withdrawal Announcement 901-218 - No More 'small machines'
http://www.garlic.com/~lynn/2001i.html#46 Withdrawal Announcement 901-218 - No More 'small machines'
http://www.garlic.com/~lynn/2001i.html#48 Withdrawal Announcement 901-218 - No More 'small machines'
http://www.garlic.com/~lynn/2001i.html#52 misc loosely-coupled, sysplex, cluster, supercomputer, & electronic commerce
http://www.garlic.com/~lynn/2001j.html#3 YKYGOW...
http://www.garlic.com/~lynn/2001j.html#4 I hate Compaq
http://www.garlic.com/~lynn/2001j.html#12 OT - Internet Explorer V6.0

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

I hate Compaq

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: I hate Compaq
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 07 Sep 2001 00:30:14 GMT

Tom Van Vleck writes:

There was a performance degradation as CPUs were added to Multics,
but it wasn't due to cache consistency.  In the 645/6180 architecture,
memory was external to the CPU, and memory interference was one
component of the slowdown.  A much bigger component was queueing
on software locks for the paging and scheduling mechanisms.  We studied
these factors and had designs for breaking down many of the big
locks into smaller locks, to increase parallelism through the
supervisor.  This was one of the many projects the Multics team
didn't get to do.

the original translation of the 5-way VAMPS to standard vm/370 product
had nearly zero locking & queuing SMP overhead (and achieved hardware
utilization thruput of the processors)  i played some tricks

most recent VAMPS overview (posted here 18aug)
http://www.garlic.com/~lynn/2001i.html#2

however some number of people were uncomfortable with the approach and
after a couple software releases changed the implementation and put in
a more traditional locking, queuing, and signalling SMP design
... which drove the SMP "software" overhead to 10-15% of each
processor ... i.e.  traditional 2-way 370 SMP would have 1.8 times
hardware thruput of a uniprocessor (because of the cache coherency
protocol slowing down each cpu by 10% ... not even taking into account
any actual cross-cache line trashing overhead).  With the later
version software change in VM ... system thruput was reduced to about
1.5 times thruput of uniprocessor running the same workload (each
processor slow down was 10% plus another 15% of each processor tied up
in various kernel SMP related operations).

I was involved in an attempt to build a 16-way 370/158 ... which was
chugging along pretty good until the head of POK was informed that MVS
SMP support was still limited to 2-way at the time (i.e. it is either
"me" or the one other cpu) and then (effectively) threatened to fire
everybody involved in the 16-way project.

The 3081/3084 finally saw MVS SMP support finally extended to >2-way.
The 3081/3084 also saw a lot of effort go into minimizing cache-line
thrashing. Storage allocation was redone to be cache-line sensitive
and various modules with internal variables were redone to separate
various things into different cache lines, various control blocks
redone to separate certain critical variables into different cache
lines. This didn't eliminate cache-line thrashing when different CPUs
needed the same variable ... but at least it mitigated cache-line
thrashin when different CPUs needed different variables that happened
to reside in the same cache line.

smp & cluster refs:
http://www.garlic.com/~lynn/subtopic.html#smp

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

I hate Compaq

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: I hate Compaq
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 07 Sep 2001 00:52:31 GMT

Anne & Lynn Wheeler writes:

the original translation of the 5-way VAMPS to standard vm/370 product
had nearly zero locking & queuing SMP overhead (and achieved hardware
utilization thruput of the processors)  i played some tricks

most recent VAMPS overview (posted here 18aug)
http://www.garlic.com/~lynn/2001i.html#2

in fact, in the above translation from VAMPS to standard 370 ... there
were a large number of situations where the above implementation saw
greater than two times the effective thruput of a uniprocessor
... even when each processor was running 10 percent slower (nominal
hardware rating of two processors were 1.8 time that of a
uniprocessor).

the issue was that standard 370 of the era took big cache-miss
penalties on interrupts ... i.e. application program chugging along
just fine and in comes a I/O interrupt which jumps into the kernel,
handles the I/O and eventually preculates back to the application.  An
implicit side-effect of the way that some of the code executed on a
2-way, in a large number of situations tended to keep the kernel
execution on the same processor (w/o bottlenecking on a kernel lock)
that it was already executing on (a kind of processor afinity). The
improvement in cache-hit efficiency (corresponding reduction in
cache-miss inefficeincy) would result in greater than twice the
thruput of a uniprocessor (even tho the native hardware was
effectively only 1.8 times that of a uniprocessor).

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

OT - Internet Explorer V6.0

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OT - Internet Explorer V6.0
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 07 Sep 2001 14:16:08 GMT

Lars Poulsen writes:

A good ethernet adapter for S/370 coupled with "LAN Manager for
MVS" would have served both IBM and customers very well.
Never figured out why you guys didn't just do it.

we got in a whole lot of trouble when we presented the "invention" of
3-layer architecture with a ethernet-based example.

the T/R people were doing 16mbit T/R theoritical comparisons against a
old-style e-net theoritical comparision (3mbit/sec e-net that didn't
have listen before transmit). The SAA people that wanted to see
client/server start to be much more server-based were also upset.

misc. 3-layer architecture references
http://www.garlic.com/~lynn/96.html#16 middle layer
http://www.garlic.com/~lynn/96.html#17 middle layer
http://www.garlic.com/~lynn/98.html#50 Edsger Dijkstra: the blackest week of his professional life
http://www.garlic.com/~lynn/99.html#123 Speaking of USB ( was Re: ASR 33 Typing Element)
http://www.garlic.com/~lynn/99.html#124 Speaking of USB ( was Re: ASR 33 Typing Element)
http://www.garlic.com/~lynn/99.html#201 Middleware - where did that come from?
http://www.garlic.com/~lynn/99.html#202 Middleware - where did that come from?
http://www.garlic.com/~lynn/2000.html#32 Homework: Negative side of MVS?
http://www.garlic.com/~lynn/2000b.html#8 "Mainframe" Usage
http://www.garlic.com/~lynn/2000b.html#11 "Mainframe" Usage
http://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink)
http://www.garlic.com/~lynn/2000f.html#27 OT?
http://www.garlic.com/~lynn/2000f.html#38 Ethernet efficiency (was Re: Ms employees begging for food)
http://www.garlic.com/~lynn/2000f.html#39 Ethernet efficiency (was Re: Ms employees begging for food)
http://www.garlic.com/~lynn/2001d.html#69 Block oriented I/O over IP

there were a couple of e-net articles in '88 ACM SIGCOMM with regard
to typical e-net adapter card thruput being around 95% of media
thruput ... and typical aggregate e-net thruput being at 95% of media
thruput dropping off to around 85% of media thruput under some
worse=case scenerios (typical LAN with all nodes in tight
device-driver loop transmitting minimum sized packets as fast as
possible).

by comparison the typical 16mbit t/r card sustained thruput was around
under 2mbit/sec ... and typical aggregate 16mbit t/r media was less
than 1/2 media thruput. The Austin group had done a custom ISA 4mbit
t/r card for the PC/RT ... but the whole corporation had to use the
PS/2 microchannel 16mbit t/r card. The PS/2 microchannel 16mbit T/R
card had lower (per card) sustained thruput than the Austin ISA 4mbit
T/R card.

Part of the issue was that both client/server as well as 3-layer have
asymmetric traffic flows (i.e. some server has to see the aggregate
traffic of all its individual clients) while all the 16mbit T/R cards
(even the ones in 370 controllers) were essentially the same, targeted
at effectively random, symmetrical traffic flows ... no single node
seeing any more traffic than any other node.

misc sigcomm refs
http://www.garlic.com/~lynn/2000f.html#38 Ethernet efficiency (was Re: Ms employees begging for food)
http://www.garlic.com/~lynn/2000f.html#39 Ethernet efficiency (was Re: Ms employees begging for food)

the other issue was that SNA didn't have any networking protocol/layer
...  as a result T/R had to be all bridged (all nodes effectively had
to see all broadcasts). By comparison, TCP/IP with a network layer
allowed for routers so that all segments didn't have to see all
broadcasts. The twisted-pair enet standard even ran over the same cat5
wiring that might have been originally installed for T/R.

I had worked on the original mainframe TCP/IP support and had done the
RFC 1044 support doing some tuning of the thruput at cray research
between a 4341 and a cray. The nominal mainframe TCP/IP support at the
time would just about consume a single 3090 processor doing
44kbytes/sec. By comparison, the 1044 support on the 4341 ran with
lots of waitstate doing channel thruput (1mbyte/sec) transfers to the
cray.

random tcp/ip refs:
http://www.garlic.com/~lynn/subtopic.html#hsdt
http://www.garlic.com/~lynn/2001i.html#52 misc loosely-coupled, sysplex, cluster, supercomputer, & electronic commerce
http://www.garlic.com/~lynn/subtopic.html#networking
http://www.garlic.com/~lynn/93.html#28 Log Structured filesystems -- think twice
http://www.garlic.com/~lynn/93.html#30 /etc/sendmail.cf UUCP routing
http://www.garlic.com/~lynn/96.html#14 mainframe tcp/ip
http://www.garlic.com/~lynn/96.html#15 tcp/ip
http://www.garlic.com/~lynn/96.html#17 middle layer
http://www.garlic.com/~lynn/96.html#32 Mainframes & Unix
http://www.garlic.com/~lynn/96.html#34 Mainframes & Unix
http://www.garlic.com/~lynn/98.html#18 Reviving the OS/360 thread (Questions about OS/360)
http://www.garlic.com/~lynn/98.html#34 ... cics ... from posting from another list
http://www.garlic.com/~lynn/98.html#49 Edsger Dijkstra: the blackest week of his professional life
http://www.garlic.com/~lynn/98.html#50 Edsger Dijkstra: the blackest week of his professional life
http://www.garlic.com/~lynn/99.html#36 why is there an "@" key?
http://www.garlic.com/~lynn/99.html#40 [netz] History and vision for the future of Internet - Public Question
http://www.garlic.com/~lynn/99.html#46 Internet and/or ARPANET?
http://www.garlic.com/~lynn/99.html#48 Language based exception handling. (Was: Did Intel pay UGS to kill Alpha port? Or Compaq simply doesn't care?)
http://www.garlic.com/~lynn/99.html#114 What is the use of OSI Reference Model?
http://www.garlic.com/~lynn/99.html#115 What is the use of OSI Reference Model?
http://www.garlic.com/~lynn/99.html#123 Speaking of USB ( was Re: ASR 33 Typing Element)
http://www.garlic.com/~lynn/99.html#158 Uptime (was Re: Q: S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#159 Uptime (was Re: Q: S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#183 Clustering systems
http://www.garlic.com/~lynn/2000.html#50 APPC vs TCP/IP
http://www.garlic.com/~lynn/2000.html#51 APPC vs TCP/IP
http://www.garlic.com/~lynn/2000.html#53 APPC vs TCP/IP
http://www.garlic.com/~lynn/2000.html#90 Ux's good points.
http://www.garlic.com/~lynn/2000b.html#1 "Mainframe" Usage
http://www.garlic.com/~lynn/2000b.html#4 "Mainframe" Usage
http://www.garlic.com/~lynn/2000b.html#5 "Mainframe" Usage
http://www.garlic.com/~lynn/2000b.html#8 "Mainframe" Usage
http://www.garlic.com/~lynn/2000b.html#10 "Mainframe" Usage
http://www.garlic.com/~lynn/2000b.html#45 OSA-Express Gigabit Ethernet card planning
http://www.garlic.com/~lynn/2000b.html#59 7 layers to a program
http://www.garlic.com/~lynn/2000b.html#79 "Database" term ok for plain files?
http://www.garlic.com/~lynn/2000c.html#27 The first "internet" companies?
http://www.garlic.com/~lynn/2000c.html#29 The first "internet" companies?
http://www.garlic.com/~lynn/2000c.html#31 The first "internet" companies?
http://www.garlic.com/~lynn/2000c.html#54 WHAT IS A MAINFRAME???
http://www.garlic.com/~lynn/2000c.html#58 Disincentives for MVS & future of MVS systems programmers
http://www.garlic.com/~lynn/2000c.html#59 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#60 Disincentives for MVS & future of MVS systems programmers
http://www.garlic.com/~lynn/2000d.html#41 TCP/IP Suite of Protocols - dumb question ...
http://www.garlic.com/~lynn/2000d.html#43 Al Gore: Inventing the Internet...
http://www.garlic.com/~lynn/2000d.html#54 NCP Help (re (D)ARPANET)
http://www.garlic.com/~lynn/2000d.html#55 NCP  v TCP/IP
http://www.garlic.com/~lynn/2000d.html#63 Is Al Gore The Father of the Internet?
http://www.garlic.com/~lynn/2000d.html#67 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2000d.html#70 When the Internet went private
http://www.garlic.com/~lynn/2000d.html#72 When the Internet went private
http://www.garlic.com/~lynn/2000d.html#77 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2000e.html#5 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2000e.html#28 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2000e.html#30 Is Tim Berners-Lee the inventor of the web?
http://www.garlic.com/~lynn/2000f.html#30 OT?
http://www.garlic.com/~lynn/2000f.html#31 OT?
http://www.garlic.com/~lynn/2000f.html#79 Cryptogram Newsletter is off the wall?
http://www.garlic.com/~lynn/2001b.html#81 36-bit MIME types, PDP-10 FTP
http://www.garlic.com/~lynn/2001c.html#5 what makes a cpu fast
http://www.garlic.com/~lynn/2001d.html#46 anyone have digital certificates sample code
http://www.garlic.com/~lynn/2001d.html#63 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001d.html#65 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001d.html#69 Block oriented I/O over IP
http://www.garlic.com/~lynn/2001e.html#8 Blame it all on Microsoft
http://www.garlic.com/~lynn/2001e.html#16 Pre ARPAnet email?
http://www.garlic.com/~lynn/2001e.html#17 Pre ARPAnet email?
http://www.garlic.com/~lynn/2001e.html#24 Pre ARPAnet email?
http://www.garlic.com/~lynn/2001e.html#32 Blame it all on Microsoft
http://www.garlic.com/~lynn/2001e.html#34 Blame it all on Microsoft
http://www.garlic.com/~lynn/2001e.html#52 Pre ARPAnet email?
http://www.garlic.com/~lynn/2001f.html#20 VM-CMS emulator
http://www.garlic.com/~lynn/2001f.html#22 Early AIX including AIX/370
http://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001h.html#13 VM: checking some myths.
http://www.garlic.com/~lynn/2001h.html#44 Wired News :The Grid: The Next-Gen Internet?
http://www.garlic.com/~lynn/2001i.html#5 YKYGOW...
http://www.garlic.com/~lynn/2001i.html#6 YKYGOW...
http://www.garlic.com/~lynn/2001i.html#21 3745 and SNI
http://www.garlic.com/~lynn/2001i.html#31 3745 and SNI

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

Parity - why even or odd (was Re: Load Locked

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Parity - why even or odd (was Re: Load Locked
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 07 Sep 2001 14:21:58 GMT

jcmorris@mitre.org (Joe Morris) writes:

Part of this is my background: in the IBM mainframe world, the
cylinder/head/record identifier for a particular unit of recorded
information on a random-access device is referred to as the "disk
address".  (Then there's the "full disk address" of the form MBBCCHHR
(pronounced "mumble").  Can anyone who never needed to set the BB
field to a nonzero value tell the class what it was used for?)

the data noodle (sometimes turning it into spaghetti)  ... random refs
http://www.garlic.com/~lynn/2000.html#9  Computer of the century
http://www.garlic.com/~lynn/2000b.html#41  How to learn assembler language for OS/390 ?
http://www.garlic.com/~lynn/2001.html#17  IBM 1142 reader/punch (Re: First video terminal?)
http://www.garlic.com/~lynn/2001.html#51  Competitors to SABRE?

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

Title Inflation

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Title Inflation
Newsgroups: alt.folklore.computers
Date: Fri, 07 Sep 2001 15:43:19 GMT

Charles Richmond writes:

I prefer "The Master of Space, Time, and Dimension" as my title...
IIRC, Isaac Azimov had business cards that said:  "Isaac Azimov,
Natural Resource". Perhaps that would be adequate for a title...

i once reported to an executive (for a time, i was the only person
that reported to him, it was a form of punishment) ... who had
business cards presented to him by the CEO that said corporate
gadfly. I managed most of my career to have business cards w/o any
title what-so-ever. A number of situations were interesting, people
not knowing how to deal with you if you lacked a title.

On the other hand, i had one of the first business cards with an email
address.

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

OT - Internet Explorer V6.0

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OT - Internet Explorer V6.0
Newsgroups: bit.listserv.ibm-main,comp.lang.cobol,alt.folklore.computers
Date: Fri, 07 Sep 2001 17:12:33 GMT

"Editor" writes:

My point was - The line between "Mainframe" and "PC" is bluring very
quickly.  I don't care if it's MVS/Windows/Unix or some OS yet to be
invented, the cost/size/technology involved is all mushing together.
And what will drive existing "big iron" users to smaller systems based on
RISC or Intel Processors is pure cost.  Cost of the iron and mostly cost of
the maintenance fees.

the counter-argument in the above is that many of the
commondity/volume platforms may have much of the feature/function
... they are still lower down the curve in many of the business
continuity areas.

in the late '80s ... after something like 20 years in the mainframe
space, my wife and i started doing clustering on "commodity" priced
platforms (she had done stint in POK in charge of loosely-coupled
architecture and originated peer-coupled shared data ... later basis
for ims hot-standby & sysplex). some number of the biggest current
proponents of clusters were some of staunchest advisaries at the time.

we were also doing things like disaster survivability &
geographic survivability (terms we had coined). we got a chance
to author sections of the corporate continuous availability
strategy document ... but both rochester & POK non-concurred
... and most of our stuff was pulled from the document.

random refs:
http://www.garlic.com/~lynn/subtopic.html#hacmp
http://www.garlic.com/~lynn/99.html#47 Language based exception handling. (Was: Did Intel pay UGS to kill Alpha port? Or Compaq simply doesn't care?)
http://www.garlic.com/~lynn/99.html#71 High Availabilty on S/390
http://www.garlic.com/~lynn/99.html#104 Fixed Head Drive (Was: Re:Power distribution (Was: Re: A primeval C compiler)
http://www.garlic.com/~lynn/99.html#128 Examples of non-relational databases
http://www.garlic.com/~lynn/2001d.html#47 Just a guick remembrance of where we all came from
http://www.garlic.com/~lynn/2001g.html#44 The Alpha/IA64 Hybrid
http://www.garlic.com/~lynn/2001i.html#41 Withdrawal Announcement 901-218 - No More 'small machines'
http://www.garlic.com/~lynn/2001i.html#48 Withdrawal Announcement 901-218 - No More 'small machines'
http://www.garlic.com/~lynn/2001i.html#49 Withdrawal Announcement 901-218 - No More 'small machines'

a big factor in iron cost started being volume (lots of huge up-front
costs that had to be amortized across the pieces).

in the mid-80s, I once observed that a $300 CDROM player had more
advanced technology than a $20,000 fiber-optic modem, claiming that I
could essentially build a better fiber-optic modem from parts out of a
$300 CDROM (in fact there were then some fiber-optic modems built from
essentially CDROM optical drivers, the 6000 SLA was essentially a 10%
faster escon ... running full-duplex instead of half-duplex, and
optical drivers cost that were at least 1/10th that of escon's).

random escon/sla refs:
http://www.garlic.com/~lynn/96.html#5 360 "channels" and "multiplexers"?
http://www.garlic.com/~lynn/96.html#15 tcp/ip
http://www.garlic.com/~lynn/2000d.html#14 FW: RS6000 vs IBM Mainframe
http://www.garlic.com/~lynn/2000f.html#31 OT?
http://www.garlic.com/~lynn/2000g.html#50 Egghead cracked, MS IIS again
http://www.garlic.com/~lynn/2001.html#12 Small IBM shops
http://www.garlic.com/~lynn/2001.html#18 Disk caching and file systems. Disk history...people forget
http://www.garlic.com/~lynn/2001.html#46 Small IBM shops
http://www.garlic.com/~lynn/2001e.html#22 High Level Language Systems was Re: computer books/authors (Re: FA:

in the late '80s there was big government push in the HDTV area
... the commerce department essentially taking the position if non-US
corporations dominated HDTV area ... that the associated technology
volumes would allow them to then dominate all aspects of electronics
hi-tech industry.

some random HDTV refs:
http://www.garlic.com/~lynn/2000e.html#11 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2001.html#73 how old are you guys
http://www.garlic.com/~lynn/2001b.html#2 FCC rulemakings on HDTV

Effectively, the volumes associated with consumer electronics provided
sufficient R&D funding that they could pass the pure hitech computer
industry ... aka the volumes could drive design of better, faster, &
less expensive chips.

There were some issues with quality ... but once the volumes got large
enuf, many areas started finding that it was cheaper to put a lot of
upfront costs into quality than the costs of the associated trouble
calls & returns (commodity priced disks going from MTBF of 40k hours
to 800k hours). In the disk area, if RAID was then layered on top, it
really became a no-contest.

some random MTBF refs:
http://www.garlic.com/~lynn/94.html#8 scheduling & dynamic adaptive ... long posting warning
http://www.garlic.com/~lynn/94.html#16 Dual-ported disks?
http://www.garlic.com/~lynn/95.html#3 What is an IBM 137/148 ???
http://www.garlic.com/~lynn/99.html#54 Fault Tolerance
http://www.garlic.com/~lynn/99.html#73 The Chronology
http://www.garlic.com/~lynn/99.html#97 Power4 = 2 cpu's on die?
http://www.garlic.com/~lynn/2001.html#32 Competitors to SABRE?
http://www.garlic.com/~lynn/2001.html#34 Competitors to SABRE?
http://www.garlic.com/~lynn/2001.html#37 Competitors to SABRE?
http://www.garlic.com/~lynn/2001.html#38 Competitors to SABRE?
http://www.garlic.com/~lynn/2001b.html#82 Disks size growing while disk count shrinking = bad performance
http://www.garlic.com/~lynn/2001b.html#84 Disks size growing while disk count shrinking = bad performance
http://www.garlic.com/~lynn/2001d.html#47 Just a guick remembrance of where we all came from
http://www.garlic.com/~lynn/2001g.html#15 Extended memory error recovery
http://www.garlic.com/~lynn/2001h.html#19 checking some myths.

This carried over into the software arenea, for instance could
(relative) low-volume operating systems maintain the new R&D
technology investments that was going into the high-volume operating
systems tracking newest technology advances.

In that sense, at some point a threshold was passed ... and the big
iron environments had to start playing catchup (they still had their
legacy apps of 30+ years). Some issue is does the legacy apps
represent sufficient value and revenue flow to underwrite the
necessary new R&D investment to keep abreast of what is going on in
some of the higher volume market segments.

Amdahl gave a seminar at MIT around '71 analysing what part
360s would play in the marketplace (the audience did somewhat roast
him for being a front for foreign interests based on the Amdahl corp
business plan/funding). It included some observation about the amount
of software investment in the legacy applications and the, then,
projected costs of rewriting applications for a new or different
platform ... which wasn't likely to happen any time in the next 30
years (it has now been 30 years). Part of the issue is that there has
been some advances in software technology ... and there are some now
standardized product offerings that offer the feature/function of the
roll-your-own, ground-up legacy implementations (potentially
significantly mitigating the rewritting argument).

random amdahl related refs:
http://www.garlic.com/~lynn/99.html#2 IBM S/360
http://www.garlic.com/~lynn/99.html#188 Merced Processor Support at it again . . .
http://www.garlic.com/~lynn/99.html#190 Merced Processor Support at it again . . .
http://www.garlic.com/~lynn/99.html#209 Core (word usage) was anti-equipment etc.
http://www.garlic.com/~lynn/2000c.html#8 IBM Linux
http://www.garlic.com/~lynn/2000c.html#44 WHAT IS A MAINFRAME???
http://www.garlic.com/~lynn/2000c.html#48 WHAT IS A MAINFRAME???
http://www.garlic.com/~lynn/2000d.html#61 "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)
http://www.garlic.com/~lynn/2000e.html#20 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2000e.html#21 Competitors to SABRE? Big Iron
http://www.garlic.com/~lynn/2000e.html#58 Why not an IBM zSeries workstation?
http://www.garlic.com/~lynn/2000f.html#11 Amdahl Exits Mainframe Market
http://www.garlic.com/~lynn/2000f.html#12 Amdahl Exits Mainframe Market
http://www.garlic.com/~lynn/2000f.html#68 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000f.html#69 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2001.html#18 Disk caching and file systems. Disk history...people forget
http://www.garlic.com/~lynn/2001.html#63 Are the L1 and L2 caches flushed on a page fault ?
http://www.garlic.com/~lynn/2001b.html#12 Now early Arpanet security
http://www.garlic.com/~lynn/2001b.html#28 So long, comp.arch
http://www.garlic.com/~lynn/2001b.html#56 Why SMP at all anymore?
http://www.garlic.com/~lynn/2001b.html#67 Original S/360 Systems - Models 60,62 70
http://www.garlic.com/~lynn/2001b.html#73 7090 vs. 7094 etc.
http://www.garlic.com/~lynn/2001d.html#35 Imitation...
http://www.garlic.com/~lynn/2001d.html#70 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001e.html#19 SIMTICS
http://www.garlic.com/~lynn/2001g.html#35 Did AT&T offer Unix to Digital Equipment in the 70s?

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

Parity - why even or odd (was Re: Load Locked

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Parity - why even or odd (was Re: Load Locked
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 07 Sep 2001 17:17:27 GMT

jcmorris@mitre.org (Joe Morris) writes:

Part of this is my background: in the IBM mainframe world, the
cylinder/head/record identifier for a particular unit of recorded
information on a random-access device is referred to as the "disk
address".  (Then there's the "full disk address" of the form MBBCCHHR
(pronounced "mumble").  Can anyone who never needed to set the BB
field to a nonzero value tell the class what it was used for?)

can you imagine being a beta-test site for the original CICS AND
doing it on one of the mumble/noodle things.

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

Parity - why even or odd (was Re: Load Locked

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Parity - why even or odd (was Re: Load Locked
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 07 Sep 2001 17:20:16 GMT

Anne & Lynn Wheeler writes:

can you imagine being a beta-test site for the original CICS AND
doing it on one of the mumble/noodle things.

and the noise at IPL/boot time ... ker-chunk, whirl, ker-chunk, whirl,
ker-cunk, whirl, ker-chunk, whirl ... as the VOLSERs were being read.

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

Help needed on conversion from VM to OS390

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Help needed on conversion from VM to OS390
Newsgroups: bit.listserv.ibm-main
Date: Fri, 07 Sep 2001 18:12:06 GMT

FarleyP@BIS.ADP.COM (Farley, Peter x23353) writes:

Sort of a poor-man's one-way "named pipe" for small amounts of data.  In the
VM world, this allows disconnected virtual machines (running but not
connected to any terminal) to perform services for logged-on users who send
their requests to that disconnected VM by name via the SMSG command.

Without having to do your own socket programming, is this capability not
available under OS390?  Did IBM (or anyone else) port the VM/CMS WAKEUP/SMSG
code to OS390 by any chance?

it was used by the author of rexx in the very early '80s to implement
and deploy a multi-user spacewar game. since the internal networking
supported SMSG ... is was possible to propagate SMSG across the
network (the internal network was the largest network in the world at
the time) ... and have mulit-user spacewar with users on multiple
different machines.

random refs
http://www.garlic.com/~lynn/2001f.html#10 5-player Spacewar?
http://www.garlic.com/~lynn/2001f.html#12 5-player Spacewar?
http://www.garlic.com/~lynn/2001f.html#13 5-player Spacewar?
http://www.garlic.com/~lynn/2001f.html#14 5-player Spacewar?
http://www.garlic.com/~lynn/2001f.html#51 Logo (was Re: 5-player Spacewar?)
http://www.garlic.com/~lynn/2001h.html#2 Alpha: an invitation to communicate
http://www.garlic.com/~lynn/2001h.html#8 VM: checking some myths.

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

Pentium 4 SMT "Hyperthreading"

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Pentium 4 SMT "Hyperthreading"
Newsgroups: comp.arch
Date: Sat, 08 Sep 2001 04:09:03 GMT

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

The point is that using a basic SMP model, yet using a pool of
execution units for all CPUs, is an old idea.  I can't offhand think
of an old system that did it at the ALU level, but it was and is
absolutely standard practice at the I/O and memory access level.
And there is no CONCEPTUAL difference between those and ALUs in
this context.  Well, let's ignore the term and consider the known
properties.

in the early to mid 70s there was a dual i-stream 370m195 project
(that never shipped). basically branches drained the 195 pipeline
(unless they branched/looped within the pipeline) ... and very few
codes kept the pipeline feed and all the units busy.

The project added 2nd instruction stream with 2nd PSW and 2nd set of
registers and a 1bit flag on all work in the pipeline (used to
indicate the instruction stream).

The idea was that the dual i-stream had a better chance of keeping the
pipeline & units fed ... at a relatively trivial incremental hardware
cost.

random 195 refs:
http://www.garlic.com/~lynn/94.html#38 IBM 370/195
http://www.garlic.com/~lynn/94.html#39 IBM 370/195
http://www.garlic.com/~lynn/95.html#3 What is an IBM 137/148 ???
http://www.garlic.com/~lynn/96.html#24 old manuals
http://www.garlic.com/~lynn/99.html#7 IBM S/360
http://www.garlic.com/~lynn/99.html#73 The Chronology
http://www.garlic.com/~lynn/99.html#97 Power4 = 2 cpu's on die?
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/99.html#126 Dispute about Internet's origins
http://www.garlic.com/~lynn/99.html#209 Core (word usage) was anti-equipment etc.
http://www.garlic.com/~lynn/2000c.html#38 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000e.html#21 Competitors to SABRE? Big Iron
http://www.garlic.com/~lynn/2000f.html#13 Airspeed Semantics, was: not quite an sr-71, was: Re: jet in IBM ad?
http://www.garlic.com/~lynn/2000f.html#21 OT?
http://www.garlic.com/~lynn/2000g.html#15 360/370 instruction cycle time
http://www.garlic.com/~lynn/2000g.html#18 360/370 instruction cycle time
http://www.garlic.com/~lynn/2001.html#63 Are the L1 and L2 caches flushed on a page fault ?
http://www.garlic.com/~lynn/2001b.html#38 Why SMP at all anymore?
http://www.garlic.com/~lynn/2001c.html#1 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001c.html#27 Massive windows waisting time (was Re: StarOffice for free)
http://www.garlic.com/~lynn/2001h.html#49 Other oddball IBM System 360's ?
http://www.garlic.com/~lynn/2001h.html#76 Other oddball IBM System 360's ?

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

Title Inflation

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Title Inflation
Newsgroups: alt.folklore.computers
Date: Sat, 08 Sep 2001 15:58:14 GMT

jcmorris@mitre.org (Joe Morris) writes:

What time frame, and what network?

internal network, 70s (I had already moved to san jose, so late '70s).
world-wide internal network was larger than arpanet/internet until '85
or so. got to add a arpanet mailing address to the card in late '82 when
the gateway was installed.

misc. ref:
http://www.garlic.com/~lynn/internet.htm#0

in the great cut-over to IP/internet protocol jan83 there were 200 or
so arpanet nodes, at which time the internal network was nearing 1000
nodes, which it passed later that year:
http://www.garlic.com/~lynn/internet.htm#22
http://www.garlic.com/~lynn/internet.htm#27
http://www.garlic.com/~lynn/internet.htm#29

random refs:
http://www.garlic.com/~lynn/subtopic.html#networking

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

Title Inflation