List of Archived Posts

2006 Newsgroup Postings (12/05 - 12/17)

Patent buster for a method that increases password security
IBM sues maker of Intel-based Mainframe clones
IBM sues maker of Intel-based Mainframe clones
IBM sues maker of Intel-based Mainframe clones
Patent buster for a method that increases password security
Patent buster for a method that increases password security
Is this true? (Were gotos really *that* bad?)
Why these original FORTRAN quirks?
Why these original FORTRAN quirks?
dcss and page mapped filesystem
long ago and far away, vm370 from early/mid 70s
long ago and far away, vm370 from early/mid 70s
more secure communication over the network
IBM sues maker of Intel-based Mainframe clones
IBM sues maker of Intel-based Mainframe clones
more secure communication over the network
intersection between autolog command and cmsback (more history)
Cache, TLB and OS
more secure communication over the network
Cache, TLB and OS
cluster-in-a-rack
SNA/VTAM for NSFNET
Are hypervisors the new foundation for system software?
Multiple mappings
IBM sues maker of Intel-based Mainframe clones
To RISC or not to RISC
Why so little parallelism?
Generalised approach to storing address details
IBM sues maker of Intel-based Mainframe clones
Descriptive term for reentrant program that nonetheless is
Does Public Key Authentication offer additional security over SSH/SFTP
Decimal FP
'Innovation' and other crimes
Decimal FP
Top versus bottom posting was Re: IBM sues maker of Intel-based Mainframe clones
Top versus bottom posting was Re: IBM sues maker of Intel-based Mainframe clones
What does a patent do that copyright does not?
What does a patent do that copyright does not?
Why so little parallelism?
Why so little parallelism?
Why so little parallelism?
Why so little parallelism?
vmshare
IBM sues maker of Intel-based Mainframe clones
more secure communication over the network
secure payment method
The Future of CPUs: What's After Multi-Core?
'Innovation' and other crimes
vmshare
Year-end computer bug could ground Shuttle
Does Public Key Authentication offer additional security over SSH/SFTP
Year-end computer bug could ground Shuttle
IBM sues maker of Intel-based Mainframe clones

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: Tue, 05 Dec 2006 09:38:05 -0700
Anne & Lynn Wheeler <lynn@garlic.com> writes:
<lots of topic drift> 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>


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
https://www.garlic.com/~lynn/2006v.html#51 Patent buster for a method that increases password security

and for even more topic drift about the latest, new, 40yr old thing

i built a lot of systems in the 60s (as an undergraduate) and 70s ... and it never occurred to build something that wasn't secure. it wasn't until much later that i found a lot of it to be prevailing use in certain quarters. minor ref:
https://web.archive.org/web/20090117083033/http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml

in the mid-70s the company got a new CSO ... these were the days when CSOs for major corporations frequently had backgrounds like retired secret service (or something similar). they tended to have a lot of physical security experience. for what ever reason, i got asked to run around with him for several months to help him learn about computer security.

minor security reference
https://www.garlic.com/~lynn/2006.html#11

somewhat akin to yes card vulnerability
https://www.garlic.com/~lynn/subintegrity.html#yescard

which appeared shortly after some chipcard deployments in the 90s ... but the above referenced scenario was approx. 25 years earlier i.e. compromise the system so that anything/everything is taken as valid pin/password

other somewhat related posts
https://www.garlic.com/~lynn/2006h.html#14
https://www.garlic.com/~lynn/2006n.html#2
https://www.garlic.com/~lynn/2006n.html#52
https://www.garlic.com/~lynn/2006t.html#38

IBM sues maker of Intel-based Mainframe clones

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: IBM sues maker of Intel-based Mainframe clones
Newsgroups: bit.listserv.ibm-main
Date: Tue, 05 Dec 2006 09:55:07 -0700
IBM sues maker of Intel-based Mainframe clones
http://www.eetimes.com/news/latest/showArticle.jhtml;jsessionid=BKMIXSNECXW0OQSNDLSCKHA?articleID=196601610

from above:
In its second major patent enforcement action in as many months, IBM is quietly suing an Intel-backed maker of computers that uses a version of IBM's high-end mainframe operating system reconfigured to run atop Intel's industry standard processors, InformationWeek has learned.

... snip ...

slightly related post mentioning unbundling
https://www.garlic.com/~lynn/2006v.html#47 Why so little parallelism?

IBM sues maker of Intel-based Mainframe clones

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM sues maker of Intel-based Mainframe clones
Newsgroups: bit.listserv.ibm-main
Date: Tue, 05 Dec 2006 16:20:49 -0700
Steve_Thompson_TW@ibm-main.lst (Thompson, Steve , SCI TW) writes:
The PCMs from a prior life all had to license patents from IBM and others. AMDAHL actually has/had patents that IBM had to as I recall. Then, I think, there were patents owned by NS (National Semi-Conductor), among others.

re:
https://www.garlic.com/~lynn/2006w.html#1 IBM sues maker of Intel-based Mainframe clones

the legal litigation led to unbundling announcement on 23jun69 ... and starting to charge for application software ... however, the argument was made that because kernel software was required to operate the hardware, it would still be offered for free.
https://www.garlic.com/~lynn/submain.html#unbundle

for recent post discussing this from slightly different perspective
https://www.garlic.com/~lynn/2006v.html#47 Why so little parallelism?
https://www.garlic.com/~lynn/2006v.html#48 Why so little parallelism?

the clone/pcm controllers were somewhat the motivation behind the failed future system project in the early 70s
https://www.garlic.com/~lynn/submain.html#futuresys

specific reference:
https://www.ecole.org/en/session/49-the-rise-and-fall-of-ibm
https://www.ecole.org/en/session/49-the-rise-and-fall-of-ibm

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

... snip ...

some past posts about having helped build clone controller as an undergraduate in the 60s ... and some article blaming four of us for (some part of) the clone controller market
https://www.garlic.com/~lynn/submain.html#360pcm

however, the appearance of the clone processors in the 70s ... was somewhat motivation behind starting to charge for kernel software ... and my resource manager got selected to be the guinea pig for kernel software charging ... and i got to spend quite a bit of time with business and pricing people working out the details.
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock

note, i've in the past conjectured that the future system project may have helped give rise to clone processors. Amdahl gave a seminar at MIT in the early 70s ... and got a lot of questions about his leaving and getting the backing to start his mainframe processor business. He made some statement about even if IBM were to completely walk away from 360/370 (which could be considered a veiled reference to future system project), there was already something like $100b ($200b?) in 360 application software which would keep clone processor business going thru the end of the century.

IBM sues maker of Intel-based Mainframe clones

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM sues maker of Intel-based Mainframe clones
Newsgroups: bit.listserv.ibm-main,alt.folklore.comptuers
Date: Wed, 06 Dec 2006 15:00:55 -0700
"Phil Payne" <phil@isham-research.co.uk> writes:
The same idea was used in Itel's EXTEND product. This allowed you to run /370 operating systems on /360s - it both emulated the /370 instructions and recognised channel presentation of a control unit request for command retry (x'4A' in the status byte - Device End, Channel End and Status Modifier, if memory serves).

re:
https://www.garlic.com/~lynn/2006w.html#1 IBM sues maker of Intel-based Mainframe clones
https://www.garlic.com/~lynn/2006w.html#2 IBM sues maker of Intel-based Mainframe clones

the first was the cp67 h/i joint project between cambridge science center
https://www.garlic.com/~lynn/subtopic.html#545tech

and endicott. the "cp67h" modifications was to add option that allowed cp67 to emulate 370 virtual machines (with 370 hardware relocate) as oppsed to 360/67 virtual memory virtual machines (tables, control registers and some of the instructions were different).

the "cp67i" modifications was to create cp67 kernel that would run on 370 hardware relocate instead of 360/67 hardware relocate.

the "cp67i" was up and running (in virtual machine) a year before endicott had the first engineering model 370 with hardware relocate operation ... in fact, running cp67i on the hardware was one of the tests for the hardware.

the story is that the initial boot of cp67i on the engineering machine failed. after some diagnostic ... it turned out that the engineers had reversed the (hardware) implementation of two of the "B2" opcodes. cp67i was quickly patched to reflect the (incorrect) hardware ... and then proceeded to boot and run successfully.

this was one of the early HONE capabilities ... allowing for testing various 370 code under HONE (running cp67 on 360/67) ... HONE was the vm370 (originally cp67) based world-wide infrastructure supporting marketing, sales, and field people
https://www.garlic.com/~lynn/subtopic.html#hone

two people from san jose came out and did the enhancements to cp67i to support rps, block mux, 3330 and 2305 devices support ... "cp67i" with the 3330/2305 device support was referred to as "cp67sj".

the other issue that cambridge had was that 370 virtual memory was a deep, dark corporate secret ... and the 370 support was running in cambridge long before any announcement. cambridge had number of non-employees using the system, including various students from colleges and univ. in the boston area. as a result, the "cp67h" system was run in a 360/67 virtual machine under the standard "floor" cp67 system (keeping it away from the prying eyes of the uninitiated). The "floor" cp67 system was heavily modified ... somewhat referred to in these posts
https://www.garlic.com/~lynn/2006v.html#36 Why these original FORTRAN quirks?
https://www.garlic.com/~lynn/2006w.html#0 Patent buster for a method that increases password security

but the modifications supporting virtual 370 were kept separate.

misc. past posts referring to cp67h, cp67i, cp67sj, etc.
https://www.garlic.com/~lynn/2002j.html#0 HONE was .. Hercules and System/390 - do we need it?
https://www.garlic.com/~lynn/2004b.html#31 determining memory size
https://www.garlic.com/~lynn/2004p.html#50 IBM 3614 and 3624 ATM's
https://www.garlic.com/~lynn/2005g.html#17 DOS/360: Forty years
https://www.garlic.com/~lynn/2005j.html#50 virtual 360/67 support in cp67
https://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
https://www.garlic.com/~lynn/2006e.html#7 About TLB in lower-level caches
https://www.garlic.com/~lynn/2006f.html#5 3380-3390 Conversion - DISAPPOINTMENT
https://www.garlic.com/~lynn/2006l.html#21 Virtual Virtualizers
https://www.garlic.com/~lynn/2006o.html#19 Source maintenance was Re: SEQUENCE NUMBERS
https://www.garlic.com/~lynn/2006q.html#1 Materiel and graft
https://www.garlic.com/~lynn/2006q.html#45 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006q.html#49 Was FORTRAN buggy?

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: Wed, 06 Dec 2006 15:51:11 -0700
Anne & Lynn Wheeler <lynn@garlic.com> writes:
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.

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

even more drift related to static authentication data being vulnerable to various kinds of skimming/harvesting attacks

Fast Payments creates strong case for two-factor authentication, says Thales
http://www.finextra.com/fullstory.asp?id=16240
Banks lobby govt on smartcard
http://www.hackinthebox.org/modules.php?op=modload&name=News&file=article&sid=21919

British Banks keep a secret..
http://www.zone-h.org/content/view/14404/31/
Banks reluctant to reveal full extent of online fraud
http://www.e-consultancy.com/news-blog/362293/banks-reluctant-to-reveal-full-extent-of-online-fraud.html
Newspaper Says UK Banks Fail to Report Online Fraud
http://www.epaynews.com/index.cgi?survey=&ref=browse&f=view&id=1165410908213202145191&block=

Smart Card Alliance slams RFID use in US passport card program
http://www.cbronline.com/article_news.asp?guid=88914D85-0D0F-47D2-AEC2-45B457496214
Industry group urges caution on U.S. plan for RFID-enabled ID cards
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9005675&intsrc=hm_list
RFID Sabotages Privacy, Says Government Watchdog
http://www.rfidnews.org/weblog/2006/12/05/rfid-sabotages-privacy-says-government-watchdog/
US government warned off RFID passports
http://www.techworld.com/security/news/index.cfm?newsID=7513&pagtype=all
Smart Card Alliance Cautions Feds on RFID Cards
http://www2.csoonline.com/blog_view.html?CID=27237

Flaw exploited in RFID-enabled passports
https://www.garlic.com/~lynn/aadsm25.htm#46
Flaw in RFID-enabled passports (part 2?)
https://www.garlic.com/~lynn/aadsm26.htm#0

Note one of the issues related to yes card bank chipcard exploits
https://www.garlic.com/~lynn/subintegrity.html#yescard

was that it used static data for authentication. this made it vulnerable to harvest/skimming and replay attacks (not too different from magstripe harvest/skimming with replay attacks using counterfeit cards).

however, the big additional vulnerability introduced with the bank chipcard exploits, was that the terminal, after initially verifying the chips (static) authentication data ... would then "obey" the cards' instructions ... which gave rise to the yes card label.

When the terminal asked if the entered PIN was correct, a counterfeit yes card would always answer YES, minor digression
https://www.garlic.com/~lynn/2006w.html#0 Patent buster for a method that increases password security

And when the terminal asked if the transaction should be offline, the counterfeit yes card would always answer YES, and when the terminal then asked if the transaction was within the account credit limit, the counterfeit yes card would again answer YES.

In some of the bank chipcard deployments ... after the appearance of some of the counterfeit yes cards (in earlier deployments in the 90s), some made the decision to only issue valid cards that only did online transactions (and never opted for offline operation, perceiving it to be a countermeasure to yes card attack).

However, these were highly card-centric operations ... and didn't understand that the counterfeit yes card attacks weren't attacks on the card ... but attacks on the terminal. It was still possible to skim the static authentication data from such cards, load it into a counterfeit yes card, and program the counterfeit yes card to tell the terminal that the correct pin was entered and to do offline transaction.

The problem is that the standard countermeasure for skimmed counterfeit (and/or lost/stolen) cards is to disable the account. However, when a terminal does an offline transaction, there is no communication to find out that the acocunt has been disabled until way after the fraud has occurred. The appropriate countermeasure to the yes card exploits wasn't to program valid cards to only do online transactions, the appropriate countermeasure to the yes card exploits was to program terminals to never do offline transactions (i.e. it was an attack on terminals not attacks on cards).

Sen. Schumer Decries Dangers of 'No-Swipe' Credit Cards
http://www.foxnews.com/story/0,2933,234586,00.html
Sen. Schumer Calls For Better Contactless Payment Security
http://www.cardtechnology.com/article.html?id=20061206O8ZLO98Q
Would You Trust RFID-Enabled ATM Cards?
http://ask.slashdot.org/askslashdot/06/12/06/0532242.shtml
Would You Trust RFID-Enabled ATM Cards?
http://ask.slashdot.org/article.pl?sid=06/12/06/0532242
Possible Serious Security Flaw In ATMs
http://it.slashdot.org/it/06/11/30/2139235.shtml?tid=187

So if bank cards continue to use static authentication data, they continue to be vulnerable to harvest/skimming exploits ... and contactless/wireless communication may increase the opportunities for attackers to record static authentication data.

Note however, there may still be other vulnerabilities even in any upgrade from static to dynamic authentication data. This is the scenario whether the card is being authenticated or is the transaction being authenticated.
https://www.garlic.com/~lynn/2006v.html#26 Fighting Fraudulent Transactions

the scenario with card authentication ... is that even with dynamic authentication data, it may still be vulnerability to a yes card MITM-attack where a yes card is paired with a lost/stolen card (or any valid card obtained by any means).

The counterfeit yes card transparently passes the card authentication messages ... but then takes over the rest of the communication to perform the YES answers to the three terminal questions 1) correct PIN, 2) offline transaction, 3) within credit limit.
https://www.garlic.com/~lynn/subintegrity.html#mitm

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: Thu, 07 Dec 2006 08:45:36 -0700
Anne & Lynn Wheeler <lynn@garlic.com> writes:
So if bank cards continue to use static authentication data, they continue to be vulnerable to harvest/skimming exploits ... and contactless/wireless communication may increase the opportunities for attackers to record static authentication data.

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

note that the purpose of disabling the account (as a fraudulent transaction compromise), is paradigm where the account number has frequently been the primary method of authentication i.e. knowing the account number as something you know authentication ... from 3-factor authentication model
https://www.garlic.com/~lynn/subintegrity.html#3factor

something you have
something you know
something you are

aka you frequently see fraud compromise being dealt with by issuing a new card which also carries a new account number (the old account number having been flagged).

in the x9.59 standard, the paradigm is changed to transaction authentication; and therefor it is no longer necessary to disable the account number (as a fraud compromise countermeasure) ... it is only necessary to disable the specific compromised authentication (i.e. say specific lost/stolen card with its corresponding something you have authentication).
https://www.garlic.com/~lynn/2006v.html#26 Fighting Fraudulent Transactions

since all valid, authorized x9.59 transactions require the appropriate authentication.
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

incoming transactions are recognized as appropriately authenticated, by the correct transaction authentication data, not by the account number.

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: Thu, 07 Dec 2006 09:05:47 -0700
Anne & Lynn Wheeler <lynn@garlic.com> writes:
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/


re:
https://www.garlic.com/~lynn/2006v.html#52 Is this true? (Were gotos really *that* bad?)

and now

More Trouble with Programming
http://www.technologyreview.com/InfoTech/17868/

from above:
The first part of this interview engendered such debate in the comments section of our site, as well as on aggregator sites like Slashdot, that Technology Review chose to address some of the objections to C++ raised by readers.

... snip ...

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, 07 Dec 2006 17:03:25 -0700
Status report on project activities mentioned in email from 12dec73 in this post
https://www.garlic.com/~lynn/2006v.html#36 Why these original FORTRAN quirks?

involving porting various functions that had been implemented in cp67 with additional enhancements.

shortly after this email was written, I enhanced the PAM filesystem support so for "small" files (with only a single data block) for the FST to point directly at the data block rather than the FST point at a (200 byte) hyperblock ... which in turn pointed at the data block. This not only cut the physical disk space requirement in half (for small files), but also allowed them to be accessed in a single disk operation, rather than having to first access the hyperblock.

The changes to move the EXEC command processer and the CMS editor (and other functions) into a shared segment was later picked up for vm370 release 3 and called DCSS. However, DCSS only incorporated a very small subset of the CSC/VM virtual memory management changes, i.e. for instance shared segments could only be loaded at fixed location (could not float or be relocated) and w/o page mapped file system support, the ability to directly map executable images ("MODULE") in the CMS filesystem to shared segments was lost.

past discussions of cms page mapped file system support
https://www.garlic.com/~lynn/submain.html#mmap

Date: Jan. 2, 1975
From: wheeler
Subject: CSC/VM SYSTEM STATUS

This is to bring you up to date on the current status of the CSC/VM system. The updates to create the CSC/VM system have been converted to the latest system available from Burlingtion, Release 2, PLC9/ICR, with R22 monitor/THI support.

Completed and in production use are the scheduling /dispatching /paging changes described in C.S.C. report; Also running in production use is multiple shared system/segments. We currently only have a test version of VM/APL which makes use of the extended sharing support. By the end of January the test VM/APL should become the standard production version. A minor CMS change has been made to support an alternate module format. This was necessary to support shared modules, like VM/APL.

Also in the production system is the CP support for a Paging Access Method (PAM). Unfortunately PAM has one drawback; some of the bits in the CP SWAPTABLE have been redefined and are in conflict with the VMA microcode support. I consider the VMA microcode change to support PAM to be minor. In addtion such a modified VMA would be completly transparent to distributed versions of VM/370.

Undergoing final production testing are page and swap table migration, both of which have been described in C.S.C. report. Swap table migration involves the writing of some of the page management tables onto disk and freeing up the main storage that they occupied. Page migration has been generalized over the drum to disk page migration described in the report to handle all preferred paging areas. Page migration will move low refererenced pages from the preferred paging areas to non-preferred areas. Additional changes are being made to page allocation on preferred paging disks to distribute pages evenly across all disks of the same type.

A version of CMS/PAM is undergoing testing, but it has a drawback of requiring a minimum of two 4k page records for each file. The first 4k record contains a 200 byte file control information record and the rest is unused. This implementation puts a high price on users with many small files. (A 5 cylinder 3330 PAM area will contain a maximum of 140 files compared to the current maximum of about 700 files). Advantages include a five fold increase in maximum file size and mini-disk size (a full 3330-11 disk accessible as one mini-disk). Also a mini-disk is supported on any device that CP supports for paging, including the 2305 drum. The current implementation involves few CMS changes and continues to support the current mini-disk formats. For large system users it becomes possible (and feaseable with page migration) to use part of a 2305 drum for a CMS system disk. The most higly used parts of the CMS system disk will fit in 1000 page records (about the equiv. of 20 3330 cylinders) which is about 40 per-cent of the drum.

The increase in the CMS nucleus size will enable highly used modules, like the EXEC processor and the EDITOR, to be placed in a shared nucleus segment. This implementation will be transparent to current user programs. During CMS ipl the additional nucleus segments will be relocated (via a VMM diagnose function) to the end of the user's virtual machine memory.


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

The "relocation" of shared segments (having the same r/o, protected shared segments appear at different virtual addresses in different virtual address spaces) has been discussed in some past posts ... collection of those posts are pointed to here
https://www.garlic.com/~lynn/submain.html#adcon

The items mentioned as "swaptable migration" and "page migration" was released as part of my "resource manager".
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock

Other posts regarding the cambridge science center
https://www.garlic.com/~lynn/subtopic.html#545tech
https://www.garlic.com/~lynn/subtopic.html#cscvm

And various posts mentioning APL (&/or the HONE system)
https://www.garlic.com/~lynn/subtopic.html#hone

CSC/VM posts
https://www.garlic.com/~lynn/submisc.html#cscvm

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, 07 Dec 2006 18:39:22 -0700
Attached is overview for CSC/VM system distribution (from 1975, sent out to a large number of internal locations). In the past, I've semi-facetiously joked that at one point I was directly distributing to as many (internal) locations (from the 4th flr, 545 tech sq) as there were total Multics installations (from the 5th flr, 545 tech sq) during its whole lifetime.
https://www.garlic.com/~lynn/subtopic.html#545tech csc/vm (&/or sjr/vm) posts
https://www.garlic.com/~lynn/submisc.html#cscvm

recent refs
https://www.garlic.com/~lynn/2006v.html#36 Why these original FORTRAN quirks?
https://www.garlic.com/~lynn/2006w.html#7 Why these original FORTRAN quirks?

also, another distribution memo from a couple years later:
https://www.garlic.com/~lynn/2006u.html#26 Assembler question

The distribution overview also makes mention of including SPM from POK which is referenced here
https://www.garlic.com/~lynn/2006k.html#51 other cp/cms history

In the above reference, there is a
copy of old email making mention that an "official" copy of SPM had been distributed to me on 8/12/75. However, as can be seen in the following 4/30/75 overview, I had included an "unofficial" version of SPM in my distribution much earlier in the year.

Date: 4/30/75
From: wheeler
Subject: CAMBRIDGE VM/370 SYSTEM (based on vm rel2, plc15)

Contained on the Cambridge VM/370 distrubution tape is a set of updates which provide performance and functional enhancements to CP-CMS. File 1 contains CP changes. They compromize a set of updates to existing CP source and macros. Also included are new source files, new cntrl, and a new load exec.

File 2 contains changes and additions to CMS and CMS/APL. File 3 contains CMS changes to support disks in paging access method (PAM) format.

Detailed documentation for any of these changes will probably not be forthcoming for some time. Reference will have to be made to the individual changes for a description of how they work. For instance, the CP support for page migration is almost totally contained in the new module DMKPGM. The CP support for PAM is contained in DMKPAM. The installation of the changes from file 1 should prove to be relatively easy. They are essientially a 'black box' addition to the existing system. If none of the new functions are to be utilized, then all that is required is a reassembly of the affected modules. No understanding of their operation is necessarily reqired.

IMPORTANT: The VIRT=REAL option has never been tested and probably contains many bugs. Also SET FAVORED with a per-centage has not been implemented.

In file 1, there are UPDTC001 and UPDTSPM update files and AUXCMB files for DMK modules and new assemble files. There are also changes to maclib files. The CMB CNTRL and CMBLOAD EXEC are the control file and load list. Also included is a CMBMAC MACLIB which contains the updated macros. These changes comprise support for the following enhancements; 1) fair share scheduler, 2) shared module support, 3) paging access method (PAM), 4) page migration, 5) the autolog command and 6) the special message function from POK.

File 2 also contains optional CP changes for new page device format. The updates are UPDTCV3 and are applied after CMB. DMKFMT UPDTCV3 changes the spacing between records on the paging and spooling devices (3330 to 110 bytes and 2305-2 to 500 bytes). DMKPAG UPDTCV3 contains changes to specify the corresponding sector addresses. These are included for compatability with the previous CSC/VM release. The performance problems which lead to the increased spacing have been rectified with PLC-15.


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

The six major items listed in the above
1) fair share scheduler (later shipped in my resource manager product)
2) shared module support (extremely small subset shipped in vm370 release 3 as DCSS)
3) paging access method (not shipped in standard product)
4) page migration (shipped in my resource manager)
5) autolog command (shipped in vm370 release 3)
6) the special message function from POK


I had originally created the autolog command as part of automating benchmarks (along with the feature that automatically started processes at initial boot)
https://www.garlic.com/~lynn/submain.html#bench

however, the feature proved so useful for general vm370 operations, it eventually came into wide use as part of standard processing and was shipped in the standard release 3 vm370 product.

again, lots of past resource manager posts
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock

The fair share scheduler, including various paging and performance items, I had originally created as enhancements to cp67 as an undergraduate in the 60s. Many of the features had been dropped in the morph from cp67 to vm370. However, by the time, the resource manager was ready to ship, I had added an implementation supporting "SET FAVORED".

CSC/VM posts
https://www.garlic.com/~lynn/submisc.html#cscvm

dcss and page mapped filesystem

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: dcss and page mapped filesystem
Newsgroups: bit.listserv.vmesa-l
Date: Thu, 07 Dec 2006 19:06:28 -0700
Anne & Lynn Wheeler <lynn@garlic.com> writes:
the real, original "old way" was with cms & cp supporting cms page mapped filesystem ... that I had originally done on cp67 and then ported to vm370. with page mapped filesystem ... then it was straight forward to have all sort of shared segment feature/function mapped directly to the stuff in cms filesystem.

they decided to pickup a very small piece of the cms & cp changes for vm370 release3 and call it DCSS ... lots of past posts with much more detailed description
https://www.garlic.com/~lynn/submain.html#mmap


some old cp/cms email from early and mid-70s mentioning original development
https://www.garlic.com/~lynn/2006v.html#36 Why these original FORTRAN quirks?
https://www.garlic.com/~lynn/2006w.html#7 Why these original FORTRAN quirks?
https://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?

long ago and far away, vm370 from early/mid 70s

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: long ago and far away, vm370 from early/mid 70s
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers
Date: Thu, 07 Dec 2006 20:21:43 -0700
Concurrent with the benchmarking, shared segment, page mapped filesystem, resource manager, and other misc. stuff referred to in these posts
https://www.garlic.com/~lynn/2006v.html#36 Why these original FORTRAN quirks?
https://www.garlic.com/~lynn/2006w.html#7 Why these original FORTRAN quirks?
https://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?
https://www.garlic.com/~lynn/2006w.html#9 dcss and page mapped filesystem

I was also at the same time doing a lot of the work on VIRGIL/TULLY (138/148) and ECPS
https://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist
https://www.garlic.com/~lynn/94.html#27 370 ECPS VM microcode assist
https://www.garlic.com/~lynn/94.html#28 370 ECPS VM microcode assist

and at the same time doing system and microcode design for VAMPS, a five-way multiprocessor effort ... collected past posts mentiong VAMPS
https://www.garlic.com/~lynn/submain.html#bounce

For some reason, the product people responsible for both VIRGIL/TULLY and VAMPS somewhat viewed the other as competing products; even though i was doing much of the design for both products. There were some corporate product escalation meetings where I was expected to sit on both sides of the table simultaneously and argue it out with myself. VIRGIL/TULLY shipped, but VAMPS was canceled.

Date: August 27, 1975
Memo to: Endicott
cc: wheeler
Subject: Simplifying Technical Considerations for VAMPS

References:
1) Technical Review of VAMPS Proposal by KKKKKK and WWWWW dated 8/5/75
2) Update of above dated 8/21/75

As you pointed out last week during the Boeblingen Technical Review sessions, the VAMPS schedule is a critical PSE factor.

During these sessions it became evident that the technical considerations of the original VAMPS proposal had not been fully adjusted to account for a marketing strategy similar to that for the VIRGIL/TULLY VM proposal.

As described in the Attachment, this revised marketing strategy for VAMPS provides a number of technical simplifications. These simplifications are being proposed for resource and schedule reasons and not for reasons of technical feasibility.

While the possible tradeoffs that these simplifications could allow in the major redesign MSC and dispatcher areas are not clear, the significant reduction in the total number of changes should not only alleviate the resources required, but also possibly the schedule due to the reduction in dependencies and testing.

If the VAMPS forecast look promising early in September, a more detail technical design review of the MSC and dispatcher areas should be immediately arranged in Boeblingen after which more accurate resource and schedule estimates can be derived.


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

long ago and far away, vm370 from early/mid 70s

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: long ago and far away, vm370 from early/mid 70s
Newsgroups: alt.folklore.computers,bit.listserv.vmesa-l
Date: Fri, 08 Dec 2006 16:18:18 -0700
ref:
https://www.garlic.com/~lynn/2006w.html#10 long ago and far away, vm370 from early/mid 70s

while only a small subset of the virtual memory management stuff was released as DCSS vm370 ... and none of the cms paged mapped filesystem stuff ... a little more of the virtual memory management stuff was used for the original relational/sql implementation in system/r ..... which provided r/w (unprotected) shared segments between semi-privileged processes (different system/r database tasks running in different virtual address spaces).

misc. past posts mentioning system/r work
https://www.garlic.com/~lynn/submain.html#systemr

It was also part of the technology transfer of system/r to endicott for what was to become sql/ds. This addition feature took on the name DWSS (or dynamic writeable shared segments) ... and there was lots of issues on whether or not it impacted ECPS and microcode on existing customer machines.

recent posts mentioning system/r and DWSS
https://www.garlic.com/~lynn/2006t.html#16 Is the teaching of non-reentrant HLASM coding practices ever defensible?
https://www.garlic.com/~lynn/2006t.html#39 Why these original FORTRAN quirks?

recent posts on early virtual memory management stuff (a small subset which was going to be released as DCSS in vm370 release 3)
https://www.garlic.com/~lynn/2006v.html#36 Why these original FORTRAN quirks?
https://www.garlic.com/~lynn/2006w.html#7 Why these original FORTRAN quirks?
https://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?
https://www.garlic.com/~lynn/2006w.html#9 dcss and page mapped file system

i also worked on a semantic network related activity about the same time as the system/r stuff which used more of the virtual memory management and page mapped technology ... recent reference
https://www.garlic.com/~lynn/2006v.html#48 Why so little parallelism?

more secure communication over the network

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: more secure communication over the network
Newsgroups: alt.folklore.computers,bit.listserv.vmesa-l
Date: Fri, 08 Dec 2006 20:28:20 -0700
In the following, CJNTEL was an online corporate directory that I had initially put up on SJRLVM1 that could be queried by anybody on the internal network.

The following has a suggestion for registering a person's public key with CJNTEL and making (effecitvely publishing) it available for retrieval by anybody with access to the internal network.

following is some 15 years or so before being brought in to do some consulting with a small client/server startup that wanted to do payment transactions on their server
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

Date: 05/15/81 13:41:12
To: wheeler
re: more secure communication over the network

One of the obvious concerns that will surely surface from the CJN work will be the problem of confidential information being exchanged over the network.

I have a package from ****** called CRYPT that may be a solution. The package implements a public key encryption system proposed by Diffie and Hellman (see recent vm newsletter). The problem we have with using CIPHER is that we must know an agreed upon key and we have to exchange the key in a secure manner prior to communication.

The public key system works as follows: I publish a key which anyone can look up. They use that key to CRYPT the file. That key can only "lock the safe". In order to DECRYPT the file ("unlock the safe") I have a private key which no-one knows. Only the private key can unlock the safe.

As an implementation I suggest we update out CJNTEL entry to include a public key for each of us. The package includes a procedure for generating keys. In this way I can look up your key in CJNTEL and send you ENCRYPTED confidential data.

Cheap and simple.


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

effectively certificate-less public key operation ... misc. past posts mentioning certificate-less public key operation
https://www.garlic.com/~lynn/subpubkey.html#certless

and somewhat similar to the discussion about publishing public keys in the domain name infrastructure ... a few posts this year discussing the subject:
https://www.garlic.com/~lynn/2006b.html#37 X.509 and ssh
https://www.garlic.com/~lynn/2006c.html#10 X.509 and ssh
https://www.garlic.com/~lynn/2006c.html#34 X.509 and ssh
https://www.garlic.com/~lynn/2006c.html#35 X.509 and ssh
https://www.garlic.com/~lynn/2006c.html#38 X.509 and ssh
https://www.garlic.com/~lynn/2006d.html#29 Caller ID "spoofing"
https://www.garlic.com/~lynn/2006f.html#16 trusted repositories and trusted transactions
https://www.garlic.com/~lynn/2006f.html#32 X.509 and ssh
https://www.garlic.com/~lynn/2006f.html#33 X.509 and ssh
https://www.garlic.com/~lynn/2006f.html#34 X.509 and ssh
https://www.garlic.com/~lynn/2006h.html#27 confidence in CA
https://www.garlic.com/~lynn/2006p.html#7 SSL, Apache 2 and RSA key sizes
https://www.garlic.com/~lynn/2006t.html#8 Root CA CRLs
https://www.garlic.com/~lynn/2006v.html#49 Patent buster for a method that increases password security

as well as the whole account authority digital signature stuff
https://www.garlic.com/~lynn/x959.html#aads

... CJNTEL is different than the internal "online telephone book" recently mentioned here
https://www.garlic.com/~lynn/2006v.html#32 Effi[ci]ency of branch table vs individual compare & branch

the internal online telephone book captured the original source from various corporate locations (that were used to generate the printed copy), converted the source to desired format and made them available for distribution. this normally was loaded on local systems that allowed users to do online lookups on their local machine.

CJNTEL could be accessed remotely over the internal network using "special message" ... misc. past posts about the internal network ... which was larger than the arpanet/internet from just about the beginning until sometime mid-85.
https://www.garlic.com/~lynn/subnetwork.html#internalnet

note that the above reference is in addition to the requirement that all links leaving corporate facilities required link encryptors ... at one point there was the claim that the internal network had move than half of all link encryptors in the world.

misc. recent posts mentioning special message
https://www.garlic.com/~lynn/2006k.html#51 other cp/cms history
https://www.garlic.com/~lynn/2006t.html#47 To RISC or not to RISC
https://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?

We did do a modification to CJNTEL so that in addition to doing various operations on its corporate directory, it was also possible (for remote network user) to request CJNTEL to execute the telephone directory command on SJRLVM1 ... returning the results over the network.

for some topic drift ... some references to the hsdt (high speed data transport) project
https://www.garlic.com/~lynn/subnetwork.html#hsdt

and some recent posts about various interactions with NSF:
https://www.garlic.com/~lynn/2006s.html#50 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006t.html#6 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006u.html#56 Ranking of non-IBM mainframe builders?

IBM sues maker of Intel-based Mainframe clones

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM sues maker of Intel-based Mainframe clones
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
To: <ibm-main@bama.ua.edu>
Date: Sat, 09 Dec 2006 08:51:05 -0700
lefuller@SBCGLOBAL.NET (Lloyd Fuller) writes:
Ahh. But UDB DB2 for Windows does not equal DB2 for z/OS (or z/VM either). They are different products that share some but not all of the same syntax. They re-act different to some commands and have different "flavors" of what is and is not allowed.

I can not develop on UDB DB2 for Windows or Linux or what have you, and be sure that it will run on DB2 for z/OS.


original post kicking off this thread:
https://www.garlic.com/~lynn/2006w.html#1 IBM sues maker of Intel-based Mainframe clones
and then a couple more:
https://www.garlic.com/~lynn/2006w.html#2 IBM sues maker of Intel-based Mainframe clones
https://www.garlic.com/~lynn/2006w.html#3 IBM sues maker of Intel-based Mainframe clones

various past posts about original relational/sql implementation and technology transfer from sjr to endicott for sql/ds
https://www.garlic.com/~lynn/submain.html#systemr

most recent comment in this post
https://www.garlic.com/~lynn/2006w.html#11

one of the people in this meeting claimed to have handled the technology transfer from endicott back to stl for DB2 (i.e. sort of long way around since SJR and STL were only about 10 miles apart, i use to ride it on my bike).
https://www.garlic.com/~lynn/95.html#13
https://www.garlic.com/~lynn/96.html#15

i.e. mainframe implementation done in PLS.

The other rdbms project was later done in toronto as portable rdbms in C and went thru a number of code names, at least shelby, persist, and crosswinds

a couple past posts mentioning the "other" db2, shelby, etc. (including some URLs comparing/contrasting)
https://www.garlic.com/~lynn/2005b.html#1 Foreign key in Oracle Sql
https://www.garlic.com/~lynn/2005u.html#41 Mainframe Applications and Records Keeping?

and for other topic drift leading up to meeting mentioned in these posts (and cluster scale-up):
https://www.garlic.com/~lynn/95.html#13
https://www.garlic.com/~lynn/96.html#15
and
https://www.garlic.com/~lynn/2001n.html#83

Date: 14 October 1991, 16:05:32 CDT
To: wheeler

Last Thursday (10/10) ******* and I made a presentation to ****** for a cluster-in-a-rack proposal called MEDUSA. ****** liked the idea and wants to see what it will take to put MEDUSA into the plan. MEDUSA would provide the capability of a cluster MP beta test in 3Q92 and address commercial (HA/6000) market.


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

of course, lots of past ha/cmp posts
https://www.garlic.com/~lynn/subtopic.html#hacmp

IBM sues maker of Intel-based Mainframe clones

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM sues maker of Intel-based Mainframe clones
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 09 Dec 2006 11:11:21 -0700
jsavard writes:
I had mentioned the company myself in a posting to alt.folklore.computers and comp.arch, having run across information on them in an Intel advertisement. Apparently, the versatility of the Itanium is such that it makes all "proprietary architectures" obsolete, and this was one example.

i had kicked off the thread with
https://www.garlic.com/~lynn/2006w.html#1

a few posts in (comp.arch) JIT thread(s)
https://www.garlic.com/~lynn/2006r.html#24 A Day For Surprises (Astounding Itanium Tricks)
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#33 Assembler question

and from the previous post
https://www.garlic.com/~lynn/2006w.html#13
and
https://www.garlic.com/~lynn/95.html#13
https://www.garlic.com/~lynn/96.html#15
https://www.garlic.com/~lynn/2001n.html#83

and a little more old MEDUSA email

The idea was significantly reducing the physical footprint ... and one of the challenges for MEDUSA was getting enuf colling into the "pancakes".

In the push for higher and higher density in racks, there were both thinner & thinner pancakes and then "half-wide" pancakes ... and then the transition to blades ... where the units were mounted vertically instead of horizontal.

Date: 10 September 1991, 07:39:24 CDT
To: wheeler

I think we need to talk some more about the cluster rack and its applicability to the HA work you are doing.

After our last conversation and additional engineering input, the definition has changed. As currently defined MEDUSA (as we now call it) is 32 processor rack with an integrated FCS Switch. Each processor drawer consists of: - one RS_1 processor - 16-256MBytes of Memory - ROS, NVRAN, + other junk - 2 FCS channels

The intent is to make the FCS channels pluggable such that either gigabit or quarter speed optics could be plugged at the users option. This also permits initial debug to occur without FCS (from a hardware standpoint FCS is the schedule gate). The number of processors is selectable by the customer as is the amount on memory per processor (pluggable up to a maximum of 256MB per proc).

The rack will contain a 64 channel fully non-blocking FCS Ancor switch.

We need to develop an initial IBP and perhaps you could help. I would like to factor in your work and thoughts on software and market potential from a commercial prospective.


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

oh and past reference to trying to do high density racks with blade like configurations in 1985 (references towards the end of the post):
https://www.garlic.com/~lynn/2004m.html#17 mainframe and microprocessor

more secure communication over the network

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: more secure communication over the network
Newsgroups: alt.folklore.computers,sci.crypt
Date: Sat, 09 Dec 2006 22:42:33 -0700
jsavard writes:
Public-key cryptosystems are a good idea when people can't exchange keys securely.

If data needs to be kept secret a long time, however, there is always the chance that a mathematical break-through might allow the secret key to be derived from the public key.

On the other hand, a key which is exchanged - it is believed - securely might still be compromised or stolen.

The best thing to do is to use public-key techniques to protect the initial exchange of conventional key-exchange keys. This gives the best security from both worlds - and by doing that for key-exchange keys, one cuts down the number of times one is using computationally-intensive public-key methods.

As this is just my opinion, I'm crossposting to a newsgroup where others may comment on my judgement (or sanity).


there may be some confusion in the cross-posting ... since the original post was a repeat of some email from 1981 suggesting (effectively) an account oriented public key infrastructure implementation
https://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network

for other comments on aspects of current, common public key infrastructure deployments see collected posts on ssl digital certificates
https://www.garlic.com/~lynn/subpubkey.html#sslcert

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

or these posts observing the catch-22 in some improvements to ssl domain name digital certificate operation (the proposals for improving integrity/deficiencies in the current operations can result in eliminating the requirement for the digital certificates)
https://www.garlic.com/~lynn/subpubkey.html#catch22

in fact, there are some similarities to some of the suggestions described in the referenced catch-22 posts and the suggestion from 1981.

intersection between autolog command and cmsback (more history)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: intersection between autolog command and cmsback (more history)
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers
Date: Sat, 09 Dec 2006 22:53:49 -0700
Another CMSBACK status, a year later than the email referenced here
https://www.garlic.com/~lynn/2006t.html#24 CMSBACK

i.e. i had done the original CMSBACK implementation and deployment in the late 70s on sjr systems and hone ... the following refers to there additional systems where it was installed:

Date: 12/11/80 15:21:31
To: distribution

CMSBACK is now installed in: Los Gatos (2, CPUs), GPD SNJ (3), GPD STL (1) Austin (1) Note: Austin has (re)installed CMSBACK in other locations. It is also being installed in Yorktown.


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

other recent CMSBACK references:
https://www.garlic.com/~lynn/2006t.html#20 Why these original FORTRAN quirks?; Now : Programming practices
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?
https://www.garlic.com/~lynn/2006v.html#24 Z/Os Storage Mgmt products

and collected past posts on backup/archive systems
https://www.garlic.com/~lynn/submain.html#backup

all of this preceeding the work mentioned in Melinda's history paper by a couple years (even preceeding the hiring of the people that Melinda's history paper mentions as having done the original work).
https://www.leeandmelindavarian.com/Melinda#VMHist

now as to automated operator &/or automated operations ... the autolog command ... mentioned here
https://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?

helped significantly with the automation of service virtual machines ... some recent references here:
https://www.garlic.com/~lynn/2006p.html#10 What part of z/OS is the OS?
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
https://www.garlic.com/~lynn/2006v.html#22 vmshare

CMSBACK would be one example of service virtual machine ... another would be VNET ... another would be the facility developed for automated benchmarking.

I had originally created the autolog command (and the automated flavor that was done at kernel boot) in support of automated benchmarking
https://www.garlic.com/~lynn/submain.html#bench

aka, i needed automatically (and unattended) to stop a current benchmark, generate a new kernel with various modifications, reboot to the new kernel, and start the next set of benchmarks. this could be repeated a couple times an hour for extended period straight (say 6-10 8hr shifts).

now some rudimentary stuff could be done for automated operations using combination of service virtual machines (autolog command being one of the enablers) and special message facility ... which allowed application to capture all text (messages, cp command responses, etc) that normally would be written to the terminal/screen. a couple recent posts mentioning SPM
https://www.garlic.com/~lynn/2006k.html#51 other cp/cms history
https://www.garlic.com/~lynn/2006t.html#47 To RISC or not to RISC
https://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?

another service virtual machine would be CJNTEL using special message ... mentioned here
https://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network

some drift ... the above post also includes a mention from 1981 for public key infrastructure kind of operation.

however, simple text/message processing was lacking sophisticated parsing ... like found in parasite/story ... misc. references
https://www.garlic.com/~lynn/2001k.html#35 Newbie TOPS-10 7.03 question
https://www.garlic.com/~lynn/2003i.html#73 Computer resources, past, present, and future
https://www.garlic.com/~lynn/2003j.html#24 Red Phosphor Terminal?
https://www.garlic.com/~lynn/2004e.html#14 were dumb terminals actually so dumb???
https://www.garlic.com/~lynn/2005r.html#12 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2006.html#3 PVM protocol documentation found
https://www.garlic.com/~lynn/2006c.html#14 Program execution speed
https://www.garlic.com/~lynn/2006f.html#37 Over my head in a JES exit
https://www.garlic.com/~lynn/2006m.html#35 Draft Command Script Processing Manual
https://www.garlic.com/~lynn/2006n.html#23 sorting was: The System/360 Model 20 Wasn't As Bad As All That
https://www.garlic.com/~lynn/2006p.html#31 "25th Anniversary of the Personal Computer"

or later hllapi-like implementations. also missing was sophisticated rule infrastructures (allowing specification about what should be done in different kinds of circumstances).

for other references, part of an old SPMS application document ....
SPMS: CMS/SPM Interface Program 1

1.0 INTRODUCTION

SPMS is a transient CMS command that can be called by an EXEC or by a program running in a virtual machine. It enables the user to use the CP Special Message Facility to intercept messages from CP or from other users and process them within a CMS program or EXEC. A CP command may be passed to SPMS to cause the response to that command to be returned to the caller, or SPMS can be used to trap messages not associated with any particular CP command. Messages received through SPMS can be placed in the CMS console stack and read in by the EXEC or program which called SPMS, or, if SPMS was called by a program, the addresses of the messages received can be passed directly back to the program. To use SPMS properly, the user should have a good knowledge of the CP and CMS command languages, as well as an understanding of the CMS console stack concept and the Special Message Facility.

SPMS provides two modes of operation. In 'immediate' mode, it issues a single CP command and returns the response (if any) to that command to the caller, and exits immediately. In 'continuous' mode, it builds a Special Message 'trap', which remains active in CMS after SPMS ends. The calling routine can then continue with other work and issue another call to SPMS with parameters requesting that any accumulated messages be returned to it at that time, or that the SPM trap be removed from CMS.

The Special Message Facility makes a distinction between messages from CP itself (such as responses to commands), and messages from other users. SPMS provides options which make it possible to deal with 'MSG' type messages and 'CP' type messages separately. When SPMS is used in 'immediate' mode, it examines the CP command passed to it to determine whether it is a command that would cause a message to be sent to another user. If it is a 'MESSAGE' type command, SPMS will wait for a 'MSG' type response in the assumption that the issuer is awaiting a response from the recipient of the message being sent. (Although it will accept a message from any user as a response.) If the command being issued is not a 'MESSAGE' type command, SPMS will wait for a 'CP' response only.

In some situations, the response to a CP command might be delayed or there might be no response. When using SPMS in immediate mode, the user may specify how long to wait before exiting without receiving a response.

Messages placed in the console stack by SPMS are stacked in FIFO sequence by default. Through the use of an optional parameter the user may cause the messages to be stacked in a

8 June 1979 1 of 16


... snip ...

and lots of old posts mentioning the subject of automated operator
https://www.garlic.com/~lynn/94.html#2 Schedulers
https://www.garlic.com/~lynn/99.html#71 High Availabilty on S/390
https://www.garlic.com/~lynn/99.html#107 Computer History
https://www.garlic.com/~lynn/99.html#128 Examples of non-relational databases
https://www.garlic.com/~lynn/99.html#136a checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/2000.html#22 Computer of the century
https://www.garlic.com/~lynn/2000f.html#12 Amdahl Exits Mainframe Market
https://www.garlic.com/~lynn/2001.html#43 Life as a programmer--1960, 1965?
https://www.garlic.com/~lynn/2001c.html#13 LINUS for S/390
https://www.garlic.com/~lynn/2001d.html#70 Pentium 4 Prefetch engine?
https://www.garlic.com/~lynn/2001d.html#71 Pentium 4 Prefetch engine?
https://www.garlic.com/~lynn/2001e.html#44 Where are IBM z390 SPECint2000 results?
https://www.garlic.com/~lynn/2001e.html#47 Where are IBM z390 SPECint2000 results?
https://www.garlic.com/~lynn/2001h.html#8 VM: checking some myths.
https://www.garlic.com/~lynn/2001k.html#13 HP-UX will not be ported to Alpha (no surprise)exit
https://www.garlic.com/~lynn/2001k.html#14 HP-UX will not be ported to Alpha (no surprise)exit
https://www.garlic.com/~lynn/2001k.html#18 HP-UX will not be ported to Alpha (no surprise)exit
https://www.garlic.com/~lynn/2001l.html#47 five-nines
https://www.garlic.com/~lynn/2001n.html#47 Sysplex Info
https://www.garlic.com/~lynn/2001n.html#85 The demise of compaq
https://www.garlic.com/~lynn/2002.html#24 Buffer overflow
https://www.garlic.com/~lynn/2002e.html#68 Blade architectures
https://www.garlic.com/~lynn/2002h.html#73 Where did text file line ending characters begin?
https://www.garlic.com/~lynn/2002l.html#62 Itanium2 performance data from SGI
https://www.garlic.com/~lynn/2002n.html#27 why does wait state exist?
https://www.garlic.com/~lynn/2002o.html#14 Home mainframes
https://www.garlic.com/~lynn/2002p.html#54 Newbie: Two quesions about mainframes
https://www.garlic.com/~lynn/2003.html#37 Calculating expected reliability for designed system
https://www.garlic.com/~lynn/2003g.html#3 Disk capacity and backup solutions
https://www.garlic.com/~lynn/2003h.html#56 The figures of merit that make mainframes worth the price
https://www.garlic.com/~lynn/2003h.html#60 The figures of merit that make mainframes worth the price
https://www.garlic.com/~lynn/2003i.html#27 instant messaging
https://www.garlic.com/~lynn/2003n.html#22 foundations of relational theory? - some references for the
https://www.garlic.com/~lynn/2003n.html#45 hung/zombie users ... long boring, wandering story
https://www.garlic.com/~lynn/2004.html#40 AMD/Linux vs Intel/Microsoft
https://www.garlic.com/~lynn/2004b.html#48 Automating secure transactions
https://www.garlic.com/~lynn/2004m.html#46 Shipwrecks
https://www.garlic.com/~lynn/2004q.html#75 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005.html#53 8086 memory space
https://www.garlic.com/~lynn/2005.html#59 8086 memory space
https://www.garlic.com/~lynn/2005c.html#7 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005d.html#9 intel's Vanderpool and virtualization in general (was Re: Cell press release, redacted.)
https://www.garlic.com/~lynn/2005j.html#60 Ancient history
https://www.garlic.com/~lynn/2005m.html#52 Cluster computing drawbacks
https://www.garlic.com/~lynn/2005o.html#30 auto reIPL
https://www.garlic.com/~lynn/2005u.html#37 Mainframe Applications and Records Keeping?
https://www.garlic.com/~lynn/2006i.html#2 The Pankian Metaphor
https://www.garlic.com/~lynn/2006u.html#30 Why so little parallelism?

Cache, TLB and OS

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Cache, TLB and OS
Newsgroups: comp.os.linux.development.system,comp.arch
Date: Sun, 10 Dec 2006 08:09:09 -0700
Casper H.S. Dik <Casper.Dik@Sun.COM> writes:
Multiple copies of the same program (programs are mapped at the same location in memory; the text segment is shared)

Multiple copies of the same shared libraries (which may or may not end up on the same virtual address; but typically are mapped at or about the same address)

Shared memory segments


lots of past posts about dealing with shared memory segments potentially mapped at different virtual addresses in different virtual address spaces
https://www.garlic.com/~lynn/submain.html#adcon

an issue is if the TLB (and virtual cache) are virtual address space associative ("STO-associative" in some of the discussions) ... then they have different TLB/cache entries (even if they might have the same physical address and potentially even the same virtual address). For shared memory segments ... the problem can go away ... if the TLB/cache are segment associative ("PTO-associative" in some of the discussions). For instance, you find TLB being virtual segment associative (instead of virtual address space associative) in various 801 machines.

some postings about 3090 having cache that was indexed by both real address (real address associative) and "logical" address (and being virtual address space associative).
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
https://www.garlic.com/~lynn/2006v.html#43 The Future of CPUs: What's After Multi-Core?

more secure communication over the network

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: more secure communication over the network
Newsgroups: alt.folklore.computers,sci.crypt
Date: Sun, 10 Dec 2006 08:33:57 -0700
Anne & Lynn Wheeler <lynn@garlic.com> writes:
there may be some confusion in the cross-posting ... since the original post was a repeat of some email from 1981 suggesting (effectively) an account oriented public key infrastructure implementation
https://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network


ref:
https://www.garlic.com/~lynn/2006w.html#15 more secure communication over the network

note the above reference is also somewhat similar to the PGP keyservers

for additional drift, a couple other posts with emails from the 70s and 80s mentioning crypto
https://www.garlic.com/~lynn/2006.html#30 IBM microwave application--early data communications
https://www.garlic.com/~lynn/2006n.html#23 sorting was: The System/360 Model 20 Wasn't As Bad As All That
https://www.garlic.com/~lynn/2006n.html#36 The very first text editor

and related thread with other archeological references:
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?

Cache, TLB and OS

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Cache, TLB and OS
Newsgroups: comp.os.linux.development.system,comp.arch,alt.folklore.computers
Date: Sun, 10 Dec 2006 09:09:43 -0700
Anne & Lynn Wheeler <lynn@garlic.com> writes:
lots of past posts about dealing with shared memory segments potentially mapped at different virtual addresses in different virtual address spaces
https://www.garlic.com/~lynn/submain.html#adcon


re:
https://www.garlic.com/~lynn/2006w.html#17 Cache, TLB, and OS

couple recent posts with emails from the early/mid 70s about doing shared segment work including support for same virtual shared segment appearing at different virtual addresses in different virtual address spaces
https://www.garlic.com/~lynn/2006v.html#36 Why these original Fortran quirks?
https://www.garlic.com/~lynn/2006w.html#7 Why these original Fortran quirks?
https://www.garlic.com/~lynn/2006w.html#8 Why these original Fortran quirks?

cluster-in-a-rack

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: cluster-in-a-rack
Newsgroups: alt.folklore.computers
Date: Sun, 10 Dec 2006 10:01:47 -0700
more in the MEDUSA saga
https://www.garlic.com/~lynn/2006w.html#13 IBM sues maker of Intel-based Mainframe clones
https://www.garlic.com/~lynn/2006w.html#14 IBM sues maker of Intel-based Mainframe clones

i.e. at the time, 32 processors per rack.

leading up to the meeting in Ellison's conference room in Jan92
https://www.garlic.com/~lynn/95.html#13
https://www.garlic.com/~lynn/96.html#15
and then
https://www.garlic.com/~lynn/2001n.html#83

In the following, "Harrier/9333" eventually became "SSA" referred to in the postings mentioning the meeting in Ellison's conference room.

Date: 24 Oct 91 07:29:46
To: wheeler

I reviewed the MEDUSA proposal with ******** concentrating on the DASD and tape requirements with focus on the projected 9/92 Beta test. I also described ****** overwhelming positive reaction to MEDUSA and his intent to put MEDUSA into the AWD plan. I also described the program in ******* to add FCS attachment to Pacheco_II with a Beta test target date of 3Q92.

Due to ******* intention of putting MEDUSA into the AWD plan, I felt it was necessary to secure an alternate DASD source for MEDUSA (a backup to the Pacheco_II plan). To this end, I asked ****** to help me put together a creditable and implementable DASD story for MEDUSA.

Of particular interest is a follow-on to Harrier and the Corsair


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

In the following, "FSD" refers to the federal system division

Date: 11/19/91 12:48:26
From: wheeler

This was a meeting with a pedigreed FSD attendance of all their best technical people and all their most important project managers, about 25 in all. The end result will be documented for us by ***** in about a week. my version is that with concurrence from all present, FSD will go forward with a business plan that makes MEDUSA with HA/6000 Unitree and Oracle the basis for most of what they're doing, and they will want to work in a joint development mode with us.


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

in a little over two months after the above email, cluster-in-a-rack project had been transferred, and we were told that we couldn't work on anything with more than four processors.

collected posts mentioning ha/6000 and ha/cmp
https://www.garlic.com/~lynn/subtopic.html#hacmp

and misc. posts mentioning unitree
https://www.garlic.com/~lynn/2001f.html#66 commodity storage servers
https://www.garlic.com/~lynn/2002e.html#46 What goes into a 3090?
https://www.garlic.com/~lynn/2002g.html#61 GE 625/635 Reference + Smart Hardware
https://www.garlic.com/~lynn/2002k.html#31 general networking is: DEC eNet: was Vnet : Unbelievable
https://www.garlic.com/~lynn/2003b.html#29 360/370 disk drives
https://www.garlic.com/~lynn/2003b.html#31 360/370 disk drives
https://www.garlic.com/~lynn/2003h.html#6 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
https://www.garlic.com/~lynn/2003i.html#53 A Dark Day
https://www.garlic.com/~lynn/2005e.html#12 Device and channel
https://www.garlic.com/~lynn/2005e.html#15 Device and channel
https://www.garlic.com/~lynn/2005e.html#16 Device and channel
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?
https://www.garlic.com/~lynn/2006v.html#10 What's a mainframe?

SNA/VTAM for NSFNET

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: SNA/VTAM for NSFNET
Newsgroups: alt.folklore.computers
Date: Sun, 10 Dec 2006 17:35:55 -0700
sna/vtam for nsfnet??

Long ago and far away, somebody ran across a copy of a series of emails and forwarded a copy to us in the HSDT project
https://www.garlic.com/~lynn/subnetwork.html#hsdt

aka ... SNA/VTAM people taking over our NSFNET activities

some of the people involved had also been involved in calling up various univ. and NSF people and canceling HSDT meetings that we had scheduled (starting earlier) ... some of which is referenced here
https://www.garlic.com/~lynn/2006u.html#56 Ranking of non-IBM mainframe builders?
and specific meeting mentioned here
https://www.garlic.com/~lynn/2005d.html#13 Cerf and Kahn receive Turing award

a couple other recent references to our NSFNET activity (having T1 and higher speed stuff)
https://www.garlic.com/~lynn/2006s.html#50 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006t.html#6 Ranking of non-IBM mainframe builders?

anyway a couple weeks short of twenty years ago ... culture of misinformation and FUD

Date: 01/09/87 16:11:26
From: ?????

TO ALL IT MAY CONCERN-

I REC'D THIS TODAY. THEY HAVE CERTAINLY BEEN BUSY. THERE IS A HOST OF MISINFORMATION IN THIS, INCLUDING THE ASSUMPTION THAT TCP/IP CAN RUN ON TOP OF VTAM, AND THAT WOULD BE ACCEPTABLE TO NSF, AND THAT THE UNIVERSITIES MENTIONED HAVE IBM HOSTS WITH VTAM INSTALLED.

Forwarded From: ***** To: ***** Date: 12/26/86 13:41

1. Your suggestions to start working with NSF immediately on high speed (T1) networks is very good. In addition to ACIS I think that it is important to have CPD Boca involved since they own the products you suggest installing. I would suggest that ***** discuss this and plan to have the kind of meeting with NSF that ***** proposes.

<... great deal more of the same; several more appended emails from several participants in the MISINFORMATION ...>


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

other old NSFNET related email
https://www.garlic.com/~lynn/lhwemail.html#nsfnet

as an aside ... sna/vtam group still considered 56kbit "high speed" and T1 was "very high speed" ... aka various references from this year:
https://www.garlic.com/~lynn/2006e.html#36 The Pankian Metaphor
https://www.garlic.com/~lynn/2006s.html#42 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006s.html#50 Ranking of non-IBM mainframe builders?

reference to sna/vtam group deciding that product support for T1 wasn't even needed until possibly sometime in the 90s (and why their 56kbit "fat pipes" were good enuf)
https://www.garlic.com/~lynn/2001.html#4 Sv: First video terminal?
https://www.garlic.com/~lynn/2002j.html#67 Total Computing Power
https://www.garlic.com/~lynn/2003m.html#28 SR 15,15
https://www.garlic.com/~lynn/2003m.html#59 SR 15,15
https://www.garlic.com/~lynn/2004g.html#37 network history
https://www.garlic.com/~lynn/2004l.html#7 Xah Lee's Unixism
https://www.garlic.com/~lynn/2005j.html#59 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
https://www.garlic.com/~lynn/2006l.html#4 Google Architecture

there was a mainframe vm-based tcp/ip product support coming ... but it didn't involve VTAM (TCP/IP on VTAM was much, much later). The vm implemetations was subsequently ported to MVS by doing a "vm diagnose" simulator (for those things needed by the tcp/ip implementation). I was somewhat involved in the vm implementation, adding rfc 1044 support to the base implementation
https://www.garlic.com/~lynn/subnetwork.html#1044

that base vm implementation was getting about 44kbytes/sec aggregegate thruput using a full 3090 processor. in some tuning work at cray research got 1mbyte/sec between a cray and a 4341-clone (out of the rfc 1044 support) ... only using a modest amount of the 4341 processor.

So the first of the forwarded email ... partially included in the above (12/26/86), was from person that was also heavily involved later in transfering cluster scale-up (and we were told we couldn't work on anything with more than four processors) ... partial reference here:
https://www.garlic.com/~lynn/95.html#13
https://www.garlic.com/~lynn/96.html#15
old email related to cluster scale-up
https://www.garlic.com/~lynn/lhwemail.html#medusa

The above excerpt (12/26/86) even suggests VTAM in NSF backbone; NOTE there was NOT TCP/IP in VTAM until much later. somewhat related leading up to the above mentioned meeting
https://www.garlic.com/~lynn/2006w.html#13
https://www.garlic.com/~lynn/2006w.html#14
https://www.garlic.com/~lynn/2006w.html#20
and
https://www.garlic.com/~lynn/2001n.html#83

for even more topic drift ... two people in the above mentioned Jan92 (in Ellison's conference room) meeting later showed up in a small client/server startup responsible for something called commerce server. we were called in to consult because they wanted to process payment transactions on their servers ... some references
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

later it started to be called electronic commerce.

and an earlier suggestion for securing networking communication
https://www.garlic.com/~lynn/2006w.html#12
https://www.garlic.com/~lynn/2006w.html#15
https://www.garlic.com/~lynn/2006w.html#18

Now while the original NSFNET request went out for T1, somewhat based on our work with them ... the actual winner for the initial NSFNET didn't have "real" T1 networking links. The network/router interfaces that they used only went up to 440kbits/sec. The contract called for T1 links ... so there were these actual physical T1 links ... and then there was telco-type multiplexor that multiplexed three 440kbit network links over the physical T1 links. Using that logic ... the T1 links possible were in turn multiplexed over even a T5 link at some point ... which would have allowed the claim that it was a T5 network(?).

as mentioned before, we were prevented for participating in the bid, and NSF analysis was that what we already had running was at least five years ahead of all bid submissions ... misc. past posts mentioning it
https://www.garlic.com/~lynn/98.html#49 Edsger Dijkstra: the blackest week of his professional life
https://www.garlic.com/~lynn/99.html#33 why is there an "@" key?
https://www.garlic.com/~lynn/99.html#37a Internet and/or ARPANET?
https://www.garlic.com/~lynn/internet.htm#0 Internet and/or ARPANET?
https://www.garlic.com/~lynn/aadsm13.htm#17 A challenge
https://www.garlic.com/~lynn/2001d.html#42 IBM was/is: Imitation...
https://www.garlic.com/~lynn/2001h.html#44 Wired News :The Grid: The Next-Gen Internet?
https://www.garlic.com/~lynn/2002.html#32 Buffer overflow
https://www.garlic.com/~lynn/2002f.html#5 Blade architectures
https://www.garlic.com/~lynn/2002i.html#45 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002k.html#56 Moore law
https://www.garlic.com/~lynn/2003c.html#46 difference between itanium and alpha
https://www.garlic.com/~lynn/2003d.html#59 unix
https://www.garlic.com/~lynn/2003g.html#36 netscape firebird contraversy
https://www.garlic.com/~lynn/2003j.html#1 FAST - Shame On You Caltech!!!
https://www.garlic.com/~lynn/2004g.html#12 network history
https://www.garlic.com/~lynn/2004q.html#57 high speed network, cross-over from sci.crypt
https://www.garlic.com/~lynn/2004q.html#58 CAS and LL/SC (was Re: High Level Assembler for MVS & VM & VSE)
https://www.garlic.com/~lynn/2005d.html#6 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005d.html#10 Cerf and Kahn receive Turing award
https://www.garlic.com/~lynn/2005j.html#30 IBM Plugs Big Iron to the College Crowd
https://www.garlic.com/~lynn/2005j.html#58 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
https://www.garlic.com/~lynn/2005l.html#16 Newsgroups (Was Another OS/390 to z/OS 1.4 migration
https://www.garlic.com/~lynn/2005n.html#28 Data communications over telegraph circuits
https://www.garlic.com/~lynn/2005p.html#10 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005p.html#16 DUMP Datasets and SMS
https://www.garlic.com/~lynn/2005q.html#3 winscape?
https://www.garlic.com/~lynn/2005q.html#6 What are the latest topic in TCP/IP
https://www.garlic.com/~lynn/2005q.html#46 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005s.html#28 MVCIN instruction
https://www.garlic.com/~lynn/2005u.html#53 OSI model and an interview
https://www.garlic.com/~lynn/2006e.html#36 The Pankian Metaphor
https://www.garlic.com/~lynn/2006f.html#12 Barbaras (mini-)rant
https://www.garlic.com/~lynn/2006g.html#18 TOD Clock the same as the BIOS clock in PCs?
https://www.garlic.com/~lynn/2006h.html#51 The Chant of the Trolloc Hordes
https://www.garlic.com/~lynn/2006i.html#21 blast from the past on reliable communication
https://www.garlic.com/~lynn/2006j.html#34 Arpa address
https://www.garlic.com/~lynn/2006r.html#6 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006s.html#20 real core
https://www.garlic.com/~lynn/2006v.html#35 What's a mainframe?

Are hypervisors the new foundation for system software?

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Are hypervisors the new foundation for system software?
Newsgroups: alt.folklore.computers
Date: Sun, 10 Dec 2006 18:25:12 -0700
Are hypervisors the new foundation for system software?
http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=443

from above:
A Pocket History of Virtualization
...
These initial enhancements could all be accommodated within the operating system, until the day arrived when different users, or different applications on the same physical machine, wanted to run different operating systems. This requirement could be satisfied only by supporting multiple VMs, each capable of running its own operating system. The virtualization era (marked by IBM's release of VM for the System/360 in 1972) had dawned.


... snip ...

the new 40yr old thing
https://www.garlic.com/~lynn/2006s.html#65
https://www.garlic.com/~lynn/2006t.html#27
https://www.garlic.com/~lynn/2006v.html#21
https://www.garlic.com/~lynn/2006v.html#52
https://www.garlic.com/~lynn/2006w.html#0

of course vm370 was a morph of cp67 that had been done for the 360/67. three people from the science center
https://www.garlic.com/~lynn/subtopic.html#545tech

came out to the university the last week of jan68 and installed a copy. I then got to play with it ... rewriting large amounts of it.

the spring mar68 SHARE meeting in houston officially announced availability of cp67.
https://www.garlic.com/~lynn/2003d.html#72 CP67 35th anniversary

old post including piece of presentation at the fall68 SHARE meeting in Atlantic City on some of the (cp67 and mft14) changes that i made
https://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14

of course, the science center had previously done cp40 on a custom modified 360/40 before the availability of 360/67 machine ... when they got one, they morphed cp40 into cp67 on the 360/67.

https://www.garlic.com/~lynn/2004c.html#11 40yrs, science center, feb. 1964

Melinda's paper has a lot more detailed history
https://www.leeandmelindavarian.com/Melinda#VMHist

Multiple mappings

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Multiple mappings
Newsgroups: comp.arch
Date: Mon, 11 Dec 2006 08:00:31 -0700
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
Let us exclude the matter of zero-initialised pages, and concentrate on ordinary physical pages mapped to two different virtual addresses in a SINGLE address space. My belief is that almost all systems permit this, but it is an essentially unused facility, for very good reasons, such as: even if the system doesn't get confused, the user probably will!

Does anyone know of a reasonable, real, application where it is done? And. if so, what is it used for?


re:
https://www.garlic.com/~lynn/2006w.html#17 Cache, TLB and OS
https://www.garlic.com/~lynn/2006w.html#10 Cache, TLB and OS

nope ... my virtual memory management didn't preclude having the same shared segment at different virtual addresses whether in different virtual address spaces or the same virtual address space ... but i didn't remember ever coming across a use for having multiple mappings of the same shared segment within the same virtual address space.

recent posts about porting virtual memory management from cp67 to vm370
https://www.garlic.com/~lynn/2006v.html#36 Why these original FORTRAN quirks?
https://www.garlic.com/~lynn/2006w.html#7 Why these original FORTRAN quirks?
https://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?

this is recent post about an old hack for >16mbyte support in 370
https://www.garlic.com/~lynn/2006t.html#15 more than 16mbyte for 370

where i proposed temporarily stuffing a couple real page addresses into a virtual address space in order to copy from above the real "16mbyte" line to below the "16mbyte" line. in the scenario where it was purely copying a 4k virtual page ... it wasn't likely to have multiple copies. However for the scenario where data was being copied from a virtual page (above the line) into kernel working storage (below the line), and it was a multiprocessor configuration where more than one processor was attempting this; the process involved temporarily dynamically allocating two page table entries from the "system" virtual address space table ... in such a scenario if the two (or more) processors were working with different kernel working buffers that happened to be in the same real page ... then for a short period of time, the "system" virtual address space table could have had two (or more) different page table entries pointing to the same real address.

there was almost a plausable scenario in original 370 architecture where the "segment protection" (i.e. read-only, non-modifiable) was a bit in the segment table entry (i.e. the pointer to the page table for a specific segment). You could have the same (shared) segment at different virtual addresses in the same virtual address space ... where one version was "protected" and the other version was unprotected. Most threads in the address space would be accessing the r/o, protected version ... while some privilege thread might have access to the r/w, unprotected version.

the original relational/sql implementation, system/r
https://www.garlic.com/~lynn/submain.html#systemr

did something of a flavor of this ... but the "threads" were running in different virtual address spaces ... not the same virtual address space.

IBM sues maker of Intel-based Mainframe clones

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM sues maker of Intel-based Mainframe clones
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 11 Dec 2006 09:50:59 -0700
Howard Brazee <howard@brazee.net> writes:
It would be interesting if we could get a copy of an Amdahl OS that would run on PCs. I used a nifty one a couple of decades ago that was in beta that I liked. A funny thing about Aspen was using the help feature to find out how to handle labeled tapes - and reading how those were used by a "water cooled computer".

Interesting that nowadays some gamers buy or build water cooled PCs.


re:
https://www.garlic.com/~lynn/2006w.html#1 IBM sues maker of Intel-based Mainframe clones
https://www.garlic.com/~lynn/2006w.html#2 IBM sues maker of Intel-based Mainframe clones
https://www.garlic.com/~lynn/2006w.html#3 IBM sues maker of Intel-based Mainframe clones
https://www.garlic.com/~lynn/2006w.html#13 IBM sues maker of Intel-based Mainframe clones
https://www.garlic.com/~lynn/2006w.html#14 IBM sues maker of Intel-based Mainframe clones

aspen got hit with some legal discovery ...

simpson of HASP fame ... misc. past posts mentioning hasp
https://www.garlic.com/~lynn/submain.html#hasp

had gone on to do something he called RASP ... sort of a page mapped VS1 system (somewhat TSS/360 like) which was eventually killed. he left and joined Amdahl in dallas and resumed the project. supposedly all new code was done in clean room ... but there was still some litigation/discovery whether aspen contained any RASP code.

i got somewhat drawn into some of the conflict between dallas/aspen and sunnyvale/gold ... and suggested why didn't they pull an SSS (a stripdown TSS kernel with Unix built on top ... done for AT&T) ... aka build unix on top of a stripped down aspen kernel.

misc. past posts mentioning aspen
https://www.garlic.com/~lynn/2000f.html#68 TSS ancient history, was X86 ultimate CISC? designs)
https://www.garlic.com/~lynn/2000f.html#69 TSS ancient history, was X86 ultimate CISC? designs)
https://www.garlic.com/~lynn/2000f.html#70 TSS ancient history, was X86 ultimate CISC? designs)
https://www.garlic.com/~lynn/2001g.html#35 Did AT&T offer Unix to Digital Equipment in the 70s?
https://www.garlic.com/~lynn/2002g.html#0 Blade architectures
https://www.garlic.com/~lynn/2002i.html#63 Hercules and System/390 - do we need it?
https://www.garlic.com/~lynn/2004q.html#37 A Glimpse into PC Development Philosophy
https://www.garlic.com/~lynn/2005p.html#44 hasp, jes, rasp, aspen, gold
https://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3
https://www.garlic.com/~lynn/2005q.html#2 Article in Information week: Mainframe Programmers Wanted
https://www.garlic.com/~lynn/2005q.html#26 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005q.html#27 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2006b.html#24 Seeking Info on XDS Sigma 7 APL
https://www.garlic.com/~lynn/2006f.html#19 Over my head in a JES exit
https://www.garlic.com/~lynn/2006f.html#26 Old PCs--environmental hazard
https://www.garlic.com/~lynn/2006i.html#0 The Pankian Metaphor
https://www.garlic.com/~lynn/2006l.html#7 Google Architecture
https://www.garlic.com/~lynn/2006m.html#30 Old Hashing Routine
https://www.garlic.com/~lynn/2006o.html#33 When Does Folklore Begin???
https://www.garlic.com/~lynn/2006q.html#32 Very slow booting and running and brain-dead OS's?
https://www.garlic.com/~lynn/2006t.html#17 old Gold/UTS reference

To RISC or not to RISC

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Subject: Re: To RISC or not to RISC
Date: Tue, 12 Dec 2006 09:08:43 -0800
Newsgroups: alt.lang.asm,comp.arch,alt.folklore.computers
Anne & Lynn Wheeler wrote:
how 'bout virtual appliances ... possibly not quite what they are talking about in this news release ... instead of ease of deployment ... talk about partitioning, security, isolation, ease of management, etc.

a 1981 referece for using CJNTEL as part of public key (small "i") infrastructure
https://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network

service virtual machines ...
https://www.garlic.com/~lynn/2006w.html#16 intersection between autolog command and cmsback (more history)

part of virtual machine history scenario
https://www.garlic.com/~lynn/2006w.html#22 Are hypervisors the new foundation for system software

service virtual machines are now being referred to as virtual appliances.
https://www.garlic.com/~lynn/2006t.html#46 To RISC or not to RISC

Minor CJNTEL topic drift ...

The standard CMS "CDF" filesystem used 800byte physical blocks. My modifications for paged mapped filesystem
https://www.garlic.com/~lynn/submain.html#mmap

left much of the "CDF" filesystem semantics alone ... but did change the "physical" block size from 800 bytes to (page size) 4k bytes. Most things worked correctly, but a few applications had felt compelled to do some fiddling based on the number of physical records (and implicit assumption the physical records were 800 bytes).

Date: 03/29/80 14:01:25
From: wheeler

what do you use for creating PACKED files??? The 191 disk for CJNTEL is a 4k PAM disk. Vanilla release 2,3,4,5, etc programs run correctly, only difference is the number of physical blocks allocated for a file. Programs which use the number of physical blocks may not work correctly .... DISK, TAPE, & VMFPLC have had to be modified. HUFF/PUFF from YKT has not been modified and doesn't work correctly. HUFFMOVE, VMFPLC2, COPYFILE, etc. do not use number of physical blocks in their calculations so they work correctly.


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

posting with reference to CSC "release 2" distribution system including page mapped filesystem support
https://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?

When the CMS "EDF" filesystem appeared in release 6 ... posting with reference to preparing a SJR "release 6" distribution system
https://www.garlic.com/~lynn/2006u.html#26 Assembler question

... I also did the modifications to map its semantics to page mapped filesystem infrastructure. The basic "EDF" filesystem offered 1k, 2k, and 4k "physical" record sizes as options. The "page mapped" mapping was to force EDF paged mapped filesystem to appear as 4k physical record size.

.... and old reference to growing acceptance of CJNTEL facility from various places around the world

Date: 04/01/80 08:41:36
To: wheeler

Greetings from the VM ZOO

After trying CJNTEL, the whole thing makes more sense. However, unfortunately, since we are not DIRECTLY on the U.S. tieline net, any listings for anyone in this building, which would include many of the Toronto people who have regular contacts with people elsewhere in the world, will be incorrect. No-one will have much luck calling me on xxx-xxxx unless they also know my extension, xxxx, so the call can be transferred.

Anyhow. I gather that input to the directory is basically voluntary (the directory we are putting online is pulled directly from the IMS personnel DB weekly). If someone provides you with a starter file, I would guess that a fair number of HQ and lab users would add themselves to it. I will ask around to see if "someone" will volunteer to assist me on it.

Our current priorities are:

1) get the Toronto directory online 2) convince HQ that there should be a Canada directory, and put it online I have discussed the situation with the person in our dept who is putting up the Toronto directory, and have concluded that we may eventually a) make a facility similar to CJNTEL (minus update capability) available to the world b) investigate the possibility of CJNTEL and ours talking to each other

But first comes the Toronto directory, as an office automation service. Managers are finally getting turned on to the idea of screens for all the right reasons. The current schedule is that my manager, his manager, etc all the way up to the VP level will be online later this summer. Strangely the push is from the top down - our VP got his end of Feb, and our director in March (plus their secretaries of course)

P.S. what is VMSHARE LIST. Looks like interesting stuff from the titles - are individual files available ?


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

a couple recent posts mentioning vmshare:
https://www.garlic.com/~lynn/2006v.html#22 vmshare
https://www.garlic.com/~lynn/2006v.html#40 vmshare

"VMSHARE LIST" was list of new/changed vmshare computer conferencing files from the latest distribution sent to me by Tymshare.

Why so little parallelism?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why so little parallelism?
Newsgroups: comp.arch,alt.folklore.computers
Date: Tue, 12 Dec 2006 17:19:00 -0700
eugene@cse.ucsc.edu (Eugene Miya) writes:
Well I would not give Nick credit. This idea went back to the IBM TF-1 and people thought for 3 orders of magnitude they would take the "power" for no languages. They'd be willing to hand machine code. They didn't buy into it and the TF-1 was never completed. Sure the GF-11 was, barely and it ran 8 GFs. Nor was a big RP3 ever made.

the major funding organizaton for RP3 asked my wife to do a technical audit of the project ... her basic conclusion was that they shouldn't continue to fund it (which they stopped doing) ... not too long after that, it died.

that may have contributed to
https://www.garlic.com/~lynn/2006w.html#21 SNA/VTAM for NSFNET
and
https://www.garlic.com/~lynn/2006w.html#20 cluster-in-a-rack

actually some of the goings on mentioned in "SNA/VTAM for NSFNET" happened before my wife audited RP3 and recommended terminating RP3 funding.

misc. past posts mentioning RP3
https://www.garlic.com/~lynn/99.html#136a checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/2000c.html#6 TF-1
https://www.garlic.com/~lynn/2000d.html#27 Superduper computers--why RISC not 390?
https://www.garlic.com/~lynn/2005q.html#46 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005q.html#47 Intel strikes back with a parallel x86 design

Generalised approach to storing address details

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Generalised approach to storing address details
Newsgroups: comp.databases.theory
Date: Tue, 12 Dec 2006 18:47:23 -0700
paul c <toledobythesea@oohay.ac> writes:
Look for some other sources. It shouldn't be hard to see that Codd's early effort was not part of a concerted research effort and it shouldn't be hard to see that one of his big interests was to show what adhoc, illogical quicksand the typical, physically-oriented database efforts of the day were built on, such as IBM's IMS and Vandl and all the Cincom and IDS stuff. It wasn't so much cost that Codd was interested in but rather dispelling some of the nonsense. In many endeavours, dispelling nonsense can reduce costs. Obviously savings would arise from one of his main points, the idea of sharing data rather than replicating it as those "DB" products did, but the fact was that at that time, the bulk of commercial data was not even maintained by so-called dbms'es, rather file-based applications.

there were some arguments between stl/ims people and sjr/systemr people that i've mentioned several times before ... misc. past posts mentioning system/r
https://www.garlic.com/~lynn/submain.html#systemr

the ims people claiming that (system/r) built-in index doubled the physical disk space ... and drastically increased the number of disk i/os to access the data (as part of processing the index)

the system/r people claiming that the built in index eliminated a lot of the manual intensive effort required to manage the direct (physical) record pointers found in IMS data (in some sense the implicit index used by the relational implementation allowed for eliminating direct record pointers in the 60s physical database implementations)

the trade-off was the manual IMS effort vis-a-vis disk and processing overhead in system/r.

the transition somewhat came in the mid-80s ... as people became more expensive and skilled resources became scarce ... at the same time disk space was rapidly increasing and the price/bit was rapidly decreasing. at the same time, the amount of real memory in systems was rapidly increasing ... which allowed for significant caching of indexes. the combination met the space/cost for the indexes was rapdily declining and the caching significantly reduced the index processing overhead. the manual/computer cost trade-offs changed ... but in some cases just the lack of the manual skills met not being able to automate (the difference between automated or not automated can be much larger than the infrastructure costs).

note however, there continue to be periodic claims that in commercial environments, IMS databases still continue to manage much more data ... than the amount of data in rdbms databases.

also, while relational may have somewhat improved application data sharing ... various RDBMS issues, like normalization can still be quite daunting ... especially if you are dealing with widely differing projects. something over a decade ago, we looked at a number of large enterprises ... and one specific example wasn't too unusual ... where an enterprise found they had something like 6000 different RDBMS ... and they believed that well over 90percent of the data was common across the 6000 different RDBMS.

IBM sues maker of Intel-based Mainframe clones

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM sues maker of Intel-based Mainframe clones
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 13 Dec 2006 07:05:40 -0700
Anne & Lynn Wheeler <lynn@garlic.com> writes:
had gone on to do something he called RASP ... sort of a page mapped VS1 system (somewhat TSS/360 like) which was eventually killed. he left and joined Amdahl in dallas and resumed the project. supposedly all new code was done in clean room ... but there was still some litigation/discovery whether aspen contained any RASP code.

re:
https://www.garlic.com/~lynn/2006w.html#24 IBM sues maker of Intel-based Mainframe clones

... and from long ago and far away about aspen ...

Date: 09/07/82 14:42:21
From: wheeler

talked to somebody about Amdahl RASP. IBM has had quite a large attrition rate in the RASP group ... a large portion going to Amdahl.


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

Date: 83/03/30 20:39:34
To: wheeler

I sent you a PL/AS document.

Just heard that "build order" for PCs this year (old + XT, together, I think) is nearly xxxx.

Amdahl is apparently is about to announce his RASP look-alike... they have already given it to a couple of customers under non-disclosure agreements.


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

Date: Wed, 11 Nov 1987 07:59:36 PST
From: wheeler

re: Amdahl unix & "RASP"; I've been saying that Amdahl's RASP system would make a very good base kernel for their unix system (ever since the guy from princeton that did the 370 port joined them). what i didn't know was that simpson wasn't having anything to do with it ... he apparently was insisting on building an mvs killer.


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

Descriptive term for reentrant program that nonetheless is

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Descriptive term for reentrant program that nonetheless is
Newsgroups: bit.listserv.ibm-main
Date: Wed, 13 Dec 2006 08:44:46 -0700
gilmap@ibm-main.lst (Paul Gilmartin) writes:
In the diachronic view, many strange things are possible. Suppose the archetypal MVS FTP client was written (in Pascal?) long before Unix System Services to do QSAM I/O to DD names INPUT and OUTPUT. The most economical accommodation to UNIX might then have been to add DYNALLOCs:

alloc dd(INPUT) path('/dev/fd/0') ... alloc dd(OUTPUT) path('/dev/fd/1') ...

and leave the rest of the code unchanged. But then concurrent invocations of FTP with _BPX_SHAREAS=YES would contend for the DD names.


long ago and far away ... the vm tcp/ip product implementation was made available on mvs ... in part, by writing a simulator for the necessary vm diagnose instructions. the original vm tcp/ip implementation had been done in vs/pascal.

recent reference
https://www.garlic.com/~lynn/2006w.html#21 SNA/VTAM for NSFNET

there is also folklore about the outside contractor that was hired to do the vtam tcp/ip implementation.

the initial implementation benchmarked with tcp/ip running much faster than lu6.2. he was then told that the only way that tcp/ip implementation could run faster than lu6.2 was if there was a bug in the implementation ... and the project wouldn't be accepted until all bugs were fixed (including the one where tcp/ip ran much faster than lu6.2 rather than much slower than lu6.2).

Does Public Key Authentication offer additional security over SSH/SFTP

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Does Public Key Authentication offer additional security over SSH/SFTP
Newsgroups: comp.security.ssh
Date: Wed, 13 Dec 2006 11:17:37 -0700
"Marty W" <Captain.Wing@gmail.com> writes:
I've got a fairly newbie (but hopefully quick) question. So I've set up a public/private key pair on my Unix boxes for authentication for my SSH/SFTP connections so I don't have to provide my password.

Does setting this up provide an extra layer of security (ie additional encryption) ?


the shared-secret (pins/password) is that the authentication information (on the server end) is the same as the originating information. as a result there is frequent requirements that a unique pin/password is required for every different security domain. over the decades, this has progressed so that people possibly now are burdened with scores of passwords.

to top it off, the passwords are supposedly selected to be hard to guess ... but that also tends to make them hard to remember. as a result, it is scores of impossible to remember passwords ... leading to frequent result that all the passwords are written down on piece of paper ... which becomes a vulnerability in itself. misc. postings mentioning shared-secret (pins, password, etc) issues.
https://www.garlic.com/~lynn/subintegrity.html#secrets

old 1APR password corporate directive from 1984:
https://www.garlic.com/~lynn/2001d.html#51 A beautiful morning in AFM
https://www.garlic.com/~lynn/2001d.html#52 A beautiful morning in AFM

so public key has the characteristic that the information used to originate the authentication is different from the information used to perform the authentication ... aka learning the public key doesn't imply that it is possible to fraudulent impersonate (like the case for shared-secret passwords). this eliminates the motivation for unique key for ever different security domain ... and theoretically allows for the same public key to be registered for all authentications.

old public key operation proposal from 1981
https://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network
https://www.garlic.com/~lynn/2006w.html#15 more secure communication over the network
https://www.garlic.com/~lynn/2006w.html#18 more secure communication over the network

misc. recent password news item URLs:

Successful Alternatives to Password Authentication?
http://ask.slashdot.org/askslashdot/06/11/10/2142218.shtml
Chinese malware takes aim at passwords
http://www.theinquirer.net/default.aspx?article=35909
The End of Password Post-Its
http://www.darkreading.com/document.asp?doc_id=111200
RSA Security research shows volume of business passwords overwhelming end users and hindering IT security efforts
http://www.ameinfo.com/103400.html
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
Warning over use of repeat passwords
http://www.linuxsecurity.com/content/view/126036/169/
Second Word Zero-day Exploit Steals Passwords
http://www.techweb.com/showArticle.jhtml?articleID=196603174
Most play poorly at the password game
http://seattlepi.nwsource.com/business/295495_password11ww.html

Decimal FP

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Decimal FP
Newsgroups: bit.listserv.ibm-main
Date: Wed, 13 Dec 2006 17:10:34 -0700
> I know that's what IBM says it meant. I don't believe them, I think
> SPOOL always meant spool.


quick search engine, here is somebody's web page
http://webpages.charter.net/thecomputercollection/ibm1410/ibm1410.htm claiming that the 1410 program was called spool.

another reference:
http://www.dacs.org/archive/0007/feature4.htm

from above:
1) 709/1401 SPOOL system peripheral operations offline
2) 360 SPOOL system peripheral operations online


... snip ...

one might imagine that the acronym was chosen because of winding onto and off of the tape reel(?)

my 1st programming job was to port 1401 "MPIO" program to 360/30.

the 1401 was doing front end unit record to/from tape for the university's 709. they replaced the 1401 with 360/m30 which could still run the program in 1401 emulation. for whatever reason i got the job of doing a port of MPIO to native 360. I got to design and implement my own monitor, interrupt handler, storage allocation, device drivers, etc.

a few past posts mentioning MPIO
https://www.garlic.com/~lynn/95.html#4 1401 overlap instructions
https://www.garlic.com/~lynn/97.html#21 IBM 1401's claim to fame
https://www.garlic.com/~lynn/2002f.html#47 How Long have you worked with MF's ? (poll)
https://www.garlic.com/~lynn/2002q.html#29 Collating on the S/360-2540 card reader?
https://www.garlic.com/~lynn/2004f.html#49 can a program be run withour main memory?
https://www.garlic.com/~lynn/2005q.html#7 HASP/ASP JES/JES2/JES3
https://www.garlic.com/~lynn/2006b.html#2 Mount a tape

and for whatever reason, a couple of the above are the number one response when i tried search engines.

'Innovation' and other crimes

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 'Innovation' and other crimes
Newsgroups: alt.folklore.computers
Date: Wed, 13 Dec 2006 17:25:23 -0700
eugene@cse.ucsc.edu (Eugene Miya) writes:
Lonely Planet Travel guides just published a book on Micronations. The first is Sealand.

some sealand pictures from this summer
https://financialcryptography.com/mt/archives/000763.html
https://financialcryptography.com/mt/archives/000768.html

and some additional discussion
https://financialcryptography.com/mt/archives/000808.html

in the above blog entry ... i even made some comments about mt. umunhum

which then resulted in this additional topic drift the next day here in a.f.c
https://www.garlic.com/~lynn/2006q.html#2 Your Mother Saves Data on Eight-Track Tapes

Decimal FP

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Decimal FP
Newsgroups: bit.listserv.ibm-main
Date: Thu, 14 Dec 2006 08:46:24 -0700
jayarelim@ibm-main.lst (J R) writes:
I think we all acknowledge that SPOOL was contrived to mean "Simultaneous Peripheral Operations On Line". The doubt expressed within this thread relates to whether anyone ever really thought of it as an acronym or were we merely using the English noun/verb with the same connotation.

re:
https://www.garlic.com/~lynn/2006w.html#31 Decimal FP

another search engine reference
http://www.dacs.org/archive/0007/feature4.htm

turns up that it originally met system peripheral operations offline for 709x/1401 operations ... it supposedly morphed to simultaneous peripheral operations online for 360 ... with transition to SPOOLing being done on the same machine.

from the referenced web site:
On 7090 On 1401 Card Reader 100 cpm 800 cpm Card Punch 100 cpm 250 cpm Line Printer 150 lpm 600 lpm

cpm = cards per minute lpm = lines per minute


Top versus bottom posting was Re: IBM sues maker of Intel-based Mainframe clones

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Top versus bottom posting was Re: IBM sues maker of Intel-based Mainframe clones
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 14 Dec 2006 10:13:26 -0700
Howard Brazee <howard@brazee.net> writes:
bit.listserv.ibm-main is created as a service to make the listserver more available. People subscribe to the listserv, its rules and conventions have priority. Although no rules have priority over simple consideration of other people.

I don't know who added alt.folklore.computers to this discussion.


I made the original post, x-posted to both bit.listserv.ibm-main and alt.folklore.computers ... I didn't "add" alt.folklore.computer to an existing thread ... since I had made the original posting
https://www.garlic.com/~lynn/2006w.html#1 IBM sues maker of Intel-based Mainframe clones

and included a reference in the above post to an earlier post that had some historical references
https://www.garlic.com/~lynn/2006v.html#47 Why so little parallelism?

including some stuff about the original 23jun68 unbundling announcement was motivated by various litigation. the original unbundling didn't included kernel software ... arguing that kernel software would continue to be free since it was required for the operation of the hardware. misc. posts mentioning unbundling
https://www.garlic.com/~lynn/submain.html#unbundle

as market forces changed and mainframe clone processors appeared on the scene ... there was transition to charging for kernel software. my resource manager got to be the guinea pig for kernel software charging ... and i got to spend some amount of time with the business people working out policies for kernel software charging. misc. posts mentioning dynamic adaptive scheduling, page management algorithms, etc ... some fot he stuff that was shipped in my resource manager
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock

for somewhat more convolution ... supposedly a prime motivation for the (failed/conceled) future system project
https://www.garlic.com/~lynn/submain.html#futuresys

was clone control units. when i was undergraduate one of the projects i worked on was a clone terminal bcontrollerb (started out using interdata/3), in part because the 2702 wouldn't do some stuff that i wanted it to do. later there was some article blaming four of us for (some part of) the clone controller business. misc. past posts mentioning having worked on clone controller
https://www.garlic.com/~lynn/submain.html#360pcm

now as to clone processors ... Amdahl gave a talk in the early 70s at MIT ... where he got a lot of questions about leaving and starting his own processor business. One of his replies was something about even if IBM were to totally walk away from 360/370 business (which could be construed as a veiled reference to the future system project) ... there was already enuf 360/370 customer application software to keep him in business thru the end of the century (possibly believing that ibm was walking away from the 360/370 business, helped motivate Amdahl to leave to build his own 360/370s?????)

... now some of the above was also my second post in the same thread
https://www.garlic.com/~lynn/2006w.html#2 IBM sues make of Intel-based Mainframe clones

so some of the archaeological references related to clone processors and the transition to licensing of kernel software have some bearing on the current subject ... and was why i had included a.f.c in the original post.

other posts related to this same thread:
https://www.garlic.com/~lynn/2006w.html#3 IBM sues maker of Intel-based Mainframe clones
https://www.garlic.com/~lynn/2006w.html#13 IBM sues maker of Intel-based Mainframe clones
https://www.garlic.com/~lynn/2006w.html#14 IBM sues maker of Intel-based Mainframe clones
https://www.garlic.com/~lynn/2006w.html#20 cluster-in-a-rack
https://www.garlic.com/~lynn/2006w.html#24 IBM sues maker of Intel-based Mainframe clones
https://www.garlic.com/~lynn/2006w.html#28 IBM sues maker of Intel-based Mainframe clones

Top versus bottom posting was Re: IBM sues maker of Intel-based Mainframe clones

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Top versus bottom posting was Re: IBM sues maker of Intel-based Mainframe clones
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 14 Dec 2006 10:33:42 -0700
Howard Brazee <howard@brazee.net> writes:
bit.listserv.ibm-main is created as a service to make the listserver more available. People subscribe to the listserv, its rules and conventions have priority. Although no rules have priority over simple consideration of other people.

re:
https://www.garlic.com/~lynn/2006w.html#34 Top versus bottom posting was Re: IBM sues maker of Intel-based Mainframe clones

for other drift ... bitnet (misc. posts mentioning bitnet and/or earn)
https://www.garlic.com/~lynn/subnetwork.html#bitnet

adopted some similar technology that was being used in the internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet

the internal network was larger than the internet/arpanet from just about the beginning until possibly sometime mid-85. misc. posts on internet and internal network
https://www.garlic.com/~lynn/internet.htm

and old posting about the size of internal network in '83 (passing 1000 nodes) ...
https://www.garlic.com/~lynn/internet.htm#22

when the arpanet had its great conversion to internetworking protocol at this time, arpanet had something between 100 and 255 nodes ... depending on who is counting ... misc. recent posts
https://www.garlic.com/~lynn/2006k.html#40 Arpa address
https://www.garlic.com/~lynn/2006r.html#7 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006u.html#6 The Future of CPUs: What's After Multi-Core?

now the bitnet listserv was somewhat similar to the earlier internal TOOLSRUN that operated in sort of a usenet type mode (aka local repository) but also offered mailing list mode.

TOOLSRUN was somewhat the outgrowth of lots of investigation into some emerging computer conferencing stuff that I had done ... and got blameed for something that came to be called "tandem memos" ... where i was doing semi-automated mailing list type of operation.

there was subsequently a stanford phd thesis, lots of papers, and some books on some aspects of the subject (computer mediated conversation)
https://www.garlic.com/~lynn/subnetwork.html#cmc

a researcher was hired to set in the back of my office for nine months and take notes on how i communicated. they also got copies of all my incoming and outgoing email as well as logs of all my instant messages. this was the material that went into the stanford phd thesis as well as the other papers and books.

misc. past posts mentioning tandem memos
https://www.garlic.com/~lynn/2001g.html#5 New IBM history book out
https://www.garlic.com/~lynn/2001g.html#6 New IBM history book out
https://www.garlic.com/~lynn/2001g.html#7 New IBM history book out
https://www.garlic.com/~lynn/2001j.html#31 Title Inflation
https://www.garlic.com/~lynn/2002k.html#39 Vnet : Unbelievable
https://www.garlic.com/~lynn/2002o.html#73 They Got Mail: Not-So-Fond Farewells
https://www.garlic.com/~lynn/2002q.html#16 cost of crossing kernel/user boundary
https://www.garlic.com/~lynn/2002q.html#38 ibm time machine in new york times?
https://www.garlic.com/~lynn/2004k.html#66 Question About VM List
https://www.garlic.com/~lynn/2005c.html#50 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005d.html#37 Thou shalt have no other gods before the ANSI C standard
https://www.garlic.com/~lynn/2005q.html#5 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2006h.html#9 It's official: "nuke" infected Windows PCs instead of fixing them
https://www.garlic.com/~lynn/2006l.html#24 Google Architecture
https://www.garlic.com/~lynn/2006l.html#51 the new math: old battle of the sexes was: PDP-1
https://www.garlic.com/~lynn/2006r.html#11 Was FORTRAN buggy?

What does a patent do that copyright does not?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What does a patent do that copyright does not?
Newsgroups: bit.listserv.ibm-main
Date: Thu, 14 Dec 2006 12:57:38 -0700
charlesm@ibm-main.lst (Charles Mills) writes:
Public key cryptography was one of my inspirations. Discussion of canceled credit cards here http://cikeep.com/faq.htm.

suggestion from 1981 on public key (little i) infrastructure:
https://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network
https://www.garlic.com/~lynn/2006w.html#15 more secure communication over the network
https://www.garlic.com/~lynn/2006w.html#18 more secure communication over the network

for other drift ...

in the mid-90s, the x9a10 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

What does a patent do that copyright does not?

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What does a patent do that copyright does not?
Newsgroups: bit.listserv.ibm-main
Date: Thu, 14 Dec 2006 13:04:07 -0700
Howard Brazee <howard@brazee.net> writes:
A while back Wintel wanted to sell the idea of having software look up a unique number on a computer chip. People complained about privacy issues.

But the big problem for me is the way Windows is designed to make it very difficult to replace hardware or to turn tested backup machines into the main machine when the old machine breaks.


ref:
https://www.garlic.com/~lynn/2006w.html#36 What does a patent do that copyright does not?

that was serial number in the PC ... subsequent has been TPM chip ... i gave a talk on assurance at the 2001 intel developer's conference in the TPM track.
https://www.garlic.com/~lynn/index.html#presentation

The talk was somewhat on the aads chip strawman
https://www.garlic.com/~lynn/x959.html#aads

and the guy running tpm was in the front row ... so i somewhat facetiously quipped that it was nice to see that over the past couple years, the TPM chip design had come to look more and more like the aads chip strawman ... he quipped back that was because I didn't have a committee of 200 people helping me design a chip.

Why so little parallelism?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why so little parallelism?
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 15 Dec 2006 11:56:31 -0700
eugene@cse.ucsc.edu (Eugene Miya) writes:
Sure. Your major funding organization makes business machines, not research machines.

It merely happens that it has 3 things it chose to name Research Centers and a number of lesser "Science" centers and similarly acronymed facilities.


re:
https://www.garlic.com/~lynn/2006w.html#26 Why so little parallelism?
https://www.garlic.com/~lynn/2006w.html#21 SNA/VTAM for NSFNET
https://www.garlic.com/~lynn/2006w.html#20 cluster-in-a-rack

the major funding organization for RP3 was not the business machine unit ... this particular organization had been responsible for a lot of machines used in various gov. operations.

Why so little parallelism?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why so little parallelism?
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 15 Dec 2006 11:59:44 -0700
eugene@cse.ucsc.edu (Eugene Miya) writes:
I sat in on Greg Pfister's presentation at SJ RC (with numerous people outside IBM like DEC). Sounded like an interesting case study in O(N lg n) interconnection architectures like the NYU Ultracomputer. Then one of your employees asked the question about whether the RP3 would be instruction set compatible with the 370-line (he clearly had not been listening to the earlier CPU portion of the talk but also aligned with the pre-PC mainframe mind set). But that's history.

Later when we were approached to buy one, gee that's over 20 years ago, and unlike most NDAs that I've signed, IBM is still in existence. Anyways, it was your choice. You guys don't have research in your names.

Other than Greg's book, I only hope we can preserve history, as opposed to economic revisionism. What's left of the hardware, what ever is left except for the cited RIOS, is on the East Coast.


re:
https://www.garlic.com/~lynn/2006w.html#26 Why so little parallelism?
https://www.garlic.com/~lynn/2006w.html#21 SNA/VTAM for NSFNET
https://www.garlic.com/~lynn/2006w.html#20 cluster-in-a-rack

my wife's analysis of RP3 had nothing to do with 370 instruction set compatibility ... it had more to do with whether it could really achieved the scale-up being claimed .... especially in the (mostly federal) gov. market segment.

i haven't tried to do either ... i've just presented actual email exchanges from the period.

Why so little parallelism?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why so little parallelism?
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 15 Dec 2006 12:20:09 -0700
eugene@cse.ucsc.edu (Eugene Miya) writes:
I sat in on Greg Pfister's presentation at SJ RC (with numerous people outside IBM like DEC). Sounded like an interesting case study in O(N lg n) interconnection architectures like the NYU Ultracomputer. Then one of your employees asked the question about whether the RP3 would be instruction set compatible with the 370-line (he clearly had not been listening to the earlier CPU portion of the talk but also aligned with the pre-PC mainframe mind set). But that's history.

re:
https://www.garlic.com/~lynn/2006w.html#26 Why so little parallelism?
https://www.garlic.com/~lynn/2006w.html#38 Why so little parallelism?
https://www.garlic.com/~lynn/2006w.html#39 Why so little parallelism?

and with regard to even statement about 128 processor configuration discussed here in a meeting in ellison's conference room
https://www.garlic.com/~lynn/95.html#13
https://www.garlic.com/~lynn/96.html#15
and
https://www.garlic.com/~lynn/2001n.html#83

here is greg pfister's comment in old post/thread that ran in comp.arch, comp.sys.super, alt.folklore.computers
https://www.garlic.com/~lynn/2000c.html#21 Cache coherence [as re: TF-1]

Greg Pfister writes:
I never heard anybody say 128-way, and I was somewhat in the middle of this. What I saw was that it was always intended as an SMP replacement (yes, SMP, don't ask, some people's heads were in a strange place then). The software bill, not the hardware, was always the sticking point. Anyway, the SP became by definition the "right" solution, and Live Oak was not resurrected again.

... snip ...

more in that same thread
https://www.garlic.com/~lynn/2000c.html#12 Cache coherence [as re: TF-1]
https://www.garlic.com/~lynn/2000c.html#22 Cache coherence [as re: TF-1]

the cluster-in-a-rack/MEDUSA was 32 processors in a rack ... and the discussion in the meeting in ellison's conference room was to have four rack operation (128 processors) in customer shops by ye92. this was before the project got transferred to kingston and we were told we couldn't work on systems with more than four processors.

a couple recent postings with old email discussing MEDUSA and cluster-in-a-rack
https://www.garlic.com/~lynn/2006w.html#13 IBM sues maker of Intel-based Mainframe clones
https://www.garlic.com/~lynn/2006w.html#14 IBM sues maker of Intel-based Mainframe clones
https://www.garlic.com/~lynn/2006w.html#20 cluster-in-a-rack

misc. other posts mentioning RP3
https://www.garlic.com/~lynn/99.html#136a checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/2000c.html#6 TF-1
https://www.garlic.com/~lynn/2000d.html#27 Superduper computers--why RISC not 390?
https://www.garlic.com/~lynn/2005q.html#46 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005q.html#47 Intel strikes back with a parallel x86 design

Why so little parallelism?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why so little parallelism?
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 15 Dec 2006 13:06:56 -0700
Anne & Lynn Wheeler <lynn@garlic.com> writes:
more in that same thread
https://www.garlic.com/~lynn/2000c.html#22 Cache coherence [was re: TF-1]


re:
https://www.garlic.com/~lynn/2006w.html#40 Why so little parallelism?
https://www.garlic.com/~lynn/2000c.html#21 Cache coherenece [was re: TF-1]

oh and Pfister's comment was in response to this posting earlier in the thread
https://www.garlic.com/~lynn/2000c.html#12 Cache coherenece [was re: TF-1]

from above post:

Anne & Lynn Wheeler <lynn@garlic.com> writes:
part of the issue was that we could demonstrate 16-way and quick path to 128-way (and above) using standard existing chips & motherboards with interconnect fabric (even demonstrate interconnect fabric on existing workstations in racks ... but some additional manufacturing cost savings by packaging standard mother boards for high-density rack mounting ... racks had to have some cooling characteristics to achieve the high-density packaging of the mother boards).

aka cluster-in-a-rack/MEDUSA
https://www.garlic.com/~lynn/2006w.html#13 IBM sues make of Intel-based Mainframe clones
https://www.garlic.com/~lynn/2006w.html#14 IBM sues make of Intel-based Mainframe clones
https://www.garlic.com/~lynn/2006w.html#20 cluster-in-a-rack

and Greg's response from:
https://www.garlic.com/~lynn/2000c.html#21 Cache coherence [as re: TF-1]

Greg Pfister writes:
I never heard anybody say 128-way, and I was somewhat in the middle of this. What I saw was that it was always intended as an SMP replacement (yes, SMP, don't ask, some people's heads were in a strange place then). The software bill, not the hardware, was always the sticking point. Anyway, the SP became by definition the "right" solution, and Live Oak was not resurrected again.

for other drift ... in one of the recent postings referencing cluster-in-a-rack/MEDUSA
https://www.garlic.com/~lynn/2006w.html#14 IBM sues make of Intel-based Mainframe clones

i also mentioned at having looked at doing (relatively) high density processor packaging in racks (for the times) in 1985
https://www.garlic.com/~lynn/2004m.html#17 mainframe and microprocessor

for the heck of it ... old email mentioning cluster-in-a-rack/MEDUSA (from referenced posts):
https://www.garlic.com/~lynn/2006w.html#email910910
https://www.garlic.com/~lynn/2006w.html#email911014
https://www.garlic.com/~lynn/2006w.html#email911024
https://www.garlic.com/~lynn/2006w.html#email911119

vmshare

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vmshare
Newsgroups: alt.folklore.computers
Date: Fri, 15 Dec 2006 16:01:42 -0700
re:
https://www.garlic.com/~lynn/2006v.html#22 vmshare

there is thread running in bit.listserv.ibm-main about convention buttons ... so i thot i would check old vmshare archive ... which leads to lots of topic drift

an old vmshare button ref from 1984
http://vm.marist.edu/~vmshare/browse.cgi?fn=BUTTON62&ft=MEMO

and old vmshare humor reference including some references to buttons
http://vm.marist.edu/~vmshare/browse.cgi?fn=HUMOR&ft=MEMO

for some additional drift, the above has a reference from net.speak, including:
PROFS Professional Office System. An IBM calendar and email program that runsin a VM environment. PROFS came to national attention during the Iran-Contra when it was learned that Oliver North and his associates communicated using PROFS email, unwittingly leaving an electronic trail of their strategems. North thought he had erased all incriminating email messages, but had not, in fact, eradicated all vestiges of his online communications.

... snip ...

I was a very strong proponent of repeated backup/archives.

I had done the CMSBACK design, implementation and deployment, a few recent references
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?
https://www.garlic.com/~lynn/2006v.html#24 Z/Os Storage Mgmt products
https://www.garlic.com/~lynn/2006w.html#16 intersection between autolog command and cmsback (more history)

as well as some number of collected posts mentioning backup/archive
https://www.garlic.com/~lynn/submain.html#backup

I had backups of stuff from the 60s (at the univ.) and the 70s (from the science center). However, I've mentioned before that these were wiped out in the almaden tape library. for a time they had a problem with operations randomly pulling tapes from the library for scratch tapes. a couple past refs:
https://www.garlic.com/~lynn/2003i.html#13 A Dark Day
https://www.garlic.com/~lynn/2003j.html#14 A Dark Day
https://www.garlic.com/~lynn/2003j.html#45 Hand cranking telephones
https://www.garlic.com/~lynn/2003m.html#12 Seven of Nine
https://www.garlic.com/~lynn/2004b.html#59 A POX on you, Dennis Ritchie!!!

I eventually got a list of about 50 of my tapes that had been wiped out in this manner ... including the following


001018 10FILES, CP/67 SOURCE & SYSTEM
001381 8FILES, CAMBRIDGE WHEELER ARCHIVE
001642 8FILES, CMS SYSTEM & MY FILES
001720 8FILES, RESOURCE MANAGER 3.7, CMS, MISC
001822 10FILES, CP/67 SOURCE & SYSTEM
001954 1FILE, RESOURCE MANAGER 3.4 LISTINGS
002090 10FILES, CP/67 SOURCE & SYSTEM
002826 1FILE, CP2.0 SOURCE
004376 5FILES, CSC/VM 2.15 + LOCAL
004789 8FILES, CAMBRIDGE ARCHIVE

all three duplicate tapes (#1018, #1822, #2090) with cp/67 source & system managed to get wiped

other drift ... recent reference to CSC/VM 2.15 (distribution) system
https://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?

about the only thing that survived was some of the original CMS (cp/67) multi-level source processes; Melinda had contacted me about the availability of such files
https://www.leeandmelindavarian.com/Melinda#VMHist

in the following email, Melinda (also) makes reference to VMSHARE/PCSHARE being moved off Tymshare (i.e. this was in period that M/D bought Tymshare) to McGill ... and Melinda would start being responsible for mailing me a monthly tape of the VMSHARE/PCSHARE files (so i could put them up at various locations on the internal network).

from long ago and far away

Date: Fri, 6 Sep 1985 16:47:51 EDT
From: Melinda
To: wheeler

Lynn, thank you for your note (via Pat) giving your recollections of the origin of the multi-level update facility. I am really enjoying piecing all this together.

Ever since I got your note, I've been puzzling over what you meant by the "'$' stuff". I've finally concluded that the CMS-360 UPDATE must have required sequence numbers in the sequence number columns of the card images being inserted into a file. The preprocessor you mentioned must have filled in sequence numbers with appropriate increments, as UPDATE does today when there is a dollar sign in the ./ I or ./ R statements.

Is that correct?

Thanks again for your help, Melinda

P.S.: The paper I'm working on is to be presented at SEAS later this month. You won't be getting a VMSHARE/PCSHARE tape from me until I get back from SEAS at the end of the month.


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

for more drift, I was somewhat involved in M/D purchase of Tymshare. As part of the purchase M/D was spinning off some number of pieces of Tymshare ... including GNOSIS ... which became KEYKOS. I was brought in to do an audit of GNOSIS as part of the spinoff.

a couple recent posts mentioning GNOSIS and/or KEYKOS
https://www.garlic.com/~lynn/2006k.html#37 PDP-1
https://www.garlic.com/~lynn/2006m.html#34 PDP-1
https://www.garlic.com/~lynn/2006p.html#13 What part of z/OS is the OS?
https://www.garlic.com/~lynn/2006s.html#7 Very slow booting and running and brain-dead OS's?

and more email about multi-level update process ....

Date: Sun, 8 Sep 1985 14:10:41 EDT
From: Melinda
To: wheeler

Lynn, I was truly touched by your having spent part of your Saturday morning loading up those CP-67 EXECs for me. It was extraordinarily thoughtful of you and has helped me answer almost all of my questions about the CP-67 implementation.

I have been working my way through the EXECs and believe that I have them all deciphered now. I was somewhat surprised to see how much of the function was already in place by the Summer of 1970. In particular, I hadn't expected to find that the update logs were being put at the beginning of the textfiles. That has always seemed to me to be one of the most ingenious aspects of the entire scheme, so I wouldn't have been surprised if it hadn't been thought of right away. One thing I can't determine from reading the EXECs is whether the loader was including those update logs in the loadmaps. Do you recall?

Of the function that we now associate with the CTL option of UPDATE, the only substantial piece I see no sign of in those EXECs is the use of auxfiles. Even in the UPAX EXEC from late January, 1971, it is clear that all of the updates listed in the control files were expected to be simple updates, rather than auxfiles. I know, however, that auxfiles were fully implemented by VM/370 Release 1. I have a First Edition of the "VM/370 Command Language User's Guide" (November, 1972) that describes them. The control file syntax at that point was

updlevel upid AUX

Do you have any memories of the origin of auxfiles?

Thank you again,
Melinda


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

for some drift about "auxfiles" the VM development group added auxfile support to the multi-level source update infrastructure (developed by the science center) to handle "PTFs". The multi-level source update had been originally targeted at handling various source level updates (cp67 local, H, I, updates, etc mentioned in past posts). "PTFs" were were specific "bug" fixes ... which might be as little as a single source update with a single instruction change.

in any case, a couple months after the above emails, research moved into the new almaden facility and later there were the problems with allocated tapes being mounted as scratch ... recent post with reference to moving into the new research facility
https://www.garlic.com/~lynn/2006v.html#34 vmshare

CSC/VM posts
https://www.garlic.com/~lynn/submisc.html#cscvm

misc. past posts mentioning PROFS:
https://www.garlic.com/~lynn/2000c.html#46 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2001k.html#35 Newbie TOPS-10 7.03 question
https://www.garlic.com/~lynn/2001k.html#39 Newbie TOPS-10 7.03 question
https://www.garlic.com/~lynn/2001k.html#40 Newbie TOPS-10 7.03 question
https://www.garlic.com/~lynn/2002h.html#58 history of CMS
https://www.garlic.com/~lynn/2002h.html#59 history of CMS
https://www.garlic.com/~lynn/2002h.html#64 history of CMS
https://www.garlic.com/~lynn/2002i.html#50 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002j.html#4 HONE, ****, misc
https://www.garlic.com/~lynn/2002p.html#34 VSE (Was: Re: Refusal to change was Re: LE and COBOL)
https://www.garlic.com/~lynn/2003b.html#45 hyperblock drift, was filesystem structure (long warning)
https://www.garlic.com/~lynn/2003e.html#69 Gartner Office Information Systems 6/2/89
https://www.garlic.com/~lynn/2003j.html#56 Goodbye PROFS
https://www.garlic.com/~lynn/2003m.html#26 Microsoft Internet Patch
https://www.garlic.com/~lynn/2004p.html#13 Mainframe Virus ????
https://www.garlic.com/~lynn/2005t.html#43 FULIST
https://www.garlic.com/~lynn/2006n.html#23 sorting was: The System/360 Model 20 Wasn't As Bad As All That
https://www.garlic.com/~lynn/2006q.html#4 Another BIG Mainframe Bites the Dust

misc. past posts mentioning cms update command and multi-level source management
https://www.garlic.com/~lynn/2000b.html#80 write rings
https://www.garlic.com/~lynn/2001e.html#57 line length (was Re: Babble from "JD" <dyson@jdyson.com>)
https://www.garlic.com/~lynn/2001g.html#46 The Alpha/IA64 Hybrid
https://www.garlic.com/~lynn/2002h.html#67 history of CMS
https://www.garlic.com/~lynn/2002n.html#39 CMS update
https://www.garlic.com/~lynn/2002n.html#73 Home mainframes
https://www.garlic.com/~lynn/2002p.html#2 IBM OS source code
https://www.garlic.com/~lynn/2003.html#58 Card Columns
https://www.garlic.com/~lynn/2003e.html#38 editors/termcap
https://www.garlic.com/~lynn/2003e.html#66 History of project maintenance tools -- what and when?
https://www.garlic.com/~lynn/2003f.html#1 History of project maintenance tools -- what and when?
https://www.garlic.com/~lynn/2003h.html#12 Do Data Models Need to built on a Mathematical Concept?
https://www.garlic.com/~lynn/2003k.html#47 Slashdot: O'Reilly On The Importance Of The Mainframe Heritage
https://www.garlic.com/~lynn/2003l.html#17 how long does (or did) it take to boot a timesharing system?
https://www.garlic.com/~lynn/2004b.html#59 A POX on you, Dennis Ritchie!!!
https://www.garlic.com/~lynn/2004d.html#69 A POX on you, Dennis Ritchie!!!
https://www.garlic.com/~lynn/2004g.html#43 Sequence Numbbers in Location 73-80
https://www.garlic.com/~lynn/2004g.html#44 Sequence Numbbers in Location 73-80
https://www.garlic.com/~lynn/2004h.html#27 Vintage computers are better than modern crap !
https://www.garlic.com/~lynn/2004m.html#30 Shipwrecks
https://www.garlic.com/~lynn/2004o.html#18 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2004o.html#21 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2004o.html#36 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2004p.html#53 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2005i.html#30 Status of Software Reuse?
https://www.garlic.com/~lynn/2005i.html#39 Behavior in undefined areas?
https://www.garlic.com/~lynn/2005m.html#38 Massive i/o
https://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3
https://www.garlic.com/~lynn/2005r.html#5 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005r.html#6 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2006.html#28 DCSS as SWAP disk for z/Linux
https://www.garlic.com/~lynn/2006b.html#10 IBM 3090/VM Humor
https://www.garlic.com/~lynn/2006e.html#7 About TLB in lower-level caches
https://www.garlic.com/~lynn/2006f.html#5 3380-3390 Conversion - DISAPPOINTMENT
https://www.garlic.com/~lynn/2006f.html#21 Over my head in a JES exit
https://www.garlic.com/~lynn/2006f.html#38 Over my head in a JES exit
https://www.garlic.com/~lynn/2006n.html#45 sorting
https://www.garlic.com/~lynn/2006o.html#14 SEQUENCE NUMBERS
https://www.garlic.com/~lynn/2006o.html#19 Source maintenance was Re: SEQUENCE NUMBERS
https://www.garlic.com/~lynn/2006q.html#45 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006t.html#24 CMSBACK
https://www.garlic.com/~lynn/2006u.html#26 Assembler question
https://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?

IBM sues maker of Intel-based Mainframe clones

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM sues maker of Intel-based Mainframe clones
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 15 Dec 2006 17:06:46 -0700
sidd@situ.com () writes:
At its peak, about 3500 computers were connected to BITNET; today there are about 900, with the number falling each month, especially in the U.S. BITNET continues to expand in some areas of the world, such as Persian Gulf region. CREN, BITNET's operating authority in the U.S., decided to suspend operation of the network at the end of 1996. TERENA, the corresponding authority in Europe, wants to continue service until the end of 1997. Parts of the network may disappear sooner, as universities and research labs depart and the mesh of interconnections falls apart.

and another recent reference:
https://www.garlic.com/~lynn/2006w.html#35

for some more EARN-specific (european version of bitnet)

for other drift, the last paragraph refers to a deal where we were exchanging offspring for the summer, one of mine for one of his (and possibly one of his friends).

note: Erich Bloch was director of the National Science Foundation for much of the 80s.

Date: 7 June 1985, 16:28:41
To: wheeler

I basically agree with your proposal to present to the EARN board as suggested by Dennis Jennings (who was the EARN BoD chairman last year) I have a lot of papers on HSDT, but could you please send me a copy of the presentation you made to Erich Bloch and Dennis Jennings together with some more detailed information you may have (I understand that the details are still confidential, so the presentation does not probably tell too much...).

Before taking a final decision, I have to talk to my boss, who will certainly agree, and I would like to have your input to give him a good view.

A possibility would be to spend few hours at the beginning of your stay, either to brief the EARN chairman and few interested people, or to give a broader talk to the EARN Board of Directors who is meeting on July 25 26 in Sweden.(By the way, David Lord, the EARN chairman is from CERN).

Have you some news for the friend of Thomas? they are both very anxious, and he will be very disappointed if he cannot go... If it works, I assume it will be an exchange?


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

lots of past posts mentioning HSDT
https://www.garlic.com/~lynn/subnetwork.html#hsdt

another posting with some old (EARN) email from 20mar84
https://www.garlic.com/~lynn/2001h.html#65

recent post containing old email putting in a connection between BITNET
https://www.garlic.com/~lynn/2006t.html#43

and VNET, the internal corporate network
https://www.garlic.com/~lynn/subnetwork.html#internalnet

and a couple other related postings touching on some of the subject:
https://www.garlic.com/~lynn/2006s.html#50
https://www.garlic.com/~lynn/2006t.html#6

and collected posts mentioning bitnet &/or earn
https://www.garlic.com/~lynn/subnetwork.html#bitnet

more secure communication over the network

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: more secure communication over the network
Newsgroups: alt.folklore.computers
Date: Fri, 15 Dec 2006 18:41:13 -0700
recent posts mentioning CJNTEL:
https://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network
https://www.garlic.com/~lynn/2006w.html#16 intersection between autolog command and cmsback (more history)
https://www.garlic.com/~lynn/2006w.html#25 To RISC or not to RISC

The following is a little difference of opinion about the internal CJNTEL vis-a-vis the internal TELE ... as if it was either/or (aka CJNTEL was upgraded in the late 70s to support queries for both the CJNTEL file as well as the TELE phone books).

Date: 09/09/85 11:50:09
To: wheeler
CC: ????

From the latest issue of CSNET news, Summer '85... There is an article by Peter Denning, Chairman of the CSNET Executive Committee... Under the heading "Lessons for the Future" is included the following paragraph. Seems to me to describe the CJNTEL PHONE experience very well...

"* The concept of a user-managed name server does not work as well as we had hoped. We had originally thought that the CSNET Name Server's entries would be separately managed and kept up to date by the users. This has not happened. Users move, change mailboxes, and shift their research interests without notifying the Name Server. Thus much of the infolrmation in that database is unreliable. The Executive Committee has recently instructed the CIC (Coordination and Information Center of CSNET, managed by BBN, Bolt, Beranek and Newman) to manage the Name Server so as to achieve a high degree of reliability in its contents. It turns out that most users have been unaffected by the Name Server because it is basically interactive and thus likely to be used only by the ARPANET and X.25 sites. We expect that the new dial-in line to the Name Server will mitigate this. We are committed to increasing the utility of the Name Server for all CSNET members."


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

Date: 9 September 1985, 09:15:29 PDT
To: ???
CC: wheeler
Subject: CJNTEL

The article you reference is a bad analogy because the TELE directories are an incomplete replacement for CJNTEL. The TELE directories do not contain all of the addresses in our network. The CJNTEL system covered all addresses by allowing anyone to add to its directory. There is no mechanism with the TELE directories for a user that is not mentioned in a TELE directory to post his or her network address. The CSNET article does indicate that they are managing a Name Server that does cover all addresses in their network.

It was a bad decision to remove the CJNTEL system before a substitute could be constructed for those who are not covered by TELE directories. Your reference to the CSNET article does not hide this fact. It only shows that CSNET made a better decision.


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

secure payment method

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: secure payment method
Newsgroups: microsoft.public.security
Date: Sat, 16 Dec 2006 10:03:15 -0700
madcaplost <madcaplost@discussions.microsoft.com> writes:
when I make a payment online I've noticed I cannot see the padlock symbol anywhere,does this mean my payments can be seen.I've got pc guard on my computer,does this help?

a couple recent detailed posts about use of SSL/https (typically the thing that causes browsers to display padlock) in securing payments and electronic commerce (as well as various threats and vulnerabilities)
https://www.garlic.com/~lynn/2006t.html#40 Encryption and authentication
https://www.garlic.com/~lynn/2006v.html#49 Patent buster for a method that increases password security
https://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network

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: Sat, 16 Dec 2006 10:11:31 -0700
Anne & Lynn Wheeler <lynn@garlic.com> writes:
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


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

At SIGOPS (Asilomar, 14-16Dec81), I was asked by Jim Gray if I could help a co-worker concerning problem he was having getting his PHD from Stanford. Jim had been at SJR and worked on the original relational/sql database, System/R (before leaving for Tandem)
https://www.garlic.com/~lynn/submain.html#systemr

and was aware of the work that I had done in numerous aspects of virtual memory management; in fact, some of the System/R implementation was based on that work. recent reference
https://www.garlic.com/~lynn/2006w.html#11

The PHD research was on global LRU page replacement algorithms (something I had implemented for CP67 as an undergraduate in the 60s). There were extremely strenuous objections from proponents of local LRU page replacement algorithms that any PHD should be granted on research into global LRU page replacement algorithms.

October 19, 1982

xxxxxxxx
Tandem Computers
19333 Vallco Parkway
Cupertino, CA 95014

Dear xxxxxx:

Sorry to have taken so long to reply concerning your doctoral thesis.

Enclosed is a brief description of several related CP paging matters that I've been involved with since 1968. There is a great deal of similarity between what I had implemented against a CP/67 base and your WSClock algorithm.

In the description, CORTABLE is referred to frequently. There is one CORTABLE entry for each real storage page. The CORTABLE entry contains is used to maintain the current status for each page. The CORTABLE is one contiguous block of real storage containing all CORTABLE entries.

Of particular interest is the fact that the Working Set Dispatcher as implemented by the Grenoble Scientific Center against the same base code actually performed poorer than the algorithm I designed and implemented (as far as I know, I currently have the only complete copy of both sets of code modifications and the associated benchmark information), dispite the fact the Grenoble machine had approximately 160 pageable pages and the Cambridge machine typically had around 105 pageable pages. This design and implementation was released as part of the CP/67 product. Essentially a very similar implementation exists in the current VM/370 (or VM/SP) product (even though the design is from the 60s). I'm attaching two unclassified research reports, VM/370 Modifications (RJ2906) and VM/370 Shared Modules (RJ2928). These reports describe several associated paging system enhancements and give further detail concerning the N.5 page replacement algorithm

Hopefully, the enclosed descriptions will prove helpful, especially in your discussions with Peter Denning.

Sincerely,

Lynn Wheeler

Attachment


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

as mentioned recently, I lost quite a bit of historical information from the 60s and early 70s when numerous tapes were wiped because of problems in Almaden operations
https://www.garlic.com/~lynn/2006w.html#42

The global LRU work had been released in cp67 and then dropped in the initial morph from cp67 to vm370. I was able to re-introduce the implementation into vm370 with my resource manager
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock

recent posts mentioning port of various pieces from cp67 to vm370
https://www.garlic.com/~lynn/2006v.html#36
https://www.garlic.com/~lynn/2006w.html#7
https://www.garlic.com/~lynn/2006w.html#8

There was another issue at work here, while I was originally asked at SIGOPS (14-16Dec81) if I could lend some aid in countering the objections about whether a PHD should be granted for research into global LRU page replacement algoritms, I wasn't permitted to send a reply until Oct82 (almost a year later).

As mentioned here
https://www.garlic.com/~lynn/2006w.html#35

I had gotten blamed for something that had gotten the label "Tandem Memos". Somewhat as a result, I was told that my external communication had to have prior approval from executives and legal. It took ten months to get the approval to send the above letter.

misc other posts this year discussing some of the global/local LRU issues:
https://www.garlic.com/~lynn/2006e.html#7 About TLB in lower-level caches
https://www.garlic.com/~lynn/2006e.html#37 The Pankian Metaphor
https://www.garlic.com/~lynn/2006f.html#0 using 3390 mod-9s
https://www.garlic.com/~lynn/2006i.html#31 virtual memory
https://www.garlic.com/~lynn/2006i.html#36 virtual memory
https://www.garlic.com/~lynn/2006i.html#37 virtual memory
https://www.garlic.com/~lynn/2006i.html#42 virtual memory
https://www.garlic.com/~lynn/2006j.html#1 virtual memory
https://www.garlic.com/~lynn/2006j.html#17 virtual memory
https://www.garlic.com/~lynn/2006j.html#25 virtual memory
https://www.garlic.com/~lynn/2006l.html#14 virtual memory
https://www.garlic.com/~lynn/2006q.html#19 virtual memory
https://www.garlic.com/~lynn/2006q.html#21 virtual memory
https://www.garlic.com/~lynn/2006r.html#34 REAL memory column in SDSF

'Innovation' and other crimes

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 'Innovation' and other crimes
Newsgroups: alt.folklore.computers
Date: Sat, 16 Dec 2006 11:04:17 -0700
"Charlie Gibbs" <cgibbs@kltpzyxm.invalid> writes:
It's been a long evolutionary process, fueled by management's belief that any name used for too long becomes stale. DP begat MIS (Management Information Services), which for some time satisfied the marketroids' need for extra syllables. But that, too, got old. There was a brief flirtation with "IS" (Information Services), but that still carried the connotation that the department should provide a service. So it was quickly replaced with "IT" because "technology" is such a cool-sounding word. So far, anyway.

when we were out doing our own startup ... we had coined the term business science ... minor past references:
https://www.garlic.com/~lynn/95.html#8aa 2nd wave?
https://www.garlic.com/~lynn/aepay3.htm#riskm The Thread Between Risk Management and Information Security
https://www.garlic.com/~lynn/2003k.html#41 An Understanding Database Theory

vmshare

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vmshare
Newsgroups: alt.folklore.computers
Date: Sat, 16 Dec 2006 11:12:35 -0700
re:
https://www.garlic.com/~lynn/2006w.html#42 vmshare

from long ago and far away, more on multi-level source update

Date: 09/06/85 14:45:21
From: wheeler
To: melinda

re: $; update only required that the source file have sequence numbers in order to apply the ./ D-R-I parameters. Update didn't require that any inserted lines also have appropriate sequence numbers. By convention (prior to cascading updating), it was usual that the resulting source have all valid sequence numbers (in many cases inforced by a assembler ISEQ statement). Frequently it was the policy that an update deck be applied "permenantly" to an assembler deck ... to become a new "base" ... using a combination of the original source deck and the update deck sequence nos. In some sense this could be considered "cascading update" procedure ... however the interval between update application spanned several weeks/months rather than seconds or milliseconds.


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

as mentioned elsewhere, when i was undergraduate in the 60s, i had originally written an (CMS) UPDATE pre-processor (that implemented the "$" convention for generation of sequence numbers)

Year-end computer bug could ground Shuttle

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Year-end computer bug could ground Shuttle
Newsgroups: alt.folklore.computers
Date: Sat, 16 Dec 2006 11:52:36 -0700
greymaus writes:
Person I know did a bit of research on the 1918 flu.. There were stories in the papers (that were printed) of cartloads of bodies being brought to the graveyards, a large part of the population was sick at the same time, but the actual crisis only lasted a month or so in each area.

from post earlier this year mentioning the flu (and the war) ... has some references studying it
https://www.garlic.com/~lynn/2006q.html#61 Wars and Allies

that i found here
http://virus.stanford.edu/uda/

some (us) stats from above
http://virus.stanford.edu/uda/flustat.html

as soon as my father was of age, he joined up and was shipped to europe, but it was rather late in the war. i don't remember him mentioning having been hit with the flu while in europe ... or after he was shipped back home.

Does Public Key Authentication offer additional security over SSH/SFTP

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Does Public Key Authentication offer additional security over SSH/SFTP
Newsgroups: comp.security.ssh
Date: Sat, 16 Dec 2006 15:45:09 -0700
Darren Tucker <dtucker@gate.dtucker.net> writes:
Root can also trivally copy the private key and perform an offline dictionary attack to determine the passphrase. This probably won't take long for simple passphrases.

arcot
http://www.arcot.com/

was demo'ing private key file cracks at rsa '98 ... avg. time was something like 30 seconds. they showed lots of vulnerabilities that attackers (not just root) could obtain/harvest files off of PCs. they also demo'ed a countermeasure that it made it significantly more difficult for an attacker doing brute force attack on private key file.

at the time, some were expecting that chip-based containers (for private keys) were just momentarily around the corner ... and the private key file scenarios were supposedly just emulating real chip containers (pending the availability of the real thing).

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, 16 Dec 2006 16:00:35 -0700
Andrew Swallow <am.swallow@btopenworld.com> writes:
Father? Try grandfather. The 1918 flu pandemic killed more people than the First World War.

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

i mentioned in the post that flu pandemic killed more people than ww1
https://www.garlic.com/~lynn/2006q.html#61 Wars and Allies

and what is mentioned in the reference here
http://virus.stanford.edu/uda/

here is picture of my mother's father (and his brother) taken in montana or wyoming (he's the one on the left, 6-6 and over 300) ... century ago
https://www.garlic.com/~lynn/grandpa.jpg

grandpa, out west, century ago

IBM sues maker of Intel-based Mainframe clones

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM sues maker of Intel-based Mainframe clones
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sun, 17 Dec 2006 15:25:36 -0700
note, something of an aside ... in hsdt
https://www.garlic.com/~lynn/subnetwork.html#hsdt

we had a number of communication things going on simultaneously .... there was the internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet

similar technology was being used in bitnet & earn
https://www.garlic.com/~lynn/subnetwork.html#bitnet

we were also in networking technology involving tcp/ip, the internet and the nsfnet backbone; some of this had nothing to do with mainframes and some of it overlapped with mainframes and/or bitnet/earn activities.

tcp/ip overlapping with mainframes ... i had done the rfc 1044 implementation for the mainframe tcp/ip support
https://www.garlic.com/~lynn/subnetwork.html#1044

the base support got around 44kbytes/sec using a 3090 processor ... the 1044 support in some tuning tests at cray research was getting 1mbyte/sec thruput between a cray machine and a 4341-clone ... using only a modest amount of the 4341-clone.

there has been several recent posts mentiong various aspects of the nsfnet backbone activity ... which can be considered the "operational" precursor to the modern internet
https://www.garlic.com/~lynn/subnetwork.html#internet

some recent posts about various nsfnet backbone related activity
https://www.garlic.com/~lynn/2006s.html#50 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006s.html#51 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006t.html#6 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006t.html#36 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006u.html#55 What's a mainframe?
https://www.garlic.com/~lynn/2006u.html#56 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006v.html#30 vmshare
https://www.garlic.com/~lynn/2006w.html#21 SNA/VTAM for NSFNET
https://www.garlic.com/~lynn/2006w.html#26 Why so little parallelism?
https://www.garlic.com/~lynn/2006w.html#29 Descriptive term for reentrant program that nonetheless is
https://www.garlic.com/~lynn/2006w.html#38 Why so little parallelism?
https://www.garlic.com/~lynn/2006w.html#39 Why so little parallelism?
https://www.garlic.com/~lynn/2006w.html#43 IBM sues maker of Intel-based Mainframe clones

hsdt project also got involved with attempting to take some technology developed by one of the baby bells and turn it out as a product ... using real "peer-to-peer" networking ... but being able to simulate sna/vtam at the boundaries, a few recent posts referencing the activity:
https://www.garlic.com/~lynn/2006r.html#4 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006v.html#30 vmshare
https://www.garlic.com/~lynn/2006v.html#34 vmshare

... however, some additional drift on internal network, SMSG and service virtual machines

recent posts
https://www.garlic.com/~lynn/2006k.html#51 other cp/cms history
https://www.garlic.com/~lynn/2006p.html#10 What part of z/OS is the OS?
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
https://www.garlic.com/~lynn/2006t.html#47 To RISC or not to RISC
https://www.garlic.com/~lynn/2006v.html#22 vmshare
https://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?
https://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network
https://www.garlic.com/~lynn/2006w.html#16 intersection between autolog command and cmsback (more history)
https://www.garlic.com/~lynn/2006w.html#25 To RISC or not to RISC
https://www.garlic.com/~lynn/2006w.html#44 more secure communication over the network

following section from old RSCS command document describing an API for rscs/vnet:
July 1986

New and Changed IPO RSCS Commands
....

6.4 RSCS APLICATION INTERFACE (API)

A virtual machine user may use the CP SMSG (Special Message) command to send messages via RSCS to remote virtual machines or to request status information about a local or remote RSCS or about a remote VM/370 system. The text of an SMSG command can be an RSCS MSG command or an RSCS CMD command.

A special application interface is available with RSCS to allow programs to more easily deal with the replies from an RSCS command. There are several fundamental problems that programs have in dealing with RSCS mes- sages that people do not:

1. Messages that are split for human convenience cause problems for programs.

2. Programs have a hard time determining when the responses for a command are finished.

3. Programs cannot easily distinguish the responses for two (even dissimilar) commands.

RSCS now supports a mode which addresses these (and other) difficulties associated with application programs. Using the APplication Interface (API) RSCS will deliver responses for a command as an SMSG. The data returned when using the API is via SMSG.

This same interface is used to allow one to write an application to dynamically handle certain discrete situations in RSCS. For instance, whenev- er a link drops a particular message is generated on the RSCS console. If this same message would be delivered to another virtual machine in a "nice" format, then one could write an application to assist with network management. This is exactly the purpose of the NETWUSER statement in the DIRECT file. The format of this message is very similar to that used to generate replies for a command.

The format of this SMSG data is a series of words (tokens), each separated by a blank (which is very convenient for REXX EXECs):

1. "RSCS" - a constant.

2. The four character RSCS message number (e.g. "0144"). All commands are terminated with the message number "0001".

3. A four character sequence number ("0001", "0002" etc.). Asynchronously generated messages for NETWUSER will have a sequence number of "0000".

4. The eight character node name where this message originated. This will be your local node for local commands. Messages from remote nodes will not be prefixed with "From node:".

5. A six character "signature" or "tag" which originated with the command. If no signature was originally specified, this defaults to the time of the original command in the form hhmmss (hours-minutes-seconds). Asynchronously generated messages for NETWUSER will have a signature in this "hhmmss" format.

6. The text of the message as it might normally be delivered via MSGNOH (with no message number, i.e. no "DMTCMX123I"). Messages from remote nodes will not be prefixed with "From node:". See "APPENDIX G: IPORSCS Messages" on page 5G-1 for a list of the messages RSCS can generate.

One tells RSCS to use the API mode by introducing a prefix to any RSCS command. This prefix must begin with an "(" and terminate with a ")". No intervening blanks are allowed. This prefix is called a SIGNATURE. A signature is composed of two parts:

1. An optional two byte (prefix) modifier which is which is used to determine exactly how the data is finally returned. This prefix may be only be:

"B." This tells RSCS to deliver only the substitution parameters for the message via SMSG. These substitution parameters are always returned in the same order (regardless of the order they are used in the message text) and are always eight-byte EBCDIC fields. There is no intervening blank between these. This format allows one to obtain the significant portions of a message regardless of the National Language in which the final message would be delivered. The maximum length that may be returned is 240 bytes.

"T." This tells RSCS to actually deliver the final text via SMSG. The maximum length that may be returned is 240 bytes.

"M." This tells RSCS to actually deliver the final text via MSGNOH or MSG. The maximum length that may be returned is 132 bytes.

If this modifier is not specified the default is "M.". In any case the string that is returned is never split (even if it is delivered by MSGNOH). In no case is this signature modifier (i.e. "T.") returned as part of the response message.

2. A one- to six-byte character string. This value is returned with each response as described above. If the signature is "$", RSCS will generate a signature based on the time of day when the response message is generated. Normally the time of the command and time of the response are the same, except when the command is a very long executing one like MONITOR. In this case a command like "MONITOR (T.$) FRED" will generate API format messages with the time of each response as the signature. Using the format "(T.)" will generate responses with a signature which has the time the original MONITOR command was issued (and not the time the response is generated).

The API interface allows one to write programs or EXECs which can communicate with RSCS in a much more reasonable manner (for programs). Please note that this API interface is only recognized by IPO versions of RSCS at version 3.0 or above. PID RSCS or pre-3.0 IPO systems will return a message complaining that the signature is not a valid command.

As a side effect of this new API interface, commands sent to IPO 3.0+ systems from IPO 3.0+ systems now have the command response built at the origin node. This means that command responses will now use your LOCAL EMSG SETTING and not that of the target node. I.e. If your local system has an "EMSG TEXT" setting, messages from IPO 3.0+ systems will be delivered without the DMT... prefix, regardless of the EMSG setting at the target node.

+----------------------------------------------------------------------+
|                                                                      |
|  Issue command: CP SMSG RSCS (T.FRANKG) CPQ T                        |
|                                                                      |
|  Results in SMSGs back which look like:                              |
|                                                                      |
|      RSCS 0172 0001 FRANKG CPQ: TIME IS 12:34:44 etc.                |
|      RSCS 0172 0002 FRANKG CPQ: CONNECT= 02:33:22 etc.               |
|      RSCS 0001 0003 FRANKG End of command response                   |
|                                                                      |
| Figure 23.  Example of API Command and Responses                     |
|                                                                      |
+----------------------------------------------------------------------+

You may trap these SMSG responses with any tools you like. The following REXX EXEC will trap these SMSGs and make them available to the EXEC for parsing. This code is presented as an example of what might be done and is not meant as an endorsement of one tool over another. Please use whatever tool best meets your needs.

/*REXX fragment to trap SMSGs and write them to the terminal  */
Do Forever
    'WAKEUP 23:59:59 (SMSG)'   /* Wait for an SMSG     */
Parse Pull junk uid text   /* Get text from RSCS */
If uid='RSCS' | uid='PVM' Then Do /* Asynchronous msg */
Parse Var text kind msgnum seqnum node signat text
      Say kind 'msg received from node' node'. Msg number='msgnum'.'
Say 'Signature="'signat'". Text="'text'".'
    End
Else Do                    /* SMSG was not from RSCS or PVM */
Say 'SMSG received from 'uid'. Text="'text'".'
End
  End

... snip ...




previous, next, index - home