List of Archived Posts

2010 Newsgroup Postings (03/28 - 04/09)

16:32 far pointers in OpenWatcom C/C++
IA64
16:32 far pointers in OpenWatcom C/C++
16:32 far pointers in OpenWatcom C/C++
Handling multicore CPUs; what the competition is thinking
16:32 far pointers in OpenWatcom C/C++
Call for XEDIT freaks, submit ISPF requirements
Call for XEDIT freaks, submit ISPF requirements
Handling multicore CPUs; what the competition is thinking
Far and near pointers on the 80286 and later
Gov't coerced Certs thwart SSL/TLS
Mainframe Executive article on the death of tape
Reverse or inverse ARP from windows/linux - no way (!?!?)
An Interview with Watts Humphrey, Part 6: The IBM 360
Gov't coerced Certs thwart SSL/TLS
Far and near pointers on the 80286 and later
Far and near pointers on the 80286 and later
Far and near pointers on the 80286 and later
The 2010 Census
The 2010 Census
16:32 far pointers in OpenWatcom C/C++
Should the USA Implement EMV?
Mainframe Executive article on the death of tape
16:32 far pointers in OpenWatcom C/C++
Mainframe Executive article on the death of tape
Intel Nehalem-EX Aims for the Mainframe
Tapes versus vinyl
Intel Nehalem-EX Aims for the Mainframe
Intel Nehalem-EX Aims for the Mainframe
someone smarter than Dave Cutler
Mainframe Executive article on the death of tape
Mainframe Executive article on the death of tape
Intel Nehalem-EX Aims for the Mainframe
SQL Server replacement
someone smarter than Dave Cutler
Intel Nehalem-EX Aims for the Mainframe
16:32 far pointers in OpenWatcom C/C++
16:32 far pointers in OpenWatcom C/C++
someone smarter than Dave Cutler
someone smarter than Dave Cutler
someone smarter than Dave Cutler
someone smarter than Dave Cutler
Interesting presentation
Interesting presentation
16:32 far pointers in OpenWatcom C/C++
IA64
16:32 far pointers in OpenWatcom C/C++
16:32 far pointers in OpenWatcom C/C++
Handling multicore CPUs; what the competition is thinking
16:32 far pointers in OpenWatcom C/C++
Call for XEDIT freaks, submit ISPF requirements
Call for XEDIT freaks, submit ISPF requirements
Handling multicore CPUs; what the competition is thinking
Far and near pointers on the 80286 and later
Gov't coerced Certs thwart SSL/TLS
Mainframe Executive article on the death of tape
Reverse or inverse ARP from windows/linux - no way (!?!?)
An Interview with Watts Humphrey, Part 6: The IBM 360
Gov't coerced Certs thwart SSL/TLS
Far and near pointers on the 80286 and later
Far and near pointers on the 80286 and later
Far and near pointers on the 80286 and later
The 2010 Census
The 2010 Census
16:32 far pointers in OpenWatcom C/C++
Fraudsters Can Easily Buy SSL Certificates, Researcher Finds
What is the protocal for GMT offset in SMTP (e-mail) header
Interesting presentation
What is the protocal for GMT offset in SMTP (e-mail) header
someone smarter than Dave Cutler
What is the protocal for GMT offset in SMTP (e-mail) header
Interesting presentation
Interesting presentation
Interesting presentation
Unknown SSL credential could imperil Firefox, Mac users
What is the protocal for GMT offset in SMTP (e-mail) header header time-stamp?
What is the protocal for GMT offset in SMTP (e-mail) header header time-stamp?
IBM responds to Oracle's Exadata with new systems
memory latency, old and new
In SSL We Trust? Not Lately
What is the protocal for GMT offset in SMTP (e-mail) header time-stamp?
What is the protocal for GMT offset in SMTP (e-mail) header time-stamp?
[OT] What is the protocal for GMT offset in SMTP (e-mail) header time-stamp?
Far and near pointers on the 80286 and later
In SSL We Trust? Not Lately
What is the protocal for GMT offset in SMTP (e-mail) header

16:32 far pointers in OpenWatcom C/C++

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 16:32 far pointers in OpenWatcom C/C++
Newsgroups: alt.sys.pdp10, alt.folklore.computers
Date: Sun, 28 Mar 2010 14:53:00 -0400
re:
http://www.garlic.com/~lynn/2010f.html#85 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010f.html#89 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010f.html#90 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010f.html#91 16:32 far pointers in OpenWatcom C/C++

as mentioned in the old post
http://www.garlic.com/~lynn/2006w.html#46 The Future of CPUs: What's After Multi-Core?

it took almost a year to get approval before sending even this innocuous item
http://www.garlic.com/~lynn/2006w.html#email821019

i have no evidence that research management were taking sides in the argument ... it was more likely just another one of the petty punishments for having offended somebody or another (i had several papers for external publication that i tried for yrs to get approved before giving up).

i had done an internal paper on RAS/never-fail (work I had done) for the disk engineering labs so that they could have on-demand, anytime arbitrary number of concurrent development testing (as opposed to their pre-scheduled, stand-alone, around the clock dedicated testing). some past posts getting to play disk engineer
http://www.garlic.com/~lynn/subtopic.html#disk

I did happen to include a reference in the internal paper that at one point a standard MVS had been tried and experienced a 15min MTBF in that environment ... which brought down the wrath of the mvs organization on my head. just another "business ethics is oxymoron" ... misc past refs:
http://www.garlic.com/~lynn/2007j.html#72 IBM Unionization
http://www.garlic.com/~lynn/2009.html#53 CROOKS and NANNIES: what would Boyd do?
http://www.garlic.com/~lynn/2009e.html#37 How do you see ethics playing a role in your organizations current or past?
http://www.garlic.com/~lynn/2009o.html#36 U.S. students behind in math, science, analysis says
http://www.garlic.com/~lynn/2009o.html#52 Revisiting CHARACTER and BUSINESS ETHICS
http://www.garlic.com/~lynn/2009o.html#57 U.S. begins inquiry of IBM in mainframe market
http://www.garlic.com/~lynn/2009p.html#43 From The Annals of Release No Software Before Its Time
http://www.garlic.com/~lynn/2009p.html#57 MasPar compiler and simulator
http://www.garlic.com/~lynn/2009p.html#60 MasPar compiler and simulator
http://www.garlic.com/~lynn/2009p.html#87 IBM driving mainframe systems programmers into the ground
http://www.garlic.com/~lynn/2009r.html#50 "Portable" data centers
http://www.garlic.com/~lynn/2010b.html#38 Happy DEC-10 Day
http://www.garlic.com/~lynn/2010c.html#82 search engine history, was Happy DEC-10 Day
http://www.garlic.com/~lynn/2010f.html#20 Would you fight?

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

IA64

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IA64
Newsgroups: comp.sys.intel, alt.folklore.computers
Date: Sun, 28 Mar 2010 15:45:24 -0400
John Levine <johnl@iecc.com> writes:
It's a pattern -- they did the same thing with the project that ended up being the 432. The parallels are quite striking. The 8800/432 project tried to use what was then state of the art thinking about capabilities and parallel processing, while the 8086 was a quick hack to make a followon for the 8085 that had wider registers and addresses. We all know which one won.

acm sigops in asilomar ... '79? or '81? ... there was 432 presentation ... i remember one of the difficulties highlighted was that they had sunk a lot of complex operating stuff into silicon ... and had to replace chips when ever they found/fixed bugs.

some of the stuff 432 moved into silicon ... i had done slightly similar in '75 moving some stuff into microcode for 5-way SMP/parallel 370 project (that never shipped) ... but it was far easier to send out replacement microcode floppy ... that it was to replace processor chips.

misc past posts mentioning i432
http://www.garlic.com/~lynn/2000e.html#6 Ridiculous
http://www.garlic.com/~lynn/2002d.html#27 iAPX432 today?
http://www.garlic.com/~lynn/2004e.html#52 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004q.html#60 Will multicore CPUs have identical cores?
http://www.garlic.com/~lynn/2004q.html#64 Will multicore CPUs have identical cores?
http://www.garlic.com/~lynn/2004q.html#73 Athlon cache question
http://www.garlic.com/~lynn/2005d.html#64 Misuse of word "microcode"
http://www.garlic.com/~lynn/2005k.html#46 Performance and Capacity Planning
http://www.garlic.com/~lynn/2006c.html#47 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006n.html#42 Why is zSeries so CPU poor?
http://www.garlic.com/~lynn/2006n.html#44 Any resources on VLIW?
http://www.garlic.com/~lynn/2007s.html#36 Oracle Introduces Oracle VM As It Leaps Into Virtualization
http://www.garlic.com/~lynn/2008d.html#54 Throwaway cores
http://www.garlic.com/~lynn/2008e.html#32 CPU time differences for the same job
http://www.garlic.com/~lynn/2008k.html#22 CLIs and GUIs
http://www.garlic.com/~lynn/2009d.html#52 Lack of bit field instructions in x86 instruction set because of patents ?
http://www.garlic.com/~lynn/2009q.html#74 Now is time for banks to replace core system according to Accenture

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

16:32 far pointers in OpenWatcom C/C++

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 16:32 far pointers in OpenWatcom C/C++
Newsgroups: alt.sys.pdp10, alt.folklore.computers
Date: Sun, 28 Mar 2010 15:48:04 -0400
Michael Wojcik <mwojcik@newsguy.com> writes:
Is this the two-handed-clock algorithm?

re:
http://www.garlic.com/~lynn/2010f.html#85 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010f.html#89 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010f.html#90 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010f.html#91 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010g.html#0 16:32 far pointers in OpenWatcom C/C++

it is two-handed-clock with a twist ... how the reset hand worked

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

16:32 far pointers in OpenWatcom C/C++

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 16:32 far pointers in OpenWatcom C/C++
Newsgroups: alt.sys.pdp10, alt.folklore.computers
Date: Mon, 29 Mar 2010 00:15:07 -0400
Mark Crispin <mrc@panda.com> writes:
Speaking as someone who operated class scheduling on TOPS-20 for some years, the people who say that they want class scheduling invariably end up being very unhappy with the results. Inevitably, the people who think that they are not receiving the "fair 40% of the CPU that they paid for" turn out to have been using quite a bit more, and thus receive less under class scheduling.

my dynamic adaptive resource manager that i did as undergraudate in the 60s for cp67 .... was periodically referred to as "fair share" scheduler (default resource policy was fair share) or the wheeler scheduler. it was dropped in a lot of simplification that was involved in the morph from cp67 to vm370; however it later migrated it to vm370 and it was eventually shipped to customers. There was also a large number of internal datacenter customers ... and for a while ... i shipped/supported directly more than a hundred such internal datacenters. some old email related to moving misc. stuff from cp67 to vm370:
http://www.garlic.com/~lynn/2006v.html#email731212
http://www.garlic.com/~lynn/2006w.html#email750102
http://www.garlic.com/~lynn/2006w.html#email750430

at one point, the people running the internal STL datacenter was talking about the large number of different depts in STL clamering for more control over resource allocation (dept. specific specified allocation) ... so i did a version that allowed specifying aggregate goals and then allowing fair share and/or other policies within aggregate (that is subset of the whole computer).

The STL datacenter management told me they wouldn't even remotely touch such a thing ... if i thot there internal deprt. user group meetings were bad now ... just see what would happen if the different depts. thot that there was a way for setting dept. specific goals ... then the political infighting would get horribly vicious ... with the datacenter management square in the middle of everybody's crossfire.

other points in this thread:
http://www.garlic.com/~lynn/2010f.html#85 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010f.html#89 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010f.html#90 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010f.html#91 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010g.html#0 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010g.html#2 16:32 far pointers in OpenWatcom C/C++

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Handling multicore CPUs; what the competition is thinking

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Handling multicore CPUs; what the competition is thinking
Newsgroups: comp.os.linux.advocacy, comp.os.linux.hardware, comp.arch,
alt.folklore.computers
Date: Mon, 29 Mar 2010 10:08:17 -0400
then there is this news item from last year

IBM pureScale Technology Redefines Transaction Processing Economics. New DB2 Feature Sets the Bar for System Performance on More than 100 IBM Power Systems
http://www-03.ibm.com/press/us/en/pressrelease/28593.wss

that I reference in post on "From The Annals of Release No Software Before Its Time"
http://www.garlic.com/~lynn/2009p.html#43

other posts with comments:
http://www.garlic.com/~lynn/2009p.html#35 DB2 announces technology that trumps Oracle RAC and Exadata
http://www.garlic.com/~lynn/2009p.html#42 big iron mainframe vs. x86 servers

past posts in this thread:
http://www.garlic.com/~lynn/2010f.html#50 Handling multicore CPUs; what the competition is thinking
http://www.garlic.com/~lynn/2010f.html#52 Handling multicore CPUs; what the competition is thinking
http://www.garlic.com/~lynn/2010f.html#55 Handling multicore CPUs; what the competition is thinking
http://www.garlic.com/~lynn/2010f.html#56 Handling multicore CPUs; what the competition is thinking
http://www.garlic.com/~lynn/2010f.html#57 Handling multicore CPUs; what the competition is thinking
http://www.garlic.com/~lynn/2010f.html#58 Handling multicore CPUs; what the competition is thinking
http://www.garlic.com/~lynn/2010f.html#60 Handling multicore CPUs; what the competition is thinking
http://www.garlic.com/~lynn/2010f.html#61 Handling multicore CPUs; what the competition is thinking
http://www.garlic.com/~lynn/2010f.html#63 Handling multicore CPUs; what the competition is thinking
http://www.garlic.com/~lynn/2010f.html#64 Handling multicore CPUs; what the competition is thinking
http://www.garlic.com/~lynn/2010f.html#70 Handling multicore CPUs; what the competition is thinking
http://www.garlic.com/~lynn/2010f.html#73 Handling multicore CPUs; what the competition is thinking

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

16:32 far pointers in OpenWatcom C/C++

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 16:32 far pointers in OpenWatcom C/C++
Newsgroups: alt.sys.pdp10, alt.folklore.computers
Date: Mon, 29 Mar 2010 13:17:37 -0400
Mark Crispin <mrc@panda.com> writes:
Most of the monitor was swappable. Pretty much all system call code was. The non-swappable stuff was either interrupt code, scheduler code, or code called from interrupts or scheduler.

original cp67 monitor code was all fixed ... along with pre-allocated, fixed "stack" (actually fixed number of save areas).

some of the things I did as undergraduate in the 60s (actually the summer I was brought in to boeing to help setting up boeing computer services) ... were

1) when pre-allocated saveareas (for calling) ran out ... be able to allocate additional saveareas (taken from the dynamic paging area)

2) all internal kernel calling convention involved SVC interrupt that would dynamically allocate save area ... and then the reverse on return. a majority of kernel calls were to small subroutines that would immediately return ... w/o calling any other routine (and so never required dynamically allocated save area). I modified this to be a direct BALR call and used a pre-allocated fixed savearea located in real storage "page zero" (aka there was unique page zero for every processor in complex). The original CP67 SVC call/return convention took over 270mics on 360/67 ... for a large number of simple subroutine calls that might take 50mics total.

3) make portions of the cp67 kernel pageable ... kernel section was split into two contiguous areas ... the low-area that had to be fixed ... and the higher-area that could be be paged. this never shipped in standard cp67 product ... but was adopted for initial release of vm370. Only routines that were called by SVC call/return linkage were in the pageable area ... and so the logic for handling the paging gorp was all encapsulated as part of the call/return processing.

other posts in this thread:
http://www.garlic.com/~lynn/2010f.html#85 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010f.html#89 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010f.html#90 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010f.html#91 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010g.html#0 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010g.html#2 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010g.html#3 16:32 far pointers in OpenWatcom C/C++

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Call for XEDIT freaks, submit ISPF requirements

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@GARLIC.COM (Anne & Lynn Wheeler)
Subject: Re: Call for XEDIT freaks, submit ISPF requirements
Newsgroups: bit.listserv.ibm-main
Date: 29 Mar 2010 10:46:02 -0700
mark.van-der-eynden@HP.COM (Mark van der Eynden) writes:
If you have the command in col 1 (i.e. no piping) it would be 'stack *'

But gees guys, you're talking about 25 year old memories, I'd expect XEDIT is even better now -)


for a little topic drift ... old posts detailing how a lot of ISPF development was paid for by siphoning off revenue from VM370 Performance products:
http://www.garlic.com/~lynn/2000d.html#17 Where's all the VMers?
http://www.garlic.com/~lynn/2001m.html#33 XEDIT on MVS
http://www.garlic.com/~lynn/2003k.html#0 VSPC
http://www.garlic.com/~lynn/2005t.html#40 FULIST
http://www.garlic.com/~lynn/2006k.html#50 TSO and more was: PDP-1
http://www.garlic.com/~lynn/2007g.html#17 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007o.html#41 Virtual Storage implementation
http://www.garlic.com/~lynn/2007o.html#69 ServerPac Installs and dataset allocations
http://www.garlic.com/~lynn/2007t.html#55 new 40+ yr old, disruptive technology
http://www.garlic.com/~lynn/2008h.html#43 handling the SPAM on this group
http://www.garlic.com/~lynn/2009s.html#46 DEC-10 SOS Editor Intra-Line Editing

the issue was that traditional favorite son operating system related development had culture of large organizations, staff, and overhead. Moving into pricing for individual software components was somewhat tramatic for that development culture ... even a decade or more after unbundling announcement (and a lot of individual products would never had sold if priced to fully cover all costs)
http://www.garlic.com/~lynn/submain.html#unbundle

product price/revenue had to be greater than infrastructure costs. The solution was to marry several products in the same package or organization ... so that aggregate organization product revenue is better than aggregate infrastructure costs.

this was done with jes2 networking married to vm370 networking. for ISPF it was merging the VM370 Performance products into the same group with ISPF. The two products had approx. the same aggregate revenue ... but at the time, the ISPF organization had nearly 100 times more people than supporting VM370 Performance products (and after the merging is kept that way ... simple support with little or no new VM370 performance product development because ISPF needed to siphon off all the funds).

by comparison xedit was done mostly by one person ... although there were some internal politics ... because there was another internal editor (also by one person) that was much more mature and more function ... that could have been selected in lieu of xedit.

some old email
http://www.garlic.com/~lynn/2006u.html#email781103
http://www.garlic.com/~lynn/2006u.html#email790606
http://www.garlic.com/~lynn/2006u.html#email800311
http://www.garlic.com/~lynn/2006u.html#email800312
http://www.garlic.com/~lynn/2006u.html#email800429
in this post
http://www.garlic.com/~lynn/2006u.html#26 Assembler question

and
http://www.garlic.com/~lynn/2006n.html#email810531
in this post
http://www.garlic.com/~lynn/2006n.html#55 The very first text editor

other past posts
http://www.garlic.com/~lynn/2001m.html#22 When did full-screen come to VM/370?
http://www.garlic.com/~lynn/2002p.html#39 20th anniversary of the internet (fwd)
http://www.garlic.com/~lynn/2003d.html#22 Which Editor
http://www.garlic.com/~lynn/2004o.html#36 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2006k.html#51 other cp/cms history
http://www.garlic.com/~lynn/2007g.html#5 Call for XEDIT freaks, submit ISPF requirements
http://www.garlic.com/~lynn/2008h.html#43 handling the SPAM on this group
http://www.garlic.com/~lynn/2009c.html#52 THE runs in DOS box?
http://www.garlic.com/~lynn/2009c.html#54 THE runs in DOS box?

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Call for XEDIT freaks, submit ISPF requirements

Refed: **, - **, - **
From: lynn@GARLIC.COM (Anne & Lynn Wheeler)
Subject: Re: Call for XEDIT freaks, submit ISPF requirements
Newsgroups: bit.listserv.ibm-main
Date: 29 Mar 2010 15:22:01 -0400
lists@AKPHS.COM (Phil Smith III) writes:
P.S. Who you callin' a freak?

re:
http://www.garlic.com/~lynn/2010g.html#6 Call for XEDIT freaks, submit ISPF requirements

note that in the above post ... I reference a previous post in this mailing list from 28mar2007 with the same exact subject line:
http://www.garlic.com/~lynn/2007g.html#5 Call for XEDIT freaks, submit ISPF requirements

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Handling multicore CPUs; what the competition is thinking

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Handling multicore CPUs; what the competition is thinking
Newsgroups: alt.folklore.computers
Date: Mon, 29 Mar 2010 23:25:33 -0400
re:
http://www.garlic.com/~lynn/2010g.html#4 Handling multicore CPUs; what the competition is thinking

related to first in thread:
http://www.garlic.com/~lynn/2010f.html#50 Handling multicore CPUs; what the competition is thinking

misc. old email related to nsfnet
http://www.garlic.com/~lynn/lhwemail.html#nsfnet

so the letter from the director of nsf just aggravated the internal politics (not being allowed to bid or participate on nsfnet backbone T1 rfp) ... then there is this old email
http://www.garlic.com/~lynn/2006w.html#email870109
in this post:
http://www.garlic.com/~lynn/2006w.html#21 SNA/VTAM for NSFNET

one of the people in the communication group had forwarded us some email on the subject ... first in the collection (dated 12/26/86 partially included in the above), was from executive later involved in transfer of cluster scaleup to kingston (and we were told we couldn't work with anything involving more than four processors).

misc. email related to cluster scaleup
http://www.garlic.com/~lynn/lhwemail.html#medusa

cluster scaleup press shortly after effort transferred
http://www.garlic.com/~lynn/2001n.html#6000clusters1
http://www.garlic.com/~lynn/2001n.html#6000clusters2

other recent posts referencing press articles
http://www.garlic.com/~lynn/2010.html#31 Larrabee delayed: anyone know what's happening?
http://www.garlic.com/~lynn/2010c.html#14 Processes' memory
http://www.garlic.com/~lynn/2010f.html#13 What was the historical price of a P/390?
http://www.garlic.com/~lynn/2010f.html#47 Nonlinear systems and nonlocal supercomputing

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Far and near pointers on the 80286 and later

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Far and near pointers on the 80286 and later
Newsgroups: alt.folklore.computers, comp.sys.intel, comp.arch
Date: Tue, 30 Mar 2010 10:13:07 -0400
George Neuner <gneuner2@comcast.net> writes:
Ok, but there are other secure systems to study such as Amoeba and EROS. They are more modern than Multics, and in particular, were designed to be distributed.

I don't mind anyone studying Multic - there is plenty to learn from it (including what not to do) ... but I would be against trying to revive it as a working operating system.


as an aside ... some of the ctss people went to 5th flr, 545 tech sq to do multics and others went to the science center on the 4th flr and did (virtual machine) cp40 (on special modified 360/40 with virtual memory hardware) which morphed into cp67 (when standard virtual memory 360/67 became available) and then morphed into vm370.
http://www.garlic.com/~lynn/subtopic.html#545tech

Old reference to Multics Security Evaluation
http://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation
http://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation
http://www.garlic.com/~lynn/2002l.html#45 Thirty Years Later: Lessons from the Multics Security Evaluation

multics page
http://www.multicians.org/multics.html

old post in multics news group (AFDS was Multics installation)
http://www.garlic.com/~lynn/2001m.html#12 Multics Nostalgia

with respect to cp67 ... there seemed to have been a lot of these guys ... but I didn't become aware of them until much later:
http://web.archive.org/web/20090117083033/http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml

I did assurance panel discussion at 2001 IDF in tcpa track ...
http://web.archive.org/web/20011109072807/http://www.intel94.com/idf/spr2001/sessiondescription.asp?id=stp+s13
with their technical director
http://web.archive.org/web/20011106111653/www.intel94.com/idf/spr2001/speakerdescriptions.asp?id=bsnow

Coyotos is successor to EROS ... EROS was based on tymshare's (370) gnosis capability operating system ... which was spun off as keykos when m/d bought tymshare (I was brought in to do gnosis audit/review as part of the spin-off).
https://en.wikipedia.org/wiki/Coyotos

There were also some number of "object" operating system efforts ... like Apple's Pink and Sun's SPRING/DOE ... some of Apple's Pink technology went to Taligent ... and (possibly) some of SPRING/DOE shows up in java (and java virtual machine)

Recent reference about being asked about coming in to head up commercialization of SPRING/DOE for shipping as product
http://www.garlic.com/~lynn/2010f.html#47 Nonlinear systems and nonlocal supercomputing

misc. past posts mentioning gnosis, keykos, eros, coyotos
http://www.garlic.com/~lynn/2000f.html#69 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000g.html#22 No more innovation? Get serious
http://www.garlic.com/~lynn/2001b.html#73 7090 vs. 7094 etc.
http://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001g.html#35 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001n.html#10 TSS/360
http://www.garlic.com/~lynn/2002f.html#59 Blade architectures
http://www.garlic.com/~lynn/2002g.html#0 Blade architectures
http://www.garlic.com/~lynn/2002g.html#4 markup vs wysiwyg (was: Re: learning how to use a computer)
http://www.garlic.com/~lynn/2002h.html#43 IBM doing anything for 50th Anniv?
http://www.garlic.com/~lynn/2002i.html#63 Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002j.html#75 30th b'day
http://www.garlic.com/~lynn/2003g.html#18 Multiple layers of virtual address translation
http://www.garlic.com/~lynn/2003h.html#41 Segments, capabilities, buffer overrun attacks
http://www.garlic.com/~lynn/2003i.html#15 two pi, four phase, 370 clone
http://www.garlic.com/~lynn/2003j.html#20 A Dark Day
http://www.garlic.com/~lynn/2003k.html#50 Slashdot: O'Reilly On The Importance Of The Mainframe Heritage
http://www.garlic.com/~lynn/2003l.html#19 Secure OS Thoughts
http://www.garlic.com/~lynn/2003l.html#22 Secure OS Thoughts
http://www.garlic.com/~lynn/2003l.html#26 Secure OS Thoughts
http://www.garlic.com/~lynn/2003m.html#24 Intel iAPX 432
http://www.garlic.com/~lynn/2003m.html#54 Thoughts on Utility Computing?
http://www.garlic.com/~lynn/2004c.html#4 OS Partitioning and security
http://www.garlic.com/~lynn/2004e.html#27 NSF interest in Multics security
http://www.garlic.com/~lynn/2004m.html#29 Shipwrecks
http://www.garlic.com/~lynn/2004m.html#49 EAL5
http://www.garlic.com/~lynn/2004n.html#41 Multi-processor timing issue
http://www.garlic.com/~lynn/2004o.html#33 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005.html#7 How do you say "gnus"?
http://www.garlic.com/~lynn/2005b.html#6 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005b.html#7 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005b.html#12 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005c.html#67 intel's Vanderpool and virtualization in general
http://www.garlic.com/~lynn/2005d.html#43 Secure design
http://www.garlic.com/~lynn/2005d.html#50 Secure design
http://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new?
http://www.garlic.com/~lynn/2005k.html#30 Public disclosure of discovered vulnerabilities
http://www.garlic.com/~lynn/2005s.html#12 Flat Query
http://www.garlic.com/~lynn/2006k.html#37 PDP-1
http://www.garlic.com/~lynn/2006m.html#34 PDP-1
http://www.garlic.com/~lynn/2006p.html#13 What part of z/OS is the OS?
http://www.garlic.com/~lynn/2006s.html#7 Very slow booting and running and brain-dead OS's?
http://www.garlic.com/~lynn/2006w.html#42 vmshare
http://www.garlic.com/~lynn/2006y.html#11 Multiple mappings
http://www.garlic.com/~lynn/2006y.html#16 "The Elements of Programming Style"
http://www.garlic.com/~lynn/2007k.html#26 user level TCP implementation
http://www.garlic.com/~lynn/2007o.html#25 LAX IT failure: leaps of faith don't work
http://www.garlic.com/~lynn/2007s.html#17 Oddly good news week: Google announces a Caps library for Javascript
http://www.garlic.com/~lynn/2008b.html#24 folklore indeed
http://www.garlic.com/~lynn/2008b.html#50 How does ATTACH pass address of ECB to child?
http://www.garlic.com/~lynn/2008e.html#12 Kernels
http://www.garlic.com/~lynn/2008g.html#7 was: 1975 movie "Three Days of the Condor" tech stuff
http://www.garlic.com/~lynn/2008g.html#23 Doug Engelbart's "Mother of All Demos"
http://www.garlic.com/~lynn/2008h.html#14 Two views of Microkernels (Re: Kernels
http://www.garlic.com/~lynn/2008s.html#3 New machine code
http://www.garlic.com/~lynn/2009b.html#4 Possibility of malicious CPUs
http://www.garlic.com/~lynn/2009f.html#28 Opinion: The top 10 operating system stinkers
http://www.garlic.com/~lynn/2010d.html#84 Adventure - Or Colossal Cave Adventure

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Gov't coerced Certs thwart SSL/TLS

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Gov't coerced Certs thwart SSL/TLS
Newsgroups: alt.privacy, alt.computer.security
Date: Tue, 30 Mar 2010 10:25:27 -0400
copy of some long-winded posts in another discussion group
http://www.garlic.com/~lynn/2010f.html#71 Law Enforcement Appliance Subverts SSL
http://www.garlic.com/~lynn/2010f.html#80 Law Enforcement Appliance Subverts SSL

Law Enforcement Appliance Subverts SSL
http://www.wired.com/threatlevel/2010/03/packet-forensics/

from above:
... security researcher Chris Soghoian discovered that a small company was marketing internet spying boxes to the feds. The boxes were designed to intercept those communications -- without breaking the encryption -- by using forged security certificates,

... snip ...

financial crypto blog discussion:

Why the browsers must change their old SSL security (?) model
http://financialcryptography.com/mt/archives/001232.html
Pushing the CA into taking responsibility for the MITM
https://financialcryptography.com/mt/archives/001233.html

this is recent computer architecture blog (posting) discussing connection between supercomputing and electronic commerce:
http://www.garlic.com/~lynn/2010f.html#56

i.e. two of the people mentioned in the jan92 cluster scaleup meeting
http://www.garlic.com/~lynn/95.html#13

leave and show up at small client/server startup responsible for something called "commerce server". We are brought in as consultants because they want to do payments transactions on the server; the startup had also invented this technology they called "SSL" that they wanted to use. As part of mapping "SSL" to payment operations (now frequently called "electronic commerce"), required threat & vulnerability studies ... which included lots of assumptions about how SSL had to be deployed and used.

As mentioned in the financial cryptography blog ... majority of exploits over the period since then ... have long been known.

..

one of the references are to the large number of digital certificates for Certification Authorities that have been added to standard browser distributions over the years. In some cases, the original Certification Authorities have gone bankrupt and are no longer in business (browsers have no method for differentiating business practices of the increasing number of different Certification Authorities that have been enabled).

one of the 20yr scenarios is criminal elements coming into some level of influence of any of these Certification Authorities. This is analogous to a number of situations where criminal elements were able to influence ATM cash machine manufacturing ... with skimming compromises installed at the time the machine was being built.

A compromised Certification Authority is able to issue a digital certificate that is acceptable by every browser in the world ... for any business ... even for businesses that have digital certificates issued from totally different Certificate Authority.

This is the old adage that the security trust chain is only as strong as the weakest link ... the criminal elements are likely to go after the weakest link not the strongest link ... (picking some clerk at a Certification Authority ... or a Certification Authority that has some other kind of weakness/vulnerability).

>From failure mode analysis ... having also done some number of high-availability products ... a high availability infrastructure is built so that the probability of infrastructure failure is the probability of all redundant components failing at the same time (the product/multiplication of the failure probabilities of the individual redundant components ... as the number of redundant components go up the probability of system failure decreases).

However, the Certification Authority infrastructure is not a high-availability infrastructure .... its characteristic is the chain analogy ... the system fails if there is any failure in any component (basically adding the failure probability of each individual component) ... as the number of acceptable Certification Authorities increase ... the probability that there is an overall system failure increases (the inverse of high-availability operation where adding redundant components lowers the system failure risk).

There is old post about jan92 meeting in ellisons conference room that draws a thread between high-availability cluster scaleup and current SSL "electronic commerce"
http://www.garlic.com/~lynn/95.html#13

Now, two of the people named in the above meeting, leave and show up at a small client/server startup responsible for something called "commerce server". As mentioned above ... we were then called in to consult because they wanted to do payment transactions on their server; the startup had also invented this technology they called "SSL" they wanted to use.

another weak link in SSL domain name digital certificate infrastructure is the domain name system. When I apply for SSL digital certificate, I provide some information about who I am ... then the Certification Authority validates with the domain name infrastructure that I am also the true owner of the corresponding domain name.

An exploit is domain name hijacking at the domain name system ... and then going to Certification Authority (that does the weakest validation) ... and apply for a valid SSL digital certificate.

Countermeasures to domain name hijacking are using various technologies to improve the integrity of the domain name system. However, there is possibility that some of the technologies can also eliminate the need for SSL domain name certificates. I've pontificated about this catch-22 in the past
http://www.garlic.com/~lynn/subpubkey.html#catch22

another article:

Sneaking Into the Transport Layer With a Fake ID
http://www.ecommercetimes.com/story/69636.html?wlc=1269788312

If crooks can get into compromising POS terminal and ATM cash machines during manufacturing (with built in skimming devices, at one point there was an estimate that as many as 1/3rd of POS terminals being sold in particular market had built in skimming devices at manufacturing) ... what so unthinkable about crooks being able to obtain (valid) SSL digital certificates using forged identification.

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Mainframe Executive article on the death of tape

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@GARLIC.COM (Anne & Lynn Wheeler)
Subject: Re: Mainframe Executive article on the death of tape
Newsgroups: bit.listserv.ibm-main
Date: 30 Mar 2010 07:43:35 -0700
ps2os2@YAHOO.COM (Ed Gould) writes:
Rick: I do not remember the maker (this was probably 30 years ago) we had a Solid state device and we used it for two things. One was PLPA and the other was for a high activity dataset that an application "needed". We fought with the application people for several years to redesign it. We finally convinced them (after a *LOT* of political cr*p) to use VIO. That small change decreased run time from 4+ hours to less than 1 hour.

We also had issue with it when ever there was a power glitch it took a double IPL (delete/define the PLPA). Management finally said the change over to VIO was all that was needed and they kicked the vendor out. When it worked it worked fine when it didn't it crippled the system.


late 70s, early 80s ... internally there was a lot of "1655" from a vendor ... used for paging at large number of internal vm370 sites. they could be configured as 2305 fixed-head disk emulation or as native (if you wrote the support).

the vendor was maker of dram chips ... and the story was that the chips used in 1655 had failed processor memory acceptance tests. the characteristic of block i/o to/from 1655 allowed the i/o controller to compensate for some number of operational characteristics that wouldn't have been acceptable in processor memory.

at that time ... i had also wanted to add separate exposure to the 3350 fixed-head feature (so i could do transfer from fixed head area overlapped with 3350 disk arm motion) ... I got shutdown by POK "JUPITER" effort that was planning on doing something similar to 1655 (JUPITER thot they were going after the paging device market and decided my alternate exposure for 3350 fixed-head feature would impact their sales). JUPITER then found out that the corporation didn't have any spare memory chips for use in emulated i/o device (especially when price as processor memory was much higher than could be gotten for emulated paging device). Eventually JUPITER effort threw in the towel ... but not before shutting me down for ever doing alternate exposure for 3350 fixed-head feature.

Eventually there was Ironwood/Sheriff (3880-11 & 3880-13); 8mbyte disk controller cache ... Ironwood was 4k byte record cache ... and Sheriff was full-track cache.

Some of this changed with 3090 and expanded store ... but until then ... lots of systems were becoming more & more real storage constrained (especially MVS systems) and 370 had trouble supporting more than 16mbyte real storage (except for the hack introduced for 3033 that fiddled two bits in the page table entry to get 26-bit real storage addressing).

some past posts mentioning the 370 >16mbyte hack
http://www.garlic.com/~lynn/93.html#14 S/360 addressing
http://www.garlic.com/~lynn/2001b.html#69 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001i.html#13 GETMAIN R/RU (was: An IEABRC Adventure)
http://www.garlic.com/~lynn/2002c.html#40 using >=4GB of memory on a 32-bit processor
http://www.garlic.com/~lynn/2003d.html#26 Antiquity of Byte-Word addressing?
http://www.garlic.com/~lynn/2003g.html#24 UltraSPARC-IIIi
http://www.garlic.com/~lynn/2004.html#0 comp.arch classic: the 10-bit byte
http://www.garlic.com/~lynn/2004.html#17 Holee shit! 30 years ago!
http://www.garlic.com/~lynn/2004c.html#6 If the x86 ISA could be redone
http://www.garlic.com/~lynn/2004n.html#50 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004o.html#57 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005.html#34 increasing addressable memory via paged memory?
http://www.garlic.com/~lynn/2005p.html#1 Intel engineer discusses their dual-core design
http://www.garlic.com/~lynn/2005p.html#19 address space
http://www.garlic.com/~lynn/2006p.html#0 DASD Response Time (on antique 3390?)
http://www.garlic.com/~lynn/2007o.html#10 IBM 8000 series
http://www.garlic.com/~lynn/2007o.html#56 360/30 memory
http://www.garlic.com/~lynn/2008f.html#12 Fantasy-Land_Hierarchal_NUMA_Memory-Model_on_Vertical
http://www.garlic.com/~lynn/2010.html#84 locate mode, was Happy DEC-10 Day

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Reverse or inverse ARP from windows/linux - no way (!?!?)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Reverse or inverse ARP from windows/linux - no way (!?!?)
Newsgroups: comp.arch.embedded, sci.electronics.design,
 comp.protocols.tcp-ip
Date: Tue, 30 Mar 2010 10:55:48 -0400
"JosephKK"<quiettechblue@yahoo.com> writes:
First off the TCP/IP stack is 4 levels, and the ISO model is 7 layers. Thus there is intrinsic mismatch. Much of the TCP/IP model tools span two or more layers in the ISO model. The real deal for TCP/IP protocol definitions comes from the IETF RFC library.

http://www.ietf.org/rfc.html

Please note that this RFC information is freely available for any use.


note quite true anymore ... the copyright notice use to say that author gives unlimited rights including any derivative works as long as the IETF copyright notice was included. A couple years ago, that was changed ... and now it ways that RFC authors may retain rights (so RFCs published since the change are subject to the new copyright rules).

look at RFCs related to IETF Trust ... for instance 5377

5377 I Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents, Halpern J., 2008/11/10 (8pp) (.txt=17843) (See Also 5378) (Refs 3935, 4071, 4371) (Ref'ed By 5744, 5745)

current documents carry the following
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document

... i got hit with it and had to hire a copyright lawyer out of my own pocket (situation where an attempt was made to try and apply the new rules to RFCs published under the old rules) ... and suggested that they needed to make it much more clear to the authors about copyright changes.

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

An Interview with Watts Humphrey, Part 6: The IBM 360

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: An Interview with Watts Humphrey, Part 6: The IBM 360
Newsgroups: alt.folklore.computers
Date: Tue, 30 Mar 2010 13:34:13 -0400
the following includes some stuff on 360/67 and time-sharing (somebody sent me email, bringing it to my attention).

The IBM 360 Announcement
http://www.informit.com/articles/article.aspx?p=1571987&rll=1

I've posted a couple comments at the above:
TSS/360 vis-a-vis CP67/CMS

While there were early orders of 360/67 for TSS/360, most of the machines ran CP67/CMS done at the science center.

Melinda has done a history that goes into significant more detail:
http://www.leeandmelindavarian.com/Melinda/
http://www.leeandmelindavarian.com/Melinda/

Lincoln Labs, 2250, CP67/CMS

CP67/CMS was installed at Lincoln Labs ... and then in Jan68 at univ (where I was undergraduate) that had original got 360/67 for TSS. Lincoln Labs had CMS fortran library supporting 2250. I took the Lincoln Labs 2250 fortran library and interfaced it to the CMS editor ... to get fullscreen editor on 2250

CP67 Commercial Timesharing Service Bureaus

TSS/360 never got far enough along to even consider some of these issues.

Part of the 7x24 operation in the 60s was that machines were leased and charged for based on cpu meter ... which nominally ran all the time if the system was running. In 7x24 online operation, there might be periods where system was idle (say 3rd shift sunday), so there were tricks to leave the system available for operation but wouldn't run the cpu meter.

Another was weekly or monthly service in datacenter with numerous 360/67s; 7x24 operation required that users didn't see any disruption when different components were taking out of service for maintenance.

There are a lot of similarities with what was learned in these cp67 operations and modern day cloud computing.


... snip ...

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Gov't coerced Certs thwart SSL/TLS

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Gov't coerced Certs thwart SSL/TLS
Newsgroups: alt.privacy, alt.computer.security
Date: Tue, 30 Mar 2010 14:02:28 -0400
"nemo_outis" <abc@xyz.com> writes:
However, here's another reason why self-signed certificates are not just "equivalent to" but actually "superior to" CA-signed certificates:

re:
http://www.garlic.com/~lynn/2010g.html#10 Gov't coerced Certs thwart SSL/TLS

lots of past posts discussing SSL domain name certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcert

note that Certification Authority digital certificate ... is simply a "self-signed" digital certificate that has been loaded into the browser cache of self-signed Certification Authority digital certificates (the primary difference between any random self-signed digital certificate and a Certification Authority self-signed digital certificate ... is whether or not the self-signed digital certificate has been loaded into the browser cache of Certification Authority self-signed digital certificates).

the PKI-based digital certificate infrastructure is a chain of digital certificates that is rooted at the Certification Authority digital certification ... and it is a "root" because if is self-signed and loaded into browser Certification Authority digital certificate cache.

As previously mentioned, the browser Certification Authority self-signed digital certificate caches have accumulated a large number of "root" certificates ... and browsers make no differentiation between the "roots". A compromised root could bring down the whole infrastructure by issuing "valid" certificates for any and all comers (even for entities that already have digital certificates from other roots).

However, the nature of URLs have gotten quite obfuscated for a large percentage of the population ... so an attacker doesn't even necessarily have to even get a SSL digital certificate (for the original domain name) ... they can obtain a similar domain name (using a valid front company) and then obtain a valid SSL digital certificate. Then they send spam email asking people to click-on their URL (which has a valid SSL). They then set up their website to operate as a MITM (potentially using slightly modified standard proxy code) ... where they run two paired sessions ... one between the end-user and their proxy (using their SSL digital certificate) and a 2nd session with the "real" site (using that organization's SSL digital certificate). They are then able to evesdrop/skim all traffic and/or even modify traffic as necessary. This is slightly less privileged level than getting a valid SSL digital certificate for the original domain name (as opposed to just a similar domain name).

Remember ... with the clicking convention and people paying little attention to the actual URL ... SSL primarily operates to validate that the webserver being talked to is the webserver (aka domain name) that it claims to be (not that the webserver that the user thinks they are talking to is the actual webserver that they are actually talking to).

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Far and near pointers on the 80286 and later

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Far and near pointers on the 80286 and later
Newsgroups: alt.folklore.computers, comp.sys.intel, comp.arch
Date: Tue, 30 Mar 2010 14:28:03 -0400
George Neuner <gneuner2@comcast.net> writes:
Pink wasn't designed with security in mind (Apple was still thinking single user) and it never really materialized anyway. Taligent's OS was more focused on being reliable than being secure.

re:
http://www.garlic.com/~lynn/2010g.html#9 Far and near pointers on the 80286 and later

I did a one week JAD with taligent (there were dozen or so top taligent people in the session and their JAD person) going over what would be required for business critical (both reliable and secure).

the net was approx. 30% hit to the taligent base ... two new frameworks plus hits to the existing frameworks.

However, I believe the taligent security guru was on business trip that week ... visiting some gov. agency on the east coast.

misc. past posts referencing the taligent JAD:
http://www.garlic.com/~lynn/2000e.html#46 Where are they now : Taligent and Pink
http://www.garlic.com/~lynn/2001n.html#93 Buffer overflow
http://www.garlic.com/~lynn/2004p.html#64 Systems software versus applications software definitions
http://www.garlic.com/~lynn/2005i.html#42 Development as Configuration
http://www.garlic.com/~lynn/2007m.html#36 Future of System/360 architecture?
http://www.garlic.com/~lynn/2008b.html#22 folklore indeed
http://www.garlic.com/~lynn/2009m.html#26 comp.arch has made itself a sitting duck for spam

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Far and near pointers on the 80286 and later

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Far and near pointers on the 80286 and later
Newsgroups: alt.folklore.computers, comp.sys.intel, comp.arch
Date: Tue, 30 Mar 2010 14:39:18 -0400
re:
http://www.garlic.com/~lynn/2010g.html#9 Far and near pointers on the 80286 and later
http://www.garlic.com/~lynn/2010g.html#15 Far and near pointers on the 80286 and later

part of it was how to cut the development for reliability and security.

we had been called in to consult with small client/server startup that wanted to do payment transactions on their server. they had some well designed and well tested application code that would handle the transactions. I then a bunch of stuff that I claimed was necessary to take a quality application and turn it into a "service" (aka business critical, 7x24) ... which took nearly ten times the original application effort. It included doing some compensating processes and diagnostic manual for Internet environments.

At the same time there were various milspec security development stuff that were also being required for critical financial infrastructures ... stuff like 2167A ... which also took something like ten times the effort of what might be considered well-designed, well-implemented, well-tested application (and then re-applied for any enhancement/changes).

Part of the JAD was could I take both the security & RAS stuff that was increasing standard application development by a factor of ten times ... and get it down to maybe only 2-3 times.

misc. past posts mentioning business critical being 4-10 times standard development for business critical:
http://www.garlic.com/~lynn/2001f.html#75 Test and Set (TS) vs Compare and Swap (CS)
http://www.garlic.com/~lynn/2001n.html#91 Buffer overflow
http://www.garlic.com/~lynn/2001n.html#93 Buffer overflow
http://www.garlic.com/~lynn/2002n.html#11 Wanted: the SOUNDS of classic computing
http://www.garlic.com/~lynn/2003g.html#62 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003j.html#15 A Dark Day
http://www.garlic.com/~lynn/2003p.html#37 The BASIC Variations
http://www.garlic.com/~lynn/2004b.html#8 Mars Rover Not Responding
http://www.garlic.com/~lynn/2004b.html#48 Automating secure transactions
http://www.garlic.com/~lynn/2004k.html#20 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2004l.html#49 "Perfect" or "Provable" security both crypto and non-crypto?
http://www.garlic.com/~lynn/2004p.html#23 Systems software versus applications software definitions
http://www.garlic.com/~lynn/2004p.html#63 Systems software versus applications software definitions
http://www.garlic.com/~lynn/2004p.html#64 Systems software versus applications software definitions
http://www.garlic.com/~lynn/2005b.html#40 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005i.html#42 Development as Configuration
http://www.garlic.com/~lynn/2005n.html#26 Data communications over telegraph circuits
http://www.garlic.com/~lynn/2006n.html#20 The System/360 Model 20 Wasn't As Bad As All That
http://www.garlic.com/~lynn/2007f.html#37 Is computer history taught now?
http://www.garlic.com/~lynn/2007g.html#51 IBM to the PCM market(the sky is falling!!!the sky is falling!!)
http://www.garlic.com/~lynn/2007h.html#78 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007n.html#10 The top 10 dead (or dying) computer skills
http://www.garlic.com/~lynn/2007n.html#76 PSI MIPS
http://www.garlic.com/~lynn/2007n.html#77 PSI MIPS
http://www.garlic.com/~lynn/2007o.html#23 Outsourcing loosing steam?
http://www.garlic.com/~lynn/2007p.html#54 Industry Standard Time To Analyze A Line Of Code
http://www.garlic.com/~lynn/2007v.html#53 folklore indeed
http://www.garlic.com/~lynn/2008e.html#41 IBM announced z10 ..why so fast...any problem on z 9
http://www.garlic.com/~lynn/2008e.html#50 fraying infrastructure
http://www.garlic.com/~lynn/2008e.html#53 Why Is Less Than 99.9% Uptime Acceptable?
http://www.garlic.com/~lynn/2008i.html#33 Mainframe Project management
http://www.garlic.com/~lynn/2008n.html#20 Michigan industry
http://www.garlic.com/~lynn/2008n.html#35 Builders V. Breakers
http://www.garlic.com/~lynn/2008p.html#48 How much knowledge should a software architect have regarding software security?
http://www.garlic.com/~lynn/2009.html#0 Is SUN going to become x86'ed ??

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Far and near pointers on the 80286 and later

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Far and near pointers on the 80286 and later
Newsgroups: alt.folklore.computers, comp.sys.intel, comp.arch
Date: Tue, 30 Mar 2010 14:53:32 -0400
Anne & Lynn Wheeler <lynn@garlic.com> writes:
At the same time there were various milspec security development stuff that were also being required for critical financial infrastructures ... stuff like 2167A ... which also took something like ten times the effort of what might be considered well-designed, well-implemented, well-tested application (and then re-applied for any enhancement/changes).

re:
http://www.garlic.com/~lynn/2010g.html#9 Far and near pointers on the 80286 and later
http://www.garlic.com/~lynn/2010g.html#15 Far and near pointers on the 80286 and later
http://www.garlic.com/~lynn/2010g.html#16 Far and near pointers on the 80286 and later

wasn't a member ... but did get invited to some of their meetings ... somewhat favorite of mine from their website ... courtesy of the wayback machine:
http://web.archive.org/web/20001018151708/http://www.software.org/quagmire/frampapr/frampapr.html

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

The 2010 Census

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The 2010 Census
Newsgroups: alt.folklore.computers
Date: Tue, 30 Mar 2010 15:25:51 -0400
re:
http://www.garlic.com/~lynn/2010f.html#54 The 2010 Census

note quite word-for-word as opening in the above post ... but the last paragraph in this blog entry is close:
http://baselinescenario.com/2010/03/30/elizabeth-warren-aba/

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

The 2010 Census

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The 2010 Census
Newsgroups: alt.folklore.computers
Date: Tue, 30 Mar 2010 15:37:47 -0400
re:
http://www.garlic.com/~lynn/2010f.html#76 The 2010 Census

and a variation on the musical chairs theme in the above ... mentioned in this blog entry:
http://baselinescenario.com/2010/03/30/geely-buys-volvo-goldman-gets-the-upside-you-get-the-downside/

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

16:32 far pointers in OpenWatcom C/C++

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 16:32 far pointers in OpenWatcom C/C++
Newsgroups: alt.sys.pdp10, alt.folklore.computers
Date: Tue, 30 Mar 2010 17:37:24 -0400
Peter Flass <Peter_Flass@Yahoo.com> writes:
I took OP's "swapping" to mean "paging." I don't think there's a lot of swapping these days. In the auld days Burroughs used to swap, I guess TOPS-10 swapped, and TSO originally used to swap. The primary rationale for swapping is in a timesharing environment where there's typically a long delay waiting for user input. OS/2 version 1.x used to swap to move segments around.

apl\360 would "swap" the whole workspace at a time (but they were typically only 16kbytes-32kbytes). apl's storage allocation and garbage collection would repeatedly touch every byte in a workspace.

moving apl\360 to cms for cms\apl ... eliminated all the tasking, swapping, etc code ... since only needed the apl interpreter ... but the storage allocation and garbage collection played havoc when workspace size became significantly larger in (paged) virtual memory (where it would still rapidly try and still touch every available byte in the workspace). this required a major rework to not having continued page thrashing ... touching every possible virtual page.

recent post mentioning cms\apl:
http://www.garlic.com/~lynn/2010e.html#21 paged-access method

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Should the USA Implement EMV?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com (Lynn Wheeler)
Date: 30 Mar, 2010
Subject: Should the USA Implement EMV?
Blog: Payment Systems Network
re:
http://www.garlic.com/~lynn/2010f.html#19 Should the USA Implement EMV?
http://www.garlic.com/~lynn/2010f.html#25 Should the USA Implement EMV?
http://www.garlic.com/~lynn/2010f.html#26 Should the USA Implement EMV?
http://www.garlic.com/~lynn/2010f.html#27 Should the USA Implement EMV?
http://www.garlic.com/~lynn/2010f.html#30 Should the USA Implement EMV?
http://www.garlic.com/~lynn/2010f.html#41 Should the USA Implement EMV?

supposedly multi-factor authentication is assumed to be more secure because the different factors have independent failure/vulernerabilities (aka PIN is countermeasure to lost/stolen card).
http://www.garlic.com/~lynn/subintegrity.html#3factor

However, PIN and magstripe data are both subject to common skimming attack at compromised endpoint. In fact, any static data authentication is vulnerable to skimming attack ... frequently making counterfeit cards trivial exercise ... as in the (chip) yes card (where once the chipcard authentication was skimmed ... the counterfeit yes card would answer that the correct PIN was entered ... regardless of what was entered).
http://www.garlic.com/~lynn/subintegrity.html#yescard

PIN/password something you know authentication has proliferated to the point that humans are starting to have extreme difficulty remembering all the different values ... this is used to explain a study that found 1/3rd of debit cards have the PIN written on them.
http://www.garlic.com/~lynn/subintegrity.html#secrets

Now, there is potential with chip technology to have dynamic authentication data as countermeasure to trivial skimming attacks (used in magstripe and the yes card compromises). In the 90s, this was defined in the X9.59 financial standard (for all retail payments, POS, unattended, internet, debit, credit, stored-value, low-value, high-value, transit turnstile, etc). In the 90s it also required careful design to get secure chip capable of dynamic data in price range comparable to RFID EPC (i.e. targeted for grocery items) price curve (and also able to meet all of the same requirements as X9.59).
http://www.garlic.com/~lynn/x959.html#x959

The chipcard POS pilot in the US a decade ago with the yes card vulnerability created some of the resistance to trying it again anytime soon.

There was also a number of chipcard efforts a decade ago in the internet space ... that have (also) resulted in some resistance to trying it again anytime soon. One of the problems was the previously mentioned enormous consumer support costs related to serial-port device. Another (internet chipcard) initially had gotten agreement from the major merchant websites that accounted for nearly 80% of (internet) financial transactions. However there was then major cognitive dissonance. Merchants have been conditioned that interchange fees go up proportional to fraud (with internet having some of the highest fees). The chipcard would drastically reduce internet fraud and merchants had expected a corresponding reduction in interchange fees. The whole thing collapsed when the merchants were told that the chip-based transactions would have even higher interchange fees than what they were currently paying.

Much of the EU FINREAD standard was countermeasure to the enormous variety of PC exploits ... and basically moved the endpoint out to the FINREAD device. Unfortunately, FINREAD appeared to be part of collateral damage a decade ago (with the implosion related to attempts to deploy serial-port device). There are unique physical fingerprinting technologies for chips ... analogous to other physical media ... it just requires the appropriate design considerations by experienced professionals.
http://www.garlic.com/~lynn/subintegrity.html#finread

There were some articles several years ago about how people should trust poor designs that have experienced a number of exploits ... because of the great experience gained from all the exploits (as opposed to professional designs that didn't have any of the corresponding vulnerabilities).

In the x9a10 financial standard working group scenario from the mid-90s, there was requirement to support ALL retail payments ... many of the current scenarios are still multiple different piece-meal solutions ... which would then still require subsequent convergence.

some past posts mentioning the interchange fee cognitive dissonance
http://www.garlic.com/~lynn/2007u.html#15 Public Computers
http://www.garlic.com/~lynn/2008b.html#75 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008p.html#79 PIN entry on digital signatures + extra token
http://www.garlic.com/~lynn/2008q.html#4 GPG
http://www.garlic.com/~lynn/2008q.html#5 GPG
http://www.garlic.com/~lynn/2009c.html#29 How to defeat new telemarketing tactic
http://www.garlic.com/~lynn/2009c.html#32 How to defeat new telemarketing tactic
http://www.garlic.com/~lynn/2009c.html#51 How to defeat new telemarketing tactic
http://www.garlic.com/~lynn/2009f.html#60 Cobol hits 50 and keeps counting
http://www.garlic.com/~lynn/2009g.html#62 Solving password problems one at a time, Re: The password-reset paradox
http://www.garlic.com/~lynn/2009g.html#64 What happened to X9.59?
http://www.garlic.com/~lynn/2009i.html#51 64 Cores -- IBM is showing a prototype already
http://www.garlic.com/~lynn/2009m.html#49 Hacker charges also an indictment on PCI, expert says
http://www.garlic.com/~lynn/2009m.html#62 August 7, 1944: today is the 65th Anniversary of the Birth of the Computer
http://www.garlic.com/~lynn/2009n.html#1 IT Story New Standard For EU-Compliant Electronic Signatures
http://www.garlic.com/~lynn/2010d.html#17 Chip and PIN is Broken!

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Mainframe Executive article on the death of tape

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@GARLIC.COM (Anne & Lynn Wheeler)
Subject: Re: Mainframe Executive article on the death of tape
Newsgroups: bit.listserv.ibm-main
Date: 31 Mar 2010 05:50:52 -0700
ron.hawkins1960@SBCGLOBAL.NET (Ronald Hawkins) writes:
Lynn,

I don't recall the year, but there was an IBM annual report one year with a picture of a computer room and an STK Solid State Disk Subsystem standing proudly standing against the wall in teh background.

Ron


re:
http://www.garlic.com/~lynn/2010g.html#11 Mainframe Executive article on the death of tape

Recent thread in a.f.c. newsgroup regarding some work I did as undergraduate in the 60s on working set, page replacement algorithms and page I/O implementation (I also cut the pathlength significantly, which then started growing with vm370). In the early 80s that got me in middle of disagreement with somebody doing Stanford Phd on paging (very similar to what I had done on cp67 in 60s) ... which was counter to some of the academic literature from the 60s.
http://www.garlic.com/~lynn/2010f.html#85 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010f.html#89 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010f.html#90 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010f.html#91 16:32 far pointers in OpenWatcom C/C++
2010g.html#016:32 far pointers in OpenWatcom C/C++
2010g.html#2 16:32 far pointers in OpenWatcom C/C++

the above also mentions changing cp67 2301 drum page i/o from single operation at a time getting 80 page i/os per sec (avg. rotational delay for every i/o) to rotationally ordered chained requests (increase to 300 page i/os per sec)

Three email references ... two from 1980 on STC solid state, and one from 1982 on the "IBM 1655" ("drums" is from 2301 which was physically rotating drum/cylinder ... 2305 was physically multiple platter, head/track, fixed-head disk).

Date: 07/10/80 08:13:08
From: wheeler

There are systems running more than 8 drums. 2305 drums I don't think are any longer in production. I would guess that the configuration limit is an attempt to distribute whats available to as many people as possible. One place with 12+ drums has run out of floor space. They will probably go to STC solid state drums, not because they are faster & require less cooling but because they don't have enuf floor space to install all the 2305s they think they need. STL, YKT, etc., most of the large 168 complexes I know about run 8 drums. STL is attempting to get more than 8 drums for the 3033s replacing 168s but they are hard to find. I would have to double check but I think STL has at least one 3033 with 10 or 12 drums.


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

There were two models of 2305 fixed-head disk, 1.5mbyte/sec & about 12mbytes and two-byte interface, 3mbyte/sec, 6mbytes and half the latency. In the 3mbyte/sec, it paired two heads per track, offset 180degrees (but didn't increase the numbers of heads so cut the number of tracks in half with two heads read/written simultaneously).

Date: 08/04/80 09:18:57
To: wheeler

Hi,

The 2305 vs STC 4305 tests so far look like this:

1. The 4305 is definitely faster. Page i/o time 3.7 ms versus 5.8 avg for 2305.

2. Benchmark showed a 10% increase in paging rate and 60% reduction in pagewait.

3. Q length for q1 went from 14.8 to 7.8.

Here is the amazing conclusion so far:

1. The cpu queue grew from 8.7 to 14.2 and the cpu became saturated.

2. The number of paging sios tripled on the 4305 because of the lack of page chaining resulting in an increase of 4-5% cpu. %chain was 84 on drum vs 54 on stc. Also average pages chained on drum was 6 vs 2 on stc.

3. The net effect was that the increase in paging overhead saturated the cpu and the actual problem state time to users was decreased from 30.29 to 28.03. In other words the faster paging device had a negative effect on boeing system (vm) and can be used only where there is a lot of cpu left to handle the additional paging and page sios.

We have yet to test the two-byte interface with stc .. which according to what we have so far will make things even worse (it doubles data xfer rate) and therefore speed of paging. Thre have been a number of h/w problems with stc trying to get the 2-byte interface to work and it still doesnt. I will let you know what the results of that are.

The benchmark used is pretty typical of boeing. The 3033 approachees cpu saturation with a paging rate of 300-400 and in in this case it looks like a faster paging device would only create a cpu bottleneck.

STC may be ahead of its time since we dont have a fast enough cpu. An ap or mp may produce better results, however.


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

The 3mbyte/sec, two-byte interface had lots of problems at installations (whether STC or 2305) because of timing&latency issues. The later 3880/3380 3mbyte/sec was done by introduction of "data streaming" ... relaxing the channel end-to-end handshaking for every byte transferred (allowing multiple byte transfer per end-to-end handshake). Data streaming relaxing the end-to-end handshaking also increased the maximum channel distance from 200ft to 400ft.

Date: 03/03/82 07:52:54
To: wheeler

Re model numbers.. yes lots of fun with those. For example, the Intel Drum we are getting is supposed to be called an IBM 1655, thus putting it in company with the infamous 1651 (internally built converted mag tape typewriter - turned into a 2741 surrogate back when the company needed to get online but had turned off the 2741 production).

THen there was the 1627 plotter (Calcomp), etc.


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

other past posts mentioning (IBM) 1655:
http://www.garlic.com/~lynn/2001c.html#17 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001l.html#53 mainframe question
http://www.garlic.com/~lynn/2002.html#31 index searching
http://www.garlic.com/~lynn/2002i.html#17 AS/400 and MVS - clarification please
http://www.garlic.com/~lynn/2002l.html#40 Do any architectures use instruction count instead of timer
http://www.garlic.com/~lynn/2003b.html#15 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#17 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003c.html#55 HASP assembly: What the heck is an MVT ABEND 422?
http://www.garlic.com/~lynn/2003m.html#39 S/360 undocumented instructions?
http://www.garlic.com/~lynn/2004d.html#73 DASD Architecture of the future
http://www.garlic.com/~lynn/2004e.html#3 Expanded Storage
http://www.garlic.com/~lynn/2005e.html#5 He Who Thought He Knew Something About DASD
http://www.garlic.com/~lynn/2005r.html#51 winscape?
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
http://www.garlic.com/~lynn/2006c.html#1 Multiple address spaces
http://www.garlic.com/~lynn/2006e.html#46 using 3390 mod-9s
http://www.garlic.com/~lynn/2006k.html#57 virtual memory
http://www.garlic.com/~lynn/2006r.html#36 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/2007e.html#59 FBA rant
http://www.garlic.com/~lynn/2007o.html#26 Tom's Hdw review of SSDs
http://www.garlic.com/~lynn/2007s.html#9 Poster of computer hardware events?
http://www.garlic.com/~lynn/2007u.html#4 Remembering the CDC 6600
http://www.garlic.com/~lynn/2008b.html#15 Flash memory arrays
http://www.garlic.com/~lynn/2009m.html#54 August 7, 1944: today is the 65th Anniversary of the Birth of the Computer

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

16:32 far pointers in OpenWatcom C/C++

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 16:32 far pointers in OpenWatcom C/C++
Newsgroups: alt.sys.pdp10, alt.folklore.computers
Date: Wed, 31 Mar 2010 09:50:26 -0400
Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
I've seen "swapping" used more-or-less as you describe (more directly, used to mean making a decision to move a process's entire address space out to disk), but "paging" in and of itself isn't an addressing scheme -- the addressing scheme is just a flat address space; the paging is either the mechanism letting you have part of the space in memory and part not or (as it's being used here) the moving of pages between disk and memory.

note that swapping has tending to switching tasks that are eligible to compete for real storage ... aka transition from one task ("working set") to another task ("working set"). size of "working set" is roughly the number of real pages needed to run efficiently. limiting the tasks to sum of working set sizes less than real storage was countermeasure to page thrashing.

in non-paged environment ... whole workspaces were moved/swapped as single unit (as in apl\360). in paged environment ... it was sometimes also applied to block move of all pages in real memory ... as part of transition from one task to another.

sometimes it was purely swap-out ... collected all virtual pages for a task to be written out ... and then new task would demand page in their working set. sometimes the working set pages from prior swap-out would be remembered ... and swapped in as part of the transition (read requests for all pages from previous swap-out).

in the early 80s, ibm mainframe introduced something part-way inbetween ... which was "big pages". Normal paging was 4k bytes. "big pages" were collections of ten 4k pages read/written as single (3380 fulltrack) I/O operation. At "swap-out" ... resident virtual pages for a task would be grouped into collections of ten 4k pages ... which would be written as a single full-track 3380 disk i/o. At later time, when the task was again made eligible for execution, if a 4k page fault belonged to a "big page" out on disk ... all ten 4k pages would be read as single i/o.

Basically, disk arm access had become major system thruput bottleneck and effectively systems had some amount of excess real storage and excess disk transfer capacity. The trade-off was to transfer significantly more pages per disk arm access (reducing avg. delay) ... potentially "wasting" some amount of real storage and disk transfer capacity (if task didn't actually require all ten of 4k pages read).

misc. past posts mentioning "big pages":
http://www.garlic.com/~lynn/2001k.html#60 Defrag in linux? - Newbie question
http://www.garlic.com/~lynn/2002b.html#20 index searching
http://www.garlic.com/~lynn/2002c.html#29 Page size (was: VAX, M68K complex instructions)
http://www.garlic.com/~lynn/2002c.html#48 Swapper was Re: History of Login Names
http://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?
http://www.garlic.com/~lynn/2002e.html#11 What are some impressive page rates?
http://www.garlic.com/~lynn/2002f.html#20 Blade architectures
http://www.garlic.com/~lynn/2002l.html#36 Do any architectures use instruction count instead of timer
http://www.garlic.com/~lynn/2002m.html#4 Handling variable page sizes?
http://www.garlic.com/~lynn/2003b.html#69 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003d.html#21 PDP10 and RISC
http://www.garlic.com/~lynn/2003f.html#5 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#9 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#48 Alpha performance, why?
http://www.garlic.com/~lynn/2003g.html#12 Page Table - per OS/Process
http://www.garlic.com/~lynn/2003o.html#61 1teraflops cell processor possible?
http://www.garlic.com/~lynn/2003o.html#62 1teraflops cell processor possible?
http://www.garlic.com/~lynn/2004.html#13 Holee shit! 30 years ago!
http://www.garlic.com/~lynn/2004e.html#16 Paging query - progress
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#15 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005j.html#51 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2005l.html#41 25% Pageds utilization on 3390-09?
http://www.garlic.com/~lynn/2005n.html#18 Code density and performance?
http://www.garlic.com/~lynn/2005n.html#19 Code density and performance?
http://www.garlic.com/~lynn/2005n.html#21 Code density and performance?
http://www.garlic.com/~lynn/2005n.html#22 Code density and performance?
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/2006l.html#13 virtual memory
http://www.garlic.com/~lynn/2006r.html#35 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006r.html#37 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006r.html#39 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006t.html#18 Why magnetic drums was/are worse than disks ?
http://www.garlic.com/~lynn/2006v.html#43 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006y.html#9 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2008f.html#6 Fantasy-Land_Hierarchal_NUMA_Memory-Model_on_Vertical
http://www.garlic.com/~lynn/2008k.html#80 How to calculate effective page fault service time?

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Mainframe Executive article on the death of tape

Refed: **, - **, - **, - **, - **
From: lynn@GARLIC.COM (Anne & Lynn Wheeler)
Subject: Re: Mainframe Executive article on the death of tape
Newsgroups: bit.listserv.ibm-main
Date: 31 Mar 2010 07:59:13 -0700
re:
http://www.garlic.com/~lynn/2010g.html#11 Mainframe Executive article on the death of tape
http://www.garlic.com/~lynn/2010g.html#22 Mainframe Executive article on the death of tape

i don't remember for sure ... but i don't think that boeing ever got stc 3mbyte/sec 2byte interface working on 3033s. recent channel discussions
http://www.garlic.com/~lynn/2010e.html#27 SHAREWARE at Its Finest
http://www.garlic.com/~lynn/2010e.html#30 SHAREWARE at Its Finest
http://www.garlic.com/~lynn/2010e.html#36 What was old is new again (water chilled)
including this old email in above post:
http://www.garlic.com/~lynn/2010e.html#email810617

303x channel directors were really 370/158s with only the integrated channel microcode and w/o the 370 microcode. i have recollection of 370/158 shooting hardware problems with 2305 1.5mbyte/sec where channel cable lengths starting getting much over 20-30 ft. 3mbyte/sec 2305s were pretty much 370/168 attachments (because of the faster channels).

re:
http://www.garlic.com/~lynn/2010g.html#email800710

so the "floor space" issue in the referenced email ... wasn't necessarily total datacenter floor space ... but floor space within the more limited channel cable length for 2305 1.5mbyte transfers.

re:
http://www.garlic.com/~lynn/2010g.html#email800804

the other reference to higher paging rates and compute intensive ... trivial interactive workloads have always tended to be dominated by paging latency (and cpu overhead to do page transfers). If an environment that was running 100% cpu utilization ... doing faster paging would tend to reduce interactive response, increase total interactive thruput, increase paging rate, and increase paging related cpu use (it isn't strictly doing less work ... it is shifting some of the work from the more compute intensive workload to the more interactive intensive workload).

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Intel Nehalem-EX Aims for the Mainframe

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@GARLIC.COM (Anne & Lynn Wheeler)
Subject: Intel Nehalem-EX Aims for the Mainframe
Newsgroups: bit.listserv.ibm-main
Date: 31 Mar 2010 08:12:44 -0700
Intel Nehalem-EX Aims for the Mainframe
http://www.internetnews.com/hardware/article.php/3873896/Intel+NehalemEX+Aims+for+the+Mainframe.htm

from above:
Intel, the world's largest chipmaker, is gunning for the mission-critical server space with the launch of the new Xeon 6500/7500 processor lines. It's a bid that will see it taking on mainframes and RISC, but the company says that its newest offerings have the goods.

... snip ...

semi-related to earlier posts about Gulftown & 370 mips on intel platform
http://www.garlic.com/~lynn/2010e.html#71 Entry point for a Mainframe?
http://www.garlic.com/~lynn/2010e.html#72 Entry point for a Mainframe?
http://www.garlic.com/~lynn/2010f.html#16 What was the historical price of a P/390?
http://www.garlic.com/~lynn/2010f.html#32 history of RPG and other languages, was search engine history
http://www.garlic.com/~lynn/2010f.html#78 Notes on two presentations by Gordon Bell ca. 1998

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Tapes versus vinyl

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Tapes versus vinyl
Newsgroups: alt.folklore.computers
Date: Wed, 31 Mar 2010 13:46:29 -0400
Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> writes:
So, too, is a CD-ROM. That doesn't explain why there weren't computers with this superior, random-access, gramophone storage in the decades when the record player was the primary means of playing music when with the advent of the Compact Disc came hundreds of thousands of machines with CD-ROM storage. Being read-only didn't limit the uses that people found for CD-ROM storage, so why didn't people find those same uses for this random-access gramophone storage decades before?

cdrom was basically digital optical storage that happened to get mass production out of the music industry ... and the corresponding significant commodity price benefit (volumes justify upfront costs for vlsi chip for stuff that was still mostly descrete components for strictly computer).

we were dealing with company that did reed-solomon error correcting for advanced communication operation ... and they had also happened to have done much of the original error correcting work for the cdrom standard.

at one point I happened to observe that the electronics and optical components in a $300 cdrom player were far more advanced than some strictly computer stuff that was priced at $6k-$20k. misc. past posts on the subject:
http://www.garlic.com/~lynn/2001j.html#23 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001n.html#77 a.f.c history checkup... (was What specifications will the standard year 2001 PC have?)
http://www.garlic.com/~lynn/2004o.html#43 360 longevity, was RISCs too close to hardware?
http://www.garlic.com/~lynn/2004o.html#44 360 longevity, was RISCs too close to hardware?
http://www.garlic.com/~lynn/2005n.html#27 Data communications over telegraph circuits
http://www.garlic.com/~lynn/2006.html#45 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006q.html#62 Cray-1 Anniversary Event - September 21st
http://www.garlic.com/~lynn/2007d.html#50 Is computer history taugh now?
http://www.garlic.com/~lynn/2007q.html#50 US or China?
http://www.garlic.com/~lynn/2009p.html#59 MasPar compiler and simulator
http://www.garlic.com/~lynn/2009q.html#0 Anyone going to Supercomputers '09 in Portland?

then there was the photostore (also digital optical)
https://en.wikipedia.org/wiki/IBM_1360

then there was 3850 mss ... the cylinders actually having strips of magtape wrap around them (and the "jukebox" much larger than the cdrom jukeboxes of the period)
http://www.columbia.edu/cu/computinghistory/mss.html
https://en.wikipedia.org/wiki/IBM_3850
http://www-03.ibm.com/ibm/history/exhibits/storage/storage_3850.html

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Intel Nehalem-EX Aims for the Mainframe

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@GARLIC.COM (Anne & Lynn Wheeler)
Subject: Re: Intel Nehalem-EX Aims for the Mainframe
Newsgroups: bit.listserv.ibm-main
Date: 31 Mar 2010 11:14:50 -0700
re:
http://www.garlic.com/~lynn/2010g.html#24 Intel Nehalem-EX Aims for the Mainframe

aside from possibility of running some sort of mainframe emulator

Intel's Xeon 7500 Series Could Be a Server Game-Changer
http://news.yahoo.com/s/nf/20100331/bs_nf/72503

from above:
make it possible for IT managers to consolidate up to 20 older single-core, four-chip servers onto a single server while maintaining the same level of performance. That, Intel said, could mean up to a 92 percent reduction in energy costs and a one-year ROI due to reductions in power, cooling and licensing costs.

... snip ...

the above article uses the phrase "democratizing high-end computing" ... when it possibly actually means (further) commoditizing

it doesn't mention virtualization-based server consolidation of possibly another 10:1 (for 200:1?).

AMD is also touting 12-core chip ... as licensing cost savings ... aka licensing costs based on number of physical chips ... as opposed to aggregate number of processor cores.

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Intel Nehalem-EX Aims for the Mainframe

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@GARLIC.COM (Anne & Lynn Wheeler)
Subject: Re: Intel Nehalem-EX Aims for the Mainframe
Newsgroups: bit.listserv.ibm-main
Date: 31 Mar 2010 11:38:50 -0700
Howard Brazee <howard.brazee@cusys.edu> writes:
For various values of "pull it off", other manufacturers *have* succeeded. There are companies running their old "mission critical" mainframe applications on Suns. Capabilities go up for IBM and for its competing hardware, and "good enough" varies considerably for different customers.

re:
http://www.garlic.com/~lynn/2010g.html#24 Intel Nehalem-EX Aims for the Mainframe
http://www.garlic.com/~lynn/2010g.html#27 Intel Nehalem-EX Aims for the Mainframe

jim's '84 fault tolerant study pointed out that hardware was becoming increasingly smaller & smaller percentage of the failures
http://www.garlic.com/~lynn/grayft84.pdf

similar thread with various references:
http://www.garlic.com/~lynn/2009p.html#0 big iron mainframe vs. x86 servers

which has citation for another paper Jim did on failures

Why Do Computers Stop and What Can Be Done About It?
http://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf

from above:
An analysis of the failure statistics of a commercially available fault-tolerant system shows that administration and software are the major contributors to failure.

... snip ...

fall-over & hot-standby have been used to mask hardware and software failures .... as well as other kinds of planned & unplanned outages (like for maintenance) ... which are largely software-based RAS

in this recent post
http://www.garlic.com/~lynn/2010f.html#2 Entry point for a Mainframe?

I mentioned that IMS hot-standby was looking at the alternative solution to compensate for VTAM restart on the hot-standby machine taking periods measured in hrs (for large configuration).

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

someone smarter than Dave Cutler

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: someone smarter than Dave Cutler
Newsgroups: alt.folklore.computers, alt.sys.pdp10
Date: Thu, 01 Apr 2010 09:51:25 -0400
Pat Farrell <pfarrell@pfarrell.com> writes:
I'll grant that IBM's SNA started in 1974, but the Arpanet was started in the late 60s. And I don't believe that SNA was in widespread usage until much later, towards the late 70s and early 80s. There were popular IBM mainframe to far away location protocols, but SNA was a later beast.

Perhaps you are missing some specifics and punctuation, but SNA and X.25 had nearly nothing in common.

X.25 was vaguely related to the "telnet" function of early arpanet, in that it was mostly about sending low speed characters as if entered by a human at a keyboard.

SNA was more properly aligned with DECnet phase 3 or 4, or modern TCP/IP stacks, or even the OSI/ISO model


SNA was whatever VTAM happened to implement. There were jokes about other corporate platforms trying to implement something based on SNA documentation ... and being impossible to get it to interoperate with VTAM (the only standard for SNA was whatever VTAM did).

in the time-frame that SNA originated ... my wife had co-authored peer-to-peer networking, AWP39 (... there was internal corporate convention for numbering architecture white papers, for instance the much later APPN was AWP164). The SNA organization possibly viewed this as competition ... even tho SNA was VTAM managing large number of dumb terminals (and really convoluted for doing anything else).

For a time, the author of APPN and I reported to the same corporate executive ... and I would needle him about not wasting his time trying to aid the SNA organization, because they would never appreciate it (and should instead work on tcp/ip). In fact, when APPN went to product announcement, the SNA organization non-concurred (objected). There was 6-8 week delay while the APPN announcement letter was careful rewritten to not imply any kind of relationship between APPN and SNA.

my wife had periodic battles with the SNA organization ... when she was con'ed into going to POK to be in charge of (mainframe cluster) loosely-coupled architecture ... the SNA organization was constantly demanding that VTAM be used for processor communciation for cluster coordination. There would be temporary truces where the SNA organization would allow that she could use whatever she wanted within the walls of the datacenter ... but SNA still have to be used anytime there was transmission that crossed the walls of the datacenter.

Much later, when she was chief architect for AMADEUS for a short period (european airline system ... somewhat based on the eartern airline system/one) ... she sided with the europeans on using x.25 ... and the SNA forces had her replaced. It didn't do any good, AMADEUS went with x.25 anyway.

I had this proposal to turn out a corporate product ... recent reference
http://www.garlic.com/~lynn/2010f.html#2 Entry point for a Mainframe

One of the baby bells had implemented SNA emulation (pu4/pu5, ncp/vtam) on series/1 ... that used "real" networking and just spoofed SNA at the SNA boundary interfaces. The net was that they could do a whole lot of things that were effectively impossible within real VTAM/NCP context. I was going to get the work done to have it announced as corporate product and then port it to RIOS (used in rs/6000).

One of the issues was that SNA didn't have network layer (osi) or an internetworking layer (tcp/ip) ... applications interface to mainframe VTAM directly used each dumb terminal address (with no intervening layer). LU6.2 interface is somewhat analogous to TCP (and transport layer). At one point, a subcontractor was hired to implement TCP/IP support in VTAM. The folklore was that when the initial implementation was submitted ... TCP/IP thruput was much higher than LU6.2. They were then told that everybody knew that a "correct" tcp/ip ran much slower than lu6.2 ... and that they would only accept a "correct" tcp/ip implementation.

One of the things that the SNA organization did contribute was uptake of IBM/PCs in the 80s with (dumb terminal) 3270 emulation. However, a big customer install base then grew up during the 80s that the SNA organization had to protect. As PCs got more sophisticated and started to move past the dumb terminal paradigm ... the SNA org continued to strongly protect its dumb terminal products & install base. This got so extreme that towards the late 80s, a senior engineer with the disk division got a talk scheduled at the internal annual world-wide SNA conference. They opened their talk with the line that the communication group was going to be responsible for the demise of the disk division. The details was that the dumb terminal emulation paradigm was representing a severe restriction on PCs being able to utilize data on the mainframe (communication group blocked some number of products that the disk division attempted to bring out to significantly improve the situation ... because it would impact their dumb terminal emulation products). As a result, there was a significant flight of data out of the datacenters to other platforms that were much more friendly to distributed use. Lots of past posts on the subject
http://www.garlic.com/~lynn/subnetwork.html#emulation

In this period, we had come up with 3-tier architecture (it was originally formulated as part of response to a large gov. agency RFI) and were out pitching to customer executives ... and taking lots of hits from the communication group. some past posts
http://www.garlic.com/~lynn/subnetwork.html#3tier

one of the programs attempting to shore up dumb terminal paradigm was SAA ... recent post mentioning that the person given responsibility for SAA had a top floor corner office in Somers and we would go by periodically and hassle them regarding the hits we were taking from the organization.
http://www.garlic.com/~lynn/2010f.html#57 Handling multicore CPUs; what the competition is thinking

note that the internal network was originally developed at the science center with cp67 ... and was not SNA. It was larger than the arpanet/internet from just about the beginning until possibly sometime late '85 or early '86.
http://www.garlic.com/~lynn/subnetwork.html#internalnet

for some truely trivia ... reference to doing some work on cluster scaleup (meeting in ellison's conference room jan92)
http://www.garlic.com/~lynn/95.html#13

two of the people named in that meeting, later left and show up at a small client/server startup responsible for something called "commerce server". We had also left our positions ... and we brought in as consultants because they wanted to do payment transactions on the server (it is now frequently called "electronic commerce"). recent comp.arch post about connection between supercomputing and electronic commerce
http://www.garlic.com/~lynn/2010f.html#56 Handling multicore CPUs; what the competition is thinking

so part of that effort was deployment of a payment gateway ... that handled SSL from the internet carrying payment transactions and merchant acquiring processor. So initial implementation used a merchant acquiring protocol that was widely implemented on PCs deployed in the T&E (travel & entertainment) industry ... with typical large T&E (example casinos in las vegas) operation having concentrator with dedicated leased x.25 line into the acquiring processor datacenter. The mechanics of "electronic commerce" had webservers forming the merchant acquiring protocol and sending the transactions to the payment gateway (which was basically emulating the concentrator functions ... the payment gateways were replicated with multiple real x.25 leased lines into merchant acquirer datacenter).
http://www.garlic.com/~lynn/subnetwork.html#gateway

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Mainframe Executive article on the death of tape

Refed: **, - **, - **
From: lynn@GARLIC.COM (Anne & Lynn Wheeler)
Subject: Re: Mainframe Executive article on the death of tape
Newsgroups: bit.listserv.ibm-main
Date: 1 Apr 2010 07:05:26 -0700
shmuel+ibm-main@PATRIOT.NET (Shmuel Metz , Seymour J.) writes:
The 2305-1 and 2305-2 were disks; the drums were 2301 and 2303. Unlike the drums, the fixed-head disks had[1] 8 exposures and RPS.

[1] AFAIK the 2305 was the first device to have multiple exposures, RPS or 2-byte channel connections.


re:
http://www.garlic.com/~lynn/2010g.html#22 Mainframe Executive article on the death of tape

that was why i prefixed the lead into the email
http://www.garlic.com/~lynn/2010g.html#email800710

with explanation that 2305 were physically fixed-head disks. however, it had become regular practice to refer to paging drums from the 2301 history ... and it carried over to referring to 2305 as paging drums

I then repeated part of the explanation with the leadin to the immediate following email
http://www.garlic.com/~lynn/2010g.html#email800804

as mentioned in earlier post in thread, I had tried to add multiple exposures for fixed-head 3350 feature ... but got shutdown by JUPITER effort in POK (which thot that they might be doing an electronic paging disk/drum)
http://www.garlic.com/~lynn/2010g.html#11 Mainframe Executive article on the death of tape

other posts in thread:
http://www.garlic.com/~lynn/2010f.html#65 Mainframe Executive article on the death of tape
http://www.garlic.com/~lynn/2010g.html#24 Mainframe Executive article on the death of tape

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Mainframe Executive article on the death of tape

Refed: **, - **, - **, - **, - **, - **
From: lynn@GARLIC.COM (Anne & Lynn Wheeler)
Subject: Re: Mainframe Executive article on the death of tape
Newsgroups: bit.listserv.ibm-main
Date: 1 Apr 2010 07:32:48 -0700
shmuel+ibm-main@PATRIOT.NET (Shmuel Metz , Seymour J.) writes:
The 2305-1 and 2305-2 were disks; the drums were 2301 and 2303. Unlike the drums, the fixed-head disks had[1] 8 exposures and RPS.

[1] AFAIK the 2305 was the first device to have multiple exposures, RPS or 2-byte channel connections.


re:
http://www.garlic.com/~lynn/2010f.html#65 Mainframe Executive article on the death of tape
http://www.garlic.com/~lynn/2010g.html#11 Mainframe Executive article on the death of tape
http://www.garlic.com/~lynn/2010g.html#22 Mainframe Executive article on the death of tape
http://www.garlic.com/~lynn/2010g.html#24 Mainframe Executive article on the death of tape
http://www.garlic.com/~lynn/2010g.html#30 Mainframe Executive article on the death of tape

I've mentioned before that the science center had joint project with endicott to support 370 virtual memory architecture ... in cp67 virtual machines. this involved modifying cp67 to add support for "virtual 370" ... as alternative to "virtual 360/67" (aka the format of the tables were different and the control registers were different and some of the instructions were different).

Partly because the cambridge cp67 had non-employees (students and others from educational institutions in the cambridge area, aka BU, MIT, Harvard, etc) ... the work went on with a version of cp67 that ran in a 360/67 virtual machine. basically:

cp67 "L" ... running on real 360/67 cp67 "H" ... running in virtual 360/67 CP67 "I" ... running in virtual 370

The cp67i system was up and running regularly a year before there was real 370 engineering machine with virtual memory hardware. In fact, the cp67i system was used to test the first engineering 370 with virtual memory hardware (370/145 in endicott).

then two engineers from san jose came out and added 3330 & 2305 device support to cp67i ... which was referred to as cp67sj. Then for a long time, there were large number of 370/145s running with the cp67sj system (both before and after 370 virtual memory was announced ... and even after vm370 rewrite was available).

as referred to in comments about boeing 3033 and stc electronic paging ... i don't believe they ever got the 2-byte interface working.
http://www.garlic.com/~lynn/2010g.html#email800804

370/158 would periodically have issues with just single-byte (1.5mbyte/sec) 2305s ... because of timing, latency and cable length issues ... and 303x channel director was 370/158 engine with just the integrated channel microcode (and w/o the 370 microcode).

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Intel Nehalem-EX Aims for the Mainframe

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel Nehalem-EX Aims for the Mainframe
Newsgroups: bit.listserv.ibm-main
Date: Thu, 01 Apr 2010 10:50:34 -0400
re:
http://www.garlic.com/~lynn/2010g.html#25 Intel Nehalem-EX Aims for the Mainframe
http://www.garlic.com/~lynn/2010g.html#27 Intel Nehalem-EX Aims for the Mainframe
http://www.garlic.com/~lynn/2010g.html#28 Intel Nehalem-EX Aims for the Mainframe

Intel launches Xeon 7500 server processor lineup; Promises three times increase in processing speed and 20 new reliability features
http://www.cbronline.com/news/intel_launches_xeon_7500_server_processor_lineup_100331

from above:
The new processor possess Machine Check Architecture (MCA) Recovery feature currently used in Itanium and RISC processors that allows the silicon to work with the operating system and virtual machine manager to recover from otherwise fatal system errors.

... snip ...

note that in the 80s ... one of the reasons for various ports of UNIX (or unix-like) operating systems to mainframe continued to be run under vm370 ... was that that adding mainframe RAS was several times larger effort than the straight-forward port (instead relying on vm370 to provide the RAS, both processor and device).

possibly some amount of that has since migrated to service processor ... possibly allowing such ports to be more comfortable executing in an LPAR (rather than requiring execution under z/VM).

old posts about getting to play disk engineer in bldgs. 14&15 ... and doing a bullet proof I/O supervisor for them that would never fail (i.e. they had tried MVS and found MVS had 15min MTBF in their environment, once having referenced that in an internal document then brought down the wrath of MVS organization on my head)
http://www.garlic.com/~lynn/subtopic.html#disk

prior to the fail-proof I/O supervisor they had scheduled dedicated mainframe testing time ... typically around the clock ... a major development bottleneck. after the fail-proof I/O supervisor ... they could do any number of on-demand concurrent testing ... significantly improving productivity.

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

SQL Server replacement

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: SQL Server replacement
Newsgroups: bit.listserv.ibm-main, alt.folklore.computers
Date: Thu, 01 Apr 2010 11:46:03 -0400
mward@SSFCU.ORG (Ward, Mike S) writes:
I have heard of IFL's for zLinux and DB/2 running under zLinux. We have DB/2 running on z/OS and also DB/2 connect on the distributed side and it is used to access DB/2 on the mainframe.

then there is:
http://www.garlic.com/~lynn/2009p.html#43 From The Annals of Release No Software Before Its Time
http://www.garlic.com/~lynn/2009p.html#46 From The Annals of Release No Software Before Its Time

DB2 announces technology that trumps Oracle RAC and Exadata
http://freedb2.com/2009/10/10/for-databases-size-does-matter/

trivia ... SQL server was originally licensed from Sybase
https://en.wikipedia.org/wiki/Sybase

Founded by Epstein ... mentioned here:
https://en.wikipedia.org/wiki/Michael_Stonebraker

The original relational/sql was system/r ... some number of past posts
http://www.garlic.com/~lynn/submain.html#systemr

Bob had been CTO at Britton-Lee and after he left ... there were various meetings across the street from bldg 28 ... recruiting his replacement.

After we left in the early 90s ... and during the mainframe troubles of the period ... there was corporate effort to try and get a lot of applications & DBMS made available on mainframes. In some number of these discussions between people from corporate hdqtrs and others (including Bob) ... we were ask to sit in ... as translators (being able to speak both mainframe and non-mainframe).

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

someone smarter than Dave Cutler

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: someone smarter than Dave Cutler
Newsgroups: alt.folklore.computers, alt.sys.pdp10
Date: Thu, 01 Apr 2010 14:52:26 -0400
Pat Farrell <pfarrell@pfarrell.com> writes:
Agreed, but again, that was in the 80s. SNA was not really much of an impact in the 70s.

re:
http://www.garlic.com/~lynn/2010g.html#29 someone smarter than Dave Cutler

they had TCAM (TeleCommunication Access Method) on the mainframe and 2701/2702/2703 controllers and then 3705 with EP (emulation program) as front end ... but were moving fast to replace it with "SNA", VTAM (virtual telecommunication access method) on the mainframe and NCP running on the 3705 (in SNA architecture, VTAM was PU5 and NCP was PU4).

a large part of "SNA" and barouqe nature of pu4/pu5 interface has been claimed to meet the original FS requirements (aka tight integration as countermeasure to clone controllers), after FS effort was killed ... misc. past FS posts
http://www.garlic.com/~lynn/submain.html#futuresys

when I was undergraduate at the univ and adding TTY/ascii terminal support to cp67 ... I tried to make the 2702 controller do something it couldn't quite do. That was somewhat the univ. motivation to do a clone controller project using Interdata/3. Later four of us got written up blamed for clone controller business. some past posts
http://www.garlic.com/~lynn/subtopic.html#360pcm

Interdata ... and later Perkin/Elmer (after PE bought Interdata) marketed it as clone controller. I ran into one about a decade ago in large (credit card) merchant acquiring datacenter ... handling incoming calls from (significant percentage of US) POS (point-of-sale) terminal dialup calls (if you are at merchant checkout counter and still hear that modem whistle negotiating protocol to establish connection).

wiki SNA reference
https://en.wikipedia.org/wiki/IBM_Systems_Network_Architecture
wiki 3705 reference
https://en.wikipedia.org/wiki/IBM_3705_Communications_Controller

one of the issues with SNA & 3705 was that they really used an underpowered processor for the 3705. At one time there was an effort to get them to use the peachtree processor instead (used in the Series/1).

there started to be more & more uptake of (SNA) VTAM and 3705NCP after customers started deploying VS2 (aka mainframe batch systems upgraded for virtual memory; initially VS2/SVS and then later VS2/MVS) in the later half of the 70s ... along with move from (real memory oriented) TCAM to (somewhat more virtual memory oriented) VTAM (as well as vtam/3705ncp integration representing countermeasure to cloen controllers)

At the next lower level ... SNA also introduced SDLC line/device protocol as opposed to the earlier bisync ... some number of bisync lines/devices continued to be used long after rest of infrastructure was moving to sna/vtam/3705ncp.

For a little DEC trivia ... the science center had developed cp67 for the 360/67 (as alternative to the "official" tss/360) ... mentioned here:
http://www.garlic.com/~lynn/2010g.html#13 An Interview with Watts Humphrey, Part 6: The IBM 360

there were others also developed to use 360/67 virtual memory hardware, like orvyl at stanford
http://infolab.stanford.edu/pub/voy/museum/pictures/IBM.html

and mts at univ. of michigan. a few past posts mentioning that MTS had done something similar with PDP8 as a clone telecommunication controller (as I had worked on with interdata):
http://www.garlic.com/~lynn/2006c.html#18 Change in computers as a hobbiest
http://www.garlic.com/~lynn/2006k.html#41 PDP-1
http://www.garlic.com/~lynn/2006k.html#42 Arpa address
http://www.garlic.com/~lynn/2006m.html#42 Why Didn't The Cent Sign or the Exclamation Mark Print?
http://www.garlic.com/~lynn/2007j.html#6 MTS *FS tape format?
http://www.garlic.com/~lynn/2007u.html#85 IBM Floating-point myths
http://www.garlic.com/~lynn/2009k.html#70 An inComplete History Of Mainframe Computing

mentioning references here:
http://www.eecis.udel.edu/~mills/gallery/gallery7.html
http://www.eecis.udel.edu/~mills/gallery/gallery8.html

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Intel Nehalem-EX Aims for the Mainframe

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@GARLIC.COM (Anne & Lynn Wheeler)
Subject: Re: Intel Nehalem-EX Aims for the Mainframe
Newsgroups: bit.listserv.ibm-main
Date: 1 Apr 2010 12:52:45 -0700
re:
http://www.garlic.com/~lynn/2010g.html#25 Intel Nehalem-EX Aims for the Mainframe
http://www.garlic.com/~lynn/2010g.html#27 Intel Nehalem-EX Aims for the Mainframe
http://www.garlic.com/~lynn/2010g.html#28 Intel Nehalem-EX Aims for the Mainframe
http://www.garlic.com/~lynn/2010g.html#32 Intel Nehalem-EX Aims for the Mainframe

IBM goes elephant with Nehalem-EX iron; Massive memory for racks and blades
http://www.theregister.co.uk/2010/04/01/ibm_xeon_7500_servers/

from above:
With so much of its money and profits coming from big Power and mainframe servers, you can bet that IBM is not exactly enthusiastic about the advent of the eight-core "Nehalem-EX" Xeon 7500 processors from Intel and their ability to link up to eight sockets together in a single system image. But IBM can't let other server makers own this space either, so it had to make some tough choices.

... snip ...

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

16:32 far pointers in OpenWatcom C/C++

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 16:32 far pointers in OpenWatcom C/C++
Newsgroups: alt.sys.pdp10, alt.folklore.computers
Date: Thu, 01 Apr 2010 17:35:49 -0400
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
Late in S/370, just before XA/370, two unused bits in the page table entries were used to allow for a 26 bit physical address, with 24 bit virtual addresses.

MVS scaling up 3033 in late 70s was having large number of teething/scaling problems. 370 was limited to 24bit instruction address (real & virtual) ... the two bit hack in the page table entry ... allowed for 14bit (4kbyte) page numbers ... allowing virtual pages to be resident in up to 64mbytes of real storage.

There were some number of problems when low-level kernel (running in real mode) required instructions to access data in virtual pages ... but couldn't generate address for >16mbytes. The original design was to page-out target page (that happened to be above the 16mbyte line) and page it back in again (below the 16mbyte line); the page I/O worked because IDALs had been introduced with original 370 ... which had 32bits (even tho standard i/o programming only allowed for 24bit real addresses).

I provided them with a hack that dummied up two page table entries, entered virtual mode ... and copied data from virtual page (above real 16mbyte line) to a virtual page (below real 16mbyte line).

MVS had a separate (scaling) problem on 3033. The original real-storage batch operating system was heavily dependent on pointer-passing APIs. The initial migration was to VS2/SVS ... a single virtual address space ... containing the kernel code and all applications code ... so pointer APIs continued to work.

The move to VS2/MVS ... with a different virtual address space for every application ... involved mapping an 8mbyte kernel image to every application address space (theoritically leaving 8mbytes for applications). However, there were something called subsystem applications ... that were system functions that resided outside of the kernel. The pointer-passing API continued to work in SVS ... but for MVS the subsystem functions were now in different virtual address space from the applications that would be calling them (and passing pointer to paremters). The hack done for MVS ... was something called the "common segment" ... and area in every virtual address space that applications could stuff API parameters before making a subsystem call (passing thru the kernel involved switching address space). The size of the common segment grew as the number of concurrent applications grew ... as well as the number of different subsystems increased. By 3033 time-frame, the common segment were 4-5 mbytes .... and threatening to become 6mbytes (aka 16mbyte virtual address space for each application, however 8mbytes for kernel image, potentially 6mbytes for common segment image ... possibly reducing application address space to just 2mbytes).

In any case, six (vm370) 4341s cluster had higher aggregate processing rate than 3033, more aggregate real storage than 3033, more aggregate channel & I/O capacity than 3033 and lower cost than 3033.

misc. recent posts mentioning 3033:
http://www.garlic.com/~lynn/2010.html#84 locate mode, was Happy DEC-10 Day
http://www.garlic.com/~lynn/2010b.html#87 "The Naked Mainframe" (Forbes Security Article)
http://www.garlic.com/~lynn/2010b.html#99 "The Naked Mainframe" (Forbes Security Article)
http://www.garlic.com/~lynn/2010c.html#1 "The Naked Mainframe" (Forbes Security Article)
http://www.garlic.com/~lynn/2010c.html#41 Happy DEC-10 Day
http://www.garlic.com/~lynn/2010c.html#71 using an FPGA to emulate a vintage computer
http://www.garlic.com/~lynn/2010d.html#52 Happy DEC-10 Day
http://www.garlic.com/~lynn/2010d.html#81 LPARs: More or Less?
http://www.garlic.com/~lynn/2010e.html#1 LPARs: More or Less?
http://www.garlic.com/~lynn/2010e.html#2 LPARs: More or Less?
http://www.garlic.com/~lynn/2010e.html#27 SHAREWARE at Its Finest
http://www.garlic.com/~lynn/2010e.html#36 What was old is new again (water chilled)
http://www.garlic.com/~lynn/2010e.html#48 z9 / z10 instruction speed(s)
http://www.garlic.com/~lynn/2010e.html#50 LPARs: More or Less?
http://www.garlic.com/~lynn/2010e.html#75 LPARs: More or Less?
http://www.garlic.com/~lynn/2010e.html#76 LPARs: More or Less?
http://www.garlic.com/~lynn/2010f.html#13 What was the historical price of a P/390?
http://www.garlic.com/~lynn/2010f.html#14 What was the historical price of a P/390?
http://www.garlic.com/~lynn/2010g.html#11 Mainframe Executive article on the death of tape
http://www.garlic.com/~lynn/2010g.html#22 Mainframe Executive article on the death of tape
http://www.garlic.com/~lynn/2010g.html#24 Mainframe Executive article on the death of tape
http://www.garlic.com/~lynn/2010g.html#31 Mainframe Executive article on the death of tape

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

16:32 far pointers in OpenWatcom C/C++

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 16:32 far pointers in OpenWatcom C/C++
Newsgroups: alt.folklore.computers, comp.lang.java,
microsoft.public.vb.general.discussion
Date: Thu, 01 Apr 2010 18:36:58 -0400
"Charlie Gibbs" <cgibbs@kltpzyxm.invalid> writes:
You're right, it's actually the snot-nosed kids who are the problem; they can write crappy applications in any language. All they need is a PHB who forgets about robustness upon seeing a flashy screen.

that was billions dump down that hole in the 90s.

real-time financial transactions (wall street, stock trades, atm cash) tended to be front-end that just starts the transactions which are then finalized in the overnight batch window (in some cases legacy code from the 60s & 70s ... with some real-time front-end stuff added in the 70s & 80s).

in the 90s, the limitations of the overnight batch window was becoming a big problem ... business growth resulting in more work needing to be done ... and globalization tended to reduce the size of time available for overnight batch.

the solution was re-engineering with straight-through processing ... using parallelization and large numbers of "killer micros". there was some object technology that provided the basis for the parallelization and it really looked great in the toy demos (and nobody paid any attention to scaleup). then during various deployments ... they discovered that the parallel/object technology introduced factor of 100 times overhead (compared to the overnight batch) ... totally swamping any hopes of thruput increases (needed for doing the straight-through processing). the projects were then quietly canceled and the billions written off.

looked at some of this in taligent jad ... recently mentioned
http://www.garlic.com/~lynn/2010g.html#9 Far and near pointers on the 80286 and later
http://www.garlic.com/~lynn/2010g.html#15 Far and near pointers on the 80286 and later

we actually went back in 2006 with a proposal for doing parallelized straight-through processing ... using a totally different kind of parallelizing technology approach ... that maybe had 4-5 times overhead increase (compared to overnight cobol batch) ... which was well within the price/performance of the current generation of "killer micros" ... clusters of recently announced Nehalem would more than meet the thruput and price/performance requirements:
http://www.garlic.com/~lynn/2010g.html#25 Intel Nehalem-EX Aims for the Mainframe
http://www.garlic.com/~lynn/2010g.html#27 Intel Nehalem-EX Aims for the Mainframe
http://www.garlic.com/~lynn/2010g.html#28 Intel Nehalem-EX Aims for the Mainframe
http://www.garlic.com/~lynn/2010g.html#32 Intel Nehalem-EX Aims for the Mainframe
http://www.garlic.com/~lynn/2010g.html#35 Intel Nehalem-EX Aims for the Mainframe

but it turned out that the large financial institutions had been so badly burned in the 90s ... they were extremely risk adverse attempting it again so soon (even with reams of performance numbers and benchmarks showing it worked and scaled ... even using 2006 processor technologies).

a few misc. posts mentioning the overnight batch window and the billions dumped down the parallelization/object hole in the 90s for straight-though processing:
http://www.garlic.com/~lynn/2010.html#77 Korean bank Moves back to Mainframes (...no, not back)
http://www.garlic.com/~lynn/2010b.html#16 How long for IBM System/360 architecture and its descendants?
http://www.garlic.com/~lynn/2010b.html#19 STEM crisis
http://www.garlic.com/~lynn/2010c.html#8 search engine history, was Happy DEC-10 Day
http://www.garlic.com/~lynn/2010c.html#78 SLIGHTLY OT - Home Computer of the Future (not IBM)

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

someone smarter than Dave Cutler

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: someone smarter than Dave Cutler
Newsgroups: alt.folklore.computers,
 comp.os.ms-windows.programmer.nt.kernel-mode,
microsoft.public.development.device.drivers, alt.sys.pdp10
Date: Fri, 02 Apr 2010 15:33:26 -0400
jmfbahciv <jmfbahciv@aol> writes:
Then we got the PDP-10 because DEC gave a lower bid than IBM.

ibm use to give very large educational discounts ... i think possibly like 60% ... but that all changed after the litigation started and the gov. jumped in (starting around 69 when unbundling was also announced 23jun69) ... then there were much fewer educational ibm installs after that.

misc. past posts mentioning unbundling announced
http://www.garlic.com/~lynn/submain.html#unbundle

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

someone smarter than Dave Cutler

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: someone smarter than Dave Cutler
Newsgroups: alt.folklore.computers, alt.sys.pdp10
Date: Fri, 02 Apr 2010 16:50:29 -0400
Pat Farrell <pfarrell@pfarrell.com> writes:
I expect all the computer vendors gave large education discounts. DEC and IBM were not the only ones. The idea was simple: have the students learn to use your brand of locked in computers, and when they get out and into companies, they will carry their biases with them.

re:
http://www.garlic.com/~lynn/2010g.html#29 someone smarter than Dave Cutler
http://www.garlic.com/~lynn/2010g.html#34 someone smarter than Dave Cutler
http://www.garlic.com/~lynn/2010g.html#38 someone smarter than Dave Cutler

they tried to come back in the 80s with the formation of ACIS (started out with allocation of $300M to "give" away to univs) .... which started giving away money ... also funding the BITNET and EARN links. Both DEC and IBM "gave" $25M to project athena at MIT ... but IBM also made $50m to CMU (i've made past jokes about funding mach and camelot three times over) and many other places.

old email from person setting up EARN ... looking for help:
http://www.garlic.com/~lynn/2001h.html#email840320
in this post
http://www.garlic.com/~lynn/2001h.html#65 UUCP email

the following year we exchanged teenagers for the summer.

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

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

someone smarter than Dave Cutler

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: someone smarter than Dave Cutler
Newsgroups: alt.folklore.computers, alt.sys.pdp10
Date: Fri, 02 Apr 2010 17:41:47 -0400
Patrick Scheible <kkt@zipcon.net> writes:
It was pretty obvious even then that putting rambunctious undergraduates on the same computer where their grades were stored was a bad idea...

i've several times repeated the story about joint project between the science center and endicott to provide 370 virtual machines (with 370 virtual memory definition) on cp67 (before virtual memory was announced). there were some number of non-employees using the system (students and others from various educational institutions in the cambridge area, bu, mit, harvard, etc) ... and there was assurnaces that the 370 virtual memory wasn't to leak out before announce. misc. recent posts:
http://www.garlic.com/~lynn/2010b.html#51 Source code for s/360
http://www.garlic.com/~lynn/2010b.html#63 Source code for s/360 [PUBLIC]
http://www.garlic.com/~lynn/2010d.html#60 LPARs: More or Less?
http://www.garlic.com/~lynn/2010e.html#23 Item on TPF
http://www.garlic.com/~lynn/2010g.html#31 Mainframe Executive article on the death of tape

of course it was also being used for online timesharing by others ... some of which i didn't hear about until much later
http://web.archive.org/web/20090117083033/http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml

it was also being used by some number of commercial online timesharing service bureaus
http://www.garlic.com/~lynn/submain.html#timeshare

some of these had moved up the value chain and added financial information and catering to various large financial houses (which would have had significant financial motivation to break security and evesdrop on things that their competitors might be doing).

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

someone smarter than Dave Cutler

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: someone smarter than Dave Cutler
Newsgroups: alt.folklore.computers, alt.sys.pdp10
Date: Sat, 03 Apr 2010 11:11:05 -0400
Pat Farrell <pfarrell@pfarrell.com> writes:
OK, I stand corrected. But it could not have been fun. When I think of Lisp, I think of crazy interaction with the user.

history of lisp
http://www.softwarepreservation.org/projects/LISP/
and
http://www.softwarepreservation.org/projects/LISP/index.html#LISP_I_and_LISP_1.5_for_IBM_704,_709,_7090_

old email references (11Jul79) to lisp machine project requesting 801s and being offered 8100s instead
http://www.garlic.com/~lynn/2003e.html#65 801 (was Re: Reviving Multics
http://www.garlic.com/~lynn/2006c.html#3 Architectural support for programming languages
http://www.garlic.com/~lynn/2006o.html#45 "25th Anniversary of the Personal Computer"
http://www.garlic.com/~lynn/2006t.html#9 32 or even 64 registers for x86-64?

at some point, my wife got asked to evaluate 8100 ... and she recommended it be killed. for other drift ... later she was also asked to audit RP3 to see if funding should continue and she turned thumbs down
http://www.garlic.com/~lynn/2010f.html#77 Notes on two presentations by Gordon Bell ca. 1998
http://www.garlic.com/~lynn/2010f.html#78 Notes on two presentations by Gordon Bell ca. 1998

from long ago and far away ... following small pieces from somebody's extremely long (400 line) email with summary about various different things.

Date: 4/24/79 20:34
To: Distribution
...
8. Teresa Roberts of Xerox PARC and Stanford talked about her thesis work, to develop evaluation techniques for text editors that are thorough, quick and usable by non-psychologists. She considered several classes of use, including "experts" using the editors as they would normally. Editors examined were WYLBUR, TECO, NLS and the WANG word processor.

One result: doing "53 core tasks" (e.g. composing and editing letters) experts took around twice as long using TECO/WYLBUR as NLS/WANG. An analysis of function (simply listing "needed tasks" and which editor could, could "sort of", or couldn't do them) made NLS appear the winner (because of lots of text formatting functions), followed by WYLBUR, WANG and TECO.

An analysis of "ease of learning" had TECO the most difficult to learn, by far (learners were beginners who knew how to type. They were given an introduction, 2 quizes, 5 sessions altogether. Unlimited practice time was allowed before quizes.)

An analysis of errors was made (time lost due to "normal" (as opposed to "catastrophic") errors, increase in errors due to distraction, and an analytic study (just an examination of the kinds of errors that "could" occur). Interesting observation: Experts spent an average of 15% of their time correcting "normal" errors.

A "checklist for disasters" has been formulated, but not yet applied. There were some evident methodological bugs in this work, but she understood what had to be done to eliminate them, and I expect she'll make the changes before continuing.
...
10. "Automated "Knowledge Processing": Computer Aids for Medical Decision- Making"-- John Kunz from Pacific Medical Center (who works with Ed Feigenbaum at Stanford talked about the state of the art in knowledge-based systems, their current capabilities and limitations. It seems that most of the useful LISP applications in the real world are in the medical area. He described MYCIN and DENDRAL (expert programs in different fields) and PUFF (an "intelligent instrument" for detecting and diagnosing pulmonary disorders) There is the possibility that IRD might be interested in developing a PUFF system. I have spoken with Konnerth (Mgr of Advanced Technology in Mt Kisco) about it, and he is definitely interested in pursuing it (IRD is already considering business ventures in the pulmonary area). Also, it seems that Feigenbaum will be involved in the Stanford Joint Study in two proposed projects: one to semi-automate the application development process (don't know the details) and another with FE, to provide an "expert program" that understands how to fix a particular device. Fred Blair and I had lunch with Kunz, and Fred will pursue the possibility of importing/developing LISP/370 applications. Kunz has been invited to give a talk on May 23 here.
...
... snip ... top of post, old email index.

past posts in this thread:
http://www.garlic.com/~lynn/2010g.html#29 someone smarter than Dave Cutler
http://www.garlic.com/~lynn/2010g.html#34 someone smarter than Dave Cutler
http://www.garlic.com/~lynn/2010g.html#38 someone smarter than Dave Cutler
http://www.garlic.com/~lynn/2010g.html#39 someone smarter than Dave Cutler
http://www.garlic.com/~lynn/2010g.html#40 someone smarter than Dave Cutler

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Interesting presentation

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Interesting presentation
Newsgroups: comp.arch
Date: Sat, 03 Apr 2010 16:09:49 -0400
i got called in to talk to some of the people regardubg mvt to initial virtual memory vs2/svs ... page replacement algorithms, local vs-a-vis global replacement, some other stuff.

for some reason, they decided to make a micro trade-off ... selecting non-changed pages for replacement before changed pages (because they didn't have to write first ... the slot was immediately available) ... didn't matter how much argued with them ... they were determined to do it anyway. it wasn't until well into the vs2/mvs time-frame that somebody realized that they were replacing high-use shared executable library pages before private, lower-use data pages.

recent thread mentioning old issue with local vis-a-vis global LRU replacement:
http://www.garlic.com/~lynn/2010f.html#85 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010f.html#89 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010f.html#90 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010f.html#91 16:32 far pointers in OpenWatcom C/C++

jim getting me into middle of academic dispute based on some work i had done as undergraduate in the 60s ... past reference
http://www.garlic.com/~lynn/2006w.html#46 The Future of CPUs: What's After Multi-Core?

in the 80s ... there was "big page" change for both mvs and vm ... sort of part-way swapping & demand page. at queue drop (aka swap) ... resident virtual pages would be formed into ten page collections and written as full-track 3380 disk write ... to the nearest free track arm position (moving cursor, slight similarity to log-structured file system). Subsequent page fault, if the page was part of a big-page, the whole big page would be brought in.

the whole orientation was arm motion is the primary bottleneck with trading off both transfer capacity and real-storage against arm motion (fetch of ten pages might bring in pages that weren't actually needed the next time, the approach was slightly better than brute force move to 40k pages ... since it was some ten 4k pages that had actually been recently used ... as opposed to 40kbyte contiguous area). recent post mentioning big pages:
http://www.garlic.com/~lynn/2010g.html#23 16:32 far pointers in OpenWatcom C/C++

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Interesting presentation

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Interesting presentation
Newsgroups: comp.arch
Date: Sun, 04 Apr 2010 09:43:11 -0400
Morten Reistad <first@last.name> writes:
The classic mainframe paging got underway when a disk access took somewhat more than 200 instructions to perform. Now it is main memory that takes a similar number of instructions to access. We have a problem with handling interrupts though; then an interrupt would cost ~20 instructions; now it costs several hundred.

On a page fault we would normally want to schedule a read of the missing page into a vacant page slot, mark the faulting thread in IO wait, and pick the next process from the scheduler list to run. On IO complete we want to mark the page good, and accessed, put the thread back on the scheduler list as runnable; and possibly run it. These bits can be done in hardware by an MMU. But for a prototype we just need to generate a fault whenever the page is not in on-chip memory.


re:
http://www.garlic.com/~lynn/2010g.html#42 Interesting presentation

"store-in caches" required the selected real memory slot to have any "changed" contents first written back to disk. the latency of this operation could somewhat be masked by running the replacement selection slightly "ahead" (asynchronous) of the selection process ... so any required writing (of selected replacede page) is completed by the time the page is selected (masks the latency to write pages back to disk but still requires the pathlength to perform the operations).

'68 ... i had rewritten pieces of cp67 to get the whole avg. pathlength from several thousand down to approx. 500. (long-winded) old post
http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Maiuframe out the Door

that is separate from latency. original cp67 used fixed-head rotating drum with single page transfer per i/o ... which then had avg. rotational delay per transfer ... limit to approx. 80 i/os per second. i changed that to "chain" all pending requests in rotational order in one single i/o operation ... raising the peak to 300 i/os per second.

As machines got faster and caches started to become critical component ... asynchronous i/o interrupts became a major thruput issues ... caches were relatively small ... so there was effectively complete cache replacement on every i/o interrupt (followed by separate cache replacement again when return to doing whatever was going on when the interrupt occured). the cache replace associated with asynchronous interrupts would start to dominant any highly optimized pathlength.

in the 80s, some number of mainframe systems could have pathlength approaching 10,000 instructions to do the page fault, replace, task switch, i/o pathlength, interrupt, task switch again. 3090 introduced expanded store (electronic paging) and synchronous page transfer instruction between main memory and expanded store. expanded store was solution to 3090 not being able to deal with non-uniform memory access with physical packaging of increasing amounts of real storage. The solution was the physical packaging that was further away and had higher latency was "expanded store" ... and the software moved pages between "processor real storage" and "expanded store". the synchronous instruction eliminated the really long pathlength associated with asynchronous operation (in many systems of the period) ... as well as some amount of the cache replace overhead.

The issue was that expanded store tended to be on the size of real storage (and the same technology ... just longer latency) ... so there still had to be disk paging ... "expanded store" management required moving replaced "expanded store" pages back into real processor storage before writing to disk.

Later processors and physical packaging eliminated "expanded store" ... but some configuration continued to be configured with the two level electronic memory (machine microcode configuration setup to simulate "expanded store" operation). The issue was that some operating system page replacement algorithms had become heavily tuned to operating with bimodel "expanded store" ... and when presented with one large homogeneous storage, the replacement page selection performed less well than when real storage was divided into the two areas.

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

16:32 far pointers in OpenWatcom C/C++

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 16:32 far pointers in OpenWatcom C/C++
Newsgroups: alt.sys.pdp10, alt.folklore.computers
Date: Sun, 28 Mar 2010 14:53:00 -0400
re:
http://www.garlic.com/~lynn/2010f.html#85 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010f.html#89 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010f.html#90 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010f.html#91 16:32 far pointers in OpenWatcom C/C++

as mentioned in the old post
http://www.garlic.com/~lynn/2006w.html#46 The Future of CPUs: What's After Multi-Core?

it took almost a year to get approval before sending even this innocuous item
http://www.garlic.com/~lynn/2006w.html#email821019

i have no evidence that research members were taking sides in the argument ... it was more likely just another one of the petty punishments for having offended somebody or another (i had several papers for external publication that i tried for yrs to get approved before giving up).

i had done an internal paper on RAS/never-fail for the disk engineering labs so that they could have on-demand, anytime arbitrary number of concurrent development testing (as opposed to their pre-scheduled, stand-alone, around the clock dedicated testing). some past posts getting to play disk engineer
http://www.garlic.com/~lynn/subtopic.html#disk

I did happen to include a reference in the internal paper that at one point a standard MVS had been tried and experienced a 15min MTBF in that environment ... which brought down the wrath of the mvs organization on my head. just another "business ethics is oxymoron" ... misc past refs:
http://www.garlic.com/~lynn/2007j.html#72 IBM Unionization
http://www.garlic.com/~lynn/2009.html#53 CROOKS and NANNIES: what would Boyd do?
http://www.garlic.com/~lynn/2009e.html#37 How do you see ethics playing a role in your organizations current or past?
http://www.garlic.com/~lynn/2009o.html#36 U.S. students behind in math, science, analysis says
http://www.garlic.com/~lynn/2009o.html#52 Revisiting CHARACTER and BUSINESS ETHICS
http://www.garlic.com/~lynn/2009o.html#57 U.S. begins inquiry of IBM in mainframe market
http://www.garlic.com/~lynn/2009p.html#43 From The Annals of Release No Software Before Its Time
http://www.garlic.com/~lynn/2009p.html#57 MasPar compiler and simulator
http://www.garlic.com/~lynn/2009p.html#60 MasPar compiler and simulator
http://www.garlic.com/~lynn/2009p.html#87 IBM driving mainframe systems programmers into the ground
http://www.garlic.com/~lynn/2009r.html#50 "Portable" data centers
http://www.garlic.com/~lynn/2010b.html#38 Happy DEC-10 Day
http://www.garlic.com/~lynn/2010c.html#82 search engine history, was Happy DEC-10 Day
http://www.garlic.com/~lynn/2010f.html#20 Would you fight?

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

IA64

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IA64
Newsgroups: comp.sys.intel, alt.folklore.computers
Date: Sun, 28 Mar 2010 15:45:24 -0400
John Levine <johnl@iecc.com> writes:
It's a pattern -- they did the same thing with the project that ended up being the 432. The parallels are quite striking. The 8800/432 project tried to use what was then state of the art thinking about capabilities and parallel processing, while the 8086 was a quick hack to make a followon for the 8085 that had wider registers and addresses. We all know which one won.

acm sigops in asilomar ... i think '79 ... there was 432 presentation ... i remember one of the difficulties highlighted was that they had sunk a lot of complex operating stuff into silicon ... and had to replace chips when ever they found/fixed bugs.

some of the stuff 432 moved into silicon ... i had done slightly similar in '75 moving some stuff into microcode for 5-way SMP/parallel 370 project (that never shipped) ... but it was far easier to send out replacement microcode floppy ... that it was to replace processor chips.

misc past posts mentioning i432
http://www.garlic.com/~lynn/2000e.html#6 Ridiculous
http://www.garlic.com/~lynn/2002d.html#27 iAPX432 today?
http://www.garlic.com/~lynn/2004e.html#52 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004q.html#60 Will multicore CPUs have identical cores?
http://www.garlic.com/~lynn/2004q.html#64 Will multicore CPUs have identical cores?
http://www.garlic.com/~lynn/2004q.html#73 Athlon cache question
http://www.garlic.com/~lynn/2005d.html#64 Misuse of word "microcode"
http://www.garlic.com/~lynn/2005k.html#46 Performance and Capacity Planning
http://www.garlic.com/~lynn/2006c.html#47 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006n.html#42 Why is zSeries so CPU poor?
http://www.garlic.com/~lynn/2006n.html#44 Any resources on VLIW?
http://www.garlic.com/~lynn/2007s.html#36 Oracle Introduces Oracle VM As It Leaps Into Virtualization
http://www.garlic.com/~lynn/2008d.html#54 Throwaway cores
http://www.garlic.com/~lynn/2008e.html#32 CPU time differences for the same job
http://www.garlic.com/~lynn/2008k.html#22 CLIs and GUIs
http://www.garlic.com/~lynn/2009d.html#52 Lack of bit field instructions in x86 instruction set because of patents ?
http://www.garlic.com/~lynn/2009q.html#74 Now is time for banks to replace core system according to Accenture

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

16:32 far pointers in OpenWatcom C/C++

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 16:32 far pointers in OpenWatcom C/C++
Newsgroups: alt.sys.pdp10, alt.folklore.computers
Date: Sun, 28 Mar 2010 15:48:04 -0400
Michael Wojcik <mwojcik@newsguy.com> writes:
Is this the two-handed-clock algorithm?

re:
http://www.garlic.com/~lynn/2010f.html#85 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010f.html#89 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010f.html#90 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010f.html#91 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010g.html#0 16:32 far pointers in OpenWatcom C/C++

it is two-handed-clock with a twist ... how the reset hand worked

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

16:32 far pointers in OpenWatcom C/C++

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 16:32 far pointers in OpenWatcom C/C++
Newsgroups: alt.sys.pdp10, alt.folklore.computers
Date: Mon, 29 Mar 2010 00:15:07 -0400
Mark Crispin <mrc@panda.com> writes:
Speaking as someone who operated class scheduling on TOPS-20 for some years, the people who say that they want class scheduling invariably end up being very unhappy with the results. Inevitably, the people who think that they are not receiving the "fair 40% of the CPU that they paid for" turn out to have been using quite a bit more, and thus receive less under class scheduling.

my dynamic adaptive resource manager that i did as undergraudate in the 60s for cp67 .... was periodically referred to as "fair share" scheduler (default resource policy was fair share) or the wheeler scheduler. it was dropped in a lot of simplification that was involved in the morph from cp67 to vm370; however it later migrated it to vm370 and it was eventually shipped to customers. There was also a large number of internal datacenter customers ... and for a while ... i shipped/supported directly more than a hundred such internal datacenters. some old email related to moving misc. stuff from cp67 to vm370:
http://www.garlic.com/~lynn/2006v.html#email731212
http://www.garlic.com/~lynn/2006w.html#email750102
http://www.garlic.com/~lynn/2006w.html#email750430

at one point, the people running the internal STL datacenter was talking about the large number of different depts in STL clamering for more control over resource allocation (dept. specific specified allocation) ... so i did a version that allowed specifying aggregate goals and then allowing fair share and/or other policies within aggregate (that is subset of the whole computer).

The STL datacenter management told me they wouldn't even remotely touch such a thing ... if i thot there internal deprt. user group meetings were bad now ... just see what would happen if the different depts. thot that there was a way for setting dept. specific goals ... then the political infighting would get horribly vicious ... with the datacenter management right in the middle of everybody's crossfire.

other points in this thread:
http://www.garlic.com/~lynn/2010f.html#85 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010f.html#89 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010f.html#90 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010f.html#91 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010g.html#0 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010g.html#2 16:32 far pointers in OpenWatcom C/C++

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Handling multicore CPUs; what the competition is thinking

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Handling multicore CPUs; what the competition is thinking
Newsgroups: comp.os.linux.advocacy, comp.os.linux.hardware, comp.arch,
alt.folklore.computers
Date: Mon, 29 Mar 2010 10:08:17 -0400
then there is this news item from last year

IBM pureScale Technology Redefines Transaction Processing Economics. New DB2 Feature Sets the Bar for System Performance on More than 100 IBM Power Systems
http://www-03.ibm.com/press/us/en/pressrelease/28593.wss

that I reference in post on "From The Annals of Release No Software Before Its Time" http://www.garlic.com/~lynn/2009p.html#43

other posts with comments:
http://www.garlic.com/~lynn/2009p.html#35 DB2 announces technology that trumps Oracle RAC and Exadata
http://www.garlic.com/~lynn/2009p.html#42 big iron mainframe vs. x86 servers

past posts in this thread:
http://www.garlic.com/~lynn/2010f.html#50 Handling multicore CPUs; what the competition is thinking
http://www.garlic.com/~lynn/2010f.html#52 Handling multicore CPUs; what the competition is thinking
http://www.garlic.com/~lynn/2010f.html#55 Handling multicore CPUs; what the competition is thinking
http://www.garlic.com/~lynn/2010f.html#56 Handling multicore CPUs; what the competition is thinking
http://www.garlic.com/~lynn/2010f.html#57 Handling multicore CPUs; what the competition is thinking
http://www.garlic.com/~lynn/2010f.html#58 Handling multicore CPUs; what the competition is thinking
http://www.garlic.com/~lynn/2010f.html#60 Handling multicore CPUs; what the competition is thinking
http://www.garlic.com/~lynn/2010f.html#61 Handling multicore CPUs; what the competition is thinking
http://www.garlic.com/~lynn/2010f.html#63 Handling multicore CPUs; what the competition is thinking
http://www.garlic.com/~lynn/2010f.html#64 Handling multicore CPUs; what the competition is thinking
http://www.garlic.com/~lynn/2010f.html#70 Handling multicore CPUs; what the competition is thinking
http://www.garlic.com/~lynn/2010f.html#73 Handling multicore CPUs; what the competition is thinking

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

16:32 far pointers in OpenWatcom C/C++

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 16:32 far pointers in OpenWatcom C/C++
Newsgroups: alt.sys.pdp10, alt.folklore.computers
Date: Mon, 29 Mar 2010 13:17:37 -0400
Mark Crispin <mrc@panda.com> writes:
Most of the monitor was swappable. Pretty much all system call code was. The non-swappable stuff was either interrupt code, scheduler code, or code called from interrupts or scheduler.

original cp67 monitor code was all fixed ... along with pre-allocated, fixed "stack" (actually fixed number of save areas).

some of the things I did as undergraduate in the 60s (actually the summer I was brought in to boeing to help setting up boeing computer services) ... were

1) when pre-allocated saveareas (for calling) ran out ... be able to allocate additional saveareas (taken from the dynamic paging area)

2) all internal kernel calling convention involved SVC interrupt that would dynamically allocate save area ... and then the reverse on return. a majority of kernel calls were to small subroutines that would immediately return ... w/o calling any other routine (and so never required dynamically allocated save area). I modified this to be a direct BALR call and used a pre-allocated fixed savearea located in real storage "page zero" (aka there was unique page zero for every processor in complex). The original CP67 SVC call/return convention took over 270mics on 360/67 ... for a large number of simple subroutine calls that might take 50mics total.

3) make portions of the cp67 kernel pageable ... kernel section was split into two contiguous areas ... the low-area that had to be fixed ... and the higher-area that could be be paged. this never shipped in standard cp67 product ... but was adopted for initial release of vm370. Only routines that were called by SVC call/return linkage were in the pageable area ... and so the logic for handling the paging gorp was all encapsulated as part of the call/return processing.

other posts in this thread:
http://www.garlic.com/~lynn/2010f.html#85 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010f.html#89 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010f.html#90 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010f.html#91 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010g.html#0 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010g.html#2 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010g.html#3 16:32 far pointers in OpenWatcom C/C++

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Call for XEDIT freaks, submit ISPF requirements

Refed: **, - **, - **, - **, - **, - **, - **
From: lynn@GARLIC.COM (Anne & Lynn Wheeler)
Subject: Re: Call for XEDIT freaks, submit ISPF requirements
Newsgroups: bit.listserv.ibm-main
Date: 29 Mar 2010 10:46:02 -0700
mark.van-der-eynden@HP.COM (Mark van der Eynden) writes:
If you have the command in col 1 (i.e. no piping) it would be 'stack *'

But gees guys, you're talking about 25 year old memories, I'd expect XEDIT is even better now -)


for a little topic drift ... old posts detailing how a lot of ISPF development was paid for by siphoning off revenue from VM370 Performance products:
http://www.garlic.com/~lynn/2000d.html#17 Where's all the VMers?
http://www.garlic.com/~lynn/2001m.html#33 XEDIT on MVS
http://www.garlic.com/~lynn/2003k.html#0 VSPC
http://www.garlic.com/~lynn/2005t.html#40 FULIST
http://www.garlic.com/~lynn/2006k.html#50 TSO and more was: PDP-1
http://www.garlic.com/~lynn/2007g.html#17 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007o.html#41 Virtual Storage implementation
http://www.garlic.com/~lynn/2007o.html#69 ServerPac Installs and dataset allocations
http://www.garlic.com/~lynn/2007t.html#55 new 40+ yr old, disruptive technology
http://www.garlic.com/~lynn/2008h.html#43 handling the SPAM on this group
http://www.garlic.com/~lynn/2009s.html#46 DEC-10 SOS Editor Intra-Line Editing

the issue was that traditional favorite son operating system related development had culture of large organizations, staff, and overhead. Moving into pricing for individual software components was somewhat tramatic for that development culture ... even a decade or more after unbundling announcement (and a lot of individual products would never had sold if priced to fully cover all costs)
http://www.garlic.com/~lynn/submain.html#unbundle

product price/revenue had to be greater than infrastructure costs. The solution was to marry several products in the same package or organization ... so that aggregate organization product revenue is better than aggregate infrastructure costs.

this was done with jes2 networking married to vm370 networking. for ISPF it was merging the VM370 Performance products into the same group with ISPF. The two products had approx. the same aggregate revenue ... but at the time, the ISPF organization had nearly 100 times more people than supporting VM370 Performance products (and after the merging is kept that way ... simple support with little or no new VM370 performance product development because ISPF needed to siphon off all the funds).

by comparison xedit was done mostly by one person ... although there were some internal politics ... because there was another internal editor (also by one person) that was much more mature and more function ... that could have been selected in lieu of xedit.

some old email
http://www.garlic.com/~lynn/2006u.html#email781103
http://www.garlic.com/~lynn/2006u.html#email790606
http://www.garlic.com/~lynn/2006u.html#email800311
http://www.garlic.com/~lynn/2006u.html#email800312
http://www.garlic.com/~lynn/2006u.html#email800429
in this post
http://www.garlic.com/~lynn/2006u.html#26 Assembler question

and
http://www.garlic.com/~lynn/2006n.html#email810531
in this post
http://www.garlic.com/~lynn/2006n.html#55 The very first text editor

other past posts
http://www.garlic.com/~lynn/2001m.html#22 When did full-screen come to VM/370?
http://www.garlic.com/~lynn/2002p.html#39 20th anniversary of the internet (fwd)
http://www.garlic.com/~lynn/2003d.html#22 Which Editor
http://www.garlic.com/~lynn/2004o.html#36 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2006k.html#51 other cp/cms history
http://www.garlic.com/~lynn/2007g.html#5 Call for XEDIT freaks, submit ISPF requirements
http://www.garlic.com/~lynn/2008h.html#43 handling the SPAM on this group
http://www.garlic.com/~lynn/2009c.html#52 THE runs in DOS box?
http://www.garlic.com/~lynn/2009c.html#54 THE runs in DOS box?

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Call for XEDIT freaks, submit ISPF requirements

Refed: **, - **, - **
From: lynn@GARLIC.COM (Anne & Lynn Wheeler)
Subject: Re: Call for XEDIT freaks, submit ISPF requirements
Newsgroups: bit.listserv.ibm-main
Date: 29 Mar 2010 15:22:01 -0400
lists@AKPHS.COM (Phil Smith III) writes:
P.S. Who you callin' a freak?

re:
http://www.garlic.com/~lynn/2010g.html#6 Call for XEDIT freaks, submit ISPF requirements

note that in the above post ... I reference a previous post in this mailing list from 28mar2007 with the same exact subject line:
http://www.garlic.com/~lynn/2007g.html#5 Call for XEDIT freaks, submit ISPF requirements

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Handling multicore CPUs; what the competition is thinking

Refed: **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Handling multicore CPUs; what the competition is thinking
Newsgroups: alt.folklore.computers
Date: Mon, 29 Mar 2010 23:25:33 -0400
re:
http://www.garlic.com/~lynn/2010g.html#4 Handling multicore CPUs; what the competition is thinking

related to first in thread:
http://www.garlic.com/~lynn/2010f.html#50 Handling multicore CPUs; what the competition is thinking

misc. old email related to nsfnet
http://www.garlic.com/~lynn/lhwemail.html#nsfnet

so the letter from the director of nsf just aggravated the internal politics (not being allowed to bid or participate on nsfnet backbone T1 rfp) ... then there is this old email
http://www.garlic.com/~lynn/2006w.html#email870109
in this post:
http://www.garlic.com/~lynn/2006w.html#21 SNA/VTAM for NSFNET

one of the people in the communication group had forwarded us some email on the subject ... first in the collection (dated 12/26/86 partially included in the above), was from executive later involved in transfer of cluster scaleup to kingston (and we were told we couldn't work with anything involving more than four processors).

misc. email related to cluster scaleup
http://www.garlic.com/~lynn/lhwemail.html#medusa

cluster scaleup press shortly after effort transferred
http://www.garlic.com/~lynn/2001n.html#6000clusters1
http://www.garlic.com/~lynn/2001n.html#6000clusters2

other recent posts referencing press articles
http://www.garlic.com/~lynn/2010.html#31 Larrabee delayed: anyone know what's happening?
http://www.garlic.com/~lynn/2010c.html#14 Processes' memory
http://www.garlic.com/~lynn/2010f.html#13 What was the historical price of a P/390?
http://www.garlic.com/~lynn/2010f.html#47 Nonlinear systems and nonlocal supercomputing

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Far and near pointers on the 80286 and later

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Far and near pointers on the 80286 and later
Newsgroups: alt.folklore.computers, comp.sys.intel, comp.arch
Date: Tue, 30 Mar 2010 10:13:07 -0400
George Neuner <gneuner2@comcast.net> writes:
Ok, but there are other secure systems to study such as Amoeba and EROS. They are more modern than Multics, and in particular, were designed to be distributed.

I don't mind anyone studying Multic - there is plenty to learn from it (including what not to do) ... but I would be against trying to revive it as a working operating system.


as an aside ... some of the ctss people went to 5th flr, 545 tech sq to do multics and others went to the science center on the 4th flr and did (virtual machine) cp40 (on special modified 360/40 with virtual memory hardware) which morphed into cp67 (when standard virtual memory 360/67 became available) and then morphed into vm370.
http://www.garlic.com/~lynn/subtopic.html#545tech

Old reference to Multics Security Evaluation
http://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation
http://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation
http://www.garlic.com/~lynn/2002l.html#45 Thirty Years Later: Lessons from the Multics Security Evaluation

multics page
http://www.multicians.org/multics.html

old post in multics news group (AFDS was Multics installation)
http://www.garlic.com/~lynn/2001m.html#12 Multics Nostalgia

with respect to cp67 ... there seemed to have been a lot of these guys ... but I didn't become aware of them until much later:
http://web.archive.org/web/20090117083033/http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml

I did assurance panel discussion at 2001 IDF in tcpa track ...
http://web.archive.org/web/20011109072807/http://www.intel94.com/idf/spr2001/sessiondescription.asp?id=stp+s13
with their technical director
http://web.archive.org/web/20011106111653/www.intel94.com/idf/spr2001/speakerdescriptions.asp?id=bsnow

Coyotos is successor to EROS ... EROS was based on tymshare's (370) gnosis capability operating system ... which was spun off as keykos when m/d bought tymshare (I was brought in to do gnosis audit/review as part of the spin-off).
https://en.wikipedia.org/wiki/Coyotos

There were also some number of "object" operating system efforts ... like Apple's Pink and Sun's SPRING/DOE ... some of Apple's Pink technology went to Taligent ... and (possibly) some of SPRING/DOE shows up in java (and java virtual machine)

Recent reference about being asked about coming in to head up commercialization of SPRING/DOE for shipping as product
http://www.garlic.com/~lynn/2010f.html#47 Nonlinear systems and nonlocal supercomputing

misc. past posts mentioning gnosis, keykos, eros, coyotos
http://www.garlic.com/~lynn/2000f.html#69 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000g.html#22 No more innovation? Get serious
http://www.garlic.com/~lynn/2001b.html#73 7090 vs. 7094 etc.
http://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001g.html#35 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001n.html#10 TSS/360
http://www.garlic.com/~lynn/2002f.html#59 Blade architectures
http://www.garlic.com/~lynn/2002g.html#0 Blade architectures
http://www.garlic.com/~lynn/2002g.html#4 markup vs wysiwyg (was: Re: learning how to use a computer)
http://www.garlic.com/~lynn/2002h.html#43 IBM doing anything for 50th Anniv?
http://www.garlic.com/~lynn/2002i.html#63 Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002j.html#75 30th b'day
http://www.garlic.com/~lynn/2003g.html#18 Multiple layers of virtual address translation
http://www.garlic.com/~lynn/2003h.html#41 Segments, capabilities, buffer overrun attacks
http://www.garlic.com/~lynn/2003i.html#15 two pi, four phase, 370 clone
http://www.garlic.com/~lynn/2003j.html#20 A Dark Day
http://www.garlic.com/~lynn/2003k.html#50 Slashdot: O'Reilly On The Importance Of The Mainframe Heritage
http://www.garlic.com/~lynn/2003l.html#19 Secure OS Thoughts
http://www.garlic.com/~lynn/2003l.html#22 Secure OS Thoughts
http://www.garlic.com/~lynn/2003l.html#26 Secure OS Thoughts
http://www.garlic.com/~lynn/2003m.html#24 Intel iAPX 432
http://www.garlic.com/~lynn/2003m.html#54 Thoughts on Utility Computing?
http://www.garlic.com/~lynn/2004c.html#4 OS Partitioning and security
http://www.garlic.com/~lynn/2004e.html#27 NSF interest in Multics security
http://www.garlic.com/~lynn/2004m.html#29 Shipwrecks
http://www.garlic.com/~lynn/2004m.html#49 EAL5
http://www.garlic.com/~lynn/2004n.html#41 Multi-processor timing issue
http://www.garlic.com/~lynn/2004o.html#33 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005.html#7 How do you say "gnus"?
http://www.garlic.com/~lynn/2005b.html#6 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005b.html#7 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005b.html#12 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005c.html#67 intel's Vanderpool and virtualization in general
http://www.garlic.com/~lynn/2005d.html#43 Secure design
http://www.garlic.com/~lynn/2005d.html#50 Secure design
http://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new?
http://www.garlic.com/~lynn/2005k.html#30 Public disclosure of discovered vulnerabilities
http://www.garlic.com/~lynn/2005s.html#12 Flat Query
http://www.garlic.com/~lynn/2006k.html#37 PDP-1
http://www.garlic.com/~lynn/2006m.html#34 PDP-1
http://www.garlic.com/~lynn/2006p.html#13 What part of z/OS is the OS?
http://www.garlic.com/~lynn/2006s.html#7 Very slow booting and running and brain-dead OS's?
http://www.garlic.com/~lynn/2006w.html#42 vmshare
http://www.garlic.com/~lynn/2006y.html#11 Multiple mappings
http://www.garlic.com/~lynn/2006y.html#16 "The Elements of Programming Style"
http://www.garlic.com/~lynn/2007k.html#26 user level TCP implementation
http://www.garlic.com/~lynn/2007o.html#25 LAX IT failure: leaps of faith don't work
http://www.garlic.com/~lynn/2007s.html#17 Oddly good news week: Google announces a Caps library for Javascript
http://www.garlic.com/~lynn/2008b.html#24 folklore indeed
http://www.garlic.com/~lynn/2008b.html#50 How does ATTACH pass address of ECB to child?
http://www.garlic.com/~lynn/2008e.html#12 Kernels
http://www.garlic.com/~lynn/2008g.html#7 was: 1975 movie "Three Days of the Condor" tech stuff
http://www.garlic.com/~lynn/2008g.html#23 Doug Engelbart's "Mother of All Demos"
http://www.garlic.com/~lynn/2008h.html#14 Two views of Microkernels (Re: Kernels
http://www.garlic.com/~lynn/2008s.html#3 New machine code
http://www.garlic.com/~lynn/2009b.html#4 Possibility of malicious CPUs
http://www.garlic.com/~lynn/2009f.html#28 Opinion: The top 10 operating system stinkers
http://www.garlic.com/~lynn/2010d.html#84 Adventure - Or Colossal Cave Adventure

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Gov't coerced Certs thwart SSL/TLS

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Gov't coerced Certs thwart SSL/TLS
Newsgroups: alt.privacy, alt.computer.security
Date: Tue, 30 Mar 2010 10:25:27 -0400
copy of some long-winded posts in another discussion group
http://www.garlic.com/~lynn/2010f.html#71 Law Enforcement Appliance Subverts SSL
http://www.garlic.com/~lynn/2010f.html#80 Law Enforcement Appliance Subverts SSL

Law Enforcement Appliance Subverts SSL
http://www.wired.com/threatlevel/2010/03/packet-forensics/

from above:
... security researcher Chris Soghoian discovered that a small company was marketing internet spying boxes to the feds. The boxes were designed to intercept those communications -- without breaking the encryption -- by using forged security certificates,

... snip ...

financial crypto blog discussion:

Why the browsers must change their old SSL security (?) model
http://financialcryptography.com/mt/archives/001232.html
Pushing the CA into taking responsibility for the MITM
https://financialcryptography.com/mt/archives/001233.html

this is recent computer architecture blog (posting) discussing connection between supercomputing and electronic commerce:
http://www.garlic.com/~lynn/2010f.html#56

i.e. two of the people mentioned in the jan92 cluster scaleup meeting
http://www.garlic.com/~lynn/95.html#13

leave and show up at small client/server startup responsible for something called "commerce server". We are brought in as consultants because they want to do payments transactions on the server; the startup had also invented this technology they called "SSL" that they wanted to use. As part of mapping "SSL" to payment operations (now frequently called "electronic commerce"), required threat & vulnerability studies ... which included lots of assumptions about how SSL had to be deployed and used.

As mentioned in the financial cryptography blog ... majority of exploits over the period since then ... have long been known.

..

one of the references are to the large number of digital certificates for Certification Authorities that have been added to standard browser distributions over the years. In some cases, the original Certification Authorities have gone bankrupt and are no longer in business (browsers have no method for differentiating business practices of the increasing number of different Certification Authorities that have been enabled).

one of the 20yr scenarios is criminal elements coming into some level of influence of any of these Certification Authorities. This is analogous to a number of situations where criminal elements were able to influence ATM cash machine manufacturing ... with skimming compromises installed at the time the machine was being built.

A compromised Certification Authority is able to issue a digital certificate that is acceptable by every browser in the world ... for any business ... even for businesses that have digital certificates issued from totally different Certificate Authority.

This is the old adage that the security trust chain is only as strong as the weakest link ... the criminal elements are likely to go after the weakest link not the strongest link ... (picking some clerk at a Certification Authority ... or a Certification Authority that has some other kind of weakness/vulnerability).

>From failure mode analysis ... having also done some number of high-availability products ... a high availability infrastructure is built so that the probability of infrastructure failure is the probability of all redundant components failing at the same time (the product/multiplication of the failure probabilities of the individual redundant components ... as the number of redundant components go up the probability of system failure decreases).

However, the Certification Authority infrastructure is not a high-availability infrastructure .... its characteristic is the chain analogy ... the system fails if there is any failure in any component (basically adding the failure probability of each individual component) ... as the number of acceptable Certification Authorities increase ... the probability that there is an overall system failure increases (the inverse of high-availability operation where adding redundant components lowers the system failure risk).

There is old post about jan92 meeting in ellisons conference room that draws a thread between high-availability cluster scaleup and current SSL "electronic commerce"
http://www.garlic.com/~lynn/95.html#13

Now, two of the people named in the above meeting, leave and show up at a small client/server startup responsible for something called "commerce server". As mentioned above ... we were then called in to consult because they wanted to do payment transactions on their server; the startup had also invented this technology they called "SSL" they wanted to use.

another weak link in SSL domain name digital certificate infrastructure is the domain name system. When I apply for SSL digital certificate, I provide some information about who I am ... then the Certification Authority validates with the domain name infrastructure that I am also the true owner of the corresponding domain name.

An exploit is domain name hijacking at the domain name system ... and then going to Certification Authority (that does the weakest validation) ... and apply for a valid SSL digital certificate.

Countermeasures to domain name hijacking are using various technologies to improve the integrity of the domain name system. However, there is possibility that some of the technologies can also eliminate the need for SSL domain name certificates. I've pontificated about this catch-22 in the past
http://www.garlic.com/~lynn/subpubkey.html#catch22

another article:

Sneaking Into the Transport Layer With a Fake ID
http://www.ecommercetimes.com/story/69636.html?wlc=1269788312

If crooks can get into compromising POS terminal and ATM cash machines during manufacturing (with built in skimming devices, at one point there was an estimate that as many as 1/3rd of POS terminals being sold in particular market had built in skimming devices at manufacturing) ... what so unthinkable about crooks being able to obtain (valid) SSL digital certificates using forged identification.

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Mainframe Executive article on the death of tape

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@GARLIC.COM (Anne & Lynn Wheeler)
Subject: Re: Mainframe Executive article on the death of tape
Newsgroups: bit.listserv.ibm-main
Date: 30 Mar 2010 07:43:35 -0700
ps2os2@YAHOO.COM (Ed Gould) writes:
Rick: I do not remember the maker (this was probably 30 years ago) we had a Solid state device and we used it for two things. One was PLPA and the other was for a high activity dataset that an application "needed". We fought with the application people for several years to redesign it. We finally convinced them (after a *LOT* of political cr*p) to use VIO. That small change decreased run time from 4+ hours to less than 1 hour.

We also had issue with it when ever there was a power glitch it took a double IPL (delete/define the PLPA). Management finally said the change over to VIO was all that was needed and they kicked the vendor out. When it worked it worked fine when it didn't it crippled the system.


late 70s, early 80s ... internally there was a lot of "1655" from a vendor ... used for paging at large number of internal vm370 sites. they could be configured as 2305 fixed-head disk emulation or as native (if you wrote the support).

the vendor was maker of dram chips ... and the story was that the chips used in 1655 had failed processor memory acceptance tests. the characteristic of block i/o to/from 1655 allowed the i/o controller to compensate for some number of operational characteristics that wouldn't have been acceptable in processor memory.

at that time ... i had also wanted to add separate exposure to the 3350 fixed-head feature (so i could do transfer from fixed head area overlapped with 3350 disk arm motion) ... I got shutdown by POK "JUPITER" effort that was planning on doing something similar to 1655 (JUPITER thot they were going after the paging device market and decided my alternate exposure for 3350 fixed-head feature would impact their sales). JUPITER then found out that the corporation didn't have any spare memory chips for use in emulated i/o device (especially when price as processor memory was much higher than could be gotten for emulated paging device). Eventually JUPITER effort threw in the towel ... but not before shutting me down for ever doing alternate exposure for 3350 fixed-head feature.

Eventually there was Ironwood/Sheriff (3880-11 & 3880-13); 8mbyte disk controller cache ... Ironwood was 4k byte record cache ... and Sheriff was full-track cache.

Some of this changed with 3090 and expanded store ... but until then ... lots of systems were becoming more & more real storage constrained (especially MVS systems) and 370 had trouble supporting more than 16mbyte real storage (except for the hack introduced for 3033 that fiddled two bits in the page table entry to get 26-bit real storage addressing).

some past posts mentioning the 370 >16mbyte hack
http://www.garlic.com/~lynn/93.html#14 S/360 addressing
http://www.garlic.com/~lynn/2001b.html#69 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001i.html#13 GETMAIN R/RU (was: An IEABRC Adventure)
http://www.garlic.com/~lynn/2002c.html#40 using >=4GB of memory on a 32-bit processor
http://www.garlic.com/~lynn/2003d.html#26 Antiquity of Byte-Word addressing?
http://www.garlic.com/~lynn/2003g.html#24 UltraSPARC-IIIi
http://www.garlic.com/~lynn/2004.html#0 comp.arch classic: the 10-bit byte
http://www.garlic.com/~lynn/2004.html#17 Holee shit! 30 years ago!
http://www.garlic.com/~lynn/2004c.html#6 If the x86 ISA could be redone
http://www.garlic.com/~lynn/2004n.html#50 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004o.html#57 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005.html#34 increasing addressable memory via paged memory?
http://www.garlic.com/~lynn/2005p.html#1 Intel engineer discusses their dual-core design
http://www.garlic.com/~lynn/2005p.html#19 address space
http://www.garlic.com/~lynn/2006p.html#0 DASD Response Time (on antique 3390?)
http://www.garlic.com/~lynn/2007o.html#10 IBM 8000 series
http://www.garlic.com/~lynn/2007o.html#56 360/30 memory
http://www.garlic.com/~lynn/2008f.html#12 Fantasy-Land_Hierarchal_NUMA_Memory-Model_on_Vertical
http://www.garlic.com/~lynn/2010.html#84 locate mode, was Happy DEC-10 Day

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Reverse or inverse ARP from windows/linux - no way (!?!?)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Reverse or inverse ARP from windows/linux - no way (!?!?)
Newsgroups: comp.arch.embedded, sci.electronics.design,
comp.protocols.tcp-ip
Date: Tue, 30 Mar 2010 10:55:48 -0400
"JosephKK"<quiettechblue@yahoo.com> writes:
First off the TCP/IP stack is 4 levels, and the ISO model is 7 layers. Thus there is intrinsic mismatch. Much of the TCP/IP model tools span two or more layers in the ISO model. The real deal for TCP/IP protocol definitions comes from the IETF RFC library.

http://www.ietf.org/rfc.html

Please note that this RFC information is freely available for any use.


note quite true anymore ... the copyright notice use to say that author gives unlimited rights including any derivative works as long as the IETF copyright notice was included. A couple years ago, that was changed ... and now it ways that RFC authors may retain rights (so RFCs published since the change are subject to the new copyright rules).

look at RFCs related to IETF Trust ... for instance 5377

5377 I Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents, Halpern J., 2008/11/10 (8pp) (.txt=17843) (See Also 5378) (Refs 3935, 4071, 4371) (Ref'ed By 5744, 5745)

current documents carry the following
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document

... i got hit with it and had to hire a copyright lawyer out of my own pocket (situation where an attempt was made to try and apply the new rules to RFCs published under the old rules) ... and suggested that they needed to make it much more clear to the authors about copyright changes.

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

An Interview with Watts Humphrey, Part 6: The IBM 360

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: An Interview with Watts Humphrey, Part 6: The IBM 360
Newsgroups: alt.folklore.computers
Date: Tue, 30 Mar 2010 13:34:13 -0400
the following includes some stuff on 360/67 and time-sharing (somebody sent me email, bringing it to my attention).

The IBM 360 Announcement
http://www.informit.com/articles/article.aspx?p=1571987&rll=1

I've posted a couple commets at the above:

TSS/360 vis-a-vis CP67/CMS

While there were early orders of 360/67 for TSS/360, most of the machines ran CP67/CMS done at the science center.

Melinda has done a history that goes into significant more detail:
http://www.leeandmelindavarian.com/Melinda/
http://www.leeandmelindavarian.com/Melinda/

Lincoln Labs, 2250, CP67/CMS

CP67/CMS was installed at Lincoln Labs ... and then in Jan68 at univ (where I was undergraduate) that had original got 360/67 for TSS. Lincoln Labs had CMS fortran library supporting 2250. I took the Lincoln Labs 2250 fortran library and interfaced it to the CMS editor ... to get fullscreen editor on 2250

CP67 Commercial Timesharing Service Bureaus

TSS/360 never got far enough along to even consider some of these issues.

Part of the 7x24 operation in the 60s was that machines were leased and charged for based on cpu meter ... which nominally ran all the time if the system was running. In 7x24 online operation, there might be periods where system was idle (say 3rd shift sunday), so there were tricks to leave the system available for operation but wouldn't run the cpu meter.

Another was weekly or monthly service in datacenter with numerous 360/67s; 7x24 operation required that users didn't see any disruption when different components were taking out of service for maintenance.

There are a lot of similarities with what was learned in these cp67 operations and modern day cloud computing.

... snip ...

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Gov't coerced Certs thwart SSL/TLS

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Gov't coerced Certs thwart SSL/TLS
Newsgroups: alt.privacy, alt.computer.security
Date: Tue, 30 Mar 2010 14:02:28 -0400
"nemo_outis" <abc@xyz.com> writes:
However, here's another reason why self-signed certificates are not just "equivalent to" but actually "superior to" CA-signed certificates:

re:
http://www.garlic.com/~lynn/2010g.html#10 Gov't coerced Certs thwart SSL/TLS

lots of past posts discussing SSL domain name certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcert

note that Certification Authority digital certificate ... is simply a "self-signed" digital certificate that has been loaded into the browser cache of self-signed Certification Authority digital certificates (the primary difference between any random self-signed digital certificate and a Certification Authority self-signed digital certificate ... is whether or not the self-signed digital certificate has been loaded into the browser cache of Certification Authority self-signed digital certificates).

the PKI-based digital certificate infrastructure is a chain of digital certificates that is rooted at the Certification Authority digital certification ... and it is a "root" because if is self-signed and loaded into browser Certification Authority digital certificate cache.

As previously mentioned, the browser Certification Authority self-signed digital certificate caches have accumulated a large number of "root" certificates ... and browsers make no differentiation between the "roots". A compromised root could bring down the whole infrastructure by issuing "valid" certificates for any and all comers (even for entities that already have digital certificates from other roots).

However, the nature of URLs have gotten quite obfuscated for a large percentage of the population ... so an attacker doesn't even necessarily have to even get a SSL digital certificate (for the original domain name) ... they can obtain a similar domain name (using a valid front company) and then obtain a valid SSL digital certificate. Then they send spam email asking people to click-on their URL (which has a valid SSL). They then set up their website to operate as a MITM (potentially using slightly modified standard proxy code) ... where they run two paird sessions ... one between the end-user and their proxy (using their SSL digital certificate) and a 2nd session with the "real" site (using that organization's SSL digital certificate). They are then able to evesdrop/skim all traffic and/or even modify traffic as necessary. This is slightly less privileged level than getting a valid SSL digital certificate for the original domain name (as opposed to just a similar domain name).

Remember ... with the clicking convention and people paying little attention to the actual URL ... SSL primarily operates to validate that the webserver being talked to is the webserver (aka domain name) that it claims to be (not that the webserver that the user thinks they are talking to is the actual webserver that they are actually talking to).

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Far and near pointers on the 80286 and later

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Far and near pointers on the 80286 and later
Newsgroups: alt.folklore.computers, comp.sys.intel, comp.arch
Date: Tue, 30 Mar 2010 14:28:03 -0400
George Neuner <gneuner2@comcast.net> writes:
Pink wasn't designed with security in mind (Apple was still thinking single user) and it never really materialized anyway. Taligent's OS was more focused on being reliable than being secure.

re:
http://www.garlic.com/~lynn/2010g.html#9 Far and near pointers on the 80286 and later

I did a one week JAD with taligent (there were dozen or so top taligent people in the session and their JAD person) going over what would be required for business critical (both reliable and secure).

the net was approx. 30% hit to the taligent base ... two new frameworks plus hits to the existing frameworks.

However, I believe the taligent security guru was on business trip that week ... visiting some gov. agency on the east coast.

misc. past posts referencing the taligent JAD:
http://www.garlic.com/~lynn/2000e.html#46 Where are they now : Taligent and Pink
http://www.garlic.com/~lynn/2001n.html#93 Buffer overflow
http://www.garlic.com/~lynn/2004p.html#64 Systems software versus applications software definitions
http://www.garlic.com/~lynn/2005i.html#42 Development as Configuration
http://www.garlic.com/~lynn/2007m.html#36 Future of System/360 architecture?
http://www.garlic.com/~lynn/2008b.html#22 folklore indeed
http://www.garlic.com/~lynn/2009m.html#26 comp.arch has made itself a sitting duck for spam

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Far and near pointers on the 80286 and later

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Far and near pointers on the 80286 and later
Newsgroups: alt.folklore.computers, comp.sys.intel, comp.arch
Date: Tue, 30 Mar 2010 14:39:18 -0400
re:
http://www.garlic.com/~lynn/2010g.html#9 Far and near pointers on the 80286 and later
http://www.garlic.com/~lynn/2010g.html#15 Far and near pointers on the 80286 and later

part of it was how to cut the development for reliability and security.

we had been called in to consult with small client/server startup that wanted to do payment transactions on their server. they had some well designed and well tested application code that would handle the transactions. I then a bunch of stuff that I claimed was necessary to take a quality application and turn it into a "service" (aka business critical, 7x24) ... which took nearly ten times the original application effort. It included doing some compensating processes and diagnostic manual for Internet environments.

At the same time there were various milspec security development stuff that were also being required for critical financial infrastructures ... stuff like 2167A ... which also took something like ten times the effort of what might be considered well-designed, well-implemented, well-tested application (and then re-applied for any enhancement/changes).

Part of the JAD was could I take both the security & RAS stuff that was increasing standard application development by a factor of ten times ... and get it down to maybe only 2-3 times.

misc. past posts mentioning business critical being 4-10 times standard development for business critical:
http://www.garlic.com/~lynn/2001f.html#75 Test and Set (TS) vs Compare and Swap (CS)
http://www.garlic.com/~lynn/2001n.html#91 Buffer overflow
http://www.garlic.com/~lynn/2001n.html#93 Buffer overflow
http://www.garlic.com/~lynn/2002n.html#11 Wanted: the SOUNDS of classic computing
http://www.garlic.com/~lynn/2003g.html#62 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003j.html#15 A Dark Day
http://www.garlic.com/~lynn/2003p.html#37 The BASIC Variations
http://www.garlic.com/~lynn/2004b.html#8 Mars Rover Not Responding
http://www.garlic.com/~lynn/2004b.html#48 Automating secure transactions
http://www.garlic.com/~lynn/2004k.html#20 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2004l.html#49 "Perfect" or "Provable" security both crypto and non-crypto?
http://www.garlic.com/~lynn/2004p.html#23 Systems software versus applications software definitions
http://www.garlic.com/~lynn/2004p.html#63 Systems software versus applications software definitions
http://www.garlic.com/~lynn/2004p.html#64 Systems software versus applications software definitions
http://www.garlic.com/~lynn/2005b.html#40 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005i.html#42 Development as Configuration
http://www.garlic.com/~lynn/2005n.html#26 Data communications over telegraph circuits
http://www.garlic.com/~lynn/2006n.html#20 The System/360 Model 20 Wasn't As Bad As All That
http://www.garlic.com/~lynn/2007f.html#37 Is computer history taught now?
http://www.garlic.com/~lynn/2007g.html#51 IBM to the PCM market(the sky is falling!!!the sky is falling!!)
http://www.garlic.com/~lynn/2007h.html#78 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007n.html#10 The top 10 dead (or dying) computer skills
http://www.garlic.com/~lynn/2007n.html#76 PSI MIPS
http://www.garlic.com/~lynn/2007n.html#77 PSI MIPS
http://www.garlic.com/~lynn/2007o.html#23 Outsourcing loosing steam?
http://www.garlic.com/~lynn/2007p.html#54 Industry Standard Time To Analyze A Line Of Code
http://www.garlic.com/~lynn/2007v.html#53 folklore indeed
http://www.garlic.com/~lynn/2008e.html#41 IBM announced z10 ..why so fast...any problem on z 9
http://www.garlic.com/~lynn/2008e.html#50 fraying infrastructure
http://www.garlic.com/~lynn/2008e.html#53 Why Is Less Than 99.9% Uptime Acceptable?
http://www.garlic.com/~lynn/2008i.html#33 Mainframe Project management
http://www.garlic.com/~lynn/2008n.html#20 Michigan industry
http://www.garlic.com/~lynn/2008n.html#35 Builders V. Breakers
http://www.garlic.com/~lynn/2008p.html#48 How much knowledge should a software architect have regarding software security?
http://www.garlic.com/~lynn/2009.html#0 Is SUN going to become x86'ed ??

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Far and near pointers on the 80286 and later

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Far and near pointers on the 80286 and later
Newsgroups: alt.folklore.computers, comp.sys.intel, comp.arch
Date: Tue, 30 Mar 2010 14:53:32 -0400
Anne & Lynn Wheeler <lynn@garlic.com> writes:
At the same time there were various milspec security development stuff that were also being required for critical financial infrastructures ... stuff like 2167A ... which also took something like ten times the effort of what might be considered well-designed, well-implemented, well-tested application (and then re-applied for any enhancement/changes).

re:
http://www.garlic.com/~lynn/2010g.html#9 Far and near pointers on the 80286 and later
http://www.garlic.com/~lynn/2010g.html#15 Far and near pointers on the 80286 and later
http://www.garlic.com/~lynn/2010g.html#16 Far and near pointers on the 80286 and later

wasn't a member ... but did get invited to some of their meetings ... somewhat favorite of mine from their website ... courtesy of the wayback machine:
http://web.archive.org/web/20001018151708/http://www.software.org/quagmire/frampapr/frampapr.html

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

The 2010 Census

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The 2010 Census
Newsgroups: alt.folklore.computers
Date: Tue, 30 Mar 2010 15:25:51 -0400
re:
http://www.garlic.com/~lynn/2010f.html#54 The 2010 Census

note quite word-for-word as opening in the above post ... but the last paragraph in this blog entry is close:
http://baselinescenario.com/2010/03/30/elizabeth-warren-aba/

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

The 2010 Census

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The 2010 Census
Newsgroups: alt.folklore.computers
Date: Tue, 30 Mar 2010 15:37:47 -0400
re:
http://www.garlic.com/~lynn/2010f.html#76 The 2010 Census

and a variation on the musical chairs theme in the above ... mentioned in this blog entry:
http://baselinescenario.com/2010/03/30/geely-buys-volvo-goldman-gets-the-upside-you-get-the-downside/

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

16:32 far pointers in OpenWatcom C/C++

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 16:32 far pointers in OpenWatcom C/C++
Newsgroups: alt.sys.pdp10, alt.folklore.computers
Date: Tue, 30 Mar 2010 17:37:24 -0400
Peter Flass <Peter_Flass@Yahoo.com> writes:
I took OP's "swapping" to mean "paging." I don't think there's a lot of swapping these days. In the auld days Burroughs used to swap, I guess TOPS-10 swapped, and TSO originally used to swap. The primary rationale for swapping is in a timesharing environment where there's typically a long delay waiting for user input. OS/2 version 1.x used to swap to move segments around.

apl\360 would "swap" the whole workspace at a time (but they were typically only 16kbytes-32kbytes). apl's storage allocation and garbage collection would repeatedly touch every byte in a workspace.

moving apl\360 to cms for cms\apl ... eliminated all the tasking, swapping, etc code ... since only needed the apl interpreter ... but the storage allocation and garbage collection played havoc when workspace size became significantly larger in (paged) virtual memory (where it would still rapidly try and still touch every available byte in the workspace). this required a major rework to not having continued page thrashing ... touching every possible virtual page.

recent post mentioning cms\apl:
http://www.garlic.com/~lynn/2010e.html#21 paged-access method

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Fraudsters Can Easily Buy SSL Certificates, Researcher Finds

From: lynn@garlic.com (Lynn Wheeler)
Date: 04 Apr, 2010
Subject: Fraudsters Can Easily Buy SSL Certificates, Researcher Finds
Blog: Payment Systems Network
Fraudsters Can Easily Buy SSL Certificates, Researcher Finds
http://www.ecommercetimes.com/story/69686.html?wlc=1270331064

from above:
The industry-accepted standard for confirming someone is who they say they are and that they control a domain is that 'the CA takes reasonable measures to verify,' which is very ambiguous at best and meaningless at worst,

... snip ...

we had been brought in by a small client/server startup that wanted to do payment transactions on the server ... the startup had also invented this technology called SSL. As part of mapping SSL to payment transactions ... we had to do end-to-end audit/walkthrus of the various business processes ... including some number of these new operations calling themselves Certification Authorities ... that were selling these things called SSL domain name certificates. There were a whole lot of things all along the business process that could be gotchas if not done correctly .... and the whole infrastructure was at risk ... if anyone of these operations didn't always perform flawlessly. misc. past posts mentioning ssl domain name digital certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcert

We had in the past produced some number of high-availability products ... where the infrastructure would be at risk if all the redundant components happened to fail at once. The PKI infrastructure is not a high-availability infrastructure (where the probability of infrastructure failure decreases as the number of redundant components are added), instead the probability of infrastructure failure increases as the number of (non-redundant) components are added.

recent threads mentioning the same theme
http://www.garlic.com/~lynn/2010b.html#5 Happy DEC-10 Day
http://www.garlic.com/~lynn/2010b.html#69 Happy DEC-10 Day
http://www.garlic.com/~lynn/2010b.html#70 Happy DEC-10 Day
http://www.garlic.com/~lynn/2010d.html#43 What was old is new again (water chilled)
http://www.garlic.com/~lynn/2010e.html#50 LPARs: More or Less?
http://www.garlic.com/~lynn/2010f.html#3 Why is Kerberos ever used, rather than modern public key cryptography?
http://www.garlic.com/~lynn/2010f.html#7 What was the historical price of a P/390?
http://www.garlic.com/~lynn/2010f.html#68 But... that's *impossible*
http://www.garlic.com/~lynn/2010f.html#80 Law Enforcement Appliance Subverts SSL
http://www.garlic.com/~lynn/2010g.html#10 Gov't coerced Certs thwart SSL/TLS

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

What is the protocal for GMT offset in SMTP (e-mail) header

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What is the protocal for GMT offset in SMTP (e-mail) header
Newsgroups: comp.mail.misc, alt.folklore.computers, comp.os.linux.advocacy
Date: Sun, 04 Apr 2010 16:57:26 -0400
Peter Köhlmann <peter-koehlmann@t-online.de> writes:
You are in "good" company. MS didn't either

msdc held spring of 1996 at moscone ... there was lots of talk about internet ... but the banners and themes were "preserve your investment" .... basically all the visual basic developers wouldn't be obsoleted (all those automated visual basic scripting things that worked in closed, small, safe business network would be extended to work over the internet ... creating opening for all sorts of happiness in the world today).

we had been called in to consult with small client/server startup that wanted to do payment transactions on their server; they had also invented this technology they called SSL they wanted to use.

part of this was deploying something called payment gateway ... some past posts
http://www.garlic.com/~lynn/subnetwork.html#gateway

in this period the internet backbone was transitioning to hierarchical routing ... there was all the redundant stuff done for the gateway with multiple paths into different parts of the backbone, but the advertising alternate routes went away. That just left client multiple a-record support ... i.e. create dns record with multiple ip-addresses ... and the client code making a connection had to cycle thru the ip-addresses until it got one that worked.

had sign-off authority on the server to payment gateway side ... so the payment webserver to payment gateway was mandated to implement multiple a-record support.

we also consulted with some large early-adopter e-commerce servers about also having multiple backbone connections and a-record with multiple ip addresses (one was large sports operation that was advertising during sunday afternoon football and were expecting big half-time internet activity ... but there were still some ISPs that had rolling outages in different cities on sundays for maintenance activity; browser multiple a-record support would be only countermeasure to getting caught by ISP planned outage).

the problem was the browser developers ... when i said they had to also implement multiple a-record support (when browser connecting to webserver) ... the came back with it was "too advanced" (i.e. possibly hadn't been taught in standard univ. course). i did some detailed tutorials and provided example client code from serveral year old 4.3 tahoe distribution. still no budging (i didn't have final approval on what the browser group shipped)

at moscone ... it turns out that redmond had hired some old hands ... and not just recent college graduates ... and they had done full multiple a-record support in their browser. it was maybe another year ... before the small client/server startup had multiple a-record support in their browser.

jim was there ... they had opened the san fran research center and i got invited over for open house that they were running during msdc.
http://web.archive.org/web/20081115000000*/http://research.microsoft.com/en-us/um/people/gray/

nearly decade later jim badgered me into interviewing for chief security architect in redmond ... "interview" went on for 2-3 weeks but we never could come to aggreement.

misc posts about celebration for jim held at berkeley
http://www.garlic.com/~lynn/2003j.html#22 why doesn't processor reordering instructions affect most
http://www.garlic.com/~lynn/2004c.html#40 Microprocessor History Site
http://www.garlic.com/~lynn/2008i.html#32 A Tribute to Jim Gray: Sometimes Nice Guys Do Finish First
http://www.garlic.com/~lynn/2008i.html#36 A Tribute to Jim Gray: Sometimes Nice Guys Do Finish First
http://www.garlic.com/~lynn/2008i.html#50 Microsoft versus Digital Equipment Corporation
http://www.garlic.com/~lynn/2008i.html#51 Microsoft versus Digital Equipment Corporation
http://www.garlic.com/~lynn/2008p.html#27 Father Of Financial Dataprocessing
http://www.garlic.com/~lynn/2009m.html#78 ATMs by the Numbers
http://www.garlic.com/~lynn/2009o.html#51 8 ways the American information worker remains a Luddite
http://www.garlic.com/~lynn/2009r.html#4 70 Years of ATM Innovation

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Interesting presentation

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Interesting presentation
Newsgroups: comp.arch
Date: Mon, 05 Apr 2010 08:20:15 -0400
"Del Cecchi" <delcecchi@gmail.com> writes:
If you are expecting to be moving stuff back and forth to disk anyway, why not dust off the S/38 idea and use disk for main memory, with dram "main memory" as a cache? Works well with very large virtual addresses, like those of 64 bits.

folklore that s/38 deployed very early RAID because all disks were treated as common allocation pool with scatter allocation across disks.

system required complete back up of all disks ... and then restore of all disks .... which could take a very long time ... for single disk failure ... or bad area on disk.

one of the guys i worked with in sj disk engineering got patent on raid ... a decade before the term raid ... misc. past refs:
http://www.garlic.com/~lynn/2006d.html#1 Hercules 3.04 announcement
http://www.garlic.com/~lynn/2006p.html#47 "25th Anniversary of the Personal Computer"
http://www.garlic.com/~lynn/2007t.html#72 Remembering the CDC 6600
http://www.garlic.com/~lynn/2009e.html#44 Architectural Diversity
http://www.garlic.com/~lynn/2009s.html#33 Larrabee delayed: anyone know what's happening?

there was tss/360 and multics that were memory mapped ... which FS adopted some features of ... and when FS was killed ... folklore was various people retreated to rochester to do s/38
http://www.garlic.com/~lynn/submain.html#futuresys

i did memory mapped filesystem for cms (that was never released) ... drawing on some number of things that i saw tss/360 do wrong.
http://www.garlic.com/~lynn/submain.html#mmap

for other drift ... some details about FS
http://www.jfsowa.com/computer/memo125.htm

other pieces in this thread
http://www.garlic.com/~lynn/2010g.html#42 Interesting presentation
http://www.garlic.com/~lynn/2010g.html#43 Interesting presentation

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

What is the protocal for GMT offset in SMTP (e-mail) header

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What is the protocal for GMT offset in SMTP (e-mail) header
Newsgroups: comp.mail.misc, alt.folklore.computers
Date: Mon, 05 Apr 2010 16:21:50 -0400
Quadibloc <jsavard@ecn.ab.ca> writes:
Dial-up access to mainframes certainly existed back then; I know, for example, that there was dial-up access to the IBM 360/67 and later the Amdahl 470 V/6 at the university where I studied. That's not the same, though, as general public utilities, rather than a computer for the use of students and faculty at one college or employees of one

national css (on 360/67) kicked off something 1st week jun68. The univ. was sending me to an ibm one week class taught by people from cambridge science center ... at beverly hills hilton(?)

i got down there ... & monday morning and it turned out that person teaching much of the class had given notice the friday before that he was leaving to join ncss (and so wouldn't be teaching) ... and i was asked to teach part of his material. misc. past posts mentioning science center
http://www.garlic.com/~lynn/subtopic.html#545tech

misc. ncss history
http://corphist.computerhistory.org/corphist/view.php?s=select&cid=4
http://corphist.computerhistory.org/corphist/view.php?s=themes&id=32
http://corphist.computerhistory.org/corphist/view.php?s=events&id=323

above ... service began with 2week free trial dec68 ... first day charge for services was 16dec68.

http://corphist.computerhistory.org/corphist/view.php?s=events&id=326

i assume some stuff mentioned in above may have been similar to things i had done in 68 and reported on at fall68 share meeting in Atlantic City ... old reference:
http://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14

and other stuff referenced here (including work on page replacement in the 60s somewhat landed me in middle of academic dispute in the 80s)
http://www.garlic.com/~lynn/2010g.html#22 Mainframe Executive article on the death of tape

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

someone smarter than Dave Cutler

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: someone smarter than Dave Cutler
Newsgroups: alt.folklore.computers, alt.sys.pdp10
Date: Mon, 05 Apr 2010 16:27:40 -0400
Pat Farrell <pfarrell@pfarrell.com> writes:
Perhaps within DEC. We never were big users of listings for programs. Perhaps because the developers were five or so blocks from the data center were the printers were.

We did live on our VT52s and VT100s. The systems folks lived on their microfiche readers.


reference to office at home in later part of 70s ... with cdi miniterm and microfiche viewer ... ref'ed in these past posts (with couple pictures):
http://www.garlic.com/~lynn/2008m.html#38 Baudot code direct to computers?
http://www.garlic.com/~lynn/2008m.html#51 Baudot code direct to computers?
http://www.garlic.com/~lynn/2009e.html#30 Timeline: 40 years of OS milestones
http://www.garlic.com/~lynn/2009g.html#45 Netbooks: A terminal by any other name

old pictures
http://www.garlic.com/~lynn/lhwemail.html#oldpicts

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

What is the protocal for GMT offset in SMTP (e-mail) header

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What is the protocal for GMT offset in SMTP (e-mail) header
Newsgroups: alt.folklore.computers
Date: Mon, 05 Apr 2010 18:55:46 -0400
Mel <mwilson@the-wire.com> writes:
The big local Toronto ISP, Canada Remote Systems joined the Internet around then. Before that it was local boards and FidoNet. They contrapted a gateway from the BBS accounts to the Net to handle e-mail and Usenet. I was saying silly things on comp.lang.scheme as early as 1992. As long as my access was dialup, the Web was very little use. Sessions had to be pre-planned so as not to pre-empt the telephone for too long. That ruled out surfing ad libitum.

very quickly got a corporate line at home to avoid tieing up personal line.

after leaving in '92 ... get shell account at netcom (and some number of other places). in '93 got a gig to do pagesat drivers for some machines and article in boardwalk magazine ... for their satellite usenet distribution.

had a 486 clone at home running dos and waffle
http://www.faqs.org/faqs/waffle-faq/

... as well as a unix machine or two.

old references (along w/picture of satellite dish in backyard)
http://www.garlic.com/~lynn/2001h.html#66 UUCP email
http://www.garlic.com/~lynn/2005l.html#20 Newsgroups (Was Another OS/390 to z/OS 1.4 migration
http://www.garlic.com/~lynn/2009j.html#19 Another one bites the dust
http://www.garlic.com/~lynn/2009l.html#21 Disksize history question

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Interesting presentation

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Interesting presentation
Newsgroups: comp.arch
Date: Mon, 05 Apr 2010 23:22:02 -0400
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
The first machine with virtual memory was the Atlas, where a fixed-point register add took 1.59 microseconds according to <https://en.wikipedia.org/wiki/Atlas_Computer>. The page does not tell how fast the drum store (used for secondary storage) was, but the drums were bigger and rotated slower than today's disk drives. E.g., <https://en.wikipedia.org/wiki/IBM_System/360> mentions the IBM 2301, which had 3500rpm. If the (earlier) Atlas drum rotated at the same speed, we get a rotational latency of 8571 microseconds, i.e., 5391 instructions. To that add the time to read in the page (a full rotation would be 10782 instructions, but maybe they could store more than one page per track, and thus have faster read times). Later mainframe paging probably had similar speed ratios.

as recently mentioned in different mailing list/thread ....
http://www.garlic.com/~lynn/2010g.html#22 Mainframe Executive article on the death of tape

original cp67 just did single page transfer per i/o ... so 2301 would saturate at about 80 page/sec. i redid several things in cp67 ... including chaining multiple page transfers in single i/o ... chaining in rotational order. this resulted in still half rotational delay per i/o ... but tended to be amortized over several page transfers. this resulted in being able to drive 2301 up to nearly 300 page transfers per second (each i/o took longer ... but the queue delay was significantly reduced under heavy load ... since it had almost four times the peak thruput).

as an aside ... 2301 drum and 2303 drum were very similar ... except 2301 would read/write four heads in parallel ... getting four times the data transfer rate (and track sizes were four time largers ... but only 1/4 the number of tracks).

so the old/original service time/latency was essentially 1/80th second (13mills). with chained requests ... the service time increases because of doing multiple transfers per i/o ... but avg. service time becomes approx. 1/300th second (3mills).

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Interesting presentation

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Interesting presentation
Newsgroups: comp.arch
Date: Tue, 06 Apr 2010 09:07:43 -0400
EricP <ThatWouldBeTelling@thevillage.com> writes:
I vaguely recall someone telling me that 370 VM had a page file defragger process that would coalesce pages for long running processes so they were contiguous in the page file, to facilitate multi page read ahead without multiple seeks.

Does any of that sound familiar to you?


"big pages" ... discussion/description in this recent post (done for both mvs & vm in the 80s)
http://www.garlic.com/~lynn/2010g.html#23 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010g.html#42 Interesting presentation

basically attempting to tailor paging to operational characteristics of 3380 disk drive ... part of it was analogous to log-structured filesystems ... sort of moving cursor across drive with writes to empty track that was closest to the current cursor position. one or more drives ... and wanted available (big page 3380) page space possibly ten times larger than expected use ... so that leading edge of cursor was empty as possible.

re:
http://www.garlic.com/~lynn/2010g.html#71 Interesting presentation

as to 2301 ... it was formated 9 4k pages per pair of tracks ... with page "5" spanning the end of one track and the start of the next. at 60revs/sec ... peak sustained was actually 270 page transfers/sec.

some regression analysis associated 1.5mills cpu per page fault/read ... that is fault, page replacement algorithm, some fraction of page write (when selected replaced page was changed and had to be written), marking current task non-executable, task switch, later i/o interrupt, processing, and switch back to faulting task. somewhere between 500-700 instructions.

cp67 avg. behavior had ratio of 3 reads per write (so 1/3rd of page write overhead was attributed to each read).

in the initial simplification morph from cp67 to vm370 ... a lot of stuff i had done for cp67 as undergraduate was dropped (some amount of paging, paging algorithms, dispatching algorithms, "fastpath" for common executed instruction paths, etc. some of the fastpath stuff leaked backin late in vm370 release1 (plc9).

there is this reference to doing major migration of remaining cp67 changes to (internal) vm370 ... and doing internal product distribution as "csc/vm"
http://www.garlic.com/~lynn/2006v.html#email731212
http://www.garlic.com/~lynn/2006w.html#email750102
http://www.garlic.com/~lynn/2006w.html#email750430

a small subset of the virtual memory management changes leaked back into the product for vm370 release 3.

i was then asked to do a separately charged kernel product for some of the remaining changes ... resource management algoritms, some newer paging stuff, etc.
http://www.garlic.com/~lynn/subtopic.html#fairshare

some of the newer paging stuff included a background sweeper task that would pull low-active pages off drum and move them to disk (increasing the effective use of the relative small capacity, faster paging device).

the big pages stuff somewhat traded off i/o capacity and real storage ... attempting to have 3380 approx. lower latency fixed head device (attempting to minimize penalty of disk arm motion ... partially be forcing the overhead to be always amortized for a ten page transfer).

some of the "big page" was motivated by no longer having a "corporate" paging device product ... some recent discussion and old email
http://www.garlic.com/~lynn/2010g.html#11 Mainframe Executive article on the death of tape
http://www.garlic.com/~lynn/2010g.html#22 Mainframe Executive article on the death of tape
http://www.garlic.com/~lynn/2010g.html#55 Mainframe Executive article on the death of tape

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Interesting presentation

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Interesting presentation
Newsgroups: comp.arch
Date: Tue, 06 Apr 2010 15:50:50 -0400
re:
http://www.garlic.com/~lynn/2010g.html#72 Interesting presentation

w/o bigpage ... pages retained "home" location on disk after being brought into storage (if page was later selected for replacement and hadn't been changed ... it avoided disk write since home location hadn't gone stale)

with bigpage, there was no longer home location on disk ... whenever a full-track bigpage was read into storage ... the corresponding disk track was released. subsequent replacement would require a write (since there was no copy retained on disk). this effectively drove up writes ... effectively a write for every replaced page ... to make room for a read (just another example of trading off transfer capacity as part of optimizing 3380 moveable arm bottleneck for paging device.
http://www.garlic.com/~lynn/2010g.html#23 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010g.html#42 Interesting presentation
http://www.garlic.com/~lynn/2010g.html#72 Interesting presentation

this is somewhat a variation on the dup/no-dup trade-off (i.e. maintaining duplicate copy on disk when page was resident in processor memory). this shows up when preferred paging storage becomes relative small compared to real storage size (and/or total allocated virtual memory).

this shows up more recently when some machine configurations had gbyte real-storage and relatively small multi-gbyte disks ... where space for paging was limited ... trade-off between total virtual pages being limited by available space on disk (duplicate) ... or available space on disk plus real storage (no-duplicates). A 2gbyte paging space and 1gbyte real storag e... might be able to handle 3gbyte total virtual pages in no-dup strategy.

i had also added some code to vm370 (besides the fixed-head paging device cleaner/sweeper) that would switch from duplicate stragegy to no-duplicate stragegy when fixed-head paging device space became especially constrained (do sweep/clean ... and then start non-duplicate for fixed-head paging device ... but typically retained duplicate for much larger paging areas on regular disks).

misc. past posts mentioning dup/no-dup stragegies:
http://www.garlic.com/~lynn/93.html#13 managing large amounts of vm
http://www.garlic.com/~lynn/2000d.html#13 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2001i.html#42 Question re: Size of Swap File
http://www.garlic.com/~lynn/2001l.html#55 mainframe question
http://www.garlic.com/~lynn/2002b.html#10 hollow files in unix filesystems?
http://www.garlic.com/~lynn/2002b.html#20 index searching
http://www.garlic.com/~lynn/2002e.html#11 What are some impressive page rates?
http://www.garlic.com/~lynn/2002f.html#20 Blade architectures
http://www.garlic.com/~lynn/2002f.html#26 Blade architectures
http://www.garlic.com/~lynn/2003f.html#5 Alpha performance, why?
http://www.garlic.com/~lynn/2004g.html#17 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#18 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#20 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004h.html#19 fast check for binary zeroes in memory
http://www.garlic.com/~lynn/2004i.html#1 Hard disk architecture: are outer cylinders still faster than inner cylinders?
http://www.garlic.com/~lynn/2005c.html#27 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005m.html#28 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2006c.html#8 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006f.html#18 how much swap size did you take?
http://www.garlic.com/~lynn/2007c.html#0 old discussion of disk controller chache
http://www.garlic.com/~lynn/2008f.html#19 Fantasy-Land_Hierarchal_NUMA_Memory-Model_on_Vertical
http://www.garlic.com/~lynn/2008k.html#80 How to calculate effective page fault service time?

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Unknown SSL credential could imperil Firefox, Mac users

From: lynn@garlic.com (Lynn Wheeler)
Date: 06 Apr, 2010
Subject: Unknown SSL credential could imperil Firefox, Mac users
Blog: Financial Crime Risk, Fraud and Security
Unknown SSL credential could imperil Firefox, Mac users
http://www.theregister.co.uk/2010/04/06/mysterious_mozilla_apple_certificate/

from above:
Mozilla web browsers and email programs and the Mac operating system contain a root authentication credential with unknown origins, a disturbing discovery that underscores the shaky foundation on which internet security is built

... snip ...

Another example of how commonly deployed PKI is not an high-availability infrastructure; aka instead of improving as number of redundant components increase ... it is an example of how the risk of failure increases as the number of components increase

other recent refs:
http://www.garlic.com/~lynn/2010f.html#71 Law Enforcement Appliance Subverts SSL
http://www.garlic.com/~lynn/2010f.html#80 Law Enforcement Appliance Subverts SSL
http://www.garlic.com/~lynn/2010g.html#10 Gov't coerced Certs thwart SSL/TLS
http://www.garlic.com/~lynn/2010g.html#14 Gov't coerced Certs thwart SSL/TLS
http://www.garlic.com/~lynn/2010g.html#54 Gov't coerced Certs thwart SSL/TLS
http://www.garlic.com/~lynn/2010g.html#58 Gov't coerced Certs thwart SSL/TLS
http://www.garlic.com/~lynn/2010g.html#65 Fraudsters Can Easily Buy SSL Certificates, Researcher Finds

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

What is the protocal for GMT offset in SMTP (e-mail) header header time-stamp?

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What is the protocal for GMT offset in SMTP (e-mail) header header time-stamp?
Newsgroups: microsoft.public.mail.misc, comp.mail.misc, comp.os.ms-windows.advocacy, alt.folklore.computers
Date: Wed, 07 Apr 2010 09:52:25 -0400
Morten Reistad <first@last.name> writes:
This was the biggest fight in the history of the Internet, and the good guys won. That was NOT the federal institutions, but around 30 entrepreneurial corporations.

a subtheme was the big telcos ... who had huge amount of bandwidth capacity (a lot of dark fiber had gone by the early 80s) ... but had never figured out non-disruptive transission ... they had huge fixed costs & there was big chicken&egg problem. There wasn't going to be the new bandwidth hungry applications w/o radically reduced charges ... and they couldn't radically reduce charges w/o having new bandwidth hungry applications (just starting out by reducing price could mean that they operate in the red for a decade until the new apps appeared).

NSFNET backbone RFP went for $11.2m ... but there have been comments that commercial interests contributed/provisioned at least four times that. The scenario was that the significant available bandwidth and resources would be a technology incubator for new generation of bandwidth hungry applications ... while the "no-commercial use" provisions would make sure that there wasn't any lost commercial revenue.

also the new generation of entrepreneurial companies didn't have the huge existing legacy fixed cost infrastructure (and having to worry about revenue stream to support those costs).

misc. old email related to NSFNET
http://www.garlic.com/~lynn/lhwemail.html#nsfnet

and old posts
http://www.garlic.com/~lynn/subnetwork.html#nsfnet

we had internal high-speed backbone with T1 and higher-speed links and having a lot of interactions with the various parties that would be in NSFNET. We could even claim that our example of T1 links contributed to T1 being specified in the NSFNET backbone RFP.

However (as in some of the email), we were then not allowed to bid on the NSFNET backbone RFP. The director of NSF wrote a letter to the corporation trying to help ... but that just aggravated the internal politics. The winning bid didn't actually put in T1 links ... they installed 440kbit links ... and then possibly to somewhat look like meeting the letter of the RFP ... installed T1 trunks with telco multiplexors running multiple 440kbit links over the T1 trunks (and calling it a T1 network). We made somewhat sarcastic comments that possibly some of the T1 trunks were, in-turn, multiplexed over telco T5 trunks ... so why couldn't they call it a T5 network.

For the round-two RFP ... upgrading NSFNET backbone to T3 ... I got asked to be the red-team (possibly to shutdown some of the sarcastic comments). Something like 30 people from 7 labs around the world were the blue team. At the review ... I got to present first, followed by the blue team. However, five minutes into the blue team presentation ... the person running the review ... pounded on the table and said that he would lie down in front of a garbage truck before allowing any but the blue team proposal to go forward.

another subtheme going on in parts of the gov. was the GOSIP mandate, basically eliminate TCP/IP and replace it with OSI.

I have some number of NSFNET and other academic network "acceptable use policies" ... NSFNET


<NIS.NSF.NET> [NSFNET] NETUSE.TXT

Interim                                              3 July 1990
NSFNET
Acceptable Use Policy

The purpose of NSFNET is to support research and education in and
among academic institutions in the U.S. by providing access to unique
resources and the opportunity for collaborative work.

This statement represents a guide to the acceptable use of the NSFNET
backbone. It is only intended to address the issue of use of the
backbone. It is expected that the various middle level networks will
formulate their own use policies for traffic that will not traverse
the backbone.

(1) All use must be consistent with the purposes of NSFNET.

(2) The intent of the use policy is to make clear certain cases
       which are consistent with the purposes of NSFNET, not to
exhaustively enumerate all such possible uses.

(3) The NSF NSFNET Project Office may at any time make
       determinations that particular uses are or are not
consistent with the purposes of NSFNET. Such determinations
       will be reported to the NSFNET Policy Advisory Committee
and to the user community.

(4) If a use is consistent with the purposes of NSFNET, then
       activities in direct support of that use will be considered
consistent with the purposes of NSFNET. For example,
       administrative communications for the support infrastructure
needed for research and instruction are acceptable.

(5) Use in support of research or instruction at not-for-profit
       institutions of research or instruction in the United States
is acceptable.

(6) Use for a project which is part of or supports a research or
instruction activity for a not-for-profit institution of
research or instruction in the United States is acceptable,
       even if any or all parties to the use are located or
employed elsewhere. For example, communications directly
       between industrial affiliates engaged in support of a
project for such an institution is acceptable.

(7) Use for commercial activities by for-profit institutions is
       generally not acceptable unless it can be justified under
(4) above. These should be reviewed on a case-by-case basis
       by the NSF Project Office.

(8) Use for research or instruction at for-profit institutions
may or may not be consistent with the purposes of NSFNET,
       and will be reviewed by the NSF Project Office on a
case-by-case basis.

... snip ...

misc. past posts mentioning academic network "acceptable use policy"
http://www.garlic.com/~lynn/2000c.html#26 The first "internet" companies?
http://www.garlic.com/~lynn/2000d.html#59 Is Al Gore The Father of the Internet?
http://www.garlic.com/~lynn/2000e.html#5 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2000e.html#29 Vint Cerf and Robert Kahn and their political opinions
http://www.garlic.com/~lynn/2000e.html#31 Cerf et.al. didn't agree with Gore's claim of initiative.
http://www.garlic.com/~lynn/2001.html#73 how old are you guys
http://www.garlic.com/~lynn/2002g.html#40 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002h.html#5 Coulda, Woulda, Shoudda moments?
http://www.garlic.com/~lynn/2006j.html#34 Arpa address
http://www.garlic.com/~lynn/2006j.html#45 Arpa address
http://www.garlic.com/~lynn/2006j.html#46 Arpa address
http://www.garlic.com/~lynn/2007l.html#67 nouns and adjectives
http://www.garlic.com/~lynn/2008e.html#45 1975 movie "Three Days of the Condor" tech stuff
http://www.garlic.com/~lynn/2008m.html#92 Blinkylights

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

What is the protocal for GMT offset in SMTP (e-mail) header header time-stamp?

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What is the protocal for GMT offset in SMTP (e-mail) header header time-stamp?
Newsgroups: microsoft.public.mail.misc, comp.mail.misc,  comp.os.ms-windows.advocacy, alt.folklore.computers
Date: Wed, 07 Apr 2010 11:21:33 -0400
re:
http://www.garlic.com/~lynn/2010g.html#66 What is the protocal for GMT offset in SMTP (e-mail) header
http://www.garlic.com/~lynn/2010g.html#68 What is the protocal for GMT offset in SMTP (e-mail) header
http://www.garlic.com/~lynn/2010g.html#70 What is the protocal for GMT offset in SMTP (e-mail) header
http://www.garlic.com/~lynn/2010g.html#75 What is the protocal for GMT offset in SMTP (e-mail) header header time-stamp?

some long winded discussion

The Internet Crucible v2.1 3jan90
http://www.ietf.org/mail-archive/web/ietf/current/msg00262.html

and i have previously posted v1.1 aug89 (including mention of "network service provider"):
http://www.garlic.com/~lynn/2000e.html#19 Is Al Gore The Father of the Internet?

the above mentions "long-term solutions" and dealing with the economic considerations.

other past posts in the same thread
http://www.garlic.com/~lynn/2000d.html#56 Is Al Gore The Father of the Internet?
http://www.garlic.com/~lynn/2000d.html#58 Is Al Gore The Father of the Internet?
http://www.garlic.com/~lynn/2000d.html#59 Is Al Gore The Father of the Internet?
http://www.garlic.com/~lynn/2000d.html#63 Is Al Gore The Father of the Internet?
http://www.garlic.com/~lynn/2000d.html#67 Is Al Gore The Father of the Internet?
http://www.garlic.com/~lynn/2000d.html#77 Is Al Gore The Father of the Internet?
http://www.garlic.com/~lynn/2000e.html#5 Is Al Gore The Father of the Internet?
http://www.garlic.com/~lynn/2000e.html#10 Is Al Gore The Father of the Internet?
http://www.garlic.com/~lynn/2000e.html#11 Is Al Gore The Father of the Internet?
http://www.garlic.com/~lynn/2000e.html#18 Is Al Gore The Father of the Internet?
http://www.garlic.com/~lynn/2000e.html#20 Is Al Gore The Father of the Internet?
http://www.garlic.com/~lynn/2000e.html#28 Is Al Gore The Father of the Internet?

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

IBM responds to Oracle's Exadata with new systems

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com (Lynn Wheeler)
Date: 07 Apr, 2010
Subject: IBM responds to Oracle's Exadata with new systems
Blog: Greater IBM
IBM responds to Oracle's Exadata with new systems
http://www.computerworld.com/s/article/9174967/IBM_responds_to_Oracle_s_Exadata_with_new_systems

from above:
IBM on Wednesday announced a new range of integrated systems for large-scale data analysis, mounting a fresh challenge to rival Oracle's Exadata platform. The offerings include the pureScale Application System as well as Smart Analysis

... snip ...

related references from last year:

http://www.garlic.com/~lynn/2009p.html#43 From The Annals of Release No Software Before Its Time
http://www.garlic.com/~lynn/2009p.html#46 From The Annals of Release No Software Before Its Time
http://www.garlic.com/~lynn/2009p.html#49 big iron mainframe vs. x86 servers
http://www.garlic.com/~lynn/2009p.html#54 big iron mainframe vs. x86 servers

referencing

DB2 announces technology that trumps Oracle RAC and Exadata
http://freedb2.com/2009/10/10/for-databases-size-does-matter/

and

IBM pureScale Technology Redefines Transaction Processing Economics. New DB2 Feature Sets the Bar for System Performance on More than 100 IBM Power Systems
http://www-03.ibm.com/press/us/en/pressrelease/28593.wss

more recent reference:

http://www.garlic.com/~lynn/2010g.html#35 Intel Nehalem-EX Aims for the Mainframe

referencing:

IBM goes elephant with Nehalem-EX iron; Massive memory for racks and blades
http://www.theregister.co.uk/2010/04/01/ibm_xeon_7500_servers

from above:
With so much of its money and profits coming from big Power and mainframe servers, you can bet that IBM is not exactly enthusiastic about the advent of the eight-core "Nehalem-EX" Xeon 7500 processors from Intel and their ability to link up to eight sockets together in a single system image. But IBM can't let other server makers own this space either, so it had to make some tough choices.

... snip ...

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

memory latency, old and new

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: memory latency, old and new
Newsgroups: alt.folklore.computers
Date: Wed, 07 Apr 2010 20:56:42 -0400
paul c <toledobythesea@oohay.ac> writes:
I see that the modern consumer processors have run at speeds that are four or so times faster than the typical memory. How does that ratio compare to the s/360's or s/370's, for that matter how do the latter compare?

360/67 didn't have processor cache.

360/67 had base memory access of 750ns ... fetching a double word at a time ... instruction timings from 360/67 functional characteristics includes prorated portion of that 750ns (i.e. 750/4 for 2byte instructions, 750/2 for 4byte instructions, etc).
http://bitsavers.org/pdf/ibm/360/funcChar/

lots of detailed instruction timing in the various model specific functional characteristic

virtual memory associated array ... did hardware virtual memory translation ... added 150ns to memory access; so when running in virtual translation mode was 900ns ... and adjusted all the instruction timings accordingly.

that was for basic single processor mode. memory bus was shared between processor and (i/o) channel processor ... heavy i/o activity would degrade processor thruput because of memory bus contention.

they did additional memory bus design for multiprocessor operation ... with multi-ported memory bus ... countermeasure to memory bus contention between processors and i/o channel activity. the multi-ported design also added fixed additional latency to memory bus accesses (but minimized memory bus contention ... even a single processor configuration with the multi-ported ... had the extra latency ... but could have higher thruput than traditional single processor because of reduced memory bus contention with i/o).

360/65 was similar to 360/67 ... but w/o the virtual memory option ... and multiprocessor 360/65 didn't have redesigned multi-ported memory (to reduce contention). single processor 360/67 would effectively operate as 360/65 w/o invoking virtual memory operation.

total latency for storage/register add instruction (add value in storage to register contents) would have two storage access (750ns each or 1.5ms plus instruction processing time). the calculations for the (4-byte) add instruction is based on assuming that only 1/2 the 750ns double word instruction fetch is used in the timing calculations ... i.e. 375ns+750ns for 1125ns ... plus processing time for the instruction ... for 1.5ms.

360/75 used same 750ns but interleaved memory bank access and instruction implementation was "hard-wired" instead of 360/65 microcode.

modern processors can have processor caches (to help compensate for memory access latency ... ratio between processor thruput and memory speed. they also can have pipelining and out-of-order execution (to allow overlapped execution of other instructions when instruction is stalled because of cache miss).

this is from somebody's recent post in comp.arch:

http://software.intel.com/sites/products/collateral/hpc/vtune/performance_analysis_guide.pdf

Table 2
Data Source Latency
L3 CACHE hit, line unshared ~40 cycles
L3 CACHE hit, shared line in another core ~65 cycles
L3 CACHE hit, modified in another core ~75 cycles
remote L3 CACHE ~100-300 cycles
Local Dram ~60 ns
Remote Dram ~100 ns

L1 and L2 cache latencies are apparently 4 cycles and 10 cycles, respectively.


... snip ...

so 360/65 memory bus and processor was same 750ns cycle (about .5mip machine modulo heavy i/o memory bus contention). current memory is little bit better than ten times faster. my (older) 1.7ghz is 3389 bogomips. my (newer) 3.2ghz is 6400 bogomips (but 4core, so aggregate is four times that).

... random description from the web
http://pix.cs.olemiss.edu/csci423/latency

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

In SSL We Trust? Not Lately

Refed: **, - **, - **, - **, - **
From: lynn@garlic.com (Lynn Wheeler)
Date: 08 Apr, 2010
Subject: In SSL We Trust? Not Lately
Blog: Financial Crime Risk, Fraud and Security
In SSL We Trust? Not Lately
http://www.darkreading.com/blog/archives/2010/04/trust_in_ssl_st.html

from above:
In the past two weeks we have seen multiple problems with SSL, which is used in our Web browsers to protect the privacy and integrity of our electronic transactions. Earlier this week there was a report on a digital certificate in Firefox's certificate store that nobody could account for.

... snip ...

we had been called in to consult with small client/server startup that wanted to do payment transactions and they had invented this technology called SSL they wanted to use. As part of applying the technology to business process we also did walk thru of these new business operations calling themselves "Certification Authorities" ... as well as some requirements regarding deployment and use. Almost immediately various of the requirements were ignored. Somewhat as a result, very early I coined the term merchant comfort certificates to describe the situation ... i.e. not used to provide security but used to provide a sense of comfort. Past posts mentioning SSL (merchant comfort) certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

part of the old extended merchant comfort certificate thread ... then gets into infrastructure improvements for DNS (because the root of issuing SSL certificate is verifying that the domain name certificate applicant is the same as registered in the DNS database as the true owner of the domain). Part of the issue with the infrastructure improvements for DNS could go a long ways towards eliminating the need for SSL domain name certificates ... quite a catch22 for the Certification Authority industry
http://www.garlic.com/~lynn/subpubkey.html#catch22

some recent references:
http://www.garlic.com/~lynn/2010g.html#10 Gov't coerced Certs thwart SSL/TLS
http://www.garlic.com/~lynn/2010g.html#14 Gov't coerced Certs thwart SSL/TLS
http://www.garlic.com/~lynn/2010g.html#29 someone smarter than Dave Cutler
http://www.garlic.com/~lynn/2010g.html#54 Gov't coerced Certs thwart SSL/TLS
http://www.garlic.com/~lynn/2010g.html#58 Gov't coerced Certs thwart SSL/TLS
http://www.garlic.com/~lynn/2010g.html#65 Fraudsters Can Easily Buy SSL Certificates, Researcher Finds
http://www.garlic.com/~lynn/2010g.html#66 What is the protocal for GMT offset in SMTP (e-mail) header
http://www.garlic.com/~lynn/2010g.html#74 Unknown SSL credential could imperil Firefox, Mac users

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

What is the protocal for GMT offset in SMTP (e-mail) header time-stamp?

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What is the protocal for GMT offset in SMTP (e-mail) header time-stamp?
Newsgroups: comp.mail.misc, alt.folklore.computers, comp.os.linux.advocacy,  comp.os.ms-w
Date: Thu, 08 Apr 2010 16:12:15 -0400
starwars <nonscrivetemi@tatooine.homelinux.net> writes:
That's true, but even 30 years ago there were multi-engine mainframes and OS support and software exploitation. It's just that CICS was so efficient at dispatching work it didn't really need more than one engine to support even very large networks of let's say 30 - 50 thousand terminal users. Let's see ANY PC or server box do that even today.

CICS shortcut the overhead of having to coordinate multiprocessor operation.

long ago and far away when I was undergraduate in the 60s, the univ. library got an ONR grant to do online catalog; some of the money went for a 2321 datacell to hold all the data ... a couple datacell refs:
http://www.columbia.edu/cu/computinghistory/datacell.html
http://www-03.ibm.com/ibm/history/exhibits/storage/storage_2321.html

the effort also got selected to be betatest for original cics product (i.e. CICS had originally been developed at a customer operation and then selected to become a corporate released product). I got tasked with supporting/debugging the CICS deployment for the library.

w/o multiprocessing and some other scaleup support ... just highly efficient in doing very lightweight tasks ... large installations would deploy multiple (independent) cics regions (for scaleup). I was in a datacenter a decade ago that did a lot of outsourcing (including dataprocessing for nearly all of the cable tv companies in the country; billing, statement, customer support terminals, commands to settop boxes) ... and they had some banner about running something like 125 CICS "regions".

recent CICS related posting in mainframe mailing list
http://www.garlic.com/~lynn/2010c.html#47 Extracting STDOUT data from USS

referenced in above:

The Evolution of CICS: CICS and Multi-region Operation (1980)
http://web.archive.org/web/20040705000349/http://www.yelavich.com/history/ev198001.htm

The Evolution of CICS: CICS and Multiprocessor Exploitation (2004)
http://web.archive.org/web/20041023110006/http://www.yelavich.com/history/ev200402.htm

from above:
CICS chose to provide for a multi-tasking environment under a single Task Control Block (TCB) using its own dispatcher (Task Control Program) rather than attempt to multi-task concurrent transaction processing using operating system subtasks. Not only was the overhead of operating system subtasking considered excessive, but having concurrently dispatched applications would have required programs to be reentrant and serialize their use of shared resources. That was felt to be too complicated at the time.

... snip ...

some other past posts mentioning cics (&/or bdam)
http://www.garlic.com/~lynn/submain.html#bdam

note that charlie invented compare&swap (CAS chosen because it is charlie's initials) instruction when he was doing work on fine-grain cp67 kernel locking at the science center ... some past posts mentioning science center
http://www.garlic.com/~lynn/subtopic.html#545tech

there then was attempt to get compare&swap including in the 370 architecture ... but was initially rebuffed (because the favorite son operating system claimed that test&set from 360 days, was sufficient for kernel multiprocessor operation). in order to have compare&swap included in 370 architecture, the challenge was to come up for a use for the instruction that wasn't strictly for kernel multiprocessor operation. thus was born the description of its use for multithread operation (whether in single processor or multiprocessor environment). The example descriptions was included in the 370 principles of operation and continues in the current principles of operation.
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dz9zr003/A.6?DT=20040504121320

misc. past posts mentioning multiprocessor and/or compare&swap
http://www.garlic.com/~lynn/subtopic.html#smp

in the 80s, started seeing compare&swap (and other similar instructions) appearing on number of didferent processors and major use by large scale DBMS systems.

misc. other posts in this thread:
http://www.garlic.com/~lynn/2010g.html#66 What is the protocal for GMT offset in SMTP (e-mail) header
http://www.garlic.com/~lynn/2010g.html#68 What is the protocal for GMT offset in SMTP (e-mail) header
http://www.garlic.com/~lynn/2010g.html#70 What is the protocal for GMT offset in SMTP (e-mail) header
http://www.garlic.com/~lynn/2010g.html#75 What is the protocal for GMT offset in SMTP (e-mail) header header time-stamp?
http://www.garlic.com/~lynn/2010g.html#76 What is the protocal for GMT offset in SMTP (e-mail) header header time-stamp?

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

What is the protocal for GMT offset in SMTP (e-mail) header time-stamp?

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What is the protocal for GMT offset in SMTP (e-mail) header time-stamp?
Newsgroups: comp.mail.misc, alt.folklore.computers, comp.os.linux.advocacy, comp.os.ms-w
Date: Thu, 08 Apr 2010 16:19:00 -0400
re:
http://www.garlic.com/~lynn/2010g.html#80 What is the protocal for GMT offset in SMTP (e-mail) header time-stamp?

oh ... and a few recent posts with references to "from annals of release no software before its time"
http://www.garlic.com/~lynn/2010g.html#0 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010g.html#4 Handling multicore CPUs; what the competition is thinking
http://www.garlic.com/~lynn/2010g.html#33 SQL Server replacement
http://www.garlic.com/~lynn/2010g.html#44 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010g.html#48 Handling multicore CPUs; what the competition is thinking
http://www.garlic.com/~lynn/2010g.html#77 IBM responds to Oracle's Exadata with new systems

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

[OT] What is the protocal for GMT offset in SMTP (e-mail) header time-stamp?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [OT] What is the protocal for GMT offset in SMTP (e-mail) header time-stamp?
Newsgroups: alt.folklore.computers
Date: Thu, 08 Apr 2010 19:22:36 -0400
Stan Barr <plan.b@dsl.pipex.com> writes:
My problem was getting 4 serial ports working simultaneously at a decent speed. I eventually gave up on Win3.1 and used MSDOS and DesqView which coped admirably with the same hardware.

semi-related to have pagesat usenet feed and waffle bbs installation.
http://www.garlic.com/~lynn/2010g.html#70 What is the protocal for GMT offset in SMTP (e-mail) header time-stamp?

old email ...
Date: Tue Dec 29 14:22:18 1992
From lynn
Subject: mail, waffle, etc

aysnch card:

On the brighter side, I upgraded my PC async/serial card to one with the 16550 FIFO. I had noticed that I would get sporadic errors doing UUCP transfers from work to home. A >100kbyte file would sometimes take 2-10 attempts before it transferred succesfully (even with modem error correction). this is UUCP that quits if it gets 12 errors on a transfer. The work/home setup is t2500 at work and 400e at home, the t2500/400e makes a 9600/REL-MNP connection, work locks the DTE to the t2500 at 19.2kbit, and home locks the 400e DTE at 56kbit.

It appeared that if the PC side started writing lots of data to disk ... it might have been dropping bits on the asynch side. With the new asynch card ... I regularly do 100kbyte file transfers from work w/o errors/problems.


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

for other topic drift ... old email from boca asking about doing (multitasking) dispatcher for os2:
http://www.garlic.com/~lynn/2007i.html#email871204
http://www.garlic.com/~lynn/2007i.html#email871204b

in these posts
http://www.garlic.com/~lynn/2007i.html#60 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#78 John W. Backus, 82, Fortran developer, dies

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

Far and near pointers on the 80286 and later

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Far and near pointers on the 80286 and later
Newsgroups: alt.folklore.computers, comp.sys.intel, comp.arch
Date: Fri, 09 Apr 2010 10:40:24 -0400
Bill Davidsen <davidsen@tmr.com> writes:
One of the things which separated MULTICS from most other operating systems was the way in which rings were used. Many operating systems use (or mostly use) only two rings, similarly to the "master mode" and "slave mode" of 1960's computers. By putting things like libraries and privileged linked programs (terminology escapes me, it's been ~40 years) in rings, access could be more nuanced.

370xa started out with access registers and then added program call (& return).

issue was that favorite son batch operating system heritage (from real memory environment) was extensively pointer-passing API.

In the initial transition to virtual memory (OS/VS2 SVS) it was just a single large virtual memory (pointer-passing APIs still working).

In the migration to MVS ... each application was given its own address space ... but an image of the MVS kernel appeared in (8mbyte) half of each (16mbyte) virtual address space (pointer passing API easily worked since MVS kernel code as in the same address space of each application).

The problem was that there were a lot of "subsystems" (semi-privileged operations) that had resided outside the kernel (called by applications with pointer passing API) that were now in their own virtual address space (i.e. application would generate system call and the kernel would invoke the subsystem in its own virtual address space).

To continue with pointer-passing API, a "common segment" was created that also resided in each virtual address space. This started out was 1mbyte of each virtual address space ... but grew ... somewhat proportional to the number of independent subsystems and the number of concurrent executing applications. eventually in the timeframe of of large 3033s ... common segments were threatening to exceed five mbytes (growing to six ... leaving only 2mbytes for applications in each application virtual address space).

to start to address the problem ... a subset of 370xa access registers were introduced in 3033 called dual-address space mode. Application wold make kernel call to invoke subsystem, kernel would swap the home & alternate virtual address space pointers before invoking the subsystem. each instance of subsystem execution would have alternate address space pointer to its invoking application ... and could directly address the invoking applications virtual address space.

Now 370xa introduced introduced access registers with more generalized implemenation of dual-address space as well as 31bit virtual addressing (31bit virtual addressing would have alleviated the common segment attempting to completely take-over remaining application area in each virtual address space).

program call (& return) ... application instruction that references a kernel hardware table ... that defines available "subsystems" and the rules for changing around the address space pointers. now applications can directly invoke a subsystem in different address space, w/o the overhead of kernel call processing (much like a library routine call that resides in the same address space).

description of program call
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dz9zr003/10.34?DT=20040504121320

program return
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dz9zr003/10.35?DT=20040504121320

discussion of access registers ("current instruction space and a maximum of 15 other spaces")
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dz9zr003/2.3.6?DT=20040504121320

discussion of address spaces
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dz9zr003/3.8?DT=20040504121320

recent posts mentioning dual-address space &/or access registers:
http://www.garlic.com/~lynn/2010c.html#41 Happy DEC-10 Day
http://www.garlic.com/~lynn/2010d.html#81 LPARs: More or Less?
http://www.garlic.com/~lynn/2010e.html#75 LPARs: More or Less?
http://www.garlic.com/~lynn/2010e.html#76 LPARs: More or Less?

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

In SSL We Trust? Not Lately

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: In SSL We Trust? Not Lately
Newsgroups: alt.folklore.computers, alt.computer.security
Date: Fri, 09 Apr 2010 14:46:39 -0400
Michael Wojcik <mwojcik@newsguy.com> writes:
Of course, SSL/TLS is far from being the weakest link in *that* chain. It's hardly worth attacking. Why use a MITM attack to grab one credit card number at a time, when you can break into someone's database and steal a million of them? Why use an active attack at all when a cheap phishing scam could get you a nice haul while you do other things?

re:
http://www.garlic.com/~lynn/2010g.html#79 In SSL We Trust? Not Lately

several times in early deployment of SSL & what is now called "electronic commerce" ... we pointed out that there were no known scenarios of actually evesdropping card numbers "in flight" ... and the MITM countermeasure was so weak that we coined the term "merchant comfort certificates" ... aka it isn't for security ... it is for providing a feeling of comfort. The spamming/phishing scenario getting people to click on URL taking them to some place ... works whether it is HTTP or HTTPS (all the attacker needs is a valid digital certificate and possibly a modified proxy where it pairs session to the real website ... actually much simpler than creating a duplicate of the real website).
http://www.garlic.com/~lynn/subpubkey.html#sslcert

SSL was supposed to provide both an evesdropping countermeasure as well as a MITM countermeasure. attackers can actually use a fraudulent URL/IP-address that then does some sort of proxy-like operation to the real website.
http://www.garlic.com/~lynn/subintegrity.html#mitm

Part of the requirements for the original SSL deployment for "electronic commerce" was that the end-user understood the relationship between the webserver they believed they were talking to and the webserver URL. Then the browser SSL code would validate the correspondance between the user-entered URL and the webserver contacted. The result was that the webserver that the user thot they were talking to, was in-fact, the webserver they were talking to.

The merchant webservers almost immediately violated that requirement. They found that HTTPS/SSL cut their thruput by 90-95% and so they dropped back to no longer having HTTPS/SSL for the initial webserver contact ... but just for the clicked-on checkout/pay button. The HTTPS/SSL was no longer being used to validate the session from a user provided URL ... but for a URL provided by an unvalidated website. The net result was that HTTPS/SSL just provided validation that the whatever the webserver claimed to be (by the URL it provided ... not the user) was the webserver that it was. This creates an enormous disconnect in the security model.

In the mid-90s, somewhat as result of doing the initial "electronic commerce" stuff ... we were invited to participate in the x9a10 financial standard working group ... which had been given the requirement to preserve the integrity of the financial infrastructure for ALL retail payments ... which resulted in the x9.59 financial retail payment standard (for ALL retail payments, aka point-of-sale, attended, unattended, card-present, internet, low-value, high-value, transit turnstile, debit, credit, ach, stored-value, gift-card, aka ALL).
http://www.garlic.com/~lynn/x959.html#x959

In the same time-frame there was various other organizations proposing some internet specific payment specifications. Many of these had enourmous cryptography overhead ... much, much larger than SSL ... but effectively provided no additional benefit (over what SSL already provided). As a result such internet-specific specifications ... with the enormously greater overhead and providing no additional benefit ... made little headway against the already established SSL convention. some past posts referencing the enormous bloat (processing and payload size 100 times that of underlying payment transaction)
http://www.garlic.com/~lynn/subpubkey.html#bloat

we were also tangentially involved in the cal. state data breach notification legislation. we had been brought in to help wordsmith the cal. state electronic signature legislation ... some past posts
http://www.garli.com/~lynn/subpubkey.html#signature

some of the parties were also heavily involved in privacy issues and had done in-depth public privacy surveys and found the number one issue was identity theft ... a big portion of that was fraudulent financial transactions as a result of data breaches. Nothing seemed to being done about the problem, so they seemed to feel that the publicity from the mandated notifications might improve the situation.

However, earlier in the x9a10 financial standard work we had done detailed, end-to-end threat & vulnerability studies of the different environments. Some of the ways we attempted to describe the current paradigm:

dual-use vulnerability; in the current paradigm, the knowledge of the account number may be sufficient to perform a fraudulent transaction (effectively authentication, as such it needs to be kept confidential and never divulged anywhere) ... while at the same time the account number needs to be readily available for a large number of business processes. The opposing/conflicting requirements (never divulged and at the same time readily available) has led to comments that even if the planet was buried under miles of information hiding encryption, it still couldn't prevent information leakage.

security proportional to risk; in the current paradigm, the value of the information (for business process) to the merchant is the profit on the transaction (possibly a couple dollars) and the value of the information (for business processes) to the processor can be a few cents per transaction ... while the value of the information (for authentication) to the crooks can be the credit limit and/or account balance (frequently 100 times or more, larger), as a result, the crooks may be able to outspend by 100 times (attacking the infrastructure) as the merchants/processors can spend (defending the infrastructure).

so in x9.59 standard, we slightly tweaked the current paradigm to eliminate the dual-use vulnerability ... which also eliminates the data breach, skimming, evesdropping, havesting, etc threats (i.e. crooks no longer have the prospect of fraudulent financial transactions as motivation for such activity; crooks can still perform such activity, it just doesn't provide the fraudulent financial return).

now since, the major use of SSL in the world today is hiding payment transactions details ... which is no longer necessary with x9.59 financial standard ... it also eliminates the major use of SSL.

now there were some interesting barriers to getting x9.59 deployed ... some of which are discussed in recent post:
http://www.garlic.com/~lynn/2010g.html#21 Should the USA Implement EMV?

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

What is the protocal for GMT offset in SMTP (e-mail) header

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What is the protocal for GMT offset in SMTP (e-mail) header
Newsgroups: comp.mail.misc, alt.folklore.computers, comp.os.linux.advocacy,
comp.os.ms-w
Date: Fri, 09 Apr 2010 15:04:02 -0400
"Non scrivetemi" <nonscrivetemi@pboxmix.winstonsmith.info> writes:
Threads are not a UNIX concept. UNIX forked work efficiently (creating a duplicate process) and when threads were added they were never efficient compared to forks, as you say, they were a kludge and many UNIX fundamentalists were againts them. Further, UNIX didn't offer the serialization mechanisms and APIs that IBM's OS and hardware supports (in enablement of threading, which is ancient and native there), so people didn't get experience with threading until much later and why "race conditions" are so common in UNIX and very uncommon in MVS.

On the other hand, threading is extremely efficient in MVS and has been around almost since the beginning. Address space creation (UNIX: forking), on the other hand, is very expensive and not a general purpose solution for multiprogramming in MVS.


re:
http://www.garlic.com/~lynn/2010g.html#80 What is the protocal for GMT
offset in SMTP (e-mail) header time-stamp?

MVS threads (TCBs) are less expensive than independent address spaces ... but still quite heavyweight. The weight of the TCB threads (starting with os/360 before virtual memory) was motivation for CICS to do its own threading/multitasking (all within a single operating system TCB).

CICS starting out doing all its own threading/multitasking within single TCB also resulted in it being limited to single processor operation (since the operating system just viewed it as a single large task ... and so there wasn't anything to run concurrently on different processors). misc. past posts mentioning CICS
http://www.garlic.com/~lynn/submain.html#cics

the work around for single TCB CICS was to run multiple CICS "regions" (aka a unique CICS instance with its own TCB) ... leading to things like an installations having over 120 CICS "regions" running.

as previously mentioned, compare&swap provided for application atomic threading operation ... whether running in single processor mode or multiprocessor mode. It was the favorite son operation system (MVS) organzation that claimed compare&swap wasn't needed in 370 ... and required that the multi-threaded examples be invented to override their objections. ... misc. past posts mentioning multiprocessing &/or compare&swap
http://www.garlic.com/~lynn/subtopic.html#smp

while UNIX didn't see posix threads until relatively recent ... lots of DBMS implementations that ran on UNIX platforms started doing their own threads (analogous to what CICS did) during the 80s (making use of compare&swap instructions where available)

In fact, early migration of various vendor RDBMS to (IBM's) RS/6000 experience significant performance penalty because the RS/6000 didn't have a atomic instruction with compare&swap like semantics. As a result, all RDBMS internal thread serialization had to be done with kernel calls.

These RDBMS approach to providing for multithreaded multiprocessor support in unix environment ... would start multiple instances of the RDBMS in different (unix) virtual address spaces ... where there was extensive virtual memory sharing of the different address spaces ... where they then provided quite a bit of their own multithreaded as well as multiprocessing operation.

--
42yrs virtualization experience (since Jan68), online at home since Mar1970




previous, next, index - home