List of Archived Posts

2006 Newsgroup Postings (12/24 - 12/31)

Why so little parallelism?

"The Elements of Programming Style"

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

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

Why so little parallelism?

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

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

Securing financial transactions a high priority for 2007

Securing financial transactions a high priority for 2007

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

Why so little parallelism?

Multiple mappings

"The Elements of Programming Style"

Your data private? Access all areas is on the cards

Why so little parallelism?

"The Elements of Programming Style"

"The Elements of Programming Style"

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

The History of Computer Role-Playing Games

The History of Computer Role-Playing Games

moving on

moving on

"The Elements of Programming Style"

moving on

"The Elements of Programming Style"

"The Elements of Programming Style"

moving on

"The Elements of Programming Style"

"The Elements of Programming Style"

"The Elements of Programming Style"

"The Elements of Programming Style"

"The Elements of Programming Style"

"The Elements of Programming Style"

"The Elements of Programming Style"

"The Elements of Programming Style"

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

Multiple mappings

"The Elements of Programming Style"

Wanted: info on old Unisys boxen

Multiple mappings

Multiple mappings

Wanted: info on old Unisys boxen

"The Elements of Programming Style"

Remote Tape drives

Why so little parallelism?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why so little parallelism?
Newsgroups: comp.arch
Date: Sun, 24 Dec 2006 08:56:39 -0700

Terje Mathisen <terje.mathisen@hda.hydro.com> writes:

Using a block mode terminal, like a web html form or an IBM 3270 would
have solved the same problem much more cleanly, but neither of them
were possible options at the time.

... ascii 3101 glass tty ... had block-mode ... intenally there was
enhancement to PVM (started out emulating remote 3270s over the
internal network ... sort of tn3270) ... for home terminal program
... starting late '79.  The option then was to either come into the
host as straight glass tty or as emulated 3270 (with the 3101 switched
to block-mode) ... where PVM 3101 support played all sorts of tricks
on optimizing what was already on the screen and just what had to be
sent.

a couple years later this support was upgraded for ibm/pcs in the
"home terminal" program ... with an application "pcterm" running in
the PC. now the support got a lot more complicated ... pcterm kept
large buffer of what had been on the screen. PVM kept state of the
pcterm buffers ... transmission was huffman encoded ... but
compression could also be pointers into stuff that was already in the
buffer.

for some network topic drift
http://www.garlic.com/~lynn/2006x.html#33 NSFNET (long post warning)

and from long ago and far away ... "TOPAZ" was code name for 3101


From: wheeler
Date: 10/11/79  13:32:01

one other thing about the TOPAZ is the lack of APL support. The hard
copy ASCII terminals we have support APL and we have the VM
mods. also.  Somebody from White Plains has been testing APL based
products with ASCII terminals. Amoung other things they wanted to
verify that some of the products would work with non-APL ASCII
terminals (like TOPAZ). They had been trying to dial up to CAMBRIDG
but were running into all sorts of problems. Some how they got around
to calling me.  They were not able to get local CAMBRIDG support in
working out the difficulties of dialing into the system and 1st asked
me to help. I tried a couple times, once for 45 minutes straight to
get into your system on the userid and password supplied. Sometimes I
was succesful but CAMBRIDG is one big pain in the ... to use,
especially from off site. I finally gave them a log on ID on our
system so they could test ASCII tubes both with and w/o TERM APL on
(and the problems went away).

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


From: wheeler
Date: 10/11/79  14:04:47

I have made mods. to DMSCIT to chain together multiple CCWs in one SIO
(everything in the CONTASK queue). This suffers from a problem in VCN
with the '3215' simulation code. On a real 3215 the request key will
not break a chain of CCWs but instead just queue an attention to be
presented when the chain is finished. XXXXX in YKT is working on
extending the DIAG 58 support for use by non-3270 'formatting' CCWs
(01, 02, & 0A). For DIAG 58, a request will break a CCW chain with
unit check. In addition for 3270s if the terminal is currently busy
all pending requests will be processed and then written using one real
SIO (similar to the remote 3270 modification). I think he is also
looking at what might be required to provide full screen type support
for TOPAZ (new 3101 ASCII terminal).

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


To: wheeler
Date: 03/01/80  13:45:57

re: s3101, blank compression;
--
normal TTY translate table now correctly translates all control characters
       for cursor control
--
our local TTY, extended translate table mistranslates (or doesn't at all)
       approx. 10-12 column select characters.
--
bit pairing TTY APL translate table mistranlates the function select code
       so no cursor positioning occurs at all
--
type pairing TTY APL translate table does like wise.
--
extended translate table may just be another case of a lot of
don't care characters. we probably should cross check the current
production TTY table against our extended table. It appears there
have been several changes to the PID table.
--
the TTY apl problem may be completely different and require a different
program altogether. Putting code down into CP simplifies problem
greatly since correct ASCII control characters can be added after
translation instead of playing all the games with figuring out
the inverse of the ASCII control characters so that they come out
correct after being translated. That would eliminate the problem
with the APL and local extended table. CP would still need
the ability by the user to define the function select code for
cursor positioning since it is different on different types of
glass teletypes.

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

and other past posts mentioning 3101, tty apl, dmscit, etc
http://www.garlic.com/~lynn/99.html#69 System/1 ?
http://www.garlic.com/~lynn/2000f.html#6 History of ASCII (was Re: Why Not! Why not???)
http://www.garlic.com/~lynn/2000g.html#17 IBM's mess (was: Re: What the hell is an MSX?)
http://www.garlic.com/~lynn/2001b.html#12 Now early Arpanet security
http://www.garlic.com/~lynn/2001b.html#13 Now early Arpanet security
http://www.garlic.com/~lynn/2001h.html#32 Wanted: pictures of green-screen text
http://www.garlic.com/~lynn/2001k.html#38 3270 protocol
http://www.garlic.com/~lynn/2001m.html#1 ASR33/35 Controls
http://www.garlic.com/~lynn/2001m.html#54 Author seeks help - net in 1981
http://www.garlic.com/~lynn/2002j.html#5 HONE, xxx#, misc
http://www.garlic.com/~lynn/2003c.html#34 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003c.html#35 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003n.html#7 3270 terminal keyboard??
http://www.garlic.com/~lynn/2004e.html#8 were dumb terminals actually so dumb???
http://www.garlic.com/~lynn/2005p.html#28 Canon Cat for Sale
http://www.garlic.com/~lynn/2005r.html#12 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2006b.html#23 Seeking Info on XDS Sigma 7 APL
http://www.garlic.com/~lynn/2006n.html#56 AT&T Labs vs. Google Labs - R&D History
http://www.garlic.com/~lynn/2006q.html#11 what's the difference between LF(Line Fee) and NL (New line) ?

"The Elements of Programming Style"

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "The Elements of Programming Style"
Newsgroups: alt.folklore.computers
Date: Sun, 24 Dec 2006 09:50:27 -0700

Greg Menke <gregm-xyzpdq3@toadmail.com> writes:

I tried his 50% penalty rule on one project- sure enough, thats what he
did.  He was also kind enough to show the grade I would have had if the
goto wasn't there.  Come to think of it, he was teaching us software
patterns but without all the bullshit that goes along with the term
nowadays.

The point being that goto is so often mis-used (at least in Cobol) that
its important to understand program structure first so that goto can be
used helpfully.

one of the issues that i found in doing problem failure
analysis/forensics was not so much with the "goto" itself ... it was
trying to reconstruct program flow and as analysis attempted to rewind
the program flow ... found that a significant number of gotos arrived
at the same point ... and attempting to reconstruct how program flow
managed to arrive at that point becoming extremely difficult.

misc. posts mentioning dumprx ... problem analysis/forensics application
that i wrote:
http://www.garlic.com/~lynn/submain.html#dumprx

past postings in this thread:
http://www.garlic.com/~lynn/2006x.html#20 "The Elements of Programming Style"
http://www.garlic.com/~lynn/2006x.html#21 "The Elements of Programming Style"
http://www.garlic.com/~lynn/2006x.html#29 "The Elements of Programming Style"
http://www.garlic.com/~lynn/2006x.html#30 "The Elements of Programming Style"
http://www.garlic.com/~lynn/2006x.html#35 "The Elements of Programming Style"

spaghetti use of gotos result in large number of mistakes ... in part
because of difficult to understand program flow. going to simple
binary logic can significantly simplify difficulty in understanding
programming operations. however, in analysing some well-written and
highly optimized kernel routines that had clear goto use
... conversion to simple binary logic operations (if/then/else)
resulted in less clear logic (especially when gotos were part of clear
3-value and/or 4-value logic operations).

programmers having to manage register contents has contributed to
large number of programming mistakes ... and given rise to advocacy
for "higher" level programming languages that eliminate the programmer
burden managing register contents. similarly, programmers having to
manage string/buffer lengths has contributed to a large number of
programming mistakes ... and it would be advantages to have a
progamming paradigm that eliminated programmer forced to always manage
length fields.

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, 24 Dec 2006 12:18:25 -0700

jmfbahciv writes:

Oh, wonderful.  Fleeing from the hurricane right into the
blizzard, both with the side effect of the power grid being
interrupted.

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

denver is in a "rain shadow" (i.e. dominate storm pattern is west to
east ... cloads tend to dump precipitation on moutains and the areas
on the eastern/back side of mountain ranges can be semi-arid; back
side of the cascades and the sierras as well as back side of the
rockies) ...  significantly mitigating weather patterns. "rain shadow"
extends past denver and then tends to resume dumping precipitation in
eastern colorado

weather channel showed the latest colorado storm somewhat unusual with
counter clockwise pattern bringing moisture up from the gulf ... it
rubs against nw to se cold front/flow (coming from canada) over
wyoming and then continues around south along the backside of the
rockies thru colorado (and past denver).

the mid-west power grid seems to be quite resilient to interruptions
... you get blizzard problems in older rural areas taking out
residential overhead power lines ... but metropolitan areas and other
areas with lots of underground utilities ... tend to be much less
affected by blizzards.

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, 24 Dec 2006 12:50:29 -0700

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

the mid-west power grid seems to be quite resilient to interruptions
... you get blizzard problems in older rural areas taking out
residential overhead power lines ... but metropolitan areas and
other areas with lots of underground utilities ... tend to be much
less affected by blizzards.

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

for some real topic drift ... when STL (renamed silicon valley lab)
started bursting at the seams circa 1980 ... we undertook to relocate
something like 300 people from the IMS group to offsite location.  the
group looked at being supported with "remote 3270s" ... but were
appalled at the response time (compared to what they were use to with
locally connected 3270s). so we put into HYPERChannel channel
extension configuration with "local", channel attached 3270s at the
remote location with HYPERChannel remote channel adapters A510s and T1
microwave connection. I've posted before how this change actually
improved some of the system response characteristics.

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

now, there was a large (couple hundred) IMS field support group in
Boulder ... which were being moved to a building across a roadway
... and "remote 3270s" had also been suggested to them. Seeing the
success of the STL move ... they wanted a similar deployment ...
however, instead of T1 microwave between the two buildings ... they
put in T1 infrared modem between the rooftops of the two bldgs.

There was some concern that the infrared modems might have severe rain
fade with heavy precipitation (and Boulder tends to have heavier
precipitation than Denver). However, in one extreme "white-out"
blizzard condition ... when nobody was able to make it into work, the
infrared modems only showed a very modest increase in the
bit-error-rate (BER).

old infrared T1 modem references
http://www.garlic.com/~lynn/94.html#23 CP spooling & programming technology
http://www.garlic.com/~lynn/99.html#137 Mainframe emulation
http://www.garlic.com/~lynn/2000c.html#65 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2001e.html#72 Stoopidest Hardware Repair Call?
http://www.garlic.com/~lynn/2001e.html#76 Stoopidest Hardware Repair Call?
http://www.garlic.com/~lynn/2003b.html#29 360/370 disk drives
http://www.garlic.com/~lynn/2004c.html#31 Moribund TSO/E
http://www.garlic.com/~lynn/2005e.html#21 He Who Thought He Knew Something About DASD
http://www.garlic.com/~lynn/2005u.html#22 Channel Distances

Why so little parallelism?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why so little parallelism?
Newsgroups: alt.folklore.computers
Date: Mon, 25 Dec 2006 10:23:06 -0700

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

... ascii 3101 glass tty ... had block-mode ... intenally there was
enhancement to PVM (started out emulating remote 3270s over the
internal network ... sort of tn3270) ... for home terminal program
... starting late '79.  The option then was to either come into the
host as straight glass tty or as emulated 3270 (with the 3101 switched
to block-mode) ... where PVM 3101 support played all sorts of tricks
on optimizing what was already on the screen and just what had to be
sent.

re:
http://www.garlic.com/~lynn/2006y.html#0 Why so little parallelism?

a little more archeological cross-over from thread in comp.arch

for other historical reference, when i was undergraduate in the 60s,
i had added the original tty/ascii terminal support to cp67 ... misc.
related postings about that somewhat leading to univ. project to
build our own mainframe clone controller
http://www.garlic.com/~lynn/subtopic.html#360pcm

other old email ... besides what was included in comp.arch posting

3101 had 6800 and we were looking to try and field upgrade mod1s
3101 motherboards to mod2s ... starting by copying mod2 EEPROMS
and installing them in mod1 motherboards.


To: fujisawa
From: wheeler
Date: 03/11/80  16:04:39

re: 3101 mod. 2 boards.
--
I am looking  for help in obtain mod. 2  version of 3101. Our location
currently has several  3101 mod. 1 on  order for delivery in  the next
couple of weeks (with mod. 2 and printers on order for delivery for as
soon as they are available). We currently have two mod. 2 3101 on loan
from  GSD for  testing  purposes.  We  are currently  developing  (and
testing) enhancements to  both MVS and VM to support the device. Would
it be possible  to obtain any  mod. 2 boards  from you to  upgrade our
3101s????

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


From: wheeler
Date: 03/12/80  08:27:17

we've been working with Series/1 GSD people in this building on 3270
simulator.  Also have mod.  2s on loan from same group for VM
modifications. XXXXX here is currently testing MVS full screen support
that he did. We currently are also working on VM support. Also in
touch with engineers in Kingston about burning new PROM for 3101 which
makes it look much more like 3270.  Talked to several customers about
control units to make ASCII tubes look like 3270s. There appear to be
at least 3 OEM boxes, one of them in Canada and another here in the
Bay area for same function.

Most customers appear to be aware of the Series/1 effort.  Their
comment has been something to the effect that Series/1 is something
like an order of magnitude more expensive than competive control units
for 3270 simulation (partially because series/1 is general purpose
computer) and the box appears to be selling very well inside IBM
(implying that it isn't anywhere else).

-- We have currently been running a large number of ASCII devices for
as long as I've been here. We have two separate ASCII translate tables
(one of which also includes the option of 'deleting' the prompt
character for input).  We also have full APL/ASCII support with
translate tables for both bit and type pairing. In CMS we have the
support for blank compression for all terminal output to ascii tubes
and a full screen edit simulator (for RED editor) for 'dumb' ascii
tubes (like adm3 or character mode 3101).

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


From: wheeler
Date: 03/14/80  14:51:16

my 3101 mod.  1 arrived today. Also I sent message to Japan on Monday
asking for mod.  2 boards. Response came back today, they are mailing
two model 2 boards.  Hopefully will have them shortly. Data jack on my
telephone being installed right now. 1200 baud Vadic modem hung up in
paper work in SJRL, hopefully clears next week an able to get
immediate delivery.

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

for other drift, a few postings about RED editor
http://www.garlic.com/~lynn/2006n.html#55 The very first text editor
http://www.garlic.com/~lynn/2006u.html#26 Assembler question
http://www.garlic.com/~lynn/2006u.html#61 Why these original FORTRAN quirks?

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, 25 Dec 2006 10:41:33 -0700

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

mentioned customers snarfing up 4331s and 4341s in orders of multi-hundred
at a time. the above post also references an older post/email
http://www.garlic.com/~lynn/2001m.html#15 departmental servers

where the air force data systems (that was a multics installation)
ordering 210 in the late 70s.

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

Another old email regarding a smaller 4341 order from a large
california bank.


To: wheeler
Date: 03/11/80  20:36:01

Lynn: <large cal. bank> needs your help. They are going to get 60 4341
and spread them around the world. All will run CP and guest operating
sytems on top

They are getting xxxxxxx to help them with a multi-domain architecture.
They need help in the areas of:
      Maintenance of a large net of machines from a single central site
      Multidomain support.

Perhaps this will force you to write the code.

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

recent postings mentioning increasing distributed 43xx deployments
http://www.garlic.com/~lynn/2006p.html#34 "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#40 "25th Anniversary of the Personal Computer"
http://www.garlic.com/~lynn/2006s.html#41 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006v.html#11 What's a mainframe?
http://www.garlic.com/~lynn/2006v.html#19 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006v.html#25 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006x.html#18 The Future of CPUs: What's After Multi-Core?

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, 25 Dec 2006 14:24:29 -0700

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

you have customers in the 79-81 time-frame talking about putting in
small to medium sized distributed 43xx computing (scores to several
hundred ... there was one single order for nearly thousand 4341s)

you have 1980 arpanet newsletter talking about how rapidly arpanet is
growing and that possibly by (sometime in) 1983, there might be as
many as 100 nodes on arpanet.
http://www.garlic.com/~lynn/2006r.html#7 Was FORTRAN buggy?

by comparison, in 1979 air force data systems was talking about a distributed
210 4341 environment.
http://www.garlic.com/~lynn/2001m.html#15 departmental servers

here, references to the internal network already being 300
machines in 1979
http://www.garlic.com/~lynn/2006p.html#31 "25th Anniversary of the Personal Computer"
http://www.garlic.com/~lynn/2006r.html#7 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006t.html#36 The Future of CPUs: What's After Multi-Core?

and a reference here about the internal network doing distributed
development between cambridge and endicott in 1970.
http://www.garlic.com/~lynn/2006k.html#9 Arpa address
http://www.garlic.com/~lynn/2006x.html#19 The Future of CPUs: What's After Multi-Core?

However, while they were hoping that arpanet would reach 100 nodes in
1983, the internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet

hit 1000 nodes
http://www.garlic.com/~lynn/2006k.html#43 Arpa address

of course, arpanet significantly changed with the switch-over to
interntworking protocol on 1jan83 ... following post includes quite a
few references to old posts mentioning 1jan83 switch-over:
http://www.garlic.com/~lynn/2006x.html#33 NSFNET (long post warning)

Securing financial transactions a high priority for 2007

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Mon, 25 Dec 2006 15:12:54 -0700

Securing financial transactions a high priority for 2007
http://www.secureidnews.com/news/2006/12/22/securing-financial-transactions-a-high-priority-for-2007/

Are we talking about the X9.59 financial standard?

In the mid-90s, the X9A10 financial standard working group was given
the requirement to preserve the integrity of the financial
infrastructure for all retail payments.  The result was the X9.59
financial standard.
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

or are we talking the infrastructure that has had the yes card
vulnerabilities (which started out about the same time as the X9A10
working group)
http://www.garlic.com/~lynn/subintegrity.html#yescard

We had started work in the financial standard X9A10 working group
after having worked on client/server payment infrastructure
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

that has since come to be referred to as electronic commerce.

Some recent posts about various vulnerabilities in that infrastructure
(and which various parts of the x9.59 standards work from the mid-90s
was intended to address):
http://www.garlic.com/~lynn/2006c.html#36 Secure web page?
http://www.garlic.com/~lynn/2006h.html#34 The Pankian Metaphor
http://www.garlic.com/~lynn/2006k.html#2 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006k.html#17 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://www.garlic.com/~lynn/2006p.html#7 SSL, Apache 2 and RSA key sizes
http://www.garlic.com/~lynn/2006s.html#11 Why not 2048 or 4096 bit RSA key issuance?
http://www.garlic.com/~lynn/2006v.html#49 Patent buster for a method that increases password security
http://www.garlic.com/~lynn/2006w.html#42 vmshare
http://www.garlic.com/~lynn/aadsm24.htm#48 more on FBI plans new Net-tapping push
http://www.garlic.com/~lynn/aadsm26.htm#1 Extended Validation - setting the minimum liability, the CA trap, the market in browser governance

and somewhat related work from the same period, aads chip strawman
... extremely high integrity with extremely aggressive chip &
infrastructure cost reduction
http://www.garlic.com/~lynn/x959.html#aads

for some trivia drift ... public key (little "i") infrastructure
from 1981:
http://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network
http://www.garlic.com/~lynn/2006w.html#15 more secure communication over the network
http://www.garlic.com/~lynn/2006w.html#18 more secure communication over the network

using CJNTEL infrastructure from the late 70s ... i.e.  some
characteristics of LDAP infrastructure along with pgp key server
infrastructure ... other posts mentioning CJNTEL
http://www.garlic.com/~lynn/2006w.html#16 intersection between autolog command and CMSBACK (more history)
http://www.garlic.com/~lynn/2006w.html#25 To RISC or not to RISC
http://www.garlic.com/~lynn/2006w.html#44 more secure communication over the network

Securing financial transactions a high priority for 2007

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Mon, 25 Dec 2006 16:10:58 -0700

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

Securing financial transactions a high priority for 2007
http://www.secureidnews.com/news/2006/12/22/securing-financial-transactions-a-high-priority-for-2007/

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

then there is somewhat (internet merchant) related news

Web 'Safe' Mark May Elude New Merchants
http://www.redorbit.com/news/technology/779351/web_safe_mark_may_elude_new_merchants/index.html
Web 'safe' mark may elude new merchants
http://news.yahoo.com/s/ap/20061225/ap_on_hi_te/internet_padlocks
'Safe' Web seal requires rigorous checks
http://news.yahoo.com/s/ap/20061225/ap_on_hi_te/internet_padlocks_checks

And this old comment regarding (w/o X9.59) providing security
proporitional to risk:
http://www.garlic.com/~lynn/2001h.html#61

and/or the possible requirement for burying the planet under huge
amounts of encryption
http://www.garlic.com/~lynn/aadsm22.htm#2 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://www.garlic.com/~lynn/aadsm23.htm#28 JIBC April 2006 - "Security Revisionism"
http://www.garlic.com/~lynn/aadsm24.htm#38 Interesting bit of a quote
http://www.garlic.com/~lynn/aadsm24.htm#48 more on FBI plans new Net-tapping push
http://www.garlic.com/~lynn/aadsm25.htm#24 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm26.htm#8 What is the point of encrypting information that is publicly visible?
http://www.garlic.com/~lynn/ansiepay.htm#breach Security breach raises questions about Internet shopping
http://www.garlic.com/~lynn/2001k.html#53 Why is UNIX semi-immune to viral infection?
http://www.garlic.com/~lynn/2005k.html#26 More on garbage
http://www.garlic.com/~lynn/2005v.html#2 ABN Tape - Found
http://www.garlic.com/~lynn/2006e.html#44 Does the Data Protection Act of 2005 Make Sense
http://www.garlic.com/~lynn/2006h.html#15 Security
http://www.garlic.com/~lynn/2006k.html#5 Value of an old IBM PS/2 CL57 SX Laptop
http://www.garlic.com/~lynn/2006k.html#18 Value of an old IBM PS/2 CL57 SX Laptop
http://www.garlic.com/~lynn/2006t.html#40 Encryption and authentication
http://www.garlic.com/~lynn/2006u.html#43 New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006v.html#2 New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006v.html#49 Patent buster for a method that increases password security

attempting to deal with naked transaction vulnerabilities
(i.e. transactions w/o end-to-end armoring providing integrity and
authentication)
http://www.garlic.com/~lynn/aadsm24.htm#5 New ISO standard aims to ensure the security of financial transactions on the Internet
http://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#9 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#10 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#12 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#14 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#22 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#26 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#27 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#30 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#31 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#38 Interesting bit of a quote
http://www.garlic.com/~lynn/aadsm24.htm#41 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#42 Naked Payments II - uncovering alternates, merchants v. issuers, Brits bungle the risk, and just what are MBAs good for?
http://www.garlic.com/~lynn/aadsm24.htm#46 More Brittle Security -- Agriculture
http://www.garlic.com/~lynn/aadsm25.htm#20 Identity v. anonymity -- that is not the question
http://www.garlic.com/~lynn/aadsm25.htm#28 WESII - Programme - Economics of Securing the Information Infrastructure
http://www.garlic.com/~lynn/aadsm26.htm#13 Who has a Core Competency in Security?
http://www.garlic.com/~lynn/2006m.html#15 OpenSSL Hacks
http://www.garlic.com/~lynn/2006m.html#24 OT - J B Hunt
http://www.garlic.com/~lynn/2006o.html#35 the personal data theft pandemic continues
http://www.garlic.com/~lynn/2006o.html#37 the personal data theft pandemic continues
http://www.garlic.com/~lynn/2006o.html#40 the personal data theft pandemic continues
http://www.garlic.com/~lynn/2006t.html#40 Encryption and authentication
http://www.garlic.com/~lynn/2006u.html#43 New attacks on the financial PIN processing

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: Tue, 26 Dec 2006 00:42:54 -0700

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

lots of collected posts mentioning (global LRU)page replacement
http://www.garlic.com/~lynn/subtopic.html#wsclock

a little more global LRU history. "Swapper" referred to what I've
called "big pages". The issue in "big pages" was how to collect
multiple pages (originally a 3380 tracks worth, ten pages) from the
same address space for transfer in single operation. It was much
easier to do something like "local" LRU ... to get a whole track of
pages (from the same address space) for a single track
transfer. however, that severely degraded performance with the
management of the pages in real memory.

from long ago and far away ... there was a lot of performance
measurements showing much improved performance by putting global
LRU back in ....


From: wheeler
Date: 01/19/86  12:29:38

re: hpo; spent some time last tues. with people putting global LRU
page replacement algorithm back into VM/HPO (it was taken out by the
swapper/ykt/hpo3.4 group ... in order to implement swapper). they have
very good performance comparison with hpo3.4. They are almost done
with implmentation of correct global LRU replacement algorithm for
>16meg real memory support (the YKT code for hpo2.5 to support >16meg
real memory screwed up the global LRU replacement algorithm ...
although they thot the code was similar ... small changes in the way
some bits were tested ... resulted in algorithm other than global LRU
being implemented).

It looks like will have page replacement algorithm put back to the way
it was prior to HPO2.5 (i.e. >16meg support & swapper support)
and a >16meg support implemented with true global LRU page
replacement ...  performing much better than the swapper hpo3.4 stuff
& hpo 2.5 >16meg support done by the YKT people.

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

a couple recent posts about support >16mbyte real storage
http://www.garlic.com/~lynn/2006t.html#15 more than 16mbyte support for 370
http://www.garlic.com/~lynn/2006w.html#23 Multiple mappings

other posts discussing "big pages"
http://www.garlic.com/~lynn/2006j.html#2 virtual memory
http://www.garlic.com/~lynn/2006j.html#3 virtual memory
http://www.garlic.com/~lynn/2006j.html#4 virtual memory
http://www.garlic.com/~lynn/2006j.html#11 The Pankian Metaphor
http://www.garlic.com/~lynn/2006l.html#13 virtual memory
http://www.garlic.com/~lynn/2006r.html#35 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006r.html#37 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006r.html#39 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006t.html#18 Why magnetic drums was/are worse than disks ?

Why so little parallelism?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why so little parallelism?
Newsgroups: alt.folklore.computers
Date: Tue, 26 Dec 2006 01:57:27 -0700

re:
http://www.garlic.com/~lynn/2006y.html#4 Why so little parallelism?

and for some more topic drift, a couple posts on improving performance
of cms virtual terminal i/o
http://www.garlic.com/~lynn/2003c.html#35 diffence between itanium and alpha
http://www.garlic.com/~lynn/2006y.html#0 Why so little parallelism?

a couple posts discussing interactive queue response and cms terminal
i/o and cp terminal i/o (there was recent post in comp.arch describing
some of the complexity in linux attempting to address something
similar for X actions):
http://www.garlic.com/~lynn/2001f.html#57 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2003k.html#2 Rexx vs. Batch

TOOLSRUN sort of combined some of the features of usenet, mailing
lists, and distributed file management. In the the following, "VMPCD"
was internal conferencing and files related to vm performance ... and
I had made my "VMPERF SCRIPT" document available.

related email (to the following) from 1983
http://www.garlic.com/~lynn/2001f.html#email830420


From: wheeler
Date: 01/21/86  15:21:39

re: TIO loop; Code was originally implemented in CP/67 ... but
apparently was modified somewhere in VM/370 ... but should have
essentually been there in base VM/370 prior to any APAR activity.

Standard terminal logic in VM is to start an I/O to the console and
then go into wait state. If the only I/O active is for the console,
DMKDSP would determine that the virtual machine is in LONGWAIT and set
the corresponding flag, DMKSCH would then see the flag and drop the
virtual machine from queue.

A virtual machine executing a TIO loop waiting for terminal I/O to end
will effectively "wait" as long a virtual machine actually doing a
LPSW with a waitstate PSW. Code was put in place to attempt to make
the TIO loop case functionally equivalent to the wait-state PSW case
(from a scheduler queue activity point of view).

Originally on CP/67 I implemented a high-speed device busy counter
that was based on the real device type ... not the virtual device
type. In the conversion to VM/370, that code was replaced with a much
longer pathlength in DMKDSP & DMKVIO that maintains summary
information in various blocks based on virtual device type (i.e.
virtual 3215). In VM/370, everthing was fine as long as the virtual
device type and the real device type were the same or similar.

When 327xs came along, the real device type was no longer a "LONGWAIT"
device even though the virtual device type (3215) was. VM/370 now
began to drop virtual machines when doing real "high-speed" I/O to
virtual "low-speed" devices. HPO3.4 attempted to partially compensate
for this "bug" with queue drop delay. My code for VMDVBSY counter (see
discussion in appendix of VMPERF SCRIPT on VMPCD) attempted to
recreate the CP/67 implementation. However, several shortcuts were
done with the VMDVBSY implementation in attempt to minimize the code
hits ... and much of the VM/370 code remained in place (design bugs
and the excessive pathlengths).

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

Multiple mappings

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Multiple mappings
Newsgroups: comp.arch
Date: Tue, 26 Dec 2006 02:32:16 -0700

"mike" <mike@mike.net> writes:

One great thing about the single level store is that code is never
ever relocated in the virtual address space.  This simplifies many
issues for both kernel and user code.

re:
http://www.garlic.com/~lynn/2006x.html#26 Multiple mappings

for a lot more (old) topic drift ... article predates os/400:

Start-Up Firm To Test MVS Replacement
From November 25, 1985 issue of Information Week
Byline:  Paul E. Schindler, Jr.

....

Key Logic's early users will get the chance to run one of the few
alternatives to the basic IBM mainframe operating system.  Although
Amdahl Corp. sells a mainframe Unix called UTS, and may someday release
a souped-up MVS-like operating system developed under the code-name
Aspen, UTS is not new to the market and Aspen is not a radical
departure.

KeyKOS is both.  It offers high performance, reliability, security,
and programmer productivity, the company says.

....

Programmers continue to deal with the same hardware they have used for
years.  In a three-week course, they can learn how to program
efficiently under KeyKOS using standard IBM programming languages.
Experience indicates that programmers writing applications for KeyKOS
produce 40% less code than do programmers for other operating systems,
including IBM's MVS and VM.

This kind of productivity is made possible by two new computing
principles upon which KeyKOS is based.  The first principle deals with
communications.  Programs, tasks, files, or even guest operating
systems are all known as objects that communicate via messages.
Objects cannot communicate with each other unless given the "keys"
(Key Logic calls them capabilities) to do so.  This ensures both
security and reliability.  A failure in one object cannot affect any
other object, ensuring continued operation.

The other principle deals with memory.  As with IBM's System/38, for
example, KeyKOS treats all main memory and disk storage as one virtual
memory.  Programmers do not have to deal with disk I/O routines or
file management -- KeyKOS does.

... snip ...

a few recent posts mentioning Aspen
http://www.garlic.com/~lynn/2006w.html#24 IBM sues maker of Intel-based Mainframe clones
http://www.garlic.com/~lynn/2006w.html#28 IBM sues maker of Intel-based Mainframe clones

GNOSIS was operating system for 370 originally developed from scratch
by Tymshare and spun-off as KeyKos when M/D bought Tymshare. I was
brought in to do evaluation of GNOSIS as part of that spin-off (I
still have the old documentation). Recent posts mentioning GNOSIS
and/or KeyKos
http://www.garlic.com/~lynn/2006k.html#37 PDP-1
http://www.garlic.com/~lynn/2006m.html#34 PDP-1
http://www.garlic.com/~lynn/2006s.html#7 Very slow booting and running and brain-dead OS's?
http://www.garlic.com/~lynn/2006w.html#42 vmshare

post mentioning coyotos/eros/capros as evolution of KeyKos
http://www.garlic.com/~lynn/2006p.html#13 What part of z/OS is the OS?

"The Elements of Programming Style"

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "The Elements of Programming Style"
Newsgroups: alt.folklore.computers
Date: Tue, 26 Dec 2006 07:38:33 -0700

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

the mainframe tcp/ip product had been implemented in vs/pascal ... i
had done the enhancements to support rfc 1044 ... which had
significantly higher thruput than the base system (1mbyte/sec
vis-a-vis 44kbytes/sec ... and something like 3-4 orders of magnitude
bytes per processor time efficiency)
http://www.garlic.com/~lynn/subtopic.html#1044

as far as i knew, the vs/pascal implementation never had any buffer
overflow exploits ... the ingrained paradigm was that all string and
buffer operations were always done with explicit lenghts.

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

the following group somewhat overlaps the stanford phd thesis that
was 9month study on how i communicated (fact-to-face, email, instant
messages, etc) ... recent post
http://www.garlic.com/~lynn/2006w.html#35 Top versus bottom posting was Re: IBM sues maker of Intel-based Mainframe clones

collected posts mentioning computer-mediated-conversation
http://www.garlic.com/~lynn/subnetwork.html#cmc

and from long ago and far away ...


To: distribution
Date: 27 Dec 83 22:47:34 PST

describe events, information, ..., of relevance to people involved
with the "Center for Studies on Language and Information".

     The Center for the Study of Language and Information (CSLI) was
founded in 1983 to bring together researchers from Stanford
University, SRI International, Xerox Palo Alto Research Center, and
other Palo Alto area research laboratories to collaborate in the study
situated language--language as used by agents situated in the world to
exchange, store, and process information.  Situated languages include
both natural languages like English and Chinese and computer languages
like PASCAL and LISP.

     The 17 senior members, or principals, of the Center are:

Jon Barwise, Director of CSLI, Stanford University
Joan Bresnan, Stanford University and Xerox PARC
Barbara J. Grosz, SRI International
Ronald Kaplan, Xerox PARC
Lauri Karttunen, SRI International
Martin Kay, Xerox PARC
John McCarthy, Stanford University
Robert C. Moore, SRI International
C. Raymond Perrault, SRI International
John Perry, Stanford University
Stanley Peters, Associate Director of CSLI, Stanford University
Stanley J. Rosenschein, SRI International
Ivan Sag, Stanford University
Patrick Suppes, Stanford University
Brian Cantwell Smith, Xerox PARC
Thomas Wasow, Stanford University
Terry Winograd, Stanford University
-------

The mailing list "CSLI-friends" includes everyone officially
connected with CSLI and anyone else who is interested in any way
in natural and/or computer languages.

For more information about CSLI, and/or to be added to this list, send
a specific request to csli-requests@sri-ai.  FYI: announcement on
Stanford BBOARD Dave Fuchs is a PhD student at Stanford who's one of
the key people on the TEX project.

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

Your data private? Access all areas is on the cards

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Your data private? Access all areas is on the cards
Newsgroups: alt.privacy
Date: Tue, 26 Dec 2006 08:17:17 -0700

Your data private? Access all areas is on the cards
http://www.smh.com.au/news/opinion/access-all-areas-is-on-the-cards/2006/12/26/1166895296883.html

from above:

Sounds great, but most people don't have 17 cards. They have just one:
their Medicare card. For most of us this means replacing our Medicare
card with a supercharged version chock-full of personal information.

A Medicare card has just a name and Medicare number. The new card has
a name, personal identification number, signature and biometric
photograph. It also has a digital chip that can carry medical
information, address, emergency contacts, concession status, even an
"electronic purse".

... snip ...

same reason that there was move to relying-party-only digital
certificates and away from x.509 identity certificates in the mid-90s
http://www.garlic.com/~lynn/subpubkey.html#rpo

however, it then is trivial to show that relying-party-only digital
certificates are redundant and superfluous

recent related posts:
http://www.garlic.com/~lynn/aadsm25.htm#46 Flaw exploited in RFID-enabled passports
http://www.garlic.com/~lynn/aadsm26.htm#0 Flaw in RFID-enabled passports (part 2?)

and for a little trivia drift ... a public key (little i) infrastructure
proposal from 1981
http://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network
http://www.garlic.com/~lynn/2006w.html#15 more secure communication over the network
http://www.garlic.com/~lynn/2006w.html#18 more secure communication over the network

for public key operation w/o digital certificates ... i.e.
http://www.garlic.com/~lynn/subpubkey.html#certless

Why so little parallelism?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why so little parallelism?
Newsgroups: comp.arch
Date: Tue, 26 Dec 2006 08:56:04 -0700

Terje Mathisen <terje.mathisen@hda.hydro.com> writes:

Almost 20 years ago, while we were developing the Oseberg North Sea
oil field, we had a couple of modules under construction in Holland
(Rotterdam/Den Haag), and the two possible alternatives for comms
links were leased SDLC or X.25.

recent posts in this thread:
http://www.garlic.com/~lynn/2006y.html#0 Why so little parallelism?
http://www.garlic.com/~lynn/2006y.html#4 Why so little parallelism?
http://www.garlic.com/~lynn/2006y.html#10 Why so little parallelism?

my wife had done brief stint as chief architect for amadeus. there was
decision about SNA or X.25 ... and my wife went w/X.25.  The SNA
forces then went into action ... which resulted in my wife being
replaced (trying to tip the balance back to SNA). It didn't do any
good since amadeus went with X.25 anyway.

a hard-copy amadeus design document has a date: 24apr87 (almost 20
years ago)

a couple recent posts about other similar run-ins
http://www.garlic.com/~lynn/2006w.html#21 SNA/VTAM for NSFNET
http://www.garlic.com/~lynn/2006x.html#8 vmshare

misc. past posts mentioning amadeus
http://www.garlic.com/~lynn/2001g.html#49 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001g.html#50 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001h.html#76 Other oddball IBM System 360's ?
http://www.garlic.com/~lynn/2003d.html#67 unix
http://www.garlic.com/~lynn/2003n.html#47 What makes a mainframe a mainframe?
http://www.garlic.com/~lynn/2004b.html#6 Mainframe not a good architecture for interactive workloads
http://www.garlic.com/~lynn/2004b.html#7 Mainframe not a good architecture for interactive workloads
http://www.garlic.com/~lynn/2004m.html#27 Shipwrecks
http://www.garlic.com/~lynn/2004o.html#23 Demo: Things in Hierarchies (w/o RM/SQL)
http://www.garlic.com/~lynn/2004o.html#29 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005f.html#22 System/360; Hardwired vs. Microcoded
http://www.garlic.com/~lynn/2005p.html#8 EBCDIC to 6-bit and back
http://www.garlic.com/~lynn/2006o.html#4 How Many 360/195s and 370/195s were shipped?
http://www.garlic.com/~lynn/2006r.html#9 Was FORTRAN buggy?

"The Elements of Programming Style"

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "The Elements of Programming Style"
Newsgroups: alt.folklore.computers
Date: Wed, 27 Dec 2006 07:25:56 -0700

jmfbahciv writes:

I still don't understand how this can happen when a compiler
language is used.

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

some compiler languages do and some compiler languages don't

(at least) two issues in C ... 1) there is wide-spread use of
data-pattern to determine end-of-string (i.e. length of string is part
of the pattern of the data) ... and 2) storage is allocated (static or
dynamic), but the language and the runtime libraries don't keep track
of the length of allocated storage (the programmer has to). Such
characteristics may contribute to periodic statements that C is just a
fancy assembler language (not a real compiler language).

in lots of c language programs ... the programmer frequently doesn't
bother to even do length validity operations ... apparently just
crossing their fingers and hoping that nothing bad happens. in other
cases, they may invoke length validity checking ... but it is up to
the programmer to remember what lengths to specify (which could be
very error prone in large, complex program)

some languages have environments where the semantics of lots of the
operations have length validity as part of the core operation ...  and
so a lot of problems that are common in c language implementations
just don't occur. this is the analogy that a log of compiler languages
have management of register contents as part of the core operations
and so it is much more difficult for a programmer to create a situation
where register contents are mismanaged.

lots of past posts about buffer overflow issues
http://www.garlic.com/~lynn/subintegrity.html#overflow

"The Elements of Programming Style"

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "The Elements of Programming Style"
Newsgroups: alt.folklore.computers
Date: Wed, 27 Dec 2006 07:53:14 -0700

Peter Flass <Peter_Flass@Yahoo.com> writes:

I disagree.  80% (90%?) of the code of anything can run fine without
special privileges.  If it runs this way it prevents a lot of damage
from bad code.  For the other 20%, a call gate or whatever that
carefully checks its arguments and performs well-defined functions
for the caller will work.  OS/2 uses rings, where the kernel is ring
0, the user is ring 3, and the device drivers are, I believe, ring
1: more privileged than the general user, but less than the kernel.
A lot of protection can also be accomplished with appropriate memory
mapping.

one of the problems for MVS moving to virtual storage from real memory
paradigm was the extensive use of pointer passing paradigm.

this effectively dictated that the MVS kernel (code) image appeared in
every application virtual address space. the harder problem was
getting the semi-privileged subsystems ... that were now in their own
individual virtual address space to interact with other applications.

the initial solution was the COMMON segment ... sort of parameter
passing storage that also appeared in every virtual address space.
application could stuff their parameters into available place in the
COMMON segment and then (thru a kernel call) pass a pointer to the
parameters to a semi-privileged subsystem.

the problem for early MVS ... limited to 16mbyte virtual address space
was the MVS kernel took 8mbytes of every virtual address space, the
basic COMMON segment took 1mbyte ... leaving only 7mbytes in each
virtual address space for application use. Large installations with
lots of semi-privileged subsystems could have a five mbyte COMMON
segment ... leaving only 3mbytes in a virtual address space for
application use.

old reference to such problems
http://www.garlic.com/~lynn/2006b.html#39 another blast from the past
http://www.garlic.com/~lynn/2006c.html#0 Multiple address spaces

to address the rapdily growing COMMON segment problem, "dual-address"
space was introduced with 3033 ... this allowed for two address space
pointers, a primary/home and potentially a secondary. in the kernel
call to a semi-privilege subsystem, the kernel would move the
application address space pointer to the secondary and switch to the
subsystem. the subsystem then could use the passed pointer to access
parameters directly in the call application address space.

this was later generalized with multiple virtual address space
pointers (more than two) and a kernel hardware table supporting
"program call" (and return) hardware instruction. the kernel hardware
table had the rules for specific subsystems in different virtual
address spaces.  an application would do a "program call" for a
specific subsystem, and the hardware would do all the address space
pointer swizzling ... w/o requiring a pass thru the kernel.

this was further enhanced so that the kernel hardware table could have
both hierarchical definitions and non-hierarchical definitions.
various kinds of things like library code could reside in different
address space ... and could be invoked with nearly as little overhead
as if it was in the same address space and being invoked with simple
branch&link.

the "program call" hardware table is almost taken on some of the
gnosis/keykos capability type characteristics (aka capabilities being
independent of any kind of hierarchical privilege structure) ... for a
little drift
http://www.garlic.com/~lynn/2006y.html#11 Multiple mappings

the above post touches a little on subject of programming difficulty.

some recent postings mentioning program call
http://www.garlic.com/~lynn/2006b.html#25 Multiple address spaces
http://www.garlic.com/~lynn/2006i.html#33 virtual memory
http://www.garlic.com/~lynn/2006r.html#8 should program call stack grow upward or downwards?
http://www.garlic.com/~lynn/2006s.html#8 Google launches search engine for finding source code
http://www.garlic.com/~lynn/2006t.html#20 Why these original FORTRAN quirks?; Now : Programming practices
http://www.garlic.com/~lynn/2006x.html#23 Multiple mappings

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: Wed, 27 Dec 2006 13:54:12 -0700

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

some more email archeology around system performance operation. Much
of the high performance and dynamic adaptive work that I had done on
CP67 as an undergraduate in the 60s had been dropped in the morph from
CP67 to VM370. I helped put a little of the pathlength optimization
back into VM370 R1PLC9 (9th monthly update to vm370 release 1).

The initial VM370 morph also had something that still perported to be
global LRU page replacement ... but because of numerous coding
vagaries, it actually turned out to work slightly more like local LRU
than global LRU.

When I was allowed to put out the resource manager ... I was able to
put a lot of the instrumentation back in to support dynamic adaptive
operation ... as well as correct a number of coding and structural
problems ... as well as real global LRU replacement. recent post
discussing some of the details (including reference to the tuning
paramemter "joke" in the resource manager).
http://www.garlic.com/~lynn/2006x.html#10 The Future of CPUs: What's After Multi-Core?

collected posts about resource management
http://www.garlic.com/~lynn/subtopic.html#fairshare
and paging management
http://www.garlic.com/~lynn/subtopic.html#wsclock

At the next major release, majority of the resource manager code was
merged into the base "free" kernel ... since a lot of the structural
coding changes had been done for multiprocessor support.
misc. collected posts about multiprocessor support
http://www.garlic.com/~lynn/subtopic.html#smp
as well as a (canceled) 5-way multiprocessor effort (shortly before
the resource manager)
http://www.garlic.com/~lynn/submain.html#bounce

The remaining pieces of the resource manager was combined with a
growing body of charged for kernel code ... misc. past posts talking
about transition from free software to charged for software (with
responsibility for the code picked up by the development group)
http://www.garlic.com/~lynn/submain.html#unbundle

Over a period of nearly a decade, various expediencies and other
factors resulted in atrophy of the instrumentation that was foundation
for dynamic adaptive resource management ... and the re-appearance of
numerous hard-coded tuning solutions (you don't just do straight-line
dynamic adaptive implementation ... but you also require the
instrumentation that the dynamic adaptive implementation is dependent
on).

some related posts
http://www.garlic.com/~lynn/2003c.html#35 difference between itanium and alpha
http://www.garlic.com/~lynn/2006y.html#10 Why so little parallelism?


From: wheeler
Date: 10/15/85  14:42:52

re: working set; Working set is a predictive algorithm that attempts
to prevent page thrashing ... rather than a "fix-up" after disaster
has hit algorithm (i.e. based on current measured real storage and
page i/o demand and past measurement history of real storage and page
i/o demand, predict if there is enuf resources to efficiently execute
additional process)

In the resource manager there was a great deal of measurement feedback
which attempts to improve its predictive controls.

Definitly some controls for recovery after disaster has struck is
better than having no controls at all. However, a more sophisticated
algorithm (predictive) that prevents disaster altogether (which
includes dynamic adaptive feedback & recovery when it is wrong)
... will perform much better than just doing simple recovery.

The other problems you will run into (typical of many current controls
implemented with HPO 3.4) is what type of number (parameter) will you
use for indicating when page thrashing has occured?; an "absolute"
page rate number that is only related to page thrashing via 2nd order
effects (including load, configurations, whether you have electronic
drums or not, etc.)?

Unfortunately ... the PID VMs don't have the instrumentation described
in my documents and other literature to accurately measure process
specific & system related I/O activity. It turns out that
instrumentation and measurement are pre-requisates for dynamic
adaptive algorithm that can predict activity, take corrective actions,
measure predicted results and use the observations for dynamically
adjusting to compensate for problems.

BY DEFINITION, IT IS NOT POSSIBLE TO IMPLEMENT THE NECESSARY CONTROL
ALGORITHMS WITHOUT HAVING THE INSTRUMENTATION AND MEASUREMENT DATA
THAT THE ALGORITHMS ARE DEPENDENT ON.

Frequently, people fake it, by making simplifying assumptions about
what the measurement data is expected to show in a small number of
observed occasions and then hard-coding the values in ... and doing
away with all the hard problems about dynamic adaptive, feedback
resource managerment.

They are then forced into making the hard-coded values into tuning
parameters ... because they will never be able to correctly "guess" at
the right values (for all possible configurations and workloads). Then
for the next several years a body of mythology grows up about what are
the magic (tuning) values that have been found to improve things in
one specific environment or another. The tuning lore around complex
systems that don't have dynamic, adaptive, feedback scheduling
compares with any of the sci-fantasy flics.

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

The History of Computer Role-Playing Games

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The History of Computer Role-Playing Games...
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers
Date: Wed, 27 Dec 2006 14:31:39 -0700

Adam Thorton wrote:

It's wrong.  ADVENT is 1972, or possibly a little bit later.  But even
Advent isn't *really* what he's talking about: "Adventure" and "RPG"
are two distinct genres, although they certainly weren't even in the
mid 1980s--_The Book of Adventure Games_ and its sequel, from 1984 and
1985 respectively, contain not only what are now adventure games, but
also hints and maps for the Wizardry and Ultima games.  He's basically
talking about games with randomized combat (although Zork would count
here), and character statistics, some sort of level or power
advancement system (oddly, Zork is still in the running: your hit
points, though hidden from you except in vague terms with DIAGNOSE, go
up, I think, as you score more points, and your chance of hitting the
thief certainly does).

ref:
http://www.rickadams.org/adventure/a_history.html
a posts on the subject:
http://www.garlic.com/~lynn/2005u.html#15 Fast action games on System/360+?
http://www.garlic.com/~lynn/2005u.html#25 Fast action games on System/360+?
http://www.garlic.com/~lynn/2005u.html#28 Fast action games on System/360+?

the following response has earlier time than original message since it
came from about 8 time-zones away


To: wheeler
Date: 04/05/78  09:36:19

good morning.
you were asking about a game called adventure.
if you still want a copy - i hav been promised a copy in few days time
so let me know if you still want it

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


From: wheeler
Date: 04/05/78  08:08:03

Would appreciate a copy of ADVENTURE. I will be going to TYMSHARE
on Friday morning and will try to get a copy from them. (TYMSHARE
is a commercial VM service. They also provide the machine, userids, etc.
for VMSHARE. When their management found out that ADVENTURE was being
offered, they wanted to take it off the system. They changed their
minds when they got a look at the books. ADVENTURE is one of TYMSHARE's
biggest money makers.) I don't know yet whether they will dump it
to tape for me. I'm also going to try and get a VMSHARE userid from them.
             thxs-  Lynn

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

Tymshare had got a PDP-10 copy from Stanford and then ported it to their
VM system ... past posts mentioning commercial vm-based timesharing companies
http://www.garlic.com/~lynn/submain.html#timeshare

I had gotten a copy of it in the late 70s and made it available internally
inside the company ... which resulted in some amount of uproar

recent posts for some bbn/imp trivia topic drift
http://www.garlic.com/~lynn/2006e.html#9 terminals was: Caller ID "spoofing"
http://www.garlic.com/~lynn/2006j.html#50 Arpa address
http://www.garlic.com/~lynn/2006k.html#3 Arpa address
http://www.garlic.com/~lynn/2006k.html#27 PDP-1
http://www.garlic.com/~lynn/2006l.html#52 Mainframe Linux Mythbusting
http://www.garlic.com/~lynn/2006m.html#42 Why Didn't The Cent Sign or the Exclamation Mark Print?
http://www.garlic.com/~lynn/2006w.html#44 more secure communication over the network

==

misc. other past posts mentioning adventure
http://www.garlic.com/~lynn/99.html#169 Crowther (pre-Woods) "Colossal Cave"
http://www.garlic.com/~lynn/2000d.html#33 Adventure Games (Was: Navy orders supercomputer)
http://www.garlic.com/~lynn/2001m.html#44 Call for folklore - was Re: So it's cyclical.
http://www.garlic.com/~lynn/2002d.html#12 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2003l.html#40 The real history of computer architecture: the short form
http://www.garlic.com/~lynn/2004c.html#34 Playing games in mainframe
http://www.garlic.com/~lynn/2004g.html#49 Adventure game (was:PL/? History (was Hercules))
http://www.garlic.com/~lynn/2004g.html#57 Adventure game (was:PL/? History (was Hercules))
http://www.garlic.com/~lynn/2004h.html#0 Adventure game (was:PL/? History (was Hercules))
http://www.garlic.com/~lynn/2004h.html#1 Adventure game (was:PL/? History (was Hercules))
http://www.garlic.com/~lynn/2004h.html#2 Adventure game (was:PL/? History (was Hercules))
http://www.garlic.com/~lynn/2004h.html#4 Adventure game (was:PL/? History (was Hercules))
http://www.garlic.com/~lynn/2004m.html#20 Whatever happened to IBM's VM PC software?
http://www.garlic.com/~lynn/2005c.html#45 History of performance counters
http://www.garlic.com/~lynn/2005h.html#38 Systems Programming for 8 Year-olds
http://www.garlic.com/~lynn/2005k.html#18 Question about Dungeon game on the PDP
http://www.garlic.com/~lynn/2005l.html#16 Newsgroups (Was Another OS/390 to z/OS 1.4 migration
http://www.garlic.com/~lynn/2006n.html#3 Not Your Dad's Mainframe: Little Iron

==

recent posts mentioning vmshare and getting process setup to be shipped
monthly tape of all vmshare (and then pcshare) files and making them
available internally
http://www.garlic.com/~lynn/2006b.html#39 another blast from the past
http://www.garlic.com/~lynn/2006d.html#2 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006h.html#9 It's official: "nuke" infected Windows PCs instead of fixing them
http://www.garlic.com/~lynn/2006n.html#3 Not Your Dad's Mainframe: Little Iron
http://www.garlic.com/~lynn/2006p.html#29 Greatest Software Ever Written?
http://www.garlic.com/~lynn/2006r.html#11 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006r.html#37 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006r.html#43 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006s.html#65 Paranoia..Paranoia..Am I on the right track?.. any help please?
http://www.garlic.com/~lynn/2006v.html#22 vmshare
http://www.garlic.com/~lynn/2006v.html#30 vmshare
http://www.garlic.com/~lynn/2006v.html#34 vmshare
http://www.garlic.com/~lynn/2006v.html#38 vmshare
http://www.garlic.com/~lynn/2006v.html#40 vmshare
http://www.garlic.com/~lynn/2006w.html#25 To RISC or not to RISC
http://www.garlic.com/~lynn/2006w.html#42 vmshare
http://www.garlic.com/~lynn/2006w.html#48 vmshare
http://www.garlic.com/~lynn/2006x.html#7 vmshare
http://www.garlic.com/~lynn/2006x.html#8 vmshare

The History of Computer Role-Playing Games

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The History of Computer Role-Playing Games...
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers
Date: Wed, 27 Dec 2006 15:00:46 -0700

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

http://www.rickadams.org/adventure/a_history.html

re:
http://www.garlic.com/~lynn/2006y.html#18 The History of Computer Role-Playing Games...

from above ... an early "SPAM" reference

In 1976, Don Woods was working at Stanford University's Stanford
Artificial Intelligence Lab, otherwise known by the acronym SAIL.

Woods found a copy of Crowther's woods picture rudimentary program
left on one of the SAIL computers by some unknown Johnny Appleseed, so
to speak.

He contacted Crowther by the simple expedient of sending email to
"crowther@sitename," where sitename was every computer then on the
Internet, only a mere handful of sites at the time. After
corresponding with Crowther and getting his blessings, Woods greatly
expanded the program.

... snip ...

but as noted, there was only a *mere handful* of sites on the arpanet
at the time. this somewhat corresponds to past references about BBN
being able to have regularly scheduled weekly maint, taking down all
the arpanet nodes at the same time ... recent references

http://www.garlic.com/~lynn/2006k.html#10 Arpa address
http://www.garlic.com/~lynn/2006x.html#8 vmshare
http://www.garlic.com/~lynn/2006y.html#5 The Future of CPUs: What's After Multi-Core?

... which is possible when you have a relatively small, homogeneous
environment.

from old RFC638:

PLEASE REMEMBER THAT TUESDAY MORNINGS FROM 7am TO 9am ARE RESERVED
FOR NETWORK SOFTWARE MAINTENANCE.

... snip ...

the referenced RFC also gives monthly hardware maintenance schedule
for all the network nodes (again, something possible when you have a
small, homogeneous environment).

moving on

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: moving on
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers
Date: Wed, 27 Dec 2006 16:44:02 -0700

Ellen wrote:

Dear VM Community,

After many years as a VM Systems Programmer and Manager, I'll be
leaving Interactive Data at the end of December to pursue other
interests.  My thanks to those of you whom I've known throughout the
years and to all the VM Community for your support.  I'd especially
like to thank the VM Developers whose talent, creativity, and
dedication make VM such a great system.  The VM mainframe continues
to be a key component of Interactive Data's IT operation.

Very best wishes for a Happy Holiday season and a Peaceful New Year.

old email mentioning IDC from long ago and far away:

first two paragraphs somewhat related to this old email from 1973 and 1975
http://www.garlic.com/~lynn/2006v.html#36 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006w.html#7 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?

whole lot of posts about trying to get address location independent
executable images
http://www.garlic.com/~lynn/submain.html#adcon

being mapped from (CMS) paged mapped filesystem that I had original
implemented for cp67 and then ported to vm370
http://www.garlic.com/~lynn/submain.html#mmap

misc. posts about vm-based commercial time-sharing services
http://www.garlic.com/~lynn/submain.html#timeshare

and some additional topic drift, recent posts discussing mapping
objects to virtual address space
http://www.garlic.com/~lynn/2006w.html#17 Cache, TLB and OS
http://www.garlic.com/~lynn/2006x.html#26 Multiple mappings
http://www.garlic.com/~lynn/2006x.html#11 Multiple mappings


From: wheeler
Date: 03/26/79 07:52:36

For relocate shared segment support, a shared segment may appear
anywhere within a virtual machine's address space (it does not need to
be at the position specified in the VMABLOK). The way I handled it in
DMKVMA was to use the PTO pointers in the VMABLOK to check the shared
segments, rather than using the segment index number to displace into
the segment table and pick-up the STE.

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

Customers appear to be ordering 4300s in large quantities. Single
outstanding problem is how to do centralized maintenance. For example
Univ. of Maine has 1 4341 and 8 4331s on order.  They would like to do
without any tape drives at all on the 4331s and do all maintenance
over the network from the 4341. One thing they wanted to know, would
it be possible to load data from the CPU's floppy disk reader? They
would initially be willing to have one tape drive which they move
around as each of the 4331s are installed, but they would then like to
get rid of it after that and rely on the network. Several other
installations are starting to talk about going the same way (Univ. of
Maine is considered a small installation). This question of remote
mainenance may become very critical (possibly the most critical) for
installations talking about 20, 30, 40 or more CPUs all being serviced
from a central site.  I would suggest that you find as many people as
possible to start looking at it and networking in general before the
next share. By comparison all the current activity with performance
optimization by customers can be minimized by just ordering additional
CPUs (if they can maintain them in a reasonable way).

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

with regard to the last paragraph ... misc recent posts on the subject of
distributed vm operation and large 43xx installations:
http://www.garlic.com/~lynn/2006v.html#11 What's a mainframe?
http://www.garlic.com/~lynn/2006x.html#18 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006x.html#30 The Elements of Programming Style
http://www.garlic.com/~lynn/2006x.html#31 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006y.html#5 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006y.html#6 The Future of CPUs: What's After Multi-Core?

moving on

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: moving on
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers
Date: Wed, 27 Dec 2006 21:15:46 -0700

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

Customers appear to be ordering 4300s in large quantities. Single
outstanding problem is how to do centralized maintenance. For example
Univ. of Maine has 1 4341 and 8 4331s on order.  They would like to do
without any tape drives at all on the 4331s and do all maintenance
over the network from the 4341. One thing they wanted to know, would
it be possible to load data from the CPU's floppy disk reader? They
would initially be willing to have one tape drive which they move
around as each of the 4331s are installed, but they would then like to
get rid of it after that and rely on the network. Several other
installations are starting to talk about going the same way (Univ. of
Maine is considered a small installation). This question of remote
mainenance may become very critical (possibly the most critical) for
installations talking about 20, 30, 40 or more CPUs all being serviced
from a central site.  I would suggest that you find as many people as
possible to start looking at it and networking in general before the
next share. By comparison all the current activity with performance
optimization by customers can be minimized by just ordering additional
CPUs (if they can maintain them in a reasonable way).

re:
http://www.garlic.com/~lynn/2006y.html#20 moving on
above includes email in the post dated 26mar79
http://www.garlic.com/~lynn/2006y.html#email790326

The 4341 tests were on an early endicott engineering machine
(E4 code name, delivered to disk test lab) that had some
temporary patches that slowed it down compared to what production
machine would be.

Following email from 2/20/79 mention customer talking about wanting to
place an order for 70 such machines.

this old post
http://www.garlic.com/~lynn/2001m.html#15 Multics Nostalgia
includes email from 4apr79
http://www.garlic.com/~lynn/2001m.html#email790404

about air force data systems looking at 20 4341s ... but then six
months later, the order had been increased to 210 (fall79).

Other recent posts mentioning orders of large numbers of 43xx
machines
http://www.garlic.com/~lynn/2006p.html#34 "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#40 "25th Anniversary of the Personal Computer"
http://www.garlic.com/~lynn/2006s.html#41 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006v.html#11 What's a mainframe?
http://www.garlic.com/~lynn/2006v.html#19 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006v.html#25 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006x.html#18 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006y.html#5 The Future of CPUs: What's After Multi-Core?


From: wheeler
Date: 02/12/79  13:01:01

Following are times for floating point fortran job running identical
CP&CMS (4341 does not have ECPS on)

                  158               3031              4341
Rain          45.64/47.42    |   37.03/37.77   |   36.21/37.57
Rain4         43.90/44.80    |   36.61/36.89   |   36.13/36.51

also times approx;
                  145                168                91
                 145 secs.           9.1 secs          6.77 secs

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

of course the following MVS 168-3 doesn't include the "capture
ratio" information ... some discussion in this post
http://www.garlic.com/~lynn/2006x.html#19 Ranking of non-IBM mainframe builders?


From: wheeler
Date: 02/12/79  21:36:29

Do you know if the STL VM 168s have (or don't have) the high speed
multiply feature?????

the 168-3 VM test number was taken from STLVM3

Following are times for floating point fortran job running identical
CP&CMS (4341 does not have ECPS on). Command was 'LOAD XXXX (START'
link-edit time included).

                    RAIN                  RAIN4

  158     |     45.64/47.42     |     43.90/44.80
 3031     |     37.03/37.77     |     36.41/36.89
 4341     |     36.21/37.57     |     36.13/36.51
168-3     |      8.89/ 9.65     |      8.81/ 9.79

SJR MVS 168-3 with high speed multiply
PGM=      |         8.84        |         8.73
LOAD&GO   |         9.3         |         9.1

also times approx;
              145                168                91
           145 SECS.           9.1 SECS          6.77 SECS

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


From: wheeler
Date: 02/20/79  09:12:59

Numbers fro Rain&Rain4 are virtual & total time (right off of CMS
ready message). Only diff. between rain&rain4 is one does a lot of
console output at intermediate steps. The job is fortran , extremely
heavy on floating point operations. It comes by the way of the palo
alto branch office. It was part of a bid proposal by the Lawrence
Radiation Lab. in Livermore (with specs that it used 35.77 cpu
secs. on a CDC6600).

VMA was turned on for all machines (but ECPS was not on the E4).  The
CPU numbers are nearly the same on 168-3 for VM, MVS, & SVS (all using
FORTGI) so there is little operating system involved. (by the way,
from another source a comment was attributed to the same lab. that if
IBM had a 1 mip processor for under $300k, they would order 70 - thats
right seventy).

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

This appears to be a case where somebody that had seen my numbers and
had leaked them.


From: wheeler
Date: 02/26/79  17:56:35

has somebody else been doing a '1 fortran job' benchmark on the 4341?
Electronic news for Feb. 20, 1979 quotes an IBM spokesman as saying
based on 1 Fortran job, that it probably exceeds performance of a 3031
mainframe in running Fortran.

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

old posts mentioning rain/rain4
http://www.garlic.com/~lynn/2000d.html#0 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2001d.html#67 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2002b.html#0 Microcode?
http://www.garlic.com/~lynn/2002e.html#75 Computers in Science Fiction
http://www.garlic.com/~lynn/2002i.html#7 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#12 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#19 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#22 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002k.html#4 misc. old benchmarks (4331 & 11/750)
http://www.garlic.com/~lynn/2003g.html#68 IBM zSeries in HPC
http://www.garlic.com/~lynn/2005m.html#25 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2006x.html#31 The Future of CPUs: What's After Multi-Core?

"The Elements of Programming Style"

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "The Elements of Programming Style"
Newsgroups: alt.folklore.computers
Date: Thu, 28 Dec 2006 06:46:40 -0700

jmfbahciv writes:

<snort>  Then you don't know about general timesharing operating
systems.  Try to find posts (there aren't many) about real-time
clocks.

misc. past posts mentioning vm-based commercial time-sharing service
bureaus.
http://www.garlic.com/~lynn/submain.html#timeshare

recent post about needing instrumentation and measurement in
order to implement dynamic adaptive resource management (requiring
lots of timing facilities)
http://www.garlic.com/~lynn/2006y.html#17 The Future of CPUs: What's After Multi-Core?

i had done original implementation on cp67 while an undergraduate in the
60s. misc. collected posts
http://www.garlic.com/~lynn/subtopic.html#fairshare

things improved going from 360/67 to 370 which added TOD timer and a number
of other hardware timing facilities. one of the first things i got
to work on after joining the science center was participate in group
trying to figure out how to handle "leap seconds" in connection with
the 370 TOD timer.

misc. past with some mention of 370 timing facilities
http://www.garlic.com/~lynn/2000.html#2 Computer of the century
http://www.garlic.com/~lynn/2000.html#4 Computer of the century
http://www.garlic.com/~lynn/2000d.html#42 360 CPU meters (was Re: Early IBM-PC sales proj..
http://www.garlic.com/~lynn/2001f.html#53 any 70's era supercomputers that ran as slow as today's   supercomputers?
http://www.garlic.com/~lynn/2002.html#52 Microcode?
http://www.garlic.com/~lynn/2002g.html#2 Computers in Science Fiction
http://www.garlic.com/~lynn/2002o.html#44 Help me find pics of a UNIVAC please
http://www.garlic.com/~lynn/2003.html#21 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#23 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003l.html#48 IBM Manuals from the 1940's and 1950's
http://www.garlic.com/~lynn/2003n.html#50 Call-gate-like mechanism
http://www.garlic.com/~lynn/2003n.html#52 Call-gate-like mechanism
http://www.garlic.com/~lynn/2004c.html#47 IBM 360 memory
http://www.garlic.com/~lynn/2004m.html#36 Multi-processor timing issue
http://www.garlic.com/~lynn/2004m.html#37 Multi-processor timing issue
http://www.garlic.com/~lynn/2004m.html#40 Result of STCK instruction - GMT or local?
http://www.garlic.com/~lynn/2004m.html#43 Multi-processor timing issue
http://www.garlic.com/~lynn/2004p.html#15 Amusing acronym
http://www.garlic.com/~lynn/2005t.html#15 Best practice for TOD clock
http://www.garlic.com/~lynn/2006c.html#20 Military Time?
http://www.garlic.com/~lynn/2006c.html#23 Military Time?
http://www.garlic.com/~lynn/2006g.html#18 TOD Clock the same as the BIOS clock in PCs?
http://www.garlic.com/~lynn/2006g.html#30 TOD Clock the same as the BIOS clock in PCs?
http://www.garlic.com/~lynn/2006i.html#0 The Pankian Metaphor
http://www.garlic.com/~lynn/2006i.html#34 TOD clock discussion
http://www.garlic.com/~lynn/2006i.html#35 TOD clock discussion
http://www.garlic.com/~lynn/2006n.html#35 The very first text editor
http://www.garlic.com/~lynn/2006p.html#46 "25th Anniversary of the Personal Computer"
http://www.garlic.com/~lynn/2006q.html#10 what's the difference between LF(Line Fee) and NL (New line) ?
http://www.garlic.com/~lynn/2006r.html#44 Was FORTRAN buggy?

moving on

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: moving on
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers
Date: Thu, 28 Dec 2006 11:09:42 -0700

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

The 4341 tests were on an early endicott engineering machine
(delivered to disk test lab) that had some temporary patches that
slowed it down compared to what production machine would be.

re:
http://www.garlic.com/~lynn/2001m.html#15 departmental servers
http://www.garlic.com/~lynn/2006y.html#20 moving on
http://www.garlic.com/~lynn/2006y.html#21 moving on
and old email
http://www.garlic.com/~lynn/2006y.html#email790212
http://www.garlic.com/~lynn/2006y.html#email790212b
http://www.garlic.com/~lynn/2006y.html#email790220
http://www.garlic.com/~lynn/2006y.html#email790326
http://www.garlic.com/~lynn/2001m.html#email790404
http://www.garlic.com/~lynn/2001m.html#email790404b

i.e. E4 was code name for 4341 ... production 4341 machine cycle
will be speeded up by about 15 percent (compared to E4 I was
benchmarking)


To: somebody in endicott
From: wheeler
Date: 01/22/79  19:22:21

Do you know anybody knowledgeable about running VM on E4???
GPD test lab just got one, we gen'ed release 5 VM to run on it. It
seems to work alright, except the E4 seems to have some hardware
(red lighting) problem with the interval timer. Hopefully that
will be corrected shortly.

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


From: wheeler
Date: 01/23/79  13:30:07

I sent a message to Endicott saying that we had IPL'ed release 5 on
the E4 and asking if anybody knew of any problems we would run into
using release 5. I also mentioned that it red lighted when we 1st
IPL'ed.

Endicott is now trying to answer the red light question. I got a call
from XXXXX who designed it, asking questions and offering suggestions.
He is calling YYYYY now to see if he can help any. It seems to have
gotten a lot more complex than i had thot.

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


From: wheeler
Date: 01/23/79  15:39:46

Just tried Q SRM DSPSL on E4 , it comes out 23.5 compared to 24.1 on 3031
and 26.1 on a 158-3.

Engineers said this is early model with 'slow' internal clock. Clock
will be speeded up at least by 1/7 which would bring DSPSL down to
20.0 or a little below. Box looks like an old fashion Freezer chest,
only about 12 inches higher and 50 % longer.

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

"The Elements of Programming Style"

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "The Elements of Programming Style"
Newsgroups: alt.folklore.computers
Date: Fri, 29 Dec 2006 08:45:45 -0700

jmfbahciv writes:

With a general timesharing OS, both have to happen.  Deciding which
one, nested or serially, is the elegance of the OS.  Consider TTY
character interrupts.  Warning: I'm using DEC lingo because I don't
know any better.  A ^C^C means stops everything for that user.
An interrupt that should cause the exec to stop (unix calls this
the kernal) is higher precedence than anything unless the data
in core is more important (you don't create a graceful crash
that reboots and clears memory).

I guess what I'm trying to say is that there can't be a hard and
fast rule about the order which priorities are serviced.  I
probably could think of some scenarios where a lower priority
should be dealt with before a higher priority.  For a general
timesharing OS, this has to a variable (set by the sysadmin?)

recent thread from comp.arch about terminal character processing.
this is issue that heavy character-at-a-time echo placed on
processing latency/response.

the original post was about supporting terminals at a really remote
location and latency/response problems by doing character-at-a-time
echo ... and attempting to do heavy optimization for handling.

initial response was a comment that block processing would have
significantly helped the situation i.e. like block processing
mode available in ascii 3101 glass tty ...
http://www.garlic.com/~lynn/2006y.html#0 Why so little parallelism?
http://www.garlic.com/~lynn/2006y.html#4 Why so little parallelism?
http://www.garlic.com/~lynn/2006y.html#10 Why so little parallelism?

the above posts then wander off into priority handling ... even with
block mode processing ... there could still be all sorts of
conditional situation. one of the posts in comp.arch mentioned that
there has been a whole lot of work in linux kernel scheduling having
to do with how X-window events are handled ... trying to promote at
response w/o letting X actually run away with processing (and totally
degrade other processing).

the general case was that there is a certain amount of human
expectation with respect to events that might be considered
interactive response ... and so should be given better execution
priority for short period. one of the problems is that certain
applications may be able to generate such a high-rate of "identified
events" ... that even with each even getting only a small amount of
high priority execution ... the frequency of the events allows the
application to monopolize the processor.

dating back to doing dynamic adaptive processing as undergraduate in
the 60s, i would monitor the resource accumulation of the process and
temper the high priority execution of "response" events by the rate of
resource consumption that the process was getting. misc. recent
posts on dynamic adaptive processing
http://www.garlic.com/~lynn/2006g.html#1 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#18 TOD Clock the same as the BIOS clock in PCs?
http://www.garlic.com/~lynn/2006g.html#34 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#36 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#40 Why are smart cards so dumb?
http://www.garlic.com/~lynn/2006h.html#7 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#22 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#23 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#25 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#30 The Pankian Metaphor
http://www.garlic.com/~lynn/2006i.html#42 virtual memory
http://www.garlic.com/~lynn/2006i.html#43 virtual memory
http://www.garlic.com/~lynn/2006j.html#1 virtual memory
http://www.garlic.com/~lynn/2006j.html#21 virtual memory
http://www.garlic.com/~lynn/2006j.html#30 virtual memory
http://www.garlic.com/~lynn/2006j.html#40 virtual memory
http://www.garlic.com/~lynn/2006n.html#42 Why is zSeries so CPU poor?
http://www.garlic.com/~lynn/2006q.html#37 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006r.html#39 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006s.html#25 VM SPOOL question
http://www.garlic.com/~lynn/2006u.html#50 Where can you get a Minor in Mainframe?
http://www.garlic.com/~lynn/2006v.html#23 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006w.html#34 Top versus bottom posting was Re: IBM sues maker of Intel-based Mainframe clones
http://www.garlic.com/~lynn/2006x.html#10 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006y.html#17 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006y.html#22 "The Elements of Programming Style"

"The Elements of Programming Style"

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "The Elements of Programming Style"
Newsgroups: alt.folklore.computers
Date: Fri, 29 Dec 2006 09:13:29 -0700

Greg Menke <gregm-xyzpdq3@toadmail.com> writes:

On that basis then "security" might involve accepting interrupts
only from hardware that has a driver ready, and the drivers ensuring
the hardware is actually asserting an interrupt before starting some
I/O, and then verifying that the I/O parameters are within the specs
of the device and conform to OS procedures.  I'm not sure I'd call
this security- the term being so general and confused these days.

this can sort of be considered in the light of availability and can
wander over into DOS-attacks ... recent post about DOS-attacks and
considering availability a characteristic of security (from the
security "PAIN" acronym)
http://www.garlic.com/~lynn/aadsm26.htm#17 Changing the Mantra - RFC 4732 on rethinking DOS
original BLOG entry
https://financialcryptography.com/mt/archives/000844.html

i ran into it earlier when i rewrote the operating system i/o
subsystem for the disk engineering and test labs (bldg. 14&15)
http://www.garlic.com/~lynn/subtopic.html#disk

they had tried running MVS on processors used for "testcell" testing
(engineering and development devices) and MTBF was on the order of
15-minutes (crashes and/or hangs) ... and they had been doing the testing
with machines in scheduled "stand alone" time (with simple, custom
written stand-alone monitors).

i set out to rewrite the i/o subsystem (drivers, interrupt handlers,
device scheduling, etc) to make it absolutely bullet-proof so that
they could do testing of multi-concurrent testcells effectively "on
demand" ...  (instead of having to wait for their serially scheduled
time). One of the issues required being able to fence off devices that
were generating hot-interrupts (i.e. constant barrage of interrupts
such that the operating system would be doing nothing else but
processing that device's interrupts).

there is the security PAIN acronym

P ... privacy (sometimes CAIN and confidentiality)
A ... authentication
I ... integrity
N ... non-repudiation

availability can be considered an "integrity" attribute.

note that a lot of people doing security focus on using encryption to
hide information (i.e. privacy/confidentiality).

an example is using SSL to hide payment card numbers ... frequently
referred to as e-commerce ... old posts
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

so a lot of this is related to press about data breaches, security
breaches, "identity theft", etc. ... and requiring more encryption
for hiding "account numbers" as countermeasure to evesdropping,
harvesting, skimming, etc, attacks
http://www.garlic.com/~lynn/subintegrity.html#harvest
and using the information in fraudulent transactions.
http://www.garlic.com/~lynn/subintegrity.html#fraud

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

so part of the analysis was the extreme dual requirements for account
numbers ... one one hand if account numbers were divulged, then they
could be used in fraudulent transactions (so account numbers had to be
kept strictly confidential and never divulged). on the other hand,
account numbers are required in a large number of different business
processes ... and as such they had to be readily available. this lead
to the observation that the planet could be buried under miles of
(information hiding) cryptography and still not prevent account number
leakage.

for x9.59 transactions, effectively privacy is replaced with
authentication and integrity (as countermeasure to
fraudulent transactions) ... i.e. the account numbers can be openly
divulged and fraudulent transactions would still not be
possible. x9.59 not only is a countermeasure to skimming at
point-of-sale and ATM terminals, but is also countermeasure to
numerous data breaches and security breaches (i.e. it
doesn't prevent the breaches, just eliminates the breaches as useful
attack for fraudulent transactions).

this is somewhat related to old comments about security proporitional
to risk
http://www.garlic.com/~lynn/2001h.html#61

or the posts about naked payments/transactions
http://www.garlic.com/~lynn/aadsm24.htm#5 New ISO standard aims to ensure the security of financial transactions on the Internet
http://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#8 Microsoft - will they bungle the security game?
http://www.garlic.com/~lynn/aadsm24.htm#9 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#10 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#12 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#14 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#22 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#26 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#27 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#30 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#31 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#38 Interesting bit of a quote
http://www.garlic.com/~lynn/aadsm24.htm#41 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#42 Naked Payments II - uncovering alternates, merchants v. issuers, Brits bungle the risk, and just what are MBAs good for?
http://www.garlic.com/~lynn/aadsm24.htm#46 More Brittle Security -- Agriculture
http://www.garlic.com/~lynn/aadsm25.htm#20 Identity v. anonymity -- that is not the question
http://www.garlic.com/~lynn/aadsm25.htm#25 RSA SecurID SID800 Token vulnerable by design
http://www.garlic.com/~lynn/aadsm25.htm#28 WESII - Programme - Economics of Securing the Information Infrastructure
http://www.garlic.com/~lynn/aadsm26.htm#6 Citibank e-mail looks phishy
http://www.garlic.com/~lynn/aadsm26.htm#13 Who has a Core Competency in Security?
http://www.garlic.com/~lynn/2006m.html#15 OpenSSL Hacks
http://www.garlic.com/~lynn/2006m.html#24 OT - J B Hunt
http://www.garlic.com/~lynn/2006o.html#35 the personal data theft pandemic continues
http://www.garlic.com/~lynn/2006o.html#37 the personal data theft pandemic continues
http://www.garlic.com/~lynn/2006o.html#40 the personal data theft pandemic continues
http://www.garlic.com/~lynn/2006t.html#40 Encryption and authentication
http://www.garlic.com/~lynn/2006u.html#43 New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006y.html#8 Securing financial transactions a high priority for 2007

moving on

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: moving on
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers
Date: Fri, 29 Dec 2006 12:31:23 -0700

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

For relocate shared segment support, a shared segment may appear
anywhere within a virtual machine's address space (it does not need to
be at the position specified in the VMABLOK). The way I handled it in
DMKVMA was to use the PTO pointers in the VMABLOK to check the shared
segments, rather than using the segment index number to displace into
the segment table and pick-up the STE.

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

re:
http://www.garlic.com/~lynn/2006y.html#20 moving on
and specifically the old email from 26mar79
http://www.garlic.com/~lynn/2006y.html#email790326
and other posts in this thread
http://www.garlic.com/~lynn/2006y.html#21 moving on
http://www.garlic.com/~lynn/2006y.html#23 moving on

one of the big problems was that the original 370 virtual memory
architecture included "segment protect" feature (i.e. turn on a bit in
segment table entry for a specific virtual address space ... and
everything in that segment became read/only for that address space).

the cp67 to vm370 morph of cms was somewhat structured around having
that feature. i've posted before how the retrofit of virtual memory
hardware to 370/165 ran into schedule problems and they dropped a
number of features from the 370 virtual memory architecture to buy
back six months in the schedule (and then made all other processors
drop them also, so that there was compatibility across the 370 line).

this resulted in forcing vm370 to revert to the cp67 convention of
protecting shared pages ... which played games with storage protect
keys. this resulted in addition vm370 overhead for cms ... but a
little later also met that VMA (virtual machine assist) microcode
performance enhancements couldn't be used with shared-system CMS (VMA
implemenation of storage key operations didn't know the rules for
protecting shared segment pages).

preparing for vm370 release 3 ... somebody came up with a hack that
would allow VMA to be used with CMS ... the storage key game was
eliminated and instead the currently running CMS would be allowed to
modify shared pages (as well as being able to run with VMA turned
on). however before switching to a different process, the dispatcher
would scan all shared pages ... searching for ones that had been
changed. If any were found ... they were discarded (and new process
requiring discarded shared page would have an unmodified copy
refreshed from disk). The trade-off of reduced overhead being able to
use VMA tended to offset the increased overhead that the dispatcher
had to scan 16 shared pages on (nearly) every process switch.

then it was also decided to pick up a very small subset of my virtual
memory management support (both cp and cms changes) as DCSS for
release 3
http://www.garlic.com/~lynn/submain.html#mmap
http://www.garlic.com/~lynn/submain.html#adcon

this initially resulted in at least doubling the typical number of
shared pages from 16 to 32. However, the overhead of the dispatcher
scanning of 32 shared pages (on every process switch) changed the
overhead trade-off vis-a-vis overhead reduction being able to use
VMA. Somebody then decided they had to go with the change page
scanning hack anyway ... since CMS intensive customers had already
been told that they would get performance benefit in vm370 release 3
with using VMA.

This was further aggravated when developing multiprocessor support
that would be shipped in vm370 release 4. The change in release 3 for
scanning for changed shared pages was predicated on a single process
having exclusive access to the shared pages at a time. With
multi-processer support, there could be multiple, concurrent running
processes. To preserve the "exclusive access" assumption, it was then
necessary to have processor specific copies of shared pages. Now, not
only did the dispatcher have to scan (an increasing number of) shared
pages for changes (on nearly every task switch) ... but it also had to
make sure that the "switched-to" process had its (virtual address)
segment table entries pointed to the processor specific shared
segments. Now, things were getting entirely out of control.

Another issue that had come up was that the original relational/sql,
system/r had been developed on vm370 and was taking advantage of more
sophisticated virtual memory support. One of the things allowed some
processes address spaces to have r/w shared access to a shared
segments while other processes had only r/o shared access
http://www.garlic.com/~lynn/submain.html#systemr
it was referred to as DWSS in the technology transfer effort from
SJR to Endicott for what became SQL/DS. few recent posts mentioning
DWSS
http://www.garlic.com/~lynn/2006t.html#16 Is the teaching of non-reentrant HLASM coding practices ever defensible?
http://www.garlic.com/~lynn/2006t.html#39 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006w.html#11 long ago and far away, vm370 from early/mid 70s

Futhermore, the processing load on the US HONE system was increasing
and they were upgrading their 370/168s to multiprocessors ... HONE was
vm370 based infrastructure that provided world-wide support to
marketing, sales, and field people.
http://www.garlic.com/~lynn/subtopic.html#hone

HONE was doing this 6-9 months before release 4 (and official
multiprocessor support) was going to be available.

As i had been involved in a lot of the multiprocessor support
http://www.garlic.com/~lynn/subtopic.html#smp
http://www.garlic.com/~lynn/submain.html#bounce

I undertook to build a version of multiprocessor support on their
production vm370 release 3; which i had already heavily modified.
While, I was doing that, I went ahead and put in the code to revert to
protection games with storage keys (eliminating needing to have unique
shared page copies for every processor) that had existed in cp67 and
in vm370 prior to release 3.

for a little drift, pieces of recent thread in comp.arch on virtual
address space mappings
http://www.garlic.com/~lynn/2006w.html#23 Multiple mappings
http://www.garlic.com/~lynn/2006x.html#23 Multiple mappings
http://www.garlic.com/~lynn/2006x.html#26 Multiple mappings
http://www.garlic.com/~lynn/2006y.html#11 Multiple mappings

past posts mentioning problem/issues retrofitting virtual memory
support to 370/165
http://www.garlic.com/~lynn/95.html#3 What is an IBM 137/148 ???
http://www.garlic.com/~lynn/99.html#7 IBM S/360
http://www.garlic.com/~lynn/99.html#204 Core (word usage) was anti-equipment etc
http://www.garlic.com/~lynn/99.html#209 Core (word usage) was anti-equipment etc
http://www.garlic.com/~lynn/2000d.html#82 "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)
http://www.garlic.com/~lynn/2000f.html#35 Why IBM use 31 bit addressing not 32 bit?
http://www.garlic.com/~lynn/2000f.html#55 X86 ultimate CISC? No. (was: Re: "all-out" vs less aggressive designs)
http://www.garlic.com/~lynn/2000f.html#63 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000g.html#10 360/370 instruction cycle time
http://www.garlic.com/~lynn/2000g.html#15 360/370 instruction cycle time
http://www.garlic.com/~lynn/2000g.html#16 360/370 instruction cycle time
http://www.garlic.com/~lynn/2000g.html#21 360/370 instruction cycle time
http://www.garlic.com/~lynn/2001.html#63 Are the L1 and L2 caches flushed on a page fault ?
http://www.garlic.com/~lynn/2001b.html#37 John Mashey's greatest hits
http://www.garlic.com/~lynn/2001c.html#7 LINUS for S/390
http://www.garlic.com/~lynn/2001k.html#8 Minimalist design (was Re: Parity - why even or