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 -0700Anne & Lynn Wheeler <lynn@garlic.com> writes:
and for even more topic drift about the latest, new, 40yr old thing
i built a lot of systems in the 60s (as an undergraduate) and 70s
... and it never occurred to build something that wasn't secure. it
wasn't until much later that i found a lot of it to be prevailing use
in certain quarters. minor ref:
https://web.archive.org/web/20090117083033/http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml
in the mid-70s the company got a new CSO ... these were the days when CSOs for major corporations frequently had backgrounds like retired secret service (or something similar). they tended to have a lot of physical security experience. for what ever reason, i got asked to run around with him for several months to help him learn about computer security.
minor security reference
https://www.garlic.com/~lynn/2006.html#11
somewhat akin to yes card vulnerability
https://www.garlic.com/~lynn/subintegrity.html#yescard
which appeared shortly after some chipcard deployments in the 90s ... but the above referenced scenario was approx. 25 years earlier i.e. compromise the system so that anything/everything is taken as valid pin/password
other somewhat related posts
https://www.garlic.com/~lynn/2006h.html#14
https://www.garlic.com/~lynn/2006n.html#2
https://www.garlic.com/~lynn/2006n.html#52
https://www.garlic.com/~lynn/2006t.html#38
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 -0700IBM sues maker of Intel-based Mainframe clones
from above:
In its second major patent enforcement action in as many months, IBM
is quietly suing an Intel-backed maker of computers that uses a
version of IBM's high-end mainframe operating system reconfigured to
run atop Intel's industry standard processors, InformationWeek has
learned.
... snip ...
slightly related post mentioning unbundling
https://www.garlic.com/~lynn/2006v.html#47 Why so little parallelism?
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 -0700Steve_Thompson_TW@ibm-main.lst (Thompson, Steve , SCI TW) writes:
the legal litigation led to unbundling announcement on 23jun69 ... and
starting to charge for application software ... however, the argument was
made that because kernel software was required to operate the hardware,
it would still be offered for free.
https://www.garlic.com/~lynn/submain.html#unbundle
for recent post discussing this from slightly different perspective
https://www.garlic.com/~lynn/2006v.html#47 Why so little parallelism?
https://www.garlic.com/~lynn/2006v.html#48 Why so little parallelism?
the clone/pcm controllers were somewhat the motivation behind the
failed future system project in the early 70s
https://www.garlic.com/~lynn/submain.html#futuresys
specific reference:
https://www.ecole.org/en/session/49-the-rise-and-fall-of-ibm
https://www.ecole.org/en/session/49-the-rise-and-fall-of-ibm
from above:
IBM tried to react by launching a major project called the 'Future
System' (FS) in the early 1970's. The idea was to get so far ahead
that the competition would never be able to keep up, and to have such
a high level of integration that it would be impossible for
competitors to follow a compatible niche strategy. However, the
project failed because the objectives were too ambitious for the
available technology. Many of the ideas that were developed were
nevertheless adapted for later generations. Once IBM had acknowledged
this failure, it launched its 'box strategy', which called for
competitiveness with all the different types of compatible
sub-systems. But this proved to be difficult because of IBM's cost
structure and its R&D spending, and the strategy only resulted in a
partial narrowing of the price gap between IBM and its rivals.
... snip ...
some past posts about having helped build clone controller as an
undergraduate in the 60s ... and some article blaming four of us for
(some part of) the clone controller market
https://www.garlic.com/~lynn/submain.html#360pcm
however, the appearance of the clone processors in the 70s ... was
somewhat motivation behind starting to charge for kernel software
... and my resource manager got selected to be the guinea pig for
kernel software charging ... and i got to spend quite a bit of time
with business and pricing people working out the details.
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock
note, i've in the past conjectured that the future system project may have helped give rise to clone processors. Amdahl gave a seminar at MIT in the early 70s ... and got a lot of questions about his leaving and getting the backing to start his mainframe processor business. He made some statement about even if IBM were to completely walk away from 360/370 (which could be considered a veiled reference to future system project), there was already something like $100b ($200b?) in 360 application software which would keep clone processor business going thru the end of the century.
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 first was the cp67 h/i joint project between cambridge science center
https://www.garlic.com/~lynn/subtopic.html#545tech
and endicott. the "cp67h" modifications was to add option that allowed cp67 to emulate 370 virtual machines (with 370 hardware relocate) as oppsed to 360/67 virtual memory virtual machines (tables, control registers and some of the instructions were different).
the "cp67i" modifications was to create cp67 kernel that would run on 370 hardware relocate instead of 360/67 hardware relocate.
the "cp67i" was up and running (in virtual machine) a year before endicott had the first engineering model 370 with hardware relocate operation ... in fact, running cp67i on the hardware was one of the tests for the hardware.
the story is that the initial boot of cp67i on the engineering machine failed. after some diagnostic ... it turned out that the engineers had reversed the (hardware) implementation of two of the "B2" opcodes. cp67i was quickly patched to reflect the (incorrect) hardware ... and then proceeded to boot and run successfully.
this was one of the early HONE capabilities ... allowing for testing
various 370 code under HONE (running cp67 on 360/67) ... HONE was the
vm370 (originally cp67) based world-wide infrastructure supporting
marketing, sales, and field people
https://www.garlic.com/~lynn/subtopic.html#hone
two people from san jose came out and did the enhancements to cp67i to support rps, block mux, 3330 and 2305 devices support ... "cp67i" with the 3330/2305 device support was referred to as "cp67sj".
the other issue that cambridge had was that 370 virtual memory was a
deep, dark corporate secret ... and the 370 support was running in
cambridge long before any announcement. cambridge had number of
non-employees using the system, including various students from
colleges and univ. in the boston area. as a result, the "cp67h" system
was run in a 360/67 virtual machine under the standard "floor" cp67
system (keeping it away from the prying eyes of the uninitiated).
The "floor" cp67 system was heavily modified ... somewhat referred to
in these posts
https://www.garlic.com/~lynn/2006v.html#36 Why these original FORTRAN quirks?
https://www.garlic.com/~lynn/2006w.html#0 Patent buster for a method that increases password security
but the modifications supporting virtual 370 were kept separate.
misc. past posts referring to cp67h, cp67i, cp67sj, etc.
https://www.garlic.com/~lynn/2002j.html#0 HONE was .. Hercules and System/390 - do we need it?
https://www.garlic.com/~lynn/2004b.html#31 determining memory size
https://www.garlic.com/~lynn/2004p.html#50 IBM 3614 and 3624 ATM's
https://www.garlic.com/~lynn/2005g.html#17 DOS/360: Forty years
https://www.garlic.com/~lynn/2005j.html#50 virtual 360/67 support in cp67
https://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
https://www.garlic.com/~lynn/2006e.html#7 About TLB in lower-level caches
https://www.garlic.com/~lynn/2006f.html#5 3380-3390 Conversion - DISAPPOINTMENT
https://www.garlic.com/~lynn/2006l.html#21 Virtual Virtualizers
https://www.garlic.com/~lynn/2006o.html#19 Source maintenance was Re: SEQUENCE NUMBERS
https://www.garlic.com/~lynn/2006q.html#1 Materiel and graft
https://www.garlic.com/~lynn/2006q.html#45 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006q.html#49 Was FORTRAN buggy?
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 -0700Anne & Lynn Wheeler <lynn@garlic.com> writes:
even more drift related to static authentication data being vulnerable to various kinds of skimming/harvesting attacks
Fast Payments creates strong case for two-factor authentication, says
Thales
http://www.finextra.com/fullstory.asp?id=16240
Banks lobby govt on smartcard
http://www.hackinthebox.org/modules.php?op=modload&name=News&file=article&sid=21919
British Banks keep a secret..
http://www.zone-h.org/content/view/14404/31/
Banks reluctant to reveal full extent of online fraud
http://www.e-consultancy.com/news-blog/362293/banks-reluctant-to-reveal-full-extent-of-online-fraud.html
Newspaper Says UK Banks Fail to Report Online Fraud
http://www.epaynews.com/index.cgi?survey=&ref=browse&f=view&id=1165410908213202145191&block=
Smart Card Alliance slams RFID use in US passport card program
http://www.cbronline.com/article_news.asp?guid=88914D85-0D0F-47D2-AEC2-45B457496214
Industry group urges caution on U.S. plan for RFID-enabled ID cards
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9005675&intsrc=hm_list
RFID Sabotages Privacy, Says Government Watchdog
http://www.rfidnews.org/weblog/2006/12/05/rfid-sabotages-privacy-says-government-watchdog/
US government warned off RFID passports
http://www.techworld.com/security/news/index.cfm?newsID=7513&pagtype=all
Smart Card Alliance Cautions Feds on RFID Cards
http://www2.csoonline.com/blog_view.html?CID=27237
Flaw exploited in RFID-enabled passports
https://www.garlic.com/~lynn/aadsm25.htm#46
Flaw in RFID-enabled passports (part 2?)
https://www.garlic.com/~lynn/aadsm26.htm#0
Note one of the issues related to yes card bank chipcard exploits
https://www.garlic.com/~lynn/subintegrity.html#yescard
was that it used static data for authentication. this made it vulnerable to harvest/skimming and replay attacks (not too different from magstripe harvest/skimming with replay attacks using counterfeit cards).
however, the big additional vulnerability introduced with the bank chipcard exploits, was that the terminal, after initially verifying the chips (static) authentication data ... would then "obey" the cards' instructions ... which gave rise to the yes card label.
When the terminal asked if the entered PIN was correct, a counterfeit
yes card would always answer YES, minor digression
https://www.garlic.com/~lynn/2006w.html#0 Patent buster for a method that increases password security
And when the terminal asked if the transaction should be offline, the counterfeit yes card would always answer YES, and when the terminal then asked if the transaction was within the account credit limit, the counterfeit yes card would again answer YES.
In some of the bank chipcard deployments ... after the appearance of some of the counterfeit yes cards (in earlier deployments in the 90s), some made the decision to only issue valid cards that only did online transactions (and never opted for offline operation, perceiving it to be a countermeasure to yes card attack).
However, these were highly card-centric operations ... and didn't understand that the counterfeit yes card attacks weren't attacks on the card ... but attacks on the terminal. It was still possible to skim the static authentication data from such cards, load it into a counterfeit yes card, and program the counterfeit yes card to tell the terminal that the correct pin was entered and to do offline transaction.
The problem is that the standard countermeasure for skimmed counterfeit (and/or lost/stolen) cards is to disable the account. However, when a terminal does an offline transaction, there is no communication to find out that the acocunt has been disabled until way after the fraud has occurred. The appropriate countermeasure to the yes card exploits wasn't to program valid cards to only do online transactions, the appropriate countermeasure to the yes card exploits was to program terminals to never do offline transactions (i.e. it was an attack on terminals not attacks on cards).
Sen. Schumer Decries Dangers of 'No-Swipe' Credit Cards
http://www.foxnews.com/story/0,2933,234586,00.html
Sen. Schumer Calls For Better Contactless Payment Security
http://www.cardtechnology.com/article.html?id=20061206O8ZLO98Q
Would You Trust RFID-Enabled ATM Cards?
http://ask.slashdot.org/askslashdot/06/12/06/0532242.shtml
Would You Trust RFID-Enabled ATM Cards?
http://ask.slashdot.org/article.pl?sid=06/12/06/0532242
Possible Serious Security Flaw In ATMs
http://it.slashdot.org/it/06/11/30/2139235.shtml?tid=187
So if bank cards continue to use static authentication data, they continue to be vulnerable to harvest/skimming exploits ... and contactless/wireless communication may increase the opportunities for attackers to record static authentication data.
Note however, there may still be other vulnerabilities even in any
upgrade from static to dynamic authentication data. This is the
scenario whether the card is being authenticated or is the transaction
being authenticated.
https://www.garlic.com/~lynn/2006v.html#26 Fighting Fraudulent Transactions
the scenario with card authentication ... is that even with dynamic authentication data, it may still be vulnerability to a yes card MITM-attack where a yes card is paired with a lost/stolen card (or any valid card obtained by any means).
The counterfeit yes card transparently passes the card
authentication messages ... but then takes over the rest of the
communication to perform the YES answers to the three terminal
questions 1) correct PIN, 2) offline transaction, 3) within credit
limit.
https://www.garlic.com/~lynn/subintegrity.html#mitm
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 -0700Anne & Lynn Wheeler <lynn@garlic.com> writes:
note that the purpose of disabling the account (as a fraudulent
transaction compromise), is paradigm where the account number has
frequently been the primary method of authentication i.e. knowing the
account number as something you know authentication ... from
3-factor authentication model
https://www.garlic.com/~lynn/subintegrity.html#3factor
• something you have
• something you know
• something you are
aka you frequently see fraud compromise being dealt with by issuing a new card which also carries a new account number (the old account number having been flagged).
in the x9.59 standard, the paradigm is changed to transaction
authentication; and therefor it is no longer necessary to disable the
account number (as a fraud compromise countermeasure) ... it is only
necessary to disable the specific compromised authentication (i.e. say
specific lost/stolen card with its corresponding something you have
authentication).
https://www.garlic.com/~lynn/2006v.html#26 Fighting Fraudulent Transactions
since all valid, authorized x9.59 transactions require the appropriate
authentication.
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959
incoming transactions are recognized as appropriately authenticated, by the correct transaction authentication data, not by the account number.
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 -0700Anne & Lynn Wheeler <lynn@garlic.com> writes:
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 ...
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 -0700Status report on project activities mentioned in email from 12dec73 in this post
involving porting various functions that had been implemented in cp67 with additional enhancements.
shortly after this email was written, I enhanced the PAM filesystem support so for "small" files (with only a single data block) for the FST to point directly at the data block rather than the FST point at a (200 byte) hyperblock ... which in turn pointed at the data block. This not only cut the physical disk space requirement in half (for small files), but also allowed them to be accessed in a single disk operation, rather than having to first access the hyperblock.
The changes to move the EXEC command processer and the CMS editor (and other functions) into a shared segment was later picked up for vm370 release 3 and called DCSS. However, DCSS only incorporated a very small subset of the CSC/VM virtual memory management changes, i.e. for instance shared segments could only be loaded at fixed location (could not float or be relocated) and w/o page mapped file system support, the ability to directly map executable images ("MODULE") in the CMS filesystem to shared segments was lost.
past discussions of cms page mapped file system support
https://www.garlic.com/~lynn/submain.html#mmap
Date: Jan. 2, 1975
From: wheeler
Subject: CSC/VM SYSTEM STATUS
This is to bring you up to date on the current status of the CSC/VM
system. The updates to create the CSC/VM system have been converted to
the latest system available from Burlingtion, Release 2, PLC9/ICR,
with R22 monitor/THI support.
Completed and in production use are the scheduling /dispatching
/paging changes described in C.S.C. report; Also running in production
use is multiple shared system/segments. We currently only have a test
version of VM/APL which makes use of the extended sharing support. By
the end of January the test VM/APL should become the standard
production version. A minor CMS change has been made to support an
alternate module format. This was necessary to support shared
modules, like VM/APL.
Also in the production system is the CP support for a Paging Access
Method (PAM). Unfortunately PAM has one drawback; some of the bits in
the CP SWAPTABLE have been redefined and are in conflict with the VMA
microcode support. I consider the VMA microcode change to support PAM
to be minor. In addtion such a modified VMA would be completly
transparent to distributed versions of VM/370.
Undergoing final production testing are page and swap table migration,
both of which have been described in C.S.C. report. Swap table
migration involves the writing of some of the page management tables
onto disk and freeing up the main storage that they occupied. Page
migration has been generalized over the drum to disk page migration
described in the report to handle all preferred paging areas. Page
migration will move low refererenced pages from the preferred paging
areas to non-preferred areas. Additional changes are being made to
page allocation on preferred paging disks to distribute pages evenly
across all disks of the same type.
A version of CMS/PAM is undergoing testing, but it has a drawback of
requiring a minimum of two 4k page records for each file. The first 4k
record contains a 200 byte file control information record and the
rest is unused. This implementation puts a high price on users with
many small files. (A 5 cylinder 3330 PAM area will contain a maximum
of 140 files compared to the current maximum of about 700 files).
Advantages include a five fold increase in maximum file size and
mini-disk size (a full 3330-11 disk accessible as one mini-disk). Also
a mini-disk is supported on any device that CP supports for paging,
including the 2305 drum. The current implementation involves few CMS
changes and continues to support the current mini-disk formats. For
large system users it becomes possible (and feaseable with page
migration) to use part of a 2305 drum for a CMS system disk. The most
higly used parts of the CMS system disk will fit in 1000 page records
(about the equiv. of 20 3330 cylinders) which is about 40 per-cent of
the drum.
The increase in the CMS nucleus size will enable highly used modules,
like the EXEC processor and the EDITOR, to be placed in a shared
nucleus segment. This implementation will be transparent to current
user programs. During CMS ipl the additional nucleus segments will be
relocated (via a VMM diagnose function) to the end of the user's
virtual machine memory.
... snip ... top of post, old email index
The "relocation" of shared segments (having the same r/o, protected
shared segments appear at different virtual addresses in different
virtual address spaces) has been discussed in some past posts ...
collection of those posts are pointed to here
https://www.garlic.com/~lynn/submain.html#adcon
The items mentioned as "swaptable migration" and "page migration" was
released as part of my "resource manager".
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock
Other posts regarding the cambridge science center
https://www.garlic.com/~lynn/subtopic.html#545tech
https://www.garlic.com/~lynn/subtopic.html#cscvm
And various posts mentioning APL (&/or the HONE system)
https://www.garlic.com/~lynn/subtopic.html#hone
CSC/VM posts
https://www.garlic.com/~lynn/submisc.html#cscvm
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 -0700Attached 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.
recent refs
https://www.garlic.com/~lynn/2006v.html#36 Why these original FORTRAN quirks?
https://www.garlic.com/~lynn/2006w.html#7 Why these original FORTRAN quirks?
also, another distribution memo from a couple years later:
https://www.garlic.com/~lynn/2006u.html#26 Assembler question
The distribution overview also makes mention of including SPM from
POK which is referenced here
https://www.garlic.com/~lynn/2006k.html#51 other cp/cms history
In the above reference, there is a
copy of old email
making mention
that an "official" copy of SPM had been distributed to me on
8/12/75. However, as can be seen in the following 4/30/75 overview, I
had included an "unofficial" version of SPM in my distribution much
earlier in the year.
Date: 4/30/75
From: wheeler
Subject: CAMBRIDGE VM/370 SYSTEM (based on vm rel2, plc15)
Contained on the Cambridge VM/370 distrubution tape is a set of
updates which provide performance and functional enhancements to
CP-CMS. File 1 contains CP changes. They compromize a set of updates
to existing CP source and macros. Also included are new source files,
new cntrl, and a new load exec.
File 2 contains changes and additions to CMS and CMS/APL. File 3
contains CMS changes to support disks in paging access method (PAM)
format.
Detailed documentation for any of these changes will probably not be
forthcoming for some time. Reference will have to be made to the
individual changes for a description of how they work. For instance,
the CP support for page migration is almost totally contained in the
new module DMKPGM. The CP support for PAM is contained in DMKPAM. The
installation of the changes from file 1 should prove to be relatively
easy. They are essientially a 'black box' addition to the existing
system. If none of the new functions are to be utilized, then all that
is required is a reassembly of the affected modules. No understanding
of their operation is necessarily reqired.
IMPORTANT: The VIRT=REAL option has never been tested and probably
contains many bugs. Also SET FAVORED with a per-centage has not been
implemented.
In file 1, there are UPDTC001 and UPDTSPM update files and AUXCMB
files for DMK modules and new assemble files. There are also changes
to maclib files. The CMB CNTRL and CMBLOAD EXEC are the control file
and load list. Also included is a CMBMAC MACLIB which contains the
updated macros. These changes comprise support for the following
enhancements; 1) fair share scheduler, 2) shared module support, 3)
paging access method (PAM), 4) page migration, 5) the autolog command
and 6) the special message function from POK.
File 2 also contains optional CP changes for new page device format.
The updates are UPDTCV3 and are applied after CMB. DMKFMT UPDTCV3
changes the spacing between records on the paging and spooling devices
(3330 to 110 bytes and 2305-2 to 500 bytes). DMKPAG UPDTCV3 contains
changes to specify the corresponding sector addresses. These are
included for compatability with the previous CSC/VM release. The
performance problems which lead to the increased spacing have been
rectified with PLC-15.
... snip ... top of post, old email index
The six major items listed in the above
1) fair share scheduler (later shipped in my resource manager product)
2) shared module support (extremely small subset shipped in vm370
release 3 as DCSS)
3) paging access method (not shipped in standard product)
4) page migration (shipped in my resource manager)
5) autolog command (shipped in vm370 release 3)
6) the special message function from POK
I had originally created the autolog command as part of automating
benchmarks (along with the feature that automatically started
processes at initial boot)
https://www.garlic.com/~lynn/submain.html#bench
however, the feature proved so useful for general vm370 operations, it eventually came into wide use as part of standard processing and was shipped in the standard release 3 vm370 product.
again, lots of past resource manager posts
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock
The fair share scheduler, including various paging and performance items, I had originally created as enhancements to cp67 as an undergraduate in the 60s. Many of the features had been dropped in the morph from cp67 to vm370. However, by the time, the resource manager was ready to ship, I had added an implementation supporting "SET FAVORED".
CSC/VM posts
https://www.garlic.com/~lynn/submisc.html#cscvm
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 -0700Anne & Lynn Wheeler <lynn@garlic.com> writes:
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 -0700Concurrent with the benchmarking, shared segment, page mapped filesystem, resource manager, and other misc. stuff referred to in these posts
I was also at the same time doing a lot of the work on VIRGIL/TULLY
(138/148) and ECPS
https://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist
https://www.garlic.com/~lynn/94.html#27 370 ECPS VM microcode assist
https://www.garlic.com/~lynn/94.html#28 370 ECPS VM microcode assist
and at the same time doing system and microcode design for VAMPS,
a five-way multiprocessor effort ... collected past posts mentiong VAMPS
https://www.garlic.com/~lynn/submain.html#bounce
For some reason, the product people responsible for both VIRGIL/TULLY
and VAMPS somewhat viewed the other as competing products; even though
i was doing much of the design for both products. There were some
corporate product escalation meetings where I was expected to sit on
both sides of the table simultaneously and argue it out with myself.
VIRGIL/TULLY shipped, but VAMPS was canceled.
Date: August 27, 1975
Memo to: Endicott
cc: wheeler
Subject: Simplifying Technical Considerations for VAMPS
References:
1) Technical Review of VAMPS Proposal
by KKKKKK and WWWWW dated 8/5/75
2) Update of above dated 8/21/75
As you pointed out last week during the Boeblingen Technical Review
sessions, the VAMPS schedule is a critical PSE factor.
During these sessions it became evident that the technical
considerations of the original VAMPS proposal had not been fully
adjusted to account for a marketing strategy similar to that for the
VIRGIL/TULLY VM proposal.
As described in the Attachment, this revised marketing strategy for
VAMPS provides a number of technical simplifications. These
simplifications are being proposed for resource and schedule reasons
and not for reasons of technical feasibility.
While the possible tradeoffs that these simplifications could allow in
the major redesign MSC and dispatcher areas are not clear, the
significant reduction in the total number of changes should not only
alleviate the resources required, but also possibly the schedule due
to the reduction in dependencies and testing.
If the VAMPS forecast look promising early in September, a more detail
technical design review of the MSC and dispatcher areas should be
immediately arranged in Boeblingen after which more accurate resource
and schedule estimates can be derived.
... snip ... top of post, old email index
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 -0700ref:
while only a small subset of the virtual memory management stuff was released as DCSS vm370 ... and none of the cms paged mapped filesystem stuff ... a little more of the virtual memory management stuff was used for the original relational/sql implementation in system/r ..... which provided r/w (unprotected) shared segments between semi-privileged processes (different system/r database tasks running in different virtual address spaces).
misc. past posts mentioning system/r work
https://www.garlic.com/~lynn/submain.html#systemr
It was also part of the technology transfer of system/r to endicott for what was to become sql/ds. This addition feature took on the name DWSS (or dynamic writeable shared segments) ... and there was lots of issues on whether or not it impacted ECPS and microcode on existing customer machines.
recent posts mentioning system/r and DWSS
https://www.garlic.com/~lynn/2006t.html#16 Is the teaching of non-reentrant HLASM coding practices ever defensible?
https://www.garlic.com/~lynn/2006t.html#39 Why these original FORTRAN quirks?
recent posts on early virtual memory management stuff (a small subset which was going to be released as DCSS in vm370 release 3)
https://www.garlic.com/~lynn/2006v.html#36 Why these original FORTRAN quirks?
https://www.garlic.com/~lynn/2006w.html#7 Why these original FORTRAN quirks?
https://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?
https://www.garlic.com/~lynn/2006w.html#9 dcss and page mapped file system
i also worked on a semantic network related activity about the same
time as the system/r stuff which used more of the virtual memory
management and page mapped technology ... recent reference
https://www.garlic.com/~lynn/2006v.html#48 Why so little parallelism?
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 -0700In the following, CJNTEL was an online corporate directory that I had initially put up on SJRLVM1 that could be queried by anybody on the internal network.
The following has a suggestion for registering a person's public key with CJNTEL and making (effecitvely publishing) it available for retrieval by anybody with access to the internal network.
following is some 15 years or so before being brought in to do some
consulting with a small client/server startup that wanted to do
payment transactions on their server
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
Date: 05/15/81 13:41:12
To: wheeler
re: more secure communication over the network
One of the obvious concerns that will surely surface from the CJN work
will be the problem of confidential information being exchanged over
the network.
I have a package from ****** called CRYPT that may be a solution. The
package implements a public key encryption system proposed by Diffie
and Hellman (see recent vm newsletter). The problem we have with
using CIPHER is that we must know an agreed upon key and we have to
exchange the key in a secure manner prior to communication.
The public key system works as follows: I publish a key which anyone
can look up. They use that key to CRYPT the file. That key can only
"lock the safe". In order to DECRYPT the file ("unlock the safe") I
have a private key which no-one knows. Only the private key can unlock
the safe.
As an implementation I suggest we update out CJNTEL entry to include a
public key for each of us. The package includes a procedure for
generating keys. In this way I can look up your key in CJNTEL and send
you ENCRYPTED confidential data.
Cheap and simple.
... snip ... top of post, old email index
effectively certificate-less public key operation ... misc. past posts
mentioning certificate-less public key operation
https://www.garlic.com/~lynn/subpubkey.html#certless
and somewhat similar to the discussion about publishing public keys in
the domain name infrastructure ... a few posts this year discussing
the subject:
https://www.garlic.com/~lynn/2006b.html#37 X.509 and ssh
https://www.garlic.com/~lynn/2006c.html#10 X.509 and ssh
https://www.garlic.com/~lynn/2006c.html#34 X.509 and ssh
https://www.garlic.com/~lynn/2006c.html#35 X.509 and ssh
https://www.garlic.com/~lynn/2006c.html#38 X.509 and ssh
https://www.garlic.com/~lynn/2006d.html#29 Caller ID "spoofing"
https://www.garlic.com/~lynn/2006f.html#16 trusted repositories and trusted transactions
https://www.garlic.com/~lynn/2006f.html#32 X.509 and ssh
https://www.garlic.com/~lynn/2006f.html#33 X.509 and ssh
https://www.garlic.com/~lynn/2006f.html#34 X.509 and ssh
https://www.garlic.com/~lynn/2006h.html#27 confidence in CA
https://www.garlic.com/~lynn/2006p.html#7 SSL, Apache 2 and RSA key sizes
https://www.garlic.com/~lynn/2006t.html#8 Root CA CRLs
https://www.garlic.com/~lynn/2006v.html#49 Patent buster for a method that increases password security
as well as the whole account authority digital signature stuff
https://www.garlic.com/~lynn/x959.html#aads
... CJNTEL is different than the internal "online telephone book"
recently mentioned here
https://www.garlic.com/~lynn/2006v.html#32 Effi[ci]ency of branch table vs individual compare & branch
the internal online telephone book captured the original source from various corporate locations (that were used to generate the printed copy), converted the source to desired format and made them available for distribution. this normally was loaded on local systems that allowed users to do online lookups on their local machine.
CJNTEL could be accessed remotely over the internal network using
"special message" ... misc. past posts about the internal network
... which was larger than the arpanet/internet from just about the
beginning until sometime mid-85.
https://www.garlic.com/~lynn/subnetwork.html#internalnet
note that the above reference is in addition to the requirement that all links leaving corporate facilities required link encryptors ... at one point there was the claim that the internal network had move than half of all link encryptors in the world.
misc. recent posts mentioning special message
https://www.garlic.com/~lynn/2006k.html#51 other cp/cms history
https://www.garlic.com/~lynn/2006t.html#47 To RISC or not to RISC
https://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?
We did do a modification to CJNTEL so that in addition to doing various operations on its corporate directory, it was also possible (for remote network user) to request CJNTEL to execute the telephone directory command on SJRLVM1 ... returning the results over the network.
for some topic drift ... some references to the hsdt (high speed data transport)
project
https://www.garlic.com/~lynn/subnetwork.html#hsdt
and some recent posts about various interactions with NSF:
https://www.garlic.com/~lynn/2006s.html#50 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006t.html#6 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006u.html#56 Ranking of non-IBM mainframe builders?
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 -0700lefuller@SBCGLOBAL.NET (Lloyd Fuller) writes:
various past posts about original relational/sql implementation and
technology transfer from sjr to endicott for sql/ds
https://www.garlic.com/~lynn/submain.html#systemr
most recent comment in this post
https://www.garlic.com/~lynn/2006w.html#11
one of the people in this meeting claimed to have handled the
technology transfer from endicott back to stl for DB2 (i.e. sort of
long way around since SJR and STL were only about 10 miles apart, i
use to ride it on my bike).
https://www.garlic.com/~lynn/95.html#13
https://www.garlic.com/~lynn/96.html#15
i.e. mainframe implementation done in PLS.
The other rdbms project was later done in toronto as portable rdbms in C and went thru a number of code names, at least shelby, persist, and crosswinds
a couple past posts mentioning the "other" db2, shelby, etc.
(including some URLs comparing/contrasting)
https://www.garlic.com/~lynn/2005b.html#1 Foreign key in Oracle Sql
https://www.garlic.com/~lynn/2005u.html#41 Mainframe Applications and Records Keeping?
and for other topic drift leading up to meeting mentioned in these posts
(and cluster scale-up):
https://www.garlic.com/~lynn/95.html#13
https://www.garlic.com/~lynn/96.html#15
and
https://www.garlic.com/~lynn/2001n.html#83
Date: 14 October 1991, 16:05:32 CDT
To: wheeler
Last Thursday (10/10) ******* and I made a presentation to ****** for
a cluster-in-a-rack proposal called MEDUSA. ****** liked the idea and
wants to see what it will take to put MEDUSA into the plan. MEDUSA
would provide the capability of a cluster MP beta test in 3Q92 and
address commercial (HA/6000) market.
... snip ... top of post, old email index
of course, lots of past ha/cmp posts
https://www.garlic.com/~lynn/subtopic.html#hacmp
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 -0700jsavard writes:
a few posts in (comp.arch) JIT thread(s)
https://www.garlic.com/~lynn/2006r.html#24 A Day For Surprises (Astounding Itanium Tricks)
https://www.garlic.com/~lynn/2006u.html#29 To RISC or not to RISC
https://www.garlic.com/~lynn/2006u.html#31 To RISC or not to RISC
https://www.garlic.com/~lynn/2006u.html#32 To RISC or not to RISC
https://www.garlic.com/~lynn/2006u.html#33 Assembler question
and from the previous post
https://www.garlic.com/~lynn/2006w.html#13
and
https://www.garlic.com/~lynn/95.html#13
https://www.garlic.com/~lynn/96.html#15
https://www.garlic.com/~lynn/2001n.html#83
and a little more old MEDUSA email
The idea was significantly reducing the physical footprint ... and one of the challenges for MEDUSA was getting enuf colling into the "pancakes".
In the push for higher and higher density in racks, there were both
thinner & thinner pancakes and then "half-wide" pancakes ... and then
the transition to blades ... where the units were mounted vertically
instead of horizontal.
Date: 10 September 1991, 07:39:24 CDT
To: wheeler
I think we need to talk some more about the cluster rack and its
applicability to the HA work you are doing.
After our last conversation and additional engineering input, the
definition has changed. As currently defined MEDUSA (as we now call
it) is 32 processor rack with an integrated FCS Switch. Each processor
drawer consists of:
- one RS_1 processor
- 16-256MBytes of Memory
- ROS, NVRAN, + other junk
- 2 FCS channels
The intent is to make the FCS channels pluggable such that either
gigabit or quarter speed optics could be plugged at the users
option. This also permits initial debug to occur without FCS (from a
hardware standpoint FCS is the schedule gate). The number of
processors is selectable by the customer as is the amount on memory
per processor (pluggable up to a maximum of 256MB per proc).
The rack will contain a 64 channel fully non-blocking FCS Ancor
switch.
We need to develop an initial IBP and perhaps you could help. I would
like to factor in your work and thoughts on software and market
potential from a commercial prospective.
... snip ... top of post, old email index
oh and past reference to trying to do high density racks with
blade like configurations in 1985 (references towards the end of the
post):
https://www.garlic.com/~lynn/2004m.html#17 mainframe and microprocessor
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 -0700jsavard writes:
for other comments on aspects of current, common public key infrastructure
deployments see collected posts on ssl digital certificates
https://www.garlic.com/~lynn/subpubkey.html#sslcert
or this post
https://www.garlic.com/~lynn/2006v.html#49 Patent buster for a method that increases password security
or these posts observing the catch-22 in some improvements to ssl
domain name digital certificate operation (the proposals for improving
integrity/deficiencies in the current operations can result in
eliminating the requirement for the digital certificates)
https://www.garlic.com/~lynn/subpubkey.html#catch22
in fact, there are some similarities to some of the suggestions described in the referenced catch-22 posts and the suggestion from 1981.
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 -0700Another CMSBACK status, a year later than the email referenced here
i.e. i had done the original CMSBACK implementation and deployment in
the late 70s on sjr systems and hone ... the following refers to
there additional systems where it was installed:
Date: 12/11/80 15:21:31
To: distribution
CMSBACK is now installed in: Los Gatos (2, CPUs), GPD SNJ (3), GPD STL
(1) Austin (1) Note: Austin has (re)installed CMSBACK in other
locations. It is also being installed in Yorktown.
... snip ... top of post, old email index
other recent CMSBACK references:
https://www.garlic.com/~lynn/2006t.html#20 Why these original FORTRAN quirks?; Now : Programming practices
https://www.garlic.com/~lynn/2006t.html#33 threads versus task
https://www.garlic.com/~lynn/2006u.html#19 Why so little parallelism?
https://www.garlic.com/~lynn/2006u.html#26 Assembler question
https://www.garlic.com/~lynn/2006u.html#30 Why so little parallelism?
https://www.garlic.com/~lynn/2006v.html#24 Z/Os Storage Mgmt products
and collected past posts on backup/archive systems
https://www.garlic.com/~lynn/submain.html#backup
all of this preceeding the work mentioned in Melinda's history paper
by a couple years (even preceeding the hiring of the people that
Melinda's history paper mentions as having done the original work).
https://www.leeandmelindavarian.com/Melinda#VMHist
now as to automated operator &/or automated operations ...
the autolog command ... mentioned here
https://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?
helped significantly with the automation of service virtual machines
... some recent references here:
https://www.garlic.com/~lynn/2006p.html#10 What part of z/OS is the OS?
https://www.garlic.com/~lynn/2006t.html#45 To RISC or not to RISC
https://www.garlic.com/~lynn/2006t.html#46 To RISC or not to RISC
https://www.garlic.com/~lynn/2006v.html#22 vmshare
CMSBACK would be one example of service virtual machine ... another would be VNET ... another would be the facility developed for automated benchmarking.
I had originally created the autolog command (and the automated
flavor that was done at kernel boot) in support of automated
benchmarking
https://www.garlic.com/~lynn/submain.html#bench
aka, i needed automatically (and unattended) to stop a current benchmark, generate a new kernel with various modifications, reboot to the new kernel, and start the next set of benchmarks. this could be repeated a couple times an hour for extended period straight (say 6-10 8hr shifts).
now some rudimentary stuff could be done for automated operations using
combination of service virtual machines (autolog command being one
of the enablers) and special message facility ... which allowed
application to capture all text (messages, cp command responses, etc)
that normally would be written to the terminal/screen. a couple recent
posts mentioning SPM
https://www.garlic.com/~lynn/2006k.html#51 other cp/cms history
https://www.garlic.com/~lynn/2006t.html#47 To RISC or not to RISC
https://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?
another service virtual machine would be CJNTEL using special
message ... mentioned here
https://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network
some drift ... the above post also includes a mention from 1981 for public key infrastructure kind of operation.
however, simple text/message processing was lacking sophisticated parsing ... like
found in parasite/story ... misc. references
https://www.garlic.com/~lynn/2001k.html#35 Newbie TOPS-10 7.03 question
https://www.garlic.com/~lynn/2003i.html#73 Computer resources, past, present, and future
https://www.garlic.com/~lynn/2003j.html#24 Red Phosphor Terminal?
https://www.garlic.com/~lynn/2004e.html#14 were dumb terminals actually so dumb???
https://www.garlic.com/~lynn/2005r.html#12 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2006.html#3 PVM protocol documentation found
https://www.garlic.com/~lynn/2006c.html#14 Program execution speed
https://www.garlic.com/~lynn/2006f.html#37 Over my head in a JES exit
https://www.garlic.com/~lynn/2006m.html#35 Draft Command Script Processing Manual
https://www.garlic.com/~lynn/2006n.html#23 sorting was: The System/360 Model 20 Wasn't As Bad As All That
https://www.garlic.com/~lynn/2006p.html#31 "25th Anniversary of the Personal Computer"
or later hllapi-like implementations. also missing was sophisticated rule infrastructures (allowing specification about what should be done in different kinds of circumstances).
for other references, part of an old SPMS application document ....
SPMS: CMS/SPM Interface Program 1
1.0 INTRODUCTION
SPMS is a transient CMS command that can be called by an
EXEC or by a program running in a virtual machine. It
enables the user to use the CP Special Message Facility to
intercept messages from CP or from other users and process
them within a CMS program or EXEC. A CP command may be
passed to SPMS to cause the response to that command to be
returned to the caller, or SPMS can be used to trap messages
not associated with any particular CP command. Messages
received through SPMS can be placed in the CMS console stack
and read in by the EXEC or program which called SPMS, or, if
SPMS was called by a program, the addresses of the messages
received can be passed directly back to the program. To use
SPMS properly, the user should have a good knowledge of the
CP and CMS command languages, as well as an understanding of
the CMS console stack concept and the Special Message
Facility.
SPMS provides two modes of operation. In 'immediate' mode,
it issues a single CP command and returns the response (if
any) to that command to the caller, and exits immediately.
In 'continuous' mode, it builds a Special Message 'trap',
which remains active in CMS after SPMS ends. The calling
routine can then continue with other work and issue another
call to SPMS with parameters requesting that any accumulated
messages be returned to it at that time, or that the SPM
trap be removed from CMS.
The Special Message Facility makes a distinction between
messages from CP itself (such as responses to commands), and
messages from other users. SPMS provides options which make
it possible to deal with 'MSG' type messages and 'CP' type
messages separately. When SPMS is used in 'immediate' mode,
it examines the CP command passed to it to determine whether
it is a command that would cause a message to be sent to
another user. If it is a 'MESSAGE' type command, SPMS will
wait for a 'MSG' type response in the assumption that the
issuer is awaiting a response from the recipient of the
message being sent. (Although it will accept a message from
any user as a response.) If the command being issued is not
a 'MESSAGE' type command, SPMS will wait for a 'CP' response
only.
In some situations, the response to a CP command might be
delayed or there might be no response. When using SPMS in
immediate mode, the user may specify how long to wait before
exiting without receiving a response.
Messages placed in the console stack by SPMS are stacked in
FIFO sequence by default. Through the use of an optional
parameter the user may cause the messages to be stacked in a
8 June 1979 1 of 16
... snip ...
and lots of old posts mentioning the subject of automated
operator
https://www.garlic.com/~lynn/94.html#2 Schedulers
https://www.garlic.com/~lynn/99.html#71 High Availabilty on S/390
https://www.garlic.com/~lynn/99.html#107 Computer History
https://www.garlic.com/~lynn/99.html#128 Examples of non-relational databases
https://www.garlic.com/~lynn/99.html#136a checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/2000.html#22 Computer of the century
https://www.garlic.com/~lynn/2000f.html#12 Amdahl Exits Mainframe Market
https://www.garlic.com/~lynn/2001.html#43 Life as a programmer--1960, 1965?
https://www.garlic.com/~lynn/2001c.html#13 LINUS for S/390
https://www.garlic.com/~lynn/2001d.html#70 Pentium 4 Prefetch engine?
https://www.garlic.com/~lynn/2001d.html#71 Pentium 4 Prefetch engine?
https://www.garlic.com/~lynn/2001e.html#44 Where are IBM z390 SPECint2000 results?
https://www.garlic.com/~lynn/2001e.html#47 Where are IBM z390 SPECint2000 results?
https://www.garlic.com/~lynn/2001h.html#8 VM: checking some myths.
https://www.garlic.com/~lynn/2001k.html#13 HP-UX will not be ported to Alpha (no surprise)exit
https://www.garlic.com/~lynn/2001k.html#14 HP-UX will not be ported to Alpha (no surprise)exit
https://www.garlic.com/~lynn/2001k.html#18 HP-UX will not be ported to Alpha (no surprise)exit
https://www.garlic.com/~lynn/2001l.html#47 five-nines
https://www.garlic.com/~lynn/2001n.html#47 Sysplex Info
https://www.garlic.com/~lynn/2001n.html#85 The demise of compaq
https://www.garlic.com/~lynn/2002.html#24 Buffer overflow
https://www.garlic.com/~lynn/2002e.html#68 Blade architectures
https://www.garlic.com/~lynn/2002h.html#73 Where did text file line ending characters begin?
https://www.garlic.com/~lynn/2002l.html#62 Itanium2 performance data from SGI
https://www.garlic.com/~lynn/2002n.html#27 why does wait state exist?
https://www.garlic.com/~lynn/2002o.html#14 Home mainframes
https://www.garlic.com/~lynn/2002p.html#54 Newbie: Two quesions about mainframes
https://www.garlic.com/~lynn/2003.html#37 Calculating expected reliability for designed system
https://www.garlic.com/~lynn/2003g.html#3 Disk capacity and backup solutions
https://www.garlic.com/~lynn/2003h.html#56 The figures of merit that make mainframes worth the price
https://www.garlic.com/~lynn/2003h.html#60 The figures of merit that make mainframes worth the price
https://www.garlic.com/~lynn/2003i.html#27 instant messaging
https://www.garlic.com/~lynn/2003n.html#22 foundations of relational theory? - some references for the
https://www.garlic.com/~lynn/2003n.html#45 hung/zombie users ... long boring, wandering story
https://www.garlic.com/~lynn/2004.html#40 AMD/Linux vs Intel/Microsoft
https://www.garlic.com/~lynn/2004b.html#48 Automating secure transactions
https://www.garlic.com/~lynn/2004m.html#46 Shipwrecks
https://www.garlic.com/~lynn/2004q.html#75 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005.html#53 8086 memory space
https://www.garlic.com/~lynn/2005.html#59 8086 memory space
https://www.garlic.com/~lynn/2005c.html#7 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005d.html#9 intel's Vanderpool and virtualization in general (was Re: Cell press release, redacted.)
https://www.garlic.com/~lynn/2005j.html#60 Ancient history
https://www.garlic.com/~lynn/2005m.html#52 Cluster computing drawbacks
https://www.garlic.com/~lynn/2005o.html#30 auto reIPL
https://www.garlic.com/~lynn/2005u.html#37 Mainframe Applications and Records Keeping?
https://www.garlic.com/~lynn/2006i.html#2 The Pankian Metaphor
https://www.garlic.com/~lynn/2006u.html#30 Why so little parallelism?
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 -0700Casper H.S. Dik <Casper.Dik@Sun.COM> writes:
an issue is if the TLB (and virtual cache) are virtual address space associative ("STO-associative" in some of the discussions) ... then they have different TLB/cache entries (even if they might have the same physical address and potentially even the same virtual address). For shared memory segments ... the problem can go away ... if the TLB/cache are segment associative ("PTO-associative" in some of the discussions). For instance, you find TLB being virtual segment associative (instead of virtual address space associative) in various 801 machines.
some postings about 3090 having cache that was indexed by both real
address (real address associative) and "logical" address (and being
virtual address space associative).
https://www.garlic.com/~lynn/2003j.html#42 Flash 10208
https://www.garlic.com/~lynn/2006u.html#37 To RISC or not to RISC
https://www.garlic.com/~lynn/2006v.html#6 Reasons for the big paradigm switch
https://www.garlic.com/~lynn/2006v.html#43 The Future of CPUs: What's After Multi-Core?
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 -0700Anne & Lynn Wheeler <lynn@garlic.com> writes:
note the above reference is also somewhat similar to the PGP keyservers
for additional drift, a couple other posts with emails from the 70s
and 80s mentioning crypto
https://www.garlic.com/~lynn/2006.html#30 IBM microwave application--early data communications
https://www.garlic.com/~lynn/2006n.html#23 sorting was: The System/360 Model 20 Wasn't As Bad As All That
https://www.garlic.com/~lynn/2006n.html#36 The very first text editor
and related thread with other archeological references:
https://www.garlic.com/~lynn/aadsm26.htm#9 Who has a Core Competency in Security?
https://www.garlic.com/~lynn/aadsm26.htm#10 Who has a Core Competency in Security?
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 -0700Anne & Lynn Wheeler <lynn@garlic.com> writes:
couple recent posts with emails from the early/mid 70s about
doing shared segment work including support for same virtual
shared segment appearing at different virtual addresses in different
virtual address spaces
https://www.garlic.com/~lynn/2006v.html#36 Why these original Fortran quirks?
https://www.garlic.com/~lynn/2006w.html#7 Why these original Fortran quirks?
https://www.garlic.com/~lynn/2006w.html#8 Why these original Fortran quirks?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: cluster-in-a-rack Newsgroups: alt.folklore.computers Date: Sun, 10 Dec 2006 10:01:47 -0700more in the MEDUSA saga
i.e. at the time, 32 processors per rack.
leading up to the meeting in Ellison's conference room in Jan92
https://www.garlic.com/~lynn/95.html#13
https://www.garlic.com/~lynn/96.html#15
and then
https://www.garlic.com/~lynn/2001n.html#83
In the following, "Harrier/9333" eventually became "SSA" referred to
in the postings mentioning the meeting in Ellison's conference room.
Date: 24 Oct 91 07:29:46
To: wheeler
I reviewed the MEDUSA proposal with ******** concentrating
on the DASD and tape requirements with focus on the projected
9/92 Beta test. I also described ****** overwhelming positive
reaction to MEDUSA and his intent to put MEDUSA into the AWD plan.
I also described the program in ******* to add FCS attachment to
Pacheco_II with a Beta test target date of 3Q92.
Due to ******* intention of putting MEDUSA into the AWD plan, I felt it
was necessary to secure an alternate DASD source for MEDUSA (a backup
to the Pacheco_II plan). To this end, I asked ****** to help me put
together a creditable and implementable DASD story for MEDUSA.
Of particular interest is a follow-on to Harrier and the Corsair
... snip ... top of post, old email index
In the following, "FSD" refers to the federal system division
Date: 11/19/91 12:48:26
From: wheeler
This was a meeting with a pedigreed FSD attendance of all their best
technical people and all their most important project managers, about
25 in all. The end result will be documented for us by ***** in about
a week. my version is that with concurrence from all present, FSD will
go forward with a business plan that makes MEDUSA with HA/6000 Unitree
and Oracle the basis for most of what they're doing, and they will
want to work in a joint development mode with us.
... snip ... top of post, old email index
in a little over two months after the above email, cluster-in-a-rack project had been transferred, and we were told that we couldn't work on anything with more than four processors.
collected posts mentioning ha/6000 and ha/cmp
https://www.garlic.com/~lynn/subtopic.html#hacmp
and misc. posts mentioning unitree
https://www.garlic.com/~lynn/2001f.html#66 commodity storage servers
https://www.garlic.com/~lynn/2002e.html#46 What goes into a 3090?
https://www.garlic.com/~lynn/2002g.html#61 GE 625/635 Reference + Smart Hardware
https://www.garlic.com/~lynn/2002k.html#31 general networking is: DEC eNet: was Vnet : Unbelievable
https://www.garlic.com/~lynn/2003b.html#29 360/370 disk drives
https://www.garlic.com/~lynn/2003b.html#31 360/370 disk drives
https://www.garlic.com/~lynn/2003h.html#6 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
https://www.garlic.com/~lynn/2003i.html#53 A Dark Day
https://www.garlic.com/~lynn/2005e.html#12 Device and channel
https://www.garlic.com/~lynn/2005e.html#15 Device and channel
https://www.garlic.com/~lynn/2005e.html#16 Device and channel
https://www.garlic.com/~lynn/2006n.html#29 CRAM, DataCell, and 3850
https://www.garlic.com/~lynn/2006u.html#19 Why so little parallelism?
https://www.garlic.com/~lynn/2006u.html#20 Why so little parallelism?
https://www.garlic.com/~lynn/2006u.html#27 Why so little parallelism?
https://www.garlic.com/~lynn/2006v.html#10 What's a mainframe?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: SNA/VTAM for NSFNET Newsgroups: alt.folklore.computers Date: Sun, 10 Dec 2006 17:35:55 -0700sna/vtam for nsfnet??
Long ago and far away, somebody ran across a copy of a series of
emails and forwarded a copy to us in the HSDT project
https://www.garlic.com/~lynn/subnetwork.html#hsdt
aka ... SNA/VTAM people taking over our NSFNET activities
some of the people involved had also been involved in calling up
various univ. and NSF people and canceling HSDT meetings that we had
scheduled (starting earlier) ... some of which is referenced here
https://www.garlic.com/~lynn/2006u.html#56 Ranking of non-IBM mainframe builders?
and specific meeting mentioned here
https://www.garlic.com/~lynn/2005d.html#13 Cerf and Kahn receive Turing award
a couple other recent references to our NSFNET activity (having T1 and
higher speed stuff)
https://www.garlic.com/~lynn/2006s.html#50 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006t.html#6 Ranking of non-IBM mainframe builders?
anyway a couple weeks short of twenty years ago ... culture of misinformation and FUD
Date: 01/09/87 16:11:26
From: ?????
TO ALL IT MAY CONCERN-
I REC'D THIS TODAY. THEY HAVE CERTAINLY BEEN BUSY. THERE IS A HOST
OF MISINFORMATION IN THIS, INCLUDING THE ASSUMPTION THAT TCP/IP CAN
RUN ON TOP OF VTAM, AND THAT WOULD BE ACCEPTABLE TO NSF, AND THAT THE
UNIVERSITIES MENTIONED HAVE IBM HOSTS WITH VTAM INSTALLED.
Forwarded From: ***** To: ***** Date: 12/26/86 13:41
1. Your suggestions to start working with NSF immediately on high
speed (T1) networks is very good. In addition to ACIS I think that it
is important to have CPD Boca involved since they own the products you
suggest installing. I would suggest that ***** discuss this and plan
to have the kind of meeting with NSF that ***** proposes.
<... great deal more of the same; several more appended emails from several
participants in the MISINFORMATION ...>
... snip ... top of post, old email index, NSFNET email
other old NSFNET related email
https://www.garlic.com/~lynn/lhwemail.html#nsfnet
as an aside ... sna/vtam group still considered 56kbit "high speed"
and T1 was "very high speed" ... aka various references from this year:
https://www.garlic.com/~lynn/2006e.html#36 The Pankian Metaphor
https://www.garlic.com/~lynn/2006s.html#42 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006s.html#50 Ranking of non-IBM mainframe builders?
reference to sna/vtam group deciding that product support for T1
wasn't even needed until possibly sometime in the 90s (and why their
56kbit "fat pipes" were good enuf)
https://www.garlic.com/~lynn/2001.html#4 Sv: First video terminal?
https://www.garlic.com/~lynn/2002j.html#67 Total Computing Power
https://www.garlic.com/~lynn/2003m.html#28 SR 15,15
https://www.garlic.com/~lynn/2003m.html#59 SR 15,15
https://www.garlic.com/~lynn/2004g.html#37 network history
https://www.garlic.com/~lynn/2004l.html#7 Xah Lee's Unixism
https://www.garlic.com/~lynn/2005j.html#59 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
https://www.garlic.com/~lynn/2006l.html#4 Google Architecture
there was a mainframe vm-based tcp/ip product support coming ... but
it didn't involve VTAM (TCP/IP on VTAM was much, much later). The vm
implemetations was subsequently ported to MVS by doing a "vm diagnose"
simulator (for those things needed by the tcp/ip implementation). I
was somewhat involved in the vm implementation, adding rfc 1044
support to the base implementation
https://www.garlic.com/~lynn/subnetwork.html#1044
that base vm implementation was getting about 44kbytes/sec aggregegate thruput using a full 3090 processor. in some tuning work at cray research got 1mbyte/sec between a cray and a 4341-clone (out of the rfc 1044 support) ... only using a modest amount of the 4341 processor.
So the first of the forwarded email ... partially included in the above
(12/26/86), was from person that was also heavily involved later in
transfering cluster scale-up (and we were told we couldn't work on
anything with more than four processors) ... partial reference here:
https://www.garlic.com/~lynn/95.html#13
https://www.garlic.com/~lynn/96.html#15
old email related to cluster scale-up
https://www.garlic.com/~lynn/lhwemail.html#medusa
The above excerpt (12/26/86) even suggests VTAM in NSF
backbone; NOTE there was NOT TCP/IP in VTAM until much
later. somewhat related leading up to the above mentioned meeting
https://www.garlic.com/~lynn/2006w.html#13
https://www.garlic.com/~lynn/2006w.html#14
https://www.garlic.com/~lynn/2006w.html#20
and
https://www.garlic.com/~lynn/2001n.html#83
for even more topic drift ... two people in the above mentioned Jan92
(in Ellison's conference room) meeting later showed up in a small
client/server startup responsible for something called commerce
server. we were called in to consult because they wanted to process
payment transactions on their servers ... some references
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
later it started to be called electronic commerce.
and an earlier suggestion for securing networking communication
https://www.garlic.com/~lynn/2006w.html#12
https://www.garlic.com/~lynn/2006w.html#15
https://www.garlic.com/~lynn/2006w.html#18
Now while the original NSFNET request went out for T1, somewhat based on our work with them ... the actual winner for the initial NSFNET didn't have "real" T1 networking links. The network/router interfaces that they used only went up to 440kbits/sec. The contract called for T1 links ... so there were these actual physical T1 links ... and then there was telco-type multiplexor that multiplexed three 440kbit network links over the physical T1 links. Using that logic ... the T1 links possible were in turn multiplexed over even a T5 link at some point ... which would have allowed the claim that it was a T5 network(?).
as mentioned before, we were prevented for participating in the bid,
and NSF analysis was that what we already had running was at least
five years ahead of all bid submissions ... misc. past posts
mentioning it
https://www.garlic.com/~lynn/98.html#49 Edsger Dijkstra: the blackest week of his professional life
https://www.garlic.com/~lynn/99.html#33 why is there an "@" key?
https://www.garlic.com/~lynn/99.html#37a Internet and/or ARPANET?
https://www.garlic.com/~lynn/internet.htm#0 Internet and/or ARPANET?
https://www.garlic.com/~lynn/aadsm13.htm#17 A challenge
https://www.garlic.com/~lynn/2001d.html#42 IBM was/is: Imitation...
https://www.garlic.com/~lynn/2001h.html#44 Wired News :The Grid: The Next-Gen Internet?
https://www.garlic.com/~lynn/2002.html#32 Buffer overflow
https://www.garlic.com/~lynn/2002f.html#5 Blade architectures
https://www.garlic.com/~lynn/2002i.html#45 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002k.html#56 Moore law
https://www.garlic.com/~lynn/2003c.html#46 difference between itanium and alpha
https://www.garlic.com/~lynn/2003d.html#59 unix
https://www.garlic.com/~lynn/2003g.html#36 netscape firebird contraversy
https://www.garlic.com/~lynn/2003j.html#1 FAST - Shame On You Caltech!!!
https://www.garlic.com/~lynn/2004g.html#12 network history
https://www.garlic.com/~lynn/2004q.html#57 high speed network, cross-over from sci.crypt
https://www.garlic.com/~lynn/2004q.html#58 CAS and LL/SC (was Re: High Level Assembler for MVS & VM & VSE)
https://www.garlic.com/~lynn/2005d.html#6 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005d.html#10 Cerf and Kahn receive Turing award
https://www.garlic.com/~lynn/2005j.html#30 IBM Plugs Big Iron to the College Crowd
https://www.garlic.com/~lynn/2005j.html#58 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
https://www.garlic.com/~lynn/2005l.html#16 Newsgroups (Was Another OS/390 to z/OS 1.4 migration
https://www.garlic.com/~lynn/2005n.html#28 Data communications over telegraph circuits
https://www.garlic.com/~lynn/2005p.html#10 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005p.html#16 DUMP Datasets and SMS
https://www.garlic.com/~lynn/2005q.html#3 winscape?
https://www.garlic.com/~lynn/2005q.html#6 What are the latest topic in TCP/IP
https://www.garlic.com/~lynn/2005q.html#46 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005s.html#28 MVCIN instruction
https://www.garlic.com/~lynn/2005u.html#53 OSI model and an interview
https://www.garlic.com/~lynn/2006e.html#36 The Pankian Metaphor
https://www.garlic.com/~lynn/2006f.html#12 Barbaras (mini-)rant
https://www.garlic.com/~lynn/2006g.html#18 TOD Clock the same as the BIOS clock in PCs?
https://www.garlic.com/~lynn/2006h.html#51 The Chant of the Trolloc Hordes
https://www.garlic.com/~lynn/2006i.html#21 blast from the past on reliable communication
https://www.garlic.com/~lynn/2006j.html#34 Arpa address
https://www.garlic.com/~lynn/2006r.html#6 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006s.html#20 real core
https://www.garlic.com/~lynn/2006v.html#35 What's a mainframe?
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 -0700Are hypervisors the new foundation for system software?
from above:
A Pocket History of Virtualization
...
These initial enhancements could all be accommodated within the
operating system, until the day arrived when different users, or
different applications on the same physical machine, wanted to run
different operating systems. This requirement could be satisfied only
by supporting multiple VMs, each capable of running its own operating
system. The virtualization era (marked by IBM's release of VM for the
System/360 in 1972) had dawned.
... snip ...
the new 40yr old thing
https://www.garlic.com/~lynn/2006s.html#65
https://www.garlic.com/~lynn/2006t.html#27
https://www.garlic.com/~lynn/2006v.html#21
https://www.garlic.com/~lynn/2006v.html#52
https://www.garlic.com/~lynn/2006w.html#0
of course vm370 was a morph of cp67 that had been done for the 360/67.
three people from the science center
https://www.garlic.com/~lynn/subtopic.html#545tech
came out to the university the last week of jan68 and installed a copy. I then got to play with it ... rewriting large amounts of it.
the spring mar68 SHARE meeting in houston officially announced
availability of cp67.
https://www.garlic.com/~lynn/2003d.html#72 CP67 35th anniversary
old post including piece of presentation at the fall68 SHARE meeting in
Atlantic City on some of the (cp67 and mft14) changes that i made
https://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14
of course, the science center had previously done cp40 on a custom modified 360/40 before the availability of 360/67 machine ... when they got one, they morphed cp40 into cp67 on the 360/67.
https://www.garlic.com/~lynn/2004c.html#11 40yrs, science center, feb. 1964
Melinda's paper has a lot more detailed history
https://www.leeandmelindavarian.com/Melinda#VMHist
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Multiple mappings Newsgroups: comp.arch Date: Mon, 11 Dec 2006 08:00:31 -0700nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
nope ... my virtual memory management didn't preclude having the same shared segment at different virtual addresses whether in different virtual address spaces or the same virtual address space ... but i didn't remember ever coming across a use for having multiple mappings of the same shared segment within the same virtual address space.
recent posts about porting virtual memory management from cp67 to
vm370
https://www.garlic.com/~lynn/2006v.html#36 Why these original FORTRAN quirks?
https://www.garlic.com/~lynn/2006w.html#7 Why these original FORTRAN quirks?
https://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?
this is recent post about an old hack for >16mbyte support in 370
https://www.garlic.com/~lynn/2006t.html#15 more than 16mbyte for 370
where i proposed temporarily stuffing a couple real page addresses into a virtual address space in order to copy from above the real "16mbyte" line to below the "16mbyte" line. in the scenario where it was purely copying a 4k virtual page ... it wasn't likely to have multiple copies. However for the scenario where data was being copied from a virtual page (above the line) into kernel working storage (below the line), and it was a multiprocessor configuration where more than one processor was attempting this; the process involved temporarily dynamically allocating two page table entries from the "system" virtual address space table ... in such a scenario if the two (or more) processors were working with different kernel working buffers that happened to be in the same real page ... then for a short period of time, the "system" virtual address space table could have had two (or more) different page table entries pointing to the same real address.
there was almost a plausable scenario in original 370 architecture where the "segment protection" (i.e. read-only, non-modifiable) was a bit in the segment table entry (i.e. the pointer to the page table for a specific segment). You could have the same (shared) segment at different virtual addresses in the same virtual address space ... where one version was "protected" and the other version was unprotected. Most threads in the address space would be accessing the r/o, protected version ... while some privilege thread might have access to the r/w, unprotected version.
the original relational/sql implementation, system/r
https://www.garlic.com/~lynn/submain.html#systemr
did something of a flavor of this ... but the "threads" were running in different virtual address spaces ... not the same virtual address space.
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 -0700Howard Brazee <howard@brazee.net> writes:
aspen got hit with some legal discovery ...
simpson of HASP fame ... misc. past posts mentioning hasp
https://www.garlic.com/~lynn/submain.html#hasp
had gone on to do something he called RASP ... sort of a page mapped VS1 system (somewhat TSS/360 like) which was eventually killed. he left and joined Amdahl in dallas and resumed the project. supposedly all new code was done in clean room ... but there was still some litigation/discovery whether aspen contained any RASP code.
i got somewhat drawn into some of the conflict between dallas/aspen and sunnyvale/gold ... and suggested why didn't they pull an SSS (a stripdown TSS kernel with Unix built on top ... done for AT&T) ... aka build unix on top of a stripped down aspen kernel.
misc. past posts mentioning aspen
https://www.garlic.com/~lynn/2000f.html#68 TSS ancient history, was X86 ultimate CISC? designs)
https://www.garlic.com/~lynn/2000f.html#69 TSS ancient history, was X86 ultimate CISC? designs)
https://www.garlic.com/~lynn/2000f.html#70 TSS ancient history, was X86 ultimate CISC? designs)
https://www.garlic.com/~lynn/2001g.html#35 Did AT&T offer Unix to Digital Equipment in the 70s?
https://www.garlic.com/~lynn/2002g.html#0 Blade architectures
https://www.garlic.com/~lynn/2002i.html#63 Hercules and System/390 - do we need it?
https://www.garlic.com/~lynn/2004q.html#37 A Glimpse into PC Development Philosophy
https://www.garlic.com/~lynn/2005p.html#44 hasp, jes, rasp, aspen, gold
https://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3
https://www.garlic.com/~lynn/2005q.html#2 Article in Information week: Mainframe Programmers Wanted
https://www.garlic.com/~lynn/2005q.html#26 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005q.html#27 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2006b.html#24 Seeking Info on XDS Sigma 7 APL
https://www.garlic.com/~lynn/2006f.html#19 Over my head in a JES exit
https://www.garlic.com/~lynn/2006f.html#26 Old PCs--environmental hazard
https://www.garlic.com/~lynn/2006i.html#0 The Pankian Metaphor
https://www.garlic.com/~lynn/2006l.html#7 Google Architecture
https://www.garlic.com/~lynn/2006m.html#30 Old Hashing Routine
https://www.garlic.com/~lynn/2006o.html#33 When Does Folklore Begin???
https://www.garlic.com/~lynn/2006q.html#32 Very slow booting and running and brain-dead OS's?
https://www.garlic.com/~lynn/2006t.html#17 old Gold/UTS reference
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.computersAnne & Lynn Wheeler wrote:
service virtual machines ...
https://www.garlic.com/~lynn/2006w.html#16 intersection between autolog command and cmsback (more history)
part of virtual machine history scenario
https://www.garlic.com/~lynn/2006w.html#22 Are hypervisors the new foundation for system software
service virtual machines are now being referred to as virtual
appliances.
https://www.garlic.com/~lynn/2006t.html#46 To RISC or not to RISC
Minor CJNTEL topic drift ...
The standard CMS "CDF" filesystem used 800byte physical blocks. My
modifications for paged mapped filesystem
https://www.garlic.com/~lynn/submain.html#mmap
left much of the "CDF" filesystem semantics alone ... but did change
the "physical" block size from 800 bytes to (page size) 4k bytes.
Most things worked correctly, but a few applications had felt
compelled to do some fiddling based on the number of physical records
(and implicit assumption the physical records were 800 bytes).
Date: 03/29/80 14:01:25
From: wheeler
what do you use for creating PACKED files??? The 191 disk for CJNTEL
is a 4k PAM disk. Vanilla release 2,3,4,5, etc programs run correctly,
only difference is the number of physical blocks allocated for a file.
Programs which use the number of physical blocks may not work
correctly .... DISK, TAPE, & VMFPLC have had to be modified.
HUFF/PUFF from YKT has not been modified and doesn't work
correctly. HUFFMOVE, VMFPLC2, COPYFILE, etc. do not use number of
physical blocks in their calculations so they work correctly.
... snip ... top of post, old email index
posting with reference to CSC "release 2" distribution system including
page mapped filesystem support
https://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?
When the CMS "EDF" filesystem appeared in release 6 ... posting
with reference to preparing a SJR "release 6" distribution system
https://www.garlic.com/~lynn/2006u.html#26 Assembler question
... I also did the modifications to map its semantics to page mapped filesystem infrastructure. The basic "EDF" filesystem offered 1k, 2k, and 4k "physical" record sizes as options. The "page mapped" mapping was to force EDF paged mapped filesystem to appear as 4k physical record size.
.... and old reference to growing acceptance of CJNTEL facility from
various places around the world
Date: 04/01/80 08:41:36
To: wheeler
Greetings from the VM ZOO
After trying CJNTEL, the whole thing makes more sense. However,
unfortunately, since we are not DIRECTLY on the U.S. tieline net, any
listings for anyone in this building, which would include many of the
Toronto people who have regular contacts with people elsewhere in the
world, will be incorrect. No-one will have much luck calling me on
xxx-xxxx unless they also know my extension, xxxx, so the call can be
transferred.
Anyhow. I gather that input to the directory is basically voluntary
(the directory we are putting online is pulled directly from the IMS
personnel DB weekly). If someone provides you with a starter file, I
would guess that a fair number of HQ and lab users would add
themselves to it. I will ask around to see if "someone" will volunteer
to assist me on it.
Our current priorities are:
1) get the Toronto directory online
2) convince HQ that there should be a Canada directory, and put it
online I have discussed the situation with the person in our dept who
is putting up the Toronto directory, and have concluded that we may
eventually
a) make a facility similar to CJNTEL (minus update capability)
available
to the world
b) investigate the possibility of CJNTEL and ours talking to each other
But first comes the Toronto directory, as an office automation
service. Managers are finally getting turned on to the idea of
screens for all the right reasons. The current schedule is that my
manager, his manager, etc all the way up to the VP level will be
online later this summer. Strangely the push is from the top down -
our VP got his end of Feb, and our director in March (plus their
secretaries of course)
P.S. what is VMSHARE LIST. Looks like interesting stuff from the
titles - are individual files available ?
... snip ... top of post, old email index
a couple recent posts mentioning vmshare:
https://www.garlic.com/~lynn/2006v.html#22 vmshare
https://www.garlic.com/~lynn/2006v.html#40 vmshare
"VMSHARE LIST" was list of new/changed vmshare computer conferencing files from the latest distribution sent to me by Tymshare.
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 -0700eugene@cse.ucsc.edu (Eugene Miya) writes:
that may have contributed to
https://www.garlic.com/~lynn/2006w.html#21 SNA/VTAM for NSFNET
and
https://www.garlic.com/~lynn/2006w.html#20 cluster-in-a-rack
actually some of the goings on mentioned in "SNA/VTAM for NSFNET" happened before my wife audited RP3 and recommended terminating RP3 funding.
misc. past posts mentioning RP3
https://www.garlic.com/~lynn/99.html#136a checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/2000c.html#6 TF-1
https://www.garlic.com/~lynn/2000d.html#27 Superduper computers--why RISC not 390?
https://www.garlic.com/~lynn/2005q.html#46 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005q.html#47 Intel strikes back with a parallel x86 design
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 -0700paul c <toledobythesea@oohay.ac> writes:
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.
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 -0700Anne & Lynn Wheeler <lynn@garlic.com> writes:
... and from long ago and far away about aspen ...
Date: 09/07/82 14:42:21
From: wheeler
talked to somebody about Amdahl RASP. IBM has had quite a large
attrition rate in the RASP group ... a large portion going to Amdahl.
... snip ... top of post, old email index
Date: 83/03/30 20:39:34
To: wheeler
I sent you a PL/AS document.
Just heard that "build order" for PCs this year (old + XT, together, I
think) is nearly xxxx.
Amdahl is apparently is about to announce his RASP look-alike... they
have already given it to a couple of customers under non-disclosure
agreements.
... snip ... top of post, old email index
Date: Wed, 11 Nov 1987 07:59:36 PST
From: wheeler
re: Amdahl unix & "RASP"; I've been saying that Amdahl's RASP system
would make a very good base kernel for their unix system (ever since
the guy from princeton that did the 370 port joined them). what i
didn't know was that simpson wasn't having anything to do with it ...
he apparently was insisting on building an mvs killer.
... snip ... top of post, old email index
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 -0700gilmap@ibm-main.lst (Paul Gilmartin) writes:
recent reference
https://www.garlic.com/~lynn/2006w.html#21 SNA/VTAM for NSFNET
there is also folklore about the outside contractor that was hired to do the vtam tcp/ip implementation.
the initial implementation benchmarked with tcp/ip running much faster than lu6.2. he was then told that the only way that tcp/ip implementation could run faster than lu6.2 was if there was a bug in the implementation ... and the project wouldn't be accepted until all bugs were fixed (including the one where tcp/ip ran much faster than lu6.2 rather than much slower than lu6.2).
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Does Public Key Authentication offer additional security over SSH/SFTP Newsgroups: comp.security.ssh Date: Wed, 13 Dec 2006 11:17:37 -0700"Marty W" <Captain.Wing@gmail.com> writes:
to top it off, the passwords are supposedly selected to be hard to
guess ... but that also tends to make them hard to remember. as a
result, it is scores of impossible to remember passwords ... leading
to frequent result that all the passwords are written down on piece of
paper ... which becomes a vulnerability in itself. misc. postings
mentioning shared-secret (pins, password, etc) issues.
https://www.garlic.com/~lynn/subintegrity.html#secrets
old 1APR password corporate directive from 1984:
https://www.garlic.com/~lynn/2001d.html#51 A beautiful morning in AFM
https://www.garlic.com/~lynn/2001d.html#52 A beautiful morning in AFM
so public key has the characteristic that the information used to originate the authentication is different from the information used to perform the authentication ... aka learning the public key doesn't imply that it is possible to fraudulent impersonate (like the case for shared-secret passwords). this eliminates the motivation for unique key for ever different security domain ... and theoretically allows for the same public key to be registered for all authentications.
old public key operation proposal from 1981
https://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network
https://www.garlic.com/~lynn/2006w.html#15 more secure communication over the network
https://www.garlic.com/~lynn/2006w.html#18 more secure communication over the network
misc. recent password news item URLs:
Successful Alternatives to Password Authentication?
http://ask.slashdot.org/askslashdot/06/11/10/2142218.shtml
Chinese malware takes aim at passwords
http://www.theinquirer.net/default.aspx?article=35909
The End of Password Post-Its
http://www.darkreading.com/document.asp?doc_id=111200
RSA Security research shows volume of business passwords overwhelming
end users and hindering IT security efforts
http://www.ameinfo.com/103400.html
Warning over use of repeat passwords
http://www.hackinthebox.org/modules.php?op=modload&name=News&file=article&sid=21901
Warning over use of repeat passwords
http://www.theage.com.au/news/security/warning-over-use-of-repeat-passwords/2006/12/03/1165080812161.html
UN warns on password 'explosion'
http://news.bbc.co.uk/2/hi/technology/6199372.stm
Warning over use of repeat passwords
http://www.linuxsecurity.com/content/view/126036/169/
Second Word Zero-day Exploit Steals Passwords
http://www.techweb.com/showArticle.jhtml?articleID=196603174
Most play poorly at the password game
http://seattlepi.nwsource.com/business/295495_password11ww.html
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Decimal FP Newsgroups: bit.listserv.ibm-main Date: Wed, 13 Dec 2006 17:10:34 -0700> I know that's what IBM says it meant. I don't believe them, I think
another reference:
http://www.dacs.org/archive/0007/feature4.htm
from above:
1) 709/1401 SPOOL system peripheral operations offline
2) 360 SPOOL system peripheral operations online
... snip ...
one might imagine that the acronym was chosen because of winding onto and off of the tape reel(?)
my 1st programming job was to port 1401 "MPIO" program to 360/30.
the 1401 was doing front end unit record to/from tape for the university's 709. they replaced the 1401 with 360/m30 which could still run the program in 1401 emulation. for whatever reason i got the job of doing a port of MPIO to native 360. I got to design and implement my own monitor, interrupt handler, storage allocation, device drivers, etc.
a few past posts mentioning MPIO
https://www.garlic.com/~lynn/95.html#4 1401 overlap instructions
https://www.garlic.com/~lynn/97.html#21 IBM 1401's claim to fame
https://www.garlic.com/~lynn/2002f.html#47 How Long have you worked with MF's ? (poll)
https://www.garlic.com/~lynn/2002q.html#29 Collating on the S/360-2540 card reader?
https://www.garlic.com/~lynn/2004f.html#49 can a program be run withour main memory?
https://www.garlic.com/~lynn/2005q.html#7 HASP/ASP JES/JES2/JES3
https://www.garlic.com/~lynn/2006b.html#2 Mount a tape
and for whatever reason, a couple of the above are the number one response when i tried search engines.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 'Innovation' and other crimes Newsgroups: alt.folklore.computers Date: Wed, 13 Dec 2006 17:25:23 -0700eugene@cse.ucsc.edu (Eugene Miya) writes:
and some additional discussion
https://financialcryptography.com/mt/archives/000808.html
in the above blog entry ... i even made some comments about mt. umunhum
which then resulted in this additional topic drift the next day here
in a.f.c
https://www.garlic.com/~lynn/2006q.html#2 Your Mother Saves Data on Eight-Track Tapes
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Decimal FP Newsgroups: bit.listserv.ibm-main Date: Thu, 14 Dec 2006 08:46:24 -0700jayarelim@ibm-main.lst (J R) writes:
another search engine reference
http://www.dacs.org/archive/0007/feature4.htm
turns up that it originally met system peripheral operations offline for 709x/1401 operations ... it supposedly morphed to simultaneous peripheral operations online for 360 ... with transition to SPOOLing being done on the same machine.
from the referenced web site:
On 7090 On 1401
Card Reader 100 cpm 800 cpm
Card Punch 100 cpm 250 cpm
Line Printer 150 lpm 600 lpm
cpm = cards per minute
lpm = lines per minute
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Top versus bottom posting was Re: IBM sues maker of Intel-based Mainframe clones Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Thu, 14 Dec 2006 10:13:26 -0700Howard Brazee <howard@brazee.net> writes:
and included a reference in the above post to an earlier post that had
some historical references
https://www.garlic.com/~lynn/2006v.html#47 Why so little parallelism?
including some stuff about the original 23jun68 unbundling
announcement was motivated by various litigation. the original
unbundling didn't included kernel software ... arguing that kernel
software would continue to be free since it was required for the
operation of the hardware. misc. posts mentioning unbundling
https://www.garlic.com/~lynn/submain.html#unbundle
as market forces changed and mainframe clone processors appeared on
the scene ... there was transition to charging for kernel software. my
resource manager got to be the guinea pig for kernel software charging
... and i got to spend some amount of time with the business people
working out policies for kernel software charging. misc. posts
mentioning dynamic adaptive scheduling, page management algorithms, etc
... some fot he stuff that was shipped in my resource manager
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock
for somewhat more convolution ... supposedly a prime motivation for
the (failed/conceled) future system project
https://www.garlic.com/~lynn/submain.html#futuresys
was clone control units. when i was undergraduate one of the projects
i worked on was a clone terminal bcontrollerb (started out using interdata/3),
in part because the 2702 wouldn't do some stuff that i wanted it to do.
later there was some article blaming four of us for (some part of) the
clone controller business. misc. past posts mentioning having worked on
clone controller
https://www.garlic.com/~lynn/submain.html#360pcm
now as to clone processors ... Amdahl gave a talk in the early 70s at MIT ... where he got a lot of questions about leaving and starting his own processor business. One of his replies was something about even if IBM were to totally walk away from 360/370 business (which could be construed as a veiled reference to the future system project) ... there was already enuf 360/370 customer application software to keep him in business thru the end of the century (possibly believing that ibm was walking away from the 360/370 business, helped motivate Amdahl to leave to build his own 360/370s?????)
... now some of the above was also my second post in the same thread
https://www.garlic.com/~lynn/2006w.html#2 IBM sues make of Intel-based Mainframe clones
so some of the archaeological references related to clone processors and the transition to licensing of kernel software have some bearing on the current subject ... and was why i had included a.f.c in the original post.
other posts related to this same thread:
https://www.garlic.com/~lynn/2006w.html#3 IBM sues maker of Intel-based Mainframe clones
https://www.garlic.com/~lynn/2006w.html#13 IBM sues maker of Intel-based Mainframe clones
https://www.garlic.com/~lynn/2006w.html#14 IBM sues maker of Intel-based Mainframe clones
https://www.garlic.com/~lynn/2006w.html#20 cluster-in-a-rack
https://www.garlic.com/~lynn/2006w.html#24 IBM sues maker of Intel-based Mainframe clones
https://www.garlic.com/~lynn/2006w.html#28 IBM sues maker of Intel-based Mainframe clones
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Top versus bottom posting was Re: IBM sues maker of Intel-based Mainframe clones Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Thu, 14 Dec 2006 10:33:42 -0700Howard Brazee <howard@brazee.net> writes:
for other drift ... bitnet (misc. posts mentioning bitnet and/or earn)
https://www.garlic.com/~lynn/subnetwork.html#bitnet
adopted some similar technology that was being used in the internal
network
https://www.garlic.com/~lynn/subnetwork.html#internalnet
the internal network was larger than the internet/arpanet from just
about the beginning until possibly sometime mid-85. misc. posts
on internet and internal network
https://www.garlic.com/~lynn/internet.htm
and old posting about the size of internal network in '83 (passing
1000 nodes) ...
https://www.garlic.com/~lynn/internet.htm#22
when the arpanet had its great conversion to internetworking protocol
at this time, arpanet had something between 100 and 255 nodes
... depending on who is counting ... misc. recent posts
https://www.garlic.com/~lynn/2006k.html#40 Arpa address
https://www.garlic.com/~lynn/2006r.html#7 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006u.html#6 The Future of CPUs: What's After Multi-Core?
now the bitnet listserv was somewhat similar to the earlier internal TOOLSRUN that operated in sort of a usenet type mode (aka local repository) but also offered mailing list mode.
TOOLSRUN was somewhat the outgrowth of lots of investigation into some emerging computer conferencing stuff that I had done ... and got blameed for something that came to be called "tandem memos" ... where i was doing semi-automated mailing list type of operation.
there was subsequently a stanford phd thesis, lots of papers, and some
books on some aspects of the subject (computer mediated conversation)
https://www.garlic.com/~lynn/subnetwork.html#cmc
a researcher was hired to set in the back of my office for nine months and take notes on how i communicated. they also got copies of all my incoming and outgoing email as well as logs of all my instant messages. this was the material that went into the stanford phd thesis as well as the other papers and books.
misc. past posts mentioning tandem memos
https://www.garlic.com/~lynn/2001g.html#5 New IBM history book out
https://www.garlic.com/~lynn/2001g.html#6 New IBM history book out
https://www.garlic.com/~lynn/2001g.html#7 New IBM history book out
https://www.garlic.com/~lynn/2001j.html#31 Title Inflation
https://www.garlic.com/~lynn/2002k.html#39 Vnet : Unbelievable
https://www.garlic.com/~lynn/2002o.html#73 They Got Mail: Not-So-Fond Farewells
https://www.garlic.com/~lynn/2002q.html#16 cost of crossing kernel/user boundary
https://www.garlic.com/~lynn/2002q.html#38 ibm time machine in new york times?
https://www.garlic.com/~lynn/2004k.html#66 Question About VM List
https://www.garlic.com/~lynn/2005c.html#50 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005d.html#37 Thou shalt have no other gods before the ANSI C standard
https://www.garlic.com/~lynn/2005q.html#5 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2006h.html#9 It's official: "nuke" infected Windows PCs instead of fixing them
https://www.garlic.com/~lynn/2006l.html#24 Google Architecture
https://www.garlic.com/~lynn/2006l.html#51 the new math: old battle of the sexes was: PDP-1
https://www.garlic.com/~lynn/2006r.html#11 Was FORTRAN buggy?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: What does a patent do that copyright does not? Newsgroups: bit.listserv.ibm-main Date: Thu, 14 Dec 2006 12:57:38 -0700charlesm@ibm-main.lst (Charles Mills) writes:
for other drift ...
in the mid-90s, the x9a10 working group was given the requirement to preserve
the integrity of the financial infrastructure for all retail payments; the
result was the x9.59 financial standard
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: What does a patent do that copyright does not? Newsgroups: bit.listserv.ibm-main Date: Thu, 14 Dec 2006 13:04:07 -0700Howard Brazee <howard@brazee.net> writes:
that was serial number in the PC ... subsequent has been TPM chip
... i gave a talk on assurance at the 2001 intel developer's conference
in the TPM track.
https://www.garlic.com/~lynn/index.html#presentation
The talk was somewhat on the aads chip strawman
https://www.garlic.com/~lynn/x959.html#aads
and the guy running tpm was in the front row ... so i somewhat facetiously quipped that it was nice to see that over the past couple years, the TPM chip design had come to look more and more like the aads chip strawman ... he quipped back that was because I didn't have a committee of 200 people helping me design a chip.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Why so little parallelism? Newsgroups: comp.arch,alt.folklore.computers Date: Fri, 15 Dec 2006 11:56:31 -0700eugene@cse.ucsc.edu (Eugene Miya) writes:
the major funding organization for RP3 was not the business machine unit ... this particular organization had been responsible for a lot of machines used in various gov. operations.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Why so little parallelism? Newsgroups: comp.arch,alt.folklore.computers Date: Fri, 15 Dec 2006 11:59:44 -0700eugene@cse.ucsc.edu (Eugene Miya) writes:
my wife's analysis of RP3 had nothing to do with 370 instruction set compatibility ... it had more to do with whether it could really achieved the scale-up being claimed .... especially in the (mostly federal) gov. market segment.
i haven't tried to do either ... i've just presented actual email exchanges from the period.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Why so little parallelism? Newsgroups: comp.arch,alt.folklore.computers Date: Fri, 15 Dec 2006 12:20:09 -0700eugene@cse.ucsc.edu (Eugene Miya) writes:
and with regard to even statement about 128 processor configuration
discussed here in a meeting in ellison's conference room
https://www.garlic.com/~lynn/95.html#13
https://www.garlic.com/~lynn/96.html#15
and
https://www.garlic.com/~lynn/2001n.html#83
here is greg pfister's comment in old post/thread that ran in
comp.arch, comp.sys.super, alt.folklore.computers
https://www.garlic.com/~lynn/2000c.html#21 Cache coherence [as re: TF-1]
Greg Pfister writes:
I never heard anybody say 128-system, and I was somewhat in the
middle of this. What I saw was that it was always intended as an
SMP replacement (yes, SMP, don't ask, some people's heads were in
a strange place then). The software bill, not the hardware, was
always the sticking point. Anyway, the SP became by definition
the "right" solution, and Live Oak was not resurrected again.
... snip ...
more in that same thread
https://www.garlic.com/~lynn/2000c.html#12 Cache coherence [as re: TF-1]
https://www.garlic.com/~lynn/2000c.html#22 Cache coherence [as re: TF-1]
the cluster-in-a-rack/MEDUSA was 32 processors in a rack ... and the discussion in the meeting in ellison's conference room was to have four rack operation (128 processors) in customer shops by ye92. this was before the project got transferred to kingston and we were told we couldn't work on systems with more than four processors.
a couple recent postings with old email discussing MEDUSA and cluster-in-a-rack
https://www.garlic.com/~lynn/2006w.html#13 IBM sues maker of Intel-based Mainframe clones
https://www.garlic.com/~lynn/2006w.html#14 IBM sues maker of Intel-based Mainframe clones
https://www.garlic.com/~lynn/2006w.html#20 cluster-in-a-rack
misc. other posts mentioning RP3
https://www.garlic.com/~lynn/99.html#136a checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/2000c.html#6 TF-1
https://www.garlic.com/~lynn/2000d.html#27 Superduper computers--why RISC not 390?
https://www.garlic.com/~lynn/2005q.html#46 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005q.html#47 Intel strikes back with a parallel x86 design
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Why so little parallelism? Newsgroups: comp.arch,alt.folklore.computers Date: Fri, 15 Dec 2006 13:06:56 -0700Anne & Lynn Wheeler <lynn@garlic.com> writes:
oh and Pfister's comment was in response to this posting earlier in the
thread
https://www.garlic.com/~lynn/2000c.html#12 Cache coherenece [was re: TF-1]
from above post:
Anne & Lynn Wheeler <lynn@garlic.com> writes:
part of the issue was that we could demonstrate 16-way and quick path
to 128-system (and above) using standard existing chips & motherboards
with interconnect fabric (even demonstrate interconnect fabric on
existing workstations in racks ... but some additional manufacturing
cost savings by packaging standard mother boards for high-density rack
mounting ... racks had to have some cooling characteristics to achieve
the high-density packaging of the mother boards).
aka cluster-in-a-rack/MEDUSA
https://www.garlic.com/~lynn/2006w.html#13 IBM sues make of Intel-based Mainframe clones
https://www.garlic.com/~lynn/2006w.html#14 IBM sues make of Intel-based Mainframe clones
https://www.garlic.com/~lynn/2006w.html#20 cluster-in-a-rack
and Greg's response from:
https://www.garlic.com/~lynn/2000c.html#21 Cache coherence [as re: TF-1]
Greg Pfister writes:
I never heard anybody say 128-system, and I was somewhat in the
middle of this. What I saw was that it was always intended as an
SMP replacement (yes, SMP, don't ask, some people's heads were in
a strange place then). The software bill, not the hardware, was
always the sticking point. Anyway, the SP became by definition
the "right" solution, and Live Oak was not resurrected again.
for other drift ... in one of the recent postings referencing
cluster-in-a-rack/MEDUSA
https://www.garlic.com/~lynn/2006w.html#14 IBM sues make of Intel-based Mainframe clones
i also mentioned at having looked at doing (relatively) high density processor
packaging in racks (for the times) in 1985
https://www.garlic.com/~lynn/2004m.html#17 mainframe and microprocessor
for the heck of it ... old email mentioning cluster-in-a-rack/MEDUSA
(from referenced posts):
https://www.garlic.com/~lynn/2006w.html#email910910
https://www.garlic.com/~lynn/2006w.html#email911014
https://www.garlic.com/~lynn/2006w.html#email911024
https://www.garlic.com/~lynn/2006w.html#email911119
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: vmshare Newsgroups: alt.folklore.computers Date: Fri, 15 Dec 2006 16:01:42 -0700re:
there is thread running in bit.listserv.ibm-main about convention buttons ... so i thot i would check old vmshare archive ... which leads to lots of topic drift
an old vmshare button ref from 1984
http://vm.marist.edu/~vmshare/browse.cgi?fn=BUTTON62&ft=MEMO
and old vmshare humor reference including some references to buttons
http://vm.marist.edu/~vmshare/browse.cgi?fn=HUMOR&ft=MEMO
for some additional drift, the above has a reference from net.speak,
including:
PROFS Professional Office System. An IBM calendar and email program
that runsin a VM environment. PROFS came to national attention
during the Iran-Contra when it was learned that Oliver North and
his associates communicated using PROFS email, unwittingly
leaving an electronic trail of their strategems. North thought he
had erased all incriminating email messages, but had not, in fact,
eradicated all vestiges of his online communications.
... snip ...
I was a very strong proponent of repeated backup/archives.
I had done the CMSBACK design, implementation and deployment, a few
recent references
https://www.garlic.com/~lynn/2006t.html#20 Why these original FORTRAN quirks?; Now : Programming practices
https://www.garlic.com/~lynn/2006t.html#24 CMSBACK
https://www.garlic.com/~lynn/2006t.html#33 threads versus task
https://www.garlic.com/~lynn/2006u.html#19 Why so little parallelism?
https://www.garlic.com/~lynn/2006u.html#26 Assembler question
https://www.garlic.com/~lynn/2006u.html#30 Why so little parallelism?
https://www.garlic.com/~lynn/2006v.html#24 Z/Os Storage Mgmt products
https://www.garlic.com/~lynn/2006w.html#16 intersection between autolog command and cmsback (more history)
as well as some number of collected posts mentioning backup/archive
https://www.garlic.com/~lynn/submain.html#backup
I had backups of stuff from the 60s (at the univ.) and the 70s (from
the science center). However, I've mentioned before that these were
wiped out in the almaden tape library. for a time they had a problem with
operations randomly pulling tapes from the library for scratch tapes.
a couple past refs:
https://www.garlic.com/~lynn/2003i.html#13 A Dark Day
https://www.garlic.com/~lynn/2003j.html#14 A Dark Day
https://www.garlic.com/~lynn/2003j.html#45 Hand cranking telephones
https://www.garlic.com/~lynn/2003m.html#12 Seven of Nine
https://www.garlic.com/~lynn/2004b.html#59 A POX on you, Dennis Ritchie!!!
I eventually got a list of about 50 of my tapes that had been wiped out in this manner ... including the following
001018 10FILES, CP/67 SOURCE & SYSTEM 001381 8FILES, CAMBRIDGE WHEELER ARCHIVE 001642 8FILES, CMS SYSTEM & MY FILES 001720 8FILES, RESOURCE MANAGER 3.7, CMS, MISC 001822 10FILES, CP/67 SOURCE & SYSTEM 001954 1FILE, RESOURCE MANAGER 3.4 LISTINGS 002090 10FILES, CP/67 SOURCE & SYSTEM 002826 1FILE, CP2.0 SOURCE 004376 5FILES, CSC/VM 2.15 + LOCAL 004789 8FILES, CAMBRIDGE ARCHIVEall three duplicate tapes (#1018, #1822, #2090) with cp/67 source & system managed to get wiped
other drift ... recent reference to CSC/VM 2.15 (distribution) system
https://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?
about the only thing that survived was some of the original CMS (cp/67)
multi-level source processes; Melinda had contacted me about the availability
of such files
https://www.leeandmelindavarian.com/Melinda#VMHist
in the following email, Melinda (also) makes reference to VMSHARE/PCSHARE being moved off Tymshare (i.e. this was in period that M/D bought Tymshare) to McGill ... and Melinda would start being responsible for mailing me a monthly tape of the VMSHARE/PCSHARE files (so i could put them up at various locations on the internal network).
from long ago and far away
Date: Fri, 6 Sep 1985 16:47:51 EDT
From: Melinda
To: wheeler
Lynn, thank you for your note (via Pat) giving your recollections of
the origin of the multi-level update facility. I am really enjoying
piecing all this together.
Ever since I got your note, I've been puzzling over what you meant by
the "'$' stuff". I've finally concluded that the CMS-360 UPDATE must
have required sequence numbers in the sequence number columns of the
card images being inserted into a file. The preprocessor you
mentioned must have filled in sequence numbers with appropriate
increments, as UPDATE does today when there is a dollar sign in the ./
I or ./ R statements.
Is that correct?
Thanks again for your help,
Melinda
P.S.: The paper I'm working on is to be presented at SEAS later this
month. You won't be getting a VMSHARE/PCSHARE tape from me
until I get back from SEAS at the end of the month.
... snip ... top of post, old email index
for more drift, I was somewhat involved in M/D purchase of Tymshare. As part of the purchase M/D was spinning off some number of pieces of Tymshare ... including GNOSIS ... which became KEYKOS. I was brought in to do an audit of GNOSIS as part of the spinoff.
a couple recent posts mentioning GNOSIS and/or KEYKOS
https://www.garlic.com/~lynn/2006k.html#37 PDP-1
https://www.garlic.com/~lynn/2006m.html#34 PDP-1
https://www.garlic.com/~lynn/2006p.html#13 What part of z/OS is the OS?
https://www.garlic.com/~lynn/2006s.html#7 Very slow booting and running and brain-dead OS's?
and more email about multi-level update process ....
Date: Sun, 8 Sep 1985 14:10:41 EDT
From: Melinda
To: wheeler
Lynn, I was truly touched by your having spent part of your Saturday
morning loading up those CP-67 EXECs for me. It was extraordinarily
thoughtful of you and has helped me answer almost all of my questions
about the CP-67 implementation.
I have been working my way through the EXECs and believe that I have
them all deciphered now. I was somewhat surprised to see how much of
the function was already in place by the Summer of 1970. In
particular, I hadn't expected to find that the update logs were being
put at the beginning of the textfiles. That has always seemed to me
to be one of the most ingenious aspects of the entire scheme, so I
wouldn't have been surprised if it hadn't been thought of right away.
One thing I can't determine from reading the EXECs is whether the
loader was including those update logs in the loadmaps. Do you
recall?
Of the function that we now associate with the CTL option of UPDATE,
the only substantial piece I see no sign of in those EXECs is the use
of auxfiles. Even in the UPAX EXEC from late January, 1971, it is
clear that all of the updates listed in the control files were
expected to be simple updates, rather than auxfiles. I know, however,
that auxfiles were fully implemented by VM/370 Release 1. I have a
First Edition of the "VM/370 Command Language User's Guide" (November,
1972) that describes them. The control file syntax at that point was
updlevel upid AUX
Do you have any memories of the origin of auxfiles?
Thank you again,
Melinda
... snip ... top of post, old email index
for some drift about "auxfiles" the VM development group added auxfile support to the multi-level source update infrastructure (developed by the science center) to handle "PTFs". The multi-level source update had been originally targeted at handling various source level updates (cp67 local, H, I, updates, etc mentioned in past posts). "PTFs" were were specific "bug" fixes ... which might be as little as a single source update with a single instruction change.
in any case, a couple months after the above emails, research moved
into the new almaden facility and later there were the problems with
allocated tapes being mounted as scratch ... recent post with
reference to moving into the new research facility
https://www.garlic.com/~lynn/2006v.html#34 vmshare
CSC/VM posts
https://www.garlic.com/~lynn/submisc.html#cscvm
misc. past posts mentioning PROFS:
https://www.garlic.com/~lynn/2000c.html#46 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2001k.html#35 Newbie TOPS-10 7.03 question
https://www.garlic.com/~lynn/2001k.html#39 Newbie TOPS-10 7.03 question
https://www.garlic.com/~lynn/2001k.html#40 Newbie TOPS-10 7.03 question
https://www.garlic.com/~lynn/2002h.html#58 history of CMS
https://www.garlic.com/~lynn/2002h.html#59 history of CMS
https://www.garlic.com/~lynn/2002h.html#64 history of CMS
https://www.garlic.com/~lynn/2002i.html#50 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002j.html#4 HONE, ****, misc
https://www.garlic.com/~lynn/2002p.html#34 VSE (Was: Re: Refusal to change was Re: LE and COBOL)
https://www.garlic.com/~lynn/2003b.html#45 hyperblock drift, was filesystem structure (long warning)
https://www.garlic.com/~lynn/2003e.html#69 Gartner Office Information Systems 6/2/89
https://www.garlic.com/~lynn/2003j.html#56 Goodbye PROFS
https://www.garlic.com/~lynn/2003m.html#26 Microsoft Internet Patch
https://www.garlic.com/~lynn/2004p.html#13 Mainframe Virus ????
https://www.garlic.com/~lynn/2005t.html#43 FULIST
https://www.garlic.com/~lynn/2006n.html#23 sorting was: The System/360 Model 20 Wasn't As Bad As All That
https://www.garlic.com/~lynn/2006q.html#4 Another BIG Mainframe Bites the Dust
misc. past posts mentioning cms update command and multi-level source
management
https://www.garlic.com/~lynn/2000b.html#80 write rings
https://www.garlic.com/~lynn/2001e.html#57 line length (was Re: Babble from "JD" <dyson@jdyson.com>)
https://www.garlic.com/~lynn/2001g.html#46 The Alpha/IA64 Hybrid
https://www.garlic.com/~lynn/2002h.html#67 history of CMS
https://www.garlic.com/~lynn/2002n.html#39 CMS update
https://www.garlic.com/~lynn/2002n.html#73 Home mainframes
https://www.garlic.com/~lynn/2002p.html#2 IBM OS source code
https://www.garlic.com/~lynn/2003.html#58 Card Columns
https://www.garlic.com/~lynn/2003e.html#38 editors/termcap
https://www.garlic.com/~lynn/2003e.html#66 History of project maintenance tools -- what and when?
https://www.garlic.com/~lynn/2003f.html#1 History of project maintenance tools -- what and when?
https://www.garlic.com/~lynn/2003h.html#12 Do Data Models Need to built on a Mathematical Concept?
https://www.garlic.com/~lynn/2003k.html#47 Slashdot: O'Reilly On The Importance Of The Mainframe Heritage
https://www.garlic.com/~lynn/2003l.html#17 how long does (or did) it take to boot a timesharing system?
https://www.garlic.com/~lynn/2004b.html#59 A POX on you, Dennis Ritchie!!!
https://www.garlic.com/~lynn/2004d.html#69 A POX on you, Dennis Ritchie!!!
https://www.garlic.com/~lynn/2004g.html#43 Sequence Numbbers in Location 73-80
https://www.garlic.com/~lynn/2004g.html#44 Sequence Numbbers in Location 73-80
https://www.garlic.com/~lynn/2004h.html#27 Vintage computers are better than modern crap !
https://www.garlic.com/~lynn/2004m.html#30 Shipwrecks
https://www.garlic.com/~lynn/2004o.html#18 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2004o.html#21 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2004o.html#36 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2004p.html#53 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2005i.html#30 Status of Software Reuse?
https://www.garlic.com/~lynn/2005i.html#39 Behavior in undefined areas?
https://www.garlic.com/~lynn/2005m.html#38 Massive i/o
https://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3
https://www.garlic.com/~lynn/2005r.html#5 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005r.html#6 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2006.html#28 DCSS as SWAP disk for z/Linux
https://www.garlic.com/~lynn/2006b.html#10 IBM 3090/VM Humor
https://www.garlic.com/~lynn/2006e.html#7 About TLB in lower-level caches
https://www.garlic.com/~lynn/2006f.html#5 3380-3390 Conversion - DISAPPOINTMENT
https://www.garlic.com/~lynn/2006f.html#21 Over my head in a JES exit
https://www.garlic.com/~lynn/2006f.html#38 Over my head in a JES exit
https://www.garlic.com/~lynn/2006n.html#45 sorting
https://www.garlic.com/~lynn/2006o.html#14 SEQUENCE NUMBERS
https://www.garlic.com/~lynn/2006o.html#19 Source maintenance was Re: SEQUENCE NUMBERS
https://www.garlic.com/~lynn/2006q.html#45 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006t.html#24 CMSBACK
https://www.garlic.com/~lynn/2006u.html#26 Assembler question
https://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM sues maker of Intel-based Mainframe clones Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Fri, 15 Dec 2006 17:06:46 -0700sidd@situ.com () writes:
for some more EARN-specific (european version of bitnet)
for other drift, the last paragraph refers to a deal where we were exchanging offspring for the summer, one of mine for one of his (and possibly one of his friends).
note: Erich Bloch was director of the National Science Foundation for
much of the 80s.
Date: 7 June 1985, 16:28:41
To: wheeler
I basically agree with your proposal to present to the EARN board as
suggested by Dennis Jennings (who was the EARN BoD chairman last year)
I have a lot of papers on HSDT, but could you please send me a copy of
the presentation you made to Erich Bloch and Dennis Jennings together
with some more detailed information you may have (I understand that
the details are still confidential, so the presentation does not
probably tell too much...).
Before taking a final decision, I have to talk to my boss, who will
certainly agree, and I would like to have your input to give him a
good view.
A possibility would be to spend few hours at the beginning of your
stay, either to brief the EARN chairman and few interested people, or
to give a broader talk to the EARN Board of Directors who is meeting
on July 25 26 in Sweden.(By the way, David Lord, the EARN chairman is
from CERN).
Have you some news for the friend of Thomas? they are both very
anxious, and he will be very disappointed if he cannot go... If it
works, I assume it will be an exchange?
... snip ... top of post, old email index, NSFNET email
lots of past posts mentioning HSDT
https://www.garlic.com/~lynn/subnetwork.html#hsdt
another posting with some old (EARN) email from 20mar84
https://www.garlic.com/~lynn/2001h.html#65
recent post containing old email putting in a connection between BITNET
https://www.garlic.com/~lynn/2006t.html#43
and VNET, the internal corporate network
https://www.garlic.com/~lynn/subnetwork.html#internalnet
and a couple other related postings touching on some of the subject:
https://www.garlic.com/~lynn/2006s.html#50
https://www.garlic.com/~lynn/2006t.html#6
and collected posts mentioning bitnet &/or earn
https://www.garlic.com/~lynn/subnetwork.html#bitnet
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: more secure communication over the network Newsgroups: alt.folklore.computers Date: Fri, 15 Dec 2006 18:41:13 -0700recent posts mentioning CJNTEL:
The following is a little difference of opinion about the internal
CJNTEL vis-a-vis the internal TELE ... as if it was either/or (aka
CJNTEL was upgraded in the late 70s to support queries for both
the CJNTEL file as well as the TELE phone books).
Date: 09/09/85 11:50:09
To: wheeler
CC: ????
From the latest issue of CSNET news, Summer '85... There is an article
by Peter Denning, Chairman of the CSNET Executive Committee... Under
the heading "Lessons for the Future" is included the following
paragraph. Seems to me to describe the CJNTEL PHONE experience very
well...
"* The concept of a user-managed name server does not work as well as
we had hoped. We had originally thought that the CSNET Name
Server's entries would be separately managed and kept up to date by
the users. This has not happened. Users move, change mailboxes,
and shift their research interests without notifying the Name
Server. Thus much of the infolrmation in that database is
unreliable. The Executive Committee has recently instructed the
CIC (Coordination and Information Center of CSNET, managed by BBN,
Bolt, Beranek and Newman) to manage the Name Server so as to
achieve a high degree of reliability in its contents. It turns out
that most users have been unaffected by the Name Server because it
is basically interactive and thus likely to be used only by the
ARPANET and X.25 sites. We expect that the new dial-in line to the
Name Server will mitigate this. We are committed to increasing the
utility of the Name Server for all CSNET members."
... snip ... top of post, old email index
Date: 9 September 1985, 09:15:29 PDT
To: ???
CC: wheeler
Subject: CJNTEL
The article you reference is a bad analogy because the TELE
directories are an incomplete replacement for CJNTEL. The TELE
directories do not contain all of the addresses in our network. The
CJNTEL system covered all addresses by allowing anyone to add to its
directory. There is no mechanism with the TELE directories for a user
that is not mentioned in a TELE directory to post his or her network
address. The CSNET article does indicate that they are managing a
Name Server that does cover all addresses in their network.
It was a bad decision to remove the CJNTEL system before a substitute
could be constructed for those who are not covered by TELE
directories. Your reference to the CSNET article does not hide this
fact. It only shows that CSNET made a better decision.
... snip ... top of post, old email index
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: secure payment method Newsgroups: microsoft.public.security Date: Sat, 16 Dec 2006 10:03:15 -0700madcaplost <madcaplost@discussions.microsoft.com> writes:
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The Future of CPUs: What's After Multi-Core? Newsgroups: alt.folklore.computers Date: Sat, 16 Dec 2006 10:11:31 -0700Anne & Lynn Wheeler <lynn@garlic.com> writes:
At SIGOPS (Asilomar, 14-16Dec81), I was asked by Jim Gray if I could
help a co-worker concerning problem he was having getting his PHD from
Stanford. Jim had been at SJR and worked on the original
relational/sql database, System/R (before leaving for Tandem)
https://www.garlic.com/~lynn/submain.html#systemr
and was aware of the work that I had done in numerous aspects of
virtual memory management; in fact, some of the System/R
implementation was based on that work. recent reference
https://www.garlic.com/~lynn/2006w.html#11
The PHD research was on global LRU page replacement algorithms
(something I had implemented for CP67 as an undergraduate in the
60s). There were extremely strenuous objections from proponents of
local LRU page replacement algorithms that any PHD should be granted
on research into global LRU page replacement algorithms.
October 19, 1982
xxxxxxxx
Tandem Computers
19333 Vallco Parkway
Cupertino, CA 95014
Dear xxxxxx:
Sorry to have taken so long to reply concerning your doctoral thesis.
Enclosed is a brief description of several related CP paging matters
that I've been involved with since 1968. There is a great deal of
similarity between what I had implemented against a CP/67 base and
your WSClock algorithm.
In the description, CORTABLE is referred to frequently. There is one
CORTABLE entry for each real storage page. The CORTABLE entry contains
is used to maintain the current status for each page. The CORTABLE is
one contiguous block of real storage containing all CORTABLE entries.
Of particular interest is the fact that the Working Set Dispatcher as
implemented by the Grenoble Scientific Center against the same base
code actually performed poorer than the algorithm I designed and
implemented (as far as I know, I currently have the only complete copy
of both sets of code modifications and the associated benchmark
information), dispite the fact the Grenoble machine had approximately
160 pageable pages and the Cambridge machine typically had around 105
pageable pages. This design and implementation was released as part
of the CP/67 product. Essentially a very similar implementation
exists in the current VM/370 (or VM/SP) product (even though the
design is from the 60s). I'm attaching two unclassified research
reports, VM/370 Modifications (RJ2906) and VM/370 Shared Modules
(RJ2928). These reports describe several associated paging system
enhancements and give further detail concerning the N.5 page
replacement algorithm
Hopefully, the enclosed descriptions will prove helpful, especially in
your discussions with Peter Denning.
Sincerely,
Lynn Wheeler
Attachment
... snip ... top of post, old email index
as mentioned recently, I lost quite a bit of historical information
from the 60s and early 70s when numerous tapes were wiped because of
problems in Almaden operations
https://www.garlic.com/~lynn/2006w.html#42
The global LRU work had been released in cp67 and then dropped in the
initial morph from cp67 to vm370. I was able to re-introduce the
implementation into vm370 with my resource manager
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock
recent posts mentioning port of various pieces from cp67 to vm370
https://www.garlic.com/~lynn/2006v.html#36
https://www.garlic.com/~lynn/2006w.html#7
https://www.garlic.com/~lynn/2006w.html#8
There was another issue at work here, while I was originally asked at SIGOPS (14-16Dec81) if I could lend some aid in countering the objections about whether a PHD should be granted for research into global LRU page replacement algoritms, I wasn't permitted to send a reply until Oct82 (almost a year later).
As mentioned here
https://www.garlic.com/~lynn/2006w.html#35
I had gotten blamed for something that had gotten the label "Tandem Memos". Somewhat as a result, I was told that my external communication had to have prior approval from executives and legal. It took ten months to get the approval to send the above letter.
misc other posts this year discussing some of the global/local LRU
issues:
https://www.garlic.com/~lynn/2006e.html#7 About TLB in lower-level caches
https://www.garlic.com/~lynn/2006e.html#37 The Pankian Metaphor
https://www.garlic.com/~lynn/2006f.html#0 using 3390 mod-9s
https://www.garlic.com/~lynn/2006i.html#31 virtual memory
https://www.garlic.com/~lynn/2006i.html#36 virtual memory
https://www.garlic.com/~lynn/2006i.html#37 virtual memory
https://www.garlic.com/~lynn/2006i.html#42 virtual memory
https://www.garlic.com/~lynn/2006j.html#1 virtual memory
https://www.garlic.com/~lynn/2006j.html#17 virtual memory
https://www.garlic.com/~lynn/2006j.html#25 virtual memory
https://www.garlic.com/~lynn/2006l.html#14 virtual memory
https://www.garlic.com/~lynn/2006q.html#19 virtual memory
https://www.garlic.com/~lynn/2006q.html#21 virtual memory
https://www.garlic.com/~lynn/2006r.html#34 REAL memory column in SDSF
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 'Innovation' and other crimes Newsgroups: alt.folklore.computers Date: Sat, 16 Dec 2006 11:04:17 -0700"Charlie Gibbs" <cgibbs@kltpzyxm.invalid> writes:
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: vmshare Newsgroups: alt.folklore.computers Date: Sat, 16 Dec 2006 11:12:35 -0700re:
from long ago and far away, more on multi-level source update
Date: 09/06/85 14:45:21
From: wheeler
To: melinda
re: $; update only required that the source file have sequence numbers
in order to apply the ./ D-R-I parameters. Update didn't require that
any inserted lines also have appropriate sequence numbers. By
convention (prior to cascading updating), it was usual that the
resulting source have all valid sequence numbers (in many cases
inforced by a assembler ISEQ statement). Frequently it was the policy
that an update deck be applied "permenantly" to an assembler deck ...
to become a new "base" ... using a combination of the original source
deck and the update deck sequence nos. In some sense this could be
considered "cascading update" procedure ... however the interval
between update application spanned several weeks/months rather than
seconds or milliseconds.
... snip ... top of post, old email index
as mentioned elsewhere, when i was undergraduate in the 60s, i had originally written an (CMS) UPDATE pre-processor (that implemented the "$" convention for generation of sequence numbers)
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Year-end computer bug could ground Shuttle Newsgroups: alt.folklore.computers Date: Sat, 16 Dec 2006 11:52:36 -0700greymaus writes:
that i found here
http://virus.stanford.edu/uda/
some (us) stats from above
http://virus.stanford.edu/uda/flustat.html
as soon as my father was of age, he joined up and was shipped to europe, but it was rather late in the war. i don't remember him mentioning having been hit with the flu while in europe ... or after he was shipped back home.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Does Public Key Authentication offer additional security over SSH/SFTP Newsgroups: comp.security.ssh Date: Sat, 16 Dec 2006 15:45:09 -0700Darren Tucker <dtucker@gate.dtucker.net> writes:
was demo'ing private key file cracks at rsa '98 ... avg. time was something like 30 seconds. they showed lots of vulnerabilities that attackers (not just root) could obtain/harvest files off of PCs. they also demo'ed a countermeasure that it made it significantly more difficult for an attacker doing brute force attack on private key file.
at the time, some were expecting that chip-based containers (for private keys) were just momentarily around the corner ... and the private key file scenarios were supposedly just emulating real chip containers (pending the availability of the real thing).
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Year-end computer bug could ground Shuttle Newsgroups: alt.folklore.computers Date: Sat, 16 Dec 2006 16:00:35 -0700Andrew Swallow <am.swallow@btopenworld.com> writes:
i mentioned in the post that flu pandemic killed more people than ww1
https://www.garlic.com/~lynn/2006q.html#61 Wars and Allies
and what is mentioned in the reference here
http://virus.stanford.edu/uda/
here is picture of my mother's father (and his brother) taken in
montana or wyoming (he's the one on the left, 6-6 and over 300)
... century ago
https://www.garlic.com/~lynn/grandpa.jpg
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM sues maker of Intel-based Mainframe clones Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Sun, 17 Dec 2006 15:25:36 -0700note, something of an aside ... in hsdt
we had a number of communication things going on simultaneously
.... there was the internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet
similar technology was being used in bitnet & earn
https://www.garlic.com/~lynn/subnetwork.html#bitnet
we were also in networking technology involving tcp/ip, the internet and the nsfnet backbone; some of this had nothing to do with mainframes and some of it overlapped with mainframes and/or bitnet/earn activities.
tcp/ip overlapping with mainframes ... i had done the rfc 1044
implementation for the mainframe tcp/ip support
https://www.garlic.com/~lynn/subnetwork.html#1044
the base support got around 44kbytes/sec using a 3090 processor ... the 1044 support in some tuning tests at cray research was getting 1mbyte/sec thruput between a cray machine and a 4341-clone ... using only a modest amount of the 4341-clone.
there has been several recent posts mentiong various aspects of the
nsfnet backbone activity ... which can be considered the "operational"
precursor to the modern internet
https://www.garlic.com/~lynn/subnetwork.html#internet
some recent posts about various nsfnet backbone related activity
https://www.garlic.com/~lynn/2006s.html#50 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006s.html#51 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006t.html#6 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006t.html#36 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006u.html#55 What's a mainframe?
https://www.garlic.com/~lynn/2006u.html#56 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006v.html#30 vmshare
https://www.garlic.com/~lynn/2006w.html#21 SNA/VTAM for NSFNET
https://www.garlic.com/~lynn/2006w.html#26 Why so little parallelism?
https://www.garlic.com/~lynn/2006w.html#29 Descriptive term for reentrant program that nonetheless is
https://www.garlic.com/~lynn/2006w.html#38 Why so little parallelism?
https://www.garlic.com/~lynn/2006w.html#39 Why so little parallelism?
https://www.garlic.com/~lynn/2006w.html#43 IBM sues maker of Intel-based Mainframe clones
hsdt project also got involved with attempting to take some technology
developed by one of the baby bells and turn it out as a product ...
using real "peer-to-peer" networking ... but being able to simulate
sna/vtam at the boundaries, a few recent posts referencing the activity:
https://www.garlic.com/~lynn/2006r.html#4 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006v.html#30 vmshare
https://www.garlic.com/~lynn/2006v.html#34 vmshare
... however, some additional drift on internal network, SMSG and service virtual machines
recent posts
https://www.garlic.com/~lynn/2006k.html#51 other cp/cms history
https://www.garlic.com/~lynn/2006p.html#10 What part of z/OS is the OS?
https://www.garlic.com/~lynn/2006t.html#45 To RISC or not to RISC
https://www.garlic.com/~lynn/2006t.html#46 To RISC or not to RISC
https://www.garlic.com/~lynn/2006t.html#47 To RISC or not to RISC
https://www.garlic.com/~lynn/2006v.html#22 vmshare
https://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?
https://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network
https://www.garlic.com/~lynn/2006w.html#16 intersection between autolog command and cmsback (more history)
https://www.garlic.com/~lynn/2006w.html#25 To RISC or not to RISC
https://www.garlic.com/~lynn/2006w.html#44 more secure communication over the network
following section from old RSCS command document describing an API for
rscs/vnet:
July 1986
+----------------------------------------------------------------------+ | | | Issue command: CP SMSG RSCS (T.FRANKG) CPQ T | | | | Results in SMSGs back which look like: | | | | RSCS 0172 0001 FRANKG CPQ: TIME IS 12:34:44 etc. | | RSCS 0172 0002 FRANKG CPQ: CONNECT= 02:33:22 etc. | | RSCS 0001 0003 FRANKG End of command response | | | | Figure 23. Example of API Command and Responses | | | +----------------------------------------------------------------------+You may trap these SMSG responses with any tools you like. The following REXX EXEC will trap these SMSGs and make them available to the EXEC for parsing. This code is presented as an example of what might be done and is not meant as an endorsement of one tool over another. Please use whatever tool best meets your needs.
/*REXX fragment to trap SMSGs and write them to the terminal */
Do Forever
'WAKEUP 23:59:59 (SMSG)' /* Wait for an SMSG */
Parse Pull junk uid text /* Get text from RSCS */
If uid='RSCS' | uid='PVM' Then Do /* Asynchronous msg */
Parse Var text kind msgnum seqnum node signat text
Say kind 'msg received from node' node'. Msg number='msgnum'.'
Say 'Signature="'signat'". Text="'text'".'
End
Else Do /* SMSG was not from RSCS or PVM */
Say 'SMSG received from 'uid'. Text="'text'".'
End
End
... snip ...