2006 Newsgroup postings (11/23 - 12/05) Lynn Wheeler

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?

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

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
https://www.garlic.com/~lynn/94.html#2 Schedulers
https://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 theoretically 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
https://www.garlic.com/~lynn/submain.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
https://www.garlic.com/~lynn/submain.html#adcon

New attacks on the financial PIN processing

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

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

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

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

New attacks on the financial PIN processing

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

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:
https://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
https://www.garlic.com/~lynn/x959.html#x959
https://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.
https://www.garlic.com/~lynn/subintegrity.html#harvest
https://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
https://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
https://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
https://www.garlic.com/~lynn/aadsm17.htm#38
Leading Cause of Data Security breaches Are Due to Insiders
https://www.garlic.com/~lynn/aadsm18.htm#49
Bank workers biggest ID theft threat
https://www.garlic.com/~lynn/2005l.html#35
other insider threat
https://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
https://www.garlic.com/~lynn/2006v.html#1 New attacks on the financial PIN processing
https://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:
https://www.garlic.com/~lynn/2006v.html#3 Historical question, what went wrong with bubble memory?

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

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

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

Why these original FORTRAN quirks?

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

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:
https://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)
https://www.garlic.com/~lynn/submain.html#dumprx

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

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

Reasons for the big paradigm switch

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

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"
https://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
https://www.garlic.com/~lynn/2003j.html#42 Flash 10208

includes email from
https://www.garlic.com/~lynn/2003j.html#email831118 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).

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:
https://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
https://www.garlic.com/~lynn/2006v.html#6 Reasons for the big paradigm switch

In Search of Stupidity

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

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:
https://www.garlic.com/~lynn/2005j.html#32 IBM Plugs Big Iron to the College Crowd
https://www.garlic.com/~lynn/2006b.html#31 Seeking Info on XDS Sigma 7 APL
https://www.garlic.com/~lynn/2006r.html#20 50th Anniversary of invention of disk drives

In Search of Stupidity

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

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:
https://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?

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

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
https://www.garlic.com/~lynn/subtopic.html#hacmp

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

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

Date: Fri, 19 May 89 13:31:31 CDT
From: wheeler
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

Date: Thu, 15 Jun 89 19:28:52 CDT
From wheeler
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
https://www.garlic.com/~lynn/2006p.html#31 "25th Anniversary of the Personal Computer"
https://www.garlic.com/~lynn/2006p.html#36 "25th Anniversary of the Personal Computer"
https://www.garlic.com/~lynn/2006p.html#40 "25th Anniversary of the Personal Computer"

a couple recent posts mentioning DataTree (unitree, nastore, and/or mesa)
https://www.garlic.com/~lynn/2006n.html#29 CRAM, DataCell, and 3850
https://www.garlic.com/~lynn/2006u.html#19 Why so little parallelism?
https://www.garlic.com/~lynn/2006u.html#20 Why so little parallelism?
https://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
https://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).
https://www.garlic.com/~lynn/2006u.html#55 What's a mainframe?

and some recent, slightly related drift
https://www.garlic.com/~lynn/2006v.html#8 In Search of Stupidity
https://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
https://www.garlic.com/~lynn/subpubkey.html#kerberos

What's a mainframe?

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

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
https://www.garlic.com/~lynn/2006p.html#31 "25th Anniversary of the Personal Computer"
https://www.garlic.com/~lynn/2006p.html#36 "25th Anniversary of the Personal Computer"
https://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
https://www.garlic.com/~lynn/2001m.html#15 departmental servers

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

so somewhat leading edge of distributed 43xx

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

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

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

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
https://www.garlic.com/~lynn/2006q.html#9 Is no one reading the article?
https://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:
https://www.garlic.com/~lynn/2006v.html#8 In Search of Stupidity
https://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

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

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:
https://www.garlic.com/~lynn/2006v.html#8 In Search of Stupidity
https://www.garlic.com/~lynn/2006v.html#9 In Search of Stupidity
https://www.garlic.com/~lynn/2006v.html#13 In Search of Stupidity

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

a very Boyd "thing"
https://www.garlic.com/~lynn/subboyd.html#boyd
https://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
https://www.garlic.com/~lynn/subnetwork.html#3tier

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

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.
https://www.garlic.com/~lynn/aadsm17.htm#56 Question on the state of the security industry
https://www.garlic.com/~lynn/aadsm21.htm#16 PKI too confusing to prevent phishing, part 28
https://www.garlic.com/~lynn/2001j.html#42 Big black helicopters
https://www.garlic.com/~lynn/2001k.html#7 hot chips and nuclear reactors
https://www.garlic.com/~lynn/2002h.html#39 Oh, here's an interesting paper
https://www.garlic.com/~lynn/2004q.html#17 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005d.html#42 Thou shalt have no other gods before the ANSI C standard
https://www.garlic.com/~lynn/2005s.html#2 Internet today -- what's left for hobbiests

and for some real topic drift:
https://www.garlic.com/~lynn/aadsm26.htm#9 Who has a Core Competency in Security?
https://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
https://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?

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

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:
https://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
https://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.

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

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?

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

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:
https://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
https://www.garlic.com/~lynn/subtopic.html#disk

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

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

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

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

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

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

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

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

The Incredible Shrinking Cosmonaut Corps

Refed: **

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
https://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:
https://www.garlic.com/~lynn/2006v.html#15 The Incredible Shrinking Cosmonaut Corps

and now for something completely different ...

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

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?
https://www.garlic.com/~lynn/aadsm26.htm#8 What is the point of encrypting information that is publicly visible?
https://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?
https://www.garlic.com/~lynn/aadsm26.htm#9 Who has a Core Competency in Security?
https://www.garlic.com/~lynn/aadsm26.htm#10 Who has a Core Competency in Security?

Ranking of non-IBM mainframe builders?

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

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:
https://www.garlic.com/~lynn/2006p.html#40 25th Anniversary of the Personal Computer
https://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.

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

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

Ranking of non-IBM mainframe builders?

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

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.
https://www.garlic.com/~lynn/2006v.html#16 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006v.html#17 Ranking of non-IBM mainframe builders?
https://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
https://www.garlic.com/~lynn/2004o.html#30 z/OS UNIX
https://www.garlic.com/~lynn/2006d.html#3 Hercules 3.04 announcement
https://www.garlic.com/~lynn/2006d.html#15 Hercules 3.04 announcement
https://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
https://www.garlic.com/~lynn/2006u.html#29 To RISC or not to RISC
https://www.garlic.com/~lynn/2006u.html#31 To RISC or not to RISC
https://www.garlic.com/~lynn/2006u.html#32 To RISC or not to RISC
https://www.garlic.com/~lynn/2006u.html#37 To RISC or not to RISC
https://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"
https://www.garlic.com/~lynn/submain.html#360pcm

the "clone" problem supposedly was one of the major motivations for the (failed) future system effort
https://www.garlic.com/~lynn/submain.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
https://www.garlic.com/~lynn/99.html#63 System/1 ?
https://www.garlic.com/~lynn/99.html#66 System/1 ?
https://www.garlic.com/~lynn/99.html#67 System/1 ?
https://www.garlic.com/~lynn/99.html#70 Series/1 as NCP (was: Re: System/1 ?)
https://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:
https://www.garlic.com/~lynn/2006u.html#28 Assembler question
https://www.garlic.com/~lynn/2006u.html#30 Why so little parallelism?
https://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).
https://www.garlic.com/~lynn/subtopic.html#801

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

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

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
https://www.garlic.com/~lynn/2006t.html#23 threads versus task

re:
https://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 ...
https://www.garlic.com/~lynn/2006t.html#31 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006t.html#32 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006t.html#34 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006t.html#36 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006t.html#41 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006t.html#42 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006t.html#43 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006t.html#49 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006t.html#50 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006u.html#0 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006u.html#6 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006u.html#7 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006u.html#8 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006u.html#9 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006u.html#10 The Future of CPUs: What's After Multi-Core?

vmshare

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

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
https://www.garlic.com/~lynn/submain.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).

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

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
https://www.garlic.com/~lynn/subnetwork.html#internalnet

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

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

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

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.
https://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:
https://www.garlic.com/~lynn/2006t.html#45 To RISC or not to RISC
https://www.garlic.com/~lynn/2006t.html#46 To RISC or not to RISC

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

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, HONE email

Ranking of non-IBM mainframe builders?

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

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

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

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
https://www.garlic.com/~lynn/submain.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.
https://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.

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

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
https://www.garlic.com/~lynn/2006p.html#40 "25th Anniversary of the Personal Computer"
https://www.garlic.com/~lynn/2006v.html#17 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006v.html#19 Ranking of non-IBM mainframe builders?

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

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

Z/Os Storage Mgmt products

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

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

Ranking of non-IBM mainframe builders?

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

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.
https://www.garlic.com/~lynn/2006p.html#40 "25th Anniversary of the Personal Computer"
https://www.garlic.com/~lynn/2006v.html#17 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006v.html#19 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006v.html#23 Ranking of non-IBM mainframe builders?

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

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

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

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
https://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
https://www.garlic.com/~lynn/x959.html#x959
https://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
https://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
https://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#4 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#42 Why security training is really important (and it ain't anything to do with security!)
https://www.garlic.com/~lynn/aadsm25.htm#44 TPM & disk crypto
https://www.garlic.com/~lynn/2006p.html#41 Device Authentication - The answer to attacks lauched using stolen passwords?
https://www.garlic.com/~lynn/2006p.html#48 Device Authentication - The answer to attacks lauched using stolen passwords?
https://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&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:
https://www.garlic.com/~lynn/2006v.html#26 Fighting Fraudulent Transactions

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
https://www.garlic.com/~lynn/2006m.html#5 Track capacity?
https://www.garlic.com/~lynn/2006m.html#8 Track capacity?
https://www.garlic.com/~lynn/2006m.html#13 Track capacity?

User Authentication

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

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).
https://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.
https://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)
https://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
https://www.garlic.com/~lynn/2006v.html#26 Fighting Fraudulent Transactions
https://www.garlic.com/~lynn/2006v.html#27 Federal Rules May Not Fully Secure Online Banking Sites

vmshare

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

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:
https://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
https://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
https://www.garlic.com/~lynn/subnetwork.html#hsdt

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

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

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
https://www.garlic.com/~lynn/gcard.html#26.3

if somebody can provide the info ... previous post
https://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

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

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.

New attacks on the financial PIN processing

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

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:
https://www.garlic.com/~lynn/2006u.html#40 New attacks on the financial PIN processing
https://www.garlic.com/~lynn/2006u.html#42 New attacks on the financial PIN processing
https://www.garlic.com/~lynn/2006u.html#43 New attacks on the financial PIN processing
https://www.garlic.com/~lynn/2006u.html#47 New attacks on the financial PIN processing
https://www.garlic.com/~lynn/2006u.html#48 New attacks on the financial PIN processing
https://www.garlic.com/~lynn/2006v.html#1 New attacks on the financial PIN processing
https://www.garlic.com/~lynn/2006v.html#2 New attacks on the financial PIN processing

vmshare

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

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:
https://www.garlic.com/~lynn/2006v.html#20 Ranking of non-IBM mainframe builders
https://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

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

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

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

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:
https://www.garlic.com/~lynn/subnetwork.html#hsdt

What's a mainframe?

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

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
https://www.garlic.com/~lynn/subnetwork.html#3tier

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

re:
https://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:
https://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).

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

"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-geographic community transport servcies (megabits/sec LAN), b) backbone transport services, c) inter-community transport services (gigabit/sec), and d) inter-complex transport services (multi-gigabit).

It mentions the ability to interface to A) IEEE 802.3, B) HYPERchannel type "A" technology, C) HYPERchannel type "B" technology, D) ieee 802.5, E) APOLLO domain network, F) HPW network, G) x.25, H) MIL-STD-188-114A, anded I) FDDI. Added to that are catagories interfacing to technology under development and interfacing to various vendor mainframe machines.

TCP should be available ... but recognized as not appropriate for all needs because of various performance and/or reliability characteristics (they refer to tracking a maturing technology ... as an aside there have been a number of references in the various CSNET/ARPANET forums by people drafting some of the newer standards that in many cases they should be implemented outside of research environments for the next 3-5 years ... because it is taking at least that long to work out various bugs in tcp/ip).

Some note is given that a gateway to SNA should be considered.

Finally the whole thing must be manageable ... both from an operational and a security/authorization viewpoint.

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

in the following, "SJ" (san jacinto) was code name for rs/6000.

Date: THU, 05/07/87 10:43:27 PDT
From: wheeler

re: "request for comments" meeting

was at customer on Tuesday with the branch office to discuss project ******. They need a IP-based network system (or at least one with ip interfaces) that will inter-connect high-performance workstations, personnel computers, terminals, department processors, and at least 4 different vendors' mainframe computers.

Intra-network needs to have a wide-range of performance over campus-like (fiber) connections along with interfaces/bridges to 10-20 different existing network technologies (hyperchannel, token-ring, etc).

The boundary nodes (except for possibly at the mainframes) need to have a limited IP session management for authenticity/authorization, while internal network transport can be handled by efficient packet movement.

Centralized authority would establish the authorization rules which would then be referenced by the boundary nodes (central data base, replicated data base, distributed data base, etc).

Using such an implementation moves it out of lots of applications and puts it into security control rather than in each individual application in each individual mainframe (i.e. asymetrical design with hosts assuming that the gate keepers at the boundaries are trusted, although the design must also support symmetrical authenticity validation between workstations). Possibility exists for limited form of distributed authorization rule capability ... specific sub-administrators being able to specify rules within a very specific domain &/or span of control. The asymmetrical mainframe design eventually dictates that all mainframe access would be restricted to only be allowed via sessions thru the boundary node, gate keepers.

Likely candidate for such a role is SJ ... although prototypes could be envisioned with RTOS on RTs &/or 386s. Lots of hardware interfaces would need to be developed for multibus, hyperchannel, hyperbus, etc.

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

Why these original FORTRAN quirks?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why these original FORTRAN quirks?
Newsgroups: alt.folklore.computers,comp.lang.fortran
Date: Fri, 01 Dec 2006 16:29:33 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:
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.

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

real old reference about porting a bunch of changes from cp67 to vm370.

the complete restructuring of how page control blocks were built and managed by the kernel was picked up by the development group for part of vm370 release 3.

a small subset of the virtual memory management changes were also picked up for "DCSS", and shipped in vm370 release 3.

the paging monitor changes, page migration, and moving control blocks out of real memory to disk were included in my resource manager release. misc. related posts:
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock

posts about related work for cms paged mapped filesystem
https://www.garlic.com/~lynn/submain.html#mmap

and problems dealing with os/360 address constant conventions in shared segments that can occur at arbitrary virtual addresses
https://www.garlic.com/~lynn/submain.html#adcon

Date: Dec 12, 1973
From: wheeler
Subject: assignment of co-op students

Per our agreement, it is my understanding that bbbbbb and ccccccc will be working with me on making modifications to VM/370 with the reservation that they may be required on demand to work on special operation problems.

The project they will be working on envolves fairly extensive changes to the paging supervisor in VM/370. It will consist of three phases, the last of which I do not fully expect to be completed when they leave us in June 1974 after graduating from Northeastern University.

Phase I reqires extensive modification throughout the VM/370 nucleus to support deferring creation of page control blocks until the point the corresponding virtual memory is actually referenced. This will centralize the control of the page blocks in one module, simplifying later modifications. At the same time performance modifications will be made to the paging monitor including the addition of several features currently in our CP/67.

Phase II will support the dynamic virtual assignment of portions of virtual memory either as 'scratch' memory or as predefined 'named' memory. This will allow virtual machines to have simultaneous virtual memory access to multiple 'named areas' any of which could also be shared. The current 'IPL BY NAME' facility becomes one specific application of this expanded memory management mechanism.

Phase III will allow the specification of both shared and non-shared dynamically defined named memory. The removal of certain page control blocks to dasd storage and their subsequant retrieval on demand will be considered, as will methods of retaining information to support a page migration scheme.

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

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is this true? (Were gotos really *that* bad?)
Newsgroups: alt.folklore.computers
Date: Fri, 01 Dec 2006 17:02:57 -0700

"winston19842005@yahoo.com" <winston19842005@yahoo.com> writes:
Our old IBM terminals for the AS/400 has a shift-lock key. It'd been about ten years since I used one when I started here, and forgot that until I entered #$%*(#@ a few times instead of numbers.

Now we use PCs with IBM iSeries Access. So much better, the occasional error writing to a memory address on the PC, with the app exiting, so then your terminal ID on the system is locked, requiring you to use another session to kill it and vary off the device. I had it happen on both my sessions, one after the other once, and was afraid I'd have trouble getting on to kill those sessions!

I really wish we had Reflections (not the IE-based crap that others use here...)

for lots of drift .... recent RFC 4777 "IBM's iSeries Telnet Enhancements"

from my rfc index
https://www.garlic.com/~lynn/rfcietff.htm

https://www.garlic.com/~lynn/rfcidx15.htm#4777
4777 I
IBM's iSeries Telnet Enhancements, Murphy T., Rieth P., Stevens J., 2006/11/29 (47pp) (.txt=104243) (Obsoletes 2877) (Refs 854, 855, 856, 858, 885, 1205, 1572, 2877) (was draft-murphy-iser-telnet-04.txt)

is listed as obsoleting rfc 2877

now rfc 2877

https://www.garlic.com/~lynn/rfcidx9.htm#2877
2877 -I
5250 Telnet Enhancements, Murphy T., Rieth P., Stevens J., 2000/07/12 (36pp) (.txt=83369) (Obsoleted by 4777) (Updates 1205) (Refs 854, 855, 856, 858, 885, 1091, 1205, 1572, 1700) (Ref'ed By 4777)

is listed as updating rfc 1205

https://www.garlic.com/~lynn/rfcidx4.htm#1205
1205 I
5250 Telnet Interface, Chmielewski P., 1991/02/21 (12pp) (.txt=26505) (Refs 854, 855, 856, 885, 1091) (Ref'ed By 2877, 4777)

now normally when a RFC obsoletes some other RFC ... which in turn "updates" a 3rd RFC ... the "NEW" (obsoleting) RFC typically also is listed as updating the 3rd RFC (in place of the RFC being obsoleted). by that logic, RFC 4777 should have listed that it not only obsoleted RFC 2877, but also that it updates RFC 1205 (in lieu of the RFC it obsoleted?).

vmshare

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vmshare
Newsgroups: alt.folklore.computers
Date: Sat, 02 Dec 2006 10:45:00 -0700

"David Wade" <g8mqw@yahoo.com> writes:
BT in the UK

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

note that one of the things that was happening in the 70s and thru much of the 80s was the appearance of a lot of (commercial) VANs (value added networks). the ascension of the internet in the 90s basically obsoleted all of them ... although some number still attempt to linger on in one from or another.

misc. past internet related posts
https://www.garlic.com/~lynn/subnetwork.html#internet

misc. past posts mentioning bitnet (in the us) and/or the earn counterpart (to bitnet in europe)
https://www.garlic.com/~lynn/subnetwork.html#bitnet

misc. past posts mentioning (vm370 based) commercial timesharing services ... including tymshare
https://www.garlic.com/~lynn/submain.html#timeshare

as an aside ... after m/d bought tymshare ... they spun off tymnet to BT.

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

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: On sci.crypt: New attacks on the financial PIN processing
Newsgroups: alt.computer.security
Date: Sat, 02 Dec 2006 13:17:44 -0700

"nemo_outis" <abc@xyz.com> writes:
The underlying paper, which came out about 2 weeks ago, is at:

http://www.arx.com/documents/The_Unbearable_Lightness_of_PIN_Cracking.pdf

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

and some misc. older posts related to ATM and debit card issues, vulnerabilities, exploits and threats:
https://www.garlic.com/~lynn/2005u.html#16 AMD to leave x86 behind?
https://www.garlic.com/~lynn/2006e.html#21 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006e.html#22 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006e.html#23 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006e.html#24 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006e.html#26 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006e.html#30 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006k.html#23 Value of an old IBM PS/2 CL57 SX Laptop
https://www.garlic.com/~lynn/aadsm22.htm#21 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#22 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#25 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#26 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm23.htm#35 3 of the big 4 - all doing payment systems
https://www.garlic.com/~lynn/aadsm23.htm#37 3 of the big 4 - all doing payment systems
https://www.garlic.com/~lynn/aadsm24.htm#9 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#10 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm26.htm#1 Extended Validation - setting the minimum liability, the CA trap, the market in browser governance
https://www.garlic.com/~lynn/aadsm26.htm#6 Citibank e-mail looks phishy
https://www.garlic.com/~lynn/aadsm26.htm#11 What is the point of encrypting information that is publicly visible?
https://www.garlic.com/~lynn/2006v.html#1 New attacks on the financial PIN processing

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

part of x9.59 standard was attempting to eliminate most of the known exploits, threats and vulnerabilities in the infrastructure.

another part was being privacy agnostic ... i.e. name and/or other identifying information would not be required at point-of-sale. part of that was looking at promoting x9.59 to ISO (international) level ... and in that period the EU had made some directive (in conjunction with the EU-DPD) that electronic transactions should be as anonymous as cash at point-of-sale.

for some other drift ... as part of co-authoring the x9.99 financial industry privacy standard ... did some work on trying to pull together a merged privacy taxonomy and glossary from several sources (including GLBA, EU-DPD, HIPAA, etc)
https://www.garlic.com/~lynn/index.html#glosnote

vmshare

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vmshare
Newsgroups: alt.folklore.computers
Date: Sat, 02 Dec 2006 15:52:49 -0700

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

... and another vmshare related email ...

after the availability of ibm/pc ... share & tymshare expanded vmshare computer conferencing to also include "pcshare".

and i've mentioned HONE before ... the (internal) vm370 based, world-wide system supporting marketing, sales, and field people.
https://www.garlic.com/~lynn/subtopic.html#hone

since I was making vmshare&pcshare information widely available inside the corporation ... the lawyers raised questions about any liability.

Date: 12/19/84 08:25:24
From: wheeler

re: vmshare&pcshare: i double checked with Tymshare, but ... all files on pcshare and vmshare are owned by Share, Inc and may only be used by Share and its members, i.e. IBM is a member and as such can use the files internally inside (however, an IBM se couldn't take a copy of some of the files from HONE and give them to a customer which was not a Share member).

Tymshare says that some program "files" are allowed on VMSHARE or PCSHARE which are in the "public domain" and/or have no restrictuions on copying, distributing, and using. Some of those program files may also contain copyright notices such that the "ownership" remains with the original author (but the right to copy, distribute, and use the program is freely given ... I presume the copyright restriction then means that somebody else can't include such a program in their own application and charge for it).

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

note early attempt on some sort of GPL stuff for free software ...

other posts in this thread:
https://www.garlic.com/~lynn/2006v.html#30 vmshare
https://www.garlic.com/~lynn/2006v.html#34 vmshare
https://www.garlic.com/~lynn/2006v.html#38 vmshare

Year-end computer bug could ground Shuttle

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Year-end computer bug could ground Shuttle
Newsgroups: alt.folklore.computers
Date: Sat, 02 Dec 2006 16:11:02 -0700

re:
https://www.garlic.com/~lynn/2006u.html#13 Year-end computer bug could ground Shuttle

for some other topic drift ... following email is with reference to having been at launch of 41-d; it was sent to somebody that lived/worked near kennedy and was a private plane pilot.

Date: 09/04/84 17:22:44
From: wheeler

re: shuttle; i was in the viewing stands when the last shuttle went up thursday ... that wasn't you in a private airplane in the launch space that ignored radio messages & had to have a chase plane sent after it?????

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

other posts in this thread
https://www.garlic.com/~lynn/2006u.html#14 Year-end computer bug could ground Shuttle
https://www.garlic.com/~lynn/2006u.html#35 Friday fun - Discovery on the pad and the software's not done

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

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: On sci.crypt: New attacks on the financial PIN processing
Newsgroups: alt.computer.security
Date: Sat, 02 Dec 2006 17:40:04 -0700

ref:
https://www.garlic.com/~lynn/2006v.html#39 On sci.crypt: New attacks on the financial PIN processing

and some more background and related topics

Bank-card PINs 'wide open' to insider attack
http://www.theregister.co.uk/2006/11/20/bank_card_pin_fraud/
Researchers uncover PIN security flaw
http://www.finextra.com/fullstory.asp?id=16183
Banks face growing threat of identity theft from insiders
http://www.hackinthebox.org/modules.php?op=modload&name=News&file=article&sid=21817
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

and repeat about some PIN issues
https://www.garlic.com/~lynn/aadsm26.htm#6
as well as the insider issue
https://www.garlic.com/~lynn/aadsm26.htm#7

UK Leads Europe In Card Crime
http://www.epaynews.com/index.cgi?survey=&ref=browse&f=view&id=116427718621320215354&block= Britain card fraud hotspot of Europe
http://business.timesonline.co.uk/article/0,,9555-2463348,00.html
UK tops Europe for card fraud
http://www.finextra.com/fullstory.asp?id=16182
Britain branded 'card fraud capital'
http://www.itv.com/news/britain_f165620f56dccc8046e18397ebbdab8a.html Britons are Europe's biggest victims of card fraud
http://today.reuters.co.uk/news/articleinvesting.aspx?type=personalFinanceNews&storyID=2006-11-21T131131Z_01_NOA147403_RTRUKOC_0_FINANCIAL-FRAUD.xml&WTmodLoc=Business-C9-PF-2 UK banks face phishing chaos
http://www.computerweekly.com/Articles/2006/11/20/220024/UK+banks+face+phishing+chaos.htm
Phishing still hits banks and customers
http://www.crime-research.org/news/21.11.2006/2361/

then there is the old yes cards discussions and the generic issue with replay attacks when static authentication data is being used
https://www.garlic.com/~lynn/subintegrity.html#yescard

and related issue is that if there is authentication separate from the transaction ... the infrastructure can be exposed to man-in-the-middle attacks ... something that x9a10 financial standard working group spent some amount of time studying

shows up relatively recently in these posts
https://www.garlic.com/~lynn/2006v.html#26 Fighting Fraudulent Transactions
https://www.garlic.com/~lynn/2006v.html#27 Federal Rules May Not Fully Secure Online Banking Sites

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

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Future of CPUs: What's After Multi-Core?
Newsgroups: alt.folklore.computers
Date: Sun, 03 Dec 2006 15:25:45 -0700

jsavard writes:
I think that 64K-byte pages of contiguous memory *are* better than 4,096-byte pages of contiguous memory. Their cost is a limit on the number of general registers, but eight general registers of each type is not unreasonably low for a CISC architecture.

there were numerous issues ... 64k pages could cut down on TLB overhead vis-a-vis 4k pages ... as well as forcing disk pages to be in units of 64k blocks versus 4k blocks.

note however the "big pages" implementation in the early 80s ... used 4k page processor virtual memory hardware ... but did transfers in blocks of 3380 track ... i.e. ten 4k pages as a unit.

part of this is trade-off of the granularity of block size vis-a-vis efficiency use of possibly scarce real memory. as real memory became less and less scarce ... any inefficiency of real memory use because of larger block size was more than offset by efficiency of managing large amounts of memory in larger chunks.

we saw some of this sort of trade-off in the 70s with both 2k and 4k page sizes supported on 370. 2k page sizes was more efficient for smaller real storage configurations ... but as real storage became less and less of a constraint ... 4k page sizes could always outperform 2k page sizes.

then there is the whole page replacement strategy and the global vis-a-vis local LRU strategy.

there was also the whole thing circa 1980 in the local/global LRU war over somebody being able to get their phd ... based on having done work on global LRU .... old reference
https://www.garlic.com/~lynn/2001c.html#10 Memory management - Page replacement

and lots of collected posts on virtual memory, replacement algorithms, etc ...
https://www.garlic.com/~lynn/subtopic.html#wsclock

another optimization is doing a virtual address indexed cache ... vis-a-vis having to go thru TLB to resolve to a real address for cache index. references to old email describing 3090 cache having effectively both real address & virtual address indexes
https://www.garlic.com/~lynn/2003j.html#42 Flash 10208
https://www.garlic.com/~lynn/2006u.html#37 To RISC or not to RISC
https://www.garlic.com/~lynn/2006v.html#6 Reasons for the big paradigm switch

User Authentication

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: User Authentication
Newsgroups: alt.computer.security
Date: Mon, 04 Dec 2006 07:36:09 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:
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).
https://www.garlic.com/~lynn/subintegrity.html#secret

re:
https://www.garlic.com/~lynn/2006v.html#29 User Authentication

news article from today:

UN agency warns of online security risks
http://news.ninemsn.com.au/article.aspx?id=168199

from above:
Computer users who type in the same username and password for multiple sites - such as online banks, travel agencies and booksellers - are at serious risk from identity thieves, a United Nations agency said.

... snip ...

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

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: On sci.crypt: New attacks on the financial PIN processing
Newsgroups: alt.computer.security
Date: Mon, 04 Dec 2006 08:30:55 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:
then there is the old yes cards discussions and the generic issue with replay attacks when static authentication data is being used
https://www.garlic.com/~lynn/subintegrity.html#yescard

re:
https://www.garlic.com/~lynn/2006v.html#39 On sci.crypt: New attacks on the financial PIN processing

general class of harvesting/skimming authentication static data for various forms of replay attacks.
https://www.garlic.com/~lynn/subintegrity.html#secrets
https://www.garlic.com/~lynn/subintegrity.html#harvest

in the yes card scenario, some considered the chip worse than the magstripe cards that it replaced. a countermeasure in the standard financial account transaction is to flag the account and negate future (online) transactions. in the yes card scenario ... once the (counterfeit) yes card replayed the authentication static data, it was allowed to instruct the terminal to do an "offline" transaction. by the time the terminal finds out the account has been flagged, it is way too late. also when the "terminal" asked the (counterfeit) yes card if the entered PIN was correct, the yes card would always reply YES (part of the where the counterfeit card got its label yes card). As a result, the attacker doesn't even need to know the PIN.

in three-factor authentication model
https://www.garlic.com/~lynn/subintegrity.html#3factor
• something you have
• something you know
• something you are

normally in multi-factor authentication, the different factors are assumed to have independent vulnerabilities. A (something you know) PIN is countermeasure to lost/stolen (something you have) card. In the yes card scenario, an attacker just needs to harvest/skim the card "authentication" information (and/or trick a lost/stolen card into divulging the information). That information then can be loaded into a (counterfeit) yes card. Futhermore, while the account for a lost/stolen card can be reported and have the corresponding account flagged, since a (counterfeit) yes card can instruct the terminal to do an offline transaction, it defeats the effect of flagging the account.

some other recent items related to static data authentication and replay attacks
https://www.garlic.com/~lynn/2006v.html#29 User Authentication
https://www.garlic.com/~lynn/2006v.html#44 User Authentication

and

User agency warns of online security risks
http://news.ninemsn.com.au/article.aspx?id=168199
Warning over use of repeat passwords
http://www.hackinthebox.org/modules.php?op=modload&name=News&file=article&sid=21901
Warning over use of repeat passwords
http://www.theage.com.au/news/security/warning-over-use-of-repeat-passwords/2006/12/03/1165080812161.html
UN warns on password 'explosion'
http://news.bbc.co.uk/2/hi/technology/6199372.stm
Schumer warns on no-swipe credit cards
http://news.yahoo.com/s/ap/schumer_id_theft

now one of the countermeasures to the static data authentication and yes card vulnerability is to convert to some form of dynamic data authentication (like digital signatures). note however, that even "dynamic data authentication" may be vulnerable to a yes card man-in-the-middle attack if it is used for card authentication as opposed to transaction authentication, i.e. pair a counterfeit yes card with a valid lost/stolen card ... where the counterfeit yes card transparently passes the card authentication messages and then controls the rest of the session (when the terminal asks if the correct PIN was entered the yes card responds YES and when the terminal asks if it should do an offline transactions, the yes card also responds YES, and then when the terminal asks the yes card if the transaction is within the account credit limit, another YES; fraud slam/dunk).

recent related item
https://www.garlic.com/~lynn/2006v.html#26 Fighting Fraudulent Transactions

and of course x9.59 financial standard
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

other posts related to man-in-the-middle attacks
https://www.garlic.com/~lynn/subintegrity.html#mitm

Patent buster for a method that increases password security

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Patent buster for a method that increases password security
Newsgroups: sci.crypt,comp.security.misc,alt.computer.security
Date: Mon, 04 Dec 2006 10:02:33 -0700

Juuso Hukkanen <juuso_12_2003@tele3d.net> writes:
A cryptographically secure (one way) - hash algorithm could then be used in calculating a unique (hash-)password for the password+address combination string. Alternatively a unique (hash-) password could be made using by encrypting a password+address combination string with a symmetric encryption algorithm. For example, Internet browser software could automatically convert the user inserted (raw-)passwords into (hash-)passwords, and send those generated (hash-)passwords to online resource when the user presses submit-buton

similar hash strategies in OTP, RFC 2289 ... post discussing rfc 2289
https://www.garlic.com/~lynn/2006u.html#4 ssh - password control or key control?

RFC 2289 includes a server specific salt/value ... so that the same password could be used with multiple different servers.

note however that in RFC 2289 ... it also includes countermeasure to static data replay attack ... i.e. if the "same" hash value is always used to connect to the same system ... then in effect the hash value becomes the (static data) password, can be evesdropped and replayed.

the server doesn't know whether the user entered a password which was hashed and then transmitted ... or that an attacker evesdropped an transmitted hash ... and replayed the (evesdropped) hash.

note that in the above referenced post, RFC 2289 claims to be countermeasure to purely passive, evesdropping attacks (as well a end-user to utilize a static value password across multiple different servers) ... but is not resistant to active and/or man-in-the-middle attacks.

recent posts about shared-secret authentication, static data authentication vulnerabilities, etc.
https://www.garlic.com/~lynn/2006v.html#29 User Authentication
https://www.garlic.com/~lynn/2006v.html#33 New attacks on the financial PIN processing
https://www.garlic.com/~lynn/2006v.html#39 On sci.crypt: New attacks on the financial PIN processing
https://www.garlic.com/~lynn/2006v.html#42 On sci.crypt: New attacks on the financial PIN processing
https://www.garlic.com/~lynn/2006v.html#44 User Authentication
https://www.garlic.com/~lynn/2006v.html#45 On sci.crypt: New attacks on the financial PIN processing

Why so little parallelism?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why so little parallelism?
Newsgroups: comp.arch
Date: Mon, 04 Dec 2006 11:46:35 -0700

eugene@cse.ucsc.edu (Eugene Miya) writes:
Over lunch I did get the story of IBM's dumping of AI research in 1955-1956 from McCarthy (until the mid-80s). I wonder if it will appear in Wikipedia and history books? I think we want to go a little beyond the chewing gum walking stage. We can barely get a car to go 100 miles w/o a driver.

There was a development group in Menlo Park in the late 80s. I think it grew to a couple hundred people and some number of people from Stanford worked/consulted there.

My vague recollection was that the whole thing was eventually shutdown ... again it is from fading memory, but I believe the reason was over patent issues.

old email from somebody in the menlo park knowlege based group.

Date: 16 February 1988, 13:33:42 PST
To: wheeler

Lynn,

I am looking for pathlength guidelines for the interactive frontend (scrolling, window moving etc) for the knowledge based systems project. We currently think the pathlength for a scrolling operation may be as much as 40-50K instructions, and are concerned that will result in very sluggish operation on what we assume will be a loaded system (the knowledge processing itself should be compute bound and non-interactive.) Do you have any rules of thumb I can pass on to our developers?

Thanks for your help,

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

While the mvs/vtam pathlength may have been on that order ... the VM issue was different (the actual scroll pathlength was significantly less). A terminal I/O would have "boosted" the processing into the "interactive" queue ... where it would get around 100K instruction execution.

The long ago, original CP67 scheduler ... and the initial VM370 schedulers ... would just give absolute interactive priority "boost".

The fair share scheduler that I did as an undergraduate in the 60s for CP67 would change the granularity of the execution bursts based on interactive or background gueue ... however, the actual priority was based on recent resource utilization vis-a-vis target (the scheduler label came because the default "target" was fair share) ... aka a particular process's execution rate would be based on competition for the processor.

This was later re-introduced as the Resource Manager product for vm370.
https://www.garlic.com/~lynn/subtopic.html#fairshare
which also included a bunch of other features related to performance, like paging
https://www.garlic.com/~lynn/subtopic.html#wsclock

for some completely other drift ... the 23jun69 "unbundling" announcement started charging for application software (somewhat in response to various litigatioin by the gov. and others). however, the system/kernel software was still free ... based on the argument that it was required as part of operating the hardware (which the customer would have already paid for).

however, by the time it came along to release my resource manager ... attitudes was starting to change ... in part because of clone processors being able to take advantage of free kernel software. the resource manager was chosen to be the guinea pig for kernel software charging. misc. past posts mentioning unbundling and starting to charge for kernel software
https://www.garlic.com/~lynn/submain.html#unbundle

and for something completely different:

II03052: RERUN MAY CAUSE THE TERMINAL TO HANG WHEN USING A VCNA TERMINAL ON VM.
http://www-1.ibm.com/support/docview.wss?uid=isg1II03052

the Resource Manager actually had a bunch of (other) code having to do with reliability and eliminating all known cases of hung/zombie users .... some related posts here having to do with stress testing of the Resource Manager in preparation for product ship
https://www.garlic.com/~lynn/submain.html#bench

however, various later kernel work introduced new hanging problems.

actually there was some amount of work involving Sowa (when he was at IBM) and semantic networks in the 70s.
http://www.jfsowa.com/

and for other drift ... a page by sowa referencing john boyd
http://www.jfsowa.com/talks/challenge.htm

and then of course some number of past boyd posts
https://www.garlic.com/~lynn/subboyd.html#boyd
and various other boyd URLs from around the web
https://www.garlic.com/~lynn/subboyd.html#boyd2

Why so little parallelism?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why so little parallelism?
Newsgroups: comp.arch
Date: Mon, 04 Dec 2006 12:23:05 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:
actually there was some amount of work involving Sowa (when he was at IBM) and semantic networks in the 70s.
http://www.jfsowa.com/

re:
https://www.garlic.com/~lynn/2006v.html#47 Why so little parallelism?

i did some of the infrastructure work on the original relational/sql system/r implementation
https://www.garlic.com/~lynn/submain.html#systemr

part of it was based on the virtual memory management work referenced here
https://www.garlic.com/~lynn/2006v.html#36 Why these original FORTAN quirks?

porting from cp67 base to vm370 base. even tho the standard (vm370) product only released a small subset, the rest of the features were available internally.

at the same time i was doing various work on system/r, i also got involved in doing some of the infrastructure work on some of the Sowa-related semantic network stuff.

while some of the results was used in internal tools, it never reached a product stage.

in recent years, I've privately re-implemented some of the stuff from scratch.
https://www.garlic.com/~lynn/index.html

it is what I use to maintain the rfc index information
https://www.garlic.com/~lynn/rfcietff.htm

as well as the merged taxonomy and glossary information
https://www.garlic.com/~lynn/index.html#glosnote

Patent buster for a method that increases password security

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Patent buster for a method that increases password security
Newsgroups: sci.crypt,comp.security.misc,alt.computer.security
Date: Mon, 04 Dec 2006 14:33:30 -0700

Juuso Hukkanen <juuso_12_2003@tele3d.net> writes:
Yes, and all mail should be encrypted by now with PKI and there should not be un-canned spam because all receiving mail-servers should be requiring a small postage payment or forcing the sender to perform some time-consuming calculation. Yes, in ideal world things always happen completely and rapidly.

ref:
https://www.garlic.com/~lynn/2006v.html#46 Patent buster for a method that increases password security

part of the issue with certification authorities and PKI is that they tended to want money for what they did. another part was that they wanted to demonstrate some value in the digital certificate they produced. some of this from the early 90s was overloading x.509 identity certificates with personal information. by the mid-90s, it was starting to be realized that x.509 identity certificates, heavily overloaded with personal information represented significant liability and privacy issues. as a result, in the mid-90s you started to see some number of relying-party-only digital certificates ... just containing a public key and some account/record indicator ... lots of past posts mentioning relying-party-only digital certificates
https://www.garlic.com/~lynn/subpubkey.html#rpo

however, if you are doing real-time lookup in a repository for either information that previously and been in a digital certificate and/or any permission and/or authorization information ... then it was trivial to demonstrate that the digital certificate was redundant and superfluous.

the situation was then there was a big expensive (redundant and superfluous) PKI and digital certificate infrastructure that provided no added value.

an example was the original pk-init extension to Kerberos called for just replacing registration of a password with a public key. lots of past posts mentioning kerberos and/or pk-init
https://www.garlic.com/~lynn/subpubkey.html#kerberos

where the onfile public key was used to validate the digital signature (in lieu of comparing passwords). lots of past posts mentioning certificate-less mode of operation
https://www.garlic.com/~lynn/subpubkey.html#certless

however, there was a lot of pressure to also add PKI-mode of operation to the pk-init specification.

now, might be able to justify the cost of a big expensive PKI operation if you could eliminate any repository lookup as part of authentication/authorization ... i.e. all information (all identification along with all persmissions and all real time authorization) was carried in the stale, static digital certificate. However, if you need to have both a digital certificate AND a real-time respository access ... then, again, it is trivial to show that the PKI part is redundant and superfluous ... just carry the registered public key in the repository (along with all the other account/individual information).

possibly the two dominant authentication infrastructures in the internet world are kerberos and radius. a similar change to radius can be done with registering public keys (in lieu of passwords) and performing digital signature verification with onfile public keys w/o needing to deploy a separate, expensive, redundant and superfluous PKI infrastructure. misc. past posts mentioning radius public key operation
https://www.garlic.com/~lynn/subpubkey.html#radius

</very old topic>

part of the previous refs talk about dangers of session authentication vis-a-vis transaction authentication
https://www.garlic.com/~lynn/2006v.html#45 User Authentication
https://www.garlic.com/~lynn/2006v.html#26 Fighting Fraudulent Transactions

we were called into consult with this small client/server startup that wanted to do financial transaction transactions on their server
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

they had this technology called SSL that was targeted at "protecting" the financial transaction. Basically SSL was targeted at 1) countermeasure to man-in-the-middle attacks and 2) hiding the account number.

however, at the time this was starting ... one of the major vulnerabilities was account number harvesting by insiders

and "insiders" threats:
https://www.garlic.com/~lynn/2006v.html#2 New attacks on the financial PIN processing

and more "insider" threats:

now SSL #2 didn't affect this class of harvesting threats. lots of past posts about skimming/harvesting static data for replay attacks
https://www.garlic.com/~lynn/subintegrity.html#harvest

modulo that the resulting e-commerce created a large number of new transaction logs that had additional vulnerabilities ... in part it drastically reduced the cost of setting up a business ... and this business possibly had less money to spend on transaction log security ... old post about security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61

as to SSL #1, the countermeasure to man-in-the-middle attack was dependent on the user typing in a URL ... the browser contacts the server, the server returns a ssl domain name certificate ... which the browser verifies and then matches the typed in URL against the domain name in the server provided ssl domain name certificate (the server the user is talking to is the server that the user thinks they are talking to).

however, most merchant websites quickly found that using SSL for the whole shopping experience, cut their thruput by 80-90 percent. as a result the industry shifted to just using SSL for the check-out/payment part of the operation.

Now the merchant supplies a check-out/payment button that provides the URL to checkout. Now instead of browser checking the domain name certificate against the URL information provided by the user ... the browser is checking the server supplied domain name certificate against the server provided URL (and it probably takes a pretty dumb man-in-the-middle attack to supply a URL that is different than the domain name certificate that it was supplying, aka the server is the server, that the server claims to be).

lots of past posts about ssl domain name certificates
https://www.garlic.com/~lynn/subpubkey.html#sslcert

</very old topic>

part of the issue is it doesn't do much good to have a huge, complicated expensive additional business processes that actually provides little or no added value.

so the x9a10 financial standard working group was given the requirement to preserve the integrity of the financial infrastructure for all retail payments. the result was x9.59 financial standard
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

now from security PAIN acronym
P ... privacy (sometimes CAIN ... confidentiality)
A ... authentication
I ... integrity
N ... non-repudiation

SSL was being used to hide the account number, achieving security via privacy/confidentiality.

however, there are quite opposing requirements. since knowledge of the account number can be sufficient to perform a fraudulent transaction, the account number has to be kept hidden and never divulged. at the same time, the account number is required for a large number of different business processes ... and as a result has to be readily available. this led to my frequently repeated observation that the planet could be buried under miles of encryption and still not prevent account number leakage.

so what x9.59 financial standard did was require strong authentication and integrity for every transaction ... and a business rule that account numbers used in x9.59 could not be used in non-authenticated transactions. basically just knowing an account number was no longer sufficient to perform a fraudulent transaction ... and so it was no longer necessary to constantly keep the account number hidden; i.e. authentication and integrity replaced privacy to achieve security. x9.59 did nothing to prevent skimming/harvesting transactions ... but eliminated the risk/fraud associated with attacker (or insider) skimming/harvesting. </very old topic>

DOS C prompt in "Vista"?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: DOS C prompt in "Vista"?
Newsgroups: alt.folklore.computers
Date: Mon, 04 Dec 2006 15:44:27 -0700

hancock4 writes:
When you say "support", do you mean the VB programs will no longer run at all? What OS and vers of VB do you have that isn't working? (I have VB 4 and presume that will work, though I'm actually more worried about my much older Quick Basic Compiler.)

jan96 m'soft developers conference at moscone center ... had a bunch of stuff about internet ... but the constantly repeated theme and on all the banners was something about preserving your investment ... aka the m'soft developers worked in vs/basic ... and m'soft was promising to perserve and enhance vs/basic ... and continue to make extensive use of it in their infrastructures and products.

this contributed to the automatic scripting in various application files ... and a major evolving internet attack vector where malicious vs/basic scripts were included as part of various files arriving over the network for automatic execution.

in purely local area network, non-hostile, non-adversarial environment (aka closed business operations) it didn't represent much of a threat ... but moved to the wide-open internet environment ... it provided no countermeasures to hostile attacks.

lots of posts about all kinds of threats, exploits, vulnerabilities, and fraud
https://www.garlic.com/~lynn/subintegrity.html#fraud

Patent buster for a method that increases password security

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Patent buster for a method that increases password security
Newsgroups: sci.crypt,comp.security.misc,alt.computer.security
Date: Mon, 04 Dec 2006 20:17:26 -0700

Juuso Hukkanen <juuso_12_2003@tele3d.net> writes:
Thank you; there was a lot of interesting background and practical information for online authentication. You know, Google might any time soon be making an offer of you for their soon to be released service: Google ComputerSecuritySence. It would work like AdSence but when ever a Googler could be sensed to have a computer security related problem,... no broblem, Google's box would fetch relevant articles from your archives.

re:
https://www.garlic.com/~lynn/2006v.html#46 Patent buster for a method that increases password security
https://www.garlic.com/~lynn/2006v.html#49 Patent buster for a method that increases password security

as i've mentioned a number of times before ... the top 8-10 search engine web crawlers appear to use my pages as a regression test based on their high number of hits everyday. i've assumed it is because the extremely high ratio of hrefs per file ... especially in the ietf rfc index
https://www.garlic.com/~lynn/rfcietff.htm

and the merged taxonomy and glossaries
https://www.garlic.com/~lynn/index.html#glosnote

the merged security taxonomy and glossary has significant ratio of hrefs per mbytes ... but the merged financial taxonomy and glossary has over 35000 hrefs in about 3.5mbytes (avg. 10,000 hrefs per mbyte).

recent reference about some of the work
https://www.garlic.com/~lynn/2006v.html#47 why so little parallelism
https://www.garlic.com/~lynn/2006v.html#48 why so little parallelism

some other computer trivia ... gml markup language (precursor to sgml, html, xml, etc)
https://www.garlic.com/~lynn/submain.html#sgml

was invented by "g", "m", and "l" at the science center
https://www.garlic.com/~lynn/subtopic.html#545tech

in 1969. shortly after that, gml processing was added to the cms script document processor.

</lots of topic drift>

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

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is this true? (Were gotos really *that* bad?)
Newsgroups: alt.folklore.computers
Date: Tue, 05 Dec 2006 09:00:48 -0700

somewhat to return to the subject of programming

Bjarne Stroustrup on the Problems With Programming
http://it.slashdot.org/it/06/12/05/0045234.shtml
The Problem with Programming
http://www.techreview.com/InfoTech/17831/

and now for something completely different ... an old april 1st article
Date: 1apr91
Subject: I Knew It -- Nothing Could Be This Bad by Accident!

Creators Admit Unix, C Hoax
In an announcement that has stunned the computer industry, Ken Thompson, Dennis Ritchie and Brian Kernighan admitted that the Unix operating system and C programming language they created is an elaborate April Fools prank kept alive for over 20 years. Speaking at the recent UnixWorld Software Development Forum, Thompson gave these revelations:

In 1969, AT&T had just ended their work with the GE/Honeywell/AT&T Multics project. Brian and I had begun working with an early release of Pascal from Professor Nicklaus Wirth's ETH labs in Switzerland. We were impressed with its elegant simplicity and power. Dennis had just finished reading "Bored of the Rings", a National Lampoon parody of "Lord of the Rings", itself a parody, by philologist J.R.R. Tolkien. As a lark, we decided to do travesties of the Multics environment and Pascal. Dennis and I were responsible for the operating environment. We looked at Multics and designed the new system to be as complex and cryptic as possible to maximize casual users' frustration levels, calling it Unix as a satire on Multics, as well as other more risque allusions. Then Dennis and Brian worked out a truly warped version of Pascal, called 'A'. When we found others were actually attempting to create real programs with A, we quickly added additional arcane features and it evolved into B, BCPL and finally C. We stopped when we got a clean compile on the following syntax:

for(;P("\n"),R-;P("|"))for(e=C;e-;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);

To think that modern programmers would try to use a language that allowed such a statement was beyond our comprehension! We proposed selling this to the Soviets to set their computer science progress back 20 years or more. Imagine our surprise when AT&T and other US corporations actually began trying to use Unix and C! It has taken them 20 years to develop enough expertise to generate even marginally useful applications using this 1960's technological parody, but we are impressed with the tenacity (if not common sense) of the general Unix and C programmer. In any event, Brian, Dennis and I have been working exclusively in Pascal on the Apple Macintosh for the past few years and feel really guilty about the chaos, confusion and truly bad programming that have resulted from our silly prank so long ago.

Major Unix and C vendors and customers, including AT&T, Microsoft, Hewlett-Packard, GTE, NCR, and DEC refused comment at this time. Borland International, a leading vendor of Pascal and C tools, including the popular Turbo Pascal, Turbo C and Turbo C++, claimed they had suspected this for a number of years and would continue to enhance their Pascal products and halt further efforts to develop C. An IBM spokesman broke into uncontrolled laughter and postponed a hastily convened news conference concerning the fate of the RS/6000, an Australian workstation, merely volunteering "VM will be available Real Soon Now". Professor Wirth of the ETH institute, author of Pascal, Modula 2 and Oberon structured languages, limited his response to a Delphic statement that P.T. Barnum was correct.

In a related late-breaking story, usually reliable sources said that a similar confession may be forthcoming from Microsoft's William Gates concerning the MS-DOS and Windows operating environments. He is reported to have said ironically, "BASIC is not REXX". IBM spokesman deny Virtual Machine (VM) product is an internal prank gone awry.

Computer News of the World 1st April 1991

... snip ...

and of course, the last item is the new, 40yr old thing ... originally brought to you by the cambridge science center
https://www.garlic.com/~lynn/subtopic.html#545tech

previous, next, index - home