List of Archived Posts

2006 Newsgroup Postings (12/17 - 12/23)

What's a mainframe?
IBM sues maker of Intel-based Mainframe clones
The Future of CPUs: What's After Multi-Core?
Why so little parallelism?
S0C1 with ILC 6
S0C1 with ILC 6
Multics on Vmware ?
vmshare
vmshare
Plurals and language confusion
The Future of CPUs: What's After Multi-Core?
The Future of CPUs: What's After Multi-Core?
The Future of CPUs: What's After Multi-Core?
The Future of CPUs: What's After Multi-Core?
IBM ATM machines
The Future of CPUs: What's After Multi-Core?
The Future of CPUs: What's After Multi-Core?
The Future of CPUs: What's After Multi-Core?
The Future of CPUs: What's After Multi-Core?
The Future of CPUs: What's After Multi-Core?
"The Elements of Programming Style"
"The Elements of Programming Style"
'Innovation' and other crimes
Multiple mappings
IBM sues maker of Intel-based Mainframe clones
Executing both branches in advance ?
Multiple mappings
The Future of CPUs: What's After Multi-Core?
The Future of CPUs: What's After Multi-Core?
"The Elements of Programming Style"
"The Elements of Programming Style"
The Future of CPUs: What's After Multi-Core?
Toyota set to lift crown from GM
NSFNET (long post warning)
Year-end computer bug could ground Shuttle
"The Elements of Programming Style"
SSL security with server certificate compromised

What's a mainframe?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What's a mainframe?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sun, 17 Dec 2006 15:53:44 -0700

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

in the following, "SJ" (san jacinto) was code name for rs/6000.

re:
http://www.garlic.com/~lynn/2006v.html#35 What's a mainframe?

"San Jacinto" morphed into RIOS and RS/6000, old news item


To: wheeler
Date: 25 August 1987, 14:39:42 EDT

>From this week's Management Information Systems Week...

IBM's Austin, Texas, manufacturing facility - where the RT was born -
is currently putting the final touches on a 10-mips Unix-based
workstation, code-named "San Jacinto," according to an industry source.

"It's a follow-on to the RT, due in the first or second quarter" said the
source. The San Jacinto will be Posix-compatible, as well.

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

as i've mentioned before RT originally started out with ROMP (chip)
and cp.r (written in pl.8) as followon to the office product division
displaywriter. when that project was killed, they decided to retarget
it to the unix workstation market ... subcontracting for a at&t unix
port with the same company that had done the pc/ix port.

misc. past romp, rios, 801, fort knox, etc posts
http://www.garlic.com/~lynn/subtopic.html#801

IBM sues maker of Intel-based Mainframe clones

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM sues maker of Intel-based Mainframe clones
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sun, 17 Dec 2006 16:41:15 -0700

phil@ibm-main.lst (Phil Payne) writes:

Purely interpretive execution has been done before and published - I
remember a book called "A Compiler Generator" in the early 1970s
that contained the complete source code for emulation of /360 code
on a /360 - the idea being that you could trace every instruction.

POK had something like that called "redcap". it was not only useable
to trace every instruction ... but also to trace all storage
references.

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

adapted it for tracing instructions and storage references for
application that did semi-automated program reorganization
... optimizing operation for virtual memory operation.

i had gotten involved in rewritting some of the redcap interfaces to
improve the operation/performance for use in the science center
application.

the science center application was used quite a bit internally by a
number of product developers .... for instance the IMS group in STL
made extensive use of it for analysing IMS execution.

eventually it was released as a product called Vs/Repack in the spring
of 76.

systems journal article describing some of the early work:

D. Hatfield & J. Gerald, Program Restructuring for Virtual Memory,
IBM Systems Journal, v10n3, 1971

misc. past posts mentioning redcap, program restructuring, vs/repack
http://www.garlic.com/~lynn/93.html#4 360/67, was Re: IBM's Project F/S ?
http://www.garlic.com/~lynn/93.html#5 360/67, was Re: IBM's Project F/S ?
http://www.garlic.com/~lynn/94.html#7 IBM 7090 (360s, 370s, apl, etc)
http://www.garlic.com/~lynn/99.html#68 The Melissa Virus or War on Microsoft?
http://www.garlic.com/~lynn/2000g.html#30 Could CDR-coding be on the way back?
http://www.garlic.com/~lynn/2001b.html#83 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001c.html#31 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001c.html#33 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001i.html#20 Very CISC Instuctions (Was: why the machine word size ...)
http://www.garlic.com/~lynn/2002c.html#28 OS Workloads : Interactive etc
http://www.garlic.com/~lynn/2002c.html#45 cp/67 addenda (cross-post warning)
http://www.garlic.com/~lynn/2002c.html#46 cp/67 addenda (cross-post warning)
http://www.garlic.com/~lynn/2002c.html#49 Swapper was Re: History of Login Names
http://www.garlic.com/~lynn/2002e.html#50 IBM going after Strobe?
http://www.garlic.com/~lynn/2002f.html#50 Blade architectures
http://www.garlic.com/~lynn/2003f.html#15 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#21 "Super-Cheap" Supercomputing
http://www.garlic.com/~lynn/2003f.html#53 Alpha performance, why?
http://www.garlic.com/~lynn/2003g.html#15 Disk capacity and backup solutions
http://www.garlic.com/~lynn/2003h.html#8 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003j.html#32 Language semantics wrt exploits
http://www.garlic.com/~lynn/2004c.html#21 PSW Sampling
http://www.garlic.com/~lynn/2004m.html#22 Lock-free algorithms
http://www.garlic.com/~lynn/2004n.html#55 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004o.html#7 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004q.html#73 Athlon cache question
http://www.garlic.com/~lynn/2004q.html#76 Athlon cache question
http://www.garlic.com/~lynn/2005.html#4 Athlon cache question
http://www.garlic.com/~lynn/2005d.html#41 Thou shalt have no other gods before the ANSI C standard
http://www.garlic.com/~lynn/2005d.html#48 Secure design
http://www.garlic.com/~lynn/2005h.html#15 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005j.html#62 More on garbage collection
http://www.garlic.com/~lynn/2005k.html#17 More on garbage collection
http://www.garlic.com/~lynn/2005m.html#28 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005n.html#18 Code density and performance?
http://www.garlic.com/~lynn/2005o.html#5 Code density and performance?
http://www.garlic.com/~lynn/2006b.html#15 {SPAM?} Re: Expanded Storage
http://www.garlic.com/~lynn/2006b.html#23 Seeking Info on XDS Sigma 7 APL
http://www.garlic.com/~lynn/2006e.html#20 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006e.html#46 using 3390 mod-9s
http://www.garlic.com/~lynn/2006i.html#37 virtual memory
http://www.garlic.com/~lynn/2006j.html#18 virtual memory
http://www.garlic.com/~lynn/2006j.html#22 virtual memory
http://www.garlic.com/~lynn/2006j.html#24 virtual memory
http://www.garlic.com/~lynn/2006l.html#11 virtual memory
http://www.garlic.com/~lynn/2006o.html#23 Strobe equivalents
http://www.garlic.com/~lynn/2006o.html#26 Cache-Size vs Performance
http://www.garlic.com/~lynn/2006r.html#12 Trying to design low level hard disk manipulation program

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

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Future of CPUs: What's After Multi-Core?
Newsgroups: alt.folklore.computers
Date: Mon, 18 Dec 2006 10:30:54 -0700

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

reports, VM/370 Modifications (RJ2906) and VM/370 Shared Modules
(RJ2928). These reports describe several associated paging system
enhancements and give further detail concerning the N.5 page
replacement algorithm

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

for some another reference to the above
http://www.garlic.com/~lynn/2006t.html#13 VM SPOOL question

has old email from 92 about run in with somebody had done some consulting
work at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

in the early 70s ... and more recently had designed the Amdahl Huron
database system and was working on the implementation. Part of the
discussion was that he was also involved at the time in co-author of
paper on LRU replacement algorithms ... in addition to replacement
algorithms as they applied to DBMS managing buffer caches.

for additional topic drift ... other recent posts about database buffer
caching
http://www.garlic.com/~lynn/2006m.html#32 Old Hashing Routine
http://www.garlic.com/~lynn/2006o.html#22 Cache-Size vs Performance
http://www.garlic.com/~lynn/2006r.html#31 50th Anniversary of invention of disk drives
http://www.garlic.com/~lynn/2006w.html#27 Generalised approach to storing address details

Why so little parallelism?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why so little parallelism?
Newsgroups: comp.arch,alt.folklore.computers
Date: Mon, 18 Dec 2006 11:32:12 -0700

eugene@cse.ucsc.edu (Eugene Miya) writes:

I know it's sitting at the Museum.

attached email was not long before we got told that the project was
being transferred and we weren't suppose to work on anything with more
than four processors.

it turned out that there was major product announcement later, but it
was by kingston, not us, and we never did do any scale-up
announcements. if you have anything in the computer museum, it didn't
come from us.

previous cluster-in-a-rack/MEDUSA refs:
http://www.garlic.com/~lynn/2006w.html#13 IBM sues maker of Intel-based Mainframe clones
http://www.garlic.com/~lynn/2006w.html#14 IBM sues maker of Intel-based Mainframe clones
http://www.garlic.com/~lynn/2006w.html#20 cluster-in-a-rack
http://www.garlic.com/~lynn/2006w.html#26 Why so little parallelism?
http://www.garlic.com/~lynn/2006w.html#38 Why so little parallelism?
http://www.garlic.com/~lynn/2006w.html#39 Why so little parallelism?
http://www.garlic.com/~lynn/2006w.html#40 Why so little parallelism?
http://www.garlic.com/~lynn/2006w.html#41 Why so little parallelism?

as several previous references, here is old references to the meeting
at oracle
http://www.garlic.com/~lynn/95.html#13
http://www.garlic.com/~lynn/96.html#15


From: wheeler
Date: 29 January 1992, 16:28:48 PST
Subject: "cluster computing"

I believe we got a charter last week to do generalized "cluster
computing" with both horizontal growth and availability. We are going
full steam ahead now with plans for major product announce directions
in 6-8 weeks.

Hester gave Larry Ellison (pres. of Oracle) some general "technology
directions".

I'm now in the middle with nailing down overall ... total computing
system environment ... for that year end time frame (database,
horizontal growth, availability, connectivity, function, fileserving,
applications, system management, enterprise wide services, etc, etc).

I wasn't able to make the LLNL meeting tues & weds. this week ... but
XXXXX and YYYYY came by this afternoon (after the meeting).

YYYYY had already put together pictures of the visionary direction
(i.e. for LLNL national storage center) titled "DATAstore" with NSC
providing a generalized fabric switch/router with lots of things
connected to it ... both directly & fully-meshed and in
price/performance hierarchy ... that had HA/6000 as the controlling
central "brains". He effectively said I can get a generalized NSC
switch/router built off combining current NSC/DX technology (including
the RISC/6000 SLA interface) and their HiPPI switch by 2nd qtr. By ye
he should have for me a generalized switch fabric (called UNIswitch)
that has variety of "port" boards

• Sonet,
• FDDI,
• ESCON,
• FCS,
• serial HiPPI,
• parallel HiPPI,
• NSC/DX

In theory, anything coming in any port ... can come out any other
port.

Also, YYYYY has built into the "switch fabric" a "security"
cross-matrix function that can limit who can talk to who
(i.e. otherwise the default fabric is fully-meshed environment,
everybody can talk to everybody). I can use this for the HA "I/O
fencing" function ...  which is absolutely necessary for going
greater than two-way.

XXXXX brought up the fact that we have a larger "scope" here and that
immediately there are about a dozen large "hot Unitree" activities
going on at the moment and that (at least) we three will have to
coordinate. One of them is the current LLNL physical data repository
technical testbed ... but there are two other production environments
at LLNL that have to be addressed in parallel with this work ... and
there are another 9 or so locations that we also have to address.

In addition, both NSC and DISCOS have been having some fairly close
dealings with Cornell ... both Cornell proper and also with regard to
the bid on the NSF stuff. Also the Grummen SI stuff for
Nasa/Huntsville came up.

ZZZZZ was also in town visiting Almaden about some multi-media stuff
... and I invited him to sit in on the meeting with YYYYY and
XXXXX. That gave us the opportunity to discuss a whole other series of
opportunities (like at Cargil(sp?)). The tie-in at Discos is
interesting since General Atomics also operates the UCSD
supercomputing center ... and at least two of the papers at last fall
SOSP on multi-media filesystem requirements were from UCSD (XXXXX
knows the people doing the work).

Also in the discussions with XXXXX about Unitree development we
covered various things that WWWWW (LLNL) had brought up in the past
couple days (off line) and the Cummings Group stuff (NQS-exec, network
caching, log-structured filesystem, etc). XXXXX wants to have two
3-way meetings now ... one between WWWWW, XXXXX and me ... in addition
to the 3-way (or possibly 4-way) meeting between Cummings, XXXXX, and
me.

This is all the visionary stuff that we sort of ran thru for the total
computing environment that we would like to have put together for next
year (hardware, software, distributed, networking, system management,
commercial, technical, filesystems, information management).
Effectively YYYYY, XXXXX, and I came out of the meeting with
ground-work platform for both hardware & software to take over the
whole worlds' computing environment. Little grandiose, but we will be
chipping away at it in nice manageable business justified
"chunks/deliverables".

This is consistent with an overall theme and a series of whitepapers
that we have an outside consultant working on (was one of the founders
of Infoworld and excellent "tech writer") ... talking about the
computing vision associated with "cluster computing" (which includes
the MEDUSA stuff ... and HA/MEDUSA being base for HA/6000 scaleup).

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

as mentioned ... within a few days of sending the above email, the
whole project was taken away from us and transferred to another
organization and we were told we couldn't work on anything with
more than four processors.

and of course, we were producing a product, i.e ha/cmp ... misc.
past posts mentioning
http://www.garlic.com/~lynn/subtopic.html#hacmp

the reference to enterprise wide services was part of our 3-tier
architecture ... misc. recent postings
http://www.garlic.com/~lynn/2006u.html#55 What's a mainframe?
http://www.garlic.com/~lynn/2006v.html#10 What's a mainframe?
http://www.garlic.com/~lynn/2006v.html#14 In Search of Stupidity
http://www.garlic.com/~lynn/2006v.html#35 What's a mainframe?

and past collected postings mentioning 3-tier
http://www.garlic.com/~lynn/subnetwork.html#3tier

for other relational drift and scale-up
http://www.garlic.com/~lynn/2004d.html#6 Memory Affinity

and couple other old rdbms/oracle references:
http://www.garlic.com/~lynn/2004o.html#40 Facilities "owned" by MVS
http://www.garlic.com/~lynn/2000e.html#49 How did Oracle get started?

and, of course, misc. and sundry posts about system/r
http://www.garlic.com/~lynn/subtopic.html#systemr

part of ha/cmp scaleup was work on distributed lock manager ...
misc past posts:
http://www.garlic.com/~lynn/2000.html#64 distributed locking patents
http://www.garlic.com/~lynn/2000g.html#32 Multitasking and resource sharing
http://www.garlic.com/~lynn/2001.html#40 Disk drive behavior
http://www.garlic.com/~lynn/2001c.html#66 KI-10 vs. IBM at Rutgers
http://www.garlic.com/~lynn/2001e.html#2 Block oriented I/O over IP
http://www.garlic.com/~lynn/2001e.html#4 Block oriented I/O over IP
http://www.garlic.com/~lynn/2001f.html#22 Early AIX including AIX/370
http://www.garlic.com/~lynn/2001i.html#21 3745 and SNI
http://www.garlic.com/~lynn/2001i.html#30 IBM OS Timeline?
http://www.garlic.com/~lynn/2001j.html#17 I hate Compaq
http://www.garlic.com/~lynn/2001j.html#47 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001k.html#5 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001k.html#18 HP-UX will not be ported to Alpha (no surprise)exit
http://www.garlic.com/~lynn/2001l.html#5 mainframe question
http://www.garlic.com/~lynn/2001l.html#8 mainframe question
http://www.garlic.com/~lynn/2001l.html#17 mainframe question
http://www.garlic.com/~lynn/2001n.html#23 Alpha vs. Itanic:  facts vs. FUD
http://www.garlic.com/~lynn/2002b.html#36 windows XP and HAL: The CP/M way still works in 2002
http://www.garlic.com/~lynn/2002b.html#37 Poor Man's clustering idea
http://www.garlic.com/~lynn/2002d.html#31 2 questions: diag 68 and calling convention
http://www.garlic.com/~lynn/2002e.html#67 Blade architectures
http://www.garlic.com/~lynn/2002e.html#71 Blade architectures
http://www.garlic.com/~lynn/2002f.html#1 Blade architectures
http://www.garlic.com/~lynn/2002f.html#4 Blade architectures
http://www.garlic.com/~lynn/2002f.html#5 Blade architectures
http://www.garlic.com/~lynn/2002f.html#6 Blade architectures
http://www.garlic.com/~lynn/2002f.html#17 Blade architectures
http://www.garlic.com/~lynn/2002k.html#8 Avoiding JCL Space Abends
http://www.garlic.com/~lynn/2002m.html#21 Original K & R C Compilers
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/2003c.html#53 HASP assembly: What the heck is an MVT ABEND 422?
http://www.garlic.com/~lynn/2003d.html#2 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003d.html#8 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003d.html#54 Filesystems
http://www.garlic.com/~lynn/2003h.html#35 UNIX on LINUX on VM/ESA or z/VM
http://www.garlic.com/~lynn/2003i.html#70 A few Z990 Gee-Wiz stats
http://www.garlic.com/~lynn/2003k.html#10 What is timesharing, anyway?
http://www.garlic.com/~lynn/2003k.html#17 Dealing with complexity
http://www.garlic.com/~lynn/2004c.html#53 defination of terms: "Application Server" vs. "Transaction Server"
http://www.garlic.com/~lynn/2004d.html#72 ibm mainframe or unix
http://www.garlic.com/~lynn/2004i.html#1 Hard disk architecture: are outer cylinders still faster than inner cylinders?
http://www.garlic.com/~lynn/2004i.html#2 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#8 Hard disk architecture: are outer cylinders still faster than inner cylinders?
http://www.garlic.com/~lynn/2004m.html#0 Specifying all biz rules in relational data
http://www.garlic.com/~lynn/2004m.html#5 Tera
http://www.garlic.com/~lynn/2004q.html#10 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2004q.html#37 A Glimpse into PC Development Philosophy
http://www.garlic.com/~lynn/2004q.html#70 CAS and LL/SC
http://www.garlic.com/~lynn/2004q.html#71 will there every be another commerically signficant new ISA?
http://www.garlic.com/~lynn/2005.html#40 clusters vs shared-memory (was: Re: CAS and LL/SC (was Re: High Level Assembler for MVS & VM & VSE))
http://www.garlic.com/~lynn/2005.html#55 Foreign key in Oracle Sql
http://www.garlic.com/~lynn/2005b.html#1 Foreign key in Oracle Sql
http://www.garlic.com/~lynn/2005f.html#18 Is Supercomputing Possible?
http://www.garlic.com/~lynn/2005f.html#32 the relational model of data objects *and* program objects
http://www.garlic.com/~lynn/2005h.html#26 Crash detection by OS
http://www.garlic.com/~lynn/2005h.html#28 Crash detection by OS
http://www.garlic.com/~lynn/2005i.html#42 Development as Configuration
http://www.garlic.com/~lynn/2005m.html#8 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005q.html#49 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005r.html#23 OS's with loadable filesystem support?
http://www.garlic.com/~lynn/2005u.html#38 Mainframe Applications and Records Keeping?
http://www.garlic.com/~lynn/2006b.html#8 Free to good home: IBM RT UNIX
http://www.garlic.com/~lynn/2006c.html#8 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006c.html#41 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006d.html#14 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006j.html#20 virtual memory
http://www.garlic.com/~lynn/2006o.html#24 computational model of transactions
http://www.garlic.com/~lynn/2006o.html#32 When Does Folklore Begin???
http://www.garlic.com/~lynn/2006o.html#33 When Does Folklore Begin???
http://www.garlic.com/~lynn/2006o.html#62 Greatest Software, System R

S0C1 with ILC 6

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: S0C1 with ILC 6
Newsgroups: bit.listserv.ibm-main
Date: Mon, 18 Dec 2006 12:24:57 -0700

shmuel+ibm-main@ibm-main.lst (Shmuel  Metz , Seymour J.) writes:

It can if it straddles page boundaries and the second page is marked
invalid. That's not something that you should see in an application
program.

aka, instruction fetch can page fault ... independent of the
instruction execution page fault.

one of the reasons that 360/67 had an 8-entry associative array (dlat,
tlb, etc) ... was the worse case for "EXECUTE" of SS instructions
required eight different page addresses.

"EX" (execute) of another instruction

2 pages - instruction start and end (crossing page boundary)

target (SS) instruction

2 pages - instruction start and end (crossing page boundary)

2 pages - operand1 start and end (crossing page boundary)

2 pages - operand2 start and end (crossing page boundary)

------

8 pages

=============

load address instruction fetch could have two page faults (when
instruction crosses page boundary).

S0C1 with ILC 6

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: S0C1 with ILC 6
Newsgroups: bit.listserv.ibm-main
Date: Mon, 18 Dec 2006 14:01:06 -0700

Edward Jaffe wrote:

Untrue! There are no Program Exceptions whatsoever listed for the LA
instruction in PoOp. In fact, it specifically states:

"No storage references for operands take place, and the address is not
inspected for access exceptions."

you can get instruction fetch program exception ... separate from
instruction execution program exceptions ... recent post
http://www.garlic.com/~lynn/2006x.html#4 S0C1 with ILC 6

the note in the PoP refers to instruction execution program exceptions
(storage references) ... as opposed to possible instruction fetch
program exception.

repeat from previous post/reference:

aka, instruction fetch can page fault ... independent of the
instruction execution page fault.

one of the reasons that 360/67 had an 8-entry associative array (dlat,
tlb, etc) ... was the worse case for "EXECUTE" of SS instructions
required eight different page addresses.

"EX" (execute) of another instruction

2 pages - instruction start and end (crossing page boundary)

target (SS) instruction

2 pages - instruction start and end (crossing page boundary)

2 pages - operand1 start and end (crossing page boundary)

2 pages - operand2 start and end (crossing page boundary)

------

8 pages

=============

load address instruction fetch could have two page faults (when
instruction crosses page boundary).

Multics on Vmware ?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Multics on Vmware ?
Newsgroups: alt.os.multics
Date: Tue, 19 Dec 2006 07:09:24 -0700

Renaissance <mapsons.gianl@libero.uk> writes:

1. This is basically a Virtual Machine running ubuntu linux with a
Hercules freeware Emulator built onto it.
^^^^^^^^^^^^^^^^^^^^^^^^^^

many of the referernces to virtual appliance is more along the lines
of server virtual machine ... virtual machine providing specific
services ... recent reference to 1981 email for using (then) existing
service virtual machine for network-based real-time public key server
... something like pgp key server ...
http://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network

misc. other recent posts about service virtual machine and/or virtual
appliance
http://www.garlic.com/~lynn/2006p.html#10 What part of z/OS is the OS?
http://www.garlic.com/~lynn/2006t.html#45 To RISC or not to RISC
http://www.garlic.com/~lynn/2006t.html#46 To RISC or not to RISC
http://www.garlic.com/~lynn/2006v.html#22 vmshare
http://www.garlic.com/~lynn/2006w.html#16 intersection between autolog command and cmsback (more history)
http://www.garlic.com/~lynn/2006w.html#25 To RISC or not to RISC
http://www.garlic.com/~lynn/2006w.html#52 IBM sues maker of Intel-based Mainframe clones

vmshare

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vmshare
Newsgroups: alt.folklore.computers
Date: Tue, 19 Dec 2006 08:17:38 -0700

ref:
http://www.garlic.com/~lynn/2006w.html#42 vmshare

a little more topic drift ... from the bureau of misinformation


To: wheeler
Date: 03/02/87 13:42:13

Re: VM and executives -It came as a surprise in my meeting with <a top
corporate executive> that Profs ran on VM. He had been led to believe
it was a VTAM application and that was why vm networking had to be
linked with VTAM.

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

the above wasn't an isolated incident, i'd heard other similar
reports.  in this period, there was an enormous amount of
misinformation being pushed up to corporate executives in an attempt
to get a corporate directive to repopulate the internal network with
dumb terminal communication operation ... as well as claims that it
could be used for NSF:
http://www.garlic.com/~lynn/2006w.html#21 SNA/VTAM for NSFNET

the internal network had nothing to do with dumb terminal
communication operation ... misc. past posts mentioning the internal
network
http://www.garlic.com/~lynn/subnetwork.html#internalnet

my wife ran into conflict with some of this same group when she served
her stint in pok in charge of loosely coupled architecture (mainframe
for "cluster").  there was eventually an uneasy truce where everything
that crossed glass house boundary supposedly had to be under control of
the strategic dumb terminal communication operation (even that truce
they would chip away at). misc. past posts making reference to her
stint in pok in charge of loosely coupled architecture
http://www.garlic.com/~lynn/subtopic.html#shareddata

we also ran into conflict a little later when we were doing 3-tier
architecture ... and taking a lot of heat from the SAA crowd
http://www.garlic.com/~lynn/subnetwork.html#3tier

and some other drift ... references about presentation that claimed
that the same organization was going to be responsible for the demise
of the disk division (the dumb terminal communication operation was
increasingly isolating the glass house from the emerging online,
networking world)
http://www.garlic.com/~lynn/2001j.html#16 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2003c.html#23 diffence between itanium and alpha
http://www.garlic.com/~lynn/2004f.html#39 Who said "The Mainframe is dead"?
http://www.garlic.com/~lynn/2004m.html#59 RISCs too close to hardware?
http://www.garlic.com/~lynn/2005j.html#33 IBM Plugs Big Iron to the College Crowd
http://www.garlic.com/~lynn/2005j.html#59 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2005r.html#8 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005t.html#30 AMD to leave x86 behind?
http://www.garlic.com/~lynn/2006k.html#25 Can anythink kill x86-64?
http://www.garlic.com/~lynn/2006l.html#4 Google Architecture
http://www.garlic.com/~lynn/2006l.html#38 Token-ring vs Ethernet - 10 years later
http://www.garlic.com/~lynn/2006r.html#4 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006r.html#20 50th Anniversary of invention of disk drives

vmshare

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: vmshare
Newsgroups: alt.folklore.computers
Date: Wed, 20 Dec 2006 00:42:10 -0700

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

and some other drift ... references about presentation that claimed
that the same organization was going to be responsible for the demise
of the disk division (the dumb terminal communication operation was
increasingly isolating the glass house from the emerging online,
networking world)

re:
http://www.garlic.com/~lynn/2006x.html#7 vmshare

the person that had given the presentation predicting the demise of
the disk division had much earlier worked on some large customer
accounts and had written about some of his experiences.

some of his writings from long ago and far away ....

The Large Conglomerate

In 1975, a large international conglomerate customer accepted the idea
that it was possible to use IBM 3600 banking systems in a
manufacturing shop floor environment.  As a result, the IBM team and
customer installed what was to be the second MVS SNA system in the
world.  The system (hardware and software) was installed by four
people and was on-line in 10 weeks.  While the effort required 300 to
400 hours overtime by each of the four people, the numerous problems
that were experienced were generally regarded as unique and isolated
situations.  Based on post-installation experiences, the customer and
the IBM team no longer hold that belief; the change in attitude
gradually occurred as various situations developed.

After the above system had been installed for several months, the 3600
system was enhanced to support dial lines as well as leased lines.
This announcement was particularly attractive to the customer since it
had two remote 3600 systems that each required 1000 mile leased lines
which were only used for 30 minutes (maximum) a day.  After
investigation, it was determined that the customer would have to
change the level of microcode in the 3600 controller to obtain the new
function.

This required the customer to

• reassemble his 3600 application programs (APBs)
• reassemble his 3600 SYSGENS (CPGENs)
• install and use the new microcode
• use a new level of 3600 starter diskette.

However, the new level of microcode required a new level of Subsystem
Support Services (SSS) and Program Validation Services (PVS).

• The new level of SSS required a new level of VTAM.
• The new level of VTAM required a new level of NCP
• reassembly of the customer written VTAM programs.

I do not recall if the new level of VTAM also required a new level of
MVS and hence IMS, as the inquiry into this announcement had halted by
this point.  The message was clear: the change from a leased line to a
dial line would have required that virtually every line of IBM system
code in the entire complex be reinstalled.  The change was viewed as a
very small configuration change by the customer but resulted in a very
large system change.  Since this was a corporate data center and
served multiple user divisions in addition to the particular division
using the 3600 system, the impact of the change was totally
unacceptable.  In short, the change would have challenged two data
processing maxims.

• First, any given change can and often does impact service
(availability) levels of seemingly unrelated components in a data
processing system.  The impact is generally unpredictable and usually
undesirable.  (For example, the customer written VTAM 3600 support
program ran for two years without a problem until VSPC was added to
the system.  Suddenly, the customer's program randomly failed when run
during the day but not when run at night.  Later it was discovered
that VSPC was slowing down VTAM enough to cause the application's VTAM
allowable buffer count occasionally to be exceeded.  Hence, VTAM
destroyed the session.)

• Second, each system change should be implemented in isolation of
other changes whenever possible.

... snip ...

Another example of such intertwined software interdependencies can be
seen in the contrast between JES2 "networking" and VNET/RSCS
"networking".

VNET/RSCS had relatively clean separation of function ... including
what could be considered something akin to gateway function in every
node. I've periodically claimed that the arpanet/internet didn't get
that capability until the great switchover to internetworking protocol
on 1/1/83 ... and one of the reasons why the internal network was
larger than the arpanet/internet from just about the beginning until
possibly mid-85. misc. past posts about the internal network.
http://www.garlic.com/~lynn/subnetwork.html#internalnet

In the JES2 networking implementation ... it somewhat reflected the
intertwined dependencies of many of the communication implementations
dating back to the 60s & 70s. Because of the intertwined dependencies,
JES2 implementations typically had to be at the same release level to
interoperate. Futhermore, it wasn't unusual for JES2 systems, at
different release levels, attempting to communicate, to crash one or
the other of the JES2 systems ... and even take down the associated
MVS systems.

In the large world-wide internal network with hundreds (and then
thousands) of different systems, it would be extremely unusual to have
all systems simultaneously at the same release level.  However such a
feature was frequently required by many traditional communication
implementations of the period. There are even historical arpanet BBN
notes about regularly scheduled system-wide IMP downtime for support
and maintenance, aka periodic complete arpanet outage ... minor ref
http://www.garlic.com/~lynn/2006k.html#10 Arpa address
for slight drift, projection that there might be as many as 100
arpanet nodes by (sometime in) 1983 (from 1980 arpanet
newsletter):
http://www.garlic.com/~lynn/2006k.html#40 Arpa address

Over time, a collection of "JES" (nji/nje) line drivers evolved for
VNET/RSCS ... that simulated JES protocol and allowed JES/MVS machines
to participate in the internal network. There tended to be unique
(VNET) JES drivers specific to each JES/MVS release ... specific
driver would be started on a communication line for whatever JES/MVS
that was at the other end of the line. Furthermore, over time,
VNET/RSCS evolved sort of a canonical representation of JES
communication ... and provided format conversion interoperability
between different JES systems (as a countermeasure to JES systems at
different release levels causing each other to crash, even bringing
down the whole MVS system).

There is the relatively well known story about a San Jose plant site
JES2/MVS system attempting to communicate with a JES2/MVS system in
Hursley and causing the Hursly MVS system to repeatedly crash. The
problem appeared to then be blamed on VNET ... for allowing MVS
systems to cause each other to crash.

As a result of the enormous vaguries in their implementations
... JES/MVS systems tended to be restricted to boundary nodes ... with
VNET/RSCS being the internal corporate networking platform.

disclaimer ... my wife did a stint in the g'burg JES product group
before doing her time in POK in charge of loosly coupled architecture
http://www.garlic.com/~lynn/subtopic.html#shareddata

misc. past posts mentioning JES2 and/or HASP (not just networking):
http://www.garlic.com/~lynn/subtopic.html#hasp

for a little drift ... recent posts mentioning service virtual
machines and/or virtual appliances:
http://www.garlic.com/~lynn/2006p.html#10 What part of z/OS is the OS?
http://www.garlic.com/~lynn/2006t.html#45 To RISC or not to RISC
http://www.garlic.com/~lynn/2006t.html#46 To RISC or not to RISC
http://www.garlic.com/~lynn/2006v.html#22 vmshare
http://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network
http://www.garlic.com/~lynn/2006w.html#16 intersection between autolog command and cmsback (more history)
http://www.garlic.com/~lynn/2006w.html#25 To RISC or not to RISC
http://www.garlic.com/~lynn/2006w.html#52 IBM sues maker of Intel-based Mainframe clones
http://www.garlic.com/~lynn/2006x.html#6 Multics on Vmware ?

Plurals and language confusion

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Plurals and language confusion
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 20 Dec 2006 09:22:17 -0700

giltjr@EARTHLINK.NET (John S. Giltner, Jr.) writes:

Never noticed that, but I only use ATM's in 7-11, gas stations, and
places that like. I would assume that I can't make a depost at one of these.

Last time I used an actual bank ATM was a long time ago.  I would assume
that you can only do this at banks (includes banks inside grocery
stores), credit unions, or other finical institutions.

for some ATM drift back to computer related .. a couple posts
mentioning work on 2984 ATM machine at los gatos lab ... and mention
of other ATM machine related itmes:
http://www.garlic.com/~lynn/2002g.html#55 Multics hardware (was Re: "Soul of a New Machine" Computer?)
http://www.garlic.com/~lynn/2002m.html#45 Wanted: the SOUNDS of classic computing
http://www.garlic.com/~lynn/2003k.html#3 Ping:  Anne & Lynn Wheeler
http://www.garlic.com/~lynn/2004p.html#25 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2004p.html#26 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2006q.html#5 Materiel and graft
http://www.garlic.com/~lynn/2006u.html#40 New attacks on the financial PIN processing

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

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: re: The Future of CPUs: What's After Multi-Core?
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers
Date: Wed, 20 Dec 2006 12:37:51 -0700

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

IME the IBM VM guys had very good ideas for interaction using the
corporate products and facilities, even though it has never been
funded adequately and often nearly terminated.

They were much better than the batch guys at letting the users fully
use all the machines' capabilities, providing nearly 100% capacity and
keeping terminal response averages close to 0.1s; the batch guys were
better at using up all the machines' capabilities, and the users
considered themselves lucky to have 70% capacity available and get 1s
terminal response times.

The really cool thing about VM systems is that you can do anything
with the software under timesharing: develop a new OS, test a changed
OS, trace the execution of an OS.

Once found a bug crashing a DB product only after tracing about a
million instructions, a few times over to get it exactly right, with
very selective output, sufficient to pinpoint the faulty code: try
doing that on a real front panel or console!

for some total drift ... a different reference to "tracing" in support
of semi-automated program reorganization to optimize execution for
virtual memory environment
http://www.garlic.com/~lynn/2006x.html#1 IBM sues make of Intel-based Mainframe clones

as an undergraduate in the 60s, i had done dynamic adaptive resource
management ... it was sometimes referred to as fair share scheduling
since the default resource management policy was fair share. this was
shipped as part cp67 for 360/67.

in the morph from cp67 to vm370 ... much of it was dropped. charlie's
cp67 multiprocessor support also didn't make it into vm370.

i had done a lot of pathlength optimization and fastpath stuff for
cp67 which was also dropped in the morph to vm370 ... i helped put a
small amount of that back into vm370 release1 plc9 ... a couple past
posts mentioning some of the cp67 pathlength stuff
http://www.garlic.com/~lynn/93.html#1 360/67, was Re: IBM's Project F/S ?
http://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14
http://www.garlic.com/~lynn/94.html#20 CP/67 & OS MFT14

i then got to work on porting a bunch of stuff that i had done for
cp67 to vm370 ... some recent posts (includes old email from the early
and mid 70s)
http://www.garlic.com/~lynn/2006v.html#36 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006w.html#7 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006w.html#10 long ago and far away, vm370 from early/mid 70s

and of course mentioned in the above referenced email ... a small
amount of the virtual memory management stuff showed up in vm370
release 3 as DCSS.

there was eventually a decision to release some amount of the features
as the vm370 resource manager.  some collected posts on scheduling
http://www.garlic.com/~lynn/subtopic.html#fairshare
and other posts on page management
http://www.garlic.com/~lynn/subtopic.html#wsclock
and for something really different old communication (from 1982) about
work i had done as undergraduate in the 60s (also in this thread):
http://www.garlic.com/~lynn/2006w.html#46 The Future of CPUs: What's after Multi-Core?

in any case, some resource manager issues/features

 by continually doing real time dynamical monitoring and
adjusting operations, I was able to operate at much higher resource
utilization and still provide decent level of service. prior to
resource manager ship, somebody from corporate stated that the current
state of the art for resource managers were large number of static
tuning parameters and that the resource manager couldn't be
considered really advanced unless it had some number of static tuning
parameters (installation system tuning expert would look at daily,
weekly and monthly activity ... and would select some set of static
tuning values that seemed to be suited to that installation). it did
absolutely no good explaining that real-time dynamic monitoring and
adapting was much more advanced that static tuning parameters. so, in
order to get final corporate release approval ... i had to implement
some number of static tuning parameters. I fully documented the
implementation and formulas and the source code was readily
available. Nobody seemed to realize that it was a joke ... somewhat
from "operations research" ... it had to do with "degrees of freedom"
... aka the static tuning parameters had much less degrees of freedom
than the dynamic adaptive features.

i had always thot that real-time dynamic adaptive control was
preferable to static parameters ... but it took another couple decades
for a lot of the rest of the operating systems to catch up. it is now
fairly evident ...  even showing up in all sorts of embedded
processors for real-time control and optimization. for some slight
boyd dynamic adaptive drift
http://www.garlic.com/~lynn/94.html#8 scheduling & dynamic adaptive
and collected posts mentioning boyd
http://www.garlic.com/~lynn/subboyd.html#boyd
and various URLs from around the web mentioning boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2

 there was transition in the mid-70s with respect to charging
for software. the 23jun69 unbundling announcement had introduced
charging for application software (somewhat because of
gov. litigation). however the excuse was that kernel software should
still be free since it was required for operation of the
hardware. however, with the advent of clone processors by the mid-70s,
the opinion was starting to shift, and the resource manager got chosen
to be the guinea pig for kernel software charging. as a result, i got
to spend some amount of time with business and legal people on kernel
software charging.
http://www.garlic.com/~lynn/subtopic.html#unbundle

 some amount of the code in the resource manager had been
originally built for multiprocessor operation .... it was then added
to base vm370 system that didn't have support for multiprocessor
hardware operation. the next release of vm370 did introduce support
for multiprocessor hardware operation ... some amount based on the
VAMPS work ... misc. past posts mentioning VAMPS
multiprocessor work:
http://www.garlic.com/~lynn/subtopic.html#bounce

the problem was that the multiprocessor support was going to be part
of the (still) free, base kernel (aka hardware support ) ... while
much of the multiprocessor kernel code structure was part of the
"priced" resource manager (and pricing policy said that there couldn't
be free software that had priced software prerequisite).  so before
the multiprocessor support was shipped, a lot of the resource manager
code base was re-organized into the free kernel.  lots of past posts
mentioning multiprocessor support (and/or charlie's invention of
compare&swap instruction)
http://www.garlic.com/~lynn/subtopic.html#smp

....

previous posts in this thread:
http://www.garlic.com/~lynn/2006t.html#27 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006t.html#31 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006t.html#32 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006t.html#34 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006t.html#36 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006t.html#41 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006t.html#42 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006t.html#43 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006t.html#49 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006t.html#50 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006u.html#0 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006u.html#6 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006u.html#7 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006u.html#8 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006u.html#9 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006u.html#10 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006v.html#21 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006v.html#43 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006x.html#2 The Future of CPUs: What's After Multi-Core?

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

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Future of CPUs: What's After Multi-Core?
Newsgroups: alt.folklore.computers
Date: Wed, 20 Dec 2006 13:22:27 -0700

eugene@cse.ucsc.edu (Eugene Miya) writes:

Well most people had not idea their channel I/O rates were 4x IBM's.
And that's not including striping which most firms still don't do.
Most serious Cray programs stayed in memory.  They might output a
checkpoint file every now and again to restart should a hiccup occur.

references to previous posts in this thread:
http://www.garlic.com/~lynn/2006x.html#10 The Future of CPUs: What's After Multi-Core?

... i.e. HSC ... LANL doing a standards flavor of cray channel ...
morped into HiPPI ... 800mbit/sec.

recent past posts mentioning HSC or HiPPI
http://www.garlic.com/~lynn/2006b.html#14 Expanded Storage
http://www.garlic.com/~lynn/2006c.html#1 Multiple address spaces
http://www.garlic.com/~lynn/2006c.html#40 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006l.html#43 One or two CPUs - the pros & cons
http://www.garlic.com/~lynn/2006m.html#52 TCP/IP and connecting z to alternate platforms
http://www.garlic.com/~lynn/2006u.html#19 Why so little parallelism?
http://www.garlic.com/~lynn/2006v.html#10 What's a mainframe?
http://www.garlic.com/~lynn/2006x.html#3 Why so little parallelism?

at about the same time, LLNL was pushing for fiber-optic version
(fiber channel standard, FCS) of non-blocking switch technology they
had installed that used serial copper (as opposed to serial
fiber-optics) .... and SLAC was pushing SCI (another serial
fiber-optic standard) ... which had a mapping for SCSI commands.

In that time-frame, POK was trying to get around to releasing escon
...  200mbit fiber-optic emulating standard mainframe half-duplex parallel
channel.  This had been knocking around in POK since the 70s ... never
quite making it out. While POK was trying to make a decision about
releasing escon, one of the Austin engineers took the base escon
technology and made a few changes ... up'ed the raw bandwidth to
220mbits/sec, enhanced it to full-duplex operation, and redid the
optical drivers (well under 1/10th the cost of the ones being used for
escon). This was released as "SLA" (serial link adapter) for rs/6000.

we were doing some stuff with LLNL (on FCS), LANL (on HiPPI) and SLAC
(on SCI) about the time the engineer had finished the SLA work and
wanted to start on a 800mbit version. It took almost six months to
talk him into abandoning SLA and going to work on FCS (where he became
the secretary/owner of the FCS standards document).

later he was one of the primary people putting together much of the
details for MEDUSA (cluster-in-a-rack). misc. recent posts mentioning
MEDUSA:
http://www.garlic.com/~lynn/2006w.html#13 IBM sues maker of Intel-based Mainframe clones
http://www.garlic.com/~lynn/2006w.html#14 IBM sues maker of Intel-based Mainframe clones
http://www.garlic.com/~lynn/2006w.html#20 cluster-in-a-rack
http://www.garlic.com/~lynn/2006w.html#40 Why so little parallelism?
http://www.garlic.com/~lynn/2006w.html#41 Why so little parallelism?
http://www.garlic.com/~lynn/2006x.html#3 Why so little parallelism?

if you go back to 370s ... there were some 1.5mbyte/sec channels
(primarily driven at that rate by fixed head disks). 3380 disks and
3880 disk controllers increased that to 3mbyte/sec operation (and the
newer generation of 3mbyte/sec channels on various processors seen in
the 80s). the earlier generation of channels did a protocol handshake
on every byte transferred. the new 3mbyte/sec "data streaming"
channels relaxed that requirement ... which both increased the data
rate ...  but also doubled the maximum channel distance from 200ft to
400ft i.e. you could have a machine room configuration with
controllers out at a 400ft radius rather than just a 200ft radius. The
200ft limitation had gotten so severe for some installations that
there were starting to appear multi-floor configurations (i.e. instead
of a 200ft radius circle limitation ... a 200ft radius sphere).

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

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Future of CPUs: What's After Multi-Core?
Newsgroups: alt.folklore.computers,bit.listserv.vmesa-l
Date: Wed, 20 Dec 2006 15:54:45 -0700

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

if you go back to 370s ... there were some 1.5mbyte/sec channels
(primarily driven at that rate by fixed head disks). 3380 disks and
3880 disk controllers increased that to 3mbyte/sec operation (and the
newer generation of 3mbyte/sec channels on various processors seen in
the 80s). the earlier generation of channels did a protocol handshake
on every byte transferred. the new 3mbyte/sec "data streaming"
channels relaxed that requirement ... which both increased the data
rate ...  but also doubled the maximum channel distance from 200ft to
400ft i.e. you could have a machine room configuration with
controllers out at a 400ft radius rather than just a 200ft radius. The
200ft limitation had gotten so severe for some installations that
there were starting to appear multi-floor configurations (i.e. instead
of a 200ft radius circle limitation ... a 200ft radius sphere).

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

for other topic drift, i had done some work in the disk engineering
(bldg14) and disk product test (bldg15) labs. ... misc. past posts
mentioning work in bldg14 &/or bldg15
http://www.garlic.com/~lynn/subtopic.html#disk

and misc. past posts this year mentioning 3380 disks and/or 3880
disk controllers
http://www.garlic.com/~lynn/2006.html#4 Average Seek times are pretty confusing
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
http://www.garlic.com/~lynn/2006c.html#6 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006c.html#8 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006c.html#9 Mainframe Jobs Going Away
http://www.garlic.com/~lynn/2006d.html#0 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006e.html#45 using 3390 mod-9s
http://www.garlic.com/~lynn/2006e.html#46 using 3390 mod-9s
http://www.garlic.com/~lynn/2006f.html#5 3380-3390 Conversion - DISAPPOINTMENT
http://www.garlic.com/~lynn/2006g.html#0 IBM 3380 and 3880 maintenance docs needed
http://www.garlic.com/~lynn/2006i.html#12 Mainframe near history (IBM 3380 and 3880 docs)
http://www.garlic.com/~lynn/2006i.html#41 virtual memory
http://www.garlic.com/~lynn/2006j.html#2 virtual memory
http://www.garlic.com/~lynn/2006j.html#3 virtual memory
http://www.garlic.com/~lynn/2006j.html#11 The Pankian Metaphor
http://www.garlic.com/~lynn/2006j.html#14 virtual memory
http://www.garlic.com/~lynn/2006l.html#6 Google Architecture
http://www.garlic.com/~lynn/2006l.html#13 virtual memory
http://www.garlic.com/~lynn/2006l.html#18 virtual memory
http://www.garlic.com/~lynn/2006m.html#5 Track capacity?
http://www.garlic.com/~lynn/2006m.html#8 Track capacity?
http://www.garlic.com/~lynn/2006m.html#13 Track capacity?
http://www.garlic.com/~lynn/2006n.html#8 Not Your Dad's Mainframe: Little Iron
http://www.garlic.com/~lynn/2006n.html#33 CRAM, DataCell, and 3850
http://www.garlic.com/~lynn/2006n.html#35 The very first text editor
http://www.garlic.com/~lynn/2006o.html#44 When Does Folklore Begin???
http://www.garlic.com/~lynn/2006q.html#50 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006r.html#35 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006r.html#36 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006r.html#37 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006r.html#39 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006r.html#40 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006s.html#30 Why magnetic drums was/are worse than disks ?
http://www.garlic.com/~lynn/2006s.html#32 Why magnetic drums was/are worse than disks ?
http://www.garlic.com/~lynn/2006s.html#33 Why magnetic drums was/are worse than disks ?
http://www.garlic.com/~lynn/2006s.html#42 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006t.html#18 Why magnetic drums was/are worse than disks ?
http://www.garlic.com/~lynn/2006t.html#41 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006v.html#0 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006v.html#16 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006v.html#17 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006v.html#20 Ranking of non-IBM mainframe builders?

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

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Future of CPUs: What's After Multi-Core?
Newsgroups: alt.folklore.computers
Date: Wed, 20 Dec 2006 20:58:10 -0700

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

Always thought IBM channels were much slower than the then current
technology could easily achieve: 10x faster would still put them below
current PC buses.

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

hsc/hippi was 800mbits/sec parallel, half-duplex

escon was 200mbits ... and although dual fiber-optics, it operated as
if half-duplex parallel channel. that put escon at 1/4 hsc/hippi.

mainframe genre refers to it as 17mbyte/sec channel. the rs/6000 SLA
somewhat originating from same original technology ... but upgrading
to 220mbits/sec (instead of 200mbits).

as mentioned, part of upgrade to 3mbyte "data streaming" also allowed
increasing aggregate channel distances from 200ft to 400ft. along with
the 3mbyte, "data streaming" channels there was also 3380 disks
with 3mbyte/sec transfer.

some of the FCS standards activity had some number of representation
from mainframe channel organization and there was lots of contention
about including half-duplex mainframe channel operation as part
of the FCS channel. it currently goes by the term "FICON". old
posts mentioning FICON
http://www.garlic.com/~lynn/2000c.html#56 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2001.html#18 Disk caching and file systems.  Disk history...people forget
http://www.garlic.com/~lynn/2001k.html#22 ESCON Channel Limits
http://www.garlic.com/~lynn/2002e.html#32 What goes into a 3090?
http://www.garlic.com/~lynn/2002n.html#50 EXCP
http://www.garlic.com/~lynn/2003h.html#0 Escon vs Ficon Cost
http://www.garlic.com/~lynn/2003o.html#54 An entirely new proprietary hardware strategy
http://www.garlic.com/~lynn/2004d.html#68 bits, bytes, half-duplex, dual-simplex, etc
http://www.garlic.com/~lynn/2004h.html#29 BLKSIZE question
http://www.garlic.com/~lynn/2004n.html#45 Shipwrecks
http://www.garlic.com/~lynn/2004p.html#29 FW: Is FICON good enough, or is it the only choice we get?
http://www.garlic.com/~lynn/2005e.html#13 Device and channel
http://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new?
http://www.garlic.com/~lynn/2005l.html#26 ESCON to FICON conversion
http://www.garlic.com/~lynn/2005m.html#55 54 Processors?
http://www.garlic.com/~lynn/2005v.html#0 DMV systems?

old posts comparing cp67 360/67 thruput with vm370 3081 thruput and
pointing out that disk relative system thruput had declined by a
factor of more than an order of magnitude over a period of 10-15 yrs
... also mentioned that disk division had taken exception and assigned
the performance modeling organization to refute my statement. a
couple weeks later they came back and commented that i had
somewhat understated the problem:
http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door
http://www.garlic.com/~lynn/94.html#43 Bloat, elegance, simplicity and other irrelevant concepts
http://www.garlic.com/~lynn/94.html#55 How Do the Old Mainframes Compare to Today's Micros?
http://www.garlic.com/~lynn/95.html#10 Virtual Memory (A return to the past?)
http://www.garlic.com/~lynn/98.html#46 The god old days(???)
http://www.garlic.com/~lynn/99.html#4 IBM S/360
http://www.garlic.com/~lynn/2001d.html#66 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001f.html#62 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001f.html#68 Q: Merced a flop or not?
http://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)
http://www.garlic.com/~lynn/2001l.html#61 MVS History (all parts)
http://www.garlic.com/~lynn/2001m.html#23 Smallest Storage Capacity Hard Disk?
http://www.garlic.com/~lynn/2002.html#5 index searching
http://www.garlic.com/~lynn/2002b.html#11 Microcode? (& index searching)
http://www.garlic.com/~lynn/2002b.html#20 index searching
http://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?
http://www.garlic.com/~lynn/2002e.html#9 What are some impressive page rates?
http://www.garlic.com/~lynn/2002i.html#16 AS/400 and MVS - clarification please
http://www.garlic.com/~lynn/2003i.html#33 Fix the shuttle or fly it unmanned
http://www.garlic.com/~lynn/2004n.html#22 Shipwrecks
http://www.garlic.com/~lynn/2004p.html#39 100% CPU is not always bad
http://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new?
http://www.garlic.com/~lynn/2005k.html#53 Performance and Capacity Planning
http://www.garlic.com/~lynn/2006m.html#32 Old Hashing Routine

IBM ATM machines

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM ATM machines
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 21 Dec 2006 10:01:27 -0700

jsavard@ecn.ab.ca wrote:

That reminds me. The first ATMs in Canada I saw at my bank were made by
IBM - and they used a formed-character printer to print the information
about the transaction on card stock media.

It was apparent to me that what they were using was exactly the right
size to be a 96-column card.

ref (including past posts mentioning los gatos lab atm machine development):
http://www.garlic.com/~lynn/2006x.html#9 Plurals and language confusion

ditto the san jose ibm credit union

offices were in the basement of bldg.12 ... they had to move out when
bldg.12 under went seismic retrofit.

and for the heck of it and more topic drift, other posts in the pin attack threads
http://www.garlic.com/~lynn/2006u.html#42 New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006u.html#43 New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006u.html#47 New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006u.html#48 New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006v.html#1 New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006v.html#2 New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006v.html#33 New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006v.html#39 On sci.crypt: New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006v.html#42 On sci.crypt: New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006v.html#46 Patent buster for a method that increases password security
http://www.garlic.com/~lynn/2006v.html#49 Patent buster for a method that increases password security

the original post in the above thread
http://www.garlic.com/~lynn/2006u.html#40 New attacks on the financial PIN processing

was oriented towards insiders being able to take advantage of their
position to compromise PIN processing.

this is different than the skimming/harvesting attacks
http://www.garlic.com/~lynn/subintegrity.html#harvest

that can be done with compromised terminals (which may involve
insiders or outsiders) ... i.e. capture of static authentication data
for replay attacks. traditionally this has involved magstripe cards
(with or w/o PINs) ... but has also been used against chipcards that
rely on static authentication data
http://www.garlic.com/~lynn/2006v.html#45 On sci.crypt: New attacks on the financial PIN processing

in some cases ... some of the chipcard implementations using static
authentication data has made it even more attractive for the attacker
doing skimming exploits.

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

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Future of CPUs: What's After Multi-Core?
Newsgroups: alt.folklore.computers
Date: Thu, 21 Dec 2006 11:19:16 -0700

eugene@cse.ucsc.edu (Eugene Miya) writes:

Why are you always a decade off?

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

you wrote "channel i/o rates were 4x IBM's" ... the only mainframe
channel that was 1/4th 800mbits was escon (200mbits) which didn't
start shipping until the time-frame of hsc/hippi ... 90s.

i was only answering based on what you had written. if you feel that
you got the time-frame reference wrong, it isn't my fault.

maybe i misunderstood what you were trying to say and you were really
were referring to I/O operations per second ... independent of bytes
transferred? or maybe you weren't refering to rates of a channel
... but actually were referring to overall number system I/O
operations per second (which happened to be channel I/O operations
... again independent of the bytes tranferred). Or maybe you met
something different than what you typed?

I apologize if I misunderstood you and you weren't actually referring
to a cray channel byte transfer rate being four times IBMs.

if you really met to reference 1970s "Cray-1 (when this started)" ...
then you would be referring to mainframe bus&tag 1.5mbyte/sec channel
... around 12mbit/sec ... or do you mean to state that the 1970s
Cray-1 channel was 4*12mbit/sec ... or 48mbit/sec????.

part of the bus&tag limitation was doing protocol handshake on
every byte transferred (which also imposed the aggregate 200ft limit
on each channel). The only devices that actually ran at that
(1.5mbyte/sec) rate were fixed-head disks ... and even then many
systems required significantly reduced channel distance limitations
(in order to operate at that channel transfer rate).

if the decade that you want to reference was with respect to an ibm
channel that was 1/4th the 800mbits/sec ... then you are talking about
escon and 90s. if you want to reference 70s when ibm channels were
1.5mbytes/sec ... then are you implying that the 1970s cray-1 channel
was around 6mbytes/sec data transfer rate?

as to raid ... reference to patent awarded 1978 to somebody at the san
jose plant site ... past posts referencing the patent:
http://www.garlic.com/~lynn/2002e.html#4 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2004d.html#29 cheaper low quality drives
http://www.garlic.com/~lynn/2004g.html#13 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2006p.html#47 "25th Anniversary of the Personal Computer"
http://www.garlic.com/~lynn/2006u.html#18 Why so little parallelism?

wiki reference:
http://en.wikipedia.org/wiki/Redundant_array_of_independent_disks

misc. past posts mentioning work with bldg. 14 disk enginnering and
bldg. 15 disk product test labs
http://www.garlic.com/~lynn/subtopic.html#disk

somewhere in the archives, I even have email with the person granted
the patent.

i got involved starting in 80s looking at various kinds of parallel
transfers as way of mitigating disk performance bottlenecks.

lots of past posts mentioning disk striping and/or raid:
http://www.garlic.com/~lynn/93.html#28 Log Structured filesystems -- think twice
http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door
http://www.garlic.com/~lynn/94.html#4 Schedulers
http://www.garlic.com/~lynn/94.html#16 Dual-ported disks?
http://www.garlic.com/~lynn/96.html#33 Mainframes & Unix
http://www.garlic.com/~lynn/99.html#197 Computing As She Really Is. Was: Re: Life-Advancing Work of Timothy Berners-Lee
http://www.garlic.com/~lynn/99.html#200 Life-Advancing Work of Timothy Berners-Lee
http://www.garlic.com/~lynn/2000c.html#24 Hard disks, one year ago today
http://www.garlic.com/~lynn/2000c.html#61 TF-1
http://www.garlic.com/~lynn/2000e.html#20 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2001.html#13 Review of Steve McConnell's AFTER THE GOLD RUSH
http://www.garlic.com/~lynn/2001.html#33 Where do the filesystem and RAID system belong?
http://www.garlic.com/~lynn/2001.html#34 Competitors to SABRE?
http://www.garlic.com/~lynn/2001.html#35 Where do the filesystem and RAID system belong?
http://www.garlic.com/~lynn/2001.html#36 Where do the filesystem and RAID system belong?
http://www.garlic.com/~lynn/2001.html#37 Competitors to SABRE?
http://www.garlic.com/~lynn/2001.html#38 Competitors to SABRE?
http://www.garlic.com/~lynn/2001.html#41 Where do the filesystem and RAID system belong?
http://www.garlic.com/~lynn/2001.html#42 Where do the filesystem and RAID system belong?
http://www.garlic.com/~lynn/2001.html#61 Where do the filesystem and RAID system belong?
http://www.garlic.com/~lynn/2001b.html#14 IBM's announcement on RVAs
http://www.garlic.com/~lynn/2001c.html#78 Unix hard links
http://www.garlic.com/~lynn/2001c.html#80 Unix hard links
http://www.garlic.com/~lynn/2001c.html#81 Unix hard links
http://www.garlic.com/~lynn/2001d.html#2 "Bootstrap"
http://www.garlic.com/~lynn/2001d.html#17 "Bootstrap"
http://www.garlic.com/~lynn/2001e.html#31 High Level Language Systems was Re: computer books/authors (Re: FA:
http://www.garlic.com/~lynn/2001f.html#62 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001f.html#71 commodity storage servers
http://www.garlic.com/~lynn/2001g.html#15 Extended memory error recovery
http://www.garlic.com/~lynn/2001j.html#23 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001k.html#5 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001m.html#56 Contiguous file system
http://www.garlic.com/~lynn/2001n.html#70 CM-5 Thinking Machines, Supercomputers
http://www.garlic.com/~lynn/2001n.html#79 a.f.c history checkup... (was What specifications will the standard year 2001 PC have?)
http://www.garlic.com/~lynn/2002d.html#14 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2002e.html#4 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?
http://www.garlic.com/~lynn/2002l.html#47 Do any architectures use instruction count instead of timer
http://www.garlic.com/~lynn/2002n.html#2 SRP authentication for web app
http://www.garlic.com/~lynn/2002n.html#9 Asynch I/O
http://www.garlic.com/~lynn/2002n.html#18 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2003.html#48 InfiniBand Group Sharply, Evenly Divided
http://www.garlic.com/~lynn/2003b.html#68 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#69 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#70 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003c.html#66 FBA suggestion was Re: "average" DASD Blocksize
http://www.garlic.com/~lynn/2003d.html#64 IBM was: VAX again: unix
http://www.garlic.com/~lynn/2003h.html#14 IBM system 370
http://www.garlic.com/~lynn/2003i.html#48 Fix the shuttle or fly it unmanned
http://www.garlic.com/~lynn/2003i.html#54 Fix the shuttle or fly it unmanned
http://www.garlic.com/~lynn/2003j.html#64 Transactions for Industrial Strength Programming
http://www.garlic.com/~lynn/2003m.html#42 S/360 undocumented instructions?
http://www.garlic.com/~lynn/2003n.html#36 Cray to commercialize Red Storm
http://www.garlic.com/~lynn/2004.html#3 The BASIC Variations
http://www.garlic.com/~lynn/2004b.html#41 SSL certificates
http://www.garlic.com/~lynn/2004c.html#38 ATA drives and vibration problems in multi-drive racks
http://www.garlic.com/~lynn/2004d.html#29 cheaper low quality drives
http://www.garlic.com/~lynn/2004d.html#30 cheaper low quality drives
http://www.garlic.com/~lynn/2004e.html#7 OT Global warming
http://www.garlic.com/~lynn/2004e.html#25 Relational Model and Search Engines?
http://www.garlic.com/~lynn/2004f.html#37 Why doesn't Infiniband supports RDMA multicast
http://www.garlic.com/~lynn/2004g.html#13 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#22 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004h.html#43 Hard disk architecture: are outer cylinders still faster than inner cylinders?
http://www.garlic.com/~lynn/2004k.html#28 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2004p.html#38 funny article
http://www.garlic.com/~lynn/2004p.html#59 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2005b.html#1 Foreign key in Oracle Sql
http://www.garlic.com/~lynn/2005d.html#33 Thou shalt have no other gods before the ANSI C standard
http://www.garlic.com/~lynn/2005e.html#5 He Who Thought He Knew Something About DASD
http://www.garlic.com/~lynn/2005e.html#6 He Who Thought He Knew Something About DASD
http://www.garlic.com/~lynn/2005e.html#10 He Who Thought He Knew Something About DASD
http://www.garlic.com/~lynn/2005e.html#11 He Who Thought He Knew Something About DASD
http://www.garlic.com/~lynn/2005h.html#44 First assembly language encounters--how to get started?
http://www.garlic.com/~lynn/2005j.html#13 Performance and Capacity Planning
http://www.garlic.com/~lynn/2005k.html#4 IBM/Watson autobiography--thoughts on?
http://www.garlic.com/~lynn/2005m.html#33 Massive i/o
http://www.garlic.com/~lynn/2005m.html#35 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005m.html#41 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005m.html#46 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005n.html#8 big endian vs. little endian, why?
http://www.garlic.com/~lynn/2005n.html#42 Moz 1.8 performance dramatically improved
http://www.garlic.com/~lynn/2005n.html#51 IPSEC and user vs machine authentication
http://www.garlic.com/~lynn/2005r.html#18 SATA woes
http://www.garlic.com/~lynn/2005t.html#17 winscape?
http://www.garlic.com/~lynn/2006b.html#39 another blast from the past
http://www.garlic.com/~lynn/2006d.html#1 Hercules 3.04 announcement
http://www.garlic.com/~lynn/2006d.html#3 Hercules 3.04 announcement
http://www.garlic.com/~lynn/2006d.html#24 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006l.html#6 Google Architecture
http://www.garlic.com/~lynn/2006l.html#14 virtual memory
http://www.garlic.com/~lynn/2006o.html#9 Pa Tpk spends $30 million for "Duet" system; but benefits are unknown
http://www.garlic.com/~lynn/2006p.html#47 "25th Anniversary of the Personal Computer"
http://www.garlic.com/~lynn/2006r.html#37 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006u.html#18 Why so little parallelism?
http://www.garlic.com/~lynn/2006u.html#56 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006v.html#37 Is this true? (Were gotos really *that* bad?)

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

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Future of CPUs: What's After Multi-Core?
Newsgroups: alt.folklore.computers
Date: Thu, 21 Dec 2006 11:49:07 -0700

eugene@cse.ucsc.edu (Eugene Miya) writes:

It surprises me that percentage of memory used by a running program was
never a big metric.  Things on the application side only started to get
interesting when it exceeded 51% and approached 99%.  Some people might
have run into that problem on disk, but less so main memory.  VM clouds
that issue (Lynn would argue makes usable more memory [but he would not
point out sacrificing performance]).  You guys all use such small
numbers in the computing sense.

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

again do you have a meaning other than what you had typed?

i've repeatedly used examples comparing 360/67 operating in 360/65
mode (w/o hardware relocation) compared to 360/67 operating with dat
enable.

basic 360/65 (and 360/67) double word memory cycle time was 750ns (for
uniprocessor).  DAT (dynamic address translation) added 150ns to that
... or 900ns (multiprocessor calculation got a lot more complex).

that is just the base hardware overhead ... doesn't include
associative array miss ... i.e. the 150ns is only for when the
virtual->real translation is in the eight entry associative array.
it also doesn't include the software overhead of managing the tables
... or software overhead of doing page i/o operations (moving pages
into/out of memory).

as to the software overhead ... part of some of my statements with
regard to cp67 virtual memory support was i rewrote most of it as an
undergraduate in the 60s and reduced the overhead by better than an
order of magnitude ... but still didn't make it disappear.

maybe you are confusing some of my statements about having rewritten
the code and reduced the software overhead by better than an order of
magnitude with my not being able to understand that the overhead is
non-zero.

later the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

developed extensive metrics as to all aspects of system performance ...
some of it mentioned in collected posts on extensive benchmarking,
work load profiling and precursor to what has become capacity planning,
virtual memory operation
http://www.garlic.com/~lynn/subtopic.html#bench

another aspect of it was vs/repack ... which was a application/product
for doing extensive program monitoring and implemented semi-automated
program reorganization for operation in virtual memory environment ...
recent post about vs/repack technology (dating back to published
article from 71)
http://www.garlic.com/~lynn/2006x.html#1

in combination there was quite a bit of investigation of things like
"weak" and "strong" working sets (something sometimes seen today with
processor caches as locality of reference) as well as percentage of
total real storage required.

misc. past posts mentiong 750/900ns difference, associative array, etc
http://www.garlic.com/~lynn/93.html#26 MTS & LLMPS?
http://www.garlic.com/~lynn/94.html#46 Rethinking Virtual Memory
http://www.garlic.com/~lynn/95.html#10 Virtual Memory (A return to the past?)
http://www.garlic.com/~lynn/98.html#46 The god old days(???)
http://www.garlic.com/~lynn/99.html#4 IBM S/360
http://www.garlic.com/~lynn/2000.html#88 ASP (was: mainframe operating systems)
http://www.garlic.com/~lynn/2000b.html#52 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000f.html#59 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2000g.html#9 360/370 instruction cycle time
http://www.garlic.com/~lynn/2000g.html#21 360/370 instruction cycle time
http://www.garlic.com/~lynn/2001.html#71 what is interrupt mask register?
http://www.garlic.com/~lynn/2001c.html#7 LINUS for S/390
http://www.garlic.com/~lynn/2001c.html#84 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001h.html#9 VM: checking some myths.
http://www.garlic.com/~lynn/2002b.html#6 Microcode?
http://www.garlic.com/~lynn/2002c.html#44 cp/67 (coss-post warning)
http://www.garlic.com/~lynn/2002d.html#51 Hardest Mistake in Comp Arch to Fix
http://www.garlic.com/~lynn/2002f.html#13 Hardware glitches, designed in and otherwise
http://www.garlic.com/~lynn/2002g.html#61 GE 625/635 Reference + Smart Hardware
http://www.garlic.com/~lynn/2003.html#13 FlexEs and IVSK instruction
http://www.garlic.com/~lynn/2003g.html#10a Speed of APL on 360s, was Any DEC 340 Display System Doco ?
http://www.garlic.com/~lynn/2003g.html#20 price ov IBM virtual address box??
http://www.garlic.com/~lynn/2003g.html#22 303x, idals, dat, disk head settle, and other rambling folklore
http://www.garlic.com/~lynn/2003g.html#23 price ov IBM virtual address box??
http://www.garlic.com/~lynn/2003g.html#33 price ov IBM virtual address box??
http://www.garlic.com/~lynn/2003k.html#48 Who said DAT?
http://www.garlic.com/~lynn/2003m.html#29 SR 15,15
http://www.garlic.com/~lynn/2003o.html#52 Virtual Machine Concept
http://www.garlic.com/~lynn/2004.html#16 Holee shit!  30 years ago!
http://www.garlic.com/~lynn/2004.html#25 40th anniversary of IBM System/360 on 7 Apr 2004
http://www.garlic.com/~lynn/2004.html#53 Mainframe not a good architecture for interactive workloads
http://www.garlic.com/~lynn/2004c.html#6 If the x86 ISA could be redone
http://www.garlic.com/~lynn/2004c.html#46 IBM 360 memory
http://www.garlic.com/~lynn/2005b.html#62 The mid-seventies SHARE survey
http://www.garlic.com/~lynn/2005d.html#66 Virtual Machine Hardware
http://www.garlic.com/~lynn/2005g.html#17 DOS/360: Forty years
http://www.garlic.com/~lynn/2005h.html#18 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005j.html#43 A second look at memory access alignment
http://www.garlic.com/~lynn/2005k.html#5 IBM/Watson autobiography--thoughts on?
http://www.garlic.com/~lynn/2005p.html#27 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005s.html#20 MVCIN instruction
http://www.garlic.com/~lynn/2005s.html#21 MVCIN instruction
http://www.garlic.com/~lynn/2006.html#15 S/360
http://www.garlic.com/~lynn/2006e.html#0 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006x.html#4 S0C1 with ILC 6
http://www.garlic.com/~lynn/2006x.html#5 S0C1 with ILC 6

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

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

eugene@cse.ucsc.edu (Eugene Miya) writes:

It surprises me that percentage of memory used by a running program was
never a big metric.  Things on the application side only started to get
interesting when it exceeded 51% and approached 99%.  Some people might
have run into that problem on disk, but less so main memory.  VM clouds
that issue (Lynn would argue makes usable more memory [but he would not
point out sacrificing performance]).  You guys all use such small
numbers in the computing sense.

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

again do you have a meaning other than what you typed?

when I was an undergraduate in the 60s, nearly all of the mainframes
were real memory systems. i had responsibility for building and
supporting the univ. production (real memory) system.

three people from the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

the last week in jan68 to deliver cp67 (virtual memory and virtul machine
support).

in my spare time between classes and my primary job responsibilities,
I got to play a little with cp67. nearly all of the applications to be
run under cp67 came over from real memory environment ... so as a
result there was constant comparison of how the application ran in the
real memory environment vis-a-vis the degradation cp67 due to 1)
hardware translation, 2) software virtual memory support and 3)
software virtual machine support ... which were all heavily measured
and identified as sources of degradation.

these days you have very few A/B comparisons (of the same exact
application running with the same exact libraries and operating
system) in real memory mode compared to virtual memory mode.

However, in the little spare time that I had to play cp67 ... i did
manage to come up with a lot of technology that I was then able to
design, implementat and deploy ... recent reference to global LRU
replacement algorithm work
http://www.garlic.com/~lynn/2006w.html#46 The Future of CPUs: What's After Multi-Core?
recent reference to dyanmic adaptive scheduling work
http://www.garlic.com/~lynn/2006x.html#10 The Future of CPUs: What's After Multi-Core?

a few posts referencing part of a conference presentation that i made
later in '68 on some of my cp67 enhancements comparing real memory
operating system performance ... running on real memory processor and
running in virtual address space under cp67 (after having a few months
to play with the cp67 source code)
http://www.garlic.com/~lynn/93.html#1 360/67, was Re: IBM's Project F/S ?
http://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14
http://www.garlic.com/~lynn/94.html#20 CP/67 & OS MFT14
http://www.garlic.com/~lynn/97.html#22 Pre S/360 IBM Operating Systems?
http://www.garlic.com/~lynn/98.html#21 Reviving the OS/360 thread (Questions about OS/360)
http://www.garlic.com/~lynn/99.html#93 MVS vs HASP vs JES (was 2821)
http://www.garlic.com/~lynn/2001f.html#26 Price of core memory
http://www.garlic.com/~lynn/2001i.html#33 Waterloo Interpreters (was Re: RAX (was RE: IBM OS Timeline?))
http://www.garlic.com/~lynn/2001k.html#37 Is anybody out there still writting BAL 370.
http://www.garlic.com/~lynn/2001l.html#42 is this correct ? OS/360 became MVS and MVS >> OS/390
http://www.garlic.com/~lynn/2002c.html#45 cp/67 addenda (cross-post warning)
http://www.garlic.com/~lynn/2002f.html#38 Playing Cards was Re: looking for information on the IBM
http://www.garlic.com/~lynn/2002l.html#55 The problem with installable operating systems
http://www.garlic.com/~lynn/2002m.html#3 The problem with installable operating systems
http://www.garlic.com/~lynn/2002n.html#29 why does wait state exist?
http://www.garlic.com/~lynn/2002n.html#53 SHARE MVT Project anniversary
http://www.garlic.com/~lynn/2003d.html#72 cp/67 35th anniversary
http://www.garlic.com/~lynn/2004f.html#6 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2005n.html#40 You might be a mainframer if... :-) V3.8
http://www.garlic.com/~lynn/2005t.html#8 2nd level install - duplicate volsers
http://www.garlic.com/~lynn/2006.html#41 Is VIO mandatory?
http://www.garlic.com/~lynn/2006e.html#45 using 3390 mod-9s
http://www.garlic.com/~lynn/2006m.html#25 Mainframe Limericks
http://www.garlic.com/~lynn/2006w.html#22 Are hypervisors the new foundation for system software?

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

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Future of CPUs: What's After Multi-Core?
Newsgroups: alt.folklore.computers
Date: Thu, 21 Dec 2006 15:21:18 -0700

eugene@cse.ucsc.edu (Eugene Miya) writes:

Because mainframes are centralized fixed fortifications which at
best belong to an ancient less distributed era.  Distributed
computing is hard.  At best we have the crudest of fault tolerance
built into systems.  Parity started as a joke with Cray (for
instance).  Many programmers have no idea about parity.  The
communication guys who think about it usually think in terms of
checksums not whole systems.  From the security/insecurity
perceptive the first thing to do if you seriously wanted penetration
tools is develop a checksum spoofer.  That would be the first of
many tools for a workbench.

do you mean what you typed? misc. refs:
http://www.garlic.com/~lynn/2006j.html#45 Arpa address
http://www.garlic.com/~lynn/2006k.html#8 Arpa address
http://www.garlic.com/~lynn/2006k.html#9 Arpa address
http://www.garlic.com/~lynn/2006k.html#34 PDP-1
http://www.garlic.com/~lynn/2006n.html#2 The System/360 Model 20 Wasn't As Bad As All That
http://www.garlic.com/~lynn/2006x.html#15 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006x.html#16 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006x.html#17 The Future of CPUs: What's After Multi-Core?

there are lots of tales about ruggedized 360s & 370s all over the place.

for minor topic drift recent post referencing distributed
lock manager supporting distributed DBMS operation while meeting ACID
properties
http://www.garlic.com/~lynn/2006x.html#3 Why so little parallism?

then there is the reference to location that Boyd managed that
supposedly was a $2.5B (billion) windfall for IBM ... misc past
posts mentioning the windfall
http://www.garlic.com/~lynn/2005m.html#22 Old Computers and Moisture don't mix - fairly  OT
http://www.garlic.com/~lynn/2005m.html#23 Old Computers and Moisture don't mix - fairly  OT
http://www.garlic.com/~lynn/2005m.html#24 Old Computers and Moisture don't mix - fairly  OT
http://www.garlic.com/~lynn/2005t.html#1 Dangerous Hardware
http://www.garlic.com/~lynn/2006q.html#37 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006q.html#38 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006u.html#49 Where can you get a Minor in Mainframe?
http://www.garlic.com/~lynn/2006u.html#50 Where can you get a Minor in Mainframe?

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

you saw a lot of distributed computing starting to happen with 370
138s & 148s ...  but it really started to come into full swing with
4331/4341 customer orders in the later 70s ... much more than vax
market (from late 70s thru mid-80s). customers were ordering then in
blocks of a hundred. one large chip design shop had a single order for
nearly 1000. these 4341 "mainframes" frequently didn't go into
traditional glasshouse locations (centralized fixed fortifications)
... they went into similar market segment as a many of the vax
machines ... except there were a lot more of them. there were stories
about locations co-opt'ing large percentage of the conference rooms
for locating the machines.

and reference to air force order in late 70s for 210 4341s
http://www.garlic.com/~lynn/2001m.html#15 departmental servers

for comparison a few past posts given vax shipments broken out by
year, model, US, world-wide, etc.
http://www.garlic.com/~lynn/2002f.html#0 Computers in Science Fiction
http://www.garlic.com/~lynn/2005f.html#37 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2006k.html#31 PDP-1

there are business critical data processing operations which formulate
criteria for their "glass house" operation ... these fixed
fortifications frequently are populated with mainframes, in part,
because of various of the business critical data processing
requirements ... however, many such "glass houses" may also be the
location for several hundred (or thousand) corporate "distributed
servers" ... again because of the corporations' business critical data
processing requirements ... and pretty much totally orthogonal to any
networking and/or distributed computing architecture issues.

earlier decades there was some driving factor for distributed
computing being co-located at remote sites ... in large part because
of constrained communication facilities. however, with advances in
communication and networking technology ... there starts to be more
latitude and trade-offs with regard to physical location.

some recent posts including old email about physical distributed as well
as distributed computing
http://www.garlic.com/~lynn/2006p.html#34 "25th Anniversary of the Personal Computer"
http://www.garlic.com/~lynn/2006p.html#40 "25th Anniversary of the Personal Computer"
http://www.garlic.com/~lynn/2006s.html#41 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006t.html#47 To RISC or not to RISC
http://www.garlic.com/~lynn/2006v.html#11 What's a mainframe?
http://www.garlic.com/~lynn/2006v.html#17 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006v.html#19 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006v.html#23 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006v.html#25 Ranking of non-IBM mainframe builders?

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

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Future of CPUs: What's After Multi-Core?
Newsgroups: alt.folklore.computers
Date: Fri, 22 Dec 2006 08:42:53 -0700

jmfbahciv writes:

Lynn is missing the point a little bit but is getting the idea.

a large part of how machines are deployed and managed have to do with
their uses .... there is also big issue of perception.

i've joked before about the perception regarding some companies
providing batch or timesharing ... as if it was an either/or scenario.

at one point there was perception that multics provided a lot more
timesharing than ibm mainframes ... presumably because there were so
many ibm mainframes being used for batch business critical operations.

i've mentioned before that there were significantly larger number of
customers using ibm mainframes for batch business critical operations
than were using them for strictly timesharing services ... ala cms,
cp67, and vm370. and the internal corporate use of ibm mainframes for
cp67, cms, and vm370 was smaller number than the total customer use of
cp67, cms, and vm370.

at one point
http://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?

I was building highly customized vm370 systems and shipping them
directly to internal timesharing corporate installation. these
internal timesharing corporate installations that i was directly
supporting was only a small percentage of the total number of internal
timesharing corporate installations. the total number of internal
timesharing corporate installations was smaller than the total nubmer
of customer timesharing installations. However, at its peak, the total
number of internal timesharing corporate installations that I was
building systems for was about about the same as the total number of
Multics systems that ever existed in the lifetime of Multics operation
(it didn't seem to be fair to compare the total number of vm370
systems to the total number of Multics systems ... or even the total
number of internal corporate vm370 systems to the total number of
Multics systems ... I'm only talking about the number of systems that
I directly built compared to the total number of Multics systems).

While the number of IBM mainframes used for such timesharing
operations was larger than any other vendor building systems for
timesharing use, the perception seems to have been that such use was
almost non-existant ... possibly because the number of such
timesharing systems was so dwarfed by the number of batch commercial
systems (i.e. the number of dedicated timesharing systems wasn't
actually that small ... it was that the number of batch commercial
systems was so much larger ... which appeared to warp peoples'
perception).

misc. past posts mentioning comparing the number of multics timesharing
systems
http://www.garlic.com/~lynn/2000f.html#60 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2001h.html#34 D
http://www.garlic.com/~lynn/2003d.html#68 unix
http://www.garlic.com/~lynn/2003g.html#29 Lisp Machines
http://www.garlic.com/~lynn/2004c.html#47 IBM 360 memory
http://www.garlic.com/~lynn/2005d.html#39 Thou shalt have no other gods before the ANSI C standard
http://www.garlic.com/~lynn/2005q.html#39 How To Abandon Microsoft
http://www.garlic.com/~lynn/2006m.html#25 Mainframe Limericks

Also as pointed at before ... no commercial timesharing offerings ever
appeared based on Multics ... however, there were several such
commercial timesharing offerings based on vm370 (with some even going
back to cp67 days starting in the late 60s).
http://www.garlic.com/~lynn/subtopic.html#timeshare

some number of these commercial timesharing services even supported
commercial corporate applications that would involve extremely
sensitive corporate information ... and even hosted different
competitive corporate clients (with extremely sensitive operations) on
the same platform. as such they had to have fairly significant
security measures to kept their (varied) corporate clients operations
private/confidential (from other clients and from outsiders) a small
example of that was alluded to here
http://www.garlic.com/~lynn/2006v.html#22 vmshare

and as to others with various kinds of integrity and confidentiality
requirements ... a small reference here
http://www.garlic.com/~lynn/2006w.html#0 Patent buster for a method that increases password security

and as referred to here ... some amount of the physical security &
integrity offered a computing platform ... may reflect the applications
being used and/or the data being processed ... as opposed to being
inherently a characteristics of the hardware.
http://www.garlic.com/~lynn/2006x.html#18 The Future of CPUs: What's After Multi-Core?

To some extent, how tools are used and deployed ... will reflect what
it is the tools are being used for. If tools are for extreme business
critical dataprocessing ... the deployment and operation can be
different than when a similar platform is used for less critical
purposes.

I've referenced before that circa 1970 ... the science center started
on joint project with endicott to add support for 370 virtual machines
with 370 virtual memory ... to cp67 kernel (running on 360/67). this
project included using network link between endicott and cambridge
for form of distributed development ... referenced here
http://www.garlic.com/~lynn/2006u.html#7 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006w.html#3 IBM sues make of Intel-based Mainframe clones

... as well as early driver for the development of cms multi-level
source management referenced here
http://www.garlic.com/~lynn/2006w.html#42 vmshare
http://www.garlic.com/~lynn/2006w.html#48 vmshare

At the time, information that virtual memory support was going to be
available on 370 machines was a closely guarded corporate secret ...
and required significant security measures.

Another undertaking at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

was the porting of apl\360 to cms. while the existance of apl on cms
wasn't a closely guarded corporate secret ... cambridge offered online
cms\apl services to internal corporate users. typical apl\360
offerrings at the time offered users 16kbyte (or possibly 32kbyte)
workspaces.  cms\apl opened that up so that several mbyte workspaces
were then possible. This enabled using cms\apl for some real-live
business modeling uses (some of the stuff typically done with
spreadsheets today) ... and cambridge got some corporate hdqtrs users
... who proceeded to load the most sensitive corporate business data
on the cambridge system (in support of their business modeling
activities).

the 370 virtual memory activity and the corporate business modeling
involved some of the most senstive and critical corporate information
of the period ... being hosted on the cambridge cp67 system. At the
same time, there was significant use of the cambridge cp67 system by
people (students and others) at various universities in the cambridge
area (mit, harvard, bu, ne, etc). This created some amount of security
tension ... having to provide the very highest level of corporate
security protection on the same platform that was being used by
univ. students and other non-employees.

misc. past mention of cambridge cp67 system and security exposure
http://www.garlic.com/~lynn/2001i.html#44 Withdrawal Announcement 901-218 - No More 'small machines'
http://www.garlic.com/~lynn/2002h.html#60 Java, C++ (was Re: Is HTML dead?)
http://www.garlic.com/~lynn/2004b.html#31 determining memory size
http://www.garlic.com/~lynn/2004c.html#7 IBM operating systems
http://www.garlic.com/~lynn/2004h.html#27 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2005f.html#63 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005p.html#20 address space
http://www.garlic.com/~lynn/2005p.html#27 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
http://www.garlic.com/~lynn/2006b.html#23 Seeking Info on XDS Sigma 7 APL
http://www.garlic.com/~lynn/2006f.html#5 3380-3390 Conversion - DISAPPOINTMENT
http://www.garlic.com/~lynn/2006h.html#14 Security
http://www.garlic.com/~lynn/2006n.html#2 The System/360 Model 20 Wasn't As Bad As All That
http://www.garlic.com/~lynn/2006o.html#19 Source maintenance was Re: SEQUENCE NUMBERS

"The Elements of Programming Style"

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

"John Coleman" <jcoleman@franciscan.edu> writes:

2) The following passage struck me as ironic in view of the fact that
Kernighan subsequently had his name indelibly attached to C, a language
which was to become notorious for subscript out of range bugs
(especially in the guise of buffer overflows):

"Some compilers (WATFIV, PL/I with SUBSCRIPTRANGE enabled, for
instance) allow a check during execution that subscripts do not exceed
array dimensions... [but] many programmers do not use such compilers
because 'They're not efficient' (Presumably this means that it is vital
to get the wrong answer quickly.)" pg. 85. Here, I think, the irony is
only apparent given the original target of C as a systems programming
language on minicomputers (as opposed to application on main frames)
where the added effeciency was worth the extra debugging time required
to get it right. But nowadays I can't see why anyone wouldn't use
runtime subscript checking.

I've contended that far more egregious than subscript out of range has
been implicit string lengths found extensively in lots of string
libraries and application code. the use of implicit lengths
... including null terminated strings aggravates the situation.

lets say it is implicitly part of the "C" programming style.

PLI and many system implementations have conventions where buffers
have actual lengths ... both max and current. simple operation of
copying a string from one place to another ... there is an explicit
length of the origin string and an explicit max. length of the target
...  and string copy/move operations explicitly support the lengths
... i.e.  lots of buffer overflows aren't program subscript at
a time ... it involves move/copy that is apparently totally ignorant
of the target location size as well as the origin location size. With
explicit lengths, some large number of buffer overflows can
never occur whether or not SUBSCRIPTTRANGE is enabled.

misc. past post on buffer overflows
http://www.garlic.com/~lynn/subintegrity.html#overflow

"The Elements of Programming Style"

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

"John Coleman" <jcoleman@franciscan.edu> writes:

1) One of the most interesting passages I read was:

"Most of the IF-ELSE examples we have shown so far have a
characteristic in common. Each approximates, as closely as the
programmer could manage, a minimum depth decision tree for the problem
at hand ... But a program is a one-dimensional construct, which
obscures any two-dimensional connectness it may have." (pg 46). This
passage suggested to me that maybe one of the sources of spaghetti code
was the use of flow charts in algorithm design, since flow-charts are
2-dimensional. Is there any truth to this? To what extent did
programmers actually *use* flow charts? Since I am a mathematician, I
thought of a mathematical analogy - any graph (system of nodes and
edges) can be embedded in 3 - dimensional space without a hitch, but if
you try to draw them in 2 dimensions, some graphs (the non-planar ones)
force you to introduce edge-crossings which detract from the
readability of the diagram. Maybe gotos are analogous to edge-crossings
- the cost of representing a structure in a space with fewer
dimensions.

for a different case ... in the early 70s I wrote a PLI program that
analyzed (360/370) assembler listings, attempted to construct program
flow, register use before set, and also generate psuedo higher level
language ... assembler was all branch (aka goto) ... but i tried to
interpret the program flow logic as if/then/else, do/while/until,
constructs.

for some straight-foward application flow ... it turned into
relatively straight-forward readable code. however, there was some
highly optimized kernel routines where the if/then/else/do/while/until
could be less clear than than the original assembler. it typically
involved a larger amount of state testing with all sorts of
condiitional processing. I eventually implemented a nested threshold
limit ... and dropped back to GOTOs when the threashold was exceeded.

recent post about some of the Fort Knox people (effort to replace many
of the internal corporate microprocessors with 801) that were looking
at using 801 for low/mid range 370s ... and possibility of doing 370
machine language program analysis and a form of JIT.
http://www.garlic.com/~lynn/2006u.html#29 To RISC or not to RISC
http://www.garlic.com/~lynn/2006u.html#31 To RISC or not to RISC
http://www.garlic.com/~lynn/2006u.html#32 To RISC or not to RISC

and further fort knox drift
http://www.garlic.com/~lynn/2006u.html#37 To RISC or not to RISC
http://www.garlic.com/~lynn/2006u.html#38 To RISC or not to RISC

and past thread about some of the characteristics/issues with doing
such machine instruction analysis and if/else program flow construction
http://www.garlic.com/~lynn/2006e.html#32 transputers again was: The