List of Archived Posts

2007 Newsgroup Postings (01/01 - 01/07)

Securing financial transactions a high priority for 2007
"The Elements of Programming Style"
"The Elements of Programming Style"
The Future of CPUs: What's After Multi-Core?
DOS C prompt in "Vista"?
Securing financial transactions a high priority for 2007
Securing financial transactions a high priority for 2007
SSL info
"The Elements of Programming Style"
"The Elements of Programming Style"
moving on
vm/sp1
"The Elements of Programming Style"
"The Elements of Programming Style"
vm/sp1
SSL info
How many 36-bit Unix ports in the old days?
SSL info
IBM sues maker of Intel-based Mainframe clones
NSFNET (long post warning)
MS to world: Stop sending money, we have enough - was Re: Most ... can't run Vista
DOS C prompt in "Vista"?
MS to world: Stop sending money, we have enough - was Re: Most ... can't run Vista
How to write a full-screen Rexx debugger?
How to write a full-screen Rexx debugger?
The History of Computer Role-Playing Games
MS to world: Stop sending money, we have enough - was Re: Most ... can't run Vista
Securing financial transactions a high priority for 2007
Securing financial transactions a high priority for 2007
Just another example of mainframe costs
V2X2 vs. Shark (SnapShot v. FlashCopy)
V2X2 vs. Shark (SnapShot v. FlashCopy)
V2X2 vs. Shark (SnapShot v. FlashCopy)
Just another example of mainframe costs
SSL info
V2X2 vs. Shark (SnapShot v. FlashCopy)
How many 36-bit Unix ports in the old days?
How many 36-bit Unix ports in the old days?
How many 36-bit Unix ports in the old days?
Just another example of mainframe costs
How many 36-bit Unix ports in the old days?
RTFM - IETF RFCs
The logic of privacy
SSH protocol analyzer
vm/sp1
Just another example of mainframe costs
How many 36-bit Unix ports in the old days?

Securing financial transactions a high priority for 2007

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Mon, 01 Jan 2007 13:15:45 -0700
krw <krw@att.bizzzz> writes:
Yep. Google "Check-21". I've gone into stores where they took my check, scanned it, and handed it back to me. Scary, but no more so than having a hundred clerks handle my check. With the routing and account numbers the account is wide open. ...always has been.

No, I'm not afraid of debit cards, though I never use them on-line.


re:
http://www.garlic.com/~lynn/2006y.html#7 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2006y.html#8 Securing financial transactions a high priority for 2007

most debit cards can now be used in either PIN-mode or signature-mode (i.e. if they have the association "bug" or "logo" on the card). the vulnerability is if the magstripe is skimmed ... then the counterfeit card can be used in signature-mode (similar to credit card) w/o requiring pin (and typically w/o some of the same protections that credit cards have). same applies if such a debit card is lost or stolen. you typically have to specially request a debit card that can only be used in pin-mode (and not also be usable in PIN-less signature debit mode).

also credit card magstripe technology had gone thru something of an evolution. early exploit was to take an account number (or even guess at an account number using some known rules about account number validity checking) and generate a counterfeit magstripe from scratch.

a secure hash code was added to credit card magstripes as a countermeasure for such exploits (basically combination of a bank secret plus account number and misc. other details ... not obviously derivable from having an account number).

to large extent, the original PIN-debit didn't view it really necessary to do similar magstripe protection because they had "real" two-factor authentication: card/magstripe as something you have and PIN as something you know. Generating a magstripe from scratch with some account number wasn't sufficient to do a fraudulent transaction since a PIN was also required.

in the past year or so, there have been some association articles deploring the lack of secure hash on debit magstripes ... since PIN-less signature-debit operation are now subject to some of the similar vulnerabilities as credit ... and to some extent the associations had promoted the PIN-less, signature-debit ... w/o requiring that (PIN-less) debit card magstripe technology was at least equivalent to credit (originally believing that PIN requirement was sufficient countermeasure to such exploits).

as previously mentioned a number of times, we were asked to consult with small client/server startup that wanted to do payment transactions.
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

which has since come to be called e-commerce. existing consumer protection credit card rules were leveraged related to "card-not-present" and "cardholder-not-present" (i.e. remote not-face-to-face transactions that had original been created for "MOTO" ... aka mail-order/telephone-order).

after that we did some work in the X9A10 financial standard working group which had been given the requirement (for a protocol) in the mid-90s to preserve the integrity of the financial infrastructure for all retail payments.
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

one of the things that we looked at was the growing "skimming" vulnerabilities ... valid magstripes were recorded and used to create counterfeit cards with correct magstripes (and since the secure hash was static data, it was being recorded right along with the rest of a valid magstripe information for use in creating duplicate magstripes).
http://www.garlic.com/~lynn/subintegrity.html#harvest
http://www.garlic.com/~lynn/subintegrity.html#secrets

about the same time the X9A10 work began ... there was a different effort begun specifically for a chip-based payment card. the deployments so far have basically had the chip regurgitate effectively a slightly enhanced version of the information on a magstripe. This chip also required the entry of an associated PIN ... supposedly resulting in two-factor authentication ... chip as something you have authentication and PIN as something you know authentication.

However, these deployments resulted in the yes card exploit/vulnerability
http://www.garlic.com/~lynn/subintegrity.html#yescard

The chip authentication is static data that is very similar to what might be found on a magstripe. Some of the infrastructure used for skimming/recorded magstripe information turned out to also be able to skim/record chip authentication information.

The attackers then installed the authentication information in counterfeit yes cards. The terminal/chip protocols have been such that once the terminal had authenticated a chip ... the terminal would then asked the chip a number of questions: a) was the correct PIN entered, b) should the transaction be performed offline, c) is the transaction with the account's credit limit

The counterfeit yes cards are programmed to always answer YES (given rise to the yes card label). Theoretically a valid PIN was required for such an operation (resulting in two factor authentication), but since counterfeit yes cards always answered YES (regardless of what PIN is entered) ... any assumptions about multi-factor authentication is negated (it is not necessary to know the correct PIN to use a counterfeit yes card for fraudulent transactions).

Furthermore, one of the countermeasures to various card exploits has been doing "online" transactions and reporting account problems and having the card's number flagged/de-activated. However, that is dependent on the transactions being done online. In the yes card case, the terminal is always instructed to perform an "offline" transaction, negating the benefit of online transaction account flagging.

"The Elements of Programming Style"

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "The Elements of Programming Style"
Newsgroups: alt.folklore.computers
Date: Mon, 01 Jan 2007 15:37:22 -0700
Anne & Lynn Wheeler <lynn@garlic.com> writes:
there was some attempt to do a cms-like implementation on PCs in the early 80s ... as well as straight vm/cms as xt/370 ... both the cms-like and xt/370 suffered greatly on the PC platforms in the early to mid-80s. cms-like and xt/370 tended to be much more disk intensive than the PC applications of the period ... and the disks were 10-20 times slower than their mainframe counterparts. the interactive pc applications of the period were usually carefully tailored to the available PC resources/hardware. as a result, cms-like and xt/370 genre failed to catch on (although some number of the cms personal applications were rewritten for pc environment and found uptake).

re:
http://www.garlic.com/~lynn/2006y.html#29 "The Elements of Programming Style"

reference to some CMS applications adapted to pc environment by "XXXXXX" (in the following old email), he adapted flavors of some CMS applications for the TRS80 ... which later were available on IBM/PC. misc. related posts:
http://www.garlic.com/~lynn/2002o.html#66 Defeating telemarketers
http://www.garlic.com/~lynn/2004.html#5 The BASIC Variations
http://www.garlic.com/~lynn/2004l.html#74 Specifying all biz rules in relational data
http://www.garlic.com/~lynn/2004m.html#20 Whatever happened to IBM's VM PC software?

and topic drift with respect to original relational/sql System/R, misc. posts
http://www.garlic.com/~lynn/submain.html#systemr

slightly related:
http://www.garlic.com/~lynn/2006w.html#46 The Future of CPUs: What's After Multi-Core?

Date: 10/16/80 12:57:51
From: wheeler

I don't know about what XXXXXX (if anything) has written. XXXXXX was an SE in LA who was also responsible for VMAP. He has left the company and formed his own VM consulting company.

I do know many of his opinions are somewhat similar to MIPENVY, although he worked in a very different environment. MIPENVY was written by Jim Gray who worked here at research. He was very instrumental in System/R and somewhat of an authority on data base in general and distributed data bases in particular. He has gone to work for Tandem. While he was here he did a lot of consulting with the STL/IMS design people. MIPENVY was a short piece of a much longer letter that he wrote at the request of his manager detailing numerous things about with IBM in general & IBM research in particular. I have not gotten any feedback on how far up his letter has gone so far.

Jim Gray has had a high degree of exposure both inside of IBM & outside. For whatever reason he has been telling people (with respect to IBM questions) to call me in his place. Just before he left, I had lunch with him & STL/IMS design people. He suggested that they should now come to me (IMS must be in deep hurt, what I really about O/S in-depth, is 10 years old). I've also gotten calls from BofA management about System/R, VM, & data base stuff.

BofA now has one of the original IMS design people as head of computing. They are hiring a number of the good IMS people out of STL (or where ever they can get them -- rumor is they have or will have larger IMS development group than IBM). STL also is feeling very pressured by the Japanese. Claim is that the Japanese IMS is much better than IBM's. STL has crash program to implement enhancements to IMS to bring it up to the current Japanese level. Only problem is that FCS is targeted for 1985 (although there are some number of bets out that it will slip).

I was down in LA in June for a customer call at LA Times & spent most of the evening with XXXXXX. He was very unhappy with the way he saw IBM going at that time. Too much pressure from the branch to sell MVS among other things. He has a Radio Shack computer at home & believes that there ought to be a crash program to get most of the CMS function into a user's terminal. Other companies are getting very close. In the next couple of years there is going to be a lot of pressure from that direction.


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

and ...

Date: 10/06/80 09:33:41
From: wheeler

re: MIPENVY script; while I was in POK last week teaching a performance and scheduling class to the VM development group and change team, Jim Gray departed IBM for Tandem. He left a goodbye note on my terminal. There was a cryptic remark about some new project that will seriously affect IBM. Knowing Jim Gray, it was not just sour grapes leaving this company. Considering all the proto-type projects that lots of people have been doing for several years with multiple (relatively) "small" processors, both tightly & loosely coupled it is surprising that nobody has come out with something sooner to seriously impact glasshouse, mainframe market.


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

misc. past posts mentioning MIPENVY
http://www.garlic.com/~lynn/2002k.html#39 Vnet : Unbelievable
http://www.garlic.com/~lynn/2002o.html#73 They Got Mail: Not-So-Fond Farewells
http://www.garlic.com/~lynn/2002o.html#75 They Got Mail: Not-So-Fond Farewells
http://www.garlic.com/~lynn/2004c.html#15 If there had been no MS-DOS
http://www.garlic.com/~lynn/2004l.html#31 Shipwrecks
http://www.garlic.com/~lynn/2005u.html#41 Mainframe Applications and Records Keeping?

"The Elements of Programming Style"

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "The Elements of Programming Style"
Newsgroups: alt.folklore.computers
Date: Mon, 01 Jan 2007 16:12:49 -0700
Anne & Lynn Wheeler <lynn@garlic.com> writes:
they had tried running MVS on processors used for "testcell" testing (engineering and development devices) and MTBF was on the order of 15-minutes (crashes and/or hangs) ... and they had been doing the testing with machines in scheduled "stand alone" time (with simple, custom written stand-alone monitors).

re:
http://www.garlic.com/~lynn/2006y.html#25 "The Elements of Programming Style"

In the past, I've made reference to earlier attempts using MVS for "testcell" operation ... being able to test engineering hardware under development in an MVS operating system environment ... and MVS experiencing a 15min MTBF.

I had done a I/O supervisor redesign and rewrite to provide an operating system environment for on-demand, concurrent testing of engineering and development hardware (in bldg. 14 & bldg. 15):
http://www.garlic.com/~lynn/subtopic.html#disk

following is simple reference to preparing to release product 3380 hardware and testing their operation under MVS.

Date: 10/15/80 13:29:38
From: wheeler

fyi; ref: I/O Reliability Enhancement; After running under VM for almost two years in the engineering labs, the 3380 hardware engineers recently did some live MVS testing.

They have a regression bucket of 57 hardware errors (hardware problems that are likely to occur & the FE must diagnose from the SCP error information provided).

It turns out that for 100% of the hardware errors, the MVS system hangs & must be re-IPL'ed. Also in 66% of the cases there is no indication of what the problem was that forced the re-IPL.


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

even tho the above email was purely internal and never was avail. outside the corporation ... it still resulted in the manager of MVS RAS generating quite a bit of uproar (something along the line of trying to kill the messenger?)

a few other, recent posts mentioning the i/o reliability work
http://www.garlic.com/~lynn/2006x.html#12 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006x.html#15 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006x.html#27 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006y.html#34 "The Elements of Programming Style"

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

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Future of CPUs: What's After Multi-Core?
Newsgroups: alt.folklore.computers
Date: Mon, 01 Jan 2007 16:48:22 -0700
Anne & Lynn Wheeler <lynn@garlic.com> writes:
We had added a new facility to the SJR/VM in 1979 (module DMKCOL) enabling capturing all disk record accesses. This information was then used in modeling various kinds of caching strategies. It was run on a number of systems in the san jose area (including some having batch operating systems running in virtual machine).

One of the findings was that a system global cache (i.e. with global LRU replacement policy) outperformed any partitioned cache strategy (aka effectively local LRU replacement strategy) ... where the aggregate amount of electronic cache was the same in the two cases.

One of the other pieces of information that started to emerge from the modeling work was finding some amount of meta-activity ... that specific collections of records were frequently accessed in longer term cyclic pattern (once-a-day, weekly, monthly, etc). This started to have implications as CMSBACK morphed and added much more sophisticated filesystem management strategies.

some work was also done about being able to use the real-time capture characteristic of DMKCOL to aid with real-time record allocation.


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

other old email about DMKCOL disk record activity tracing/collection facility:

Date: 08/07/80 08:24:58
To: wheeler

Lynn:

I work in Aids Development in Poughkeepsie in VM modeling & measurement areas (VMPR, SMART, VMAP). Recently, we have been investigating cache dasd and heard about some mods you made (presumably to IOS) which collects and logs 'mbbcchhr' information.

We have received a hit ratio analysis program from XXXXXX who informed us of your work. The point is that we would like to make a package available to the field, prior to fcs, which would project the effect of adding a cache of a given size. Can you give me your opinion on the usability of such a package. I am presuming that most of the work involves updating and re-loading cp...I would like to take the code and try it myself...can it be run second level?? Appreciate your response...


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

Date: 08/07/80 07:22:34
From: wheeler

re: collect mods;

CP mods. include a new module (DMKCOL), a new bit definition in the trace flags, a couple new diagnose codes, a new command, and a hit to DMKPAG (so code can distinguish between cp paging and other I/O) and a hook in dmkios. no problem running code 2nd level.

1) collected data is useful for general information about I/O characteristics but there are a lot of other data gatherers which provide almost as much info (seek information, but not down to the record level).

2) I guess I don't understand the relative costs for an installation to justify cache. I would think in most cases a ballpark estimate can be made from other data gatherers. It would seem that unless the cache is going to be relatively expensive this may be something of an overkill.

3) From the stand point of impressing a customer with IBM's technical prowess the hit-ratio curves is a fantastic 'gimmick' for the salesman. Part of my view point may be based on having made too many customer calls, I've seen very few decisions really made on technical merit.

4) Hit-ratio curves may be in several cases a little too concrete. An account team will need additional guidelines (fudge factors) to take into account changing load (/growth).

Will send code. The updates are currently against a sepp 6.8/csl19 system. dmkios update should go in w/o problems. updates for new diagnose and command you will have to adapt to your own system (command & diagnose tables have been greatly changed).


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

DOS C prompt in "Vista"?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: DOS C prompt in "Vista"?
Newsgroups: alt.folklore.computers
Date: Tue, 02 Jan 2007 09:05:20 -0700
Pascal Bourguignon <pjb@informatimago.com> writes:
The next change had something esoteric to do with save-area chaining conventions -- again, for the sake of conventions and to keep the dump analysis tools happy.

Note that the "null program" has tripled in size: both in terms of the number of source statements and in terms of the number of instructions executed!


there was APAR/fix that had to do with attributes specified in the linkedit step (there was recently long thread in mainframe n.g. on various meanings of rent, serial reusable, etc). if a copy of the program was already loaded ... could it be directly used or did it have to be reloaded from disk.

recent posts in the mainframe thread that wandered into the (real?) meanings of various linkedit options:
http://www.garlic.com/~lynn/2006s.html#53 Is the teaching of non-reentrant HLASM coding practices ever defensible?
http://www.garlic.com/~lynn/2006s.html#55 Is the teaching of non-reentrant HLASM coding practices ever defensible?
http://www.garlic.com/~lynn/2006s.html#61 Is the teaching of non-reentrant HLASM coding practices ever defensible?
http://www.garlic.com/~lynn/2006s.html#64 Is the teaching of non-reentrant HLASM coding practices ever defensible?
http://www.garlic.com/~lynn/2006t.html#1 Is the teaching of non-reentrant HLASM coding practices ever
http://www.garlic.com/~lynn/2006t.html#2 Is the teaching of non-reentrant HLASM coding practices ever defensible?
http://www.garlic.com/~lynn/2006t.html#16 Is the teaching of non-reentrant HLASM coding practices ever defensible?

misc. past threads mentioning iefbr14
http://www.garlic.com/~lynn/99.html#81 Perfect Code
http://www.garlic.com/~lynn/99.html#85 Perfect Code
http://www.garlic.com/~lynn/99.html#96 IEFBR14 cookie from www.ibm.com
http://www.garlic.com/~lynn/2001e.html#60 Estimate JCL overhead
http://www.garlic.com/~lynn/2001n.html#48 The demise of compaq
http://www.garlic.com/~lynn/2003m.html#15 IEFBR14 Problems
http://www.garlic.com/~lynn/2003m.html#31 SR 15,15 was: IEFBR14 Problems
http://www.garlic.com/~lynn/2003m.html#32 SR 15,15 was: IEFBR14 Problems
http://www.garlic.com/~lynn/2003m.html#34 SR 15,15 was: IEFBR14 Problems
http://www.garlic.com/~lynn/2003m.html#35 SR 15,15 was: IEFBR14 Problems
http://www.garlic.com/~lynn/2004.html#52 AMD/Linux vs Intel/Microsoft
http://www.garlic.com/~lynn/2005r.html#38 IEH/IEB/... names?
http://www.garlic.com/~lynn/2005r.html#40 IEH/IEB/... names?

Securing financial transactions a high priority for 2007

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Tue, 02 Jan 2007 09:53:24 -0700
jmfbahciv writes:
Someday just watch the guy ahead of you play with the swipe machines. Notice when something goes wrong. Invariably, the card ends up getting swiped again, and sometimes a third time. You don't need to manufacture a fake.

re:
http://www.garlic.com/~lynn/2006y.html#7 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2006y.html#8 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007.html#0 Securing financial transactions a high priority for 2007

if the compromise is really with the swipe machine ... then such behavior is frequently quickly traced to the offending terminal and it is "caught" and removed.

in skimming scenarios ... the attackers can go to great lengths to disguise the point of compromise (i.e. compromised machine that is recording magstripes and possibly pins) ... in some cases being able to garner several tens of millions before the authorities are able to trace back enuf possible common factors to the point of compromise
http://www.garlic.com/~lynn/subintegrity.html#harvest
http://www.garlic.com/~lynn/subintegrity.html#secrets

misc. past posts mentioning attackers attempting to maximize fraud ROI (return-on-investment)
http://www.garlic.com/~lynn/aadsm10.htm#bio6 biometrics
http://www.garlic.com/~lynn/aadsm14.htm#4 Who's afraid of Mallory Wolf?
http://www.garlic.com/~lynn/aadsm17.htm#2 Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
http://www.garlic.com/~lynn/aadsm17.htm#47 authentication and authorization ... addenda
http://www.garlic.com/~lynn/aadsm17.htm#60 Using crypto against Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm18.htm#45 Banks Test ID Device for Online Security
http://www.garlic.com/~lynn/aadsm19.htm#13 What happened with the session fixation bug?
http://www.garlic.com/~lynn/aadsm19.htm#17 What happened with the session fixation bug?
http://www.garlic.com/~lynn/aadsm19.htm#26 Trojan horse attack involving many major Israeli companies, executives
http://www.garlic.com/~lynn/aadsm19.htm#45 payment system fraud, etc
http://www.garlic.com/~lynn/aadsm23.htm#34 Chip-and-Pin terminals were replaced by "repairworkers"?
http://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#44 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2003o.html#35 Humans
http://www.garlic.com/~lynn/2004.html#29 passwords
http://www.garlic.com/~lynn/2004b.html#39 SSL certificates
http://www.garlic.com/~lynn/2005p.html#25 Hi-tech no panacea for ID theft woes

lots of past posts mentioning fraud, exploits, vulnerabilities, threats, etc
http://www.garlic.com/~lynn/subintegrity.html#fraud

the data breach and security breach operations frequently basically use the similar scenario ... but instead of attacker doing real-time recording from a compromised terminal ... collect the recorded information from transaction logs. frequently there is quite a bit of effort to disguise the fact that the transaction logs have been copied ... since when it is discovered, all the affected account numbers are frequently deactivated and cards re-issued (which may be a $10-$20 expense per account, aka not just mailing the new card but all the associated data-processing, administrative and notification activity).

there have been a number of recent "new year" stories about having recently hit 100million in the aggregate number of accounts that have been involved in recent breaches. Phishing and various computer Trojans have been other mechanisms for harvesting information that enables fraudulent transactions.

some of the "new year" breach stories:

Encryption a perfect response to the Year of the Breach
http://scmagazine.com/us/news/article/623768/encryption-perfect-response-year-breach Bots, breaches and bugs plague 2006
http://www.securityfocus.com/news/11432
By the numbers: A dismal year for data breaches
http://blogs.zdnet.com/BTL/?p=4169
VanBokkelen: 2006: The year of the breach

http://www.fcw.com/article97098-12-18-06-Print
Personal data security breaches hit 100 million milestone in US
http://www.finextra.com/fullstory.asp?id=16296
An Ominous Milestone: 100 Million Data Leaks (data breach)
http://www.hackinthebox.org/modules.php?op=modload&name=News&file=article&sid=22030
100m US records exposed by security blunders
http://www.theregister.com/2006/12/18/data_breach_milestone/
100 Million Victims of Data Theft (data breach)
http://it.slashdot.org/it/06/12/17/2214219.shtml
Boeing laptop theft puts U.S. data breach tally over 100M
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9006140&intsrc=hm_list

Gift Cards have a different kind of skimming vulnerability ... where crooks record numbers of unsold cards at stores and then return later to see which ones have been activated (which they promptly attempt to empty). there have been some recent stories that this is a new exploit just this year ...

Three gift card scams take value from your presents
http://www.twincities.com/mld/twincities/living/16267723.htm

however, it has been around for some time, story from a year ago about observing one possible such event:
http://www.garlic.com/~lynn/aadsm22.htm#10

Securing financial transactions a high priority for 2007

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Tue, 02 Jan 2007 10:15:17 -0700
jmfbahciv writes:
Someday just watch the guy ahead of you play with the swipe machines. Notice when something goes wrong. Invariably, the card ends up getting swiped again, and sometimes a third time. You don't need to manufacture a fake.

re:
http://www.garlic.com/~lynn/2006y.html#7 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2006y.html#8 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007.html#0 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007.html#5 Securing financial transactions a high priority for 2007

& fraud roi addenda

in traditional credit card scenario ... there is a merchant financial institution that is financially responsible for the merchant (acquirer) and a consumer financial institution that is financially responsible for the consumer (issuer). the transaction goes from the merchant terminal to the acquirer and then to the issuer.

the issuer processing frequently includes various kinds of account specific fraud detection patterns ... like calling you up if particularly suspicious transactions are going on for an account.

in similar manner, the acquiring processing will also be looking for merchant (and/or merchant terminal) fraud patterns. a terminal doing duplicate transactions (a really simple replay attack scenario) and/or multiple transactions against accounts might not last a day ... and the fraudulent transactions not even get posted for processing. A duplicate transaction (in a merchant terminal scenario) can be fairly easily recognized ... and the processing would eventually result in duplicate credit being posted to the merchant bank account. depending on when the fraud is recognized ... such a credit might not even get scheduled ... or if it is performed, it may be reversed in straight-forward manner. furthermore depending on relationship and standing between the acquiring financial institution and the merchant ... postings might actually be delayed several days (and/or go into some sort of impounded account).

some of the reasons that a compromised terminal is frequently simply used for recording data ... and the actual fraudulent transactions happen as far away and widely dispersed as possible.

SSL info

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: SSL info
Newsgroups: alt.computer.security
Date: Tue, 02 Jan 2007 11:37:06 -0700
"UKuser" <spidercc21@yahoo.co.uk> writes:
I'm going to be working with some SSL pages (php) and wondered if there were any good design/development sites for security tips etc so I miss out on making the "obvious" blunders - whatever they may be.

I've found: http://blogs.msdn.com/ie/archive/2005/04/20/410240.aspx which is very good and lists two possible problems. Here then is the newbie question.

If a form is hosted on a HTTP (non secure) site and points to a HTTPS in the action tag, does this mean that the page has already made the SSL connection/handshake? Does the browser recognize the potential for a HTTPS connection and therefore do the same as if it was a full SSL page?

Secondly, why is mixed content so bad (any sites would be great)? I appreciate various elements could be secure/unsecure but how would that pose a risk?


originally SSL was suppose to address two issues 1) are you really talking to the server that you think you are talking to and 2) encryption (hiding) of transmitted information.

for #1, the user typed in the URL of the server they wanted to talk to, the server returned a SSL domain name server digital certificate, the browser validated the digital certificate and then compared the domain name in the user supplied URL with the domain name in the digital certificate.

some posts about working on this long ago and far away with a small client/server startup that wanted to do payment transactions
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

they had this technology called SSL ... and the payment transaction processing has since come to be called e-commerce. some number of past posts mentioning SSL processing
http://www.garlic.com/~lynn/subpubkey.html#sslcert

fairly quickly a problem cropped up ... merchants discovered that using SSL for the complete processing cut their processing thruput by 80-90percent ... so they restricted SSL for just the checkout/payment processing. So now a user enters a non-SSL URL ... which doesn't check to see that the server that the user is talking to, is really the server that the user thinks they are talking to.

the users click on a server provided button ... which supplies the (SSL) URL. In this situation ... rather than checking that the server is the server the user thinks they are talking to ... the only thing it does is checks that the server is whoever they claim to be (i.e. the server provides both the URL with a domain name as well as the digital certificate with the domain name). it would take a fairly inexperienced to claim to be one server and not be able to provide a digital certificate that substantiates that claim. this is also what is behind some of the Phishing emails that can provide (SSL) URLs to click-thru on ... where the attacker provides both the URL and any digital certificate that supports that they are who they claim to be.

there is separate catch-22 scenario that certification authorities are looking at for improving the integrity of the domain name digital certificates that they issue. currently they require a lot of identification information as to the applicant for the digital certificate. they then go thru a time-consuming, costly, and error prone processing of cross-checking that the provided information (by the digital certificate applicant) matches the information on-file with the domain name infrastructure as to the owner of the specific domain.

the proposal is for having domain name owners provide a public key to the domain name infrastructure when they register the domain name. now the certification authorities can require that digital certificate applications be digitally signed. Now the certification authorities can do a real-time retrieval of the on-file public key (from the domain name infrastructure ... analogous to what they do now when they do real-time retrieval of information as to the owner of the domain name for matching) ... and use it to validate the digital signature. This turns a time-consuming, error prone, and costly identification matching process into a much more reliable, simple, and less expensive authentication process.

the catch-22 is that if the certification authority can do a real-time retrieval of the on-file public key for digital certificate, then potentially the rest of the world can also ... eliminating the need for the digital certificates ... misc. past posts mentioning the catch-22
http://www.garlic.com/~lynn/subpubkey.html#catch22

that can result in transition to certificate-less public key operation. misc. past posts mentioning certificate-less operation
http://www.garlic.com/~lynn/subpubkey.html#certless

and reference to old email from 1981 with a suggestion for a certificate-less public key operation:
http://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network
http://www.garlic.com/~lynn/2006w.html#15 more secure communication over the network
http://www.garlic.com/~lynn/2006w.html#18 more secure communication over the network

some number of references to account-based public key operation (as opposed to digital certificate public key operation)
http://www.garlic.com/~lynn/x959.html#aads

"The Elements of Programming Style"

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "The Elements of Programming Style"
Newsgroups: alt.folklore.computers
Date: Tue, 02 Jan 2007 12:22:23 -0700
Justa Lurker <JustaLurker@att.net> writes:
The 'PC' platform has put useful computing power in the hands of millions more people and organizations than your beloved PDP-10, Lynn's beloved VM/CMS, etc. ever did or could have. Those were fine systems in their own right, but like fishing stories and old girlfriends, recollections and perceptions automagically improve with age.

re:
http://www.garlic.com/~lynn/2006y.html#29 "The Elements of Programming Style"
http://www.garlic.com/~lynn/2006y.html#34 "The Elements of Programming Style"
http://www.garlic.com/~lynn/2007.html#1 "The Elements of Programming Style"

and from wiki
https://en.wikipedia.org/wiki/History_of_CP/CMS
and
https://en.wikipedia.org/wiki/CP/CMS

in the above ... mention of IDC
https://en.wikipedia.org/wiki/History_of_CP/CMS#1964.3F.E2.80.9372.3F:_IDC.27s_use_of_CP.2FCMS
and
https://en.wikipedia.org/wiki/Interactive_Data_Corporation

recent thread referencing IDC:
http://www.garlic.com/~lynn/2006y.html#20 moving on
http://www.garlic.com/~lynn/2006y.html#21 moving on
http://www.garlic.com/~lynn/2006y.html#23 moving on
http://www.garlic.com/~lynn/2006y.html#26 moving on

and NCSS reference in history article
https://en.wikipedia.org/wiki/History_of_CP/CMS#1968.E2.80.9386.3F:_VP.2FCSS
and
https://en.wikipedia.org/wiki/VP/CSS
https://en.wikipedia.org/wiki/National_CSS

some various past posts mentioning ncss
http://www.garlic.com/~lynn/99.html#10 IBM S/360
http://www.garlic.com/~lynn/2001h.html#59 Blinkenlights
http://www.garlic.com/~lynn/2001m.html#51 Author seeks help - net in 1981
http://www.garlic.com/~lynn/2001m.html#55 TSS/360
http://www.garlic.com/~lynn/2002c.html#44 cp/67 (coss-post warning)
http://www.garlic.com/~lynn/2002i.html#63 Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002i.html#64 Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002i.html#69 Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002l.html#56 10 choices that were critical to the Net's success
http://www.garlic.com/~lynn/2002m.html#61 The next big things that weren't
http://www.garlic.com/~lynn/2002p.html#37 Newbie: Two quesions about mainframes
http://www.garlic.com/~lynn/2003d.html#15 CA-RAMIS
http://www.garlic.com/~lynn/2003d.html#17 CA-RAMIS
http://www.garlic.com/~lynn/2003d.html#68 unix
http://www.garlic.com/~lynn/2003d.html#72 cp/67 35th anniversary
http://www.garlic.com/~lynn/2003i.html#15 two pi, four phase, 370 clone
http://www.garlic.com/~lynn/2003k.html#10 What is timesharing, anyway?
http://www.garlic.com/~lynn/2003l.html#22 Secure OS Thoughts
http://www.garlic.com/~lynn/2003l.html#34 Thoughts on Utility Computing?
http://www.garlic.com/~lynn/2003m.html#33 MAD Programming Language
http://www.garlic.com/~lynn/2003n.html#15 Dreaming About Redesigning SQL
http://www.garlic.com/~lynn/2003o.html#23 Tools -vs- Utility
http://www.garlic.com/~lynn/2004d.html#33 someone looking to donate IBM magazines and stuff
http://www.garlic.com/~lynn/2005.html#5 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005b.html#45 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2006b.html#39 another blast from the past
http://www.garlic.com/~lynn/2006k.html#35 PDP-1
http://www.garlic.com/~lynn/2006k.html#36 PDP-1
http://www.garlic.com/~lynn/2006k.html#37 PDP-1
http://www.garlic.com/~lynn/2006k.html#39 PDP-1
http://www.garlic.com/~lynn/2006m.html#50 The System/360 Model 20 Wasn't As Bad As All That
http://www.garlic.com/~lynn/2006n.html#13 Not Your Dad's Mainframe: Little Iron
http://www.garlic.com/~lynn/2006o.html#49 The Fate of VM - was: Re: Baby MVS???

===

and lots of past posts mentioning cp-based time-sharing operations
http://www.garlic.com/~lynn/submain.html#timeshare

"The Elements of Programming Style"

Refed: **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "The Elements of Programming Style"
Newsgroups: alt.folklore.computers
Date: Tue, 02 Jan 2007 12:50:45 -0700
stanb45@dial.pipex.com (Stan Barr) writes:
Hardware Forth implementations typically provide only a CALL/RET and some sort of IF, ELSE, NEXT construct for loops - forms of JMP - but not usually any programmer usable JMP, although it's normally possible to simulate one if you feel the need.

Forth is an example of a low-level goto-less language. It's easy enough to write a GOTO but I've never seen it used except as a JMP in assembler for conventional processors.


from long ago and far away

Date: Mon 26 Nov 84 08:51:42-PST
To: distribution
Subject: Hewlett Packard Laboratories-Computer Colloquium-November 29, 1984

CHUCK MOORE

Computer Cowboys

The Silicon Cowboy Rides FORTH


"I have been a maverick programmer for 25 years, constantly at odds with conventional wisdom. I developed the FORTH programming language to express the creativity of the expert. It remains unparalleled in efficiency, brevity and versatility."

"Countless applications and thousands of FORTH programmers later, we finally obtain hardware that can match the software. The FORTHchip boasts an elegantly simple architecture for the ultimate in programmability and throughput."

Thursday, November 29, 1984 4:00 p.m.

5M Conference Room
1501 Page Mil Road
Palo Alto, CA 94304

NON-HP EMPLOYEES: Welcome! Please come to the lobby on time so that you may be escorted to the conference room.


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

moving on

Refed: **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: moving on
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers
Date: Tue, 02 Jan 2007 13:04:17 -0700
Anne & Lynn Wheeler <lynn@garlic.com> writes:
For relocate shared segment support, a shared segment may appear anywhere within a virtual machine's address space (it does not need to be at the position specified in the VMABLOK). The way I handled it in DMKVMA was to use the PTO pointers in the VMABLOK to check the shared segments, rather than using the segment index number to displace into the segment table and pick-up the STE.

One of the co-op students that helped me write the original shared segment support for release 2 VM (included the sub-set that is now in the product DCSS) is now with Interactive Data Corporation (IDC). They have taken the idea and put a whole group on expanding the idea. They now call it Floating segments (instead of relocating segments). They have a modified assembler for generating adcon free code and are working on the compilers. All this work they have done has greater significance than they realize. It would greatly simplify conversion to an increased address space size.


re:
http://www.garlic.com/~lynn/2006y.html#20 moving on
http://www.garlic.com/~lynn/2006y.html#21 moving on
http://www.garlic.com/~lynn/2006y.html#23 moving on
http://www.garlic.com/~lynn/2006y.html#26 moving on

"XXXXXX" was one of the two original people at the Los Gatos lab. responsible for mainframe pascal. He went on to be vp of software development at MIPs and later showed up as general manager of the SUN business unit responsible for the fledgling JAVA.

misc. collected posts about difficulty with positioning executables (that followed standard os/360 conventions)
http://www.garlic.com/~lynn/submain.html#adcon

Date: 10/08/80 16:51:57
From: wheeler

re: relocating shared code; XXXXXX thinks that he can have Pascal/VS not using relative adcons and also "compile" code that doesn't have relative adcons. Adcons are generated as absolute, the target address minus the base address of the module. The loader supports both positive and negative displacements. When it comes time to transfer control the routine picks up the absolute adcon and adds in the value of the base register to resolve the relocated address. Code can then be generated in shared modules (ref: shared modules, RJ2928) and the CMS loadmod upgraded to load code into available segments (of course the same procedure works for non-shared modules also).


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

other references to mips/sun things long ago and far away:
http://www.garlic.com/~lynn/2000.html#15 Computer of the century
http://www.garlic.com/~lynn/2004c.html#25 More complex operations now a better choice?
http://www.garlic.com/~lynn/2004q.html#35 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005b.html#14 something like a CTC on a PC
http://www.garlic.com/~lynn/2005r.html#20 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2006u.html#31 To RISC or not to RISC

vm/sp1

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: vm/sp1
Newsgroups: alt.folklore.computers
Date: Tue, 02 Jan 2007 15:35:59 -0700
I have an old t-shirt that some people at Amdahl were distributing when vm/sp initially came out; it has a particularly gory looking vulture labeled vm/sp and a line underneath it says vm/sp is waiting for you.

Date: 10/15/80 14:04:55
To: wheeler

lynn,

i have been working on bringing up vm/sp rel 1 on a 4331 processor here at the sci. center. i spoke with XXXXX this morning and he mentioned your name and your feelings about sp. i felt i should tell you about some of our problems etc.

first of all, they changed the rbloks copy and redefined redevstat to rdevsta4. that proved to be devastating to us because we run some software that used the field.

there's a ctca bug in sp1. pvm gets into infinite loops the system never was able to stay up one night !! as you know, the nuc has grown to well over 240-260k for a large system. that is intolerable on 4300 processors. i cut out parts of cp and i have it down to 196k. (up from 170k)

about the only thing that works right is XXXXX's SPM stuff!

i am going to go back to release 6 plc 11 tonight. i am putting vm/sp aside for awhile until a few plcs are out.

well, thats about it......


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

some past references to SPM
http://www.garlic.com/~lynn/2006k.html#51 other cp/cms history
http://www.garlic.com/~lynn/2006t.html#47 To RISC or not to RISC
http://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network
http://www.garlic.com/~lynn/2006w.html#16 intersection between autolog command and cmsback (more history)
http://www.garlic.com/~lynn/2006w.html#52 IBM sues maker of Intel-based Mainframe clones

======

vm/sp release 1 was sometimes referred to as sp1. this was different than the sp1 announced by kingston in spring of 92:
http://www.garlic.com/~lynn/97.html#5 360/44 (was Re: IBM 1130 (was Re: IBM 7090--used for business or
http://www.garlic.com/~lynn/99.html#54 Fault Tolerance
http://www.garlic.com/~lynn/2000d.html#2 IBM's "ASCI White" and "Big Blue" architecture?

after we were told we could not work on anything with more than four processors ... recent reference:
http://www.garlic.com/~lynn/2006x.html#3 Why so little parallelism?

=====

misc. past posts mentioning vm/sp1 (and/or the vm/sp1 changes to multiprocessor support for single TPF guest running on otherwise idle 3081; which resulted in degrading thruput for nearly every other customer multiprocessor installation)
http://www.garlic.com/~lynn/2001f.html#57 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2002c.html#9 IBM Doesn't Make Small MP's Anymore
http://www.garlic.com/~lynn/2003.html#27 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003g.html#32 One Processor is bad?
http://www.garlic.com/~lynn/2004f.html#21 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2005h.html#22 Today's mainframe--anything to new?
http://www.garlic.com/~lynn/2005j.html#17 Performance and Capacity Planning
http://www.garlic.com/~lynn/2005n.html#4 54 Processors?
http://www.garlic.com/~lynn/2005n.html#47 Anyone know whether VM/370 EDGAR is still available anywhere?
http://www.garlic.com/~lynn/2005s.html#7 Performance of zOS guest
http://www.garlic.com/~lynn/2006d.html#5 IBM 610 workstation computer

"The Elements of Programming Style"

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "The Elements of Programming Style"
Newsgroups: alt.folklore.computers
Date: Tue, 02 Jan 2007 15:52:51 -0700
Anne & Lynn Wheeler <lynn@garlic.com> writes:
and from wiki
https://en.wikipedia.org/wiki/History_of_CP/CMS
and
https://en.wikipedia.org/wiki/CP/CMS


re:
http://www.garlic.com/~lynn/2007.html#8 "The Elements of Programming Style"

and recent historical reference here: An Overview of Virtualization
http://linux.slashdot.org/linux/07/01/02/1917205.shtml
Virtual Linux
http://www-128.ibm.com/developerworks/linux/library/l-linuxvirt/?ca=dgr-lnxw01Virtual-Linux

in the wiki article,
https://en.wikipedia.org/wiki/History_of_CP/CMS#1967.E2.80.9368:_CP-67

they mentioned that science center
http://www.garlic.com/~lynn/subtopic.html#545tech

making cp67 available to lincoln labs in apr67 ... and then it was released to customers in may68. however, between apr67 and may68 it was also installed the last week in jan68 at the univ. where i was undergraduate (and already responsible for the production os/360 system). i then got to play with cp67 (mostly on weekends). I was asked to participate at the product announcement at the spring share meeting in houston.

there was a product education meeting scheduled first of jun68 at ibm center on wilshire (down from hollywood). one of the primary people that was scheduled to teach the class had just given notice the friday before that they were leaving for ncss
https://en.wikipedia.org/wiki/History_of_CP/CMS#1968.E2.80.9386.3F:_VP.2FCSS

and that monday morning i got roped into teaching part of the class.

"The Elements of Programming Style"

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "The Elements of Programming Style"
Newsgroups: alt.folklore.computers
Date: Tue, 02 Jan 2007 16:17:27 -0700
Anne & Lynn Wheeler <lynn@garlic.com> writes:

Date: 10/06/80 09:33:41
From: wheeler

re: MIPENVY script; while I was in POK last week teaching a performance and scheduling class to the VM development group and change team, Jim Gray departed IBM for Tandem. He left a goodbye note on my terminal. There was a cryptic remark about some new project that will seriously affect IBM. Knowing Jim Gray, it was not just sour grapes leaving this company. Considering all the proto-type projects that lots of people have been doing for several years with multiple (relatively) "small" processors, both tightly & loosely coupled it is surprising that nobody has come out with something sooner to seriously impact glasshouse, mainframe market.


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

re:
http://www.garlic.com/~lynn/2007.html#1 "The Elements of Programming Style"

for other topic drift, additional reference to the class in POK ... i.e.
http://www.garlic.com/~lynn/2007.html#email801006

Date: 10/06/80 15:51:24
From: endicott
To: wheeler

Lynn, SPD mgmt. has agreed to pursue your generalized solution to the Q-DROP problem described in apar vm11293 per your suggestion at our meeting in Pok. on 10/1. We look to you to provide the following:
1) a general description of the function including problem description and proposed solution
2) list of modules/macros impacted with a brief description and an estimate on LOC to be added/changed
3) unit tested code on an SP1 base.

Endicott will run regression and performance tests and coordinate a plan to XMIT the code to the field.

We also enlist your aid in diagnosing problems that may occur during our tests (normally remotely, but on site if required), reviewing our perf. runs, and assisting with any Pubs changes.

Please call me on tie line xxx-xxxx as soon as possible in order that I may understand any requirements you have to provide the above. We would like to have items 1 and 2 by 10/10 and 3 by 10/17 if possible.

Thank you for your support and I await your call.


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

Date: 10/08/80 10:22:48
From: wheeler
To: endicott

re: loagwait fix; will have code & a couple paragraphs either today or tomorrow. Will be against a release 6, ltr 11 system. Have updates for sp system but they were prior to permanent application to base and resequencing. May be sometime next week (or later) before I can get ahold of SP source for modules affected and have sequence nos. converted. VMBLOK hit is immaterial, should be able to do it there, all that is required is space obtain out of currently reserved fileds.


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

recent post referring to vm/sp1
http://www.garlic.com/~lynn/2007.html#11 vm/sp1

a couple posts referring to longwait and various q-drop related issues
http://www.garlic.com/~lynn/2001f.html#57 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2006y.html#10 Why so little parallelism?

vm/sp1

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vm/sp1
Newsgroups: alt.folklore.computers
Date: Tue, 02 Jan 2007 16:50:01 -0700
Anne & Lynn Wheeler <lynn@garlic.com> writes:
I have an old t-shirt that some people at Amdahl were distributing when vm/sp initially came out; it has a particularly gory looking vulture labeled "vm/sp" and a line underneath that says "vm/sp is waiting for you".

re:
http://www.garlic.com/~lynn/2007.html#11 vm/sp1
http://www.garlic.com/~lynn/2007.html#13 "The Elements of Programming Style"

old xmas day "sp1" email

Date: 12/25/81 12:41:11
From: wheeler

been checking latest vmshare on SP1.07 & sp1.08 problems. While i was at it thot to go back and check the SP1.05 & SP1.06 comments that we have already from our distributed vmshare (almost month old). Listed is recommendations to pull 11780 & 12111 to dmkcns which lead to prg5s (updates are 1.02). Also listed are recommendations to pull 11439, 118841, 12448. Finally is comment to pull 13311 (1.06) to QCN which leads to bad problems with attached graphics on 3277. Finally is description of problem in DMKRGA which leads to PSA004 abend because code runs off the end of NICBLOK and uses bad area for VMBLOK (this last is open APAR 14???).


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

and for topic drift, x-mas day email from a year later

Date: 12/25/82 17:18:43
From: wheeler

re: sjr system; have SJR 3081 up and running at the SCH level ... I've slightly re-arraigned the SJC2 muxfile to group the Group fair share changes with the rest of the SCH changes. Also have fixed misc. bugs in other updates. Started the process of enabling the majority of the SJC2 updates up thru the SPOOLMAX updates (there is a complete TODO level assembly console log with filename TODO5B already out on the 109 disks). A whole slew of files are waiting at SJRL destined for LSGVMB ... but the connectivity between bldgs 28 & 29 is down at the moment. Hopefully those will make it thru on Monday. Still have some hardware problems with this 3081 (which will have to be cleared up on Monday). Reasonably good chance of getting majority of the rest of the updates activated by January 1st.

By the way Merry Christmas & Happy Holidays.


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

"attached graphics on 3277" is the 3277ga ... i.e. tektronics tube that plugs into side of 3277 terminal.
http://www.garlic.com/~lynn/2001f.html#49 any 70's era supercomputers that ran as slow as today's supercompu
http://www.garlic.com/~lynn/2001i.html#51 DARPA was: Short Watson Biography
http://www.garlic.com/~lynn/2002p.html#29 Vector display systems
http://www.garlic.com/~lynn/2004l.html#27 Shipwrecks
http://www.garlic.com/~lynn/2004l.html#32 Shipwrecks
http://www.garlic.com/~lynn/2004m.html#8 Whatever happened to IBM's VM PC software?
http://www.garlic.com/~lynn/2006e.html#9 terminals was: Caller ID "spoofing"
http://www.garlic.com/~lynn/2006e.html#28 MCTS
http://www.garlic.com/~lynn/2006n.html#24 sorting was: The System/360 Model 20 Wasn't As Bad As All That
http://www.garlic.com/~lynn/2006q.html#16 what's the difference between LF(Line Fee) and NL (New line) ?
http://www.garlic.com/~lynn/2006v.html#19 Ranking of non-IBM mainframe builders?

============

and more topic drift, posts in 2006 mentioning vmshare:
http://www.garlic.com/~lynn/2006b.html#39 another blast from the past
http://www.garlic.com/~lynn/2006d.html#2 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006h.html#9 It's official: "nuke" infected Windows PCs instead of fixing them
http://www.garlic.com/~lynn/2006n.html#3 Not Your Dad's Mainframe: Little Iron
http://www.garlic.com/~lynn/2006p.html#29 Greatest Software Ever Written?
http://www.garlic.com/~lynn/2006r.html#11 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006r.html#37 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006r.html#43 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006s.html#65 Paranoia..Paranoia..Am I on the right track?.. any help please?
http://www.garlic.com/~lynn/2006v.html#22 vmshare
http://www.garlic.com/~lynn/2006v.html#30 vmshare
http://www.garlic.com/~lynn/2006v.html#34 vmshare
http://www.garlic.com/~lynn/2006v.html#38 vmshare
http://www.garlic.com/~lynn/2006v.html#40 vmshare
http://www.garlic.com/~lynn/2006w.html#16 intersection between autolog command and cmsback (more history)
http://www.garlic.com/~lynn/2006w.html#25 To RISC or not to RISC
http://www.garlic.com/~lynn/2006w.html#42 vmshare
http://www.garlic.com/~lynn/2006w.html#48 vmshare
http://www.garlic.com/~lynn/2006w.html#52 IBM sues maker of Intel-based Mainframe clones
http://www.garlic.com/~lynn/2006x.html#6 Multics on Vmware ?
http://www.garlic.com/~lynn/2006x.html#7 vmshare
http://www.garlic.com/~lynn/2006x.html#8 vmshare
http://www.garlic.com/~lynn/2006x.html#19 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006x.html#33 NSFNET (long post warning)
http://www.garlic.com/~lynn/2006y.html#7 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2006y.html#11 Multiple mappings
http://www.garlic.com/~lynn/2006y.html#14 Why so little parallelism?
http://www.garlic.com/~lynn/2006y.html#18 The History of Computer Role-Playing Games
http://www.garlic.com/~lynn/2006y.html#19 The History of Computer Role-Playing Games
http://www.garlic.com/~lynn/2006y.html#29 "The Elements of Programming Style"
http://www.garlic.com/~lynn/2006y.html#35 The Future of CPUs: What's After Multi-Core?

SSL info

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: SSL info
Newsgroups: alt.computer.security
Date: Tue, 02 Jan 2007 23:16:01 -0700
Ertugrul Soeylemez <never@drwxr-xr-x.org> writes:
That also helps exploiting the full potential of SSL. For example, you can't just authenticate the server, you can also authenticate the client or anything else via a certificate. So no more username/password pairs are needed. Users don't need to login manually, they just present their certificate, which is straightforward in today's modern browsers.

actually, client authentication/authorization can be done straight forwardly using registered public keys and digital signatures w/o requiring any digital certificate what-so-ever. misc. past posts mentioning certificate-less operation
http://www.garlic.com/~lynn/subpubkey.html#certless

the first place that became especially evident was when we were brought in to do some consulting with this small client/server startup that had this technology called SSL and wanted to do payment transactions ... for something that has since come to be called e-commerce. previous post in this thread:
http://www.garlic.com/~lynn/2007.html#7 SSL info

at the time SSL didn't have mutual authentication ... but we required it for the payment gateway (the webservers authenticated the payment gateway using installed public key ... and the payment gateway authenticate the webservers using on-file public keys). The addition code had to be added to SSL to do mutual authentication and since it was already heavily certificate-based orientation there still were digital certificates that were passed back-and-forth ... but in actuality ... each authorized webserver had the information about the payment gateway preloaded as part of the payment processing software ... and the payment gateway had onfile information about each authorized webserver. it quickly became strikingly apparent that the digital certificates were redundant and superfluous. misc. other posts mentioning ssl digital certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcert

so the dominant forms of client authentication in the world wide web environments are KERBEROS and RADIUS. These started out being userid/password. However, both KERBEROS and RADIUS have had definitions and implementations were client public keys are registered (in lieu of passwords), servers transmit some random information (as countermeasure to replay attacks), and the clients (using their private key) digitally sign and return the digital signature ... which the server than verifies with the onfile public key.

The original KERBEROS PKINIT (public key) draft initially just specified certificate-less operation ... but under a great deal of lobbying, certificate-mode operation was also added.

One of the scenarios for various webserver software is that client authentication has frequently just been a stub model ... although there are plugins for webserver software that provide KERBEROS and radius interfaces for client authentication. In many of these typical implementations ... the KERBEROS and radius implementations are done in such a way that it is possible to specify password or digital signature operation on a account by account basis ... again certificate-less operation. misc. past posts about KERBEROS operation
http://www.garlic.com/~lynn/subpubkey.html#kerberos
and radius operation
http://www.garlic.com/~lynn/subpubkey.html#radius

sort of the original idea for certificate-mode of operation was that there was interaction between two parties that had no prior knowledge of each other. it was necessary for the certificates to carry all the necessary information. this also sort of gave rise to the x.509 identity certificates from the early 90s.

however, by the mid-90s it was realized that x.509 identity certificates, typically heavily overloaded with personal information represented significant privacy and liability issues. as a result, you saw many institutions dropping back to what they called relying-party-only certificates ... misc. past posts mentioning RPO certificates:
http://www.garlic.com/~lynn/subpubkey.html#rpo

the issue here is that an RPO-certificate basically just carries a public key and some sort of account number. the relying party, takes the account number and retrieves the appropriate account record ... where the actual personal information including any authorization information is kept. however, since the public key originally had to be registered and stored in an account record before any digital certificate was issued, it was trivial to show that the relying party retrieving the account record can include the registered public key. Again, the digital certificate becomes redundant and superfluous.

basically the kerberos and radius PKI implementations with digital certificates typically have done something similar as RPO-certificate, the permission/authorization information is stored in an onfile account record. if any of the client PKI digital certificates authentication operations (kerberos, radius, or roll-your-own) at some point have to retrieve any sort of account record as part of permissions and authorizations ... it is then trivial to also show (again) that the digital certificates are redundant and superfluous.

The digital certificate actually only has meaningful role ... when the server never has to resort to really knowing who the client is and/or anything about the client ... other than what is presented in the digital certificates. No additional information related to things like permissions, authorizations, billing, accounts, etc is required.

its like anybody with valid digital certificate can log into your system and have all permissions regardless of who they are ... and there is no userid account record for the system that is required to provide any additional information related to the user and/or what the user is allowed to do or not do.

as soon as the process has to resort to any additional information (than what is provided in the digital certificate) for doing any operation what-so-ever for the client ... then it is trivial to show that the digital certificate is redundant and superfluous.

How many 36-bit Unix ports in the old days?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How many 36-bit Unix ports in the old days?
Newsgroups: alt.folklore.computers
Date: Wed, 03 Jan 2007 08:49:01 -0700
Lawrence Statton XE2/N1GAK <yankeeinexile@gmail.com> writes:
In fact, until quite recently ( late 80s to early 90s ) nobody would have considered any Unix system as "powerfully built, sturdy".

early 90s? (i suppose i should find a reference) there was a big deal made of tandem lab in austin donating a large number of integrity/reliability fixes (thousand?) to the unix kernel source base.

we were somewhat watching such stuff since we were building ha/cmp on aix kernel
http://www.garlic.com/~lynn/subtopic.html#hacmp

SSL info

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: SSL info
Newsgroups: alt.computer.security
Date: Wed, 03 Jan 2007 11:47:07 -0700
Anne & Lynn Wheeler <lynn@garlic.com> writes:
however, by the mid-90s it was realized that x.509 identity certificates, typically heavily overloaded with personal information represented significant privacy and liability issues. as a result, you saw many institutions dropping back to what they called relying-party-only certificates ... misc. past posts mentioning RPO certificates:
http://www.garlic.com/~lynn/subpubkey.html#rpo


for a little drift ... these are a couple of posts that draw the comparison between some of the current electronic chip passports and the x.509 identity certificates from the early 90s.
http://www.garlic.com/~lynn/aadsm25.htm#46 Flaw exploited in RFID-enabled passports
http://www.garlic.com/~lynn/aadsm26.htm#0 Flaw in RFID-enabled passports (part 2?)

using that comparison, then there is the possibility that all personal information would be eliminated from the passport chips ... for similar privacy and liability reasons that resulted in change-over to relying-party-only certificates in the mid-90s (and away from x.509 identity certificates frequently overloaded with personal information)
http://www.garlic.com/~lynn/subpubkey.html#rpo

after having worked on SSL-based infrastructure ... that has since come to be called e-commerce ... previous posts in this thread
http://www.garlic.com/~lynn/2007.html#7 SSL info
http://www.garlic.com/~lynn/2007.html#15 SSL info

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

it was in this period that we had coined the term certificate manufacturing to differentiate the commoningly deployed SSL digital certificate infrastructure (of the period) from "real" PKI:
http://www.garlic.com/~lynn/subpubkey.html#manufacture

it was also in this period that several people made claims that upgrading financial transactions with client/consumer digital certificates would bring retail financial transactions in the modern era.

the issue here (as in the passport case) is that credentials and certificates are constructs developed for providing trusted information for an offline environment. in the 70s, electronic payment networks made the transition from the offline environment to the online environment ... and supported real-time information regarding authentication and authorization. digital certificate-based offline paradigm for financial transactions, rather than representing any modernization, would result to reverting to pre-70s paradigm.

it was in this period that we also coined the term comfort certificates ... the redundant and superfluous use of stale, static digital certificates (an offline paradigm construct) in an online environment. The comfort certificates provided familiarity and comfort to mindsets that were stuck in the old fashion offline paradigm (which required credentials and certificates to provide trusted information distribution) ... and had difficulty making the transition to an trusted online integrity paradigm.

our repeated observations about the offline digital certificate model actually regressing effective operation by several decades (rather than representing any modernization) was some of the motivation behind OCSP (online certificate status protocol). However, our observation was that it was really a rube goldberg fabrication ... given any operation ... what is more valuable: ... 1) a real time transaction involving real time authentication and authorization information ... or 2) a real time transaction providing status indication about stale, static digital certificate information.

this was also the period that spawned the infrastructure that enabled the yes card exploits
http://www.garlic.com/~lynn/subintegrity.html#yescard

i.e. adding chips to payment cards for use in retail transactions. there were some number of claims that adding the chips even increased the vulnerabilities ... compared to a similar magstripe card w/o a chip.

IBM sues maker of Intel-based Mainframe clones

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM sues maker of Intel-based Mainframe clones
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 03 Jan 2007 11:58:33 -0700
lynn@GARLIC.COM (Anne & Lynn Wheeler) writes:
i.e. "3090" service processor was a modified version of vm370 release 6 running on a pair of 4361 processors, most of the screens/menus written in IOS3270. Part of this was the result of the experience with the 3081 service processor where all of the software was totally written from scratch (trying to get to some amount of off-the-shelf stuff).

minor folklore ... my dumprx was selected for use as diagnostic support for the 3090 service processor ... in the early 80s, i had (re-)implemented large superset of IPCS function totally in rexx
http://www.garlic.com/~lynn/submain.html#dumprx


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

note (in the following) the name rex was changed to "REXX" before shipping as product.

Date: 03/23/82 19:44:00
From: wheeler

re: dumprx; experimental exec . . . Planning on writing nucxload'ing routine to access PRB files. Then same DUMPRX can be used for both cp core & PRB files.


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

and next day

Date: 03/24/82 10:44:27
From: wheeler

re: dumprx; DUMPRX is an experimental IPCS written in rex. It currently supports only CP storage and makes use of local S.J. research extensions to the COMMON 'LOCATE CP' command (for live system). Currently being planed is an exec to extract label & format information from a specified MACLIB.


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

the extensions to the "LOCATE CP" command was to include the (DMKLDR00E) loader tables as part of the pageable kernel (at initial system build) ... so all external symbols were available.

other postings mentioning dumprx
http://www.garlic.com/~lynn/submain.html#dumprx

and a couple hours later

Date: 03/24/82 18:47:10
From: wheeler

re: latest dumprx; dumprx will now format storage if a maclib is available with appropriate dsects for description.


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

and a week later ...

Date: 04/01/82 13:28:53
From: wheeler

re: dumprx exec; does anybody know where the machine copy of the CP abend codes are? &/or how to obtain them?? SP HELP appears to have the "messages" portion of the MESSAGES & CODES manual ... but i didn't see the abend codes anywhere.

I have got the interface for processing PRB files nearly done. Have the LOCATE, RIO, & VIO commands yet to go. I also need to improve its interface to the REX interpreter for returning information. The program is called DMPRXX & is NUCXLOADed.

Except for FSX & MOVEFILE, DUMPRX will completely run in subset mode. I haven't tried pre-NUCXLOADing FSX, which may solve that problem. MOVEFILE is used to extract a member from a maclib for doing a formated control block display. If IOX had a BLDL function, it would be possible to extract a member with FCOPY using the BLDL values. I could resort to dummying up a standard EXEC & calling EXSERV BLDL.

One of the major features that DUMPRX will have over the standard DUMPSCAN is the ease of writing new dump analysis extensions &/or formating routines (example is DUMPRXB EXEC which does a formated display of storage giving instruction op-codes). It will be possible to invoke the editor from DUMPRX, write a new EXEC (&/or modify an existing one), return to DUMPRX ... & then invoke the procedure. Simplest method to "extend" the DUMPRX command language is to require the user to type:

'CMS EXEC filename anyargs'

which would then invoke the new EXEC. That would loose the symbolic name capability tho. Anybody have suggestions for a command language syntax solution?


... snip ... top of post, old email index< /pre>

NSFNET (long post warning)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: NSFNET (long post warning)
Newsgroups: alt.folklore.computers
Date: Wed, 03 Jan 2007 16:06:37 -0700
re:
http://www.garlic.com/~lynn/2006x.html#33 NSFNET (long post warning)

misc. past postings mentioning hsdt activity
http://www.garlic.com/~lynn/subnetwork.html#hsdt

additional background leading up to
http://www.garlic.com/~lynn/2005d.html#13 Cerf and Kahn receive Turing award
http://www.garlic.com/~lynn/2006u.html#56 Ranking of non-IBM mainframe builders?

Date: 04/28/86 20:54:51
From: wheeler

I can give the same talk that has been given to Berkeley and several others and includes some of the stuff on the joint-study proposal for the NSF super computer backbone.

I can talk some on the phone, not sure about when I might be able to get down to UCLA. Welcome to come-up to San Jose to see some of the hardware & software.


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

some past references to some earlier Berkeley discussions (especially with respect to the 10m telescope being planned for Hawaii)
http://www.garlic.com/~lynn/2004h.html#7 CCD technology
http://www.garlic.com/~lynn/2004h.html#8 CCD technology
http://www.garlic.com/~lynn/2006t.html#12 Ranking of non-IBM mainframe builders?

as mentioned before
http://www.garlic.com/~lynn/2006s.html#50 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006t.html#6 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006w.html#43 IBM sues maker of Intel-based Mainframe clones

Eric Bloch was director of the national science foundation for much of the 80s.

Date: 04/28/86 21:02:39
From: wheeler

... oh yes, Eric Bloch suggested that I contact Klinerock at UCLA for some discussions about high-speed network support.


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

and ... aaaaargh ... way too much sna, vtam, ncp, etc.

Date: 30 April 1986, 16:59:50 EST
To: wheeler

Lynn, I am in the process of changing jobs from Charlotte to the IBM/ACIS and Cornell Supercomputer Facility at Cornell. I understand that there will be an overview of HSDT to the Cornell staff tomorrow as a possible additional project for T2-T3 speed connections to NSFnet etc. My new job will be to understand the Cornell etc Network environment as it relates to the Supercomputer facility (including WISCNET , TCP/IP , CSNET, etc etc).

My background has been system support for MVS/Jes2 , VM/SP, RSCS, PVM, ACF/VTAM, 3705 EP/NCP etc. I was in the VNET TSG. Background mainly networking for the last 7 years.

With all the intro done, Could you send me any documentation on HSDT that you might have. While I was in Hursley you sent several documents to XXXXXX, but my copies were lost when my Hursley ID was cancelled.


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

of course, as mentioned before, all the people scheduled for the followup meeting were contacted and told the meeting was canceled.

after that ... there were some number of activities pushing SNA/VTAM for NSFNET activity.
http://www.garlic.com/~lynn/2006w.html#21 SNA/VTAM for NSFNET
and other somewhat related activities
http://www.garlic.com/~lynn/2006x.html#7 vmshare

we had layed a lot of the ground work from hsdt activity for NSFNET being T1 ... ref
http://www.garlic.com/~lynn/internet.htm#nsfnet
with the NSFNET program announcement 28apr86
http://www.garlic.com/~lynn/2002k.html#12
but weren't allowed to bid ... reference to 24nov97 NSFNET award
http://www.garlic.com/~lynn/2000e.html#10

and as per above email 30apr86, we were already working towards T2 & T3.

also as noted elsewhere, initial NSFNET deployment wasn't actually T1 network links (by winning bid) ... but T1 trunks over which were multiplexed 440kbit network links.
http://www.garlic.com/~lynn/99.html#146 Dispute about Internet's origins
http://www.garlic.com/~lynn/2000.html#49 IBM RT PC (was Re: What does AT stand for ?)
http://www.garlic.com/~lynn/2000c.html#78 Free RT monitors/keyboards
http://www.garlic.com/~lynn/2001.html#4 Sv: First video terminal?
http://www.garlic.com/~lynn/2001e.html#76 Stoopidest Hardware Repair Call?
http://www.garlic.com/~lynn/2002j.html#67 Total Computing Power
http://www.garlic.com/~lynn/2003c.html#46 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003c.html#77 COMTEN- IBM networking boxes
http://www.garlic.com/~lynn/2003c.html#79 COMTEN- IBM networking boxes
http://www.garlic.com/~lynn/2003d.html#13 COMTEN- IBM networking boxes
http://www.garlic.com/~lynn/2003d.html#59 unix
http://www.garlic.com/~lynn/2004l.html#1 Xah Lee's Unixism
http://www.garlic.com/~lynn/2004l.html#7 Xah Lee's Unixism
http://www.garlic.com/~lynn/2006e.html#38 The Pankian Metaphor

MS to world: Stop sending money, we have enough - was Re: Most ... can't run Vista

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: MS to world: Stop sending money, we have enough - was Re: Most ... can't run Vista
Newsgroups: alt.folklore.computers
Date: Wed, 03 Jan 2007 17:01:29 -0700
jmfbahciv writes:
Honey, some of the smartest people I know today are in the luser category. That's because they are not paid to be computer user experts.

a different kind of Boyd reference:
http://www.garlic.com/~lynn/2000e.html#35 War, Chaos, & Business (web site), or Col John Boyd

citing web page
http://www.belisarius.com/modern_business_strategy/mie/mie_33.htm
http://web.archive.org/web/20020217191358/http://belisarius.com/modern_business_strategy/moore/mie_33.htm

which has since morphed:
http://www.belisarius.com/
http://web.archive.org/web/20010722050327/http://www.belisarius.com/

from above:
"There are two career paths in front of you, and you have to choose which path you will follow. One path leads to promotions, titles, and positions of distinction.... The other path leads to doing things that are truly significant for the Air Force, but the rewards will quite often be a kick in the stomach because you may have to cross swords with the party line on occasion. You can't go down both paths, you have to choose. Do you want to be a man of distinction or do you want to do things that really influence the shape of the Air Force? To be or to do, that is the question." Colonel John R. Boyd, USAF 1927-1997

From the dedication of Boyd Hall, United States Air Force Weapons School, Nellis Air Force Base, Nevada. 17 September 1999


... snip ...

misc. past posts mentioning John Boyd
http://www.garlic.com/~lynn/subboyd.html#boyd
and various URLs from around the web mentioning John Boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2

DOS C prompt in "Vista"?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: DOS C prompt in "Vista"?
Newsgroups: alt.folklore.computers
Date: Wed, 03 Jan 2007 22:52:26 -0700
Eric Sosman <Eric.Sosman@sun.com> writes:
Not a clue. Atex still exists as a company, but has gone through multiple changes of ownership and focus and apparently has little resemblance to its 1970's and 1980's self. I doubt that they're still selling systems based on PDP-11 hot-rods.

at some point atex had been bought by kodak.

in this period, atex was running w/ingres on vax/vms platforms

Date: 06/15/90 12:06:37
To: distribution

KODAK AND IBM TO FORM PUBLISHING ALLIANCE

ROCHESTER and WHITE PLAINS, NY, June 15 . . . Eastman Kodak Company and IBM Corporation today announced an alliance to develop an open publishing systems architecture and a new generation of integrated, enterprise-wide publishing systems for newspapers and magazines worldwide.
Under this alliance, Kodak's Electronic Pre-Press Systems, Inc. (EPPS) subsidiary, particularly its Atex Publishing Systems units, and IBM's Media Industry Marketing intend to combine their technological expertise to establish and support a publishing systems architecture based on open industry standards.
This architecture will enable publishers to integrate their pre-press and business operations into an enterprise-wide publishing solution. Pre-press operations include the editorial, advertising and production activities that go into creating a newspaper or magazine. Business systems include circulation, finance, management reporting, and credit checking and billing for advertising.
IBM will provide technical, marketing, development and financial resources to this endeavor and will play an active role in strategic and operational activities. EPPS will provide its publishing-industry and applications-software expertise. Other terms of the agreement were not disclosed.
Kodak's John White, vice president and general manager, Integration and Systems Products Division, said, "The alliance with IBM will enable us to focus on imaging and publishing systems software, which is where we can add value for our customers. It's clear we both bring much to this alliance and have a lot to gain from the partnership."
Mark Elliott, vice president, General and Public Sector Industries at IBM, said, "Marrying IBM and Atex technologies clearly positions us to build on our international presence with newspaper and magazine customers by delivering state-of-the-art publishing systems and participating with the industry in the development of open standards."
EPPS President David Monks said, "What publishers are looking for are ways to integrate their pre-press and business operations to better manage growth and change."
"Through this new alliance, we will offer the architecture on which those enterprise-wide solutions can be based, and a variety of systems to meet specific pre-press and business requirements," Monks said.
Jonathan Seybold, a leading observer of publishing systems technology, said, "The industry has been looking for this kind of leadership around open systems architecture to stimulate new creative publishing solutions. This Atex/IBM alliance should be able to deliver the key products and solutions needed by the industry."


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

MS to world: Stop sending money, we have enough - was Re: Most ... can't run Vista

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: MS to world: Stop sending money, we have enough - was Re: Most ... can't run Vista
Newsgroups: alt.folklore.computers
Date: Thu, 04 Jan 2007 09:08:31 -0700
jmfbahciv writes:
Yes. I understand completely. It is very difficult to choose the todo path because nobody who has their standing in society in mind will allow you to keep doing. Rewards for doing a good job is invariably a promotion which moves you out of the pay level where the real work is done.

re:
http://www.garlic.com/~lynn/2007.html#20 MS to world: Stop sending money, we have enough - was Re: Most ... can't run Vista

actually the line i heard was more like "the best you can hope for is to not be fired and be allowed to do it again"

the other line .. is "heads roll uphill" ... or the reward for taking credit for a good job is a promotion.

How to write a full-screen Rexx debugger?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How to write a full-screen Rexx debugger?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 04 Jan 2007 09:21:34 -0700
Binyamin Dissen wrote:
By CP, I was referring to VM CP. Not TSO CP.

VM CP is a hypervisor which runs MVS as a client.


from long ago and far away, I had done IPCS superset written in rexx (when it was still called rex and hadn't been release as a product) ... which was initially line-mode CMS commands ... recent post mentioning dumprx (and old email from 1982)
http://www.garlic.com/~lynn/2007.html#18 IBM sues maker of Intel-based Mainframe clones

Relatively early, I enhanced dumprx to run as XEDIT macro ... using XEDIT fullscreen support to provide fullscreen operation. collected posts mentioning dumprx
http://www.garlic.com/~lynn/submain.html#dumprx

In 1976, the vm development group in the old SBC bldg. in Burlington Mall were told that they had to all move to POK to work on supporting MVS/XA development and there would be no more/new VM releases.

The (old) vm development group would be responsible for a new internal only virtual machine tool ("VMTOOL", that would never ship as a product) which was purely dedicated to MVS/XA development. Apparently corporate hdqtrs had been convinced that it was necessary to kill off vm370 in order for mvs/xa to be developed.

Endicott managed to salvage some of the situation and continue with VM product releases.

NOTE: "VMTOOL" is different from "VMTOOLS" ... "VMTOOL" was the internal only virtual machine facility supporting MVX/XA development; "VMTOOLS" was an network information and software distribution facility as well as computer conferencing, available on the internal network (implemented using TOOLSRUN)
http://www.garlic.com/~lynn/subnetwork.html#internalnet

supporting operations that included "mailing list" type operation as well as mechanism more akin to "usenet" news.

Date: 07/26/82 07:39:46
From: wheeler

re: UofM per; oh yes, the person who wrote the UofM per joined the VMTOOL group about 2-3 yrs ago. He wrote new PER support for the VMTOOL that has all the functions of OET. A major enhancement is that the VMTOOL has what is called CP EXEC files. Since the major purpose of the VMTOOL was going to be a MVS development vehicle ... the delivery of computing services had to be done primarily within the CP environement. The result was that an EXEC type processor and a new type of spool file was created. Valid CP commands now can be one of these CP EXEC files & as a result the type of things that can be invoked when a PER event occurs is much more sophisticated (i.e. a PER event can be the execution of any CP command ... which in the case of VMTOOL may be a CPEXEC file with lots of conditional testing logic).

re: page migration; I've significantly rewritten the logic in DMKPGM ... to include among other things the use of multiple page buffers. Biggest problems with the current implementation are 1) release 4 AP upgrade was incorrectly done, resulting in DMKPGM execution be serial, rather than concurrent (i.e. possible to have several invokations of PGM execution going on at the same time) and 2) only one physical page buffer is used per invokation (i.e. I/O is done sequentially one drum I/O followed by one disk I/O, and then the next drum I/O ... elapsed time to perform migration on large system can exceed 20 minutes).


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

A similar vm370 extended PER implementation had been done in 1980 (for internal vm370 installations) "DMKHSL" ... by the same person that had done parasite & story.



Date: 06/09/80  14:43:07
From: somebody at WINH5
To: wheeler

You can try this DMKHSL if like living dangerously -

The source is set up to use
          VMUSER1
as a pointer to an IFBLOK chain but any spare word in the VMBLOK
will do - it's only referanced in PRG and DMKHSL.

You will need to add a new entry to CFC for
"IF" and "WHEN" calling DMKHSLEN --- class G

It hooks into the existing PER mods
There is one mod to DMKPRG to call DMKHSLIH if there are active
IFBLOK's.

There is an entry point DMKHSLRL which will release the IFBLOK
Chain - but havn't got round to sorting out who should call it yet
on things like logoff force etc....

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

One of the issues was to take a flavor of dumprx that had access to symbolic definitions and use it for converting symbolic references to absolute addressed used by CP PER command.

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

page migration was one of the features of my resource manager (implemented in module DMKPGM). misc. collected posts mentioning various aspects of resource management
http://www.garlic.com/~lynn/subtopic.html#fairshare
and/or paging management
http://www.garlic.com/~lynn/subtopic.html#wsclock

misc. past posts mentioning VMTOOL and/or killing off of vm370 product in 1976.
http://www.garlic.com/~lynn/2001m.html#38 CMS under MVS
http://www.garlic.com/~lynn/2001m.html#47 TSS/360
http://www.garlic.com/~lynn/2001n.html#67 Hercules etc. IBM not just missing a great opportunity...
http://www.garlic.com/~lynn/2002e.html#27 moving on
http://www.garlic.com/~lynn/2002m.html#9 DOS history question
http://www.garlic.com/~lynn/2002p.html#14 Multics on emulated systems?
http://www.garlic.com/~lynn/2003g.html#22 303x, idals, dat, disk head settle, and other rambling folklore
http://www.garlic.com/~lynn/2004g.html#38 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004k.html#23 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of
http://www.garlic.com/~lynn/2004k.html#66 Question About VM List
http://www.garlic.com/~lynn/2004n.html#7 RISCs too close to hardware?
http://www.garlic.com/~lynn/2005d.html#3 IBM Acronyms
http://www.garlic.com/~lynn/2005f.html#58 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005f.html#59 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005j.html#25 IBM Plugs Big Iron to the College Crowd
http://www.garlic.com/~lynn/2005j.html#54 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2005s.html#35 Filemode 7-9?
http://www.garlic.com/~lynn/2006h.html#30 The Pankian Metaphor
http://www.garlic.com/~lynn/2006j.html#27 virtual memory
http://www.garlic.com/~lynn/2006l.html#25 Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)

How to write a full-screen Rexx debugger?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How to write a full-screen Rexx debugger?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 04 Jan 2007 09:36:12 -0700
Anne & Lynn Wheeler <lynn@garlic.com> writes:
from long ago and far away, I had done IPCS superset written in rexx (when it was still called rex and hadn't been release as a product) ... which was initially line-mode CMS commands ... recent post mentioning dumprx (and old email from 1982)
http://www.garlic.com/~lynn/2007.html#18 IBM sues maker of Intel-based Mainframe clones

Relatively early, I enhanced dumprx to run as XEDIT macro ... using XEDIT fullscreen support to provide fullscreen operation. collected posts mentioning dumprx
http://www.garlic.com/~lynn/submain.html#dumprx


and more old dumprx topic drift ... in the following, DUMPRX tended to be distributed to unique individual per (internal corporate) location ... since it was primarily used by system support personal.

using rex(x) as implementation language for DUMPRX aided in making it possible for other people to provide enhancements.

the following 8 (person) months estimate had at least 50percent contingency in the estimate. while DUMPRX was used extensively inside the company and more than justified any costs ... they were still looking for package price to completely cover all costs that had ever been associated with the effort.

Date: 06/16/86 10:27:43
From: wheeler

re: dumprx; IBM Canada is currently putting together a "canned" VM system that will have several features and be charged for. They have requested that DUMPRX be included in the canned system. They have requested total development resources for DUMPRX (for estimating price) ... I've estimated a total, maximum effort of DUMPRX at less than 8 months spread over the past 5 years ... including all development, test, distribution, production support, and release to release conversions ... that is for everybody, not just me, but everyone that has contributed any changes, fixes, &/or enhancements to DUMPRX. My direct distribution list for DUMPRX peaked at 130 people a couple of years ago ... prior to its availability on VMTOOLS ... that distribution list is now down to 108 people ... with an unknown number of people obtaining DUMPRX from VMTOOLS.


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

recent post with old email from 1982 with some sequence of originally creating dumprx, also mentioning dumprx was used as problem determination supporting the 3090 service processor (pair of 4361 machines running customized version of vm370 release 6)
http://www.garlic.com/~lynn/2007.html#18 IBM sues maker of Intel-based Mainframe clones

and slightly related recent mentioning dumprx (also some description of "VMTOOLS" facility)
http://www.garlic.com/~lynn/2007.html#23 How to write a full-screen Rexx debugger?

lots of past posts mentioning dumprx
http://www.garlic.com/~lynn/submain.html#dumprx

The History of Computer Role-Playing Games

Refed: **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The History of Computer Role-Playing Games...
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers
Date: Thu, 04 Jan 2007 09:57:21 -0700
previous posts in this thread:
http://www.garlic.com/~lynn/2006y.html#18 The History of Computer Role-Playing Games
http://www.garlic.com/~lynn/2006y.html#19 The History of Computer Role-Playing Games

old email mentioning ZORK

Date: 03/31/80 19:57:00
From: wheeler

re: ZORK; Barry Gold is not at MIT but at SHARE installation code RL (i'll have to look it up sometime), sorry about the wild goose chase around MIT. His statement on VMSHARE of 6/27/79, said he was going to have 370 ZORK available shortly. I've contacted him via VMSHARE and he has gotten caught up in a multitude of other VM activities. He is working from the DEC user group's FORTRAN version but claims that he had to get MIT approval to work on the source and would also require MIT approval to allow other installations to work on it (while he is busy with his other tasks). He isn't too hopeful since he has several other communications with MIT group that have gone unanswered for a long time and are still outstanding.


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

Melinda used to have source and executable on her home page ... re:
http://listserv.uark.edu/scripts/wa.exe?A2=ind9707&L=ibmvm&D=0&T=0&P=9631

but it no longer seems to be there.

MS to world: Stop sending money, we have enough - was Re: Most ... can't run Vista

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: MS to world: Stop sending money, we have enough - was Re: Most ... can't run Vista
Newsgroups: alt.folklore.computers
Date: Thu, 04 Jan 2007 10:02:39 -0700
Anne & Lynn Wheeler <lynn@garlic.com> writes:
actually the line i heard was more like "the best you can hope for is to not be fired and be allowed to do it again"

the other line .. is "heads roll uphill" ... or the reward for taking credit for a good job is a promotion.


re:
http://www.garlic.com/~lynn/2007.html#20 MS to world: Stop sending money, we have enough - was Re: Most ... can't run Vista
http://www.garlic.com/~lynn/2007.html#22 MS to world: Stop sending money, we have enough - was Re: Most ... can't run Vista

the other line used was they could have forgiven me for being wrong, but they were never going to forgive me for being right.

Securing financial transactions a high priority for 2007

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Thu, 04 Jan 2007 10:25:45 -0700
jmfbahciv writes:
So it takes a day to sort out the error. Who gets the float?

not so much the error ... but countermeasures to possible fraud.

previous posts
http://www.garlic.com/~lynn/2007.html#5 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007.html#6 Securing financial transactions a high priority for 2007

however ... somewhat related posts
http://www.garlic.com/~lynn/2006k.html#23 Value of an old IBM PS/2 CL57 SX Laptop
http://www.garlic.com/~lynn/2006l.html#37 Google Architecture
http://www.garlic.com/~lynn/2006v.html#42 On sci.crypt: New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006w.html#4 Patent buster for a method that increases password security

and some discussion about who is getting what ...

Interchange Fees: The tipping point
http://www.cyberwarzone.com/united-states-leaking-1tb-data-daily-foreign-countries

from above
Fed up with out-of-control interchange fees, retailers are fighting back with concerted legal and educational tactics -- and, in some cases, proactive offensives of their own.

... snip ...


http://www.epaynews.com/newsletter/epaynews322.html

from above:
Convenience store operators can make more money on a 12-ounce cup of coffee than they can on a 12-gallon tank of gas. Credit card fees now account for almost half of a typical store's expenses - more than labor.

... snip ...

Payments Technologies Vie For Banks' IT Dollars
http://web.archive.org/web/20060526221137/http://www.epaynews.com/index.cgi?survey=&ref=browse&f=view&id=1147439455861413176&block=

from above:
Payments revenues at European banks typically represent 10 per cent of annual revenues, while in the US, this figure is nearer to 40 per cent

... snip ...

Securing financial transactions a high priority for 2007

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Thu, 04 Jan 2007 10:44:18 -0700
previous posts in thread:
http://www.garlic.com/~lynn/2007.html#5 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007.html#6 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007.html#27 Securing financial transactions a high priority for 2007

for other topic drift

Faster payments should not result in weaker authentication
http://www.securitypark.co.uk/article.asp?articleid=26294&CategoryID=1

from above:
The 11 faster payments member banks are progressing rapidly with their implementation projects ahead of the November 2007 deadline. However, as the systems being developed will enable a payment to be processed in less than 15 seconds, there is no time to stop a payment, and adequate authentication of the transactions becomes critical.

... snip ...

when we did the payment gateway as part of this stuff that came to be called e-commerce ... we had some stats on how fast a transaction turned around at the payment gateway; thru the payment network and back (that was separate from any transit delays thru the Internet between the webservers and the payment gateway) ... the avg. ran between 200-300 milliseconds.

recent post mentioning payment gateway
http://www.garlic.com/~lynn/2007.html#15 SSL info

one of the early aads chip strawman objectives (in the 90s) was to be able to meet the transit 200millisecond requirement in contactless form factor and contactless power profile
http://www.garlic.com/~lynn/x959.html#aads

for x9.59 like transaction
http://www.garlic.com/~lynn/x959.html#x959

Just another example of mainframe costs

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Just another example of mainframe costs.
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 04 Jan 2007 14:01:57 -0700
John.Mckown@ibm-main.lst (McKown, John) writes:
Our SAN boxes do this on Fibre Channel as well. Hum, I am not sure about the multipathing. From some discussion on the z/Linux forum about FCP (Fibre Channel) I think it is supported. In any case, the "open" DASD are still cheaper per megabyte that the exact same boxes which are Ficon (with ECKD emulation).

in part because of our work on ha/cmp product
http://www.garlic.com/~lynn/subtopic.html#hacmp

and having been asked to author section in corporate continuous strategy document,
http://www.garlic.com/~lynn/submain.html#available

i also got called into design walkthru on various raid product designs ... looking for gatcha's that they had overlooked (from integrity standpoint).

recent post mentioning fcs, hippi, escon, ficon, etc:
http://www.garlic.com/~lynn/2006b.html#14 Expanded Storage
http://www.garlic.com/~lynn/2006c.html#1 Multiple address spaces
http://www.garlic.com/~lynn/2006c.html#40 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006i.html#34 TOD clock discussion
http://www.garlic.com/~lynn/2006l.html#43 One or two CPUs - the pros & cons
http://www.garlic.com/~lynn/2006m.html#52 TCP/IP and connecting z to alternate platforms
http://www.garlic.com/~lynn/2006p.html#46 "25th Anniversary of the Personal Computer"
http://www.garlic.com/~lynn/2006q.html#24 "25th Anniversary of the Personal Computer"
http://www.garlic.com/~lynn/2006u.html#19 Why so little parallelism?
http://www.garlic.com/~lynn/2006v.html#10 What's a mainframe?
http://www.garlic.com/~lynn/2006x.html#3 Why so little parallelism?
http://www.garlic.com/~lynn/2006x.html#11 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006x.html#13 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006x.html#15 The Future of CPUs: What's After Multi-Core?

compared to when this was written, standard drive reliability has increased by at least an order of magnitude.

Date: Thu, 23 Aug 90 15:35:31 EST
From: wheeler
To: someplace on the east coast

Somebody you apparently know called me yesterday and said he was looking for background information on hippi, fcs, etc.

I believe he left the conversation with some misunderstandings. I mentioned disk arrays, ipi3 over hippi, fcs, etc. I explained disk arrays to him and parity drives in an 8-for-9 configuration representing no single point of failure. He disagreed. He said that he study the subject and the best correcting codes could do was on the order of 3 correcting bits for 8 bits of data.

He misunderstanding is at several levels. First, the parity drive isn't to detect errors. Each drive has significant embedded error detection/correction capability. The parity drive handles the situation where the drive is reported as bad. All the standard, run-of-the-mill disk technology is used to indicate whether data coming from a drive is good or bad (or even if you are getting any data at all from the drive). It is only once that standard disk technology identifies which block of data is bad ... then RAID technology takes over and is able to use the parity drive to recreate the original record (including the missing piece from the bad drive). A 8-for-9 RAID configuration is able to withstand a single point of failure and still reconstruct the data. In the worst case, a whole drive fails (and standard disk technology identifies that the drive has failed). Information from the parity drive and the remaining 7 data drives are able to reconstruct the missing piece of data.

The same-principle works even in a 16-for-17 configuration. The single parity drive is able to reconstruct data from a single missing drvie. However, as the number of drives increase in a RAID configuration, the probability increases that there would be multiple simultaneous failures. In the Thinking Machines "Data Vault", where they make use of 32 parallel drives (32 drives spinning and having the appearance of a single drive that has 32 times the capacity and 32 times the transfer rate), there are actually 40 drives in the configuration. Five drives are used as "ECC" drives, and three drives are "spare", that are available for electronicly swap/switching into the configuration (in the place of a defective drive). As part of a spare-drive "swap-in", the data on the defective disk is recreated (in the background) and written to the new substitute drive.

The other comment (after further discussion) was that the drive failure is so improbable that it isn't worth doing. It is worth doing in large number of cases. Assuming a decent data base configuration (we had one such customer in today) that has 1.5 terabytes of data spinning in a single machine room. In a RAID configuration, you can take off the shelf Imprimus 1.5gbyte, 5.25in drives that spins at 5400 rpm and has well under 12millisecond avg. access. 4 of these drives can go in a drawer and you can have seven drawers in a rack. This provides for 28 drives, three "8-for-9" logical drives, with a single spare drive. Effectively there are 36gbytes in a single rack. Approximately 45 such racks (1000 data drvies + 250 parity drives = 1250 drives) provide 1.5 terabytes of data such racks. The base quantity price for the Imprimus drive is around $4k, resulting in a little over $5m for the Imprimus disk costs. Assuming a nominal conservative 80k hours for drive MTBF & a uniform failure distribution, then one would expect a drive failure (somewhere in the complex) on the avg. of once every 60 hours. It actually isn't a uniform failure distribution, so observed failure rate would be somewhat better ... but still quite frequently.

Finally, I'm not sure that he has been keeping up with things like various foward-error-correcting codes, like Reed-Solomon. For the High-Speed Data Transport project (there are a number of papers on the project that I wrote), we were dealing with Cyclotomics which is a leading outside vendor in the area. 15/16ths Reed-Solomon encoding (i.e. 15 data bits of 16 total bits) can provide six orders of magnitude improvement in the bit error rate. In some of the media that we were looking at with BER rates in the 10**-9 range, 15/16ths Reed-Solomon encoding provides the appearance of 10**-15 BER. Simple things like the whole compact disk market is using digital FEC encoding.

in any case, you might like to talk to him ... and bring him a little bit better up to-date on technology


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

other posts mentioning HSDT project
http://www.garlic.com/~lynn/subnetwork.html#hsdt

for some drift ... past posts mentioning doing work in disk engineering and product test labs (bldg. 14 & 15 on san jose plant site)
http://www.garlic.com/~lynn/subtopic.html#disk

other posts mentioning reed-solomon
http://www.garlic.com/~lynn/93.html#28 Log Structured filesystems -- think twice
http://www.garlic.com/~lynn/99.html#115 What is the use of OSI Reference Model?
http://www.garlic.com/~lynn/99.html#210 AES cyphers leak information like sieves
http://www.garlic.com/~lynn/2000c.html#38 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2001b.html#80 Disks size growing while disk count shrinking = bad performance
http://www.garlic.com/~lynn/2001k.html#71 Encryption + Error Correction
http://www.garlic.com/~lynn/2002p.html#53 Free Desktop Cyber emulation on PC before Christmas
http://www.garlic.com/~lynn/2003e.html#27 shirts
http://www.garlic.com/~lynn/2003h.html#3 Calculations involing very large decimals
http://www.garlic.com/~lynn/2003j.html#73 1950s AT&T/IBM lack of collaboration?
http://www.garlic.com/~lynn/2004f.html#37 Why doesn't Infiniband supports RDMA multicast
http://www.garlic.com/~lynn/2004h.html#11 Mainframes (etc.)
http://www.garlic.com/~lynn/2004o.html#43 360 longevity, was RISCs too close to hardware?
http://www.garlic.com/~lynn/2005k.html#25 The 8008
http://www.garlic.com/~lynn/2005n.html#27 Data communications over telegraph circuits
http://www.garlic.com/~lynn/2005r.html#52 Go-Back-N protocol?
http://www.garlic.com/~lynn/2005t.html#50 non ECC
http://www.garlic.com/~lynn/2006u.html#44 waiting for acknowledgements
http://www.garlic.com/~lynn/2006u.html#45 waiting for acknowledgements

V2X2 vs. Shark (SnapShot v. FlashCopy)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: V2X2 vs. Shark (SnapShot v. FlashCopy)
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 04 Jan 2007 19:56:39 -0700
glenn.miller writes:
My comment about the STK Log Structured Array ( LSA ) mechanism was a comparison to all the other mainframe DASD vendors ( IBM, HDS & EMC ). The STK LSA is a method of storing the data internally within the DASD subsystem. As far as I know, no other mainframe DASD vendor used ( the IBM RVA doesn't count, it was a 'newer' STK ICEBERG with an IBM label on the cover of the machine ) the LSA concept to internally store the data.

DFSMShsm Fast Replication Technical Guide
http://www.redbooks.ibm.com/redbooks/pdfs/sg247069.pdf

from above:
The source volumes within a storage group can span logical subsystems, physical subsystems, or both.

With ESS FlashCopy Version 2, the source volumes can be in different Logical Subsystems within the same Storage Subsystem.

Because the ESS is not a Log Structured Array (LSA) device, but rather uses Home Area method, the use of multiple backup versions means that physical space will be consumed by this approach. On the RVA, in contrast, its LSA technology means that the backup versions only take a small fraction of extra physical space.


... snip ...

for drift ... some old email with old mention of log structured filesystem studies.

Date: 4 October 1991, 15:48:12 PDT
From: wheeler

Subject: nasa/ames

I've got a call to provide more detailed information to nasa/ames on

1) unitree
2) hippi
3) disk arrays

They've requested a meeting here in lsg the afternoon of the 14th. There was some question would we see some of the nasa/ames at ieee mss in monterey ... I'm not sure how much time we will be at the ieee meeting since we have work to do as well as both UK social security department and Sanwa back coming in next week.

Also the nasa/ames meeting the following week interfers with attendance at sosp '91 in asilimor on the 13th-16th. It is too bad that it isn't the 15th ... I would drive back up and stay for the MIPS presentation. This means I'll effectively be commuting back&forth between here and monterey some good part of next week and the week after.

..... reference .....

Newsgroups: ibm.ibmunix.unixnews
Date: 4 Oct 91 17:30:26 GMT

... this is being cross posted with netwrkng.forum on chaste and unixnews.forum on ibmunix xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Note that AIX/EXPO was this week at the Santa Clara Convention Center. We also held the HA/6000 class for IBM/US at the Sunnyvale AIX Porting this week.

Because of conflicts over the HA/6000 presentation at AIX/EXPO and the class, I've missed the ANSI X3S3.3 HSP and XTP/TAB meetings in Boulder this week. During a disclosure that I gave to Nasa/Ames this week at AIX/EXPO, Eugene was there. He asked me if I could bring some interesting toys (for a conference) ... he also mentioned that he has gotten a full-size skyboard VR system (board, feedback, wrap-around image, etc).

There were a couple of vendor products that were of interest at AIX/EXPO ... one especially for HA/6000 was a SCSI RAID3/RAID5 (configurable) product with dual-power supplies and two SCSI bus interfaces (i.e. could be connected to two different SCSI buses ... going to two different processors ... and as such doesn't get into the power on/off glitches). Controller supports up to seven 4-for-5 banks (i.e. seven logical RAID5 drives, ... 35 drives total). Claimed performance for a 5 drive RAID5 configuration with 1024 byte sector size and 4:1 read-to-write ratio is 425 I/Os per second.

Also note, next week Interop '91 is at the Santa Clara Convention Center. Also, next week, the RISC/6000 shrink-wrap Unitree will be on display at the IEEE MSS meeting in Monterey. As an aside, the XTP/TAB members will be out in force during the 14th-17th in Minneapolis.

I've managed to be busy/miss every SOSP since we had that last business meeting at SOSP/Asilomar and decided that it would be fairer to the east coast students if the meetings were rotated between coasts

Looks like one could spend almost the whole fall going to interesting activities. Unfortunately, we leave for Hong Kong on the 24 for the HA/6000 class for APG ... and then on to Sydney the following week for a week HA/6000 class for IBM Australia. I would like to hear from anybody planning on attending Allison's pitch on the 24th.

xxxxxxxxxxxxxxxxxxxxxxxxxxx

11th IEEE Symp. on Mass Storage Systems, Oct. 7-10, Monterey, Calif. Sponsor: IEEE Computer Soc. Technical Committee on Mass Storage Systems and Tech. Contact Bernard T. O'Lear, NCAR, PO Box 3000, Boulder, CO 80307, phone (303) 497-1268, fax (303) 497-1137.

xxxxxxxxxxxxxxxxxxxxxxxxxxx

SOSP '91 13th ACM Symposium on Operating Systems Principles

Asilomar Conference Center, Pacific Grove, Ca., Oct 13-16, 1991

10/14

File Systems
The Design and Implementation of a Log-structured file system
Virtual Directories for Intelligent File systems

Shared Memory Multiprocessing
The Implications of Cache Affinity on Processor Scheduling for multiprogrammed shared memory multiprocessors
Empirical Studies of competitive spinning for shared-memory multiprocessors

Multimedia systems
A High Performance Multi-structured file system design
Scheduling and IPC Mechanisms for Continuous media
Designing file systems for digital video and audio

Panel Discussions
Increasing the effectivenes of operating system research

10/15

Kernel Structure
Scheduler activations: effective kernel support for user-level management of parallelism
First-class User-level threads
Continuations: Unifying thread management and communication in operating system

Distributed Memory Multiprocessing
Tuning NUMA Memory Management for Applications and architecture
Implementation and Performance of Munin

Networking and Authentication
Authentication in distributed systems: theory and practice
Automatic reconfiguration in autonet

10/16

File Systems II
Measurements of a distributed file system
Disconnected operation in the Coda File System

Reliability in Distributed Systems
Replication in the Harp File System
Experience with Transactions in Quicksilver

xxxxxxxxxxxxxxxxxxxxxxxxxxx

16th Annual Conference on Local Computer Networks

Oct. 14-17, 1991, Minneapolis, Minn. Sponsored by the IEEE Computer Society

Wed, 10/16

10:30-12 Panel: Data Networking Trends in the 90's FDDI-A Token Ring on UTP

1:30-3 Panel: LAN Interconnection Gigabit Networks Internetworking

3:30-5 Panel: Gigabit Networks Interconnection LANs ATMs

Thur, 10/17

8:30-10 Panel: Multi-Protocol Routers Wireless LANs Real Time/XTP

10:30-12 Panel: FDDI Network Management High Speed Protocols

1:30-3 Panel: Bridges or Routers? Integrated Services Networks FDDI-B

3:30-5 LAN Technology Performance Applications

xxxxxxxxxxxxxxxxxxxxxxxxxxxx

SCV/Computer

The MIPS R4000: 1000 MHz and 64 Bits or Bust!

John Mashey is vice president, systems technology at MIPS Computer Systems, Inc., and he is responsible for long-range product planning and technical direction for his company's marketing and sales. He is also the featured speaker for the October 15 meeting of the Santa Clara Valley Computer Society. He will talk about the MIPS R4000.

The presentation will look at recent progress in microprocessors, focusing especially on the MIPS R4000. The R4000 is a superpipeline 1.3-million transistor chip that includes on-chip caches, floating point, 64-bit integer unit, and control for two-level writeback caches with support for many cache coherency protocols.

Mashey will describe the chip and especially the rationale for some of the design choices. He will also touch on the ACE initiative and the R4000's relationship to it. Samples of the R4000 will be available for viewing.

Proior to joining MIPS in 1986, John Mashey was directory of software engineering for the data systems division of Convergent Technologies. Before that he spent 10 years with Bell Labs where he was a key contributor to the design and development of the Programmers Workbench version of UNIX. Mashey has been an ACM National Lecturer and is a leading speaker on UNIX and RISC. He earned his PhD in computer science from Penn State.


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

V2X2 vs. Shark (SnapShot v. FlashCopy)

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: V2X2 vs. Shark (SnapShot v. FlashCopy)
Newsgroups: alt.folklore.computers,bit.listserv.ibm-main
Date: Fri, 05 Jan 2007 11:13:38 -0700
Anne & Lynn Wheeler <lynn@garlic.com> writes:
Date: 4 October 1991, 15:48:12 PDT
From: wheeler

Subject: nasa/ames

I've got a call to provide more detailed information to nasa/ames on

1) unitree 2) hippi 3) disk arrays

They've requested a meeting here in lsg the afternoon of the 14th. There was some question would we see some of the nasa/ames at ieee mss in monterey ... I'm not sure how much time we will be at the ieee meeting since we have work to do as well as both UK social security department and Sanwa back coming in next week.

Also the nasa/ames meeting the following week interfers with attendance at sosp '91 in asilimor on the 13th-16th. It is too bad that it isn't the 15th ... I would drive back up and stay for the MIPS presentation. This means I'll effectively be commuting back&forth between here and monterey some good part of next week and the week after.


re:
http://www.garlic.com/~lynn/2007.html#30 V2X2 vs. (SnapShot v. FlashCopy)

and some other ha/cmp activities going on the the month of oct91
http://www.garlic.com/~lynn/subtopic.html#hacmp

re:
http://www.garlic.com/~lynn/2006w.html#20 cluster-in-a-rack

following email is prelude to the FSD meeting mentioned here
http://www.garlic.com/~lynn/2006w.html#email911119

Date: Thu, 03 Oct 91 10:22:23
From: someplace on the eastcoast
To: wheeler

Lynn,

XXXXXX and I wish to talk with you about Medusa. We are working on massively parallel processing, and what IBM approach may be suitable for DARPA. I was unable to get a message left with your phone mail, so this note will alert you to our interest. We will attempt to call you at 8:30 your time.


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

and another MEDUSA, cluster-in-a-rack email related to this subsequent email
http://www.garlic.com/~lynn/2006w.html#email911024

Date: 5 October 1991, 09:31:08 CDT
From: someplace in austin
To: wheeler

I would like to get together Monday to discuss strategy.

For software I think we need to take a phased approach ranging from
1) The first phase would then be the minimum that a Alpha test customer would require to be successful (someone like LLNL or Sandia)
N) The last phase would be the blown 'everything you ever wanted' in Medusa software support

I believe this would let us concentrate on the first phase.

We also need to develop a software test plan for phase 1

I believe it would be VERY good if we could include this as part of the 10/10 review.


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

and reference to commercial (as opposed to numerical intensive) market possibility
http://www.garlic.com/~lynn/95.html#13
http://www.garlic.com/~lynn/96.html#15
http://www.garlic.com/~lynn/2001n.html#83

and other past posts with reference to MEDUSA &/or cluster-in-a-rack
http://www.garlic.com/~lynn/2006w.html#13 IBM sues maker of Intel-based Mainframe clones
http://www.garlic.com/~lynn/2006w.html#14 IBM sues maker of Intel-based Mainframe clones
http://www.garlic.com/~lynn/2006w.html#26 Why so little parallelism?
http://www.garlic.com/~lynn/2006w.html#38 Why so little parallelism?
http://www.garlic.com/~lynn/2006w.html#39 Why so little parallelism?
http://www.garlic.com/~lynn/2006w.html#40 Why so little parallelism?
http://www.garlic.com/~lynn/2006w.html#41 Why so little parallelism?

and posting with old email from just prior to being told that the effort was being transferred and we weren't suppose to work on anything with more than four processors:
http://www.garlic.com/~lynn/2006x.html#3 Why so little parallelism?

V2X2 vs. Shark (SnapShot v. FlashCopy)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: V2X2 vs. Shark (SnapShot v. FlashCopy)
Newsgroups: alt.folklore.computers,bit.listserv.ibm-main
Date: Fri, 05 Jan 2007 11:46:52 -0700
Anne & Lynn Wheeler <lynn@garlic.com> writes:
1) unitree
2) hippi
3) disk arrays


re:
http://www.garlic.com/~lynn/2007.html#30 V2X2 vs. Shark (SnapShot v. FlashCopy)
http://www.garlic.com/~lynn/2007.html#31 V2X2 vs. Shark (SnapShot v. FlashCopy)

a couple recent posts mentioning various filesystem management infrastrcuture
http://www.garlic.com/~lynn/2006u.html#27 Why so little parallelism?
http://www.garlic.com/~lynn/2006v.html#10 What's a mainframe?

an old email with another passing mention of unitree

Date: Mon, 18 Jun 90 15:44:15 -0700
From: wheeler

I (basically) have a internet shadow via ftp/anonymous on "wheeler" .... previously wheeler.austin and now wheeler.lsg. It includes most of the gnu stuff, psk bit maps, most of the project athena stuff ... along with lots of other things from around the internet.

For instance, Austin got both Kerberos and gnumake from "wheeler". Also, apparently aix/370 development group has just recently discovered Kerberos ... and because of the way (at least some of the) aixnet routers are set-up ... austin subnets can access wheeler.lsg, but the aix/370 group's subnets (ip-addresses) can't get at wheeler.lsg (our security is so good, that even ip subnets that we would like to have access, can't get thru).

I finally had to tar/compress all the kerberos stuff and binary/upload to VM and then send it off to aix/370 group.

aix/370 group needs Kerberos for (at least):

1) NFS/project Athena access
2) standard NFS 2.0 supporting Kerberos
3) AFS/Kerberos support
4) Unitree/Kerberos support


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

for some drift ... collected posts mentioning kerberos and/or pk-init
http://www.garlic.com/~lynn/subpubkey.html#kerberos

for other drift, some posts mentioning having done the original CMSBACK, precursor to current TSM (renamed from ADSM)
http://www.garlic.com/~lynn/submain.html#backup

aix/370 (along with aix/ps2) was productized version of UCLA's Locus. misc. past posts mentioning locus:
http://www.garlic.com/~lynn/99.html#2 IBM S/360
http://www.garlic.com/~lynn/99.html#63 System/1 ?
http://www.garlic.com/~lynn/99.html#64 Old naked woman ASCII art
http://www.garlic.com/~lynn/2000.html#64 distributed locking patents
http://www.garlic.com/~lynn/2000c.html#8 IBM Linux
http://www.garlic.com/~lynn/2000d.html#68 "all-out" vs less aggressive designs
http://www.garlic.com/~lynn/2000d.html#69 "all-out" vs less aggressive designs
http://www.garlic.com/~lynn/2000e.html#20 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2000e.html#27 OCF, PC/SC and GOP
http://www.garlic.com/~lynn/2001.html#44 Options for Delivering Mainframe Reports to Outside Organizat ions
http://www.garlic.com/~lynn/2001.html#49 Options for Delivering Mainframe Reports to Outside Organizat ions
http://www.garlic.com/~lynn/2001f.html#20 VM-CMS emulator
http://www.garlic.com/~lynn/2001f.html#22 Early AIX including AIX/370
http://www.garlic.com/~lynn/2001l.html#17 mainframe question
http://www.garlic.com/~lynn/2002b.html#36 windows XP and HAL: The CP/M way still works in 2002
http://www.garlic.com/~lynn/2002d.html#31 2 questions: diag 68 and calling convention
http://www.garlic.com/~lynn/2002h.html#65 Bettman Archive in Trouble
http://www.garlic.com/~lynn/2002i.html#54 Unisys A11 worth keeping?
http://www.garlic.com/~lynn/2002i.html#81 McKinley Cometh
http://www.garlic.com/~lynn/2002j.html#36 Difference between Unix and Linux?
http://www.garlic.com/~lynn/2002n.html#67 Mainframe Spreadsheets - 1980's History
http://www.garlic.com/~lynn/2002o.html#40 I found the Olsen Quote
http://www.garlic.com/~lynn/2002p.html#45 Linux paging
http://www.garlic.com/~lynn/2003d.html#8 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003d.html#54 Filesystems
http://www.garlic.com/~lynn/2003h.html#35 UNIX on LINUX on VM/ESA or z/VM
http://www.garlic.com/~lynn/2003h.html#45 Question about Unix "heritage"
http://www.garlic.com/~lynn/2003h.html#52 Question about Unix "heritage"
http://www.garlic.com/~lynn/2003o.html#49 Any experience with "The Last One"?
http://www.garlic.com/~lynn/2004d.html#72 ibm mainframe or unix
http://www.garlic.com/~lynn/2004h.html#41 Interesting read about upcoming K9 processors
http://www.garlic.com/~lynn/2004h.html#42 Interesting read about upcoming K9 processors
http://www.garlic.com/~lynn/2004n.html#12 XML: The good, the bad, and the ugly
http://www.garlic.com/~lynn/2004n.html#30 First single chip 32-bit microprocessor
http://www.garlic.com/~lynn/2004q.html#37 A Glimpse into PC Development Philosophy
http://www.garlic.com/~lynn/2004q.html#38 CAS and LL/SC
http://www.garlic.com/~lynn/2004q.html#39 CAS and LL/SC
http://www.garlic.com/~lynn/2005b.html#22 The Mac is like a modern day Betamax
http://www.garlic.com/~lynn/2005f.html#28 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005h.html#5 Single System Image questions
http://www.garlic.com/~lynn/2005j.html#26 IBM Plugs Big Iron to the College Crowd
http://www.garlic.com/~lynn/2005q.html#14 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005q.html#26 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005q.html#49 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005s.html#34 Power5 and Cell, new issue of IBM Journal of R&D
http://www.garlic.com/~lynn/2005t.html#19 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005u.html#61 DMV systems?
http://www.garlic.com/~lynn/2006b.html#8 Free to good home: IBM RT UNIX
http://www.garlic.com/~lynn/2006c.html#11 Mainframe Jobs Going Away
http://www.garlic.com/~lynn/2006q.html#4 Another BIG Mainframe Bites the Dust

Just another example of mainframe costs

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Just another example of mainframe costs.
Newsgroups: bit.listserv.ibm-main
Date: Fri, 05 Jan 2007 15:19:39 -0700
Bob.Richards@SUNTRUST.COM (Richards.Bob) writes:
That is exactly WHY the z9 can be cost effective in the right circumstances using Linux under z/VM. Heck, even z/OS competes well today against WebSphere/UDB under AIX with the advent of zAAPs and zIIPs.

... various news items (this week) on the subject has somewhat been all over the place

Mainframe review 2006
http://searchdatacenter.techtarget.com/originalContent/0,289142,sid80_gci1236947,00.html
IBM| Analyst reports find IBM mainframe more cost efficient than other platforms
http://www.prdomain.com/companies/I/IBM/newsreleases/2006122938279.htm
IBM Mainframe Offers Unmatched Security and Power Efficiency
http://www.huliq.com/4460/ibm-mainframe-offers-unmatched-security-and-power-efficiency
Big Blue cheaper than Red Hat
http://www.computerworld.com.au/index.php/id;1059308317
Big Blue cheaper than Red Hat, says research firm
http://computerworld.com/action/article.do?command=viewArticleBasic&taxonomyName=hardware&articleId=9006994&taxonomyId=12
IBM and Business Partners Realize Significant Growth on the Mainframe and Linux
http://www.verivox.de/News/ArticleDetails.asp?aid=41245&pm=1
Analyst Praises IBM Mainframe
http://news.tmcnet.com/news/2007/01/03/2212991.htm
IBM System z Mainframe a Rising Star for Emerging IT Market Segments
http://www.itnewsonline.com/showstory.php?storyid=7848&scatid=8&contid=3
Year of the Mainframe? Not Quite, Say Linux Grids
http://linux.slashdot.org/linux/07/01/05/0538224.shtml
Linux grid takes out firm's aging mainframe
http://searchopensource.techtarget.com/originalContent/0,289142,sid39_gci1237399,00.html

SSL info

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: SSL info
Newsgroups: alt.computer.security
Date: Fri, 05 Jan 2007 21:09:35 -0700
Ertugrul Soeylemez <never@drwxr-xr-x.org> writes:
Besides the fact that a certificate contains a bit more information, what are the privacy implications? Unless the certificate represents something like an electronic form of your passport, you decide, what goes in there. When the CA decides to sign it, then they do so. Otherwise you're free to go elsewhere.

Now to the security part: A public key, as its name states, is made publicly available. If that does reduce security, then what's the point in public key cryptography? The authenticator really just needs the public key to verify authenticity. A certificate is nothing more than an encapsulated public key, together with some informations about its holder, and one or more signatures (at least from a CA in the proper case).


so you have a client that generates a public/private key pair. the client registers the public key with the server/certification authority ... the server/ca registers the public key in the server/ca database ... then the server/ca generates a digital certificate containing the public key and gives a copy of the digital certificate to the client..

now in an authentication operation, the client digital signs something, appends the digital certificate and transmits the digital signature and digital certificate to the server/ca ... who already has a copy of the client's public key on-file.

since the server/ca already has a copy of the client's public key (as part of the registration operation) ... and, in fact, the server/ca probably even recorded the original of the client's digital certificate. that means the server/ca not only has the client's public key as well the client's digital certificate.

requiring the client to return a copy of the digital certificate to the ca/server on each digital signature operation is redundant and superfluous ... when the ca/server already has copy of the client's public key and typically also has the client's original digital certificate (after having sent a copy of the client's digital certificate to the client).

the ca/server would also run much more efficiently if they just used the onfile client's public key that they already have to verify the client's digital signature ... rather than having to go thru the repeated extraneous gorp of verifying the (appended transmitted) client digital certificate along with all the related digital certificate encoding/decoding magic.

past posts in this thread:
http://www.garlic.com/~lynn/2007.html#7 SSL info
http://www.garlic.com/~lynn/2007.html#15 SSL info
http://www.garlic.com/~lynn/2007.html#17 SSL info

as mentioned before ... one of the reasons for the retrenching from the early 90s x.509 identity digital certificates to the relying-party-only digital certificates in the mid-90s ... was eliminating all the extraneous personal information. It isn't so much the publication of public key that was the issue ... it was spraying personal information all over the place every time the digital certificate was transmitted.

Reducing the digital certificate to public key and some sort of (server) record locator ... is the relying-party-only digital certificate
http://www.garlic.com/~lynn/subpubkey.html#rpo

however, it is straight-forward to demonstrate that it is much more efficient and drastically simpler for the relying party to directly retrieve the public key from an online record, eliminating all of the client digital certificate gorp ... i.e. certificate-less public key
http://www.garlic.com/~lynn/subpubkey.html#certless

so comparing simple certificate-less digital signature authentication to password authentication

1) well implemented digital signature authentication is immune from skimming/eavesdropping and replay attacks (impersonation)

2) typically password scenarios require a unique value for every different security domain. the problem is that the same value is used for both origination and verification. unique passwords are countermeasure for scenarios where one domain can attack another (i.e. local garage isp and your online banking or your place of business).

there is huge advantage of using public keys (and digital signatures) for authentication ... compared to pins/passwords. this is true regardless of whether it is a certificate or certificate-less paradigm.

however, sometimes there is misconception that public keys and digital certificates are equivalent.

digital certificates are mechanism for trusted information distribution for the offline environment ... somewhat the electronic version of letters of introduction/credit from the sailing ship days ... when two entities were strangers and had no prior relations .... and the relying party(s) had no way of directly contacting any certifying party.

However when it becomes abundantly evident that the offline paradigm digital certificates are redundant and superfluous in an online world ... and/or between entities that have established relationship ... then it doesn't have to follow that there is no advantage to having public key infrastructure (without digital certificates).

V2X2 vs. Shark (SnapShot v. FlashCopy)

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: V2X2 vs. Shark (SnapShot v. FlashCopy)
Newsgroups: alt.folklore.computers,bit.listserv.ibm-main
Date: Sat, 06 Jan 2007 08:10:19 -0700
somewhat related post here
http://www.garlic.com/~lynn/2007.html#29 Just another example of mainframe costs

with lots of old post referencing hippi, fcs, escon, ficon, etc and long email from aug90
http://www.garlic.com/~lynn/2007.html#email900823

while hippi may have been more expensive than scsi ... for scale-up with various kinds of raid .... really large aggregation of (inexpensive) raid disks could be handled by hippi ... and the disk prices (price/mbyte) would dominate.

part of the issue with some of the more complex file management infrastructure is also the scaleup when you have hundreds and/or possibly thousands of drives. keeping track of what was actually needed on disk. unitree and some of the others ... referred to here
http://www.garlic.com/~lynn/2006v.html#10 What's a mainframe?

sort of started at the high-end having to deal with such management issues.

I had started with somewhat similar position when i originally implemented CMSBACK in the late 70s ... starting out as purely backup/archive operation ... not integrated into filesystem workings. However, CMSBACK went thru quite a bit of evolution ... workstation datasave facility, ADSM, and now the current TSM (tivolli storage management)
http://www.garlic.com/~lynn/2006v.html#24 Z/Os Storage Mgmt products

lots of past posts referring to work on CMSBACK and related activity
http://www.garlic.com/~lynn/submain.html#backup

other posts in the thread:
http://www.garlic.com/~lynn/2007.html#30 V2X2 vs. Shark (SnapShot v. FlashCopy)
http://www.garlic.com/~lynn/2007.html#31 V2X2 vs. Shark (SnapShot v. FlashCopy)
http://www.garlic.com/~lynn/2007.html#32 V2X2 vs. Shark (SnapShot v. FlashCopy)

How many 36-bit Unix ports in the old days?

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How many 36-bit Unix ports in the old days?
Newsgroups: alt.folklore.computers
Date: Sat, 06 Jan 2007 08:31:14 -0700
jmfbahciv writes:
<shrug> If you got 1000 parts that can break, your software has to be a lot more paranoid about a lot more specific things.

the issue is whether system has interdependent failures or independent failures.

slightly related post here
http://www.garlic.com/~lynn/2007.html#29 Just another example of mainframe costs

with this old email
http://www.garlic.com/~lynn/2007.html#email900823

other related posts having worked on various availability efforts
http://www.garlic.com/~lynn/submain.html#available

as well as scaleup
http://www.garlic.com/~lynn/subtopic.html#hacmp

for other drift, one of the things i (vaguely?) remember being told about the difference between 360/195 and 370/195 ... was some amount of instruction retry had been added to 370/195. the claim was that there were so many parts in the 195 ... there were possibility of a couple hardware events a week that would be handled by instruction retry.

this was when the 370/195 guys were talking to us about doing software support for a dual-istream 195. the 195 pipeline supported something like 10mip when there was branch looping within the pipeline ... but otherwise branches would stall the machine ... and normal codes ran closer to 5mips. a dual-isteam (somewhat like current genre of hardware multi-threading) had chance of keepting pipeline full (since there would be two streams nominally running at 5mips). this never shipped to customers.

How many 36-bit Unix ports in the old days?

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How many 36-bit Unix ports in the old days?
Newsgroups: alt.folklore.computers
Date: Sat, 06 Jan 2007 08:50:09 -0700
jmfbahciv writes:
<shrug> If you got 1000 parts that can break, your software has to be a lot more paranoid about a lot more specific things.

previous post
http://www.garlic.com/~lynn/2007.html#36 How many 36-bit Unix ports in the old days?

and i had to address similar problem when i rewrote the i/o supervisor for the disk engineering and product test labs to make it absolutely bullet-proof ... recent reference
http://www.garlic.com/~lynn/2007.html#2 "The Elements of Programming Style"

and collected posts
http://www.garlic.com/~lynn/subtopic.html#hacmp

How many 36-bit Unix ports in the old days?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How many 36-bit Unix ports in the old days?
Newsgroups: alt.folklore.computers
Date: Sat, 06 Jan 2007 09:21:21 -0700
jmfbahciv writes:
<shrug> If you got 1000 parts that can break, your software has to be a lot more paranoid about a lot more specific things.

there have been past threads before about why wasn't aix/370 (and some of the other 370 oriented unixs) and (amdahl's) UTS normally run on the bare iron as opposed to normal operation under VM.

one of the big issues was that there was significant RAS code in VM ... and the cost of adding similar RAS code to any unix port was significantly larger than the total cost of just doing a straight-forward port of unix to 370.

Field Service even took the position that they would not service a machine that didn't have the necessary RAS and EREP software (i.e. VM RAS and EREP would handle a lot of the error diagnostic, recovery, and recording ... transparent to the virtual machine operation).

previous posts in this thread:
http://www.garlic.com/~lynn/2007.html#36 How many 36-bit Unix ports in the old days?
http://www.garlic.com/~lynn/2007.html#37 How many 36-bit Unix ports in the old days?

the exception that prooves the point was the tss/370 ssup that saw extensive deployment inside at&t. higher level parts of Unix were mated to the low-level tss/370 kernel interfaces ... unix was sort of running on a "370 bare machine" ... but it was actually layered on top of the lower level tss/370 kernel (which provided all the 370 RAS and EREP support).

At this NASA sponsored workship on high dependability
http://web.archive.org/web/20011004023230/http://www.hdcc.cs.cmu.edu/may01/index.html

I told the story of 3090 product manager contacting me after the 3090 had been in customer shops for a year ... recent reference
http://www.garlic.com/~lynn/2006y.html#43 Remote Tape drives

the 3090 had been designed so that there was a certain kind of error that was only suppose to have 3-5 aggregate occurances for the year (aggregate total across all customer machines installed for a year, not just aggregate per customer). the problem was that there was published that there had been closer to 20 such aggregate errors. I asked the vendors in the audience how many had facilities where they knew the number of all errors for all installed machines, and if they were even accumulating such information ... how many vendors had the information readily publicly available?

past posts having some mention of 370 unixes
http://www.garlic.com/~lynn/99.html#2 IBM S/360
http://www.garlic.com/~lynn/99.html#64 Old naked woman ASCII art
http://www.garlic.com/~lynn/99.html#66 System/1 ?
http://www.garlic.com/~lynn/99.html#190 Merced Processor Support at it again
http://www.garlic.com/~lynn/99.html#191 Merced Processor Support at it again
http://www.garlic.com/~lynn/2000c.html#8 IBM Linux
http://www.garlic.com/~lynn/2000e.html#27 OCF, PC/SC and GOP
http://www.garlic.com/~lynn/2000f.html#68 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000f.html#69 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2001.html#44 Options for Delivering Mainframe Reports to Outside Organizat ions
http://www.garlic.com/~lynn/2001.html#49 Options for Delivering Mainframe Reports to Outside Organizat ions
http://www.garlic.com/~lynn/2001e.html#19 SIMTICS
http://www.garlic.com/~lynn/2001f.html#20 VM-CMS emulator
http://www.garlic.com/~lynn/2001f.html#22 Early AIX including AIX/370
http://www.garlic.com/~lynn/2001l.html#17 mainframe question
http://www.garlic.com/~lynn/2001l.html#18 mainframe question
http://www.garlic.com/~lynn/2001l.html#19 mainframe question
http://www.garlic.com/~lynn/2002b.html#36 windows XP and HAL: The CP/M way still works in 2002
http://www.garlic.com/~lynn/2002d.html#31 2 questions: diag 68 and calling convention
http://www.garlic.com/~lynn/2002i.html#54 Unisys A11 worth keeping?
http://www.garlic.com/~lynn/2002i.html#81 McKinley Cometh
http://www.garlic.com/~lynn/2002j.html#36 Difference between Unix and Linux?
http://www.garlic.com/~lynn/2002n.html#58 IBM S/370-168, 195, and 3033
http://www.garlic.com/~lynn/2002n.html#67 Mainframe Spreadsheets - 1980's History
http://www.garlic.com/~lynn/2002p.html#45 Linux paging
http://www.garlic.com/~lynn/2003d.html#8 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003d.html#54 Filesystems
http://www.garlic.com/~lynn/2003h.html#35 UNIX on LINUX on VM/ESA or z/VM
http://www.garlic.com/~lynn/2003h.html#45 Question about Unix "heritage"
http://www.garlic.com/~lynn/2003o.html#49 Any experience with "The Last One"?
http://www.garlic.com/~lynn/2004c.html#6 If the x86 ISA could be redone
http://www.garlic.com/~lynn/2004d.html#72 ibm mainframe or unix
http://www.garlic.com/~lynn/2004h.html#41 Interesting read about upcoming K9 processors
http://www.garlic.com/~lynn/2004h.html#42 Interesting read about upcoming K9 processors
http://www.garlic.com/~lynn/2004n.html#30 First single chip 32-bit microprocessor
http://www.garlic.com/~lynn/2004q.html#37 A Glimpse into PC Development Philosophy
http://www.garlic.com/~lynn/2004q.html#38 CAS and LL/SC
http://www.garlic.com/~lynn/2004q.html#39 CAS and LL/SC
http://www.garlic.com/~lynn/2005b.html#22 The Mac is like a modern day Betamax
http://www.garlic.com/~lynn/2005f.html#28 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005h.html#5 Single System Image questions
http://www.garlic.com/~lynn/2005j.html#26 IBM Plugs Big Iron to the College Crowd
http://www.garlic.com/~lynn/2005m.html#4 [newbie] Ancient version of Unix under vm/370
http://www.garlic.com/~lynn/2005m.html#7 [newbie] Ancient version of Unix under vm/370
http://www.garlic.com/~lynn/2005q.html#14 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005q.html#26 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005q.html#27 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005q.html#49 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005s.html#34 Power5 and Cell, new issue of IBM Journal of R&D
http://www.garlic.com/~lynn/2005u.html#61 DMV systems?
http://www.garlic.com/~lynn/2006b.html#8 Free to good home: IBM RT UNIX
http://www.garlic.com/~lynn/2006b.html#24 Seeking Info on XDS Sigma 7 APL
http://www.garlic.com/~lynn/2006c.html#11 Mainframe Jobs Going Away
http://www.garlic.com/~lynn/2006e.html#31 MCTS
http://www.garlic.com/~lynn/2006f.html#27 Old PCs--environmental hazard
http://www.garlic.com/~lynn/2006u.html#27 Why so little parallelism?
http://www.garlic.com/~lynn/2006y.html#11 Multiple mappings
http://www.garlic.com/~lynn/2007.html#32 V2X2 vs. Shark (SnapShot v. FlashCopy)

Just another example of mainframe costs

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Just another example of mainframe costs.
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 06 Jan 2007 12:10:00 -0700
rfochtman@YNC.NET (Rick Fochtman) writes:
No argument here. But the hardware evolution in terms of RAS has made the MF KING in this area. MF had a poor record to start, but it's improved immeasurably over the last 40+ years, with the evolution of microcode and things like automatic recovery and fail-over to unaffected components, sparing, etc. The "squatty boxen" will eventually arrive at the same point in their evolution, but they haven't got there yet. In my own experience, the hard drives in use today have a long way to go. They've come a long way, compared to their abysmal past, but there's still a lot of room for improvement. And I have a MAJOR problem with a software vendor who tells me to "Reboot and see if that fixes it" or "Re-install and see if that fixes it". Diagnostic tools and procedures are a world apart between z/OS and the various Intel-based systems.

cross-over from similar/related discussion in a.f.c
http://www.garlic.com/~lynn/2007.html#36 How many 36-bit Unix ports in the old days?
http://www.garlic.com/~lynn/2007.html#37 How many 36-bit Unix ports in the old days?
http://www.garlic.com/~lynn/2007.html#39 How many 36-bit Unix ports in the old days?

besides many of the 370 UNIX ports running under VM in virtual machines ... in large part because of the significant costs to add RAS/EREP support to Unix (significantly larger than cost of doing a unix port to 370) ... there was also periodic concern regarding just maintaining RAS/EREP support in the standard 370 operating systems ... one example
http://www.garlic.com/~lynn/2007.html#2 "The Elements of Programming Style"
that includes this old email reference
http://www.garlic.com/~lynn/2007.html#email801015

at one point there was a study of the "four" standard 370 operating systems and the corporation was going to cut back to fewer ... just based on the cost of maintaining the RAS/EREP software in all the different operating systems.

I mentioned a 3090 RAS/EREP story here
http://www.garlic.com/~lynn/2007.html#38 How many 36-bit Unix ports in the old days?
and at this NASA sponsored working on dependable computing
http://web.archive.org/web/20011004023230/http://www.hdcc.cs.cmu.edu/may01/index.html
and in this thread:
http://www.garlic.com/~lynn/2006y.html#43 Remote Tape drives

another is story about 3090 service processor. Field Service had a defined process for being able to diagnose and service customer machines in the field ... that started with being able to "scope" components to diagnose failed elements.

the 3081 had lots of components which were no longer directly scopeable ... which gave rise to the "service processor". The service processor had extensive probes into the 3081 components for diagnosing errors and failed components. While the 3081 wasn't directly scopeable, there was a bootstrape "scope" diagnostic process that started with scoping the service processor ... and then using the service processor to diagnose the 3081.

as refereneced in this recent posts, the 3090 had a vm370-based service processor
http://www.garlic.com/~lynn/2007.html#18 IBM sues maker of Intel-based Mainframe clones
http://www.garlic.com/~lynn/2007.html#24 How to write a full-screen Rexx debugger?

which started out as a 4331 ... which was scopeable. Before the 3090 shipped, the service processor strategy was upgraded to a pair of (vm370-based) 4361s. Instead of having a bootstrapable scoping field service process ... 3090 went to a pair of redundant 4361s.

part of mainframe availability strategy was based on loosedly-coupled configurations. long ago and far away ... my wife had been con'ed into going to POK to be responsible for loosely-coupled architecture. While she was there she developed peer-coupled shared data architecture
http://www.garlic.com/~lynn/submain.html#shareddata

however, except for IMS hot-standby, there wasn't a lot of uptake until sysplex (somewhat as a result, she didn't stay long in the job).

however, we were also able to repeat some of the effort with ha/cmp product
http://www.garlic.com/~lynn/subtopic.html#hacmp

including work on disaster survivability and geographic survivability (two terms we coined when we were doing ha/cmp)
http://www.garlic.com/~lynn/submain.html#available

we also worked on scaleup for loosely-coupled configuration .. including some of the early work on high-density computer, floor-space efficient footprints ... recent posts referencing MEDUSA (cluster-in-a-rack):
http://www.garlic.com/~lynn/2006w.html#13 IBM sues maker of Intel-based Mainframe clones
http://www.garlic.com/~lynn/2006w.html#14 IBM sues maker of Intel-based Mainframe clones
http://www.garlic.com/~lynn/2006w.html#20 cluster-in-a-rack
http://www.garlic.com/~lynn/2006w.html#40 Why so little parallelism?
http://www.garlic.com/~lynn/2006w.html#41 Why so little parallelism?
http://www.garlic.com/~lynn/2006x.html#3 Why so little parallelism?
http://www.garlic.com/~lynn/2006x.html#11 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006x.html#33 NSFNET (long post warning)
http://www.garlic.com/~lynn/2007.html#31 V2X2 vs. Shark (SnapShot v. FlashCopy)

How many 36-bit Unix ports in the old days?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How many 36-bit Unix ports in the old days?
Newsgroups: alt.folklore.computers
Date: Sat, 06 Jan 2007 12:25:43 -0700
CBFalconer <cbfalconer@yahoo.com> writes:
In the old days we designed the fundamental gates (with transistors, diodes, resistors and power supplies) to work under worst case component tolerances, and the fan-in/fan-out was specified accordingly.

somewhat related, being able to scope & diagnose individual components ... and the transition to no longer being able to scope individual components ... recent cross-over post from bit.listserv.ibm-main
http://www.garlic.com/~lynn/2007.html#39 Just another example of mainframe costs

RTFM - IETF RFCs

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: RTFM - IETF RFCs
Newsgroups: comp.security.misc
Date: Sat, 06 Jan 2007 12:44:47 -0700
NeoPhyte_Rep <abuse@127.0.0.1> writes:
Internet Engineering Task Force (IETF) Request For Comments (RFC):
http://www.ietf.org/rfc.html

The RFCs are the documents that describe the design intent of the various protocols that are used on the Internet.


i've index RFCs in various different ways
http://www.garlic.com/~lynn/rfcietff.htm

some RFCs are also STDs ... i.e. the protocol (and other) standards for internet operation
http://www.garlic.com/~lynn/rfcstd.htm#rfcstd
and
http://www.garlic.com/~lynn/rfcdoc.htm#STDdoc

there is also defined process that proposed/pending standards go thru ... first (RFCs) as proposed standards
http://www.garlic.com/~lynn/rfcstd.htm#prop

and then progress to draft standards
http://www.garlic.com/~lynn/rfcstd.htm#draf

before moving on to full standards.

there are numerious other RFCs that are classified as informational (some giving design intent) or experimental. Then there are some number of RFCs that are classified as historical and/or obsolete.

then there is a whole process involving internet-drafts ... documents that haven't yet reached RFC status. i.e.
http://www.ietf.org/ID.html

The logic of privacy

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: The logic of privacy
Newsgroups: alt.privacy
Date: Sat, 06 Jan 2007 13:14:43 -0700
The logic of privacy, A new way to think about computing and personal information
http://www.economist.com/science/displayStory.cfm?story_id=8486072

recent post with short discussion about why X.509 identity certificates (from the early 90s) morphed into relying-party-only certificates by the mid-90s (and possibly why something similar could happen to passports)
http://www.garlic.com/~lynn/2007.html#17 SSL info

and this discussion about rather than attempting to absolutely eliminate possibility of all data breaches and security breaches (even those involving insiders) ... eliminate the attackers being able to use (majority of) the information for fraudulent purposes
http://www.garlic.com/~lynn/2007.html#5 Securing financial transactions a high priority for 2007
and somewhat related post here
http://www.garlic.com/~lynn/aadsm26.htm#18 SSL (https, really) acclerators for Linux/Apache?

SSH protocol analyzer

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: SSH protocol analyzer
Newsgroups: alt.privacy.anon-server,alt.privacy
Date: Sun, 07 Jan 2007 09:34:22 -0700
Fred C Dobbs <fredcdobbs@nymialias.net> writes:
The original TCP/IP reference model consisted of four layers, but has evolved into a five layer model.

The OSI model describes a fixed, seven layer stack for networking protocols. Comparisons between the OSI model and TCP/IP can give further insight into the significance of the components of the IP suite, but can also cause confusion, since the definition of the layers are slightly different.


https://en.wikipedia.org/wiki/Internet_protocol_suite


ISO compounded this with policy that it would not standardize any networking standards that didn't correspond to the OSI model (which it had also standardized).

we got mixed up in that in ANSI X3S3.3 (US ISO chartered standardization body dealing with standards corresponding to OSI level 3&4) for something called HSP (or high-speed protocol).

it was eventually found that X3S3.3 couldn't do anything with HSP because

1) HSP went directly from transport to LAN MAC interface. LAN MAC interface sits someplace in the middle of OSI layer 3, or network (LAN MAC interface includes some networking features). Since LAN MAC interface violated OSI model ... then protocol that supported talking to the LAN MAC interface also violated OSI model

2) HSP went directly from transport to LAN MAC interface ... bypassing the transport/network interface ... which also violated the OSI model

3) HSP supported internetworking. internetworking (i.e. IP in TCP/IP) is a non-existant OSI layer that sort of sits between the bottom of transport (layer 4 in OSI) and the top of network (layer 3 in OSI). Since IP doesn't exist in OSI, protocol that supports IP/internetworking also violates OSI.

lots of past posts mentioning HSP
http://www.garlic.com/~lynn/subnetwork.html#xtphsp

for other gorp this reference to RFC801, NCP/TCP Transition Plan RFC from Nov. 1981 i.e. arpanet was closer to OSI model w/o the internetworking layer.

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

RFC801 summary
http://www.garlic.com/~lynn/rfcidx2.htm#801

801
NCP/TCP transition plan, Postel J., 1981/11/01 (21pp) (.txt=40824) (Ref'ed By 1475, 1705, 1707)

as always in the RFC summaries, clicking on the ".txt=nnnn" field, retrieves the actual RFC.

from above:
It was clear from the start of this research on other networks that the base host-to-host protocol used in the ARPANET was inadequate for use in these networks. In 1973 work was initiated on a host-to-host protocol for use across all these networks. The result of this long effort is the Internet Protocol (IP) and the Transmission Control Protocol (TCP).

... snip ...

now, one of the issues/inadequacies was being able to internetworking layer that allowed lots of different networks to interoperate.

the "great change-over" from (arpanet) host-to-host protocol to (tcp/ip) internetworking protocol occured on 1jan83.

now, one of the interesting things that happened in the late 80s was the US federal gov. mandate (similar positions could be found by numerous other govs) to eliminate the internet and replace it with OSI model, ISO standards protocol ... even tho all the work leading up to internetworking in the 70s and early 80s showed that OSI-model was not adequate for large heterogeneous operations (i.e. not so much the technical interoperability ... but that totally different organizations and business operations could interoperate). OSI model was much more of a single organization, flat (networking) service model, typical of the telephone companies and PTTs of the 60s and 70s.

misc. past posts mentioning GOSIP (fed gov. plan to eliminate internet and replace it with osi).
http://www.garlic.com/~lynn/99.html#114 What is the use of OSI Reference Model?
http://www.garlic.com/~lynn/99.html#115 What is the use of OSI Reference Model?
http://www.garlic.com/~lynn/2000b.html#0 "Mainframe" Usage
http://www.garlic.com/~lynn/2000b.html#79 "Database" term ok for plain files?
http://www.garlic.com/~lynn/2000d.html#16 The author Ronda Hauben fights for our freedom.
http://www.garlic.com/~lynn/2000d.html#43 Al Gore: Inventing the Internet...
http://www.garlic.com/~lynn/2000d.html#63 Is Al Gore The Father of the Internet?
http://www.garlic.com/~lynn/2000d.html#70 When the Internet went private
http://www.garlic.com/~lynn/2001e.html#32 Blame it all on Microsoft
http://www.garlic.com/~lynn/2001i.html#5 YKYGOW...
http://www.garlic.com/~lynn/2001i.html#6 YKYGOW...
http://www.garlic.com/~lynn/2002g.html#21 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002g.html#30 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002i.html#15 Al Gore and the Internet
http://www.garlic.com/~lynn/2002m.html#59 The next big things that weren't
http://www.garlic.com/~lynn/2002n.html#42 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2003e.html#71 GOSIP
http://www.garlic.com/~lynn/2003e.html#72 GOSIP
http://www.garlic.com/~lynn/2003o.html#68 History of Computer Network Industry
http://www.garlic.com/~lynn/2004c.html#52 Detecting when FIN has arrived
http://www.garlic.com/~lynn/2004e.html#13 were dumb terminals actually so dumb???
http://www.garlic.com/~lynn/2005.html#29 Network databases
http://www.garlic.com/~lynn/2005d.html#11 Cerf and Kahn receive Turing award
http://www.garlic.com/~lynn/2005e.html#39 xml-security vs. native security
http://www.garlic.com/~lynn/2005u.html#53 OSI model and an interview
http://www.garlic.com/~lynn/2006j.html#34 Arpa address
http://www.garlic.com/~lynn/2006k.html#6 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006k.html#45 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006k.html#47 Hey! Keep Your Hands Out Of My Abstraction Layer!

vm/sp1

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vm/sp1
Newsgroups: alt.folklore.computers
Date: Sun, 07 Jan 2007 17:05:18 -0700
Anne & Lynn Wheeler <lynn@garlic.com> writes:
I have an old t-shirt that some people at Amdahl were distributing when vm/sp initially came out; it has a particularly gory looking vulture labeled "vm/sp" and a line underneath that says "vm/sp is waiting for you".

there was another 370 operating system that also needed extensive RAS/EREP support, which was TPF ... recent post mentioning mainframe RAS/EREP topic
http://www.garlic.com/~lynn/2007.html#39 Just another example of mainframe costs

TPF had been called ACP (airline control program) but appeared to get renamed to transaction processing facility when they found large financial networks using it for high-end transaction processing.

there was some tie-in between TPF and special VM370 multiprocessor support introduced in vm/sp1 for TPF on 3081s. some recent posts with vm/sp1 references (including old email)
http://www.garlic.com/~lynn/2007.html#11 vm/sp1
http://www.garlic.com/~lynn/2007.html#13 "The Elements of Programming Style"
http://www.garlic.com/~lynn/2007.html#14 vm/sp1

the original vm370 multiprocessor support from the 70s was somewhat based on the assumption that there was enuf work to keep the processors busy. lots of past posts mentioning multiprocessor support and/or compare&swap instruction
http://www.garlic.com/~lynn/subtopic.html#smp

however, there were special changes in vm/sp1 that significantly increased the multiprocessor overhead for nearly all customers in order to pick up some benefit for a small set of customers interested in running TPF (as a single processor guest, since TPF didn't have multiprocessing support) on 3081s (with little no other workload). 3081 was originally introduced with no plans for a single processor machine (later they did introduce the single processor 3083 ... in large part based on TPF customer requirement).

the vm370 issue was that normally, (TPF) virtual machine execution was serialized with vm370 kernel emulation of various privilege instructions. the big vm/sp1 change for single guest 3081/TPF, was somewhat around virtual machine handling for the SIOF (start i/o fast) instrucation.

SIOF (instruction with 370s) instruction architecture allowed for some amount of overlapped processing with subsequent processor instruction execution. As a result, vm370 could theoretically (also) carry out SIOF instruction emulation overlapped with virtual machine execution (if there was at least two processors available). In order to enable this scenario (in large part because in the single guest TPF/3081 scenario the 2nd processor was always idle), a lot of signal processor instructions were introduced into the vm370 kernel (for interprocessor kernel signaling) causing a lot of kernel signal processor interrupts and a whole lot of (additional) multiprocessor lock operations. This was done for the general case, on the off chance it might provide for concurrent two-processor utilization in the single guest TPF/3081 SIOF scenario. However, it significantly drove up general kernel overhead for processing all the SIGP interrupts and managing all the additional kernel locking operations (for all cases).

In the following, the "I/O reliability" clean-up/rewrite ... made nearly all of the I/O code smaller, faster, cleaner and more straight forward ... not just alternate path support.

from long ago and far away:

Date: 02/19/86 19:47:53
From: wheeler
To: some east coast distribution

re: alternate path; as part of the I/O reliability clean-up ... circa 80 ... I completely rewrote the alternate path code (for both UP and MP) ... it is smaller, faster, cleaner and more straight forward to understand than the existing alternate path support. It also maintains more information about path use activity and gives a clearer picture about what is going on in the system.

Changes in SP1 aggravated a lot of lock spin, cpu-to-cpu SIGP chatter, and VMBLOK dispatch allocation by processor. Unfortunately most of the activity to address some of the problems introduced by SP1 (&/or generic MP problems) have been confined to HPO (on the other hand HPO has been doing a lot of things like attempting to tune free storage allocation to 3081 cross cache characteristics).

There appears to have been little or no base-SP activity in the MP performance area.


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

The SP vis-a-vis HPO multiprocessor issue was that HPO was an added price option which was somewhat justified for the high-end "POK" machines. The mid-range "Endicott" machines were starting to ship more and more multiprocessors ... but the base multiprocessor support had significant extra overhead introduced with VM/SP1 ... which was only getting fixed in the extra cost HPO kernel addon.

reference to some old email with other HPO work (including global LRU activity):
http://www.garlic.com/~lynn/2006y.html#9 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006y.html#17 The Future of CPUs: What's After Multi-Core?

another old email concerning significantly increased SMP overhead in vm/sp

Date: 05/12/82 17:34:45
To: wheeler

The comment about system locks that i was making was comparing VM/SP with VM REL 6 there are vastly more locks obtained in SP than there are REL 6 we've been running CP REL6 for 9 months or so. I dont understand why they decided to put lots more lock requests in SP


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

Date: 05/12/82 09:46:11
From: wheeler

re: lock message; recent observation by a internal location undergoing conversion from release 6 to VM/SP is that VM/SP is taking at least 6-8% additional CPU overhead because of the new locking features of VM/SP.


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

However, VM/SP issues weren't simply limited to changes for multiprocessor operation ... but also degraded single processor operations ... as implied in old t-shirt reference that was being distributed by people at Amdahl
http://www.garlic.com/~lynn/2007.html#11 vm/sp1

Date: 05/13/82 20:00:51
From: wheeler

re: sp/MP performance; observed SP/MP performance degradation compared to release 6 is consistant with measurements at a large number of installations (almost everyone I have talked to), customer & internal, UP, AP, & MP. This is even with subpool fix plus several enhancements to SP (which would have also improved release 6 performance), SP still runs slower than release 6. Every severity one performance situation that I've been contacted by people in the field since SP came out has been a release 6 to VM/SP conversion problem (i.e. problem appeared at the time the installation converted to SP). Also, while UP performance is degraded, AP/MP performance is more severely degraded. Implication is that there may be multiple problems causing degraded SP performance (as compared to release 6) ... some of the problem(s) are general (UP, AP, & MP), others are uniquely multiprocessor problems.

This most recent data point is completely consistant with all others that I'm aware of.


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

for other drift, recent posts mentioning various integrity changes
http://www.garlic.com/~lynn/2007.html#2 "The Elements of Programming Style"
http://www.garlic.com/~lynn/2007.html#29 Just another example of mainframe costs

misc past posts mentioning hobby of playing around across the street in the disk engineering and product test labs. doing things like the i/o reliability rewrite:
http://www.garlic.com/~lynn/subtopic.html#disk

the "3081 cross cache" references work that had been done to make kernel data structures and dynamic kernel storage management ... cache-line sensitive i.e. align on cache line boundaries and allocate in multiples of cache lines ... to help minimize multiprocessor cache thrashing. a few past posts mentioning the reworking kernel data structures and kernel dynamic storage for cache sensitivity in the early 80s:
http://www.garlic.com/~lynn/2000d.html#47 Charging for time-share CPU time
http://www.garlic.com/~lynn/2001b.html#62 z/Architecture I-cache
http://www.garlic.com/~lynn/2001j.html#17 I hate Compaq
http://www.garlic.com/~lynn/2001j.html#18 I hate Compaq
http://www.garlic.com/~lynn/2002i.html#83 HONE

Just another example of mainframe costs

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Just another example of mainframe costs.
Newsgroups: bit.listserv.ibm-main
To: <ibm-main@bama.ua.edu>
Date: Sun, 07 Jan 2007 20:08:31 -0700
edgould1948@COMCAST.NET (Ed Gould) writes:
Never heard of it so I guess it, that doesn't mean it never existed just an extremely small audience. I don't recall ever hearing anything about VF . I would expect if it were popular that there would be a current model, no?

I am guessing that VF stands for vector facility (?). I don't recall seeing PTF's for it. So either it was extremely small install base or the code IBM didn't have bugs?

I used the scan PTF cover letters and don't recall any mention of it. My memory is far from perfect, but chance are I would have read (or heard from a GUIDE/SHARE presentation of it).


a few past posts that mention 3090vf:
http://www.garlic.com/~lynn/2000c.html#61 TF-1
http://www.garlic.com/~lynn/2002i.html#12 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2003g.html#68 IBM zSeries in HPC
http://www.garlic.com/~lynn/2005m.html#20 simd for 390(or z990)?
http://www.garlic.com/~lynn/2006m.html#4 The Power of the NORC

supposedly one of the benefits of vectors is to increase the rate the floating point unit(s) is feed to keep it constantly busy ... not stalling waiting for memory fetches or other delays.

claims have been that various kinds of optimization in instruction fetching and other optimization can improve scalar floating point ... such that floating point unit can be kept busy w/o requiring vectors.

bugs would have tended to be related with program loading/use of the vector registers, mostly fortran ... although there may have been a performance optimization in virtual machine support about whether a virtual machine was enabled for vector facility or not ... and whether vector registers had to be saved and/or restored.

from long ago and far away ...

Date: 03/04/85 19:01:52
To: wheeler

Regarding vector: For the past two months we have been working on (and have now completed) the Objectives for VM/XA SP Release 1. (Terminology update: VM/XA Migration Aid releases 3 and 4 have become VM/XA Systems Facility releases 1 and 2; the next thing after that is VM/XA SP Release 1.)

VM/XA SP Release 1 is currently planning to support vector. XXXXXX owns the design of the vector line item and I own the design of the dispatcher. Dispatcher will be changed to:

(1) Have some flavor of a true runlist to reduce overhead. (Though part of the overhead that yyyyyy sees here will tend to disappear naturally when other problems in the system are fixed... such as avoiding putting excessive users in the dispatch list.)
(2) Have a "soft affinity" capability. Users should tend to get dispatched on the same processor on successive dispatches to reduce cache interference.
(3) Have a "hard affinity" capability. This is so a user can be assigned to always run on the same processor or subset of processors. For example, when the user needs vector and not all processors in the system have it.

The question quickly comes up, how will vector be supported? Since it could be costly to dispatch someone using vector, do you allow everyone to use it, or just authorized users? And do you allow just one vector user into the dispatch list at a time, or do you allow everyone in? We are currently leaning strongly toward letting anyone use it (no authorization), and letting everyone into the dispatch list at once. There are two reasons why it seems we will be able to get away with that: (1) With the existing VM/XA design it seems that we will be able to bill the extra dispatching overhead to the guilty user... that is, it will be stolen from his problem state time, and will not be felt by other users. (2) I am told by XXXXXX that the hardware keeps reference (and/or) change status on the various vector registers, therefore when a vector user is dispatched repeatedly (as when he is swapping in his working set) the vector overhead won't be so bad because we only have to save/restore the part that was used. At least that is the theory... I'm not knowledgeable about vector, I get all my information from XXXXXX. A while back though XXXXXXX said the hardware may initially not have all the reference/change stuff implemented... so maybe our initial support will be more limited than I've indicated.


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

past posts in this thread:
http://www.garlic.com/~lynn/2007.html#29 Just another example of mainframe costs
http://www.garlic.com/~lynn/2007.html#33 Just another example of mainframe costs
http://www.garlic.com/~lynn/2007.html#39 Just another example of mainframe costs

How many 36-bit Unix ports in the old days?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How many 36-bit Unix ports in the old days?
Newsgroups: alt.folklore.computers
Date: Sun, 07 Jan 2007 22:48:36 -0700
Brian Inglis <Brian.Inglis@SystematicSW.Invalid> writes:
Under VM/CP SET AFFINITY ON 1 only allowed the virtual machine to execute on CPU 1, so it got harder to schedule that virtual machine to the deadline as the system got more loaded, although could reduce TLB misses and cache invalidations if the system had any idle time.

related discussion here from bit.listserv.ibm-main regarding 3090vf
http://www.garlic.com/~lynn/2007.html#45 Just another example of mainframe costs

and dispatching issues with respect to vector register and cache contents.

for some drift, old email discussing VMS announcement of support for symmetric multiprocessing support. i think ultrix symmetric multiprocessing support was two years later(?)

Date: 24 Mar 88 GMT
To: distribution
Subject: Symmetric Multiprocessing and VMS release 5

Looking through the lead article in the 3/14 issue of ComputerWorld there is a clarification of the recent DEC announcement of the 4 way MP and DEC's support of Symmetric Multiprocessing.

Basically the message is that the operating system shipped with the new VAX machines DOES support symmetric multiprocessing. Apparently, the operating system is a pre-release version of VMS 5.0 or perhaps an older version with the VMS 5.0 symmetric processing support added.

Since their machines have been APs in the past, we have not included the multiprocessor versions of their machines as competitors in a Commercial benchmark. Now it would appear that they have changed the game by supporting symmetric multiprocessing. I suspect that we will now have to look at their MPs as well as their UPs in positioning them in the commercial benchmark.


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

Date: 29 Mar 88 17:29:22 GMT
To: distribution
Subject: A New DEC Database?

In Computerworld, 3/21/88, page 1, "DEC Stalks Big Game with Symmetrical VMS", there is the following sentence. "The full release of VMS release 5, with added online transaction processing, hooks to a new database and other enhancements, is due out later this spring". This is the first I've heard of a new database. Does anyone heard similar rumors about a new database?


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

long reference ....


Source:  Digital Press Release of March 8, 1988

Marlboro, Mass., March 8, 1988 -- Digital today introduced its most
powerful VAX computers -- the VAX 8800 Series.  The new series provides
a continuous growth path, providing from 1 to 3.7 times the processing
power of Digital's VAX 8700 computer.  Pricing ranges from $543,900 to
over $1.7 million, depending on configuration.

The VAX 8800 Series is available immediately.

With the new VAX 8800 Series, Digital:

o  introduced VMS symmetric multiprocessing for the VAX 8800
       Series.

o  announced a support and service program that is the most
comprehensive ever offered with any Digital system;

o  presented a growth path through the series, as well as the
       ability for users to upgrade existing VAX 8700 and VAX 8800
systems to the new series.

The VAX 8800 Series is fully compatible with Digital's VAX family,
and runs the VMS operating system.  ULTRIX and VAX ELN software are
supported on the VAX 8810 system now; both will be available for the
other configurations in the future.

There are five system configurations -- the VAX 8810, the VAX
8820, the VAX 8830, the VAX 8840 and the VAX 8842, incorporating
from one to four processors.

    The VAX 8842 adds Digital's VAXcluster system technology for high
availability and access to a common database.

The VAX 8840 and VAX 8842 are also complemented with two optional
solution packages.  These are tailored for new VAXcluster system
installations.  One provides a basic VAXcluster system configuration
for new VAXcluster system sites.  The other provides high data
availability.

The VAX 8800 Series supports VMS symmetric multiprocessing, which
treats the processors as peers and dynamically balances the workload
across all processors.  The combination of simultaneous processing of
multiple applications and dynamic load balancing enables the systems
to run more jobs, support more users, and run larger workloads than
any other VAX system.

    The new series provides for multiple Ethernet connections, a
VAXcluster system port, and up to six VAXBI busses.  Users upgrade a
VAX 8810, VAX 8820, or VAX 8830 by adding one or more processors.
Upgrading is a straightforward process that is done on-site and
typically takes less than a day.  Upgrades are priced at $280,000 per
configuration.

There can be up to 512 Mbytes of main memory.

The price of each multiprocessor VAX 8800 configuration includes
the most comprehensive service and support program Digital has yet
offered.  It includes installation, 24-hour, 7-day telephone
service and hardware support, and Performance Reporting Service
for one year.  The one-year warranty covers all Digital hardware,
software, and Digital-licensed software purchased with the system.
Each customer gets an account manager at Digital's Customer Support
Center, who coordinates service and administers the Performance
Reporting Service.

Support service for the entry-level VAX 8810 configuration
includes a full one-year DECservice hardware warranty that provides
hardware installation, 24-hour hardware telephone support, and on-site
hardware support during business hours.  The warranty programs for the
first year are included in the system price, and can be extended at
the time of purchase to a total of up to three years.

                     Sample Configurations
VAX 8810

o  60in h x 74in w x 30in d cabinet occupies 15.5 square feet
        (1.44 square meters) of floor space
o  One processor
     o  48 Mbytes of main memory
o  MicroPDP-11 console subsystem
o  VMS operating system software license
o  DECnet-VAX software end node license
     o  1 Ethernet adapter
o  1 VAXBI bus
     o  1 VAXcluster system adapter or 1 KDB50 local disk
controller
o  One year DECservice hardware warranty including
installation, 24-hour hardware telephone support and
        on-site support during business hours
o  Performance: Equivalent to VAX 8700
     o  Prices begin at US$543,900

VAX 8820

     o  60in h x 106in w x 30in d cabinet occupies 22.2 square feet
(2.0 square meters) of floor space
     o  Two processors
o  128 Mbytes of main memory
o  MicroVAX II console subsystem with VT320 terminal, LA75
printer, 71 Mbyte RD53 fixed disk drive, and 95 Mbyte
        TK50 tape drive
o  VMS operating system software license
     o  DECnet-VAX software end node license
o  VAXcluster system software license
o  1 Ethernet adapter
o  2 VAXBI buses
     o  1 VAXcluster system adapter
o  One-year hardware and software warranty, 24-hour, 7-day
        on-site hardware service, account support manager,
Performance Reporting Service
o  Performance: up to 1.9 times the performance of VAX 8810
o  Prices begin at US$833,700

VAX 8830

o  60in h x 106in w x 30in d cabinet occupies 22.2 square feet
(2.0 square meters) of floor space
o  Three processors
     o  128 Mbytes of main memory
o  MicroVAX II console subsystem with VT320 terminal and
        LA75 printer,  71 Mbyte RD53 fixed disk drive, and 95
Mbyte TK50 tape drive
o  VMS operating system software license
o  DECnet-VAX software end node license
     o  VAXcluster system software license
o  2 Ethernet adapters
     o  2 VAXBI buses
o  1 VAXcluster system adapter
o  One-year hardware and software warranty, 24-hour, 7-day
on-site hardware service, account support manager,
        Performance Reporting Service, and 6-month resident
software engineer
     o  Performance: up to 2.8 times the performance of VAX 8100
o  Prices begin at US$1,062,000

VAX 8840

o  60in h x 106in w x 30in d cabinet occupies 22.2 square feet
        (2.0 square meters) feet of floor space
o  Four processors
o  128 Mbytes of main memory
o  2.5 Gbytes of disk storage
     o  Intelligent storage controller
o  MicroVAX II console subsystem with VT320 terminal and
        LA75 printer,  71 Mbyte RD53 fixed disk drive, and 95
Mbyte TK50 tape drive
o  VMS operating system software license
o  DECnet-VAX software end node license
     o  VAXcluster system software license
o  2 Ethernet adapters
     o  2 VAXBI buses
o  1 VAXcluster system adapter
o  One-year hardware and software warranty, 24-hour, 7-day
on-site hardware service, account support manager,
        Performance Reporting Service, and 6-month resident
software engineer
     o  Performance: up to 3.7 times the performance of VAX 8810
o  Prices begin at US$1,472,000

VAX 8842

o  Two 8820 systems
     o  2.5 Gbytes of disk storage
o  Intelligent storage controller
o  One-year hardware and software warranty, 24-hour, 7-day
on-site hardware service, account support manager,
        Performance Reporting Service, and 6-month resident
software engineer
     o  Prices begin at: US$1,577,000

Solution Start-Up and Service Package:

     o  Additional 2.5 Gbytes of disk storage
o  Dual density tape drive, Star Coupler
     o  VAXcluster system console system and VAX Performance
Advisor system management tools
o  Pre-site planning, DECstart Plus, software installation
o  DECplan educational credits
     o  Additional 6-month software engineering resident
o  Prices begin at US$510,900

High Data Availability Package:

o  Additional intelligent storage controller, Dual-porting
        capability
o  VAX Volume Shadowing software
     o  Price: US$125,100



previous, next, index - home