List of Archived Posts

2005 Newsgroup Postings (05/04 - 05/18)

Where should the type information be?

Single System Image questions

Single System Image questions

IBM 360 channel assignments

IBM 360 channel assignments

Single System Image questions

Software for IBM 360/30 (was Re: DOS/360: Forty years)

IBM 360 channel assignments

keysigning: identity checks

Exceptions at basic block boundaries

Exceptions at basic block boundaries

Exceptions at basic block boundaries

practical applications for synchronous and asynchronous communication

Today's mainframe--anything to new?

Today's mainframe--anything to new?

Exceptions at basic block boundaries

Today's mainframe--anything to new?

Exceptions at basic block boundaries

Exceptions at basic block boundaries

Blowing My Own Horn

Key pair & Certificate lifetimes

Thou shalt have no other gods before the ANSI C standard

Today's mainframe--anything to new?

Single System Image questions

Description of a new old-fashioned programming language

couple more Q's on basic public key encryption techniques

Crash detection by OS

How do you get the chain of certificates & public keys securely

Crash detection by OS

Dealing with warning that certifcate can't be trusted?

Query on Load Balancer with SSL

IBM 1130

Software for IBM 360/30

Software for IBM 360/30

some walk down history lane

Systems Programming for 8 Year-olds

Security via hardware?

Software for IBM 360/30

Systems Programming for 8 Year-olds

Attacks on IPsec

Software for IBM 360/30

Systems Programming for 8 Year-olds

Systems Programming for 8 Year-olds

Systems Programming for 8 Year-olds

First assembly language encounters--how to get started?

First assembly language encounters--how to get started?

Password question

Where should the type information be?

From: lynn@garlic.com
Subject: Re: Where should the type information be?
Newsgroups: comp.arch.arithmetic,comp.arch,alt.folklore.computers
Date: 4 May 2005 07:50:15 -0700

Brian Inglis wrote:

Most programs (e.g. ftp, HLLAPI, telnet/tn3270) I've used interconvert
the characters unavailable on the other's keyboard: [ ] to =A2 =AC in
arbitrary order; conversions between EBCDIC solid and broken vertical
bars and the ASCII vertical bar are idiosyncratic, to say the least.

some of this may be my fault. three people came out from CSC the last
week of january, 1968 to install cp67 at the university. at that time,
cp67 only contained 1052 & 2741 terminal support. I had to add
TTY/ascii terminal support. I started out by borrowing ebcdic<->ascii
translate tables from BTAM ... and tweaking them to make them more
conducive for cp67 operation.

one of the cp67 characteristics was terminal character & line delete
operation. on the right side of 2741 keyboard, there is key with
at-sign lower-case and cent-sign as upper-case. the convention in cp67
was that at-sign (lowercase key) deleted the next character to the left
(already entered) ... multiple at-signs would delete multiple adjacent
characters (already entered on the left). The cent-sign (uppercase on
the at-sign key) would delete all characters to the left (already
entered, to start of line).

i don't have reference right now ... but from vague memory ... i
believe tty/33 had left/right brackets in approx. same position on the
keyboard (so i fiddled the translate tables based on that).

the standard cp67 code had dynamic terminal identification for 1052 &
2741 (you didn't have to make fixed terminal type definitions
associated with specific terminal controller port). I thot that i was
going to be fancy and do the same thing when adding tty support. i also
thot that i could have a single dial-up number for modem pool ... so
all terminals could dial-in on the same number.

The dynamic terminal identification worked ... but the dial-in part
didn't. While the code could dynamically determine the connected
terminal ... the standard mainframe terminal controller interface
couldn't handle the general case of arbitrary terminal connecting to an
arbitrary controller port.

The terminal controller did have "SAD" command support so that an
arbitrary line-scanner could be associated with an arbitrary port. The
problem was that they had hardwired oscillators on each port ... which
fixed the port baud rate. As long as different terminals shared the
same baud-rate ... it was possible to use the "SAD" command support to
associate the appropriate line-scanner with a port (which is why the
1052 & 2741 terminal support worked ... they had different controller
line-scanner ... but the same baud rate).

Adding TTY support ... it was possible to dynamically define the
terminal type (w/o requiring predefined terminal tables) ... but it
wasn't possible to actually dynamically intermix connection of
terminals with different baud rates on the same port.

this somewhat kicked off the clone controller project
http://www.garlic.com/~lynn/subtopic.html#360pcm

where the mainframe channel interface was reversed engineered and a
channel interface board built for an Interdata/3 ... and the
Interdata/3 was programmed to emulate the ibm mainframe controller. In
the interdate/3 impementation ... support was added to do high-speed
probe of in-coming signal on ports to dynamically determine connecting
terminal baud rate.

Single System Image questions

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Single System Image questions
Newsgroups: comp.arch,alt.folklore.computers
Date: Wed, 04 May 2005 11:43:21 -0600

bs2k1 writes:

Hi,
I have a few quick questions on the topic of Single System Images.

1. What are the reasons that a Single System Image is used?
2. Why would you have more than one SSI in a cluster?
3. If you have more than one SSI why would it be useful to do this?

Thanks.

Bill.

homework question, right?

the hone system provided dataprocessing support for world-wide
sales, marketing, and field personnel. in the late 70s, the
US hone datacenters were consolidated in california. circa
1980, the US hone complex was pushing 40k user defintions.
http://www.garlic.com/~lynn/subtopic.html#hone

the typical HONE environment was complex set of cms\apl applications
that migrated to apl\cms ... which were frequently very processor
intensive. basically the us hone complex were the largest mainframe
SMP of the period with max. number configured in a cluster with common
disk farm.

with the consolidation of all the us hone datacenters, the "dumb" 3270
terminals were connected to frontend terminal concentrators which were
interconnected to the backend HONE processor cluster. prior to the
datacenter consolidation ... specific field connections went to a
specific datacenter machine. with all the datacenters consolidated at
a single lcoation with interconnected common disk farm ... it offered
the opportunity of implementing single-system-image with
load-balancing and fall-over/availability support.

the hone system had started out as a clone of the science
center's cp67/cms system
http://www.garlic.com/~lynn/subtopic.html#545tech

i was done a lot of performance optimization work ... but there was
also a couple projects at the science center doing performance
modeling work. one was a sophisticated performance model implemented
in cms\apl. some amount of this work provided basis for the original
morphing of performance management into things like capacity planning.

the apl performance model was also used as a basis for controlling a
large sophisticated set of automated (2000 that took 3months elapsed
time to run) benchmarks
http://www.garlic.com/~lynn/submain.html#bench

as part of calibrating the resource manager in preparation for release.
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock

the same apl performance model was also used for a HONE application
called the performance predictor that customer sales people could
run "what-if" questions about effects of change in customer hardware
configuration or workload (i.e. in this period APL was used for a lot
of applications that are currently implemented with spreadsheets)

the APL performance model was also used as an application that ran on
every processor complex in the cluster and provided information to the
front-end terminal concentrators on which processor to route login
requests ... aka SSI load-balancing. The application was also aware of
offline machines and/or machines about to become offline ...  so it
would avoid routing login requests to those processors in the cluster.

In the early 80s, the northern cal. HOME consolidated complex was
replicated, first in Dallas and then again in Boulder ...  handling
load-balancing ... but also availability (some worry about earthquake
disaster hitting the cal. datacenter.)

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

Single System Image questions

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Single System Image questions
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 06 May 2005 09:12:25 -0600

bs2k1 writes:

Thanks everyone for you answers they have been very useful.  Just one
more question.
- On a cluster that uses SSI can every computer in the cluster use the
same SSI? What I mean is can different people use the SSI from
different nodes?

in the 70s (when my wife was still in preschool) she was con'ed into
going to pok to be in charge of loosely-coupled architecture ... this
is the mainframe cluster stuff dating back to the 60s ... although
didn't necessarily always totally represent SSI. during her stint
... she wrote peer-coupled shared data architecture ... but at the
time ... POK was much more focused on big iron symmetric
(shared-memory) multiprocessing ... rather than loosely-coupled ...
so she didn't last long (some of her stuff didn't see light in the
mainframe arena until more recent sysplex)

some peer-couple references
http://www.garlic.com/~lynn/submain.html#shareddata

in late 80s we started ha/cmp (high availability,
cluster multiprocessor)
http://www.garlic.com/~lynn/subtopic.html#hacmp

minor reference a little later
http://www.garlic.com/~lynn/95.html#13

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

IBM 360 channel assignments

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 360 channel assignments
Newsgroups: alt.folklore.computers
Date: Fri, 06 May 2005 10:38:05 -0600

Peter Flass writes:

As you probably know, byte multiplexor channels interleaved data from
several I/O operations on a byte basis.  Think "one byte from the card
reader, one to the printer, ...".  Selector channels only carried out
one operation at a time.  Block multiplexor channels interleaved data
by blocks, that is, the channel could start several I/O operations
going, and the CPU or control unit would only tie up the channel when
it actually had a block of data to transfer.

Selector channels (IIRC) pretty much died out with the 360.  After
that all non character-type I/O was done by the block multiplexors,
DASD, Tape, and what-have-you.  Not as useful for tapes, but the
channel could profitably disconnect for REW, FSF, etc.

byte multiplexor typically were unit record or telecommunication
controllers. byte multiplexor could interleave multiple concurrent
streams simultaneously.

when we were doing the telecommunication clone controller
http://www.garlic.com/~lynn/subtopic.html#360pcm

one of the first bugs testing hardware on 360/67 was locking out the
high-speed timer. 360/67 had high-speed timer option that updating
storage location 80 (x'50'). if channel continuously locked out the
memory bus so that the timer had a second tic happen before it had a
chance to update memory for previous tic ... then the machine would
"red-light" (and stop with machine check).

360 had byte multiplexor and selector channels. block multiplexor was
a sort of interleave selector channel introduced with 370. block
multiplexor allowed the 3330 "set sector" feature to suspend channel
program processing until the controller raised reconnect.

in 360 ... there was paradigm that you could effectively trade
off lots of i/o channel capacity for processor real storage ...
dasd/disk channel program would position the arm and then
search for specific record identification.
http://www.garlic.com/~lynn/submain.html#dasd

these searches would tie-up up the selector channel, controller, and
device. 3330 had 19 data tracks and a 20th hardware positioning track
(sector). if you knew approximately the rotational position of the
record you needed ... you could insert a SET-SECTOR ccw in the channel
program ... that would disconnect from the channel until that position
rotated under the head (on track 20) .. at which point, it would raise
channel reconnect.

by the mid-70s, the trade-off was beginning to switch with much more
abundant real storage and more constrained i/o capacity. i once was
called into a large national retail customer that was experiencing
unexplained severed i/o bottleneck thruput. they had multiple 168s in
loosely-couple configuration with SVS. It turns out that they had a
large applicaton program PDS dataset with a three (3330) cylinder
library directory. Standard os support used multi-track search of the
program directory to find the index pointer to specific program image
on disk. multi-track search would spin until it found the correct
record ... or until end of cylinder (locking out the channel,
controller, and device). for 3330 at 3600rpm and 19 tracks ... a
full-cylinder search took appox. 300milliseconds elapsed time. On the
avg. a search took 1.5 cylinders ... or about 450milliseconds ... plus
time to load the program ... about .5seconds total. The whole
multi-system complex was being limited to about two application
program loads per second.

block multiplexor and 3330 set sector allowed for use of direct
location positioning ... but os/360 had CKD multi-track search
ingrained into various library and directory structures ... VTOCS,
PDS, etc ...  which continued to severely aggravate for years.

random past references to claiming that disk relative system performance
had declined by a factor of ten times over a period of years
http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door
http://www.garlic.com/~lynn/94.html#43 Bloat, elegance, simplicity and other irrelevant concepts
http://www.garlic.com/~lynn/94.html#55 How Do the Old Mainframes Compare to Today's Micros?
http://www.garlic.com/~lynn/95.html#10 Virtual Memory (A return to the past?)
http://www.garlic.com/~lynn/98.html#46 The god old days(???)
http://www.garlic.com/~lynn/99.html#4 IBM S/360
http://www.garlic.com/~lynn/2001b.html#38 Why SMP at all anymore?
http://www.garlic.com/~lynn/2001d.html#66 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001f.html#62 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001f.html#68 Q: Merced a flop or not?
http://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)
http://www.garlic.com/~lynn/2001l.html#61 MVS History (all parts)
http://www.garlic.com/~lynn/2001m.html#23 Smallest Storage Capacity Hard Disk?
http://www.garlic.com/~lynn/2002b.html#11 Microcode? (& index searching)
http://www.garlic.com/~lynn/2002b.html#20 index searching
http://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?
http://www.garlic.com/~lynn/2002e.html#9 What are some impressive page rates?
http://www.garlic.com/~lynn/2002.html#5 index searching
http://www.garlic.com/~lynn/2002i.html#16 AS/400 and MVS - clarification please
http://www.garlic.com/~lynn/2004n.html#15 360 longevity, was RISCs too close to hardware?
http://www.garlic.com/~lynn/2004p.html#39 100% CPU is not always bad
http://www.garlic.com/~lynn/2005f.html#55 What is the "name" of a system?

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

IBM 360 channel assignments

From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: 6 May 2005 14:23:41 -0700
Subject: Re: IBM 360 channel assignments

Eric Smith wrote:

Are you sure it appeared with the 370?  I've seen references to the
2880 block multiplexor channel for use with the 360/65, /67, and
/85.

2880 block multiplexor was needed for 3330/3830 set sector, channel
disconnect/reconnect. i can see it being available on 360/85 since it
sort of spanned end of 360 generation (being 1st cache machine)
... and possibly be retrofitted on RPQ basis to 65, 67, & possibly 75.

on standard 370 ... channels were integrated except for 165 & 168.

tried quick search engine ... which came up with a few refs
http://www.beagle-ears.com/lars/engineer/comphist/ibm_nos3.htm
http://www-03.ibm.com/ibm/history/exhibits/storage/storage_3330.html

Single System Image questions

From: lynn@garlic.com
Newsgroups: comp.arch, alt.folklore.computers
Date: 6 May 2005 15:55:04 -0700
Subject: Re: Single System Image questions

Jack Peacock wrote:

Yes and no.  Yes if the joining node is compatible with the cluster
resources, no if it requires resources (for example, special
versions of the binaries to handle hardware incompatibilities) not
shared with the rest of the cluster.  If the system image is being
shared across cluster nodes then by definition different users would
be using it on different nodes. A partial exception would be
heterogeneous clusters with mixed processor architectures, where the
image would only be available on matching hardware.
Jack Peacock

ucla locus supported heterogenous operation .... with different
architectures and even process migration across different nodes in the
cluster. the palo alto science center had running across 68k and
series/1 machines. it was later released as product ... aix/370 and
aix/ps2.

Software for IBM 360/30 (was Re: DOS/360: Forty years)

From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: 6 May 2005 19:53:19 -0700
Subject: Re: Software for IBM 360/30 (was Re: DOS/360: Forty years)

Joe Morris wrote:

I doubt that I could locate a tape control unit SRL to check it,
but I would expect that REW would return CE as ending status upon
receipt of the command, and would subsequently return DE when the
load point was reached.  I would expect RUN to return CE+DE
on receipt of the command since the device may never go ready again.

CE would release both the channel and control unit.

Sigh...with all the SYSGENs I ran over the years I never thought to
squirrel away a copy of one so that I could look back on it years
later...

i thot i usually the whole machine room to myself on the weekend ...
but one weekend i got pre-empted because the ibm se and one of the
univ. system programmers were doing a sysgen. i tried to work around
them ... they spent something like 8 hrs do a stage1 & stage2
sysgen ... maybe 150 cards stage1 ... that in turn punched out a
jobstream of about 2000 cards for stage2 sysgen. apparently something
went wrong in the stage2 ... so they broke for dinner and were going
to come back and redo the whole thing again from scratch.

while they were gone ... i made copies of both the stage1 deck and the
stage2 deck to see what was going on.

they came back ... and did their thing ... but over the next couple
weeks i tried to figure out what stage1 and stage2 were doing as well
as what was on the starter system. they had done os/360 release 7 or
8?  after some more work ... i asked if i could do the next sysgen in
the standard system job stream. I did os/360 release 9.5 ... mostly
using a starter system.

for os/360 release 11 sysgen, i ran stage1 in standard stream and got
the stage2 sysgen deck ... and sent it off to be interpretted. i then
broke the individual job steps apart and added job cards so many of
them could be run as independent jobs ... instead of one long, single
job stream. some of the stuff, i reorganized in attempt to better
optimize placement of different stuff on disk.

i made a presentation on the work at share ... and also continued work
on reorganizing the stage2 stream to better optimize the resulting
system files.

various past sysgen posts:
http://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14
http://www.garlic.com/~lynn/97.html#22 Pre S/360 IBM Operating Systems?
http://www.garlic.com/~lynn/97.html#28 IA64 Self Virtualizable?
http://www.garlic.com/~lynn/98.html#21 Reviving the OS/360 thread (Questions about OS/360)
http://www.garlic.com/~lynn/99.html#93 MVS vs HASP vs JES (was 2821)
http://www.garlic.com/~lynn/99.html#135 sysprog shortage - what questions would you ask?
http://www.garlic.com/~lynn/2000d.html#48 Navy orders supercomputer
http://www.garlic.com/~lynn/2000d.html#50 Navy orders supercomputer
http://www.garlic.com/~lynn/2000d.html#51 Navy orders supercomputer
http://www.garlic.com/~lynn/2001d.html#48 VTOC position
http://www.garlic.com/~lynn/2001h.html#12 checking some myths.
http://www.garlic.com/~lynn/2001.html#17 IBM 1142 reader/punch (Re: First video terminal?)
http://www.garlic.com/~lynn/2001k.html#37 Is anybody out there still writting BAL 370.
http://www.garlic.com/~lynn/2001k.html#54 DEC midnight requisition system
http://www.garlic.com/~lynn/2001l.html#39 is this correct ? OS/360 became MVS and MVS >> OS/390
http://www.garlic.com/~lynn/2001l.html#42 is this correct ? OS/360 became MVS and MVS >> OS/390
http://www.garlic.com/~lynn/2002b.html#24 Infiniband's impact was Re: Intel's 64-bit strategy
http://www.garlic.com/~lynn/2002c.html#45 cp/67 addenda (cross-post warning)
http://www.garlic.com/~lynn/2002c.html#51 cp/67 addenda (cross-post warning)
http://www.garlic.com/~lynn/2002d.html#30 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2002g.html#1 WATFOR's Silver Anniversary
http://www.garlic.com/~lynn/2002l.html#29 Do any architectures use instruction count instead of timer
http://www.garlic.com/~lynn/2002m.html#3 The problem with installable operating systems
http://www.garlic.com/~lynn/2003b.html#44 filesystem structure, was tape format (long post)
http://www.garlic.com/~lynn/2003c.html#51 HASP assembly: What the heck is an MVT ABEND 422?
http://www.garlic.com/~lynn/2003c.html#53 HASP assembly: What the heck is an MVT ABEND 422?
http://www.garlic.com/~lynn/2003j.html#38 Virtual Cleaning Cartridge
http://www.garlic.com/~lynn/2003k.html#49 S/360 IPL from 7 track tape
http://www.garlic.com/~lynn/2004b.html#53 origin of the UNIX dd command
http://www.garlic.com/~lynn/2004c.html#59 real multi-tasking, multi-programming
http://www.garlic.com/~lynn/2004.html#35 40th anniversary of IBM System/360 on 7 Apr 2004
http://www.garlic.com/~lynn/2004k.html#41 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2004l.html#29 FW: Looking for Disk Calc program/Exec
http://www.garlic.com/~lynn/2005b.html#30 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005b.html#35 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005b.html#41 [Lit.] Buffer overruns

IBM 360 channel assignments

From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: 7 May 2005 06:30:45 -0700
Subject: Re: IBM 360 channel assignments

Rob Warnock wrote:

The RCA Spectra-70 byte multiplexor channels provided a
small-but-useful addition that added a bit of the block multiplexor
functionality. A byte mux device could burst for a *few* bytes in a
row (max 4, IIRC) for better performance than a standard byte
mux. The device had to be designed to know about the extra wire on
the bus/tag interface that requested this function, whose name
was...

for 3380 drives, they introduced data streaming. selector & byte
multiplexor had bus&tag synchronous hand-shake on every byte
... that limited normal stuff to about 200ft and something like 2301
drum (over 1mbyte/sec) to maybe 70-80ft.

data streaming up that to 8bytes and supported 3mbyte/sec up to 400'
(later raised to 4.5mbyte/sec).

part of the problem with escon (fiber 200mbit/sec) is that it tended
to preserve the end-to-end half-dupliex operation. escon had been
laying around pok for quite some time before it saw the
light-of-day. one of the rs/6000 engineers took the basic escon
... up'ed it to 220mbit/sec, used much cheaper optical drivers
... which was announced as serial-link adapter (SLA) for rs/6000.

we had been going to hippi and fcs meetings and when the engineer
started looking at moving sla to 800mbit ... we talked him in working
on fiber-channel standard instead. he became editor of the FCS
document. one of the issue in FCS was some number of the pok channel
engineers were participating in the standards meetings and they were
constantly trying to overlay the escon half-duplex operational model on
basically a full-duplex operation.

misc. past post mentioning data-streaming
http://www.garlic.com/~lynn/96.html#5 360 "channels" and "multiplexers"?
http://www.garlic.com/~lynn/2000b.html#38 How to learn assembler language for OS/390 ?
http://www.garlic.com/~lynn/2000c.html#75 Does the word "mainframe" still have a meaning?>
http://www.garlic.com/~lynn/2001b.html#59 Disks size growing while disk count shrinking = bad performance
http://www.garlic.com/~lynn/2001h.html#28 checking some myths.
http://www.garlic.com/~lynn/2001m.html#19 3270 protocol
http://www.garlic.com/~lynn/2002e.html#7 Bus & Tag, possible length/distance?
http://www.garlic.com/~lynn/2002f.html#7 Blade architectures
http://www.garlic.com/~lynn/2002g.html#33 ESCON Distance Limitations - Why ?
http://www.garlic.com/~lynn/2002h.html#16 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002i.html#0 Where did text file line ending characters begin?
http://www.garlic.com/~lynn/2002l.html#71 Faster seeks (was Re: Do any architectures use instruction
http://www.garlic.com/~lynn/2002m.html#73 VLSI and "the real world"
http://www.garlic.com/~lynn/2003h.html#15 Mainframe Tape Drive Usage Metrics
http://www.garlic.com/~lynn/2004d.html#65 System/360 40 years old today
http://www.garlic.com/~lynn/2004l.html#40 "Perfect" or "Provable" security both crypto and non-crypto?
http://www.garlic.com/~lynn/2004n.html#45 Shipwrecks

keysigning: identity checks

From: lynn@garlic.com
Newsgroups: comp.security.pgp.discuss
Date: 7 May 2005 07:56:53 -0700
Subject: Re: keysigning: identity checks

Richard Johnson wrote:

Indeed.  Don't lose sight of the fact that the transport mechanism has
nothing to do with the validity of key->person mapping.
Making the email address part of the identity is improper.  Email is a
transport mechanism only, not an identity.

typically signing ... within 3-factor authentication model
http://www.garlic.com/~lynn/subintegrity.html#3factor

• something you have
• something you know
• something you are

amounts to something you have authentication ... that the
originating party has access to and use of the private key ... that is
used for signing ... and the corresponding public key can be use to
verify.

authentication doesn't require identification ... for instance ... i
could supply a public key at the same time i apply for ISP (& email)
account. the public key can be used with any of my digital signatures
to indicate that subsequent communication is associated with the same
entity that opened the email account. in that sense ... a sequence of
emails all signed with the same private key (and verified with the
same public key) may be assumed to have originated from the same
entity (based on something you have authentication ... and
regardless of the originating email address).

another example is the whole SSL domain name certificate scenario. The
current scenario has the certificate applicant supplying a bunch of
identification information. The certification authority then takes
that identification and attempts to match it up with the
identification material on file with the authoritative agency
responsible for domain name ownership (the domain name
infrastructure), which is a costly, complex, and error-prone process.
http://www.garlic.com/~lynn/subpubkey.html#sslcert

somewhat from the certification authority industry is proposal that
when somebody applsies for a domain name, they register a public key
at the same time. any future communication is digitally signed by the
domain name owner, and the domain name infrastructure can verify the
digital signature with the onfile public key. There is no sense of
requiring "identification" of the domain name owner ... just the sense
that the person communicating is the same person that opened the
domain name account (authentication).

For ssl domain name certificate application, the domain name owner
just digitally signs the application. the certification authority now
just retrieves the on-file public key ... aka certificate-less
operation
http://www.garlic.com/~lynn/subpubkey.html#certless

and verifies the digital signature on the application. This converts a
costly, complex, and error-prone identification process into a much
cheaper, simpler, and reliable authentication process.

Exceptions at basic block boundaries

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Exceptions at basic block boundaries
Newsgroups: comp.arch
Date: Sat, 07 May 2005 10:18:20 -0600

"Eric P." writes:

Really? And all these years I thought it was. Live and learn.
What's a Storage Key? Is there a table of per-frame words describing
the state of each frame which includes the Access and Dirty flags
that is managed by the MMU?

storage key is from original 360 .... could have store &/or fetch
protection as optional feature. each 2k area of storage could have a
storage key (as part of optional storage key feature). a storage
key could have value 0-15 (4bits) and the currently running psw
could have key value. for non-zero psw keys ... store operations
had to have corresponding storage key value set. optional fetch
proectio feature was a 5th bit in the storage key ... turning on
the fetch protecture feature (same rules as store protection).

360/67 then had the reference and change bits in the storage key.
to check the value of the reference &/or change bits ... you had
to use the storage key isntruction.

random past storage key postings
http://www.garlic.com/~lynn/93.html#25 MTS & LLMPS?
http://www.garlic.com/~lynn/2000e.html#57 Why not an IBM zSeries workstation?
http://www.garlic.com/~lynn/2000f.html#69 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2001c.html#30 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001g.html#65 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2002m.html#46 Encryption algorithm for stored data
http://www.garlic.com/~lynn/2003d.html#18 Efficent Digital Signature Schemes
http://www.garlic.com/~lynn/2003.html#13 FlexEs and IVSK instruction
http://www.garlic.com/~lynn/2003m.html#15 IEFBR14 Problems
http://www.garlic.com/~lynn/2004m.html#4 REVIEW: "Biometrics for Network Security", Paul Reid
http://www.garlic.com/~lynn/2004p.html#8 vm/370 smp support and shared segment protection hack
http://www.garlic.com/~lynn/2004p.html#58 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2005.html#6 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005b.html#25 360POO
http://www.garlic.com/~lynn/2005c.html#18 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005f.html#45 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005f.html#46 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005g.html#32 Maximum RAM and ROM for smartcards

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

Exceptions at basic block boundaries

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Exceptions at basic block boundaries
Newsgroups: comp.arch,alt.folklore.computers
Date: Sat, 07 May 2005 12:54:33 -0600

"Eric P." writes:

Actually I don't think it must do any more work than it already has to.
In other words, from what I can see, moving the flags wouldn't save
the OS any significant work.

With Global Working Set Management (like Linux) when a frame
gets recycled the OS has to chase down all the PTE references
and patch them. So it can pick up the state flags then.

With Local Working Set Management (like VMS & WNT) as a virtual
page falls out of the works set list, the OS propagates the
Accessed and Dirty flags from the PTE into the frame state descriptor
and decrements the reference count. When the reference count
goes to zero, the frame goes to either the modify or valid list.

So if there is a benefit to moving the flags to a central table,
it looks like it would have to be for other reasons.

360/67 & 370 used shared segments for sharing of pages ...
i.e. implicit only one PTE per page frame (multiple different address
spaces or segment tables ... and pointers to the same page table
... collection of PTEs).

360/67 only had 1mbyte segments (256 pages) and originally CMS only
had something like 3-4 pages set up for shareable. So cp67 did have a
hack for shared-pages that involved (a small number of) multiple
different PTEs in different address spaces pointing to the same real
page.

370 came out with options ... 2kpages and 4kpages and 64k (16 page)
segments and 1mbyte (256 page) segments. CMS was restructure to have a
single shared segment. The base 370 architecture also defined a
feature where the segment table pointer (to the page table) could have
a read-only flag ... so you could have store-protect on a
shared-segment basis (similear but different to the 360 real memory
storage protect based storage keys).

note that in the original 370 announcement, there wasn't mention of
virtual memory support ... which was a later enhancement. the low &
mid-range 370s ... it just required microcode change. But for the
370/155 & 370/165 it required significant hardware retrofit to the
machines already in customer shops. At one point ... the 165 engineers
raised an issue that they could ship basic virtual memory hardware
support six months earlier if they could drop some of the stuff in the
define virtual memory architecture (like shared segment protection).
A business decision was finally made to drop the extra features from
all 370 virtual memory implementations ... in order to have six month
earlier announce & ship of virtual memory.

This caused quite a hardship for the CMS shared segment (across
different virtual address space) protection ... and they finally
had to come up with a hack kluge.

i had originally came up with global LRU page replacement algorithm in the
60s as an undergraduate and added it to cp67 (and it was picked up and
shipped in the standard product). this was about the same time as the
ACM article appeared on working sets and local page replacement
algorithm.
http://www.garlic.com/~lynn/subtopic.html#wsclock

Over ten years later ... somebody was trying to get a stanford phd on
global page replacement algorithm and there was quite a bit of
opposition from the parties associated with local page replacement. I
was asked if i could contribute.

It turns out that the grenoble science center had an ACM paper
published in the early 70s on modifications they made to cp67
for local page replacements ... and performance measurements they
ran on cp67 machine they ran at grenoble (360/67 with 1mbyte real
storage, 154 4k "pageable pages" after fixed kernel requiremetns);
30-35 cms users with mixed-mode workload,

About the same time, cambridge science center
http://www.garlic.com/~lynn/subtopic.html#545tech

was running similar workload with 75-80 users on a 768k real storage
360/67 (104 4k pageable pages after fixed storage requirements) using
a version of cp67 running my local page replacement algorithm ... and
having about the same response and thruput as the grenoble machine
(twice as many users and 1/3rd the real storage).

I provided old plots and papers ... and the person eventually got
their phd.

misc. past posts mentioning shared segment protection:
http://www.garlic.com/~lynn/2004p.html#8 vm/370 smp support and shared segment protection hack
http://www.garlic.com/~lynn/2004p.html#9 vm/370 smp support and shared segment protection hack
http://www.garlic.com/~lynn/2004p.html#10 vm/370 smp support and shared segment protection hack
http://www.garlic.com/~lynn/2004p.html#14 vm/370 smp support and shared segment protection hack
http://www.garlic.com/~lynn/2004q.html#37 A Glimpse into PC Development Philosophy
http://www.garlic.com/~lynn/2005.html#3 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005c.html#18 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005c.html#20 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005d.html#61 Virtual Machine Hardware
http://www.garlic.com/~lynn/2005f.html#45 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005f.html#46 Moving assembler programs above the line

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

Exceptions at basic block boundaries

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Exceptions at basic block boundaries
Newsgroups: comp.arch,alt.folklore.computers
Date: Sat, 07 May 2005 13:46:11 -0600

"Eric P." writes:

370 has a inverted page table so it would have no option.  In a
hierarcical table, since the PTE contains the frame number you could
always retreive those bits as though they were in the PTE.  So
existing designs would most likely contnue to work.

360/67 and 370 had hirrarchical tables ... slightly different ... enuf
to make virtual machine implementations of the different tables
something of a pain.

370 architecture had Segment table with segment table entries that
pointed to page tables. architecture provided option support for
selection of either 2k or 4k pages and either 64k segments (16 pages)
or 1mbyte segments (256 pages). base 370 architecture allowed for
implementation of either "STO" associative TLB (i.e. the physical
address of the segment table origin was used to tag entries in the
TLB, effectively address space associative) or "PTO" associative TLB
(i.e. the physical address of the page table origina was used to tag
the entries in the TLB). In STO-associative, shared pages (same PTE
belonging to shared segment/pagetable, but different address spaces)
would have different entries in the TLB. In PTO-associative
implementation, there would be a single TLB entry for shared PTEs.

I believe all 370s implemented STO-associative ... even tho the
architecture allowed for PTO-associative.

low-end & mid-range 370s tended to have small TLB that had all
entries flushed every time address space (segment table pointer) was
changed ... so there was no concept of having concurrent entries for
same shared PTE for different address spaces.

370 165/168 had 128 entry TLB and a 7-entry "STO-stack" ... and each
TLB entry had a 3-bit identifier that corresponded with an entry in
the STO-stack. Changing address space (loading new STO value in CR1)
would check to see if the STO value was already in the STO-stack
... if so, it just srarted using that value. If not, one of the
entries in the STO-stack would be selected for replacement ... and all
of the associated TLB-entries would be flushed.

One of the problems with the introduction of the 168-3 ... was they
doubled the cache from 32kbytes to 64kbytes ... and used the 2k bit as
one of the address bits for indexing cache entries. When in 2k virtual
page mode ... the 168-3 ran with only 32k cache active (only using
full 64k cache when in virtual 4k page mode). There was a customer
that had mix-mode workload with VS1 running under vm/370 with cms and
other stuff. VS1 was a 2k virtual page operating system ... and vm/370
had to provide its virtual machine operation with 2k virtual page
shadow page tables. The customer upgraded from 168-1 to 168-3 doubling
machine cache ... and thruput got much worse. In theory running with
half 168-3 cache should have been no worse than 168-1 ... however,
every time vm/370 switched between virtual page mode (2k->4k or
4k->2k), the hardware cache had completely flush all entries
because the mapping process changed.

801/risc defined inverted page tables
http://www.garlic.com/~lynn/subtopic.html#801

i've made the assertion that 801/risc was in some sense a reaction
to the failure of FS
http://www.garlic.com/~lynn/submain.html#futuresys

with the swing to the complete opposite end of hardware complexity ...
instead of maximum hardware complexity ... have maximum hardware
simplicity ... and move a lot of issues into software, pushing the
envelope on compiler (pl.8) and operating system (CPr) technology.

in the late 70s ... there was a push to migrate the scores of
different internal corporate microprocessors to an 801/risc
architecture. for instance all of the low-end and mid-range 360s and
370s had been a variety of microprocessor engines that were coded to
emulate 360/370 (avg. about ten native microprocessor instructions per
360/370 instruction). the follow-on to the 4341 mid-range processor
was nominally going to be a native mode 801/risc processor. the issue
was that silicon state of the art was getting to the point where you
could just about do the full 370 in silicon chip ... rather than
having to emulate it. i helped write the drafts that argued having the
4341 followon be a native silicon implementation (with much better
price/performance) than a native 801/risc with 370 "microcode"
emulation (at a 10:1 penalty).

in the early 80s, research had a joint project with office products
division to use an 801/risc chip; ROMP with CPr (implemented in PL.8)
as a displaywriter followon. one of the CPr (pl.8) issues was loads of
stuff had been moved from hardware to software ... there were inverted
page tables, no hardware protection domains ... any inline software
could execute every instruction and access every machine facility.
Things like protection and security were issues provided and supported
by correct compiler generated code and correct operating system
loading.

Instead of segment and page tables, there were 16 segment registers
that could be loaded with 12bit "segment" identifier. The top four
bits of a 32bit virtual address was used to select a segment register
which pulled a 12bit segment identifier. The 12bit segment identifier
plus the remaining 28bit virtual address was used to index TLB
entry. In 370 terms, it was a PTO-associated TLB with 256mbyte
segments ... because each TLB entry was associated with a specific
segment value (as opposed to a virtual address space value). Write-ups
even referred to the ROMP chip having 40bit virtual addressing
... from TLBs being tagged with the 12bit segment associative value
(combined with the 28bit virtual segment displacement value). In
theory, inline application code would dynamical change segment
register associative values ... as easily as more familiar code could
change address pointers in general purpose registers.

The displaywriter project was killed, and the group decided on
retargeting the platform to unix workstation market (PC/RT).  One of
the things that had to be added back in was hardware support for
protection domains.  The company that had been hired to do the
AT&T unix port for ibm/pc (pc/ix) was hired to do a similar port
for "AIX". However, you had all these pl.8 programmers ... so instead
of having the AIX port done to the bare hardware ... an abstract
virtual machine was defined for the AIX port ... and the pl.8
programmers were put to work implementing the VRM ... which talked to
the real hardware and provided the abstract virtual machine
interface. There was some claim that this could be done faster and
easier than having the outside company doing an ATT unix port to the
native hardware.

The counter was when the palo alto science center did a BSD port to
the native ROMP hardware with less resources than was used in either
the ATT "AIX" effort to VRM and/or the VRM effort.

The follow-on chipset for ROMP was RIOS/power. it still had inverted
tables, 16 segment tables registers ... but they had doubled the
segment-associative number of bits from 12bits to 24bits ... as a
result, you may trip across early descriptions of power referring to
its 52bit virtual address capability.

a couple recent posts that talk about the transition from free
software to priced/licensed software ... and some impact of FS on the
transition.
http://www.garlic.com/~lynn/2005g.html#51
http://www.garlic.com/~lynn/2005g.html#53
http://www.garlic.com/~lynn/2005g.html#54
http://www.garlic.com/~lynn/2005g.html#57

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

practical applications for synchronous and asynchronous communication

From: lynn@garlic.com
Newsgroups: comp.os.misc, comp.arch, comp.protocols.tcp-ip, alt.folklore.computers
Date: 7 May 2005 16:45:57 -0700
Subject: Re: practical applications for synchronous and asynchronous communication

Rob Warnock wrote:

Except that when you lose a token due to bit errors, Token Ring
becomes async, too!! [Something the TR proponents conveniently
forgot to mention during those heated debates...]

pc/rt had done a custom 4mbit t/r card for its 16bit bus. but the
rs/6000 was forced to use the ps2 microchannel 16mbit t/r card (32bit
bus) ... rather than doing its own. One of the issues with the ps2
microchannel 16mbit t/r card ... was that the per-card thruput was
actually lower than the custom pc/rt 4mbit t/r card (ps2 16mbit t/r
design point was hundreds of PS2s sharing the same 16mbit t/r).

my wife had co-authored and presented a response to a gov. secure
campus-like network RFI ... in it, she had postulated some of the
fundamentals of 3-tier architecture. We then expanded on that in
conjunction with ethernet and other technology and started presenting
it at customer executive meetings.

we got hammered from the SAA and T/R crowd .... who possibly could be
characterized as trying to put the client/server genie back in the
bottle ... and we were out pitching 3-layer architecture, middleware,
etc.
http://www.garlic.com/~lynn/subnetwork.html#3tier

one of the things that the t/r group were claiming was enet typically
degraded quickly to less than 1mbit thruput. the assumptions for this
appeared to be an early 3mbit enet technology before there was listen
before transmit. In this timeframe there was an ACM sigcomm article
that measured in most typical enet deployments ... it degraded to
8.5mbit effective thruput under worst case scenario ... all stations
in tight low-level device driver loop constantly transmitting minimum
sized packets. By comparison, it was rare to see 16mbit t/r getting
better than 8mbit effective thruput ... and its nominal message
latency was typically much greater than the nominal enet latency.

disclaimer ... my wife is named as co-inventor on one of the early
token passing patents from the 70s.

some past postings on the enet & t/r issues ...
http://www.garlic.com/~lynn/2000f.html#38 Ethernet efficiency (was Re: Ms employees begging for food)
http://www.garlic.com/~lynn/2002b.html#4 Microcode? (& index searching)
http://www.garlic.com/~lynn/2002q.html#40 ibm time machine in new york times?
http://www.garlic.com/~lynn/2002q.html#41 ibm time machine in new york times?

some old 3-tier postings:
http://www.garlic.com/~lynn/96.html#16 middle layer
http://www.garlic.com/~lynn/96.html#17 middle layer
http://www.garlic.com/~lynn/98.html#50 Edsger Dijkstra: the blackest week of his professional life
http://www.garlic.com/~lynn/99.html#123 Speaking of USB ( was Re: ASR 33 Typing Element)
http://www.garlic.com/~lynn/99.html#124 Speaking of USB ( was Re: ASR 33 Typing Element)
http://www.garlic.com/~lynn/99.html#202 Middleware - where did that come from?

Today's mainframe--anything to new?

From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: 8 May 2005 07:57:08 -0700
Subject: Re: Today's mainframe--anything to new?

jsav...@ecn.ab.ca wrote:

No, probably that stuff is done from a keyboard and display, using
whatever a z/990 uses for a BIOS. After all, it uses custom
microchips that handle the 370 instruction set, not SSI, so there's
nowhere to *connect* the front panel lights.

FE service people had requirements that they could bootstrap diagnosis
starting with probes and scope. the 3081 starting with TCMs where
there wasn't anyplace to put probes ... and so there was a service
processor that had manufactured probes into all sorts of places
... and the serice processor could be probed (and replaced).

the 3090 started out with going to have a 4331 running a custom vm370
release 6 ... as the service processor (possible to scope the 4331).
before the 3090 shipped, this was eventually upgraded to a pair of
4361s as service processors (still using a highly modified vm370
release 6).

i provided some amount of code enhancements for the service processor
code. the group supporting the highly modified vm370 was also one of
the internal sites that picked on my debug analysis tool for supporting
their operation (it never got released to customers ... but majority of
the internal locations started using it ... including PSRs supporting
customers).
http://www.garlic.com/~lynn/submain.html#dumprx

3090 also introduced extended store. the constant march of ambundance
of electronic memory was continuing. i had previously made comparison
between 360/67 and 3081 and relative system disk performance declining
by a factor of ten times. along the way, the abundance of electronic
memory was being used to compensate for deficiency in disk performance
(aka various kinds of caching). the problem with 3090 era was that you
could get a lot more electronic memory than you could physically
package within normal memory latency. as a result, they went to
another memory level ... that was software managed as 4k
pages. basically they used the paging metaphor for software to stage
data between regular memory and extended store in 4k page
operations. the extended store had a special high-speed and wide bus.

later when kingston was trying to craft hippi support on 3090 ... the
standard 3090 i/o interfaces couldn't handle the rate ... so they cut
into the side of the extended store bus to do the hippi attachment.

in the 3090 time-frame ... amdahl had come up with hypervisor support
... basically an abbreviated virtual machine with dedicated real
storage allcoation. you could run vm370 in normal operation providing
normal virtual machine ... and mvs in the hardware hypervisor with
almost no virtual machine degradation. IBM responded with 3090 PR/SM
which has since evolved into current day LPARS (logical partitions).

we had been attending hippi, fcs, and sci meetings (hippi basically by
lanl trying to standardize the cray 800mbit/sec copper channel, fcs,
by llnl trying to standardize a 1gbit fiber version of some serial
technology they had, sci was some other fiber stuff out of SLAC).

ibm mainframe had done something with 200mbit escon ... which had been
laying around pok since the late 70s. one of the rs/6000 engineers had
taken escon ... increased it by about 10percent to 220mbit, redid it
with much cheaper optical drives ... (sla, seial link adapter). escon
.. while pairs of unidirectional fiber ...  preserved the half-duplex
paradigm from the bus&tag cables. The rs/6000 engineer then
started work on 800mbit SLA ... but we eventually manage to talk him
into moving to FCS ... and he became the editor of the FCS standards
document. There was some amount of contention in FCS meeting from POK
channel engineers attempting to overlay the half-duplex paradigm (from
escon and bus&tag cable) on the fundamentally full-duplex FCS.

the current generation of that is ficon ...
http://www-1.ibm.com/servers/eserver/zseries/connectivity/ficon_recov...

note in the above reference ... we had coined the terms and defined
disaster survivability and geographic survivability for ha/cmp ... as
contrast to simple disaster/recovery
http://www.garlic.com/~lynn/subtopic.html#hacmp

another ficon description
http://www.cisco.com/en/US/netsol/ns512/networking_solutions_white_pa...

... aka ficon is the upper layer protocols on top of FCS to turn a
native FCS full-duplex paradigm ... into the old-style bus&tag
half-duplex paradigm.

misc. past extended store posts
http://www.garlic.com/~lynn/95.html#15 multilevel store
http://www.garlic.com/~lynn/2001m.html#25 ESCON Data Transfer Rate
http://www.garlic.com/~lynn/2001m.html#53 TSS/360
http://www.garlic.com/~lynn/2002c.html#53 VAX, M68K complex instructions (was Re: Did Intel Bite Off More Than  It Can Chew?)
http://www.garlic.com/~lynn/2002e.html#26 Crazy idea: has it been done?
http://www.garlic.com/~lynn/2002e.html#32 What goes into a 3090?
http://www.garlic.com/~lynn/2003j.html#2 Fix the shuttle or fly it unmanned
http://www.garlic.com/~lynn/2003n.html#52 Call-gate-like mechanism
http://www.garlic.com/~lynn/2003p.html#41 comp.arch classic: the 10-bit byte
http://www.garlic.com/~lynn/2003p.html#46 comp.arch classic: the 10-bit byte
http://www.garlic.com/~lynn/2005.html#17 Amusing acronym

misc. past pr/sm, lpar posts
http://www.garlic.com/~lynn/98.html#45 Why can't more CPUs virtualize themselves?
http://www.garlic.com/~lynn/98.html#57 Reliability and SMPs
http://www.garlic.com/~lynn/99.html#191 Merced Processor Support at it again
http://www.garlic.com/~lynn/2000b.html#50 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000b.html#51 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000b.html#62 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000c.html#8 IBM Linux
http://www.garlic.com/~lynn/2000c.html#50 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#76 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000.html#8 Computer of the century
http://www.garlic.com/~lynn/2000.html#63 Mainframe operating systems
http://www.garlic.com/~lynn/2001e.html#5 SIMTICS
http://www.garlic.com/~lynn/2001e.html#61 Estimate JCL overhead
http://www.garlic.com/~lynn/2001f.html#17 Accounting systems ... still in use? (Do we still share?)
http://www.garlic.com/~lynn/2001f.html#23 MERT Operating System & Microkernels
http://www.garlic.com/~lynn/2001h.html#2 Alpha: an invitation to communicate
http://www.garlic.com/~lynn/2001h.html#33 D
http://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
http://www.garlic.com/~lynn/2002d.html#31 2 questions: diag 68 and calling convention
http://www.garlic.com/~lynn/2002e.html#25 Crazy idea: has it been done?
http://www.garlic.com/~lynn/2002e.html#75 Computers in Science Fiction
http://www.garlic.com/~lynn/2002f.html#57 IBM competes with Sun w/new Chips
http://www.garlic.com/~lynn/2002n.html#6 Tweaking old computers?
http://www.garlic.com/~lynn/2002n.html#27 why does wait state exist?
http://www.garlic.com/~lynn/2002n.html#28 why does wait state exist?
http://www.garlic.com/~lynn/2002o.html#0 Home mainframes
http://www.garlic.com/~lynn/2002o.html#15 Home mainframes
http://www.garlic.com/~lynn/2002o.html#18 Everything you wanted to know about z900 from IBM
http://www.garlic.com/~lynn/2002p.html#4 Running z/VM 4.3 in LPAR & guest v-r or v=f
http://www.garlic.com/~lynn/2002p.html#40 Linux paging
http://www.garlic.com/~lynn/2002p.html#44 Linux paging
http://www.garlic.com/~lynn/2002p.html#45 Linux paging
http://www.garlic.com/~lynn/2002p.html#46 Linux paging
http://www.garlic.com/~lynn/2002p.html#48 Linux paging
http://www.garlic.com/~lynn/2002p.html#54 Newbie: Two quesions about mainframes
http://www.garlic.com/~lynn/2002p.html#55 Running z/VM 4.3 in LPAR & guest v-r or v=f
http://www.garlic.com/~lynn/2002q.html#26 LISTSERV Discussion List For USS Questions?
http://www.garlic.com/~lynn/2003f.html#56 ECPS:VM DISPx instructions
http://www.garlic.com/~lynn/2003.html#9 Mainframe System Programmer/Administrator market demand?
http://www.garlic.com/~lynn/2003.html#14 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#15 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#56 Wild hardware idea
http://www.garlic.com/~lynn/2003k.html#9 What is timesharing, anyway?
http://www.garlic.com/~lynn/2003l.html#12 Why are there few viruses for UNIX/Linux systems?
http://www.garlic.com/~lynn/2003m.html#37 S/360 undocumented instructions?
http://www.garlic.com/~lynn/2003n.html#13 CPUs with microcode ?
http://www.garlic.com/~lynn/2003n.html#29 Architect Mainframe system - books/guidenance
http://www.garlic.com/~lynn/2003o.html#52 Virtual Machine Concept
http://www.garlic.com/~lynn/2004b.html#58 Oldest running code
http://www.garlic.com/~lynn/2004c.html#4 OS Partitioning and security
http://www.garlic.com/~lynn/2004c.html#5 PSW Sampling
http://www.garlic.com/~lynn/2004d.html#6 Memory Affinity
http://www.garlic.com/~lynn/2004e.html#26 The attack of the killer mainframes
http://www.garlic.com/~lynn/2004e.html#28 The attack of the killer mainframes
http://www.garlic.com/~lynn/2004g.html#15 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004k.html#37 Wars against bad things
http://www.garlic.com/~lynn/2004k.html#43 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2004m.html#41 EAL5
http://www.garlic.com/~lynn/2004m.html#49 EAL5
http://www.garlic.com/~lynn/2004n.html#10 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004o.html#13 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004p.html#37 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2004q.html#18 PR/SM Dynamic Time Slice calculation
http://www.garlic.com/~lynn/2004q.html#72 IUCV in VM/CMS
http://www.garlic.com/~lynn/2004q.html#76 Athlon cache question
http://www.garlic.com/~lynn/2005b.html#5 Relocating application architecture and compiler support
http://www.garlic.com/~lynn/2005c.html#56 intel's Vanderpool and virtualization in general
http://www.garlic.com/~lynn/2005d.html#59 Misuse of word "microcode"
http://www.garlic.com/~lynn/2005d.html#70 Virtual Machine Hardware
http://www.garlic.com/~lynn/2005d.html#74 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005f.html#45 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005f.html#59 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005.html#6 [Lit.] Buffer overruns

some number of past escon, ficon, fcs, hippi. and/or sci posts
http://www.garlic.com/~lynn/94.html#2 Schedulers
http://www.garlic.com/~lynn/94.html#16 Dual-ported disks?
http://www.garlic.com/~lynn/94.html#17 Dual-ported disks?
http://www.garlic.com/~lynn/94.html#54 How Do the Old Mainframes
http://www.garlic.com/~lynn/95.html#13 SSA
http://www.garlic.com/~lynn/96.html#5 360 "channels" and "multiplexers"?
http://www.garlic.com/~lynn/96.html#8 Why Do Mainframes Exist ???
http://www.garlic.com/~lynn/96.html#15 tcp/ip
http://www.garlic.com/~lynn/96.html#25 SGI O2 and Origin system announcements
http://www.garlic.com/~lynn/97.html#5 360/44 (was Re: IBM 1130 (was Re: IBM 7090--used for business or
http://www.garlic.com/~lynn/98.html#30 Drive letters
http://www.garlic.com/~lynn/98.html#40 Comparison Cluster vs SMP?
http://www.garlic.com/~lynn/98.html#49 Edsger Dijkstra: the blackest week of his professional life
http://www.garlic.com/~lynn/98.html#58 Reliability and SMPs
http://www.garlic.com/~lynn/99.html#54 Fault Tolerance
http://www.garlic.com/~lynn/99.html#217 AADS/X9.59 demo & standards at BAI (world-wide retail banking) show
http://www.garlic.com/~lynn/99.html#224 X9.59/AADS announcement at BAI this week
http://www.garlic.com/~lynn/2000c.html#22 Cache coherence [was Re: TF-1]
http://www.garlic.com/~lynn/2000c.html#56 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#59 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#68 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#74 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000d.html#14 FW: RS6000 vs IBM Mainframe
http://www.garlic.com/~lynn/2000d.html#38 S/360 development burnout?
http://www.garlic.com/~lynn/2000e.html#52 Why not an IBM zSeries workstation?
http://www.garlic.com/~lynn/2000f.html#28 OT?
http://www.garlic.com/~lynn/2000f.html#31 OT?
http://www.garlic.com/~lynn/2000f.html#72 SET; was Re: Why trust root CAs ?
http://www.garlic.com/~lynn/2000.html#1 Computer of the century
http://www.garlic.com/~lynn/2001b.html#23 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
http://www.garlic.com/~lynn/2001b.html#39 John Mashey's greatest hits
http://www.garlic.com/~lynn/2001b.html#56 Why SMP at all anymore?
http://www.garlic.com/~lynn/2001b.html#85 what makes a cpu fast
http://www.garlic.com/~lynn/2001c.html#69 Wheeler and Wheeler
http://www.garlic.com/~lynn/2001d.html#32 Imitation...
http://www.garlic.com/~lynn/2001d.html#63 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001d.html#65 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001e.html#22 High Level Language Systems was Re: computer books/authors (Re: FA:
http://www.garlic.com/~lynn/2001f.html#11 Climate, US, Japan & supers query
http://www.garlic.com/~lynn/2001f.html#66 commodity storage servers
http://www.garlic.com/~lynn/2001g.html#43 The Alpha/IA64 Hybrid
http://www.garlic.com/~lynn/2001h.html#57 Whom Do Programmers Admire Now???
http://www.garlic.com/~lynn/2001.html#12 Small IBM shops
http://www.garlic.com/~lynn/2001.html#18 Disk caching and file systems. Disk history...people forget
http://www.garlic.com/~lynn/2001.html#21 Disk caching and file systems. Disk history...people forget
http://www.garlic.com/~lynn/2001.html#46 Small IBM shops
http://www.garlic.com/~lynn/2001.html#66 what is interrupt mask register?
http://www.garlic.com/~lynn/2001i.html#6 YKYGOW...
http://www.garlic.com/~lynn/2001j.html#9 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#12 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001j.html#17 I hate Compaq
http://www.garlic.com/~lynn/2001j.html#23 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001k.html#5 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001k.html#22 ESCON Channel Limits
http://www.garlic.com/~lynn/2001k.html#24 HP Compaq merger, here we go again.
http://www.garlic.com/~lynn/2001k.html#73 Expanded Storage?
http://www.garlic.com/~lynn/2001k.html#74 Expanded Storage?
http://www.garlic.com/~lynn/2001l.html#14 mainframe question
http://www.garlic.com/~lynn/2001l.html#16 Disappointed
http://www.garlic.com/~lynn/2001m.html#25 ESCON Data Transfer Rate
http://www.garlic.com/~lynn/2001m.html#56 Contiguous file system
http://www.garlic.com/~lynn/2001n.html#54 The demise of compaq
http://www.garlic.com/~lynn/2002b.html#29 windows XP and HAL: The CP/M way still works in 2002
http://www.garlic.com/~lynn/2002c.html#13 OS Workloads : Interactive etc
http://www.garlic.com/~lynn/2002c.html#28 OS Workloads : Interactive etc
http://www.garlic.com/~lynn/2002c.html#53 VAX, M68K complex instructions (was Re: Did Intel Bite Off More Than  It Can Chew?)
http://www.garlic.com/~lynn/2002d.html#4 IBM Mainframe at home
http://www.garlic.com/~lynn/2002d.html#7 IBM Mainframe at home
http://www.garlic.com/~lynn/2002e.html#5 What goes into a 3090?
http://www.garlic.com/~lynn/2002e.html#7 Bus & Tag, possible length/distance?
http://www.garlic.com/~lynn/2002e.html#26 Crazy idea: has it been done?
http://www.garlic.com/~lynn/2002e.html#31 Hardest Mistake in Comp Arch to Fix
http://www.garlic.com/~lynn/2002e.html#32 What goes into a 3090?
http://www.garlic.com/~lynn/2002e.html#46 What goes into a 3090?
http://www.garlic.com/~lynn/2002f.html#6 Blade architectures
http://www.garlic.com/~lynn/2002f.html#7 Blade architectures
http://www.garlic.com/~lynn/2002f.html#11 Blade architectures
http://www.garlic.com/~lynn/2002f.html#60 Mainframes and "mini-computers"
http://www.garlic.com/~lynn/2002g.html#10 "Soul of a New Machine" Computer?
http://www.garlic.com/~lynn/2002g.html#33 ESCON Distance Limitations - Why ?
http://www.garlic.com/~lynn/2002g.html#51 Timecard stupidity
http://www.garlic.com/~lynn/2002g.html#80 Pipelining in the past
http://www.garlic.com/~lynn/2002h.html#78 Q: Is there any interest for vintage Byte Magazines from 1983
http://www.garlic.com/~lynn/2002.html#10 index searching
http://www.garlic.com/~lynn/2002i.html#30 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#53 wrt code first, document later
http://www.garlic.com/~lynn/2002i.html#83 HONE
http://www.garlic.com/~lynn/2002j.html#30 Weird
http://www.garlic.com/~lynn/2002j.html#45 M$ SMP and old time IBM's LCMP
http://www.garlic.com/~lynn/2002j.html#65 Total Computing Power
http://www.garlic.com/~lynn/2002j.html#78 Future interconnects
http://www.garlic.com/~lynn/2002k.html#1 misc. old benchmarks (4331 & 11/750)
http://www.garlic.com/~lynn/2002k.html#31 general networking is: DEC eNet: was Vnet : Unbelievable
http://www.garlic.com/~lynn/2002k.html#33 general networking is: DEC eNet: was Vnet : Unbelievable
http://www.garlic.com/~lynn/2002k.html#42 MVS 3.8J and NJE via CTC
http://www.garlic.com/~lynn/2002l.html#13 notwork
http://www.garlic.com/~lynn/2002l.html#52 Itanium2 performance data from SGI
http://www.garlic.com/~lynn/2002m.html#19 A new e-commerce security proposal
http://www.garlic.com/~lynn/2002m.html#20 A new e-commerce security proposal
http://www.garlic.com/~lynn/2002m.html#73 VLSI and "the real world"
http://www.garlic.com/~lynn/2002n.html#50 EXCP
http://www.garlic.com/~lynn/2002o.html#11 Home mainframes
http://www.garlic.com/~lynn/2002o.html#32 I found the Olsen Quote
http://www.garlic.com/~lynn/2002o.html#40 I found the Olsen Quote
http://www.garlic.com/~lynn/2002o.html#47 XML, AI, Cyc, psych, and literature
http://www.garlic.com/~lynn/2002p.html#8 Sci Fi again
http://www.garlic.com/~lynn/2002p.html#30 Sci Fi again
http://www.garlic.com/~lynn/2002q.html#6 Sci Fi again was: THIS WEEKEND: VINTAGE
http://www.garlic.com/~lynn/2002q.html#8 Sci Fi again was: THIS WEEKEND: VINTAGE
http://www.garlic.com/~lynn/2002q.html#35 HASP:
http://www.garlic.com/~lynn/2002q.html#40 ibm time machine in new york times?
http://www.garlic.com/~lynn/2003b.html#29 360/370 disk drives
http://www.garlic.com/~lynn/2003b.html#47 send/recv vs. raw RDMA
http://www.garlic.com/~lynn/2003c.html#21 Network separation using host w/multiple network interfaces
http://www.garlic.com/~lynn/2003c.html#63 Re : OT: One for the historians - 360/91
http://www.garlic.com/~lynn/2003c.html#65 Dijkstra on "The End of Computing Science"
http://www.garlic.com/~lynn/2003d.html#37 Why only 24 bits on S/360?
http://www.garlic.com/~lynn/2003d.html#54 Filesystems
http://www.garlic.com/~lynn/2003d.html#57 Another light on the map going out
http://www.garlic.com/~lynn/2003e.html#13 unix
http://www.garlic.com/~lynn/2003e.html#15 unix
http://www.garlic.com/~lynn/2003e.html#34 Use of SSL as a VPN
http://www.garlic.com/~lynn/2003e.html#46 MP cost effectiveness
http://www.garlic.com/~lynn/2003g.html#22 303x, idals, dat, disk head settle, and other rambling folklore
http://www.garlic.com/~lynn/2003g.html#24 UltraSPARC-IIIi
http://www.garlic.com/~lynn/2003g.html#27 SYSPROF and the 190 disk
http://www.garlic.com/~lynn/2003h.html#0 Escon vs Ficon Cost
http://www.garlic.com/~lynn/2003h.html#3 Calculations involing very large decimals
http://www.garlic.com/~lynn/2003.html#0 Clustering ( was Re: Interconnect speeds )
http://www.garlic.com/~lynn/2003.html#6 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#68 3745 & NCP Withdrawl?
http://www.garlic.com/~lynn/2003i.html#32 A Dark Day
http://www.garlic.com/~lynn/2003j.html#2 Fix the shuttle or fly it unmanned
http://www.garlic.com/~lynn/2003k.html#46 Slashdot: O'Reilly On The Importance Of The Mainframe Heritage
http://www.garlic.com/~lynn/2003l.html#37 Thoughts on Utility Computing?
http://www.garlic.com/~lynn/2003l.html#42 Thoughts on Utility Computing?
http://www.garlic.com/~lynn/2003m.html#20 360 Microde Floating Point Fix
http://www.garlic.com/~lynn/2003m.html#25 Microsoft Internet Patch
http://www.garlic.com/~lynn/2003o.html#54 An entirely new proprietary hardware strategy
http://www.garlic.com/~lynn/2003o.html#64 1teraflops cell processor possible?
http://www.garlic.com/~lynn/2003p.html#1 An entirely new proprietary hardware strategy
http://www.garlic.com/~lynn/2003p.html#16 Star Trek, time travel, and such
http://www.garlic.com/~lynn/2003p.html#30 Not A Survey Question
http://www.garlic.com/~lynn/2003p.html#41 comp.arch classic: the 10-bit byte
http://www.garlic.com/~lynn/2003p.html#46 comp.arch classic: the 10-bit byte
http://www.garlic.com/~lynn/2004.html#1 Saturation Design Point
http://www.garlic.com/~lynn/2004b.html#12 pointless embedded systems
http://www.garlic.com/~lynn/2004b.html#18 Seriously long term storage
http://www.garlic.com/~lynn/2004c.html#47 IBM 360 memory
http://www.garlic.com/~lynn/2004c.html#59 real multi-tasking, multi-programming
http://www.garlic.com/~lynn/2004d.html#6 Memory Affinity
http://www.garlic.com/~lynn/2004d.html#10 IBM 360 memory
http://www.garlic.com/~lynn/2004d.html#65 System/360 40 years old today
http://www.garlic.com/~lynn/2004d.html#68 bits, bytes, half-duplex, dual-simplex, etc
http://www.garlic.com/~lynn/2004d.html#75 DASD Architecture of the future
http://www.garlic.com/~lynn/2004e.html#2 Expanded Storage
http://www.garlic.com/~lynn/2004e.html#4 Expanded Storage
http://www.garlic.com/~lynn/2004e.html#33 The attack of the killer mainframes
http://www.garlic.com/~lynn/2004f.html#63 before execution does it require whole program 2 b loaded in
http://www.garlic.com/~lynn/2004g.html#35 network history (repeat, google may have gotten confused?)
http://www.garlic.com/~lynn/2004h.html#7 CCD technology
http://www.garlic.com/~lynn/2004h.html#29 BLKSIZE question
http://www.garlic.com/~lynn/2004j.html#19 Wars against bad things
http://www.garlic.com/~lynn/2004j.html#42 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2004l.html#14 Xah Lee's Unixism
http://www.garlic.com/~lynn/2004l.html#20 Is the solution FBA was Re: FW: Looking for Disk Calc
http://www.garlic.com/~lynn/2004m.html#47 IBM Open Sources Object Rexx
http://www.garlic.com/~lynn/2004m.html#53 4GHz is the glass ceiling?
http://www.garlic.com/~lynn/2004n.html#10 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#45 Shipwrecks
http://www.garlic.com/~lynn/2004n.html#52 CKD Disks?
http://www.garlic.com/~lynn/2004n.html#54 CKD Disks?
http://www.garlic.com/~lynn/2004o.html#45 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004p.html#5 History of C
http://www.garlic.com/~lynn/2004p.html#7 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004p.html#8 vm/370 smp support and shared segment protection hack
http://www.garlic.com/~lynn/2004p.html#13 Mainframe Virus ????
http://www.garlic.com/~lynn/2004p.html#29 FW: Is FICON good enough, or is it the only choice we get?
http://www.garlic.com/~lynn/2004q.html#64 Will multicore CPUs have identical cores?
http://www.garlic.com/~lynn/2005.html#17 Amusing acronym
http://www.garlic.com/~lynn/2005.html#38 something like a CTC on a PC
http://www.garlic.com/~lynn/2005.html#40 clusters vs shared-memory (was: Re: CAS and LL/SC (was Re: High Level Assembler for MVS & VM & VSE))
http://www.garlic.com/~lynn/2005.html#48 [OT?] FBI Virtual Case File is even possible?
http://www.garlic.com/~lynn/2005.html#50 something like a CTC on a PC
http://www.garlic.com/~lynn/2005.html#58 Foreign key in Oracle Sql
http://www.garlic.com/~lynn/2005c.html#3 The mid-seventies SHARE survey
http://www.garlic.com/~lynn/2005c.html#24 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005c.html#33 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005c.html#40 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005c.html#42 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005d.html#20 shared memory programming on distributed memory model?
http://www.garlic.com/~lynn/2005d.html#37 Thou shalt have no other gods before the ANSI C standard
http://www.garlic.com/~lynn/2005d.html#41 Thou shalt have no other gods before the ANSI C standard
http://www.garlic.com/~lynn/2005d.html#74 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005e.html#12 Device and channel
http://www.garlic.com/~lynn/2005e.html#13 Device and channel
http://www.garlic.com/~lynn/2005e.html#19 Device and channel
http://www.garlic.com/~lynn/2005e.html#35 Thou shalt have no other gods before the ANSI C standard
http://www.garlic.com/~lynn/2005f.html#10 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005f.html#18 Is Supercomputing Possible?
http://www.garlic.com/~lynn/2005f.html#46 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005f.html#59 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005g.html#24 DOS/360: Forty years
http://www.garlic.com/~lynn/2005g.html#26 Maximum RAM and ROM for smartcards
http://www.garlic.com/~lynn/2005h.html#7 IBM 360 channel assignments

Today's mainframe--anything to new?

From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: 8 May 2005 10:00:09 -0700
Subject: Re: Today's mainframe--anything to new?

Alexander Schreiber wrote:

And then there is the story about Cray selling a building used for
manufacturing the machines. It was in a part of the US that gets
pretty cold winters and had _no_ heating installed since it was kept
comfortably warm by the waste heat turned out by a few Cray systems
running tests before shipment.

The new owner however seemingly could not afford to "just power up a
few Crays" to keep the building warm and had to install heating ;-)

the brand new research building .... almaden up on the hill .. moving
out of bldg. 28 on the main plant site ... was completely wired with
cat5 and other stuff for t/r thru-out the bldg.

they installed a whole bunch of ibm pc/rt with enet (they did a lot of
tests and found out that they got significantly better thruput using
the cat5 for 10mbit enet than they could get from 16mbit t/r).

in a energy conservation move ... there was guideline that all PCs
should be powered down when people left at the end of the day. they
tried it for awhile and the building maint. people complained. they
claimed that the heating/cooling hadn't been designed to handle the
wild temperature swings caused by powering up several hundred pc/rt in
the morning and then powering them down in the evening.

Exceptions at basic block boundaries

From: lynn@garlic.com
Newsgroups: comp.arch, alt.folklore.computers
Date: 8 May 2005 13:06:51 -0700
Subject: Re: Exceptions at basic block boundaries

Eric P. wrote:

The grenoble changes must have been a very early attempt at Local
Replacement. Since there is no such performance disparity between
Local and Global these days so I can only guess that the grenoble
mods did not use the same mechanism as the current approaches.

working set tended to assign a task a set number of real pages. when a
task faulted, local LRU replacement would select one of the tasks own
pages for replacement. in global LRU replacement, all pages belonging
to all tasks were examined for replacement.

in the tightly constrained real memory of the period ... and the normal
ebb and flow of program behavior .... at any point in time ... there
could be a page belonging to some other task that was much more ideally
suited for replacement than a task's own page.

in effect, global LRU replacement rank all virtual pages in real
memory as to their appropriateness for replacement ... instead of lots
of little private rankings for each task. the analogy is somewhat akin
to financial institutions having lots of tellers .... but a single
queue for all tellers (as opposed to one queue per teller).

as real storage configurations increased ... and it was found that you
had spare real storage for lots of other things ... like file caching
... the degree that a system was bottlenecked became less ... and the
degree that overall system throughput was tightly tied to real memory
sizes drastically decreased (and with the decrease in how tightly
overall system thruput was tied to memory and paging ... there was
also a corresponding decrease in the degree that different paging
algorithms affected overall system performance).

In a real-memory constrained system where there is an extremely close
relationship between overall system thruput and the importance of each
individual page replacement decision ... differences in page
replacement algorithms were much more pronounced.

For instance, in the early 80s ... big pages were introduced with 3380
disks. basically instead of doing single 4k page replacement at a time
... paging was done in blocks of ten 4k pages at a time (40k bytes per
transfer).

Typical real storage sizes had gotten much larger ... by possibly a
factor of 50 times ... but disk (arm) thruput had only increased by
less than factor of 5 times. The total amount of pages moved with big
page implementation was possibly 30 to 50 percent larger than the same
workload in a environment doing single page at a time replacement.
Because of the large shift in the bottlenecks from being real storage
contrained to being disk arm constrained .... the importance in the
quality of the page replacement decision had declined significantly
.... it was more importan that you could move ten times as many pages
per transfer ....  even if 30 percent of the page transfers turned out
to be wrong or unnecessary.

at the same time grenoble had published the local lru replacement paper
.... cambridge science center
http://www.garlic.com/~lynn/subtopic.html#545tech

had developed a number of very sophisticated performance modeling
tools. some of this was the origins of the transition of performance
management into capacity planning. other was an apl-based model that
was made available on the internal HONE system
http://www.garlic.com/~lynn/subtopic.html#hone

called the performance predictor that allowed world-wide sales and
marketing people to do customer what-if scenarios (change workload,
change hardware, etc ... in this period, APL was frequently used for a
number of things that spreadsheets were later used for).
http://www.garlic.com/~lynn/submain.html#bench

some of the technology involved taking detailed instruction/page
reference traces and running it thru very detailed even modeling that
implemented a wide variety of page replacment algorithms .... numerous
(global LRU) clock variations; local LRU; belady's OPT ... aka given
perfect fore-knowledge ... always make the optimial replacement
decision; true, exact LRU and others.

Part of this work was used to examine application program repackaging
for better virtual memory operation (aka the transition that many
applications were making in the 70s from real memory environment to
virtual memory environment).  In the mid-70s, a version of this
technology was also released to customers as a product called
VS/Repack. A early version of the vs/repack technology was also used
in the morphing of apl\360 from real-memory environment to cms\apl in
a virtual memory environment (and extreme highlighting of why the
apl\360 memory management and garbage collection had to be redone for
a virtual memory environment).

Besides extensive live performance test with variety of global LRU and
local LRU replacement ... there was also extensive modeling down
across wide variety of different applications as well as various kinds
of global LRU and local LRU implementations. Except for some
pathelogical scenarios ... global LRU always beat local LRU.

another interesting characteristic was that the various LRU
approximation replacement implementations (whether global or local)
...  it appeared to characterize them in how close they came to "true",
"exact" LRU (i.e. with full instruction trace and storage reference
...  it was possible to model "exact" LRU replacement ... as opposed
to simply approximate LRU that implementations typically tried for).

For some reason, i came up with a slight of hand in a clock, global
LRU implementations ... that seemed to be an improvment ... but the
modeling people even found something unexpected. Rather than being
almost as good as "true" LRU replacement (as all the other LRU
approximate implementations had been) ... it turned out to be better
than "true", "exact" LRU. Caused quite a bit of head scratching (this
wasn't involved in the grenoble/cambrige, local/global LRU comparison)

The question in the grenoble/cambridge, local/global LRU replacement
... was whether a page belonging to the current task with a page fault
.... out a better choice for replacement than all possible virtual
pages in virtual memory. Pure local LRU replacement could never
consider this as an option. Global LRU could consider all virtual
pages currently resident in real memory as to possible optimal page
for removal/replacement (even virtual pages belonging to other tasks).

misc. past LRU replacement and/or vs/repack postings
http://www.garlic.com/~lynn/93.html#0 360/67, was Re: IBM's Project F/S ?
http://www.garlic.com/~lynn/94.html#7 IBM 7090 (360s, 370s, apl, etc)
http://www.garlic.com/~lynn/94.html#14 lru, clock, random & dynamic adaptive ... addenda
http://www.garlic.com/~lynn/94.html#49 Rethinking Virtual Memory
http://www.garlic.com/~lynn/96.html#0a Cache
http://www.garlic.com/~lynn/96.html#0b Hypothetical performance question
http://www.garlic.com/~lynn/98.html#54 qn on virtual page replacement
http://www.garlic.com/~lynn/99.html#68 The Melissa Virus or War on Microsoft?
http://www.garlic.com/~lynn/99.html#104 Fixed Head Drive (Was: Re:Power distribution (Was: Re: A primeval C compiler)
http://www.garlic.com/~lynn/2000d.html#11 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#13 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000f.html#34 Optimal replacement Algorithm
http://www.garlic.com/~lynn/2000f.html#36 Optimal replacement Algorithm
http://www.garlic.com/~lynn/2000g.html#30 Could CDR-coding be on the way back?
http://www.garlic.com/~lynn/2001b.html#83 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001c.html#31 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001c.html#33 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001i.html#20 Very CISC Instuctions (Was: why the machine word size ...)
http://www.garlic.com/~lynn/2002c.html#28 OS Workloads : Interactive etc
http://www.garlic.com/~lynn/2002c.html#45 cp/67 addenda (cross-post warning)
http://www.garlic.com/~lynn/2002c.html#46 cp/67 addenda (cross-post warning)
http://www.garlic.com/~lynn/2002c.html#49 Swapper was Re: History of Login Names
http://www.garlic.com/~lynn/2002e.html#50 IBM going after Strobe?
http://www.garlic.com/~lynn/2002f.html#50 Blade architectures
http://www.garlic.com/~lynn/2003f.html#15 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#21 "Super-Cheap" Supercomputing
http://www.garlic.com/~lynn/2003f.html#53 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#55 Alpha performance, why?
http://www.garlic.com/~lynn/2003g.html#15 Disk capacity and backup solutions
http://www.garlic.com/~lynn/2003g.html#55 Advantages of multiple cores on single chip
http://www.garlic.com/~lynn/2003h.html#8 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003j.html#32 Language semantics wrt exploits
http://www.garlic.com/~lynn/2004c.html#21 PSW Sampling
http://www.garlic.com/~lynn/2004c.html#59 real multi-tasking, multi-programming
http://www.garlic.com/~lynn/2004g.html#13 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#18 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004.html#14 Holee shit!  30 years ago!
http://www.garlic.com/~lynn/2004i.html#0 Hard disk architecture: are outer cylinders still faster than
http://www.garlic.com/~lynn/2004m.html#22 Lock-free algorithms
http://www.garlic.com/~lynn/2004n.html#55 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004o.html#7 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004q.html#73 Athlon cache question
http://www.garlic.com/~lynn/2004q.html#76 Athlon cache question
http://www.garlic.com/~lynn/2004q.html#77 Athlon cache question
http://www.garlic.com/~lynn/2005.html#4 Athlon cache question
http://www.garlic.com/~lynn/2005c.html#53 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005d.html#37 Thou shalt have no other gods before the ANSI C standard
http://www.garlic.com/~lynn/2005d.html#41 Thou shalt have no other gods before the ANSI C standard
http://www.garlic.com/~lynn/2005d.html#48 Secure design
http://www.garlic.com/~lynn/2005f.html#47 Moving assembler programs above the line

Today's mainframe--anything to new?

From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: 9 May 2005 10:37:41 -0700
Subject: Re: Today's mainframe--anything to new?

Morten Reistad wrote:

Of course there is measurement and security overhead; but you are
in error about performance and security monitoring being contrary.
They are different views of the same observations. The challenge
is to build the reference model, and describe what is "normal" and
what is "abnormal"; and to also define dependency chains. If your
power is out you will have lots of other alarms, which should be
ignored by the on-site troubleshooters until power is restored.
(but off-site troubleshooters want to see them, as they may
have alternate facilities).

Likewise, you don't want to see noise from attacks you know you are
immune against going up the chain of escalation. But there is still
lots of chatter from old virii and worms on the Internet. For some
unknown chatter you just want to block the IP address with just a
routine message to operators/logs.

The point about being unobtrusive in monitoring is also important.
Use of statistical methods is important.

two things that frequently affect performance, integrity, and
availability (and frequently then are also considered security issues)
are complexity and implicit design issues. implicit design issues may
propagate into complexity and exposures later on ..... because
implicit consideration may not faithfully survive multi-year product
lifetimes (if they are implicit ... lots of people may not understand
implicit issues later on).

i've frequently found when i make implicit things, explicit; along
with simplifying complexity can improve performance, integrity and
availability ... all at the same time.

ten some years ago ... i gave a talk at a usc graduate student seminar
why tcp/ip didn't meet business critical dataprocessing requirements.
this was about the time we were working with small client/server
startup in silicon valley that wanted to do payment transactions ... misc.
ref
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

more recently, i've frequently commented that much of the
state-of-the-art may be compareable to the '60s aftermarket seatbelt
situation ... and that safety and integrity is much better when it is
built in from the ground up.

Exceptions at basic block boundaries

From: lynn@garlic.com
Newsgroups: comp.arch, alt.folklore.computers
Date: 9 May 2005 12:40:17 -0700
Subject: Re: Exceptions at basic block boundaries

Michel Hack wrote:

NO -- as I said several times already, in S/370 the C&R bits have
nothing to do with the MMU (as MMU is commonly understood, i.e. that
part that deals with address translation).  It is part of the memory
subsystem -- the part that manages real addresses and selects
physical memory chips/banks/whatever.  Each physical page contains
effectively 4097 bytes, the extra byte holds the storage key
inherited from S/360 and the Change&Reference bits added when an MMU
was added (360/67 and S/370).  There is no separate "table"

-- these extra bits are accessed or set using special instructions
(Set Key, Get Key, Reset Reference Bit and report its previous state).
Lynn Wheeler explained much of this already.  (On older machines this
"Key array" used special hardware; on modern machines with
industry-standard memory interfaces there may well be a table in
memory somewhere, but it would be accessible only to microcode.)

on older machines ... there tended to be special key array ... in part
because the feature was optional and orderable separately. except for
360/67, the 360s didn't have virtual memory support ... but you could
order the optional storage protection feature ... which included the
storage protection key array. this was basically 4bits per 2k bytes of
real storage.

the ssk & isk instructions were privilege and available ... and i
suspect that if the feature wasn't installed, ssk didn't do anything
... and isk just forced a zero value.

you could also optionally order storage protection feature with or w/o
fetch protection. the default was just store protect. if you had the
optional fetch protect ... it was a fifth bit in the storage key array
... which turned on/off fetch protection (using the same key value
rules as store protect).

basically if storage protection feature was installed and a non-zero
value was loaded into the PSW key field (a preivilege operation) ...
then the non-zero PSW key field value had to match the storage (2k)
area protection key.

360/67 required the storage protection feature be installed ... and
they defined two addition bits per storage key (per 2k area of
storage); one bit indicating storage area had been modified and the
other bit indicate the storage area had been referenced. Bits could be
reset using the same ssk instruction that set the storage key ... and
interrogated using the isk instruction.

cp67 running on 360/67 provided virtual machine support ... including
virtual 360/67 operation ... as a result it had to have private tables
that shadowed the real machine values (for the virtual machine). cp67
for each 4k page location had an 8byte swaptable entry; basically two
bytes of flags, two bytes that represented the virtual storage key
values for the two 2k area keys, and a four byte field that gave the
location of the page on disk (when it wasn't in memory). this was in
addition to the 2byte PTE value.

any time cp67 would reset a change or reference bit ... it would first
have to interrogate the current value(s) ... and save them to the
virtual machines shadow in the coresponding "swaptable" entry. Anytime
the virtual machine interrogated virtual storage keys (i.e. "isk"
instruction) ... cp67 had to interrogate the real-value and OR it with
the virtual machine backup value from the corresponding swaptable
entry.

any time a virtual machine reset their virtual storage key change
&/or reference values ... cp67 would have to first interrogate the
real hardware value and OR the current hardware values with the saved
cp67 values in the corresponding swaptable flag fields. it would then
zero the hardware change &/or reference values ... and set the
value specified by the virtual machine in the shadow key fields in the
corresponding swaptable entries.

in effect, there were different change and reference shadow bits in a
swaptable entry ... one pair for cp67 and one pair for the virtual
machine. Anytime the virtual machine reset their bits ... the real
hardware bits would be or'ed with the cp67 shadow bits and the real
bits and the virtual machine shadows bits were zero. anytime cp67
reset changed &/or reference bits ... the real bits had to be
interrogated and OR'ed with the virtual machine shadow bits before
zeroing cp67's shadow bits and the real hardware bits.

If either cp67 or the virtual machine interrogated the bits ... the
real hardware bits had to be OR'ed with the corresponding shadow bits.

Exceptions at basic block boundaries

From: lynn@garlic.com
Newsgroups: comp.arch, alt.folklore.computers
Date: 9 May 2005 17:57:14 -0700
Subject: Re: Exceptions at basic block boundaries

in much the same way that cp67 had to maintain "shadow" virtual keys
for virtual machines ... cp67 also had to maintain "shadow" segment &
pagetables.

virtual machine would have "virtual" segment and page tables that
mapped 2nd level virtual addresses to address of the virtual machine.
cp67 would use virtual memory hardware to have virtual machine pagess
at arbitrary real addresses.

when emulating a virtual machine operating system that supported its
own virtual memory ... cp67 would build a shadow set of segment and
page tables ... and use the DAT look-aside buffer hardware rules for
managing the entries in the segment and page tables. Effectively, the
shadow tables started with all the invalid bits set. the operating
system in the virtual machine would load pointers to its memory
translation tables and start execution ... which would immediately
result in a fault that was fielded by the cp67 operating system. It
would emulate the operation of TLB hardware for fetching the entry
from the table in the virtual machine ... and then run it thru the
"1st level" tables that mapped virtual machine addressed to real
machine addresses (akin to the process that hardware TLBs use for
loading entries).

Any time there was a 1st level virtual memory page replaced ... and
the corresponding "real" PTE invalidated ... then all the shadow PTEs
also got invalidated (since there wasn't a reverse mapping between
individual first level tables and shadow PTEs). The emulation had
quite a bit more reasons for invalidating shadow PTEs that possibly
real hardware TLB might have ... akin to previous discussion where 168
had to replace a STO entry in the STO-stack and then all corresponding
TLB entries that had been associated with the previous STO-stack
entry.

the process was made recursive. there was a joint project between the
science center
http://www.garlic.com/~lynn/subtopic.html#545tech

and endicott to produce a virtual machine implementating 370 virtual
memory architecture definition (some of the bits in the tables were
different from that defined in 360/67, as well as control register
useage, and some of the instruction definition).

This was before 370 virtual memory hardware was available and/or even
virtual memory feature had been announced publicly.

The cambridge machine offered somewhat open time-sharing service
http://www.garlic.com/~lynn/submain.html#timeshare

that included various univ. students in the cambridge area (BU, MIT,
Harvard, etc). the possibility of virtual memory for 370 was
considered an extremely confidential corporate secret.

so there was the normal cp67 (cp67-l) running on the bare 360/67
hardware.

there was a modified version of cp67 (cp67-h) that ran in a 360/67
virtual machine ... and emulated the rules of 370 architecture
definition ... rather than emulating the rules of 360/67 architecture
definition .... however it mapped the 370 virtual machine formated
PTEs into "shadow" tables that were in 360/67 format.

there was a highly modified version of cp67 (cp67-i) that ran in a 370
virtual machine ... that used 370 control instructions and 370 virtual
memory architecture tables.

finally there was a cms that ran in a 370 virtual machine ... so the
scenario was:

360/67 real hardware with real virtual memory support
  cp67-l ran on the 360/67 providing 360 & 360/67 virtual machines
    cp67-h ran in a 360/67 virtual machine providing 370 virtual
    machines
      cp67-i ran in 370 virtual machine providing 370 virtual machine
        cms ran in a 370 virtual machine

the above was operation and in regular use a year before the first 370
engineering machines were available with virtual memory hardware
support.

360/67 didn't have a specific instruction for invalidating the
hardware look-aside buffer. reloading the control register that was
used for the virtual memory table pointer ... did flush all the
entries in the look-aside buffer.

360/67 also didn't have separate instructions that allowed
testing/changing page reference and/or changed bits. The bits were
attached to the storage protection key array ... and so the standard
isk & ssk instructions had to be used for accessing and manipulating
the reference and change bits.

the original 370 virtual memory architecture defined PTLB (purge
look-aside buffer), ISTE (invalidate segment table entry), and IPTE
(invalidate page table entry). All three instructions were defined to
also operate consistently on all hardware look-aside tables in a
multi-processor configuration.

the low-end and mid-range 370s were primarily microcode. The 155 & 165
required extensive hardware for virtual memory support. Since 370s
started shipping before virtual memory hardware was either announced
or available. At one point the 165 engineers noted that they could
ship basic virtual memory hardware support six months before they
could have the "full" 370 virtual memory architecture supported. A
business decision was made that all the extra features would be
dropped from the 370 virtual memory announcement (for all 370 models
... even those models that had the extra features already
implemented).  PTLB was retained but ISTE and IPTE instructions were
dropped. At least w/PTLB the flushing of the look-aside buffer was
divorced from the instruction that changed the active virtual address
apace (which was combined in the one instruction on 360/67).

370 also introduced the RRB instruction which tested the reference and
change bits ... set the instruction condition code appropriately and
zero'ed the reference bit. This was more efficient than retrieving the
full key (w/isk), checking the specific bits, and resetting the key
(w/ssk). the deficiency of the isk/ssk scenario was that it could miss
bit state in multiprocessor environment ... where the RRB was defined
as being multiprocessor consistent.

Blowing My Own Horn

From: lynn@garlic.com
Newsgroups: bit.listserv.ibm-main, alt.folklore.computers
Date: 10 May 2005 08:01:17 -0700
Subject: Re: Blowing My Own Horn

EA MacNEIL wrote:

"LPAR and PR/SM":
http://www.eservercomputing.com/ME2/Audiences/dirmod.asp?sid=&nm=&type=Publishing&mod=Publications%3A%3AArticle&mid=8F3A7027421841978F18BE895F87F791&tier=4&id=04EE2C13E2734B9F8970E4E393F5BC0E&AudID=174DB902288C4970A30C71C9427313A7

"Don't be Mislead by MIPS":
http://www.eservercomputing.com/ME2/Audiences/dirmod.asp?sid=&nm=&type=Publishing&mod=Publications%3A%3AArticle&mid=8F3A7027421841978F18BE895F87F791&tier=4&id=F0C43E81FF224DE0A44C45BC901CE3A7&AudID=174DB902288C4970A30C71C9427313A7

"The Case for Capacity Planning":
http://www.eservercomputing.com/ME2/Audiences/dirmod.asp?sid=&nm=&type=Publishing&mod=Publications%3A%3AArticle&mid=8F3A7027421841978F18BE895F87F791&tier=4&id=6D8F527A14924287A985059C3BFB4CCC&AudID=174DB902288C4970A30C71C9427313A7

and now for something a little bit different ....
http://www.ibmsystemsmag.com/mainframe/marchapril05/stoprun/10020p1.aspx

recent post on genesis of pr/sm and lpar
http://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new?

recent posts on genesis of capacity planning (evolution from
performance maangement)
http://www.garlic.com/~lynn/2005h.html#1 Single System Image questions
http://www.garlic.com/~lynn/2005h.html#10 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005h.html#15 Exceptions at basic block boundaries

Key pair & Certificate lifetimes

From: lynn@garlic.com
Newsgroups: comp.security.misc
Date: 10 May 2005 08:41:50 -0700
Subject: Re: Key pair & Certificate lifetimes

John wrote:

Not necessarily so. Good PKI systems allow for a renewal of the
certificate, whilst keeping the original keypair.

aka the certification of the public key in a certificate is somewhat
independent operation of the certification of other information that
might also be certified in the certificate. the reasonable lifetime of
a public/private key pair can be totally unrelated to reasonable
lifetime of any other information that is also certified in a
certificate ... aka my previous posting
http://www.garlic.com/~lynn/2005g.html#39 Key pair & Certificate lifetimes

investigation into certificates with things like 8hr or 24hr lifetimes
(because some of the certified information may reasonably expected to
possibly have very short lifetime).

note that PKI and certification authority infrastructure design point
was to address scenario where the relying party had not other recourse
to the actual online or offline information about the subject (aka the
offline electronic version of letters of credit from sailing ship
days).

PKIs weren't originally viewed as substituting for situations where
the relying party might have direct access to the real information
(rather than having to relying on stale, static substitute information
from certificates).

One of the scenarios about PKIs from the mid-90s ... would a relying
party prefer to know

1) only know that the subject had a bank account from a specific
institution at some point in the past (possibly several months)
... aka the stale, static, redundant and superfluous certificate
scenario

or

2) have a real time response from the financial institution ... not
only does the subject have a current bank account ... but the
financial institution has determined there is sufficient balance to
cover the transaction ... and has actually gone ahead and debit the
account for the amount of the transaction.

There were actually some factions that appeared to be convinced that
the first scenario was much more valuable than the second scenario.

Thou shalt have no other gods before the ANSI C standard

From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: 10 May 2005 15:53:32 -0700
Subject: Re: Thou shalt have no other gods before the ANSI C standard

Brian Inglis wrote:

Check to see if there were any changes in or near your house about
that time of the year, and if not, email the FCC (fcci...@fcc.gov) and
ask them if they know of any local changes to transmission sources,
broadcast power, or patterns starting about that time of the year and
day, as it started interfering with your AM reception. That's part of
their job, and they should be knowledgeable and helpful.

one of the things we were doing in hsdt
http://www.garlic.com/~lynn/subnetwork.html#hsdt

we put in tdma satellite system ... and had a transponder on sbs4 ...
which went up on 41-d
http://www.nasa.gov/mission_pages/shuttle/shuttlemissions/archives/sts-41D.html

with some 4.5m dishes. there was public hearing about zoning for the
dishes in various places ... and people showed up with very strong
complaints about the radiation from the dishes. the dishes had 25watt
transmitter with uplink power control ... nominal operation at maybe
1/3rd ... and only go to 25watts when there was heavy rain absorbtion.

calculation was done that if a crane suspended somebody directly above
the dish when operating at full power ... they would get less radition
than the neighborhood was constantly receiving from the nearby 50,000
watt FM transmission tower.

Today's mainframe--anything to new?

From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: 10 May 2005 16:31:12 -0700
Subject: Re: Today's mainframe--anything to new?

jmfbah...@aol.com wrote:

That change would have bugged me.  I  can't begin to describe
the change of the feel of TOPS-10 when it went from master/slave
to SMP.  The difference is rather like moving one's seat from
the back of a turtle to an SST's nose.

the original vm370 smp support had some fine-grain locking ... but had
a global lock on much of the kernel. this bore some simularities to
some of the smp kernel/supervisor spin locks of the period .... except
there were a small number of very high-use/fastpaths that were enabled
for concurrent kernal smp execution.

the other difference was that the majority of the global kernel locks
from the period were "spin" locks ... a processor that attempted to
enter the kernel would spin on the kernel lock until is was made
available by some other processor. this is what i called a bounce
lock (instead of spin lock)
http://www.garlic.com/~lynn/submain.html#bounce

where if a processor didn't obtain the (almost) global kernel lock ...
it queued an extremely lightweight thread and went looking for other
activity.  as a result there was almost no measurable smp "overhead"
(like you might find with spin locks). it also had the side effect of
increasing the mip rate on high end cache machines ... since there was
a tendency if a specific processor got into kernel mode ... and other
processors also needed kernel services ... these other kernel services
requests tended to queue against the processor already performing
kernel services (better cache hit rate ... and therefor higher mip
rate).

this continued for a couple of releases and then had a major rewrite
... which supposedly vastly improved the smp thruput .... but most
customers saw 10-20percent thruput degradation. One large federal TLA
was especially concerned.

It turns out that the smp rewrite for this release was targeted at a
very specific customer situation. 3081s had been originally targeted
at never being available in non-smp version. the problem was that the
airline control program (acp