List of Archived Posts

2006 Newsgroup Postings (10/23 - 11/02)

Microsoft to design its own CPUs - Next Xbox In Development

Is the teaching of non-reentrant HLASM coding practices ever

Is the teaching of non-reentrant HLASM coding practices ever defensible?

Universal constants

Turbo C 1.5 (1987)

Are there more stupid people in IT than there used to be?

Ranking of non-IBM mainframe builders?

32 or even 64 registers for x86-64?

Root CA CRLs

32 or even 64 registers for x86-64?

Why these original FORTRAN quirks?

Ranking of non-IBM mainframe builders?

Ranking of non-IBM mainframe builders?

VM SPOOL question

32 or even 64 registers for x86-64?

more than 16mbyte support for 370

Is the teaching of non-reentrant HLASM coding practices ever defensible?

old Gold/UTS reference

Why magnetic drums was/are worse than disks ?

old vm370 mitre benchmark

Why these original FORTRAN quirks?; Now : Programming practices

Are there more stupid people in IT than there used to be?

threads versus task

threads versus task

CMSBACK

Are there more stupid people in IT than there used to be?

Universal constants

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

Why these original FORTRAN quirks?

Storage Philosophy Question

Why these original FORTRAN quirks?

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

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

threads versus task

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

Universal constants

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

Are there more stupid people in IT than there used to be?

Vulnerability Assessment of a EAL 4 system

Why these original FORTRAN quirks?

Encryption and authentication

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

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

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

1960s railroad data processing on L&N

To RISC or not to RISC

To RISC or not to RISC

To RISC or not to RISC

To RISC or not to RISC

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

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

Microsoft to design its own CPUs - Next Xbox In Development

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Microsoft to design its own CPUs - Next Xbox In Development
Newsgroups: comp.arch
Date: Mon, 23 Oct 2006 09:48:03 -0600

torbenm@app-3.diku.dk (Torben Ægidius Mogensen) writes:

This is more a software issue than a hardware issue, except to the
extent that current systems require so tortuous methods to exploit
that you can't abstract these into libraries or compilers.

For a next-generation games machine, I think the best idea is to
codesign hardware and sofware, i.e., make a language that exploits the
hardware at the same time as you make the hardware, and make both be
aware that the other exist, so you don't make it impossible to compile
to the hardware nor make the language impossible to implement
efficiently.

aka it is a system issue ... and the semantics of the different
pieces.  right now there is some assertions that the semantics of
various existing hardware features are sufficiently complex and/or
obtuse that it is nearly impossible to develop software that achieves
the desired performance and real-time presentation.

some of this is matching the semantics and the overall infrastructure
that needs to concurrently manage a large number of different
processes/operations in highly parallelized environment ... in several
cases, extremely fine-grain parallel, concurrent operations. this has
something of the flavor of the oldtime high performance processors
that needed highly tuned and highly specialized horizontal microcoding
(and the execution/work units may span a number of different chips).

re:
http://www.garlic.com/~lynn/2006s.html#62 Microsoft to design its own CPUs - Next Xbox In Development
http://www.garlic.com/~lynn/2006s.html#63 Microsoft to design its own CPUs - Next Xbox In Development

Is the teaching of non-reentrant HLASM coding practices ever

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever
Newsgroups: bit.listserv.ibm-main,bit.listserv.vmesa-l,alt.folklore.computers
Date: Mon, 23 Oct 2006 11:27:34 -0600

gilmap writes:

Is it necessary to round to a page boundary, or only to a cache line
boundary?  (Either is subject to architectural change.)

what is the objective? ... things like cache line thrashing across
different processors ... or use of page-oriented protection mechanisms
(of course it is usually transparent if program loading rounds up to a
larger storage aligned increment).

it used to be that storage key based protection mechanism was 2k ...
but with 3081 and 370-xa ... 2k storage keys were dropped in favor of
4k storage keys.

and as mentioned ... cms had shared pages in cp67 ... which was
oriented around r/o protection on page basis (using a hack involving
2k storage key protection). in the morph of cms for vm370, some amount
of cms was reworked to align with the segment sharing (across address
spaces) and segment protection facility in the original 370 virtual
memory architecture. the segment protection (and other) features of
the original 370 virtual memory architecture got dropped as part of
buying six months schedule time for 370/165 hardware implementation
(and while the cms programing model retained the shared-segment
alignment orientation ... the underlying protection mechanism used by
vm370 reverted to the storage key based protection mechenism used by
cp67),

and then, of course, there is the whole os/360 heritage of relocatable
adcons ... not only do all the relocable adcons need to be swizzled as
part of program loading ... but it is further aggravated by
relocatable adcons being intermixed with program code and data (as
aside, cms leverages uses of the os/360 derived assemblers, compilers,
conventions, etc ... however, tss/360 had a much better convention for
the handling of program address constants in a virtual memory
environment).

various recent postings mentioning the relocatable adcon issue
http://www.garlic.com/~lynn/2006s.html#17 bandwidth of the swallaw (was Real core)
http://www.garlic.com/~lynn/2006s.html#61 Is the teaching of non-reentrant HLASM coding practices ever defensible?

and lots of past posts mentioning relocatable adcon issue
http://www.garlic.com/~lynn/submain.html#adcon

Is the teaching of non-reentrant HLASM coding practices ever defensible?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever defensible?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 23 Oct 2006 13:34:09 -0600

Anne & Lynn Wheeler <lynn@garlic.com> writes:

for some trivia ... one of the people in the following meeting claimed
to have been primary person handling sql/ds technology transfer from
endicott back to stl for db2
http://www.garlic.com/~lynn/95.html#13

re:
http://www.garlic.com/~lynn/2006s.html#61 Is the teaching of non-reentrant HLASM coding practices ever defensible?

the meeting was primarily to focus on cluster scaleup for our (ibm) ha/cmp
product (and possible relationship between cluster scaleup and parallel
oracle)
http://www.garlic.com/~lynn/subtopic.html#hacmp

for completely other triva ... two of the other people mentioned in
the same meeting later showed up in a small client/server startup
and responsible for something they called the "commerce server". at that time,
we were called in as consultants on something called payment gateway
... because they wanted to process financial transactions on servers
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

the small client/server startup had this technology called https (or
ssl) and the payment stuff is frequently now referred to as electronic
commerce.

a couple other recent posts on some (even older) networking activity
http://www.garlic.com/~lynn/2006s.html#50 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006s.html#51 Ranking of non-IBM mainframe builders?

and then there are these two
http://www.garlic.com/~lynn/internet.htm#0
http://www.garlic.com/~lynn/internet.htm#31

Universal constants

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Universal constants
Newsgroups: alt.folklore.computers
Date: Mon, 23 Oct 2006 18:11:13 -0600

for completely other drift .... 30 min. program on Legends of Airpower
just started on the Military (cable) channel ... this program on
John Boyd.

misc. Boyd URLs from around the web
http://www.garlic.com/~lynn/subboyd.html#boyd2

and misc. of my past posts mentioning John Boyd
http://www.garlic.com/~lynn/subboyd.html#boyd

Turbo C 1.5 (1987)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Turbo C 1.5 (1987)
Newsgroups: alt.folklore.computers
Date: Mon, 23 Oct 2006 18:51:16 -0600

Al Kossow <aek@spies.com> writes:

I would suggest using Imagedisk
http://www.classiccmp.org/dunfield/img/

If you need a drive, I should be able to loan one to you, or if they are of
historical interest, I could read the floppies for you at the Museum.

any directions on how to help imagedisk find the floppy controller ...
it just hangs on startup saying it can't find any floppy drives.

i put a 1.2m 5.25in teac drive in an old pentium pro machine who's
scsi hard disk had long since died ... however, the floppy cable did
have edge connector for the teac drive ... along with 3.5in floppy
reader. i've got a number dos4 and dos6 3.5in bootable diskettes and
was able to read numerous 360kbyte diskettes on the B: drive.

however, i haven't been able to read/process any of the 80trk 10sector
diskettes as well as half dozen 360kbyte diskettes. i was hoping that
imagedisk would be able to do the trick ... but imagedisk apparently
can't find the floppy controller to directly access.

the dos systems haven't had a problem and i've also been boot and run
knoppix (from the scsi cdrom drive).

Are there more stupid people in IT than there used to be?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Are there more stupid people in IT than there used to be?
Newsgroups: alt.folklore.computers
Date: Mon, 23 Oct 2006 21:23:41 -0600

winston19842005 writes:

All the problems with data being lost, like your credit card numbers.

People taking laptops home with information that was supposed to be
secure.

in the early 80s, there was decision to allow off-site/remote access
via portable terminals. one of the vulnerabilities identified as
part of the effort was extreme risk of most hotel PBX. as part of
that, it was decided to build a custom encrypting modem for internal
corporate use ... and no offsite/remote access would be allowed w/o
the appropriate encrypting capability.

i found it quite remarkable the number of operations allowing
offsite/remote access in the 90s up thru the present day that don't
use even the simplest security measures. if so many organizations
weren't even encrypting offsite/remote communication ... why would
you expect that they would provide protection for data actually
on the laptops????

for other drift ... there is my old posting on security proportional
to risk
http://www.garlic.com/~lynn/2001h.html#61

and post with quite a few references to data breaches and other data loss
scenarios
http://www.garlic.com/~lynn/aadsm25.htm#24 DDA cards may address UK Chip&Pin woes

and collection of posts on various associated vulnerabilities and exploits
http://www.garlic.com/~lynn/subintegrity.html#yescard

note that the x9a10 financail standard working group had been given the
requirement to preserve the integrity of the financial infrastructure
for all related payments in conjunction with the work on the x9.59
financial standard
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

part of the work eliminated risk associated with account numbers
for x9.59 transactions ... i.e. x9.59 didn't do anything
about prevent data breaches associated with account numbers
http://www.garlic.com/~lynn/subintegrity.html#harvest
http://www.garlic.com/~lynn/subintegrity.html#secrets

however, it eliminated any risks associated with attackers obtaining
(x9.59 related) account numbers ... and since the risks were
eliminated ... then based on security proportional to risks ... the
security issues were significantly mitigated.

misc. past posts mentioning corporate encrypting modems for offline/remote
access
http://www.garlic.com/~lynn/aadsm14.htm#1 Who's afraid of Mallory Wolf?
http://www.garlic.com/~lynn/aadsm22.htm#16 serious threat models
http://www.garlic.com/~lynn/aadsm25.htm#34 Mozilla moves on security
http://www.garlic.com/~lynn/aepay11.htm#37 Who's afraid of Mallory Wolf?
http://www.garlic.com/~lynn/2002d.html#11 Security Proportional to Risk (was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2003i.html#62 Wireless security
http://www.garlic.com/~lynn/2004q.html#57 high speed network, cross-over from sci.crypt
http://www.garlic.com/~lynn/2006p.html#35 Metroliner telephone article

Ranking of non-IBM mainframe builders?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Ranking of non-IBM mainframe builders?
Newsgroups: alt.folklore.computers
Date: Tue, 24 Oct 2006 11:41:04 -0600

Anne & Lynn Wheeler <lynn@garlic.com> writes:

note that it was external visibility like this that got HSDT into
political problems with the communication group ...  in part, because
there was such a huge gap between what they were doing and what we
were doing.

re:
http://www.garlic.com/~lynn/2006s.html#50 Ranking of non-IBM mainframe builders?

some other background ... part of the history leading up to the letter
from NSF being sent to corporate hdqtrs (mentioned in the referenced
4/17/86 email in the previous post) events had significant overtones
involving corporate political infighting


From: wheeler
Date: 05/06/85  16:41:57

I noticed in this months sigops a quicky synopsis of Project Admiral
... I've been making presentations on HSDT recently (it has been
pitched to NSF as a backbone to tie together all the super computer
sites). Last week in Boulder at the National Center for Atmospheric
Research, one of the people mentioned that Project Admiral and HSDT
will be managing the satellite channel simarily ... do you have more
detailed info?

BTW ... I'll probably be over in Europe during July. People at NSF ask
that HSDT also be pitched to the european network (EARN).

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


From: wheeler
Date: 09/30/85  15:34:06

I'm meeting with NSF on weds. to discuss the implementation for tieing
together the super-computer centers. I'll be back in Milford next week
to present the NSF project status. I've been asked to get together
with Univ. of Cal. by the end of the month to discuss their use for
tieing together the UofC campuses.

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

Eric Bloch was director of the National Science Foundation for much of
the 80s.


From: wheeler
Date: 04/07/86  10:06:34

re: hsdt; I'm responsible for an advanced technology project called
High Speed Data Transport. One of the things it supports is a 6mbit
TDMA satellite channel (and can be configured with up to 4-6 such
channels).  Several satellite earth stations can share the same
channel using a pre-slot allocated scheme (i.e. TDMA). The design is
fully meshed ...  somewhat like a LAN but with 3000 mile diameter
(i.e. satellite foot-print).

We have a new interface to the earth station internal bus that allows
us to emulate a LAN interface to all other earth stations on the same
channel. Almost all other implementations support emulated
point-to-point copper wires ... for 20 node network, each earth
station requires 19 terrestrial interface ports ... i.e. (20*19)/2
links. We use a single interface that fits in an IBM/PC. A version is
also available that supports standard terrestrial T1 copper wires.

It has been presented to a number of IBM customers, Berkeley, NCAR,
Eric Bloch and Dick Jennings at NSF and a couple of others. NSF finds
it interesting since 6-36 megabits is >100* faster than the "fast"
56kbit links that a number of other people are talking about. Some
other government agencies find it interesting since the programmable
(full bandwidth) encryption interface allows crypto-key to be changed
on a packet basis.  We have a design that supports data-stream (or
virtual circuit) specific encryption keys and multi-cast protocols.

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

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

misc. posts mentioning bitnet/earn
http://www.garlic.com/~lynn/subnetwork.html#bitnet

post referencing old email about setting up earn:
http://www.garlic.com/~lynn/2001h.html#65 UUCP email

32 or even 64 registers for x86-64?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 32 or even 64 registers for x86-64?
Newsgroups: comp.arch,alt.folklore.computers
Date: Wed, 25 Oct 2006 09:54:50 -0600

"ranjit_mathews@yahoo.com" <ranjit_mathews@yahoo.com> writes:

Elcaro Nosille wrote:
> Today's RISC CPUs don't have a minimized set of instructions. The only
> difference to CPUs we called CISC is, that the're pure load/store-archi-
> tectures, i.e. they don't have operations with memory-operands except
> from load or store.

... but then, "reduced" doesn't mean minimized. RISC instructions are
reduced to the extent of removing 1-3 address operations with operands
in memory.

Be that as it may, RISC was as much a marketing term as an
architectural description. Before the Spectrum architecture was renamed
to PA-RISC, did HP call Spectrum a RISC architecture? Did Apollo use
"RISC" to refer to their PRISM architecture (which was nipped in the
bud by HP when they took over Apollo)?

mention of risc from long ago and far away ...


To: wheeler
Date: 29 September 1982, 10:46:37 EST

Hm, interesting article you sent....

I obtained advance information about the Intel iAPX286 .... it looks
very interesting.... also have some data on the iAPX 86/30 and 88/30
Operating system processors....  this looks extremely interesting, and
one can assume that the 286 cannot be far behind in getting an
operating system chip to go with it....

iAPX86/30 is a 2 chip processor, with 35 operating system processor
primitives as instructions... things like job and task management,
interrupt management, free memory management, intertask communication,
intertask synchronization, and environmental control... It also
supports 5 operating system data types: jobs, tasks, segments,
mailboxes, and regions.  Someday we'll be able to look back at the big
RISC vs. CISC and wonder what all the fuss was about....

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

a couple previous posts with copy of the above email
http://www.garlic.com/~lynn/2006p.html#15 25th Anniversary of the Personal Computer
http://www.garlic.com/~lynn/2006p.html#19 Wat part of z/OS is the OS?

and nearly a year earlier


To: wheeler
Date: 12/08/81  21:53:49

Re: Complexity

Agreed, decomposition is ONE solution to solving complex problems.
Another widely accepted solution is sucessive approximation.  The
principle there is that you attempt a cheap solution as an
approximation, observe the results and interate to produce a better
solution.  This method has been used in the creation of the S/370
architecture, among other things.  It is already an established
mathematical and engineering procedure for establishing optimality.

In the 801, quite a bit has been pushed onto the
code/compiler/operating system.  As a first approximation, that's not
a bad idea, since it is relatively cheaper to change the operating
system than it is to change the machine.  I claim that after iterating
on the operating system a while, the proper concepts can be reasonably
put into silicon.  It is just too damn expensive to go out and try to
do it right the first time.  I believe that the iapx432 will fail for
that reason.  I can't believe that they are going to get it right so
that they can get into mass production until after the development
budget has completely blown any profits they may make.

Whatever Yorktown's reasons, a simple computer isn't a bad idea.
Seymore Cray has made one hell of a lot of hay on that idea.  Guys at
Berkeley have ripped off the basic 801 idea(simple computer) and built
RISC(Reduced Instruction Set Computer) in FET which they claim will
outrun most mini's in the world.  Complexity in a machine architecture
SLOWS IT DOWN.  Let's find the complexity in the software, and then
move it to the hardware as necessary on further iterations.

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

wikipedia reference to berkeley risc
http://en.wikipedia.org/wiki/Berkeley_RISC

lots of past postings mentioning 801, romp, rios, fort knox, power,
somerset, etc
http://www.garlic.com/~lynn/subtopic.html#801

as an aside, i've previously mentioned being at an (internal) advanced
technology conference early 77 doing presentation on 16-way smp design
... where the 801 group was presenting 801 (and getting into argument
about how to handle shared segments in virtual memory
architecture). as much as the hardware design was the compiler (pl.8)
and operating system (cp.r) ... since, in effect, a lot of hardware
stuff was being moved into software.

my view was that some amount of the motivation for 801 was in reaction
to the failed future system effort
http://www.garlic.com/~lynn/submain.html#futuresys

and to try and do as nearly as possible, the exact opposite, in terms
of hardware complexity.

and as to the mentioned subthread on complexity (and moving complex
software into hardware) ... my somewhat counter argument from the
period ... was that at lot of software complexity (especially kernel)
was spaghetti patched mess that possibly had evolved over a decade (or
more). the original people that understood the purpose for the code
are no longer around and what is left is a lot of incremental patching
activity.

benefits of redoing in hardware comes as much from just the
redoing (and figuring out what is really going on) as comes
from moving anything into hardware.

what you did find was that some of the people that had worked on
early 801, going to both amd (29k?) and hp (snake?)

there is some folklore that one of the people that gave notice that
they were leaving for HP ... then spent their remaining 2weeks in the
los gatos lab doing some final work on blue iliad (early 32bit 801
chip).

the aix unix workstation, pc/rt ... with (an 801) ROMP chip
... originally started at as an OPD project for a follow-on to the
displaywriter. when that project was killed, there was some looking
around and eventual decision to retarget the machine to the unix
workstation market.  the company that had done the at&t unix port
to the ibm/pc for pc/ix was hired to do a similar port to what was
going to "aix". cp.r had to be scrapped ... however the group writting
the pl.8 displaywriter software was retargeted to implement a virtual
machine abstraction (VRM) in pl.8. the company doing the unix port,
was directed to do it to the VRM interface (rather than the bare
hardware).

recent post mentioning vrm:
http://www.garlic.com/~lynn/2006r.html#49 Seeking info on HP FOCUS (HP 9000 Series 500) and IBM ROMP CPUs from early 80's

Root CA CRLs

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Root CA CRLs
Newsgroups: microsoft.public.security
Date: Wed, 25 Oct 2006 11:56:30 -0600

Seeker <newsgroups@minusthespam.michaelstarks.com> writes:

I'm setting up a two-tier PKI hierarchy.  The root will be offline and
will sign the issuing CA certificate.  What is the best-practice for the
root Certificate Revocation List and revoking the root certificate?

Should I immediately revoke the root certificate after creating the
issuing CA and store it in a secure location in case the passphrase is lost?

Should I create a certificate revocation list from the root or only on
the issuing CA?  I certainly don't want to have to retrieve the root
authority to update the list, but will the clients handle this OK if the
root public key is in the browser but the issuing CA revokes
certificates and publishes the list?  I would think so, since the chain
should be intact.

scrap PKIs, certification authorities, and certificate revocation list
...  and migrate to real-time, online infrastructure.

the original kerberos pk-init ... misc. past posts
http://www.garlic.com/~lynn/subpubkey.html#kerberos

started out with a certificate-less public key infrastructure ...  the
registration authority (which is common to lots of business processes)
just registered the public key in lieu of a password ... w/o having to
issue a certificate ... misc. past posts
http://www.garlic.com/~lynn/subpubkey.html#certless

so entities can connect/login just thru kerberos digital signature
authentication protocol ... where the digital signature is directly
verified by doing real-time access to the registered public key.

note there was also a similar certificate-less done for radius ...
again, w/o having to resort to any of the PKI, certification
authority, and/or certificate revocation list stuff.
http://www.garlic.com/~lynn/subpubkey.html#radius

for the SSL, server authentication/encryption scenario ... misc.
past posts
http://www.garlic.com/~lynn/subpubkey.html#sslcert

the scenario involved registering public keys with the domain name
infrastructure ... and doing real-time retrieval of public keys as
part of the existing domain name infrastructure protocols (even
piggyback in existing transmission).

the issue here was that the PKI/CA business operations were already
somewhat advocating registration of public keys with the domain name
infrastructure ... as a countermeasure to some integrity issues that
the SSL domain name certificate operations have ... aka as part of a
ceritification authority certifying a SSL domain name certificate
operations ... they have to validate that they are dealing with the
true domain name owner. they currently require a lot of
"identification" information ... which then they cross check with the
registered identification for the domain name owner on file with the
domain name infrastructure. having the domain name owner register a
public key helps eliminate some vulnerabilities associated with
who the domain name owner is.

this does represent something of a catch-22 for the SSL domain name
certificate operation. With a public key on file for the domain
name owner, they can now require that all SSL domain name
certificate applications be digitally signed. They can then do a
real-time (certificate-less) retrieval of the public key from
the domain name infrastructure for validating the digital
signature. This turns an expensive, error-prone, and time-consuming
identification process into a much simpler, less-expensive, and more
reliable authentication process (as part of due diligence related to
the SSL domain name certificate application).

the catch-22 issues are:

1) SSL domain name certificates were originally justified (in part)
based on integrity issues with the domain name infrastructure.
improving the overall integrity of the domain name infrastructure
reduces some of the originally justification for having SSL domain
name certificates

2) if the SSL domain name certificate operations can do
real-time retrieval of public keys for their purposes (basically it
becomes the trust root for the certification process) ... then it is
possible that the rest of the world could also start doing real-time
retrieval of public keys from the domain name infrastructure
... eliminating the need for SSL domain name certificates at
all (aka directly using the same trust root that is the foundation for
the SSL domain name certificates)

misc. past posts mentioning the catch-22 issue for the SSL domain name
certificate business related to their desire to have public keys
registered with the domain name infrastructure ... and being able to
do real-time, certificate-less, public key retrievals.
http://www.garlic.com/~lynn/subpubkey.html#catch22

32 or even 64 registers for x86-64?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 32 or even 64 registers for x86-64?
Newsgroups: comp.arch,alt.folklore.computers
Date: Wed, 25 Oct 2006 16:10:17 -0600

re:
http://www.garlic.com/~lynn/2006t.html#7 32 or even 64 registers for x86-64?

in the following, "MLS" refers to the 16-way SMP mentioned in the
previous post.  VAMPS was a 5-way smp project that preceded MLS
... misc.  collected posts mentioning VAMPS
http://www.garlic.com/~lynn/submain.html#bounce


From: wheeler
Date: 11/28/78  14:45:51

I can wait. Remember the '801' cpu from Yorktown? There was a a
presentation on it at that ad-tech meeting in POK when we presented
MLS. Well it is being fabricated in Los Gatos and they are looking for
applications for it. They are interested in programming 370
instruction set and running VM on it. There is a GPD ad-tech group
located here in bldg. 28 looking at system support. A lot of things in
VAMPS and MLS look like possibilities.

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


From: wheeler
Date: 06/07/79  07:48:11

The 801 seems to be the only game in town. The hardware architecture
is much closer to vertical microcode than machine language (there has
even been suggestion that 370 be programmed on it, which would make
the 801 microcoded).

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

one of the suggested purposes for 801s was to replace the myriad of
internal microprocessors ... including some number of microprocessors
used in 370 implementations. misc. posts mentioning microprocessor
microprogramming
http://www.garlic.com/~lynn/subtopic.html#mcode

old email that i've posted before mentioning 801:


To: wheeler
Date: 79/07/11 11:00:03

i heard a funny story: seems the MIT LISP machine people proposed that
IBM furnish them with an 801 to be the engine for their prototype.
B.O. Evans considered their request, and turned them down.. offered
them an 8100 instead!  (I hope they told him properly what they
thought of that)

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

note: 8100 system used a totally different microprocessor (I believe
uc.5) that was in no way related to 801.

and for something completely different, 801's pl.8 compiler (using
pascal language front end and both 68k and 370 backend code
generation)


To: wheeler
Date: 8 August 1981, 16:47:28 EDT

the 801 group here has run a program under several different PASCAL
"systems".  The program was about 350 statements and basically
"solved" SOMA (block puzzle..).  Although this is only one test, and
all of the usual caveats apply, I thought the numbers were
interesting...  The numbers given in each case are EXECUTION TIME ONLY
(Virtual on 3033).

6m 30 secs               PERQ (with PERQ's Pascal compiler, of course)
4m 55 secs               68000 with PASCAL/PL.8 compiler at OPT 2
0m 21.5 secs             3033 PASCAL/VS with Optimization
0m 10.5 secs             3033 with PASCAL/PL.8 at OPT 0
0m 5.9 secs              3033 with PASCAL/PL.8 at OPT 3

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


To: wheeler
Date: 11/04/81  08:48:39
From: somebody in Endicott

Lynn,
    Somebody suggested that you may know of someone that has done a
PL1 version of CP. We are interested in any information you may have
on the subject.
    We are currently looking for a control program that could be run
natively on an Atlantic machine (801 processor from Yorktown).  We
have access to a PL1-like compiler which we can generate 801 code
with. If such a PL1 version of CP existed it may save us some recoding
of existing function. We are still in a hardware position where
trade-offs can be made to support the control program.  It is
sufficient for the near term that the virtual machine support be S/370
only. This would probably change later.

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

aka Endicott was looking at using an "801" as the microprocessor in
the follow-on to the 4341. I had done a program that analyzed 370
assembler listings, register useage, code flow, and instructions
... and then generated a program representation in pli-like psuedo
code.  the reference in the above to "PL1-like" is, of course
pl.8. the idea behind this email, was not only use the 801 as the
microprocessor for emulating 370s ... but to also take the whole vm370
virtual machine kernel and drop it into native 801 code.

this would have been somewhat analogous to the current generation of
370 virtual machine supervisors implemented on i86 platforms.

Why these original FORTRAN quirks?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why these original FORTRAN quirks?
Newsgroups: alt.folklore.computers
Date: Wed, 25 Oct 2006 16:15:28 -0600

Joe Morris <jcmorris@mitre.org> writes:

A similar idea reportedly earned an IBM FE a big bonus back in the
days of OS/360: he designed a template to be printed on transparant
acetate that could be laid down on a hex dump of a VTOC.  For each of
the various flavors of DSCB it marked the location of each field
and its name, making it a trivial task to chase down the bytes that
you didn't need often enough to memorize their location.

Given the number of records in a VTOC and the amount of information
they contained, a formatted listing would have been quite long; the
VTOC overlay gave you most of the info you needed but required much
less paper.

much later with dumprx (nearly all written in rex)
http://www.garlic.com/~lynn/submain.html#dumprx

i had a format command where you could point at a starting location in
a dump image and a "DSECT" library member ... and it would interpret
the DSECT source on the fly and format the storage according to the
specified DSECT.

Ranking of non-IBM mainframe builders?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Ranking of non-IBM mainframe builders?
Newsgroups: alt.folklore.computers
Date: Wed, 25 Oct 2006 16:51:22 -0600

re:
http://www.garlic.com/~lynn/2006s.html#50 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006t.html#6 Ranking of non-IBM mainframe builders?

other HSDT email from long ago and far away


To: wheeler
Date: 04/18/84 11:27:41

There is a T1 circuit currently scheduled by NY TEl for installation
12/84 from Yorktown to West 1.  This was the missing link in the t1 circuit
from Kingston to Yorktown.  NY Tel now indicates that they believe they
can improve the installation date to 9/1/84.  INET's interest in doing that,
and in fact, installing the circuit at all at this time may depend
on HSDT requirements.

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

the April email is concerning an on order T1 link between Yorktown
(NY) and Kingston (NY) and informing that the installation date might
possibly be improved from December to September.

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

Ranking of non-IBM mainframe builders?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Ranking of non-IBM mainframe builders?
Newsgroups: alt.folklore.computers
Date: Wed, 25 Oct 2006 21:00:22 -0600

re:
http://www.garlic.com/~lynn/2006s.html#50 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006t.html#6 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006t.html#11 Ranking of non-IBM mainframe builders?

and another old email related to hsdt


From: wheeler
Date: 11/21/84  08:55:26

re: hsdt; oh, almost forgot. I'm having another meeting with the
Berekely ten meter telescope people (this time just the IBMers working
with them). They want to set-up for remote observing (observatory will
be about 14,000 foot level in Hawaii) from both "local" sea level and
eventually the mainland. Current estimates are that the digitized
image represents about 800kbits of data during the evening hours (data
flow is asymetrical with telescope control commands going in the
opposite direction only about 1200 baud).

Because of numerous reasons (staffing, support, etc.), they would like
to limit the hardware at the site to PC/AT scale machine (customer
field replacable units ... service call would be extremely time
consuming and loose valuable observing time).

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

a couple other posts on the subject (including copies of old email)
http://www.garlic.com/~lynn/2004h.html#7 CCD technology
http://www.garlic.com/~lynn/2004h.html#8 CCD technology

and recent news article about there being some damage in the recent
earthquake:
http://www.keckobservatory.org/ W. M. Keck Observatory
http://www.keckobservatory.org/news.php W. M. Keck Observatory News
http://www.keckobservatory.org/article.php?id=95 W. M. Keck Observatory Earthquake

VM SPOOL question

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: VM SPOOL question
Newsgroups: alt.folklore.computers,bit.listserv.vmesa-l
Date: Wed, 25 Oct 2006 22:29:42 -0600

lynn writes:

for a little drift ... also as an undergraduate i complete redid the
page replacement algorithm ... implementing global LRU based on page
reference bits ... lots of past postings discussing page replacement
algorithms
http://www.garlic.com/~lynn/subtopic.html#wsclock

re:
http://www.garlic.com/~lynn/2006s.html#25 VM SPOOL question

for additional drift ... another old email mentioning page replacement
work:


From: wheeler
Date: 6/22/92  19:57:09

Last year there was some sort of announcement from Amdahl regarding
Huron ... describing it as a hierarchical database system ... part of
something look like it was targeted along the same lines as ad/cycle.

at a meeting in boston on friday, i ran into consultant/professor (who
i had known from the early '70s) that mentioned he had designed the
Huron database system and was working with amdahl on the
implementation.

the actual context of the discussion started out on LRU replacement
algorithms and a paper he and two other professors were writting on
the subject.  I had been responsible for possible the original
implementation of "clock" algorithm in the late '60s (which he had
known). the point of the discussion was that i had also developed a
different class of LRU replacement algorithms during the early 70s
that had some interesting advantages over clock. specifically both
"clock" and this hybrid are approximations to a "true" LRU replacement
(i.e. the time of the most recent reference to every object in memory
could be exactly determined ... and all the objects could be exactly
ordered by the exact/true reference information).

Doing detailed trace-driven simulation studies, "clock" would be
measured as coming within X% (where X is typically in the 2-10 range)
of the performance of true LRU (i.e. almost as good as). The
interesting thing about the hybrid was that it was possible to find a
version of the hybrid that was 5-10% better than true LRU.

In any case, he had thought that his work on LRU "clock" like
replacement algorithms could significantly improve the performance of
the Huron buffer cache manager. He had forgotten about this other work
I had done on hybrid replacement algorithm. In any case, he became
interested in whether I would review and/or even possibly contribute
to the paper.

As to Huron database, he said that it was NOT a hiearchicial
implementation and had asked Amdahl to not describe it as such. Some
of the details sounds something like what Atherton went thru starting
with a RDBMS and then evolving to a RYO for unstructured real-world
data. Claim is that Huron can handle relational queries but also
maintains order (w/o having to sort on sequence field ...  especially
evolving mega-entries) and can do direct links (w/o join overhead), as
well as not having to recompile apps when schemas change.

In any case, is there anybody out there that already has detailed
description of Huron database implementation?

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

32 or even 64 registers for x86-64?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 32 or even 64 registers for x86-64?
Newsgroups: alt.folklore.computers
Date: Thu, 26 Oct 2006 17:05:45 -0600

Peter Flass <Peter_Flass@Yahoo.com> writes:

Lynne, your posts are always interesting, but a little more context
would be nice here, I don't quite get what you are saying:-(

the thread started in comp.arch ... issue somewhat about risc
vis-a-vis cisc ... as well as early use of the term risc (somewhat
with regard to HP circa 1989).

in my previous post
http://www.garlic.com/~lynn/2006t.html#9 32 or even 64 registers for x86-64?

i had referenced my original post in the thread:
http://www.garlic.com/~lynn/2006t.html#7 32 or even 64 registers for x86-64?

which included email from 1981
http://www.garlic.com/~lynn/2006t.html#email810812
and 1982
http://www.garlic.com/~lynn/2006t.html#email820929
where the term "risc" was used ... somewhat in conjunction with 801. I
had also added alt.folklore.computers ... in part because of the
included references from the early 80s.

the referenced 1981 email included somebody's comment that possibly
Berkeley had "ripped" off the basic idea for risc from 801.

in the previous post that you referenced
http://www.garlic.com/~lynn/2006t.html#9 32 or even 64 registers for x86-64?

I followed up with additional email from 1978,
http://www.garlic.com/~lynn/2006t.html#email781128

1979,
http://www.garlic.com/~lynn/2006t.html#email790607
http://www.garlic.com/~lynn/2006t.html#email790711

and 1981
http://www.garlic.com/~lynn/2006t.html#email811104

that also included 801 references.

... aka RISC dates back to earlier than HP circa 1989 ... or Berkeley in
the early 80s ... but to original 801 from the mid-70s.
http://www.garlic.com/~lynn/subtopic.html#801

which I've frequently commented was possibly a reaction to the
failed future system project
http://www.garlic.com/~lynn/submain.html#futuresys

where 801 appeared to take nearly the opposite tack from that of the
future system project with regard to hardware complexity.

and just for the fun of it, other posts that include early emails that
mention 801
http://www.garlic.com/~lynn/2003e.html#65 801 (was Re: Reviving Multics
http://www.garlic.com/~lynn/2003j.html#42 Flash 10208
http://www.garlic.com/~lynn/2006b.html#38 blast from the past ... macrocode
http://www.garlic.com/~lynn/2006c.html#3 Architectural support for programming languages
http://www.garlic.com/~lynn/2006o.html#45 "25th Anniversary of the Personal Computer"
http://www.garlic.com/~lynn/2006p.html#15 "25th Anniversary of the Personal Computer"
http://www.garlic.com/~lynn/2006p.html#39 "25th Anniversary of the Personal Computer"
http://www.garlic.com/~lynn/2006p.html#42 old hypervisor email

more than 16mbyte support for 370

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: more than 16mbyte support for 370
Newsgroups: alt.folklore.computers
Date: Fri, 27 Oct 2006 09:06:29 -0600

for another old email ... here is comment on proposal for adding
>16mbyte real storage to 370 (originally 3033, but also used with
3081s and 3090s in 370 mode)


From: wheeler
Date: 01/21/80  11:39:17
To: somebody in Endicott

I got a call at home from YKT telling me about POK processor plans are
slipping but they want to maintain revenue flow. Proposal is to offer
>16meg real storage /processor. Use of additional storage would only
be via use of current "Must BE" Zero bits in existing page table entries
(i.e. two additional address lines from the PTE would allow
addressibility thru 64meg., instruction decode/addressibility, etc.
remain unaltered and limited to 24bit addresses). POK/VM proposal was
to limit all of CP and control blocks to <16meg.  Virtual pages would
only be allowed >16meg. Any CP instruction simulation encountering
page >16meg. would result in page being written out to DASD and read
back into storage <16meg. Flag would also be set in SWPFLAG for that
page indicating that in the future that page could only be page into
addresses <16meg (major problem they overlooked, other than the
obvious overhead to do the page out / page in, is that after some
period of time, most pages would get the <16meg flag turned on.

I countered with subroutine in DMKPSA of about 25-50 instructions
which is supplied real address in CP control block (<16 meg), real
address in virutal page (possibly >16meg), and length. Subroutine
would 'insert' real addresses in two available PTEs in CP's virtual
address tables. It would then enter translate mode, supervisor state,
perform an MVCL and then revert to non-translate mode (I had
originally created CP virtual address space control blocks in cp67 for
paging portions of the cp67 kernel, implemention that later shipped
in vm370).

No page out/page in, and no creeping overhead problem where most pages
eventually get the <16meg flag turned on. Also if special case MVCL
was ever created to handle >16meg. addresses it would be a very small
hit to the subroutine only.

It also has the attraction that access to virtual machine storage is
concentrated in one place. It makes it much simpler to modify large
sections of CP to run in relocate mode all of the time.  Movement of
most CP code to 'psuedo' virtual machine/ virtual address space leaves
something behind which is much more nearly containable entirely in
microcode.

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

this also was somewhat intertwined with comparisons of clusters of
4341 that had aggregate greater thruput and less cost than 3033. part
of this was that 4.5mips 3033 could only be configured with 16mbytes
real storage ... while six 4341s (easily aggregate six mips) could
have an aggregate of 96mbytes real storage (@16mbytes each) ... for
about the same cost. this was in the era when real storage was
increasingly being used to compensate for the lack of disk relative
system thruput (i.e. systems were getting faster and disks were
getting faster, but the rate that disks were getting faster was much
less than the rate that cpus and memories were getting faster).

misc. posts from this year mentioning 370 >16mbyte real storage:
http://www.garlic.com/~lynn/2006b.html#34 Multiple address spaces
http://www.garlic.com/~lynn/2006c.html#8 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006e.html#45 using 3390 mod-9s
http://www.garlic.com/~lynn/2006l.html#2 virtual memory
http://www.garlic.com/~lynn/2006m.html#27 Old Hashing Routine
http://www.garlic.com/~lynn/2006m.html#32 Old Hashing Routine
http://www.garlic.com/~lynn/2006o.html#68 DASD Response Time (on antique 3390?)
http://www.garlic.com/~lynn/2006p.html#0 DASD Response Time (on antique 3390?)
http://www.garlic.com/~lynn/2006s.html#42 Ranking of non-IBM mainframe builders?

misc posts from this year mentioning 4341 clusters:
http://www.garlic.com/~lynn/2006b.html#39 another blast from the past
http://www.garlic.com/~lynn/2006i.html#41 virtual memory
http://www.garlic.com/~lynn/2006l.html#2 virtual memory
http://www.garlic.com/~lynn/2006l.html#4 Google Architecture
http://www.garlic.com/~lynn/2006p.html#0 DASD Response Time (on antique 3390?)
http://www.garlic.com/~lynn/2006r.html#4 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006s.html#41 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006s.html#42 Ranking of non-IBM mainframe builders?

misc. posts from this year mentioning the declining relative system thruput
of disks:
http://www.garlic.com/~lynn/2006.html#4 Average Seek times are pretty confusing
http://www.garlic.com/~lynn/2006e.html#45 using 3390 mod-9s
http://www.garlic.com/~lynn/2006f.html#1 using 3390 mod-9s
http://www.garlic.com/~lynn/2006j.html#2 virtual memory
http://www.garlic.com/~lynn/2006m.html#32 Old Hashing Routine
http://www.garlic.com/~lynn/2006o.html#65 "25th Anniversary of the Personal Computer"
http://www.garlic.com/~lynn/2006o.html#68 DASD Response Time (on antique 3390?)
http://www.garlic.com/~lynn/2006r.html#31 50th Anniversary of invention of disk drives
http://www.garlic.com/~lynn/2006r.html#36 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006r.html#37 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006s.html#42 Ranking of non-IBM mainframe builders?

misc. posts from this year moving nearly all of vm370 spool file support
itno virtual address space:
http://www.garlic.com/~lynn/2006e.html#36 The Pankian Metaphor
http://www.garlic.com/~lynn/2006k.html#51 other cp/cms history
http://www.garlic.com/~lynn/2006o.html#64 The Fate of VM - was: Re: Baby MVS???
http://www.garlic.com/~lynn/2006p.html#10 What part of z/OS is the OS?
http://www.garlic.com/~lynn/2006p.html#11 What part of z/OS is the OS?
http://www.garlic.com/~lynn/2006p.html#28 Greatest Software Ever Written?
http://www.garlic.com/~lynn/2006q.html#27 dcss and page mapped filesystem
http://www.garlic.com/~lynn/2006s.html#7 Very slow booting and running and brain-dead OS's?
http://www.garlic.com/~lynn/2006s.html#25 VM SPOOL question

Is the teaching of non-reentrant HLASM coding practices ever defensible?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever defensible?
Newsgroups: alt.folklore.computers
Date: Fri, 27 Oct 2006 10:00:22 -0600

Anne & Lynn Wheeler <lynn@garlic.com> writes:

this also caused some perturbation in the original relational/sql
implementation (all done as a vm370-based implementation).
http://www.garlic.com/~lynn/submain.html#systemr

where there was going to be some (virtual address space/)processes
that had r/w access to the data ... but there was design that had
application with access to some of the same data ... only unable to
change that data. it was ideally designed to take advantage of the
original 370 virtual memory architecture segment protection. however,
the implemention then required some amount of fiddling for release
as sql/ds.

for some trivia ... one of the people in the following meeting claimed
to have been primary person handling sql/ds technology transfer from
endictt back to stl for db2
http://www.garlic.com/~lynn/95.html#13

re:
http://www.garlic.com/~lynn/2006s.html#61 Is the teaching of non-reentrant HLASM coding practices ever defensible?

... in the following old email, DWSS was part of the original
technology transfer of system/r to endicott for sql/ds (vm370 support
for r/w, "unprotected" shared segments)


From: wheeler
Date: 02/27/80  08:37:42
To: numerous people in Endicott

re: yesterday's protect bit discussion.

It does make a difference whether the protect bit is in the page table
entry or segment table entry (page table entry bit , I think may have
originated MVS 811 hardware to provide them selective storage
protection in addition to don't trash/stomp on page zero for system
protection).

Segment table entry protect bit provides selective protection for some
users and the possibility of no protection for others, i.e. some
virtual address space have R/W shared segments (DWSS) and others only
have R/O access. Segment table protect bit was also defined in the
original 370 architecture.

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

other refs in this thread
http://www.garlic.com/~lynn/2006s.html#64 Is the teaching of non-reentrant HLASM coding practices ever defensible?
http://www.garlic.com/~lynn/2006t.html#1 Is the teaching of non-reentrant HLASM coding practices ever defensible?
http://www.garlic.com/~lynn/2006t.html#2 Is the teaching of non-reentrant HLASM coding practices ever defensible?

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

old Gold/UTS reference

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: old Gold/UTS reference
Newsgroups: alt.folklore.computers
Date: Fri, 27 Oct 2006 10:38:32 -0600

so the old trivia about why Amdahl Unix was referred to as
"gold" before it was announced as UTS?

note that ibm was doing tss/370 rpq for bell ... ssup. this was all of
the tss/370 ui/api stripped away and unix interfaced to low-level
tss/370 kernel.


From: wheeler
Date: 03/17/80  08:42:26

Talked to people from Amdahl for two hours about UNIX. They now have a
PHD who started working on putting up UNIX under VM while at
Princton. It is now up and running at Amdahl production.  Claim is
that it represents more of a load on the VM system than either SCPs or
CMS.

Somewhat simpler than CMS. By convention and/or design system tends to
two and three letter commands w/o arguments. There might be 20 or 30
versions of a program like copyfile and since the possible two letter
commands starting with 'C' is limited there would be a tendency to use
any available two letter combination rather than go to 3 or 4
letters.

Comment is that it has become something a 'cult' amoung computer
science graduates (at least one of the people had used UNIX for 4-5
years in college) and fealing was that the high use of UNIX at Amdahl
(over CMS) wasn't really justified. However from Bell's stand point,
it's availability across the line of computers is very attractive.

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

previous post mentioning ssup/unix and uts ... including email from
'84 talking about benchmark comparing ssup/unix and uts
http://www.garlic.com/~lynn/2006e.html#31 MCTS

other posts mentioning ssup/unix and/or uts:
http://www.garlic.com/~lynn/96.html#4a John Hartmann's Birthday Party
http://www.garlic.com/~lynn/99.html#2 IBM S/360
http://www.garlic.com/~lynn/2000b.html#61 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000c.html#8 IBM Linux
http://www.garlic.com/~lynn/2000f.html#68 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000f.html#69 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000f.html#70 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2001e.html#19 SIMTICS
http://www.garlic.com/~lynn/2001f.html#20 VM-CMS emulator
http://www.garlic.com/~lynn/2001f.html#22 Early AIX including AIX/370
http://www.garlic.com/~lynn/2001f.html#23 MERT Operating System & Microkernels
http://www.garlic.com/~lynn/2001l.html#8 mainframe question
http://www.garlic.com/~lynn/2001l.html#17 mainframe question
http://www.garlic.com/~lynn/2001l.html#18 mainframe question
http://www.garlic.com/~lynn/2001l.html#20 mainframe question
http://www.garlic.com/~lynn/2002f.html#42 Blade architectures
http://www.garlic.com/~lynn/2002i.html#63 Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002m.html#21 Original K & R C Compilers
http://www.garlic.com/~lynn/2002m.html#24 Original K & R C Compilers
http://www.garlic.com/~lynn/2002n.html#32 why does wait state exist?
http://www.garlic.com/~lynn/2002n.html#54 SHARE MVT Project anniversary
http://www.garlic.com/~lynn/2002n.html#58 IBM S/370-168, 195, and 3033
http://www.garlic.com/~lynn/2003c.html#53 HASP assembly: What the heck is an MVT ABEND 422?
http://www.garlic.com/~lynn/2003d.html#54 Filesystems
http://www.garlic.com/~lynn/2003g.html#24 UltraSPARC-IIIi
http://www.garlic.com/~lynn/2003g.html#31 Lisp Machines
http://www.garlic.com/~lynn/2003h.html#52 Question about Unix "heritage"
http://www.garlic.com/~lynn/2003i.html#53 A Dark Day
http://www.garlic.com/~lynn/2004g.html#4 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#16 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004p.html#10 vm/370 smp support and shared segment protection hack
http://www.garlic.com/~lynn/2004q.html#37 A Glimpse into PC Development Philosophy
http://www.garlic.com/~lynn/2005b.html#13 Relocating application architecture and compiler support
http://www.garlic.com/~lynn/2005c.html#20 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005d.html#61 Virtual Machine Hardware
http://www.garlic.com/~lynn/2005m.html#4 [newbie] Ancient version of Unix under vm/370
http://www.garlic.com/~lynn/2005m.html#7 [newbie] Ancient version of Unix under vm/370
http://www.garlic.com/~lynn/2005p.html#44 hasp, jes, rasp, aspen, gold
http://www.garlic.com/~lynn/2005q.html#26 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005s.html#34 Power5 and Cell, new issue of IBM Journal of R&D
http://www.garlic.com/~lynn/2006b.html#24 Seeking Info on XDS Sigma 7 APL
http://www.garlic.com/~lynn/2006c.html#18 Change in computers as a hobbiest
http://www.garlic.com/~lynn/2006e.html#33 MCTS
http://www.garlic.com/~lynn/2006f.html#26 Old PCs--environmental hazard
http://www.garlic.com/~lynn/2006f.html#27 Old PCs--environmental hazard
http://www.garlic.com/~lynn/2006f.html#28 Old PCs--environmental hazard
http://www.garlic.com/~lynn/2006m.html#30 Old Hashing Routine
http://www.garlic.com/~lynn/2006p.html#22 Admired designs / designs to study
http://www.garlic.com/~lynn/2006p.html#26 Admired designs / designs to study

Why magnetic drums was/are worse than disks ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why magnetic drums was/are worse than disks ?
Newsgroups: alt.folklore.computers
Date: Fri, 27 Oct 2006 12:41:17 -0600

Anne & Lynn Wheeler <lynn@garlic.com> writes:

when i was trying to get 3350 hardware change to support multiple
exposures, i also redid the internal control block structure for page
allocation on disk ... from being purely device oriented to being
arbitrary device sub-areas ... having any organization. the default
structure was all paging areas on a device ... following the previous
purely device "speed" organization. However, it also allowed
organizing the 3350 fixed head area on equivalent round-robin level
with other fixed-head areas (like 2305 fixed-head disks). the
combination of the 3350 hardware change for multiple exposures, the
various page migration pieces, and the redo of the allocation control
block struction (allowing arbitrary storage allocation policies) ...
made the 3350 fixed head area significantly more useful.

re:
http://www.garlic.com/~lynn/2006s.html#59 Why magnetic drums was/are worse than disks ?

some old email discussing page allocation rework ... somewhat motivated
by the 3350 fixed-head feature


From: wheeler
Date: 01/19/80  10:45:54
To: several people in POK

re: design for contiguous allocation of paging backing store.
ref: SYSPAG script file.

New entry point can be defined in DMKPGT to allocate contiguous blocks
(similar to the current 3705 code, possible to enhance that code so
that it would serve both purposes). DMKPGM will be responsible for
determining if continguous allocation areas are required.  It will
call PGT to allocate the contiguous space. A SYSPAG block will be
built which is chained off of the VMBLOK & points to an ALOCBLOK for
the contiguous storage. The SYSPAG block will also point back into the
normal SYSPAG chain allocation. Normal PGT allocation on reaching the
end of preferred , non-drum SYSPAG (at the smae place a test is made
to determine if the preferred paging area 'full' flag is to be set), a
check will be made for the existance of a VMBLOK's SYSPAG block. If
one is found, the SYSPAG register pointer will be switched to the
VMBLOK's SYSPAG block (the VMBLOK, SYSPAG block will point back into
the SYSPAG chain if no room is found in the VMBLOK area). DMKUSO will
be responsible for releasing all the control blocks and allocate
areas.

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

now in the following, the reference to DMKPGM was to page migration
function that I had introduced as part of my resource manager
http://www.garlic.com/~lynn/2001e.html#45 VM/370 Resource Manager

which included a lot of stuff i had done as an undergraduate for
cp67 and then was subsequently dropped in the morph to vm370 ...

.... in new syspag, since there was a different structure for chain
structure for allocation and deallocation ... just by removing all the
relavent blocks from the allocation structure ... and then invoking
page migration to move everything off a specific device ... there was
no problem interlocking new pages getting allocated on the device
(while page migration was running). the separate allocation and
deallocation structures ... also made it possible to allow for a
user-specific contiguous page allocation ... as mentioned in the above
email.


From: wheeler
Date: 02/27/80  18:58:19
To: several people in POK

A couple of additional points showed up today. SYSPAG allocation
blocks are alwas constructed whether anything was specified at all or
not. Attach/CPI subroutine will build default structure/ordering
if no SYSPAG specifications have been made. Benefit is that PGT code
is small, simple, short , and fast and the same alwas. Complex
desisions are made  when blocks are built (and or merged).
This is of a lot of benefit because of frequent use of PGT compared
to DMKCPI.

Another point came up. Requirment was to take volumes off line. Turns
out SYSPAG structure easily supports implementation. All allocation
blocks are double threaded. One way for allocation search and a
different chain for de-allocation. Take about 75% of existing code in
DMKPGM, put in another 300 or so lines of code and you have vary off
support of paging packs. New module would unchain all blocks for
specific device from allocation chain, but leave on de-allocation
chain. Then PGM code would be turned loose for pages on the specific
device. When finished allocation blocks could be unchained from
de-allocation chain and FRET'ed. I said in the document that design
was open ended to allow dynamic re-organization of chains.

... snip ...

a past post also mentioning syspag work:
http://www.garlic.com/~lynn/2000b.html#43 Migrating pages from a paging device (was Re: removal of paging device)

another past post mentioning syspag work ... as well as subsequent
work on "big pages" (originally for 3380s) which somewhat subsumed
much of the earlier demand page-at-a-time optimization:
http://www.garlic.com/~lynn/2003f.html#5 Alpha performance, why?

old vm370 mitre benchmark

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: old vm370 mitre benchmark
Newsgroups: alt.folklore.computers
Date: Fri, 27 Oct 2006 13:21:18 -0600

Anne & Lynn Wheeler <lynn@garlic.com> writes:

i tested the program with 3830 controllers on 4341, 158, 168, 3031,
3033, and 3081. it turns out that a 3830 in combination with 4341 and
370/168, the head switch command processed within the 101 byte
rotation latency.

combination of 3830 and 158 didn't process the head switch command
within the 101 byte rotation (resulting in a missed revolution). the
158 had integrated channel microcode sharing the 158 processor engine
with the 370 microcode. all the 303x processors had a external
"channel director" box. the 303x channel director boxes were a
dedicated 158 processing engine with only the integrated channel
microcode (w/o the 370 microcode) ... and none of the 303x processors
could handle the head switch processing within the 101 byte dummy
block rotation latency. the 3081 channels appeared to have similar
processing latency as 158 and 303x channel director (not able to
perform head switch operation within 101 dummy block rotation).

i also got a number of customer installations to run the test with a
wide variety of processors and both 3830 controllers and oem clone
disk controllers.

re:
http://www.garlic.com/~lynn/2006r.html#40 REAL memory column in SDSF

Problem with benchmarking Mitre paging changes is that they included
"BU" (boston univ) 3330 paging performance enhancements. The problem
was that only able to do 3330 multi-page transfer in single revolution
on 145/148/4341 and 168 ... attempting it on 158 and any 303x could
result in severe performance degradation ... because there would be
additional full revolution for each page transfer ... which not only
tied up the device ... but the disk controller (locking out all other
disks on the same controller) and the channel.

the "2880" is the external channel box used by 370/168. 145/148/4341
had integrated channels ... as did the 370/158. as mentioned before,
the 370/158 integrated channels was basis for the external 303x
channel director box used by all 303x models.


From: wheeler
Date: 02/28/80  12:12:17
To: numerous vm370 product support people

re: benchmark Mitre paging changes;

somebody got a little 'took' on those changes. They include head
switch 3330 changes from BU off the Waterloo tape. I sent out detailed
info to at least some of you over a year ago.

Specs for 3330 don't allow enuf time to head switch between records
with less than a 110 dummy record gap between pages. 3330 track is
only spec'ed at about 100-101 bytes available for dummy record. BU
went ahead an put in changes for head switching on their 145 system
using 101 byte gaps (and optional code to count the number of
succesful head switches).  I got same code benchmarked on 145, 158,
168, 3031, 3033; with ISCs, with 3830s, with&w/o string switching. Also
got 168 benchmark with IBM drives, CDC drives, and Memorex drives.

145&168 on all combinations of IBM drives and CDC drives were able to
succesfully switch almost 100% of the time (Memorex drives could do
head switch with 50 byte gaps 100% of the time).

158 at its best would only be succesful about 20% of the time, the
rest of the time requiring additional revolutions.

Turns out 145 channels are the best of the 370 line (rated around 2.7
megabyte capacity according to the engineers), then the 2880 and then
the 158 channels. The 158 channels are by far the slowest of the
three. It also turns out the 303x share the same hardware channel
directors and all have performance numbers in this area comparable to
the 158. It turns out that the channel directors are substantially 158
boxes. 148 are substantially 145 channels and I believe the 4341
channels are somewhat better.

I also 'warned' several IBM'ers to be wary of upgrading 168s with BU
mods. and heavy 3330 paging to same configuration on any 303x because
they may experience a degradation of thru-put.

I can somewhat understand the questionable benchmark results that was
obtained by IBM running the Mitre mods. on 158 with 3330 paging.

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

other posts in the referenced thread:
http://www.garlic.com/~lynn/2006r.html#34 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006r.html#35 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006r.html#36 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006r.html#37 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006r.html#39 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006r.html#42 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006r.html#43 REAL memory column in SDSF

Why these original FORTRAN quirks?; Now : Programming practices

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why these original FORTRAN quirks?; Now : Programming practices
Newsgroups: alt.folklore.computers,comp.lang.fortran
Date: Fri, 27 Oct 2006 14:14:19 -0600

glen herrmannsfeldt <gah@seniti.ugcs.caltech.edu> writes:

The mmm is incremented.  You need to supply one DD card
for each file you expect to read.  There is no requirement
that they be on the same tape, or even on tape at all.
One reason is the extra work to process standard labelled
tapes.  There are label records between files, in addition
to the tape mark.

VMS processes ANSI labelled tapes, and so may also do
some of this processing.  I did once convince OS/VS2
to write an ANSI labelled tape to read on VAX/VMS.

standard label had 80-byte "VOL1" record (similar to what is used on
disk). files had 80-byte "HDR1" record (and sometimes "HDR2" records)
... dating back to at least 360 days.

here is more discussion (from quicky use of search engine) for "VOL1"
and "HDR1"
http://it-dep-fio-ds.web.cern.ch/it-dep-fio-ds/Documentation/tapedrive/labels.html

above also discusses ansi x3.27 standard and dec systems use.

some of the current tape library software managing later generations
of large capacity tapes do volume stacking ... where a single physical
tape will contain images of multiple logical tape volumes.

search engine reference included volume stacking
http://publib.boulder.ibm.com/infocenter/pdthelp/v1r1/topic/com.ibm.filemanager5.doc/base/fmnu1e02233.htm

misc. other search engine URLs mentioning VOL1 and HDR1
http://www.vsoftsys.com/doc/doc42/vtape/vtap4006.htm
http://operations.rutgers.edu/tapes/tape_formats.html
http://www-03.ibm.com/servers/eserver/zseries/zvse/downloads/tools.html
http://groups.google.com/group/alt.sys.pdp11/browse_thread/thread/d043a37616ff4e19/ac76930d628ef0fa
http://www.decus.org/libcatalog/document_html/vs0097_8.html
http://cnlart.web.cern.ch/cnlart/234/art_tlab.html
http://www.cbttape.org/awstape.htm
http://mitvma.mit.edu/cmshelp.cgi?CMS%20TAPEMAC%20
http://mitvma.mit.edu/cmshelp.cgi?CMS%20TAPPDS%20
http://pcmap.unizar.es/softlinux/VMS-to-Linux-HOWTO.txt

search engine even turns up one of my old pasts mentioning VOL1 and
HDR1:
http://www.garlic.com/~lynn/2004q.html#20 Systems software versus applications software definitions

which discusses an old backup/archive system that i had written for
internal use ... which then went thru several iterations and
eventually released as workstation datasave facility, morphed into
ADSM and is now known as TSM
http://www.garlic.com/~lynn/submain.html#backup

in Melinda's section on CMSBACK in her history
http://www.princeton.edu/~melinda/25paper.pdf

her history starts with what would be considered "version 3" (or maybe
version 4) of CMSBACK. I had done the implementation and
deployment for the initial version; then another person and I did
quite a bit of enhancements. The other person that I worked with, left
IBM and went on to do development for some number of other (non-ibm)
vm archive/backup systems (and I started work on other projects). It
was in this period, that it was turned over to the two people
mentioned in Melinda's history related to CMSBACK.

Between the start of that phase in CMSBACK development and the
release of workstation datasave facility (precursor to
ADSM), there was an effort (not mentioned in Melinda's history)
to get Endicott to make it available as a product. Endicott evaluated
marketing one of the non-IBM products or releasing the internal
CMSBACK. At that time, Endicott chose to market one of the
non-IBM products (much of that development had been done by the same
person that I had worked with on the earlier CMSBACK version).

from Melinda's paper

ADSM had its origins in about 1983 as a program called CMSBACK,
written by two VM support people at IBM's Almaden Research, Rob Rees
and Michael Penner. CMSBACK allowed CMS users to back up and restore
their own files. It quite naturally became the basis a few years later
for a program to allow workstation users to back up and restore their
files, which was announced as the WDSF/VM product in 1990. By that
time, VM Development in Endicott had gotten involved, doing much of
the work required to bring the new product to market.

... snip ...

CMSBACK actually dates back a number of years earlier, before Almaden
was built and/or the two mentioned individuals had even been hired.

Are there more stupid people in IT than there used to be?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Are there more stupid people in IT than there used to be?
Newsgroups: alt.folklore.computers
Date: Fri, 27 Oct 2006 14:58:22 -0600

"Charlie Gibbs" <cgibbs@kltpzyxm.invalid> writes:

The larger the group, the lower the effective intelligence of that
group, regardless of the intelligence of its individual members.
I suspect the formula is something like the one for calculating
resistances in parallel.

some quantifications about group intelligence as
the lowest member iq

min(iq1, iq2, ... iqN)

but then instead of the avg

sum(iq1, iq2, ..., iqN)/N

it may be more like

sum(iq1, iq2, ..., iqN)/(N**2)

sum of the inidividual IQs divided by the square of the number of
individuals ... instead of tending to the lowest IQ in the group ...it
quickly tends to zero as the size of the group grows (avg group
IQ divided by the number of members) ... possible

min(iq1, iq2, ..., iqN)/N

or the minimum IQ divided by the number of members.

there has been this constant thread about not enuf trained resources
dating back to at least the mid-70s ... and probably long before.

in the mid-70s ... the 370/148 project wanted to go after a greatly
increased market ... but they recognized that there wasn't enuf
traditional skilled resources. they needed to dumb down the skill
requirements for supporting systems (although they didn't express it
in those terms) ... which in turn required layer of software that
automatically did lots of the stuff that had previously been done by
skill support person.

the two analogies that were frequently used in the mid-70s were

1) Ford trying to figure out how to drastically expand market for the
Model T ... up until then automobiles required a chauffeur that was
also a fairly skilled mechanic. over time, automobile use was
drastically simplified so that they could be operated by people that
may not have the slightest idea of how they worked.

2) phone company project that to expand telephone use would require
hiring at least half of the adults in the country as operators.  the
phone paradigm was changed with each user becoming their own operator
... aka they did their own dialing ... which was then handled by
automatic switching equipment.

part of expanding the market was making the computer product
significantly less expensive and more of a commodity. at some point,
the market inhibitor became not the expense of the product ... but the
cost of the highly trained talent needed to support the product. at
some point the necessary highly trained talent could be several times
more expensive than the product itself. so attempts are made to lower
skill level necessary for operating computer products compareable to
that necessary for operating an automobile (or a telephone).

threads versus task

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: threads versus task
Newsgroups: comp.arch
Date: Sat, 28 Oct 2006 10:09:34 -0600

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:

Multi-tasking means that you can run several programs (seemingly)
concurrently.  Each program would run in its own task.  The programs
may run in the same address space, or in different ones, protected
from each other or not.  "Task" is not a very well-defined concept, or
maybe it is just a very general concept (and I will use it as general
term in the rest of this posting); anyway, to have something with a
more specific meaning, new terms were introduced:

A "process" (as used in Unix and most OS literature) is a task that
runs in its own address space, protected from other processes, and
commiunicating with them only through various OS mechanisms.

At some point people wanted to write programs consisting of several
tasks.  One can do this by having several processes for the program,
but that is often suboptimal, because the communication between tasks
is often more important for such programs, and having to go through OS
mechanisms can be too slow; also, the protection from other processes
is often not needed between such tasks.

os/360 had TCB or task control blocks ... for scheduling, execution
and resource management. There were system/language construct ATTACH
that could do create execution tasks under the primary scheduling
control and system WAIT/POST for coordinating operations in
multiprogramming environment.  All of this started out in the same
(real) address space.

For a lot of things, TCB was fairly heavyweight system construct ...
especially for some of the evolving online applications. So you saw
"subsystems" like CICS showing up in the late 60s that supported their
own (lightweight) tasks (very much akin to the later lightweight
threads some 20 years later) ... where the "subsystem" providing its
own (lightweight) process creation and serialization operations.  In
the later 70s, you might find a CICS regions controlling tens of
thousand and then hundreds of thousands of ATM machines ... even later
there would be CICS regions that handled millions of (cable) settop
boxes.

in any case, tasks were system (or subsystem) control and resournce
management construct. multiprogramming could be done with system tasks
or cooperating operations within a single task (and single address
space). this got more complicated when os/360 morphed into virtual
address space operation for each "task" in the mid-70s as "MVS"
(default was that "task" and "address space" was somewhat equivalent
... but then you could use system tasking facilities to invoke
multiple tasks in the same address space).

at the science center in the late 60s and early 70s, Charlie was doing
a lot of work on multiprocessor fine-grain locking in the cp67 kernel
and invented the compare&swap instruction (compare&swap mnemonic
chosen because CAS are Charlie's initials). The initial attempt to try
and get compare&swap included as part of (the new) 370 architecture
was rejected on the grounds that test-and-set (left over from 360) was
sufficient for multiprocessing control.

The challenge was that in order to get compare&swap justified in 370
... a non-multiprocessor specific use was needed. Thus was born the
use examples for atomic instruction for multiprogramming operations
... that aren't necessarily multiprocessor related. In the early 70s,
the multiprogramming use examples were originally part of the
instruction programming notes in the 370 principle of
operations. later principle of operations moved the use examples to
the appendix.

a couple recent posts mentioning comapre&swap
http://www.garlic.com/~lynn/2006s.html#21 Very slow booting and running and brain-dead OS's?
http://www.garlic.com/~lynn/2006s.html#53 Is the teaching of non-reentrant HLASM coding practices ever defensible?

while multiprogramming and system TASKs are somewhat loosely related
...  TASKs can be in different address spaces ... and multiple
execution in the same address space can be done w/o (heavyweight)
system TASKS.

recent principle of operations appendix reference

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

from above:

When two or more programs sharing common storage locations are being
executed concurrently in a multiprogramming or multiprocessing
environment, one program may, for example, set a flag bit in the
common-storage area for testing by another program. It should be noted
that the instructions AND (NI or NC), EXCLUSIVE OR (XI or XC), and OR
(OI or OC) could be used to set flag bits in a multiprogramming
environment; but the same instructions may cause program logic errors
in a multiprocessing configuration where two or more CPUs can fetch,
modify, and store data in the same storage locations simultaneously.

Subtopics:

• A.6.1 Example of a Program Failure Using OR Immediate
• A.6.2 Conditional Swapping Instructions (CS, CDS)
• A.6.3 Bypassing Post and Wait
• A.6.4 Lock/Unlock
• A.6.5 Free-Pool Manipulation
• A.6.6 PERFORM LOCKED OPERATION (PLO)

... snip ...

threads versus task

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: threads versus task
Newsgroups: comp.arch
Date: Sat, 28 Oct 2006 13:07:19 -0600

nmm1@cus.cam.ac.uk (Nick Maclaren) writes:

Before MVS/XA, it was almost impossible for an application to switch
address space, even if privileged.  Theoretically, it was there a bit
earlier, but ....

re:
http://www.garlic.com/~lynn/2006t.html#22 threads versus task

the mid-60s os/360 philosophy heavily revolved around *scarce* real
storage assumptions. the apis were all pointer passing and the i/o
model involved direct transfers involving application buffers. the
physical i/o commands were built directly by applications pointing to
their real buffer addresses (and/or library routines directly called
by applications).

the i/o library routines provided a number of asynchronous and
synchronous abstractions. the asynchronous abstractions for i/o provided
a natural multiprogramming environment ... where application logic
might possibly be dealing with multiple i/o buffers and overlapping
execution with i/o transfer ... requiring various amounts of WAIT
operations for serialization.

one might assert that the posix activity from the late 80s and early
90s for async i/o and threading was to translate this mid-60s paradigm
into unix environment (some number of dbms applications would take
advantage of such features ... somewhat emulating operation of online
os/360 dbms activity dating back to the 60s).

the os/360 transition to virtual address spaces in the mid-70s carried
with it a number of problems.

the application convention of building the physical i/o commands no
longer used real addresses ... but were virtual (buffer)
addresses. the low level kernel function supporting application i/o
had to be enhanced to scan/interpret the application i/o command
operations, create *shadow* copy of the application i/o command
sequence, translating all the virtual addresses into real addresses
(as well as fetching and pinning the associated virtual pages until
the real i/o sequence had completed).

the prevalent use of pointer passing in APIs resulted in the kernel
code sharing the application address space. Initially in mvs/370 with
16mbyte virtual address spaces, one per application ... the kernel
occupied half of the 16mbytes, in theory leaving 8mbytes for each
application.

however, the os/360 heritage also had a lot of "subsystem" services
that weren't part of the kernel, each were now in their own unique
virtual address space ... but still "called" by applications with
pointer passing api. Initially this was addressed by a "common
segment" that appeared in every virtual address space where parameters
could be stashed and then directly accessed by subsystems using the
passed (parameter address) pointers. However, for large operations
with a large number of possible different subsystems, it wasn't
uncommon to find that the "common segment" had to be expanded to five
mbytes. With the kernel taking 8mbytes out of each address space and
"common segment" taking 5mbytes (and potentially still growing), it
would only leave 3mbytes for applications use.

to help address this problem, 3033 (introduced in the late 70s)
provided "dual-address" space support. A new addressing mode was
provided to semi-privileged subsystems (running in their own address
space) that allowed them to "reach" across into application virtual
address space and access the parameters that needed to be referenced
in the pointer-passing API. A subsystem implementation, running in its
own virtual address space could be multiprogrammed with each
invokation having its own state consisting of registers and
instruction address ...  as well as control register pointing to the
invoking application virtual address.

Later (mvs/xa) 370 virtual addressing was increased from 24bit to
31bit and dual-address space support was generalized with access
registers and multiple address space operation. Not only could
subsystems reside in their own address space ... but a lot of the
former system library software that was loaded and executed as part of
an application could be moved into unique semi-privileged address
space. A new hardware call instruction was defined that referenced a
system defined table which controlled switching address space pointers
and some number of other access control features. The operation could
appear still as if it was direction executing under the application
task control block (and resource control) ... but instead of execution
continuing in a library routine in the application address space
... execution was continuing in a library routine that resided in a
totally different address space. more detailed discussion of
access registers and multiple address space operation
http://www.garlic.com/~lynn/2006r.html#32 MIPS architecture question - Supervisor mode & who is using it?

Sort of the original default was a single TCB (for resource control)
mapping to a single application (and later a single address space).
However, various options and features allowed this to get potentially
extremely complicated with possibly multiprogramming under a single
TCB (providing something akin to multi-threading in single process),
multiple TCBs operating in the same address space, a single TCB with
multiple address spaces, and/or multiple TCBs and multiple address
spaces.

in unix environments ... w/o posix async i/o and threading ... you had
DBMS translated (to unix) where there were multiple different
processes and address spaces ... with the address spaces setup to
share a lot of common storage (in order to simulate lightweight
threading in a single address space). early on, the DBMS would
implement "raw" I/O to the physical device ... in order to achieve the
effect of asynchronous operation and direct transfers to/from
application memory/buffers.

somewhat in parallel with os/360 with real storage later morphing into
virtual memory MVS system ... there was the original cp67 virtual
machine system ... started originally in 1966 as cp40 with a custom
modified 360/40 with virtual memory. In 1967, cp40 morphed into cp67
when standard virtual memory 360/67 machines became available. cp67
made extensive use of the virtual memory hardware in its virtual
machine implementations. later cp67 morphed into vm370 when virtual
memory became available on 370s. melinda's vm370 history, mentioning
ctss, multics, cp40, cp67, etc
http://www.princeton.edu/~melinda/25paper.pdf

the original relational/sql implementation was system/r done in
the 70s on vm370 platform
http://www.garlic.com/~lynn/submain.html#systemr

this made use of multiple virtual address spaces with some amount of
the virtual address space shared across independent cooperating
processes (virtual machines) recent post mentioning some of the
technology transfer for system/r from san jose to endicott for sql/ds
product
http://www.garlic.com/~lynn/2006t.html#16 Is the teaching of non-reentrant HLASM coding practices ever defensible?

it is somewhat this model in the mid to late 80s, that you saw some
DBMS vendors translating into unix environment with multiple processes
each with their different address spaces ... where the different
address spaces shared some amount of common storage (and DBMS was
using unix "raw i/o" for accessing disks for futher asynchronous
operation)

some other recent posts mentioning dual-address space and/or access
register operation
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/2006s.html#42 Ranking of non-IBM mainframe builders?

CMSBACK

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: CMSBACK
Newsgroups: alt.folklore.computers,bit.listserv.vmesa-l
Date: Sat, 28 Oct 2006 14:17:47 -0600

Anne & Lynn Wheeler <lynn@garlic.com> writes:

search engine even turns up one of my old pasts mentioning VOL1 and
HDR1:
http://www.garlic.com/~lynn/2004q.html#20 Systems software versus applications software definitions

which discusses an old backup/archive system that i had written for
internal use ... which then went thru several iterations and
eventually released as workstation datasave facility, morphed into
ADSM and is now known as TSM
http://www.garlic.com/~lynn/submain.html#backup

re:
http://www.garlic.com/~lynn/2006t.html#20 Why these original FORTRAN quirks?; Now : Programming practices

old email from the other person working on CMSBACK version 2. this is
on enhancing the pattern matching capability in the user interface
file retrieval process (from the backup/archive repository).

as noted in the above reference, Melinda's history starts with what
would be CMSBACK version 3 (or possibly 4 ... depending on how you
classify all the work done between my initial CMSBACK deployments and
start of work by the people mentioned in Melinda's history).
http://www.princeton.edu/~melinda/25paper.pdf


To: wheeler
Date: 10/25/79  02:11:58

I had to make one change to OSPATM to make it work. The macro SREGS is
a bit too much for me tonite so I replaced the one to set up
addressability to the work area using R5 with the L R5,8(,R1) and
USING PATSPC,R5. AND......  it works like a super star!!!! Try issuing
the CMSBACK exec, ask for a report, and enter whatever patterns you
like.. Disk load the returned RPT file and see what you get.. I've
been playing with it now for a while and it really works great. (I
will make the matching available on date and time tommorrow..  why
stop with just the filename and filetype).

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

for the original low-level CMSBACK interface to tape, I used a highly
modified version of VMFPLC (mentioned in the old email below) that I
had renamed VMXPLC. Not mentioned in the below ... but it was also
enhanced to provide optimal processing for the paged mapped filesystem
implementation that I had done
http://www.garlic.com/~lynn/submain.html#mmap

start of buffers were page aligned ... and 15 800 byte data blocks
could be three 4096 byte blocks. For small files, the minimum size
data block on tape could be 800 bytes. With separate FST record and
data block, a tape with a lot of small files would have half (or more)
of the length could be taken up with interrecord gaps. Merging the FST
record and the first data record into the same physical tape record,
would cut the tape devoted to interrecord gaps in half (when lots of
small files was involved).


From: wheeler
Date: 03/21/80  13:41:39
To: somebody in endicott

The original VMFPLC was an update to release 2 DMSTPE. The code took
the FST record which is placed in a trailing 800 byte record following
the file dumped and placed it in a 59 byte record in front of the file
dumped. It also blocked up to 5 800 byte data blocks per physical tape
block. I captured the update early and maintained it (I heard that the
development lost it and didn't have a copy) against the current
release & plc level. I also enhanced the update to block up to 15 800
byte data blocks, to merge the FST record into the 1st physical data
block dumped and to avoid rewriting the MFD after each file loaded.

VMFPLC2 appears to have several new features which would indicate that
it is not a modification of the original VMFPLC (since as far as I
know, I'm the only one with the source) but it still maintains the
original tape format.  I must confess that I've not looked at the new
release 6/bsepp tape source (although I've heard that it has grown
substantially and has been split into several files).

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

and for an even earlier CMSBACK related email. standard CMS could
"share" various filesystem areas across multiple virtual
machines. However, the filesystem status information would be
duplicated in every virtual address space. A hack was done to place a
copy of some shared CMS filesystem information in shared (r/o
protected) memory ... so there only need to be a single physical copy
of the filesystem metadata (shared across everybody). The "problem"
for DMSDSK, DMSTPE, VMFPLC and VMXPLC was that there was a hack where
they temporarily modified the file metadata that forced the logical
record size to match the physical disk record ... and then restore it
when they were done.  This hack would fail if the file metadata
information was located in shared (r/o protected) memory.


From: wheeler
Date: 04/02/79  19:22:35

Yorktown has done an update for DMSDSK (DISK DUMP) to handle the
problem of dumping from a disk with FST in shared memory
(DMSDSK YK187DMS). Can you merge with what you have been doing to
DMSTPE for TAPE, VMFPLC, & VMXPLC??????

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

and a related reference from Almaden Research
http://www.almaden.ibm.com/StorageSystems/Past_Projects/TSM.shtml

Are there more stupid people in IT than there used to be?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Are there more stupid people in IT than there used to be?
Newsgroups: alt.folklore.computers
Date: Sun, 29 Oct 2006 00:33:33 -0600

Charlton Wilbur <cwilbur@mithril.chromatico.net> writes:

Yes, this crew wanted to transmit credit card data in the clear
because they could not figure out how to establish an HTTPS connection.

My manager's response was, "sure!  as long as you put in writing that
you're choosing to do it, and you accept the liability should we get
sued."  *That* caused a flurry of activity.

recent post in this thread about some threats in this area
http://www.garlic.com/~lynn/2006t.html#5 Are there more stupid people in IT than there used to be?

and some other recent posts discussing some related threat issues:
http://www.garlic.com/~lynn/2006s.html#10 Why not 2048 or 4096 bit RSA key issuance?
http://www.garlic.com/~lynn/2006s.html#11 Why not 2048 or 4096 bit RSA key issuance?
http://www.garlic.com/~lynn/2006t.html#2 Is the teaching of non-reentrant HLASM coding practices ever defensible?
http://www.garlic.com/~lynn/2006t.html#8 Root CA CRLs

various past collected posts related to assurance
http://www.garlic.com/~lynn/subintegrity.html#assurance

as opposed to various past collected posts related to threats,
vulnerabilities, fraud, and/or exploits:
http://www.garlic.com/~lynn/subintegrity.html#fraud

and a post from today about possibly new exploit
http://www.garlic.com/~lynn/aadsm25.htm#46 Flaw exploited in RFID-enabled passports

Universal constants

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Universal constants
Newsgroups: alt.folklore.computers
Date: Sun, 29 Oct 2006 00:53:01 -0600

Steve O'Hara-Smith <steveo@eircom.net> writes:

Let an economist in and it will soon get complex.

for quite a bit of drift ... I had made a number of posts last spring
and this summer mentioning a talk given by the comptroller general
... the subject matter has apparently just been discovered in the past
day or two

GAO Chief Warns Economic Disaster Looms, GAO Chief Takes to Road,
Warns Economic Disaster Looms Even As Many Candidates Avoid Issue
http://www.cbsnews.com/stories/2006/10/28/ap/business/mainD8L1OC5G0.shtml
GAO Chief Warns Economic Disaster Looms
http://www.washingtonpost.com/wp-dyn/content/article/2006/10/28/AR2006102800420.html
GAO Chief Warns Economic Disaster Looms
http://news.moneycentral.msn.com/provider/providerarticle.asp?feed=AP&Date=20061028&ID=6145849
GAO Chief Warns Economic Disaster Looms
http://abcnews.go.com/Politics/wireStory?id=2613135
GAO Chief Warns Economic Disaster Looms
http://www.latimes.com/news/nationworld/politics/wire/sns-ap-america-the-bankrupt,1,515499.story?coll=sns-ap-politics-headlines
GAO Chief Warns Economic Disaster Looms
http://hosted.ap.org/dynamic/stories/A/AMERICA_THE_BANKRUPT?SITE=DCUSN&SECTION=TOP_STORIES&TEMPLATE=DEFAULT
GAO Chief Warns Economic Disaster Looms
http://apnews.myway.com/article/20061028/D8L1OC5G0.html
GAO chief warns economic disaster looms
http://seattlepi.nwsource.com/national/1155AP_America_the_Bankrupt.html

posts from last spring about his talk
http://www.garlic.com/~lynn/2006g.html#9
http://www.garlic.com/~lynn/2006g.html#14
http://www.garlic.com/~lynn/2006g.html#27
http://www.garlic.com/~lynn/2006h.html#2
http://www.garlic.com/~lynn/2006h.html#3
http://www.garlic.com/~lynn/2006h.html#4
http://www.garlic.com/~lynn/2006h.html#17
http://www.garlic.com/~lynn/2006h.html#19
http://www.garlic.com/~lynn/2006h.html#33

and post from late summer with some excerpts from his talk
http://www.garlic.com/~lynn/2006o.html#61

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: The Future of CPUs: What's After Multi-Core?
Newsgroups: alt.folklore.computers
Date: Sun, 29 Oct 2006 08:51:58 -0700

The Future of CPUs: What's After Multi-Core?
http://www.informit.com/articles/article.asp?p=663085&rl=1

from above (the new, 40yr old thing)

This rule was driven home to me when I attended a talk by an IBM
engineer about his company's new virtualization technology. He
commented that his company had an advantage over other people working
in the area: Whenever they were stuck, they could go along the hall to
the mainframe division and ask how they solved the same problem a
couple of decades ago.

... snip ...

semi-related thread from comp.arch
http://www.garlic.com/~lynn/2006t.html#23 threads versus task

Why these original FORTRAN quirks?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why these original FORTRAN quirks?
Newsgroups: alt.folklore.computers,comp.lang.fortran
Date: Sun, 29 Oct 2006 09:11:20 -0700

Brian Inglis <Brian.Inglis@SystematicSW.Invalid> writes:

I don't think I could justify SAS for home, and companies and staff
often have to get by with what's made available; only those with a
larger machine heritage seem to have expensive products like SAS,
because they kept the software around when they downsized machines.

recent post about using multiple regression analysis to identify a
significant performance improvement (large financial application that
ran for hours on large number of fully decked out mainframes)
http://www.garlic.com/~lynn/2006s.html#24 Curiousity: CPU % for COBOL program

I was using a free package off the web that had various limits on the
number of variables that it could handle ... which would have been
pretty much eliminated using SAS.

the original reference to performance analysis work in the early and
mid-70s at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

that eventually evolved into things like capacity planning
http://www.garlic.com/~lynn/submain.html#bench

had used multiple regression analysis from the fortran scientific
subroutine package. i have some vague memory that when the scientific
subroutine package was discontinued ... all of that stuff was possibly
picked up by SAS(?).

the other language that was used extensively in that period was APL
... including significant amount of performance and system modeling.
One such (APL) application from the science center eventually evolved into
the performance predictor available on the internal HONE system
providing worldwide support to field, sales, and marketing people
http://www.garlic.com/~lynn/subtopic.html#hone

customer profile information could be input (workload, configuration,
performance, etc) and "what-if" questions could be asked regarding
what happens if there were changes in workload and/or configuration.

in the 70s and 80s there was quite a bit of use of APL for modeling
and "what-if" scenarios ... a lot of which subsequently migrated to
various spreadsheet technologies.

Storage Philosophy Question

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Storage Philosophy Question
Newsgroups: bit.listserv.ibm-main
Date: Sun, 29 Oct 2006 09:47:50 -0700

rfochtman@ibm-main.lst (Rick Fochtman) writes:

He may also have been thinking about the "Great Chicago Flood" of a
few years ago, when several prominent Chicago banks learned the folly
of computer rooms in basements and sub-basements.

previous post in thread:
http://www.garlic.com/~lynn/2006s.html#28  Storage Philosophy Question

i remember places like Chicago Board of Trade also being affected

wasn't it construction or some other event that resulted in a break
in subsurface dam/barrier that was designed to keep the lake out?

note that even if the computer rooms aren't there ... lots of the
related utilities, power backup, etc ... frequently are.

this is akin to the multitude of backhoe vulnerabilities; possibly
one of the most famous was the isolating the new england internet
several years ago. supposedly the original infrastructure had
carefully laid out diverse routing for nine different circuits running
over nine different physical trunks. over the years, while nobody was
paying attention, all the circuits were eventually consolidated into
one physical trunk ... which one day was attacked by a backhoe and
taken out.

Why these original FORTRAN quirks?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why these original FORTRAN quirks?
Newsgroups: alt.folklore.computers,comp.lang.fortran
Date: Sun, 29 Oct 2006 10:37:39 -0700

jmfbahciv writes:

CAreful.  The linkers and loaders aren't separate.  What is even
worse is that the kiddies who think they know how machines work,
are not aware of the reasons for linkers and loaders; they assume,
rightly from their experience, that it is all one procedural step.
This is a loss of knowledge that is happening right now.

one of the other things left over from the os/360 real memory days is
figuring out where the program image was to be loaded ... and then
having to swizzle all the "relocatable" address constants that were
frequently randomly distributed thru-out the program image.

os/360 compilers and assemblers generated 80byte cards with 12-2-9
(0x02 hex) in column followed by ESD, TXT, RLD, etc.

ESD cards gave the "external" symbol information ... the names of entry
points into the program and names of external applications.
http://www.garlic.com/~lynn/2001.html#8 finding object decks with multiple entry points
http://www.garlic.com/~lynn/2001.html#14 IBM Model Numbers (was: First video terminal?)

TXT cards contained up to 56 bytes of actual program instructions and
data
http://www.garlic.com/~lynn/2001.html#60 Text (was: Review of Steve McConnell's AFTER THE GOLD RUSH)

RLD cards contained the location (displacement in the program) of
"relocatable" address constants.
http://www.garlic.com/~lynn/2002o.html#26 Relocation, was Re: Early computer games

once the linker/loader had decided on the address for loading the
program image ... it then had to run thru all the RLD information,
finding the associated "relocatable" address constants and swizzling
their values to correspond to actual memory address. that is in
addition to "resolving" addresses (swizzling them also) of external
program entry points.

recent posting discussing issues with os/360 convention of relocatable
address constants
http://www.garlic.com/~lynn/2006j.html#38 The Pankian Metaphor
http://www.garlic.com/~lynn/2006m.html#30 Old Hashing Routine
http://www.garlic.com/~lynn/2006s.html#61 Is the teaching of non-reentrant HLASM coding practices ever defensible?

lots of posts about difficulty of translating os/360 (real memory)
relocatable address constant convention into page mapped filesystem
environment attempting to invoke program images that were r/o shared
across multiple address spaces (and not being able to modify/alter
the program image)
http://www.garlic.com/~lynn/submain.html#adcon

misc. others posts discussing format of 12-2-9 cards
http://www.garlic.com/~lynn/93.html#17 unit record & other controllers
http://www.garlic.com/~lynn/95.html#4 1401 overlap instructions
http://www.garlic.com/~lynn/2001m.html#45 Commenting style (was: Call for folklore)
http://www.garlic.com/~lynn/2002f.html#41 Blade architectures
http://www.garlic.com/~lynn/2002h.html#1 DISK PL/I Program
http://www.garlic.com/~lynn/2002n.html#62 PLX
http://www.garlic.com/~lynn/2002n.html#71 bps loader, was PLX
http://www.garlic.com/~lynn/2002o.html#25 Early computer games
http://www.garlic.com/~lynn/2004h.html#17 Google loves "e"
http://www.garlic.com/~lynn/2004p.html#24 Systems software versus applications software definitions
http://www.garlic.com/~lynn/2005c.html#54 12-2-9 REP & 47F0
http://www.garlic.com/~lynn/2005f.html#16 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005t.html#47 What is written on the keys of an ICL Hand Card Punch?
http://www.garlic.com/~lynn/2006b.html#1 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006c.html#17 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006g.html#43 Binder REP Cards (Was: What's the linkage editor really wants?)
http://www.garlic.com/~lynn/2006g.html#58 REP cards
http://www.garlic.com/~lynn/2006n.html#1 The System/360 Model 20 Wasn't As Bad As All That
http://www.garlic.com/~lynn/2006n.html#11 Not Your Dad's Mainframe: Little Iron

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Future of CPUs: What's After Multi-Core?
Newsgroups: alt.folklore.computers
Date: Sun, 29 Oct 2006 12:50:32 -0700

jsavard writes:

IBM might well remember why the IBM PC was so successful in the first
place. Yes, the "IBM name" was a factor, but the product had its own
intrinsic merits. It was competing against Z-80 based computers; *they*
could be expanded to 64 K (or even 128 K with certain kludges) while
the IBM PC could be expanded to 640 K.

original ref:
http://www.garlic.com/~lynn/2006t.html#27 The Future of CPUs: What's After Multi-Core?

my frequent theme has been that one of big PC market penetrations was
into commercial ... where a PC was about the same price as a 3270 ...
could provide both 1) 3270 terminal emulation and 2) some local
desktop computing in a single screen/keyboard footprint.
http://www.garlic.com/~lynn/subnetwork.html#emulation

once that enormous market penetration had been obtained ... it was
difficult for anything else to compete (something of a snowball
effect, large install base attracted a lot of application programmers,
a lot of applications attracted bigger market). clones and
plug-compatible was one of the few remaining approaches.

and for other drift related to cluster scaleup
http://www.garlic.com/~lynn/95.html#13

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

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Future of CPUs: What's After Multi-Core?
Newsgroups: alt.folklore.computers
Date: Mon, 30 Oct 2006 12:56:05 -0700

jsavard writes:

But while experience at Cray might prove to have *some* value for IBM
engineers working on the next generation of micros, IBM has plenty of
experience, with machines like Blue Gene, with massively parallel
arrays of machines to draw on as well.

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

and for other drift than the previous mention related to working on
cluster scaleup while we were doing ibm's HA/CMP product
http://www.garlic.com/~lynn/subtopic.html#hacmp

sort of part of the earlier HSDT project
http://www.garlic.com/~lynn/subnetwork.html#hsdt

... a recent HSDT post or two
http://www.garlic.com/~lynn/2006t.html#6 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006t.html#11 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006t.html#12 Ranking of non-IBM mainframe builders?

... the original ibm mainframe tcp/ip product had been implemented in
vs/pascal ... however because of various issues ... it would consume
nearly a whole 3090 processor getting 44kbytes/sec sustained thruput.

i did a rfc 1044 driver implementation (that was eventually shipped in
the product) ... which in some tuning at cray research got 1mbyte/sec
sustained between a cray and 4341-clone ... using only a modest amount
of the 4341-clone.
http://www.garlic.com/~lynn/subnetwork.html#1044

trivia item was we were to leave on flight from sfo to Minneapolis for
dong some testing ... and was 20 mins or so late getting off the
ground.  part way thru the flight, i noticed a lot of whispering back
in the galley and wandered back to see what it was all
about. apparently something like five minutes after leaving the ground
the earthquake had hit.

before the previously mentioned incident that drastically
changed their direction
http://www.garlic.com/~lynn/95.html#13

kingston had been providing some assistance to chen ... as well as
working on their own machine of somewhat similar design. for other
recent drift along this line.
http://www.garlic.com/~lynn/2006q.html#9 Is no one reading the article?

threads versus task

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: threads versus task
Newsgroups: comp.