List of Archived Posts

2008 Newsgroup Postings (02/23 - 03/06)

The Economic Impact of Stimulating Broadband Nationally
Migration from Mainframe to othre platforms - the othe bell?
How many overwrites for secure erase?
The hands-free way to steal a credit card
Migration from Mainframe to othre platforms - the othe bell?
1998 vs. 2008: A Tech Retrospective
1998 vs. 2008: A Tech Retrospective
was: 1975 movie "Three Days of the Condor" tech stuff
MAINFRAME Training with IBM Certification and JOB GUARANTEE
The Economic Impact of Stimulating Broadband Nationally
Kernels
Kernels
Kernels
Nat'l Surface Transportion Policy & Revenue Study Cmsn
Kernels
Kernels
Kernels
MAINFRAME Training with IBM Certification and JOB GUARANTEE
Metcalfe Pitches Terabit Ethernet
MAINFRAME Training with IBM Certification and JOB GUARANTEE
cp67 announced 40 yrs ago at spring 68 share in houston
MAINFRAME Training with IBM Certification and JOB GUARANTEE
Linux zSeries questions
was: 1975 movie "Three Days of the Condor" tech stuff
Berkeley researcher describes parallel path
Spammers crack Gmail Captcha
Berkeley researcher describes parallel path
Richard Feynman, the Challenger Disaster, and Software Engineering
MAINFRAME Training with IBM Certification and JOB GUARANTEE
Who's Winning the ID Theft War?
VMware signs deal to embed software in HP servers
IBM announced z10 ..why so fast...any problem on z 9
CPU time differences for the same job
IBM Preview of z/OS V1.10
The hands-free way to steal a credit card
PIN devices vulnerable to 'tapping' attacks, researchers warn
Batch job to perform sftp transfer
was: 1975 movie "Three Days of the Condor" tech stuff
Any benefit to programming a RISC processor by hand?
z10 presentation on 26 Feb
Fantasy-Land_Hierarchal_NUMA_Memory-Model_on_Vertical
IBM announced z10 ..why so fast...any problem on z 9
Banks failing to manage IT risk - study
fraying infrastructure
insider fraud
1975 movie "Three Days of the Condor" tech stuff
1975 movie "Three Days of the Condor" tech stuff
System z10 announcement (in English)
fraying infrastructure
Any benefit to programming a RISC processor by hand?
fraying infrastructure
was: 1975 movie "Three Days of the Condor" tech stuff
Any benefit to programming a RISC processor by hand?
Why Is Less Than 99.9% Uptime Acceptable?
news maintenance: Prison pushes
Google ventures into health records biz
Any benefit to programming a RISC processor by hand?
Any benefit to programming a RISC processor by hand?
Any benefit to programming a RISC processor by hand?
independent appraisers
z10 presentation on 26 Feb
Study Finds Sharp Math, Science Skills Help Expand Economy
Any benefit to programming a RISC processor by hand?
Study Finds Sharp Math, Science Skills Help Expand Economy
Shockwave traffic jam recreated for first time
Banks failing to manage IT risk - study
independent appraisers
Any benefit to programming a RISC processor by hand?
Computer science graduating class of 2007 smallest this decade
independent appraisers
independent appraisers
US aerospace and defense sector braces for potential brain drain as Cold War workers retire
was: 1975 movie "Three Days of the Condor" tech stuff
Convergent Technologies vs Sun
Convergent Technologies vs Sun
Banks failing to manage IT risk - study
independent appraisers
independent appraisers
independent appraisers
Any benefit to programming a RISC processor by hand?

The Economic Impact of Stimulating Broadband Nationally

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Economic Impact of Stimulating Broadband Nationally
Newsgroups: alt.folklore.computers
Date: Sat, 23 Feb 2008 13:53:47
Lon <lon.stowell@comcast.net> writes:
Ayup. Lived for years in the technology slums of Cupertino only a couple blocks from Apple hqs. Pac Bell repeatedly reneged on commitments to install a promised CO. Finally managed to get ISDN where even the Pac Bell folks recommended getting it from Covad rather than them. Then got DSL, but was so far from the telco that could get only the ultra-expensive business grade medium speed stuff--again from Covad. Had to go visit friends a few miles away to get the [then blistering] @Home cable based internet speeds.

re:
http://www.garlic.com/~lynn/2008d.html#80 The Economic Impact of Stimulating Broadband Nationally
http://www.garlic.com/~lynn/2008d.html#94 The Economic Impact of Stimulating Broadband Nationally

i remember news articles citing the PUCC repeatedly refusing pacbell tariff requests for upgrade of CO for cupertino ... some claim that the only reason for the upgrade was for new functions that would be only useful for younger people ... that all the seniors would never use any of the new features and would still experience a rate hike to cover the cost of the new hardware.

we had done some stuff with pacbell with regard to business processes and being able to capture all the information ... several generations earlier than what is mentioned here
http://www.garlic.com/~lynn/index.html

simple new service request could require hundreds of process checks.

pacbell had room with printed sheets tape to the wall ... completely covered approx. 6' high by 12-15' long ... with tiny little boxes (on the order of 1in sq) representing processes ... with lines connecting the boxes .... sort of flow chart of what needed to be done for residential service request to add additional feature.

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Migration from Mainframe to othre platforms - the othe bell?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Migration from Mainframe to othre platforms - the othe bell?
Newsgroups: alt.folklore.computers
Date: Sat, 23 Feb 2008 15:19:04
Lon <lon.stowell@comcast.net> writes:
Wasn't there a group near Triangle Park working on VTAM to make it more AIX friendly in the 80's?

One problem all the other "unix" vendors ran into against 370 AIX or Amdahl's UTS was that none of them really could handle PU Type 5 or ESCON host, and even more of a barrier was the sheer cost of replacing all the block mode terminals and channel type printers [particularly the big mommas] in order to replace a mainframe in any given customer. The cost of the Unix box, even the big bad SMP or Massively Parallel ones was a mere piece of chump change compared to the cost of the infrastructure used to access the mainframe. Everything from keyboards to phone lines and modems had to essentially be fork lifted and replaced at horrific cost.


as an aside there was also ssup/unix, at&t had done the deal for internal at&t use with unix layered on top of a stripped down tss/370 (ssup) kernel.

we were doing some work with one of the baby bells in the mid-80s that had implemented pu4/pu5 emulation on series/1 and was using it with both ibm and non-ibm (not even compatible/clone) mainframes. they had several tens of thousands of such 3270 terminals (both local and remote, lots even bisync).

we were looking at turning it into a product and moving off series/1 platform onto a risc/rios platform. we had been expecting some of the communication division efforts like had been used with the disk division ... slight digression:
http://www.garlic.com/~lynn/2008d.html#64 Interesting ibm about the myths of the Mainframe

we thot we had come up with innovative project operation which would be immune from meddling by the communication division ... but they managed to kill the project anyway. i suppose i didn't help things by going into the lions den ... i got scheduled to do a presentation on the project to the sna arb (architecture review board) in raleigh. I would somewhat characterize the presentation as all the technical people in the meeting would have much preferred to work on what i was presenting (than what they were doing). After the presentation, the executive responsible for the sna arb came up and ask who was responsible for scheduling my talk (strong implication that the person would be serverely reprimanded)

misc. past posts about the project (including potions of the presentation given at the sna arb)
http://www.garlic.com/~lynn/99.html#66 System/1 ?
http://www.garlic.com/~lynn/99.html#67 System/1 ?
http://www.garlic.com/~lynn/99.html#70 Series/1 as NCP (was: Re: System/1 ?)

as an aside ... sequent/dynix did have escon support at some point.

there was cmu effort to implement sna lu6.2 support in unix ... using the fapl definition (used to drive 3820 printer) ... old email
http://www.garlic.com/~lynn/2006h.html#email850604
in this post with other discussion of fapl and other sna pieces
http://www.garlic.com/~lynn/2006h.html#56 The Pankian Metaphor

other posts mentioning fapl
http://www.garlic.com/~lynn/2005e.html#1 [Lit.] Buffer overruns
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/2006m.html#0 Mainframe Linux Mythbusting
http://www.garlic.com/~lynn/2007d.html#55 Is computer history taugh now?
http://www.garlic.com/~lynn/2007v.html#46 folklore indeed

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

How many overwrites for secure erase?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How many overwrites for secure erase?
Newsgroups: alt.computer.security
Date: Sat, 23 Feb 2008 10:54:40
Arthur T. <arthur@munged.invalid> writes:
On another list, someone asked a question which piqued my curiosity.

U.S. DoD requires 7 overwrites. The OP wanted a '*technical* justification of "15-times" or any other number. Technical one, not "because mama said so".'


post in another thread
http://www.garlic.com/~lynn/2008c.html#47 Data Erasure Products
http://www.garlic.com/~lynn/2008c.html#48 Data Erasure Products

the above hast reference to NIST standard for overwriting and GAO finding that it was adequate ... and then some vendor study finding out that they could still recover data (at least in the case of used magnetic tape that the gov. was selling ... after overwrites).

as to disk, some really old email about disk track spacing being reduced from 20widths to 10widths (doubling number of tracks ... later to 2widths).
http://www.garlic.com/~lynn/2006s.html#email871122
in this post
http://www.garlic.com/~lynn/2006s.html#30 Why magnetic drums was/are worse than disks ?

above also references early work on vertical/perpendicular recording ... which more recently is showing up in commodity products
http://www.garlic.com/~lynn/2007o.html#64 Toshiba Boosts Hard Drive Density by 50%

this old email doing a different kind of head design (working with the person that originated risc chip architecture)
http://www.garlic.com/~lynn/2006s.html#email871230

part of the issue use to be small head jitter ... head write surface would be wider than head read surface ... to reasonable assure that most recent write path would cover the area that subsequent reading head would travel. by implication a subsequent write operation might not exactly overlap a previous write operation (residual signal from previous writes offset to one side or another).

quicky search engine turns up reference to current issues with signal noise from closenest of adjacent tracks

this reference could imply possibly looking at noise from previous writes:
http://www.lecroy.com/tm/solutions/datastorage/DDNA/default.asp

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

The hands-free way to steal a credit card

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The hands-free way to steal a credit card
Newsgroups: alt.folklore.computers
Date: Sat, 23 Feb 2008 16:17:00
Lon <lon.stowell@comcast.net> writes:
To segue only slightly, how reliable are the reports that if you can catch a computer powered on, all you need is a can of air duster to freeze the DRAM, power it off, run off with the computer and hack it and so much for the encryption of data.

re:
http://www.garlic.com/~lynn/2008d.html#84 The hands-free way to steal a credit card
http://www.garlic.com/~lynn/2008d.html#88 The hands-free way to steal a credit card

issue is encrypted filesystem support ... where password/key is entered early in the boot process and the password/key remains in memory

the issue is can the password/key be found in memory.

for other topic drift ... erasing (non-encrypted) data from magnetic media
http://www.garlic.com/~lynn/2008e.html#2 How many overwrites for secure erase?

some of the disk encryption news references ....
Cold Boot Attack Defeats Disk Encryption Software
http://news.yahoo.com/s/cmp/206801184
Disk encryption easily cracked, researchers find
http://www.networkworld.com/news/2008/022108-disk-encryption-cracked.html?t51hb
Encryption: Security Wonks Warn of DRAM Decryption Danger
http://www.technewsworld.com/story/61804.html
Your Encrypted Data: Not So Safe After All
http://www.popsci.com/gear-gadgets/article/2008-02/your-encrypted-data-not-so-safe-after-all
Cold Reboot Attacks on Disk Encryption
http://it.slashdot.org/it/08/02/21/1543234.shtml
Attack on computer memory reveals vulnerability of widely-used security systems
http://www.eurekalert.org/pub_releases/2008-02/pues-aoc022108.php
Attack On Computer Memory Reveals Vulnerability Of Widely-used Security Systems
http://www.sciencedaily.com/releases/2008/02/080221105820.htm
Cold Boot Attack Defeats Disk Encryption Software
http://www.informationweek.com/news/showArticle.jhtml?articleID=206801184
Study: Data Encryption Leaves Sleeping Computers Vulnerable
http://www.crn.com/security/206801225
Disk encryption may not be secure enough, new research finds
http://www.news.com/8301-13578_3-9876060-38.html
Laptop Hard Drive Encryption Has Achilles Heel
http://www.pcworld.com/article/id,142708-c,hardwaresecuritycomponents/article.html
Laptop Hard Drive Encryption Has Achilles Heel
http://news.yahoo.com/s/pcworld/142708
Researchers find hard drive encryption's Achilles' heel
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9064098
Hard drive encryption has Achilles heel
http://www.arnnet.com.au/index.php/id;274957049;fp;4;fpid;1382389953
Hard drive encryption has Achilles heel, say researchers
http://www.networkworld.com/news/2008/022108-hard-drive-encryption-has-achilles.html
Hard drive encryption has Achilles heel, say researchers
http://www.infoworld.com/article/08/02/21/Hard-drive-encryption-has-Achilles-heel-say-researchers_1.html
Disk Encryption Not So Sure, New Study Finds
http://www.efluxmedia.com/news_Disk_Encryption_Not_So_Sure_New_Study_Finds_14313.html
Disk encryption easily cracked, researchers find
http://www.networkworld.com/news/2008/022108-disk-encryption-cracked.html

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Migration from Mainframe to othre platforms - the othe bell?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Migration from Mainframe to othre platforms - the othe bell?
Newsgroups: alt.folklore.computers
Date: Sat, 23 Feb 2008 16:43:37
Lon <lon.stowell@comcast.net> writes:
Yeah, if I ever got to Mulligan my career, I would try to get on the SP2 cluster teams at IBM. All of those guys seemed to be having an absolute blast.

minor digression:
http://www.garlic.com/~lynn/95.html#13
http://www.garlic.com/~lynn/96.html#15

in ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp

scaleup activity
http://www.garlic.com/~lynn/lhwemail.html#medusa

and getting told after the technology transfer to kingston, we weren't to work on anything with more than four processors.

prior to that, the kingston activities had supposedly been focused on things like helping fund steve chen.

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

1998 vs. 2008: A Tech Retrospective

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 1998 vs. 2008: A Tech Retrospective
Newsgroups: alt.folklore.computers
Date: Sat, 23 Feb 2008 17:47:50
re:
http://www.garlic.com/~lynn/2008d.html#93 1998 vs. 2008: A Tech Retrospective

and of course, they had typo in the title ... which has finally been corrected:

1988 vs. 2008: A Tech Retrospective
http://www.pcworld.com/article/id,142550/article.html

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

1998 vs. 2008: A Tech Retrospective

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 1998 vs. 2008: A Tech Retrospective
Newsgroups: alt.folklore.computers
Date: Sat, 23 Feb 2008 18:04:43
re:
http://www.garlic.com/~lynn/2008d.html#93 1998 vs. 2008: A Tech Retrospective
http://www.garlic.com/~lynn/2008e.html#5 1998 vs. 2008: A Tech Retrospective

and some total (encryption) topic drift from 1988.

one of the issues regarding internal network links
http://www.garlic.com/~lynn/subnetwork.html#internalnet

was that all links physically leaving corporate facilities had to be encrypted. in the mid-80s there were comments that the internal network had over half of all link encryptors in the world.

however, hsdt backbone links at T1 (and higher speeds)
http://www.garlic.com/~lynn/subnetwork.html#hsdt

was paying $16k for vendor T1 link encryptors ... which prompted effort for doing some hardware that had significantly more encryption function at significnatly lower cost. some recent past posts:
http://www.garlic.com/~lynn/2004p.html#44 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2004p.html#51 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2004p.html#55 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2004q.html#57 high speed network, cross-over from sci.crypt
http://www.garlic.com/~lynn/2005s.html#28 MVCIN instruction

older email mentioning doing encryption/decryption in software and requiring a full 3081 processor to handle T1 data rate encryption:
http://www.garlic.com/~lynn/2006n.html#email841115
in this post
http://www.garlic.com/~lynn/2006n.html#36 The very first text editor

misc. old email mentionin encryption and/or public key operations
http://www.garlic.com/~lynn/lhwemail.html#publickey

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

was: 1975 movie "Three Days of the Condor" tech stuff

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: was: 1975 movie "Three Days of the Condor" tech stuff
Newsgroups: alt.folklore.computers
Date: Sat, 23 Feb 2008 19:01:35
"Rostyslaw J. Lewyckyj" <urjlew@bellsouth.net> writes:
New power from wind or tides power plant powers the local loads. So the power plant that was shipping power (to the left), now has the extra to send to the oil rig in the North Sea.

and now for something completely different ... they put in reversable pumps on grand coulee dam to handle peak load situation. the pumps had been put in to irrigate the coulee basin ... and the generators provided power to run the pumps ... with additional power dumped into the grid ... for a little additional drift ... related to datacenters mentioned here:
http://www.garlic.com/~lynn/2008d.html#72 Price of CPU seconds

however, with the reversable pumps ... they could pump extra water during offshift ... and then reverse the process during peak demand. couple previous posts:
http://www.garlic.com/~lynn/2002n.html#43 VR vs. Portable Computing
http://www.garlic.com/~lynn/2007o.html#14 Geothermal was: VLIW pre-history

some references:
http://en.wikipedia.org/wiki/Grand_Coulee_Dam
http://www.usbr.gov/power/data/sites/grandcou/grandcou.html
http://users.owt.com/chubbard/gcdam/
http://content.lib.washington.edu/grandcouleeweb/index.html
http://digital.lib.cwu.edu/cgi-bin/library?site=localhost&a=p&p=about&c=rufuswoo&l=en&w=utf-8

the grand coulee was part of water flow from ice age ... but is way above the level of the current river level. it is where water is pumped to flow into columbia basin irrigation (desert or at least semi-arid, see above wiki page reference). storage of excess water in grand coulee is what the reversable pumps can use for power generation during peak demand.

for total other drift, ice age floods

Ice Age Floods Institute
http://www.iafi.org/index.htm

from above:
During the last Ice Age (18,000 to 12,000 years ago), and in multiple previous Ice Ages, cataclysmic floods inundated portions of the Pacific Northwest from Glacial Lake Missoula, pluvial Lake Bonneville, and perhaps from subglacial outbursts. Glacial Lake Missoula was a body of water as large as some of the USA's Great Lakes. This lake formed from glacial meltwater that was dammed by a lobe of the Canadian ice sheet. Episodically, perhaps every 40 to 140 years, the waters of this huge lake forced its way past the ice dam, inundating parts of the Pacific Northwest. Eventually, the ice receded northward far enough that the dam did not reform, and the flooding episodes ceased.
... snip ...

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

MAINFRAME Training with IBM Certification and JOB GUARANTEE

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: MAINFRAME Training with IBM Certification and JOB GUARANTEE
Newsgroups: alt.folklore.computers
Date: Sat, 23 Feb 2008 20:20:08
Lon <lon.stowell@comcast.net> writes:
We had a drive-by manager zip thru one company complete with mba and total lack of common sense. His method of "improving" support [in the company with the reputation at the time of being among the top support orgs of the world] was "certification" Thankfully more senior heads prevailed when we demonstrated that a few of the office "user interface and documentation testing experts" could read a few paragraphs and pass the certification tests without being able to perform even a few of the most basic tasks on the certified technology. Unfortunately a lot of damage was done in the process where to this day I am ashamed of being a Certified Novell Instructor and have difficulty remembering much more than bindery and .mnu files.

folklore about disk division DataHub (pc network server) project in the early 80s. part of the implementation had been subcontracted out (under work-for-hire contract) to small operation in provo (some number of the people were associated with or attending the univ). one of the DataHub people (from san jose) was commuting to provo nearly every week. at some point the corporation decided to cancel the project ... and allowed the organization in provo to have rights to what they had implemented. not long after a pc server corporation appeared in provo.

misc. past posts mentioning DataHub project:
http://www.garlic.com/~lynn/96.html#4a John Hartmann's Birthday Party
http://www.garlic.com/~lynn/2000g.html#40 No more innovation? Get serious
http://www.garlic.com/~lynn/2002f.html#19 When will IBM buy Sun?
http://www.garlic.com/~lynn/2002g.html#79 Coulda, Woulda, Shoudda moments?
http://www.garlic.com/~lynn/2002o.html#33 Over-the-shoulder effect
http://www.garlic.com/~lynn/2003e.html#26 MP cost effectiveness
http://www.garlic.com/~lynn/2003f.html#13 Alpha performance, why?
http://www.garlic.com/~lynn/2004f.html#16 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2005p.html#23 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005q.html#9 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005q.html#36 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2006l.html#39 Token-ring vs Ethernet - 10 years later
http://www.garlic.com/~lynn/2006y.html#31 "The Elements of Programming Style"
http://www.garlic.com/~lynn/2007f.html#17 Is computer history taught now?
http://www.garlic.com/~lynn/2007j.html#49 How difficult would it be for a SYSPROG ?
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/2007n.html#86 The Unexpected Fact about the First Computer Programmer
http://www.garlic.com/~lynn/2007p.html#35 Newsweek article--baby boomers and computers
http://www.garlic.com/~lynn/2007v.html#53 folklore indeed

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

The Economic Impact of Stimulating Broadband Nationally

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Economic Impact of Stimulating Broadband Nationally
Newsgroups: alt.folklore.computers
Date: Sat, 23 Feb 2008 23:02:58
Lon <lon.stowell@comcast.net> writes:
I suspect that the dinosaurian management think of the telcos is exceeded only by that of the regulators. Even the horrific Deutsche Telekom was a mere amateur compared to the USofA telco cartels.

possibly old thread you recognize?
http://www.garlic.com/~lynn/2003j.html#73 1950s AT&T/IBM lack of collaboration?
http://www.garlic.com/~lynn/2003j.html#74 1950s AT&T/IBM lack of collaboration?
http://www.garlic.com/~lynn/2003j.html#75 1950s AT&T/IBM lack of collaboration?
http://www.garlic.com/~lynn/2003j.html#76 1950s AT&T/IBM lack of collaboration?

in particular this reply?
http://www.garlic.com/~lynn/2003k.html#4 1950s AT&T/IBM lack of collaboration?

... now other posts in this thread:
http://www.garlic.com/~lynn/2008d.html#80 The Economic Impact of Stimulating Broadband Nationally
http://www.garlic.com/~lynn/2008d.html#94 The Economic Impact of Stimulating Broadband Nationally
http://www.garlic.com/~lynn/2008e.html#0 The Economic Impact of Stimulating Broadband Nationally

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Kernels

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Kernels
Newsgroups: alt.folklore.computers,alt.sys.pdp10
Date: Sun, 24 Feb 2008 10:39:25
Peter Flass <Peter_Flass@Yahoo.com> writes:
AIX is apparently some microkernel underneath, a last bit of FS. On the surface it looks like unix.

the VRM that was done for aix.v2 on pc/rt was something of a "hypervisor", "virtualization" microkernel (as are many of the virtual machine hypervisors) ... but provided an abstract virtual machine interface ... discussed in this recent post:
http://www.garlic.com/~lynn/2008d.html#83 Migration from Mainframe to othre platforms - the othe bell?

much of aix v2 to v3 transition (& from pc/rt romp to rs/6000 rios) was elimination of VRM.

misc. 801, risc, romp, rios, pc/rt, rs/6000, power, power/pc, etc

somewhat separate, 801/risc architecture has had this database/transaction memory support. it was used in aix v3 (on rs/6000 rios) for implementing the journaled filesystem (JFS). the unix filesystem metadata information was organized into 801/risc database memory area ... so that all modification and changes were identified and could be journaled.

future system was extremely complex hardware definition in the early 70s that was going to replace 370
http://www.garlic.com/~lynn/submain.html#futuresys

when it failed, the folklore is some number of people retreated to rochester and produced the s/38.

i've claimed that a lot of the motiviation by the person responsible for 801/risc in the mid-70s was to do the exact opposite of FS.

circa 1980, there was a program to replace the large number of different internal microprocessors used in wide variety of products (low & mid-range 370, controllers, embedded, etc) with common 801/risc processors called Iliad ... misc. old email mentioning 801, risc, iliad, etc
http://www.garlic.com/~lynn/lhwemail.html#801

one of these fort knox, iliad projects was going to be for the as/400 ... which was follow-on to s/38 (using iliad chip for the internal as/400 microprocessor). this ran into problems and as/400 microprocessor moved to a cisc chip implementation. however, later in the 90s, as/400 was moved to 801/risc power/pc microprocessor.

as an aside ... one of the splits between the palo alto group (did bsd port to pc/rt for "AOS" and did aix/368 & aix/370 work) ... recent post:
http://www.garlic.com/~lynn/2008d.html#82 Migration from Mainframe to othre platforms - the othe bell?

and the austin group (did vrm underneath the aix/v2 which had been subcontracted to corporation that had done the unix port for pc/ix) ... was over the journaled filesystem implementation. The palo alto group had done a portability port of the journaled filesystem (didn't require 801/risc database/transaction memory) that was much more efficient with purely software logging (even when running on the same rios/power hardware).

misc. past posts mentioning journaled filesystem and/or database/transaction memory
http://www.garlic.com/~lynn/2001f.html#58 JFSes: are they really needed?
http://www.garlic.com/~lynn/2001f.html#59 JFSes: are they really needed?
http://www.garlic.com/~lynn/2002b.html#33 Does it support "Journaling"?
http://www.garlic.com/~lynn/2002b.html#34 Does it support "Journaling"?
http://www.garlic.com/~lynn/2003c.html#49 Filesystems
http://www.garlic.com/~lynn/2003c.html#50 Filesystems
http://www.garlic.com/~lynn/2003d.html#54 Filesystems
http://www.garlic.com/~lynn/2003h.html#45 Question about Unix "heritage"
http://www.garlic.com/~lynn/2003o.html#49 Any experience with "The Last One"?
http://www.garlic.com/~lynn/2005j.html#26 IBM Plugs Big Iron to the College Crowd
http://www.garlic.com/~lynn/2005n.html#20 Why? (Was: US Military Dead during Iraq War
http://www.garlic.com/~lynn/2005n.html#32 Why? (Was: US Military Dead during Iraq War
http://www.garlic.com/~lynn/2005o.html#21 help understand disk managment
http://www.garlic.com/~lynn/2005o.html#22 help understand disk managment
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/2006o.html#26 Cache-Size vs Performance
http://www.garlic.com/~lynn/2006y.html#36 Multiple mappings
http://www.garlic.com/~lynn/2007b.html#44 Why so little parallelism?
http://www.garlic.com/~lynn/2007b.html#57 "The Elements of Programming Style"
http://www.garlic.com/~lynn/2007c.html#21 How many 36-bit Unix ports in the old days?
http://www.garlic.com/~lynn/2007i.html#27 John W. Backus, 82, Fortran developer, dies
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?

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Kernels

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Kernels
Newsgroups: alt.folklore.computers,alt.sys.pdp10
Date: Sun, 24 Feb 2008 10:59:32
jeffj@panix.com (Jeff Jonas) writes:
In the late 80s, the Unix kernel was a huge monolith that was hard to maintain, expand, extend or fix. Yes, there are advantages to things operating in the kernel space and I've been convinced of the performance advantages, but it has consequences too, as you noted.

re:
http://www.garlic.com/~lynn/2008e.html#10 Kernels

most of the virtual machine hypervisors have been microkernels ... and frequent, consuming interest has been performance ... frequently with hardware assists. part of the issue of virtual machine microkernels and other sorts of microkernels ... that it is possible to come to grips and consensus on what factors in the microkernels that represent performance issues ... and design specific hardware solutions to improve performance.

many times, other kinds of microkernel implementation have a much less focused understanding of what the microkernel performance issues are ... frequently leading to just moving implementation across the microkernel boundary ... negating any original microkernel focus (and the lack of clear concise vision and understanding contributes to not being able to specify hardware features that would assist and promote microkernel operation).

even with kiss and focus for virtual machine micorkernels ... it was still frequently a battle with letting people, with traditional operating system background, touch the source ... which would significantly contribute to kernel bloat and lack of focus. it takes quite a bit of discipline to maintain microkernel separation ... in the face of frequent tendency to do the quick&dirty implementation (there has been periodic claims that maintaining kiss & simplicity is significantly harder than the quick&dirty approach).

in the virtual machine microkernel genre this has frequently been trade-off between doing some implementation inside the kernel or outside the kernel in virtual address space. the virtual address space implementations have periodically been referred to as service virtual machines and/or virtual appliances; misc. past posts;
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?
http://www.garlic.com/~lynn/2007o.html#3 Hypervisors May Replace Operating Systems As King Of The Data Center
http://www.garlic.com/~lynn/2007q.html#25 VMware: New King Of The Data Center?
http://www.garlic.com/~lynn/2007s.html#4 Why do we think virtualization is new?
http://www.garlic.com/~lynn/2007s.html#26 Oracle Introduces Oracle VM As It Leaps Into Virtualization
http://www.garlic.com/~lynn/2007s.html#35 Oracle Introduces Oracle VM As It Leaps Into Virtualization
http://www.garlic.com/~lynn/2007u.html#39 New, 40+ yr old, direction in operating systems
http://www.garlic.com/~lynn/2007u.html#41 New, 40+ yr old, direction in operating systems
http://www.garlic.com/~lynn/2007u.html#81 IBM mainframe history, was Floating-point myths
http://www.garlic.com/~lynn/2007v.html#75 virtual appliance
http://www.garlic.com/~lynn/2007v.html#80 software preservation volunteers ( was Re: LINC-8 Front Panel Questions)
http://www.garlic.com/~lynn/2008.html#59 old internal network references
http://www.garlic.com/~lynn/2008b.html#39 folklore indeed
http://www.garlic.com/~lynn/2008b.html#52 China's Godson-2 processor takes center stage
http://www.garlic.com/~lynn/2008c.html#2 folklore indeed
http://www.garlic.com/~lynn/2008c.html#55 Kernels
http://www.garlic.com/~lynn/2008d.html#42 VM/370 Release 6 Waterloo tape (CIA MODS)

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Kernels

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Kernels
Newsgroups: alt.folklore.computers,alt.sys.pdp10
Date: Sun, 24 Feb 2008 11:18:46
Al Kossow <aek@spies.com> writes:
You try starting from scratch (Pink, Copeland, BeOS) but no single company is big enough to play catch up to get what you can get from a free software (ie. Unix) code base.

re:
http://www.garlic.com/~lynn/2008c.html#55 Kernels
http://www.garlic.com/~lynn/2008e.html#10 Kernels
http://www.garlic.com/~lynn/2008e.html#11 Kernels

microkernels with capability twist ... many of theme tracing lineage to gnosis implementation at tymshare
http://www.garlic.com/~lynn/2001g.html#35 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2002h.html#43 IBM doing anything for 50th Anniv?
http://www.garlic.com/~lynn/2003h.html#41 Segments, capabilities, buffer overrun attacks
http://www.garlic.com/~lynn/2003l.html#22 Secure OS Thoughts
http://www.garlic.com/~lynn/2004c.html#4 OS Partitioning and security
http://www.garlic.com/~lynn/2004m.html#29 Shipwrecks
http://www.garlic.com/~lynn/2004n.html#41 Multi-processor timing issue
http://www.garlic.com/~lynn/2005.html#7 How do you say "gnus"?
http://www.garlic.com/~lynn/2006k.html#37 PDP-1
http://www.garlic.com/~lynn/2006p.html#13 What part of z/OS is the OS?
http://www.garlic.com/~lynn/2006s.html#7 Very slow booting and running and brain-dead OS's?
http://www.garlic.com/~lynn/2006y.html#16 "The Elements of Programming Style"
http://www.garlic.com/~lynn/2007o.html#25 LAX IT failure: leaps of faith don't work
http://www.garlic.com/~lynn/2007s.html#17 Oddly good news week: Google announces a Caps library for Javascript
http://www.garlic.com/~lynn/2008b.html#24 folklore indeed

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Nat'l Surface Transportion Policy & Revenue Study Cmsn

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Nat'l Surface Transportion Policy & Revenue Study Cmsn
Newsgroups: alt.folklore.computers
Date: Sun, 24 Feb 2008 11:40:39
real time on cspan is broadcast of presentation/hearing by the commission.

statement that 16percent of the world's petroleum production is used by US surface road transportion.

statement that the federal highway fund is bankrupt ... in part because funds have been earmarked and redirected for other purposes (and the nations surface road transportion is starting to fail)

also claim that tax&build won't solve the current problem ... in part because use is decoupled from pricing ... implication is natural human tendency is to consume (relatively free) resource until it is exhausted (i.e. existing direct price ... like gas. price ... is only a very small percent of the surface road infrastructure true cost). just adding extra lanes ... use will (always) quickly expand to fill available capacity (there have been computer processing capacity corollaries).

a suggestion is that behavior, reflecting actual resource cost, only happens when priced for the resource useage directly reflects the resource cost.

old post with extract from road construction consideration standard/document
http://www.garlic.com/~lynn/2002j.html#41 Transportation

and other related past posts
http://www.garlic.com/~lynn/2006g.html#5 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#6 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#10 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#12 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#15 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#19 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#24 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#26 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#32 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#35 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#46 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#48 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#49 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#50 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#51 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#52 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#53 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#54 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#56 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#57 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#59 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#60 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#61 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#62 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#0 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#5 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#6 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#11 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#23 The Pankian Metaphor
http://www.garlic.com/~lynn/2006p.html#2 Overweight truckers stopped by tech checks
http://www.garlic.com/~lynn/2007n.html#97 Loads Weighing Heavily on Roads
http://www.garlic.com/~lynn/2008b.html#55 Toyota Sales for 2007 May Surpass GM

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Kernels

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Kernels
Newsgroups: alt.folklore.computers,alt.sys.pdp10
Date: Sun, 24 Feb 2008 12:34:57
Johnny Billquist <bqt@update.uu.se> writes:
The performance problems are not totally a microkernel problem. MACH as a design has a huge performance problem because of the way it was designed. Everything via a general IPC mechanism, and trying to still look like Unix.

re:
http://www.garlic.com/~lynn/2008c.html#55 Kernels
http://www.garlic.com/~lynn/2008e.html#10 Kernels
http://www.garlic.com/~lynn/2008e.html#11 Kernels
http://www.garlic.com/~lynn/2008e.html#12 Kernels

mvs sort of backed into the hardware assist with regard to minimizing stuff in the kernel ... although it is far from having been a "microkernel" objective.

the real storage heritage evolved a very strong pointer passing api. the initial transition to virtual memory basically layed everything out into a larger, simulated real storage paradigm. the next transition to mvs (multiple virtual storage ... or address spaces), gave each application its own address space.

the heavy use of pointer passing api ... effectively dictated that the (8mbyte) kernel image appeared in every application (16mbyte) virtual address space.

in addition, there were some number of system services outside the kernel ... that now found themselves in their own virtual address space ... making it difficult to pass parameter pointers from application virtual address space to subsystem running in different virtual address space. the solution was what was called the "common segment" ... an area of storage in every virtual address space where applications could squirrel away parameters ... and then call a subsystem (requiring a kernel call to effect hardware virtual address space switch).

a growing problem in 370 was that larger installations were requiring common segments of 4-5 mbytes (or larger) that had to be carved out of every application (16mbyte) virtual address space (which already had 8mbyte kernel image) ... leaving applications with 3-4 mbytes (or less).

the 8ll architecture had things like access registers and program call. however, there was immediate need for customer installations ... so there was somewhat a access register subset called dual-address space mode done for 3033 in the late 70s.

dual-address space mode ... basically had two sets of hardware address space pointers. application call to subsystem (in different address space) had the kernel moving the application virtual address space to the secondary status ... and the subsystem to the primary status. then the subsystem execution could take a passed parameter pointer and reach directly into the (secondary) application address space (w/o needing the application to have moved the parameters to the common segment).

dual-address space allowed for the efficiency of pointer-passing paradigm ... between different virtual address space (with kernel-like services outside the kernel ... w/o the inefficiencies of message passing). however, there was still the requirement for having the kernel call ... and kernel execution to switch the address space.

the other part of 811 architecture ... in addition to generalized access registers (for multiple virtual address space concurrent access) was "program call" (& return). this was a hardware defined table that had the rules for changing access registers and other information ... when a application called a non-kernel system function (in different address space). this allowed for hardware support of moving directly between application to non-kernel system function ... with nearly the efficiency of library subroutine call.

a claim is that the access register and program call/return hardware support went a long way towards being able to efficiently provide system services in their own virtual address space (and outside kernel boundary) ... aka focus and consise vision leading to hardware support for efficient system services outside of the kernel.

recent principles of operation
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dz9zr003/CCONTENTS

address spaces summary:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dz9zr003/3.8?DT=20040504121320

pc-number (program call) translation
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dz9zr003/5.5?DT=20040504121320

access-register introduction
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dz9zr003/5.7?DT=20040504121320

misc. past posts mentioning dual-address space, access registers, program call/return:
http://www.garlic.com/~lynn/98.html#36 What is MVS/ESA?
http://www.garlic.com/~lynn/2000c.html#84 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000d.html#28 RS/6000 vs. System/390 architecture?
http://www.garlic.com/~lynn/2000e.html#58 Why not an IBM zSeries workstation?
http://www.garlic.com/~lynn/2001d.html#28 Very CISC Instuctions (Was: why the machine word size ...)
http://www.garlic.com/~lynn/2001d.html#30 Very CISC Instuctions (Was: why the machine word size ...)
http://www.garlic.com/~lynn/2001h.html#73 Most complex instructions
http://www.garlic.com/~lynn/2001i.html#13 GETMAIN R/RU (was: An IEABRC Adventure)
http://www.garlic.com/~lynn/2001k.html#16 Minimalist design (was Re: Parity - why even or odd)
http://www.garlic.com/~lynn/2002d.html#51 Hardest Mistake in Comp Arch to Fix
http://www.garlic.com/~lynn/2002g.html#5 Black magic in POWER5
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/2002n.html#58 IBM S/370-168, 195, and 3033
http://www.garlic.com/~lynn/2002n.html#74 Everything you wanted to know about z900 from IBM
http://www.garlic.com/~lynn/2002p.html#43 cost of crossing kernel/user boundary
http://www.garlic.com/~lynn/2002q.html#1 Linux paging
http://www.garlic.com/~lynn/2003c.html#13 Unused address bits
http://www.garlic.com/~lynn/2003d.html#53 Reviving Multics
http://www.garlic.com/~lynn/2003d.html#69 unix
http://www.garlic.com/~lynn/2003e.html#0 Resolved: There Are No Programs With >32 Bits of Text
http://www.garlic.com/~lynn/2003e.html#12 Resolved: There Are No Programs With >32 Bits of Text
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/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/2004f.html#27 [Meta] Marketplace argument
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#41 Moving assembler programs above the line
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#39 Wylbur and Paging
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
http://www.garlic.com/~lynn/2007o.html#10 IBM 8000 series
http://www.garlic.com/~lynn/2007p.html#21 Newsweek article--baby boomers and computers
http://www.garlic.com/~lynn/2007q.html#68 Direction of Stack Growth
http://www.garlic.com/~lynn/2007r.html#56 CSA 'above the bar'
http://www.garlic.com/~lynn/2007t.html#16 segmentation or lack thereof
http://www.garlic.com/~lynn/2007t.html#75 T3 Sues IBM To Break its Mainframe Monopoly
http://www.garlic.com/~lynn/2008c.html#33 New Opcodes
http://www.garlic.com/~lynn/2008c.html#35 New Opcodes
http://www.garlic.com/~lynn/2008d.html#69 Regarding the virtual machines

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Kernels

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Kernels
Newsgroups: alt.folklore.computers,alt.sys.pdp10
Date: Sun, 24 Feb 2008 16:16:52
Lon <lon.stowell@comcast.net> writes:
I've tried building stuff around some of those "real time operating systems" that were either glorified schedulers or memory managers but rarely both at once. None were as fast as a couple proprietary implementations, one from an MIT puke, the other from a USC puke, both of whom agreed with me that nobody but them touched the innards and nobody got killed.

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

responsible for the technology used in the internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet

and bitnet/earn
http://www.garlic.com/~lynn/subnetwork.html#bitnet

many years later was working with one of the major real-time systems ... and noticed something familiar in the core dispatching/scheduling function. on closer examination it appeared to be line-for-line translaction from his 360 assembler to C ... including retaining all the original comments ... from his networking implementation.

in the virtual machine environment his networking function had been implemented as what was referred to as service virtual machine ... but sometimes now is called virtual appliance.

misc. other posts in this thread:
http://www.garlic.com/~lynn/2008c.html#55 Kernels
http://www.garlic.com/~lynn/2008e.html#10 Kernels
http://www.garlic.com/~lynn/2008e.html#11 Kernels
http://www.garlic.com/~lynn/2008e.html#12 Kernels
http://www.garlic.com/~lynn/2008e.html#14 Kernels

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Kernels

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Kernels
Newsgroups: alt.folklore.computers,alt.sys.pdp10
Date: Sun, 24 Feb 2008 16:56:59
Lon <lon.stowell@comcast.net> writes:
Then the fun of running a single kernel image across multiple tightly coupled processors without running afoul of Amdahl's Law. Or the trade-offs of attempting to come up with the perfect job priority queue servicing at high queue counts as opposed to monte carloing the queue and going back to work. I've seen kernels spend more time trying to pick the perfect job to run [per-priority queue counts in the several thousands] than simply running *something* with a bit of card trickery to make sure nothing ever got totally starved out.

60s & 70s implementation frequently had enormous number of state tests as well as pair-wise comparisions (sometimes nearly n-factorial).

one of the things i did as undergraudate for fairshare scheduler (actually dynamic adaptive with default policy was fairshare) ... was periodically recalculate advisory deadline (current tod plus some delta) ... which was used for (relatively long-lived) positioning in queue.

this had the effect of nearly eliminating measureable overhead for the feature ... especially compared to nearly all of the competing implementations during the period (with their enormous heavyweight and bloated overhead). it also had a side-effort of doing much better distribution of resources to competing processes.

some other principles from that effort was the dynamic adaptive scheduling (with effectively zero pathlength) being able to "schedule to the bottleneck".

a side-effort for kernel hackers, especially for those accustomed to requiring enormous numbers of state tests and comparisons ... was that the shift in coding style sometimes would obfuscate things ... quick transition from very state-testing programming style ... to nearly something more akin to fortran operations research programming style ... in the span of very few instructions.

the unfamiliarity of such multiple different programming styles ... possibly contributed to allowing me to get away with the joke in the resource manager.

much of the work i had done as undergraduate and was included in cp67 ... was dropped in the morph of cp67 to vm370. there was mounting pressure to let me re-introduce the features in vm370 ... including many former cp67 customers lobbying ibm ... in places like share. finally it was decided that i could release the "fairshare" scheduler as the vm370 resource manager. misc. past posts mentiong fairshare scheduling
http://www.garlic.com/~lynn/subtopic.html#fairshare

however, leading up to that, there were some reviews of the implementation. some number of experts complained that "modern" schedulers had enormous numbers of "tuning" knobs (like the favorite son operating system) ... and my resource manager couldn't be considered "modern" w/o having similar numbers of "tuning" knobs.

this ignored

1) the dynamic adaptive implementation effectively performed all the function automagically, continuously and in real time w/o requiring human intervention

2) individuals representing favorite son operating system would make presentations at share about extensive benchmarks involving effectively (static) random walks around the parameter space of the enormous numbers of turning values for different workloads ... which tended to show little or know conclusive results. in advertising this might be considered "featuring" a bug ... spend lots of effort publicising enormous numbers of studies showing how much manual constant care and feading was needed.

in any case, i added some tuning knobs, documented the effects of the tuning knobs and also shipped all the source code. the joke is related to something that is referred to "degrees of freedom" in operations resource ... i.e. the effect of the tuning knobs had more limited degrees of freedom than the degrees of freedom for the dynamic adaptive code

for slight other digression i also redid the page replacement infrastructure and page thrashing controls ... again attempting to make the implementation appear to perform in nearly zero instructions.
http://www.garlic.com/~lynn/subtopic.html#wsclock

part of this (more than decade later) landed me into the middle of dispute between global replacement stragegies and local replacement stragies ... something jim gray dragged me into since one of his co-workers at tandem was working on phd thesis on global replacement (and there was lots of road blocks being thrown up by local replacement interests) ... old reference
http://www.garlic.com/~lynn/2006w.html#email821019
in this post
http://www.garlic.com/~lynn/2006w.html#46 The Future of CPUs: What's After Multi-Core?

somewhat independent of global LRU vis-a-vis local lru ... was that LRU algorithms tended to degenerate to FIFO. one of the things that i did was come up with a slight-of-hand coding trick ... to all intents and purposes ... the code was pure LRU ... done in nearly zero instructions ... but the slight-of-hand coding trick had the side-effect of degenerating to RANDOM rather than FIFO.

the science center was involved in all sorts of performance related activities, modeling, simulations, workload profiling, work leading up to capacity planning ... some related posts
http://www.garlic.com/~lynn/submain.html#benchmark

some of this included doing detailed instruction & storage address traces ... as well as page traces. some of the extensive tracing activity was used for the technology that did semi-automated reorganization of programs for improved virtual memory operation ... later released as vs/repack application.

some of the other use of the traces was detailed simulation of various page replacement algorithms ... included "exact" least recently used (aka ordering maintained exactly updated on each instruction execution).

one of the characteristics of most page replacement implementations was that they were all worse than "exact" LRU ... "goodness" measured in how close they came to "exact" LRU. the slight-of-hand coding trick that degenerated to RANDOM (instead of FIFO) tended to show slightly better than "exact" LRU. The explanation seemed to be in those situations were LRU would degenerate to FIFO ... RANDOM would be better choice than FIFO.

misc. other recent posts in this thread:
http://www.garlic.com/~lynn/2008c.html#55 Kernels
http://www.garlic.com/~lynn/2008e.html#10 Kernels
http://www.garlic.com/~lynn/2008e.html#11 Kernels
http://www.garlic.com/~lynn/2008e.html#12 Kernels
http://www.garlic.com/~lynn/2008e.html#14 Kernels

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

MAINFRAME Training with IBM Certification and JOB GUARANTEE

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: MAINFRAME Training with IBM Certification and JOB GUARANTEE
Newsgroups: alt.folklore.computers
Date: Sun, 24 Feb 2008 17:09:34
Lon <lon.stowell@comcast.net> writes:
Too bad IBM and TI didn't partner up with Madge [they of Söderblom patent fame] and produce 100 Mbit and faster variants of Token Ring. The original IBM MAU's stunk to high heaven, but StarTek and others that used active drive on the lobes and added lobe protection to the MAU-MAU cabling were pretty good. The 10BaseT variants stunk up the place, but I would think a CAT-5 8 wire implementation might have worked at 100Mbit or even faster. I still prefer the manageability of Token Ring, particularly where you had both Remove Station and the managed MAUs that could simply be told to bypass a lobe. The priority scheme left a bit to be desired compared to ATM, but it arguably is still better than Ethernet implementations.

i've mentioned before my wife being con'ed into going to pok to be in charge of loosely-coupled architecture ... while there she came up with peer-coupled shared data architecture
http://www.garlic.com/~lynn/submain.html#shareddata

which didn't see a lot of takeup until more recent sysplex; except for the ims hotstandby work.

also while there she is one of co-inventors on token-passing patent ... both US and international ... misc. past refs
http://www.garlic.com/~lynn/2001c.html#69 Wheeler and Wheeler
http://www.garlic.com/~lynn/2004e.html#13 were dumb terminals actually so dumb???
http://www.garlic.com/~lynn/2004p.html#55 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2005h.html#12 practical applications for synchronous and asynchronous communication
http://www.garlic.com/~lynn/2005i.html#43 Development as Configuration
http://www.garlic.com/~lynn/2005q.html#17 Ethernet, Aloha and CSMA/CD -
http://www.garlic.com/~lynn/2005u.html#50 Channel Distances
http://www.garlic.com/~lynn/2005u.html#53 OSI model and an interview
http://www.garlic.com/~lynn/2005u.html#56 OSI model and an interview
http://www.garlic.com/~lynn/2006l.html#35 Token-ring vs Ethernet - 10 years later
http://www.garlic.com/~lynn/2007b.html#46 'Innovation' and other crimes
http://www.garlic.com/~lynn/2007g.html#80 IBM to the PCM market(the sky is falling!!!the sky is falling!!)
http://www.garlic.com/~lynn/2007h.html#35 sizeof() was: The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007p.html#44 what does xp do when system is copying

note that when they were building almaden research center ... lots of wiring was put in ... the cat-5 nominally targeted for 16mbit T/R. the problem was that when they went to deploy ... they found that 10mbit ethernet had both higher effective bandwidth as well as lower latency.

we got embroiled in the middle since we had come up with 3-tier networking architecture and were out making customer executive presentations. The sample configurations with ethernet vis-a-vis 16mbit t/r ... over the same cat-5 wiring ... showed ethernet significantly higher thruput at significantly lower cost (compared to 16mbit t/r).
http://www.garlic.com/~lynn/subnetwork.html#3tier

in that time frame, one of the science & engineering groups put out a study showing 16mbit t/r significantly outperforming ethernet. the only conclusion we could come up for the comparison was that they used an early 3mbit ethernet w/o listen before transmit.

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Metcalfe Pitches Terabit Ethernet

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Metcalfe Pitches Terabit Ethernet
Newsgroups: alt.folklore.computers
Date: Sun, 24 Feb 2008 18:36:02
re:
http://www.garlic.com/~lynn/2008d.html#64 Interesting ibm about the myths of the Mainframe
http://www.garlic.com/~lynn/2008e.html#17 MAINFRAME Training with IBM Certification and JOB GUARANTEE

Metcalfe Pitches Terabit Ethernet
http://www.lightreading.com/document.asp?doc_id=146628

Terabit Ethernet
http://www.lightreading.com/document.asp?doc_id=144775

Optical Fiber and the Future of Communication - Major Research Conference to be held in San Diego, Feb. 24-28
http://www.businesswire.com/portal/site/google/index.jsp?ndmViewId=news_view&newsId=20080214005633&newsLang=en

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

MAINFRAME Training with IBM Certification and JOB GUARANTEE

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: MAINFRAME Training with IBM Certification and JOB GUARANTEE
Newsgroups: alt.folklore.computers
Date: Sun, 24 Feb 2008 18:47:50
Lon <lon.stowell@comcast.net> writes:
Is that the source of the FUD that 10 Mbit Ethernet could absolutely not go over roughly 240Kbyte second, at a time when some of the Unix vendors already had interfaces and drivers capable of pretty much saturating it?

re:
http://www.garlic.com/~lynn/2008e.html#17 MAINFRAME Training with IBM Certification and JOB GUARANTEE

about the time of one of the 16mbit t/r better than e-net publications, there was article in acm sigcomm proceedings detailing study with 30 stations on e-net and resulting effective thruput. if you put all 30 stations in low-level driver loop constantly transmitting minimum size e-net packet ... effective thruput dropped off to 8.5mbits/sec.

there was also a article showing that slow-start wasn't stable in real-life long-haul internet environment.

we had arrived at that a number of years earlier in hsdt project
http://www.garlic.com/~lynn/subnetwork.html#hsdt

implementing rate-based pacing as much more effective alternative to stuff like slow-start for congestion control.

misc. past posts mentioning acm sigcomm e-net study:
http://www.garlic.com/~lynn/2000b.html#11 "Mainframe" Usage
http://www.garlic.com/~lynn/2000f.html#38 Ethernet efficiency (was Re: Ms employees begging for food)
http://www.garlic.com/~lynn/2000f.html#39 Ethernet efficiency (was Re: Ms employees begging for food)
http://www.garlic.com/~lynn/2001j.html#20 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2002.html#38 Buffer overflow
http://www.garlic.com/~lynn/2002b.html#4 Microcode? (& index searching)
http://www.garlic.com/~lynn/2002b.html#9 Microcode? (& index searching)
http://www.garlic.com/~lynn/2002q.html#40 ibm time machine in new york times?
http://www.garlic.com/~lynn/2002q.html#41 ibm time machine in new york times?
http://www.garlic.com/~lynn/2003g.html#54 Rewrite TCP/IP
http://www.garlic.com/~lynn/2003j.html#46 Fast TCP
http://www.garlic.com/~lynn/2003k.html#57 Window field in TCP header goes small
http://www.garlic.com/~lynn/2003p.html#13 packetloss bad for sliding window protocol ?
http://www.garlic.com/~lynn/2004e.html#13 were dumb terminals actually so dumb???
http://www.garlic.com/~lynn/2004e.html#17 were dumb terminals actually so dumb???
http://www.garlic.com/~lynn/2004k.html#8 FAST TCP makes dialup faster than broadband?
http://www.garlic.com/~lynn/2004p.html#55 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2005g.html#4 Successful remote AES key extraction
http://www.garlic.com/~lynn/2005h.html#12 practical applications for synchronous and asynchronous communication
http://www.garlic.com/~lynn/2005i.html#43 Development as Configuration
http://www.garlic.com/~lynn/2005q.html#18 Ethernet, Aloha and CSMA/CD -
http://www.garlic.com/~lynn/2005q.html#22 tcp-ip concept
http://www.garlic.com/~lynn/2006d.html#21 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006g.html#18 TOD Clock the same as the BIOS clock in PCs?
http://www.garlic.com/~lynn/2006l.html#35 Token-ring vs Ethernet - 10 years later
http://www.garlic.com/~lynn/2007g.html#80 IBM to the PCM market(the sky is falling!!!the sky is falling!!)

...

misc. past posts mentioning rate-based pacing:
http://www.garlic.com/~lynn/94.html#22 CP spooling & programming technology
http://www.garlic.com/~lynn/2000b.html#11 "Mainframe" Usage
http://www.garlic.com/~lynn/2001h.html#44 Wired News :The Grid: The Next-Gen Internet?
http://www.garlic.com/~lynn/2002i.html#45 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#57 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002k.html#56 Moore law
http://www.garlic.com/~lynn/2002p.html#28 Western Union data communications?
http://www.garlic.com/~lynn/2002p.html#31 Western Union data communications?
http://www.garlic.com/~lynn/2003.html#55 Cluster and I/O Interconnect: Infiniband, PCI-Express, Gibat
http://www.garlic.com/~lynn/2003b.html#44 filesystem structure, was tape format (long post)
http://www.garlic.com/~lynn/2003g.html#54 Rewrite TCP/IP
http://www.garlic.com/~lynn/2003g.html#64 UT200 (CDC RJE) Software for TOPS-10?
http://www.garlic.com/~lynn/2003j.html#1 FAST - Shame On You Caltech!!!
http://www.garlic.com/~lynn/2003j.html#19 tcp time out for idle sessions
http://www.garlic.com/~lynn/2003j.html#46 Fast TCP
http://www.garlic.com/~lynn/2004f.html#37 Why doesn't Infiniband supports RDMA multicast
http://www.garlic.com/~lynn/2004k.html#8 FAST TCP makes dialup faster than broadband?
http://www.garlic.com/~lynn/2004k.html#12 FAST TCP makes dialup faster than broadband?
http://www.garlic.com/~lynn/2004k.html#13 FAST TCP makes dialup faster than broadband?
http://www.garlic.com/~lynn/2004k.html#16 FAST TCP makes dialup faster than broadband?
http://www.garlic.com/~lynn/2004k.html#29 CDC STAR-100
http://www.garlic.com/~lynn/2004n.html#35 Shipwrecks
http://www.garlic.com/~lynn/2004o.html#62 360 longevity, was RISCs too close to hardware?
http://www.garlic.com/~lynn/2004q.html#3 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2004q.html#57 high speed network, cross-over from sci.crypt
http://www.garlic.com/~lynn/2005d.html#6 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005g.html#4 Successful remote AES key extraction
http://www.garlic.com/~lynn/2005q.html#37 Callable Wait State
http://www.garlic.com/~lynn/2006d.html#21 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006g.html#18 TOD Clock the same as the BIOS clock in PCs?
http://www.garlic.com/~lynn/2006m.html#20 Why I use a Mac, anno 2006
http://www.garlic.com/~lynn/2006o.html#64 The Fate of VM - was: Re: Baby MVS???
http://www.garlic.com/~lynn/2006u.html#44 waiting for acknowledgements
http://www.garlic.com/~lynn/2007q.html#19 Fixing our fraying Internet infrastructure

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

cp67 announced 40 yrs ago at spring 68 share in houston

From:   Anne & Lynn Wheeler <lynn@garlic.com>
Subject: cp67 announced 40 yrs ago at spring 68 share in houston
Date: Mon, 25 Feb 2008 08:59:45
Newsgroups: bit.listserv.vmesa-l
CP67 was announced 40yrs ago at spring 68 share in houston.

I was invited to attend. I was undergraduate at univ where the last week of jan68, three people from the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

had come out to install cp67.

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

MAINFRAME Training with IBM Certification and JOB GUARANTEE

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: MAINFRAME Training with IBM Certification and JOB GUARANTEE
Newsgroups: alt.folklore.computers
Date: Mon, 25 Feb 2008 09:22:25
Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
That wasn't FUD, it was different assumptions. If a bunch of workstations are all pumping packets out with a reasonable distribution, Ethernet (real Ethernet -- using a shared bus) utilization peaks out at something under 30%.

If you've got a lone transmitter sending out packets as fast as possible, you can get pretty much the whole theoretical bandwidth.


re:
http://www.garlic.com/~lynn/2008e.html#17 MAINFRAME Training with IBM Certification and JOB GUARANTEE
http://www.garlic.com/~lynn/2008e.html#19 MAINFRAME Training with IBM Certification and JOB GUARANTEE

the articles showing 16mbit t/r better than e-net seemed to be using really old e-net ... 3mbit version before listen-before-transmit (i.e. just transmitting w/o checking if something already transmitting).

the sigcomm article had 30 stations on cat-5 star-wired ... where effective e-net thruput dropped off to 85percent of media speed (10mbits) in case where all 30 stations were in low-level device driver loop constantly transmitting minimum sized packets.

fairly early in e-net technology, there was upgrade from 3mbit/sec to 10mbit/sec ... and introduction of listen-before-transmit (i.e. don't transmit if there is signal already on the wire).

in the listen-before-transmit scenario ... worst case collisions is with longest propagation delay. in cable e-net ... there is effectively single cable snaking between all the stations. the worst case propagation delay is between the two stations on the opposite ends of the cable.

star-wired enet over cat-5 tends to have much better worst case propagation delay since it is the two longest arms out of the central station.

there is a separate issue in lots of LAN configurations with client/server operation ... where the server tends to require the aggregate of the individual capacity of the individual clients. this is asymmetrical bandwidth needs ... with server requiring higher thruput than its individual clients.

separate from the LAN effective thrupt ... i.e. in the scenario with with 30 stations all simulataneously low-level transmit loop of minimum size packets (non-asymmetrical) ... there can be an issue with thruput of the individual LAN adapter cards (separate from aggregate LAN effective thruput ... in client/server asymmetrical scenario there is thruput of LAN adapter card for the server).

for the pc/rt, austin had done a custom 4mbit t/r 16bit isa lan adapter card. in transition from pc/rt to rs/6000, austin had moved to microchannel bus. boca then got heavy handed and applied corporate political pressure that rs/6000 had to use boca microchannel cards (and couldn't design/use their own cards). there then was some comments that the results would be that the rs/6000 would run as slow as ps2. this was applied to graphics card, scsi cards, t/r cards, all microchannel cards.

separate from the issue ... where almaden found that effective aggregate 16mbit t/r rate was lower than effective aggregate 10mbit e-net rate ... there is the issue of the effective thruput of individual cards ... especially in the asymmetrical client/server enviornmnet.

the ps2 16mbit t/r card had design point of terminal emulation bandwidth requirements ... frequent customer installation would have 300 PCs sharing common 16mbit t/r bandwidth ... as a result, individual 16mbit t/r cards didn't individual require significant thruput. recent post discussing terminal emulation
http://www.garlic.com/~lynn/2008d.html#64 Interesting ibm about the myths of the Mainframe
other posts mentioning terminal emulation
http://www.garlic.com/~lynn/subnetwork.html#emulation

in fact, the individual 16mbit (32bit microchannel ps/2) t/r cards had lower thruput than the custom 4mbit (16bit isa, pc/rt) t/r cards. this made a really big difference between the assumed ps/2 LAN environment for mainframe terminal emulation ... and the unix workstation client/server (or 3tier) environment.

we had also come up with the idea of 3-tier network architecture and were out pitching it to customer executives ... including some of the comparisons between 16mbit t/r (terminal emulation) design point vis-a-vis 10mbit enet multi-tier network. this resulted in taking a lot of corporate barbs and arrows from the 16mbit t/r as well as the sna/saa folks
http://www.garlic.com/~lynn/subnetwork.html#3tier

misc. past posts mentioning individual pc/rt 4mbit t/r cards having higher thruput than ps2 microchannel 16mbit t/r cards
http://www.garlic.com/~lynn/2002g.html#9 IBM MIcrochannel??
http://www.garlic.com/~lynn/2002q.html#40 ibm time machine in new york times?
http://www.garlic.com/~lynn/2004p.html#59 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2005h.html#12 practical applications for synchronous and asynchronous communication
http://www.garlic.com/~lynn/2005q.html#21 Ethernet, Aloha and CSMA/CD -
http://www.garlic.com/~lynn/2005q.html#38 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005u.html#50 Channel Distances
http://www.garlic.com/~lynn/2006l.html#35 Token-ring vs Ethernet - 10 years later
http://www.garlic.com/~lynn/2006l.html#36 Token-ring vs Ethernet - 10 years later
http://www.garlic.com/~lynn/2007g.html#81 IBM to the PCM market

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Linux zSeries questions

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Linux zSeries questions
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 25 Feb 2008 09:47:44
Anne & Lynn Wheeler <lynn@garlic.com> writes:
vulnerability database ... and having difficulty categorizing exploits ... and lobbying the CVE interests to improve the strucuture/nature of CVE reports.
http://www.garlic.com/~lynn/2004e.html#43 security taxonomy and CVE
http://www.garlic.com/~lynn/2005c.html#28 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005c.html#32 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2007q.html#20 Hackers Attack Apps While Still in Development


re:
http://www.garlic.com/~lynn/2008d.html#58 Linux zSeries questions

and past posts mentioning c-language programming environment proclivity for buffer overflows
http://www.garlic.com/~lynn/subintegrity.html#overflow

The common cold of IT security
http://www.gcn.com/online/vol1_no1/45864-1.html

from above:
IT security experts are not ready to admit defeat by one of the most common types of exploits, but the battle against buffer overflows so far has produced about the same results as medical science has against the common cold: We can treat it, but we haven't found a way to cure it.

"It's the same problem over and over again," independent security consultant Shawn Moyer said Thursday at the Black Hat Federal Briefings in Washington. "We patch, we scan, we patch, we scan, and the cycles get shorter and shorter and the problem is worse." The result, he said, is a "flailing death spiral of updates and patches."

... snip ...

we had done quite a bit of implementations using vs/pascal ... including the original mainframe tcp/ip implementation ... w/o having any buffer length problems (not that they couldn't happen ... but it took quite a bit more effort in pascal to have a buffer length problem ... compared to c language programming environment).

for other drift ... the original base tcp/ip implementation had 44kbytes/sec thruput consuming a full 3090 processor ... in large part because of the characteristics of the controller used to interface to LANs. i had done the rfc 1044 enhancements (to support a controller box from another vendor) and in some tuning tests at cray research between a cray and 4341 clone ... was getting 1mbyte/sec using only a modest amount of the 4341 processor (approx. three orders of magnitude improvement in bytes transfered per instruction executed)
http://www.garlic.com/~lynn/subnetwork.html#1044

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

was: 1975 movie "Three Days of the Condor" tech stuff

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: was: 1975 movie "Three Days of the Condor" tech stuff
Newsgroups: alt.folklore.computers
Date: Mon, 25 Feb 2008 14:48:08
Morten Reistad <first@last.name> writes:
900 gallons ..times 131 megajoules per gallon should be ca 118 gigajoules. Or 32 MWh. Or 15 times the 2.4MWh electrical consumption.

This is yourop fuel oil figures. US oil has lower energy content per liter, but higher per kilogram. (Denser. The US are pumping from older fields, more tar come out). You may deduct 5-10% from the figures.

That is a lot of energy. A 100m2 apartment is considered uneconomical here if it uses more than 20 MWh per year.


there has been a number of articles along these lines over the past week:

Nanoparticles could make hydrogen cheaper than gasoline
http://www.eetimes.com/showArticle.jhtml?articleID=206801669

from above:
PORTLAND, Ore. -- The hydrogen economy is getting a shot in the arm from a start-up that says its nanoparticle coatings could make hydrogen easy to produce at home from distilled water, and ultimately bring the cost of hydrogen fuel cells in line with that of fossil fuels.
... snip ...

now where are the conspiracy theorists from 30yrs ago about technology like this being bought up and suppressed by the large oil companies?

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Berkeley researcher describes parallel path

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Berkeley researcher describes parallel path
Newsgroups: alt.folklore.computers
Date: Mon, 25 Feb 2008 15:55:36
Al Kossow <aek@spies.com> writes:
This is all about semi vendors trying to figure out what to do with all the transistors they can fab. I knew someone at LSI Logic working on tools methodology for dealing with the complexity of billion transistor logic design. Haven't heard much about that in the last couple of years.

some of the old timers at lsi logic had come from varian where cp67 was used for running some of the design tools ... and then they had vm370 infrastructure deployed at lsi logic for quite some time ... well into the late 80s ... before starting to transition to other platforms.

one of the people there had done lots of work on c compiler optimizing for (cms) 370 ... as part of porting some of the design tools from berkeley.

we would frequently visit with them up thru late 90s. there were some x-over between some lsi logic chip people and sun people ... both on sparc chip ... and for some complicated reasons ... the sun object-oriented spring operating system (in same timeframe and similar effort to what apple was doing with pink). at some point we were approached about heading up effort turning spring into commercial offering ... in conjunction with large collections of sparc processors with a form of SCI interconnect.

LSI logic also was doing some work in the area of chip design verification with some people at stanford and had also hired the math institute in a different country.

old email discussing older SCI meetings:
http://www.garlic.com/~lynn/2001f.html#email920630
in this post:
http://www.garlic.com/~lynn/2001f.html#11 Climate, US, Japan & supers query

misc. past post in thread:
http://www.garlic.com/~lynn/2008d.html#81 Berkeley researcher describes parallel path
http://www.garlic.com/~lynn/2008d.html#87 Berkeley researcher describes parallel path
http://www.garlic.com/~lynn/2008d.html#89 Berkeley researcher describes parallel path
http://www.garlic.com/~lynn/2008d.html#90 Berkeley researcher describes parallel path

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Spammers crack Gmail Captcha

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Spammers crack Gmail Captcha
Newsgroups: alt.folklore.computers
Date: Mon, 25 Feb 2008 16:13:25
Spammers crack Gmail Captcha
http://www.theregister.co.uk/2008/02/25/gmail_captcha_crack/

from above:
Internet security firm Websense reports that miscreants have created bots which are capable of signing up and creating random Gmail accounts for spamming purposes, defeating Captcha-based defences in the process. It reckons the same group of spammers are behind both attacks.
... snip ...

past posts mentioning captcha
http://www.garlic.com/~lynn/2003p.html#20 Dumb anti-MITM hacks / CAPTCHA application
http://www.garlic.com/~lynn/2005j.html#3 Request for comments - anti-phishing approach
http://www.garlic.com/~lynn/2007u.html#66 folklore indeed
http://www.garlic.com/~lynn/2007v.html#2 folklore indeed
http://www.garlic.com/~lynn/2008b.html#19 Yahoo's CAPTCHA Security Reportedly Broken
http://www.garlic.com/~lynn/2008b.html#23 Yahoo's CAPTCHA Security Reportedly Broken
http://www.garlic.com/~lynn/2008d.html#2 Spammers' bot cracks Microsoft's CAPTCHA

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Berkeley researcher describes parallel path

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Berkeley researcher describes parallel path
Newsgroups: alt.folklore.computers
Date: Mon, 25 Feb 2008 16:26:06
for more multi-core:

Sun Leaks 6-core Intel Xeon, Nehalem Details
http://www.dailytech.com/Sun%20Leaks%206core%20Intel%20Xeon%20Nehalem%20Details/article10834.htm

from above:
Dunnington includes 16MB of L3 cache shared by all six processors. Each pair of cores can also access 3MB of local L2 cache. The end result is a design very similar to the AMD Barcelona quad-core processor; however, each Barcelona core contains 512KB L2 cache, whereas Dunnington cores share L2 cache in pairs.
... snip ...

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Richard Feynman, the Challenger Disaster, and Software Engineering

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Richard Feynman, the Challenger Disaster, and Software Engineering
Newsgroups: alt.folklore.computers
Date: Mon, 25 Feb 2008 19:44:02
Peter Flass <Peter_Flass@Yahoo.com> writes:
If I understand what you're saying, the problem was that the files weren't created to be portable. Usually you'd get (copies of) the production tapes used on the generating system. This means all kinds of wierd formats. I vaugely recall writing a conversion program from H-200 to S/360. I also more recently wrote code to read Multics backup tapes and try to do something useful with the various types of files.

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

did some work on was descriptive headers for files (early on, somewhat tape oriented) ... to enable processing, potentially decades later.

i believe this orientation contributed to the invention at the science center in 1969 of GML (precursor to sgml, html, xml, etc)
http://www.garlic.com/~lynn/submain.html#sgml

in the mid-90s we attended some metadata standards meetings. oil industry participated ... they were looking at descriptive header information for their huge inventory of seismic files ... making it easier to process information originating from all over the world ... dating back decades.

one of the issues was attempting to map metadata information into relational databases. relational structure was easily setup supporting homogeneous information structures. metadata frequently tends to be extremely non-homogeneous. the pass that the oil industry had taken for mapping seismic file metadata description into relational dbms structure involved 998 (relational) tables.

there were also gov types at some of the meetings discussing similar problems, like old nasa tapes containing photos of the back side of the moon ... that they no longer knew how to process.

handling metadata is also somewhat the kind of stuff we do in the merged taxonomy and glossories that we have on our webpages
http://www.garlic.com/~lynn/index.html#glosnote

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

MAINFRAME Training with IBM Certification and JOB GUARANTEE

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: MAINFRAME Training with IBM Certification and JOB GUARANTEE
Newsgroups: alt.folklore.computers
Date: Tue, 26 Feb 2008 02:49:28
Anne & Lynn Wheeler <lynn@garlic.com> writes:
there was also a article showing that slow-start wasn't stable in real-life long-haul internet environment.

we had arrived at that a number of years earlier in hsdt project
http://www.garlic.com/~lynn/subnetwork.html#hsdt

implementing rate-based pacing as much more effective alternative to stuff like slow-start for congestion control.


re:
http://www.garlic.com/~lynn/2008e.html#19 MAINFRAME Training with IBM Certification and JOB GUARANTEE

since i had started doing rate-based resource management back in the 60s as undergraduate ... with dynamic adaptive controls ... recent posts
http://www.garlic.com/~lynn/2008e.html#16 Kernels

it wouldn't be too surprising that in hsdt project ... i would be doing rate-based pacing for bandwidth management as well as congestion control (analogous to control of other dataprocessing resources).

in the past, one of the claims i've made about the primitive state of both unix more generalized resource management implementations, as well as networking bandwidth specific issues ... was the extremely poor timer facilities offered on many of the platforms that they ran on. halfway decent timer facilities were a start to implement low-overhead resource rate utilization ... as prerequisite to doing resource rate management.

other recent posts mentioning dynamic adaptive scheduling, fairshare scheduling policy and/or resource management product
http://www.garlic.com/~lynn/2008.html#16 No Glory for the PDP-15
http://www.garlic.com/~lynn/2008.html#88 folklore indeed
http://www.garlic.com/~lynn/2008.html#89 folklore indeed
http://www.garlic.com/~lynn/2008b.html#9 folklore indeed
http://www.garlic.com/~lynn/2008b.html#10 folklore indeed
http://www.garlic.com/~lynn/2008b.html#59 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008c.html#9 was: 1975 movie "Three Days of the Condor" tech stuff
http://www.garlic.com/~lynn/2008c.html#20 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008c.html#21 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008c.html#72 No Glory for the PDP-15
http://www.garlic.com/~lynn/2008c.html#78 CPU time differences for the same job
http://www.garlic.com/~lynn/2008c.html#88 CPU time differences for the same job

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Who's Winning the ID Theft War?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Who's Winning the ID Theft War?
Newsgroups: alt.folklore.computers
Date: Tue, 26 Feb 2008 08:43:56
Who's Winning the ID Theft War?
http://www.ecommercetimes.com/story/61828.html

from above:
One study says ID fraud is on a downward trend; another indicates it's staying about the same. Determining how much ID theft is occurring and how often ID fraud is perpetrated can depend on one's point of view. A lot depends on how the researchers doing the studies define what they are surveying.
... snip ...

a year ago, there was study claiming identity fraud was declining 10-12 percent at the same time another study claimed it was exploding.

recent posts
http://www.garlic.com/~lynn/2008.html#4 folklore indeed
http://www.garlic.com/~lynn/2008b.html#26 folklore indeed
http://www.garlic.com/~lynn/2008d.html#18 New Research Confirms Identity Fraud Is On Decline
http://www.garlic.com/~lynn/2008d.html#34 New Research Confirms Identity Fraud Is On Decline

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

VMware signs deal to embed software in HP servers

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: VMware signs deal to embed software in HP servers
Newsgroups: alt.folklore.computers
Date: Tue, 26 Feb 2008 09:08:12
VMware signs deal to embed software in HP servers
http://news.zdnet.com/2100-3513_22-6232078.html

from above:
VMware and Hewlett-Packard said on Tuesday they have signed an agreement to integrate VMware's virtualization software into 10 models of HP's computer servers. The companies said the joint offering will help customers adopt virtualization with greater speed and simplicity.
... snip ...

we had attempted to do that for all (endicott, low and mid-range) 138/148 370 machines.

the ecps virtual machine m'code assist had been done for the line of machines:
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assit
http://www.garlic.com/~lynn/94.html#27 370 ECPS VM microcode assit

besides having the hardware feature, the desire was to include vm370 packaged as part of every machine shipped ... somewhat akin to how LPAR support ... aka virtual machine subset, is integrated into the hardware of every mainframe machine shipped. however, at the time, there were other corporate factions looking at killing off vm370 ... and the strategy (of shipping vm370 integrated into every 138 and 148) was vetoed.

In fact, in this time frame, POK had convinced the corporation to kill the vm370 product, shutdown the vm370 development group, and move all the people to POK to help support the mad-rush to turn out enhanced version of the favorite son operating system. Endicott managed to save the vm370 product mission, but required reconstitute the vm370 development organization.

as an aside ... this week is spring share in orlando ... 40yrs ago, cp67 (virtual machine) system was announced at the spring share meeting in houston ... recent post
http://www.garlic.com/~lynn/2008e.html#20 cp67 announced 40 yrs ago at spring 68 share in houston

this week, the new z10 mainframe machines were announced ... previous reference
http://www.garlic.com/~lynn/2008d.html#91 z10 presentation on 26 Feb

IBM rolls out new mainframe
http://news.yahoo.com/s/ap/ibm_new_mainframe

from above:
The size of IBM's investment — the company spent five years and $1.5 billion developing the new mainframe — also underscores its commitment to the long-term viability of the mainframe and efforts continue adapting the decades-old product line to the Internet age.
... snip ...

in mainframe mailing list it notes that previous model was announced/shipped 3yrs ago. this would imply that the mainframe 7-8 yr development cycle has been reduced to five yrs ... but product cycles are being overlapped ... referenced recently in post about automobile C4 effort:
http://www.garlic.com/~lynn/2008c.html#68 Toyota Beats GM in Global Production

also from new mainframe:
The z10's capacity is equivalent to 1,500 servers based on the popular x86 design, IBM says, though it has 85 percent lower energy costs and takes up 85 percent less space than the batch of x86 servers
... snip ...

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

IBM announced z10 ..why so fast...any problem on z 9

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM announced z10 ..why so fast...any problem on z 9
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 26 Feb 2008 11:16:45
tommytsui@GMAIL.COM (Tommy Tsui) writes:
Actually, I worry becuase there are no competitors in the market, why IBM announced the new CPU model so fast, it doesn't like a desktop computer ..I think z9 is announced around 3 years...As I remember, IBM never try to announced a new model of mainframe computer just three years later...a market needs??? ..just curious...if you upgrade the mianframe currently I think you also have a question...

lots of industries were on 7-8 yr development cycle ... but they had two parallel efforts offset by 3-4 yrs ... so there was new announcements every 3-4yrs.

in the 70s, the company had a problem because they had so focused on moving everything off 360/370 and on to future system replacement ... old post with somebody quoting from Fergus & Morris book
http://www.garlic.com/~lynn/2001f.html#33
lots of other posts mentioning future system effort
http://www.garlic.com/~lynn/submain.html#futuresys

as a result the 370 product pipeline was allowed to run dry. then when future system project was killed ... there was mad rush to get things back into the 370 product pipeline.

the 303x was rush stopgap ... while they tried to ramp up for xa.

the integrated channel microcode from the 370/158 engine was moved into a dedicated separate box and relabled "channel director".

then a 370/158 was repackaged with just the 370 microcode and relabled a 3031 ... with a 2nd dedicated 158 microcode engine running the channel director microcode.

the 370/168 was repackaged to work with channel director and relabled 3032.

the 3033 started out with 370/168 wiring logic remapped to faster chip technology ... which would have nominally resulted in machine approx. 20percent faster than 168. however, the new chip technology also had ten times the circuits per chip. there was some very targeted thruput redesign to better do things within the same chip ... which eventually resulted in 3033 shipping at 50percent faster than 168 (rather than just 20percent faster).

in parallel with 303x effort, there was all the stuff for 370-xa. first was the new architecture that was referred to as "811" ... eventually leading to 3081, mvs/xa, etc. after the 303x got out ... that team started on 3090 ... overlapped with 3081 work.

circa 1990, the american automobile industry had "C4" taskforce to look at revamping their 7-8 yr product cycles (also doing two parallel efforts offset by 3-4 yrs ... even tho "new" models were introduced every yr ... they were mostly superficial changes between actual new product releases). The "C4" effort was that foreign competition had first reduced new product development cycle to 3-4 yrs (total elapsed) and were heading for 12-18 months for total elapsed time for new product ... from drawing board to rolling off the line. A major part of the "C4" was to heavily leverage information technology to totally redo how product development cycle happened. Part of the issue between having a 7-8yr elapsed product development cycle vis-a-vis a 1-3yr elapsed product development cycle ... was the significant increase in agility to adopt to changing consumer preferences and/or new technologies.

several information technology vendors were invited to participate in C4 ... including both the company's mainframe as well as workstation divisions. there were some behind the scenes comments from the workstation division that they were already on a 1-3yr product development cycle ... while the mainframe group was on their own 7-8yr product development cycle (ironic that the mainframe group were being included in an effort to provide advice on how to move from a 7-8yr product development cycle to a significantly more agile product development cycle).

Since then the mainframe group has significantly reorganized and revitalized themselves.

some recent posts mentioning the C4 activity:
http://www.garlic.com/~lynn/2008.html#84 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008.html#85 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008c.html#22 Toyota Beats GM in Global Production
http://www.garlic.com/~lynn/2008c.html#68 Toyota Beats GM in Global Production

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

CPU time differences for the same job

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CPU time differences for the same job
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 26 Feb 2008 13:54:13
recent posts mentioning doing dispatching in the 60s for improving both uniprocessor as well as multiprocessor cache hit ratios (including a form of low-overhead cache affinity dispatching)
http://www.garlic.com/~lynn/2008c.html#78 CPU time differences for the same job
http://www.garlic.com/~lynn/2008c.html#92 CPU time differences for the same job
http://www.garlic.com/~lynn/2008c.html#81 Random thoughts
http://www.garlic.com/~lynn/2008d.html#1 What happened to resumable instructions?

last Friday with early mention of hiperdispatch
http://www.garlic.com/~lynn/2008d.html#91 z10 presentation on 26 Feb

there was some question of moving more of the multiprocessing dispatching function into the microcode ... or making it more sensitive to cache hit efficiencies ... or just fastpath software.

i had done fastpath dispatch software as undergraduate in the 60s for cp67 (40yrs since it was announced at the spring 68 share meeting in houston).

in the mid-70s ... doing work on 5-way multiprocessor product (which got canceled before shipping) ... misc past posts
http://www.garlic.com/~lynn/submain.html#bounce

... i was able to move lots of stuff in microcode ... defining queued interface for path i/o operation as well as for dispatching (software and microcode interacting with common queue). the i/o stuff provided some of the function of 370-xa queued i/o interface ... the dispatching was somewhat analogous to what was defined later for the i432.

re:
http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=AN&subtype=CA&htmlfid=897/ENUS108-154&appname=USN

from above:
HiperDispatch

A z10 EC exclusive, HiperDispatch represents a cooperative effort between the z/OS operating system and the z10 EC hardware and is intended to provide improved efficiencies in both the hardware and the software in the following ways:

* Work may be dispatched across fewer logical processors therefore reducing the multi-processor (MP) effects and lowering the interference among multiple partitions.

* Specific z/OS tasks may be dispatched to a small subset of logical processors which Processor Resource/Systems Manager™ (PR/SM™) will tie to the same physical processors, thus improving the hardware cache re-use and locality of reference characteristics such as reducing the rate of cross-book communication.

... snip ...

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

IBM Preview of z/OS V1.10

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Preview of z/OS V1.10
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 26 Feb 2008 17:59:30
eamacneil@YAHOO.CA (Ted MacNEIL) writes:
I've seen the 'S' stand for service, storage, & system, over the last 28 years, so I have given up. The 'S' stands for 's'.

it started out as common segment area ... when it originally was a single segment. this was the transition from svs to mvs and required some place for applications to pass parameters to subsystems (running in different virtual address space) using pointer passing paradigm. however, it quickly got out of hand ... and became multiple common segments.

recent posts with discussion of evolution of mvs, common segments, dual-address space feature on 3033, and access registers
http://www.garlic.com/~lynn/2008c.html#35 New Opcodes
http://www.garlic.com/~lynn/2008d.html#69 Regarding the virtual machines
http://www.garlic.com/~lynn/2008e.html#14 Kernels

here is posting with MVS APAR/PTF 0267587 from 1983 ... for running MVS Guest under VM ... when there was a problem with "common segments" bit on 3090 ...
http://www.garlic.com/~lynn/2002m.html#0

common segment bit was added to virtual memory hardware table segment table entry definition. i have done a q&d html conversion of the old gcard ios3270 (green card with additional info done in ios3270 format):
http://www.garlic.com/~lynn/gcard.html#13

370 table look aside buffer (TLB) implementations were STO-associative ... i.e. every hardware translation entry was associated with specific virtual address space (determine by its segment table origin address).

if you did a special case operation for an installation running a (single) MVS operating system ... it was possible to imagine customizing improved hardware thruput ... even if it didn't conform to "official" 370 architecture ... but tailoring the hardware operation for exactly how MVS happened to be using the hardware.

In the case of the common segment(s) ... the identical same segments appeared in every virtual address space (at least if you were only running a single MVS operating system on the bare hardware). That resulted in huge number of duplicate TLB entries ... since there were huge number of different applications (from their virtual address spaces) referencing locations in the common segment(s). Even if they were the same exact location ... since they origianted from different virtual address spaces ... they would have different (duplicate) entries in the TLB (associated with the specific STO/virtual address space that the operation occured in).

The 370 segment table entry hardware table (see gcard DAT reference) was updated to define a bit meaning "common segment". If TLB was processing a virtual address associated with a segment having the "C" bit turned on ... rather than associating the TLB entry with a specific virtual address space ... the TLB entry would be flagged as associated with the Common Segment(s). The straight-forward implementation only works if there is one and only one set of common segments across the whole infrastructure.

current principles of operation reference for segment-table entries:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dz9zr003/3.11.2.2?DT=20040504121320

from above:
Common-Segment Bit (C): Bit 59 controls the use of the translation-lookaside-buffer (TLB) copies of the segment-table entry and of the page table which it designates. A zero identifies a private segment; in this case, the segment-table entry and the page table it designates may be used only in association with the segment-table origin that designates the segment table in which the segment-table entry resides. A one identifies a common segment; in this case, the segment-table entry and the page table it designates may continue to be used for translating addresses corresponding to the segment index, even thouqgh a different segment table is specified. However, TLB copies of the segment-table entry and page table for a common segment are not usable if the private-space control, bit 55, is one in the address-space-control element used in the translation or if that address-space-control element is a real-space designation. The common-segment bit must be zero if the segment-table entry is fetched from storage during a translation when the private-space control is one in the address-space-control element being used; otherwise, a translation-specification exception is recognized.
... snip ...

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

The hands-free way to steal a credit card

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The hands-free way to steal a credit card
Newsgroups: alt.folklore.computers
Date: Tue, 26 Feb 2008 20:21:05
re:
http://www.garlic.com/~lynn/2008d.html#84 The hands-free way to steal a credit card
http://www.garlic.com/~lynn/2008d.html#88 The hands-free way to steal a credit card
http://www.garlic.com/~lynn/2008e.html#3 The hands-free way to steal a credit card

Cambridge researchers show that Chip & PIN machines are vulnerable to attack
http://www.cl.cam.ac.uk/research/security/banking/ped/press-release.html

from above:
The Cambridge attacks call into question the system under which bank terminals are certified. Visa and APACS certified these devices as secure, and the vendors are pushing retailers to buy certified devices. But the evaluators did not find the flaws identified by the Cambridge team. The Protection Profile – the target used by the evaluators – was approved by GCHQ, and yet the Cambridge work has shown it was unrealistic. APACS and Visa claimed the devices were evaluated under the Common Criteria, an international evaluation scheme administered in the UK by GCHQ; yet GCHQ had not heard of the work and now says that the devices were never certified under the Common Criteria.

Visa and APACS have refused to disclose the evaluation report and to withdraw the vulnerable terminals from use. The vendors are passing the buck to APACS and Visa, and GCHQ is claiming they knew nothing of what was going on.

... snip ...

Security of Chip & PIN
http://www.paymentsnews.com/2008/02/security-of-chi.html
How secure is Chip and PIN?
http://news.bbc.co.uk/2/hi/programmes/newsnight/7265437.stm
PIN Entry Device (PED) vulnerabilities
http://www.cl.cam.ac.uk/research/security/banking/ped/
Researchers hack 'tamper-proof' PIN terminals
http://www.builderau.com.au/news/soa/Researchers-hack-tamper-proof-PIN-terminals/0,339028227,339286329,00.htm

past discussions of various kinds of chip payment card vulnerabilities
http://www.garlic.com/~lynn/subintegrity.html#yescard

for other topic drift ... various glossaries from common critiera (cc1, cc2, cc2.1) are included in merged security glossary and taxonomy
http://www.garlic.com/~lynn/index.html#glosnote

misc. past posts mentioning common criteria and/or protection profile:
http://www.garlic.com/~lynn/aadsm12.htm#13 anybody seen (EAL5) semi-formal specification for FIPS186-2/x9.62 ecdsa?
http://www.garlic.com/~lynn/aadsm13.htm#20 surrogate/agent addenda (long)
http://www.garlic.com/~lynn/aadsm17.htm#26 privacy, authentication, identification, authorization
http://www.garlic.com/~lynn/aadsm24.htm#23 Use of TPM chip for RNG?
http://www.garlic.com/~lynn/aadsm27.htm#10 K6 again, again and again. Therefore, H6.4 -- Compromise on Security before Delivery
http://www.garlic.com/~lynn/aadsm27.htm#37 The bank fraud blame game
http://www.garlic.com/~lynn/2001.html#50 What exactly is the status of the Common Criteria
http://www.garlic.com/~lynn/2001b.html#47 what is interrupt mask register?
http://www.garlic.com/~lynn/2001i.html#55 Computer security: The Future
http://www.garlic.com/~lynn/2001l.html#15 Security Classifications? (Where to Find Info)
http://www.garlic.com/~lynn/2002e.html#17 Smart Cards
http://www.garlic.com/~lynn/2002f.html#23 Computers in Science Fiction
http://www.garlic.com/~lynn/2002j.html#40 Beginner question on Security
http://www.garlic.com/~lynn/2002j.html#84 formal fips186-2/x9.62 definition for eal 5/6 evaluation
http://www.garlic.com/~lynn/2002k.html#11 Serious vulnerablity in several common SSL implementations?
http://www.garlic.com/~lynn/2002k.html#35 ... certification
http://www.garlic.com/~lynn/2002m.html#72 Whatever happened to C2 "Orange Book" Windows security?
http://www.garlic.com/~lynn/2003c.html#39 DOD 5200.28-STD capable OS?
http://www.garlic.com/~lynn/2003j.html#36 CC vs. NIST/TCSEC - Which do you prefer?
http://www.garlic.com/~lynn/2003m.html#18 Threat Analysis and Threat Trees
http://www.garlic.com/~lynn/2004j.html#2 Authenticated Public Key Exchange without Digital Certificates?
http://www.garlic.com/~lynn/2004m.html#41 EAL5
http://www.garlic.com/~lynn/2004m.html#49 EAL5
http://www.garlic.com/~lynn/2004p.html#42 chip inside smart card is firmware?
http://www.garlic.com/~lynn/2006t.html#38 Vulnerability Assessment of a EAL 4 system
http://www.garlic.com/~lynn/2007b.html#30 How many 36-bit Unix ports in the old days?
http://www.garlic.com/~lynn/2007l.html#39 My Dream PC -- Chip-Based
http://www.garlic.com/~lynn/2007q.html#34 what does xp do when system is copying
http://www.garlic.com/~lynn/2007t.html#8 Translation of IBM Basic Assembler to C?
http://www.garlic.com/~lynn/2007u.html#5 Public Computers

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

PIN devices vulnerable to 'tapping' attacks, researchers warn

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: PIN devices vulnerable to 'tapping' attacks, researchers warn
Newsgroups: alt.folklore.computers
Date: Wed, 27 Feb 2008 08:46:58
re:
http://www.garlic.com/~lynn/2008d.html#84 The hands-free way to steal a credit card
http://www.garlic.com/~lynn/2008d.html#88 The hands-free way to steal a credit card
http://www.garlic.com/~lynn/2008e.html#3 The hands-free way to steal a credit card
http://www.garlic.com/~lynn/2008e.html#34 The hands-free way to steal a credit card

more in the most recent

PIN devices vulnerable to 'tapping' attacks, researchers warn
http://www.finextra.com/fullstory.asp?id=18148

and

Attack on Brit retail payments -- some takeways
https://financialcryptography.com/mt/archives/001009.html

recent discussion about evesdropping/skimming attacks and card acceptor device compromises
http://www.garlic.com/~lynn/aadsm28.htm#37

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Batch job to perform sftp transfer

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Batch job to perform sftp transfer
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 27 Feb 2008 12:00:43
John.Mckown@HEALTHMARKETS.COM (McKown, John) writes:
What do you mean by "OMVS is not unix"? I'm more curious than anything else. If you're talking about the TSO OMVS command, then it is every bit as much "unix" as the original TTY terminals (anybody else every use a KSR-33?). Also, z/OS UNIX System Service is also UNIX. It has been so branded by the owner of the UNIX trademark (The Open Group?)

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

came out the last week of jan68 to install cp67 (predecessor to vm370 that ran on 360/67) at the univ. at the time, cp67 only supported 1052 and 2741 terminals. the univ. was getting some ksr-33 terminals and so i had to add ascii/tty support to cp67.

2702 supported SAD command that allowed terminal line-scanner to be associated with specific ports under program control. the science center had done support to dynamically determine whether it was dealing with either a 1052 or 2741 ... and use the SAD command to associate with the different ports as appropriate.

so as part of adding ascii/tty support ... i figured i could do the same thing with ascii/tty support. well, it initially seemed to work ... however, the scenario that i really wanted to handle ... a single dialin phone number (for rotory pool) that could be used regardless of the terminal type ... failed to actually work. The problem wasn't with the SAD command and the line-scanner ... it was that the telecommunication controller took a short-cut and hardwired line-speed oscillator to each port. I needed to be able to both change the line-scanner and the oscillator line-speed on a port-by-port basis.

this short-coming helped precipitate a project at the univerisity to build our own clone controller. started with a interdata/3 minicomputer, that was programmed to scan the port signal rise/fall to dynamically determine terminal line speed. also had to reverse engineer the 360 channel interface and build a channel interface board for the interdata/3.

this was subsequently expanded to a cluster of interdata/4 handling the channel interface with multiple interdata/3s handling the port line-scanner interface.

this project was written up somewhat blaming four of us for the clone controller business. misc. past posts
http://www.garlic.com/~lynn/subtopic.html#360pcm

and, of course, the clone controller business is blamed for motivation behind the future system project ... recently mentioned here
http://www.garlic.com/~lynn/2008e.html#31 IBM announced z10 ..why so fast...any problem on z 9

and this reference mentions Fergus & Morris book attributing the distraction of the future system project providing the entre for the clone processors (as well as having long term dampening effects on corporate innovation).
http://www.garlic.com/~lynn/2001f.html#33
and this recent post
http://www.garlic.com/~lynn/2008d.html#16 more on (the new 40+ yr old) virtualization
references this article that also discusses future system project
http://web.archive.org/web/20110718153549/http://www.ecole.org/Crisis_and_change_1995_1.htm
http://www.ecole.org/en/seances/CM07
numerous other posts mentioning future system
http://www.garlic.com/~lynn/submain.html#futuresys

as to Fergus & Morris reference to dampening effects on corporate innovation ... i've periodically speculated that the person responsible for 801/risc ... was attempting to go to the exact opposite extreme (in terms of hardware complexity) as what had been going on in the future system effort
http://www.garlic.com/~lynn/subtopic.html#801

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

was: 1975 movie "Three Days of the Condor" tech stuff

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: was: 1975 movie "Three Days of the Condor" tech stuff
Newsgroups: alt.folklore.computers
Date: Wed, 27 Feb 2008 19:42:43
jmfbahciv writes:
The key is small business. You don't need exceptional brains and you don't need good luck to succeed at this. To insist that each and every small business has to become a large capitialization conglomerate is complete nonsesne. The US tax laws are slowly exhibiting this attitude. It's strangling the nation. I submit the premise that all of Morten's observations about the US losing its leadership in producing scientists, engineers and their ilk can be traced back to this stranulation.

i've mentioned before doing some work with one of the large mid-western state land grant universities in the mid-90s ... they said that they had dumbed down the freshman text books three different times between the 60s and the 90s.
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/2006m.html#12 DEC's Hudson fab
http://www.garlic.com/~lynn/2006p.html#23 SAT Reading and Math Scores Show Decline
http://www.garlic.com/~lynn/2007j.html#45 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#85 IBM Unionization
http://www.garlic.com/~lynn/2007o.html#31 EZPass: Yes, Big Brother IS Watching You!
http://www.garlic.com/~lynn/2007o.html#33 EZPass: Yes, Big Brother IS Watching You!

other posts in the SAT scores thread:
http://www.garlic.com/~lynn/2006p.html#21 SAT Reading and Math Scores Show Decline
http://www.garlic.com/~lynn/2006p.html#24 SAT Reading and Math Scores Show Decline
http://www.garlic.com/~lynn/2006p.html#25 SAT Reading and Math Scores Show Decline
http://www.garlic.com/~lynn/2006p.html#33 SAT Reading and Math Scores Show Decline
http://www.garlic.com/~lynn/2006q.html#6 SAT Reading and Math Scores Show Decline

the issue in the late 90s at the height of the internet bubble ... was that over half of US technical Phd graduates were foreign born.

the issues since then has been many of those foreign economies have been improving ... resulting in larger percentage of their technical graduates (from us schools) returning to their native countries ... as well as significant increase in technical education programs in their respective countries; US no longer being able to rely on over half of the technical expertise coming from other countries (even if the same number of foreign scientists, engineers, etc, were graduating from US schools ... significant numbers were starting to return home). some past posts mentioning US tech economy having been heavily dependent on foreign students
http://www.garlic.com/~lynn/2002e.html#1 More on Aging Legacy Workforce
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/2007j.html#51 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#57 IBM Unionization

aka ... the US leadership in producing scientists, engineers, etc had been heavily dependent on foreigners for some time ... even if there was no change in the US ... just improvements in other countries native ecnomies would still have significant impact on technical skills in the US.

also, all other things being equal, improving technical capability of other countries ... will put them more & more in competition with US. loss of the high level technical foreign skills ... can represent double whammy for the US ... both the heavy dependency on the departing skills as well as those same skills showing up as competition in their native countries.

the implication is that US will be more & more dependent on the products of its own schoool systems ... and be less able to rely on foreigners to make up the deficit. misc. recent posts:
http://www.garlic.com/~lynn/2007h.html#42 Experts: Education key to U.S. competitiveness
http://www.garlic.com/~lynn/2007u.html#78 Education ranking
http://www.garlic.com/~lynn/2007u.html#80 Education ranking
http://www.garlic.com/~lynn/2007u.html#82 Education ranking
http://www.garlic.com/~lynn/2007v.html#16 Education ranking
http://www.garlic.com/~lynn/2007v.html#19 Education ranking
http://www.garlic.com/~lynn/2007v.html#20 Education ranking
http://www.garlic.com/~lynn/2007v.html#38 Education ranking
http://www.garlic.com/~lynn/2007v.html#39 Education ranking
http://www.garlic.com/~lynn/2007v.html#44 Education ranking
http://www.garlic.com/~lynn/2007v.html#45 Education ranking
http://www.garlic.com/~lynn/2007v.html#51 Education ranking
http://www.garlic.com/~lynn/2007v.html#71 Education ranking
http://www.garlic.com/~lynn/2008.html#52 Education ranking
http://www.garlic.com/~lynn/2008.html#55 Education ranking
http://www.garlic.com/~lynn/2008.html#57 Computer Science Education: Where Are the Software Engineers of Tomorrow?
http://www.garlic.com/~lynn/2008.html#60 Education ranking
http://www.garlic.com/~lynn/2008.html#68 Computer Science Education: Where Are the Software Engineers of Tomorrow?
http://www.garlic.com/~lynn/2008.html#73 Computer Science Education: Where Are the Software Engineers of Tomorrow?
http://www.garlic.com/~lynn/2008.html#81 Education ranking
http://www.garlic.com/~lynn/2008.html#83 Education ranking
http://www.garlic.com/~lynn/2008.html#87 Computer Science Education: Where Are the Software Engineers of Tomorrow?
http://www.garlic.com/~lynn/2008b.html#6 Science and Engineering Indicators 2008
http://www.garlic.com/~lynn/2008b.html#13 Education ranking
http://www.garlic.com/~lynn/2008d.html#40 Computer Science Education: Where Are the Software Engineers of Tomorrow?

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Any benefit to programming a RISC processor by hand?

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Any benefit to programming a RISC processor by hand?
Newsgroups: comp.arch,comp.programming
Date: Wed, 27 Feb 2008 22:18:48
Andrew Reilly <andrew-newspost@areilly.bpc-users.org> writes:
I don't know that that was ever explicitly the goal. The much-quoted "reason" for RISC was that measurements on the big CISCs of the day (especially VAX) showed that sequences of "primitive" operations often out-performed the more complicated variants that the architecture offered. It was also noticed that the good compilers knew this already, and generally didn't emit the complicated instructions. So the RISC guys wondered how much faster they could go if they made the core (and particularly the instruction decode) really streamlined, used the space for more registers and more and better functional units. All of which pretty much worked as expected, but wasn't in the end enough of a win to get PC users away from their PCs.

So hand-programmability wasn't really an explicit anti-goal, unless you want to interpret the need to manually load and store, and manually compute addresses, as a particular hardship. Since that's the way good assembly programmers code anyway, it really isn't.


i've claimed that the person responsible for 801/risc ... was possibly taking the exact opposite of the hardware complexity in future system effort. i know that the presentations and meetings i attended in the mid-to-late 70s ... constantly had statements that 801/risc hardware simplicity trade-offs would be compensated by pl.8 compiler and/or cp.r operation system (aka 801/risc predated creation of any vax machine).

one of the things in 801/risc was no (hardware) protection domains ... this was supposedly compensated for by pl.8 compiler only generating correct code ... and program loader in cp.r would only "load" properly compiled pl.8 code. hardware/software complexity trade-off for risc hardware simplicity went way beyond just efficiency of code generation.

also, my complaints about only having 16 segment registers ... making it difficult to do proper memory mapped & sharing operation across multiple different domains ... was met with comment that there was (again) no protection domains ... and inline application code could change virtual address space segment registers ... as easily as address and/or general purpose registers were changed (and since cp.r and pl.8 guaranteed correct program operation ... there wasn't integrity issue).

it wasn't until later in the early 80s when trying to apply 801/risc to unix environment paradigm that things got sticky ... needing introduction of protection domain ... and some other hacks to deal with the small number of segments.

misc. past posts mentioning 801, risc, romp, rios, iliad, power, power/pc, fort knox, etc
http://www.garlic.com/~lynn/subtopic.html#801

recent post referencing some of the after effects of failed future system project:
http://www.garlic.com/~lynn/2008e.html#36

older post referencing Fergus & Morris book attributing after effects of future system failure having stifling effect on corporate innovation
http://www.garlic.com/~lynn/2001f.html#33

other posts mentioning future system
http://www.garlic.com/~lynn/submain.html#futuresys

on the other hand, one of the 801/risc efforts circa 1980 was to replace the large variety of different corporate microprocessor chips with 801/risc Iliad chips ... including microprocessors used in entry and mid-range 370s ... including using Iliad in 4381, the 4341-followon.

I help contribute to the documents killing that effort ... instead going with a customized CISC chip for 4381.

similarly, Iliad was originally going to be used in as/400, the s/38-followon. that effort ran into problems and it was also retargeted to custom CISC chip. it wasn't until the mid-90s when as/400 finally moved to (801/risc) power/pc chip.

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

z10 presentation on 26 Feb

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: z10 presentation on 26 Feb
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 27 Feb 2008 23:12:52
Eric Smith <eric@brouhaha.com> writes:
What's the difference between a "Hardware Storage Array" and memory?

re:
http://www.garlic.com/~lynn/2008d.html#91 z10 presentation on 26 Feb
http://www.garlic.com/~lynn/2008e.html#31 IBM announce Z10 ..why so fast...any problem on z 9

modern generation of mainframes have significant amount of microcode function requiring all sorts of tables and other storage structures. when queued i/o was introduced for 370-xa with 3081 ... it was called "bump" storage ... part of memory fenced off from program useage for various microcode functions. a couple past posts mentioning bump storage:
http://www.garlic.com/~lynn/2005i.html#51 Regarding interrupt sharing architectures!
http://www.garlic.com/~lynn/2007h.html#9 21st Century ISA goals?

with respect to using HSA for "internal disk cache" (mentioned in one of the following references) ... in the late 70s, we had done modification to production vm370 systems (that ran production at numerous internal datacenters in the san jose area) to capture disk record requests from the guest systems. the information was used to model various kinds of i/o caching strategies. One of the results was that for all other things being equal ... including total amount of memory devoted to caching ... a global system cache always outperformed any partitioning strategy (channel, controller, individual disk, etc). This was purely based on hit ratios ... independent of the efficiency of microcode storage copy vis-a-vis real I/O mentioned in the following references.

I found that this was analogous to what I had found in the 60s as an undergraduate for "global" LRU versus (partitioned) "local" LRU replacement strategy. recent post mentioning global vis-a-vis local
http://www.garlic.com/~lynn/2008e.html#16 Kernels

misc. collected posts mentioning replacement strategies, caching and/or paging
http://www.garlic.com/~lynn/subtopic.html#wsclock

misc. HSA references from quicky search engine use:

Method and system for dynamically changing the size of a hardware system area
http://www.patentstorm.us/patents/5784701-description.html

from above:
The purpose of the HSA is manyfold as it conventionally contains information that is closely associated with different hardware of the data processing system. Typical uses may include, for example, input/output queues, microcode patch areas and buffers for interprocessor communications.

.. snip ...

S/390 CMOS server I/O: The continuing evolution
http://findarticles.com/p/articles/mi_qa3751/is_199707/ai_n8765034/pg_12

from above:
The internal disk storage cache and associated directories are located in a special portion of main memory known as the hardware system area (HSA). HSA is not accessible by S/390 programs and is only accessible by internal system elements such as CPUs, SAPs, and channels. All operations to the internal disk storage go through the cache. If the operation is a read, the SAP examines the directory to determine whether the requested data are in the cache. If they are, the data are simply copied from one area of main memory (the cache in HSA) to another area of main memory (the area specified by the requesting program). This relatively fast and simple copy of data from one area of memory to another is the reason why internal disk storage has such a large performance advantage over external disk storage subsystems.
... snip ...

http://mainframe-watch-belgium.blogspot.com/

from above:
Recent announcements always had the same message : watch out, the HSA has grown. Now, IBM has changed strategy : it now always reserves 16GB for the HSA. This 16GB falls outside the memory the customer buys for his own use. The HSA reserves space for 4 CSSs, 15 LPs in each CSS and per CSS Subchannel set-0 and Subchannel set-1 MAXDEVICES are set to maximum. How is it implemented ? The customer orders e.g. 112GB of memory, pays for 112GB, has 112GB at his disposal, but the z10 is shipped with 128GB (112GB + 16GB for the HSA).
... snip ...

http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/topic/com.ibm.mq.csqsao.doc/csqsao0407.htm

from above:
Structure struc-name unusable, vector size n1 incorrect, required n2

Explanation: The queue manager cannot use the named CF structure because it has been allocated a list notification vector of size n1, but MQ requires at least size n2. This is probably because there is not enough available hardware storage area (HSA) for the vector.

System Action: The queues that use the CF structure are not usable.

System Programmer Response: You cannot adjust the amount of HSA defined for your processor. Instead, retry the application (or other process) which was attempting to open the shared queue. If the problem persists, contact your IBM support center for assistance.

... snip ...

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Fantasy-Land_Hierarchal_NUMA_Memory-Model_on_Vertical

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Fantasy-Land_Hierarchal_NUMA_Memory-Model_on_Vertical ...
Newsgroups: comp.arch,alt.folklore.computers
Date: Thu, 28 Feb 2008 09:21:33
rpw3@rpw3.org (Rob Warnock) writes:
p.s. Oh, and note the footnote in the chapter on ccNUMA in Greg Phister's "On Clusters" where he admits that an IBM 3081(?) with >4 CPUs is actually ccNUMA, not SMP, though with only ~1.4:1 remote-to-local latency ratio compared to 2-3:1 for SGI's Origin. [I could have the IBM model number wrong, since I don't have the book at hand at the moment.]

prior to 3081 ... 360 & 370 two-processor SMP were actually two independent processor complexes ... with provisions to coordinate memory as one set ... but could also be split and run as two independent processor complexes.

3081 was referred to as "dyadic" ... since the two processors were built into the same box and no longer possible to split into two separate, independent processor complexes. 3084 was two independent 3081s tied together to operate as 4-way smp (but could be split apart and operate as two independent 3081s).

for a little x-over from this thread:
http://www.garlic.com/~lynn/2008e.html#38 Any benefit to programming a RISC processor by hand?

801/risc provided for no cache consistency ... in much the same way that risc simplification was extreme counter reaction to the complexity of future system ... no cache consistency was reaction to heavy performance penalty paid by both 370 and future system for cache consistency.

standard two-way 370 smp cache machine ran machine cycle at .9 times uniprocessor machines ... to allow for x-cache chatter (any actual x-cache invalidates would slow processing down futher). so standard 370 two-way smp basic hardware was rated at 1.8 times a uniprocessor (actual thruput was frequently quoted at 1.3-1.5 times a uniprocessor when x-cache invalidates and smp software overhead was included). cleaving a (two-way) 370 smp to operate as two independent processors ... would automatically bump machine cycle to full speed.

there was never initially any intention to provide single processor version of 308x machine ... however some of the operating systems were slow in upgrading kernel for multiprocessor support ... primarily acp (airline control program, renamed tpf, transaction processing facility, to reflect its heavy use by financial transaction networks). because of acp/tpf issue ... they finally released 3083 ... basically 3081 with 2nd processor removed from the box and machine cycle bumped up to full speed.

3084 4-way operation was resulting in some amount of cache thrashing performance impact (i.e. each cache getting signals from three other caches, rather than one other cache. in the early time-frame of 3084 deployments, there were major operating system efforts to restructure kernel storage allocation for cache line sensitivity ... make sure that kernel data structures were cache-line aligned ... and in units of cache-line. these kernel storage cache-line sensitivity efforts resulted in five+ percent overall system thruput improvement.

going into 3090 with larger number of processors ... they had to resort to driving cache at significantly higher machine cycle than the rest of the machine.

3090 had a different kind of NUMA problem with physical packaging of memory ... i.e. the physical distance of some of the memory was beginning to exceed the design point for latency. to address this issue ... effectively the same memory technology was packaged in two different ways. there was the standard memory storage bus that handled standard instruction operations (cache misses, etc). The additional memory storage as packaged as "expanded storage" ... on a new kind of wider bus. Synchronous processor instructions were used by the kernel to copy pages back&forth between "normal" memory and "expanded storage" memory (as sort of psuedo paging device).

later machine generations got around the physical packaging issue and eliminated physical expanded storage ... however, there retained microcode configuration operations to simulate "expanded storage" using regular memory ... finding that splitting the memory into two different categories alleviated problems in kernel page replacement algorithm implementations (with performance guidelines about "expanded storage" configurations continuing up into this decade).

a different issue regarding partitioning memory is discussed in this post regarding recent z10 announcement
http://www.garlic.com/~lynn/2008e.html#39 z10 presentation on 26 Feb

involving "HSA" and its use as system-wide disk cache ... with some discussion of global LRU replacement vis-a-vis (partitioned) local LRU replacement.

misc. past posts mentioning SMP operation
http://www.garlic.com/~lynn/subtopic.html#smp

above also mentions working with charlie at the science center when he invented compare&swap instruction.

for other cluster topic drift
http://www.garlic.com/~lynn/2000c.html#21 Cache coherence [was Re: TF-1]
http://www.garlic.com/~lynn/2001n.html#83 CM-5 Thinking Machines, Supercomputers
http://www.garlic.com/~lynn/2006w.html#40 Why so little parallelism?
http://www.garlic.com/~lynn/2006w.html#41 Why so little parallelism?

on this topic of work we were doing in ha/cmp scaleup
http://www.garlic.com/~lynn/subtopic.html#hacmp
and old MEDUSA, cluster-in-a-rack email
http://www.garlic.com/~lynn/lhwemail.html#medusa

there is possible some justification for transferring the project and being told to not work on anything with more processors ... related to this comment about fall-out of future system failure:
http://www.garlic.com/~lynn/2001f.html#33

since we weren't just restricting cluster-in-a-rack scaleup to numerical intensive ... but were also working on commercial applications ... old reference
http://www.garlic.com/~lynn/95.html#13
http://www.garlic.com/~lynn/96.html#15

more recent reference discussing scaleup for cluster distributed lock manager
http://www.garlic.com/~lynn/2008b.html#69 How does ATTACH pass address of ECB to child?
http://www.garlic.com/~lynn/2008c.html#81 Random thoughts

another recent mention of SCI for numa implementation:
http://www.garlic.com/~lynn/2008e.html#24 Berkeley researcher describes parallel path

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

IBM announced z10 ..why so fast...any problem on z 9

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM announced z10 ..why so fast...any problem on z 9
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 28 Feb 2008 13:15:11
Quadibloc <jsavard@ecn.ab.ca> writes:
But Itanium-based servers in particular are being advertised as a way to achieve mainframe-like reliability. IBM provides an alternative type of mainframe, the AS/400, or, now, the iSystem, built on the PowerPC. With suitable software, x86 servers can handle mainframe tasks, and they're cost-effective where applicable.

there were the killer-micro stories from the 90s ... that were going to replace all the mainframes:
http://www.garlic.com/~lynn/2004p.html#12 360 longevity, was RISCs too close to hardware?
http://www.garlic.com/~lynn/2006.html#47 "VAX" Tradename reused !
http://www.garlic.com/~lynn/2007u.html#19 Distributed Computing
http://www.garlic.com/~lynn/2007u.html#21 Distributed Computing

part of the mainframe issues go well behond things like hardware reliability and/or even software reliability ... there is whole genre of industrial strength dataprocessing that requires some amount of additional features (in some cases people get into situations where they don't even know what it is they don't know about the subject).

some of this can be seen in recent posts about unix ports to 370/mainframe during the 80s ... were mostly deployed on vm/370 platforms. part of this was that mainframe field service people required a minimum level of EREP & RAS support ... which didn't exist in unix (aka adding EREP & RAS features to unix port was an effort several times larger than just port itself). deployments on vm/370 would rely on vm/370 to provide the necessary EREP & RAS function.
http://www.garlic.com/~lynn/2008c.html#53 Migration from Mainframe to othre platforms - the othe bell?
http://www.garlic.com/~lynn/2008c.html#54 Migration from Mainframe to othre platforms - the othe bel?
http://www.garlic.com/~lynn/2008d.html#47 Linux zSeries questions

we got on the other side of this with our ha/cmp product
http://www.garlic.com/~lynn/subtopic.html#hacmp
getting involved with things like continuous availability .... coining the terms disaster survivability and geographic survivability when were were out marketing (to differentiate from disaster/recovery)
http://www.garlic.com/~lynn/submain.html#available

we even got asked to write a section in the corporate continuous availability strategy document ... which got pulled when POK (mainframe) and rochester (as/400) complained about not being able to meet what we were doing.

for other drift ... recent reference doing ha/cmp scaleup
http://www.garlic.com/~lynn/2008e.html#4 Migration from Mainframe to othre platforms - the othe bell?
http://www.garlic.com/~lynn/2008e.html#40 Fantasy-Land_Hierarchal_NUMA_Memory-Model_on_Vertical ...

with reference to this meeting mentioned in these posts
http://www.garlic.com/~lynn/95.html#13
http://www.garlic.com/~lynn/96.html#15

two of the people in the above people ... later show up at at a small client/server startup responsible for something called the commerce server. we got asked to come in to consult on being able to do payment transactions on their servers ... which is frequently now referred to as electronic commerce. part of this involved the servers interfacing to something called payment gateway
http://www.garlic.com/~lynn/subnetwork.html#gateway

during this effort, we would comment that it typically takes 4-to-10 times the effort of doing a well-designed, well-implemented, and well-tested application and turn it into an industrial strength service. we claimed that the webserver/gateway operation was one such example ... that it took nearly ten times the original implementation effort ... to add the necessary industry strength service characteristics.

misc. past posts mentioning the 4-10 times effort for industrial strength dataprocessing:
http://www.garlic.com/~lynn/aadsm25.htm#37 How the Classical Scholars dropped security from the canon of Computer Science
http://www.garlic.com/~lynn/aadsm27.htm#48 If your CSO lacks an MBA, fire one of you
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/2002n.html#11 Wanted: the SOUNDS of classic computing
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/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
http://www.garlic.com/~lynn/2007o.html#23 Outsourcing loosing steam?
http://www.garlic.com/~lynn/2007p.html#54 Industry Standard Time To Analyze A Line Of Code
http://www.garlic.com/~lynn/2007v.html#53 folklore indeed

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Banks failing to manage IT risk - study

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Banks failing to manage IT risk - study
Newsgroups: alt.folklore.computers
Date: Thu, 28 Feb 2008 13:38:07
Banks failing to manage IT risk - study
http://www.finextra.com/fullstory.asp?id=18159

from above:
A separate study from Datamonitor released earlier this year suggests that the sub-prime crisis will spur banks to increase spending on operational risk technology from $754 million in 2007 to over $1 billion in 2010 - an average annual increase of almost 12%.
... snip ...

in Bernanke's testimony this morning ... they asked why Federal Reserve wasn't able to prevent financial institutions getting all bolixed up in the toxic CDO crisis ... as well as why didn't Basel II help ... a little wiki basel II drift:
http://en.wikipedia.org/wiki/Basel_II

excuse given for Basel II not helping, was that it relied on numbers from the securities/bond/cdo rating institutions

recent reference to somebody recommending Chinese financial funds based on better "governance" allowed them to avoid most of the toxic CDO mess:
http://www.garlic.com/~lynn/2008d.html#85 Toyota Sales for 2007 May Surpass GM

so far i haven't heard the words Glass-Steagall ... some recent posts
http://www.garlic.com/~lynn/2008b.html#12 Computer Science Education: Where Are the Software Engineers of Tomorrow?
http://www.garlic.com/~lynn/2008c.html#11 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008c.html#87 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008d.html#85 Toyota Sales for 2007 May Surpass GM

old standby post on the subject of information security and risk management:
http://www.garlic.com/~lynn/aepay3.htm#riskm The Thread Between Risk Management and Information Security

other recent posts referencing the above post
http://www.garlic.com/~lynn/2008.html#66 As Expected, Ford Falls From 2nd Place in U.S. Sales
http://www.garlic.com/~lynn/2008.html#70 As Expected, Ford Falls From 2nd Place in U.S. Sales
http://www.garlic.com/~lynn/2008.html#71 As Expected, Ford Falls From 2nd Place in U.S. Sales
http://www.garlic.com/~lynn/2008.html#78 As Expected, Ford Falls From 2nd Place in U.S. Sales
http://www.garlic.com/~lynn/2008b.html#14 on-demand computing
http://www.garlic.com/~lynn/2008c.html#13 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008d.html#38 outsourcing moving up value chain

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

fraying infrastructure

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: fraying infrastructure
Newsgroups: alt.folklore.computers
Date: Thu, 28 Feb 2008 22:52:32
apparently it is not just the internet infrastructure that is fraying ... maintenance and investment has been neglated in many areas that are falling into disrepair ... transportation, ports, power, etc

U.S. Infrastructure Needs Billions Of Investment, Executives Warn
http://www.informationweek.com/news/showArticle.jhtml?articleID=206900902

... one of the areas mentioned in the article:
"There is neither the money nor the political will to build another interstate highway system," Moorman said. "It doesn't seem like there is the money or the will to keep the one we have got in good repair, let alone add any substantial amount of capacity to the highway system."
... snip ...

misc. post mentioning fraying infrastructure
http://www.garlic.com/~lynn/2007q.html#18 Fixing our fraying Internet infrastructure
http://www.garlic.com/~lynn/2007q.html#19 Fixing our fraying Internet infrastructure
http://www.garlic.com/~lynn/2007q.html#60 Fixing our fraying Internet infrastructure
http://www.garlic.com/~lynn/2007q.html#62 Fixing our fraying Internet infrastructure
http://www.garlic.com/~lynn/2007r.html#25 Fixing our fraying Internet infrastructure
http://www.garlic.com/~lynn/2007r.html#53 Fixing our fraying Internet infrastructure
http://www.garlic.com/~lynn/2007r.html#58 Fixing our fraying Internet infrastructure
http://www.garlic.com/~lynn/2007r.html#59 Fixing our fraying Internet infrastructure
http://www.garlic.com/~lynn/2007r.html#60 Fixing our fraying Internet infrastructure
http://www.garlic.com/~lynn/2007r.html#70 Latest OECD broadband data puts US in middle of the pack on speed, price
http://www.garlic.com/~lynn/2007s.html#1 Translation of IBM Basic Assembler to C?
http://www.garlic.com/~lynn/2007s.html#25 Translation of IBM Basic Assembler to C?
http://www.garlic.com/~lynn/2007t.html#0 Newsweek article--baby boomers and computers
http://www.garlic.com/~lynn/2007t.html#1 Newsweek article--baby boomers and computers
http://www.garlic.com/~lynn/2007t.html#12 Translation of IBM Basic Assembler to C?
http://www.garlic.com/~lynn/2007t.html#13 Newsweek article--baby boomers and computers
http://www.garlic.com/~lynn/2007t.html#50 Newsweek article--baby boomers and computers
http://www.garlic.com/~lynn/2007u.html#19 Distributed Computing
http://www.garlic.com/~lynn/2007u.html#63 folklore indeed
http://www.garlic.com/~lynn/2007v.html#25 Newsweek article--baby boomers and computers
http://www.garlic.com/~lynn/2008.html#90 Computer Science Education: Where Are the Software Engineers of Tomorrow?
http://www.garlic.com/~lynn/2008d.html#80 The Economic Impact of Stimulating Broadband Nationally
http://www.garlic.com/~lynn/2008e.html#19 MAINFRAME Training with IBM Certification and JOB GUARANTEE

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

insider fraud

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: insider fraud
Newsgroups: alt.folklore.computers
Date: Fri, 29 Feb 2008 09:04:07
another case from news today:

MF Global to review order entry systems after $141.5m rogue trading loss
http://www.finextra.com/fullstory.asp?id=18161
Wheat trader for MF Global loses $141.5 million in unauthorized trading
http://www.iht.com/articles/2008/02/29/business/29trader.php

in the early 80s there was work on collusion countermeasures ... aka multi-party operations were countermeasure to insider fraud ... which was being countered by insider collusion.

since then insiders have continued to be the major source of problems, but there has been a lot of distraction in popular news regarding internet.

other recent posts mentioning insider problems, multi-party operations, collusion countermeasures, etc:
http://www.garlic.com/~lynn/2008.html#4 folklore indeed
http://www.garlic.com/~lynn/2008.html#5 folklore indeed
http://www.garlic.com/~lynn/2008.html#9 folklore indeed
http://www.garlic.com/~lynn/2008.html#36 1970s credit cards, was: 1975 movie "Three Days of the Condor" tech stuff
http://www.garlic.com/~lynn/2008b.html#26 folklore indeed
http://www.garlic.com/~lynn/2008b.html#82 Break the rules of governance and lose 4.9 billion
http://www.garlic.com/~lynn/2008c.html#44 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008c.html#76 Neglected IT Tasks May Have Led to Bank Meltdown
http://www.garlic.com/~lynn/2008c.html#85 Human error tops the list of security threats
http://www.garlic.com/~lynn/2008d.html#9 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008d.html#10 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008d.html#11 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008d.html#26 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008d.html#27 Kerberized authorization service
http://www.garlic.com/~lynn/2008d.html#30 Toyota Sales for 2007 May Surpass GM

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

1975 movie "Three Days of the Condor" tech stuff

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 1975 movie "Three Days of the Condor" tech stuff
Newsgroups: alt.folklore.computers
Date: Fri, 29 Feb 2008 10:00:12
Brian Inglis <Brian.Inglis@SystematicSW.Invalid> writes:
More likely because the corporate "high speed" long distance leased lines were SNA, before tunneling protocols; don't think DECnet supported tunneling, like DECnet over SNA, DECnet over TCP/IP, TCP/IP over SNA, SNA over TCP/IP. BTDTGTSTPI

sna & "high speed"??

some old references to somebody in the communication distributing (one friday) a new internal discussion group on the subject and specified some definitions ...
low-speed <9.6kbits medium-speed 19.2kbits high-speed 56kbits very high-speed 1.5mbits

the next monday i was in conference room on the other side of the pacific that had their own defintions (on posters on the wall of the conference room)
low-speed <20mbits medium-speed 100mbits high-speed 200-300mbits very high-speed >600mbits

part of the problem was that the communication group's current generation of products didn't support 1.5mbits (T1). some customers had (very long in the tooth) 2701 controllers from the 60s that supported T1 and there were small number of special-bid "zirpel" cards for series/1 that would support T1.

we had to go outside the company to get the hardware to support our T1 (and higher speed) links for hsdt
http://www.garlic.com/~lynn/subnetwork.html#hsdt

other old email from the 80s related to nsfnet backbone (& T1)
http://www.garlic.com/~lynn/lhwemail.html#nsfnet

some of this might be associated with this comment about the after effects of failure of future system project in this old post
http://www.garlic.com/~lynn/2001f.html#33

remote 3270 terminal controllers supported 19.2kbits ... old post mentioning working on trying to come up with a competitive product with pu4/pu5 emulator
http://www.garlic.com/~lynn/99.html#67

.... 370x, for host-to-host communication, would support 56kbits.

in the mid-80s, there had been an official corporate strategy document that found no customers with T1 links installed and projected in 8-10 yrs there would only be 200 T1 links installed at customer shops. There was major fallacy in their analysis (possibly motivated by none of their current products having T1 support).

the 370x box had "fat pipe" support ... being able to define a collection of 56kbit links that would work in parallel. the strategy document looked at the number of customer "fat pipe" installations with two 56kbit links, three 56kbit links, four 56kbit links, five 56kbit links, etc. the number of "fat pipes" with five 56kbit links was very small and they found no "fat pipes" with six (or higher) 56kbit links.

The fallacy was T1 link were being tariffed at about the same price as 5 or 6 56kbit links. What had happened was that when the customers got to four or five 56kbit links ... they found it cheaper to move to a full T1 link, using products from other vendors. At the time, a superficial (alternative) customer study easily found 200 T1 installations (supported by products from other vendors) .... something that supposedly wasn't going to happen for another 8-10 yrs.

misc. past posts mentioning "fat pipe" support:
http://www.garlic.com/~lynn/2001.html#4 Sv: First video terminal?
http://www.garlic.com/~lynn/2002j.html#67 Total Computing Power
http://www.garlic.com/~lynn/2003m.html#28 SR 15,15
http://www.garlic.com/~lynn/2003m.html#59 SR 15,15
http://www.garlic.com/~lynn/2004g.html#37 network history
http://www.garlic.com/~lynn/2004l.html#7 Xah Lee's Unixism
http://www.garlic.com/~lynn/2005j.html#59 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2006l.html#4 Google Architecture
http://www.garlic.com/~lynn/2006w.html#21 SNA/VTAM for NSFNET

in the other topic drift ... in the hsdt project ... i had given a hand to the IMS group in STL ... different than this mention of being asked to consult with them on dbms design:
http://www.garlic.com/~lynn/2007.html#email801016
in this post
http://www.garlic.com/~lynn/2007.html#1

in the same time-frame ... the IMS group was growing and STL was bursting at their seams ... and they were looking at moving 300 people from the IMS group into an offsite building. They had looked at supporting them with remote 3270s (multiple terminals on controller running at 19.2kbit) ... and the users found it totally unacceptable. I did the support for a "channel extender" (Network System's HYEPRChannel) box ... that ran over T1 link ... and supported "local" 3270s at the remote site.

a slightly different aspect of SNA support vis-a-vis TCP ... is the internal pathlength & other overhead ... referenced in this recent post:
http://www.garlic.com/~lynn/2008d.html#1

another recent post in the same n.g. referenced performance test of NGE running over TCP was faster than running over SNA.

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

1975 movie "Three Days of the Condor" tech stuff

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 1975 movie "Three Days of the Condor" tech stuff
Newsgroups: alt.folklore.computers
Date: Fri, 29 Feb 2008 10:43:42
Brian Inglis <Brian.Inglis@SystematicSW.Invalid> writes:
There were a few attempts to live communally on cheap moor land. IMHO the climate, culture, and post-war economies were not conducive to US-style hippiedom; hippie seemed to be widely used pejoratively as a synonym for long-haired, good for nothing, lazy yobbos.

there was fairly widespread sterotype of lifestyle being subsidized by living off the public dole ... and/or people doing minimum amount of work to become eligible for unemployment insurance ... and then living off that until it ran out (and then repeating the cycle, unemployment insurance wasn't a last resort type of thing but lifestyle to aspire to).

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

System z10 announcement (in English)

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: System z10 announcement (in English)
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
To: <ibm-main@bama.ua.edu>
Date: Fri, 29 Feb 2008 15:03:32
shmuel+ibm-main@PATRIOT.NET (Shmuel Metz , Seymour J.) writes:
I was the one advocating Script for word processing, not John. If IBM ever ports the products to Linux or OS/2, I'll start using them at home.

original script was done at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

for (cp67) cms, in the mid-60s ... carry over from ctss application ... used "run-off" like "dot" commands (i may even still have an old, hardcopy script manual in a box someplace). reference to the CTSS command
http://web.mit.edu/Saltzer/www/publications/CC-244.html

gml was invented at the science center in 1969 ("g", "m", and "l" are initials of the last names of the three people involved) and a decade or so later went thru the international standardization process for sgml
http://xml.coverpages.org/sgmlhist0.html
http://www.sgmlsource.com/history/roots.htm
other post posts mentioning gml, sgml, etc
http://www.garlic.com/~lynn/submain.html#sgml

gml tag processing had been added to script ... and for quite some time ... you could find documents that contained a mixture of "dot" formating commands and gml "tags".

the cp67 and vm370 documents were done with script ... and its use perculated into the rest of the company. one of the first such use was for principles of operation ... which had two flavors ... that could be controlled with cms command line option ... producing either the "full" architecture manual or the principles of operation subset.

univ. of waterloo did a lot of vm370/cms based stuff ... including a script clone ... which found its way to a number of customer installations ... the following discusses the evolution at cern from sgml into html:
http://infomesh.net/html/history/early/
and cern sister lab, SLAC had the first webserver outside of europe, on the slac/vm system
http://www.slac.stanford.edu/history/earlyweb/history.shtml
waterloo script page
http://csg.uwaterloo.ca/sdtp/watscr.html

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

fraying infrastructure

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: fraying infrastructure
Newsgroups: alt.folklore.computers
Date: Fri, 29 Feb 2008 18:37:33
re:
http://www.garlic.com/~lynn/2008e.html#43 fraying infrastructure

related recent post:
http://www.garlic.com/~lynn/2008e.html#13 Nat'l Surface Transportion Policy & Revenue Study Cmsn

lots of the stuff requires deferred maintenance ... sometimes for decades ... to get into the state they are in. other posts mention gov. agencies diverting funds to pet projects that should have been used for maintenance purposes.

highway, bridge, and transit conditions and performance: 1993 (tables of conditions from 83-91)
http://www.tfhrc.gov/pubrds/summer93/p93su8.htm

here is gov report from '95 that 35 percent of the (just the) bridges in the country are classified as deficient
http://www.tfhrc.gov/pubrds/summer95/p95su23.htm

the problem was going on decades old at that time ... and it hasn't changed.

re:
http://www.garlic.com/~lynn/2006h.html#0 The Pankian Metaphor

the above has reference to this more recent URL
http://www.fhwa.dot.gov/hfl/about.cfm

with quote about nearly 1/3rd of the bridges in the country are either structurally deficient or functionally obsolete ... there are some number of other references.

there was article that federal trust fund may have additional problems (more than they already have) because gasoline tax hasn't been increased since 1993 ... so it hasn't kept up with inflation and increased fuel efficiency cuts down on gas used ... but doesn't necessary decrease the maintenance required for the (highway, bridge, etc) infrastructure (including wear&tear).

alternative funding suggestion is to go to miles-driven ... as opposed to gallons used. however, that may start to skate too close to wear&tear miles-driven ... aka heavy trucking which accounts for nearly all wear&tear miles-driven.

from road design document ... quoted several times in the "The Pankian Metaphor" thread:
Pavement structural sections are designed to carry the projected truck traffic considering the expanded truck traffic volume, mix, and the axle loads converted to 80 kN equivalent single axle loads (ESAL's) expected to occur during the design period. The effects on pavement life of passenger cars, pickups, and two-axle trucks are considered to be negligible.
... snip ...

comments from several sides conjecture that starting to adequately account for & fund highway infrastructure ... may improve things for the nations railroads ... since they are much more efficient (than heavy trucking) from many standpoints ... at least gas mileage efficiency per ton moved ... but also infrastructure maintenance.

furthermore, reduction in heavy truck useage reduces the fraying of the highway/bridge infrastructure.

one indication of the effect of heavy truck useage ... is the whole highway weigh station operation ... i.e. existance of weigh stations points to widespread proclivity for heavy truck operators to exceed highway design point ... if they can get away with it (further increasing their significant wear&tear on the infrastructure).

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Any benefit to programming a RISC processor by hand?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Any benefit to programming a RISC processor by hand?
Newsgroups: comp.arch
Date: Sat, 01 Mar 2008 14:14:36
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
That's not true. Line for line, assembly language is comparable with any other more-or-less unchecked language (such as C) and not all that much worse than loosely checked languages (like C++ and Fortran). The key is disciplined design and coding.

previous post in thread:
http://www.garlic.com/~lynn/2008e.html#38 Any benefit to programming a RISC processor by hand?

i've some amount of 360/370 assembler kernel coding as well as problem determination applications ... which looked at frequency and types of failures. in the assembly kernel there tended to be quite a lot of failures around

1) register value correctness ... lots of complicated code paths ... not all of which provided the correct values in registers needed by later instructions

2) asynchronous event serialization ... including failures involving dangling storage references

because of coding and system conventions there were almost no buffer length related problems ... not because it wasn't possible in assembler to have such problems, ... but the way coding and buffer length conventions were handled ... it took significant effort to mess up.

by comparison ... C language programming environment has had enormous problems with buffer length problems ... which for a long time the number one cause of internet exploits. lots of past posts discussing this subject
http://www.garlic.com/~lynn/subintegrity.html#overflow

i've also been involved in doing a tcp/ip protocol stack product implementation in pascal ... for which i know of no known length problems. it wasn't that it was impossible to make a buffer length mistake in pascal ... but the language and conventions made it extremely difficult to messup lengths (by comparison ... common c language environment implementations have enormous numbers of such problems).

i had also done a 360/370 assembler program analysis application ... which would process 360/370 program assembler listings ... and create abstract representation of the instruction and code flow. it would then look for things like specific code paths that failed to at least initialize registers with any values ... where the register was later referenced. i also attempted to generate a "higher level" language psuedo code representation of the 360/370 programs. One of the issues was that there were some highly optimzied assembler programs that appeared to be relatively straight-forward in assembler ... but the psuedo code representation become horribly convoluted (using traditional if/then/else, do/while/until, etc conditional constructs and avoiding GOTOs). Part of the issue were 360/370 instructions resulting in 4-value status/logic ... with all four instruction paths implemented (instead of simpler binary logic) ... and part of it was GOTO/branches can sometimes actually result in more easily understandable logic.

keeping 100k or two of kernel assembler code straight wasn't so bad ... it was when other people messed with the code. i've been known to carefully construct a few instruction sequence in one routine ... where some other code in another routine, at a much later point would have an implicit dependency. somebody not having intimate familiarity with all couple hundred thousand lines of kernel assembler ... might make a modification ... resulting in all sorts of unanticipated and inexplicable side-effects (in some cases happening a decade or more later).

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

fraying infrastructure

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: fraying infrastructure
Newsgroups: alt.folklore.computers
Date: Sat, 01 Mar 2008 17:26:25
Dav Vandenbroucke <dav_and_frances_vandenbroucke@compuserve.com> writes:
I wouldn't be surprised if it has always been true. People ignore infrastructure as long as it is working and then react in a frenzy when it breaks. Building the interstate system was probably the exceptional period, not now.

re:
http://www.garlic.com/~lynn/2008e.html#43 fraying infrastructure
http://www.garlic.com/~lynn/2008e.html#48 fraying infrastructure

"people" (as in general "public") may ... the issue frequently is whether the responsible individuals/organizations also ignore it ... one may conjecture that it may be related to the quality of the responsible parties.

i remember as a kid seeing track maintenance crews every summer out west ... and then moving to boston area ... seeing tracks that hadn't had maintenance in couple decades.

it usually seems to be a case of individuals/groups that believe that they can get away with something and let the consequences be somebody else's problem.

there was a case in cal. with puc allowing utility company revenue to cover regular shrub and tree limb clearing around power lines. however, for a couple of years ... the fund apparently was instead used for executive bonuses. this came to light when some houses burned down after fires started by power lines.

it would be tempting to place it on par with other kinds of insider threats ... or the comptroller general's observation that it has apparently been 50yrs since anybody in congress has been capable of simple middle school arithmatic.

misc. past posts mentioning railroad track maintenance or other kinds of maintenance failures
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/2006g.html#35 The Pankian Metaphor
http://www.garlic.com/~lynn/2007j.html#22 IBM Unionization
http://www.garlic.com/~lynn/2007u.html#32 What do YOU call the # sign?

along similar lines, this mentions failure of various pension funds because of inadequate funding (aka *not* fully funded pension plans) ... one might conjecture that "inadequate funding" involved funds being used for other purposes
http://www.garlic.com/~lynn/2006g.html#36 The Pankian Metaphor

another variation on the theme
http://www.garlic.com/~lynn/2008e.html#42 Banks failing to manage IT risk - study

for totally other drift ... post mentioning jacks that were used in railroad track maintenance activity:
http://www.garlic.com/~lynn/2007u.html#46 What do YOU call the # sign?

I've done quite a bit of dataprocessing stuff in support of avoiding problems and/or providing automagic handling of problems ... so that users aren't even aware of all the possible pitfalls that surround them ... and not being appreciated because it made things appear to be so easy (they never saw the problems avoided).

and by comparison ... other operations that constantly experienced difficulties were preceived as having a much more difficult task ... as opposed to being significantly less capable.

for even more topic drift ... the 4-10 times effort theme for turning well done application into a service
http://www.garlic.com/~lynn/2008e.html#41 IBM announced z10 ..why so fast...any problem on z 9

for instance with respect to the payment gateway activity ... that is associated with what is now commingly referred to as electronic commerce
http://www.garlic.com/~lynn/subnetwork.html#gateway

i once did a series of 2000 automated benchmarks that took three months elapsed time to run ... as part of calibrating and validating the resource manager ... as part of preperation for product release
http://www.garlic.com/~lynn/submain.html#benchmark

i then refused to provide monthly maintenance release ... instead, claiming that I could only do maintenance release every three months because of the extensive QA that I needed to be do before every ship.

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

was: 1975 movie "Three Days of the Condor" tech stuff

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: was: 1975 movie "Three Days of the Condor" tech stuff
Newsgroups: alt.folklore.computers
Date: Sun, 02 Mar 2008 13:35:32
Anne & Lynn Wheeler <lynn@garlic.com> writes:
the issue in the late 90s at the height of the internet bubble ... was that over half of US technical Phd graduates were foreign born.

re:
http://www.garlic.com/~lynn/2008e.html#37 was: 1975 movie "Three Days of the Condor" tech stuff

one scenario is that in transition to knowledge economy ... technical Phds become the new mercenaries/samurais
http://www.garlic.com/~lynn/2008d.html#38 outsourcing moving up value chain

established operations become less critical ... agility and ability to quickly adapt become more critical ... ala Boyd and OODA-loops
http://www.garlic.com/~lynn/subboyd.html#boyd2

fixed physical fortifications become less critical ... and maneuver warfare becomes more important
http://www.garlic.com/~lynn/2008b.html#71 was: 1975 movie "Three Days of the Condor" tech stuff
http://www.garlic.com/~lynn/2008c.html#9 was: 1975 movie "Three Days of the Condor" tech stuff
http://www.garlic.com/~lynn/2008c.html#38 was: 1975 movie "Three Days of the Condor" tech stuff

in dynamic, changing environment ... what an automobile company sold last year ... becomes less of issue, if they can go from drawing board to rolling off the line in 12-18 months (rather than 7-8 yrs).
http://www.garlic.com/~lynn/2008.html#86 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008c.html#46 Toyota Beats GM in Global Production
http://www.garlic.com/~lynn/2008c.html#56 Toyota Beats GM in Global Production
http://www.garlic.com/~lynn/2008c.html#68 Toyota Beats GM in Global Production

however, just new/different doesn't necessarily mean better ... some of the major failed projects in the 90s attempting to leverage massively parallel for large financial infrastructures found that out.
http://www.garlic.com/~lynn/2008b.html#74 Too much change opens up financial fault lines
http://www.garlic.com/~lynn/2008d.html#87 Berkeley researcher describes parallel path

other recent competitiveness related posts
http://www.garlic.com/~lynn/2008.html#39 competitiveness
http://www.garlic.com/~lynn/2008.html#62 competitiveness
http://www.garlic.com/~lynn/2008.html#73 Computer Science Education: Where Are the Software Engineers of Tomorrow?
http://www.garlic.com/~lynn/2008.html#87 Computer Science Education: Where Are the Software Engineers of Tomorrow?
http://www.garlic.com/~lynn/2008b.html#6 Science and Engineering Indicators 2008
http://www.garlic.com/~lynn/2008b.html#78 Move over US -- China to be new driver of world's economy and innovation
http://www.garlic.com/~lynn/2008c.html#50 Migration from Mainframe to othre platforms - the othe bell?
http://www.garlic.com/~lynn/2008d.html#16 more on (the new 40+ yr old) virtualization
http://www.garlic.com/~lynn/2008d.html#41 COTS software on box ? to replace mainframe was Re: Curious(?) way to ZIP a mainframe file
http://www.garlic.com/~lynn/2008d.html#59 more on (the new 40+ yr old) virtualization
http://www.garlic.com/~lynn/2008d.html#86 U.S. Science Funding Hits a Political Wall
http://www.garlic.com/~lynn/2008e.html#45 1975 movie "Three Days of the Condor" tech stuff

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Any benefit to programming a RISC processor by hand?

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Any benefit to programming a RISC processor by hand?
Newsgroups: comp.arch,comp.programming
Date: Sun, 02 Mar 2008 14:08:51
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
I have no idea what the "RISC purists" are smoking, but I don't think discussing their dogmas is worthwhile. ARM is at least as clean and simple as almost any of the other modern "RISC" designs. As we have discussed before, so was the basic instruction set of the System/360, which is a pretty damning indictment of what the excellent principle of RISC got turned into :-(

as i've said before ...
http://www.garlic.com/~lynn/2008e.html#38 Any benefit to programming a RISC processor by hand?

i've claimed that the person that originated 801/risc
http://www.garlic.com/~lynn/subtopic.html#801

was reacting to the significant hardware complexity of the failed future system project
http://www.garlic.com/~lynn/submain.html#futuresys

which was to be the replacement for all 360s.

during the 70s, there were various discussion that 801/risc would make hardware/software complexity trade-off in favor of much simpler hardware and much more complex software.

in the intervening 30+ yrs ... RISC has been applied to a variety of things ... quite a few evolving to less & less KISS over the years.

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Why Is Less Than 99.9% Uptime Acceptable?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Why Is Less Than 99.9% Uptime Acceptable?
Newsgroups: alt.folklore.computers
Date: Sun, 02 Mar 2008 16:50:36
Why Is Less Than 99.9% Uptime Acceptable?
http://ask.slashdot.org/askslashdot/08/03/02/1847213.shtml
Communications: Why do we accept less than 99.999%?
http://www.thestandard.com/news/2008/02/28/communications-why-do-we-accept-less-99-999

one of the things that we looked at with regard to turning an application into a service was RAS ... part of the 4-10 times increase in effort ... a couple recent post:
http://www.garlic.com/~lynn/2008e.html#41 IBM announced z10 ..why so fast...any problem on z 9
http://www.garlic.com/~lynn/2008e.html#50 fraying infrastructure

... and part of what we worked on doing this thing with small client/server startup and is now commingly called electronic commerce
http://www.garlic.com/~lynn/subnetwork.html#gateway

it was surprising the number of kids who had kneejerk response that tcp/ip & the internet were adequately reliable and automatically handle all possible failures; explaining to them the purpose of multiple A-records was met with a stare and/or claim that was much too complex. a few recent posts:
http://www.garlic.com/~lynn/2007h.html#67 SSL vs. SSL over tcp/ip
http://www.garlic.com/~lynn/2007i.html#44 latest Principles of Operation
http://www.garlic.com/~lynn/2007n.html#41 Windows: Monitor or CUSP?
http://www.garlic.com/~lynn/2007p.html#34 what does xp do when system is copying
http://www.garlic.com/~lynn/2007p.html#67 what does xp do when system is copying
http://www.garlic.com/~lynn/2007r.html#13 What do ATMS and card readers use?

we looked at in great detail when we were doing our ha/cmp product
http://www.garlic.com/~lynn/subtopic.html#hacmp

and had come up with geographic survivability and disaster survivability to differentiate from simple disaster/recovery
http://www.garlic.com/~lynn/submain.html#available

some other recent posts:
http://www.garlic.com/~lynn/2008.html#1 LINC-8 Front Panel Questions
http://www.garlic.com/~lynn/2008b.html#33 windows time service
http://www.garlic.com/~lynn/2008b.html#42 windows time service
http://www.garlic.com/~lynn/2008b.html#45 windows time service
http://www.garlic.com/~lynn/2008d.html#21 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008e.html#41 IBM announced z10 ..why so fast...any problem on z 9

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

news maintenance: Prison pushes

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: news maintenance: Prison pushes
Newsgroups: alt.folklore.computers
Date: Sun, 02 Mar 2008 18:49:47
Greg Menke <gusenet@comcast.net> writes:
A decent programming language raises the bar but the issue remains, one hopes a compiler is better at handling derefs better than the programmer but theres always runtime state getting messed up to cause wild pointers no matter what the language.

and/or at least a decent set of conventions.

a little x-over from comp.arch and comp.programming thread
http://www.garlic.com/~lynn/2008e.html#49 Any benefit to programming a RISC processor by hand?

as in the above ... wild pointers showed up in assembler with convoluted execution paths ... and some paths didn't appropriately initialize the registers.

the other case mentioned in the above is serialization/syncronization issues ... resulting in dangling pointers. i had once completely rewrote the serialization/syncronization function in cp67 to get rid of all such problems as well as hung/zombie tasks. later included a similar rewrite as part of the resource manager release for vm370 ... actually, only about ten percent of the resource manager had to do with resource management ... the other 90 percent had to do with various kernel integrity clean-up issues, redoing the serialization/syncronization mechanism to elimiante all hung/zombie tasks and (at least) all the dangling pointers (that had been discovered so far).

slightly other drift ... recent post mentioning RAS, QA, integrity issues
http://www.garlic.com/~lynn/2008e.html#50 fraying infrastructure

and then this RAS related post
http://www.garlic.com/~lynn/2008e.html#53 Why is Less Than 99.9% Uptime Acceptable?

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Google ventures into health records biz

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Google ventures into health records biz
Newsgroups: alt.folklore.computers
Date: Sun, 02 Mar 2008 19:51:47
Google ventures into health records biz
http://www.cnn.com/2008/TECH/02/21/google.records.ap/index.html

Google Health, a first look
http://googleblog.blogspot.com/2008/02/google-health-first-look.html
Portability - Our Internet presence ultimately means that through Google Health, you will be able to have access and control over your health data from anywhere. Through the Cleveland Clinic pilot, we have already found great use-cases in which, for example, people spend 6 months of the year in Ohio, and 6 months of the year in Florida or Arizona, and will now be able to move their health data between their various health providers seamlessly and with total control.
... snip ...

The Google backlash at HIMSS
http://healthcare.zdnet.com/?p=754

Reference to Google Health and Data Portability
http://groups.google.com/group/dataportability-public/browse_thread/thread/53899b1b58ae1b11?hl=en

and for some a.f.c. archeology, something from usenet archives mentioning HL7
http://groups.google.com/group/sci.med/browse_thread/thread/5030f6eef7d76464/bfa0808466cebb14?lnk=st&q=hl7#bfa0808466cebb14

which was hspnet-l digest gatewayed from mailing list on bitnet. old reference to medical related bitnet mailing lists
http://pac-its.psu.edu/pub/internexus/MEDLIST.INDEX
more on bitnet mailing lists
http://nethistory.dumbentia.com/nm9107.html

past posts mentioning bitnet (& earn in europe, much of it done with corporate funds):
http://www.garlic.com/~lynn/subnetwork.html#bitnet

was mainframe networking using technology also used in the internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet

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

old email with early '60s internal networking reference vis-a-vis arpanet
http://www.garlic.com/~lynn/2008.html#email781018
in this post
http://www.garlic.com/~lynn/2008.html#59 old internal network references

other bitnet overview and history
http://nethistory.dumbentia.com/bitov.html
wiki bitnet page:
http://en.wikipedia.org/wiki/BITNET

and a medical common/portable data model reference from long ago and far away:
From: beeler@mayo.edu (George Beeler)
Date: 23 Jul 93
To: internet <internet@vaxdev.mayo.edu>

HISPP/MSDS JOINT WORKING GROUP FOR A COMMON DATA MODEL

The Joint Working Group for a Common Data Model will hold its second set of meetings on September 20, and 21 at the Infomart in Dallas, TX. The meetings are being held in conjunction with the HL7 Plenary Meeting scheduled for 9/21- 9/24. Specific locations and times for the Joint Working Group are:

Monday, 9/20/93, 8:30AM - 5:00PM - Infomart Room 1060
Tuesday, 9/21/93, 8:30AM - 5:00PM - Infomart Room 7012

OVERVIEW/BACKGROUND

The Joint Working Group for a Common Data Model is an open standards effort to support the development of a common data model that can be shared by developers of healthcare informatics standards. The Joint Working Group was formed by the Message Standards Developers Subcommittee (MSDS) of the ANSI Healthcare Informatics Standards Planning Panel (HISPP). MSDS is composed of representatives from ACR-NEMA, ASTM, HL7, IEEE-MEDIX, ASC X12N and NCPDP. Participation in the Joint Working Group is open to individual members of any of these standards groups and to other interested parties.

The immediate tasks of the Joint Working Group include the following:

- Develop a draft of a framework for the common data model.

- Have the framework reviewed and adopted by each of the standards bodies which make up MSDS.

- Refine a high-level model of the healthcare domain such that this model can be used in assigning responsibility for developing components of the complete data model.

- Support the efforts of MSDS to define a mechanism whereby the common data model can be reviewed and balloted by any member of an MSDS constituent, regardless of where the data model is developed.

... snip ...

the above data model work has some x-over with metadata reference here:
http://www.garlic.com/~lynn/2008e.html#27 Richard Feynman, the Challenger Disaster, and Software Engineering

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Any benefit to programming a RISC processor by hand?

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Any benefit to programming a RISC processor by hand?
Newsgroups: comp.arch
Date: Mon, 03 Mar 2008 10:05:37
Jan Vorbrüggen <Jan.Vorbrueggen@not-thomson.net> writes:
RSA is dead, long live ECC.

nearly a decade ago, ecdsa was how we could do a iso 14443 compliant contactless card for x9.59 transaction
http://www.garlic.com/~lynn/x959.html#x959

within iso 14443 power profile and subsecond elapsed time meeting transit/metro gate requirements ... aads chip strawman
http://www.garlic.com/~lynn/x959.html#aadsstraw

issue at the time was psuedo random number generator. it took some innovation to get a really inexpensive chip that also had a high quality prng. ecdsa required high quality prng integrated into the chip (or key could be compromised) which rsa didn't.

by comparison, rsa required enormous elapsed time ... or enormous chip circuit area doing 1024bit operations ... which shortened things to just significant elapsed time (along with significant increased power draw).

at the time, i claimed chips w/o high quality prng contributed to rsa hanging on (since a lot of protocols were done anticipating that chipcards were optionally involved)

in the mid-90s we semi-facetiously claimed we were taking a $500 mil-spec chip, doing aggressive cost reduction by 2-3 orders of magnitude while improving the integrity.

misc. past posts in thread:
http://www.garlic.com/~lynn/2008e.html#38 Any benefit to programming a RISC processor by hand?
http://www.garlic.com/~lynn/2008e.html#49 Any benefit to programming a RISC processor by hand?
http://www.garlic.com/~lynn/2008e.html#52 Any benefit to programming a RISC processor by hand?

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Any benefit to programming a RISC processor by hand?

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Any benefit to programming a RISC processor by hand?
Newsgroups: comp.arch,alt.folklore.computers
Date: Mon, 03 Mar 2008 10:40:09
Anne & Lynn Wheeler <lynn@garlic.com> writes:
in the mid-90s we semi-facetiously claimed we were taking a $500 mil-spec chip, doing aggressive cost reduction by 2-3 orders of magnitude while improving the integrity.

re:
http://www.garlic.com/~lynn/2008e.html#56 Any benefit to programming a RISC processor by hand?

i gave talk on assurance (& aads chip strawman) in trusted computing track at 2001 intel developer's forum. person running tpm was in the front row ... and i quipped that it was interesting that over the past couple yrs, the tpm chip had started looking more & more like aads chip strawman.

a couple past posts from period
http://www.garlic.com/~lynn/aadsm5.htm#asrn1
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
http://www.garlic.com/~lynn/aadsm5.htm#asrn4

current home page for tcg
https://www.trustedcomputinggroup.org/home

misc. other past posts mentioning the talk
http://www.garlic.com/~lynn/aadsm15.htm#6 x9.59
http://www.garlic.com/~lynn/aadsm28.htm#12 #4.2 Simplicity is Inversely Proportional to the Number of Designers
http://www.garlic.com/~lynn/2005g.html#36 Maximum RAM and ROM for smartcards
http://www.garlic.com/~lynn/2007g.html#61 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007g.html#63 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007l.html#42 My Dream PC -- Chip-Based
http://www.garlic.com/~lynn/2007m.html#20 Patents, Copyrights, Profits, Flex and Hercules
http://www.garlic.com/~lynn/2007v.html#37 Apple files patent for WGA-style anti-piracy tech

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Any benefit to programming a RISC processor by hand?

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Any benefit to programming a RISC processor by hand?
Newsgroups: comp.arch,alt.folklore.computers
Date: Mon, 03 Mar 2008 10:58:44
Jan Vorbrüggen <Jan.Vorbrueggen@not-thomson.net> writes:
RSA is dead, long live ECC.

other archeological drift for this thread ... one of the people credited with originating ecc in the mid-80s was at the same lab as the person that originated risc in the 70s.

misc. other posts in this thread:
http://www.garlic.com/~lynn/2008e.html#38 Any benefit to programming a RISC processor by hand?
http://www.garlic.com/~lynn/2008e.html#49 Any benefit to programming a RISC processor by hand?
http://www.garlic.com/~lynn/2008e.html#52 Any benefit to programming a RISC processor by hand?
http://www.garlic.com/~lynn/2008e.html#56 Any benefit to programming a RISC processor by hand?
http://www.garlic.com/~lynn/2008e.html#57 Any benefit to programming a RISC processor by hand?

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

independent appraisers

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: independent appraisers
Newsgroups: alt.folklore.computers
Date: Mon, 03 Mar 2008 11:23:07
business news channel said that fannie & freddy just announced that appraisers have to be independent.

this was big issue in the s&l crisis in the 80s ... but seems to have been forgotten.

independence was big issue with auditors and problems the early part of this decade ... and also resulted in the audit companies spinning off their consulting businesses (those that survived).

independence was effectively part of the Glass-Steagall act from the early 30s (as reaction to the investment problems in the previous decade) ... which was repealed late in the last century.

it is also behind the (independent) multi-party operations as countermeasure to insider fraud. the crooks response has been collusion ... which then starts to result in collusion countermeasures.

misc. recent posts on the subject:
http://www.garlic.com/~lynn/2008b.html#12 Computer Science Education: Where Are the Software Engineers of Tomorrow?
http://www.garlic.com/~lynn/2008b.html#26 folklore indeed
http://www.garlic.com/~lynn/2008b.html#82 Break the rules of governance and lose 4.9 billion
http://www.garlic.com/~lynn/2008c.html#11 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008c.html#44 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008c.html#76 Neglected IT Tasks May Have Led to Bank Meltdown
http://www.garlic.com/~lynn/2008c.html#87 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008d.html#10 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008d.html#26 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008d.html#27 Kerberized authorization service
http://www.garlic.com/~lynn/2008d.html#30 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008d.html#85 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008e.html#42 Banks failing to manage IT risk - study
http://www.garlic.com/~lynn/2008e.html#44 insider fraud

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

z10 presentation on 26 Feb

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: z10 presentation on 26 Feb
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 03 Mar 2008 12:29:59
Eric Smith <eric@brouhaha.com> writes:
Oh, I imagine that the customer does pay for that 16GB of HSA. IBM isn't in the business of giving away free memory.

re:
http://www.garlic.com/~lynn/2008d.html#91 z10 presentation on 26 Feb
http://www.garlic.com/~lynn/2008e.html#39 z10 presentation on 26 Feb

of course, never a claim that they didn't ... HSA 16GB would be bundled as part of the basic system infrastructure costs (processors, processor cache, interconnect, ras, service processors, channels, etc) ... rather than incremental memory size charges. helps manage the bean counters ... and/or others that don't appreciate infrastructure issues.

we had an old similar but different suggestion with 3380 disk drives. it was fairly straight-forward to profile different data on disk (especially before extensive availability of disk/file caches) as access/sec/mbyte. total disk capacity was increasing much faster than disk arm access/sec thruput ... as a result ... it was becoming easier and easier to bottleneck disk arm access/sec thruput (by overloading disk with too much mbytes that had aggregate access/sec/mbyte profile exceeding disk arm access/sec thruput).

one suggestion was to just leave 3380s containing data (with high-thruput requirements) partially empty. many customers complained that various administrators (in their shops) objected to such a strategy as "wasting" resources (even tho degradation effect on system thruput "waste" might be several times larger).

so the proposed solution was to offer a special "high-performance" 3380 that might have only half the capacity but faster avg arm access (special microcode load that limited the total cylinders that arm would move ... fewer travelled cylinders increased the avg. arm access profile ... and therefor also increased the disk arm access/sec) ... and this special "high-performance" 3380 would have higher cost than regular 3380 (to increase the warm & fuzzy feelings for the customer administrators that they were getting their money worth).

misc. past posts mentioning the 3380 situation:
http://www.garlic.com/~lynn/2001b.html#61 Disks size growing while disk count shrinking = bad performance
http://www.garlic.com/~lynn/2003b.html#67 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003i.html#42 Fix the shuttle or fly it unmanned
http://www.garlic.com/~lynn/2003m.html#43 S/360 undocumented instructions?
http://www.garlic.com/~lynn/2004l.html#14 Xah Lee's Unixism
http://www.garlic.com/~lynn/2005l.html#41 25% Pageds utilization on 3390-09?
http://www.garlic.com/~lynn/2006c.html#6 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006g.html#0 IBM 3380 and 3880 maintenance docs needed
http://www.garlic.com/~lynn/2006n.html#33 CRAM, DataCell, and 3850
http://www.garlic.com/~lynn/2007h.html#6 21st Century ISA goals?
http://www.garlic.com/~lynn/2007k.html#62 3350 failures

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Study Finds Sharp Math, Science Skills Help Expand Economy

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Study Finds Sharp Math, Science Skills Help Expand Economy
Newsgroups: alt.folklore.computers
Date: Mon, 03 Mar 2008 15:43:34
Anne & Lynn Wheeler <lynn@garlic.com> writes:
one scenario is that in transition to knowledge economy ... technical Phds become the new mercenaries/samurais
http://www.garlic.com/~lynn/2008d.html#38 outsourcing moving up value chain


re:
http://www.garlic.com/~lynn/2008e.html#51 was: 1975 movie "Three Days of the Condor" tech stuff

Study Finds Sharp Math, Science Skills Help Expand Economy
http://online.wsj.com/news/articles/SB120452027357807261?mg=reno64-wsj&url=http%3A%2F%2Fonline.wsj.com%2Farticle%2FSB120452027357807261.html

from above:
Nearly two decades ago, the National Governors Association called for U.S. students to sharply improve in math and science by 2000. If the U.S. had managed to achieve the goal, and joined world leaders like Finland, Hong Kong and South Korea, GDP would be two percentage points higher today and 4.5 points higher in 2015, the study calculated. "Had we figured out some way to improve our schools, or do what we could to improve the learning of our students, we would be a lot better off today," said Mr. Hanushek.
... snip ...

other recent posts:
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/2007h.html#42 Experts: Education key to U.S. 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
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
http://www.garlic.com/~lynn/2007o.html#22 U.S. Cedes Top Spot in Global IT Competitiveness
http://www.garlic.com/~lynn/2007p.html#15 U.S. Cedes Top Spot in Global IT Competitiveness
http://www.garlic.com/~lynn/2007p.html#18 U.S. Cedes Top Spot in Global IT Competitiveness
http://www.garlic.com/~lynn/2007p.html#22 U.S. Cedes Top Spot in Global IT Competitiveness
http://www.garlic.com/~lynn/2007p.html#32 U.S. Cedes Top Spot in Global IT Competitiveness
http://www.garlic.com/~lynn/2007u.html#78 Education ranking
http://www.garlic.com/~lynn/2007u.html#80 Education ranking
http://www.garlic.com/~lynn/2007u.html#82 Education ranking
http://www.garlic.com/~lynn/2007v.html#16 Education ranking
http://www.garlic.com/~lynn/2007v.html#19 Education ranking
http://www.garlic.com/~lynn/2007v.html#20 Education ranking
http://www.garlic.com/~lynn/2007v.html#38 Education ranking
http://www.garlic.com/~lynn/2007v.html#39 Education ranking
http://www.garlic.com/~lynn/2007v.html#44 Education ranking
http://www.garlic.com/~lynn/2007v.html#45 Education ranking
http://www.garlic.com/~lynn/2007v.html#51 Education ranking
http://www.garlic.com/~lynn/2007v.html#71 Education ranking
http://www.garlic.com/~lynn/2008.html#39 competitiveness
http://www.garlic.com/~lynn/2008.html#52 Education ranking
http://www.garlic.com/~lynn/2008.html#55 Education ranking
http://www.garlic.com/~lynn/2008.html#60 Education ranking
http://www.garlic.com/~lynn/2008.html#62 competitiveness
http://www.garlic.com/~lynn/2008.html#81 Education ranking
http://www.garlic.com/~lynn/2008.html#83 Education ranking
http://www.garlic.com/~lynn/2008b.html#13 Education ranking

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Any benefit to programming a RISC processor by hand?

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Any benefit to programming a RISC processor by hand?
Newsgroups: comp.arch
Date: Tue, 04 Mar 2008 07:53:10
Jan Vorbrüggen <Jan.Vorbrueggen@not-thomson.net> writes:
Here in Germany, RSA for legally relevant digital signatures requires 2048 bit keys since the beginning of this year. I hear this will be the last key size for RSA to be supported by smart cards - in about five years' time, everthing will need to convert to ECC.

re:
http://www.garlic.com/~lynn/2008e.html#56 Any benefit to programming a RISC processor by hand?
http://www.garlic.com/~lynn/2008e.html#58 Any benefit to programming a RISC processor by hand?

some states passed similar legislation in the 90s. we were brought in to help word-smith cal. state electronic signature legilsation and then later the federal legislation. the lawyers (in both cases) made a big issue that digital signatures having none of the properties of human signatures ... up until then some of the standards bodies had almost been taking digital signature as sufficient for non-repudiation. after then there was quite a bit of work defining properties for non-repudiation ... which were (at least) orthogonal to digital signature properties. it was when we started making the comments about possible enormous semantic confusion just because both of the terms (digital signature and human signature) containing the word signature. misc. past posts
http://www.garlic.com/~lynn/subpubkey.html#signature

way back when ... we got an EAL4+ evaluation by a lab. in germany for a AADS chip strawman with ECC (done by a new fab in dresden). we had wanted to go for a EAL5+ evaluation (or higher) ... since similar chips by other vendors were getting such an evaluation. The "problem" was that we had built ECC into the silicon of the chip ... as a security improvement (i.e. software couldn't be loaded on the chip) ... and there was no EAL5 specification for ECC. Other vendors were getting EAL5 evaluation on the bare chip ... and loading software onto the chip after the evaluation. We claimed that these other chips with EAL5 evaluations ... when deployed ... actually had a much lower security level than our EAL4 evaluated chip (since they needed unevaluated software to be loaded before deployment). That is besides being significantly cheaper, significantly faster and significantly lower power draw.

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Study Finds Sharp Math, Science Skills Help Expand Economy

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Study Finds Sharp Math, Science Skills Help Expand Economy
Newsgroups: alt.folklore.computers
Date: Tue, 04 Mar 2008 07:57:18
jmfbahciv writes:
Sadly, people are still generally assuming that one only needs the piece of paper called a diploma, rather than the learning, to get a job and oodles of money.

re:
http://www.garlic.com/~lynn/2008e.html#61 Study Finds Sharp Math, Science Skills Help Expand Economy

other aspects of dumbing down things?

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Shockwave traffic jam recreated for first time

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Shockwave traffic jam recreated for first time
Newsgroups: alt.folklore.computers
Date: Tue, 04 Mar 2008 10:37:37
Shockwave traffic jam recreated for first time
http://technology.newscientist.com/article/dn13402-shockwave-traffic-jam-recreated-for-first-time.html

from above:
The mathematical theory behind these so-called "shockwave" jams was developed more than 15 years ago using models that show jams appear from nowhere on roads carrying their maximum capacity of free-flowing traffic – typically triggered by a single driver slowing down.
... snip ...

... or at least tapping their brakes ... this is frequently precipitated by small number of aggressive drivers making frequent lane changes ... quickly switching from one lane to another ... and the vehicle, they just cut in front of, forced to tap their breaks.

something similar referenced here
http://www.garlic.com/~lynn/2007v.html#18 Traffic Jam Mystery Solved By Mathematicians

in this article
http://www.sciencedaily.com/releases/2007/12/071219103102.htm

previous posts mentioning the phenomena
http://www.garlic.com/~lynn/2004c.html#17 If there had been no MS-DOS
http://www.garlic.com/~lynn/2005p.html#7 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005p.html#10 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2006p.html#5 sorting
http://www.garlic.com/~lynn/2006p.html#12 sorting
http://www.garlic.com/~lynn/2007e.html#34 Is computer history taught now
http://www.garlic.com/~lynn/2008c.html#5 Toyota Sales for 2007 May Surpass GM

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Banks failing to manage IT risk - study

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Banks failing to manage IT risk - study
Newsgroups: alt.folklore.computers
Date: Tue, 04 Mar 2008 15:13:01
Anne & Lynn Wheeler <lynn@garlic.com> writes:
in Bernanke's testimony this morning ... they asked why Federal Reserve wasn't able to prevent financial institutions getting all bolixed up in the toxic CDO crisis ... as well as why didn't Basel II help ... a little wiki basel II drift:
http://en.wikipedia.org/wiki/Basel_II

excuse given for Basel II not helping, was that it relied on numbers from the securities/bond/cdo rating institutions

recent reference to somebody recommending Chinese financial funds based on better "governance" allowed them to avoid most of the toxic CDO mess:
http://www.garlic.com/~lynn/2008d.html#85 Toyota Sales for 2007 May Surpass GM


re:
http://www.garlic.com/~lynn/2008e.html#42 Banks failing to manage IT risk - study

Bank regulators: 'Asleep at the switch'; Senate banking committee chair blasts regulators for not sounding warning about risky lending practices
http://money.cnn.com/2008/03/04/news/companies/senatebank/index.htm?postversion=2008030412

above reads almost as if banks aren't adults and federal gov. needs to treat them as minors and protect them from themselves.

during Bernanke's talk today to community bankers ... he was asked about closing the ILC "loop-hole" ... possibly drawing attention away from the problems that the standard federal regulated institutions are having. recent posts mentioning ILCs
http://www.garlic.com/~lynn/2008c.html#7 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008c.html#11 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008c.html#12 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008c.html#25 Toyota Sales for 2007 May Surpass GM

also from today:

Citigroup sinks on sovereign wealth fund comments
http://ctv2.theglobeandmail.com/servlet/story/RTGAM.20080304.wcitigroup0304/business/Business/businessBN/ctv-business Sovereign funds may not save Citigroup
http://news.yahoo.com/s/ap/20080304/ap_on_bi_ge/dubai_funds_citigroup;_ylt=AsePivnAVi0glJl3X.JLHk2yBhIF Citigroup Slides
http://www.forbes.com/markets/2008/03/04/citigroup-subprime-dubai-markets-equity-cx_md_0304markets18.html?partner=moreover Sovereign funds may not save Citigroup
http://www.miamiherald.com/business/AP/story/443584.html

from above:
The reason is that Citi is likely to suffer additional losses due to defaulting credit. Having already written down $18 billion in bad mortgage-related debt in the fourth quarter, Merrill Lynch analysts predicted that Citi will have to write down another $18 billion in the first quarter, according to Dow Jones Newswires.
... snip ...

it is now almost 20yrs since citi supposedly almost went under from earlier mortgage lending problems in '89 ... old post
http://www.garlic.com/~lynn/aepay3.htm#riskm The Thread Between Risk Management and Information Security

other recent posts mentioning the above:
http://www.garlic.com/~lynn/2008.html#66 As Expected, Ford Falls From 2nd Place in U.S. Sales
http://www.garlic.com/~lynn/2008.html#70 As Expected, Ford Falls From 2nd Place in U.S. Sales
http://www.garlic.com/~lynn/2008.html#71 As Expected, Ford Falls From 2nd Place in U.S. Sales
http://www.garlic.com/~lynn/2008.html#78 As Expected, Ford Falls From 2nd Place in U.S. Sales
http://www.garlic.com/~lynn/2008b.html#14 on-demand computing
http://www.garlic.com/~lynn/2008c.html#13 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008c.html#87 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008d.html#38 outsourcing moving up value chain

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

independent appraisers

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: independent appraisers
Newsgroups: alt.folklore.computers
Date: Wed, 05 Mar 2008 06:44:01
krw <krw@att.bizzzzzzzzzz> writes:
Do you expect the Spy vs. Spy game to have an end?

re:
http://www.garlic.com/~lynn/2008e.html#59 independent appraisers

Spy vs. Spy is somewhat implying that the attacks and countermeasures are of equal difficulty with equal rewards.

In many of the situations the difficulty of the attacks dramatically increases ... and the economic rewards for the attackers can start to become less than the cost of the attacks ... resulting in the number of vulnerability points that require further measures radically decreases. in some cases the order of the problems drops from billions to thousands to tens.

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

it is also somewhat the theme discussed in this old post
http://www.garlic.com/~lynn/aepay3.htm#riskm The Thread Between Risk Management and Information Security

also mentioned in this recent post
http://www.garlic.com/~lynn/2008e.html#65 Banks failing to manage IT risk - study

for additional topic drift on the theme, frequently mentioned in other posts, in the mid-90s, 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 the x9.59 financial industry standard
http://www.garlic.com/~lynn/x959.html#x959

part of the effort was detailed, end-to-end threat and vulnerability study. one of the vulnerabilities identified was skimming information from transactions and using the information in a form of replay attacks for fraudulent financial transactions. another threat/vulnerability identified was data breaches and security breaches involving retained logs of prior transactions (required by numerous business processes) ... again the crooks would use the information for a form of replay attacks for fraudulent financial transactions. These two combined, represent the majority of the news items related to identity fraud.

The straight-forward solution was to continue to dramatically increase the security and protection of all these points of vulnerability ... which amounts to potentially hundreds of millions of points with potentially billions of attackers. This is somewhat discussed in posts on the theme of dealing with "naked transaction" metaphor:
http://www.garlic.com/~lynn/subintegrity.html#payments

A common countermeasure has been to dramatically increase the use of encryption technologies to deal with the threat. However, because of the enormous numbers of places requiring access and use of the information, we started making the claim that even if the planet was buried under miles of information hiding encryption ... it still wouldn't eliminate the information leakage (drastically increase in countermeasure costs with diminishing protection).

the approach taken in the x9.59 financial transaction standard wasn't attempting to eliminate all those points of leakage ... but to eliminate the usefullness of the information to the crooks for performaing fraudulent transactions (i.e. eliminate the replay attack exploit). x9.59 does nothing to protect against skimming attacks or data breaches and security breaches ... however, the x9.59 financial transaction standard eliminates the usefullnes of any such information obtained by the crooks for performing fraudulent transactions.

Sort of the idea was that the inclusion of such activity in identity fraud statistics has been because the attackers can use the obtained information to perform fraudulent financial transactions (or "account fraud"). The x9.59 financial transaction standard did nothing to prevent the tens of millions of obvious attack points ... it just eliminated those kinds of attacks as a "real" vulnerability ... since the crooks were no longer able to use the information for fraudulent purposes (aka it has made the stealing of the information useless ... where currently the stealing of the information is extremely worthwhile because it can be used to perform fraudulent transactions).

the obvious knee-jerk reaction to the vulnerability has been ever increasing cost of protecting the hundreds of millions of vulnerable points. the x9.59 financial transaction standard approach was to eliminate all those kinds of threats. There are still other ways that crooks can perform fraudulent operations ... but x9.59 drastically reduced the magnitude of what requires additional countermeasures (since a whole category of attacks has been totally eliminated).

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Any benefit to programming a RISC processor by hand?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Any benefit to programming a RISC processor by hand?
Newsgroups: comp.arch,comp.programming
Date: Wed, 05 Mar 2008 07:05:30
Casper H.S. Dik <Casper.Dik@Sun.COM> writes:
Not really because you couldn't have have a multi processor without such instructions. I think the "Reduced" in RISC is more about "as few instructions as you can get away with"; not a forced upperbound to the complexity of instructions. All modern RISCs build for MP systems have such instructions.

charlie had been doing fine-grain locking multiprocessing work on cp67 kernel at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

when he invented the compare&swap instruction (i.e. CAS are charlie's initials ... which then required a corresponding instruction name)
http://www.garlic.com/~lynn/subtopic.html#smp

trying to get the instruction into the 370 architecture was initially rebuffed saying that it was felt that additional multiprocessor specific instructions weren't required. in order to justify compare&swap instruction for 370, uses for the instruction were needed that weren't multiprocessor specific; thus was born the use of the instructions for multi-threaded applications that were enabled for interrupts (i.e. performing atomic operations in multi-thread interruptable applications). several of the examples became the programming notes for the compare&swap instruction in generations (up thru current versions) of (mainframe) principles of operation manual. relative recent version ... section (more recent versions have also added the newer PLO instruction): A.6 Multiprogramming and Multiprocessing Examples:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dz9zr003/A.6?DT=20040504121320

for a long time, 801/risc was no cache consistency ...
http://www.garlic.com/~lynn/subtopic.html#801

and effectively, no multiprocessor operation. this was up thru at least rios/power. The change started to happen with somerset (joint between the austin group, apple, motorolo, etc) ... the executive that we reported to when we were doing our ha/cmp product
http://www.garlic.com/~lynn/subtopic.html#hacmp

went over to head up somerset (later he left somerset to become president of mips).

however, by the time of rios/power (& rs/6000), the compare&swap instruction (or instructions with similar semantics) was starting to become institutionalized in large multithreaded applications ... like many of the DBMS implementations (even when running on strictly single processor machines). as part of supporting such applications on rs/6000, compare&swap instruction semantics were implemeted with a supervisor call that had a very short fastpath simulation in the supervisor call interrupt handler ... with immediate return to the application.

for other topic drift ... original relational/sql dbms implementation was done on (virtual machine) vm370 (follow-on to cp67)
http://www.garlic.com/~lynn/submain.html#systemr

and leveraged compare&swap instruction in its multi-threaded operation ... aka compare&swap use become somewhat orthogonal to whether it was running on multiprocessor platform or not.

other posts in this thread:
http://www.garlic.com/~lynn/2008e.html#38 Any benefit to programming a RISC processor by hand?
http://www.garlic.com/~lynn/2008e.html#49 Any benefit to programming a RISC processor by hand?
http://www.garlic.com/~lynn/2008e.html#52 Any benefit to programming a RISC processor by hand?
http://www.garlic.com/~lynn/2008e.html#56 Any benefit to programming a RISC processor by hand?
http://www.garlic.com/~lynn/2008e.html#57 Any benefit to programming a RISC processor by hand?
http://www.garlic.com/~lynn/2008e.html#58 Any benefit to programming a RISC processor by hand?
http://www.garlic.com/~lynn/2008e.html#62 Any benefit to programming a RISC processor by hand?

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Computer science graduating class of 2007 smallest this decade

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Computer science graduating class of 2007 smallest this decade
Newsgroups: alt.folklore.computers
Date: Wed, 05 Mar 2008 07:30:28
Anne & Lynn Wheeler <lynn@garlic.com> writes:
one scenario is that in transition to knowledge economy ... technical Phds become the new mercenaries/samurais
http://www.garlic.com/~lynn/2008d.html#38 outsourcing moving up value chain


re:
http://www.garlic.com/~lynn/2008e.html#51

Computer science graduating class of 2007 smallest this decade
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9066659

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

independent appraisers

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: independent appraisers
Newsgroups: alt.folklore.computers
Date: Wed, 05 Mar 2008 08:33:41
krw <krw@att.bizzzzzzzzzz> writes:
Do you expect the Spy vs. Spy game to have an end?

re:
http://www.garlic.com/~lynn/2008e.html#59 independent appraisers
http://www.garlic.com/~lynn/2008e.html#66 independent appraisers

another way of measuring the x9.59 scenario
http://www.garlic.com/~lynn/x959.html#x959

is that the attacker compromises an (point-of-sale) end-point to skim/harvest account numbers
http://www.garlic.com/~lynn/subintegrity.html#harvest

the information is then used for fraudulent transaction at one of possibly tens of millions other end-points located at some random location somewhere else in the world.

the forensics for the fraudulent transaction then attempts to determine which of the tens (or hundreds) of millions of end-points that the compromise actually occured.

the crooks have made some investment in the end-point compromise and are looking to maximize that investment ... hoping to harvest potentially tens (or hundreds) of thousand transactions ... which they then will use to perform fraudulent transactions at other locations in the world (attempting as much as possible to obfuscate the actual point of compromise).

x9.59 eliminates that particular skimming/harvesting vulnerability ... but it doesn't eliminate the general case of all end-point compromises. however, the remaining kinds of end-point compromises are more expensive (for the attacker) and the kinds of exploits possible, involve performing fraudulent activities at the point of compromise. This enormously reduces the forensics involved in identifying a point of compromise ... and drastically reduces the time to take a point of compromise out of service; effectively enormously reducing the possible fraud ROI for an attacker (cost of attack goes up, the benefits of the attack is significantly reduced ... and the elapsed time that the compromise is in place is drastically reduced).

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

for totally other topic drift ... chip&pin recently became mandatory in the UK ... and was projected to reduce the amount of fraud. This article claims that instead of the amount of fraud decreasing, it apparently went up by over 1/3rd:
http://www.thisismoney.co.uk/news/article.html?in_article_id=431514

some old discussions about various kinds of threats, vulnerabilities and exploits
http://www.garlic.com/~lynn/subintegrity.html#yescard

for other related integrity topic drift from comp.arch
http://www.garlic.com/~lynn/2008e.html#56 Any benefit to programming a RISC processor by hand?
http://www.garlic.com/~lynn/2008e.html#58 Any benefit to programming a RISC processor by hand?
http://www.garlic.com/~lynn/2008e.html#62 Any benefit to programming a RISC processor by hand?

and this starts to get back to the periodic reference to a nearly decade old post
http://www.garlic.com/~lynn/aepay3.htm#riskm The Thread Between Risk Management and Information Security

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

independent appraisers

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: independent appraisers
Newsgroups: alt.folklore.computers
Date: Wed, 05 Mar 2008 10:04:50
greymaus <greymausg@mail.com> writes:
Trying to rescue something from the mess. Better to get (x*.8) from the mortagee (sp?) than nothing. there are horror stories of streets being cleared, houses vandalized as they are left empty, and even those who can pay are finding the value of their homes dropping as nearby ones are cleared. Agree about the 'certain amount'. That, AFAIK, is basically what he is doing. Liquid cash is in very low supply.

re:
http://www.garlic.com/~lynn/2008e.html#59 independent appraisers
http://www.garlic.com/~lynn/2008e.html#66 independent appraisers
http://www.garlic.com/~lynn/2008e.html#69 independent appraisers

lots of institutions have been advocating gov. bailout for the poor homeowners. some that having been looking at the problem are having difficulty separating the poor homeowners from the speculators and CDO operations ... for stereotype homeowner scenario .. they also have people who signed for a house ... moved in (or rented it out), never figured on ever making a payment ... figuring to flip the house for large profit. they then also have all the large institutions (who have been the biggest lobbyists for bailouts)

as per previous posts ...
http://www.garlic.com/~lynn/2008b.html#75 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008d.html#0 Toyota Sales for 2007 May Surpass GM

in the past, the fed would lower the interest rate, which would decrease the resistance to borrowing ... resulting in more borrowing and increased economic activity. the current scenario is that there was an over abundance of borrowing already ... some based on enormously bad decisions. even with decreased interest rates ... many of the lenders are retrenching on money they are making available (compared to recent frenzy) ... in part because of recent history of very poor lending decisions.

the leverage of federal interest rates is when majority of economic activity were related to those rates. when lots of economic activity has been decoupled from the federal interest rates ... like the recent spate of subprime mortgages ... changing the official federal interest rates ... has much less effect (especially when lowering the rates is trying to encourage borrowing ... and the recent correction has been because the subprime rates were way too low and there was too much borrowing).

the easy subprime mortgages supported speculation frenzy ... the increased demand for real estate (because of the speculation frenzy) helped significantly boost real estate price inflation, increases in real estate price inflation, further contributes to fueling speculation frenzy. issue is that it isn't a self-substaining situation and then starts to look more & more like a pyramid scheme ... or an analogy used for the toxic CDOs ... musical chairs (and who is going to be left holding the bag).

other recent posts mentioning real estate speculation, subprime mortgages, toxic CDOs, etc:
http://www.garlic.com/~lynn/2007h.html#64 sizeof() was: The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007h.html#66 sizeof() was: The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007i.html#12 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007j.html#48 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#80 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#81 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#82 IBM Unionization
http://www.garlic.com/~lynn/2007k.html#10 IBM Unionization
http://www.garlic.com/~lynn/2007k.html#12 IBM Unionization
http://www.garlic.com/~lynn/2007k.html#51 IBM Unionization
http://www.garlic.com/~lynn/2007o.html#0 The Unexpected Fact about the First Computer Programmer
http://www.garlic.com/~lynn/2007p.html#50 Newsweek article--baby boomers and computers
http://www.garlic.com/~lynn/2007q.html#28 what does xp do when system is copying
http://www.garlic.com/~lynn/2007q.html#41 Newsweek article--baby boomers and computers
http://www.garlic.com/~lynn/2007r.html#29 The new urgency to fix online privacy
http://www.garlic.com/~lynn/2007r.html#54 The new urgency to fix online privacy
http://www.garlic.com/~lynn/2007r.html#58 Fixing our fraying Internet infrastructure
http://www.garlic.com/~lynn/2007r.html#60 Fixing our fraying Internet infrastructure
http://www.garlic.com/~lynn/2007s.html#1 Translation of IBM Basic Assembler to C?
http://www.garlic.com/~lynn/2007s.html#25 Translation of IBM Basic Assembler to C?
http://www.garlic.com/~lynn/2007s.html#28 Translation of IBM Basic Assembler to C?
http://www.garlic.com/~lynn/2007t.html#7 Identity Theft Prevention tips
http://www.garlic.com/~lynn/2007t.html#12 Translation of IBM Basic Assembler to C?
http://www.garlic.com/~lynn/2007t.html#50 Newsweek article--baby boomers and computers
http://www.garlic.com/~lynn/2007v.html#25 Newsweek article--baby boomers and computers
http://www.garlic.com/~lynn/2008.html#66 As Expected, Ford Falls From 2nd Place in U.S. Sales
http://www.garlic.com/~lynn/2008.html#70 As Expected, Ford Falls From 2nd Place in U.S. Sales
http://www.garlic.com/~lynn/2008.html#90 Computer Science Education: Where Are the Software Engineers of Tomorrow?
http://www.garlic.com/~lynn/2008b.html#12 Computer Science Education: Where Are the Software Engineers of Tomorrow?
http://www.garlic.com/~lynn/2008c.html#11 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008c.html#13 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008c.html#20 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008c.html#21 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008c.html#25 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008c.html#63 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008c.html#87 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008d.html#10 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008d.html#85 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008e.html#42 Banks failing to manage IT risk - study
http://www.garlic.com/~lynn/2008e.html#65 Banks failing to manage IT risk - study

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

US aerospace and defense sector braces for potential brain drain as Cold War workers retire

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: US aerospace and defense sector braces for potential brain drain as Cold War workers retire
Newsgroups: alt.folklore.computers
Date: Wed, 05 Mar 2008 10:57:23
earlier part of this century ... one of the major financial transaction operations identified retiring workers as their major risk ... i.e. loosing the people with 30-40 yrs experience, responsible for putting the existing infrastructure in place, and possibly the only ones that understood why things are the way they are.

US aerospace and defense sector braces for potential brain drain as Cold War workers retire
http://www.technologyreview.com/Wire/20374/

from above:
The problem -- almost 60 percent of U.S. aerospace workers in 2007 were 45 or older -- could affect national security and even close the door on commercial products that start out as military technology, industry officials said.
... snip ...

another reference: Aerospace Industry Faces Coming Worker Shortage
http://www.redorbit.com/news/space/1281235/aerospace_industry_faces_coming_worker_shortage/index.html

this is similar to recent references in the petroleum industry regarding major projects being cut by 1/3rd to 1/2 because the experienced workers will be retiring before projects have completed:
http://www.garlic.com/~lynn/2007q.html#42 Newsweek article--baby boomers and computers
http://www.garlic.com/~lynn/2007s.html#32 Newsweek article--baby boomers and computers
http://www.garlic.com/~lynn/2007s.html#63 Newsweek article--baby boomers and computers

this references similar problem in the mining industry:
http://www.garlic.com/~lynn/2007v.html#72 whats the world going to do when all the baby boomers retire

there is the issue that the replacements don't have the 30-40 yrs experience. there also appears to be issues that on the avg., the replacements don't have the skill levels because of the declining educational quality. recent posts
http://www.garlic.com/~lynn/2008.html#39 competitiveness
http://www.garlic.com/~lynn/2008.html#52 Education ranking
http://www.garlic.com/~lynn/2008.html#55 Education ranking
http://www.garlic.com/~lynn/2008.html#57 Computer Science Education: Where Are the Software Engineers of Tomorrow?
http://www.garlic.com/~lynn/2008.html#60 Education ranking
http://www.garlic.com/~lynn/2008.html#62 competitiveness
http://www.garlic.com/~lynn/2008.html#73 Computer Science Education: Where Are the Software Engineers of Tomorrow?
http://www.garlic.com/~lynn/2008.html#81 Education ranking
http://www.garlic.com/~lynn/2008.html#83 Education ranking
http://www.garlic.com/~lynn/2008b.html#3 on-demand computing
http://www.garlic.com/~lynn/2008b.html#6 Science and Engineering Indicators 2008
http://www.garlic.com/~lynn/2008b.html#13 Education ranking
http://www.garlic.com/~lynn/2008c.html#56 Toyota Beats GM in Global Production
http://www.garlic.com/~lynn/2008d.html#38 outsourcing moving up value chain
http://www.garlic.com/~lynn/2008d.html#55 was: 1975 movie "Three Days of the Condor" tech stuff
http://www.garlic.com/~lynn/2008d.html#74 Price of CPU seconds
http://www.garlic.com/~lynn/2008d.html#86 U.S. Science Funding Hits a Political Wall
http://www.garlic.com/~lynn/2008d.html#87 Berkeley researcher describes parallel path
http://www.garlic.com/~lynn/2008e.html#37 was: 1975 movie "Three Days of the Condor" tech stuff
http://www.garlic.com/~lynn/2008e.html#61 Study Finds Sharp Math, Science Skills Help Expand Economy
http://www.garlic.com/~lynn/2008e.html#63 Study Finds Sharp Math, Science Skills Help Expand Economy

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

was: 1975 movie "Three Days of the Condor" tech stuff

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: was: 1975 movie "Three Days of the Condor" tech stuff
Newsgroups: alt.folklore.computers
Date: Wed, 05 Mar 2008 14:42:54
Anne & Lynn Wheeler <lynn@garlic.com> writes:
one scenario is that in transition to knowledge economy ... technical Phds become the new mercenaries/samurais
http://www.garlic.com/~lynn/2008d.html#38 outsourcing moving up value chain


re:
http://www.garlic.com/~lynn/2008e.html#51 was: 1975 movie "Three Days of the Condor" tech stuff

so this was reference to technical Phds being the new mercenaries/samurais, as in economic warfare
http://www.garlic.com/~lynn/2008e.html#61 Study Finds Sharp Math, Science Skills Help Expand Economy
http://www.garlic.com/~lynn/2008e.html#63 Study Finds Sharp Math, Science Skills Help Expand Economy

... however there is also more traditional warfare moving into cyberspace

The New Art of War
http://www.washingtonpost.com/wp-dyn/content/article/2008/03/02/AR2008030202216.html

and boyd's maneuver warfare and OODA-loops ... the tempo is really increasing ... misc. past posts:
http://www.garlic.com/~lynn/subboyd.html#boyd
and various boyd &/or OODA-loop URLs from around the web
http://www.garlic.com/~lynn/subboyd.html#boyd2

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Convergent Technologies vs Sun

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Convergent Technologies vs Sun
Newsgroups: alt.folklore.computers
Date: Wed, 05 Mar 2008 16:22:05
Tim Shoppa <shoppa@trailing-edge.com> writes:
Did Sun really leapfrog everyone else by not jumping on but wholeheartedly starting the TCP/IP bandwagon in '82, when back then everyone else was worrying about SNA and X25 and all those other dead- ends? (Yes, I'm gonna say it: dead-ends.) Certainly in '83 DEC viewed the network as important (and really, in my experience, their network- based clustering ruled in many ways) but important as in they have to support fifteen different dead-end networking protocols (I don't think they even named TCP/IP).

as in past ... SNA wasn't networking technology ... it was communication infrastructure for huge numbers of dumb terminals.

in the early days of SNA ... my wife had co-authored peer-to-peer networking architecture, AWP39 ... which the SNA crowd somewhat viewed as competition ... even tho SNA doesn't have any networking (and only in organization that was using networking applied to communicating with large numbers of dumb terminals ... was it necessary to qualify networking with "peer-to-peer").

not too long later my wife got con'ed into going to pok to be in charge of loosely-coupled architecture (mainframe for cluster). while there she originated peer-to-peer shareddata architecture ... which found little takeup, except for IMS hotstandby, until more recent sysplex
http://www.garlic.com/~lynn/submain.html#shareddata

she had frequent battles with the sna/communication organization regarding protocols for loosely-coupled operation. one (temporary) truce was that she could use what she wanted to within the boundaries of glasshouse datacenter walls.

an example of truce breacking down was the vm/4341 (8-way) cluster product that had been implementated at research using 3088/trotter (in the early 80s). before customer release the product was forced to a sna implementation. a simple example was that the pre-sna implementation could execute full cluster syncronization protocol in under a second ... while the (product) sna-flavor required on the order of half a minute.

arpanet had its "great" change-over to tcp/ip on 1/1/83 ... which brought in gateways and internetworking:
http://www.garlic.com/~lynn/subnetwork.html#internet

i've claimed that one reason that the internal network (which wasn't sna) was larger than the arpanet/internet from just about the beginning until sometime mid-85 ... was because it had a form of gateway layer in each node (which came to arpanet/internet with 1/1/83 changeover):
http://www.garlic.com/~lynn/subnetwork.html#internalnet

one the big things that nsfnet backbone brought was operational (tcp/ip) "internetworking" between lots of (tcp/ip) "networks" ... some old nsfnet related email
http://www.garlic.com/~lynn/lhwemail.html#nsfnet
and posts
http://www.garlic.com/~lynn/subnetwork.html#nsfnet

OSI was coming into standardization about the timeframe as the tcp/ip 1/1/83 switchover .... however, in addition to being overly complex and cumbersome, it represented the oldstyle communication paradigm ... lacking any sense of gateways and internetworking.

iso further aggravated the situation by stipulating that ISO and ISO-chartered standards organization couldn't do standards (national, international) for protocols that violated OSI
http://www.garlic.com/~lynn/subnetwork.html#xtphsp

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Convergent Technologies vs Sun

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Convergent Technologies vs Sun
Newsgroups: alt.folklore.computers
Date: Wed, 05 Mar 2008 17:33:51
Rich Alderson <news@alderson.users.panix.com> writes:
Remember that Sun started with the SUN[1] workstation designed by Ralph Gorin and given to Andy Bechtolsheim to work out the details. TCP/IP was a built-in assumption from the get-go.

[1] Stanford University Network. It was designed to be a 3M system--1MB memory plus 1MIPS processor plus 1 million pixels on the screen. 3Mbit Ethernet was included.


re:
http://www.garlic.com/~lynn/2008e.html#73 Convergent Technologies vs Sun

and shopped around before resorting to a startup. an old post mentioning the evaluation done at the palo alto science center
http://www.garlic.com/~lynn/96.html#4a John Hartmann's Birthday Party

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Banks failing to manage IT risk - study

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Banks failing to manage IT risk - study
Newsgroups: alt.folklore.computers
Date: Wed, 05 Mar 2008 18:41:27
Anne & Lynn Wheeler <lynn@garlic.com> writes:
Bank regulators: 'Asleep at the switch'; Senate banking committee chair blasts regulators for not sounding warning about risky lending practices
http://money.cnn.com/2008/03/04/news/companies/senatebank/index.htm?postversion=2008030412


re:
http://www.garlic.com/~lynn/2008e.html#42 Banks failing to manage IT risk - study
http://www.garlic.com/~lynn/2008e.html#65 Banks failing to manage IT risk - study

the hearing
http://banking.senate.gov/index.cfm?Fuseaction=Hearings.Detail&HearingID=295

above has URLs for pdf of witness testimony and URL for the hearing video.

Kogn testimony (html)
http://www.federalreserve.gov/newsevents/testimony/kohn20080304a.htm

other urls

Fed's No. 2: Banks Sound, Need Time
http://www.smartmoney.com/bn/ON/index.cfm?story=ON-20080304-000562-1147 US banks face bad debts beyond subprime-Dugan
http://www.marketwatch.com/news/story/us-banks-facing-more-risks/story.aspx?guid={303B1D7B-89BD-4275-9803-FBDDE6D09653} Most bank deposits are insured, but it's best to check
http://www.usatoday.com/money/perfi/columnist/block/2008-03-03-deposit-insurance_N.htm

from above:
The number of banks on the "problem list" is still low by historical standards, FDIC spokesman David Barr says. During the banking crisis of 1990, by contrast, 1,500 banks were on the list. The FDIC never identifies institutions on its problem list because it doesn't want to cause a run on the banks.
... snip ...

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

independent appraisers

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: independent appraisers
Newsgroups: alt.folklore.computers
Date: Thu, 06 Mar 2008 09:10:32
krw <krw@att.bizzzzzzzzzz> writes:
Yes, and what about passwords? Their rules are often so onerous that one writes them down. Even the UserID for my time-accounting application is a random string of letters; bad enough that it's written on the base of the monitor at work. People don't often add in the end-user costs.

re:
http://www.garlic.com/~lynn/2008e.html#59 independent appraisers
http://www.garlic.com/~lynn/2008e.html#66 independent appraisers
http://www.garlic.com/~lynn/2008e.html#69 independent appraisers
http://www.garlic.com/~lynn/2008e.html#70 independent appraisers

passwords are shared-secrets ... lots of past posts
http://www.garlic.com/~lynn/subintegrity.html#secrets

kindergarten security 101 teaches that a unique, unguessable, frequently changed one-a-month shared-secret is required for every unique secruity domain ... as a countermeasure to cross-domain attacks. the people establishing the password rules appear to think that their security domain is the only one that exists.

large numbers of unique, unguessable, and frequently changes shared-secrets ... also contributes to secrets not being easy (impossible) to memorize .... especially as they mount to large scores ... leading to standard human factors requirement to write them down.

as part of the x9.59 financial transaction standard in the mid-90s
http://www.garlic.com/~lynn/x959.html#x959

we also did quite a bit of work on being able to change from an institutional-centric paradigm to a person-centric paradigm. some of the work mentioned in these recent posts
http://www.garlic.com/~lynn/2008e.html#56 Any benefit to programming a RISC processor by hand?
http://www.garlic.com/~lynn/2008e.html#57 Any benefit to programming a RISC processor by hand?
http://www.garlic.com/~lynn/2008e.html#62 Any benefit to programming a RISC processor by hand?

the above mentions giving a talk on some of the work at assurance panel in the trusted computing track at a past intel developer's forum.

a big part of the work on person-centric paradigm ... was looking at what would be needed by institutions with very stringent security requirements, in order for them to transition from an institutional-centric paradigm to a person-centric paradigm.

we had jokingly pointed at that the existing approaches had been going down the track of improving shared-secret environment by replacing each shared-secret with some sort of multi-factor authentication ... frequently involving some sort of hardware token. lots of past posts about three-factor authentication model
http://www.garlic.com/~lynn/subintegrity.html#3factor

... but would result with people carrying around large scores of hardware tokens. the only practical approach would be to also move past the institutional-centric paradigm to a person-centric paradigm.

misc. past posts mentioning work on person-centric paradigm:
http://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, or average case? (TCPA)
http://www.garlic.com/~lynn/aadsm19.htm#14 To live in interesting times - open Identity systems
http://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm19.htm#47 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/aadsm22.htm#12 thoughts on one time pads
http://www.garlic.com/~lynn/aadsm24.htm#49 Crypto to defend chip IP: snake oil or good idea?
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#7 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#42 Why security training is really important (and it ain't anything to do with security!)
http://www.garlic.com/~lynn/aadsm26.htm#35 Failure of PKI in messaging
http://www.garlic.com/~lynn/aadsm26.htm#48 Governance of anonymous financial services
http://www.garlic.com/~lynn/aadsm27.htm#23 Identity resurges as a debate topic
http://www.garlic.com/~lynn/aadsm27.htm#50 If your CSO lacks an MBA, fire one of you
http://www.garlic.com/~lynn/aadsm28.htm#30 Fixing SSL (was Re: Dutch Transport Card Broken)
http://www.garlic.com/~lynn/2003e.html#22 MP cost effectiveness
http://www.garlic.com/~lynn/2003e.html#31 MP cost effectiveness
http://www.garlic.com/~lynn/2004e.html#8 were dumb terminals actually so dumb???
http://www.garlic.com/~lynn/2005g.html#47 Maximum RAM and ROM for smartcards
http://www.garlic.com/~lynn/2005g.html#57 Security via hardware?
http://www.garlic.com/~lynn/2005m.html#37 public key authentication
http://www.garlic.com/~lynn/2005p.html#6 Innovative password security
http://www.garlic.com/~lynn/2005p.html#25 Hi-tech no panacea for ID theft woes
http://www.garlic.com/~lynn/2005t.html#28 RSA SecurID product
http://www.garlic.com/~lynn/2005u.html#26 RSA SecurID product
http://www.garlic.com/~lynn/2006d.html#41 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006o.html#20 Gen 2 EPC Protocol Approved as ISO 18000-6C
http://www.garlic.com/~lynn/2006p.html#32 OT - hand-held security
http://www.garlic.com/~lynn/2006q.html#3 Device Authentication - The answer to attacks lauched using stolen passwords?
http://www.garlic.com/~lynn/2007b.html#12 Special characters in passwords was Re: RACF - Password rules
http://www.garlic.com/~lynn/2007b.html#13 special characters in passwords
http://www.garlic.com/~lynn/2007d.html#12 One Time Identification, a request for comments/testing
http://www.garlic.com/~lynn/2007l.html#8 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007l.html#9 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007l.html#43 My Dream PC -- Chip-Based
http://www.garlic.com/~lynn/2007m.html#27 nouns and adjectives
http://www.garlic.com/~lynn/2007m.html#31 nouns and adjectives
http://www.garlic.com/~lynn/2007s.html#59 Translation of IBM Basic Assembler to C?
http://www.garlic.com/~lynn/2007s.html#62 Translation of IBM Basic Assembler to C?
http://www.garlic.com/~lynn/2007s.html#65 Translation of IBM Basic Assembler to C?
http://www.garlic.com/~lynn/2007t.html#8 Translation of IBM Basic Assembler to C?
http://www.garlic.com/~lynn/2007u.html#51 folklore indeed

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

independent appraisers

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: independent appraisers
Newsgroups: alt.folklore.computers
Date: Thu, 06 Mar 2008 09:28:00
krw <krw@att.bizzzzzzzzzz> writes:
In some cases it's the opposite. One can buy a serviceable gun for $100, though the average bank robbery is only $4K.

re:
http://www.garlic.com/~lynn/2008e.html#69 independent approaisers

of course, there can always be exceptions ... expecially if individuals are involved that don't comprehend the cost/benefit issues. it is also like saying that there are armed bank robberies can yield millions of dollars (ignoring the avgs). however, one could also cite some of the electronic exploits that could yield billions ... for even less effort.

the cost for compromsie on end-point terminal can cost on the order of a handgun ... and the effort on the order of a armed robbery ... however there is frequently little chance of being caught performing the compromise ... since it can be done w/o anybody there.

the cost/effort for end-point terminal compromise is on the order of an armed robbery ... with significantly reduced threat to the attacker. the "return" for the effort (roi) can be hundreds to thousands of accounts .... each account yiedling on the avg. of $1k to the attacker

armed robbery attacker would have to perform several thousand robberies to see similar return ... for three orders of magnitude more effort (and at least three orders of magnitude increase in the probability of being caught).

the armed robberies tend to show up a lot more in the popular press ... as well as stick in peoples' minds ... especially when the haul is millions of dollars.

misc. past posts mentioning fraud roi.
http://www.garlic.com/~lynn/aadsm10.htm#bio6 biometrics
http://www.garlic.com/~lynn/aadsm17.htm#2 Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
http://www.garlic.com/~lynn/aadsm17.htm#47 authentication and authorization ... addenda
http://www.garlic.com/~lynn/aadsm17.htm#60 Using crypto against Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm18.htm#45 Banks Test ID Device for Online Security
http://www.garlic.com/~lynn/aadsm19.htm#13 What happened with the session fixation bug?
http://www.garlic.com/~lynn/aadsm19.htm#17 What happened with the session fixation bug?
http://www.garlic.com/~lynn/aadsm19.htm#26 Trojan horse attack involving many major Israeli companies, executives
http://www.garlic.com/~lynn/aadsm19.htm#45 payment system fraud, etc
http://www.garlic.com/~lynn/aadsm23.htm#34 Chip-and-Pin terminals were replaced by "repairworkers"?
http://www.garlic.com/~lynn/aadsm26.htm#35 Failure of PKI in messaging
http://www.garlic.com/~lynn/99.html#172 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#44 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2003o.html#35 Humans
http://www.garlic.com/~lynn/2004.html#29 passwords
http://www.garlic.com/~lynn/2004b.html#39 SSL certificates
http://www.garlic.com/~lynn/2005i.html#1 Brit banks introduce delays on interbank xfers due to phishing boom
http://www.garlic.com/~lynn/2005p.html#25 Hi-tech no panacea for ID theft woes
http://www.garlic.com/~lynn/2006h.html#26 Security
http://www.garlic.com/~lynn/2007.html#5 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007.html#6 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#11 Decoding the encryption puzzle
http://www.garlic.com/~lynn/2007l.html#40 My Dream PC -- Chip-Based
http://www.garlic.com/~lynn/2007o.html#27 EZPass: Yes, Big Brother IS Watching You!
http://www.garlic.com/~lynn/2008e.html#69 independent appraisers

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

independent appraisers

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: independent appraisers
Newsgroups: alt.folklore.computers
Date: Thu, 06 Mar 2008 09:45:36
Dave Garland <dave.garland@wizinfo.com> writes:
That's not to say it's all due to fraud. ARMs and stuff with balloon payments have always struck me as insane. But some people fell for it, really did believe that the next 5 years would be as good as the last 5 (for housing prices, for personal situation). You better believe that the salescreatures did everything they could to reinforce that belief.

re:
http://www.garlic.com/~lynn/2008e.html#59 independent appraisers
http://www.garlic.com/~lynn/2008e.html#66 independent appraisers
http://www.garlic.com/~lynn/2008e.html#69 independent appraisers
http://www.garlic.com/~lynn/2008e.html#70 independent appraisers

tv tends to talk about the ignorant individuals that get into a five year subprime and are unable to understand that payments increase after five years.

there is much less discussion of large numbers of individuals that are using the subprime mortgages to acquire 2-3 properties and planning on flipping them in a year or two ... attracted by the extremely low monthly run-rate ... and the promise of possible double digit real estate inflation. such speculation activity dramatically drives up the demand for properties that they can buy & flip ... further fueling real estate inflation (and speculation frenzy). when it eventually implodes ... there are a lot of empty properties ... in part because the underlying demand wasn't there for other than speculation.

part of loan documentation used to be attributes like owner-occupied. in the speculation frenzy ... all of that can evaporate. when the bubble bursts, non-owner-occupied would contribute to large number of vacant properites

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Any benefit to programming a RISC processor by hand?

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Any benefit to programming a RISC processor by hand?
Newsgroups: comp.arch,comp.programming
Date: Thu, 06 Mar 2008 10:01:39
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
The System/370 was vastly saner, with no indirect addressing, though MVC etc. had two memory operands of up to 256 bytes (any alignment). While that was tedious to implement, its complexity was only because it usually had several optimised cases. MVCL etc. were interruptible and could be regarded as extracodes. So, at worst, that would use five pages of data and require data cache associativity of at least two (or three for a combined cache).

I really don't see a problem with allowing two or three aligned memory operands on a single core CPU, and the original RISC objections were mainly dogma. However, I do agree that excluding them on a multi-core CPU makes a vast simplification.


360/67 had 8-entry (fully) associative array for tlb ... to handle worst case MVC case.

360 instructions would pretest start/end locations and required all locations to be available before starting execution. this carried over to 370 ... except for new CLCL/MVCL instructions which would incrementally execute, could be interrupted, and restarted (from the interruption point).

more recently there are new class of instructions introduced that also can finish incomplete ... with cc=3 indication ... and it is necessary for application to loop back and restart the instruction to complete. the claim is that it allows application windows to possibly perform other operations in the intermittent breaks. this could be attributed to the increasing mismatch between processor cycle speed and memory accesses. recent thread/discussion
http://www.garlic.com/~lynn/2008c.html#67 What happened to resumable instructions?
http://www.garlic.com/~lynn/2008d.html#1 What happened to resumable instructions?

one might conjecture a requirement for easily spinning off independent asynchronous instruction as an alternative implementation ... but then there is still semantics how such asynchronous execution complete is recognized.

--
40+yrs virtualization experience (since Jan68), online at home since Mar70




previous, next, index - home