List of Archived Posts

2006 Newsgroup Postings (11/23 - 12/05)

Why these original FORTRAN quirks?

New attacks on the financial PIN processing

New attacks on the financial PIN processing

Historical question, what went wrong with bubble memory?

Historical question, what went wrong with bubble memory?

Why these original FORTRAN quirks?

Reasons for the big paradigm switch

Why these original FORTRAN quirks?

In Search of Stupidity

In Search of Stupidity

What's a mainframe?

What's a mainframe?

Steve Chen Making China's Supercomputer Grid

In Search of Stupidity

In Search of Stupidity

The Incredible Shrinking Cosmonaut Corps

Ranking of non-IBM mainframe builders?

Ranking of non-IBM mainframe builders?

The Incredible Shrinking Cosmonaut Corps

Ranking of non-IBM mainframe builders?

Ranking of non-IBM mainframe builders?

The Future of CPUs: What's After Multi-Core?

vmshare

Ranking of non-IBM mainframe builders?

Z/Os Storage Mgmt products

Ranking of non-IBM mainframe builders?

Fighting Fraudulent Transactions

Federal Rules May Not Fully Secure Online Banking Sites

MB to Cyl Conversion

User Authentication

vmshare

MB to Cyl Conversion

Effi[ci]ency of branch table vs individual compare & branch

New attacks on the financial PIN processing

vmshare

What's a mainframe?

Why these original FORTRAN quirks?

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

vmshare

On sci.crypt: New attacks on the financial PIN processing

vmshare

Year-end computer bug could ground Shuttle

On sci.crypt: New attacks on the financial PIN processing

The Future of CPUs: What's After Multi-Core?

User Authentication

On sci.crypt: New attacks on the financial PIN processing

Patent buster for a method that increases password security

Why so little parallelism?

Why so little parallelism?

Patent buster for a method that increases password security

DOS C prompt in "Vista"?

Patent buster for a method that increases password security

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

Why these original FORTRAN quirks?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why these original FORTRAN quirks?
Newsgroups: alt.folklore.computers,comp.lang.fortran
Date: Thu, 23 Nov 2006 08:49:12 -0700

Peter Flass <Peter_Flass@Yahoo.com> writes:

Sorry, I missed this in my last post, why not just page-map the
executable and tag the pages.  You could do the relocation withing a
page the first time it was referenced?

smop

some amount of stuff cms inherited from os/360 which was real storage
paradigm and did stuff up-front ... before turning loose execution.

in addition to doing all the cp67 kernel changes and work on os/360
batch systems
http://www.garlic.com/~lynn/94.html#2 Schedulers
http://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14

and doing paged mapped filesystem for cms (along with the
corresponding cp kernel changes) and restructuring pieces of cms
executable code for running in protected shared storage ... i would
have had to rewrite the whole link/loader process (i.e. it wasn't
theoritically system design ... i had to do all the design and changes
myself).

i had started doing some games with how to fetch pages from paged
mapped filesystem. one of the performance issues with tss page map
filesystem was it could do the page mapping ... and then individually
page fault each 4k executable page. for "large" executable ... say
half megabyte (128 pages), that could mean 128 4k page faults ... done
serially ... with the serialized page fault latency for each operation
.... say avg. of 30mills service time ... plus any queuing delay
because of other activity ... say four seconds startup delay plus
maybe two-three times that if there was any contention.

native os/360 and cms executable load would "read" up to 64k bytes at
a time in a single operation (assuming contiguous allocation) ...
doing each 64k operation in possibly 40mills compared to the 30mills
for single 4k operation (say 320mills startup delay instead of four
seconds).

so one of my challenges doing the paged mapped support for the cms
filesystem was to retain the benefits of the larger block transfers
(and not fall into one of the tss pits purely waiting for doing single
page fault at a time).

one of the problems then was not locking out other users ... being
able to dynamically adjust the size of block transfers to contention
on the system. later on i was able to demonstrate full-cylinder
transfers (150 pages) on 3380 drives in single block operation.
downside was that locked up the resource for the duration of the
transfer ... potentially impacting other applications.

misc. past posts about paged mapped filesystem changes
http://www.garlic.com/~lynn/subtopic.html#mmap

and misc. past posts about supporting shared protected executables
that the same executable could appear at different virtual addresses
in different virtual address spaces
http://www.garlic.com/~lynn/subtopic.html#adcon

other posts in this thread:
http://www.garlic.com/~lynn/2006s.html#22 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006s.html#26 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006s.html#27 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006s.html#29 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006s.html#39 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006s.html#46 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006s.html#49 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006s.html#54 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006t.html#10 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006t.html#28 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006t.html#30 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006t.html#39 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006u.html#1 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006u.html#2 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006u.html#19 Why so little parallelism?
http://www.garlic.com/~lynn/2006u.html#30 Why so little parallelism?
http://www.garlic.com/~lynn/2006u.html#54 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006u.html#60 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006u.html#61 Why these original FORTRAN quirks?

New attacks on the financial PIN processing

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: New attacks on the financial PIN processing
Newsgroups: sci.crypt
Date: Thu, 23 Nov 2006 09:46:30 -0700

uri writes:

In any case, the interesting sci.crypt results here are the
crypto-cracking part: the Visa/Mastercard standards were specifically
crypto-designed to prevent the plan A attack, but they fail.

minor nit ... it is a visa/mastercard logo on a debit card that is
part of allowing it to be used in pin-less, signature debit mode
("credit card" mode).

if you request a debit card that can used in pin-only mode (and can't
be used in pin-less, signature debit mode), it won't have a
visa/mastercard logo.

The PIN encryption stuff is part of pin-debit mode and not part of the
pin-less signature debit mode.

the PIN encryption stuff ... rather than visa/mastercard specification
(i.e. visa/mastercard specifications aren't technically standards) has
tended to be ansi X9 standards stuff (which may also show up at ISO
level).

somewhat related:
http://www.garlic.com/~lynn/aadsm26.htm#6

other drift discussing signature debit and pin debit
http://www.garlic.com/~lynn/2005u.html#16

misc. past posts in this thread:
http://www.garlic.com/~lynn/2006u.html#40 New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006u.html#42 New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006u.html#43 New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006u.html#47 New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006u.html#48 New attacks on the financial PIN processing

New attacks on the financial PIN processing

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: New attacks on the financial PIN processing
Newsgroups: sci.crypt
Date: Thu, 23 Nov 2006 10:57:48 -0700

re:
http://www.garlic.com/~lynn/2006v.html#1 New attacks on the financial PIN processing

part of the issue was that the x9a10 financial standards working group
in the mid-90s was given the requirement to preserve the integrity of
the financial infrastructure for all retail transactions (that met all
kinds of environments, internet, point-of-sale, face-to-face,
non-face-to-face, etc ... as well as all kinds of retail transactions,
credit, debit, ach, etc).

part of the activity was looking at existing standards, industry
specifications, association specifications ... other protocol related
work going on in the same time ... and investigate the various
associated threats and vulnerabilities ... and what any
countermeasures were being targeted at.

the result was the x9.59 financial standard for all retail payments
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

one of the wide-spread threats/vulnerabilities at the time was
skimming/harvesting of static data that could be used in various kinds
of replay attacks for fraudulent transactions. a major feature of
x9.59 was the elimination of static data.
http://www.garlic.com/~lynn/subintegrity.html#harvest
http://www.garlic.com/~lynn/subintegrity.html#secrets

another was the extreme ambiquity/confusion regarding the account
number in various kinds of transactions. in some kinds of
transactions, skimming/harvesting the account number was sufficient
(static) information for an attacker to perform a fraudulent
transaction. this led to requirements for the account number to be
kept confidential and never be divulged. at the same time, the account
number was the critical piece of information needed in performing a
large number of different business processes ... requiring it to be
readily available. the conflicting requirements led to my comments
about even if the planet was buried under miles of encryption, it
still wouldn't be sufficient to prevent account number leakage.

so another part of the x9.59 was to make it so that the account number
was no longer sufficient for letting an attacker perform a fraudulent
transaction (it didn't do anything about preventing account number
leakage, it just eliminated the risk related to any account number
leakage).

this is slightly related to my past comment about security proportional
to risk
http://www.garlic.com/~lynn/2001h.html#61

and a recent news item concerning insider threats

Banks face growing threat of identity theft from insiders
http://news.com.com/Banks+face+growing+threat+of+identity+theft+from+insiders/2100-1029_3-6137940.html

from above:

Banks are pouring money into building formidable defenses against
computer hackers, but are only just waking up to what may be a bigger
threat--the physical theft of client information by people in the
office.

.... snip ...

also mentioned here
http://www.garlic.com/~lynn/aadsm26.htm#7

it isn't exactly new news ... insiders have always been considered the
major threat ... whether it is physical theft or various kinds of
electronic data breaches and/or security breaches.

misc. past items ...

Study: ID theft usually an inside job
http://www.garlic.com/~lynn/aadsm17.htm#38
Leading Cause of Data Security breaches Are Due to Insiders
http://www.garlic.com/~lynn/aadsm18.htm#49
Bank workers biggest ID theft threat
http://www.garlic.com/~lynn/2005l.html#35
other insider threat
http://www.garlic.com/~lynn/2006p.html#9

Historical question, what went wrong with bubble memory?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Historical question, what went wrong with bubble memory?
Newsgroups: alt.folklore.computers
Date: Thu, 23 Nov 2006 11:04:58 -0700

Walter Bushell <proto@panix.com> writes:

Explain credit card and national debt then please.

well how 'bout this little bit from this thread in sci.crypt
http://www.garlic.com/~lynn/2006v.html#1 New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006v.html#2 New attacks on the financial PIN processing

Historical question, what went wrong with bubble memory?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Historical question, what went wrong with bubble memory?
Newsgroups: alt.folklore.computers
Date: Thu, 23 Nov 2006 11:09:13 -0700

Walter Bushell <proto@panix.com> writes:

Explain credit card and national debt then please.

re:
http://www.garlic.com/~lynn/2006v.html#3 Historical question, what went wrong with bubble memory?

there is also my merged taxonomy and glossary
http://www.garlic.com/~lynn/index.html#glosnote

for financial
http://www.garlic.com/~lynn/financial.htm

and also specifically payments
http://www.garlic.com/~lynn/payment.htm

Why these original FORTRAN quirks?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why these original FORTRAN quirks?
Newsgroups: alt.folklore.computers,comp.lang.fortran
Date: Thu, 23 Nov 2006 11:26:10 -0700

re:
http://www.garlic.com/~lynn/2006v.html#0 Why these original FORTRAN quirks?

for total other link/loader drift ... playing with the (bps) loader
table from the initialization of the cp/67 kernel.

the additional changes mentioned in the email had been done by the
time i had implemented "dumprx" (a vmfdump replacement)
http://www.garlic.com/~lynn/subtopic.html#dumprx


From: wheeler
Date: 12/16/77  09:30:25

I made a number of simple changes to the savecp module in cp/67 and
then redefined the interface to obtain pageable cp core (i.e. a
diagnose that would setup pointers similar to the way dmkvmi is done
at ipl time). When the loader is done, it branches to the last csect
entry loaded or the entry point specified by the 'ldt' card.  At that
time it passes a pointer to the start of the loader tables and the
count of table entries. I modified savecp to move the table to the end
of pageable cp core and save it along with the rest of cp
core. Modifications not yet done: 1) when the cp auto disk dump is
allocated, move the loader table immediately to the dump area so that
it will be available when cp abends. 2) modify vmfdump to recognize
the loader table pages in the dump.
----

When the loader table was moved to CP pageable core, It was sorted by
core address because the loader table is in the same sequence as
appears on the load map (nearly random within modules). Also in the
loader table, the high order byte of the address field contains the
'esd' id, i.e. the id number that appears on the external symbol
dictionary page in a listing.

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

and prevous posts mentioning changes that I did as undergraduate to
cp67 to make portions of kernel "pageable" (which weren't released in
product until vm370) ... which then enabled adding the loader table
entries to the end of the pageable kernel image
http://www.garlic.com/~lynn/94.html#11 REXX
http://www.garlic.com/~lynn/2000b.html#32 20th March 2000
http://www.garlic.com/~lynn/2001b.html#23 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
http://www.garlic.com/~lynn/2001l.html#32 mainframe question
http://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
http://www.garlic.com/~lynn/2002i.html#9 More about SUN and CICS
http://www.garlic.com/~lynn/2002n.html#71 bps loader, was PLX
http://www.garlic.com/~lynn/2002p.html#56 cost of crossing kernel/user boundary
http://www.garlic.com/~lynn/2002p.html#64 cost of crossing kernel/user boundary
http://www.garlic.com/~lynn/2003f.html#3 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#12 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#14 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#20 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#23 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#26 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#30 Alpha performance, why?
http://www.garlic.com/~lynn/2003n.html#45 hung/zombie users ... long boring, wandering story
http://www.garlic.com/~lynn/2004b.html#26 determining memory size
http://www.garlic.com/~lynn/2004f.html#46 Finites State Machine (OT?)
http://www.garlic.com/~lynn/2004g.html#13 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#45 command line switches [Re: [REALLY OT!] Overuse of symbolic constants]
http://www.garlic.com/~lynn/2004o.html#9 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005f.html#10 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005f.html#16 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005f.html#47 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005h.html#10 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005n.html#23 Code density and performance?
http://www.garlic.com/~lynn/2006.html#35 Charging Time
http://www.garlic.com/~lynn/2006.html#40 All Good Things
http://www.garlic.com/~lynn/2006i.html#36 virtual memory
http://www.garlic.com/~lynn/2006j.html#5 virtual memory
http://www.garlic.com/~lynn/2006n.html#11 Not Your Dad's Mainframe: Little Iron
http://www.garlic.com/~lynn/2006n.html#49 Not Your Dad's Mainframe: Little Iron

Reasons for the big paradigm switch

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Reasons for the big paradigm switch
Newsgroups: comp.arch
Date: Thu, 23 Nov 2006 13:25:24 -0700

"jacko" <jackokring@gmail.com> writes:

if the cache needs no TLB then it could be twice as big for the same
area, so L2 cache as main memory would limit to about 2MB at present.
an amiga amount.

do you mean a "virtual cache" ... where cache lines are directly
indexed by virtual address (and some sort of virtual address space id)
...  and in the case of a cache miss, must do a virtual->real
translation (possibly with the aid of a translation lookaside buffer,
TLB)?

recent mention of work on "virtual cache"
http://www.garlic.com/~lynn/2006u.html#37 To RISC or not to RISC

in old iliad email from 20apr83.

for something a little more different, this old post from 2003
http://www.garlic.com/~lynn/2003j.html#42 Flash 10208

includes email from 18nov83 describing sort of a dual-index cache used
for 3090 D-cache. standard tlb gives real address ... but there is
also a "logical directory" ... where the match includes the "STO ID".
STO is for "segment table origin", the real address of the table used
to describe each virtual address space, aka the "STO ID" is used for
doing "STO-associative" (or virtual address space associative)
lookups.

one of the issues in the translation of os/360 into mvs paradigm was
that the kernel and a lot of the system was mapped into every
(application) virtual address space. the result was that the majority
of the addresses ... and therefor the majority of the TLB entries (for
every virtual address space) belonged to the same system resources
(potentially 1/3rd of the virtual addresses were unique application
... but the remaining for each virtual address space was common kernel
and system stuff). as a result, a TLB could become polluted with a
large number of different entries all pointing to the same real
addresses (because they were STO or virtual address space associative,
as opposed to segment or shared object associative).

note that 801 had inverted index .... and so there was no thing as
real table for every virtual address space. 801 went instead to 16
"segment registers" in 32-bit virtual address space; top four bits
from 32-bit indexed one of the segment registers with a 28-bit virtual
(segment) address. in romp/rt, the segment register contained a 12bit
segment identifier. To index the TLB, the 12bit segment identifier
(from the segment register) was combined with the 28-bit virtual
(segment) address. In effect, this was "segment-associative" (as
opposed to STO-associative). A virtual address space would be composed
of (defined by) a combination of 16 different segment identifiers.  It
would be possible to have the same "shared" segment across different
virtual address spaces ... and all virtual addresses in that segment
would map to the same set of TLB entries (segment-associative ... as
opposed to 370 where the same segment virtual addresses in different
virtual address spaces would map to different TLB entries,
i.e. STO-associative). The use of segment-id associative TLB in
801/romp somewhat gave rise to common descriptions from the period of
romp having 40bit virtual addresses (i.e. 12bit segment index plus
28-bit virtual segment address). This continued into some of the later
RIOS/power descriptions claiming 52-bit virtual addresses (since the
size of the segment index had been doubled from 12bits to 24bits).

misc. past posts mentioning sto-associative and/or 801 40bit/52bit
"virtual addresses"
http://www.garlic.com/~lynn/93.html#8 PowerPC Architecture (was: Re: PowerPC priced very low!)
http://www.garlic.com/~lynn/98.html#27 Merced & compilers (was Re: Effect of speed ... )
http://www.garlic.com/~lynn/2000.html#59 Multithreading underlies new development paradigm
http://www.garlic.com/~lynn/2000b.html#54 Multics dual-page-size scheme
http://www.garlic.com/~lynn/2000g.html#25 SSL as model of security
http://www.garlic.com/~lynn/2001c.html#63 SSL weaknesses
http://www.garlic.com/~lynn/2001c.html#84 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2002b.html#29 windows XP and HAL: The CP/M way still works in 2002
http://www.garlic.com/~lynn/2002c.html#40 using >=4GB of memory on a 32-bit processor
http://www.garlic.com/~lynn/2002g.html#17 Black magic in POWER5
http://www.garlic.com/~lynn/2002l.html#60 Handling variable page sizes?
http://www.garlic.com/~lynn/2002m.html#33 simple architecture machine instruction set
http://www.garlic.com/~lynn/2002n.html#10 Coherent TLBs
http://www.garlic.com/~lynn/2003e.html#0 Resolved: There Are No Programs With >32 Bits of Text
http://www.garlic.com/~lynn/2003g.html#13 Page Table - per OS/Process
http://www.garlic.com/~lynn/2003h.html#37 Does PowerPC 970 has Tagged TLBs (Address Space Identifiers)
http://www.garlic.com/~lynn/2003m.html#29 SR 15,15
http://www.garlic.com/~lynn/2004.html#31 Two subjects: 64-bit OS2/eCs, Innotek Products
http://www.garlic.com/~lynn/2004h.html#16 Page coloring required?
http://www.garlic.com/~lynn/2004k.html#27 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2005.html#43 increasing addressable memory via paged memory?
http://www.garlic.com/~lynn/2005d.html#70 Virtual Machine Hardware
http://www.garlic.com/~lynn/2005f.html#7 new Enterprise Architecture online user group
http://www.garlic.com/~lynn/2005h.html#11 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005m.html#48 Code density and performance?
http://www.garlic.com/~lynn/2005r.html#44 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2006e.html#0 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006e.html#5 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006e.html#12 About TLB in lower-level caches

Why these original FORTRAN quirks?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Why these original FORTRAN quirks?
Newsgroups: alt.folklore.computers,comp.lang.fortran
Date: Thu, 23 Nov 2006 13:45:35 -0700

re:
http://www.garlic.com/~lynn/2006u.html#60 Why these original FORTRAN quirks?

another issue regarding "shared segments" ... (i.e. the same executable
showing up in multiple different virtual address spaces) has to do with
pollution of TLB entries (while there is only one shared copy in real
memory) ... whether they are restricted to the same virtual address or
the same virtual object is allowed to appear simultaneously at
different virtual addresses in different virtual address spaces.

recent (long) post in comp.arch touching on the subject
http://www.garlic.com/~lynn/2006v.html#6 Reasons for the big paradigm switch

In Search of Stupidity

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: In Search of Stupidity
Newsgroups: alt.folklore.computers
Date: Thu, 23 Nov 2006 14:08:51 -0700

In Search of Stupidity; Over Twenty Years of High Tech Marketing Disasters
http://books.slashdot.org/books/06/11/22/1423216.shtml

from above:

"In Search of Stupidity gets its title from the classic, albeit
infamous business book In Search of Excellence: Lessons from America's
Best-Run Companies, by Tom Peters and Robert Waterman. In Search of
Excellence quickly became a best-seller when it came out in 1988 and
launched a new era of management consultants and business books. But
in 2001, Peters admitted that he falsified the underlying
data. Librarians have been slow to move the book to the fiction
section."

... snip ...

Note that one of the companies covered in "In Search of Excellence"
went into the red four years later in 1992.

only slightly related:
http://www.garlic.com/~lynn/2005j.html#32 IBM Plugs Big Iron to the College Crowd
http://www.garlic.com/~lynn/2006b.html#31 Seeking Info on XDS Sigma 7 APL
http://www.garlic.com/~lynn/2006r.html#20 50th Anniversary of invention of disk drives

In Search of Stupidity

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: In Search of Stupidity
Newsgroups: alt.folklore.computers
Date: Fri, 24 Nov 2006 09:31:12 -0700

jmfbahciv writes:

I had not heard about Peters admitting this.  Is it true?
That would explain the nonsense.  One of his texts were dumped
at the dump and I picked it up thinking I could learn something.
It was a very expensive text book  *text***book***, that
consisted of nothing but copies of some set of his seminar
slides.  They were the same set printed repeatedly in the
book.  And i'll bet there were professors who required this
text in their classes and taught it with seriousness.

re:
http://www.garlic.com/~lynn/2006v.html#8 In Search of Stupidity

Tom Peter's True Confessions (issue 53, nov2001)
http://www.fastcompany.com/magazine/53/peters.html

from above:

Confession number three: This is pretty small beer, but for what it's
worth, okay, I confess: We faked the data. A lot of people suggested
it at the time.

... snip ...

What's a mainframe?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What's a mainframe?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 24 Nov 2006 12:46:34 -0700

some of client/server activity from the later half of the 80s and thru
the 90s were

1) much faster and agile deployments for new applications on
client/server than mainframe

2) moving system support to individual users, downsizing the
datacenter and drastically cutting it as separate business expense
item (which may have been false economy).

downside of attempting to replace some number of the existing business
applications was that datacenters and mainframes had a lot of business
critical dataprocessing support that was totally lacking in the
client/server environment (including little high availability culture
and/or pro-active handling of possible failure modes). some drift
on our ha/cmp product
http://www.garlic.com/~lynn/subtopic.html#hacmp

some collected 3-tier postings
http://www.garlic.com/~lynn/subnetwork.html#3tier

... we were calling our 3-tier marketing pitch middle layer


From: wheeler
Date: Fri, 19 May 89 13:31:31 CDT
Subject: middle layer for <gov. TLA>

I just talked was talking to XXXXX (<gov. TLA> account). <gov. TLA> is
projected to release an RFP around year end for about $500m worth of
middle layer hardware and software. Their middle layer (management,
servers, backup/restore, archive, administration, etc) specifications
matches up pretty much with our middle layer pitch (as well as what
other marketing people have been telling us as being representitive
requirements for distributed environment next year).

XXXXX also said that YYYYY was in to talk to <gov. TLA> last week ...
as well as the customer having gone up to see Project Athena last
week. <gov. TLA> was impressed with the system managment stuff that
Project Athena has done. (I told XXXXX that I would send him a
softcopy of the trip report/review (SJA025) did may of '88 on what
they have ...  including the SMS stuff (making the distinction that
this was SYSTEM MANAGEMENT ... as opposed to the configuration
management being done for AIX work stations). Much of the (Project
Athena) SMS implementation was done by ZZZZZ ... who is now over at
**** fulltime working on ****).

I related to XXXXX the sad story the **** interference with our
dealing with **** ... and he said that if bringing his customer into
the discussions would help ... he would be more than happy.

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


From wheeler
Date: Thu, 15 Jun 89 19:28:52 CDT
Subject: rios fileserver, array disks, hsc, UCB, etc.

Hardware had a meeting with ***** today to discuss HSC. Hardware
engineering is going up to ***** next tuesday to talk to them about
HSC.  It is beginning to look like full steam ahead with
HSC. Currently I'm scheduled to be up in ***** with the engineers on
Tuesday and then at GM hdqtrs on Weds (to give the middle layer
pitch). If things go ok, I'll be in San Jose on Thursday and Friday
(22, 23). Depending on how things go we could get together then.

*****'s pitch covered their product, some of what they are doing with
Kingston 3090/ES and little on some of the other stuff ... like
DataTree support of *****, 3090 software diskstripping, HSC
framebuffer.

***** offered design tools and PAL logic (for HSC) to Austin (claims
to cut design time from 9-12 months down to 3 months or less)

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

HSC ... high-speed channel, turned into HiPPI ...

a few posts (including misc old email) touching on early evolution of 3-tier
http://www.garlic.com/~lynn/2006p.html#31 "25th Anniversary of the Personal Computer"
http://www.garlic.com/~lynn/2006p.html#36 "25th Anniversary of the Personal Computer"
http://www.garlic.com/~lynn/2006p.html#40 "25th Anniversary of the Personal Computer"

a couple recent posts mentioning DataTree (unitree, nastore, and/or mesa)
http://www.garlic.com/~lynn/2006n.html#29 CRAM, DataCell, and 3850
http://www.garlic.com/~lynn/2006u.html#19 Why so little parallelism?
http://www.garlic.com/~lynn/2006u.html#20 Why so little parallelism?
http://www.garlic.com/~lynn/2006u.html#27 Why so little parallelism?

older post on early 2-tier ... with the proliferation of distributed
43xx machines outside of the datacenter ... predating client/server
2-tier ... the combination of the two 2-tiers then evolved into 3-tier
http://www.garlic.com/~lynn/2001m.html#15 departmental servers

however, one of the inhibiting/limiting factors for distributed 43xx
started to be availability of skills and resources to support them.

and as stated numerous times before ... in this later period, there
was the SAA corporate strategy which has been somewhat characterized
as trying to crame the (2-tier) client/server genie back into the
bottle (and we were taking heat for doing customer executive
presentations on middle layer).
http://www.garlic.com/~lynn/2006u.html#55 What's a mainframe?

and some recent, slightly related drift
http://www.garlic.com/~lynn/2006v.html#8 In Search of Stupidity
http://www.garlic.com/~lynn/2006v.html#9 In Search of Stupidity

for other drift from above mention of Project Athena, Kerberos was a
Project Athena project ... collected past posts mentioning Kerberos
http://www.garlic.com/~lynn/subpubkey.html#kerberos

What's a mainframe?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What's a mainframe?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 24 Nov 2006 21:32:42 -0700

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

a few posts (including misc old email) touching on early evolution of 3-tier
http://www.garlic.com/~lynn/2006p.html#31 "25th Anniversary of the Personal Computer"
http://www.garlic.com/~lynn/2006p.html#36 "25th Anniversary of the Personal Computer"
http://www.garlic.com/~lynn/2006p.html#40 "25th Anniversary of the Personal Computer"

older post on early 2-tier ... with the proliferation of distributed
43xx machines outside of the datacenter ... predating client/server
2-tier ... the combination of the two 2-tiers then evolved into 3-tier
http://www.garlic.com/~lynn/2001m.html#15 departmental servers

re:
http://www.garlic.com/~lynn/2006v.html#10 What's a mainframe?

so somewhat leading edge of distributed 43xx


From: wheeler
Date: 03/26/79  08:44:36

One of the biggest questions raised at SHARE was that a whole lot is
not being done yet about centralized maintenance. One of the 'smaller'
VM installations is ordering 1 4341 & 8 4331s.  They are planning on
doing all maintenance from the 4341 (and have not even ordered tape
drives for the 4331s) using the network. The price of the 4300s are
down in the range where large installations are talking about 50 to
100 CPUs. What are we going to be offering allow somebody to run 100
cpus? Possibility exists that 4331s will be going into places that
currently run 2780s or even just a dial-up terminal.

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

of course, a little later you found large installations ordering
several hundred 4341s.

later there was something about VMS systems requiring only 1/3rd the
effort of 43xx systems.

Steve Chen Making China's Supercomputer Grid

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Steve Chen Making China's Supercomputer Grid
Newsgroups: alt.folklore.computers
Date: Sat, 25 Nov 2006 10:01:58 -0700

Steve Chen Making China's Supercomputer Grid
http://science.slashdot.org/science/06/11/25/1429208.shtml

"The THIRD-BRAIN: The Next Generation of Supercomputer Design Beyond
PetaFlop/s" - an interview with Steve Chen
http://www.hoise.com/primeur/06/articles/weekly/AE-PR-09-06-1.html

a couple mildly related posts
http://www.garlic.com/~lynn/2006q.html#9 Is no one reading the article?
http://www.garlic.com/~lynn/2006t.html#32 The Future of CPUs: What's After Multi-Core?

one of the above include a couple other old news references:
http://www.taipeitimes.com/News/biz/archives/2004/11/08/2003210211
http://www.ahaventures.net/index.php?option=com_content&task=view&id=17&Itemid=32

In Search of Stupidity

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: In Search of Stupidity
Newsgroups: alt.folklore.computers
Date: Sat, 25 Nov 2006 10:28:52 -0700

jmfbahciv writes:

How do you verify that the latter wasn't a lie?

re:
http://www.garlic.com/~lynn/2006v.html#8 In Search of Stupidity
http://www.garlic.com/~lynn/2006v.html#9 In Search of Stupidity

alls sorts of stuff could be lies ... the issue is if it is public
enuf and there appears to be no refutation ... then there is some
degree of confidence to take it at face value (for instance on what
does anybody base any belief that the original book did not lie?)

the previous post just had reference to the actual interview ... but
using search engine to find that reference ... some large number of
other (public) references to the same interview came up ...
http://www.businessweek.com/magazine/content/01_49/b3760040.htm

is this tom peters real web page?
http://www.tompeters.com/

it also makes reference to the 2001 interview with fast company
where he describes what he (really) met.

In Search of Stupidity

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: In Search of Stupidity
Newsgroups: alt.folklore.computers
Date: Sat, 25 Nov 2006 12:35:39 -0700

greymaus writes:

Terms:
Diversify
Core Market
Organic Growth
New and Innovative methods

re:
http://www.garlic.com/~lynn/2006v.html#8 In Search of Stupidity
http://www.garlic.com/~lynn/2006v.html#9 In Search of Stupidity
http://www.garlic.com/~lynn/2006v.html#13 In Search of Stupidity

recent post mentioning abouut being fast and agile
http://www.garlic.com/~lynn/2006v.html#10 What's a mainframe

a very Boyd "thing"
http://www.garlic.com/~lynn/subboyd.html#boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2

part of the issue is having significant market position can
result in spending more time protecting what you have than
remaining agile and adaptible (has some number of analogies
in boyd's maneuver warfare)

one of my periodic comments about SAA ... opposing our 3-tier efforts
http://www.garlic.com/~lynn/subnetwork.html#3tier

and return-to/control terminal emulation market
http://www.garlic.com/~lynn/subnetwork.html#emulation

besides comments about automobile industry and related c4 activity
http://www.garlic.com/~lynn/2000f.html#41 Reason Japanese cars are assembled in the US (was Re: American bigotry)
http://www.garlic.com/~lynn/2000f.html#43 Reason Japanese cars are assembled in the US (was Re: American bigotry)
http://www.garlic.com/~lynn/2001d.html#43 Economic Factors on Automation
http://www.garlic.com/~lynn/2002d.html#7 IBM Mainframe at home
http://www.garlic.com/~lynn/2002p.html#27 Secure you PC or get kicked off the net?
http://www.garlic.com/~lynn/2003i.html#61 TGV in the USA?
http://www.garlic.com/~lynn/2004b.html#52 The SOB that helped IT jobs move to India is dead!
http://www.garlic.com/~lynn/2004c.html#51 [OT] Lockheed puts F-16 manuals online
http://www.garlic.com/~lynn/2004c.html#54 [OT] Lockheed puts F-16 manuals online
http://www.garlic.com/~lynn/2004h.html#22 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2005g.html#7 Where should the type information be?
http://www.garlic.com/~lynn/2005s.html#2 Internet today -- what's left for hobbiests
http://www.garlic.com/~lynn/2005t.html#29 AMD to leave x86 behind?
http://www.garlic.com/~lynn/2006.html#23 auto industry
http://www.garlic.com/~lynn/2006.html#43 Sprint backs out of IBM outsourcing deal
http://www.garlic.com/~lynn/2006.html#44 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006g.html#14 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#17 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#20 The Pankian Metaphor
http://www.garlic.com/~lynn/2006m.html#49 The Pankian Metaphor (redux)

i've also strayed into making comments about the add-on, after-market
security market ... which should be a temporary blip ... since
security/integrity really needs to be "built in" and part of the basic
infrastructure ... not an after-market item.
http://www.garlic.com/~lynn/aadsm17.htm#56 Question on the state of the security industry
http://www.garlic.com/~lynn/aadsm21.htm#16 PKI too confusing to prevent phishing, part 28
http://www.garlic.com/~lynn/2001j.html#42 Big black helicopters
http://www.garlic.com/~lynn/2001k.html#7 hot chips and nuclear reactors
http://www.garlic.com/~lynn/2002h.html#39 Oh, here's an interesting paper
http://www.garlic.com/~lynn/2004q.html#17 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005d.html#42 Thou shalt have no other gods before the ANSI C standard
http://www.garlic.com/~lynn/2005s.html#2 Internet today -- what's left for hobbiests

and for some real topic drift:
http://www.garlic.com/~lynn/aadsm26.htm#9 Who has a Core Competency in Security?
http://www.garlic.com/~lynn/aadsm26.htm#10 Who has a Core Competency in Security?

The Incredible Shrinking Cosmonaut Corps

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: The Incredible Shrinking Cosmonaut Corps
Newsgroups: alt.folklore.computers
Date: Sat, 25 Nov 2006 13:25:56 -0700

The Incredible Shrinking Cosmonaut Corps
http://science.slashdot.org/science/06/11/25/1517227.shtml

slightly related
http://www.garlic.com/~lynn/2006r.html#48 cold war again

does anybody remember "Elvis+"? from the mid-90s .... the president
of the company had something to do with ISS design/operation
... minor references here
http://jya.com/hir-hear.htm
http://www.jya.com/cryptover.htm

Ranking of non-IBM mainframe builders?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Ranking of non-IBM mainframe builders?
Newsgroups: alt.folklore.computers
Date: Sat, 25 Nov 2006 16:08:19 -0700

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

I've told some stories in the past about being involved in some
problems with 3880 disk controller prior to first customer ship
... which were different than the problem referred to regarding the
3380 disk drives.

re:
http://www.garlic.com/~lynn/2006s.html#42 Ranking of non-IBM mainframe builders?

The attached is discussion of the original vm370 alternate
channel/path support before I rewrote it as part of kernel changes
that I did to i/o support for the disk engineering and product test
labs
http://www.garlic.com/~lynn/subtopic.html#disk

an approach (for alternate path) was path load balancing (by keeping
track of cummulative activity by path that i implemented in i/os
rewrite)

One of the later problems was with the introduction of the 3880 disk
controller and its exorbitant controller overhead including when
having to switch channel paths involving processing requests on
different channel paths (on the order of milliseconds) ... aka path
load balancing could actually be slower with 3880 disk controller than
trying to maintain strict path affinity.


From: wheeler
Date: 03/29/78  09:40:33

AUSE is now coming out with all string switched DASD on channel 2.  In
our RIO we have devices 240-247 gen'ed on control unit 240 and
alternate 340. Devices 350-357 are gen'Ed on control unit 340 and
alternate 240. We did this because the alternate path implementation
is not very good.  It would probably be a lot more trouble to get the
RDEVBLOKs to come out on the primary path, instead of the 1st path
found.

the alternate path code is only tried if the busy bit is on in the
RCHBLOK. Since we are running block MPX channels, CP almost never sets
the busy bit on. To get the channel balance we have to play with the
RIO gen to get it to come out right. It would be nice if IOS was
changed such that it would try the alternate path in more cases. For
instance if it got channel busy condition back on the SIO.

       Lynn

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

Ranking of non-IBM mainframe builders?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Ranking of non-IBM mainframe builders?
Newsgroups: alt.folklore.computers
Date: Sun, 26 Nov 2006 09:35:57 -0700

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

One of the later problems was with the introduction of the 3880 disk
controller and its exorbitant controller overhead including when
having to switch channel paths involving processing requests on
different channel paths (on the order of milliseconds) ... aka path
load balancing could actually be slower with 3880 disk controller than
trying to maintain strict path affinity.

re:
http://www.garlic.com/~lynn/2006v.html#16 Ranking of non-IBM mainframe builders?

and even more 3880 disk controller historical reference

JIB' was the (vertical microcode) chip used in the 3880. A combination
of hardware dedicated datapath and JIB' replaced the (faster)
horizontal microcode engine used in the 3830 disk controller.

part of one of my hobby activities over in disk engineering and product
test labs
http://www.garlic.com/~lynn/subtopic.html#disk

old post about Shugart inventing diskette (floppies) for microprogram
loads for 3830 disk controller.
http://www.garlic.com/~lynn/2004.html#5 The BASIC Variations

old email from 28jan81, when they eventually got MDB/MDS moved to CMS
http://www.garlic.com/~lynn/2006p.html#40 25th Anniversary of the Personal Computer


From: wheeler
Date: 10/10/79  13:19:55

Do you have or know about a JIB PRIME translator ?? The 3880 engineers
are currently using something from STL/MVS which is very large and
awkward.

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


To: wheeler
Date: 10/10/79  13:29:16

What would you like to know?  We are writing code for the JIB' here
using EDX, PASCAL, and JIB' assembler.

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


From: wheeler
Date: 10/10/79  13:43:51

one of the engineers that support the 3880 may be getting in touch
with you. They currently use a very large program which runs on MVS to
generate JIB' code which is sent over three or four network nodes to a
floppy writer. They then get the new floppy and test out the new 3880
control unit code. There are currently in the process of modifying one
of the in house 3880s to write (as well as read) a floppy. They are
interested finding something much simpler that the MVS program they
currently have to generate the code tho.  The MVS program apparently
runs to several hundred text decks and is a generalized translator
which after 3-4 weeks of effort appears impossible to move to CMS (it
would be easier to write a translator from scratch than to get MDB to
move from MVS to CMS -- STL has a group of 10-15 people supporting the
program).

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

misc. past 3880 references:
http://www.garlic.com/~lynn/2006.html#4 Average Seek times are pretty confusing
http://www.garlic.com/~lynn/2006c.html#6 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006c.html#8 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006c.html#9 Mainframe Jobs Going Away
http://www.garlic.com/~lynn/2006c.html#46 Hercules 3.04 announcement
http://www.garlic.com/~lynn/2006e.html#45 using 3390 mod-9s
http://www.garlic.com/~lynn/2006e.html#46 using 3390 mod-9s
http://www.garlic.com/~lynn/2006g.html#0 IBM 3380 and 3880 maintenance docs needed
http://www.garlic.com/~lynn/2006i.html#12 Mainframe near history (IBM 3380 and 3880 docs)
http://www.garlic.com/~lynn/2006i.html#41 virtual memory
http://www.garlic.com/~lynn/2006j.html#11 The Pankian Metaphor
http://www.garlic.com/~lynn/2006j.html#14 virtual memory
http://www.garlic.com/~lynn/2006o.html#44 When Does Folklore Begin???
http://www.garlic.com/~lynn/2006q.html#50 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006r.html#23 50th Anniversary of invention of disk drives
http://www.garlic.com/~lynn/2006r.html#36 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006r.html#40 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006s.html#32 Why magnetic drums was/are worse than disks ?
http://www.garlic.com/~lynn/2006s.html#33 Why magnetic drums was/are worse than disks ?
http://www.garlic.com/~lynn/2006s.html#42 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006s.html#43 Ranking of non-IBM mainframe builders?

The Incredible Shrinking Cosmonaut Corps

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Incredible Shrinking Cosmonaut Corps
Newsgroups: alt.folklore.computers
Date: Sun, 26 Nov 2006 11:24:42 -0700

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

The Incredible Shrinking Cosmonaut Corps
http://science.slashdot.org/science/06/11/25/1517227.shtml

slightly related
http://www.garlic.com/~lynn/2006r.html#48 cold war again

does anybody remember "Elvis+"? from the mid-90s .... the president
of the company had something to do with ISS design/operation
... minor references here
http://jya.com/hir-hear.htm
http://www.jya.com/cryptover.htm

re:
http://www.garlic.com/~lynn/2006v.html#15 The Incredible Shrinking Cosmonaut Corps

and now for something completely different ...


From: wheeler
Date: 06/24/1997 08:41 AM

spent a couple hrs yesterday with pres/ceo of elvis+ (you may have
seen some news in relationship to sun and cryptography). he had been
head of space station technologies in the 80s ... but left to form his
own company in 91.

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

and another reference:
http://www.rcrinc.com/
and here
http://www.rcrinc.com/security.html

and for recent somewhat crypto topic drift
https://financialcryptography.com/mt/archives/000839.html What is the point of encrypting information that is publicly visible?
http://www.garlic.com/~lynn/aadsm26.htm#8 What is the point of encrypting information that is publicly visible?
http://www.garlic.com/~lynn/aadsm26.htm#11 What is the point of encrypting information that is publicly visible?
https://financialcryptography.com/mt/archives/000840.html Who has a Core Competency in Security?
http://www.garlic.com/~lynn/aadsm26.htm#9 Who has a Core Competency in Security?
http://www.garlic.com/~lynn/aadsm26.htm#10 Who has a Core Competency in Security?

Ranking of non-IBM mainframe builders?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Ranking of non-IBM mainframe builders?
Newsgroups: alt.folklore.computers
Date: Mon, 27 Nov 2006 08:51:22 -0700

re:
http://www.garlic.com/~lynn/2006p.html#40 25th Anniversary of the Personal Computer
http://www.garlic.com/~lynn/2006v.html#17 Ranking of non-IBM mainframe builders?

some internal politics along the way about moving to lots of
distributed 4341 vm systems (last sentence, 1st paragraph).

"graphic attachment" (3277ga) is a large rebranded tektronic display
that hooks into the side of a 3277 terminal. basically there is
"escape" to direct data to tektronic display (rather than 3277
display).  this is higher level protocol sitting on top of normal 3277
driver so buffer write size is limited to standard 3277 screen size
(sometimes resulting in multiple 3277 buffer writes to paint a
tecktronic display).

side note that it was considered severe bug if VM's "capture rate"
dropped below 98-99 percent.


From: wheeler
Date: 07/17/80  14:51:37

re: MDS meeting this morning from 8:30 until 1:00; GPD has three or
four large engineering application programs (including MDS & MDS like)
which run on one or two large 168 MVS systems in building 26. They are
looking at moving the applications as much as possible out into
satellite CPUs to increase availability and reliability. There is also
the problem currently with limited CPU resources to adequantly support
the demand (w/o even consideration for future growth). Going to a
distributed CPU design goes a long way to eliminating that bottleneck.
The current target CPU is 4341s and if the target SCP is not MVS then
GPD vice presidents better be presented with a super good reason.

There was a couple of presentations by building 26, MVS accounting.
They were showing all the accounting information break down and
various system component overhead. Some very surprising things started
to come out (for some in the audience). There was a little number
associated with each line called capture ratio. It turns out that the
MDS group was trying to predict the load that their application would
have on a 4341 with MVS. Somewhere in the meeting it came out that
capture ratio (it runs around 40-50%) was the amount of time that
could be accounted for (i.e. unaccounted time is 50-60%, aka a lot MVS
processing isn't being captured). The capture ratio can only be
estimated for the overall system and it turns out that it varies by
type of work done (i.e. APL/SV system which has been worked over and
over to use as little as possible of MVS has a capture ratio of
82%). The MDS people were somewhat suprised to learn that they were
underestimating their processor requirements by a factor of two.

There was a presentation by the LDL people from Los Gatos about what
they had to do to convert it from MVS to VM. LDL appears to be
somewhat the same order of magniture as MDS. The Los Gatos
presentation came off extremely biased from the MVS point of view. Los
Gatos wrote about 12k (bytes) of code to supplement the standard CMS
O/S simulation. They claim that not only is LDL running better and
faster but they have been able to make significant enhancements that
were not possible in the MVS environemnt.  MDS runs something like 40K
lines of code and it appears that the supplements to CMS O/S
simulation that are required to support it is much less than normal
change activity in the MDS system.

Another item that came out of the building 26 numbers was VTAM (which
goes back again to capture ratios). The VTAM 'overhead' was showing up
as <4% of the machine. The MDS application uses graphic attachment
and typically transmits 3-6 2k buffers per screen. VTAM proudly claim
that under ideal conditions their best (fast path) path length is 10k
instructions per I/O. Under ideal circumstances then VTAM is able to
drive 300 i/os per second with a 'dedicated' 168. 150 VTAM i/os might
be more realistic estimate tho if you could get a 168 cpu that was
just dedicated to VTAM.  That is cut by at least a factor of 3-4 when
going to a 4341, or VTAM would require 100% of a 4341 to perform 40
I/Os per second (optimal fastpath, leaving nothing for anybody
else). Or to fill one screen in one second with 6 buffers, VTAM (all
by itself) would require at least 15% of a 4341.  The JES2 comparisons
indicated similar numbers. My guess is that (1) MVS can't support more
than a couple MDS users on a 4341 and (2) the decision is mostly
politics, i.e. a lot of top management still believe that MVS is the
only strategic SCP and VM isn't.

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

a few past posts mentioning 3277ga:
http://www.garlic.com/~lynn/2000e.html#53 Why not an IBM zSeries workstation?
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/2001i.html#51 DARPA was: Short Watson Biography
http://www.garlic.com/~lynn/2002p.html#29 Vector display systems
http://www.garlic.com/~lynn/2004l.html#27 Shipwrecks
http://www.garlic.com/~lynn/2004l.html#32 Shipwrecks
http://www.garlic.com/~lynn/2004m.html#8 Whatever happened to IBM's VM PC software?
http://www.garlic.com/~lynn/2006e.html#9 terminals was: Caller ID "spoofing"
http://www.garlic.com/~lynn/2006e.html#28 MCTS
http://www.garlic.com/~lynn/2006n.html#24 sorting was: The System/360 Model 20 Wasn't As Bad As All That
http://www.garlic.com/~lynn/2006q.html#16 what's the difference between LF(Line Fee) and NL (New line) ?

Ranking of non-IBM mainframe builders?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Ranking of non-IBM mainframe builders?
Newsgroups: alt.folklore.computers
Date: Mon, 27 Nov 2006 12:06:23 -0700

Peter Flass <Peter_Flass@Yahoo.com> writes:

You've said this before about other products (3274s come to mind).
IBM seems to have had a habit of doing this, presumably because of
cost.  No wonder they ran into trouble!

part of the issue is that horizontal microcode engines were
"difficult" to program. the transition from 3830 to 3880 as adding
significant feature/function to the controller ... which would have
been all but impossible to have succeeded with programming for a
horizontal microcode engine.

an analogous situation showed up in 5880/3090 scenario ... where
amdahl introduced hypervisor on 5880 by implementing in "macrocode"
... while 3090 struggled to do all implementations in horizontal
microcode.

the 3880 issue was somewhat getting the kinks out of the transition.
http://www.garlic.com/~lynn/2006v.html#16 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006v.html#17 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006v.html#19 Ranking of non-IBM mainframe builders?

the 3274 was much more of a manufacturing cost issue ... much of the
electronics that had been in the 3277 terminal ... was moved back into
the 3274 controller (shared resource across all the terminals). this
significantly reduced the cost/complexity/etc of the newer generation
of 327x terminals.

as disk controllers complexity continued to increase the transition to
vertical microcode engine somewhat helped ... but they were still
being done with software tools that were much more primitive than
standard operating system development. complexity became one of the
issues in the early 90s with seastar controller development ...
which was spec'ed to have a great deal of complexity.

misc. past posts mentioning seastar
http://www.garlic.com/~lynn/2004o.html#30 z/OS UNIX
http://www.garlic.com/~lynn/2006d.html#3 Hercules 3.04 announcement
http://www.garlic.com/~lynn/2006d.html#15 Hercules 3.04 announcement
http://www.garlic.com/~lynn/2006n.html#29 CRAM, DataCell, and 3850

in theory, this was one of the things that "fort knox" was supposed
to address ... rather than all the controllers & other embedded functions
having to start from scratch every time ... they could build on top
of much more general purpose platform ... recent thread
http://www.garlic.com/~lynn/2006u.html#29 To RISC or not to RISC
http://www.garlic.com/~lynn/2006u.html#31 To RISC or not to RISC
http://www.garlic.com/~lynn/2006u.html#32 To RISC or not to RISC
http://www.garlic.com/~lynn/2006u.html#37 To RISC or not to RISC
http://www.garlic.com/~lynn/2006u.html#38 To RISC or not to RISC

another example ... was that in some ways ... the whole VTAM/NCP
complex interface was supposed to significantly raise the bar for
competitors.  I've posted before about having been involved as
undergraduate in building our own terminal controller clone on
interdata platform ... and subsequent article blaming four of
us for the clone "problem"
http://www.garlic.com/~lynn/subtopic.html#360pcm

the "clone" problem supposedly was one of the major motivations
for the (failed) future system effort
http://www.garlic.com/~lynn/subtopic.html#futuresys

in the mid-80s, function being added to 37xx/ncp was getting quite
complex. ncp had started off with an extremely primitive, low-level
monitor ... and as a result, every application running in the 37xx had
to re-invent and implement a large number of their own services (would
would otherwise typically be provided as standard operating system
services). this significantly increased the skill level, the amount of
resources and the development time to deploy anything new.

i got involved in the mid-80s at looking at taking a NCP emulator that
had been done in higher level language with significantly more
function and shipping it as a product on RIOS (rs/6000) platform. it
was built on a kernel with much more sophisticated function
... drastically reducing the effort that would go into building
individual feature/function. it also had native peer-to-peer
networking ... so any SNA stuff was encapsulated in peer-to-peer
support at the boundary emulation.

misc. past post discussing the effort
http://www.garlic.com/~lynn/99.html#63 System/1 ?
http://www.garlic.com/~lynn/99.html#66 System/1 ?
http://www.garlic.com/~lynn/99.html#67 System/1 ?
http://www.garlic.com/~lynn/99.html#70 Series/1 as NCP (was: Re: System/1 ?)
http://www.garlic.com/~lynn/2001.html#4 First video terminal?

the result was that the effort required less than 1/10th of the
37xx/ncp organization while providing possibly ten times the
functionality (in large part because of the combination of reduced
feature/function complexity because of the availability of much more
sophisticated kernel services ... and native peer-to-peer
networking). a few recent posts mentioning some peer-to-peer:
http://www.garlic.com/~lynn/2006u.html#28 Assembler question
http://www.garlic.com/~lynn/2006u.html#30 Why so little parallelism?
http://www.garlic.com/~lynn/2006u.html#55 What's a mainframe?

The "rios" effort would have moved the implementation off series/1
giving possibly a ten times cost/performance boost (and sort of a
implementation that met the original "fort knox" objectives).
http://www.garlic.com/~lynn/subtopic.html#801

misc. past posts mentioning 5880 and/or macrocode
http://www.garlic.com/~lynn/99.html#190 Merced Processor Support at it again
http://www.garlic.com/~lynn/2002n.html#58 IBM S/370-168, 195, and 3033
http://www.garlic.com/~lynn/2002p.html#44 Linux paging
http://www.garlic.com/~lynn/2002p.html#48 Linux paging
http://www.garlic.com/~lynn/2003.html#9 Mainframe System Programmer/Administrator market demand?
http://www.garlic.com/~lynn/2003.html#56 Wild hardware idea
http://www.garlic.com/~lynn/2004c.html#6 If the x86 ISA could be redone
http://www.garlic.com/~lynn/2005d.html#59 Misuse of word "microcode"
http://www.garlic.com/~lynn/2005d.html#60 Misuse of word "microcode"
http://www.garlic.com/~lynn/2005h.html#24 Description of a new old-fashioned programming language
http://www.garlic.com/~lynn/2005p.html#14 Multicores
http://www.garlic.com/~lynn/2005p.html#29 Documentation for the New Instructions for the z9 Processor
http://www.garlic.com/~lynn/2005u.html#40 POWER6 on zSeries?
http://www.garlic.com/~lynn/2005u.html#43 POWER6 on zSeries?
http://www.garlic.com/~lynn/2005u.html#48 POWER6 on zSeries?
http://www.garlic.com/~lynn/2006b.html#38 blast from the past ... macrocode
http://www.garlic.com/~lynn/2006c.html#7 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006c.html#9 Mainframe Jobs Going Away
http://www.garlic.com/~lynn/2006c.html#24 Harvard Vs  Von Neumann architecture
http://www.garlic.com/~lynn/2006c.html#40 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006e.html#15 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006h.html#30 The Pankian Metaphor
http://www.garlic.com/~lynn/2006j.html#32 Code density and performance?
http://www.garlic.com/~lynn/2006j.html#35 Code density and performance?
http://www.garlic.com/~lynn/2006m.html#39 Using different storage key's
http://www.garlic.com/~lynn/2006p.html#42 old hypervisor email
http://www.garlic.com/~lynn/2006t.html#14 32 or even 64 registers for x86-64?
http://www.garlic.com/~lynn/2006u.html#27 Why so little parallelism?
http://www.garlic.com/~lynn/2006u.html#33 Assembler question
http://www.garlic.com/~lynn/2006u.html#34 Assembler question

The Future of CPUs: What's After Multi-Core?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Future of CPUs: What's After Multi-Core?
Newsgroups: alt.folklore.computers
Date: Mon, 27 Nov 2006 12:49:28 -0700

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

The Future of CPUs: What's After Multi-Core?
http://www.informit.com/articles/article.asp?p=663085&rl=1

from above (the new, 40yr old thing)

This rule was driven home to me when I attended a talk by an IBM
engineer about his company's new virtualization technology. He
commented that his company had an advantage over other people working
in the area: Whenever they were stuck, they could go along the hall to
the mainframe division and ask how they solved the same problem a
couple of decades ago.

... snip ...

semi-related thread from comp.arch
http://www.garlic.com/~lynn/2006t.html#23 threads versus task

re:
http://www.garlic.com/~lynn/2006t.html#27 The Future of CPUs: What's After Multi-Core?

... and the prospects for parallel-processing on the desktop? .... 20
plus years ago:

Date: 30 Jan 86 15:16:34 PST (Thursday)
Subject: Xerox PARC Forum Tuesday, Feb 11, Bill Joy: "Computer Workstation Architecture: 1982-1992"
From: Kluger.osbunorth@xerox.com
To: ArpaColloquiums^.PA@xerox.com
cc: sun!blyon@ucbvax.berkeley.edu, Kluger.osbunorth@xerox.com

          Xerox Palo Alto Research Center Forum

                Tuesday, February 11, 1986
                2:00 pm, PARC Auditorium

                        Bill Joy

         Vice President of Research and Development
                     Sun Microsystems

                      will speak on

       Computer Workstation Architecture: 1982-1992

The talk will center on the architecture of computer workstations.  We
have over a decade of experience with personal workstations, starting
with the Alto and the Dorado at Xerox. Over the last four years,
workstations have come into widespread commercial use driven by the
32-bit micros, driven largely by the Motorola 680x0 family.

The presentation will look at the architecture of workstations and the
supporting network environment, and speculate forward to 1992.
Questions to be addressed include the structure of a distributed
software environment, resource sharing among heterogeneous machines, the
impact of RISC technology, support for AI languages, and the prospects
for parallel-processing on the desktop.

... snip ...

other posts in the thread ...
http://www.garlic.com/~lynn/2006t.html#31 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006t.html#32 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006t.html#34 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006t.html#36 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006t.html#41 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006t.html#42 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006t.html#43 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006t.html#49 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006t.html#50 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006u.html#0 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006u.html#6 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006u.html#7 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006u.html#8 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006u.html#9 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006u.html#10 The Future of CPUs: What's After Multi-Core?

vmshare

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: vmshare
Newsgroups: alt.folklore.computers
Date: Tue, 28 Nov 2006 07:38:24 -0700

series of email about getting setting process to mirror VMSHARE
computer conferencing files from Tymshare. In addition to getting
process for mirroring VMSHARE files ... also talked to them about some
number of other things (like augment).

Tymshare was one of the vm-based commercial timesharing services
http://www.garlic.com/~lynn/subtopic.html#timeshare

Current repository of VMSHARE Archives:
http://vm.marist.edu/~vmshare/

The following email mentions getting legal approval to have a Tymshare
VMSHARE userid (in addition to getting the process to be regularly
shipped copies of all the VMSHARE files).


From: wheeler
Date: 03/19/80  12:52:48

my GOD! legal.  I gave a 45 minute VM internals overview for the
Baybunch meeting at SLAC. One of the guys from Amdahl came back the
next month and says that I was responsible for them spending the month
rewriting VMPE. I've gotten sign offs on having the ID and told that I
should keep a low profile.  I have a lot of customer contact just
normally so I just periodically mention things. Nobody has yet said
that I can't talk to customers.

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

I've mentioned before the problems with not only getting private links
that cross country borders between purely internal sites ... but also
getting the links encrypted. at one point, the claim was that over
half of all link encryptors in the world were on the internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet


From: wheeler
Date: 03/31/80  20:08:26

Tymshare claims that European government's regulation and prohibitions
against hooking up to ARPA are relatively trivial compared to problems
dealing with Japan. They gave a French government example where
somebody accidently mentioned to the French that the Mexican
government was using Tymnet to do its communication with the Mexican
embassies.  French government got all in an uproar over that being
illegal because the French post office had a monopoly on such
communication (at least with the Mexican embassy in Paris) and that
Tymnet had to prevent Mexico from making such misuse of Tymnet. Tymnet
currently has a policy that they make no statements about what their
users may be doing (and in fact do everything possible to keep from
finding out anything that their users may be doing).

They just give their users a list of things that they are not suppose
to use Tymnet for (and then go into a pitch about how all uses
of Tymnet are kept very confidential, even from people at Tymnet).

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


From: wheeler
Date: 04/01/80  15:50:46

also, re: augment; went up to Tymshare two weeks ago for an augment
demo. they hadn't heard about cord keyboard that Rochester has for
3270 (i pointed them to the IEEE article), it is a lot more useful
than 5 key one they are using.  Level of sophistication is very high
but I think they almost require a color tube to present all the
information. Having control characters all over your screen are hard
to pick out (too much information is being presented than is easily
possible with black&white screen). Also no good provisions for hard
copy of any document. Black and white paper even suffers more, there
isn't a mouse and keyboard with which to operate on the fields and
they become mostly extraneous and get in the way.

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

HONE was the internal world-wide vm-based service supporting
sales, marketing and field people.
http://www.garlic.com/~lynn/subtopic.html#hone

some people were concerned that I might not know anybody at HONE in
order to convince them to make copy of VMSHARE available on HONE. I
would do highly customized cp and cms systems with large number of
enhancements for internal distribution. HONE was one of the sites that
made use of my internally distributed systems (example).

RGET/DATASTAG in the following refers to a ftp/anonymous type of
service as a service virtual machine; recent service virtual machine
reference:
http://www.garlic.com/~lynn/2006t.html#45 To RISC or not to RISC
http://www.garlic.com/~lynn/2006t.html#46 To RISC or not to RISC


From: wheeler
Date: 04/09/80  19:47:29

XXXXXX may have been worried about me being able to get HONE to put up
VMSHARE disk on that system. I don't think they remembered that I've
been supplying them with VM for as long as there has been an HONE (and
even before when it was CP & CP/67). VMSHARE 291 is up on SJRLVM1 and
accessible via RGET & DATASTAG, don't have userid set up yet.  VMSHARE
is loaded on PAVMS system (went to them on 1st file of CP
tape). Should shortly be accessible to HONE users as VMSHARE 291.

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

and misc. past posts mentioning cord keyboards and/or augment
http://www.garlic.com/~lynn/2000g.html#22 No more innovation?  Get serious
http://www.garlic.com/~lynn/2000g.html#26 Who Owns the HyperLink?
http://www.garlic.com/~lynn/2000g.html#31 stupid user stories
http://www.garlic.com/~lynn/2001n.html#70 CM-5 Thinking Machines, Supercomputers
http://www.garlic.com/~lynn/2002b.html#25 Question about root CA authorities
http://www.garlic.com/~lynn/2002d.html#4 IBM Mainframe at home
http://www.garlic.com/~lynn/2002g.html#4 markup vs wysiwyg (was: Re: learning how to use a computer)
http://www.garlic.com/~lynn/2002h.html#6 Biometric authentication for intranet websites?
http://www.garlic.com/~lynn/2002o.html#48 XML, AI, Cyc, psych, and literature
http://www.garlic.com/~lynn/2002q.html#8 Sci Fi again was:  THIS WEEKEND: VINTAGE
http://www.garlic.com/~lynn/2003g.html#44 Rewrite TCP/IP
http://www.garlic.com/~lynn/2004j.html#39 Methods of payment
http://www.garlic.com/~lynn/2004k.html#39 August 23, 1957
http://www.garlic.com/~lynn/2004q.html#55 creat
http://www.garlic.com/~lynn/2005.html#47 creat
http://www.garlic.com/~lynn/2005.html#48 [OT?] FBI Virtual Case File is even possible?
http://www.garlic.com/~lynn/2005f.html#8 Mozilla v Firefox
http://www.garlic.com/~lynn/2005g.html#32 Maximum RAM and ROM for smartcards
http://www.garlic.com/~lynn/2005s.html#12 Flat Query
http://www.garlic.com/~lynn/2006g.html#8 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#15 Security
http://www.garlic.com/~lynn/2006n.html#50 stacks: sorting
http://www.garlic.com/~lynn/2006n.html#51 stacks: sorting
http://www.garlic.com/~lynn/2006p.html#54 Douglas Engelbart's HyperScope 1.0 Launched

Ranking of non-IBM mainframe builders?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Ranking of non-IBM mainframe builders?
Newsgroups: alt.folklore.computers
Date: Tue, 28 Nov 2006 08:19:30 -0700

Some more moving internal design tools off MVS to CMS


To: wheeler
Date: 03/10/80  09:55:45

Welcome back from rainy Southern California. Any good rumors from
SHARE?

Yes, YYYYYY's area should have some interesting things to do.  But
. . . you mentioned Burlington, Vermont as a source of conflict. What
is going on there? Who do I talk to to find out?

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

In the following, VAMPS was a 5-way smp project that I worked on
http://www.garlic.com/~lynn/subtopic.html#bounce

I've talked before about the basic MVS design, 16mbyte virtual address
space, 8mbytes of each address space has the MVS kernel mapped and at
a minimum there is a 1mbyte "common" segment. That leaves a maximum of
7mbytes for application program (and in larger shops, it could be as
little as 3mbytes because of a 5mbyte common segment).

The scheduler referred to in the following is my dynamic adaptive
resource manager product.
http://www.garlic.com/~lynn/subtopic.html#fairshare

While this replay appears to be earlier than the original message, it
is the difference between east coast time and west coast time.


From: wheeler
Date: 03/10/80  08:08:43

they were looking at doing things on a chip. I don't know if it is
conflict or complement. Some of the people worked on VAMPS and would
like to do CMS but I don't think their chips are that large (yet?).

Burlington is still a strategic MVS shop with no VM. They may have to
install at least one. Their MVS is 9 meg (leaving 7 meg.), and they
have a Fortran design program that now has exceeded that size. VM/CMS
could provide them 16 meg. less about 200k or so.

XXXXX (in defense of POK) said they are seriously looking at segment
protect in the hardware now. Several weeks ago a TSO product
admin. called me about putting the scheduler into MVS. They appear to
be running scared.  It seems that they would like to avoid having
salesman going into MVS accounts and admit that MVS isn't the answer
to everything (and by implecation the IBM salesman was wrong) and now
they will have to install VM for interactive computing. Also heard
that POK management tried to brow beat DP marketing into giving equal
billing to TSO (after the VM/CMS is the interactive way to go).

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

a few recent posts mentioning various design tools in san jose
http://www.garlic.com/~lynn/2006p.html#40 "25th Anniversary of the Personal Computer"
http://www.garlic.com/~lynn/2006v.html#17 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006v.html#19 Ranking of non-IBM mainframe builders?


From: wheeler
Date: 06/24/80  13:51:22

re: MDS under CMS; got a call from somebody associated with EDS
(engineering design system) used in Fishkill/POK who is interested in
converting to CMS. I've referred him to XXXXXX & the MDS group for
help & info. At first glance there might be a good lashup between the
two groups in converting to CMS. Sounded like the POK people had no
knowledge about CMS, so the MDS group here may be able to provide
valuable assistance.

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

and misc. past posts mentioning the CERN CMS/TSO "bake-off" (comparing
the two) in 74 time-frame
http://www.garlic.com/~lynn/98.html#28 Drive letters
http://www.garlic.com/~lynn/2000f.html#61 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2001h.html#11 checking some myths.
http://www.garlic.com/~lynn/2001i.html#30 IBM OS Timeline?
http://www.garlic.com/~lynn/2001m.html#19 3270 protocol
http://www.garlic.com/~lynn/2002g.html#67 Coulda, Woulda, Shoudda moments?
http://www.garlic.com/~lynn/2002n.html#73 Home mainframes
http://www.garlic.com/~lynn/2002o.html#54 XML, AI, Cyc, psych, and literature
http://www.garlic.com/~lynn/2003g.html#22 303x, idals, dat, disk head settle, and other rambling folklore
http://www.garlic.com/~lynn/2003h.html#19 Why did TCP become popular ?
http://www.garlic.com/~lynn/2003o.html#16 When nerds were nerds
http://www.garlic.com/~lynn/2003o.html#21 TSO alternative
http://www.garlic.com/~lynn/2004c.html#10 XDS Sigma vs IBM 370 was Re: I/O Selectric on eBay: How to use?
http://www.garlic.com/~lynn/2004c.html#26 Moribund TSO/E
http://www.garlic.com/~lynn/2004c.html#27 Moribund TSO/E
http://www.garlic.com/~lynn/2004n.html#17 RISCs too close to hardware?
http://www.garlic.com/~lynn/2006n.html#3 Not Your Dad's Mainframe: Little Iron

Z/Os Storage Mgmt products

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Z/Os Storage Mgmt products
Newsgroups: bit.listserv.ibm-main
To: <ibm-main@bama.ua.edu>
Date: Tue, 28 Nov 2006 10:58:25 -0700

antonio_cecilio@ibm-main.lst (Antonio Cecilio) writes:

I don't know if IBM's Tivoli suite does similar tasks??

some recent threads discussing history of TSM (tivoli storage manager);
http://www.garlic.com/~lynn/2006.html#9 How to restore VMFPLC dumped files on z/VM V5.1
http://www.garlic.com/~lynn/2006.html#21 IBM up for grabs?
http://www.garlic.com/~lynn/2006b.html#2 Mount a tape
http://www.garlic.com/~lynn/2006b.html#14 Expanded Storage
http://www.garlic.com/~lynn/2006m.html#19 Mainframe Linux Mythbusting
http://www.garlic.com/~lynn/2006n.html#29 CRAM, DataCell, and 3850
http://www.garlic.com/~lynn/2006o.html#64 The Fate of VM - was: Re: Baby MVS???
http://www.garlic.com/~lynn/2006t.html#20 Why these original FORTRAN quirks?; Now : Programming practices
http://www.garlic.com/~lynn/2006t.html#24 CMSBACK
http://www.garlic.com/~lynn/2006t.html#33 threads versus task
http://www.garlic.com/~lynn/2006u.html#19 Why so little parallelism?
http://www.garlic.com/~lynn/2006u.html#26 Assembler question
http://www.garlic.com/~lynn/2006u.html#30 Why so little parallelism?

Ranking of non-IBM mainframe builders?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Ranking of non-IBM mainframe builders?
Newsgroups: alt.folklore.computers
Date: Tue, 28 Nov 2006 17:10:00 -0700

from long ago and far away, ongoing saga of LDL, MDS, EDS, and
migration to distributed vm 4341s.
http://www.garlic.com/~lynn/2006p.html#40 "25th Anniversary of the Personal Computer"
http://www.garlic.com/~lynn/2006v.html#17 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006v.html#19 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006v.html#23 Ranking of non-IBM mainframe builders?


From: wheeler
Date: 09/03/80  17:32:16

There are three systems, LDL, MDS, and EDS. LDL is a logic diagram
system in Los Gatos that has already been converted from MVS to CMS.
MDS is micro-code design system in San Jose GPD. MDS is being looked
at for conversion from MVS to CMS. Amoung other things MDS includes
something called CLICK which appears to be an environment superviser
that all the MDS programs run under. CLICK is 40,000 PLS/assembler
statements. Comment is once CLICK is converted to CMS then the MDS
should be moved over relatively easily. MDS is looking at some things
done by the LDL conversion people who wrote some amount of O/S SVC
simulation code (some replacement for existing SVC simulation and
other is brand new code simulation for SVCs not previously handled)
specified via HNDSVC as possibly solving a number of their problems.

Finally there is engineering design system (EDS) somewhere in fishkill
which appears to require dedicated 168s just to make one run. The MDS
people claim that EDS is a god awful large cludge (this is from people
which have a small 40,000 line superviser running under MVS). I have
had two meetings with the MDS people (running 8-10 hours total). I
have talked to an EDS guy from fishkill for 5-15 minutes. Advice
appears to be the less you have to do with EDS the better off you are.

LDL, MDS, and EDS all appear to be been implemented with some sort of
umbrella supervisor of their own, under which all sorts of application
programs run. The superviser provides some level of supervisery
services over that provided by MVS, but its primary purpose is to
isolate/insulate the application programs from the problems with
dealing directly with MVS. LDL claim that in the conversion from MVS
to CMS they were able to eliminate the LDL superviser and run the
application programs directly under CMS. As a result they claim some
large human factors, functional, and performance improvements. LDL is
no longer a logic design system but just a set of application
programs.

At first glance it would appear that the 40,000 line of CLICK code
could also be replaced by some simple CMS execs. The MDS people are
not too happy with that thot (they have a lot of resources, job
security, etc. invested in CLICK).

Just what is involved in EDS is less clear, its possible that no one
even knows what all is in EDS.

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

Fighting Fraudulent Transactions

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Fighting Fraudulent Transactions
Newsgroups: alt.security
Date: Wed, 29 Nov 2006 08:47:33 -0700

Fighting Fraudulent Transactions
http://www.schneier.com/blog/archives/2006/11/fighting_fraudu.html

... from above ....

The solution is not to better authenticate the person, but to
authenticate the transaction. (Think credit cards. No one checks your
signature. They really don't care if you're you. They maintain
security by authenticating the transactions.)

... snip ...

some comments related to x9.59 financial transactions
http://www.garlic.com/~lynn/aadsm26.htm#13 Who has a Core Competency in Security?

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

x9.59 not only allowed for authenticating the transaction by verifying
a digital signature ... but also allowed the originating environment to
also digitally sign the transactions.

this is somewhat complimentary to the EU FINREAD standard ... lots of
past posts mentioning FINREAD
http://www.garlic.com/~lynn/subintegrity.html#finread

the FINREAD standard specifies integrity requirements for transaction
originating terminals .... some assurance that the transaction being
signed is the transaction being displayed, countermeasures for various
kinds of evesdropping, countermeasures to various kinds of malicious
code performing transactions w/o users knowledge, etc.

however, there was no provision in the FINREAD standard for the
relying-party to actually know whether a FINREAD terminal was actually
involved. x9.59 standard allowed for the originating transaction
environment to also digitally co-sign the transaction ... providing
the relying-party some indication as to the integrity of the
transaction originating environment.

this is somewhat related to some of the requirements for TPM ... misc.
past posts mentioning TPM and/or device authentication
http://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#4 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#42 Why security training is really important (and it ain't anything to do with security!)
http://www.garlic.com/~lynn/aadsm25.htm#44 TPM & disk crypto
http://www.garlic.com/~lynn/2006p.html#41 Device Authentication - The answer to attacks lauched using stolen passwords?
http://www.garlic.com/~lynn/2006p.html#48 Device Authentication - The answer to attacks lauched using stolen passwords?
http://www.garlic.com/~lynn/2006q.html#3 Device Authentication - The answer to attacks lauched using stolen passwords?

Federal Rules May Not Fully Secure Online Banking Sites

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Federal Rules May Not Fully Secure Online Banking Sites
Newsgroups: alt.security
Date: Wed, 29 Nov 2006 09:12:20 -0700

Federal Rules May Not Fully Secure Online Banking Sites
http://www.computerworld.com/action/article.do?command=viewArticleBasic&taxonomyName=security&articleId=274881

from above:

Financial institutions that truly want to bolster their online
security need to look beyond the federal guidelines on end-user
authentication that go into effect Jan. 1, IT managers and analysts
said last week.

... snip ...

and previous post:
http://www.garlic.com/~lynn/2006v.html#26 Fighting Fraudulent Transactions

and misc. other recent related posts
http://www.garlic.com/~lynn/aadsm26.htm#3 Citibank e-mail looks phishy
http://www.garlic.com/~lynn/aadsm26.htm#4 Citibank e-mail looks phishy
http://www.garlic.com/~lynn/aadsm26.htm#5 ATMs hacked using MP3 player
http://www.garlic.com/~lynn/aadsm26.htm#6 Citibank e-mail looks phishy
http://www.garlic.com/~lynn/aadsm26.htm#7 Citibank e-mail looks phishy
http://www.garlic.com/~lynn/aadsm26.htm#9 Who has a Core Competency in Security?
http://www.garlic.com/~lynn/aadsm26.htm#11 What is the point of encrypting information that is publicly visible?
http://www.garlic.com/~lynn/aadsm26.htm#12 Who has a Core Competency in Security?

MB to Cyl Conversion

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: MB to Cyl Conversion
Newsgroups: bit.listserv.ibm-main
To: <ibm-main@bama.ua.edu>
Date: Wed, 29 Nov 2006 10:51:59 -0700

Dean.Montevago@ibm-main.lst (Dean Montevago) writes:

Hi,
Is there a formula for this ? Also Gb to cyl.
Thanks
Dean

relatively recent thread
http://www.garlic.com/~lynn/2006m.html#5 Track capacity?
http://www.garlic.com/~lynn/2006m.html#8 Track capacity?
http://www.garlic.com/~lynn/2006m.html#13 Track capacity?

User Authentication

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: User Authentication
Newsgroups: alt.computer.security
Date: Wed, 29 Nov 2006 13:08:33 -0700

"Michael P." <michael@michaeljpatterson.com> writes:

I'm looking for a best practices paper on online user authentication.
Currently one of our systems allows people to share a user id and
password and to login with that id at the same time in multiple
locations.  I believe that is a poor security practice.  Are there any
papers that discuss this situation and why it may or may not be good
practice.  I'm creating a paper for the company I work with and would
like documentation to support my findings.

the basic premise in shared-secret authentication ... is to have
unique shared-secrets for unique security domains (countermeasure
for individuals in one security domain attacking another ... i.e.
local garage ISP attacking your place of work or financial
institution).
http://www.garlic.com/~lynn/subintegrity.html#secret

there is trade-off issues involving multiple systems within same
security domain.

the unique shared-secret guidelines have resulted in individuals
having to deal with large scores of unique shared-secrets and
finding it impossible to remember them all. this is further aggravated
by guidelines for "impossible to guess" shared-secrets ... which are
also impossible to remember. the whole issue may become further
obfuscated when each system sort of makes believe that they are the
only one in existance ... and therefor the end-user only is dealing
with the one and only password that they required.

so the trade-off involving multiple systems within a single security
domain ... is that a single password compromise can compromise all
systems ... against having large number of different passwords
resulting in the end-user having to write down every one (as an aid to
all the impossible to remember stuff). an attacker getting the written
copy of all passwords can also compromise all systems ... so is a
single password less vulnerable than multiple different passwords (all
recorded in the same place)?

some of the single-sign-on scenarios allow the individual to
authenticate once to the authentication service ... and then the
authentication sevice provides the credentials for all the actual
system connections and authorizations.

one such common facility that is fairly widely deployed is kerberos
originally developed at mit's project athena. there is even a kerberos
specification (pk-init) for allowing for authentication via
verification of digital signature.
http://www.garlic.com/~lynn/subpubkey.html#kerberos

the original pk-init called for just substituting registration of
public key for registration of password ... and then using the registered
public key for verifying any digital signature (w/o requiring any PKI
or digital certificates)
http://www.garlic.com/~lynn/subpubkey.html#certless

later, PKI-mode of operation was added to the pk-init standards
document. my oft repeated comment is that in such environments, the
digital certificates are mostly redundant and superfluous. for whole
lot of reasons (like privacy, security, etc), such digital
certificates tend to only carry information regarding what is
associated with the digital signature being verified ... still
requiring system to lookup in some sort of repository the permissions
and other characteristics. in all such situations, having to make a
repository lookup implies that the registered public key can be
carried in the same repository. if the registered public key can be
carried as part of a repository lookup that is being performed anyway
... the whole PKI and digital certificate distribution infrastructure
is therefor redundant and superfluous.

of course, the alternative is to avoid a repository lookup and
everybody with any kind of acceptable digital certificate is allowed
all possible permissions and privileges.

for other drift ... note that digital signature verification is also a
countermeasures to replay attacks typical of shared-secret based
paradigms ... i.e. evesdropping the shared-secret allows attacker to
replay it. typical digital signature verification operations may have the
system presenting some random data to be digitally signed (as a
countermeasure to static data replay attacks).

a little drift from a couple recent posts
http://www.garlic.com/~lynn/2006v.html#26 Fighting Fraudulent Transactions
http://www.garlic.com/~lynn/2006v.html#27 Federal Rules May Not Fully Secure Online Banking Sites

vmshare

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vmshare
Newsgroups: alt.folklore.computers
Date: Wed, 29 Nov 2006 14:37:46 -0700

Morten Reistad <first@last.name> writes:

In the original rollout of X.25, up until 1981-82, X.25 was strictly
national in Europe. DNIC's followed country boundaries.

Then the internationals rolled out their networks, with dialup and leased
line access. Tymnet, Sprint, Telenet and others. France Telecom was also
an early mover in other countries, mostly to support Minitel access.

Internastional X.25 charges were exorbitant with the incumbents, but
were sort of reasonable with the new entrants. Also, performance was
decent. All the international gateways forced the X.25 window/packet
sizes to 2/128, or a window of 256 bytes. That made international
performance stink. No such problem with Telenet or Sprint, the ones
I tested.

I don't think the telco's understood what happened with X.25, and how
it opened a connectivity door through the monopolies that were widened
by other networks (IBM among them), and later opened for the Internet.

re:
http://www.garlic.com/~lynn/2006v.html#22 vmshare

it wasn't limited to just europe and/or international calls ... lots
of the PTTs all over the world were charging exorbitant rates for
business, long-distance, and international ... somewhat used to
subsidize residential/consumer rates.

the emerging business/long-haul competitors then precipitated the
breakup of the bell monopoly in the us

there are even some similarities with the current VOIP situation.

for other topic drift ... the 37xx/NCP emulator discussed in this post
http://www.garlic.com/~lynn/2006v.html#20 Ranking of non-IBM mainframe builders?

had originated at one of the baby bells. I got involved in looking at
turning it out as a product (as well as porting it to RIOS).

while this activity was somewhat done under hsdt project
http://www.garlic.com/~lynn/subnetwork.html#hsdt

it was independent of other hsdt activity ... like some of the stuff
related to nsfnet backbone ... some recent posts
http://www.garlic.com/~lynn/2006j.html#34 Arpa address
http://www.garlic.com/~lynn/2006j.html#43 virtual memory
http://www.garlic.com/~lynn/2006j.html#45 Arpa address
http://www.garlic.com/~lynn/2006j.html#46 Arpa address
http://www.garlic.com/~lynn/2006k.html#37 PDP-1
http://www.garlic.com/~lynn/2006m.html#10 An Out-of-the-Main Activity
http://www.garlic.com/~lynn/2006p.html#13 What part of z/OS is the OS?
http://www.garlic.com/~lynn/2006r.html#6 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006s.html#20 real core
http://www.garlic.com/~lynn/2006s.html#50 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006s.html#51 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006t.html#6 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006t.html#36 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006t.html#43 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006u.html#55 What's a mainframe?
http://www.garlic.com/~lynn/2006u.html#56 Ranking of non-IBM mainframe builders?

the baby bell responsible for the emulator was part of US West ... and
they used the S/1s and emulator to drive several tens of thousands of
327x terminals. another of the US West baby bells had similar
configuration but was using COMTEN clone-controllers. Eventually, US
West decided on consolidating on a single configuration across the
organization ... which met that the emulator group was going to have a
face-off in Denver with the COMTEN-based organization. I was even
invited to be part of the meetings ... which i managed to avoid.

MB to Cyl Conversion

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: RE: MB to Cyl Conversion
Newsgroups: bit.listserv.ibm-main
To: <ibm-main@bama.ua.edu>
Date: Thu, 30 Nov 2006 10:00:30 -0700

rfochtman@ibm-main.lst (Rick Fochtman) writes:

There are similar references for all the "newer" DASD since that time,
as well. But they're hard to find.

i would be happy to update gcard section
http://www.garlic.com/~lynn/gcard.html#26.3

if somebody can provide the info ... previous post
http://www.garlic.com/~lynn/2006v.html#28 MB to Cyl Conversion

gcard started out as ios3270 version of the green card. i've done a
very simple conversion to html.

for those that don't think they've seen ios3270 ... the service
processor on the 3090 was a pair of 4361s running a highly modified
version of vm/cms release 6 ... using ios3270 for the service screens.

and for something completely different ... i'm still looking for
code names for completing the following.

           2301       fixed-head/track (2303 but 4 r/w heads at time)
           2303       fixed-head/track r/w 1-head (1/4th rate of 2301)
Corinth    2305-1     fixed-head/track
Zeus       2305-2     fixed-head/track
           2311
           2314
           2321       data-cell "washing machine"
Piccolo    3310       FBA
Merlin     3330-1
Iceberg    3330-11
Winchester 3340-35
           3340-70
           3344       (3350 physical drive simulating multiple 3340s)
Madrid     3350
NFP        3370       FBA
Florence   3375       3370 supporting CKD
Coronado   3380 A04, AA4, B04
EvergreenD 3380 AD4, BD4
EvergreenE 3380 AE4, BE4
           3830       disk controller, horizontal microcode engine
Cybernet   3850       MSS (also Comanche & Oak)
Cutter     3880       disk controller, jib-prime (vertical) mcode engine
Ironwood   3880-11    (4kbyte/page block 8mbyte cache)
Sheriff    3880-13    (full track 8mbyte cache)
Sahara     3880-21    (larger cache for "11")
??         3880-23    (larger cache for "13")

... snip ...

i believe most current dasd is really ckd emulated on FBA-based disks
... sort of the first would have been 3375.

Effi[ci]ency of branch table vs individual compare & branch

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Effi[ci]ency of branch table vs individual compare & branch
Newsgroups: bit.listserv.ibm-main
To: <ibm-main@bama.ua.edu>
Date: Thu, 30 Nov 2006 10:57:57 -0700

Dan Espen <daneNO@MORE.mk.SPAMtelcordia.com> writes:

Back in my insurance days on an IBM 1440, I was able to
demonstate impossibly fast state lookup times with the
simple expedient of putting NY, NJ and CA first in the table.

Who needs binary lookups when the data cooperates.

for the online internal telephone book ... used a radix search (rather
than binary). basically took the first two letter frequency (in names)
and built that into the search ... first probe then calculated "error"
for performing the next probe.

with a couple hundred thousand employees ... binary search is on the
order of 16-17 probes. assuming 4k physical records (cms filesystem),
radix could frequently be within the correct physical record on the
first probe.

the effort guidelines was that the program could be written/tested in
one person week ... and the maintenance and distribution (on the
internal network) of the files would be on the order of less than one
person day/month. also, lookup had to be faster than lookup of paper
copy sitting on desk.

this was counter to a corporate hdqtrs online phone book proposal for
$20m budget with dedicated 370/158 and staff.

misc. past posts mentioning phone book effort:
http://www.garlic.com/~lynn/2000g.html#14 IBM's mess (was: Re: What the hell is an MSX?)
http://www.garlic.com/~lynn/2001j.html#29 Title Inflation
http://www.garlic.com/~lynn/2001j.html#30 Title Inflation
http://www.garlic.com/~lynn/2002e.html#33 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2003b.html#45 hyperblock drift, was filesystem structure (long warning)
http://www.garlic.com/~lynn/2003i.html#58 assembler performance superiority: a given
http://www.garlic.com/~lynn/2004c.html#0 A POX on you, Dennis Ritchie!!!
http://www.garlic.com/~lynn/2004j.html#58 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2004l.html#32 Shipwrecks
http://www.garlic.com/~lynn/2004p.html#13 Mainframe Virus ????
http://www.garlic.com/~lynn/2005c.html#32 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005c.html#38 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005c.html#43 History of performance counters
http://www.garlic.com/~lynn/2005s.html#3 Flat Query
http://www.garlic.com/~lynn/2005s.html#4 Flat Query
http://www.garlic.com/~lynn/2005s.html#26 IEH/IEB/... names?
http://www.garlic.com/~lynn/2005t.html#44 FULIST
http://www.garlic.com/~lynn/2005t.html#49 FULIST
http://www.garlic.com/~lynn/2006f.html#20 Old PCs--environmental hazard
http://www.garlic.com/~lynn/2006n.html#22 sorting was: The System/360 Model 20 Wasn't As Bad As All That
http://www.garlic.com/~lynn/2006n.html#23 sorting was: The System/360 Model 20 Wasn't As Bad As All That
http://www.garlic.com/~lynn/2006p.html#31 "25th Anniversary of the Personal Computer"
http://www.garlic.com/~lynn/2006r.html#46 Trying to design low level hard disk manipulation program

New attacks on the financial PIN processing

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: New attacks on the financial PIN processing
Newsgroups: sci.crypt
Date: Thu, 30 Nov 2006 19:45:56 -0700

Possible Serious Security Flaw In ATMs
http://it.slashdot.org/it/06/11/30/2139235.shtml

ATM system called unsafe
http://redtape.msnbc.com/2006/11/researchers_who.html

from above:

A U.S. Secret Service memo obtained by MSNBC.com indicates that
organized criminals are systematically attempting to subvert the ATM
system and unscramble encrypted PIN codes.

... snip ...

past posts in this thread:
http://www.garlic.com/~lynn/2006u.html#40 New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006u.html#42 New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006u.html#43 New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006u.html#47 New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006u.html#48 New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006v.html#1 New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006v.html#2 New attacks on the financial PIN processing

vmshare

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vmshare
Newsgroups: alt.folklore.computers
Date: Thu, 30 Nov 2006 21:25:27 -0700

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

the baby bell responsible for the emulator was part of US West ... and
they used the S/1s and emulator to drive several tens of thousands of
327x terminals. another of the US West baby bells had similar
configuration but was using COMTEN clone-controllers. Eventually, US
West decided on consolidating on a single configuration across the
organization ... which met that the emulator group was going to have a
face-off in Denver with the COMTEN-based organization. I was even
invited to be part of the meetings ... which i managed to avoid.

re:
http://www.garlic.com/~lynn/2006v.html#20 Ranking of non-IBM mainframe builders
http://www.garlic.com/~lynn/2006v.html#30 vmshare

Almost showed up in denver ... but did manage to squeak out.  This was
shortly after research moved from bldg. 28 (on the main plant site) up
the hill to the "new" almaden facility


From: wheeler
Date: 01/24/86  08:52:04

I can be in Denver on Monday ... I have a meeting in Chicago with
Amoco for Tuesday afternoon tho. What, were, when, etc? You may
notice that I've moved into the new research facility and have
a new phone no.

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

this was getting even more involved in baby bell politics (behind the
scenes); in the following ... southern bell lined up to tell IBM to
not bother even bidding products unless IBM was prepared to ship the
emulator product.

then had a meeting to preview presentation for the head of the
communication group with his technical assistent.


From: wheeler
Date: 01/24/86  12:38:38

Talked to XXXXX, they pitched to Southern Bell in Raleigh.  Southern
Bell told IBM that unless it bids the emulator, IBM might as well
no-bid if it is considering any other solution. Things aren't final,
but as of now, I presume I'm going to be in Denver on Monday morning
talking to US-West executives about the emulator.

I've got meeting set up with XXXX on the 4th to go over the emulator
and will try and have meeting set up for later that week with YYYY

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

other hsdt:
http://www.garlic.com/~lynn/subtopic.html#hsdt

What's a mainframe?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What's a mainframe?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 01 Dec 2006 09:55:20 -0700

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

some collected 3-tier postings
http://www.garlic.com/~lynn/subnetwork.html#3tier

... we were calling our 3-tier marketing pitch middle layer

re:
http://www.garlic.com/~lynn/2006v.html#10 What's a mainframe

and some other background regarding 3-tier/middle layer activity ...

the following "RFC" is different from the RFCs in the IETF standards
... IETF RFC standards index:
http://www.garlic.com/~lynn/rfcietff.htm

the RFC mentioned here is sometimes also called RFI (request for
information) and frequently are prelude to RFP (request for price)
or RFQ (request for quote).


From: wheeler
Date: THU, 04/16/87 14:54:42 PDT

"request for comments" that will be the subject of the 4/29 & 5/5
meetings is being referred to as a white paper on Project *****.

The basic premise is that there is a large community of users that
interface to intelligent workstations (IBM XTs, IBM ATs, and things
called high performance workstations ...  HPW appear to be RTs,
Apollos, and 3B2).  There is also a large collection of servers
providing services and/or data bases (on mainframes, minis,
workstations, etc).

The objective of ***** is to allow the interconnection of everybody to
everything in controlled, managed manner.

Severs/services are broken into 6 catagories, 1) user services, 2)
geographic community services, 3) central community services, 4)
global services, 5) T transport services, and 6) network management
facility.

Transport services are broken into a) intra-geo