List of Archived Posts

2007 Newsgroup Postings (08/11 - 09/14)

The Unexpected Fact about the First Computer Programmer
Hypervisors May Replace Operating Systems As King Of The Data Center
Hypervisors May Replace Operating Systems As King Of The Data Center
Hypervisors May Replace Operating Systems As King Of The Data Center
Hypervisors May Replace Operating Systems As King Of The Data Center
The Unexpected Fact about the First Computer Programmer
Loads Weighing Heavily on Roads
Hypervisors May Replace Operating Systems As King Of The Data Center
Original Colossal Cave Adventure
Hypervisors May Replace Operating Systems As King Of The Data Center
IBM 8000 series
Original Colossal Cave Adventure
more transactional memory for mutlithread/multiprocessor operation
EZPass: Yes, Big Brother IS Watching You!
Geothermal was: VLIW pre-history
"Atuan" - Colossal Cave in APL?
Hypervisors May Replace Operating Systems As King Of The Data Center
FORTRAN IV program illustrating assigned GO TO on web site
Flying Was: Fission products
Geothermal was: VLIW pre-history
U.S. Cedes Top Spot in Global IT Competitiveness
U.S. Cedes Top Spot in Global IT Competitiveness
U.S. Cedes Top Spot in Global IT Competitiveness
Outsourcing loosing steam?
LAX IT failure: leaps of faith don't work
LAX IT failure: leaps of faith don't work
Tom's Hdw review of SSDs
EZPass: Yes, Big Brother IS Watching You!
EZPass: Yes, Big Brother IS Watching You!
EZPass: Yes, Big Brother IS Watching You!
EZPass: Yes, Big Brother IS Watching You!
EZPass: Yes, Big Brother IS Watching You!
reading erased bits
EZPass: Yes, Big Brother IS Watching You!
EZPass: Yes, Big Brother IS Watching You!
Is a RISC chip more expensive?
It's No Secret: VMware to Develop Secure Systems for NSA
Each CPU usage
It's No Secret: VMware to Develop Secure Systems for NSA
It's No Secret: VMware to Develop Secure Systems for NSA
EZPass: Yes, Big Brother IS Watching You!
Virtual Storage implementation
mainframe performance, was Is a RISC chip more expensive?
Flying Was: Fission products
64 gig memory
Virtual Storage implementation
Virtual Storage implementation
Virtual Storage implementation
Virtual Storage implementation
64 gig memory
64 gig memory
EZPass: Yes, Big Brother IS Watching You!
Virtual Storage implementation
Virtual Storage implementation
mainframe performance, was Is a RISC chip more expensive?
mainframe performance, was Is a RISC chip more expensive?
360/30 memory
ACP/TPF
ACP/TPF
ACP/TPF
Are Relational Databases Obsolete?
(Newbie question)How does the modern high-end processor been designed?
Horrid thought about Politics, President Bush, and Democrats
'pipe <' doesn't work in Windows xp? I get an error saying its not a command
Toshiba Boosts Hard Drive Density By 50%
The use of "script" for program
The use of "script" for program
1401 simulator for OS/360
CA to IBM TCP Conversion
ServerPac Installs and dataset allocations
The name "shell"
The use of "script" for program
FICON tape drive?
The name "shell"
Horrid thought about Politics, President Bush, and Democrats
The name "shell"
Graduate Enrollment in 2005

The Unexpected Fact about the First Computer Programmer

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Subject: Re: The Unexpected Fact about the First Computer Programmer
Newsgroups: alt.folklore.computers
Date: Sat, Aug 11 2007 3:31 pm
On Aug 10, 6:25 pm, Peter Flass <Peter_Fl...@Yahoo.com> wrote:
This is good in theory, but making money without any other considerations has led us to Enron, Mi$uck, and the mortgage meltdown. Business used to be moderated by ethics or, at least, by the desire to build up the company you were running. Today no one has ethics, and managers only want to keep their company running long enough so that *they* can cash in, and the heck with whoever comes after.

recent article on the (subprime) mortgage meltdown

Credit Crisis? Not Really
http://www.cbsnews.com/stories/2007/08/10/opinion/main3156566.shtml

from above:
With approximately 254,000 mortgages in foreclosure at the moment - up from roughly 219,000 last year - the sub-prime meltdown has given us an increase of 35,000 mortgage foreclosures over the last quarter. Since the average sub-prime mortgage clocks in at almost exactly $200,000, we're looking at an approximate $7 billion increase in foreclosed value in the first quarter of this year.

... snip ...

... which the article says represents something like 0.01percent. there appeared to be some implication in the referenced program that some corporations that were involved in the securitization backing that $7b would welcome national disaster references since it might contribute to the gov. covering their losses (analogous to some gov. bail-out of mostly high wealth individuals in the highly speculative hedge fund industry early in this decade).

for other topic drift .... old, long winded post touching on savings&loan situation from the 80s and some other financial issues touching on mortgages from the period (and general risk management subject)
http://www.garlic.com/~lynn/aepay3.htm#riskm

there has been past discussions about re-action to enron (and a few others) was sox. i've observed before that sox puts in a whole lot more auditing .... however auditing tends to be more beneficial if it can uncover inconsistencies between different/independent sets of records/books. in the modern dataprocessing age ... it is possible to leverage dataprocessing to generate a consistent set of corporate books/records regardless of what is actually going on (i.e. it may be necessary to change the whole auditing paradigm in order to look for inconsistencies across independent records). sox does have almost an addenda section that encourages whistle blowers and informants as a mechanism for identifying wrong doing.

recent news item touching on dataprocessing and sox:

IT pros impede PCI, Sarbanes Oxley compliance
http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1267322,00.html

some recent posts mentioning sox:
http://www.garlic.com/~lynn/2007b.html#63 Is Silicon Valley strangeled by SOX?
http://www.garlic.com/~lynn/2007j.html#0 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007j.html#74 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#75 IBM Unionization

as to the PCI scenario ... a lot of that we looked at when we did a detailed threat and vulnerability study in the mid-90s in the x9a10 financial standard working group .... i.e. the x9a10 financial standard working group had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments .... the result was x9.59 standard
http://www.garlic.com/~lynn/x959.html#x959

part of the detailed threat and vulnerability study identified that with relatively trivial amounts of information from previous transactions .... it was possible for an attacker to generate fraudulent financial transactions. This created a requirement that all information going into an existing transaction be kept completely confidential and never divulged to anybody. On the other hand, there are large numbers of business processes that require the information from a transaction ... in order to properly execute the transaction. This creates enormous, diametrically opposing pressures to expose transaction information ... as part of being able of executing the transaction ... and never allowing the transaction information to ever be exposed (even if it prevents the transaction from being executed). The issue is further exacerbated by statistics that upwards of seventy percent of related compromises involved insiders ... many of them required to access the information as part of normal business processes. the resulting observation was that even if the planet was buried under miles of encryption ... it would still be impossible to prevent such information leakage.

some recent posts mentioning some of the issues:
http://www.garlic.com/~lynn/aadsm25.htm#13 Sarbanes-Oxley is what you get when you don't do FC
http://www.garlic.com/~lynn/aadsm26.htm#8 What is the point of encrypting information that is publicly visible?
http://www.garlic.com/~lynn/aadsm27.htm#3 Solution to phishing -- an idea who's time has come?
http://www.garlic.com/~lynn/2007b.html#8 Special characters in passwords was Re: RACF - Password rules
http://www.garlic.com/~lynn/2007b.html#20 How many 36-bit Unix ports in the old days?
http://www.garlic.com/~lynn/2007b.html#60 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#10 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#33 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#53 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007d.html#34 Mixed Case Password on z/OS 1.7 and ACF 2 Version 8
http://www.garlic.com/~lynn/2007e.html#26 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007f.html#75 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007g.html#20 T.J. Maxx data theft worse than first reported
http://www.garlic.com/~lynn/2007i.html#65 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007k.html#76 My Dream PC -- Chip-Based
http://www.garlic.com/~lynn/2007n.html#85 PCI Compliance - Encryption of all non-console administrative access

Hypervisors May Replace Operating Systems As King Of The Data Center

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: Sat, 11 Aug 2007 15:27:53 -0700
Subject: Hypervisors May Replace Operating Systems As King Of The Data Center
Hypervisors May Replace Operating Systems As King Of The Data Center
http://www.informationweek.com/news/showArticle.jhtml?articleID=175001755

from above:
The increased use of virtualization in the data center will enhance the importance of hypervisors and diminish the importance of Windows, Linux, and other general-purpose operating systems.

... snip ...

and recent post from ibm-main on subject of (pr/sm) virtualization:
http://www.garlic.com/~lynn/2007n.html #96 some questions about System z PR/SM

slightly earlier post mentioning vm370 35th announcement anniv at share ... and that cp67's 40th announcement anniv is coming up next spring
http://www.garlic.com/~lynn/2007n.html#92 vm 35th b'day at share in san diego next week

and related follow-up
http://www.garlic.com/~lynn/2007n.html#93 How old are you?

Hypervisors May Replace Operating Systems As King Of The Data Center

Refed: **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: Sat, 11 Aug 2007 15:52:05 -0700
Subject: Re: Hypervisors May Replace Operating Systems As King Of The Data Center
re:
http://www.garlic.com/~lynn/2007o.html#1 Hypervisors May Replace Operating Systems As King Of The Data Center

and other recent items on the subject: VMware Predicts Death To Operating Systems
http://informationweek.com/news/showArticle.jhtml?articleID=201311257
Could Virtual Systems Replace Windows?
http://www.pcworld.com/article/id,135774-c,tradeshows/article.html
Virtualization: Key To Linux Future Or Linux Killer?
http://www.informationweek.com/news/showArticle.jhtml?articleID=202401578
VMware: Linux Is Ideal OS for Virtualization
http://www.internetnews.com/dev-news/article.php/3693656
VMware: Linux Is Ideal OS for Virtualization
http://news.earthweb.com/dev-news/article.php/3693656
VMware: Linux Is Ideal OS for Virtualization
http://itmanagement.earthweb.com/osrc/article.php/3693706
Will VMWare IPO Boost Virtualization?
http://news.earthweb.com/bus-news/article.php/3693661
Will VMWare IPO Boost Virtualization?
http://www.internetnews.com/bus-news/article.php/3693661
'Virtual sandboxing' provides safe security testing
http://www.computerworld.com/action/article.do?command=viewArticleBasic&taxonomyName=security&articleId=9029885&taxonomyId=17

Hypervisors May Replace Operating Systems As King Of The Data Center

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: Sat, 11 Aug 2007 17:27:31 -0700
Subject: Re: Hypervisors May Replace Operating Systems As King Of The Data Center
On Aug 11, 7:53 pm, John Ahlstrom <Ahlstro...@comcast.net> wrote:
Aren't hypervisors there "just" to allow running multiple OSs? Hypervisors are essential, but aren't the apps still going to be written to use the OS APIs?

Also
http://www.networkworld.com/news/2007/080907-linuxworld-vmware-virtual-appliance-a.html?fsrc=rss-security

reports IBM announcing it will replace 4000 servers with Linux VMs running on 30 System Zs.


...
http://www.garlic.com/~lynn/2007o.html#1 Hypervisors May Replace Operating Systems As King Of The Data Center
http://www.garlic.com/~lynn/2007o.html#2 Hypervisors May Replace Operating Systems As King Of The Data Center

they can be ... but they can also be leveraged for a paradigm change with simplified implementations ... referred to as service virtual machines (from the 60s & 70s) ... but new terminology is virtual appliances.

quick use of search engine for a few virtual appliance references:
VMware virtual appliance a threat to the OS
http://www.networkworld.com/news/2007/081007-novell-wins-right-to-unix.html
Virtual Appliance Marketplace - VMware
http://www.vmware.com/appliances/
Virtual appliance - Wikipedia, the free encyclopedia
https://en.wikipedia.org/wiki/Virtual_appliance
The Stanford Collective Group; A Virtual Appliance Computing Infrastructure
http://suif.stanford.edu/collective/
Red Hat to Build Virtual Appliance OS for Managing Intel vPro-based Desktops
http://www.redhat.com/about/news/prarchive/2007/vpro_appliance.html
VMWare's Virtual Appliance Showroom
http://www.internetnews.com/dev-news/article.php/3629496 Virtual appliance for email archiving and electronic discovery with VMware
http://www.inboxer.com/virtual-appliance.shtml
How to convert a VMWare virtual appliance to work with Parallels
http://www.virtualizationdaily.com/archives/73_how-to-convert-a-vmware-virtual-appliance-to-work-with-parallels.html
Virtual appliances cure appliance bloat
http://www.newsdaily.com/stories/bre90u07r-us-deutschebank-q4/
The Ultimate Virtual Appliance Challenge
http://www.vmwarez.com/2006/02/ultimate-virtual-appliance-challenge.html
Red Hat to Build a Virtual Appliance OS
http://www.eweek.com/article2/0,1759,2127848,00.asp
VMware Ultimate Virtual Appliance Challenge - Time is Running Out!
http://weblog.infoworld.com/virtualization/archives/2006/05/vmware_ultimate.html
The case for chargeback and virtual appliances
http://servervirtualization.blogs.techtarget.com/2007/08/02/the-case-for-chargeback-and-virtual-appliances/


...e old posts mentioning service virtual machines and/or virtual appliances
http://www.garlic.com/~lynn/2002m.html#26 Original K & R C Compilers
http://www.garlic.com/~lynn/2003c.html#77 COMTEN- IBM networking boxes
http://www.garlic.com/~lynn/2004q.html#72 IUCV in VM/CMS
http://www.garlic.com/~lynn/2005.html#59 8086 memory space
http://www.garlic.com/~lynn/2005j.html#58 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2006p.html#10 What part of z/OS is the OS?
http://www.garlic.com/~lynn/2006t.html#45 To RISC or not to RISC
http://www.garlic.com/~lynn/2006t.html#46 To RISC or not to RISC
http://www.garlic.com/~lynn/2006v.html#22 vmshare
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#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#8 vmshare
http://www.garlic.com/~lynn/2007i.html#21 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#36 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007k.html#26 user level TCP implementation
http://www.garlic.com/~lynn/2007k.html#48 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007m.html#67 Operating systems are old and busted
http://www.garlic.com/~lynn/2007m.html#70 Is Parallel Programming Just Too Hard?

Hypervisors May Replace Operating Systems As King Of The Data Center

Refed: **, - **, - **, - **
From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: Sat, 11 Aug 2007 17:51:34 -0700
Subject: Re: Hypervisors May Replace Operating Systems As King Of The Data Center
re:
http://www.garlic.com/~lynn/2007o.html#1 Hypervisors May Replace Operating Systems As King Of The Data Center
http://www.garlic.com/~lynn/2007o.html#2 Hypervisors May Replace Operating Systems As King Of The Data Center
http://www.garlic.com/~lynn/2007o.html#3 Hypervisors May Replace Operating Systems As King Of The Data Center

it might also be considered a variation on some of the microkernel efforts ... except a decade or two earlier.

the paradigm can also be used for partitioning of different components improving integrity and isolating failures/compromises

for a little topic drift ... a recent thread or two
http://www.garlic.com/~lynn/aadsm27.htm#47 If your CSO lacks an MBA, fire one of you
http://www.garlic.com/~lynn/aadsm27.htm#48 If your CSO lacks an MBA, fire one of you
http://www.garlic.com/~lynn/aadsm27.htm#49 If your CSO lacks an MBA, fire one of you
http://www.garlic.com/~lynn/aadsm27.htm#50 If your CSO lacks an MBA, fire one of you
http://www.garlic.com/~lynn/aadsm27.htm#52 more on firing your MBA-less CSO
http://www.garlic.com/~lynn/aadsm27.htm#53 Doom and Gloom spreads, security revisionism suggests "H6.5: Be an adept!"
http://www.garlic.com/~lynn/aadsm27.htm#54 Security can only be message-based?

The Unexpected Fact about the First Computer Programmer

Refed: **, - **, - **, - **, - **
From: lynn@garlic.com
Date: Sun, 12 Aug 2007 06:56:07 -0700
Subject: Re: The Unexpected Fact about the First Computer Programmer
Newsgroups: alt.folklore.computers
re:
http://www.garlic.com/~lynn/2007o.html#0 The Unexpected Fact about the First Computer Programmer

for other topic drift on any attempts to bury the planet under miles of encryption:

The TJX Effect (data breach)
http://www.informationweek.com/showArticle.jhtml?articleID=181502068

and

Banks Test 'Text Messaging' Security
http://www.paymentsnews.com/2007/08/banks-test-text.html
Banks Test 'Text Messaging' Security
http://money.cnn.com/news/newsfeeds/articles/newstex/IBD-0001-18794249.htm

from above:
Banks and brokerages have been on the hunt for just the right way to boost log-on and transaction security for customers. They seek the perfect balance of convenience and cost.

... snip ...

note in referenced article, part of the issue is when they get things wrong

this references some pilots spending significant amounts of money before realizing that they won't work and aborting the issues
http://www.garlic.com/~lynn/aadsm27.htm#52 more on firing your MBA-less CSO

or like in the YES CARD scenario
http://www.garlic.com/~lynn/subintegrity.html#yescard
and/or are distracted by technology and loose focus addressing the important issue (which can contributed significantly to the cost, even tho unrelated to the purpose) ... counter example was aads chip strawman
http://www.garlic.com/~lynn/x959.html#aads
they've also had issues with static authentication information (no matter how complicated and/or obfuscated) is vulnerable to mitm attacks
http://www.garlic.com/~lynn/subintegrity.html#mitm

Man-in-the-middle phishing kits circulating freely on the Web

some specific postings discussing mitm-attack
http://www.garlic.com/~lynn/aadsm19.htm#21 Citibank discloses private information to improve security
http://www.garlic.com/~lynn/aadsm26.htm#28 man in the middle, SSL
http://www.garlic.com/~lynn/aadsm26.htm#30 man in the middle, SSL
http://www.garlic.com/~lynn/aadsm26.htm#31 man in the middle, SSL ... addenda 2
http://www.garlic.com/~lynn/aadsm26.htm#56 Threatwatch: MITB spotted: MITM over SSL from within the browser
http://www.garlic.com/~lynn/2007d.html#26 Securing financial transactions a high priority for 2007

Loads Weighing Heavily on Roads

Refed: **, - **, - **
From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: Tue, 14 Aug 2007 05:13:18 -0700
Subject: Re: Loads Weighing Heavily on Roads
On Aug 14, 6:26 am, jmfbah...@aol.com wrote:
Of course. And the real maintenance is not done.

re:
http://www.garlic.com/~lynn/2007n.html#97 Loads Weighing Heavily on Roads

on and off over the yrs we've had similar discussions about the deferred maint. that went on in the railroads during the 60s and 70s. eventually the infrastructure deficit (related to things like deferred maint) appeared to exceed the perceived total corporate value.

misc. past refs
http://www.garlic.com/~lynn/2001e.html#75 Apology to Cloakware (open letter)
http://www.garlic.com/~lynn/2002q.html#7 Big Brother -- Re: National IDs
http://www.garlic.com/~lynn/2003i.html#41 TGV in the USA?
http://www.garlic.com/~lynn/2004e.html#7 OT Global warming
http://www.garlic.com/~lynn/2005c.html#3 The mid-seventies SHARE survey
http://www.garlic.com/~lynn/2006h.html#18 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#19 The Pankian Metaphor

Hypervisors May Replace Operating Systems As King Of The Data Center

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: Tue, 14 Aug 2007 08:27:25 -0700
Subject: Re: Hypervisors May Replace Operating Systems As King Of The Data Center
ref:
http://www.garlic.com/~lynn/2007o.html#1 Hypervisors May Replace Operating Systems As King Of The Data Center
http://www.garlic.com/~lynn/2007o.html#2 Hypervisors May Replace Operating Systems As King Of The Data Center
http://www.garlic.com/~lynn/2007o.html#3 Hypervisors May Replace Operating Systems As King Of The Data Center
http://www.garlic.com/~lynn/2007o.html#4 Hypervisors May Replace Operating Systems As King Of The Data Center

the standard home platform has a number of different (and diametrically opposing) requirements. The unconnected, home, gaming pc ... allowed arbitrary applications to completely take-over the home machine. The use in the business environment was terminal emulation but otherwise a unconnected desktop machine. Later this business environment expanded to include purely local business network ... but still didn't have to worry about countermeasures for hostile attackers.

the internet appliance application would have a starting point of extremely fixed software operation w/o being able to introduce malicious (or most other kinds of) code.

the use of the same platform ... originating from a heritage with no requirement for countermeasures against hostile attackers ... for both things like purely personal gaming use (and applications that take over the whole machine) and for internet surfing ... creates diametrically opposing requirements.

this opposing operational requirement dichotomy can be considered significant contribution to the large existing botnets (where malicious applications have surreptitiously taking over control of large number of machines).

2-3 yrs ago, Jim cajoled me into interviewing for the position of chief security architect. there never was agreement on the terms for the position ... but I did spend a lot of time discussing the diametrically opposing requirements being placed on the platform.

attempting to resolve the opposing requirements is one of the things that hypervisor and virtualization is being billed for. connectivity to the internet and potentially extremely hostile attacks is done in a strictly constrained environment ... which is frequently rebuilt fresh and is discarded when it is no longer being used. This drastically restricts the damage that an hostile attack is able to achieve.

misc. recent posts mentioning Jim
http://www.garlic.com/~lynn/2007.html#1 "The Elements of Programming Style"
http://www.garlic.com/~lynn/2007.html#13 "The Elements of Programming Style"
http://www.garlic.com/~lynn/2007d.html#4 Jim Gray Is Missing
http://www.garlic.com/~lynn/2007d.html#6 Jim Gray Is Missing
http://www.garlic.com/~lynn/2007d.html#8 Jim Gray Is Missing
http://www.garlic.com/~lynn/2007d.html#17 Jim Gray Is Missing
http://www.garlic.com/~lynn/2007d.html#33 Jim Gray Is Missing
http://www.garlic.com/~lynn/2007g.html#28 Jim Gray Is Missing
http://www.garlic.com/~lynn/2007i.html#68 A tribute to Jim Gray

misc. recent botnet items
Criminals Using Botnet To Attack iPhone Buyers
http://www.informationweek.com/news/showArticle.jhtml?articleID=201400215
FBI, Carnegie Mellon Identify 1 MM BotNet Nodes
http://campustechnology.com/articles/49053/
Storm Botnet Driving PDF Spam
http://www.securitypronews.com/news/securitynews/spn-45-20070713StormBotnetDrivingPDFSpam.html
Why we're losing the botnet battle
http://www.networkworld.com/news/2007/080107-ibm-data-centers-green.html
ISPs may not be doing enough about botnets
http://arstechnica.com/news.ars/post/20070731-isps-may-not-be-doing-enough-about-botnets.html
Invasion of Botnets, Trojans, Worms Malware - DA issues fraud alert
http://www.thecherrycreeknews.com/content/view/1603/2/


...re>

Original Colossal Cave Adventure

Refed: **, - **, - **, - **
From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: Tue, 14 Aug 2007 12:56:05 -0700
Local: Tues, Aug 14 2007 3:56 pm
Subject: Re: Original Colossal Cave Adventure
On Aug 14, 2:44 pm, Al Balmer <albal...@att.net> wrote:
I admit to having spent some time playing Adventure on our Varian Data Machines minicomputers :-) I don't remember much of it (close to 30 years ago), but I remember XYZZY, the two varieties of twisty passages, and how to kill the dragon. According to this article, it was probably the Woods variation, since the dragon was his.

varian was early cp67 customer ... some number of the people moved on to lsi logic (bringing vm370 with them) ... old post/ref
http://www.garlic.com/~lynn/2001c.html#53 Varian (was Re: UNIVAC - Help ??)

posts w/old email regarding tracking down copy of adventure for vm370/ cms:
http://www.garlic.com/~lynn/2006y.html#18 The History of Computer Role-Playing Games
http://www.garlic.com/~lynn/2007m.html#6 Zork and Adventure

I then redistributed executables on the internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet

... and would send the source to anybody getting to 300pts.

Hypervisors May Replace Operating Systems As King Of The Data Center

Refed: **, - **, - **
From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: Tue, 14 Aug 2007 14:11:51 -0700
Subject: Re: Hypervisors May Replace Operating Systems As King Of The Data Center
re:
http://www.garlic.com/~lynn/2007o.html#1 Hypervisors May Replace Operating Systems As King Of The Data Center
http://www.garlic.com/~lynn/2007o.html#2 Hypervisors May Replace Operating Systems As King Of The Data Center
http://www.garlic.com/~lynn/2007o.html#3 Hypervisors May Replace Operating Systems As King Of The Data Center
http://www.garlic.com/~lynn/2007o.html#4 Hypervisors May Replace Operating Systems As King Of The Data Center
http://www.garlic.com/~lynn/2007o.html#7 Hypervisors May Replace Operating Systems As King Of The Data Center

new crop of virtualization items
Intel boosts virtualization with quad-core Xeons
http://news.com.com/Intel+boosts+virtualization+with+quad-core+Xeons/2100-1006_3-6202470.html
Intel boosts virtualization with quad-core Xeons
http://news.zdnet.com/2100-9584_22-6202470.html
VMWare surge puts virtualization in the spotlight
http://news.com.com/VMWare+surge+puts+virtualization+in+the+spotlight/2100-1012_3-6202553.html
VMWare surge puts virtualization in the spotlight
http://news.zdnet.com/2100-3513_22-6202553.html
XenSource new release closes gap with VMware
http://www.networkworld.com/news/2007/100407-feds-pull-ca-gov-domain.html
Virtualization--threat or menace?
http://news.com.com/8301-10784_3-9758794-7.html


...re>

IBM 8000 series

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Newsgroups: alt.folklore.computers, comp.arch
Date: Wed, 15 Aug 2007 06:07:43 -0700
Subject: Re: IBM 8000 series
On Aug 15, 4:34 am, Mike Hore <mike_hore...@OVE.invalid.aapt.net.au> wrote:
2. Insufficient address bits. Yes, this series followed the time-honored tradition. 16 bits was never going to be enough in 1961. ISTR that we need about 2 more address bits every 3 years. The 7090 came out in 1959 with 15 address bits, but that architecture was already near the end of its life (which is why there was an 8000 series after all), so if these new machines were planned to last say 10 years they would have needed (on this calculation) about 8 more address bits than that, or 23. These were 64-bit words, but that wouldn't make much difference. The initial 360 had 24 address bits in 1964, or 21 if we correct to 64-bit units, and this address needed to be extended to 31 bits in 1983, though reading Pugh et al it seems that 24 were getting a bit inadequate even as early as 1975. So 16 in 1961 was definitely short-sighted. Even if my number 23 is a bit generous, surely at least 20 would have been needed.

360/67 could be considered a 360/65 that had hardware translate (virtual addressing) box added ... that supported both 24-bit and 32-bit virtual addressing ... this was the machine that cp67 (virtual machine and virtual memory support) was built on.

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

had earlier done a virtual machine/memory implementation on a custom modified 360/40 ... pending general availability of 360/67 (i.e. and morphing cp/40 into cp/67).

370 was initially announced w/o virtual memory ... but not too long later, virtual memory was announced for all 370s ... and cp67 morphed into vm370 (with virtual memory and virtual machine support). 370s only had 24-bit virtual addressing mode.

by the mid-70s there were starting to be almost two separate issues ... restrictions because of 24-bit real addressing ... somewhat separate from restrictions because of 24-bit virtual addressing.

the 24-bit virtual addressing was exaserbated by the way the favorite son operating system was moved from real addressing to virtual addressing. the favorite son operating system had been making extensive use of pointer passing APIs (somewhat optimized for small real storage environment).

In the translation of that operating system into virtual memory environment, they eventually got around to having a separate virtual address space for every application ... however the 16mbyte space (24-bits) was divided in half with an 8mbyte image of the kernel appearing in every virtual address space. This theoretically left 8mbytes for applications (i.e. kernel code, resident in every virtual address space, could directly access application parameters).

However, there were these "subsystems" (system services that had resided outside the kernel) that were moved into their own virtual address space. The issue here was that there were still pointer-passing API between normal application and subsystem services in a different virtual address space (having kernel code resident in every virtual address space got around the problem for kernel calls).

The initial solution to the pointer-passing API between different virtual address spaces ... was to define a "common segment" that also resided in every virtual address space ... this was sort of a scratch parameter passing region ... where an application could obtain some space ... stuff in parameters and pass the address to the parameters in the API. The size of the "common segment" started out at 1mbyte ... but for typical installations with normal set of subsystem services it could be 4-5 mbytes .... which then only left 3-4 mbytes max for applications (and for larger installation the number of subsystem services were increasingly putting lots of pressure on increasing the common segment size ... at the same time having larger applications that needed more than 2-3 mbytes).

late in the 70s, "dual address space" mode was introduced for 3033. this allowed parameter passing API between virtual address spaces and semi-privileged subsystem services had special addressing modes that allowed them to use pointers to directly access data in other virtual address spaces (removing pressure on increasing size of the common segment for using pointer-passing API between virtual address spaces, aka subsystems could directly access application virtual address space w/o the need of a "common segment". This was later generalized to being able to address several different virtual address spaces (in addition to having 31-bit and 64-bit virtual addressing modes ... there is also the capability of accessing multiple different virtual address spaces)

the other problem starting to appear in the mid-70s was the 16mbyte restriction on real storage size. processor thruput was increasing much faster than disk thruput was increasing. as a result, real memory was being leveraged more and more as caching to compensate for limitations in disk thruput.

there was scenario where cluster of 4341 machines might have more aggregate processor thruput at less cost than a 3033 ... and the 4341 cluster could also have 5-6 times more aggregate real memory than 3033.(because of the 16mbyte limitations on both real and virtual addressing). Somewhat to compensate for this ... there was a page-table hack introduced with the 3033 that could allow real addressing of 64mbytes. The standard 370 page table entry was 16bits ... two defined flag bits, 12bit page number and two undefined bits. 12bit page number with 4096byte pages ... gave 24bit (real) addressing or 16mbytes. The PTE hack was to take the two undefined bits and turn them into page number bits. ... giving 14bit (real) page number .... for a total of 64mbytes. Instructions could only directly form 24bit address .... but translated thru the virtual page translation ... could come up with a 26bit effective real address.

misc. past post mentioning the PTE hack for 14bit page numbers
http://www.garlic.com/~lynn/93.html#14 S/360 addressing
http://www.garlic.com/~lynn/2001b.html#69 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001i.html#13 GETMAIN R/RU (was: An IEABRC Adventure)
http://www.garlic.com/~lynn/2001m.html#15 departmental servers
http://www.garlic.com/~lynn/2002c.html#40 using >=4GB of memory on a 32-bit processor
http://www.garlic.com/~lynn/2002d.html#51 Hardest Mistake in Comp Arch to Fix
http://www.garlic.com/~lynn/2003d.html#26 Antiquity of Byte-Word addressing?
http://www.garlic.com/~lynn/2004.html#17 Holee shit! 30 years ago!
http://www.garlic.com/~lynn/2004c.html#6 If the x86 ISA could be redone
http://www.garlic.com/~lynn/2004g.html#20 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004n.html#50 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004o.html#57 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005.html#34 increasing addressable memory via paged memory?
http://www.garlic.com/~lynn/2005.html#43 increasing addressable memory via paged memory?
http://www.garlic.com/~lynn/2005m.html#28 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005p.html#1 Intel engineer discusses their dual-core design
http://www.garlic.com/~lynn/2005p.html#19 address space
http://www.garlic.com/~lynn/2005q.html#30 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005u.html#44 POWER6 on zSeries?
http://www.garlic.com/~lynn/2006b.html#34 Multiple address spaces
http://www.garlic.com/~lynn/2006c.html#8 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006l.html#2 virtual memory
http://www.garlic.com/~lynn/2006m.html#27 Old Hashing Routine
http://www.garlic.com/~lynn/2006p.html#0 DASD Response Time (on antique 3390?)
http://www.garlic.com/~lynn/2006s.html#42 Ranking of non-IBM mainframe builders?

misc. past posts mentioning dual-address space mode:
http://www.garlic.com/~lynn/2002g.html#17 Black magic in POWER5
http://www.garlic.com/~lynn/2002g.html#18 Black magic in POWER5
http://www.garlic.com/~lynn/2002l.html#51 Handling variable page sizes?
http://www.garlic.com/~lynn/2002l.html#57 Handling variable page sizes?
http://www.garlic.com/~lynn/2003d.html#53 Reviving Multics
http://www.garlic.com/~lynn/2003d.html#69 unix
http://www.garlic.com/~lynn/2003g.html#13 Page Table - per OS/Process
http://www.garlic.com/~lynn/2003m.html#29 SR 15,15
http://www.garlic.com/~lynn/2004f.html#53 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004n.html#26 PCIe as a chip-to-chip interconnect
http://www.garlic.com/~lynn/2004n.html#54 CKD Disks?
http://www.garlic.com/~lynn/2004o.html#18 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004o.html#57 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005.html#3 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005b.html#53 The mid-seventies SHARE survey
http://www.garlic.com/~lynn/2005c.html#63 intel's Vanderpool and virtualization in general
http://www.garlic.com/~lynn/2005d.html#62 Misuse of word "microcode"
http://www.garlic.com/~lynn/2005f.html#7 new Enterprise Architecture online user group
http://www.garlic.com/~lynn/2005f.html#57 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005p.html#18 address space
http://www.garlic.com/~lynn/2005p.html#19 address space
http://www.garlic.com/~lynn/2005q.html#41 Instruction Set Enhancement Idea
http://www.garlic.com/~lynn/2005q.html#48 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2006.html#39 What happens if CR's are directly changed?
http://www.garlic.com/~lynn/2006b.html#25 Multiple address spaces
http://www.garlic.com/~lynn/2006b.html#28 Multiple address spaces
http://www.garlic.com/~lynn/2006e.html#0 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006i.html#33 virtual memory
http://www.garlic.com/~lynn/2006p.html#10 What part of z/OS is the OS?
http://www.garlic.com/~lynn/2006r.html#26 A Day For Surprises (Astounding Itanium Tricks)
http://www.garlic.com/~lynn/2006r.html#32 MIPS architecture question - Supervisor mode & who is using it?
http://www.garlic.com/~lynn/2006s.html#42 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006t.html#23 threads versus task
http://www.garlic.com/~lynn/2006x.html#23 Multiple mappings
http://www.garlic.com/~lynn/2006y.html#16 "The Elements of Programming Style"
http://www.garlic.com/~lynn/2006y.html#39 Multiple mappings
http://www.garlic.com/~lynn/2007g.html#59 IBM to the PCM market(the sky is falling!!!the sky is falling!!)
http://www.garlic.com/~lynn/2007k.html#14 Some IBM 3033 information
http://www.garlic.com/~lynn/2007k.html#27 user level TCP implementation
http://www.garlic.com/~lynn/2007k.html#28 IBM 360 Model 20 Questions
http://www.garlic.com/~lynn/2007l.html#71 IBM 360 Model 20 Questions

misc. past posts about observing that processor thruput was increasing much faster than disk thruput
http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door
http://www.garlic.com/~lynn/94.html#43 Bloat, elegance, simplicity and other irrelevant concepts
http://www.garlic.com/~lynn/94.html#55 How Do the Old Mainframes Compare to Today's Micros?
http://www.garlic.com/~lynn/95.html#10 Virtual Memory (A return to the past?)
http://www.garlic.com/~lynn/98.html#46 The god old days(???)
http://www.garlic.com/~lynn/99.html#4 IBM S/360
http://www.garlic.com/~lynn/2001d.html#66 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001f.html#62 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001f.html#68 Q: Merced a flop or not?
http://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)
http://www.garlic.com/~lynn/2001l.html#61 MVS History (all parts)
http://www.garlic.com/~lynn/2001m.html#23 Smallest Storage Capacity Hard Disk?
http://www.garlic.com/~lynn/2002.html#5 index searching
http://www.garlic.com/~lynn/2002b.html#11 Microcode? (& index searching)
http://www.garlic.com/~lynn/2002b.html#20 index searching
http://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?
http://www.garlic.com/~lynn/2002e.html#9 What are some impressive page rates?
http://www.garlic.com/~lynn/2002i.html#16 AS/400 and MVS - clarification please
http://www.garlic.com/~lynn/2003i.html#33 Fix the shuttle or fly it unmanned
http://www.garlic.com/~lynn/2004n.html#22 Shipwrecks
http://www.garlic.com/~lynn/2004p.html#39 100% CPU is not always bad
http://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new?
http://www.garlic.com/~lynn/2005k.html#53 Performance and Capacity Planning
http://www.garlic.com/~lynn/2006m.html#32 Old Hashing Routine
http://www.garlic.com/~lynn/2006o.html#27 oops
http://www.garlic.com/~lynn/2006x.html#13 The Future of CPUs: What's After Multi-Core?

Original Colossal Cave Adventure

From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: Wed, 15 Aug 2007 12:11:01 -0700
Subject: Re: Original Colossal Cave Adventure
On Aug 15, 2:24 pm, Charles Richmond <friz...@tx.rr.com> wrote:
I have heard of an Adventure version in PL/I, but I have *never* been able to locate it.

re:
http://www.garlic.com/~lynn/2007o.html#8 Original Colossal Cave Adventure

when i was distributing advent internally ... pli was being handled out of stl. one of the people in stl got their 300 pts and so i sent them a copy of the fortran source. they produced a pli version enhanced to something like 550 pts

referenced in above post was pointer to post earlier this yr
http://www.garlic.com/~lynn/2007m.html#6 Zork and Adventure

which includes old email mentioning pli version
http://www.garlic.com/~lynn/2007m.html#email780517

as mentioned in the post ... i have references to the files ... but no longer have the actual files.

more transactional memory for mutlithread/multiprocessor operation

From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: Thu, 16 Aug 2007 06:27:46 -0700
Subject: more transactional memory for mutlithread/multiprocessor operation
Sun Gives Multithreading an RDBMS Feel
http://itmanagement.earthweb.com/entdev/article.php/3694666

from above:

"Transactional memory's promise is to make all this automatic, to make sure you don't all interfere with each other. You just write the code to get done and the system makes sure they don't interfere with each other," said Moir.

... snip ...

lots of past posts mentioning rdbms and/or original sql/relational implementation
http://www.garlic.com/~lynn/submain.html#systemr

lots of past posts mentioning compare&swap instruction and/or multiprocessor operation
http://www.garlic.com/~lynn/subtopic.html#smp

misc. past posts mentioning transactional memory
http://www.garlic.com/~lynn/2005r.html#27 transactional memory question
http://www.garlic.com/~lynn/2005s.html#33 Power5 and Cell, new issue of IBM Journal of R&D
http://www.garlic.com/~lynn/2007b.html#44 Why so little parallelism?
http://www.garlic.com/~lynn/2007n.html#6 Is Parallel Programming Just Too Hard?
http://www.garlic.com/~lynn/2007n.html#36 How to flush data most efficiently from memory to disk when db checkpoint?

EZPass: Yes, Big Brother IS Watching You!

Refed: **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Newsgroups: alt.folklore.computers, misc.transport.road
Date: Thu, 16 Aug 2007 06:43:11 -0700
Subject: Re: EZPass: Yes, Big Brother IS Watching You!
On Aug 16, 12:19 am, "k_fl...@lycos.com" <k_fl...@lycos.com> wrote:
There is a difference between "personal information" and "invasion of privacy." I can gather lots of personal information on people (in fact, I do and get paid for it!) but it is all public record.

we were co-authors of the financial industry x9.99 standard regarding privacy and personal information (which is starting to slowly progress at international level). we had to look at a number of different related areas ... including glba, hipaa, and eu-dpd. as part of the effort ... i did a merged taxonomy and glossary subset
http://www.garlic.com/~lynn/index.html#glosnote

specific for privacy
http://www.garlic.com/~lynn/privacy.htm

Geothermal was: VLIW pre-history

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: Thu, 16 Aug 2007 06:53:11 -0700
Subject: Re: Geothermal was: VLIW pre-history
On Aug 16, 9:03 am, Quadibloc <jsav...@ecn.ab.ca> wrote:
Of course, places with hydroelectric power have long used their excess off-peak power for such purposes as making aluminum or heavy water. One criticism of nuclear power is that it is a baseload source of power, producing constant output.

grand coulee dam uses electricity to pump water up into the grand coulee ... which then flows into central washington to provide irrigation from something like million(?) acres.

the pumps are reversable ... they actually pump excess water in off-peak hrs and reverse the flow during peak hrs.
https://en.wikipedia.org/wiki/Grand_Coulee_Dam
http://www.usbr.gov/power/data/sites/grandcou/grandcou.html

"Atuan" - Colossal Cave in APL?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: Thu, 16 Aug 2007 18:09:01 -0700
Subject: Re: "Atuan" - Colossal Cave in APL?
On Aug 16, 4:12 pm, anders.johan...@gmail.com wrote:
I visited a data center when I was a kid, perhaps 10 years old, and I distinctly remember laying a text-based adventure called "Atuan". I have always assumed that was Colossal Cave adventure, but now I wonder...

Can anybody elaborate on this? All Google can tell me is that this may > have been a re-implementation of CC in APL, but that's not much to go > on.


re:
http://www.garlic.com/~lynn/2007o.html#8 Original Colossal Cave Adventure
http://www.garlic.com/~lynn/2007o.html#11 Original Colossal Cave Adventure

from long ago and far away:

Date: 09/12/79 22:26:39
From: wheeler

have heard of ZORK but don't know of an available version. Will check around. ATUAN is the latest ADVENTURE version with several new places and activities, etc. The newest game we have is INV but it is 3270 version. It is very much like the SPACE Invaders video game. Unless you get a boot-legged copy, the 'standard' version won't play between 9&noon and 1&5 (7 days a week, just users O/S time macro, doesn't figure out the day)


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

Hypervisors May Replace Operating Systems As King Of The Data Center

From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: Fri, 17 Aug 2007 05:40:51 -0700
Subject: Re: Hypervisors May Replace Operating Systems As King Of The Data Center
re:
http://www.garlic.com/~lynn/2007o.html#7 Hypervisors May Replace Operating Systems As King Of The Data Center

recent botnet item

Storm Botnet Puts Up Defenses And Starts Attacking Back
http://www.informationweek.com/news/showArticle.jhtml?articleID=20180...

from above:
Researchers are warning universities that they're at risk of being hit with massive distributed denial-of-service attacks when they scan their own networks.

... snip ...

FORTRAN IV program illustrating assigned GO TO on web site

From: lynn@garlic.com
Newsgroups: alt.folklore.computers, comp.lang.fortran
Date: Sat, 18 Aug 2007 09:09:20 -0700
Subject: Re: FORTRAN IV program illustrating assigned GO TO on web site
On Aug 18, 9:51 am, krw <k...@att.bizzzz> wrote:
The only religion with more priests is EMACS.

try rdbms. part of the religious annealing process can be having an opposing foe early in its development. the early scenario between bldg. 90 (60s dbms) and bldg. 28 (rdbms) as that the stl guys were claiming that rdbms typically doubled the physical disk space and significantly increased the disk accesses. the rdbms counter-argument was that the relational paradigm abstracted away the physical pointers (along with the index implementation under the covers) and significantly reduced the ongoing human/administrative overhead.

something of the change-over was in the early to mid 80s ... when amount of disk space significantly increased while the cost significantly decreased ... along with the significant increase in real memory sizes allowing the indexes to be cached ... significantly reducing the necessary physical disk accesses. overall people resources were constrained and becoming more expensive (i.e. cost associated with 60s physical dbms) and the hardware was becoming much more plentiful and less expensive.

while the physical management of the pointers has been abstracted with the index management (mostly) automatically handled by the infrastructure ... there is still enough of the index abstraction exposed in the typical implementations that it frequently requires human/administrative effort to transform (and maintain) information structures in the necessary index abstraction

misc. past posts about original rdbms/sql implementation
http://www.garlic.com/~lynn/submain.html#systemr

note that at the same time i was involved in various details of the original rdbms/sql implementation ... i also got involved in a dbms effort with some of the same objectives (abstraction that eliminated manual effort/maint related to pointers) as rdbms ... but also attempted to drastically reduce the manual effort/activity related to the rdbms index abstraction (normalization, unique indexes, uniformity/homogeneity of large amounts of information).

some of that background i've used to apply to the rfc index
http://www.garlic.com/~lynn/rfcietff.htm

and the merged glossary/taxonomies
http://www.garlic.com/~lynn/index.html#glosnotes

Flying Was: Fission products

Refed: **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: Sat, 18 Aug 2007 09:21:33 -0700
Subject: Re: Flying Was: Fission products
On Aug 17, 8:21 pm, ArarghMail708NOS...@NOT.AT.Arargh.com wrote:
And, I don't particularly trust the ATC system

one of the ATC-modernization projects from the late 80s (nearly 20yrs now) attempted to leverage all sorts of new technology to automagically handle all failure modes. However, there was effectively an assumption that all failure/glitches would be computer and/or electronic related. The idea was that the actual application could be written as if failure/glitches didn't exist ... and the underlying system would have recovery to mask all possible failure/glitches from the application.

We had already gotten involved doing the ha/cmp product
http://www.garlic.com/~lynn/subtopic.html#hacmp

and got called in to review some of the details. Turns out there could be numerous domain specific process glitches ... that would be outside the scope of the underlying system implementation ... it would require application specific knowledge to recognize and handle (which required significant change to the original design point ... that assumed the application didn't need glitch/recovery logic ... because it could all be handled at the underlying system level).

Geothermal was: VLIW pre-history

From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: Sat, 18 Aug 2007 09:38:39 -0700
Subject: Re: Geothermal was: VLIW pre-history
re:
http://www.garlic.com/~lynn/2007o.html#14 Geothermal was: VLIW pre-history

and now for something completely different ...

Heat Threatens Safety of Nuclear Reactors as France Girds for Electricity Rationing
http://www.commondreams.org/headlines03/0811-03.htm
Heat Wave Shuts Down Alabama Reactor
http://hardware.slashdot.org/hardware/07/08/18/131226.shtml
TVA reactor shut down; cooling water from river too hot
http://www.chron.com/disp/story.mpl/business/energy/5061439.html

from above:
The nation's largest public utility shut down Unit 2 about 5:42 p.m. CDT because water drawn from the Tennessee River was exceeding a 90- degree average over 24 hours, amid a blistering heat wave across the Southeast.

"We don't believe we've ever shut down a nuclear unit because of river temperature," said John Moulton, spokesman for the Knoxville, Tenn.- based utility.


... snip ...

U.S. Cedes Top Spot in Global IT Competitiveness

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: Sat, 18 Aug 2007 13:31:28 -0700
Subject: U.S. Cedes Top Spot in Global IT Competitiveness
re:
http://www.garlic.com/~lynn/2007g.html#6 U.S. Cedes Top Spot in Global IT Competitiveness
http://www.garlic.com/~lynn/2007g.html#7 U.S. Cedes Top Spot in Global IT Competitiveness
http://www.garlic.com/~lynn/2007g.html#34 U.S. Cedes Top Spot in Global IT Competitiveness
http://www.garlic.com/~lynn/2007g.html#35 U.S. Cedes Top Spot in Global IT Competitiveness
http://www.garlic.com/~lynn/2007g.html#52 U.S. Cedes Top Spot in Global IT Competitiveness
http://www.garlic.com/~lynn/2007g.html#68 U.S. Cedes Top Spot in Global IT Competitiveness
http://www.garlic.com/~lynn/2007i.html#13 U.S. Cedes Top Spot in Global IT Competitiveness
http://www.garlic.com/~lynn/2007l.html#22 U.S. Cedes Top Spot in Global IT Competitiveness

recent addenda for an old thread:

Failing Our Geniuses
http://slashdot.org/articles/07/08/17/211255.shtml
Are We Failing Our Geniuses?
http://www.time.com/time/magazine/article/0,9171,1653653,00.html

from above:
To some extent, complacency is built into the system. American schools spend more than $8 billion a year educating the mentally retarded. Spending on the gifted isn't even tabulated in some states, but by the most generous calculation, we spend no more than $800 million on gifted programs. But it can't make sense to spend 10 times as much to try to bring low-achieving students to mere proficiency as we do to nurture those with the greatest potential.

... snip ...

U.S. Cedes Top Spot in Global IT Competitiveness

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: Sun, 19 Aug 2007 05:42:48 -0700
Subject: Re: U.S. Cedes Top Spot in Global IT Competitiveness
On Aug 18, 5:31 pm, CBFalconer <cbfalco...@yahoo.com> wrote:
I don't know about that. The gifted are probably quite capable of self-care, and are quite likely to reject unrequested assistance.

re:
http://www.garlic.com/~lynn/2007o.html#20 U.S. Cedes Top Spot in Global IT Competitiveness

that may be more a question of the quality of the educational system ... possibly geared towards the extremely disadvantage ... resulting in one of the higher per capital spending but at the bottom of the 20 industrial nations in effectiveness (i.e. really gifted currently can only benefit from doing it on their own ... since the majority of the system is clearly not setup to benefit them)

misc. other posts on the subject from earlier this year ... including half the high school age graduates are functionally illiterate
http://www.garlic.com/~lynn/2007i.html#24 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#79 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007j.html#31 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#51 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#80 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#85 IBM Unionization
http://www.garlic.com/~lynn/2007k.html#10 IBM Unionization
http://www.garlic.com/~lynn/2007k.html#30 IBM Unionization
http://www.garlic.com/~lynn/2007k.html#34 IBM Unionization
http://www.garlic.com/~lynn/2007k.html#42 IBM Unionization
http://www.garlic.com/~lynn/2007n.html#68 Poll: oldest computer thing you still use

U.S. Cedes Top Spot in Global IT Competitiveness

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: Sun, 19 Aug 2007 06:33:42 -0700
Subject: Re: U.S. Cedes Top Spot in Global IT Competitiveness
re:
http://www.garlic.com/~lynn/2007o.html#20 U.S. Cedes Top Spot in Global IT Competitiveness
http://www.garlic.com/~lynn/2007o.html#21 U.S. Cedes Top Spot in Global IT Competitiveness

so the other part is society being required to subsidize individuals that contribute less to society than they use.

one aspect of this is old posts about census dept. estimating that half the industrial jobs had to be subsidized to one degree or another (the worker's economic contribution was less than they earned ... at least to some amount)
http://www.garlic.com/~lynn/2004b.html#42 The SOB that helped IT jobs move to India is dead!
http://www.garlic.com/~lynn/2004d.html#18 The SOB that helped IT jobs move to India is dead!
http://www.garlic.com/~lynn/2006f.html#44 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#20 The Pankian Metaphor

or recent posts where the gao estimated that illegal alien economic contribution was barely half of their cost to society (something in society being required to make up the short fall)
http://www.garlic.com/~lynn/2007i.html#18 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#70 illegal aliens
http://www.garlic.com/~lynn/2007i.html#79 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#81 illegal aliens

so pre technology society ... society value was largely based on available natural resources and/or ability to utilize those resources .... extensive use of natural resources could be used to compensate for differences between individual's total cost to society (standard of living, etc) and their contribution to society. in migration to technology society ... value significantly migrates to technology and away from natural resources. The primary contributions to technology society are the individuals with the skills to come up with new ideas and inventions.

A large part of the whole public school system justification has been based on making citizens more productive members of society (and requiring less society subsidy to maintain them). One strategy is attempting to minimize the subsidy that large portions of the population requires. Another strategy is maximize the excess resources available for subsidizing those members. In transition to technology society, the "excess resources" are going to be new ideas and inventions (subsidy requires shifting excess resources in one area to other areas ... w/o excess resources ... the ability to "subsidize" starts to disappear).

The numbers for the educational system seems to indicate that its ability to produce productive members of society (i.e. able to exist w/o subsidy) is declining while at the same time, the shift to technology society is raising the requirements on what is required to be productive (the bar is being raised on what is required to be functionally literate as opposed to functionally illiterate).

In any case, with technology society, there would appear to be a shift that society value becomes less based on the natural resources within its borders (and/or the ability to utilize such natural resources) and more based on the new ideas and inventions from the best and brightest in the society.

Outsourcing loosing steam?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Subject: Outsourcing loosing steam?
Date: Sun, 19 Aug 2007 10:21:04 -0400
Newsgroups: bit.listserv.ibm-main
On Aug 15, 11:11 am, da...@ibm-main.lst (daver++) wrote:
"Around 1:30 p.m., the CPB experienced problems accessing its database containing information on international travelers. Assuming this to be a wide-area network problem, CBP called Sprint, its carrier, to test the lines. After three fruitless hours of remote testing, Sprint finally sent technicians on-site. Another three hours passed before Sprint finally concluded that transmission lines were not the problem, meaning the problem was inside the CBP local network. After more hours of troubleshooting, the issue was finally resolved at 11:45 p.m. The real culprit: a failed router."
http://blogs.zdnet.com/projectfailures/?p=346

20,000 stranded because it took over ten hours to diagnose and replace a failed router. I used to be a mainframe guy that inherited the network side, so they cut me some slack. BUT- I can guarantee that there wasn't anywhere near enough slack for me to get off with taking that long to replace a router. I would have been tarred, feathered and run out of town. It seems like basic due diligence wasn't even followed. Yes, Sprint added to the problem, but Sprint never should have been called. Why call Sprint before determining that the problem isn't on _your_ end? It is all a bit silly, and it frightens me a bit that our airlines have this level of quality.


...e that inadequate processes in packet networks contribute significantly to diagnosing the problems. some of the older protocols were much more circuit oriented ... and could much more rely on telco circuit diagnostics to identify problems.

we experience this when we were building reliable network based infrastructures in the 80s ... and attempting to do some work on NSFNET infrastructure .... misc. collected old emails
http://www.garlic.com/~lynn/lhwemail.html#nsfnet

and to some extent met with quite a bit of corporate resistance ... somewhat highlighted in this old email:
http://www.garlic.com/~lynn/2006w.html#email870109
in this post
http://www.garlic.com/~lynn/2006w.html#21

note that while tcp/ip is the technology basis for the modern internet, nsfnet was the operational basis (interconnections of networks, i.e. internetworking), and cix was the business basis. in the above reference there is somebody in corporation proposing that sna could be proposed for basis for nsfnet ... the main issue was the ability to providing internetworking ... interconnection of large number of different networks.

we later investigated several of the issues in more detail when we were doing the ha/cmp product
http://www.garlic.com/~lynn/subtopic.html#hacmp

which required a detailed threat and vulnerability study for high availability environments.

we later got to use some of that experience when we were called in to consult with a small client/server company that wanted to do payments on their server
http://www.garlic.com/~lynn/subnetwork.html#gateway

they had this technology called SSL and the effort is now frequently referred to as electronic commerce. the initial simple obvious solution was to move the payment transaction message formats from their existing circuit-based environment to a packet-based enviornment. however, that totally ignored much of the availability, diagnostic, and recovery processews that were available in the circuit based environment. We eventually developed a set of compensating processes and procedures attempting to make the availability of the packet-based environment somewhat compareable to the existing circuit-based environment.

for a little topic drift ... recent comment on availability, diagnosing and recovery in one of the ATC modernization efforts
http://www.garlic.com/~lynn/2007o.html#18

misc past posts on estimated of 4-10 times the effort to take a well written application and turn it into an industrial strength service (in the case of the payment gateway, it was closer to ten times, including inventing various diagnostic and recovery process to compensate for moving payment gateway to a packet-based environment)
http://www.garlic.com/~lynn/2001f.html#75 Test and Set (TS) vs Compare and Swap (CS)
http://www.garlic.com/~lynn/2001n.html#91 Buffer overflow
http://www.garlic.com/~lynn/2001n.html#93 Buffer overflow
http://www.garlic.com/~lynn/2003g.html#62 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003j.html#15 A Dark Day
http://www.garlic.com/~lynn/2003p.html#37 The BASIC Variations
http://www.garlic.com/~lynn/2004b.html#8 Mars Rover Not Responding
http://www.garlic.com/~lynn/2004b.html#48 Automating secure transactions
http://www.garlic.com/~lynn/2004k.html#20 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2004l.html#49 "Perfect" or "Provable" security both crypto and non-crypto?
http://www.garlic.com/~lynn/2004m.html#51 stop worrying about it offshoring - it's doing fine
http://www.garlic.com/~lynn/2004p.html#23 Systems software versus applications software definitions
http://www.garlic.com/~lynn/2004p.html#63 Systems software versus applications software definitions
http://www.garlic.com/~lynn/2004p.html#64 Systems software versus applications software definitions
http://www.garlic.com/~lynn/2005b.html#40 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005i.html#42 Development as Configuration
http://www.garlic.com/~lynn/2005n.html#26 Data communications over telegraph circuits
http://www.garlic.com/~lynn/2006n.html#20 The System/360 Model 20 Wasn't As Bad As All That
http://www.garlic.com/~lynn/2007f.html#37 Is computer history taught now?
http://www.garlic.com/~lynn/2007g.html#51 IBM to the PCM market(the sky is falling!!!the sky is falling!!)
http://www.garlic.com/~lynn/2007h.html#78 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007n.html#10 The top 10 dead (or dying) computer skills
http://www.garlic.com/~lynn/2007n.html#76 PSI MIPS
http://www.garlic.com/~lynn/2007n.html#77 PSI MIPS

LAX IT failure: leaps of faith don't work

From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: Sun, 19 Aug 2007 17:58:09 -0700
Subject: LAX IT failure: leaps of faith don't work
a little x-over post from bit.listserv.ibm-main
http://www.garlic.com/~lynn/2007o.html#23

LAX IT failure: leaps of faith don't work
http://blogs.zdnet.com/projectfailures/?p=346

... after more hrs of troubleshooting, the issue was finally resolved at 11:45 pm The real culprit: a failed router ...

... snip ...

LAX IT failure: leaps of faith don't work

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Newsgroups: alt.folklore.computers, bit.listserv.ibm-main
Date: Tue, 21 Aug 2007 17:45:28 -0700
Subject: Re: LAX IT failure: leaps of faith don't work
On Aug 20, 2:46 am, "winston19842...@yahoo.com" wrote:
We had the same thing happen to us with a NIC card on an Alpha system. Just started streaming packets, basically flooded the network.

Taking down the entire CMIS billing system, which handled Verizon's billing and wireless calling network, affecting switches, etc. Maybe even POS (can't remember, even though that was my system). Well "taking down" might be an overstatement. Sure as hell slowed it down...

It didn't take too long to isolate the issue, maybe an hour or two. But that is a LONG time in the world of cellular communications...


re:
http://www.garlic.com/~lynn/2007o.html#23
http://www.garlic.com/~lynn/2007o.html#24

there was once a central office problem with large scale 1-800 POS terminal calls that resulted in service interruption for 18 mins. Afterwards this was escalated to top executive levels between the two organizations.

in early tests of the payment gateway
http://www.garlic.com/~lynn/subnetwork.html#gateway

for what is now frequently referred to as electronic commece ... there was call into the call center. after extensive 3hr investigation ... the trouble ticket was closed as NTF (no trouble found) ... not necessarily that there wasn't trouble ... but it couldn't be diagnosed. this is environment where the call center is typically doing 1st level problem diagnosis within five minutes for the (primarily) circuit-based infrastructure.

an issue in moving the (payment) transaction message formats from a circuit-based environment to a (internet) packet-based environment ... there wasn't any support for similar industrial strength data processing capability. An outcome was that we had to put together a whole lot of compensating procedures (in an attempt to approximate the circuit-based industrial strength) for a packet-based environment (as well as adding much better diagnostic information as part of the infrastructure ... objective was that the call center would be able to do 1st level trouble diagnostic in approx. 5mins).

misc. past posts mentioning "trouble ticket" issues with early electronic commerce activity
http://www.garlic.com/~lynn/aadsm5.htm#asrn3 Assurance, e-commerce, and some x9.59 ... fyi
http://www.garlic.com/~lynn/aadsm16.htm#20 Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before
http://www.garlic.com/~lynn/99.html#16 Old Computers
http://www.garlic.com/~lynn/2001h.html#43 Credit Card # encryption
http://www.garlic.com/~lynn/2002.html#28 Buffer overflow
http://www.garlic.com/~lynn/2003b.html#53 Microsoft worm affecting Automatic Teller Machines
http://www.garlic.com/~lynn/2003g.html#62 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003j.html#15 A Dark Day
http://www.garlic.com/~lynn/2003p.html#37 The BASIC Variations
http://www.garlic.com/~lynn/2004b.html#8 Mars Rover Not Responding
http://www.garlic.com/~lynn/2004q.html#51 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005n.html#30 Data communications over telegraph circuits
http://www.garlic.com/~lynn/2006i.html#29 Which entry of the routing table was selected?

Tom's Hdw review of SSDs

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Tom's Hdw review of SSDs
Newsgroups: alt.folklore.computers
Date: Thu, 23 Aug 2007 16:06:17 -0400
Tim Shoppa <shoppa@trailing-edge.com> writes:
There was a predecessor device for Massbus that must've dated from the late 1970's or so, and which used the 11/70 or 11/750 memory boxes (with a massbus-emulating hard drive interface bolted on) to achieve solid state disks. Of course, they were solid state disks that sucked many kilowatts to store a few megabytes :-).

there was a vendor device available internally circa 1980 ... referred to as "1655" that emulated 2305 fixed-head (paging) disks.

the "story" was that they were built from the vendor's memory chips that had failed standard memory acceptance tests ... however with the latency and other processes that were available for emulated (paging) disk operation ... it was possible to "mask" the failures ... and still get useful function from the chips (as opposed to just consigning them to the trash).

part of the issue for electronic device emulation is that there has to be some sort of trade-off for just not having directly addressable electronic memory. in the 1655 case, it was standard memory chips that failed the normal memory acceptance tests. in some other cases, there were systems issues with being able to address additional electronic storage (i.e. number of address bits supported by the system). another case with 3090 expanded storage ... the physical packaging resulted in higher latency to the additional memory. however, in the 3090 expanded storage case, the additional memory was accessed by special (synchronous) processor instructions that would move pages between standard memory and expanded memory (as opposed to asynchronous i/o operations).

misc. past posts mentioning 1655, electronic paging devices.
http://www.garlic.com/~lynn/2001c.html#17 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001l.html#53 mainframe question
http://www.garlic.com/~lynn/2002.html#31 index searching
http://www.garlic.com/~lynn/2002i.html#17 AS/400 and MVS - clarification please
http://www.garlic.com/~lynn/2002l.html#40 Do any architectures use instruction count instead of timer
http://www.garlic.com/~lynn/2003b.html#15 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#17 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003c.html#55 HASP assembly: What the heck is an MVT ABEND 422?
http://www.garlic.com/~lynn/2003m.html#39 S/360 undocumented instructions?
http://www.garlic.com/~lynn/2004d.html#73 DASD Architecture of the future
http://www.garlic.com/~lynn/2004e.html#3 Expanded Storage
http://www.garlic.com/~lynn/2005e.html#5 He Who Thought He Knew Something About DASD
http://www.garlic.com/~lynn/2005r.html#51 winscape?
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
http://www.garlic.com/~lynn/2006c.html#1 Multiple address spaces
http://www.garlic.com/~lynn/2006e.html#46 using 3390 mod-9s
http://www.garlic.com/~lynn/2006k.html#57 virtual memory
http://www.garlic.com/~lynn/2006r.html#36 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006s.html#30 Why magnetic drums was/are worse than disks ?
http://www.garlic.com/~lynn/2007e.html#2 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007e.html#59 FBA rant

misc. past posts mentioning 3090 expanded stor
http://www.garlic.com/~lynn/2000c.html#61 TF-1
http://www.garlic.com/~lynn/2001k.html#73 Expanded Storage?
http://www.garlic.com/~lynn/2001k.html#74 Expanded Storage?
http://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?
http://www.garlic.com/~lynn/2004e.html#2 Expanded Storage
http://www.garlic.com/~lynn/2004e.html#3 Expanded Storage
http://www.garlic.com/~lynn/2004e.html#4 Expanded Storage
http://www.garlic.com/~lynn/2005i.html#51 Regarding interrupt sharing architectures!
http://www.garlic.com/~lynn/2006.html#13 VM maclib reference
http://www.garlic.com/~lynn/2006b.html#14 Expanded Storage
http://www.garlic.com/~lynn/2006b.html#15 Expanded Storage
http://www.garlic.com/~lynn/2006b.html#16 Expanded Storage
http://www.garlic.com/~lynn/2006b.html#17 Expanded Storage
http://www.garlic.com/~lynn/2006b.html#18 Expanded Storage
http://www.garlic.com/~lynn/2006b.html#34 Multiple address spaces
http://www.garlic.com/~lynn/2006c.html#1 Multiple address spaces
http://www.garlic.com/~lynn/2006r.html#35 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006r.html#42 REAL memory column in SDSF

-- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

EZPass: Yes, Big Brother IS Watching You!

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: EZPass: Yes, Big Brother IS Watching You!
Newsgroups: alt.folklore.computers,misc.transport.road
Date: Thu, 23 Aug 2007 20:40:52 -0400
"k_flynn@lycos.com" <k_flynn@lycos.com> writes:
You know, the predominant method of identity theft is still the good ol' fashioned purse snatch or mailbox pilfering. That has nothing to do with computerization of the data that you rail against. Your wallet gets picked on the bus or in the mall, and within an hour someone's used your Visa to buy a big screen teevee. We used to call that plain ol' theft, but now it's been upgraded to "identity theft" to add to the "killer bees" fear mongering.

FTC and others have been attempting to differentiate "id theft" between impersonation involving transactions against existing accounts (stealing a credit/debit card and then impersonating the owner to perform fraudulent transactions) and impersonation involving opening new accounts.

both involve impersonation. stealing a payment card is old fashion theft ... using the stolen payment card for a fraudulent transaction requires impersonating the owner of that card. claiming to be somebody else in order to open new accounts is also a form of impersonation.

both forms of impersonation have been labeled as "identity theft" ... however, several organizations have been attempting to further differentiate the different types (break down identity theft into different kinds).

i believe that in the debit/credit card variety of account fraud now breaks down into something like 1/3rd lost/stolen card (fraudulent use of a valid card). other kinds of debit/credit fraud involve things like skimming and havesting (i.e. acquiring information from existing transactions) ... misc. posts discussing skimming and harvesting
http://www.garlic.com/~lynn/subintegrity.html#harvest

skimming/harvesting frequently involves some form of electronic vulnerability (individual transactions at point of origin, or data breaches involving logs of previous transactions). skimming/harvesting can involved "card not present" fraud ... i.e. the crook does some sort of electronic commerce or MOTO (mail order/telephone order) transaction. skimming/harvesting exploits have also involved the production of counterfeit cards from the compromised information.

just now, quicking search engine for statistics turns up this reference
http://kalysis.com/content/modules.php?op=modload&name=EasyContent&file=index&menu=410&page_id=109


in 2001, (UK) card fraud losses were
counterfeit cards:   160.3
card-not-present:     95.7
lost/stolen card:    114.0
intercepted in post:  26.7

total:               411.4

taking "intercepted in post" and lost/stolen as 141 total ... that is approx. 1/3rd of total card fraud losses ... which is the number i've heard frequently quoted in the past.

part of the issue is that in the lost/stolen card case, the owner frequently notices the missing card and reports it, resulting in the use being deactivated ... helping limit the total amount of fraud.

data breaches, skimming, harvesting tends to be much more profitable for crooks. the number of accounts affected per effort by the crooks is significantly larger (compared to the effort to physically acquiring valid cards). furthermore, the card owner may not be aware that their account has been compromised until they receive the next statement; this allows the crook much more fraudulent activity against each account. The net is much higher fraud ROI (total amount of fraud divided by total amount of effort). physical risk to the crook also tends to be much lower in the various forms involving electronic compromises.

lots of posts mentioning vulnerabilities, threats, risks, compromises, and/or fraud
http://www.garlic.com/~lynn/subintegrity.html#fraud

various past posts mentioning efforts to better differentiate types of identity theft ... including breaking out account fraud as a separate category
http://www.garlic.com/~lynn/aadsm19.htm#45 payment system fraud, etc
http://www.garlic.com/~lynn/aadsm20.htm#17 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#41 Another entry in the internet security hall of shame
http://www.garlic.com/~lynn/aadsm21.htm#35 [Clips] Banks Seek Better Online-Security Tools
http://www.garlic.com/~lynn/aadsm24.htm#38 Interesting bit of a quote
http://www.garlic.com/~lynn/aadsm24.htm#48 more on FBI plans new Net-tapping push
http://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#20 Identity v. anonymity -- that is not the question
http://www.garlic.com/~lynn/aadsm25.htm#21 Identity v. anonymity -- that is not the question
http://www.garlic.com/~lynn/2003m.html#51 public key vs passwd authentication?
http://www.garlic.com/~lynn/2004b.html#50 The SOB that helped IT jobs move to India is dead!
http://www.garlic.com/~lynn/2005j.html#52 Banks
http://www.garlic.com/~lynn/2005j.html#53 Banks
http://www.garlic.com/~lynn/2005l.html#35 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005m.html#42 public key authentication
http://www.garlic.com/~lynn/2005p.html#24 Hi-tech no panacea for ID theft woes
http://www.garlic.com/~lynn/2005p.html#25 Hi-tech no panacea for ID theft woes
http://www.garlic.com/~lynn/2005u.html#3 PGP Lame question
http://www.garlic.com/~lynn/2005v.html#3 ABN Tape - Found
http://www.garlic.com/~lynn/2006c.html#35 X.509 and ssh
http://www.garlic.com/~lynn/2006d.html#25 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006d.html#26 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006e.html#26 Debit Cards HACKED now
http://www.garlic.com/~lynn/2006e.html#44 Does the Data Protection Act of 2005 Make Sense
http://www.garlic.com/~lynn/2006h.html#15 Security
http://www.garlic.com/~lynn/2006k.html#4 Passwords for bank sites - change or not?
http://www.garlic.com/~lynn/2006n.html#40 Identity Management Best Practices
http://www.garlic.com/~lynn/2006o.html#35 the personal data theft pandemic continues
http://www.garlic.com/~lynn/2006o.html#37 the personal data theft pandemic continues
http://www.garlic.com/~lynn/2006p.html#8 SSL, Apache 2 and RSA key sizes
http://www.garlic.com/~lynn/2006x.html#22 'Innovation' and other crimes
http://www.garlic.com/~lynn/2007b.html#60 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007b.html#61 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007b.html#62 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#10 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#22 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007e.html#29 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007e.html#58 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007e.html#61 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007l.html#35 My Dream PC -- Chip-Based

-- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

EZPass: Yes, Big Brother IS Watching You!

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: EZPass: Yes, Big Brother IS Watching You!
Newsgroups: alt.folklore.computers,misc.transport.road
Date: Thu, 23 Aug 2007 22:07:47 -0400
"k_flynn@lycos.com" <k_flynn@lycos.com> writes:
And to call TJ Maxx's retention of its sales records as a trivial purpose is naive.

misc. past posts in this thread:
http://www.garlic.com/~lynn/2007o.html#13 EZPass: Yes, Big Brother IS Watching You!
http://www.garlic.com/~lynn/2007o.html#27 EZPass: Yes, Big Brother IS Watching You!

note that payment card transaction information for standard business processes can be needed for six months or more after the actual transaction. this requirement by numerous business processes (related to payment card transactions) to have access to the original transaction information ... long after the actual transaction has been performed ... has contributed to lax purging of records ... for example on the date when merchant might no longer be involved in a disputed transaction (i.e. the consumer may have period in which to dispute the transaction ... usually for some period after it appears on a statement ... then there can be some additional period before when the consumer's financial institution actually communicates the dispute to the merchant).

this was one of the issues in the x9a10 financial standards working group ... which in the mid-90s had been given the requirement to preserve the integrity of the financial infrastructure for all retail paymnets ... resulting in the x9.59 standard
http://www.garlic.com/~lynn/x959.html#x959

as part of the standards work, the x9a10 financial standards working group did a study of infrastructure vulnerabilities. one of the things identified was the ease in which it is possible to use information from previous transactions for future fraudulent transactions (and the enormous numbers of places that information is required) ... which implies that the transaction information is kept strictly confidential and never divulged (which would effectively preclude even being able to do such transactions at point-of-sale). The diametrically opposing requirements placed on executed transaction information led to the observation that even if the planet was buried under miles of (information hiding) encryption, it still would not be possible to eliminate such information leakage.

this led (in the x9.59 standard) to attempting to elimiante the fraudulent usefulness of information from executed transactions ... i.e. x9.59 doesn't attempt to hide any of the transaction information ... it attempts to change the paradigm so that such transaction information is no longer useful to crooks for fraudulent transactions (account fraud). some of this is discussed in the series of posts about the "naked transaction" metaphor
http://www.garlic.com/~lynn/subintegrity.html#payment

now we had been called in to consulte with a small client/server startup that wanted to do payment transactions on their server
http://www.garlic.com/~lynn/subnetwork.html#gateway

which is now frequently referred to as electronic commerce. they had this technology that they wanted to use for hiding the transaction information while it was being transmitted over the internet ... misc. posts discussing some of the SSL issues
http://www.garlic.com/~lynn/subpubkey.html#sslcert

this use of SSL technology would continue the paradigm that transaction information had to be kept hidden or bad things would happen. when we got involved in x9a10 and the x9.59 standard ... the x9.59 standard eliminated needing to hide the transaction information as part of preserving the integrity of the financial infrastructure (whether it was being transmitted over the internet or the information was being stored in transaction logs as part of normal business processes).

misc. past posts making the observation of burying the planet under miles of information hiding encryption:
http://www.garlic.com/~lynn/aadsm25.htm#24 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm26.htm#24 News.com: IBM donates new privacy tool to open-source Higgins
http://www.garlic.com/~lynn/2005v.html#2 ABN Tape - Found
http://www.garlic.com/~lynn/2006e.html#44 Does the Data Protection Act of 2005 Make Sense
http://www.garlic.com/~lynn/2006k.html#5 Value of an old IBM PS/2 CL57 SX Laptop
http://www.garlic.com/~lynn/2006k.html#18 Value of an old IBM PS/2 CL57 SX Laptop
http://www.garlic.com/~lynn/2006y.html#8 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007b.html#60 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007i.html#65 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007o.html#5 The Unexpected Fact about the First Computer Programmer

-- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

EZPass: Yes, Big Brother IS Watching You!

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: EZPass: Yes, Big Brother IS Watching You!
Newsgroups: alt.folklore.computers,misc.transport.road
Date: Fri, 24 Aug 2007 09:42:52 -0400
Anne & Lynn Wheeler <lynn@garlic.com> writes:
i believe that in the debit/credit card variety of account fraud now breaks down into something like 1/3rd lost/stolen card (fraudulent use of a valid card). other kinds of debit/credit fraud involve things like skimming and havvesting (i.e. acquiring information from existing transactions) ... misc. posts discussing skimming and harvesting
http://www.garlic.com/~lynn/subintegrity.html#harvest


re:
http://www.garlic.com/~lynn/2007o.html#27 EZPass: Yes, Big Brother IS Watching You!

one of the issues with pin-debit is that it uses two-factor authentication ... from 3-factor authentication
http://www.garlic.com/~lynn/subintegrity.html#3factor

something you havesomething you knowsomething you are

in the case of pin-debit, it is a combination of the card (something you have) and the pin (something you know). there is frequently an assumption related to multi-factor authentication that the different factors have different kinds of vulnerabilities ... and therefor are more secure ... aka somebody just finding/stealing your card won't also know your pin.

however, in the skimming scenarios ... the attacker can capture both the card information and the pin information in a common attack. the card information is then used to create a counterfeit card and the pin information is used (in combination with the counterfeit card) to perform a fraudulent transaction (aka it represents a common vulnerability ... negating the assumption about multi-factor authentication being more secure because the different factors have independent vulnerabilities ... skimming represents a common vulnerability to both beiing able to create a counterfeit card and obtaining the pin).

recent skimming reference from today:

PINs Skimmed at Canadian Theater Kingston This Week
http://www.epaynews.com/index.cgi?survey=&ref=browse&f=view&id=11879531168370229186&block=

the (newer) signature debit cards ... typically can operate with or w/o a pin (the signature isn't actually verified as part of the transaction, so it can't really be considered multi-factor authentication). as a result, debit cards that can be used w/o a pin ... tend to have much higher fraud. misc. past posts referencing statistics that signature-debit has 15-times more fraud than pin-debit.
http://www.garlic.com/~lynn/aadsm22.htm#22 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm27.htm#40 a fraud is a sale, Re: The bank fraud blame game
http://www.garlic.com/~lynn/2007i.html#59 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007j.html#15 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007j.html#60 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007k.html#12 IBM Unionization

-- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

EZPass: Yes, Big Brother IS Watching You!

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: EZPass: Yes, Big Brother IS Watching You!
Newsgroups: alt.folklore.computers,misc.transport.road
Date: Fri, 24 Aug 2007 09:58:59 -0400
"k_flynn@lycos.com" <k_flynn@lycos.com> writes:
You know, the predominant method of identity theft is still the good ol' fashioned purse snatch or mailbox pilfering. That has nothing to do with computerization of the data that you rail against. Your wallet gets picked on the bus or in the mall, and within an hour someone's used your Visa to buy a big screen teevee. We used to call that plain ol' theft, but now it's been upgraded to "identity theft" to add to the "killer bees" fear mongering.

re:
http://www.garlic.com/~lynn/2007o.html#27 EZPass: Yes, Big Brother IS Watching You!
http://www.garlic.com/~lynn/2007o.html#29 EZPass: Yes, Big Brother IS Watching You!

earlier this spring, over a period of a couple weeks, there were (different) articles citing statistics that identity fraud was declining and at the same time exploding.

recent references mentioning articles essentially having identity fraud simultaneously declining and exploding
http://www.garlic.com/~lynn/aadsm27.htm#45 Threatwatch: how much to MITM, how quickly, how much lost
http://www.garlic.com/~lynn/2007i.html#19 John W. Backus, 82, Fortran developer, dies

earlier posts referencing the articles
http://www.garlic.com/~lynn/aadsm27.htm#43 a fraud is a sale, Re: The bank fraud blame game
http://www.garlic.com/~lynn/2007e.html#58 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007e.html#62 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007f.html#58 Securing financial transactions a high priority for 2007

-- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

EZPass: Yes, Big Brother IS Watching You!

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: EZPass: Yes, Big Brother IS Watching You!
Newsgroups: alt.folklore.computers,misc.transport.road
Date: Fri, 24 Aug 2007 13:53:31 -0400
Walter Bushell <proto@oanix.com> writes:
But they go to college to learn what in previous years they would have learned in High School. Too boot, they also have no more advantage from graduating from college than the did earlier from graduating from High School. Now you need a master's degree to do what a college education did for you 40 years ago.

somewhat separate issues ... declines in the public school system have resulted in college having to make up for deficiencies. for instance;

large mid-western land grant college having to "dumb-down" entering freshman text books three times over a period of 20 yrs (general level of public school is declining in the absolute sense ... independent of whether society is requiring members to have more education)

and

when foreign auto makers started putting plants in the US, they found that they having to require 2yr community college education (to get same level that they were accustomed from high-school eductation)

and

some reference to studies ranking school systems against other countries:
http://www.garlic.com/~lynn/2007j.html#58 IBM Unionization

however,

continued transition to technology society is also raising the level of education needed to be functionally literate

previous posts referencing dumbing down entering freshman text books:
http://www.garlic.com/~lynn/2002k.html#45 How will current AI/robot stories play when AIs are real?
http://www.garlic.com/~lynn/2003i.html#28 Offshore IT
http://www.garlic.com/~lynn/2003i.html#45 Offshore IT
http://www.garlic.com/~lynn/2005e.html#48 Mozilla v Firefox
http://www.garlic.com/~lynn/2006l.html#63 DEC's Hudson fab
http://www.garlic.com/~lynn/2006p.html#23 SAT Reading and Math Scores Show Decline
http://www.garlic.com/~lynn/2006t.html#21 Are there more stupid people in IT than there used to be?
http://www.garlic.com/~lynn/2007j.html#45 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#51 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#85 IBM Unionization

previous posts referencing foreign auto makers starting plants in the us:
http://www.garlic.com/~lynn/2006l.html#61 DEC's Hudson fab
http://www.garlic.com/~lynn/2006l.html#63 DEC's Hudson fab
http://www.garlic.com/~lynn/2006p.html#33 SAT Reading and Math Scores Show Decline
http://www.garlic.com/~lynn/2007j.html#31 IBM Unionization

past posts mentioning functionally literate/illiterate:
http://www.garlic.com/~lynn/2002k.html#45 How will current AI/robot stories play when AIs are real?
http://www.garlic.com/~lynn/2003i.html#28 Offshore IT
http://www.garlic.com/~lynn/2003i.html#45 Offshore IT
http://www.garlic.com/~lynn/2003i.html#55 Offshore IT
http://www.garlic.com/~lynn/2003p.html#33 [IBM-MAIN] NY Times editorial on white collar jobs going
http://www.garlic.com/~lynn/2004b.html#42 The SOB that helped IT jobs move to India is dead!
http://www.garlic.com/~lynn/2004d.html#18 The SOB that helped IT jobs move to India is dead!
http://www.garlic.com/~lynn/2004h.html#18 Low Bar for High School Students Threatens Tech Sector
http://www.garlic.com/~lynn/2005e.html#48 Mozilla v Firefox
http://www.garlic.com/~lynn/2005g.html#43 Academic priorities
http://www.garlic.com/~lynn/2006g.html#20 The Pankian Metaphor
http://www.garlic.com/~lynn/2006l.html#63 DEC's Hudson fab
http://www.garlic.com/~lynn/2007g.html#7 U.S. Cedes Top Spot in Global IT Competitiveness
http://www.garlic.com/~lynn/2007i.html#24 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#79 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007j.html#31 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#51 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#80 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#82 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#85 IBM Unionization
http://www.garlic.com/~lynn/2007k.html#10 IBM Unionization
http://www.garlic.com/~lynn/2007k.html#30 IBM Unionization
http://www.garlic.com/~lynn/2007k.html#34 IBM Unionization
http://www.garlic.com/~lynn/2007k.html#42 IBM Unionization
http://www.garlic.com/~lynn/2007l.html#5 IBM Unionization
http://www.garlic.com/~lynn/2007n.html#68 Poll: oldest computer thing you still use
http://www.garlic.com/~lynn/2007o.html#21 U.S. Cedes Top Spot in Global IT Competitiveness
http://www.garlic.com/~lynn/2007o.html#22 U.S. Cedes Top Spot in Global IT Competitiveness

-- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

reading erased bits

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: reading erased bits
Newsgroups: alt.folklore.computers
Date: Fri, 24 Aug 2007 14:39:46 -0400
Frank McCoy <mccoyf@millcomm.com> writes:
In modern computers with gigabytes of RAM, you don't really need a swap-file any more. In fact, it's really unwanted; as it slows the system down tremendously. Still, some programs and often Windows itself *insist* on it being there, even if never ever used.

recent comment about another aspect of electronic memory technology
http://www.garlic.com/~lynn/2007o.html#26 Tom's Hdw review of SSDs

page/swap files ... still have some decent uses ... especially with trade-off on long running programs that only wake-up infrequently. the memory can be better used by actively running programs.

the trade-off is that a lot of page/swap infrastructures have lagged disk useage technologies. by the mid-70s, processor thruput was increasing faster than disk thruput was increasing. to compensate, larger and larger memories were being to cache information to compensate for the relative system disk thruput decline ... as well as disk i/o strategies that atttempted to move more data in one transfer ... aka processor thruput was increasing faster than disk transfer thruput which were increasing faster than disk arm access thruput, so transfering more data per disk arm access would help compensate for the relatively system slower thruput of disk arm access thruput.

the problem was that page sizes (around 4k bytes) didn't change much and page i/o tended to be done in page sizes. in the early 80s, "big page" technology was developed in both (mainframe) mvs and vm370 .... forcing page i/o transfers to collections of pages that filled a whole disk track (in the case of the 3380 disks of the period, ten 4k pages).

in the environment where page i/o transfer sizes didn't keep pace with other technology attempting to optimize disk thruput ... doing a few large block transfers for initial program loading followed by the overhead of program initialization ... could be much more efficient than doing a large number of much smaller page i/o transfers (to "reload" an inactive, previously loaded program).

misc. past posts mentioning "big page" technology attempting to compensate for decline in relative system disk thruput:
http://www.garlic.com/~lynn/2001k.html#60 Defrag in linux? - Newbie question
http://www.garlic.com/~lynn/2002b.html#20 index searching
http://www.garlic.com/~lynn/2002c.html#29 Page size (was: VAX, M68K complex instructions)
http://www.garlic.com/~lynn/2002c.html#48 Swapper was Re: History of Login Names
http://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?
http://www.garlic.com/~lynn/2002e.html#11 What are some impressive page rates?
http://www.garlic.com/~lynn/2002f.html#20 Blade architectures
http://www.garlic.com/~lynn/2002l.html#36 Do any architectures use instruction count instead of timer
http://www.garlic.com/~lynn/2002m.html#4 Handling variable page sizes?
http://www.garlic.com/~lynn/2003b.html#69 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003d.html#21 PDP10 and RISC
http://www.garlic.com/~lynn/2003f.html#5 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#9 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#16 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#48 Alpha performance, why?
http://www.garlic.com/~lynn/2003g.html#12 Page Table - per OS/Process
http://www.garlic.com/~lynn/2003o.html#61 1teraflops cell processor possible?
http://www.garlic.com/~lynn/2003o.html#62 1teraflops cell processor possible?
http://www.garlic.com/~lynn/2004.html#13 Holee shit! 30 years ago!
http://www.garlic.com/~lynn/2004e.html#16 Paging query - progress
http://www.garlic.com/~lynn/2004n.html#22 Shipwrecks
http://www.garlic.com/~lynn/2004p.html#39 100% CPU is not always bad
http://www.garlic.com/~lynn/2005h.html#15 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005j.html#51 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2005l.html#41 25% Pageds utilization on 3390-09?
http://www.garlic.com/~lynn/2005n.html#18 Code density and performance?
http://www.garlic.com/~lynn/2005n.html#19 Code density and performance?
http://www.garlic.com/~lynn/2005n.html#21 Code density and performance?
http://www.garlic.com/~lynn/2005n.html#22 Code density and performance?
http://www.garlic.com/~lynn/2006j.html#2 virtual memory
http://www.garlic.com/~lynn/2006j.html#3 virtual memory
http://www.garlic.com/~lynn/2006j.html#4 virtual memory
http://www.garlic.com/~lynn/2006j.html#11 The Pankian Metaphor
http://www.garlic.com/~lynn/2006l.html#13 virtual memory
http://www.garlic.com/~lynn/2006r.html#35 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006r.html#37 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006r.html#39 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006t.html#18 Why magnetic drums was/are worse than disks ?
http://www.garlic.com/~lynn/2006v.html#43 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006y.html#9 The Future of CPUs: What's After Multi-Core?

-- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

EZPass: Yes, Big Brother IS Watching You!

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: EZPass: Yes, Big Brother IS Watching You!
Newsgroups: alt.folklore.computers,misc.transport.road
Date: Sat, 25 Aug 2007 11:35:41 -0400
"pigsty1953@yahoo.com" <rshersh@gmail.com> writes:
Someone mentioned the foreign automakers disdain of American education. Look where they are located, in the south, places like SC, AL, KY, and rural IN. Places where education has always been a low priority, low budget entity. They should have known that before they went in, but they went for cheap, and that is what you get.

re:
http://www.garlic.com/~lynn/2007o.html#31 EZPass: Yes, Big Brother IS Watching You!

in above post i mentioned that the foreign automakers finding that they required 2yr junior college education in order to get high-school level educated workers.

however, it also noted that large midwestern land-grant university (state up near canadian border) found that they had to dumb down textbooks for entering freshman, three times in the period between the late 60s and the early 90s (i.e. the absolute overall education level of entering freshman was declining significantly in that period).

it also mentioned the statistics on overall US literacy rate ranks near the bottom of wealthy industrial countries.

-- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

EZPass: Yes, Big Brother IS Watching You!

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: EZPass: Yes, Big Brother IS Watching You!
Newsgroups: misc.transport.road,alt.folklore.computers
Date: Mon, 27 Aug 2007 11:30:47 -0400
jmfbahciv writes:
When you do OS development, you have to be able to anticipate all kinds of nefarious scenarios, events, and perverse usage.

I was told in this newsgroup (a.f.c.) that being able to deal with all possibilities, including the ones that can't be anticipated, was a form of paranoia.


... database development, operating system development, ... almost any sort of business critical dataprocessing

a couple recent posts mentioning business critical dataprocessing
http://www.garlic.com/~lynn/2007n.html#76 PSI MIPS
http://www.garlic.com/~lynn/2007n.html#77 PSI MIPS
http://www.garlic.com/~lynn/2007n.html#82 mainframe developer = permanent position - Dublin Ireland

-- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Is a RISC chip more expensive?

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is a RISC chip more expensive?
Newsgroups: comp.arch
Date: Mon, 27 Aug 2007 12:08:11 -0400
Quadibloc <jsavard@ecn.ab.ca> writes:
Let's suppose, as you suggest, that IBM, through adroit marketing, got a lock on the server market with the PowerPC processor. So instead of Sun developing Sparc, and Apollo/HP going to PA-RISC, they use PowerPC processors as well.

so 801 is from the 70s ... various 801 posts
http://www.garlic.com/~lynn/subtopic.html#801

one of the "big" efforts was project to replace a large variety of different internal microprocessors with common 801 base (drastically cutting hardware and software development and maintenance). after some amount of that got canceled ... you saw some number of people that had worked on various 801 efforts showing up at other companies to work on risc projects.

one of the 801 projects was romp (joint between research and office products division) to be a opd displaywriter following (running closed system cp.r implemented in pl.8). at some point the displaywriter followon got canceled and the project looked around for something else to ship and settled on unix technical workstation market. the pl.8 programmers got assigned to implementing a virtual machine abstration layer for romp ... and the company that had done pc/ix port was hired to do a port to the virtual machine abstraction interface ... eventually announced as pc/rt and aix (v2).

power/rios was then started to be follow-on chipset (six chips) to the pc/rt targeted at the high-end unix technical workstation market. for power/rios the virtual machine abstration was eliminated and it was announced as rs/6000 and aix (v3).

we started a project, ha/cmp to use the hardware targeted at the unix business market segment
http://www.garlic.com/~lynn/subtopic.html#hacmp

some old email referring to ha/cmp scaleup activity (for business market) getting side-tracked
http://www.garlic.com/~lynn/lhwemail.html#medusa

when somerset was started, the executive we reported to (when we started ha/cmp), went over to head up it up. somerset was joint ibm, motorola, apple, etc effort to do a single chip risc implementation that was referred to as power/pc (to differentiate from the multi-chip rios/power for the high-end technical workstation market).

-- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

It's No Secret: VMware to Develop Secure Systems for NSA

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: It's No Secret: VMware to Develop Secure Systems for NSA
Newsgroups: alt.folklore.computers
Date: Wed, 29 Aug 2007 09:37:18 -0400
It's No Secret: VMware to Develop Secure Systems for NSA
http://www.eweek.com/article2/0,1895,2176741,00.asp

40yr old technology ... misc. recent ref
http://www.garlic.com/~lynn/2007b.html#21 history question
http://www.garlic.com/~lynn/2007d.html#52 CMS (PC Operating Systems)
http://www.garlic.com/~lynn/2007e.html#20 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007e.html#30 Health Care
http://www.garlic.com/~lynn/2007f.html#36 Silly beginner questions
http://www.garlic.com/~lynn/2007f.html#39 Silly beginner questions
http://www.garlic.com/~lynn/2007j.html#23 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007j.html#35 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007j.html#43 z/VM usability
http://www.garlic.com/~lynn/2007k.html#47 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007k.html#52 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007m.html#53 Is Parallel Programming Just Too Hard?
http://www.garlic.com/~lynn/2007m.html#64 Operating systems are old and busted
http://www.garlic.com/~lynn/2007m.html#66 Off Topic But Concept should be Known To All
http://www.garlic.com/~lynn/2007n.html#27 What if phone company had developed Internet?
http://www.garlic.com/~lynn/2007n.html#29 Programmable TLB management?
http://www.garlic.com/~lynn/2007n.html#30 How would a relational operating system look like?

and some other references:
http://www.garlic.com/~lynn/2007e.html#6 GCN at 25: VAX for the memory
http://www.garlic.com/~lynn/2007g.html#13 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007g.html#31 Wylbur and Paging
http://www.garlic.com/~lynn/2007i.html#20 Does anyone know of a documented case of VM being penetrated by hackers?
http://www.garlic.com/~lynn/2007k.html#48 John W. Backus, 82, Fortran developer, dies

-- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Each CPU usage

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Each CPU usage
Date: Wed, 29 Aug 2007 15:02:50 -0400
Newsgroups: bit.listserv.ibm-main
Steve_Thompson@ibm-main.lst (Thompson, Steve) writes:
Imagine, you have a 3081 at 100% and you upgraded to a 3084 (basically you added the other 3081) and you are still at 100%. Or you have a 3033 and you went to a 470/V8. [I'm not saying these were the systems, just using them as examples.]

3081 was two processor ... and 3084 was pair of 3081s (four-processors).

the basic 370/3033/308x multiprocessor cache coherency started out slowing the processor speed by 10% to allow for cross-cache chatter (i.e. raw two-processor thruput was 1.8 times raw single processor thruput). this is independent of any actual cache invalidates that were occuring (i.e. just providing for basic cross-cache communication). 3084 was even worse since each processor cache had to listen for x-cache chatter from three other processors (rather than just one other processor).

308x wasn't even going to have a single processor version ... however, eventually a single processor, 3083 did ship. This was primarily motivated by ACP/TPF which didn't have multiprocessor support at the time (base 3083 processor was almost 15percent faster than one of the 3081 processors since the multiprocessor x-cache chatter slowdown was eliminated)

in the 3081 time-frame ... both vm and mvs had kernel storage re-org to carefully align storage on cache-line boundaries (and multiples of cache lines). this was to eliminate a lot of cache-line "thrashing" where two different storage locations overlapped in the same cache-line (and different processors could be simultaneously operating on the two storage locations). This kernel storage re-org was claimed to improve system thruput by something over five percent.

the other example was a major restructuring of the vm multiprocessor support between r6 and sp1. the issue was that since acp/tpf didn't have multiprocessor support, there was a lot of acp/tpf running under vm370 on 3081s. for the dedicated acp/tpf, 3081 operations implied that they ran two copies of acp/tpf (in two different virtual machines) and/or that one of the processors sat idle most of the time.

for the later case, the multiprocessor restructuring attempted to get (some amount of) virtual machine kernel processing running on the "idle" processor (overlapped with acp/tpf execution on the other processor). This involved introducing a lot of signal processor instructions to wake the possibly idle processor to get busy on some execution and return to executing the (acp/tpf) virtual machine (specific scenario was overlapping siof instruction emulation and channel program translation with the acp/tpf virtual machine execution).

the standard virtual machine multiprocessor support was designed for efficiently handling lots of independent/separate operations. the sp1 reorganization (for acp/tpf overlapped execution) was generic for all possible execution environments ... and introduced quite a bit of overhead (in the acp/tpf scenario it was justified on the basis that it improved overall thruput ... since there was an otherwise idle processor).

a lot of existing customers moving from r6 multiprocessor support to sp1 multprocessor support found significant increase in multiprocessor overhead ... a combination of the significant increase in signal processor instructions, the corresponding interrupts and a lot of new spin-lock activities (just the "new" spin-locks measured as much as ten percent of each processor).

spin-locks were typically used to provide exclusive execution for lots of kernel code. global kernel spin-locks were typical of lot of 60s, 70s and even 80s operating systems (i.e. a single kernel lock that kernel would attempt to obtain at entry into kernel mode ... interrupt routines, etc ... and spin/loop until it obtained the lock).

at the science center,
http://www.garlic.com/~lynn/subtopic.html#545tech

charlie was working on fine-grain multiprocessing kernel locks (lots of short execution paths rather than the whole kernal) for cp67 when he invented the compare&swap instruction (CAS mnemonic chosen because they are charlie's initials ... compare&swap designation had to be invented to have something that matched CAS). the attempt to get CAS added to 370 architecture was initially rebuffed ... the favorite son operating system considered the test&set lock instruction (used for os/360 multiprocessor global kernel spin-locks) more than sufficient for 370 multiprocessing support. the challenge was to come up with a non-multiprocessor use for the compare&swap instruction ... in order to get it included in 370 architecture. lots of past posts mentioning multiprocessor and/or compare&swap instruction
http://www.garlic.com/~lynn/subtopic.html#smp

this is where the use for a lot of multithreaded application software (regardless of whether running on multiprocessor hardware) was invented .. as well as the programming notes that now appear in appendix of principles of operation ... i.e.

A.6 Multiprogramming and Multiprocessing Examples
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/A.6?SHELF=DZ9ZBK03&DT=20040504121320

up until vm/sp1 ... the primary kernel multiprocessor locking support was something i started out calling bounce lock ... rather than "spinning" on a lock, i had created a mechanism that queued a very lightweight execution request (for instance, significantly more lightweight than SRB) when certain reqeusted locks were in use by some other processor. i had originally developed the technique for a multiprocessor project (that didn't ship as a product) where a lot of the related code had been migrated to microcode. When the microcode could no longer process the operation (in parallel with other processors) ... it would queue an interrupt into the kernel to complete the processing. When this project was killed, i translated the convention to vanilla multiprocessor 370 machines ... some past posts mentioning the heavily microcoded multiprocessor effort
http://www.garlic.com/~lynn/submain.html#bounce

It's No Secret: VMware to Develop Secure Systems for NSA

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: It's No Secret: VMware to Develop Secure Systems for NSA
Newsgroups: alt.folklore.computers
Date: Wed, 29 Aug 2007 15:45:10 -0400
AZ Nomad <aznomad.2@PremoveOBthisOX.COM> writes:
What that history lesson to do with vmware secure systems?

re:
http://www.garlic.com/~lynn/2007o.html#36 It's No Secret: VMware to Develop Secure Systems for NSA

... following minor reference to 40yr old virtual machine secure systems (i.e. this wasn't the 1st time that it was done)
http://web.archive.org/web/20090117083033/http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml

also mentioned in some of the referenced posts
http://www.garlic.com/~lynn/2007e.html#6 GCN at 25: VAX for the memory
http://www.garlic.com/~lynn/2007g.html#13 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007g.html#31 Wylbur and Paging
http://www.garlic.com/~lynn/2007i.html#20 Does anyone know of a documented case of VM being penetrated by hackers?
http://www.garlic.com/~lynn/2007k.html#48 John W. Backus, 82, Fortran developer, dies

It's No Secret: VMware to Develop Secure Systems for NSA

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: It's No Secret: VMware to Develop Secure Systems for NSA
Newsgroups: alt.folklore.computers
Date: Wed, 29 Aug 2007 21:21:26 -0400
re:
http://www.garlic.com/~lynn/2007o.html#36 It's No Secret: VMware to Develop Secure Systems for NSA
http://www.garlic.com/~lynn/2007o.html#38 It's No Secret: VMware to Develop Secure Systems for NSA

more on latest genre of 40yr old

No Secret: NSA Taps VMware For Virtualization
http://www.internetnews.com/storage/article.php/3696996

from above:
Prescott B. Winter, former director of the NSA/CSS Commercial Solutions Center (NCSC) and now CTO at the NSA, said the agency "has a strong interest in leveraging innovative commercial technologies to provide a secure workstation environment for the government community".

... snip ...

revisiting 40yr old technology

-- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

EZPass: Yes, Big Brother IS Watching You!

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: EZPass: Yes, Big Brother IS Watching You!
Newsgroups: alt.folklore.computers
Date: Thu, 30 Aug 2007 07:47:16 -0400
Larry Elmore <ljelmore@verizon.spammenot.net> writes:
It was cancelled because it was too expensive. US actually funded a big chunk of the development, but wasn't inclined to pay for production of a direct competitor for its own products, and Israel couldn't afford it on its own. It wasn't clear whether the added capabilities were worth the higher costs. I was disappointed but not surprised that it was cancelled.

old thread wandering into tigershark vis-a-vis f16
http://www.garlic.com/~lynn/2007i.html#3 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#4 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#6 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#7 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#8 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#10 John W. Backus, 82, Fortran developer, dies

Boyd had been largely responsible for f16 (as alternative to f15). i suspected that he was also involved in f20 since it embodied several characteristics that Boyd advocated. misc. past posts mentioning Boyd
http://www.garlic.com/~lynn/subboyd.html#boyd
and misc. URLs from around the web mentioning Boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2

-- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Virtual Storage implementation

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Virtual Storage implementation
Date: Thu, 30 Aug 2007 17:05:03 -0400
Newsgroups: bit.listserv.ibm-main
RugenL@ibm-main.lst (Rugen, Len) writes:
Virtual storage isn't exclusive to MVS - z/OS. One on of the best presentations I recall was in a VM Performance and Tuning class.

Together with storage protection keys, page tables can be built to allow different "users" to have various parts of private, shared for read and shared for update storage. (At least update if you're friendly with the think king and he lets you in key 0).


360/67 was machine that came with virtual memory as standard ... it could be viewed somewhat as 360/65 with DAT box bolted on to the side ... although the 360/67 multiprocessor was significantly more sophisticated that 360/65 multiprocessor (for instance, all 360/67 processors in a multiprocessor complex could address all channels ... which wasn't true of 360/65 multiprocessors) ... some multiprocessor digression from a recent thread
http://www.garlic.com/~lynn/2007o.html#37 Each CPU usage

some of the people at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

were worried about some of the virtual memory issues ... some historical comment that atlas virtual memory never worked well ... misc. past posts mentioning atlas
http://www.garlic.com/~lynn/2000f.html#78 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2001h.html#10 VM: checking some myths.
http://www.garlic.com/~lynn/2001h.html#26 TECO Critique
http://www.garlic.com/~lynn/2003b.html#1 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003m.html#34 SR 15,15 was: IEFBR14 Problems
http://www.garlic.com/~lynn/2005o.html#4 Robert Creasy, RIP
http://www.garlic.com/~lynn/2006i.html#30 virtual memory
http://www.garlic.com/~lynn/2007e.html#1 Designing database tables for performance?
http://www.garlic.com/~lynn/2007g.html#36 Wylbur and Paging

also reference to cp67 and vm370 historical paper
http://www.leeandmelindavarian.com/Melinda/

anyway, as result of the concerns about virtual memory, cambridge modified a 360/40 with custom virtual memory hardware ... prior to 360/67 availability. cp/40 virtual machine system was built for the custom 360/40 ... which was remapped to cp/67 when 360/67 machines became available.

virtual memory hardware support was eventually going to be made available on 370s ... although only 24-bit virtual memory addressing ... 360/67 had support for both 24-bit virtual memory addressing as well as 32-bit virtual memory addressing.

originally 370 virtual memory was going to have a lot more features. the translation of the cp67 virtual machine system to vm370 virtual machine system was going to include use of some of these additional features. one specific feature that was going to be used was virtual memory shared segment .... allowing the same shared segment to appear in multiple different virtual address spaces ... and be read/only protected.

retrofitting 370 virtual memory hardware support to 370/165 ran into some schedule delays ... in order to make up those delays, lots of 370 virtual memory features were dropped ... and the other machines that had implemented the full 370 virtual memory support had to remove the additional features. in escalation meetings about the trade-off delaying 370 virtual memory availability by six more months (because of hardware implementation issues for 370/165) or shipping a subset six months earlier ... the favorite son operating system took the position that they didn't need any of the additional features.

this had a fairly big impact on vm370 implementation which including coming up with a emulation of shared segment protection using a kludge involving storage keys.

the initial translation of os/360 MVT to virtual memory environment (for os/vs2 svs) involved creating a single 16mbyte virtual address space and hacking a simple paging support into the side of MVT. Then CCWTRANS (from cp67) was integrated into the MVT kernel to provide for channel program translation (i.e. handle all the stuff of taking the application space channel program that had been created with virtual address ... creating a copy substituting real addresses, pinning the associated pages, and all the rest of the gorp).

misc. past posts mentioning the 370/165 virtual memory implementation schedule problems and impact on vm370 implementation
http://www.garlic.com/~lynn/2000.html#59 Multithreading underlies new development paradigm
http://www.garlic.com/~lynn/2003d.html#53 Reviving Multics
http://www.garlic.com/~lynn/2003f.html#14 Alpha performance, why?
http://www.garlic.com/~lynn/2004p.html#8 vm/370 smp support and shared segment protection hack
http://www.garlic.com/~lynn/2004p.html#9 vm/370 smp support and shared segment protection hack
http://www.garlic.com/~lynn/2004p.html#10 vm/370 smp support and shared segment protection hack
http://www.garlic.com/~lynn/2004p.html#14 vm/370 smp support and shared segment protection hack
http://www.garlic.com/~lynn/2005.html#3 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005.html#5 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005e.html#53 System/360; Hardwired vs. Microcoded
http://www.garlic.com/~lynn/2005f.html#45 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005f.html#46 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005h.html#10 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005j.html#39 A second look at memory access alignment
http://www.garlic.com/~lynn/2005j.html#54 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2005o.html#10 Virtual memory and memory protection
http://www.garlic.com/~lynn/2006.html#13 VM maclib reference
http://www.garlic.com/~lynn/2006b.html#39 another blast from the past
http://www.garlic.com/~lynn/2006i.html#9 Hadware Support for Protection Bits: what does it really mean?
http://www.garlic.com/~lynn/2006i.html#23 Virtual memory implementation in S/370
http://www.garlic.com/~lynn/2006i.html#43 virtual memory
http://www.garlic.com/~lynn/2006j.html#5 virtual memory
http://www.garlic.com/~lynn/2006j.html#41 virtual memory
http://www.garlic.com/~lynn/2006l.html#22 Virtual Virtualizers
http://www.garlic.com/~lynn/2006m.html#26 Mainframe Limericks
http://www.garlic.com/~lynn/2006m.html#54 DCSS
http://www.garlic.com/~lynn/2006s.html#61 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#16 Is the teaching of non-reentrant HLASM coding practices ever defensible?
http://www.garlic.com/~lynn/2006u.html#26 Assembler question
http://www.garlic.com/~lynn/2006u.html#60 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006w.html#7 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006w.html#11 long ago and far away, vm370 from early/mid 70s
http://www.garlic.com/~lynn/2006w.html#23 Multiple mappings
http://www.garlic.com/~lynn/2006y.html#26 moving on
http://www.garlic.com/~lynn/2007d.html#32 Running OS/390 on z9 BC
http://www.garlic.com/~lynn/2007f.html#14 more shared segment archeology
http://www.garlic.com/~lynn/2007f.html#16 more shared segment archeology
http://www.garlic.com/~lynn/2007g.html#14 ISPF not productive
http://www.garlic.com/~lynn/2007j.html#43 z/VM usability

misc. past posts mentioning hacking cp67's CCWTRANS into the side of MVT ... initial effort to migrate MVT to OS/VS2 SVS:
http://www.garlic.com/~lynn/2000c.html#34 What level of computer is needed for a computer to Love?
http://www.garlic.com/~lynn/2001b.html#18 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
http://www.garlic.com/~lynn/2001i.html#37 IBM OS Timeline?
http://www.garlic.com/~lynn/2001i.html#38 IBM OS Timeline?
http://www.garlic.com/~lynn/2002c.html#39 VAX, M68K complex instructions (was Re: Did Intel Bite Off More Than It Can Chew?)
http://www.garlic.com/~lynn/2002n.html#62 PLX
http://www.garlic.com/~lynn/2003k.html#27 Microkernels are not "all or nothing". Re: Multics Concepts For
http://www.garlic.com/~lynn/2004.html#18 virtual-machine theory
http://www.garlic.com/~lynn/2004e.html#40 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004o.html#57 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005f.html#47 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005t.html#7 2nd level install - duplicate volsers
http://www.garlic.com/~lynn/2006.html#31 Is VIO mandatory?
http://www.garlic.com/~lynn/2006b.html#25 Multiple address spaces
http://www.garlic.com/~lynn/2006j.html#27 virtual memory
http://www.garlic.com/~lynn/2007f.html#6 IBM S/360 series operating systems history
http://www.garlic.com/~lynn/2007f.html#33 Historical curiosity question
http://www.garlic.com/~lynn/2007n.html#35 IBM obsoleting mainframe hardware

mainframe performance, was Is a RISC chip more expensive?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: mainframe performance, was Is a RISC chip more expensive?
Newsgroups: comp.arch
Date: Fri, 31 Aug 2007 09:17:01 -0400
Stephen Fuld <S.Fuld@PleaseRemove.att.net> writes:
The general consensus that led to RISC systems was that a sequence of RISC instructions was at least as fast, and usually faster than a heavily microcoded instruction for accomplishing complex tasks. So what is it about the microcode assists that changes this consensus?

other post in this thread
http://www.garlic.com/~lynn/2007o.html#35 Is a RISC chip more expensive?

fort knox and related activities ... replacing large variety of different microprocessors with 801 "iliad" processors was more about eliminated huge amount of hardware and software investment in constantly developing and supporting different processors. misc. past posts mentioning romp, rios, 801, iliad, fort knox, etc
http://www.garlic.com/~lynn/subtopic.html#801

the big thing in microcode assists was that typical 370 mainframe implementation for the low-end and mid-range machines involved microprocessors with an avg. of ten microprocessor instructions executed for every 370 instruction emulated. something similar is currently observed in the 370 emulators implemented on i86 platforms.

the 138/148 ecps microcode assist identified high-use kernel code paths and architectected mechanism that took critical (370 mainframe) code sequences and moved them into native processor engine ... for a 10:1 performance improvement. This issue is orthogonal to whether the native engine was cisc or a 801 iliad processor. for other drift ... old email mentioning 801
http://www.garlic.com/~lynn/lhwemail.html#801

there was another class of virtual machine microcode assists that gained performance by avoiding context switch. a "privilege" instruction involved interrupt into hypervisor kernel, context change and state save, redecode the instruction (in software), emulate the instruction, and context change/state restore back to the virtual machine. in this scenario ... the native hardware had additional support to directly implement the instruction according to virtual machine rules. This didn't involve executing the same operations faster ... this involved the elimination of a lot of hypervisor overhead (state change in and out of hypervisor kernel).

for other drift, old email from early 80s ... discussing the difference between the SIE instruction implementation in 3081 and 3090
http://www.garlic.com/~lynn/2006j.html#email810630
in this post
http://www.garlic.com/~lynn/2006j.html#27 virtual memory

misc. past posts mentioning ECPS vm microcode assit:
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist
http://www.garlic.com/~lynn/94.html#27 370 ECPS VM microcode assist
http://www.garlic.com/~lynn/94.html#28 370 ECPS VM microcode assist
http://www.garlic.com/~lynn/2000.html#12 I'm overwhelmed
http://www.garlic.com/~lynn/2000c.html#50 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#76 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000e.html#6 Ridiculous
http://www.garlic.com/~lynn/2000g.html#7 360/370 instruction cycle time
http://www.garlic.com/~lynn/2001i.html#2 Most complex instructions (was Re: IBM 9020 FAA/ATC Systems from 1960's)
http://www.garlic.com/~lynn/2001i.html#3 Most complex instructions (was Re: IBM 9020 FAA/ATC Systems from 1960's)
http://www.garlic.com/~lynn/2002e.html#75 Computers in Science Fiction
http://www.garlic.com/~lynn/2002l.html#51 Handling variable page sizes?
http://www.garlic.com/~lynn/2002l.html#62 Itanium2 performance data from SGI
http://www.garlic.com/~lynn/2002o.html#15 Home mainframes
http://www.garlic.com/~lynn/2002o.html#16 Home mainframes
http://www.garlic.com/~lynn/2002p.html#44 Linux paging
http://www.garlic.com/~lynn/2002p.html#48 Linux paging
http://www.garlic.com/~lynn/2003.html#4 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#7 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#14 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#16 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#17 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#61 MIDAS
http://www.garlic.com/~lynn/2003d.html#21 PDP10 and RISC
http://www.garlic.com/~lynn/2003e.html#56 Reviving Multics
http://www.garlic.com/~lynn/2003f.html#21 "Super-Cheap" Supercomputing
http://www.garlic.com/~lynn/2003f.html#43 ECPS:VM DISPx instructions
http://www.garlic.com/~lynn/2003f.html#52 ECPS:VM DISPx instructions
http://www.garlic.com/~lynn/2003f.html#54 ECPS:VM DISPx instructions
http://www.garlic.com/~lynn/2003f.html#56 ECPS:VM DISPx instructions
http://www.garlic.com/~lynn/2003m.html#37 S/360 undocumented instructions?
http://www.garlic.com/~lynn/2004f.html#3 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004f.html#21 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004f.html#29 [Meta] Marketplace argument
http://www.garlic.com/~lynn/2004j.html#45 A quote from Crypto-Gram
http://www.garlic.com/~lynn/2004m.html#5 Tera
http://www.garlic.com/~lynn/2004q.html#64 Will multicore CPUs have identical cores?
http://www.garlic.com/~lynn/2004q.html#72 IUCV in VM/CMS
http://www.garlic.com/~lynn/2005d.html#41 Thou shalt have no other gods before the ANSI C standard
http://www.garlic.com/~lynn/2005d.html#59 Misuse of word "microcode"
http://www.garlic.com/~lynn/2005f.html#59 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005g.html#17 DOS/360: Forty years
http://www.garlic.com/~lynn/2005h.html#24 Description of a new old-fashioned programming language
http://www.garlic.com/~lynn/2005k.html#17 More on garbage collection
http://www.garlic.com/~lynn/2005k.html#38 Determining processor status without IPIs
http://www.garlic.com/~lynn/2005k.html#42 wheeler scheduler and hpo
http://www.garlic.com/~lynn/2005k.html#49 Determining processor status without IPIs
http://www.garlic.com/~lynn/2005k.html#50 Performance and Capacity Planning
http://www.garlic.com/~lynn/2005k.html#54 Determining processor status without IPIs
http://www.garlic.com/~lynn/2005k.html#59 Book on computer architecture for beginners
http://www.garlic.com/~lynn/2005n.html#12 Code density and performance?
http://www.garlic.com/~lynn/2005n.html#18 Code density and performance?
http://www.garlic.com/~lynn/2005n.html#45 Anyone know whether VM/370 EDGAR is still available anywhere?
http://www.garlic.com/~lynn/2005o.html#35 Implementing schedulers in processor????
http://www.garlic.com/~lynn/2005p.html#14 Multicores
http://www.garlic.com/~lynn/2005p.html#27 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005p.html#29 Documentation for the New Instructions for the z9 Processor
http://www.garlic.com/~lynn/2005p.html#38 storage key question
http://www.garlic.com/~lynn/2005s.html#36 Filemode 7-9?
http://www.garlic.com/~lynn/2005u.html#40 POWER6 on zSeries?
http://www.garlic.com/~lynn/2005u.html#43 POWER6 on zSeries?
http://www.garlic.com/~lynn/2005u.html#44 POWER6 on zSeries?
http://www.garlic.com/~lynn/2005u.html#45 IBM's POWER6
http://www.garlic.com/~lynn/2006b.html#38 blast from the past ... macrocode
http://www.garlic.com/~lynn/2006c.html#11 Mainframe Jobs Going Away
http://www.garlic.com/~lynn/2006c.html#47 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006j.html#21 virtual memory
http://www.garlic.com/~lynn/2006m.html#39 Using different storage key's
http://www.garlic.com/~lynn/2006m.html#54 DCSS
http://www.garlic.com/~lynn/2006n.html#44 Any resources on VLIW?
http://www.garlic.com/~lynn/2006o.html#23 Strobe equivalents
http://www.garlic.com/~lynn/2006r.html#37 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006s.html#22 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006u.html#29 To RISC or not to RISC
http://www.garlic.com/~lynn/2006u.html#32 To RISC or not to RISC
http://www.garlic.com/~lynn/2006u.html#33 Assembler question
http://www.garlic.com/~lynn/2006u.html#34 Assembler question
http://www.garlic.com/~lynn/2006w.html#11 long ago and far away, vm370 from early/mid 70s
http://www.garlic.com/~lynn/2006y.html#21 moving on
http://www.garlic.com/~lynn/2007f.html#6 IBM S/360 series operating systems history
http://www.garlic.com/~lynn/2007f.html#14 more shared segment archeology
http://www.garlic.com/~lynn/2007f.html#16 more shared segment archeology
http://www.garlic.com/~lynn/2007g.html#72 The Perfect Computer - 36 bits?

Flying Was: Fission products

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Flying Was: Fission products
Newsgroups: alt.folklore.computers
Date: Fri, 31 Aug 2007 09:22:49 -0400
lynn writes:
one of the ATC-modernization projects from the late 80s (nearly 20yrs now) attempting to leverage all sorts of new technology to automagically handle all failure modes. However, there was effectively an assumption that all failure/glitches would be computer and/or electronic related. The idea was that the actual application could be written as if failure/ glitches didn't exist ... and the underlying system would have recovery to mask all possible failure/glitches from the application.

re:
http://www.garlic.com/~lynn/2007o.html#18 Flying Was: Fission products

latest round of ATC-modernization:

ITT wins $1.8 bln bid to bring air-traffic control to modern era
http://www.marketwatch.com/news/story/itt-wins-18-bln-bid/story.aspx?guid=%7BBAD16EB9-6E60-4ABF-AB98-5C173C504DB6%7D&dist=MostTopHome
ITT Awarded FAA Contract For Air-Traffic Control System
http://www.washingtonpost.com/wp-dyn/content/article/2007/08/30/AR2007083002045.html?hpid=moreheadlines
Raytheon-XM Satellite Radio bid to revamp U.S. air traffic control system
http://www.iht.com/articles/2007/08/23/technology/air.php
Fixing the Air Traffic Mess
http://online.wsj.com/article/SB118757406199802519.html?mod=googlenews_wsj
ITT wins contract for air-traffic system
http://seattletimes.nwsource.com/html/nationworld/2003861601_ndig31.html

64 gig memory

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 64 gig memory
Newsgroups: comp.lang.asm370,alt.folklore.computers
Date: Fri, 31 Aug 2007 17:43:15 -0400
SkippyPB <swiegand@nospam.neo.rr.com> writes:
I know we upgraded to a 370/115 with DOS/VS and Power/VS and were thrilled we now had enough speed and memory to run Cobol programs :)

cp40 originally ran on modified 360/40 with 256k (and custom DAT hardware) ... it then morphed into cp67 when 360/67 with standard DAT hardware became available ... and still would run somewhat comfortably on 256k bytes .... although over time the cp67 started to bloat somewhat and made it harder to run comfortably in 256k real memory.

at that time, all of the cp67 kernel was fixed into real memory. i initially did modifications to support paging portions (of lower useage) parts of the kernel (freeing up more real storage for use as application virtual address paging). this never shipped as part of cp67 product ... but it was part of standard vm370 product. however, even with standard ability to "page" parts of the vm370 kernel, the "fixed" kernel part got fairly bloated over time.

at one point, a customer tried to run vm370 on 256k 370/125 ... even tho vm370 hadn't been official announced as supported on 125. i eventually got contacted to come down and see what i could do to improve vm370 on 125 (it was nyc office of some european shipping company). at the time, the fixed portion of vm370 kernel had grown to around 120k ... and with some fiddling i got it down to 80k ... still not quite as good as cp67 ... but it improved pageable storage for applications from about 120k to 170k or so.

my first student programming job had been porting a 1401 program to 64kbyte 360/30. the 1401 was acting as cardreader/print/punch front-end to 709 (handling cardreader/print/punch to/from tape). as part of eventually replacing 709 with 360, they got a 360/30 as replacement for the 1401. the 360/30 could be run in 1401 hardware emulation mode ... but i got the job of implementing all the function in native 360. i got to design, implement, test, etc my own monitor, interrupt handlers, device drivers, error recovery, dynamic storage management, etc. the program was evenaully about 2000 cards ... possibly 1600 360 assembler statements ... or program somewhere around 4000-5000 bytes ... and it would dynamically use all remaining storage for i/o buffers.

misc. past posts mentiong 370/125
http://www.garlic.com/~lynn/99.html#149 OS/360 (and descendents) VM system?
http://www.garlic.com/~lynn/2000.html#11 I'm overwhelmed
http://www.garlic.com/~lynn/2000.html#12 I'm overwhelmed
http://www.garlic.com/~lynn/2000c.html#30 internal corporate network, misc.
http://www.garlic.com/~lynn/2000c.html#49 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#68 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000e.html#6 Ridiculous
http://www.garlic.com/~lynn/2000e.html#7 Ridiculous
http://www.garlic.com/~lynn/2000f.html#63 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000g.html#7 360/370 instruction cycle time
http://www.garlic.com/~lynn/2000g.html#8 360/370 instruction cycle time
http://www.garlic.com/~lynn/2001b.html#40 John Mashey's greatest hits
http://www.garlic.com/~lynn/2001c.html#2 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001f.html#43 Golden Era of Compilers
http://www.garlic.com/~lynn/2001f.html#69 Test and Set (TS) vs Compare and Swap (CS)
http://www.garlic.com/~lynn/2001h.html#69 Very CISC Instuctions (Was: why the machine word size ...)
http://www.garlic.com/~lynn/2001i.html#2 Most complex instructions (was Re: IBM 9020 FAA/ATC Systems from 1960's)
http://www.garlic.com/~lynn/2001j.html#48 Pentium 4 SMT "Hyperthreading"
http://www.garlic.com/~lynn/2002f.html#13 Hardware glitches, designed in and otherwise
http://www.garlic.com/~lynn/2002i.html#2 Where did text file line ending characters begin?
http://www.garlic.com/~lynn/2002i.html#24 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#76 HONE was .. Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002o.html#16 Home mainframes
http://www.garlic.com/~lynn/2002p.html#58 AMP vs SMP
http://www.garlic.com/~lynn/2003.html#5 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#7 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#8 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#13 FlexEs and IVSK instruction
http://www.garlic.com/~lynn/2003j.html#27 A Dark Day
http://www.garlic.com/~lynn/2004b.html#26 determining memory size
http://www.garlic.com/~lynn/2004c.html#33 separate MMU chips
http://www.garlic.com/~lynn/2004d.html#12 real multi-tasking, multi-programming
http://www.garlic.com/~lynn/2004g.html#42 command line switches [Re: [REALLY OT!] Overuse of symbolic constants]
http://www.garlic.com/~lynn/2004m.html#17 mainframe and microprocessor
http://www.garlic.com/~lynn/2005.html#5 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005c.html#33 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005f.html#10 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005l.html#27 How does this make you feel?
http://www.garlic.com/~lynn/2006.html#12 Zeroing core
http://www.garlic.com/~lynn/2006n.html#26 sorting was: The System/360 Model 20 Wasn't As Bad As All That
http://www.garlic.com/~lynn/2006n.html#46 Why is z series so CPU poor?
http://www.garlic.com/~lynn/2006q.html#45 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006q.html#49 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2007d.html#72 IBM S/360 series operating systems history
http://www.garlic.com/~lynn/2007j.html#29 John W. Backus, 82, Fortran developer, dies

misc. past posts mentioning first student programming job
http://www.garlic.com/~lynn/93.html#15 unit record & other controllers
http://www.garlic.com/~lynn/93.html#23 MTS & LLMPS?
http://www.garlic.com/~lynn/94.html#53 How Do the Old Mainframes
http://www.garlic.com/~lynn/97.html#21 IBM 1401's claim to fame
http://www.garlic.com/~lynn/98.html#9 ** Old Vintage Operating Systems **
http://www.garlic.com/~lynn/99.html#130 early hardware
http://www.garlic.com/~lynn/2001k.html#31 Is anybody out there still writting BAL 370.
http://www.garlic.com/~lynn/2002f.html#47 How Long have you worked with MF's ? (poll)
http://www.garlic.com/~lynn/2002m.html#3 The problem with installable operating systems
http://www.garlic.com/~lynn/2002o.html#19 The Hitchhiker's Guide to the Mainframe
http://www.garlic.com/~lynn/2003h.html#30 Hardware support of "new" instructions
http://www.garlic.com/~lynn/2003i.html#8 A Dark Day
http://www.garlic.com/~lynn/2003i.html#12 Which monitor for Fujitsu Micro 16s?
http://www.garlic.com/~lynn/2004f.html#49 can a program be run withour main memory?
http://www.garlic.com/~lynn/2004g.html#39 spool
http://www.garlic.com/~lynn/2004k.html#40 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2004q.html#66 Will multicore CPUs have identical cores?
http://www.garlic.com/~lynn/2005c.html#54 12-2-9 REP & 47F0
http://www.garlic.com/~lynn/2005g.html#52 Software for IBM 360/30
http://www.garlic.com/~lynn/2005n.html#3 Data communications over telegraph circuits
http://www.garlic.com/~lynn/2005q.html#7 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2006b.html#2 Mount a tape
http://www.garlic.com/~lynn/2006g.html#43 Binder REP Cards (Was: What's the linkage editor really wants?)
http://www.garlic.com/~lynn/2006l.html#64 Large Computer Rescue
http://www.garlic.com/~lynn/2006n.html#1 The System/360 Model 20 Wasn't As Bad As All That
http://www.garlic.com/~lynn/2006s.html#38 Design life of S/360 components?
http://www.garlic.com/~lynn/2006w.html#31 Decimal FP
http://www.garlic.com/~lynn/2007d.html#51 IBM S/360 series operating systems history
http://www.garlic.com/~lynn/2007h.html#52 ANN: Microsoft goes Open Source
http://www.garlic.com/~lynn/2007m.html#73 Operating systems are old and busted
http://www.garlic.com/~lynn/2007n.html#59 IBM System/360 DOS still going strong as Z/VSE

Virtual Storage implementation

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Virtual Storage implementation
Date: Fri, 31 Aug 2007 19:07:11 -0400
Newsgroups: bit.listserv.ibm-main
eamacneil@YAHOO.CA (Ted MacNEIL) writes:
Also, sub-systems like DB2 are getting to the point where you should/could/would not like it to page. Sort of throws the concept out the window, doesn't it?

previous post in thread
http://www.garlic.com/~lynn/2007o.html#41 Virtual Storage implementation

one of the things that can happen is if you run a subsystem doing LRU-like activity management in a virtual address space that is also being managed with a LRU-like activity management.

I first noticed this in the 70s ... when some of the os/360 migrated to virtual storage support and were in turn run in a virtual machine. vm370 was managing the virtual address space (of the virtual machine) with an LRU-like algorithm .... while the guest operating system was also managing (what it thot to be real storage) with a LRU-like algorithm.

if the virtual quest took a page fault ... it would examine its available storage for the least-recently used page to "replace". if the vm370 hypervisor was also paging ... it will also have used the same criteria to remove the least-recently used page from real storage ... however, this would possibly also going to be the most likely next page that the virtual guest was going to start using (when it did its own paging).

dbms subsystems tends to have large buffer storage ... that are managed in a manner analogous to virtual storage ... i.e. the least recently used buffer is likely to be replaced with the latest requested record. A heavily used dbms subsystem is likely going to use the maximum storage available to it (because it is going to replace its least recently used buffers with the most recently requested records).

one of my statements from the 70s was that running an LRU-like algorithm under a LRU-like algorithm can result in very pathelogical behavior and the virtualized quest/subystem can exhibit exact opposite of behavior of assumptions that are the foundation of LRU implementations (the least recently used page is the least likely to be needed in the near future, a "virtual" LRU-like algorithm is most likely to use the least recently used page).

lots of past posts mentioning virtual storage page replacement and/or page/buffer replacement algorithms
http://www.garlic.com/~lynn/subtopic.html#wsclock

misc. past posts mentioning original rdbms & sql implementation (originally all done on vm370 platform)
http://www.garlic.com/~lynn/submain.html#systemr

including tech. transfer from bldg. 28 to endicott for sql/ds.

for other topic drift one of the people in the meeting mentioned in the following post claimed to have handled large part of the technology transfer from endicott to bldg. 90 for DB2
http://www.garlic.com/~lynn/95.html#13
http://www.garlic.com/~lynn/96.html#15

above meeting was related to turning out ha/cmp product
http://www.garlic.com/~lynn/subtopic.html#hacmp

and other old email related to working on ha/cmp scaleup
http://www.garlic.com/~lynn/lhwemail.html#medusa

another scenaro of running subsystem in a paged virtual address space ... which believed that the virtual address space was really memory was when the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

originally did the port of apl\360 to cms for cms\apl. The problem was that apl\360 believed its "workspace" was resident real storage and had a storage allocation strategy that would assign a new storage location for every assignment statement ... until it had exhausted the available (workspace) available storage ... at which point it would do garbage collection and collapse all allocated locations into contiguous memory ... and then starting all over again. It wasn't too bad to repeatedly use all of a (real storage) 16kbyte swapped workspace. However, in cms virtual address space environment, the available workspace could easily be several mbytes (or even nearly all of 16mbytes). this would be under cp67 on a 360/67 with typically 512kbytes to 1mbyte of real storage. very quickly it was realized that the apl\360 storage management and garbage collection implementation had to be significantly reworked to move it to a virtual memory environment.

Turns out one of the early major uses of cms\apl on the cambridge cp67 machine was the business planning people in armonk. prior to cms\apl, apl\360 with only 16kbyte-32kbyte workspace sizes didn't provide much room for working on any real world problems. significantly opening up the apl workspace size with cms\apl allowed for work on some real world problems. the business planning people loaded the most sensitive corporate information ... detailed customer information ... on the cambridge machine and ran sophisticated business modeling applications implemented in apl. lots of past posts mentioning apl (&/or hone)
http://www.garlic.com/~lynn/subtopic.html#hone

for other drift, this represented some interested security issues ... since the cambridge system was also being used by numerous students and others from colleges and universities in the cambridge area. recent post on that particular topic drift:
http://www.garlic.com/~lynn/2007o.html#36 It's No Secret: VMware to Develop Secure Systems for NSA
http://www.garlic.com/~lynn/2007o.html#38 It's No Secret: VMware to Develop Secure Systems for NSA
http://www.garlic.com/~lynn/2007o.html#39 It's No Secret: VMware to Develop Secure Systems for NSA

Virtual Storage implementation

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: re: Virtual Storage implementation
Date: Fri, 31 Aug 2007 19:30:39 -0400
Newsgroups: bit.listserv.ibm-main
mpost@ibm-main.lst (Mark Post) writes:
Oh, and if you create a 64GB z/VM guest, shame on you. As someone who is very heavy into z/VM performance once told me, "z/VM is very good at managing large numbers of small things. It's not so good at managing a smaller number of very large things." I tend to agree. The z/VM scheduler isn't too happy about guests with large working sets.

the issue may not so much be a scheduling problem and/or specifically a "large" working set problem ... as somewhat mentioned in this post:
http://www.garlic.com/~lynn/2007o.html#45 Virtual Storage implementation

there is an implicit assumption in paged virtual memory and working sets with regard to least-recently-used page replacement algorithms ... which assumes that the page/buffer that has been least-recently-used in the past is likely to be least-recently-used in the future. however, virtual guests and various subsystems (which manage storage with their own least-recently-used algorithm) or likely to exhibit just the opposite behavior ... the page/buffer that has been least-recently-used in the past ... is the page/buffer that the virtual guest/subsystem is going to select for replacement and start using.

Having a multi-level least-recently-used replacement strategy can exhibit pathelogical behavior where the next lower level management has removed the page/buffer .... which is going to be the higher level management operation is most likely to select to start using (the "hypervisor" closest to the hardware is the lowest level).

lots of past posts mentioning page replacement algorithms and virtual storage management
http://www.garlic.com/~lynn/subtopic.html#wsclock

Virtual Storage implementation

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Virtual Storage implementation
Date: Fri, 31 Aug 2007 19:51:48 -0400
Newsgroups: bit.listserv.ibm-main
Steve_Thompson@ibm-main.lst (Thompson, Steve) writes:
VSE, as I recall, was told that it had 32MB (or something similar) and VM then took care of the paging (because VSE didn't page in that case) -- must understand the memory system used by VSE (similar to VS1).

recent posts in this thread:
http://www.garlic.com/~lynn/2007o.html#41 Virtual Storage implementation
http://www.garlic.com/~lynn/2007o.html#45 Virtual Storage implementation
http://www.garlic.com/~lynn/2007o.html#46 Virtual Storage implementation

the handshaking had earlier been implemented in cp67 with mvt by one of the university cp67 installations.

a similar implementation was done for vm370 somewhat in conjunction with the ecps microcode assist ... for a little topic drift a recent post in comp.arch mentioning ecps (as well as sie)
http://www.garlic.com/~lynn/2007o.html#42 mainframe performance, was Is a RISC chip more expensive?

vs1 typically ran with something like a 4mbyte virtual address space ... something akin to the initial move of mvt to os/vs2 svs which ran with a 16mbyte virtual address space.

for vs1 handshaking, vm370 gave the vs1 guest virtual machine a 4mbyte machine. then vs1 mapped its 4mbyte virtual address space one-for-one to the 4mbyte virtual machine address space (at first glance vs1 had 4mbyte virtual address space to a 4mbyte machine so it would never get any "guest" page faults). all the page faults would be happening at the vm370 level, which would then schedule a psuedo page-fault interrupt for the vs1 guest while it performed the page replacement operation. This would allow vs1 to switch to a different task/application ... so that the whole virtual machine execution wouldn't be blocked just waiting on page fault processing for a specific task/application. When page fetch had been completed, vm370 would post a psuedo page fetch completion interrupt to VS1 guest ... so that it might choose to re-enable that faulted task for execution.

the assumption was that the virtual machine guest is multitasking lots of different workload and is capable of doing a task switch and continue execution when a specific task has a missing page.

I had highly optimized both the native vm370 page processing pathlength as well as selection of code paths to be moved to microcode as part of the ECPS effort. As a result, it was actually possible for VS1 to have higher thruput under vm370 than running stand-alone on the same hardware (w/o vm370; my pathlength for doing page processing was significantly better than VS1's ... as well as my page replacement implementation).

Virtual Storage implementation

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Virtual Storage implementation
Date: Fri, 31 Aug 2007 20:13:36 -0400
Newsgroups: bit.listserv.ibm-main
mpost@ibm-main.lst (Mark Post) writes:
That's still probably too much, if only by a little. The idea is to force Linux to use as little storage as possible for buffers and cache, and page out any programs, etc., that haven't been used very recently. Letting z/VM handle this via expanded storage, and paging some things out to real disk turns out to work very well in a shared environment. Other techniques, such as having the kernel in a Named Saved Segment, and executable userspace code in a DCSS using the eXecute In Place file system helps even more.

previous posts in this thread:
http://www.garlic.com/~lynn/2007o.html#41 Virtual Storage implementation
http://www.garlic.com/~lynn/2007o.html#45 Virtual Storage implementation
http://www.garlic.com/~lynn/2007o.html#46 Virtual Storage implementation
http://www.garlic.com/~lynn/2007o.html#47 Virtual Storage implementation

for more archeological topic drift with regard to DCSS. i had originally started what i called "virtual memory management" on cp67 platform at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

this included mapping the cms filesystem to a paged mapped infrastructure
http://www.garlic.com/~lynn/submain.html#mmap

which included a lot of fancy options about moving pages to/from virtual address space and disk storage. i then ported this to a vm370/cms environment with a lot of options for sharing of segments. a variety of some of this was used in some of the original relation/sql dbms work ... all done on vm370 platform
http://www.garlic.com/~lynn/submain.html#systemr

in the early 70s, there was a project called future system
http://www.garlic.com/~lynn/submain.html#futuresys

which was going to replace 360/370 with a radically different machine architecture. this effort absorbed significant corporate resources and when it was finally canceled (w/o even being announced) there was significant scrambling to get all sort of items back into the 370 hardware and software product pipeline.

The resulting mad scramble open opportunity to get a lot of work ... that had continued at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

on 370s into vm370 product ... including my resource manager
http://www.garlic.com/~lynn/subtopic.html#fairshare

that included a large amount of other work not strictly related to resource management, things like lots of kernel reorganization for multiprocessor support
http://www.garlic.com/~lynn/subtopic.html#smp

part of that opportunity resulted in releasing an extremely small subset of the "virtual memory management" work as DCSS (and the generalized paged mapped infrastructure was not included). for additional topic drift ... some discussions of various problems trying to reconcile generalized virtual memory management features with os/360 address constant convention
http://www.garlic.com/~lynn/submain.html#adcon

64 gig memory

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 64 gig memory
Newsgroups: comp.lang.asm370,alt.folklore.computers
Date: Sat, 01 Sep 2007 08:30:22 -0400
Eric Smith <eric@brouhaha.com> writes:
Not likely. Maybe it was a 360/40.

from:
http://www.beagle-ears.com/lars/engineer/comphist/model360.htm

As for the IBM S/360 machines, here's a summary from a table in
appendix D of the book 'Programming the IBM 360' by Clarence B.
Germain (1967):

360 MODELS

#    Core Size  25  30  40  50  65  75  85  91-95   44  67  20
B        4K......X...........................................X.
C        8K......X...X.......................................X.
D       16K......X...X...X...................................X.
E       32K......X...X...X...........................X.........
F       64K..........X...X...X.......................X.........
G      128K..............X...X...X...................X.........
H      256K..............X...X...X...X...............X..X......
I      512K..................X...X...X...X..............X......
J     1024K..................X...X...X...X.....X........X......
K     2048K..............................X.....X........X......
L     4096K..............................X.....X...............
2361  1024K..................X...X...X.........................
2361  2048K..................X...X...X.........................
CD      24K....................................................
DE      48K....................................................

Cycle time(uS)  .9  1.5 2.5 2.0 .75 .75 1.04 .75-.125 1.0 .75 3.6
  per _ bytes    2  1   2   4   8   8   16   8        4   8   1

64 gig memory

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 64 gig memory
Date: Sat, 01 Sep 2007 08:26:37 -0400
Newsgroups: alt.folklore.computers
Frank McCoy <mccoyf@millcomm.com> writes:
It really ain't so much the *language* used, as the person doing the programming (or engineering).

i've frequently made the comparison between C language environment string/length handling metaphor ... and road systems. there are some road constructions that tend to have significantly higher accidents and the severity of the accidents are worse. lots of effort has gone into accident mitigation both in road design/construction and in automobiles.

one might make similar observation about analogy with building codes ... not only for roads, but houses, malls, bridges, etc

there can be significant variation in different people's programming capabilities ... but with lots & lots of people programming ... skill level is going to be all across the board ... somewhat analogous to drivers and driving infrastructure.

there was study of multics ... implemented in pli, of never having length related vulnerabilities.
http://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation
http://www.garlic.com/~lynn/2002l.html#45 Thirty Years Later: Lessons from the Multics Security Evaluation

original mainframe tcp/ip support was done in vs/pascal ... and also i'm not aware of it having any length related vulnerabilities. as it happened, there were other performance issues with that implementation which would burn nearly a full 3090 processor getting 44kbytes/sec thruput. I modified the implementation for rfc 1044 support and some testing at cray research between a cray and 4341-clone got 1mbyte/sec thruput using only a modest amount of the 4341-clone processor
http://www.garlic.com/~lynn/subnetwork.html#1044

my frequent assertion is that C string/length methapor significantly contributes to length related errors/mistakes being made by people programming in C.

lots of past posts on the subject of length vulnerabilities and C language string/length metaphor.
http://www.garlic.com/~lynn/subintegrity.html#overflow

one observation regarding programming skill is analogy with natural language skills ... one of the characteristic periodically claimed for natural language skill is when you dream/thing/etc directly in the language ... as opposed to constantly having to translate.
http://www.garlic.com/~lynn/2002e.html#37 Would the value of knowledge and information be transferred or shared accurately across the different culture??????
http://www.garlic.com/~lynn/2004j.html#26 Losing colonies
http://www.garlic.com/~lynn/2005d.html#48 Secure design
http://www.garlic.com/~lynn/2005d.html#49 Secure design

EZPass: Yes, Big Brother IS Watching You!

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: EZPass: Yes, Big Brother IS Watching You!
Date: Sat, 01 Sep 2007 08:41:29 -0400
Newsgroups: alt.folklore.computers,misc.transport.road
John Ahlstrom <AhlstromJK@comcast.net> writes:
But we did. During the Revolutionary War the number of British sympathizers was huge and the battles between Americans were bloody.

But then the Tories fled/were driven out and we could get on with our nation building.

Political if not ethnic cleansing.


for other drift ... my wife's father was awarded a set of history books for something when he was at west point. they were from a series of history lectures from the later half of 1880s.

one of the points raised in the books was that if it hadn't been for the heavy scottish influence (from the mid-atlantic states), the influence of the english (from ny, new england) would have resulted in a significantly different constitution and type of governemnt.

misc. past posts:
http://www.garlic.com/~lynn/2006b.html#30 Empires and Imperialism
http://www.garlic.com/~lynn/2006r.html#47 Mickey and friends
http://www.garlic.com/~lynn/2006u.html#57 Pedantry (was RE: Shane's antipodes)

Virtual Storage implementation

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Virtual Storage implementation
Date: Sat, 01 Sep 2007 13:27:53 -0400
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Anne & Lynn Wheeler wrote:
for other topic drift one of the people in the meeting mentioned in the following post claimed to have handled large part of the technology transfer from endicott to bldg. 90 for DB2
http://www.garlic.com/~lynn/95.html#13
http://www.garlic.com/~lynn/96.html#15


re:
http://www.garlic.com/~lynn/2007o.html#45 Virtual Storage implementation

for other archaeological topic drift ... two of the other people in the referenced meeting were later at a small client/server startup responsible for something called the commerce server. we had been called in to consult because they wanted to do payment transactions on the server ... misc. past postings
http://www.garlic.com/~lynn/subnetwork.html#gateway

and the small startup also had this technology they called SSL ... misc. past postings
http://www.garlic.com/~lynn/subpubkey.html#sslcert

the effort is frequently now referred to as electronic commerce.

misc. other postings in this thread:
http://www.garlic.com/~lynn/2007o.html#41 Virtual Storage implementation
http://www.garlic.com/~lynn/2007o.html#46 Virtual Storage implementation
http://www.garlic.com/~lynn/2007o.html#47 Virtual Storage implementation
http://www.garlic.com/~lynn/2007o.html#48 Virtual Storage implementation

Virtual Storage implementation

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@GARLIC.COM (Anne & Lynn Wheeler)
Subject: Re: Virtual Storage implementation
Date: 1 Sep 2007 14:23:03 -0700
Newsgroups: bit.listserv.ibm-main
Mark Post wrote:
If you give a Linux guest a 4GB virtual machine, it will have very close to a 4GB working set. If you give that same Linux guest 64GB, it will have very close to a 64GB working set. The fact that you say "Linux will use what it needs" tells me that you have little or no experience running Linux, either on midrange systems or on the mainframe. Linux will _always_ use everything you give it, if for nothing else than buffers and cache. Hence the constant battle we have with midrange Linux sysadmins, DBAs, etc., regarding this topic. It's also a recurring topic with the midrange performance/capacity folks, since we keep getting concerned phone calls and emails about how we have to add more RAM to a Linux system because it's running out. It hasn't run out, it is just using all the otherwise unused storage for buffers and cache, but that's not the behavior they're used to seeing from AIX, Solaris, HPUX, etc.

past posts in this thread:
http://www.garlic.com/~lynn/2007o.html#41 Virtual Storage implementation
http://www.garlic.com/~lynn/2007o.html#45 Virtual Storage implementation
http://www.garlic.com/~lynn/2007o.html#46 Virtual Storage implementation
http://www.garlic.com/~lynn/2007o.html#47 Virtual Storage implementation
http://www.garlic.com/~lynn/2007o.html#48 Virtual Storage implementation
http://www.garlic.com/~lynn/2007o.html#52 Virtual Storage implementation

unix/linux will use its (virtual) machine storage for running applications and file caching. if there is enough machine storage ... the application storage is whatever the page requirements for the collection of the running appliications (linux kernel code, demons, etc). if the machine storage is at least as large as the total program execution storage ... then the system may not have to do any paging operations.

the remaining (potentially virtual) machine storage will be used for file record caching is analogous to the operation of dbms systems with database record caching. lots of dbms systems have configuration parameters for total size of record caching ... attempting to tune them when running in a virtual memory environment. this is similar to the description of the (storage management) changes migrating apl\360 (assuming the available storage was "real") to cms\apl (where there was enormously larger amount of virtual, paged storage). The implicit assumption was that the available configured storage was "real" and could be used arbitrarily w/o regard to potential working set size implications and effect on demand paging.
http://www.garlic.com/~lynn/2007o.html#45 Virtual Storage implementation

one of the other projects at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

involved application instruction and storage access tracing. this was used in modeling possible page replacement algorithms and working set sizes. Eventually some of this was released as VS/REPACK product which would do semi-automated program reorgnization to optimize virtual storage operation.

Early version of what became VS/REPACK was used in assisting with migrating apl\360 to virtual memory environment as cms\apl. Various versions of VS\REPACK were also used by other corporate product groups aiding in the migration from "real storage" paradigm to "virtual storage" paradigm. One such early user of the package was the organization developing and supporting IMS. A side-effect of the package tracing/monitoring ... in addition to helping analyzing execution characteristics in virtual storage environment, it was also used for straight-forward execution "hot-spot" analysis.

random past posts mentioning vs/repack:
http://www.garlic.com/~lynn/94.html#7 IBM 7090 (360s, 370s, apl, etc)
http://www.garlic.com/~lynn/97.html#20 Why Mainframes?
http://www.garlic.com/~lynn/99.html#7 IBM S/360
http://www.garlic.com/~lynn/99.html#61 Living legends
http://www.garlic.com/~lynn/99.html#68 The Melissa Virus or War on Microsoft?
http://www.garlic.com/~lynn/2000.html#78 Mainframe operating systems
http://www.garlic.com/~lynn/2000d.html#12 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000g.html#11 360/370 instruction cycle time
http://www.garlic.com/~lynn/2000g.html#30 Could CDR-coding be on the way back?
http://www.garlic.com/~lynn/2001b.html#83 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001c.html#31 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001c.html#33 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001i.html#20 Very CISC Instuctions (Was: why the machine word size ...)
http://www.garlic.com/~lynn/2001j.html#3 YKYGOW...
http://www.garlic.com/~lynn/2002c.html#28 OS Workloads : Interactive etc
http://www.garlic.com/~lynn/2002c.html#45 cp/67 addenda (cross-post warning)
http://www.garlic.com/~lynn/2002c.html#46 cp/67 addenda (cross-post warning)
http://www.garlic.com/~lynn/2002c.html#49 Swapper was Re: History of Login Names
http://www.garlic.com/~lynn/2002d.html#7 IBM Mainframe at home
http://www.garlic.com/~lynn/2002e.html#50 IBM going after Strobe?
http://www.garlic.com/~lynn/2002f.html#8 Is AMD doing an Intel?
http://www.garlic.com/~lynn/2002f.html#50 Blade architectures
http://www.garlic.com/~lynn/2002g.html#15 Security Issues of using Internet Banking
http://www.garlic.com/~lynn/2002p.html#59 AMP vs SMP
http://www.garlic.com/~lynn/2003f.html#15 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#21 "Super-Cheap" Supercomputing
http://www.garlic.com/~lynn/2003f.html#53 Alpha performance, why?
http://www.garlic.com/~lynn/2003g.html#15 Disk capacity and backup solutions
http://www.garlic.com/~lynn/2003g.html#63 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003h.html#8 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003j.html#32 Language semantics wrt exploits
http://www.garlic.com/~lynn/2004.html#9 Dyadic
http://www.garlic.com/~lynn/2004.html#10 Dyadic
http://www.garlic.com/~lynn/2004.html#14 Holee shit! 30 years ago!
http://www.garlic.com/~lynn/2004c.html#21 PSW Sampling
http://www.garlic.com/~lynn/2004f.html#21 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#2 Text Adventures (which computer was first?)
http://www.garlic.com/~lynn/2004m.html#17 mainframe and microprocessor
http://www.garlic.com/~lynn/2004m.html#22 Lock-free algorithms
http://www.garlic.com/~lynn/2004n.html#55 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004o.html#7 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004q.html#73 Athlon cache question
http://www.garlic.com/~lynn/2004q.html#76 Athlon cache question
http://www.garlic.com/~lynn/2005.html#4 Athlon cache question
http://www.garlic.com/~lynn/2005.html#17 Amusing acronym
http://www.garlic.com/~lynn/2005b.html#26 CAS and LL/SC
http://www.garlic.com/~lynn/2005d.html#41 Thou shalt have no other gods before the ANSI C standard
http://www.garlic.com/~lynn/2005d.html#48 Secure design
http://www.garlic.com/~lynn/2005d.html#62 Misuse of word "microcode"
http://www.garlic.com/~lynn/2005e.html#35 Thou shalt have no other gods before the ANSI C standard
http://www.garlic.com/~lynn/2005h.html#15 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005h.html#40 Software for IBM 360/30
http://www.garlic.com/~lynn/2005j.html#62 More on garbage collection
http://www.garlic.com/~lynn/2005k.html#17 More on garbage collection
http://www.garlic.com/~lynn/2005m.html#28 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005n.html#18 Code density and performance?
http://www.garlic.com/~lynn/2005o.html#5 Code density and performance?
http://www.garlic.com/~lynn/2006b.html#15 Expanded Storage
http://www.garlic.com/~lynn/2006b.html#23 Seeking Info on XDS Sigma 7 APL
http://www.garlic.com/~lynn/2006e.html#20 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006e.html#46 using 3390 mod-9s
http://www.garlic.com/~lynn/2006f.html#29 X.509 and ssh
http://www.garlic.com/~lynn/2006h.html#30 The Pankian Metaphor
http://www.garlic.com/~lynn/2006i.html#37 virtual memory
http://www.garlic.com/~lynn/2006j.html#18 virtual memory
http://www.garlic.com/~lynn/2006j.html#22 virtual memory
http://www.garlic.com/~lynn/2006j.html#24 virtual memory
http://www.garlic.com/~lynn/2006l.html#11 virtual memory
http://www.garlic.com/~lynn/2006m.html#19 Mainframe Linux Mythbusting
http://www.garlic.com/~lynn/2006n.html#16 On the 370/165 and the 360/85
http://www.garlic.com/~lynn/2006n.html#29 CRAM, DataCell, and 3850
http://www.garlic.com/~lynn/2006n.html#39 sorting
http://www.garlic.com/~lynn/2006o.html#23 Strobe equivalents
http://www.garlic.com/~lynn/2006o.html#26 Cache-Size vs Performance
http://www.garlic.com/~lynn/2006q.html#31 VAXen with switchmode power supplies?
http://www.garlic.com/~lynn/2006r.html#12 Trying to design low level hard disk manipulation program
http://www.garlic.com/~lynn/2006r.html#22 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006s.html#40 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006x.html#1 IBM sues maker of Intel-based Mainframe clones
http://www.garlic.com/~lynn/2006x.html#16 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2007c.html#14 How many 36-bit Unix ports in the old days?
http://www.garlic.com/~lynn/2007c.html#16 How many 36-bit Unix ports in the old days?
http://www.garlic.com/~lynn/2007d.html#21 How many 36-bit Unix ports in the old days?
http://www.garlic.com/~lynn/2007e.html#32 I/O in Emulated Mainframes
http://www.garlic.com/~lynn/2007f.html#28 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007f.html#38 IBM System z9
http://www.garlic.com/~lynn/2007g.html#31 Wylbur and Paging
http://www.garlic.com/~lynn/2007g.html#57 IBM to the PCM market(the sky is falling!!!the sky is falling!!)
http://www.garlic.com/~lynn/2007h.html#1 21st Century ISA goals?
http://www.garlic.com/~lynn/2007i.html#31 Latest Principles of Operation
http://www.garlic.com/~lynn/2007j.html#29 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007k.html#39 VLIW pre-history
http://www.garlic.com/~lynn/2007m.html#55 Capacity and Relational Database
http://www.garlic.com/~lynn/2007n.html#31 IBM obsoleting mainframe hardware

mainframe performance, was Is a RISC chip more expensive?

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: mainframe performance, was Is a RISC chip more expensive?
Date: Sun, 02 Sep 2007 18:04:03 -0400
Newsgroups: comp.arch
Stephen Fuld <S.Fuld@PleaseRemove.att.net> writes:
I think you may be confusing two different levels here. At one level, what used to be the bus and tag channels and later ESCON has now become fibre channel (FC). They did this to take advantage of the infrastructure available for FC (switches, cables, etc.) and allow elimination of the R&D expense of developing a faster ESCON, etc. FC has the ability to run several protocols over it. IBM runs one they call FICON. It is essentially an encapsulation of ECKD.

fiber channel started out as communication infrastructure ... somewhat pushed by llnl as a fiber version of a (copper) non-blocking switch implementation they had.

there was some fiber stuff (escon) for device i/o that had been laying around pok that was having trouble getting announced and shipped. one of the rs/6000 architects took the escon specification boosted the aggregate thruput by about ten percent and the driver compenents were done with significantly less costly components. this was announed with rs/6000 as SLA (serial link adaptor) ... for communciation (and incompatible with escon which was eventually announced and shipped).

he then started working on 800mbit version of sla. we had been working on some of the standards stuff and finally convinced him to give-up work on 800mbit sla effort and work on fiber channel standard (becoming the editor of the fcs standards document).

i've got quite a bit of old stuff from fcs standards mailing list .... and there was significant activity by the pok channel people applying higher level protocol on top of fiber channel attempting to emulate the half-duplex device i/o convention ... matching the two halves of the outgoing and incoming device i/o communication pairs (in addition to ECKD encapsulation)

ECKD somewhat started out as minimal modifications to CKD .... lots of old posts mentioning CKD
http://www.garlic.com/~lynn/submain.html#dasd

..... somewhat in lieu of moving to full FBA support ... for 3380 speed-match buffer ... allowing 3mbyte/sec 3380s to be attached to (earlier) 168 & 3033 1.5mbyte/sec channels ... misc. past post mentioning ECKD and speed-matching
http://www.garlic.com/~lynn/97.html#16 Why Mainframes?
http://www.garlic.com/~lynn/2002g.html#13 Secure Device Drivers
http://www.garlic.com/~lynn/2003.html#15 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003b.html#7 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2004d.html#68 bits, bytes, half-duplex, dual-simplex, etc
http://www.garlic.com/~lynn/2007.html#29 Just another example of mainframe costs
http://www.garlic.com/~lynn/2007e.html#40 FBA rant
http://www.garlic.com/~lynn/2007e.html#46 FBA rant
http://www.garlic.com/~lynn/2007f.html#0 FBA rant
http://www.garlic.com/~lynn/2007g.html#39 Wylbur and Paging

misc. past posts mentioning fcs and ficon
http://www.garlic.com/~lynn/2000c.html#56 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000d.html#14 FW: RS6000 vs IBM Mainframe
http://www.garlic.com/~lynn/2001k.html#22 ESCON Channel Limits
http://www.garlic.com/~lynn/2001m.html#25 ESCON Data Transfer Rate
http://www.garlic.com/~lynn/2002e.html#32 What goes into a 3090?
http://www.garlic.com/~lynn/2003h.html#0 Escon vs Ficon Cost
http://www.garlic.com/~lynn/2004d.html#68 bits, bytes, half-duplex, dual-simplex, etc
http://www.garlic.com/~lynn/2004p.html#29 FW: Is FICON good enough, or is it the only choice we get?
http://www.garlic.com/~lynn/2005.html#50 something like a CTC on a PC
http://www.garlic.com/~lynn/2005e.html#12 Device and channel
http://www.garlic.com/~lynn/2005h.html#7 IBM 360 channel assignments
http://www.garlic.com/~lynn/2005j.html#13 Performance and Capacity Planning
http://www.garlic.com/~lynn/2005l.html#26 ESCON to FICON conversion
http://www.garlic.com/~lynn/2005m.html#55 54 Processors?
http://www.garlic.com/~lynn/2006l.html#43 One or two CPUs - the pros & cons
http://www.garlic.com/~lynn/2006p.html#46 "25th Anniversary of the Personal Computer"
http://www.garlic.com/~lynn/2006x.html#11 The Future of CPUs: What's After Multi-Core?

mainframe performance, was Is a RISC chip more expensive?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: mainframe performance, was Is a RISC chip more expensive?
Date: Sun, 02 Sep 2007 18:04:29 -0400
Newsgroups: comp.arch
johnl@iecc.com (John L) writes:
Nope. The most recent POO has some new instructions for handling Unicode and a few more storage locking instructions, but nothing as complex as the sort assist. I presume IBM doesn't document the microcode assists because they don't want to have to support the exact interfaces they use from now until the end of time.

luther's radix stuff
A.7 sorting instructions
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/A.7?SHELF=DZ9ZBK03&DT=20040504121320


...t posts mentioning luther and radix stuff
http://www.garlic.com/~lynn/2001.html#2 A new "Remember when?" period happening right now
http://www.garlic.com/~lynn/2001d.html#28 Very CISC Instuctions (Was: why the machine word size ...)
http://www.garlic.com/~lynn/2001e.html#18 Pre ARPAnet email?
http://www.garlic.com/~lynn/2001h.html#73 Most complex instructions
http://www.garlic.com/~lynn/2002d.html#18 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2002e.html#55 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2005c.html#35 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005c.html#38 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005e.html#37 Where should the type information be?
http://www.garlic.com/~lynn/2007l.html#57 How would a relational operating system look like?

360/30 memory

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 360/30 memory
Newsgroups: comp.lang.asm370,alt.folklore.computers
Date: Mon, 03 Sep 2007 13:10:01 -0400
John Byrns <byrnsj@sbcglobal.net> writes:
This raises a question, if additional microcode was required for address calculations, then I would think that the additional microcode instructions that were executed would slow down the overall speed of the machine by increasing the number of microinstructions that it was necessary to execute for each 360 instruction. Does anyone know anything about this aspect of the situation and how the third party memory vendors and or the IBM RPQs dealt with it to maintain the original machine performance?

post on standard memory sizes ... plus standard LCS (large core storage) option ... which were also available from other vendors:
http://www.garlic.com/~lynn/2007o.html#49 64 gig memory

and 3033 had special feature to address (up to) 64mbytes of real storage (26bit) even tho instructions could only generate 24bit (both real and virtual) addresses.

the 370 page table entry had 16bits, 12bit page number (4k pages giving 24bit real addressing or 16mbytes), 2 defined bits, and two undefined bits.

with

systems using real memory for more and more caching ... somewhat to compensate for the relative system thruput of disk declining (disks were getting faster, but processor was getting much faster than disks were getting faster) and

a cluster of 4341 could have the same or higher aggregate processor speed, possibly 4-5 times more aggregate real storage, higher aggregate i/o thruput ... for less money (and significantly large disk caching).

... anyway, the two undefined bits in the PTE were scavenged to augment the 12bit page number ... providing for up to 14bit (4kbyte) page number ... for up to aggregate 64mbyte real addressing (even tho instruction addressing only supported up to 24bit/16mbyte).

misc. old email mentioning 43xx
http://www.garlic.com/~lynn/lhwemail.html#43xx

misc. past posts about 3033 supporting larger than 16mbyte storage configurations:
http://www.garlic.com/~lynn/93.html#14 S/360 addressing
http://www.garlic.com/~lynn/2000c.html#83 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000d.html#7 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#82 "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)
http://www.garlic.com/~lynn/2000g.html#28 Could CDR-coding be on the way back?
http://www.garlic.com/~lynn/2002c.html#40 using >=4GB of memory on a 32-bit processor
http://www.garlic.com/~lynn/2003d.html#26 Antiquity of Byte-Word addressing?
http://www.garlic.com/~lynn/2004.html#17 Holee shit! 30 years ago!
http://www.garlic.com/~lynn/2004c.html#6 If the x86 ISA could be redone
http://www.garlic.com/~lynn/2004e.html#41 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004n.html#50 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004o.html#57 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005m.html#28 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005p.html#1 Intel engineer discusses their dual-core design
http://www.garlic.com/~lynn/2005p.html#19 address space
http://www.garlic.com/~lynn/2006m.html#32 Old Hashing Routine
http://www.garlic.com/~lynn/2006p.html#0 DASD Response Time (on antique 3390?)
http://www.garlic.com/~lynn/2007b.html#16 V2X2 vs. Shark (SnapShot v. FlashCopy)
http://www.garlic.com/~lynn/2007g.html#59 IBM to the PCM market(the sky is falling!!!the sky is falling!!)
http://www.garlic.com/~lynn/2007o.html#10 IBM 8000 series

misc. past posts about 4341 clusters vis-a-vis 3033
http://www.garlic.com/~lynn/2001m.html#15 departmental servers
http://www.garlic.com/~lynn/2002j.html#4 HONE, ****, misc
http://www.garlic.com/~lynn/2002j.html#7 HONE, ****, misc
http://www.garlic.com/~lynn/2004f.html#39 Who said "The Mainframe is dead"?
http://www.garlic.com/~lynn/2004j.html#57 Monster(ous) sig (was Re: Vintage computers are better
http://www.garlic.com/~lynn/2004o.html#57 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004q.html#71 will there every be another commerically signficant new ISA?
http://www.garlic.com/~lynn/2005.html#34 increasing addressable memory via paged memory?
http://www.garlic.com/~lynn/2005f.html#30 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005n.html#11 Code density and performance?
http://www.garlic.com/~lynn/2005p.html#1 Intel engineer discusses their dual-core design
http://www.garlic.com/~lynn/2005q.html#30 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005q.html#38 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005u.html#44 POWER6 on zSeries?
http://www.garlic.com/~lynn/2006b.html#39 another blast from the past
http://www.garlic.com/~lynn/2006i.html#41 virtual memory
http://www.garlic.com/~lynn/2006l.html#2 virtual memory
http://www.garlic.com/~lynn/2006l.html#4 Google Architecture
http://www.garlic.com/~lynn/2006p.html#0 DASD Response Time (on antique 3390?)
http://www.garlic.com/~lynn/2006p.html#31 "25th Anniversary of the Personal Computer"
http://www.garlic.com/~lynn/2006r.html#4 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006s.html#41 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006s.html#42 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006t.html#15 more than 16mbyte support for 370
http://www.garlic.com/~lynn/2007f.html#44 Is computer history taught now?
http://www.garlic.com/~lynn/2007g.html#59 IBM to the PCM market(the sky is falling!!!the sky is falling!!)
http://www.garlic.com/~lynn/2007j.html#7 Newbie question on table design
http://www.garlic.com/~lynn/2007j.html#71 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007m.html#72 The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM
http://www.garlic.com/~lynn/2007n.html#20 The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM
http://www.garlic.com/~lynn/2007n.html#21 The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM
http://www.garlic.com/~lynn/2007o.html#10 IBM 8000 series

misc. past posts about relative system disk thruput declining over time
http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door
http://www.garlic.com/~lynn/94.html#43 Bloat, elegance, simplicity and other irrelevant concepts
http://www.garlic.com/~lynn/94.html#55 How Do the Old Mainframes Compare to Today's Micros?
http://www.garlic.com/~lynn/95.html#10 Virtual Memory (A return to the past?)
http://www.garlic.com/~lynn/98.html#46 The god old days(???)
http://www.garlic.com/~lynn/99.html#4 IBM S/360
http://www.garlic.com/~lynn/2001d.html#66 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001f.html#62 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001f.html#68 Q: Merced a flop or not?
http://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)
http://www.garlic.com/~lynn/2001l.html#61 MVS History (all parts)
http://www.garlic.com/~lynn/2001m.html#23 Smallest Storage Capacity Hard Disk?
http://www.garlic.com/~lynn/2002.html#5 index searching
http://www.garlic.com/~lynn/2002b.html#11 Microcode? (& index searching)
http://www.garlic.com/~lynn/2002b.html#20 index searching
http://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?
http://www.garlic.com/~lynn/2002e.html#9 What are some impressive page rates?
http://www.garlic.com/~lynn/2002i.html#16 AS/400 and MVS - clarification please
http://www.garlic.com/~lynn/2003i.html#33 Fix the shuttle or fly it unmanned
http://www.garlic.com/~lynn/2004n.html#22 Shipwrecks
http://www.garlic.com/~lynn/2004p.html#39 100% CPU is not always bad
http://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new?
http://www.garlic.com/~lynn/2005k.html#53 Performance and Capacity Planning
http://www.garlic.com/~lynn/2006m.html#32 Old Hashing Routine
http://www.garlic.com/~lynn/2006o.html#27 oops
http://www.garlic.com/~lynn/2006x.html#13 The Future of CPUs: What's After Multi-Core?

ACP/TPF

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: ACP/TPF
Newsgroups: comp.lang.asm370,alt.folklore.computers
Date: Mon, 03 Sep 2007 13:22:13 -0400
Paul Hinman <paul.hinman@shaw.ca> writes:
He was a gutless wonder who would never have made a suggestion to take a radical approach, he was part of the group that decided not to select IMS because our shop would never go to a virtual memory operating system (which it did, of course).

recent post mentioning vs/repack ... it was used by a number of corporate product groups helping migrate from real storage paradigm to virtual ... including exensively used by the group developing and supporting IMS.
http://www.garlic.com/~lynn/2007o.html#53 Virtual Storage implementation

vs/repack had been developed at the cambridge science center
http://www.garlic.com/~lynn/subtopic.html#545tech

which was also responsible for cp40, a virtual machine operating system built on a modified 360/40 with virtual memory hardware. cp40 was then morphed into cp67 with the availability of 360/67 with standard virtual memory support.

gml was also invented at the science center in 1969 ... precusor to sgml, html, xml, etc
http://www.garlic.com/~lynn/submain.html#sgml

and the technology for internal network was also developed at the science center
http://www.garlic.com/~lynn/subnetwork.html#internalnet

which was later used in the academic bitnet and earn networks
http://www.garlic.com/~lynn/subnetwork.html#bitnet

ACP/TPF

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: ACP/TPF
Newsgroups: comp.lang.asm370,alt.folklore.computers
Date: Mon, 03 Sep 2007 15:20:54 -0400
Paul Hinman <paul.hinman@shaw.ca> writes:
I heard all kinds of stories about how fast it was to IPL and bring up the applications compared to bringing up MVT/SVS/MVS and then once the OS was up one could begin starting the applications.

re:
http://www.garlic.com/~lynn/2007o.html#57 ACP/TPF

story about how fast cp67 could fail, automatically dump, and reboot/ipl (especially compared to multics)
http://www.multicians.org/thvv/360-67.html

this was one the features that aided in cp67 being used as commercial time-sharing system. an issue was having the system up and running 24x7 for (commercial) dial-in access. a lot of time off-shift operation would have very little useage ... making it difficult to recover costs thru useage charges. minimizing off-shift costs contributed to leaving the system up and running around the clock. auto-dump and reboot contributed to allowing offshift system "lights-out" operation. misc. posts mentioning cp67 (& vm370) commercial time-sharing operation
http://www.garlic.com/~lynn/submain.html#timeshare

besides auto reboot/restart .... cp67 also was using "prepare" CCW i/o command on terminal/dial-in lines. large numbers of 360s were leased and montly leased charges were based on processor useage "meter". The useage "meter" would run whenever the processor was executing and/or whenever there was active i/o. the "prepare" CCW would suspend operation on the line (halting the "meter" if nothing else was running) until bits were moving on line(s). "prepare" CCW allowed system to be up and available, but the useage meter wouldn't be running when there wasn't actually anything going on.

ACP/TPF

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: ACP/TPF
Newsgroups: comp.lang.asm370,alt.folklore.computers
Date: Tue, 04 Sep 2007 12:41:19 -0400
Paul Hinman <paul.hinman@shaw.ca> writes:
He was a gutless wonder who would never have made a suggestion to take a radical approach, he was part of the group that decided not to select IMS because our shop would never go to a virtual memory operating system (which it did, of course).

past posts in this thread:
http://www.garlic.com/~lynn/2007o.html#57 ACP/TPF
http://www.garlic.com/~lynn/2007o.html#58 ACP/TPF

for a little topic drift ... my wife had been con'ed into going to POK to be in charge of loosely-coupled architecture; while there she originated peer-coupled shared data architecture, which didn't see a lot of takeup until sysplex, except for ims hot-standby
http://www.garlic.com/~lynn/submain.html#shareddata

for other topic drift ... old email mentioning IMS
http://www.garlic.com/~lynn/2007.html#email801016

later my wife served short stint as chief architect for amadeus ... misc. past posts mentioning amadeus
http://www.garlic.com/~lynn/2001g.html#49 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001g.html#50 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001h.html#76 Other oddball IBM System 360's ?
http://www.garlic.com/~lynn/2003d.html#67 unix
http://www.garlic.com/~lynn/2003n.html#47 What makes a mainframe a mainframe?
http://www.garlic.com/~lynn/2004b.html#6 Mainframe not a good architecture for interactive workloads
http://www.garlic.com/~lynn/2004b.html#7 Mainframe not a good architecture for interactive workloads
http://www.garlic.com/~lynn/2004m.html#27 Shipwrecks
http://www.garlic.com/~lynn/2004o.html#23 Demo: Things in Hierarchies (w/o RM/SQL)
http://www.garlic.com/~lynn/2004o.html#29 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005f.html#22 System/360; Hardwired vs. Microcoded
http://www.garlic.com/~lynn/2005p.html#8 EBCDIC to 6-bit and back
http://www.garlic.com/~lynn/2006o.html#4 How Many 360/195s and 370/195s were shipped?
http://www.garlic.com/~lynn/2006r.html#9 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006y.html#14 Why so little parallelism?
http://www.garlic.com/~lynn/2007d.html#19 Pennsylvania Railroad ticket fax service
http://www.garlic.com/~lynn/2007e.html#52 US Air computers delay psgrs
http://www.garlic.com/~lynn/2007h.html#12 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007k.html#72 The top 10 dead (or dying) computer skills

Are Relational Databases Obsolete?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Are Relational Databases Obsolete?
Newsgroups: alt.folklore.computers
Date: Thu, 06 Sep 2007 21:35:54 -0400
Are Relational Databases Obsolete?
http://developers.slashdot.org/developers/07/09/06/1527258.shtml
Relational database pioneer says technology is obsolete
http://www.computerworld.com/action/article.do?command=printArticleBasic&articleId=9034619

posts mentioning original relational/sql implementation
http://www.garlic.com/~lynn/submain.html#systemr

and other technology
http://www.garlic.com/~lynn/index.html

(Newbie question)How does the modern high-end processor been designed?

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: (Newbie question)How does the modern high-end processor been designed?
Date: Sat, 08 Sep 2007 11:51:35 -0400
Newsgroups: comp.arch
Del Cecchi <cecchinospam@us.ibm.com> writes:
Perhaps you could get some general background and ask more specific questions.

Some circuits are designed and layed out by hand. Others are from libraries or created parametrically. Some netlists are designed by hand and others are synthesized. Place and route is mostly done by tool.


somewhat after our first retirement ... there was a period where the corporation was moving to COTS tools ... some of which involved transferring some of the internal tools to commerical tool vendor.

one of the internal tools being transferred was a layout/place/route application which was a 50-60k line program implemented in vs/pascal .... and had to be ported to much more vanilla pascal platform ... and we got a contract to do the port.

the problem was that it appeared that vs/pascal was one of the few pascal implementations that had been used for large production projects .... it was not clear that some of the other pascal applications had ever been used for anything other than academic programming classes (at one point it appeared that it would be much easier to port from vs/pascal to some commercial c++ implementation than to any other pascal implementation).

Horrid thought about Politics, President Bush, and Democrats

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Horrid thought about Politics, President Bush, and Democrats   ...
Newsgroups: alt.folklore.computers
Date: Sat, 08 Sep 2007 13:09:14 -0400
greymaus writes:
Considering, what a lot of people don't think of, that insurance companies calculate the chance of something happening, what it will cost to fix, divide, add in a little profit (well run ones will live on the float), and charge. Nobody is going to insure a case like lowlying New Orleans..

i think there was some statistic that every year, half of the national emergency/disaster flood funds went to the same areas in Mississippi ... despite the fact there was legislation passed in congress in the 80s that national disaster/emergency flood funds could no longer be used for repeated payouts year after year to the same locations (i.e. something that repeatedly happens every year becomes more and more difficult to classify as emergency). i think that somebody once made the statement that it actually was a method of national subsidy to the state of mississippi (although if that were the case, one might claim that the subsidy might be better distributed directly to places like educational institutions in the state of mississippi).

old thread
http://www.garlic.com/~lynn/2001.html#41 Where do the filesystem and RAID system belong?
http://www.garlic.com/~lynn/2001.html#42 Where do the filesystem and RAID system belong?

'pipe <' doesn't work in Windows xp? I get an error saying its not a command

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 'pipe <' doesn't work in Windows xp? I get an error saying its not a command...
Newsgroups: comp.lang.rexx,alt.folklore.computers
Date: Sat, 08 Sep 2007 14:26:04 -0400
"Gil Barmwater" <gil_b@bellsouth.net> writes:
Just a point of clarification: Rexx was NOT modeled on the DOS batch language. Rexx predates (1979) the first release of DOS (1981). As TRL2 (The REXX Language, A Practical Approach to Programming, Second Edition) points out, it "... borrows from many earlier languages; PL/1, Algol, and even APL..." but it "...was designed as an entirely new language...". I'd recommend the OP get a copy of the book if he wants to understand the philosophy behind Rexx's design. ISBN 0-13-780651-5

a big part of it was to be enhancement of cms exec (& exec2) processing.

an old email with early rex reference (rex presentation at conference early 1980; name was changed to rexx as part of first commercial release)
http://www.garlic.com/~lynn/2005f.html#email800121
in this post
http://www.garlic.com/~lynn/2005f.html#34 [Lit.] Buffer overruns

Toshiba Boosts Hard Drive Density By 50%

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Toshiba Boosts Hard Drive Density By 50%
Newsgroups: alt.folklore.computers
Date: Sun, 09 Sep 2007 12:27:08 -0400
Toshiba Boosts Hard Drive Density By 50%
http://hardware.slashdot.org/hardware/07/09/08/1938203.shtml
Toshiba Leads Industry in Bringing Discrete Track Recording Technology to Prototype of 120GB Hard Disk Drive
http://www.newswire.ca/en/releases/archive/September2007/06/c5819.html

from above:
The new prototype HDD is a 1.8-inch PMR HDD. Toshiba's latest 1.8-inch HDD in the market offers a single platter capacity of 80GB; application of DTR technology boosts platter capacity to 120GB, and takes the recording density to 516 megabits per square millimeter (333gigabits per square inch). A servo pattern for tracking control is also formed on the disk.

... snip ...

old email about similar but different discussion but with regard to multiple data tracks (16+2) per servo track (work with the person responsible for 801/risc technology) ... now vertical recording now comingly referred to as perpendicular recording
http://www.garlic.com/~lynn/2006s.html#email871122
http://www.garlic.com/~lynn/2006s.html#email871230
in this post
http://www.garlic.com/~lynn/2006s.html#30 Why magnetic drums was/are worse than disks ?

other references here
http://www.garlic.com/~lynn/2007k.html#21 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007k.html#38 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007l.html#52 Drums: Memory or Peripheral?
http://www.garlic.com/~lynn/2007m.html#23 Bulkiest removable storage media?

... the reference from 20years ago talks about gigabyte on 5inch platter and gigabit/sec transfer rate.

The use of "script" for program

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The use of "script" for program
Date: Mon, 10 Sep 2007 09:07:24 -0400
Newsgroups: alt.folklore.computers
et472@FreeNet.Carleton.CA (Michael Black) writes:
But that brings us back to the original question, which was something about when did interpreted languages become scripted languages.

in cp67/cms world the files that batched sequences of interactive commands, were called EXECs.

i have some vague recollection of "scripting" starting to be used for command files in association with terminal emulation ... as opposed to the cms SCRIPT command which started out with runoff-like dot document formating ... but after markup language was invented in 1969 at the science center,
http://www.garlic.com/~lynn/subtopic.html#545tech

tag command formating was also added
http://www.garlic.com/~lynn/submain.html#sgml

in the late 70s, "scripting" appeared as parasite "story" files (before PCs doing terminal emulation and terminal emulation scripting support). misc. past posts mentioning general topic of terminal emuatlion
http://www.garlic.com/~lynn/subnetwork.html#emulation

in the early-to-mid 70s, there were (interactive workload) benchmarking applications that had a terminal emulation driver which required emulated terminal input/entry sequences ... but i don't remember whether these were referred to as scripts.

in any case, there was very small conceptual jump from terminal emulation scripts to also referring to any sequence of emulated input to be "scripts"

misc. past posts mentioning parasite/story
http://www.garlic.com/~lynn/2001k.html#35 Newbie TOPS-10 7.03 question
http://www.garlic.com/~lynn/2001k.html#36 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)
http://www.garlic.com/~lynn/2007.html#23 How to write a full-screen Rexx debugger?

The use of "script" for program

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The use of "script" for program
Date: Mon, 10 Sep 2007 10:33:56 -0400
Newsgroups: alt.folklore.computers
re:
http://www.garlic.com/~lynn/2007o.html#65 The use of "script" for program

earliest old email (that I could find) referring to terminal emulation scripting using the term "script"

Date: 04/04/83 21:17:37
From: wheeler

are automated terminal scripts in-place &/or planned for PCTERM???? It sure would be nice to invoke a PCTERM script to automatically get me thru the PVM menu screen and logging on.


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

PCTERM was an internally developed ibm/pc terminal emulation program. in conjunction with application on mainframe host, it had the capability of emulating local 3270 terminals over dial-up ascii terminal lines.

my reference to requesting terminal scripting capability for PCTERM implies that the term was in common use prior the date of the email.

misc. past posts mentioning PCTERM:
http://www.garlic.com/~lynn/2003n.html#7 3270 terminal keyboard??
http://www.garlic.com/~lynn/2003p.html#44 Mainframe Emulation Solutions
http://www.garlic.com/~lynn/2006y.html#0 Why so little parallelism?

1401 simulator for OS/360

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 1401 simulator for OS/360
Date: Mon, 10 Sep 2007 16:36:36 -0400
Newsgroups: bit.listserv.ibm-main
David Andrews wrote:
Yeppers. Google "ivan sutherland clock" and "I feel lucky". Sun Research has several circa-2001 papers on tap that discuss Sutherland's asynchronous design methodology.

los gatos vlsi lab did the LSM (originally the los gatos simulation machine) which had a clock that allowed simulation of digital chips with analog circuits (like, the, then new generation of disk thin-film r/w heads) and digital chips with asynchronous operation.

later there were writeups on ysm (yorktown simulation machine), but i don't know of any that was actually built. then endicott turned out EVE (endicott verification engine) .... ysm and eve didn't have clock/timing facilities ... they effectively assumed a global synchronous clock (you didn't need a clock to simulate global synchronous clock, but need a clock to simulate digital circuit asynchronous operation).

besides getting to play disk engineer
http://www.garlic.com/~lynn/subtopic.html#disk

and vlsi design tools in the los gatos lab ... i also got to play high-speed network with my hsdt (high-speed data transport) project with several internal high-speed links.
http://www.garlic.com/~lynn/subnetwork.html#hsdt

There was even claim that HSDT-links contributed to bringing in the rios/rs6000 chip set a year early ... i.e. austin using hsdt to ship chip designs to the west coast ... both to the LSM in bldg. 29 and the EVE that GPD had in bldg. 86.

for external publication, lsm was "renamed" logic state machine, misc. past posts mentioning lsm, ysm, and eve.
http://www.garlic.com/~lynn/2002d.html#3 Chip Emulators - was How does a chip get designed?
http://www.garlic.com/~lynn/2002g.html#55 Multics hardware (was Re: "Soul of a New Machine" Computer?)
http://www.garlic.com/~lynn/2002j.html#26 LSM, YSE, & EVE
http://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation
http://www.garlic.com/~lynn/2003.html#31 asynchronous CPUs
http://www.garlic.com/~lynn/2003k.html#3 Ping: Anne & Lynn Wheeler
http://www.garlic.com/~lynn/2003k.html#14 Ping: Anne & Lynn Wheeler
http://www.garlic.com/~lynn/2003o.html#38 When nerds were nerds
http://www.garlic.com/~lynn/2004j.html#16 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2004o.html#25 CKD Disks?
http://www.garlic.com/~lynn/2004o.html#65 360 longevity, was RISCs too close to hardware?
http://www.garlic.com/~lynn/2005c.html#6 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005d.html#33 Thou shalt have no other gods before the ANSI C standard
http://www.garlic.com/~lynn/2005q.html#17 Ethernet, Aloha and CSMA/CD -
http://www.garlic.com/~lynn/2006.html#29 IBM microwave application--early data communications
http://www.garlic.com/~lynn/2006r.html#11 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006s.html#20 real core
http://www.garlic.com/~lynn/2007f.html#73 Is computer history taught now?
http://www.garlic.com/~lynn/2007h.html#61 Fast and Safe C Strings: User friendly C macros to Declare and use C Strings
http://www.garlic.com/~lynn/2007l.html#53 Drums: Memory or Peripheral?
http://www.garlic.com/~lynn/2007m.html#58 Is Parallel Programming Just Too Hard?

CA to IBM TCP Conversion

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CA to IBM TCP Conversion
Date: Tue, 11 Sep 2007 12:02:38 -0400
Newsgroups: alt.folklore.computers,bit.listserv.ibm-main
Chris Mason wrote:
Robert

I thought I'd dig further into this IUCV point and I found a reference in the IP Configuration Guide. It appears that IUCV, VMCF and TNF "stuff" is still available, you just don't necessarily need it. It would appear to have become an *optional* bit of preparation for the use of the Communications Server (CS) IP component from being *required* as it was when I used to teach TCP/IP for MVS.

It is described in the CS IP Configuration Guide under "Chapter 2. Configuration overview", "Required steps before starting TCP/IP" as "Step 3: Configure VMCF and TNF" on page 111 of the z/OS 1.8 manual. It appears that the section headers are logically incorrect since, as far as I can tell, it really is an *optional* step and depends on whether or not the Pascal API is used or not. The clearest indication that this step really is optional is "... therefore, some installations will require setting up VMCF and TNF." at the end of the first paragraph.

I then found Dana Mitchell's post where he/she said something of the same as above.

Chris Mason


the original tcp/ip implementation was done in vs/pascal on vm370 (20 yrs ago) ... but there were some number of implementation bottlenecks .... such that it got about 44kbyte/sec aggregate thruput consuming a 3090 processor. i then did rfc1044 support for the product and in some tuning tests at cray research (between 4341 clone and a cray machine) was getting 4341 channel media speed thruput using only a modest amount of the 4341 clone.
http://www.garlic.com/~lynn/subnetwork.html#1044

for some topic drift, recent post mentioning vs/pascal
http://www.garlic.com/~lynn/2007o.html#61 (Newbie question)How does the modern high-end processor been designed?

which is slightly related to topic in this newsgroup since the los gatos vlsi tools group was responsible for the 370 pascal implementation as well as the "LSM"
http://www.garlic.com/~lynn/2007o.html#67 1401 simulator for OS/360

somewhat drifting back to the topic, a port of the implementation was then done for mvs ... by doing a (vm370) vmcf/iucv emulator for mvs systems.

for other background ... internally there was something called spm that was originally implemented on cp67 (precursor to vm370 that ran on 360/67s) which was a superset of the later vmcf and iucv implementations. there was somewhat internal dissension leading up to the initial vmcf release ... since spm had been around for much longer period and had so much more function. Later, iucv was released to cover some additional function (also covered by spm) that wasn't handled by vmcf.

some old email with spm reference
http://www.garlic.com/~lynn/2006w.html#email750430
http://www.garlic.com/~lynn/2006k.html#email851017

misc. old posts mentioning spm:
http://www.garlic.com/~lynn/2002d.html#31 2 questions: diag 68 and calling convention
http://www.garlic.com/~lynn/2004m.html#20 Whatever happened to IBM's VM PC software?
http://www.garlic.com/~lynn/2005m.html#45 Digital ID
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

ServerPac Installs and dataset allocations

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com (Anne & Lynn Wheeler)
Newsgroups: bit.listserv.ibm-main
Subject: Re: ServerPac Installs and dataset allocations
Date: 11 Sep 2007 12:45:32 -0700
Ted MacNEIL wrote:
> I put the heavily hit loadlibs such as SYS1.LINKLIB on one side of
> the VTOC, and the ISPF libraries on the other side of the VTOC.
> With todays heavily cached dasd, that probably will buy you very
> little anymore.

Very little. Especially, since it's been over 15 years since IBM stopped recommending placing the VTOC (VTOCIX, VVDS, & Catalogue [if there is one]) elsewhere than at the beginning of the pack.


for os/360 releases 11 & 14 system builds .... i had carefully reodered stage-2 sysgen to achieve optimal placement ... not only of datasets but also members within pds. i had given presentations at share (on the results of both the customized release 11 and 14 system builds) ... that for the university workload, i could achieve nearly three times increased thruput. i had also asked for being able to specify vtoc location ... which showed up in release 15/16 (release 15 slipped and there was a combined release 15/16).

one of the problems was applying normal system maintenance ... replacing members in pds libraries like sys1.linklib could detrimentally affect the carefully ordering .... and over a period of six months, thruput could degrade by a third or more (and might require a new "build" of critical pds libraries).

reference to old presentation that i had made a fall68 share meeting in boston (this particular presentation also included some measurements after i had rewritten several critical sections of the cp67 kernel):
http://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14
http://www.garlic.com/~lynn/94.html#20 CP/67 & OS MFT14

however, going into the mid-70s, it was becoming apparent that overall system thruput (processor and memory) was increasing much faster than disk technology thruput was increasing. as a result there was starting to be more and more reliance on mechanisms (like more use of various kinds of caching technology) to compensate for the relative system degradation of disk thruput.

at one point, i had made the observation that relative system disk thruput had degrading by a factor of ten times over a period of years. this upset some of the people in the disk division ... and the disk division performance group was assigned to refute the observation. after several weeks, they came back and effectively said that i had slightly understated the amount of relative system thruput degradation (i.e. disks were getting faster, but overall systems were getting also getting faster, much faster than disks were getting faster). in any case, the work by the disk division performance group eventually turned into a share presentation ... not on how slow disks are ... but on how to organize data on disk to improve overall system thruput.

as caching technologies became more and more wide used ... nearly all of the work on careful ordering of "highly used" disk records (that i had done as undergraduate in the 60s) was obsoleted since such high-used records would now be found in the electronic caches.

some number of old posts mentioning gpd finding that i had slightly understated the degree of disk technology relative system thruput degradation over a period of years
http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door
http://www.garlic.com/~lynn/94.html#43 Bloat, elegance, simplicity and other irrelevant concepts
http://www.garlic.com/~lynn/94.html#55 How Do the Old Mainframes Compare to Today's Micros?
http://www.garlic.com/~lynn/95.html#10 Virtual Memory (A return to the past?)
http://www.garlic.com/~lynn/98.html#46 The god old days(???)
http://www.garlic.com/~lynn/99.html#4 IBM S/360
http://www.garlic.com/~lynn/2001d.html#66 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001f.html#62 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001f.html#68 Q: Merced a flop or not?
http://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)
http://www.garlic.com/~lynn/2001l.html#61 MVS History (all parts)
http://www.garlic.com/~lynn/2001m.html#23 Smallest Storage Capacity Hard Disk?
http://www.garlic.com/~lynn/2002.html#5 index searching
http://www.garlic.com/~lynn/2002b.html#11 Microcode? (& index searching)
http://www.garlic.com/~lynn/2002b.html#20 index searching
http://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?
http://www.garlic.com/~lynn/2002e.html#9 What are some impressive page rates?
http://www.garlic.com/~lynn/2002i.html#16 AS/400 and MVS - clarification please
http://www.garlic.com/~lynn/2003i.html#33 Fix the shuttle or fly it unmanned
http://www.garlic.com/~lynn/2004n.html#22 Shipwrecks
http://www.garlic.com/~lynn/2004p.html#39 100% CPU is not always bad
http://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new?
http://www.garlic.com/~lynn/2005k.html#53 Performance and Capacity Planning
http://www.garlic.com/~lynn/2006m.html#32 Old Hashing Routine
http://www.garlic.com/~lynn/2006x.html#13 The Future of CPUs: What's After Multi-Core?

The name "shell"

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The name "shell"
Date: Wed, 12 Sep 2007 08:57:17 -0400
Newsgroups: alt.folklore.computers,alt.os.multics
jmfbahciv writes:
It didn't matter what the word size was; DEC called that software the montior.

a lot of the os/360 "monitors" were implementations that attempted to compensate for difficulties with os/360. our university tried some number of monitors before installing watfor ... i.e. os/360 jobcontrol/scheduling/etc for "3-step" fortran, compile, linkedit, and go ... could be 30 seconds elapsed time ... with less than a second actually devoted to (student fortran) compile & execution. The monitors attempted to special case the job-control/allocation function for the student-job scenario eliminating nearly all of the generalized overhead. the university had been running student fortran programs on 709 monitor taking on the order of second or so elapsed time. initial moving from 709 to 360/65 (actually 360/67 that ran in non-virtual memory 360/65 mode) significantly degraded student job through-put.

independent of the os/360 flavor of monitors ... science center
http://www.garlic.com/~lynn/subtopic.html#545tech

(aka 4th flr, 545 tech sq, multics was on 5th flr) did cms .... cambridge monitor system. cms originally was a single-user interactive operating system that could run on dedicated 360 (started out running on 360/40) ... or in a virtual machine. initial virtual machine system was cp40 that cambridge had implemented on 360/40 modified with special virtual memory hardware. cp40 morphed into cp67 when standard virtual memory hardware became available with 360/67.

later, with the morph of cp67 to vm370, the cambridge monitor system was renamed the conversational monitor system ... and the ability for cms to boot/ipl on real machine was crippled.

The use of "script" for program

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The use of "script" for program
Date: Thu, 13 Sep 2007 06:44:20 -0400
Newsgroups: alt.folklore.computers
kkt <kkt@zipcon.net> writes:
I'm pretty impressed that the editors went through the RFCs for early uses of computing terms.

I agree with others here that the definition isn't quite right as far as not having to be compiled. Often the case, but not always.

("Script kiddy" has also made it into the OED, you'll be happy to know.)


for a little topic drift, the author of rex(x) did an assignment at oxford university press in the mid-80s

wiki entry
https://en.wikipedia.org/wiki/Oxford_English_Dictionary

.... from above ...
And so the New Oxford English Dictionary (NOED) project began. More than 120 keyboarders of International Computaprint Corporation in Tampa, Florida, and Fort Washington, Pennsylvania, USA, started keying in over 350,000,000 characters, their work checked by 55 proof-readers in England. But, retyping the text alone was not sufficient; all the information represented by the complex typography of the original dictionary had to be retained, which was done by marking up the content in SGML; and a specialized search engine and display software were also needed to access it. Under a 1985 agreement, some of this software work was done at the University of Waterloo, Canada, at the Centre for the New Oxford English Dictionary, led by F.W. Tompa and Gaston Gonnet; this search technology went on to be the basis for Open Text Corporation. Computer hardware, database and other software, development managers, and programmers for the project were donated by the British subsidiary of IBM; the colour syntax-directed editor for the project, LEXX, was written by Mike Cowlishaw of IBM. The University of Waterloo, in Canada, volunteered to design the database. A. Walton Litz, an English professor at Princeton University who served on the Oxford University Press advisory council, told Paul Gray for TIME (March 27, 1989), "I've never been associated with a project, I've never even heard of a project, that was so incredibly complicated and that met every deadline."

.... snip ...

.... footnote from old email:
Date: 22 Aug 1985, 17:25:19
To: wheeler
....
On assignment at Oxford University Press, back on Wednesdays.


.... snip ...

(gml) markup language was invented at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

in 1969 and then went on to become an iso standard sgml
http://www.garlic.com/~lynn/submain.html#sgml

FICON tape drive?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@ibm-main.lst (Anne & Lynn Wheeler)
Subject: Re: FICON tape drive?
Newsgroups: bit.listserv.ibm-main
Date: 13 Sep 2007 06:42:11 -0700
George McAliley wrote:
All IBM 3490's on mainframes were either Block MPX channel (bus/tag) or ESCON. The STK 9490's on mainframe were also ESCON though they did have a SCSI interface for distributed system attachment. The IBM Magstar (3590) series were natively FICON and ESCON capable depending on how you configure the drive/controller. The newer 3592's are also either ESCON or FICON though they are really too fast for ESCON. All the Magstar drives have standalone (non_ATL) configurations but are now usually installed in ATL's or VTL's in today's world.

a recent escon, sla, fcs, ficon and eckd x-over discussion from comp.arch newsgroup
http://www.garlic.com/~lynn/2007o.html#54 mainframe performance, was Is a RISC chip more expensive?

and additional drift, other posts in the thread:
http://www.garlic.com/~lynn/2007o.html#42 mainframe performance, was Is a RISC chip more expensive?
http://www.garlic.com/~lynn/2007o.html#55 mainframe performance, was Is a RISC chip more expensive?

.. escon had been fiber technology that had knocking around pok from the 70s. my wife had been con'ed into going to pok to be in charge of loosely-coupled architecture where she created peer-coupled shared data architecture
http://www.garlic.com/~lynn/submain.html#shareddata

which didn't see a whole lot of take-up until sysplex ... except for ims hot-standby work.

she also had significant battles with the communication group over not using sna for peer-coupled operation. eventually there supposedly was a (temporary) truce where sna had to be used for anything transiting the walls of the glasshouse but non-sna could be used within the walls of the glasshouse. this sort of came to a test with ctca enhancement; trotter/3088 where she pushed hard for being able to have full-duplex operation ... as improvement over standard ctca/channel half-duplex operation (which didn't make it out the door).

san jose research did do a vm/4341 cluster prototype using enhanced 3088 peer-coupled operation ... but when it came to make it available to customers, they were required to use sna for the implementation. a trivial example of the difference was the cluster synchronization protocol ... which started out being done in subsecond elapsed time. it was severely crippled by being forced to regress to a sna implementation which increased the cluster synchronization protocol elapsed time to nearly a minute.

all of this contributed to her not lasting very long as pok's loosely-coupled architect. of course, part of her problem was that she had earlier co-authored AWP39, peer-to-peer networking architecture in the early days of SNA ... which they possibly viewed as a threat. SNA architecture was VTAM ... not a networking architecture at all, but a (dumb) terminal communication control infrastructure that could handle massive numbers of terminals (or at least initially up to 64k). for other random trivia, appn was AWP164

misc. past posts mentioning AWP39
http://www.garlic.com/~lynn/2004n.html#38 RS/6000 in Sysplex Environment
http://www.garlic.com/~lynn/2004p.html#31 IBM 3705 and UC.5
http://www.garlic.com/~lynn/2005p.html#8 EBCDIC to 6-bit and back
http://www.garlic.com/~lynn/2005p.html#15 DUMP Datasets and SMS
http://www.garlic.com/~lynn/2005p.html#17 DUMP Datasets and SMS
http://www.garlic.com/~lynn/2005q.html#27 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005u.html#23 Channel Distances
http://www.garlic.com/~lynn/2006h.html#52 Need Help defining an AS400 with an IP address to the mainframe
http://www.garlic.com/~lynn/2006j.html#31 virtual memory
http://www.garlic.com/~lynn/2006k.html#9 Arpa address
http://www.garlic.com/~lynn/2006k.html#21 Sending CONSOLE/SYSLOG To Off-Mainframe Server
http://www.garlic.com/~lynn/2006l.html#4 Google Architecture
http://www.garlic.com/~lynn/2006l.html#45 Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
http://www.garlic.com/~lynn/2006o.html#62 Greatest Software, System R
http://www.garlic.com/~lynn/2006r.html#4 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006r.html#9 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006t.html#36 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006u.html#28 Assembler question
http://www.garlic.com/~lynn/2006u.html#55 What's a mainframe?
http://www.garlic.com/~lynn/2007b.html#9 Mainframe vs. "Server" (Was Just another example of mainframe
http://www.garlic.com/~lynn/2007b.html#48 6400 impact printer
http://www.garlic.com/~lynn/2007d.html#55 Is computer history taugh now?
http://www.garlic.com/~lynn/2007h.html#35 sizeof() was: The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007h.html#39 sizeof() was: The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007l.html#62 Friday musings on the future of 3270 applications

The name "shell"

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The name "shell"
Newsgroups: alt.folklore.computers,alt.os.multics
Date: Thu, 13 Sep 2007 11:34:19 -0400
jmfbahciv writes:
That's was the reason for so many -11 and -8 monitors. It was difficult to be a general purpose system with so few resources. Each OS had its own "specialty". You can (or used to be able to) see this specialty bias in Unix. One variation did disk I/O very well; another variation did networking very well.

re:
http://www.garlic.com/~lynn/2007o.html#70 The name "shell"

the 709/7090 monitors were directly booted/ipled.

the os/360 "monitors" ran under os/360 and created their own specialized subsystem environment (running under os/360). part of the issue was that os/360 resource allocation tended to be quite heavyweight. the os/360 "subsystem" monitors would be brought up and do large block allocations ... and then would create a tailored customized environment (typically with much lighter weight resource sub-allocation)

os/360 was scp ... or system control program, the initial boot/ipl image was the "nucleus" (kernel by any other name).

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

had done cp/40 (control program/40) for a custom modifed 360/40 with virtual memory. this morphed into cp/67 (control program/67) when virtual memory (with 360/67) became generally available.

some of the os/360 subsystem monitors would acquire privilege execution state when they ran ... but others would run in normal application execution state ... although there tended to be an increasing use of 360 key-based storage protection ... this was still all a single (real storage) address space (as opposed to cp/40 and cp/67 kernels which isolated themselves from virtual machine and/or application execution using virtual address spaces).

some of the subsystems became integral part of os/360 and later created quite a bit of problem in the migration to multiple virtual address spaces. initial migration of os/360 to virtual storage ... defined a single 16mbyte virtual address space ... with minimal necessary support to handle paging operations (but tended to emulate the operation as if os/360 was running in a 16mbyte real machine). this was os/vs2 "svs". the change-over to os/vs2 "mvs" allocated a separate 16mbyte virtual address space for each application ... but the "mvs" kernel/nucleus image occupied 8mbytes of each virtual address space (in effect it was left over real storage paradigm that made extensive use of pointer-passing paradigm APIs).

the complication was that the "subsystems" migrated into their own virtual address space ... and things got kind of sticky when other applications (running in their own virtual address space) attempted to use a pointer-passing subsystem API (since the pointer was to parameter list in the application virtual address space and not in the subystem virtual address space).

a couple recent posts discussing the migration of the single (real) address space pointer passing API into multiple independent (virtual) address space environment
http://www.garlic.com/~lynn/2007g.html#59 IBM to the PCM market(the sky is falling!!!the sky is falling!!)
http://www.garlic.com/~lynn/2007k.html#27 user level TCP implementation
http://www.garlic.com/~lynn/2007o.html#10 IBM 8000 series

Horrid thought about Politics, President Bush, and Democrats

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Horrid thought about Politics, President Bush, and Democrats   ...
Newsgroups: alt.folklore.computers
Date: Thu, 13 Sep 2007 21:08:29 -0400
in the past, i've run across a claim that babies born to drug addicted mothers have so many medical problems ... that the individual will cost society an extra $5m in medical services over their (typically, shortened) lifetime. a million such babies would represent a $5trillion extra cost to society (inflation in the medical sector may have doubled that amount)

quick search engine turns up article from 1991
http://money.cnn.com/magazines/fortune/fortune_archive/1991/07/01/75211/index.htm

mentions 375,000 such babies being born every year. that would make the incremental expense for society on par with what the comptroller general has been quoting for some other programs ... posts from past year or so, mentioning some of the comptroller general pet peeves (including possibly somewhat facetious reference to believing that there hasn't been a member of congress for more than 50 yrs capable of even simple middle school arithmatic)
http://www.garlic.com/~lynn/2006f.html#41 The Pankian Metaphor
http://www.garlic.com/~lynn/2006f.html#44 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#9 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#14 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#27 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#2 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#3 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#4 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#17 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#19 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#33 The Pankian Metaphor
http://www.garlic.com/~lynn/2006o.html#61 Health Care
http://www.garlic.com/~lynn/2006p.html#17 Health Care
http://www.garlic.com/~lynn/2006r.html#0 Cray-1 Anniversary Event - September 21st
http://www.garlic.com/~lynn/2006t.html#26 Universal constants
http://www.garlic.com/~lynn/2007j.html#20 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#91 IBM Unionization
http://www.garlic.com/~lynn/2007k.html#19 Another "migration" from the mainframe

The name "shell"

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The name "shell"
Newsgroups: alt.folklore.computers,alt.os.multics
Date: Fri, 14 Sep 2007 08:55:35 -0400
jmfbahciv writes:
TOPS-10 maintained a user page map page and its own exec page map page and never mixed the two up. When you started designing exceptions to the rule, you end up have a design that is 99.9% exceptions to the rule. I think this is a truth in all layers of computing. However, I haven't thought enough about this one to make it a declaration.

re:
http://www.garlic.com/~lynn/2007o.html#70 The name "shell"
http://www.garlic.com/~lynn/2007o.html#73 The name "shell"

what they migrated to, was additional hardware addressing modes where (typically semi-privileged code) could address different virtual address spaces. this started out requiring interrupt thru the kernel which would fiddle the (multiple) virtual address space control registers ... as to what was "home" virtual address space and what was the "calling application" virtual address space (supporting pointer passing api paradigm, allowing subsystem to reach into the calling applicaton's virtual address space).

they then added a program call (and program return) instruction that referenced a (protected) hardware table which described the rules for fiddling the virtual address control registers for different called subsystems. this eliminated API-call needing to pass thru the kernel to have it done in software. this promoted even being able to migrate various kinds of library code into separate virtual address space.

multiple virtual address space addressing has been leveraged for other functions ... like a virtual address space dedicated for effectively file data. normal application can be setup to have "home" virtual address space ... and a separate virtual address space dedicated to (memory mapped) file data.

they also started doing special case TLB implementations for the part about common system pages that appeared in every virtual address space (the initial hack for transition from os/vs2 svs to os/vs2 mvs). default hardware table lookaside buffer (supporting virtual address to real address mapping) are virtual address space associative i.e. and found frequently half the TLB entries were "duplicates" (the same high use system page that appeared in every virtual address space might have large number of different TLB entries). The other TLB performance issue was since a specific virtual address could only map to a small subset of TLB entries ... the "same" common virtual page entry was constantly thrashing the limited TLB entries. A "common" flag in the virtual memory hardware tables would indicate to the hardware TLB to treat the virtual page as part of a special case, global, (effectively) system virtual address space (independent of what actual virtual address space it actually appeared in).

Graduate Enrollment in 2005

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Graduate Enrollment in 2005
Newsgroups: alt.folklore.computers
Date: Fri, 14 Sep 2007 19:23:57 -0400
re:
http://www.cra.org/wp/index.php?p=120

above includes graph showing total of 9000 first-time, full-time graudate CS enrollement in 2001, 6,500 foreign, 2,500 US. for 2005, total had dropped to a little over 8,000, 4,500 foreign, and a little over 3,500 US.

past posts mentioning that much of the internet boom/bubble was because of the availability of foreign skills (since there weren't nearly enuf "native" individuals to fill the need).
http://www.garlic.com/~lynn/2001l.html#50 What makes a mainframe?
http://www.garlic.com/~lynn/2002e.html#1 More on Aging Legacy Workforce
http://www.garlic.com/~lynn/2002k.html#41 How will current AI/robot stories play when AIs are real?
http://www.garlic.com/~lynn/2003g.html#48 Lisp Machines
http://www.garlic.com/~lynn/2003i.html#28 Offshore IT
http://www.garlic.com/~lynn/2003i.html#45 Offshore IT
http://www.garlic.com/~lynn/2003p.html#33 [IBM-MAIN] NY Times editorial on white collar jobs going
http://www.garlic.com/~lynn/2004b.html#2 The SOB that helped IT jobs move to India is dead!
http://www.garlic.com/~lynn/2004f.html#39 Who said "The Mainframe is dead"?
http://www.garlic.com/~lynn/2004l.html#14 Xah Lee's Unixism
http://www.garlic.com/~lynn/2005.html#20 I told you ... everybody is going to Dalian,China
http://www.garlic.com/~lynn/2006g.html#21 Taxes
http://www.garlic.com/~lynn/2006h.html#37 Taxes
http://www.garlic.com/~lynn/2006h.html#38 Taxes
http://www.garlic.com/~lynn/2007j.html#51 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#57 IBM Unionization
http://www.garlic.com/~lynn/2007l.html#5 IBM Unionization



...re>
previous, next, index - home