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

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 langauge (precursor
to sgml, html, xml, etc)
http://www.garlic.com/~lynn/submain.html#sgml

was invented by "g", "m", and "l" at the science center
http://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:
http://www.garlic.com/~lynn/2006v.html#46 Patent buster for a method that increases password security
http://www.garlic.com/~lynn/2006v.html#49 Patent buster for a method that increases password security
http://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 occured 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:
http://www.nsa.gov/selinux/list-archive/0409/8362.cfm

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
http://www.garlic.com/~lynn/2006.html#11

somewhat akin to yes card vulnerability
http://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
http://www.garlic.com/~lynn/2006h.html#14
http://www.garlic.com/~lynn/2006n.html#2
http://www.garlic.com/~lynn/2006n.html#52
http://www.garlic.com/~lynn/2006t.html#38

IBM sues maker of Intel-based Mainframe clones

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
http://www.garlic.com/~lynn/2006v.html#47> Why so little parallelism?

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:
http://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.
http://www.garlic.com/~lynn/submain.html#unbundle

for recent post discussing this from slightly different perspective
http://www.garlic.com/~lynn/2006v.html#47 Why so little parallelism?
http://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
http://www.garlic.com/~lynn/submain.html#futuresys

specific reference:
http://www.ecole.org/Crisis_and_change_1995_1.htm

from above:

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

... snip ...

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

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:
http://www.garlic.com/~lynn/2006w.html#1 IBM sues maker of Intel-based Mainframe clones
http://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
http://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 succesfully.

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
http://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
http://www.garlic.com/~lynn/2006v.html#36 Why these original FORTRAN quirks?
http://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.
http://www.garlic.com/~lynn/2002j.html#0 HONE was .. Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2004b.html#31 determining memory size
http://www.garlic.com/~lynn/2004p.html#50 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2005g.html#17 DOS/360: Forty years
http://www.garlic.com/~lynn/2005j.html#50 virtual 360/67 support in cp67
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
http://www.garlic.com/~lynn/2006e.html#7 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006f.html#5 3380-3390 Conversion - DISAPPOINTMENT
http://www.garlic.com/~lynn/2006l.html#21 Virtual Virtualizers
http://www.garlic.com/~lynn/2006o.html#19 Source maintenance was Re: SEQUENCE NUMBERS
http://www.garlic.com/~lynn/2006q.html#1 Materiel and graft
http://www.garlic.com/~lynn/2006q.html#45 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006q.html#49 Was FORTRAN buggy?

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: 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:
http://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
http://www.garlic.com/~lynn/aadsm25.htm#46
Flaw in RFID-enabled passports (part 2?)
http://www.garlic.com/~lynn/aadsm26.htm#0

Note one of the issues related to yes card bank chipcard exploits
http://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
http://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 occured. 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.
http://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.
http://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:
http://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
http://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).
http://www.garlic.com/~lynn/2006v.html#26 Fighting Fraudulent Transactions

since all valid, authorized x9.59 transactions require the appropriate
authentication.
http://www.garlic.com/~lynn/x959.html#x959
http://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:
http://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?

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
http://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
http://www.garlic.com/~lynn/submain.html#mmap


From: wheeler
Date: Jan. 2, 1975
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 accesable 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
http://www.garlic.com/~lynn/submain.html#adcon

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

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

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

Why these original FORTRAN quirks?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why these original FORTRAN quirks?
Newsgroups: alt.folklore.computers,comp.lang.fortran
Date: Thu, 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.
http://www.garlic.com/~lynn/subtopic.html#545tech

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

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

The distribution overview also makes mention of including SPM from
POK which is referenced here
http://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.


From: wheeler
Date: 4/30/75
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 (shipped in my resource manager)
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)
http://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
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://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".

dcss and page mapped filesystem

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
http://www.garlic.com/~lynn/submain.html#mmap

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

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

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
http://www.garlic.com/~lynn/2006v.html#36 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006w.html#7 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?
http://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
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist
http://www.garlic.com/~lynn/94.html#27 370 ECPS VM microcode assist
http://www.garlic.com/~lynn/94.html#28 370 ECPS VM microcode assist

and at the same time doing system and microcode design for VAMPS,
a five-way multiprocessor effort ... collected past posts mentiong VAMPS
http://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.


Memo to: Endicott
cc: wheeler
Date: August 27, 1975
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

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:
http://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
http://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
http://www.garlic.com/~lynn/2006t.html#16 Is the teaching of non-reentrant HLASM coding practices ever defensible?
http://www.garlic.com/~lynn/2006t.html#39 Why these original FORTRAN quirks?

recent posts on early virtual memory management stuff (a small subset which was going to be released as DCSS in vm370 release 3)
http://www.garlic.com/~lynn/2006v.html#36 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006w.html#7 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?
http://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
http://www.garlic.com/~lynn/2006v.html#48 Why so little parallelism?

more secure communication over the network

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
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3


To: wheeler
Date: 05/15/81 13:41:12
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
http://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:
http://www.garlic.com/~lynn/2006b.html#37 X.509 and ssh
http://www.garlic.com/~lynn/2006c.html#10 X.509 and ssh
http://www.garlic.com/~lynn/2006c.html#34 X.509 and ssh
http://www.garlic.com/~lynn/2006c.html#35 X.509 and ssh
http://www.garlic.com/~lynn/2006c.html#38 X.509 and ssh
http://www.garlic.com/~lynn/2006d.html#29 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006f.html#16 trusted repositories and trusted transactions
http://www.garlic.com/~lynn/2006f.html#32 X.509 and ssh
http://www.garlic.com/~lynn/2006f.html#33 X.509 and ssh
http://www.garlic.com/~lynn/2006f.html#34 X.509 and ssh
http://www.garlic.com/~lynn/2006h.html#27 confidence in CA
http://www.garlic.com/~lynn/2006p.html#7 SSL, Apache 2 and RSA key sizes
http://www.garlic.com/~lynn/2006t.html#8 Root CA CRLs
http://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
http://www.garlic.com/~lynn/x959.html#aads

... CJNTEL is different than the internal "online telephone book"
recently mentioned here
http://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.
http://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
http://www.garlic.com/~lynn/2006k.html#51 other cp/cms history
http://www.garlic.com/~lynn/2006t.html#47 To RISC or not to RISC
http://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
http://www.garlic.com/~lynn/subnetwork.html#hsdt

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

IBM sues maker of Intel-based Mainframe clones

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:
http://www.garlic.com/~lynn/2006w.html#1 IBM sues maker of Intel-based Mainframe clones
and then a couple more:
http://www.garlic.com/~lynn/2006w.html#2 IBM sues maker of Intel-based Mainframe clones
http://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
http://www.garlic.com/~lynn/submain.html#systemr

most recent comment in this post
http://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).
http://www.garlic.com/~lynn/95.html#13
http://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)
http://www.garlic.com/~lynn/2005b.html#1 Foreign key in Oracle Sql
http://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 scaleup):
http://www.garlic.com/~lynn/95.html#13
http://www.garlic.com/~lynn/96.html#15
and
http://www.garlic.com/~lynn/2001n.html#83


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

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

IBM sues maker of Intel-based Mainframe clones

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
http://www.garlic.com/~lynn/2006w.html#1

a few posts in (comp.arch) JIT thread(s)
http://www.garlic.com/~lynn/2006r.html#24 A Day For Surprises (Astounding Itanium Tricks)
http://www.garlic.com/~lynn/2006u.html#29 To RISC or not to RISC
http://www.garlic.com/~lynn/2006u.html#31 To RISC or not to RISC
http://www.garlic.com/~lynn/2006u.html#32 To RISC or not to RISC
http://www.garlic.com/~lynn/2006u.html#33 Assembler question

and from the previous post
http://www.garlic.com/~lynn/2006w.html#13
and
http://www.garlic.com/~lynn/95.html#13
http://www.garlic.com/~lynn/96.html#15
http://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.


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

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):
http://www.garlic.com/~lynn/2004m.html#17 mainframe and microprocessor

more secure communication over the network

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
http://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
http://www.garlic.com/~lynn/subpubkey.html#sslcert

or this post
http://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)
http://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)

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
http://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:


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

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:
http://www.garlic.com/~lynn/2006t.html#20 Why these original FORTRAN quirks?; Now : Programming practices
http://www.garlic.com/~lynn/2006t.html#33 threads versus task
http://www.garlic.com/~lynn/2006u.html#19 Why so little parallelism?
http://www.garlic.com/~lynn/2006u.html#26 Assembler question
http://www.garlic.com/~lynn/2006u.html#30 Why so little parallelism?
http://www.garlic.com/~lynn/2006v.html#24 Z/Os Storage Mgmt products

and collected past posts on backup/archive systems
http://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).
http://www.princeton.edu/~melinda/

now as to automated operator &/or automated operations ...
the autolog command ... mentioned here
http://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:
http://www.garlic.com/~lynn/2006p.html#10 What part of z/OS is the OS?
http://www.garlic.com/~lynn/2006t.html#45 To RISC or not to RISC
http://www.garlic.com/~lynn/2006t.html#46 To RISC or not to RISC
http://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
http://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
http://www.garlic.com/~lynn/2006k.html#51 other cp/cms history
http://www.garlic.com/~lynn/2006t.html#47 To RISC or not to RISC
http://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?

another service virtual machine would be CJNTEL using special
message ... mentioned here
http://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
http://www.garlic.com/~lynn/2001k.html#35 Newbie TOPS-10 7.03 question
http://www.garlic.com/~lynn/2003i.html#73 Computer resources, past, present, and future
http://www.garlic.com/~lynn/2003j.html#24 Red Phosphor Terminal?
http://www.garlic.com/~lynn/2004e.html#14 were dumb terminals actually so dumb???
http://www.garlic.com/~lynn/2005r.html#12 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2006.html#3 PVM protocol documentation found
http://www.garlic.com/~lynn/2006c.html#14 Program execution speed
http://www.garlic.com/~lynn/2006f.html#37 Over my head in a JES exit
http://www.garlic.com/~lynn/2006m.html#35 Draft Command Script Processing Manual
http://www.garlic.com/~lynn/2006n.html#23 sorting was: The System/360 Model 20 Wasn't As Bad As All That
http://www.garlic.com/~lynn/2006p.html#31 "25th Anniversary of the Personal Computer"

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

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
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
http://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).
http://www.garlic.com/~lynn/2003j.html#42 Flash 10208
http://www.garlic.com/~lynn/2006u.html#37 To RISC or not to RISC
http://www.garlic.com/~lynn/2006v.html#6 Reasons for the big paradigm switch
http://www.garlic.com/~lynn/2006v.html#43 The Future of CPUs: What's After Multi-Core?

more secure communication over the network

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
http://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network

ref:
http://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
http://www.garlic.com/~lynn/2006.html#30 IBM microwave application--early data communications
http://www.garlic.com/~lynn/2006n.html#23 sorting was: The System/360 Model 20 Wasn't As Bad As All That
http://www.garlic.com/~lynn/2006n.html#36 The very first text editor

and related thread with other archeological references:
http://www.garlic.com/~lynn/aadsm26.htm#9 Who has a Core Competency in Security?
http://www.garlic.com/~lynn/aadsm26.htm#10 Who has a Core Competency in Security?

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
http://www.garlic.com/~lynn/submain.html#adcon

re:
http://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
http://www.garlic.com/~lynn/2006v.html#36 Why these original Fortran quirks?
http://www.garlic.com/~lynn/2006w.html#7 Why these original Fortran quirks?
http://www.garlic.com/~lynn/2006w.html#8 Why these original Fortran quirks?

cluster-in-a-rack

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
http://www.garlic.com/~lynn/2006w.html#13 IBM sues maker of Intel-based Mainframe clones
http://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
http://www.garlic.com/~lynn/95.html#13
http://www.garlic.com/~lynn/96.html#15
and then
http://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.


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

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


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

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

and misc. posts mentioning unitree
http://www.garlic.com/~lynn/2001f.html#66 commodity storage servers
http://www.garlic.com/~lynn/2002e.html#46 What goes into a 3090?
http://www.garlic.com/~lynn/2002g.html#61 GE 625/635 Reference + Smart Hardware
http://www.garlic.com/~lynn/2002k.html#31 general networking is: DEC eNet: was Vnet : Unbelievable
http://www.garlic.com/~lynn/2003b.html#29 360/370 disk drives
http://www.garlic.com/~lynn/2003b.html#31 360/370 disk drives
http://www.garlic.com/~lynn/2003h.html#6 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003i.html#53 A Dark Day
http://www.garlic.com/~lynn/2005e.html#12 Device and channel
http://www.garlic.com/~lynn/2005e.html#15 Device and channel
http://www.garlic.com/~lynn/2005e.html#16 Device and channel
http://www.garlic.com/~lynn/2006n.html#29 CRAM, DataCell, and 3850
http://www.garlic.com/~lynn/2006u.html#19 Why so little parallelism?
http://www.garlic.com/~lynn/2006u.html#20 Why so little parallelism?
http://www.garlic.com/~lynn/2006u.html#27 Why so little parallelism?
http://www.garlic.com/~lynn/2006v.html#10 What's a mainframe?

SNA/VTAM for NSFNET

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
http://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
http://www.garlic.com/~lynn/2006u.html#56 Ranking of non-IBM mainframe builders?
and specific meeting mentioned here
http://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)
http://www.garlic.com/~lynn/2006s.html#50 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006t.html#6 Ranking of non-IBM mainframe builders?

anyway a couple weeks short of twenty years ago ...


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

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.

 <... lots more of the same ...>

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

as an aside ... sna/vtam group still considered 56kbit "high speed"
and T1 was "very high speed" ... aka various references from this year:
http://www.garlic.com/~lynn/2006e.html#36 The Pankian Metaphor
http://www.garlic.com/~lynn/2006s.html#42 Ranking of non-IBM mainframe builders?
http://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)
http://www.garlic.com/~lynn/2001.html#4 Sv: First video terminal?
http://www.garlic.com/~lynn/2002j.html#67 Total Computing Power
http://www.garlic.com/~lynn/2003m.html#28 SR 15,15
http://www.garlic.com/~lynn/2003m.html#59 SR 15,15
http://www.garlic.com/~lynn/2004g.html#37 network history
http://www.garlic.com/~lynn/2004l.html#7 Xah Lee's Unixism
http://www.garlic.com/~lynn/2005j.html#59 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://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
http://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.

some of the same people involved in canceling our NSF meetings were
also later involved in transfering the (MEDUSA) cluster scaleup
work and telling us we were limited to working on systems with no more
than four processors:
http://www.garlic.com/~lynn/95.html#13
http://www.garlic.com/~lynn/96.html#15
and somewhat related leading up to the above mentioned meeting
http://www.garlic.com/~lynn/2006w.html#13
http://www.garlic.com/~lynn/2006w.html#14
http://www.garlic.com/~lynn/2006w.html#20
and
http://www.garlic.com/~lynn/2001n.html#83

for even more topic drift ... two people in the above mentioned
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
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

later it started to be called electronic commerce.

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

Are hypervisors the new foundation for system software?

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
http://www.garlic.com/~lynn/2006s.html#65
http://www.garlic.com/~lynn/2006t.html#27
http://www.garlic.com/~lynn/2006v.html#21
http://www.garlic.com/~lynn/2006v.html#52
http://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
http://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 ... rewritting large amounts of it.

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

old post including piece of presentation at the aug68 SHARE meeting in
boston on some of the the (cp67 and mft14) changes that i made
http://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.

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

Melinda's paper has a lot more detailed history
http://www.princeton.edu/~melinda/

Multiple mappings

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:
http://www.garlic.com/~lynn/2006w.html#17 Cache, TLB and OS
http://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
http://www.garlic.com/~lynn/2006v.html#36 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006w.html#7 Why these original FORTRAN quirks?
http://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
http://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
http://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

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

To RISC or not to RISC

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
http://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network

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

part of virtual machine history scenario
http://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.
http://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
http://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).


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

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
http://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
http://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


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

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:
http://www.garlic.com/~lynn/2006v.html#22 vmshare
http://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?

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
http://www.garlic.com/~lynn/2006w.html#21 SNA/VTAM for NSFNET
and
http://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
http://www.garlic.com/~lynn/99.html#136a checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/2000c.html#6 TF-1
http://www.garlic.com/~lynn/2000d.html#27 Superduper computers--why RISC not 390?
http://www.garlic.com/~lynn/2005q.html#46 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005q.html#47 Intel strikes back with a parallel x86 design

Generalised approach to storing address details

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
http://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

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:
http://www.garlic.com/~lynn/2006w.html#24 IBM sues maker of Intel-based Mainframe clones

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


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

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


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

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


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

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

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
http://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>
Su