List of Archived Posts

2003 Newsgroup Postings (01/10 - 01/19)

Clustering ( was Re: Interconnect speeds )

cost of crossing kernel/user boundary

vax6k.openecs.org rebirth

vax6k.openecs.org rebirth

vax6k.openecs.org rebirth

vax6k.openecs.org rebirth

vax6k.openecs.org rebirth

vax6k.openecs.org rebirth

vax6k.openecs.org rebirth

Mainframe System Programmer/Administrator market demand?

Mainframe System Programmer/Administrator market demand?

Mainframe System Programmer/Administrator market demand?

cost of crossing kernel/user boundary

FlexEs and IVSK instruction

vax6k.openecs.org rebirth

vax6k.openecs.org rebirth

vax6k.openecs.org rebirth

vax6k.openecs.org rebirth

cost of crossing kernel/user boundary

Message (authentication/integrity); was: Re: CRC-32 collision

vax6k.openecs.org rebirth

vax6k.openecs.org rebirth

Multics preservation: good news

vax6k.openecs.org rebirth

vax6k.openecs.org rebirth

vax6k.openecs.org rebirth

vax6k.openecs.org rebirth

vax6k.openecs.org rebirth

Multics preservation: good news

Message (authentication/integrity); was: Re: CRC-32 collision

Round robin IS NOT load balancing (?)

asynchronous CPUs

Mainframe System Programmer/Administrator market demand?

Round robin IS NOT load balancing (?)

Calculating expected reliability for designed system

Round robin IS NOT load balancing (?)

mainframe

Calculating expected reliability for designed system

Calculating expected reliability for designed system

Flex Question

InfiniBand Group Sharply, Evenly Divided

InfiniBand Group Sharply, Evenly Divided

basic pki question

Timesharing TOPS-10 vs. VAX/VMS "task based timesharing"

Will Apple ever offer a newsreader?

InfiniBand Group Sharply, Evenly Divided

Horror stories: high system call overhead

Timesharing TOPS-10 vs. VAX/VMS "task based timesharing"

InfiniBand Group Sharply, Evenly Divided

InfiniBand Group Sharply, Evenly Divided

Origin of Kerberos

Top Gun

SSL & Man In the Middle Attack

Cluster and I/O Interconnect: Infiniband, PCI-Express, Gibat

Timesharing TOPS-10 vs. VAX/VMS "task based timesharing"

Cluster and I/O Interconnect: Infiniband, PCI-Express, Gibat

Wild hardware idea

If you lived as a child in the 50's, 60's or 70's,

Card Columns

Cluster and I/O Interconnect: Infiniband, PCI-Express, Gibat

MIDAS

MIDAS

Card Columns

SSL & Man In the Middle Attack

SSL & Man In the Middle Attack

Amdahl's VM/PE information/documentation sought

SSL & Man In the Middle Attack

3745 & NCP Withdrawl?

3745 & NCP Withdrawl?

Why did they make FORTRAN so hard to parse?

Disk drives as commodities. Was Re: Yamhill

Card Columns

Disk drives as commodities. Was Re: Yamhill

Card Columns

paper tape input

Clustering ( was Re: Interconnect speeds )

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Clustering ( was Re: Interconnect speeds )
Newsgroups: comp.arch,comp.sys.sgi.hardware,comp.sys.intel
Date: Thu, 02 Jan 2003 17:16:04 GMT

Alexis Cousein writes:

It'd be much more interesting to see someone from LANL (not LLNL,
BTW -- they have a Power4 based setup, not ASCI Q) comment on
the application scalability on the entire Q setup on a diverse set of
applications -- Top500 is fine for some uses, but
hardly for a comprehensive debate about computer architecture.

somewhat as an aside .... my view from the standards period
(essentially going on simultaneously) was that

LANL was driving factor behind HiPPI .... wanting a industry standard
(commodity priced?) for cray channel

LLNL was driving factor behined FCS ... wanting a fiber standards
version of a copper serial non-blocking switch that they had
installed.

SLAC was driving factor behind SCI ... comments recently posted
(sequent, data general, and convex built SCI-based computers)

random ref:
http://www.garlic.com/~lynn/95.html#13

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

cost of crossing kernel/user boundary

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: cost of crossing kernel/user boundary
Newsgroups: comp.arch
Date: Thu, 02 Jan 2003 17:22:48 GMT

Emil Naepflein writes:

That is standard on most systems today because the processors support
this by generating a trap when the registers were not saved and a new
task wants to access floating point registers.

the place that i first saw such hardware assist was for the registers
in the 3090's optional vector processor.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

vax6k.openecs.org rebirth

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vax6k.openecs.org rebirth
Newsgroups: alt.folklore.computers,comp.sys.prime
Date: Thu, 02 Jan 2003 20:03:17 GMT

Morten Reistad writes:

Timeline, from Google, Wiki, SGI, sympatico.ca etc. :

??      1981 : IBM starts ROMP
??      1981 : Stanford starts MIPS project
??      1984 : First MIPS processor implementation
April   1986 : First Fujitsu SPARC chips, 10 mips
June    1986 : Mips 2000 introduced.
October 1986 : PA-Risc introduced.
March   1987 : 4D/60 R2000 based system, 7 mips, 0.7 mflops
July    1987 : Sun announces SPARC spec officially
??      1987 : ARM, Archimedes home computer, 4 mips
??      1987 : AMD29000,
mid     1988 : Motorola 88000
October 1988 : PowerSeries R2000 based systems from SGI, 20+++ MIPS, 2+++ mflop
??      1988 : Mips R3000, 40++ mips
??      1989 : Sparcstation 1, 12.5 mips

For comparison, 6-8 mips was a pretty high end minicomputer in 1985.

CP.r (control program for 801 processor) & PL.8 (programming language
for 801 processor) was presented at an internal advanced technology
meeting held in pok spring of '77 (may have been spring '76, i can't
find the reference at the moment).

This was followed by Fort Knox ... which was a large project to
replace all the low-end & mid-range microprocessors with 801s
(i.e. the low & mid range 370 microprocessos, the rochester system/3
stuff, etc) ... and other control processors, like the things what the
uc.5 & jib-prime were used for). While fort knox was killed some of
the work still showed up as internal control processors in other
products.

Fort Knox was eventually killed ... but office products division and
research started up ROMP as the basis for displaywriter follow-on
(using both CP.r and PL.8 as the basis). When the displaywriter
follow-on was killed, the group tried to quickly adapt ROMP to the
unix workstation market (contracting with the same company that had
done the PC/IX port for the PC).

misc 801, romp, fort knox postings:
http://www.garlic.com/~lynn/subtopic.html#801

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

vax6k.openecs.org rebirth

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vax6k.openecs.org rebirth
Newsgroups: alt.folklore.computers,comp.sys.prime
Date: Thu, 02 Jan 2003 20:23:45 GMT

Anne & Lynn Wheeler writes:

misc 801, romp, fort knox postings:
http://www.garlic.com/~lynn/subtopic.html#801

and while some number of the engineers on fort knox showed up on ROMP
... some also left the company showing up (at least) on AMD's 29k and
HP's. one of the other internal projects going on about the same time
as ROMP (16bit 801) was blue iliad (32bit 801). Blue iliad never
shipped ... but one of the people that worked on it later showed up at
HP ... and possibly one of the others showed up at SUN.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

vax6k.openecs.org rebirth

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vax6k.openecs.org rebirth
Newsgroups: alt.folklore.computers,comp.sys.prime
Date: Thu, 02 Jan 2003 21:10:11 GMT

Anne & Lynn Wheeler writes:

CP.r (control program for 801 processor) & PL.8 (programming language
for 801 processor) was presented at an internal advanced technology
meeting held in pok spring of '77 (may have been spring '76, i can't
find the reference at the moment).

was spring of '77 (not '76). spring of '76 i was doing the resource
manager, the stuff for ECPS (vm m'code assist for virgil/tully) and
VAMPS (5-way smp). didn't start on the 16-way smp stuff until later in
'76.  at the same adtech meeting (spring '77) where the 801 group
presented 801, cp.r, pl.8, etc. .... we presented the 16-way smp
project.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

vax6k.openecs.org rebirth

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vax6k.openecs.org rebirth
Newsgroups: alt.folklore.computers,comp.sys.prime
Date: Fri, 03 Jan 2003 04:39:47 GMT

Brian Inglis writes:

Did 16 way SMP go anywhere? I know most IBM shops stopped at
four-way per system, as 370 cache coherence/snooping overhead
took away about 20% of each available CPU, you only ever got 0.8N
usable processing, so by five-way you effectively got only four
CPUs worth of processing. Bigger complexes always seemed to get
partitioned into multiple systems with smaller numbers of
processors on each.

standard 370 had very strong consistency memory model .... requiring
tight coupling between caches. 370, 303x, 308x two-way .... basically
took a ten percent performance hit .... just for the cycle time
slow-down to listen for cache invalidates from one other processor.
That is just for starts .... when cache line invalidate signals
were actually happening ... there was additional slowdowns.

3084 was a four way ... where each cache had to listen for cache line
signals from three other processors (rather than just one). Later machines
started running portions of cache hardware at significantly faster cycle
times than the rest of the processor infrastructure .... just to keep
up with the cache line invalidate signals.

the five-way project wasn't a cache machine (so didn't suffer the
cache consistency overhead issues) ... it was a 370/125. The 370/125
was physical a 9-way SMP machine .... nine positions on the memory bus
with some or all of the positions occupired by microprocessors. The
basic difference between the micrprocessors was what kind of microcode
was loaded .... aka traditional 370/125 had one of the microprocessors
loaded with 370 instruction set emulation ... and the other
microprocessors were loaded with various kinds of controller and I/O
functions. The five-way ... had up to five of the microprocessors
loaded with 370 instruction set emulation. There was also going to be
a superset of VM microcode assist that was done for virgel/tully
(ECPS) ... along with effectively task queue and task switch in
microcode (somewhat move akin to some of the 432 stuff than the XA SIE
instruction) and much of the page subsystem offloaded to the disk
controller microprocessor. misc m'code discussions:
http://www.garlic.com/~lynn/subtopic.html#360mcode

Effectively the remaining portions of VM kernel (not moved to
microcode) had the old-style 360/65 OS kernel lock ... however it was
unique in rather than a spin-lock ... it was a queued or bounce lock,
aka if a processor microcode couldn't obtain the kernel lock .... it
queued a lightweight kernel processing request against the kernel lock
and went off to the microcode schedule/dispatcher to find some other
work. The objective was that the virtual/kernel processing ratio was
on the order of 9:1 or better (aided by various portions of the VM
kernel dropped into the parallelized microcode). As long as it stayed
better than 4:1 ... the workload wouldn't bottleneck on the kernel
lock (and it was a very low-overhead lock since there was no
spinning).

This was also the design model I used for the SMP support in the
VM/370 product release. Basically all of what was in the VAMPS
parallelized microcode had the necessary fine-grain locking support.
There was then a single "kernel" lock for main body of low useage
kernel code. If processing required the "kernel" lock ... and couldn't
obtain it ... it would queue a lightweight request off the kernel lock
and go to the parallelized dispatcher/scheduler to find some other
work not requiring the kernel lock. I claimed that this was the
maximum parallelized SMP thruput for the fewest number of code
changes. misc. smp threads/posts
http://www.garlic.com/~lynn/subtopic.html#smp

As i mentioned I was doing the resource manager at the same time ... aka
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock

The resource manager had the distinction of being the first "priced"
operating system code .... and i got the opportunity to work with the
business people on the business rules for such pricing. However, there
was a lot of code that I put into the resource manager that wasn't
strictly algorithm control .... there was a lot of code that was
integrity oriented (failure resistant) and also oriented towards
structures supporting parallelized SMP operation. However, it went
out before the standard VM/370 support shipped with SMP support.
Some discussion of the integrity & benchmarking posts:
http://www.garlic.com/~lynn/submain.html#bench

When it came time to ship VM/370 release with SMP support ... it was
decided that it would be a "free" release ... but containing something
like 80 percent of the lines of code from the resource manager. The
resource manager product for the first SMP VM/370 release continued to
be charged the same as it had in the pre-SMP release version ... but
it had only about 1/5th the lines of code (the rest of the code being
absorbed by the still free operating system release).

16-way smp had a much weaker cache consistency memory model (than
traditional mainframes) .... allowing much less inter-cache
overheads. this required some additional operating system changes for
things like more pervasive use of compare&swap in certain
situations. it ran into other issues ... as mentioned in (executives
hammered some engineers for working with us when it was realized that
there was no chance of MVS supporting the machine):
http://www.garlic.com/~lynn/2002p.html#58 AMP vs SMP

Some of the degradation in scalable processors was how strong the
memory model was maintained by cache hardware & associated protocols.
Other issues affecting thruput was somewhat independent of the cache
consistency protocols. One of the things that a lot of attention in
the 3084 (4-way) time-frame was kernel storage allocation structures
...  starting to align them on cache line boundaries and making them
multiples of cache line sizes. The issue was that if two different
data structures occupied the same cache line ... and were potentially
in use by two different processes on two different processors at the
same time ... there could be extremely extensive cache line trashing.

The other issues that operating system paradigm dependent .... is the
locking granularity .... whether or not spin-lock paradigm was used
.... or some other paradigm was used. The compare&swap instruction was
the doings of charlie at cambridge scientific center ... original
working on fine-grain locking for CP/67. The instruction was first
invented and the mnemonic chosen to match charlie's initials (it is
one of the few widely used instructions that are actually somebody's
initials).

Another issue is what sort of paradigm does the kernel use to
serialize/syncronize various operations across different processes.
One of the last release of VM (aka for 370) ... before VM/XA
significantly redid the structure for the use of the SIGP (signal
processing instruction). When that release hit the streets ... the
SIGP paradigm change was using ten percent of total elapsed time on
both processors just for SIGP and related infrastructure processing
(just on the off chance that it might be useful to tell the other
processor something).

In this situation ... for two way operation ... there was the hardware
loss of ten percent of both processors going to the caches listening
for each others invalidate & syncronization signals ... plus this
software kernel release introduced an additional ten percent of both
processors going to the kernel on each processor waving to itself on
the other processor (and then you get to talk about all the other
normal single processor as well normal multiprocessor kernel
overheads).

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

vax6k.openecs.org rebirth

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vax6k.openecs.org rebirth
Newsgroups: alt.folklore.computers,comp.sys.prime
Date: Fri, 03 Jan 2003 04:59:27 GMT

Anne & Lynn Wheeler writes:

a superset of VM microcode assist that was done for virgel/tully
(ECPS) ... along with effectively task queue and task switch in
microcode (somewhat move akin to some of the 432 stuff than the XA SIE
instruction) and much of the page subsystem offloaded to the disk
controller microprocessor. misc m'code discussions:
http://www.garlic.com/~lynn/subtopic.html#360mcode

the five-way was targeted at cms intensive environment .... and the
CMS had my redo that mapped the cms filesystem into a paged mapped
infrastructure. as a result all disk i/o used the page mapped
semantics (i.e. for file operation and for virtual memory paging
... as well as all of the various kernel on-disk filestructures).

so all disk & file i/o became page I/O operations of one sort or
another ... majority of the processing offloaded to the disk
controller microprocessor. misc. page mapped postings
http://www.garlic.com/~lynn/submain.html#mmap

later when we were doing ha/cmp (high availability, cluster
multiprocessor product for the 6000) we also got involved in the
hippi, fcs, and sci standards activity. sci was scalable model used
by (at least) sequent, data general, and convex for scalable
processor configurations; recent reference ...
http://www.garlic.com/~lynn/2003.html#0 Clustering (was interconnect speeds)

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

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

vax6k.openecs.org rebirth

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vax6k.openecs.org rebirth
Newsgroups: alt.folklore.computers,comp.sys.prime
Date: Fri, 03 Jan 2003 16:10:48 GMT

jmaynard@thebrain.conmicro.cx (Jay Maynard) writes:

The S/370 architecture only allows for two CPUs. How was that going to be
extended for more? (The 3084 would only allow all 4 CPUs to run in one
system image in XA mode.)

easy .... as per previous post .... the underlying hardware of the
370/125 (370/115) was a 9-way ...  it had up to nine microprocessors
sharing the same memory bus. the normal 125 configuration only had one
of the 370s loaded with the microcode to emulate 370 ... the other
microprocessors had other kinds of microcode to emulate other kinds of
functions (disk controller, other i/o functions, etc).

the five-way would have up to five of the microprocessors running the
microcode to emulate 370 ... but with heavy modifications; a superset
of both SIE instruction and ECPS (for virgil/tully) ... along with
changes for parallelization in microcode including the
dispatching/scheduling function in the the microcode. also the disk
controller microcode had most of the page i/o offloaded to it.

so based on above from original post .... if there was going to be
that much microcode changes .... how hard would it be to support
five-way 370? ... when the underlying hardware was already supporting
nine-way.

actually ... almost all of the function for parallelization was in the
microcode .... there was a trivial amount in the kernel for the single
global queue or bounce lock ... and there serialization with
compare&swap for queue management .... things going on/off the
dispatch queue ... things going on/off the disk i/o queue, etc.

The design was actually for 16-way .... however the underlying
hardware was only 9-way ... and given that some of the microprocessors
had to perform i/o control functions .... needed a minimum of four
processors doing the various i/o control functions .... leaving only
five slots for microprocessors executing 370 code.

as an aside, remember that the original 360/67 was designed for 4-way
... nearly 20 years before the 3084 4-way (in xa mode).

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

vax6k.openecs.org rebirth

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vax6k.openecs.org rebirth
Newsgroups: alt.folklore.computers,comp.sys.prime
Date: Fri, 03 Jan 2003 16:26:13 GMT

jmaynard@thebrain.conmicro.cx (Jay Maynard) writes:

The S/370 architecture only allows for two CPUs. How was that going to be
extended for more? (The 3084 would only allow all 4 CPUs to run in one
system image in XA mode.)

also ... what is the 370 SMP architecture that is sensitive to number
of processors. there is the signal processor instruction. in the
five-way design the whole sigp stuff was replaced with all the
microcode level shared-queue management i.e. most of the kernel type
logic involved in operations associated with sigp'ing other processors
was pushed down into the microcode ... it was abstracted out of the
software kernel model all together and moved into microcode function.

not directly related ... but there is whether all processors have
access to all i/o. the tradtional 360/370 had dedicated i/o channels
for each processor and the I/O controllers then had multi-path channel
connections allowing each controller access to channels for each
processor.

The 360/67 had a different architecture that allowed all channels to
be address by all processors (in up to 4-way configuration). Such
architecture for I/O channel addressing didn't show up again until XA.
The limitation of lashing two 3081s together to form a 4-way 3084 was
much more a hardware limitatin than a difficult architecture
limitation.

Now, since for the 5-way 370/125 ... since we were doing all the
microcode changes .... moving almost everything involving
multiprocessing support out of the direct 370 architecture (and
kernel) into the microcode ... and since the 370/125 didn't have real
channels ... just other microprocessors on the same memory bus with
the appropriate microcode .... there was also change to the i/o
structure. As mentioned in the original post ... the interface between
the processor and disks was changed from SIO/channel architecture to
shared queues ... where most of the page & disk processing was
offloaded into the microprocessor with the disk controller microcode.
Rather than being SIO/channel there was queue of requests pending by
the disk controller and there was the queue of requests that had
finished.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Mainframe System Programmer/Administrator market demand?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframe System Programmer/Administrator market demand?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 03 Jan 2003 16:54:53 GMT

gsmith@NC.RR.COM (Greg Smith) writes:

Indeed.  I never realized that s370/s390/z900 architecture was so
`common' that mere riff-raff could write code to emulate it.

there is some contention that much of the pu4/pu5 complexity was
because of of project that four of did when i was undergraduate coming
up with first PCM controller.
http://www.garlic.com/~lynn/subtopic.html#360pcm

later with amdahl/fujitsu and national/hitachi processors (as well as
some of the little guys 4pi, etc, i think late 70s & early 80s saw a
number of entry/mid-range clones) there were similar questions
regarding driving factors in processor architecture enhancements.

one of the big issues when pr/sm origination time-frame (leading to
lpars) was amdahl's macrocode. the high-end mainframes tended to be
very complex horizontal microcode ... and architecture changes tended
to be quite complex code undertakings. amdahl's macrocode was a 370
subset for microcode impelemtation .... making it significantly easier
to track (& even enhance) architecture changes (aka amdahl's original
implementation was much simpler undertaking than ibm's response with
pr/sm).
http://www.garlic.com/~lynn/2000c.html#76 Is a VAX a mainframe?
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#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

as to the low/mid range ... that market was taken over by high-end PCs
and workstations for everybody starting sometime in the mid-80s
.... not just the IBM 370 low/mid range (but most of the minis).
http://www.garlic.com/~lynn/2002q.html#3 Vector display systems
http://www.garlic.com/~lynn/2002j.html#66 vm marketing (cross post)

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Mainframe System Programmer/Administrator market demand?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframe System Programmer/Administrator market demand?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 03 Jan 2003 17:38:07 GMT

Anne & Lynn Wheeler writes:

as to the low/mid range ... that market was taken over by high-end PCs
and workstations for everybody starting sometime in the mid-80s
.... not just the IBM 370 low/mid range (but most of the minis).
http://www.garlic.com/~lynn/2002q.html#3 Vector display systems
http://www.garlic.com/~lynn/2002j.html#66 vm marketing (cross post)

the market segment started this explosion ... in the same time-frame
the airforce was ordering 240 4341s ...
http://www.garlic.com/~lynn/2001m.html#15 departmental servers

TI had a project that they ordered 800 4341s for a project. STL was
converting a conference room on every floor, in every tower to a 4341
room.

the orders for 4341s far outstripped the production (some rumor in
part because of some intra-company issues between 4341 & 3031). clones
were appearing to fill the gap. it was general market segment so there
was also big increase for most minis (not just 370).

however, as all this was happening ... PCs and workstations were
starting to appear ... and started to take over the market segment
(transition year being about '85 ... which is about also when the
nodes on the internet exceeded the nodes on the internal network).

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Mainframe System Programmer/Administrator market demand?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframe System Programmer/Administrator market demand?
Newsgroups: bit.listserv.ibm-main
Date: Fri, 03 Jan 2003 21:23:55 GMT

edgould@AMERITECH.NET (Edward Gould) writes:

Phil,

What do you feel are (is) the major reason(s) why outsourcing fails?

from a different point of view .... outsourcing really works when
there is no change .... everything has been pretty much the same for
the last 20-30 years.

one of the oursourcing complexities is creating a larger disconnect
between the users/clients of the data processing service and the
actual service ... things tend to be much more contractual and formal
(and using a boyd'ism ... creates resistance and reduces agility, boyd
has some number of commercial examples .... but a military was why
does the army want its own close air support rather than relying on
the air force).

where there is little need for agility (because of no evolving
circumstances and changing requirements) ... aka a relatively static
environment ... then the lack of agility has little impact.

the counter argument is outsourcing may bring higher trained data
processing specialists which can more than compensate for the
resistance introduced by a more formal contractual relationship.

the other classical failure is where there is active animosity between
the users and the executives making the out-sourcing decision
(resulting in all kinds of subversion).

boyd OODA-loops and high agility for competitive rapidly changing
environments:
http://www.garlic.com/~lynn/subboyd.html#boyd

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

cost of crossing kernel/user boundary

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: cost of crossing kernel/user boundary
Newsgroups: comp.arch
Date: Sat, 04 Jan 2003 15:03:57 GMT

jfc@mit.edu (John F. Carr) writes:

On the original RS/6000 the svc/svcr instruction pair took about
four cycles, compared to about zero for a direct call and return.
Notably, that was less time than a pair of pipeline drains.  There
was a vectored system call (caller selects one of a large number
of entry points) that could be used to reduce overhead for simple
calls.  I think atomic compare&swap was implemented as a fast
system call.

compare&swap is supposed to be atomic ... non-interruptable and
provide serialization in an smp environment. when original
compare&swap was proposed (for 370) ... challenge by the owners of the
370 architecture was to come up with various methodologies for using
compare&swap in uniprocessors environments ... which was born the
description for using it for various kinds of "safe" queue updating in
multi-threaded applications. the 6000/rios didn't have compare&swap
primitive and didn't have multiprocessing support ... the only thing
needed for simulating compare&swap for multi-threaded applications was
to prevent interrupts. the fast simulation in the svc handler was a
way of getting all interrupts turned off from application mode during
the simulation of the instruction.

old trivia ... and of course compare&swap mnemonic was chosen because
they are charlie's initials.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

FlexEs and IVSK instruction

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: FlexEs and IVSK instruction
Newsgroups: bit.listserv.ibm-main
Date: Sat, 04 Jan 2003 16:27:02 GMT

xarax@email.com (xarax) writes:

space, rather than the home address space (causing all kinds of
storage overlays when in key 0 cross memory mode). All of these were
IBM boo-boos that made it into the field, and subsequently fixed.
(Ancient history now.)

370/125 had one in the long instructions. in all the 360 instructions,
the start & end addresses of operands were checked before starting the
instruction ... and aborting for things like protection, addressing,
etc. the long instructions were incremental & interruptable ... you
didn't check the ending address before starting ... but checked the
addresses as the instruction was executing. when a long instruction
was interrupted .... like for protection, addressing (or i/o, etc)
... the registers had been updated to reflect most recently processed
data. the 125 had an early boo-boo where it prechecked the ending addresses
of the long instructions and interrupted at that point.

some programs used mvcl with zero padding to clear storage and at the
same time to check for end of memory ... the instruction should
interrupt with addressing interrupt with registers set to last valid
address processed. prechecking resulted in no execution at all and no
register update ... and as result incorrect value for size of real
storage.

story of bug in 360/67 with the virtual memory table look aside
(referred to associative array at the time):
http://www.garlic.com/~lynn/2002q.html#54 cost of crossing kernel/user boundary

some other recent 125 refs:
http://www.garlic.com/~lynn/2002f.html#13 Hardware glitches, designed in and otherwise
http://www.garlic.com/~lynn/2002i.html#2 Where did text file line ending characters begin?
http://www.garlic.com/~lynn/2002i.html#9 More about SUN and CICS
http://www.garlic.com/~lynn/2002i.html#24 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#76 HONE was .. Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002j.html#64 vm marketing (cross post)
http://www.garlic.com/~lynn/2002m.html#75 New Book
http://www.garlic.com/~lynn/2002n.html#58 IBM S/370-168, 195, and 3033
http://www.garlic.com/~lynn/2002o.html#16 Home mainframes
http://www.garlic.com/~lynn/2002p.html#47 Linux paging
http://www.garlic.com/~lynn/2002p.html#58 AMP vs SMP
http://www.garlic.com/~lynn/2003.html#5 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#7 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#8 vax6k.openecs.org rebirth

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

vax6k.openecs.org rebirth

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vax6k.openecs.org rebirth
Newsgroups: alt.folklore.computers,comp.sys.prime
Date: Sat, 04 Jan 2003 16:55:12 GMT

jmaynard@thebrain.conmicro.cx (Jay Maynard) writes:

I was thinking SIGP and CONCS/DISCS, specifically. Looks like you got around
both of those, although it would have required running under a specific
version of VM.

i was working on ECPS with endicott for virgil/tully at the same time
and that required running a specific version of vm .... a vm modified
for all the ecps instructions ... and released as a product. while all
the changes for ecps weren't as many as the changes for VAMPS ... they
were still significant ... and required specific version of vm. ecps
was the vm microcode assists/accelerator for virgil/tully (370/138 &
370/148 and then 4331, 4341, etc). An initial product strategy was to
attempt to make ecps/vm part of the hardware product on all machines
shipped (in much the same way done for LPARS today).

later the VAMPS architecture was translated to vanilla 158/168
multiprocessor support (w/o microcode enhancements) ... which required
running a specific version of vm .... a vm modified to support
multiprocessing .... and released as a product (course there is the
intertwining of the resource manager which had a bunch of things down
for multiprocessor environments and released prior to the vm release
with full multiprocessor support .... and all that code had to be
switched from the resource manager product ... to the base product).

the translation of VAMPS to vanilla 158/168 was about the same amount
of code changes for specific version of vm.

I didn't see where VAMPS was all that different than what i was doing
for ecps or the resource manager .... and it sure wasn't that
different from the official smp support. just do it, get it into the
product and ship it. much of the technique used for ecps could also be
used for most of VAMPS.

for ecps, at boot ... there was a list of all the ecps instructions
thru-out the kernel ... if ecps wasn't available on the machine
... all those instructions got no-oped ... and the kernel effectively
dropped thru to the software instructions. if the ecps instruction was
executed ... it continued after the instructions it replaced (as
opposed to the following instruction). in some of the VAMPS cases
... it would have bypassed large bodies of instructions.

part of the reason that VAMPS didn't make it out was that it would
have been competing in the same market segment as vigil/tully. since i
was doing both ... in some of the product escalation meetings ... i
got a chair on both sides of the table and had the opportunity to have
extensive arguments with my opposing self as to which was better and
why.

misc smp refs:
http://www.garlic.com/~lynn/subtopic.html#smp

misc. ecps refs:
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist
http://www.garlic.com/~lynn/94.html#27 370 ECPS VM microcode assist
http://www.garlic.com/~lynn/94.html#28 370 ECPS VM microcode assist
http://www.garlic.com/~lynn/2000.html#12 I'm overwhelmed
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/2000e.html#6 Ridiculous
http://www.garlic.com/~lynn/2000g.html#7 360/370 instruction cycle time
http://www.garlic.com/~lynn/2001b.html#29 z900 and Virtual Machine Theory
http://www.garlic.com/~lynn/2001b.html#83 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001i.html#2 Most complex instructions (was Re: IBM 9020 FAA/ATC Systems from 1960's)
http://www.garlic.com/~lynn/2001i.html#3 Most complex instructions (was Re: IBM 9020 FAA/ATC Systems from 1960's)
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/2002i.html#80 HONE
http://www.garlic.com/~lynn/2002j.html#5 HONE, xxx#, misc
http://www.garlic.com/~lynn/2002l.html#51 Handling variable page sizes?
http://www.garlic.com/~lynn/2002l.html#62 Itanium2 performance data from SGI
http://www.garlic.com/~lynn/2002o.html#15 Home mainframes
http://www.garlic.com/~lynn/2002o.html#16 Home mainframes
http://www.garlic.com/~lynn/2002p.html#44 Linux paging
http://www.garlic.com/~lynn/2002p.html#48 Linux paging
http://www.garlic.com/~lynn/2003.html#4 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#5 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#6 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#7 vax6k.openecs.org rebirth

misc. VAMPS refs:
http://www.garlic.com/~lynn/2000c.html#68 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000d.html#10 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#11 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000e.html#6 Ridiculous
http://www.garlic.com/~lynn/2000e.html#7 Ridiculous
http://www.garlic.com/~lynn/2001i.html#2 Most complex instructions (was Re: IBM 9020 FAA/ATC Systems from 1960's)
http://www.garlic.com/~lynn/2001j.html#18 I hate Compaq
http://www.garlic.com/~lynn/2001j.html#19 I hate Compaq
http://www.garlic.com/~lynn/2001j.html#48 Pentium 4 SMT "Hyperthreading"
http://www.garlic.com/~lynn/2002i.html#80 HONE
http://www.garlic.com/~lynn/2002i.html#82 HONE
http://www.garlic.com/~lynn/2002o.html#16 Home mainframes
http://www.garlic.com/~lynn/2003.html#4 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#5 vax6k.openecs.org rebirth

other 4341 refs:
http://www.garlic.com/~lynn/95.html#3 What is an IBM 137/148 ???
http://www.garlic.com/~lynn/96.html#1 360/370
http://www.garlic.com/~lynn/98.html#34 ... cics ... from posting from another list
http://www.garlic.com/~lynn/98.html#49 Edsger Dijkstra: the blackest week of his professional life
http://www.garlic.com/~lynn/99.html#7 IBM S/360
http://www.garlic.com/~lynn/99.html#36 why is there an "@" key?
http://www.garlic.com/~lynn/99.html#123 Speaking of USB ( was Re: ASR 33 Typing Element)
http://www.garlic.com/~lynn/2000.html#29 Operating systems, guest and actual
http://www.garlic.com/~lynn/2000.html#90 Ux's good points.
http://www.garlic.com/~lynn/2000b.html#37 How to learn assembler language for OS/390 ?
http://www.garlic.com/~lynn/2000c.html#76 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000c.html#83 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000d.html#0 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000d.html#7 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#9 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#10 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#11 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#12 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/2000d.html#20 S/360 development burnout?
http://www.garlic.com/~lynn/2000d.html#82 "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)
http://www.garlic.com/~lynn/2000e.html#52 Why not an IBM zSeries workstation?
http://www.garlic.com/~lynn/2000e.html#53 Why not an IBM zSeries workstation?
http://www.garlic.com/~lynn/2000e.html#57 Why not an IBM zSeries workstation?
http://www.garlic.com/~lynn/2001.html#21 Disk caching and file systems.  Disk history...people forget
http://www.garlic.com/~lynn/2001.html#22 Disk caching and file systems.  Disk history...people forget
http://www.garlic.com/~lynn/2001b.html#69 Z/90, S/390, 370/ESA (slightly off topic)
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/2001d.html#67 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001e.html#9 MIP rating on old S/370s
http://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001h.html#44 Wired News :The Grid: The Next-Gen Internet?
http://www.garlic.com/~lynn/2001j.html#3 YKYGOW...
http://www.garlic.com/~lynn/2001j.html#20 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001l.html#32 mainframe question
http://www.garlic.com/~lynn/2001m.html#12 Multics Nostalgia
http://www.garlic.com/~lynn/2001m.html#15 departmental servers
http://www.garlic.com/~lynn/2001n.html#39 195 was: Computer Typesetting Was: Movies with source code
http://www.garlic.com/~lynn/2002.html#11 The demise of compaq
http://www.garlic.com/~lynn/2002b.html#0 Microcode?
http://www.garlic.com/~lynn/2002d.html#7 IBM Mainframe at home
http://www.garlic.com/~lynn/2002e.html#46 What goes into a 3090?
http://www.garlic.com/~lynn/2002e.html#75 Computers in Science Fiction
http://www.garlic.com/~lynn/2002f.html#8 Is AMD doing an Intel?
http://www.garlic.com/~lynn/2002g.html#44 ibm icecube -- return of watercooling?
http://www.garlic.com/~lynn/2002h.html#52 Bettman Archive in Trouble
http://www.garlic.com/~lynn/2002i.html#7 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#19 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#22 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#23 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#27 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#29 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#30 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#37 IBM was: CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#43 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002j.html#4 HONE, , misc
http://www.garlic.com/~lynn/2002j.html#7 HONE, , misc
http://www.garlic.com/~lynn/2002j.html#67 Total Computing Power
http://www.garlic.com/~lynn/2002k.html#1 misc. old benchmarks (4331 & 11/750)
http://www.garlic.com/~lynn/2002k.html#3 misc. old benchmarks (4331 & 11/750)
http://www.garlic.com/~lynn/2002k.html#4 misc. old benchmarks (4331 & 11/750)
http://www.garlic.com/~lynn/2002n.html#58 IBM S/370-168, 195, and 3033
http://www.garlic.com/~lynn/2002n.html#59 IBM S/370-168, 195, and 3033
http://www.garlic.com/~lynn/2002n.html#63 Help me find pics of a UNIVAC please
http://www.garlic.com/~lynn/2002o.html#51 E-mail from the OS-390 ????
http://www.garlic.com/~lynn/2002o.html#74 They Got Mail: Not-So-Fond Farewells
http://www.garlic.com/~lynn/2002p.html#48 Linux paging
http://www.garlic.com/~lynn/2002q.html#27 Beyond 8+3
http://www.garlic.com/~lynn/2003.html#10 Mainframe System Programmer/Administrator market demand?

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

vax6k.openecs.org rebirth

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vax6k.openecs.org rebirth
Newsgroups: alt.folklore.computers,comp.sys.prime
Date: Sat, 04 Jan 2003 17:51:58 GMT

Anne & Lynn Wheeler writes:

was the vm microcode assists/accelerator for virgil/tully (370/138 &
370/148 and then 4331, 4341, etc). An initial product strategy was to
attempt to make ecps/vm part of the hardware product on all machines
shipped (in much the same way done for LPARS today).

part of this was some amount of the VM handshaking for vs1 made it
into the product (i.e. if VM was going to be the only operational mode
for these machines ... then it would be useful to optimize for that
mode in the other operating systems).

it eventually got to the point that the best optimized VS1 with
handshaking ran faster under VM ... than a compareably best optimized
VS1 (for standalone, bare hardware) ran on the bare hardware (although
not all of these optimzations made out the door in VS1). Still there
was frequently lots of situations where the product VS1 would had
higher thruput running under VM than when running on the bare
hardware.

we utilized an instance of this later at SJR. SJR for a long time ran
195 with MVT ... and then eventually installed 158 running VM (and
also used for MVS testing in preperation to replacing the 195 with
168).

After the 168 was installed ... the whole disk pool was setup so that
all controllers were connected to both 168/mvs and 158/vm. However, we
learned early never ot intermix mvs packs on vm strings & vm
controllers. typical situation was when operater accidentially mounted
an mvs pack on a vm string ... the data center would start getting
irate calls from users that vm thruput had gone down the toilet.

the cause, of course was mvs's use of multi-track search for VTOC &
PDS operations .... where worst case busy could be on the order of
1/3rd of a sec. for the transfer of a record amounting to a couple
hundred bytes at the most. since the MVS users always ran in this mode
of operation ... they didn't know that they there standard of living
was that thruput was always in the toilet.

some number of instances happened where the mvs people would say
... oops, sorry ... but it really isn't that important to stop things
and move the pack.

so the solution was to bring up a VS1 under vm ... and mount one of
its packs on a MVS string and then start a vs1 multi-track search
application of our own .... using few spare cycles on the loaded
vm/158 system to bring the mvs/168 system to its knees (which
immediately improved thruput for the vm users). That happened a couple
of times ... and the mvs people got a lot more careful about mounting
mvs packs on vm strings.

misc. CKD technology:

disk (or dasd) "strings" were a number of drives that shared the same
control unit. in the days of 3330s .... all of these had
removeable/mountable disk packs. a multi-track search .... was a
controller/device i/o operation that looked for a string match. A
multi-track search .... could search all 19 tracks of a 3330 w/o
finding a match ... and then switch to the next cylinder and do it
again. Worst case per operation was 19 revolutions at 60 revs/sec
... or slightly under 1/3rd sec. per operation. The operation had the
characteristic of making both the drive and the controller busy. A
shared controller might have 16 drives .... in which case, during a
multi-track operation to any one drive it wasn't possible to access
any of the other (possibly 15) drives.

it turns out that while vm/cms supported CKD disks ... it didn't make
use of the multi-track search paradigm .... since the original days of
cms in the mid-60s ... it used a fixed-block paradigm ... and if
necessary emulated that on CKD devices.

one of the tso (interactive) thruput issues running on any of the
operating systems that made heavy use of the CKD multi-track paradigm
... they didn't know that their thruput was always in the toilet
... because they had no reference of not operating in that mode.

while doing some work in the engineering lab ....
http://www.garlic.com/~lynn/subtopic.html#disk
I did an optimized paging access method implementation
http://www.garlic.com/~lynn/submain.html#mmap
demonstration using both (software) emulated fixed-block on CKD as
well as real (3370) fixed-block devices ... that showed three times
thruput increase compared to typical multi-track searce based
environments ... and then worked on the case for having MVS support
fixed-block devices. STL came back that even if given fully tested
code for MVS ... that it was still a $26m cost to release it. Instead
they started down the ECKD path ... just that cost was eventually much
more than $26m ...  not to mention all the subsequent hardware
gyrations/costs because all disks are now really fixed-block and CKD
operation has to be emulated in the hardware.

random past ckd/multi-track postings:
http://www.garlic.com/~lynn/93.html#29 Log Structured filesystems -- think twice
http://www.garlic.com/~lynn/94.html#35 mainframe CKD disks & PDS files (looong... warning)
http://www.garlic.com/~lynn/97.html#16 Why Mainframes?
http://www.garlic.com/~lynn/97.html#29 IA64 Self Virtualizable?
http://www.garlic.com/~lynn/99.html#75 Read if over 40 and have Mainframe  background
http://www.garlic.com/~lynn/2000.html#86 Ux's good points.
http://www.garlic.com/~lynn/2000c.html#34 What level of computer is needed for a computer to Love?
http://www.garlic.com/~lynn/2000f.html#18 OT?
http://www.garlic.com/~lynn/2000f.html#19 OT?
http://www.garlic.com/~lynn/2000f.html#42 IBM 3340 help
http://www.garlic.com/~lynn/2000g.html#42 4M pages are a bad idea (was Re: AMD 64bit Hammer CPU and VM)
http://www.garlic.com/~lynn/2000g.html#51 > 512 byte disk blocks (was: 4M pages are a bad idea)
http://www.garlic.com/~lynn/2000g.html#52 > 512 byte disk blocks (was: 4M pages are a bad idea)
http://www.garlic.com/~lynn/2001.html#19 Disk caching and file systems.  Disk history...people forget
http://www.garlic.com/~lynn/2001c.html#17 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001d.html#60 VTOC/VTOC INDEX/VVDS and performance (expansion of VTOC position)
http://www.garlic.com/~lynn/2001d.html#64 VTOC/VTOC INDEX/VVDS and performance (expansion of VTOC position)
http://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)
http://www.garlic.com/~lynn/2002.html#5 index searching
http://www.garlic.com/~lynn/2002.html#6 index searching
http://www.garlic.com/~lynn/2002.html#10 index searching
http://www.garlic.com/~lynn/2002c.html#48 Swapper was Re: History of Login Names
http://www.garlic.com/~lynn/2002d.html#22 DASD response times
http://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?
http://www.garlic.com/~lynn/2002f.html#8 Is AMD doing an Intel?
http://www.garlic.com/~lynn/2002g.html#13 Secure Device Drivers
http://www.garlic.com/~lynn/2002l.html#47 Do any architectures use instruction count instead of timer
http://www.garlic.com/~lynn/2002l.html#49 Do any architectures use instruction count instead of timer
http://www.garlic.com/~lynn/2002n.html#50 EXCP
http://www.garlic.com/~lynn/2002o.html#46 Question about hard disk scheduling algorithms

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

vax6k.openecs.org rebirth

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vax6k.openecs.org rebirth
Newsgroups: alt.folklore.computers,comp.sys.prime
Date: Sat, 04 Jan 2003 18:09:10 GMT

Anne & Lynn Wheeler writes:

for ecps, at boot ... there was a list of all the ecps instructions
thru-out the kernel ... if ecps wasn't available on the machine
... all those instructions got no-oped ... and the kernel effectively
dropped thru to the software instructions. if the ecps instruction was
executed ... it continued after the instructions it replaced (as
opposed to the following instruction). in some of the VAMPS cases
... it would have bypassed large bodies of instructions.

and when the standard multiprocessing support shipped ... you had
binaries (text decks) for both multiprocessing and non-multiprocessing
..  and kernels built with the multiprocessing binaries and kernels
built with the non-mulitprocessing binaries. a multiprocessing kernel
could run on a non-multiprocessor ... and a non-multiprocessing kernel
could run on a multiprocessor (just use only single cpu).

in addition to the ecps methodology ... it is also straight forward to
have VAMPS binaries ... and VAMPS kernel ... which would run in
vanilla single processor mode if it wasn't on a VAMPS multiprocessor.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

vax6k.openecs.org rebirth

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vax6k.openecs.org rebirth
Newsgroups: alt.folklore.computers,comp.sys.prime
Date: Sat, 04 Jan 2003 18:30:21 GMT

Anne & Lynn Wheeler writes:

and when the standard multiprocessing support shipped ... you had
binaries (text decks) for both multiprocessing and non-multiprocessing
..  and kernels built with the multiprocessing binaries and kernels
built with the non-mulitprocessing binaries. a multiprocessing kernel
could run on a non-multiprocessor ... and a non-multiprocessing kernel
could run on a multiprocessor (just use only single cpu).

in addition to the ecps methodology ... it is also straight forward to
have VAMPS binaries ... and VAMPS kernel ... which would run in
vanilla single processor mode if it wasn't on a VAMPS multiprocessor.

and for even more thread drift ....

when i originally did the fair share scheduling and the paging
algorithm and the other resource manager stuff on cp/67 while an
undergraduate in the late '60s ... i did all this dynamically adaptive
stuff. In the translation from cp/67 to vm/370 all of that was dropped
in the product.
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock

the initial standard vm/370 product went out with a table of cpuids
(cpu model numbers) in the boot (dmkcpi) routine and boot/ipl did
various things based on the model number.

I retrofitted all the resource manager stuff including dynamic adaptive
to vm/370 ... which eventually shipped as the vm/370 resource manager
(first charged-for/priced kernel software product). One of the dynamic
adaptive things was to eliminate the processor model table and attempt
to do everything based on determining characteristics dynamically.

part of this was that the kernel had much longer life over a broad
range of products. an early version of this retrofit for vm/370 (along
with 30k to 40k lines of other kernel modifications) disappeared into
AT&T longlines .... and propagated there for something like ten years
across a broad range of processors (both non-clones and some
pcm/clones). Eventually somebody from the branch office responsible
for AT&T longlines tracked me down ... since the next model of machine
was XA-only .... and AT&T longlines had gotten use to this ten year
old kernel that dynamically adapted to all sorts of machine models,
machine configurations and loads.

the official version shipped as the resource manager was viewed with
suspicion in some quarters since it no longer had the cpuid/model
table ... and therefor was totally agnostic with regard to running on
official 370s or pcm/clone 370s.

... and another dynamic adaptive story

also as an undergraduate I put tty/ascii terminal support into cp/67.
cp/67 had this code already that dynamically attempted to identify
between kinds of 2741s and 1052s ... w/o having to pre-specify what
kind of terminal was on which port. I tried to integrate the tty/ascii
support in so that it operated in the same way (aka dynamically adapt
to the kind of terminaL). The terminal controller had a different
line-scanners for different kind of terminals .... and it was possible
to dynamically tell the terminal controller which line scanner to use
with which line (either hard-wired lines or dial-up lines). So i got
all of this working ... and proadly demo'ing it ... when one of the
ibm field service people pointed out to me that while the type of line
scanner was dynamically selectable ... they had taken a shortcut in
the controller implementation and hardwired oscillators to specific
lines.

this met that while i could dynamically switch a line from 2741 line
scanner to a tty/ascii line scanner, i couldn't switch the baud rate.

this prompted us to start a project at the university to build our own
terminal controller ... that supported both dynamic baud rate
determination as well as dynamic terminal type determination, This
also led to getting blamed for originating the pcm controller market
(and some rumor also responsible for the convulated nature of the
pu4/pu5 interface):
http://www.garlic.com/~lynn/subtopic.html#360pcm

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

cost of crossing kernel/user boundary

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: cost of crossing kernel/user boundary
Newsgroups: comp.arch
Date: Sun, 05 Jan 2003 13:49:08 GMT

"Andy Glew" writes:

You've said this before.
What was Charlie's full name?

past answers (compare&swap mnemonic ... includes pointers to POP and
programming notes):
http://www.garlic.com/~lynn/99.html#89 FIne-grained locking
http://www.garlic.com/~lynn/2001f.html#41 Test and Set (TS) vs Compare and Swap (CS)

somewhat aside .... during project athena days (half funded by dec,
half funded by ibm) .... jerry saltzer was director ... charlie was
asst. director (or whatever they called the position) on the ibm side
... and i forget who it was on the dec side?

when we were doing ha/cmp ... we subcontracted much of the software
development to company that started out as some number of people
having worked at project athena (all within half mile or so
of tech sq). other past trivia
http://www.garlic.com/~lynn/2000d.html#68 "all-out" vs less aggressive designs

in the above, i watched as they pried the letters off the building
... i keep thinking that i needed to ask the guy if I could have one
of the letters.

other stuff from by-gone days:
http://www.garlic.com/~lynn/subtopic.html#545tech

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Message (authentication/integrity); was: Re: CRC-32 collision

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Message (authentication/integrity); was: Re: CRC-32 collision
 rate
Newsgroups: sci.crypt
Date: Sun, 05 Jan 2003 15:59:39 GMT

"Tom St Denis" writes:

I don't know why you're making a big deal of it.  The distinctions are quite
clear.  If you want to detect medium errors then a simple integrity check is
all you need.  If you want to check that the messages are authentic, that is
the message is intact and attributed to a specific sender, then you need a
digital signature or MAC.

CRCs, FEC, HASH, detect &/or correct random errors .... and help with
detecting if the integrity of the message is intact

purposeful errors can defeat simple CRCs, FEC, HASH ... with resulting
loss of the ability to detect if the integrity of the message is
intact.

encryption of the hash can help with integrity issues of purposeful
errors.

business processes that control who has access to the encrypting key
(used for encrypting the hash) .... can be used to infer who sent the
message.

the act of encrypting the hash doesn't establish the sender ... it is
the business process controlling who has access to the key used for
the encryption that establishes the sender.

that still doesn't necessarily establish authentic in the real world
.... in the real world ... an authentic message would also imply that
the sender wrote the message. this is touched on various past
non-repudiation threads; one scenario was the use of public key
encryption in a challenge/response scenario ... the sender may be
signing something that they didn't write (say as part of some sort of
access control challenge/response protocol).

1) message wasn't altered in transit
2) message originated from specific sender
3) message was authored by the sender

both #2 and #3 require various kinds of business processes ... in
addition to simply using an asymmetric key for encrypting a hash.

random refs:
http://www.garlic.com/~lynn/subpubkey.html#privacy x9.59, identity, authentication, and privacy

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

vax6k.openecs.org rebirth

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vax6k.openecs.org rebirth
Newsgroups: alt.folklore.computers
Date: Sun, 05 Jan 2003 22:04:32 GMT

"Charlie Gibbs" writes:

Famous Last Words #1: "Oh, don't worry about that; it'll never happen."

actually the response was i thot i had fixed all of the prg9. the other
prg9 that got me was when somebody pushed stop button in the middle of
that loop (or a couple other timing sequences that i had in DMKSTP)
... resulting in time-intervals that were ridiculously long ... as
opposed to ridiculously short (both could result in prg9).

the other response was that i originally wrote the specific code over
25 years ago in an era when

1) kernels were only built for possibly a (or limited number of)
specific machine model(s).

2) were typically decommited within five years by the vendor

this was one of the first attempts to make dynamically adaptive kernel
across a really wide range of machine models (both non-clone & clone)
and over a fairly wide range of time.

several thousand benchmarks went into calibrating the resource manager
with fairly detailed performance data down to subprocess level
... along with a fairly detailed model of the algorithms. we would put
a synthetic mixed-mode workload on that totally saturated the machine
...  and then do a whole series of additional benchmarks incrementally
changing the workload (adding/subtracting various kinds of processes).
the resulting detailed monitor information as to the overal system
execution characteristics as well as the moment to moment execution
characteristics of the individual processes had to correspond to the
model.

this was possibly the only product (at the time, still?) that accepted
customer bug reports when the real life operation of the resource
manager deviated from the algorithm specifications (traditionally the
response has been "broken as designed").

random refs:
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock
http://www.garlic.com/~lynn/submain.html#bench

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

vax6k.openecs.org rebirth

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vax6k.openecs.org rebirth
Newsgroups: alt.folklore.computers
Date: Sun, 05 Jan 2003 22:44:09 GMT

jmaynard@thebrain.conmicro.cx (Jay Maynard) writes:

As it happens, this one's not that far wrong. I don't know if it happens in
VM/SP, but the error only occurs on a system that breaks 7.5 MIPS on a
single CPU in a tight BCTR loop, and I'm not sure any real iron ever ran in
370 mode that fast - and I really doubt that anyone ever ran the
unmodified VM/370 on one that did. (The interval timer resolution, as
checked by this routine, is 1/300 second.) I doubt anyone tripped over it
until Hercules.

it ran on 3081Ks in 370 mode ... where DMKCPI should come up on a CPU
rated 7mips for general instruction mix (so a tight BCTR loop Could
have on the order of possibly twice that). It also ran on some number
of 370-clones that had processors rated for general instruction mix
over 7mips.

note ... however ... the resource manager in both DMKCPI and DMKSTP
used the store timer instruction ... 64bit value with bit twelve
defined to be a microsecond (and bit 32 was just slightly more than 1
second). Machines could have higher or lower resolution than a
microsecond ... but bit twelve was a microsecond ...  also two
back-to-back stores were supposed to be defined as storing different
values.

the location 80 timer had been used in cp/67 ... because that was the
only timer on the 360/67 ... but everything would have been coverted
to store clock for 370 & vm/370. There were actually three 64bit values ...

1) the TOD clock ...
2) the clock comparator .... which would generate an interrupt
when the TOD clock value and the clock comparator were the same
3) the interval timer that decremented at the same rate as the TOD clock
incremented

the interval timer and the tod clock had the same resolution ... 64
bits and bit 12 being one microsecond.

this 370 64-bit interval timer is different than the location 80
32-bit interval timer from 360 days. one of the reasons that the
location 80 interval timer was depreciated in the 370 ... was that it
updated real memory ... which required getting the memory bus and
storing into real memory on every tic. 360s would have hardware
failures if the timer function couldn't obtain the memory bus for the
timer value updates (say because of processor and/or i/o activity).

the low-end 360s and the 370s 32bit location 80 timer were tic'ed
1/300 second ... every 3.3mills (real storage update issues).  the
360/67 had a high resolution 32-bit location 80 timer that tic'ed once
every 13.?microseconds (had more real-storage update issues). The
32bits counted about 14?hrs elapsed time (wether they tic'ed at
3.3millis or 13.?microseconds)

all of the 370s tic'ed their 64bit timers at well under millisecond
intervals ... been awhile but i believe in the low tens or even single
digit microseconds.

kernel calculations would typically pickup the resulting 64bit value
... calculate the difference between starting and end ... and then do
shift right logical 12 bits ... putting microsecond in bit 0. Then if
you continued with 32bit arithmatic you had a maximum value of about
4k seconds with microsecond resolution ... supplied by hardware that
typically tic'ed on the order of at least tens of microseconds (for
the slower speed machines ... say rated in the kips rather than mips)
and for higher speed machines the tic rate was to increase to less
than microseconds (although most calculations shifted out the bits
less than microsecond).

So my resource manager code on a high MIP machine that tic'ed at least
once a microsecond .... would have been computing the BCTR loop based
on the elapsed time measured in microseconds (and count up to 4k
seconds).

The problem i ran into early with the prg9 failure in the calculations
was somebody pressing the stop button in the middle of the timer
calculations ... and the calculations overflowing 4k seconds (stop
buttom pressed for least 70 minutes or so ... and then starting up
again).

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Multics preservation: good news

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Multics preservation: good news
Newsgroups: alt.os.multics,alt.folklore.computers
Date: Sun, 05 Jan 2003 22:48:12 GMT

"Shmuel (Seymour J.) Metz" writes:

360/70 (never shipped)
360/75

there were 360/60, 360/62, & 360/70 ... all designed to ship with 1mic
memory. the 750nsec memory came along and the models with higher speed
memory became 360/65, 360/67, and 360/75 (and 60, 62, & 70 never shipped).


note/update:

I remember reading an early document about 360/6x machine with virtual
memory having one, two, and four processors. I sort of had vaque
recollection that it was model number other than 360/67.

however, i've subsequently been told that 360/60 was with 2mic memory
and 360/62 was with 1mic memory. both models never shipped, and were
replaced with 360/65 with 750ns memory. the 360/67 then shipped as
360/65 with virtual memory ... only available in one (uniprocessor)
and two processor (multiprocessor) configurations

http://www.garlic.com/~lynn/2006m.html#50 The System/360 Model 20 Wasn't As Bad As All That


--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

vax6k.openecs.org rebirth

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vax6k.openecs.org rebirth
Newsgroups: alt.folklore.computers
Date: Mon, 06 Jan 2003 01:02:23 GMT

Anne & Lynn Wheeler writes:

note ... however ... the resource manager in both DMKCPI and DMKSTP
used the store timer instruction ... 64bit value with bit twelve
defined to be a microsecond (and bit 32 was just slightly more than 1
second). Machines could have higher or lower resolution than a
microsecond ... but bit twelve was a microsecond ...  also two
back-to-back stores were supposed to be defined as storing different
values.

here is the official description ... but they are counting bits from
the opposite end ... the microsecond bit is position 51 (but i still
shift right logical 12 bits ... to move it into the low order bit
position; 32bit value giving 4kseconds counted in number of
microseconds:
http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/4.6.4?DT=19970613131822

specifically from above:

The CPU timer is a binary counter with a format which is the same as
that of the TOD clock, except that bit 0 is considered a sign. In the
basic form, the CPU timer is decremented by subtracting a one in bit
position 51 every microsecond. In models having a higher or lower
resolution, a different bit position is decremented at such a
frequency that the rate of decrementing the CPU timer is the same as
if a one were subtracted in bit position 51 every microsecond. The
resolution of the CPU timer is such that the stepping rate is
comparable to the instruction-execution rate of the model.

======

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

vax6k.openecs.org rebirth

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vax6k.openecs.org rebirth
Newsgroups: alt.folklore.computers
Date: Mon, 06 Jan 2003 01:32:42 GMT

given the official timer description .... the prg9 could occur if the
whole bctr loop was executed in less than one microsecond elapsed time
or greater than 4k seconds elapsed time (but i thot i had fixed the
prg9s sometime in the past ... oh well).

a machine that could execute the bctr loop in less than one
microsecond would have "stepping" of the clock at finer resolution
than one microsecond .... but the shift operation would result in the
timed interval being rounded down to one microsecond resolution (aka
the full clock definition has ability for providing on the order of .2
nanosecond in the low order bit position).

if the current mechanism is tripping (prg9 exception) when the loop
executes at a rate of 7mips and takes less than 3.3milliseconds
.... then if the actual hardware clock definition was implemented
... the effective mip rate would have to be 3333 times that in order
to lead to the prg9 (executing the loop in less than 1 microsecond) or
a machine running at around 23,331 mips.

I know that the original code ran on machines on the order of 50kips
(.05mips) ... trying to provide dynamic adaptive capability across a
period of more than 30 years ... and from .05mips to 23,331mips (close
to six orders of magnitude range) wouldn't seem unreasonable.

also referencing the previous document ... it lists the location 80
timer being dropped in the transition from 370 to 370/xa
http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/F.3.5?DT=19970613131822

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

vax6k.openecs.org rebirth

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vax6k.openecs.org rebirth
Newsgroups: alt.folklore.computers
Date: Sun, 05 Jan 2003 19:23:10 -0700

trying to reconstruct the location 80 timer.

the shift of the 370 cpu timer ... resulted low order bit position
one microsecond and nearly 70 minutes of time for 32bit number.

the high resolution location 80 on the 360/67 ... tic the low order
bit position something like 13.6microseconds and gave 14 or 15hr
measurement in 32bits ....

13.6 times 70 minutes gives 15.8hr measurement.

tic'ing the 8th bit once every 1/300 sec ,,, yields a measurement
interval of 15.4hrs (32bit number). that means that the high
resolution timer that tic'ed bit zero ... was actually
13.02microseconds ... not 13.6microseconds.

now the location 80 timer would cause a machine check "red light" if
it was unable to obtain the memory bus to update real location 80.
basically there was almost a full tic window ... a update for storage
would go pending with a tic .... if the next tic happened before the
storage was updated for the previous tic ... the machine would red
light.

we experienced this on the 360/67 at the university when we were
developing the first 360 non-ibm (i.e. clone) controller.
http://www.garlic.com/~lynn/subtopic.html#360pcm

the channel interface had been reverse engineered and a channel
interface board had been built for the 360/67 channel. Some of the
early testing resulted in "red lighting" (aka machine check) the
machine. The controller got the channel interface ... and thru it, the
memory bus and was transfering data .... but held it continuously for
more than a tic interval (and voila a machine check).  some amount of
additional engineering had to be done to make sure that the channel
interface (and therefor the memory bus) was released at least once
every timer tic interval.

it was much more of a problem on the 360/67 with the high resolution
timer and 13.02 microsecond windows ... than on the slower speed 360s
... or the 370s ... with tics only happending every 3.3mills.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

vax6k.openecs.org rebirth

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vax6k.openecs.org rebirth
Newsgroups: alt.folklore.computers
Date: Mon, 06 Jan 2003 01:54:21 GMT

... and if it is really failing because it is using location 80 timer
...  (stepping at 3.3mills) then it ain't my code .... because all of
my stuff used cpu timer.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

vax6k.openecs.org rebirth

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vax6k.openecs.org rebirth
Newsgroups: alt.folklore.computers
Date: Mon, 06 Jan 2003 04:51:25 GMT

Brian Inglis writes:

It's been a decade or so since I did this, so I may have
forgotten some details about how things were done, and what goes
where, but weren't the ASSEMBLE files the original product
release sources, e.g. VM/370, BSEPP, SEPP, HPO, XA, ESA, with all
subsequent changes being source or object updates on additional
MDISKs?

the resource manager had the updates for dynamically calculating the
dspslice based on the timed loop ... rather than value loaded from a
cpu model table in dmkcpi. i forget what i original called the update
files for the initial release of the resource manager (applied to
vm/370 release 3). 80 percent of the resource manager code was merged
into the release 4 assemble files (as part of multiprocessing support
in release 4) ... with the rest of the code staying in the resource
manager.  Resource manager combined with some other stuff for SEPP for
release 5 (including the dmkcpi timed loop ... again update
files). for what would have been vm/370 release 7 ...  it was renamed
vm/sp1 (with the code to DMKCPI now appearing in base assemble files
as opposed to update)

the resource manager were update files ... except for two new assemble
files DMKSTP ASSEMBLE and DMKSRM ASSEMBLE.

STP was taken from '60s televison advertisement ... the racer's edge.

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

Multics preservation: good news

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Multics preservation: good news
Newsgroups: alt.os.multics,alt.folklore.computers
Date: Mon, 06 Jan 2003 14:02:28 GMT

"Shmuel (Seymour J.) Metz" writes:

Weren't the 60 and 62 "microprogrammed"?

as far as i could tell 60 & 62 were same was 65 & 67 but with 1mic
memory instead of 750ns memory.

sorry ... i wasn't commenting on hardwired issue .... it was that
70, 62, & 60 all had in common was that they were for 1mic memory
and didn't ship .... and 75, 67, & 65 were presumably essentially
the same models but with the faster memory (and whatever other
changes were necessary).

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Message (authentication/integrity); was: Re: CRC-32 collision

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Message (authentication/integrity); was: Re: CRC-32 collision
 rate
Newsgroups: sci.crypt
Date: Mon, 06 Jan 2003 14:10:54 GMT

Anne & Lynn Wheeler writes:

random refs:
http://www.garlic.com/~lynn/subpubkey.htm#privacy x9.59, identity, authentication, and privacy

finger slip on some past non-repudiation
http://www.garlic.com/~lynn/subpubkey.html#privacy

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Round robin IS NOT load balancing (?)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Round robin IS NOT load balancing (?)
Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Date: Tue, 07 Jan 2003 03:00:51 GMT

arielgont@softhome.net (Fernando Gont) writes:

I mean, the client should try the next IP address returned by the
nameserver.

there are all sorts of things in this world thst should ... however,
some number of apps ... don't handle multiple A-records at all.

At least at some time in the past ... if there wasn't an example of it
in a tcp/ip college text ... then some large amount of the world
didn't believe it was possible.

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

asynchronous CPUs

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: asynchronous CPUs
Newsgroups: alt.os.multics,alt.folklore.computers
Date: Tue, 07 Jan 2003 20:19:36 GMT

Tom Van Vleck writes:

Recent articles that talk about how this new idea of
asynchronous design could make machines faster and more
efficient don't mention that the idea was used long ago.
Which CPUs of yore were asynchronous and which had master
clocks?

LSM (los gatos simulation machine ... or logic simulation machine
... depending on if the external sanitized version was used) ... could
simulate asynchronous activity. all of the hardware simulaters
following the LSM used a short cut and assumed a synchronous clock for
the logic.

LSM supported clock specification ... allowing simulation of
asyhncronous chips ... as well as digital/analog chips ... aka used
for the original disk thinfilm read/write heads.

random past refs to LSM:
http://www.garlic.com/~lynn/2002d.html#3 Chip Emulators - was How does a chip get designed?
http://www.garlic.com/~lynn/2002g.html#55 Multics hardware (was Re: "Soul of a New Machine" Computer?)
http://www.garlic.com/~lynn/2002g.html#77 Pipelining in the past
http://www.garlic.com/~lynn/2002g.html#82 Future architecture
http://www.garlic.com/~lynn/2002j.html#26 LSM, YSE, & EVE

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

Mainframe System Programmer/Administrator market demand?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframe System Programmer/Administrator market demand?
Newsgroups: bit.listserv.ibm-main
Date: Tue, 07 Jan 2003 21:26:12 GMT

Anne & Lynn Wheeler writes:

one of the oursourcing complexities is creating a larger disconnect
between the users/clients of the data processing service and the
actual service ... things tend to be much more contractual and formal
(and using a boyd'ism ... creates resistance and reduces agility, boyd
has some number of commercial examples .... but a military was why
does the army want its own close air support rather than relying on
the air force).

where there is little need for agility (because of no evolving
circumstances and changing requirements) ... aka a relatively static
environment ... then the lack of agility has little impact.

the counter argument is outsourcing may bring higher trained data
processing specialists which can more than compensate for the
resistance introduced by a more formal contractual relationship.

the other classical failure is where there is active animosity between
the users and the executives making the out-sourcing decision
(resulting in all kinds of subversion).

boyd OODA-loops and high agility for competitive rapidly changing
environments:
http://www.garlic.com/~lynn/subboyd.html#boyd

... and article on the subject

Managing the Outsourcing Relationship

http://itmanagement.earthweb.com/netsys/article.php/1565251

Managing the Outsourcer Relationship
January 7, 2003
By Drew Robb

Doing everything yourself may sound great, but it quickly becomes
tedious and inefficient. So we outsource everything from pumping our
water to ironing our shirts and educating our children, focusing
instead on our core functions.

snip

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

Round robin IS NOT load balancing (?)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Round robin IS NOT load balancing (?)
Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Date: Wed, 08 Jan 2003 04:50:41 GMT

marka@isc.org (Mark Andrews) writes:

I doubt if many of the application writers have actually thought
about their decision to only try one address.

when we were working with this little client/server startup on getting
the server doing financial transactions (sometimes referred to now as
electronic commerce) we had some say about the server to payment
gateway part and could require things like multiple a-record support
(and some number of other things) ... but we had little influence over
the client part at the time .... other then nagging them about it and
when they complained about it being too advanced ... showing examples
from client code from old implementation sources.

random refs:
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

Calculating expected reliability for designed system

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Calculating expected reliability for designed system
Newsgroups: comp.arch
Date: Wed, 08 Jan 2003 19:33:33 GMT

jason_watkins@pobox.com (Jason Watkins) writes:

For most hardware you should be able to find out the MTBF, though it
may require going to compaq's suppliers.
Other than that, I know there's some usable data from the tera disk
project. H&P 3rdEd also has a section that may have some numbers you
can cite.
I recall one signifigant finding is that controller and cabling
componants were as much a problem as disks themselves.

mainframes have had erep recording for 40? years. For well over 30
years some company (r-star or something) has been collecting erep logs
from customers and publishing summaries about all the stats. I got
sort of caught because I had worked on some software simulation for
some (hyperchannel) channel extender of i/o devices ... and when there
was an unrecoverable telco error .... i faked a form of channel error
... then kicked of various error recording and and recovery actions.

when the 3090 had been in customer shops for a year ... some corporate
guy tracked me down trying to figure out some skewed data from the
public reports. they had projected five total errors of particular
kind across all machines at all customer installations for 12 month
period. the stats from the reporting company was showing that a total
of something like 15 such errors had been recorded (this is not total
per machine per year ... this is total across all machines for 12
months) ... and there was serious concern about the difference between
the projected five and the reported 15 ... which turns out to have
been the error indication i had selected. turns out that i could
change the simulated error to a different kind ... and still kick-off
effectively the same error recovery process.

note that while some vendors talked at:
http://www.hdcc.cs.cmu.edu/may01/index.html

nobody was giving up any kind of numbers ... at least not in that
particular market segment

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

Round robin IS NOT load balancing (?)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Round robin IS NOT load balancing (?)
Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Date: Wed, 08 Jan 2003 20:03:59 GMT

Anne & Lynn Wheeler writes:

http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

one of those brain/finger slips ... "htm" not "html":
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

mainframe

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: mainframe
Newsgroups: bit.listserv.ibm-main
Date: Thu, 09 Jan 2003 14:39:32 GMT

Terry Sambrooks writes:

At one time mainframes, at least in the IBM sense, could be produced by
IBM, Amdahl, Fujitsi, and Hitachi to name but four.

at least by some, amdahl was a fujitsu subsidiary ... and NAS was a
Hitachi subidiary. i was at a talk that amdahl gave on the mit campus
in the early 70s ... where he really got grilling about the fujitsu
content (investment, manufacturing, etc).

by the early '80s there was also a number in of 2nd tier(?) clones in
the low/mid-range marketplace. recent discussions:
http://www.garlic.com/~lynn/2003.html#10 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

from earlier ... non-clones/non-PCM there use to be snow white and the
seven dwarfs ... or the BUNCH:
http://www.garlic.com/~lynn/2002o.html#78 Newsgroup cliques?

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

Calculating expected reliability for designed system

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Calculating expected reliability for designed system
Newsgroups: comp.arch
Date: Thu, 09 Jan 2003 15:08:21 GMT

"del cecchi" writes:

To steal Lynn Wheeler's thunder, isn't that why the mainframe guys
developed all that automated operator stuff?  One doof deleting the
wrong file, or sticking in the wrong floppy/mounting the wrong tape and
you just blew the .5% (40 hours/year) for the next year.  Install a bad
device driver.  you know the drill.

yes, well ... we were in this meeting with the guy responsible for a
large financial transaction backbone ... who claimed the primary
reason for one hundred percent availability for the previous six+
years was: 1) ims hot-standby, and 2) automated operator
http://www.garlic.com/~lynn/94.html#2 Schedulers
http://www.garlic.com/~lynn/99.html#71 High Availabilty on S/390
http://www.garlic.com/~lynn/99.html#107 Computer History
http://www.garlic.com/~lynn/99.html#128 Examples of non-relational databases
http://www.garlic.com/~lynn/99.html#136a checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/2000.html#22 Computer of the century
http://www.garlic.com/~lynn/2000f.html#12 Amdahl Exits Mainframe Market
http://www.garlic.com/~lynn/2001.html#43 Life as a programmer--1960, 1965?
http://www.garlic.com/~lynn/2001c.html#13 LINUS for S/390
http://www.garlic.com/~lynn/2001d.html#70 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001d.html#71 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001e.html#44 Where are IBM z390 SPECint2000 results?
http://www.garlic.com/~lynn/2001e.html#47 Where are IBM z390 SPECint2000 results?
http://www.garlic.com/~lynn/2001h.html#8 VM: checking some myths.
http://www.garlic.com/~lynn/2001k.html#14 HP-UX will not be ported to Alpha (no surprise)exit
http://www.garlic.com/~lynn/2001k.html#18 HP-UX will not be ported to Alpha (no surprise)exit
http://www.garlic.com/~lynn/2001l.html#47 five-nines
http://www.garlic.com/~lynn/2001n.html#47 Sysplex Info
http://www.garlic.com/~lynn/2001n.html#85 The demise of compaq
http://www.garlic.com/~lynn/2002.html#24 Buffer overflow
http://www.garlic.com/~lynn/2002e.html#68 Blade architectures
http://www.garlic.com/~lynn/2002h.html#73 Where did text file line ending characters begin?
http://www.garlic.com/~lynn/2002l.html#62 Itanium2 performance data from SGI
http://www.garlic.com/~lynn/2002n.html#27 why does wait state exist?
http://www.garlic.com/~lynn/2002o.html#14 Home mainframes
http://www.garlic.com/~lynn/2002p.html#54 Newbie: Two quesions about mainframes

when we were doing ha/cmp we also talked to guys developing 1-800
number system ... who were looking at a fault tolerant computer
... that would have to be taken down to do software
maint/upgrade. Doing this just once a year blew a minimum of five
years of budgeted/allowed outage. a replicated/fall-over solution
addressed the outage for software maint/upgrade ... but also subsumed
the advantage of having a fault tolerant computer.
http://www.garlic.com/~lynn/96.html#36 Mainframes & Unix (and TPF)
http://www.garlic.com/~lynn/99.html#143 OS/360 (and descendents) VM system?
http://www.garlic.com/~lynn/2001g.html#58 TECO Critique
http://www.garlic.com/~lynn/2001k.html#10 HP-UX will not be ported to Alpha (no surprise)exit
http://www.garlic.com/~lynn/2002e.html#67 Blade architectures

there are lots of other characteristics for well designed system.
when wereworking on this thing called a payment gateway for this thing
that came to be called electronic commerce ... one of the issues was
diagnosing the end to end environment ... if you got a problem call,
you wanted to be able to do first level problem determination within
five minutes ... not have it turn into NTF (no trouble found) after
three hrs.
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
http://www.garlic.com/~lynn/aadsm5.htm#asrn2

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

Calculating expected reliability for designed system

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Calculating expected reliability for designed system
Newsgroups: comp.arch
Date: Fri, 10 Jan 2003 14:56:24 GMT

Anne & Lynn Wheeler writes:

when we were doing ha/cmp we also talked to guys developing 1-800
number system ... who were looking at a fault tolerant computer
... that would have to be taken down to do software
maint/upgrade. Doing this just once a year blew a minimum of five
years of budgeted/allowed outage. a replicated/fall-over solution
addressed the outage for software maint/upgrade ... but also subsumed
the advantage of having a fault tolerant computer.

... I think it was actually expected to be closer to 100 years of
outage budget for scheduled maint. As systems have moved into more &
more business critical operations .... the end users have become less
& less tolerant of outages (if you have ever participated in weekly
user datacenter confrontation ... where the users detail everything
that went wrong for the past week .... they don't care why they
couldn't get their work done). This has resulted in expanding the
view of outages (regardless of cause) to end-to-end systemic
operation.

we coined the terms disaster survivability and geographic
survivability to try and highlight some of these business critical
issues ... distinquishing from simpler disaster/recovery scenarios.

there was one weekend in the early '90s that a lot of people couldn't
get money out of atm machines .... most of them didn't really care
that the roof of the primary datacenter had collapsed with snow load
... and the backup datacenter was out because of the WTC bombing.

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

Flex Question

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Flex Question
Newsgroups: bit.listserv.ibm-main
Date: Fri, 10 Jan 2003 15:24:29 GMT

pdw@MARCDATABASE.COM (Peter D. Ward) writes:

I believe Ed's reading of the rationale on Pat's I/O paper is exactly
spot on.  I also think Pat's conclusion, that modern Intel hardware
provides an I/O subsystem meeting the throughput needs of the emulated
Flex-ES CPU, will hold true even as Flex-ES moves up the CPU mippage
scale.

I believe that one of the significant flex-es delivery platforms
had/has been (is) sequent .... scalable numa achitecture (sci with up
to 256 processors). that may have been complicated when ibm bought
sequent.

at least sequent, data-general, and convex have all done scalleable
numa implementations with sci.

there is both the issue of direct processor instruction emulation
thruput as well as various kinds of support operations. in the
standard mainframe line .... something similar can be seen in the
transition from 370 to 303x and integrated channels. Even tho the 3031
and the 158 were the same microprocessor .... the 158 shared the
microprocessor between 370 emulation and (integrated) channel
functions. For the 303x series ... a 158 engine was taken and had the
370 emulation removed ... leaving only the channel emulation microcode
and called it a 303x channel director.

In some sense, a single-processer 3031 was actually a multiprodcessor
system with two 158 microprocessor engines ... one with the dedicated
370 emulation and one with the dedicated channel function (instead of
both functions sharing a single microprocessor engine as in the
vanilla 370/158).

Earlier 115/125 was built on the same philosophy. The 370 115/125 had
a nine-position memory bus for microprocessers ... standard
configuration had one microprocessor with the 370 emulation ... and
from two up to eight other (same) microprocessors with other kinds of
microcode programs implementing other kinds of channel, controller,
and I/O functions. The only difference between 115 and 125 was that
the microprocessor used in the 125 for 370 emulation function ran
somewhat faster than the other microprocessors in the configuration.

One could draw a very close analogy between flex-es on an eight-way
SMP ... with the 115/125 implementation ... except running at a
significantly higher thruput rate.

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

InfiniBand Group Sharply, Evenly Divided

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: InfiniBand Group Sharply, Evenly Divided
Newsgroups: comp.arch
Date: Fri, 10 Jan 2003 18:16:57 GMT

young_r@encompasserve.org (Rob Young) writes:

One other method that is employed is to have a tie breaking
node at a 3rd datacenter.  This raises the availability.  It
isn't as common but is being done, no personal experience but
have been told.

the large financial transaction settlement network ... mentioned
recently in another thread in this n.g. ... attributing 100 percent
uptime for the previous six years ... to 1) ims hotstandy and 2)
automated operation ... does have third datacenter operation.

recent posts:
http://www.garlic.com/~lynn/2003.html#34 Calculating expected reliability for designed system
http://www.garlic.com/~lynn/2003.html#37 Calculating expected reliability for designed system
http://www.garlic.com/~lynn/2003.html#38 Calculating expected reliability for designed system

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

InfiniBand Group Sharply, Evenly Divided

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: InfiniBand Group Sharply, Evenly Divided
Newsgroups: comp.arch
Date: Sat, 11 Jan 2003 06:57:40 GMT

Jan Ingvoldstad <jani+news-comp@nntp.ifi.uio.no> writes:

But, as several people have put it:  Don't rely on DNS for _anything_
important.

actually the whole internet relies on DNS .... there was recent news
clip on a dos attack on some of the primary ... with a footnote that
it was fortunate that not all of the them were gotten ... or otherwise
the internet would have pretty much come to a halt. so at a macro
level ...  the whole internet relies on dns ... which puts it into the
important level.

now ... supposedly SSL was put into place to help catch some DNS
vulnerabilities.

basically both SSL and DNS have some common vulnerabilities
... basically master domain name registration databases. corrupting
those can result in DNS sending out bad data. Corrupting those also
means that a bad guy can go to a SSL certificate manufacturing
operation ... and get a valid certificate (since the CA/certificate
manufacturing checks the master domain name database as to valid
applications for SSL certificates).

from a client's standpoint ... dns can 1) not supply data (a DOS
attack), 2) supply bad data (aka ip-address spoof/take-over) and 3)
supply good data. SSL effectively addresses case #2 ... and turns it
into case #1 (or DOS attack).

SSL doesn't improve #2 into #3 (say like a forward error correcting
algorithm might), it is purely a detection and toss mechanism (meaning
that a bad data attack is turned into a DOS attack).

now wandering a bit (because of some recent threads in pkix and
elsewhere) ... i claim that it would be possible to eliminate the
current TTP certificate manufacturing (term we coined to differentiate
the current SSL infrastructure from a PKI) and replace it with one
where DNS distributed signed packets. The signed packets effectively
are a domain name, a public key, and a signature. A browser treats the
signed packets exactly like it treats an SSL certificate ... but
instead of getting it from a website it gets it from DNS.

My claim is that if the signing of the packets is done with the same
care as the current certificates ... there is no decrease
in the level of integrity (compared to the current DNS+SSL
environment) ... DOS attacks are not affected and the same bad data
attacks will be detected and turned into DOS attacks ... aka every
case where an ip-address is corrupted or replace ... will be detected
with the DNS distributed signed packets as with SSL certificates.

The advantage is that when there isn't corrupted data ... that a SSL
can be setup in single exchange .. since the client already has the
server's public key before the session initiation starts (there are
some amount of micro protocol efficiencies).

One of my objectives in making the proposal is an attempt to highlight
the actual DNS vulnerabilities ... and some of the macro level things
that might be necessary to address them.

bunch of stuff on ssl "comfort" certificates:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

some reference to early ssl related activities (this little
client/server startup that was in silicon valley before moving to
mountain view):
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
http://www.garlic.com/~lynn/aadsm5.htm#asrn2

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

basic pki question

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: basic pki question
Newsgroups: sci.crypt
Date: Sat, 11 Jan 2003 07:33:52 GMT

mdalbis@smartronix.com (usmcpsu) writes:

I may be dense but what is the difference between Public Key
Infrastructure and Private Key Infrastructure. The material I have is
no clear.  Also, from what I have read, the message will be encrypted
with a synnetric (secret) key which will be passed using the public (
asymmetric) key of the receiver. I have also read that the message can
be encrypted using the public ( asymmetric ) key of the receiver and
that a secre ( symmetric ) key will not be involved at all.  I figure
if this is worh knowing, it is worth knowing correctly.

asymmetric keys can be used to address an issue with key distribution.

one part of the pair can be made public ... and anybody wanting to
securely and privately communicate with you can use that public key
for encrypting messages ... and only you ... with the corresponding
asymmetric key can decrypt it.

now sometimes because asymmetric key encryption is too heavy duty
(compared to symmetric key encryption) ... a random symmetric secret
key is generated (for each message/session), the message encrypted
with the symmetric secret key ... and then just the symmetric secret
key encrypted with the public key ... and the combined encrypted
message and encrypted key are transmitted. again, only the person with
the corresponding asymmetric key can read the message ... since only
that key can decrypt the random symmetric secret key which is then
used to decrypt the actual message. This is effectively the common
SSL/HTTPS technique used by browsers for securing communication.

both cases, asymmetric cryptography is being used to address an issue
in cryptography associated with key distribution.

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

Timesharing TOPS-10 vs. VAX/VMS "task based timesharing"

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Timesharing TOPS-10  vs. VAX/VMS "task based timesharing"
Newsgroups: alt.folklore.computers
Date: Sat, 11 Jan 2003 15:48:07 GMT

jmfbahciv writes:

Nah.  It just has to do with OS philosophies and the tradeoffs that
had to be done in order to implement certain computing services.
I'm not very good at it but JMF was phenomenally(sp?) good at
discerning the philosophy of a piece of most code (probably not
compilers).  You can usually tell what kind of CPU architecture
was used when an OS got its start.  Which makes sense but its
a knowledge that seems to be getting lost.  I don't know if this
knowledge is worth keeping around for implementing new stuff.
Dennis and Lynn may have a better idea about how useful it is
for future work.

note one of the things that i tried to do when i first started
resource management back as undergraduate in the '60s with cp/67 was
to separate amount of resources from the granularity of
resource. cp/67 at the time ... based on certain kinds of activity
... changed both the graunularity of resource as well as the amount of
resource. People found that they could get unfair resources by
exhibiting certain types of activity.

i did this thing i called fair share scheduler ... but that was just
the default if no other specifications were made (explicit
specifications could provide all sorts of UNfair resource management).