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?

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

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

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

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/subtopic.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

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

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

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

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 (for its nov78 date) 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

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

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/subtopic.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

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/subtopic.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

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

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

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

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/subtopic.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

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

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

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/subtopic.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" for the nov78
date on the documents ... 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

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/subtopic.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

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

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,33