List of Archived Posts

2008 Newsgroup Postings (07/30 - 08/16)

IBM-MAIN longevity
IBM-MAIN longevity
IBM-MAIN longevity
IBM-MAIN longevity
IBM-MAIN longevity
IBM-MAIN longevity
IBM-MAIN longevity
IBM-MAIN longevity
IBM-MAIN longevity
IBM-MAIN longevity
IBM-MAIN longevity
recent mentions of 40+ yr old technology
IBM-MAIN longevity
IBM-MAIN longevity
recent mentions of 40+ yr old technology
Code Page 1047 vs 037 - Green card confusion
IBM-MAIN longevity
IBM-MAIN longevity
recent mentions of 40+ yr old technology
IBM-MAIN longevity
IBM-MAIN longevity
recent mentions of 40+ yr old technology
dollar coins
Memories of ACC, IBM Channels and Mainframe Internet Devices
dollar coins
dollar coins
dollar coins
dollar coins
Verifying Verified By Visa - Registration breaks chain of trust
Verifying Verified By Visa - Registration breaks chain of trust
Verifying Verified By Visa - Registration breaks chain of trust
Authentication in the e-tailer / payment gateway / customer triangle
Authentication in the e-tailer / payment gateway / customer triangle
Authentication in the e-tailer / payment gateway / customer triangle
Authentication in the e-tailer / payment gateway / customer triangle
Quality of IBM school clock systems?
dollar coins
dollar coins
dollar coins
dollar coins
dollar coins
dollar coins
dollar coins
recent mentions of 40+ yr old technology
dollar coins
z/OS BIND9 DNS Vulnerable to Cache Poisoning Attack Problem?
z/OS BIND9 DNS Vulnerable to Cache Poisoning Attack Problem?
Intel: an expensive many-core future is ahead of us
Intel: an expensive many-core future is ahead of us
Quality of IBM school clock systems?
IBM manual web pages
Monetary affairs on free reign, but the horse has Boulton'd
Payments Security in RFS
Quality of IBM school clock systems?
dollar coins
Intel: an expensive many-core future is ahead of us
Intel: an expensive many-core future is ahead of us
No offense to any one but is DB2/6000 an old technology. Does anybody still use it, if so what type of industries??
Intel: an expensive many-core future is ahead of us
Intel: an expensive many-core future is ahead of us
recent mentions of 40+ yr old technology
Osama bin Laden gets a cosmetic makevover in his British Vanity Passport
Intel: an expensive many-core future is ahead of us
Early commercial Internet activities (Re: IBM-MAIN longevity)
Blinkylights
Crippleware: hardware examples
Blinkylights
dollar coins
Taxes
Verifying Verified By Visa - Registration breaks chain of trust
dollar coins
md5
Error handling for system calls
Blinkylights
Blinkylights
Intel: an expensive many-core future is ahead of us
squirrels
Blinkylights
Yet another squirrel question - Results (very very long post)
Book: "Everyone Else Must Fail" --Larry Ellison and Oracle ???
Book: "Everyone Else Must Fail" --Larry Ellison and Oracle ???
Intel: an expensive many-core future is ahead of us
Yet another squirrel question - Results (very very long post)
old 370 info
Yet another squirrel question - Results (very very long post)
old 370 info
Yet another squirrel question - Results (very very long post)
Yet another squirrel question - Results (very very long post)
Book: "Everyone Else Must Fail" --Larry Ellison and Oracle ???
Fraud due to stupid failure to test for negative

IBM-MAIN longevity

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM-MAIN longevity
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 30 Jul 2008 19:00:55 -0400
kkt <kkt@zipcon.net> writes:
I think you're misrepresenting Arpanet by the 1980s. Many, many US universities were on it, not just a few. Of the universities I know about, more were on Arpanet than on Bitnet. If you count individuals with access, rather than nodes, Arpanet probably had more.

Also, it would be a mistake to ignore other networks. If you just wanted e-mail and file transfer on a shoestring budget, there was always UUCP. Probably more reachable hosts than Bitnet and Arpanet put together.


re:
https://www.garlic.com/~lynn/2008k.html#85 IBM-MAIN longevity

the quote was from

lsoft's listserv history:
http://www.lsoft.com/products/listserv-history.asp#bitnet

you might cut him a little slack ... since it seems to be from perspective of europe (and EARN).

note that a lot of the (non-bitnet) connectivity in the states was csnet
https://en.wikipedia.org/wiki/CSNET

from above:
It was a forerunner to NSFNet. CSNET operated autonomously until 1989, when it merged with Bitnet to form CREN. By 1991 the growth of the Internet had made the CSNET services redundant, and CREN discontinued them.

... snip ...

CSNET supported a number of connectivity technologies as referenced in this reference to connection between sjr and csnet in fall of '82
https://www.garlic.com/~lynn/98.html#email821022
in this old post
https://www.garlic.com/~lynn/98.html#59

nsfnet wiki site
https://en.wikipedia.org/wiki/NSFNet

my view of nsfnet was the rfp for T1 backbone; NSFNET program announcement
https://www.garlic.com/~lynn/2002k.html#12
and NSFNET award announcement reference:
https://www.garlic.com/~lynn/2000e.html#10

... as opposed to the earlier 56kbit links mentioned here
https://www.garlic.com/~lynn/2008j.html#41 NSFnet -- 20 Years of Internet Obscurity and Insight

above has reference to:

NSF and the Birth of the Internet
http://www.nsf.gov/news/special_reports/nsf-net/textonly/index.jsp

that mentions the 56kbit links between the five NSF supercomputer centers and NCAR.

the 56kbit link references make it sound much more like networking interconnect of the five NSF supercomputer centers and NCAR.

a quote from the NSFNET award reference makes it sound much more like a "backbone" providing internetworking of the 12 regional networks:
On November 24th, 1987 the National Science Foundation announced that MERIT, supported by IBM and MCI was selected to develop and operate the evolving NSF Network and gateways integrating 12 regional networks.

... snip ...

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

IBM-MAIN longevity

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM-MAIN longevity
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 30 Jul 2008 21:29:18 -0400
kkt <kkt@zipcon.net> writes:
Also, it would be a mistake to ignore other networks. If you just wanted e-mail and file transfer on a shoestring budget, there was always UUCP. Probably more reachable hosts than Bitnet and Arpanet put together.

re:
https://www.garlic.com/~lynn/2008k.html#85 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008l.html#0 IBM-MAIN longevity

following from an internet monthly status report:
The NSFnet is an internet originally designed to provide access to NSF-funded supercomputers. Prospective supercomputer sites initially proposed their own consortium networks. These access networks were later augmented by a nationwide backbone which interconnects the supercomputer sites. Additional proposals were received and funded by the NSF to enrich the NSFnet infrastructure by building new regional networks and attaching them to the backbone, and by helping existing networks to attach.

The NSFnet backbone sites are located at Cornell University, the University of Illinois (Urbana Campus), the John von Neumann Center in Princeton, the National Center for Atmospheric Research, the Pittsburgh Supercomputing Center and the San Diego Supercomputing Center.

Regional/consortium networks currently existing or being implemented are the Bay Area Regional Research network (BARRnet), the consortium networks of the John von Neumann Center and the San Diego Supercomputer Center and the network of the Pittsburgh Supercomputer Academic Affiliates (PSCAAnet), WESTnet, NORTHWESTnet, NYSERnet in New York State, MIDnet in the Midwest, SESQUInet in the Houston area, SURAnet in the Southeast, and the University SAtellite Network pilot project (USAN).

Pre-existing networks being connected include the Merit Computer Network in Michigan, CSNET, and the ARPANET - which is being augmented to include a number of NSF-specified sites.

Active collaboration and coordination between DARPA and NSF is carried out under the terms of a Memorandum of Understanding signed by the Director of each agency. The NSFnet has already a richly connected infrastructure, building upon and partly using DARPA- developed protocols and systems; DARPA's pioneering network research has played an important role in the implementation of the NSFnet, and many participants in the DARPA-funded efforts are also active in helping the ambitious NSFnet program to succeed.


... snip ...

and arpanet was still being called arpanet:
ARPANET STATUS

The ARPANET experienced another period of extreme congestion beginning in late January and lasting roughly through mid-February. During this period service across gateways was particularly bad.

Over the past six months, transmission capacity in the ARPANET has been critical, especially on the network's cross-country paths. The congestion experienced in January and February was due primarily to a modest increase in traffic that pushed the ARPANET "over the edge".


... snip ...

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

IBM-MAIN longevity

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM-MAIN longevity
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 30 Jul 2008 22:14:11 -0400
re:
https://www.garlic.com/~lynn/2008k.html#81 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008k.html#83 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008k.html#85 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008l.html#0 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008l.html#1 IBM-MAIN longevity

old quote from joe morris regarding number of nodes sometime in 1985:
https://www.garlic.com/~lynn/2002k.html#26 DEC eNet: was Vnet : Unbelievable
https://www.garlic.com/~lynn/2006t.html#50 The Future of CPUs: What's After Multi-Core?


BITNET    435
ARPAnet  1155
CSnet     104 (excluding ARPAnet overlap)
VNET     1650
EasyNet  4200
UUCP     6000
USENET   1150 (excluding UUCP nodes)

... snip ...

the following from CSnet history:
http://www.livinginternet.com/i/ii_csnet.htm
The history of the CSNET is a story of enterprising academic entrepreneurship, and yet another example of TCP/IP's inexorable drive to spread. In 1979, most U.S. universities weren't doing research with the Department of Defence and so weren't connected to the ARPANET, but were increasingly aware of the network's advantages and wanted to level the research playing field. With seed funding and support from Kent Curtis at the National Science Foundation, Larry Landweber at the University of Wisconsin-Madison put together a proposal to build a network to connect non-ARPANET computer science departments. The proposal made its way to Dave Farber for review, who gave it to one of his graduate students, Dave Crocker, who thought it was an interesting idea but, like others, worried about the university's lack of networking experience.

to provide networking connectivity to educational institutions not involved with DOD (and allowed to have access to arpanet).

in that sense ... the number of bitnet nodes in 1985 being four times larger than the non-DOD academic csnet nodes ... may support the reference at the lsoft website by the listserv author
http://www.lsoft.com/products/listserv-history.asp#bitnet

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

IBM-MAIN longevity

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM-MAIN longevity
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 30 Jul 2008 22:43:25 -0400
for something a little different:

Project to rebuild Internet gets $12M, bandwidth
http://news.yahoo.com/s/ap/tec_techbit_rebuilding_the_internet

from above:
A massive project to redesign and rebuild the Internet from scratch is inching along with $12 million in government funding and donations of network capacity by two major research organizations.

... snip ...

website:
http://geni.net/

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

IBM-MAIN longevity

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM-MAIN longevity
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 31 Jul 2008 07:59:10 -0400
kkt <kkt@zipcon.net> writes:
I note that CSnet used TCP/IP and gatewayed to the Arpanet, NSFnet, etc., without the user needing to be aware of which networks their packets were travelling over. That's the central feature of the Internet, regardless of whether it was before or after the name change.

that is somewhat the periodic refrain that tcp/ip was the technology basis for the Internet (i.e. internetworking), nsfnet was the operational basis for the Internet, and CIX was the business basis for the Internet.
https://www.garlic.com/~lynn/2008k.html#85 IBM-MAIN longevity

tcp/ip wasn't absolutely required for end-to-end operation ... but it made it a lot easier. csnet was moving email (users didn't really care about the underlying transport format) transparently across a variety of different protocols ... prior to tcp/ip ... i.e. same reference
https://www.garlic.com/~lynn/2008k.html#85 IBM-MAIN longevity

references oct82 csnet connectivity announcement
https://www.garlic.com/~lynn/98.html#email821022
in this post
https://www.garlic.com/~lynn/98.html#59

which lists some of the different protocols in use by csnet ... prior to the arpanet cutoff to tcp/ip on 1/1/83.

gateways of various flavors were needed for moving across protocol boundaries prior to tcp/ip (and many continued in use after the arpanet tcp/ip cutover on 1/1/83)

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

IBM-MAIN longevity

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM-MAIN longevity
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 31 Jul 2008 08:08:32 -0400
Peter Flass <Peter_Flass@Yahoo.com> writes:
Maybe in your world, but only large universities could afford ARPANet connections. Smaller colleges, and I was working at one, could easily afford Bitnet connectivity. I would guess that in the State University of New York system, possibly six or so sites would have hat ARPANet connectivity for research - the four university centers naturally, plus a couple of the larger four-year colleges. I believe all 64 campuses had a Bitnet connection.

and as in the justification for starting csnet
https://www.garlic.com/~lynn/2008l.html#2 IBM-MAIN longevity

... was requiring some sort of DOD affiliation ... part of what kicked this off was that the original IBM-MAIN thread was question about when the IBM-MAIN (listserv) mailing originated (on BITNET) ... and suggesting that the lsoft website &/or listserv author might know. the lsoft website had some historical timeline ... including the quote about BITNET (&/or EARN)
https://www.garlic.com/~lynn/2008k.html#85 IBM-MAIN longevity

and the comment may have been somewhat been a non-US centric perspective
https://www.garlic.com/~lynn/2008l.html#0 IBM-MAIN longevity

since non-US educational institutions may had more difficulty with DOD affiliations ... independent of the cost.

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

IBM-MAIN longevity

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM-MAIN longevity
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 31 Jul 2008 08:33:11 -0400
kkt <kkt@zipcon.net> writes:
This seems really low and I haven't found the source of these statistics in a reasonable look. Are they counting member institutions instead of computers?

For comparison, the hosts.txt table that shows all the hosts directly routable plus foreign networks and gateways as of 4 Feb. 1988 is available from


http://pdp-10.trailing-edge.com/bb-ev83b-bm/01/new-system/hosts.txt.html

This must be about the last centrally maintained hosts.txt file from SRI-NIC. My count is 807 networks, 223 gateways, and 5496 hosts. Give or take one or two for comment lines.


re:
https://www.garlic.com/~lynn/2008l.html#2 IBM-MAIN longevity

after tcp/ip cutover on 1/1/83 ... there was fairly rapid growth. at the time of the cut-over, arpanet had somewhere between 100 nodes and 250 hosts (different sources cite different counts ... it is possible nodes were the network node IMPs which might have one or more connected hosts?).

one of the reference posts
https://www.garlic.com/~lynn/2006t.html#50 The Future of CPUs: What's After Multi-Core?


BITNET    435
ARPAnet  1155
CSnet     104 (excluding ARPAnet overlap)
VNET     1650
EasyNet  4200
UUCP     6000
USENET   1150 (excluding UUCP nodes)

... snip ...

also had one of my old emails from 85
https://www.garlic.com/~lynn/2006t.html#email850625

complaining about cost of DES link encryptors for HSDT project
https://www.garlic.com/~lynn/subnetwork.html#hsdt

and commenting about internal network approaching 2000 nodes ... and all links requiring link encryptors. The HSDT links were T1 and higher ... so I was paying a lot more ... than the rest of the links which were 56kbits or slower.

anyway ... the reference
https://www.garlic.com/~lynn/2006t.html#50 The Future of CPUs: What's After Multi-Core?

also includes an old info.nets reference from 18feb89 quoting
BITNET 01/18/85 435 University/nonprofit/research network Arpanet 01/22/85 1155 DoD related

... snip ...

which matches numbers provided by Joe.

also referenced was ... The December 1988 BITNET nodes file contains 2691 entries. This includes BITNET/NETNORTH/EARN nodes

also showing that the rate of increase in number of nodes was increasing in 85-88 period.

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

IBM-MAIN longevity

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM-MAIN longevity
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 31 Jul 2008 09:02:12 -0400
Anne & Lynn Wheeler <lynn@garlic.com> writes:
also includes an old info.nets reference from 18feb89 quoting
BITNET    01/18/85    435 University/nonprofit/research network
Arpanet   01/22/85   1155 DoD related
... snip ...


re:
https://www.garlic.com/~lynn/2006l.html#2 IBM-MAIN longevity
https://www.garlic.com/~lynn/2006l.html#6 IBM-MAIN longevity

the info.nets reference:


From: magill@eniac.seas.upenn.edu (Operations Manager)
Newsgroups: info.nets
Subject: "world net" size
Date: 17 Feb 89 19:32:42 GMT
Date-Received: 18 Feb 89 19:00:50 GMT
To: info-nets@Think.COM

>   Does anyone have a current table of size estimates for the academic
>   and research networks?
>
>   Network   as of     count Description
>   --------  --------  ----- -----------------------------------------------
>   BITNET    01/18/85    435 University/nonprofit/research network
>   Arpanet   01/22/85   1155 DoD related

The December 1988 BITNET nodes file contains 2691 entries.
This includes BITNET/NETNORTH/EARN nodes.

The growth of the Internet has been explosive.

... snip ...

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

IBM-MAIN longevity

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM-MAIN longevity
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 31 Jul 2008 09:39:01 -0400
kkt <kkt@zipcon.net> writes:
This must be about the last centrally maintained hosts.txt file from SRI-NIC. My count is 807 networks, 223 gateways, and 5496 hosts. Give or take one or two for comment lines.

During the 80s, I use to shadow much of nisc.sri.com (actually was shadowing 60-70 locations) ... automated process checking new/changed files and fetching ... it was in large part oriented towards making sure having all current RFCs ... but also some number of other files. then the files moved to nnsc.nsf.net and then to "internic" ... and now RFCs are at rfc-editor (aka isi).

old post (in thread similar to this one):
https://www.garlic.com/~lynn/2000e.html#20 Is Al Gore The Fater of the Internet?

I included a list of all domain names from the oct90 domain list.

i still have automated process to shadow RFCs at rfc-editor ... it is part of maintaining rfc index
https://www.garlic.com/~lynn/rfcietff.htm

and in earlier versions of STD1, I provided section 6.10 that listed RFC status inconsistencies.

past posts in this thread:
https://www.garlic.com/~lynn/2008k.html#81 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008k.html#83 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008k.html#85 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008l.html#0 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008l.html#1 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008l.html#2 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008l.html#3 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008l.html#4 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008l.html#5 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008l.html#6 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008l.html#7 IBM-MAIN longevity

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

IBM-MAIN longevity

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM-MAIN longevity
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 31 Jul 2008 10:28:03 -0400
Roger Blake <rogblake10@iname10.com> writes:
A few of the man pages from my BSD 4.1 programmer's manual (circa early 1980s) reference the internet.

and as per the info.nets reference
https://www.garlic.com/~lynn/2008l.html#7 IBM-MAIN longevity

frequently the interconnected/gatewayed networks were referred to as internet ... even when it wasn't all tcp/ip. in the info.nets reference the comment is about the explosive internet growth with regard to the 485 bitnet nodes on 18jan85 and the 2691 nodes in dec88 (over 550%)

the reference to the modern internet ... my comments have been the technology from tcp/ip protocol, operations from nsfnet, and business from cix.
https://www.garlic.com/~lynn/2008k.html#85 IBM-MAIN longevity

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

IBM-MAIN longevity

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM-MAIN longevity
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 31 Jul 2008 12:50:08 -0400
Peter Flass <Peter_Flass@Yahoo.com> writes:
It sounds like the trend lines crossed in the 1988-89 timeframe.

part of the issue in the internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet

being larger than arpanet from just about the beginning until possible mid-85 was that the technology used in the internal network effectively had a form of gateway built into every node.

centralized control ... as either technology and/or business would be a growth inhibitor.

that is past statements about arpanet being somewhere between 100 nodes and 250 hosts at the time of the 1/1/83 switchover to tcp/ip (arpanet was both centralized homogeneous protocol and operational control ... switch to tcp/ip improved homogeneous technology issues) ... at a point when the internal network was approaching 1000. old reference to internal network reaching 1000 nodes:
https://www.garlic.com/~lynn/99.html#112 OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
https://www.garlic.com/~lynn/2003j.html#10 20th anv of 1000th node on internal network

internal network continued to grow in size thru the mid-80s with the rapid growth in the number of internal mid-range mainframes. the internal growth of mainframes then started to slack off in the mid-80s, similar to shift in the customer market from mid-range machines & departmental servers to workstations and larger PCs. This has been frequently discussed here with regard to change in mid-range sales for both 43xx machines as well as vax machines in the mid-80s.

externally ... there was still rapid growth because the environment 1) had started much later with pervasive network introduction and 2) increasing number of workstation and PC nodes.

this is a post that includes a list cities with internal locations that added one or more new nodes during 1983 (it also includes a sample of some of the new nodes added during 1983):
https://www.garlic.com/~lynn/2006k.html#8 Arpa address

a major paradigm change was migration of end-to-end networking protocols into workstations and PCs ... which went a long way to exploding the number of "internet" nodes. On the internal network, workstations and PCs were still being dealt with using terminal emulation
https://www.garlic.com/~lynn/subnetwork.html#emulation

in fact, the communication division SAA strategy appeared to try and constrain customer terminal emulation environments from moving to client/server. in that time-frame, we had come up with 3tier networking architecture and were out making customer executive presentations (and taking some amount of hits from the communication division).
https://www.garlic.com/~lynn/subnetwork.html#3tier

other posts in this thread:
https://www.garlic.com/~lynn/2008k.html#81 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008k.html#83 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008k.html#85 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008l.html#0 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008l.html#1 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008l.html#2 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008l.html#3 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008l.html#4 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008l.html#5 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008l.html#6 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008l.html#7 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008l.html#8 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008l.html#9 IBM-MAIN longevity

there have been similar threads that have played out in this n.g. in the past (from 2006):
https://www.garlic.com/~lynn/2006j.html#34 Arpa address
https://www.garlic.com/~lynn/2006j.html#45 Arpa address
https://www.garlic.com/~lynn/2006j.html#46 Arpa address
https://www.garlic.com/~lynn/2006j.html#49 Arpa address
https://www.garlic.com/~lynn/2006j.html#50 Arpa address
https://www.garlic.com/~lynn/2006j.html#53 Arpa address
https://www.garlic.com/~lynn/2006k.html#3 Arpa address
https://www.garlic.com/~lynn/2006k.html#8 Arpa address
https://www.garlic.com/~lynn/2006k.html#9 Arpa address
https://www.garlic.com/~lynn/2006k.html#10 Arpa address
https://www.garlic.com/~lynn/2006k.html#12 Arpa address
https://www.garlic.com/~lynn/2006k.html#40 Arpa address
https://www.garlic.com/~lynn/2006k.html#42 Arpa address
https://www.garlic.com/~lynn/2006k.html#43 Arpa address

or (from 2002):
https://www.garlic.com/~lynn/2000d.html#43 Al Gore: Inventing the Internet...
https://www.garlic.com/~lynn/2000d.html#56 Is Al Gore The Father of the Internet?
https://www.garlic.com/~lynn/2000d.html#58 Is Al Gore The Father of the Internet?
https://www.garlic.com/~lynn/2000d.html#59 Is Al Gore The Father of the Internet?
https://www.garlic.com/~lynn/2000d.html#63 Is Al Gore The Father of the Internet?
https://www.garlic.com/~lynn/2000d.html#67 Is Al Gore The Father of the Internet?^
https://www.garlic.com/~lynn/2000d.html#70 When the Internet went private
https://www.garlic.com/~lynn/2000d.html#77 Is Al Gore The Father of the Internet?^
https://www.garlic.com/~lynn/2000e.html#5 Is Al Gore The Father of the Internet?^
https://www.garlic.com/~lynn/2000e.html#10 Is Al Gore The Father of the Internet?^
https://www.garlic.com/~lynn/2000e.html#11 Is Al Gore The Father of the Internet?^
https://www.garlic.com/~lynn/2000e.html#13 internet preceeds Gore in office.
https://www.garlic.com/~lynn/2000e.html#14 internet preceeds Gore in office.
https://www.garlic.com/~lynn/2000e.html#15 internet preceeds Gore in office.
https://www.garlic.com/~lynn/2000e.html#18 Is Al Gore The Father of the Internet?^
https://www.garlic.com/~lynn/2000e.html#19 Is Al Gore The Father of the Internet?^
https://www.garlic.com/~lynn/2000e.html#20 Is Al Gore The Father of the Internet?^
https://www.garlic.com/~lynn/2000e.html#26 Al Gore, The Father of the Internet (hah!)
https://www.garlic.com/~lynn/2000e.html#28 Is Al Gore The Father of the Internet?^
https://www.garlic.com/~lynn/2000e.html#31 Cerf et.al. didn't agree with Gore's claim of initiative.
https://www.garlic.com/~lynn/2000e.html#38 I'll Be! Al Gore DID Invent the Internet After All ! NOT
https://www.garlic.com/~lynn/2000e.html#39 I'll Be! Al Gore DID Invent the Internet After All ! NOT
https://www.garlic.com/~lynn/2000f.html#44 Al Gore and the Internet (Part 2 of 2)
https://www.garlic.com/~lynn/2000f.html#45 Al Gore and the Internet (Part 2 of 2)
https://www.garlic.com/~lynn/2000f.html#46 Al Gore and the Internet (Part 2 of 2)
https://www.garlic.com/~lynn/2000f.html#47 Al Gore and the Internet (Part 2 of 2)
https://www.garlic.com/~lynn/2000f.html#49 Al Gore and the Internet (Part 2 of 2)
https://www.garlic.com/~lynn/2000f.html#50 Al Gore and the Internet (Part 2 of 2)
https://www.garlic.com/~lynn/2000f.html#51 Al Gore and the Internet (Part 2 of 2)
https://www.garlic.com/~lynn/2002h.html#79 Al Gore and the Internet
https://www.garlic.com/~lynn/2002h.html#80 Al Gore and the Internet
https://www.garlic.com/~lynn/2002h.html#81 Al Gore and the Internet
https://www.garlic.com/~lynn/2002h.html#82 Al Gore and the Internet
https://www.garlic.com/~lynn/2002h.html#85 Al Gore and the Internet
https://www.garlic.com/~lynn/2002h.html#86 Al Gore and the Internet
https://www.garlic.com/~lynn/2002i.html#15 Al Gore and the Internet
https://www.garlic.com/~lynn/2002i.html#28 trains was: Al Gore and the Internet
https://www.garlic.com/~lynn/2002i.html#35 pop density was: trains was: Al Gore and the Internet
https://www.garlic.com/~lynn/2002i.html#36 pop density was: trains was: Al Gore and the Internet
https://www.garlic.com/~lynn/2002l.html#70 Al Gore and Fidonet [was: 10 choices]

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

recent mentions of 40+ yr old technology

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: recent mentions of 40+ yr old technology
Newsgroups: alt.folklore.computers
Date: Thu, 31 Jul 2008 13:49:10 -0400
Report: Microsoft prepares for end of Windows with Midori
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=009111018

from above:
July 29, 2008 (IDG News Service) With the Internet increasingly taking on the role of the PC operating system and the growing prevalence of virtualization technologies, there likely will be a day when the Windows client operating system as it has been developed for the past 20-odd years becomes obsolete.

According to published reports, Microsoft Corp. seems to be preparing for that day with an incubation project codenamed Midori, which seeks to create a componentized, non-Windows operating system that will take advantage of technologies not available when Windows first was conceived.


... snip ...

other recent posts in this (particular virtualization) thread
https://www.garlic.com/~lynn/2008k.html#45 recent mentions of 40+ yr old technology
https://www.garlic.com/~lynn/2008k.html#46 recent mentions of 40+ yr old technology
https://www.garlic.com/~lynn/2008k.html#52 recent mentions of 40+ yr old technology
https://www.garlic.com/~lynn/2008k.html#53 recent mentions of 40+ yr old technology
https://www.garlic.com/~lynn/2008k.html#55 recent mentions of 40+ yr old technology
https://www.garlic.com/~lynn/2008k.html#60 recent mentions of 40+ yr old technology

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

IBM-MAIN longevity

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM-MAIN longevity
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 31 Jul 2008 14:01:22 -0400
Anne & Lynn Wheeler <lynn@garlic.com> writes:
one of the reference posts
https://www.garlic.com/~lynn/2006t.html#50 The Future of CPUs: What's After Multi-Core?
BITNET    435
ARPAnet  1155
CSnet     104 (excluding ARPAnet overlap)
VNET     1650
EasyNet  4200
UUCP     6000
USENET   1150 (excluding UUCP nodes)
... snip ...


re:
https://www.garlic.com/~lynn/2008l.html#6 IBM-MAIN longevity

R.I.P Usenet: 1980-2008
http://tech.slashdot.org/tech/08/07/31/1622251.shtml
R.I.P Usenet: 1980-2008
http://www.pcmag.com/article2/0,2704,2326848,00.asp

from above:
Child-porn investigations have doomed one of the last remnants of a smaller, kinder Net.

... snip ...

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

IBM-MAIN longevity

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM-MAIN longevity
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 31 Jul 2008 15:41:11 -0400
Roger Blake <rogblake10@iname10.com> writes:
The BSD 4.1 manual does reference and describe TCP/IP, probably the earliest book in my possession that does.

One of the man pages I happened on just recently therein was a program or function for looking up hostnames on a TCP/IP network. (The "bugs" section complained that there was no central database for hostnames -- obviously written pre-DNS.)


re:
https://www.garlic.com/~lynn/2008l.html#9 IBM-MAIN longevity

recent post with reference to inventor of DNS
https://www.garlic.com/~lynn/2008j.html#87 CLIs and GUIs

having worked at the science center
https://www.garlic.com/~lynn/subtopic.html#545tech

for something a little different ... there was post in old thread about CSRG being told that they couldn't do a tcpip/network implementation and they went ahead and did it anyway:
https://www.garlic.com/~lynn/2000e.html#28 Is Al Gore The Father of the Internet?^

the reference in the above was
http://www.be.daemonnews.org/199909/usenix-kirk.html

from above:
He said (paraphrased) that every DARPA meeting ended up the same, with the Military coming in and giving CSRG (at UCB, the group that worked on BSD) a stern warning that they were to work on the Operating System, and that BBN will work on the networking. Every time, Bob Fabry, then the adviser of CSRG, would "Yes: them to death" and they'd go off and just continue the way they were going. Much to the frustration of the DARPA advisery board

... snip ...

I had done internet specific post archive from similar threads in 99 time-frame:
https://www.garlic.com/~lynn/internet.htm

one of the threads (in the internet archive):
https://www.garlic.com/~lynn/99.html#37a Internet and/or ARPANET?
https://www.garlic.com/~lynn/99.html#37b Internet and/or ARPANET?
https://www.garlic.com/~lynn/99.html#38a Internet and/or ARPANET?
https://www.garlic.com/~lynn/99.html#38b Internet and/or ARPANET?
https://www.garlic.com/~lynn/99.html#38d Internet and/or ARPANET?
https://www.garlic.com/~lynn/99.html#39 Internet and/or ARPANET?
https://www.garlic.com/~lynn/99.html#44 Internet and/or ARPANET?
https://www.garlic.com/~lynn/99.html#45 Internet and/or ARPANET?
https://www.garlic.com/~lynn/99.html#46 Internet and/or ARPANET?
https://www.garlic.com/~lynn/99.html#51 Internet and/or ARPANET?
https://www.garlic.com/~lynn/99.html#53 Internet and/or ARPANET?

some of the posts (both in 99.html archive and copies in internet.htm archive) has extracts from IEN (internet engineering) documents on issue with the development of IP and internetworking.

as per
https://www.garlic.com/~lynn/99.html#38d Internet and/or ARPANET?
https://www.garlic.com/~lynn/internet.htm#5 Internet and/or ARPANET?

internet was also referred to as multinetwork (in IEN-16, 20May77) and catenet (in IEN-32, 28apr78). IEN-16 (also RFC 730) has some discussion about the changes in the Host-IMP interface for extensible Field Addressing ...
Multinetwork Systems

The prospect of interconnections of networks to form a complex multinetwork system poses additional addressing problems. The new Host-IMP interface specification has reserved fields in the leader to carry network addresses [2]. There is experimental work in progress on interconnecting networks [4, 5, 6]. We should be prepared for these extensions to the address space.


... snip ...

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

recent mentions of 40+ yr old technology

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: recent mentions of 40+ yr old technology
Newsgroups: alt.folklore.computers
Date: Thu, 31 Jul 2008 15:53:21 -0400
Peter Flass <Peter_Flass@Yahoo.com> writes:
The article goes on to say "Midori is an offshoot of Singularity." I was much less than impressed by Singularity.

re:
https://www.garlic.com/~lynn/2008l.html#11 recent mentions of 40+ yr old technology

but it does seem that they are attempting to catch the wave that has been moving in the direction of virtual appliances (or what we started out calling service virtual machines in the early 70s). past posts mentioning the new virtual appliance genre:
https://www.garlic.com/~lynn/2006t.html#46 To RISC or not to RISC
https://www.garlic.com/~lynn/2006w.html#25 To RISC or not to RISC
https://www.garlic.com/~lynn/2006x.html#6 Multics on Vmware ?
https://www.garlic.com/~lynn/2006x.html#8 vmshare
https://www.garlic.com/~lynn/2007i.html#36 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007k.html#26 user level TCP implementation
https://www.garlic.com/~lynn/2007k.html#48 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007m.html#67 Operating systems are old and busted
https://www.garlic.com/~lynn/2007m.html#70 Is Parallel Programming Just Too Hard?
https://www.garlic.com/~lynn/2007o.html#3 Hypervisors May Replace Operating Systems As King Of The Data Center
https://www.garlic.com/~lynn/2007q.html#25 VMware: New King Of The Data Center?
https://www.garlic.com/~lynn/2007s.html#4 Why do we think virtualization is new?
https://www.garlic.com/~lynn/2007s.html#26 Oracle Introduces Oracle VM As It Leaps Into Virtualization
https://www.garlic.com/~lynn/2007s.html#35 Oracle Introduces Oracle VM As It Leaps Into Virtualization
https://www.garlic.com/~lynn/2007u.html#39 New, 40+ yr old, direction in operating systems
https://www.garlic.com/~lynn/2007u.html#41 New, 40+ yr old, direction in operating systems
https://www.garlic.com/~lynn/2007u.html#81 IBM mainframe history, was Floating-point myths
https://www.garlic.com/~lynn/2007v.html#75 virtual appliance
https://www.garlic.com/~lynn/2007v.html#80 software preservation volunteers ( was Re: LINC-8 Front Panel Questions)
https://www.garlic.com/~lynn/2008.html#59 old internal network references
https://www.garlic.com/~lynn/2008b.html#39 folklore indeed
https://www.garlic.com/~lynn/2008b.html#52 China's Godson-2 processor takes center stage
https://www.garlic.com/~lynn/2008c.html#2 folklore indeed
https://www.garlic.com/~lynn/2008c.html#55 Kernels
https://www.garlic.com/~lynn/2008e.html#11 Kernels
https://www.garlic.com/~lynn/2008e.html#15 Kernels
https://www.garlic.com/~lynn/2008h.html#47 Microsoft versus Digital Equipment Corporation
https://www.garlic.com/~lynn/2008h.html#97 Is virtualization diminishing the importance of OS?

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Code Page 1047 vs 037 - Green card confusion

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Code Page 1047 vs 037 - Green card confusion
Newsgroups: bit.listserv.ibm-main
To: <ibm-main@bama.ua.edu>
Date: Thu, 31 Jul 2008 17:59:16 -0400
shmuel+ibm-main@PATRIOT.NET (Shmuel Metz , Seymour J.) writes:
No, I'm referring to the 1403 line-printer Universal Character Set buffer, since the context was the 1416. That was a wrapper around an array of code points the same size as the band[1], chain[2] or train.

The 3800 and 3900 were very different, because you could actually define the pixel layout of each character.

[1] Not applicable to the 1403

[2] I don't recall whether there was an S/360 model of the 1403 that used a chain


i saw both 1403-7 (600lpm) and 1403-N1 (1100lpm) in use on 360-30.

IBM 1403 Printer train
http://www-03.ibm.com/ibm/history/exhibits/attic3/attic3_024.html

from above:
The "chain" printer for computers was introduced with the IBM 1401 computer in 1959. Improving both speed and reliability, the IBM 1403 printer's "chain-loop" of characters traveled horizontally at 90 inches a second and printed 600 lines a minute as it was struck by 132 hammers positioned across the paper. The last IBM 1403 -- of more than 23,000 shipped to U.S. customers -- was delivered in 1983

... snip ...

the above title says *train* and then description talks about *chain*

1403-2 & 1403-7 printers
http://www-03.ibm.com/ibm/history/exhibits/supplies/supplies_5404PH09.html

i think should be "chain" printers (600lpm) ... above says "-7" was 120 print positions and could be used with 360s & 370s; "-2" was 132 print positions and could be used with 360, 370, & s/3 model 10

This reference:

The evolution of printers and displays
http://www.research.ibm.com/journal/sj/253/ibmsj2503a4N.pdf

says that 1403 used chains with train introduced in later 1403N1

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

IBM-MAIN longevity

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM-MAIN longevity
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 31 Jul 2008 18:42:14 -0400
Anne & Lynn Wheeler <lynn@garlic.com> writes:
also had one of my old emails from 85
https://www.garlic.com/~lynn/2006t.html#email850625

complaining about cost of DES link encryptors for HSDT project
https://www.garlic.com/~lynn/subnetwork.html#hsdt

and commenting about internal network approaching 2000 nodes ... and all links requiring link encryptors. The HSDT links were T1 and higher ... so I was paying a lot more ... than the rest of the links which were 56kbits or slower.


re:
https://www.garlic.com/~lynn/2008l.html#6 IBM-MAIN longevity

I've mentioned before that in this period that there were comments that over half of all the link encryptors in the world were on the internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet

looking at some of the nsfnet status reports ... i also found this inclusion ... ref (bay area regional research network) BARNET T1s (from '87):
Proteon routers with Ethernet and full T-1 interfaces (SBE boards) have been bench tested at Stanford with Avanti Accupak 1.5 data formatters (DSX-1 interface w/o CSUs). Appears that with the CSU (Avanti's internal "ISU") the effective thruput will be limited to 1.344Mb/s by the Avanti because it uses straight bit-stuffing to meet the telco connect requirements. As a result, we have started testing Verilink units which use an algorithm for maintaining the telco T-1 bit density requirements that appears to avoid the loss of the 192kbps. Will also test Phoenix microsystems units which purport the same in their reformatter/CSUs and have a better physical configuration (8 packs, formatter or CSU to a 19in rack) and a built-in BERT in CSU.

... snip ...

HSDT first telco T1s (some in the bay area) were "clear-channel". Then telcos started insisting that T1s conform to ones density requirement ... and we initially used the Avanti (UltraMuxes) bit-stuffing described in the above status report. We had already been using Avanti with a separate 56kbit subchannel dedicated to continuous bit-error-test (FireBerd).

HSDT did get some Phoenix boxes a couple yrs later in the fall of '86.

for other link encryptor and hsdt topic drift:
https://www.garlic.com/~lynn/2008h.html#87 New test attempt
https://www.garlic.com/~lynn/2008i.html#86 Own a piece of the crypto wars
https://www.garlic.com/~lynn/2008j.html#43 What is "timesharing" (Re: OS X Finder windows vs terminal window weirdness)

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

IBM-MAIN longevity

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM-MAIN longevity
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 01 Aug 2008 05:12:01 -0400
Anne & Lynn Wheeler <lynn@garlic.com> writes:
HSDT first telco T1s (some in the bay area) were "clear-channel". Then telcos started insisting that T1s conform to ones density requirement ... and we initially used the Avanti (UltraMuxes) bit-stuffing described in the above status report. We had already been using Avanti with a separate 56kbit subchannel dedicated to continuous bit-error-test (FireBerd).

HSDT did get some Phoenix boxes a couple yrs later in the fall of '86.


re:
https://www.garlic.com/~lynn/2008l.html#16 IBM-MAIN longevity

... past hsdt posts
https://www.garlic.com/~lynn/subnetwork.html#hsdt

this was all well before SNMP; The FireBerds and UltrMux did have rs232 output that could be hooked to hardcopy terminals. so i configured PC/XTs with 4-port async cards ... and hooked the rs232 to the PC/XTs. I wrote a turbo pascal program to emulate hardcopy terminal on all the ports ... would log the output to the harddisk as well as scan for various alert conditions and raise alarms.

SNMP rfc was:
https://www.garlic.com/~lynn/rfcidx3.htm#1067
1067 - Simple Network Management Protocol, Case J., Davin J., Fedor M., Schoffstall M., 1988/08/01 (33pp) (.txt=67742) (Obsoleted by 1098) (See Also 1065, 1066) (Refs 768, 1028, 1052) (Ref'ed By 1089, 1095, 1156, 1704)

....

I had a PC/RT with megapixal display at Interop '88 ... misc. past posts
https://www.garlic.com/~lynn/subnetwork.html#interop88

it was in the NSC booth ... which was at the end of a row. Case was in the Sun booth which was at the end of a row at right angles to the NSC booth ... and got Case to come over and install their SNMP on the PC/RT.

Part of the reason that I was in the NSC booth ... was that I had also done RFC 1044 support ... misc. past posts
https://www.garlic.com/~lynn/subnetwork.html#1044

re:
https://www.garlic.com/~lynn/rfcidx3.htm#1044
1044 - Internet Protocol on Network System's HYPERchannel: Protocol Specification. K. Hardwick, J. Lekashman. February 1988. (Format: TXT=100836 bytes) (Also STD0045) (Status: STANDARD)

for mainframe tcp/ip product. The product had been implemented in vs/pascal ... but wasn't very optimized ... getting about 44kbytes/sec using a full 3090 processor. In some RFC1044 tuning testing at Cray Research (between cray and 4341-clone), I got 1mbyte/sec (4341 channel) using only a modest amount of the 4341 (nearly 3 orders of magnitude improvement in bytes transferred per instructions executed).

... and turbo pascal snippet from somewhere long ago and far away:
{$V+,R+,B-,C-,U-} {note: the C- & U- aviods losing type-ahead} (* FIREBERD minimize ERROR entries in cases of prolonged high-error rate conditions. Calculate ERRORs/sec Make no more than one entry in ERROR per 15 minutes unless ERRORs/sec change by more than 50%.

minimize ERROR entries for sync lost/sync acquired loops.

ULTRAMUX recognize alarm messages define status flags for various alarm messages when sync. is lost, include fireberd information in screen

COM2 asynch interrupt check for Asynch card interrupt ... if not asynch, restore status/regs and goto saved IRA (i.e. cascaded IRQ4 interrupt routines)


... snip ...

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

recent mentions of 40+ yr old technology

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: recent mentions of 40+ yr old technology
Newsgroups: alt.folklore.computers
Date: Fri, 01 Aug 2008 09:39:29 -0400
Virtual Sprawl Hits Wall Street
http://www.financetech.com/news/showArticle.jhtml?articleID=191901528

from above:
Having implemented virtualization software to conquer "server sprawl" (or, more specifically, to perform more work on fewer servers and thus minimize the proliferation of servers), many Wall Street firms are now in the throes of "virtual sprawl".

... snip ...

one of the issues ...
Further, software vendors increasingly are policing their customers, auditing how many instances of their programs a company is really running versus the number of licenses it purchased and then asking the client to cough up the difference, which can run into millions of dollars.

... snip ...

this has also come up in the past with the proliferation of multi-core chips ... initially starting out with license priced proportional to number of cores. virtualization might result in hundreds of software "instances" all on a single (physical) server.

past posts in thread:
https://www.garlic.com/~lynn/2008j.html#85 recent mentions of 40+ yr old technology
https://www.garlic.com/~lynn/2008k.html#45 recent mentions of 40+ yr old technology
https://www.garlic.com/~lynn/2008k.html#46 recent mentions of 40+ yr old technology
https://www.garlic.com/~lynn/2008k.html#52 recent mentions of 40+ yr old technology
https://www.garlic.com/~lynn/2008k.html#53 recent mentions of 40+ yr old technology
https://www.garlic.com/~lynn/2008k.html#55 recent mentions of 40+ yr old technology
https://www.garlic.com/~lynn/2008k.html#60 recent mentions of 40+ yr old technology
https://www.garlic.com/~lynn/2008l.html#11 recent mentions of 40+ yr old technology
https://www.garlic.com/~lynn/2008l.html#14 recent mentions of 40+ yr old technology

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

IBM-MAIN longevity

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM-MAIN longevity
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 01 Aug 2008 09:57:36 -0400
Anne & Lynn Wheeler <lynn@garlic.com> writes:
ULTRAMUX recognize alarm messages define status flags for various alarm messages when sync. is lost, include fireberd information in screen

re:
https://www.garlic.com/~lynn/2008l.html#16 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008l.html#17 IBM-MAIN longevity

one of the issues related to comment about internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet

having over half of all the link encryptors in the world ... as well as my annoyance with what I had to pay for link encryptors for T1 and higher speed links (resulted in working on design for some hardware that would handle encryption with a lot more function, at much higher rates, and built at much lower cost) ... was that encryption was very sensitive to bit-errors and sync loss ... and if there was some latency with ultramux recovery ... there was significantly longer delay getting the encryption units back in sync after bit-error or sync loss.

so besides looking at issues on how to better do encryption ... the other technology (somewhat driven by also having to do encryption) was having much better forward-error-correcting. There was a company up in Berkeley (Cyclotomics) that had specialized in reed-solomon ... and (among other things) had gotten involved in cdrom (encoding) standard ... that we started working with. Cyclotomics was soon after bought by Kodak. misc. past posts mentioning cyclotomics (and/or reed-solomon):
https://www.garlic.com/~lynn/2001.html#1 4M pages are a bad idea (was Re: AMD 64bit Hammer CPU and VM)
https://www.garlic.com/~lynn/2002p.html#53 Free Desktop Cyber emulation on PC before Christmas
https://www.garlic.com/~lynn/2003e.html#27 shirts
https://www.garlic.com/~lynn/2004f.html#37 Why doesn't Infiniband supports RDMA multicast
https://www.garlic.com/~lynn/2004o.html#43 360 longevity, was RISCs too close to hardware?
https://www.garlic.com/~lynn/2005n.html#27 Data communications over telegraph circuits
https://www.garlic.com/~lynn/2007.html#29 Just another example of mainframe costs
https://www.garlic.com/~lynn/2007j.html#4 Even worse than UNIX
https://www.garlic.com/~lynn/2007v.html#82 folklore indeed

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

IBM-MAIN longevity

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM-MAIN longevity
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 01 Aug 2008 13:08:34 -0400
Lars Poulsen <lars@beagle-ears.com> writes:
This was a good thing. The first network code we ran at ACC was a BBN enhancement to the version 7 unix on our PDP-11/70, and it was atrocious: Badly designed, badly implemented.

When we finally got a VAX with 4.2BSD, life got a lot better (and we crashed a lot less). A while after that, we got the Wollongong Group (later TGV) version of SRI's port of the BSD code to VMS, and that seemed at the time to be the best of many OS/network combinations.


for a short senior moment, I translated ACC to ACSC (another company in the LA area).

when we were doing ha/cmp product ... some past posts:
https://www.garlic.com/~lynn/subtopic.html#hacmp
and working on scale-up ... some old email from the period:
https://www.garlic.com/~lynn/lhwemail.html#medusa

we had been part of turning LLNL's Lincs into Unitree commercial product ... and we were paying ACSC to do some of the work.

slightly related to previous post about doing rfc1044 support (and doing performance tuning tests at cray research):
https://www.garlic.com/~lynn/subnetwork.html#1044

Date: Wed, 24 Feb 88 13:31:00 CST
From: Brick Verser <BAV%KSUVM>
Forum: IBMTCP-L DIGEST
Subject: Re: If you had to do it over again...

We just received an ACC ACS9310 to use with the FAL software. ACC has a software driver for the 9310 for version 1.0 of FAL, but it looks like it will need some work to get it to run on 1.1. We are currently waiting for the VS PASCAL compiler to arrive so we can start work on it (with the new release of FAL, VS/PASCAL no longer works, grumble, grumble).

The 9310 is cabled into the channel, and I've written a little assembler routine which does its own channel programming to simply read packets from the controller. It seems to do that just fine. But I can't say anything about throughput until we actually get VS PASCAL and can recompile and relink the driver into FAL.

The 9310 is built like a tank. It is also a single integrated box, unlike the 8232 which is an AT with add-on hardware. I'm sure it will work out well once we get the driver installed. ACC has been building ARPANET stuff for ages and got into the commerical game only in the last few years. The 9310 is the box of choice for MVS sites, it seems, and ACC finally has the software driver to make the 9310 work with FAL. The retail price of the 9310 is something like $29K, but until December 31, 1987 they were letting them go to NSFNET sites for $19K. That made it cheaper than the 8232, and I suspect it is faster and more reliable as well.
... snip ... top of post, old email index

note that 8232 was an industrial, rack-mount pc/at ... and numerous in the corporation wanted to sell them a lot closer to cost.

past posts in this thread:
https://www.garlic.com/~lynn/2008k.html#81 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008k.html#83 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008k.html#85 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008l.html#0 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008l.html#1 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008l.html#2 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008l.html#3 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008l.html#4 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008l.html#5 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008l.html#6 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008l.html#7 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008l.html#8 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008l.html#9 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008l.html#10 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008l.html#12 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008l.html#13 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008l.html#16 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008l.html#17 IBM-MAIN longevity
https://www.garlic.com/~lynn/2008l.html#19 IBM-MAIN longevity

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

recent mentions of 40+ yr old technology

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: recent mentions of 40+ yr old technology
Newsgroups: alt.folklore.computers
Date: Sat, 02 Aug 2008 09:18:40 -0400
jmfbahciv <jmfbahciv@aol> writes:
When will the security issue of sprawling to automatically to an insecure virtual server start to matter?

re:
https://www.garlic.com/~lynn/2008l.html#18 recent mentions of 40+ yr old technology

standard security processes are KISS and partitioning ... and/or partitioning helps with KISS; partitioning is also used to limit scope of breach. at least the more serious attackers have some sense of ROI ... going after the most return for the least effort. partitioning tends to at least maintain the level of the attackers effort while trying to drastically reducing the return.

also, vulnerabilities tend to be proportional to complexity.

virtualization provides quite a bit for effective partitioning and helps to contribute to KISS.

from an economic justification it has been reducing (and simplifying) number of physical components by an order of magnitude or more. there are attempts to leverage virtualization further by increasing the partitioning (i.e. virtual appliance).

part of the issue can be some level of administration based on pure physical things ... w/o actually understanding the operation of those things. I would claim that this is also related to issue with *orange book* security didn't deal well with interconnected components (networking) ... looking mostly at demonstrating security compliance within a disconnected operation.

A decade ago I gave a talk on electronic commerce for USC/ISI graduate student seminar and IETF RFC editor group ... where I claimed that much of the (tcp/ip) networking that evolved during the 80s and 90s was not *industrial strength* (also involved security related issues).

included was various compensating processes that we had to invent and/or mandate for the operation of the "payment gateway"
https://www.garlic.com/~lynn/subnetwork.html#gateway

one of the examples was about the time we were doing the payment gateway aspect of electronic commerce ... the largest online service provider was having internet related failures. this went on for two months (while they had some significant number of experts in the field in to look for solution). One of the people then flew out to the west coast and bought me a hamburger after work. While I ate the hamburger, he explained the symptoms. I then gave him a Q&D fix that he applied later that night.

I explained that it was one of the areas that we had identified during the ha/cmp product effort
https://www.garlic.com/~lynn/subtopic.html#hacmp

as part of ha/cmp, we had done detailed vulnerability studies ... including tcp/ip ... which involved both detailed review of standards (and RFCs) as well as detailed review of code (to both understand what the code was doing as well as what the standards were saying). Part of the issue were cracks/gaps that would be standard consideration as part of any real industrial strength (and/or business critical) effort.

Over the next several weeks, I approached the major vendors about needing to address the specific and related issues ... but there was no interest (possibly in part because the largest online service provider had no interest in publicizing the situation). Almost exactly a year later (to the date when somebody bought me a hamburger after work), the problem hit the press (at some other service provider) ... and then over the next month ... most of the vendors were publicly patting themselves on the back on how quickly they were patching the problem.

misc. past posts mentioning situation:
https://www.garlic.com/~lynn/2005c.html#51 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2006e.html#11 Caller ID "spoofing"
https://www.garlic.com/~lynn/2006i.html#6 The Pankian Metaphor
https://www.garlic.com/~lynn/2008b.html#34 windows time service

for other drift ... past posts mentioning fraud/attackers ROI
https://www.garlic.com/~lynn/aadsm10.htm#bio6 biometrics
https://www.garlic.com/~lynn/aadsm14.htm#4 Who's afraid of Mallory Wolf?
https://www.garlic.com/~lynn/aadsm17.htm#2 Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
https://www.garlic.com/~lynn/aadsm17.htm#47 authentication and authorization ... addenda
https://www.garlic.com/~lynn/aadsm17.htm#60 Using crypto against Phishing, Spoofing and Spamming
https://www.garlic.com/~lynn/aadsm18.htm#45 Banks Test ID Device for Online Security
https://www.garlic.com/~lynn/aadsm19.htm#13 What happened with the session fixation bug?
https://www.garlic.com/~lynn/aadsm19.htm#17 What happened with the session fixation bug?
https://www.garlic.com/~lynn/aadsm19.htm#26 Trojan horse attack involving many major Israeli companies, executives
https://www.garlic.com/~lynn/aadsm19.htm#45 payment system fraud, etc
https://www.garlic.com/~lynn/aadsm23.htm#34 Chip-and-Pin terminals were replaced by "repairworkers"?
https://www.garlic.com/~lynn/aadsm26.htm#35 Failure of PKI in messaging
https://www.garlic.com/~lynn/aadsm28.htm#60 Seeking expert on credit card fraud prevention - particularly CNP/online transactions
https://www.garlic.com/~lynn/aadsm28.htm#73 "Designing and implementing malicious hardware"
https://www.garlic.com/~lynn/99.html#172 checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#44 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2003o.html#35 Humans
https://www.garlic.com/~lynn/2004.html#29 passwords
https://www.garlic.com/~lynn/2004b.html#39 SSL certificates
https://www.garlic.com/~lynn/2005i.html#1 Brit banks introduce delays on interbank xfers due to phishing boom
https://www.garlic.com/~lynn/2005p.html#25 Hi-tech no panacea for ID theft woes
https://www.garlic.com/~lynn/2006h.html#26 Security
https://www.garlic.com/~lynn/2007.html#5 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#11 Decoding the encryption puzzle
https://www.garlic.com/~lynn/2007l.html#40 My Dream PC -- Chip-Based
https://www.garlic.com/~lynn/2007o.html#27 EZPass: Yes, Big Brother IS Watching You!
https://www.garlic.com/~lynn/2008e.html#69 independent appraisers
https://www.garlic.com/~lynn/2008g.html#27 Hannaford case exposes holes in law, some say

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

dollar coins

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: dollar coins
Newsgroups: alt.folklore.computers
Date: Sat, 02 Aug 2008 09:46:33 -0400
jmfbahciv <jmfbahciv@aol> writes:
One of their last actions was to OK more millions for the Mass. Turnpike Authority to borrow. The intention is to sell bonds so they can pay off the bonds that have a high interest rate. Do you really believe that those bonds will get retired? I don't. It's not clear that the legislation that was passed made it impossible to not use the funds for something else.

i thot that reason for toll on mass. turnpike was to pay off the original construction bonds. when that happened, i understood that they decided to continue the tolls to cover maintenance costs so they wouldn't need additional bonds.

when i 1st moved to mass., i heard jokes about use of water soluble asphalt, effectively as part of ongoing subsidy to road construction companies. recent reference
https://www.garlic.com/~lynn/2008k.html#73 Cormpany sponsored insurance

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Memories of ACC, IBM Channels and Mainframe Internet Devices

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Memories of ACC, IBM Channels and Mainframe Internet Devices
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 02 Aug 2008 10:11:51 -0400
Lars Poulsen <lars@beagle-ears.com> writes:
A different group developed the ACS-9310, which was based on an already existing Versabus chassis developed for a government contract, and for which we had a MC68000 CPU board with an ethernet jack, as well as a BBN-1822 board. For this project we did a 360-channel interface board, and an embedded software project called VIA-FD (Versabus Internet Access Feasibility Demonstration). I think the customer for this was in fact IBM Federal Systems Division.

recent post about doing 360-channel interface board ... possibly two decades earlier
https://www.garlic.com/~lynn/2008k.html#65 Crippleware: hadware examples

as part of doing a plug-compatible/clone controller ... other past posts
https://www.garlic.com/~lynn/submain.html#360pcm

this was written up, blaming four of us for the plug-compatible/clone controller business.

this post
https://www.garlic.com/~lynn/2008d.html#16 more on (the new 40+ yr old) virtualization

cites reference
https://www.ecole.org/en/session/49-the-rise-and-fall-of-ibm
https://www.ecole.org/en/session/49-the-rise-and-fall-of-ibm

attributing much of the motivation for the (failed) future system effort was the plug-compatible/clone controller business
https://www.garlic.com/~lynn/submain.html#futuresys

this older post
https://www.garlic.com/~lynn/2001f.html#33 IBM's "VM for the PC" c.1984?

has reference to Morris/Fergus book about the failure of the future system effort having long-term detrimental effects on the company. It possibly also wasn't career enhancing, that at the time, I had poked fun at the effort drawing comparisons with a cult film playing down the street in central sq.

i've also made recent references
https://www.garlic.com/~lynn/2008i.html#18 Microsoft versus Digital Equipment Corporation
https://www.garlic.com/~lynn/2008k.html#21 IBM's 2Q2008 Earnings

that it appeared much of John's motivation for 801/risc appeared to be something that was the exact opposite in hardware complexity to what went on in the future system effort. misc. past posts mentioning 801/risc
https://www.garlic.com/~lynn/subtopic.html#801

i've also made past posts that when we were doing hsdt project
https://www.garlic.com/~lynn/subnetwork.html#hsdt

we got involved in doing a "clone" controller with significant more feature/function (but from within the company) ... old reference:
https://www.garlic.com/~lynn/99.html#67 System/1 ?
https://www.garlic.com/~lynn/99.html#70 Series/1 as NCP (was: Re: System/1 ?)

which drew the ire of the communication's division. The above started out with an implementation currently running on a Series/1 ... but the product plans involved quickly moving it to 801/risc (significantly increasing the thruput and price/performance).

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

dollar coins

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: dollar coins
Newsgroups: alt.folklore.computers
Date: Sat, 02 Aug 2008 10:24:46 -0400
jmfbahciv <jmfbahciv@aol> writes:
All of a sudden, the Turnpike Authority is billions in debt and in a fiscal crisis. The governor, a Democrat, is trying to put back all the toll booths that the Republican governors eliminated. What a wonderful idea. Install more stops and traffic snarls and backups and traffic blocks so that more gas can be burned sitting in state-imposed parking lots, a.k.a. roads.

re:
https://www.garlic.com/~lynn/2008k.html#73 Cormpany sponsored insurance
https://www.garlic.com/~lynn/2008l.html#22 dollar coins

there was serious business news show commentary yesterday that the reason that the transportaion infastructure is in such a bad state (i.e. 30 yrs or so of not doing adequate maintenance) is because that since May, driving is down and so for the past couple months, the governments haven't been collecting as much fuel taxes. they seem to be tying it in with the 1yr anniversary of the collapse of the interstate bridge (and possibly the reduction in fuel taxes for the last couple months somehow contributed to the bridge collapse).

my 1st exposure to the mass. turnpike was a winter x-country drive from the west coast ... and running into masspike speed limit reduced to 30mph because of "frost heaves" ... which was something that wasn't found in western county mountain roads (i.e. western state county roads built to higher standards than interstate in mass)

misc. past posts mentioning frost heaves on massspike:
https://www.garlic.com/~lynn/99.html#22 Roads as Runways Was: Re: BA Solves Y2K (Was: Re: Chinese Solve Y2K)
https://www.garlic.com/~lynn/2002i.html#28 trains was: Al Gore and the Internet
https://www.garlic.com/~lynn/2002i.html#35 pop density was: trains was: Al Gore and the Internet
https://www.garlic.com/~lynn/2002i.html#36 pop density was: trains was: Al Gore and the Internet
https://www.garlic.com/~lynn/2002j.html#42 Transportation
https://www.garlic.com/~lynn/2002j.html#68 Killer Hard Drives - Shrapnel?
https://www.garlic.com/~lynn/2003j.html#11 Idiot drivers
https://www.garlic.com/~lynn/2006h.html#45 The Pankian Metaphor

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

dollar coins

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: dollar coins
Newsgroups: alt.folklore.computers
Date: Sat, 02 Aug 2008 10:57:37 -0400
Anne & Lynn Wheeler <lynn@garlic.com> writes:
there was serious business news show commentary yesterday that the reason that the transportaion infastructure is in such a bad state (i.e. 30 yrs or so of not doing adequate maintenance) is because that since May, driving is down and so for the past 3 months, the governments haven't been collecting as much fuel taxes. they seem to be tying it in with the 1yr anniversary of the collapse of the interstate bridge (and possibly the reduction in fuel taxes for the last three months somehow contributed to the bridge collapse).

re:
https://www.garlic.com/~lynn/2008l.html#24 dollar coins

some of this might also be considered a side-effect of not accurately pricing/charging based on costs.

past posts have mentioned that basic road design (and much of construction cost) is predicated on projected heavy truck (18 wheeler) axle-loads and nearly all wear&tear (also therefor maintenance costs is based on heavy truck (18 wheeler) axle-loads.

however, significant portion of funds comes from fuel road-use tax paid by vehicles that aren't heavy trucks (i.e. use by vehicles which don't contribute to road design/contrustion costs and/or contribute to road wear&tear maintenace costs).

my conjecture is that majority of the reduction in fuel use and therefor drop in road-use taxes are from vehicles that aren't heavy trucks. The issue is that while that is a significant hit to funds for road construction & maintenace ... it doesn't affect the heavy truck axle-loads which is the basis for construction and maintenance costs.

conjecture in thread (in this n.g.) from couple years ago on the subject ... was when the source of funding wasn't directly proportional to use ... such discontinuity/disconnect could result in all sorts of subsequent problems (i.e. current situation when there is significant drop in funds w/o a corresponding significant drop in the use that result in the majority of costs).

past posts mentioning heavy truck axle/load as the major factor in road construction and maintenance costs:
https://www.garlic.com/~lynn/2002j.html#41 Transportation
https://www.garlic.com/~lynn/2006g.html#5 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#6 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#10 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#12 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#15 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#19 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#24 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#26 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#32 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#35 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#46 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#48 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#49 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#50 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#51 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#52 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#53 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#54 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#56 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#57 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#59 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#60 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#61 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#62 The Pankian Metaphor
https://www.garlic.com/~lynn/2006h.html#0 The Pankian Metaphor
https://www.garlic.com/~lynn/2006h.html#5 The Pankian Metaphor
https://www.garlic.com/~lynn/2006h.html#6 The Pankian Metaphor
https://www.garlic.com/~lynn/2006h.html#11 The Pankian Metaphor
https://www.garlic.com/~lynn/2006h.html#23 The Pankian Metaphor
https://www.garlic.com/~lynn/2006p.html#2 Overweight truckers stopped by tech checks
https://www.garlic.com/~lynn/2007n.html#97 Loads Weighing Heavily on Roads
https://www.garlic.com/~lynn/2008b.html#55 Toyota Sales for 2007 May Surpass GM
https://www.garlic.com/~lynn/2008e.html#48 fraying infrastructure
https://www.garlic.com/~lynn/2008k.html#68 Historian predicts the end of 'science superpowers'

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

dollar coins

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: dollar coins
Newsgroups: alt.folklore.computers
Date: Sat, 02 Aug 2008 13:35:51 -0400
CBFalconer <cbfalconer@yahoo.com> writes:
I think you will find that the crucial factor in frost-heaves is the water content of the soil. I suspect there is a large difference between Mass. and the west in this. The temperature has little to do with it (apart from being below freezing).

frost heaves come from having water in the soil ... frequently underground streams and/or run-off (as opposed to things like humidity).

whether a road actually has frost heaves is whether it has been designed to handle forst heaves (aka things like drainage and sufficient road bed as countermeasure to damp/freezing underground).

there was some joke/speculation by the people in mass. wasn't that the soil moisture under the road bed was different ... it was whether drainage and road bed was adequately prepared.

Actually some of the jokes about mass pike were a little more caustic ... possibly hiring a farmer to plow a swath ... and then running asphalt paving machine over the plowed ground (which is obviously a scenario where if the underlying soil got wet and froze ... there would be frost heaves)

as in previous post
https://www.garlic.com/~lynn/2008l.html#24 dollar coins

past posts mentioning frost heaves and there are road construction road bed standards to prevent frost heaves from affecting the road:
https://www.garlic.com/~lynn/99.html#22 Roads as Runways Was: Re: BA Solves Y2K (Was: Re: Chinese Solve Y2K)
https://www.garlic.com/~lynn/2002i.html#28 trains was: Al Gore and the Internet
https://www.garlic.com/~lynn/2002i.html#35 pop density was: trains was: Al Gore and the Internet
https://www.garlic.com/~lynn/2002i.html#36 pop density was: trains was: Al Gore and the Internet
https://www.garlic.com/~lynn/2002j.html#42 Transportation
https://www.garlic.com/~lynn/2002j.html#68 Killer Hard Drives - Shrapnel?
https://www.garlic.com/~lynn/2003j.html#11 Idiot drivers
https://www.garlic.com/~lynn/2006h.html#45 The Pankian Metaphor

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

dollar coins

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: dollar coins
Newsgroups: alt.folklore.computers
Date: Sat, 02 Aug 2008 13:43:54 -0400
CBFalconer <cbfalconer@yahoo.com> writes:
I think you will find that the crucial factor in frost-heaves is the water content of the soil. I suspect there is a large difference between Mass. and the west in this. The temperature has little to do with it (apart from being below freezing).

re:
https://www.garlic.com/~lynn/2008l.html#26 dollar coins

other caustic remarks were about western state county roads being built to better standards than mass. interstate ... but that also went along with the jokes about the use of water soluble asphalt.

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Verifying Verified By Visa - Registration breaks chain of trust

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Verifying Verified By Visa - Registration breaks chain of trust
Newsgroups: uk.finance,comp.security.misc
Date: Sat, 02 Aug 2008 15:14:41 -0400
David Woolley <david@ex.djwhome.demon.co.uk.invalid> writes:
Note. A similar problem arises with many e-commerce sites which use an unknown service (their ISP?) for credit card processing, but the main risk there tends to be that authentication doesn't guarantee the company is trustworthy.[C]

we were brought to consult with small client/server company that wanted to do payment transactions on their server and had this technology they had invented called SSL they wanted to use ... the result is now frequently referred to as electronic commerce. Part of what was done was something called a payment gateway ... and we mandated some amount of the usage interface between the webservers and the payment gateway ... including implementing something called "mutual authentication" (which didn't exist at the time). misc. past posts mentioning payment gateway for electronic commerce
https://www.garlic.com/~lynn/subnetwork.html#gateway

we also did detailed protocol and business process walk thru of SSL, digital certificates and these new businesses calling themselves certification authorities.

for the payment gateway process, SSL mutual authentication evolved to the point where it was apparent that digital certificates were redundant and superfluous ... and there use was just a side-effect of using the existing SSL software library ... aka the payment gateway had table of all authorized webservers and each webserver had table with details about the payment gateway (so obtaining the corresponding public key from a digital certificate was superfluous).

also, at the time, the use of SSL domain name authentication ... by clients were based on some business process assumptions ... in order to result in:
the webserver that a client is interacting with ... is the webserver that they think they are interacting with

aka

1) the client understood that relationship between the server they wanted to talk to and the server's URL

2) the client supplied the URL to the browser

3) the browser validated the digital certifcate obtained from the server

4) the browser validated the URL corresponded with the URL in the (validated) digital certificate

misc. past posts mentioning SSL domain name digital certficates and/or domain name digital certification
https://www.garlic.com/~lynn/subpubkey.html#sslcerts

Almost immediately electronic commerce webservers discouvered that SSL cut their thruput significantly and they dropped back to using SSL just for payment/checkout. This created a large disconnect in the assumption about the SSL business process and the associated integrity/security that it provided. No longer was SSL being used to validate the URL provided for initial contact.

The payment/checkout paradigm has the (typically completely unvalidated) webserver making claims about a button that is clicked on. The client clicks on a button which results in the webserver supplying a URL to the browser (not the client). This now typically creates a huge disconnect between the webserver that a client thinks they are talking to and the associated URL.

Since the browser is only validating that the authenticated supplied digital certificate corresponds to the supplied URL (not by the client but by the webserver that hasn't been authenticate) ... SSL typical is now
the webserver that a client is interacting with ... is the webserver that the webserver claims to be

There is a huge difference between validating that the webserver is the webserver the client believes it to be vis-a-vis validating that the webserver is the webserver that it claims to be.

This is also at the root of phishing vulnerabilities ... an email has verbage saying clicking on a button takes the client to a banking webserver ... the actual URL is for some webserver under control of an attacker ... who has applied for and obtained a valid domain name digital certificate for that webserver (proving that the webserver is the valid webserver for that URL).

The critical issue in the original SSL deployment was that the client knew & understood the relationship between the webserver they believed they were talking to and that webserver's (SSL validated) URL. That has become increasingly rare in the current environment.

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Verifying Verified By Visa - Registration breaks chain of trust

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Verifying Verified By Visa - Registration breaks chain of trust
Newsgroups: uk.finance,comp.security.misc
Date: Sat, 02 Aug 2008 15:41:51 -0400
Anne & Lynn Wheeler <lynn@garlic.com> writes:
This is also at the root of phishing vulnerabiilties ... an email has verbage saying clicking on a button takes the client to a banking webserver ... the actual URL is for some webserver under control of an attacker ... who has applied for and obtained a valid domain name digital certificate for that webserver (proving that the webserver is the valid webserver for that URL).

re:
https://www.garlic.com/~lynn/2008l.html#28 Verifying Verified By Visa - Registration breaks chain of trust

an email phishing countermeasure has been if the area to be clicked on (i.e. between the ">" after the href URL and the "</a>") looks to be a URL ... then the email client checks if the purported claimed URL matches the actual URL in the href. A simple work-around/countermeasure (by the attackers) is to not display anything that resembles a URL ... so there is nothing to match on.

However, i've seen cases (for at least some email clients) ... where they take the hostname from what appears to be a displayed URL ... and do a string compare against the hostname in the actual href URL ... and it is treated as valid, even if the attackers are using a much longer hostname (that just has a prefix part that matches the hostname part of what is displayed).

the URL may or may not be a HTTPS/SSL connection. However, even if it is a SSL connection ... all the attackers need to have done is to obtain a SSL digital certificate proving that the actual provided URL (in the HREF, not what is displayed) is a valid URL.

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Verifying Verified By Visa - Registration breaks chain of trust

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Verifying Verified By Visa - Registration breaks chain of trust
Newsgroups: uk.finance,comp.security.misc
Date: Sat, 02 Aug 2008 15:59:18 -0400
David Woolley <david@ex.djwhome.demon.co.uk.invalid> writes:
Which is why banks should be encouraging people to challenge any unexpected domain name, rather than making unannounced domain name switches themselves (but they also use other bad practices, like using scripting)

re:
https://www.garlic.com/~lynn/2008l.html#28 Verifying Verified By Visa - Registration breaks chain of trust
https://www.garlic.com/~lynn/2008l.html#29 Verifying Verified By Visa - Registration breaks chain of trust

then you probably aren't going to like:

Huge rise in fraud against UK banks
http://www.vnunet.com/vnunet/news/2222850/fraud-against-uk-banks-rise-kpmg
Bank fraud rockets in wake of credit crunch
http://www.inthenews.co.uk/money/manchester-united/features/bank-fraud-rockets-in-wake-credit-crunch-$1233892.htm
Banks hardest hit by fraudsters in 2008
http://www.channelweb.co.uk/crn/news/2222802/banks-hardest-hit-fraudsters
Major fraud against banks soars
http://www.computerweekly.com/Articles/2008/07/29/231676/major-fraud-against-banks-soars.htm
US Web Banking Full of Security Flaws - Three out of four financial
institutions have security related issues
http://news.softpedia.com/news/US-Web-Banking-Full-of-Security-Flaws-90860.shtml
Study Claims Majority of Web Banking Sites Insecure
http://www.epaynews.com/index.cgi?survey=&ref=browse&f=view&id=1217276924837016561&block=
UK banks hit by record fraud levels
http://www.finextra.com/fullstory.asp?id=18791
e-banking cybercrime
http://www.securitypark.co.uk/security_article261863.html
Security shocker: 75% of US Bank websites have flaws
http://www.theregister.co.uk/2008/07/25/bank_sites_insecure/
Three in Four Banks Exposed to Fraud Online: U Mich study
http://www.financetech.com/news/showArticle.jhtml?articleID=211100066
e-banking not yet secure
http://attrition.org/pipermail/dataloss/2008-July/002565.html
Study on Bank Site Security Design Flaws
http://bankwebsecurity.blogspot.com/
Banks warned of computer 'super bug' that can change identity
http://business.scotsman.com/bankinginsurance/Banks-warned-of-computer-39super.4328710.jp
Web banking security flaws 'widespread'
http://www.vnunet.com/vnunet/news/2222561/security-flaws-widespread-web
It's reality: legitimate websites are no longer safe (security breach)
http://www.securecomputing.net.au/News/117708,its-reality-legitimate-websites-are-no-longer-safe.aspx
Design flaws, besides vulnerabilities, hurt banking sites
http://www.networkworld.com/news/2008/080508-eleven-charged-in-massive-id.html
Study finds bank websites vulnerable to hackers
http://www.latimes.com/business/la-fi-bankweb24-2008jul24,0,1619927.story
Design flaws impair security at banking sites
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9110549&source=NLT_AM&nlid=1
Online Banking: Widespread Security Flaws Revealed
http://www.livescience.com/technology/080723-online-banking.html
Three out of four banking websites have serious security flaws - study
http://www.tgdaily.com/content/view/40079/113/
Widespread Flaws In Online Banking Security Found
http://www.redorbit.com/news/technology/1491509/widespread_flaws_in_online_banking_security_found/index.html
Online Banking Security Flaws
http://www.technologynewsdaily.com/node/10099
Security flaws in online banking sites found to be widespread
http://www.physorg.com/news136023039.html
Summary Box: Study sees online banking flaws
http://news.yahoo.com/s/ap/20080723/ap_on_hi_te/tec_banking_security_summary_box
Studies: Banking Web sites, corporate computers are insecure
http://news.yahoo.com/s/cnet/20080723/tc_cnet/830110093999810683
Study: Online banking possibly dicier than assumed
http://news.yahoo.com/s/ap/tec_banking_security
Most Bank Websites Are Insecure
http://it.slashdot.org/it/08/07/24/1227230.shtml
Design Flaws, Besides Vulnerabilities, Hurt Banking Sites
http://www.pcworld.com/businesscenter/article/148790/design_flaws_besides_vulnerabilities_hurt_banking_sites.html
Design Flaws, Besides Vulnerabilities, Hurt Banking Sites
http://news.yahoo.com/s/pcworld/20080723/tc_pcworld/148790
Researchers Find Security Flaws In Online Banking Sites
http://www.consumeraffairs.com/news04/2008/07/online_banking.html
Design flaws impair security at banking sites
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9110549
Most Bank Sites Are Insecure
http://www.informationweek.com/news/security/antivirus/showArticle.jhtml?articleID=227700363
Study: websites of financial institutions insecure by design
http://arstechnica.com/news.ars/post/20080723-study-websites-of-financial-institutions-insecure-by-design.html
Study: Online banking possibly dicier than assumed
http://www.sfgate.com/cgi-bin/article.cgi?f=/n/a/2008/07/23/financial/f120506D22.DTL

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Authentication in the e-tailer / payment gateway / customer triangle

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Authentication in the e-tailer / payment gateway / customer triangle
Newsgroups: uk.finance,comp.security.misc
Date: Sat, 02 Aug 2008 17:14:17 -0400
David Woolley <david@ex.djwhome.demon.co.uk.invalid> writes:
What you haven't said, but must be the case, is that, if they don't have public keys, they must have shared-secrets. preferably a bit stronger than the last transaction number, and information that is secure by obscurity.

re:
https://www.garlic.com/~lynn/2008l.html#28 Verifying Verified By Visa - Registration breaks chain of trust
https://www.garlic.com/~lynn/2008l.html#29 Verifying Verified By Visa - Registration breaks chain of trust
https://www.garlic.com/~lynn/2008l.html#30 Verifying Verified By Visa - Registration breaks chain of trust

I didn't say they didn't have public keys ... i claimed that the digital certificates were redundant and superfluous.

for some topic drift ... the original public key draft for Kerberos was certificate-less ... with digital certificate specification added later (kerberos is a widely used authentication infrastructure available on mainly platforms, including windows)
https://www.garlic.com/~lynn/subpubkey.html#kerberos

there have also been certificate-less public key implementations dones for RADIUS ... a widely used authentication mechanism used by ISPs and corporate intranets ... frequently the mechanisms found at the server end of PPP connections
https://www.garlic.com/~lynn/subpubkey.html#radius

misc. posts mentioning public key & digital signature authentication w/o requiring digital certificates
https://www.garlic.com/~lynn/subpubkey.html#certless

in the certification authority model ... a public key is generated and a certification authority does some validating about the entity associated with the public key and other information associated with the entity. it then issues a digital signed digital certificate (including the entity's public key and the associated information).

this is part of the process that we long ago and far away audited ... when the organizations calling themselves certification authorities were new & young.

however, for this to work ... a browser (or other application) has a built-in table of public keys (belonging to certification authorities) that are used to validate/authenticate the (certification authorties) digital signature on the digital certificate ... as the step where the browser/application "validates" the digital certificate (before trusting/making use of the public key included in the digital certificate).

so the payment gateway provides its public key directly to the webservers as part of all the other stuff that the payment gateway provides to the webserver for correct operation. each webserver provides their public key to the entity operating the payment gateway (as part of a whole lot of other information that they need to provide). the exchanged public keys are kept in tables in much the same way that browsers keeps a table of (trusted) certification authority public keys.

involving an independent (redundant and superfluous) 3rd party certification authority in the process, is redundant and superfluous and the digital certificates that they issue are then also redundant and superfluous.

the digital certficate scenario is the electronic analogy to letters of credit/introduction from the sailing ship days when the relying party had first time encounter with complete stranger and had no other recourse to information about the stranger they were dealing with.

the digital certificate design point is the offline email paradigm from the early 80s; the electronic postoffice is dialed, email exhanged, connection is broken ... and there is first-time communcation between a complete stranger. In the absence of any other mechanism for information about the stranger, a digital certificate can be better than nothing.

after having realized that digital certificates were redundant and superfluous in situations where the parties already have information about each other and/or have online access to information about each other ... which was part of setting up payment gateway for electronic commerce
https://www.garlic.com/~lynn/subnetwork.html#gateway

we were brought in to the x9a10 financial standard working group that had been given the requirement to preserve the integrity of the financial infrastructure for all retail transactions ... which resulted in the x9.59 financial standard
https://www.garlic.com/~lynn/x959.html#x959

some of the other financial transactions efforts going on in that period (that also involved public key) ... were heavily steeped in digital certificates. a serious roadblock for them was that the digital certificate paradigm increased the typical payment transaction size by a factor of 100 times as well as increasing the processing overhead by a factor of 100 times. misc. past posts mentioning the enormous bloat that (redundant and superfluous) digital certificates represented for payment transactions
https://www.garlic.com/~lynn/subpubkey.html#bloat

the x9a10 financial standard working group had been given the requirement to preserve the integrity of the financial infrasturcture for ALL retail transactions ... and so we had a lot of payload size, transaction processing overhead and protocol chatter constraints that other efforts simply ignored.

for other topic drift ... recent posts in crypto mailing list regarding certificate-less public key in the DNSSEC scenario and a hypothetical superfast SSL "lite"
https://www.garlic.com/~lynn/2008k.html#48 The PKC-only application security model
https://www.garlic.com/~lynn/2008k.html#49 The PKC-only application security model
https://www.garlic.com/~lynn/2008k.html#51 The PKC-only application security model
https://www.garlic.com/~lynn/2008k.html#54 The PKC-only application security model

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Authentication in the e-tailer / payment gateway / customer triangle

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Authentication in the e-tailer / payment gateway / customer triangle
Newsgroups: uk.finance,comp.security.misc
Date: Sat, 02 Aug 2008 17:38:51 -0400
David Woolley <david@ex.djwhome.demon.co.uk.invalid> writes:
Note that, because the internet is vulnerable to man in the middle attacks, you cannot safely negotiate session keys without simultaneously authenticating, even though I believe the SSL libraries allow this. That authentication can be done with symmetric keys, and in the extreme case, authentication can simply be the result of using the master key without negotiating a session key.

re:
https://www.garlic.com/~lynn/2008l.html#28 Verifying Verified By Visa - Registration breaks chain of trust
https://www.garlic.com/~lynn/2008l.html#29 Verifying Verified By Visa - Registration breaks chain of trust
https://www.garlic.com/~lynn/2008l.html#30 Verifying Verified By Visa - Registration breaks chain of trust
https://www.garlic.com/~lynn/2008l.html#31 Authentication in the e-tailer / payment gateway / customer triangle

for other topic drift, lots of past posts discussing man-in-the-middle attacks
https://www.garlic.com/~lynn/subintegrity.html#mitm

one of the scenarios about certificate-less operation
https://www.garlic.com/~lynn/subpubkey.html#certless

is that the table of trusted (certification authorities) public keys preloaded in browsers and PGP tables of trusted public keys are effectively the same mechanism ... they are directly trusted public keys.

certification authorities and digital certificates provide a mechanism for indirect trust (ala letters of credit/introduction model from sailing ship days) when there is no other source for the information.

for other topic drift ... part of recent thread in crypto mailing list and (uk) financial crypto blog about historical pgp (and certificate-less public key)
https://www.garlic.com/~lynn/2008i.html#86 Own a piece of the crypto wars
https://www.garlic.com/~lynn/2008i.html#87 Historical copy of PGP 5.0i for sale -- reminder of the war we lost

there is archeological reference/copy of old email from '81
https://www.garlic.com/~lynn/2006w.html#email810515

for a (certificate-less) pgp-like implementation ... approx. decade before pgp.

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Authentication in the e-tailer / payment gateway / customer triangle

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Authentication in the e-tailer / payment gateway / customer triangle
Newsgroups: uk.finance,comp.security.misc
Date: Sat, 02 Aug 2008 18:00:16 -0400
David Woolley <david@ex.djwhome.demon.co.uk.invalid> writes:
It is also important that significant information about the transaction is reconfirmed in the authenticated part of the transaction - in particular transaction value (as a limit on risk) and delivery address, although the details of the order are also a good idea.

re:
https://www.garlic.com/~lynn/2008l.html#28 Verifying Verified By Visa - Registration breaks chain of trust
https://www.garlic.com/~lynn/2008l.html#29 Verifying Verified By Visa - Registration breaks chain of trust
https://www.garlic.com/~lynn/2008l.html#30 Verifying Verified By Visa - Registration breaks chain of trust
https://www.garlic.com/~lynn/2008l.html#31 Authentication in the e-tailer / payment gateway / customer triangle
https://www.garlic.com/~lynn/2008l.html#32 Authentication in the e-tailer / payment gateway / customer triangle

there is overlap in this area between x9.59 financial transaction standard (usable with certificate-less public key) ... references
https://www.garlic.com/~lynn/x959.html#x959

and the EU FINREAD standard ... misc. past posts discussing issues and objectives of the EU FINREAD standard
https://www.garlic.com/~lynn/subintegrity.html#finread

... i.e. how do you know that the transaction being digitally signed is really the transaction that you think it is.

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Authentication in the e-tailer / payment gateway / customer triangle

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Authentication in the e-tailer / payment gateway / customer triangle
Newsgroups: uk.finance,comp.security.misc
Date: Sat, 02 Aug 2008 20:13:04 -0400
David Woolley <david@ex.djwhome.demon.co.uk.invalid> writes:
Further topic drift: there are other flaws in the certificate system in that, by default, browsers come with all certificates enabled, but some represent higher levels of verification than others. As the level of trust for some interactions may differ from that for others, one would really need to check the issuer on every access needing more than minimal authentication. That's mainly dumbing down, but it has been suggested that you can basically buy the right to have a root certificate in a browser. I think very few browser users realize that not all certificates are alike.

there have been several discussions over the past decade on the vulnerabiilty of the infrastructure when all certification authorities are treated the same. simplest scenario is that if the probability of any particular certification authority is X/year and there are 100 loaded certification authority public keys ... then a compromise of any specific one (compromising the whole infrastructure) is 100*x/year.

One issue raised is what happens if a certification authority goes out of business, what is the assurance of the associated private keys.

as discussed in this scenario
https://www.garlic.com/~lynn/2008k.html#48 The PKC-only application security model
https://www.garlic.com/~lynn/2008k.html#49 The PKC-only application security model
https://www.garlic.com/~lynn/2008k.html#51 The PKC-only application security model
https://www.garlic.com/~lynn/2008k.html#54 The PKC-only application security model

mentioned in earlier post
https://www.garlic.com/~lynn/2008l.html#32 Authentication in the e-tailer / payment gateway / customer triangle

is the ssl domain name certification authority catch-22
https://www.garlic.com/~lynn/subpubkey.html#catch22

Basically, some number of the SSL domain name certification authorities were supporting DNSSEC operation ... for a couple of reasons.

1) the original SSL domain name digital certificates were, in part, justified based on perceived weaknesses in the domain name infrastructure. However, the SSL domain name certification authorities rely on the integrity of the domain name infrastructure as to the "true" owner of a domain (when validating requests for SSL domain name digital certificates). Part of the DNSSEC scenario would include having domain name applicants to register a public key as part of registering a domain name. Then future communication would be digitally signed (authenticated with the on-file public key), minimizing vulnerabilities like domain name hijacking. This improves the trust that certification authority can correctly identify the true owner of a domain .... and validating that the true owner is applying for an SSL domain name digital certificate i.e. a fundamental basic trust issue for ssl domain name digital certificate resides in whether the domain name infrastructure correctly maintains the true owner of the domain name.

2) the current SSL domain name digital certificate process requires the certification authority to perform the expensive, time-consuming, and error-prone process of verifying that the digital certificate applicant is the same as the owner on-file with the domain name infrastructure. With an on-file public key, the certification authorities, can require that SSL digital certificate applications be digitally signed. They then could do a real-time retrieval of the on-file public key and turn an error-prone, time-consuming, and expensive verification process into a much simpler, less-expensive and reliable authentication process.

this creates the catch-22, since if the certification authorities can do real-time retrieval of on-file public key ... then it is possible that the rest of the world could also.

the scenario is that a standard DNS host->ip-address lookup would optionally piggy-back a (on-file) public key (and potentially other crypto negotiation options) in the responseresponse. Then an extremely lightweight SSL ... has the client generating the random secret key, encoding it with the server's public key and encrypting the initial communication ... from the start (bypassing all the SSL protocol setup chatter).

For additional topic drift ... in the 80s ... we had been involved in both the NSFNET backbone activity ... some old email
https://www.garlic.com/~lynn/lhwemail.html#nsfnet
and various posts
https://www.garlic.com/~lynn/subnetwork.html#nsfnet

and we were also on the XTP technical advisery board ... which was looking at a highly efficient reliable protocol ... that would support both efficient reliable transaction operation (minimum packet exchange of 3 packets ... compared to minimum packet exchange of 7 packets for TCP) as well as multicast and some number of other features. There was also an attempt to get (ASC) X3S3.3 (us chartered organization for standards involving the area around level 3 & level 4 in the OSI networking model) ... misc. past posts
https://www.garlic.com/~lynn/subnetwork.html#xtphsp

So in XTP terms (having access to the server's public key, either cached from some previous interaction and/or piggy-backed on recent name->ip-address response), a full reliable transaction SSL-lite could be done in the 3-packet minimum exchange ... piggybacking the first packet with the public key encoded random secret (session/transaction) key on the encrypted transaction.

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Quality of IBM school clock systems?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Quality of IBM school clock systems?
Newsgroups: alt.folklore.computers
Date: Sat, 02 Aug 2008 20:34:17 -0400
krw <krw@att.bizzzzzzzzzz> writes:
Indeed. At my CPOE (for another week) I'm surprised we're allowed to have them; classified contracts and all. Cameras aren't permitted (except cell phones, but we're admonished not to use the cameras [*]) but I can swipe an entire project on a stick. At the PPOE, the entire PowerPC 970 design easily fit on a stick. Some did carry it around in their pocket. I just carried my piece (Instruction Sequencing Unit). ;-)

FBI: Flash drive used to steal Countrywide customer data
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9111438

from above:
Using his computer at work, he saved the customer data onto his own flash drives to remove it from the office, the FBI alleges.

... snip ...

... he was arrested for stealing the customer data and then selling it.

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

dollar coins

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: dollar coins
Newsgroups: alt.folklore.computers
Date: Sun, 03 Aug 2008 00:34:59 -0400
ArarghMail808NOSPAM writes:
And the last time I was on I-70, in Ohio, it would have done a roller coaster proud, with all the broken up pavement.

as past posts, nearly all of this is heavy truck usage ... modulo not doing basic design and engineering for things like frost heaves.
https://www.garlic.com/~lynn/99.html#22 Roads as Runways Was: Re: BA Solves Y2K (Was: Re: Chinese Solve Y2K)
https://www.garlic.com/~lynn/2002i.html#28 trains was: Al Gore and the Internet
https://www.garlic.com/~lynn/2002i.html#35 pop density was: trains was: Al Gore and the Internet
https://www.garlic.com/~lynn/2002i.html#36 pop density was: trains was: Al Gore and the Internet
https://www.garlic.com/~lynn/2002j.html#42 Transportation
https://www.garlic.com/~lynn/2002j.html#68 Killer Hard Drives - Shrapnel?
https://www.garlic.com/~lynn/2003j.html#11 Idiot drivers
https://www.garlic.com/~lynn/2006h.html#45 The Pankian Metaphor
https://www.garlic.com/~lynn/2008l.html#24 dollar coins
https://www.garlic.com/~lynn/2008l.html#26 dollar coins

highways have to be heavily engineered to handle projected heavy truck axle-load i.e. each axle-load from heavy truck causes damage (with cars and lighter weight trucks having negligible effect). highway basically is engineered to survive the damage from projected number of heavy truck axle loads (and requiring rebuilding highway roadbed and payment infrastructure).

doubling the daily heavy truck axle-loads (over projected) can approx. cut the useful highway lifetime in half. overloaded trucks are significantly worse on useful highway lifetime (one of the financial justifications for weigh station infrastructure is that w/o them lots of heavy truckers won't observe highway rated weight limits resulting in rapid, enormous deterioration of highway system).

one mechanism is to take a stretch of road that has been built for a projected number of axle-loads ... dividing the total road construction and lifetime maintenance costs by the projected number of axle-loads (that the road was designed for). eliminate fuel-based road use taxes and toll booths for other than heavy trucks. integrate truck weigh station with heavy truck toll booth. weigh station calculates each heavy trucks equivalent axle-loads and multiplies times the fully-loaded highway cost per heavy truck axle-load.

that would tie the toll charges directly to expected highway lifetime, if the truck traffic doubled ... cutting the highway lifetime in half ... would also double the toll charges ... to provide substainable highway funding.

current situation can have truck traffic doubling ... significantly cutting highway lifetime ... w/o corresponding significant increase in funding.

quicky search engine for reference:
http://pavementinteractive.org/index.php?title=Loads

from above:
Using the ESAL method, damage from all loads (including multi-axle loads) are converted to damage from an equivalent number of 18,000 lb. single axle loads, which is then used for design. A "load equivalency factor" represents the equivalent number of ESALs for the given weight-axle combination. The equation used to determine load equivalency can be quite complicated. As a rule-of-thumb, the load equivalency of a particular load (and also the pavement damage imparted by a particular load) is roughly related to the load by a power of four (for reasonably strong pavement surfaces). For example, a 36,000 lb. single axle load will cause about 16 times the damage as an 18,000 lb. single axle load.

... snip ...

i.e. not only use ESAL for highway design ... but also for setting the highway use charge (tolls) ... autombiles and light trucks effectively have zero ESAL.

past posts including mention of ESAL:
https://www.garlic.com/~lynn/2002j.html#41 Transportation
https://www.garlic.com/~lynn/2004e.html#7 OT Global warming
https://www.garlic.com/~lynn/2006g.html#56 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#57 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#59 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#60 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#61 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#62 The Pankian Metaphor
https://www.garlic.com/~lynn/2006h.html#0 The Pankian Metaphor
https://www.garlic.com/~lynn/2006h.html#6 The Pankian Metaphor
https://www.garlic.com/~lynn/2006h.html#11 The Pankian Metaphor
https://www.garlic.com/~lynn/2006h.html#23 The Pankian Metaphor
https://www.garlic.com/~lynn/2008e.html#48 fraying infrastructure

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

dollar coins

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: dollar coins
Newsgroups: alt.folklore.computers
Date: Sun, 03 Aug 2008 09:07:55 -0400
jmfbahciv <jmfbahciv@aol> writes:
Sure. But all those automobile drivers eat and wear clothes. I don't mind paying a bit for trucking.

The reduction in fuel taxes is a very recent phenomena. It shouldn't have anything to do with the maintenance planned for this year. Legislatures who are delaying maintenance this summer are playing dodgy with the funds they should have already collected from their gas tax. Ours goes straight into the general budget which is a black hole and not acountable to anybody. One of the reasons the voter ballot question for eliminating the state income tax was done was to force the legislature to make the general fund spending public.


re:
https://www.garlic.com/~lynn/2008l.html#36 dollar coins

so this would also require direct connection of funds (for costs incurred), i.e budgeting those funds to the purpose that they were collected for. the chances for money to go astray increases with the layers of indirection and obfuscation.

i would guess that a lot of people are confused about the issue that every time a heavy truck passes down the highway ... there is substantial damage occurring to the highway ... and there needs to funds appropriated for each one of heavy truck trips.

If the funds aren't being collected at the time of each one of the trips ... then at least there should be daily and weekly tallies reported so that the funds are budgeted for the repair purpose related to the rate that the damage is happening (knowing the axle-load miles by heavy trucks on a stretch of road every day tells how much damage has occurred that day ... from which the rate of damage can be calculated and whether it has changed the projected highway end-of-life ... or "death" date).

Lacking that, then things started to get even more obfuscated ... and at some point people become so confused about the relationship between the rate that the damage is occurring and the required amount of funds needed to be budgeted ... that it effectively becomes another (implied) unfunded mandate.

however, one might claim that pushing responsibility and costs off to the future ... and living on borrowed money has become epidemic in the society (obfuscation and not bothering to accurately account for things that require budgeting ... becomes institutionalized).

is isn't just making the general fund spending public ... but there needs to be comparison about the theoritical funding allocation for each portion of the general fund spending ... against actuals. would it be perverse to imply that the legislature is laundering the money by passing it thru the general fund so to further obfuscate what the money is supposed to be spent for versus what it is actually being spent for.

for related topic drift on obfuscation ... was calculation that the current ratio of retirees (receiving benefits) to workers (being taxed to provide benefits) increases by factor of eight times in the future (retiring baby boomers increase retiree population by factor of four, while number of workers in generation following the baby boomers is a little over half the number of the baby boomer workers).

Current SS tax is little over 15% of salary (combined direct deductions and employer contribution ... another obfuscation). The factor of eight implies that SS would have to increase to 120%. Secondary is that globalization may cut effective avg. salary in half ... which would mean that SS would have to increase to 240%.

past posts on the subject:
https://www.garlic.com/~lynn/2008f.html#99 The Workplace War for Age and Talent
https://www.garlic.com/~lynn/2008g.html#1 The Workplace War for Age and Talent
https://www.garlic.com/~lynn/2008g.html#4 CDOs subverting Boyd's OODA-loop
https://www.garlic.com/~lynn/2008g.html#5 The Workplace War for Age and Talent
https://www.garlic.com/~lynn/2008h.html#3 America's Prophet of Fiscal Doom
https://www.garlic.com/~lynn/2008h.html#26 The Return of Ada
https://www.garlic.com/~lynn/2008i.html#98 dollar coins

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

dollar coins

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: dollar coins
Newsgroups: alt.folklore.computers
Date: Sun, 03 Aug 2008 09:48:50 -0400
jmfbahciv <jmfbahciv@aol> writes:
Yup. Southboro's truck farm shut down 3 years ago. It was the only viable acreage left. There is one "farm" left and it is supplying its cows with hay paid out of donations. The fact that the flyers claim that each cow eats $2000+ worth of hay each year has made me suspicious about pocket linings.

east coast is heavily dependent on long-haul cross-conntry transportation for its food supply. with the increasing optimization of things like just-in-time at grocery stores (going directly from trailor to shelves with little or no stock room) ... there supposedly is only a week or two supply of food actually on the east coast at any point in time (on grocery shelves and regional distribution centers). I believe this was looked at as one of the possible Y2K vulnerabilities (possible computer failures leading to transportation/supply chain disruption).

an analogous problem was documented for grain export a couple years ago. there was very little (train) freight car buffer into and out of Houston (major national grain export) port ... and it became gridlocked. scheduling for freight cars into and out of houston had gotton slightly out of kilter and inbound freight cars couldn't get in because unloaded freight cars couldn't get out (freight car gridlock supposedly eventually extended at least the state of texas). grain was piling up all over the midwest and rotting.

quicky web search for freight train gridlock

Houston can't wait: Gridlock must be resolved now
http://www.houstonarchitecture.info/haif/index.php?showtopic=170

although the above article doesn't go into specific detail about the gridlock meltdown resulting in grain rotting all over the midwest (acutal storage capacity was only a few days harvest based on transportation infrastructure that would normally pickup and move the harvest within a few days).

old post mentioning the incident
https://www.garlic.com/~lynn/2005o.html#29 Penn Central RR computer system failure?

this is also intersection of computer scheduling optimization (and supply-chain management) reducing costs by reducing redundancy (things like just-in-time) ... however implicit in optimization and reducing redundancy can also imply creating single-points-of-failure and less robust/resiliant infrastructure. That coupled with fraying infrastructure can result in systemic vulnerabilities.

recent posts mentioning fraying infrastructure:
https://www.garlic.com/~lynn/2008e.html#43 fraying infrastructure
https://www.garlic.com/~lynn/2008e.html#48 fraying infrastructure
https://www.garlic.com/~lynn/2008e.html#50 fraying infrastructure
https://www.garlic.com/~lynn/2008e.html#53 Why Is Less Than 99.9% Uptime Acceptable?
https://www.garlic.com/~lynn/2008e.html#54 news maintenance: Prison pushes
https://www.garlic.com/~lynn/2008h.html#3 America's Prophet of Fiscal Doom
https://www.garlic.com/~lynn/2008i.html#98 dollar coins
https://www.garlic.com/~lynn/2008j.html#24 To: Graymouse -- Ireland and the EU, What in the H... is all this about?
https://www.garlic.com/~lynn/2008j.html#80 dollar coins
https://www.garlic.com/~lynn/2008k.html#61 Historian predicts the end of 'science superpowers'
https://www.garlic.com/~lynn/2008k.html#68 Historian predicts the end of 'science superpowers'
https://www.garlic.com/~lynn/2008k.html#71 Cormpany sponsored insurance
https://www.garlic.com/~lynn/2008l.html#25 dollar coins
https://www.garlic.com/~lynn/2008l.html#36 dollar coins

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

dollar coins

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: dollar coins
Newsgroups: alt.folklore.computers
Date: Mon, 04 Aug 2008 08:04:45 -0400
Peter Flass <Peter_Flass@Yahoo.com> writes:
As someone said, eating habits would have to change. You probaby don't get too much wheat, although you'd get some. You'd get lots of corn, barley, and probably oats. People would go back to eating lots more cabbage and potatoes, especially in the winter.

From:
http://www.answers.com/topic/new-england

Above mentions
With its rocky soil and climate, New England is not a strong agricultural region

.

The article also talks about early colonists from England found subsistance in New England much more difficult (because of colder climate and harsher conditions), i.e.:
Still summers were shorter, hotter, and more humid than English growing seasons, conditions that adversely affected wheat and pea growing in particular. A recurring mildew attacked wheat, gradually impelling a switch from wheat flour bread to one made with rye and the Native American's cornmeal.

... snip ...

also:
Uncertainty with grain crops together with the relative ease of apple growing gradually brought about a slight shift from beer and ale to apple cider drinking.

... snip ...

There are some articles that with global warming, there is the potential for extending the New England growing season and improving local food production (however, there is uncertainty about changes in precipitation affecting food production). an example
http://www.usgcrp.gov/usgcrp/nacc/education/northeast/ne-edu-3.htm

above notes that agricultural yields of existing crops could decrease by 40 percent (farmers not adapting to changing climate).

related study

Food Self-Sufficiency in the New England States, 1975-1997
http://www.massbenchmarks.org/publications/studies/pdf/foodself00.pdf

from above:
The data provided by an analysis of aggregate self-sufficiency measures indicate that the agricultural economy is healthy. Regional food production has consistently kept pace with increased consumer demand for the New England region as a whole, with an overall self- sufficiency in 1997 matching that of 1975 at 28 percent.

... snip ...

US Census has New England population growing from 11.8million in 1970s to 13.9 million in 2000.

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

dollar coins

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: dollar coins
Newsgroups: alt.folklore.computers
Date: Mon, 04 Aug 2008 09:10:50 -0400
Anne & Lynn Wheeler <lynn@garlic.com> writes:
From:
http://www.answers.com/topic/new-england

Above mentions "With its rocky soil and climate, New England is not a strong agricultural region".

The article also talks about early colonists from England found subsistance in New England much more difficult (because of colder climate and harsher conditions), i.e.:


re:
https://www.garlic.com/~lynn/2008l.html#39 dollar coins

could get into economic trade-off of trying to increase food production in new england ... where the yield is low because of the soil conditions and climate ... and likely has much lower max ... some formula like food calories yield per effort calories input (energy ROI). past history and current substainabiilty wouldn't appear to point to huge success?

the other formula is some region with significant higher crop yields ... so the formula becomes food-calories yield per effort-calories input plus transportation-calories (enery cost to grow in more favorable region and transport it). All energy costs are going up, not just transportation ... so it may be that energy costs attempting to increase New England food production might not offset transportation costs.

the actual optimal (energy) solution might be to move the majority of the people out of new england (which also has benefits of reducing heating energy costs as well as transportation for the energy used for heating) ... modulo changes in the calculations due to global warming effects. also have to take into account increasing energy use for cooling ... attempting to provide environment with very little variation.

old post about yields ... mentioning dry land eastern montana wheat with 3-5 bushels/acre and south eastern washington wheat with 90-100 bushels/acre (both requiring similar energy costs per acre).
https://www.garlic.com/~lynn/2002d.html#42 Farm kids
https://www.garlic.com/~lynn/2002q.html#52 Big Brother -- Re: National IDs
https://www.garlic.com/~lynn/2005l.html#38 IBM/Watson autobiography--thoughts on?

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

dollar coins

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: dollar coins
Newsgroups: alt.folklore.computers
Date: Mon, 04 Aug 2008 11:56:37 -0400
greymaus <greymausg@mail.com> writes:
Rough comparison, winter wheat in Europe would yield up to and above 5 tonnes an acre, as against one tonne in Montana. (3-5 bushels would seem disasterously low, may have been a bad year). I have seen wheat sown on land to the East of what seemed possible in Syria and Jordan. Never there in harvesting time, but they wouldn't sow it if the crops failed most years.

re:
https://www.garlic.com/~lynn/2008l.html#39 dollar coins
https://www.garlic.com/~lynn/2008l.html#40 dollar coins

... and ... old posts about yields ... mentioning dry land eastern montana wheat with 3-5 bushels/acre and south eastern washington wheat with 90-100 bushels/acre (both requiring similar energy costs per acre).
https://www.garlic.com/~lynn/2002d.html#42 Farm kids
https://www.garlic.com/~lynn/2002q.html#52 Big Brother -- Re: National IDs

at the time, contract combine would take around 2(?) bushels/acre plus percent above 2 bushels/acre (there was at least one year where there was nothing left over what contract combine took).
https://www.garlic.com/~lynn/2005l.html#38 IBM/Watson autobiography--thoughts on?

above references traveling combine crews ... that would move through the midwest as crop was ready for harvest.

one of the references:
http://www.ckfigginsharvesting.com/

from above:
I bought my first combines in 1975. I had been going on the harvest run for many years prior to that, starting when I was in high school. I devote most of my time and energy into this business to make it a success.

... snip ...

and:
We start our harvest run in north central Texas usually the middle of May, moving onto western Kansas then to Colorado and onto the golden triangle of Montana, cutting wheat, barley and oats. Then we travel back to western Kansas for the fall harvest of corn, milo, sunflowers and popcorn. We usually get back to our home base of Mankato, KS by the middle of November. We have been doing this for more than 30 years.

... snip ...

my memories are from the 50s.

wiki page on the south-east washington wheat growing region
https://en.wikipedia.org/wiki/Palouse

this article mentions area is typically more than 80 bushels/acre
http://seattletimes.nwsource.com/html/localnews/2003861712_wheatharvest31m.html

this article from Oct2007, wheat reached a record $10.25/bushel (up from $4.14/bushell as recently a year early)
http://www.koze950.com/2007/10/01/record-prices-continue-for-soft-white-wheat-in-the-palouse/

more recent article from 24jul2008
http://www.cbsnews.com/stories/2008/07/24/ap/tech/main4289047.shtml

from above:
The amount of land planted in wheat in Washington has risen by 250,000 acres in the past year. Winter wheat acreage grew by 80,000 acres, to approximately 1.8 million acres. Spring wheat grew by 170,000 acres to about 620,000 acres.

... snip ...

from the same article:
FRESNO, Calif. (AP) Fresno County topped the $5.3 billion mark in agriculture production last year, holding onto its place as the No. 1 farming county in the country.

... snip ...

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

dollar coins

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: dollar coins
Newsgroups: alt.folklore.computers
Date: Mon, 04 Aug 2008 13:53:25 -0400
re:
https://www.garlic.com/~lynn/2008k.html#29 dollar coins

with regard to toxic CDOs and past threads about $2 trillion problem, a business tv news show had on some guests this morning ... one of them let loose with its a $2 trillion dollar problem caused by greenspan keeping the prime rate too low ... and before the dust settles there will be five hundred or so banks that will go under.

the others on the show didn't know what to say. news accounts are still quoting only slightly under $500 billion has so far been written off.

as mentioned before ... a great deal of the subprime mortgages were originated by institutions that aren't under federal reserve, fdic, and/or most of the other controls. their introductory teaser rates were even lower than the fed prime rate (effectively could be totally disconnected from what ever greenspan was setting). lots of these were bought be speculators that appeared to be planning on being able to flip the property before the rates ever reset.

the originators didn't need to go to the fed and/or need traditional deposit accounts as source of money ... they could package the mortgages as toxic CDOs and market them ... although it was critical that they be given a triple-A rated in order to have access to sufficient buyers (and their supply of money). In theory, they would repeat the process forever ... totally outside the traditional banking infrastructure.

The huge infusion of liguidity and speculators significantly drove up the market ... current stories about price drops of 30percent may make mention that it tends to be local, formally "hot" environments ... but they usually don't mention that the "hot" markets had just gone thru period of 20precent/annum inflation.

as mention before ... when it all comes crashing down ... there will be all sorts caught up (systemic risk, etc) ... i.e.
https://www.garlic.com/~lynn/2008k.html#13 dollar coins

Thet also tend to not get into the complexity that a lot of the big banks caught up with toxic CDO write-offs, were ones that had been buying these triple-A rated toxic CDOs on the investment banking side of the house ... also outside of the fed supervision ... i.e. repeal of Glass-Steagall in 99 ... which had been passed in the wake of '29 to keep the safety&soundness of regulated banking separate from the unregulated risky investment banking.

at various times in the past several months, there have been mention that the Chinese banks were little affected by the toxic CDO problem because they were "better regulated". Article from today:

China Wins Financial Olympics as Credit Losses Hit U.S., Europe
http://www.bloomberg.com/apps/news?pid=20601087
http://www.bloomberg.com/apps/news?pid=20601087&sid=a8njO_1bnVMQ&refer=home

from above:
Chinese banks hold three of top six spots among the world's largest financial companies based on market value, even though their shares fell more than 20 percent in Hong Kong trading since October. London-based HSBC Holdings Plc, the biggest non-Chinese bank, is No. 3, trailing Beijing-based Industrial & Commercial Bank of China Ltd. and China Construction Bank Corp.

... snip ...

There have been some past implication that the former top position holders were there because of the paper value of their toxic CDO holdings .... which all came crashing down ... somewhat the emperor's new clothes analogy.

past posts mentioning the emperor's new clothes analogy and/or the repeal of Glass-Steagall:
https://www.garlic.com/~lynn/2008b.html#12 Computer Science Education: Where Are the Software Engineers of Tomorrow?
https://www.garlic.com/~lynn/2008c.html#11 Toyota Sales for 2007 May Surpass GM
https://www.garlic.com/~lynn/2008c.html#87 Toyota Sales for 2007 May Surpass GM
https://www.garlic.com/~lynn/2008d.html#85 Toyota Sales for 2007 May Surpass GM
https://www.garlic.com/~lynn/2008e.html#42 Banks failing to manage IT risk - study
https://www.garlic.com/~lynn/2008e.html#59 independent appraisers
https://www.garlic.com/~lynn/2008f.html#1 independent appraisers
https://www.garlic.com/~lynn/2008f.html#13 independent appraisers
https://www.garlic.com/~lynn/2008f.html#17 independent appraisers
https://www.garlic.com/~lynn/2008f.html#43 independent appraisers
https://www.garlic.com/~lynn/2008f.html#46 independent appraisers
https://www.garlic.com/~lynn/2008f.html#53 independent appraisers
https://www.garlic.com/~lynn/2008f.html#71 Bush - place in history
https://www.garlic.com/~lynn/2008f.html#73 Bush - place in history
https://www.garlic.com/~lynn/2008f.html#75 Bush - place in history
https://www.garlic.com/~lynn/2008f.html#79 Bush - place in history
https://www.garlic.com/~lynn/2008f.html#94 Bush - place in history
https://www.garlic.com/~lynn/2008f.html#96 Bush - place in history
https://www.garlic.com/~lynn/2008f.html#97 Bush - place in history
https://www.garlic.com/~lynn/2008g.html#2 Bush - place in history
https://www.garlic.com/~lynn/2008g.html#4 CDOs subverting Boyd's OODA-loop
https://www.garlic.com/~lynn/2008g.html#16 independent appraisers
https://www.garlic.com/~lynn/2008g.html#44 Fixing finance
https://www.garlic.com/~lynn/2008g.html#51 IBM CEO's remuneration last year ?
https://www.garlic.com/~lynn/2008g.html#52 IBM CEO's remuneration last year ?
https://www.garlic.com/~lynn/2008g.html#57 Credit crisis could cost nearly $1 trillion, IMF predicts
https://www.garlic.com/~lynn/2008g.html#59 Credit crisis could cost nearly $1 trillion, IMF predicts
https://www.garlic.com/~lynn/2008g.html#66 independent appraisers
https://www.garlic.com/~lynn/2008g.html#67 independent appraisers
https://www.garlic.com/~lynn/2008h.html#1 subprime write-down sweepstakes
https://www.garlic.com/~lynn/2008h.html#28 subprime write-down sweepstakes
https://www.garlic.com/~lynn/2008h.html#32 subprime write-down sweepstakes
https://www.garlic.com/~lynn/2008h.html#89 Credit Crisis Timeline
https://www.garlic.com/~lynn/2008j.html#12 To: Graymouse -- Ireland and the EU, What in the H... is all this about?
https://www.garlic.com/~lynn/2008j.html#40 dollar coins
https://www.garlic.com/~lynn/2008j.html#60 dollar coins
https://www.garlic.com/~lynn/2008j.html#66 lack of information accuracy
https://www.garlic.com/~lynn/2008j.html#69 lack of information accuracy
https://www.garlic.com/~lynn/2008k.html#10 Why do Banks lend poorly in the sub-prime market? Because they are not in Banking!
https://www.garlic.com/~lynn/2008k.html#16 dollar coins
https://www.garlic.com/~lynn/2008k.html#27 dollar coins
https://www.garlic.com/~lynn/2008k.html#28 dollar coins
https://www.garlic.com/~lynn/2008k.html#36 dollar coins
https://www.garlic.com/~lynn/2008k.html#41 dollar coins

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

recent mentions of 40+ yr old technology

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: recent mentions of 40+ yr old technology
Newsgroups: alt.folklore.computers
Date: Mon, 04 Aug 2008 16:13:29 -0400
Anne & Lynn Wheeler <lynn@garlic.com> writes:
Report: Microsoft prepares for end of Windows with Midori
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=009111018


re:
https://www.garlic.com/~lynn/2008l.html#11 recent mentions of 40+ yr old technology

more items from today:

Windows Is Dead - Long Live Midori?
http://tech.slashdot.org/tech/08/07/30/1714249.shtml?tid=201
New Details On Microsoft's Replacement For Windows
http://www.redorbit.com/news/technology/1508954/new_details_on_microsofts_replacement_for_windows/index.html
Microsoft working on "post-Windows" OS
http://www.pcpro.co.uk/news/216417/microsoft-working-on-postwindows-os.html
Microsoft Working On "post-Windows" Cloud Computing OS
http://slashdot.org/articles/08/08/04/1425236.shtml
Cloud Computing, Microsoft's Midori, and the End of Windows
http://www.pcworld.com/businesscenter/blogs/larkin_on_the_web/149373/cloud_computing_microsofts_midori_and_the_end_of_windows.html

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

dollar coins

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: dollar coins
Newsgroups: alt.folklore.computers
Date: Mon, 04 Aug 2008 16:32:33 -0400
re:
https://www.garlic.com/~lynn/2008k.html#29 dollar coins
https://www.garlic.com/~lynn/2008l.html#42 dollar coins

... there continue to be some number of news stories about billions in toxic CDOs that merrill unloaded last week at 22cents on the dollar ...

Making the Most of Merrill
http://online.barrons.com/article/SB121763136297705935.html
Is This The Bottom?
http://www.bloggernews.net/117047
Merrill Lynch bites the bullet on credit-crunch losses
http://www.kansascity.com/business/story/730511.html

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

z/OS BIND9 DNS Vulnerable to Cache Poisoning Attack Problem?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: z/OS BIND9 DNS Vulnerable to Cache Poisoning Attack Problem?
Newsgroups: bit.listserv.ibm-main
To: <ibm-main@bama.ua.edu>
Date: Mon, 04 Aug 2008 17:02:47 -0400
patrick.okeefe@WAMU.NET (Patrick O'Keefe) writes:
I don't think it's "out of ignorance" at all. As I understand it, the whole concept of DNS lookups is built around recursion - "I don't know, but know does". The only 2 real choices are "I'll go ask him" or "You go ask him". (Maybe only the first is considered recursive. I don't know DNS processing that well. I'm not even sure the 2nd option is part of standard DNS processing.)

the domain name infrastructure is sort of a combination of a hierarchy and mesh. both clients and servers can point to any place in the infrastructure (servers point to other places in the infrastructure for information that they aren't the authoritative server). both clients and servers may cache information from other places in the infrastructure. Lists of other servers to ask (used by both clients and servers) frequently have a minimum of two ... but sometimes can have dozens (somewhat blurs the distinction between what is client and what is server).

most ISP clients get automatically setup to point at the DNS servers run by that ISP. For something a little different, here is a service that is advertising itself as a preferred alternative to default ISP DNS servers ... goes into some detail about DNS as part of supporting their claims as to being "better":
http://www.opendns.com/

slightly older post with several references about the domain name infrastructure vulnerabiilty
https://www.garlic.com/~lynn/2008j.html#87 CLIs and GUIs

also mentions that the inventor of DNS having earlier done a stint at the science center
https://www.garlic.com/~lynn/subtopic.html#545tech

recent post on the subject in a.f.c ng
https://www.garlic.com/~lynn/2008k.html#78 Secure64 Develops First Automated DNSSEC Signing Application to Help Secure the Internet Worldwide

and repeat in thread in comp.arch
https://www.garlic.com/~lynn/2008k.html#79 Larrabee details: Yes, it is based on the Pentium. :-)

above mentions that one of the founders of Secure64 had also worked on 801/risc
https://www.garlic.com/~lynn/subtopic.html#801

however, it doesn't mention that they had also earlier been responsible for dual-address space mode on 3033.

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

z/OS BIND9 DNS Vulnerable to Cache Poisoning Attack Problem?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: z/OS BIND9 DNS Vulnerable to Cache Poisoning Attack Problem?
Newsgroups: bit.listserv.ibm-main
Date: Mon, 04 Aug 2008 17:25:03 -0400
re:
https://www.garlic.com/~lynn/2008l.html#45 z/OS BIND9 DNS Vulnerable to Cache Poisoning Attack Problem?

if you are really feeling at loose ends ... here is recent thread in security ng regarding SSL and domain name digital certificates
https://www.garlic.com/~lynn/2008l.html#28 Verifying Verified By Visa - Registration breaks chain of trust
https://www.garlic.com/~lynn/2008l.html#29 Verifying Verified By Visa - Registration breaks chain of trust
https://www.garlic.com/~lynn/2008l.html#30 Verifying Verified By Visa - Registration breaks chain of trust
https://www.garlic.com/~lynn/2008l.html#31 Authentication in the e-tailer / payment gateway / customer triangle
https://www.garlic.com/~lynn/2008l.html#32 Authentication in the e-tailer / payment gateway / customer triangle
https://www.garlic.com/~lynn/2008l.html#33 Authentication in the e-tailer / payment gateway / customer triangle
https://www.garlic.com/~lynn/2008l.html#34 Authentication in the e-tailer / payment gateway / customer triangle

the current issue is mechanism that attacker can use to poison a cache.

we had been called in to consult with a small client/server startup that wanted to do payment transactions and they had this technology they invented called SSL that they wanted to use ... the result is now frequently referred to as electronic commerce ... some related past posts about the payment gateway part of that effort
https://www.garlic.com/~lynn/subnetwork.html#gateway

as part of that effort we had to do detailed protocol review as well as business process reviews ... including audits of many of these new operations calling themselves certification authorities and issuing these things called SSL domain name digital certificates. misc. past posts
https://www.garlic.com/~lynn/subpubkey.html#sslcert

one of the justifications for SSL was countermeasure to (general case) of DNS cache poisoning, as well as other kinds of domain name hijacking and/or ip-address hijacking (redirection for the purpose of webserver impersonation).

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Intel: an expensive many-core future is ahead of us

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel: an expensive many-core future is ahead of us
Newsgroups: alt.folklore.computers
Date: Mon, 04 Aug 2008 23:29:24 -0400
Rich Alderson <news@alderson.users.panix.com> writes:
Morten, I don't understand what you are saying here. What is there in the (e.g.) _System/360 Principles of Operation_ that is not present in the _DECsystem-10/DECSYSTEM-20 Hardware Reference Manual_? (In point of fact, the POO required a separate manual for each model's differences, where the HRM details them in a single book.)

principles of operation was all the "programming" that was the same across all the machines. it fairly early on became a (cp67) cms script file ... actually it was the "architecture red book" ... which contained a bunch of additional stuff; justifications and trade-offs for specific instructions ... and/or considerations because of some technology, features not yet announced, etc.

script formating support conditional/branch processing ... that could be controlled/set from command like options ... so either the full red book was printed or just the principles of operation subset.

an issue was that 360 processors were being developed at various locations around the planet ... the architecture red book (and the principles of operation) subset was what all the processor locations had to conform to (and "owned" by the architecture group in pok).

lots more than two processors (from around the planet) ... for 360s, the processor specific, functional characteristics included things like instruction times. these could be written at the different locations.

next level of hardware reference includes things like machine specific microcode (used to implement 360 architecture) and diagnose instruction operation (defined as model specific).

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Intel: an expensive many-core future is ahead of us

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel: an expensive many-core future is ahead of us
Newsgroups: alt.folklore.computers
Date: Tue, 05 Aug 2008 10:24:28 -0400
Peter Flass <Peter_Flass@Yahoo.com> writes:
As I recall there was *one* _System/360 Principles of Operation_, with addenda for unique machines like the /85 perhaps, or the /91, or for RPQs like the Vector Processor.

re:
https://www.garlic.com/~lynn/2008l.html#47 Intel: an expensive many-core future is ahead of us

functional characteristics
http://www.bitsavers.org/pdf/ibm/360/functional_characteristics/

360/67 with hardware virtual memory support ...
http://www.bitsavers.org/pdf/ibm/360/functional_characteristics/A27-2719-0_360-67_funcChar.pdf
http://www.bitsavers.org/pdf/ibm/360/functional_characteristics/GA27-2719-2_360-67_funcChar.pdf

principles of operation
http://www.bitsavers.org/pdf/ibm/360/princOps/

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Quality of IBM school clock systems?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Quality of IBM school clock systems?
Newsgroups: alt.folklore.computers
Date: Tue, 05 Aug 2008 10:56:18 -0400
Eric Sosman <Eric.Sosman@sun.com> writes:
What I don't understand is why these data-losing organizations aren't in court defending skillions of lawsuits. I mean, "We took good care of your private data" sounds a bit hollow when the said data goes walkabout, doesn't it?

w/o specific laws for damages for data breaches; part of it may have to do with proving the connection to damage/loss.

we had been called in to help word smith the cal. state (and later federal) electronic signature law
https://www.garlic.com/~lynn/subpubkey.html#signature

some of the organizations involved were also involved in consumer privacy issues. they had done detailed consumer surveys on privacy issues and found that the two top privacy issues were

• identity theft ... including major subcategory, account fraud • denial of service ... institutions using personal information to the detriment of the individual

the source of much of the various kinds of fraud associated with identity theft involved various kinds of breaches ... both involving insiders and outsiders (studies over long period of time, have found that as much as 70 precent of breaches involved insiders).

the issue was that there seemed to be little being done about the data breaches and little public exposure ... which seemed to be a large part of the motivation behind the cal. state data breach legislation (at least notify the public about when it happened)

lots of past posts about fraud, exploits, vulnerabilities, threats, risks
https://www.garlic.com/~lynn/subintegrity.html#fraud

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

IBM manual web pages

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM manual web pages
Newsgroups: bit.listserv.ibm-main
Date: Tue, 05 Aug 2008 11:42:25 -0400
howard.brazee@CUSYS.EDU (Howard Brazee) writes:
Automatic redirection means people don't notice and don't change anything (it still works). I guess such redirections should require an explicit user input, and include an option to save the bookmark.

re:
https://www.garlic.com/~lynn/2008l.html#45 z/OS BIND9 DNS Vulnerable to Cache Poisoning Attack Problem?
https://www.garlic.com/~lynn/2008l.html#46 z/OS BIND9 DNS Vulnerable to Cache Poisoning Attack Problem?

automatic redirection is also a form of impersonation ... something that SSL was designed as countermeasure; other forms of impersonation can involve dns cache poisoning, domain name hijacking, ip-address hijacking/take-over, etc. redirects would be caught by SSL if it involved a SSL domain name certificate that failed the matching check with the original URL.

SSL domain name certificates can be exact hostname match ... or some can specify pattern match for group of hostnames with matching domain name part.

part of the current issue is that the original SSL work was predicated that it could provide for showing that the webserver that the client thought they were talking to was the same as the webserver that they were talking to.

this required that the client understand the relationship between the webserver they thought they were talking to and the URL they typed into the browser. The browser would then check that the hostname part of the URL matched what was in the SSL domain name certificate provided by the webserver.

what happened almost immediately was that webservers found that SSL degraded thruput by 90percent or more ... and the electronic commerce websites dropped back to just using SSL for the paying/checkout part of the experience. typical operation is that the (unvalidated) website provides a checkout/pay button that the user clicks on ... which provides the URL.

This violates basic part of the assumptions about SSL security. The scenario now (with browser checking the webserver provided URL) is that "whatever the webserver claims to be is what the webserver is" ... that is a big difference from "the webserver that the client thinks they are talking to is the webserver that they actually are talking to".

this scenario has also been used by a lot of phishing email ... getting users to click on a URL provided by an (unvalidated) email.

SSL is dependent on users knowing the relationship between the webserver they think they are talking to and the corresponding URL (in order to achieve that the webserver a client thinks they are talking to is the webserver they are talking to) ... with the URL coming from a trusted, validated source.

recent long wind set of posts mentioned in cache poisoning post:
https://www.garlic.com/~lynn/2008l.html#28 Verifying Verified By Visa - Registration breaks chain of trust
https://www.garlic.com/~lynn/2008l.html#29 Verifying Verified By Visa - Registration breaks chain of trust
https://www.garlic.com/~lynn/2008l.html#30 Verifying Verified By Visa - Registration breaks chain of trust
https://www.garlic.com/~lynn/2008l.html#31 Authentication in the e-tailer / payment gateway / customer triangle
https://www.garlic.com/~lynn/2008l.html#32 Authentication in the e-tailer / payment gateway / customer triangle
https://www.garlic.com/~lynn/2008l.html#33 Authentication in the e-tailer / payment gateway / customer triangle
https://www.garlic.com/~lynn/2008l.html#34 Authentication in the e-tailer / payment gateway / customer triangle

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Monetary affairs on free reign, but the horse has Boulton'd

Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: August 5, 2008 12:09 PM
Subject: Monetary affairs on free reign, but the horse has Boulton'd
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/001084.html

the term moral hazard has also been showing up in the news ... the FED making funds available to bail out unregulated, risky investment banking. in theory risky investment banking is suppose to be unregulated and have the opportunity to take risks. part of that is they also have the opportunity to fail. When the FED intervenes to prevent such failures, it creates moral hazard ... perception that investment banking won't be held responsible for failures ... then they are likely to take greater and greater risks.

post from yesterday
https://www.garlic.com/~lynn/2008l.html#42

commenting on:

China Wins Financial Olympics as Credit Losses Hit U.S., Europe
http://www.bloomberg.com/apps/news?pid=20601087
http://www.bloomberg.com/apps/news?pid=20601087&sid=a8njO_1bnVMQ&refer=home

there have been articles in the past several months that the safety and soundness of China banks are doing much better than western banks (US and Europe) because they have been better regulated.

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Payments Security in RFS

Refed: **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: August 5, 2008
Subject: Payments Security in RFS
Blog: Risk Management
We had been brought in to consult with small client/server startup that wanted to do payment transactions on their server ... and they had this technology they had invented called SSL they wanted to use ... the result is now frequently referred to as electronic commerce. Much of the SSL activity was addressing countermeasures to evesdropping vulnerabiities and server impersonation (server authentication) vulnerabilities. Recent thread related to DNS cache poisoning as a flavor of server impersonation
https://www.garlic.com/~lynn/2008l.html#46

The above also has references to large number of recent articles about study that found 3/4ths of bank sites have vulnerabilities.

after that in the mid-90s, we got roped into the x9a10 financial standard working group which had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments (aka all as in ALL ... not just internet ... but ALL). The result was the x9.59 financial standard
https://www.garlic.com/~lynn/x959.html#x959

part of x9.59 standards work had gotten into the area of parameterised risk management ... making the level of security proportional to risk. This included things like number of authentication factors and kind of factors related to amount of transaction.

Another part was business rule that information from x9.59 transactions could not be used in non-X9.59 transactions (and/or transactions w/o equivalent authentication). The objective here was to eliminate evesdropping, data breach, and security breach related vulnerabilities ... where information from previous transactions (as little as knowing account number) could be used for fraudulent transactions .... i.e. not only were x9.59 transactions authenticated ... but it wasn't possible to have a security breach involving account numbers and/or other information, from x9.59 transactions, which would result in fraudulent transactions (x9.59 didn't do anything about preventing security breaches, x9.59 just eliminated the account fraud transactions that are typical result of security breaches).

For other topic drift ... merged security taxonomy & glossary ... including from FFIEC
https://www.garlic.com/~lynn/index.html#glosnote

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Quality of IBM school clock systems?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Quality of IBM school clock systems?
Newsgroups: alt.folklore.computers
Date: Tue, 05 Aug 2008 16:41:40 -0400
Anne & Lynn Wheeler <lynn@garlic.com> writes:
we had been called in to help word smith the cal. state (and later federal) electronic signature law
https://www.garlic.com/~lynn/subpubkey.html#signature

some of the organizations involved were also involved in consumer privacy issues. they had done detailed consumer surveys on privacy issues and found that two top privacy issues were

• identity theft ... including major subcategory, account fraud • denial of service ... institutions using personal information to the detriment of the individual


re:
https://www.garlic.com/~lynn/2008l.html#49 Quality of IBM school clock system?

somewhat related recent post regarding account fraud:
https://www.garlic.com/~lynn/2008l.html#52 Payments Security in RFS

after having worked on what is now frequently called electronic commerce, we were brought into the x9a10 financial standard working group which had been given the requirement to preserve the integrity of the financial infrastructure working group for all retail payments (i.e. all as in ALL, not just internet, but ALL). The result was the x9.59 financial standard
https://www.garlic.com/~lynn/x959.html#x959

the transactions were authenticated to eliminate fraud ... but there was also a business rule that information from x9.59 transactions (like account numbers) couldn't be used in non-x9.59 (non-authenticated) transactions. the issue was that detailed threat and vulnerability study identified evesdropping, data breaches, and security breaches as a major problem because of resulting account fraud.

X9.59 financial standard didn't address anything about evesdropping, data breaches, and/or security breaches ... what it addressed was the elimination of the account fraud that might result from the breaches.

we've also commented that the major use of SSL in the world today is the electronic commerce work we had done (prior to x9.59) for hiding account numbers (as a countermeasure to account fraud and fraudulent transactions).
https://www.garlic.com/~lynn/subpubkey.html#sslcert

however, the x9.59 financial standard eliminates the threat of account fraud that can happen when the account number is exposed, which, in turn eliminates the need to hide the account number ... which then eliminates the major justification in the world today for SSL.

hot news off the wire:

Eleven Indicted in Massive ID Theft Scheme
http://www.pcworld.com/businesscenter/article/149440/eleven_indicted_in_massive_id_theft_scheme.html
Update: Eleven indicted in massive ID theft scheme
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9111670
Eleven charged in massive ID theft scheme
http://www.networkworld.com/news/2008/120908-the-computer-mouse-turns.html
11 charged in connection with credit card fraud
http://www.physorg.com/news137165100.html

the above scenario was one of the areas that the x9.59 financial standard was designed to counteract ... aka it did nothing to prevent "sniffing" for collecting credit card and password information ... it just eliminated the threat of account fraud and fraudulent transactions that could result from such sniffing.

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

dollar coins

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: dollar coins
Newsgroups: alt.folklore.computers
Date: Tue, 05 Aug 2008 18:48:39 -0400
Walter Bushell <proto@panix.com> writes:
What's wrong with a hummer, if it done freely, between consenting adults, (or juveniles even.)

some number (along with other vehicles in similar weight class) were automatically classified as commercial and allowed up to $100k tax deduction ... but were really being purchased for personal consumer use.

one of the issues raised in cal. was many residential areas have prohibitions against commercial traffic by vehicles starting in that weight class ... and there was some drive to have the laws enforced ... requiring individuals to find some location outside residential area to leave their vehicles (even when being used for commuting). old post about some in cal. trying to get laws enforced prohibiting commercial (weight) vehicles on residential streets (including high-end "commercial" SUVs)
https://www.garlic.com/~lynn/2006s.html#13 Newisys Horus & AMD Opteron

one issue might be that the roads weren't built to handle repeated axle-loads for vehicles above certain weight (possible to save significant amount of money on construction costs). i've also periodically wondered if less expensive road construction was used on truck-prohibited traffic lanes.

old post citing related studies regarding problems with bus axle-load traffic on residential streets
https://www.garlic.com/~lynn/2006h.html#6 The Pankian Metaphor

other recent posts mentioning axle-load
https://www.garlic.com/~lynn/2008l.html#25 dollar coins
https://www.garlic.com/~lynn/2008l.html#36 dollar coins
https://www.garlic.com/~lynn/2008l.html#37 dollar coins

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Intel: an expensive many-core future is ahead of us

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel: an expensive many-core future is ahead of us
Newsgroups: alt.folklore.computers
Date: Wed, 06 Aug 2008 07:43:35 -0400
jmfbahciv <jmfbahciv@aol> writes:
The load balancing was done by planning the hardware configuration. The guy who did the 5-CPU hardware plan spent several months thinking about it. He didn't have to any software mods to control the load balance. Since the disks and magtapes had switchable ports, you could rearrange the load balance by popping the plug or throwing a switch on the device.

This may sound crude or clumsy but it was new back then. Before this sites used to "share" disk drives by having one port go to one system and the other port to the other system and then setting the A or B switch to whichever system the pack being mounted was supposed to be connected to.


when i rewrote the i/o supervisor for the disk engineering lab & product test lab:
https://www.garlic.com/~lynn/2008k.html#75 Disk drive improvements

one of the things was doing channel load balancing for disk controllers. multiple channel interfaces could be attached to different channels in the same "CEC" (either single processor or multiple processors, CEC multiple processors were tightly-coupled multiprocessing) and/or different "CEC" (different CEC multiple processors were loosely-coupled multiprocessing ... mainframe for clusters).

however, one of the side-effects of the slow processor (used for commands) introduced in the 3880 disk controller, was that it collected up a bunch of information about a specific channel interface. If it was hit with an i/o request from a different channel interface (than the one it was currently dealing with(, it had to unload a bunch of information for the interface it had been dealing with and load up information for the new interface. This channel interface switch was significant (whether dealing with same CEC or multiple CECs) ... over a millisecond.

Any benefits of (disk controller) channel load balancing (on the same CEC) was way offset by the disk controller overhead switching channel interfaces ... as a result, it was better thruput to use primary channel interface with one or more alternates ... as opposed to full load balancing (including any overhead to switch processors in a tightly-coupled multiprocessor configuration).

The original code that had been replaced had evolved over several years and gotten quite convoluted (even doing simple primary w/alternates). My rewrite significantly cleaned up the code (and side effect was significant reduction in pathlength). It was then fairly easy to switch between full load balancing stategy vis-a-vis primary with alternates.

Part of the issue is that 360 (except for 360/67) tightly coupled multiprocessor ... provided for shared memory ... but I/O (channel) interfaces were dedicated per processor (it was possible to reconfigure a two-processor multiprocessor with its dedicated channels such that the memory was unshared and they operated as two independent single processor machines). This was multiprocessor design that continued to be used w/370.

The 360/67 was different, besides having virtual memory support, the 360/67 multiprocessor support allowed for processors sharing all memory as well as all i/o (channel) interfaces (all processors could address all channels). This didn't reappear in mainframes until 370-xa.

As an aside, 360/67 also supported both 32-bit virtual addressing and 24-bit virtual addressing options. When virtual memory support was introduced for 370s, it only supported 24-bit virtual addressing. it wasn't until 370-xa that 31-bit virtual address was introduced.

other posts mentioning getting to play disk engineer over in bldgs. 14 & 15
https://www.garlic.com/~lynn/subtopic.html#disk

for other topic drift ... small footnote ... as i've mentioned before ... when charlie was doing multiprocessor fine-grain locking at the science center
https://www.garlic.com/~lynn/subtopic.html#545tech

for cp67 (on 360/67), he invented compare&swap instruction ... (CAS was chosen because they are charlie's initials). misc. past posts mentioning symmetric, tightly-coupled multiprocessor and/or compare&swap instruction
https://www.garlic.com/~lynn/subtopic.html#smp

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Intel: an expensive many-core future is ahead of us

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel: an expensive many-core future is ahead of us
Newsgroups: alt.folklore.computers
Date: Wed, 06 Aug 2008 08:10:23 -0400
cb@mer.df.lth.se (Christian Brunschen) writes:
Basically, a thread of execution within a process is a set of CPU state with which execution is progressing, or can be resumed. This includes the program counter (PC), stack pointer (if applicable - but all computers have/had stacks), and any other registers that are necessary to distinguish one path of execution through the code that makes up the process. And by 'execution path' I mean not just the current location, but also anything that may be necessary for returning from functions or similar (that's where the stack comes in, if available).

on standard 360s, multi-threaded (aka multiprogramming) operation evolved fairly early ... in part because of the real-memory operation. However, standard threads were fairly heavy weight in os/360 with TCB (task control blocks).

fairly early, subsystems applications evolved (transaction monitors, database systems, etc) that appeared to the operating system as single task ... but implemented their own (light-weight) threads. An example was/is CICS. When I was undergraduate in 60s, the university had a digital library ONR-grant and was selected to be beta-test for the original CICS product. I got tasked to support CICS and had to do some debugging on the product.

Not too long later, Charlie invented the compare&swap instruction at the science center ... recent reference
https://www.garlic.com/~lynn/2008l.html#55 Intel: an expensive many-core future is ahead of us

and there was a push to get the instruction included in the (new) 370 architecture. There was initial push back ... claims that the (existing) test&set instruction was more than sufficient for supporting (kernel) multiprocessor operation. Challenge was to come up with compare&swap justification that wasn't multiprocessor specific. The result was description for using compare&swap instruction in application (light-weight) thread coordination ... whether running in a single processor or multiprocessor operation.

The issue in application threads (even on a single processor) was that applications are still enabled for interrupts which could occur at any point; interrupt could occur for one thread ... and execution might then resume with a different thread. Critical sections involving multiple instructions could require kernel call to correctly serialize and prevent deadlocks (resumed lightweight thread spinning on lock held by an interrupted lightweight thread ... which won't release the lock until the spinning thread completes). compare&swap allowed for some number of "lock-free" atomic operations.

The thread-operation justification for compare&swap was not only successful ... but was also added to the 370 principles of operation ... and are still there in modern principles of operation. Recent version

A.6 Multiprogramming and Multiprocessing Examples
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/A.6?SHELF=DZ9ZBK03&DT=20040504121320

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

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

No offense to any one but is DB2/6000 an old technology. Does anybody still use it, if so what type of industries??

Refed: **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: August 6, 2008
Subject: No offense to any one but is DB2/6000 an old technology. Does anybody still use it, if so what type of industries??
Blog: Databases
The original relational/SQL implementation was done on vm370 platform in bldg. 28. misc. past posts mentioning the activity
https://www.garlic.com/~lynn/submain.html#systemr

there was then technology transfer from SJR to Endicott for SQL/DS. One of the people mentioned in this meeting claims to have handled most of the technology transfer from Endicott to STL for (mainframe) DB2.
https://www.garlic.com/~lynn/95.html#13

although there was also collaboration with SJR ... i.e. STL & SJR only 10 miles apart. This was mainframe PLS programming language implementation.

Later there was Shelby project at Toronto lab. to do a portable relational database implementation in C (initially) for OS2 ... this was also given the DB2 product name as well as ported to Unix and RS/6000.

for other information, DB2 wiki page:
https://en.wikipedia.org/wiki/IBM_DB2

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Intel: an expensive many-core future is ahead of us

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel: an expensive many-core future is ahead of us
Newsgroups: alt.folklore.computers
Date: Wed, 06 Aug 2008 20:02:23 -0400
Peter Flass <Peter_Flass@Yahoo.com> writes:
System code is different. The function of the system is to stay up, if at all possible. Some huge percentage of code in OS/360 and successors is error recovery, and I expect TOPS-10 et. al. are the same.

recent post mentioning rewriting I/O supervisor for disk engineering and product test labs so it wouldn't crash. they had tried using standard MVS ... but the MTBF was 15 minutes.
https://www.garlic.com/~lynn/2008k.html#75 Disk drive improvements
https://www.garlic.com/~lynn/2008l.html#55 Intel: an expensive many-core future is ahead of us

other posts being allowed to play disk engineer in bldgs. 14&15
https://www.garlic.com/~lynn/subtopic.html#disk

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Intel: an expensive many-core future is ahead of us

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel: an expensive many-core future is ahead of us
Newsgroups: alt.folklore.computers
Date: Thu, 07 Aug 2008 09:46:31 -0400
jmfbahciv <jmfbahciv@aol> writes:
It's not really any different from a certain viewpoint. All the daemons that had to run before anybody can log in and use the system is also a set of software that shouldn't just blow up if an aberrant error return happens. There has to be a trap of some kind in that layer of software. In our OSes, we would ship a message to the human operator to inform him/her it was time to panic and do something.

old story about multics possibly hrs of recovery time compared to quick restart of cp67 ... motivating rewrite of parts of cp67 (i.e. part of the ctss group went to science on the 4th flr and worked on cp67 and part went to 5th flr and worked on multics):
https://www.multicians.org/thvv/360-67.html

as an undergraduate, i had added tty/ascii terminal support to cp67 ... and got fancy with 1 byte values for arithmetic (since tty wasn't over 80). a cp67 system installed at MIT ...different from science center ... i think still bldg in tech sq ... but across the courtyard from 545tech
https://www.garlic.com/~lynn/subtopic.html#545tech

some psuedo-terminal(?) down at harvard (graphics, plotter) had much longer line-length ... so somebody made mod. to allow max line length of something like 1200 bytes ... so the calculations resulted in over running buffer.

in any case, the system crashed and recovered 27 times in a single day.

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

recent mentions of 40+ yr old technology

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: recent mentions of 40+ yr old technology
Newsgroups: alt.folklore.computers
Date: Thu, 07 Aug 2008 12:30:22 -0400
Walter Bushell <proto@panix.com> writes:
And how many other jobs are running at the same wall clock time. Perhaps, you should compare total time from submission, until the job is returned to you. eh?

recent post about a job getting few weeks turn around on 370/195 and moving it to an idle 3033. the elapsed run time was slightly longer (since peak mips on 195 was about twice 3033) ... but being unloaded met that it could start immediately
https://www.garlic.com/~lynn/2008k.html#77 Disk drive improvements

this particular job was air-bearing simulation for design of new generation of disk heads.

actually few weeks was with priority ... palo alto science center had a job that was getting three month turn around on the sjr 370/195. they found that with some checkpoint and other stuff for their 370/145 vm370 time-sharing system that they could get enough off-shift procesing (weekends and evenings) that turn-around was shorter/reduced (even tho 145 had possibly 1/30th mip rate of 195).

misc. past posts mentioning PASC getting 3 month turn around on sjr 370/195
https://www.garlic.com/~lynn/2001n.html#39 195 was: Computer Typesetting Was: Movies with source code
https://www.garlic.com/~lynn/2002n.html#63 Help me find pics of a UNIVAC please
https://www.garlic.com/~lynn/2003j.html#69 Multics Concepts For the Contemporary Computing World
https://www.garlic.com/~lynn/2004.html#21 40th anniversary of IBM System/360 on 7 Apr 2004
https://www.garlic.com/~lynn/2005f.html#4 System/360; Hardwired vs. Microcoded
https://www.garlic.com/~lynn/2005o.html#44 Intel engineer discusses their dual-core design
https://www.garlic.com/~lynn/2006c.html#44 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006x.html#27 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2007j.html#13 Interrupts
https://www.garlic.com/~lynn/2007j.html#16 Newbie question on table design

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Osama bin Laden gets a cosmetic makevover in his British Vanity Passport

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: August 7, 2008 10:46 AM
Subject: Osama bin Laden gets a cosmetic makevover in his British Vanity Passport
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/001085.html

Various of the comments from that (and other) articles are about anything can be forged. Presumably the point of the chip was to significantly increase the cost of making forgeries (compared to non-chip passports).

This was somewhat our periodic semi-facetious comments in the mid-90s about taking a $500 milspec chip, aggressive cost reduction by 2-3 orders of magnitude ... while at the same time, actually increasing the security and integrity.

One of the problems we got into was that we got on the (EPC) RFID chip curve ... i.e. manufacturing costs are basically per wafer, cost per chip then has been improved by making smaller chips and/or larger wafers (i.e. more chips per wafer).

At the start of this decade, one of the problems was the saw cuts to split wafers into individual (small) chips were taking more surface area than the actual chips (limiting increases in the number of chips/wafer and further chip cost reductions). New technology was eventually developed that made the cut surface area significantly smaller ... allowing significant increases in the chips/wafer (both for the ultra-small EPC RFID chips as well as our super-secure, super cheap chip).

This included ISO14443 (RFID) proximity ... "inches" ... not the "meters" that EPC RFID are spec'ed for.

Intel: an expensive many-core future is ahead of us

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel: an expensive many-core future is ahead of us
Newsgroups: alt.folklore.computers
Date: Thu, 07 Aug 2008 14:06:46 -0400
scott@slp53.sl.home (Scott Lurndal) writes:
And with VMS, one had to be careful to use the non-paged pool for data structures required during paging operations, allowing for some odd driver/ACP bugs.

when cp67 was first installed at the univ. jan68, the kernel was fixed in real storage ... but less than 70k-bytes.

over the next couple yrs, i rewrote large amount of the code, interrupt handlers, fastpaths, added dynamic adaptive resource management (it was referred to as fair share scheduler because default resource policy was fair share), page replacement algorithm and bunch of other stuff including tty/ascii terminal support ... recent tty/ascii reference:
https://www.garlic.com/~lynn/2008l.html#59 Intel: an expensive many-core future is ahead of us

a lot of the stuff was picked up and shipped in the product ... but other features were also being added and kernel size was heading towards 100k-bytes. I then implemented a mechanism that allowed parts of the kernel to be paged ... but it was restricted to lower-use, non-critical portions ... but easily gained back 30k-40k real storage. This support wasn't included in any of the cp67 releases ... but was adapted as port of the morph into vm370.

Later for vm370, I also augmented the pageable kernel process ... with mechanism that could "page" low-usage/inactive real-storage resident data structures. One of the co-op students that assisted in that work ... mentioned in this old communcation:
https://www.garlic.com/~lynn/2006v.html#email731212
in this post
https://www.garlic.com/~lynn/2006v.html#36 Why these original FORTRAN quicks?

went to work for one of the vm370 commercial time-sharing service bureaus (after graduation)
https://www.garlic.com/~lynn/submain.html#timeshare

and expanded that pageable support to enable process migration in loosely-coupled multiprocessor environment (i.e. everything for process was moved to disk ... and then brought into a different machine in the cluster). This was in the days when processors had to be taken offline for regular scheduled preventive maintenance. Some of these commercial time-sharing service bureaus had not only moved into 7x24 operations ... but were picking up world-wide clientele ... requirement was becoming around-the-clock service operation ... something that has become more common recently with globalization and the world-wide penetration of the internet.

... misc. past posts mentioning pageable kernel:
https://www.garlic.com/~lynn/2001b.html#23 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
https://www.garlic.com/~lynn/2001l.html#32 mainframe question
https://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
https://www.garlic.com/~lynn/2002n.html#71 bps loader, was PLX
https://www.garlic.com/~lynn/2002p.html#56 cost of crossing kernel/user boundary
https://www.garlic.com/~lynn/2002p.html#64 cost of crossing kernel/user boundary
https://www.garlic.com/~lynn/2003f.html#12 Alpha performance, why?
https://www.garlic.com/~lynn/2003f.html#14 Alpha performance, why?
https://www.garlic.com/~lynn/2003f.html#20 Alpha performance, why?
https://www.garlic.com/~lynn/2003f.html#23 Alpha performance, why?
https://www.garlic.com/~lynn/2003f.html#26 Alpha performance, why?
https://www.garlic.com/~lynn/2003f.html#30 Alpha performance, why?
https://www.garlic.com/~lynn/2003n.html#45 hung/zombie users ... long boring, wandering story
https://www.garlic.com/~lynn/2004b.html#26 determining memory size
https://www.garlic.com/~lynn/2004g.html#45 command line switches [Re: [REALLY OT!] Overuse of symbolic constants]
https://www.garlic.com/~lynn/2004o.html#9 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2005f.html#10 Where should the type information be: in tags and descriptors
https://www.garlic.com/~lynn/2005f.html#16 Where should the type information be: in tags and descriptors
https://www.garlic.com/~lynn/2006.html#35 Charging Time
https://www.garlic.com/~lynn/2006.html#40 All Good Things
https://www.garlic.com/~lynn/2006j.html#5 virtual memory
https://www.garlic.com/~lynn/2006n.html#11 Not Your Dad's Mainframe: Little Iron
https://www.garlic.com/~lynn/2006n.html#49 Not Your Dad's Mainframe: Little Iron
https://www.garlic.com/~lynn/2006v.html#5 Why these original FORTRAN quirks?
https://www.garlic.com/~lynn/2007.html#18 IBM sues maker of Intel-based Mainframe clones
https://www.garlic.com/~lynn/2007d.html#72 IBM S/360 series operating systems history
https://www.garlic.com/~lynn/2007n.html#57 IBM System/360 DOS still going strong as Z/VSE
https://www.garlic.com/~lynn/2008c.html#67 What happened to resumable instructions?

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Early commercial Internet activities (Re: IBM-MAIN longevity)

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Early commercial Internet activities (Re: IBM-MAIN longevity)
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 07 Aug 2008 19:30:21 -0400
bbreynolds <bbreynolds@aol.com> writes:
From that timeframe I remember ACC products for the Series/1, and realize that I had already implemented the needed functionality on the Series/1 which I supported. I will look for my ACC documentation to see what products they were offering (that being communications cards for the Series/1) which had functionality beyond which I could pull out of the IBM communications features cards of that time period (early/mid 1980s). I do recall a lot of hype in the advertisements, but not a lot of specifics in the documentation.

HSDT project
https://www.garlic.com/~lynn/subnetwork.html#hsdt

had quite a few Series/1 with *Zirpel* cards ... these supported T1 ... and were original for fed. gov. that had some number of T1s supported by 2701s getting quite long in the tooth by the mid-80s.

re:
https://www.garlic.com/~lynn/2008l.html#23 Memories of ACC, IBM Channels and Mainframe Internet Devices

we also went head-to-head over whether HSDT would market a pu4/pu5 emulator (implemented on series/1) as product ... with plans to upgrade to 801/rios platform
https://www.garlic.com/~lynn/99.html#67 System/1 ?
https://www.garlic.com/~lynn/99.html#70 Series/1 as NCP (was: Re: System/1 ?)

as mentioned, i had already gotten blamed for clone controller business as part of having developed plug-compatible controller when I was undergraduate.

misc. past posts mentioning zirpel cards:
https://www.garlic.com/~lynn/2001.html#4 Sv: First video terminal?
https://www.garlic.com/~lynn/2003d.html#13 COMTEN- IBM networking boxes
https://www.garlic.com/~lynn/2003m.html#28 SR 15,15
https://www.garlic.com/~lynn/2004g.html#37 network history
https://www.garlic.com/~lynn/2004l.html#7 Xah Lee's Unixism
https://www.garlic.com/~lynn/2005j.html#59 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
https://www.garlic.com/~lynn/2006n.html#25 sorting was: The System/360 Model 20 Wasn't As Bad As All That
https://www.garlic.com/~lynn/2007f.html#80 The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2008e.html#45 1975 movie "Three Days of the Condor" tech stuff

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Blinkylights

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Blinkylights
Newsgroups: alt.folklore.computers
Date: Thu, 07 Aug 2008 19:54:48 -0400
krw <krw@att.bizzzzzzzzzz> writes:
Yes, even the IBM sr. execs have trouble with this concept. Years ago, cow-orker was told to get the delay out of the demo satellite link before the next demo. When exec was told about the speed limit, he replied "then move the satellite closer". Good plan.

one of the things had in HSDT
https://www.garlic.com/~lynn/subnetwork.html#hsdt

was TDMA satellite system ... with transponder on SBS4 (SBS started out being jointly owned by ibm, aetna, and comsat) and some number of earth stations (4.5m dishes, except a 7m dish in austin; austin was more humid and satellite was closer to horizon so signal had much more atmosphere to travel thru).

some what motivated by background in dynamic adaptive resource management ... i worked on being able to change packet transmission on superframe boundary. i also worked on rate-based pacing ... as much more stable and adaptive that window-based implementations (and starting to treat as TDMA satellite as WAN, real packets as opposed to emulated circuits).

one of the issues/problems that the communication group had was they were still mired in (circuit-oriented) window-based pacing ... which had difficulty handling single-hop delays (and there were some operations that had multi-hop delay from west coast to europe).

the other issue for much of the communication group was that they were excessively half-duplex oriented (in part because of mainframe channel operation). When we had to deal with full-duplex circuit situation from mainframe side ... implementated dual simplex (one interface dedicated to outgoing, another interface dedicated to incoming) as approach to driving full-duplex.

we had earth station digital TDMA electronics built to spec by a couple different vendors. later we were told by the vendors that they were approached by another company asking if they would build a set of (identical) earth stations for them (to the same spec).

old story about switching back and forth between SNA and VNET on a double-hop connection between STL and Hursley:
https://www.garlic.com/~lynn/93.html#28 Log Structured filesystems -- think twice
https://www.garlic.com/~lynn/94.html#22 CP spooling & programming technology
https://www.garlic.com/~lynn/99.html#212 GEOPLEX
https://www.garlic.com/~lynn/2002q.html#35 HASP:
https://www.garlic.com/~lynn/2003j.html#19 tcp time out for idle sessions
https://www.garlic.com/~lynn/2004k.html#19 FAST TCP makes dialup faster than broadband?
https://www.garlic.com/~lynn/2004o.html#60 JES2 NJE setup
https://www.garlic.com/~lynn/2004o.html#61 360 longevity, was RISCs too close to hardware?
https://www.garlic.com/~lynn/2006m.html#16 Why I use a Mac, anno 2006
https://www.garlic.com/~lynn/2006s.html#17 bandwidth of a swallow (was: Real core)
https://www.garlic.com/~lynn/2007j.html#39 Newbie question on table design
https://www.garlic.com/~lynn/2007p.html#63 Damn

other posts mentioning rate-based pacing work:
https://www.garlic.com/~lynn/99.html#33 why is there an "@" key?
https://www.garlic.com/~lynn/2000b.html#11 "Mainframe" Usage
https://www.garlic.com/~lynn/2001h.html#44 Wired News :The Grid: The Next-Gen Internet?
https://www.garlic.com/~lynn/2002.html#38 Buffer overflow
https://www.garlic.com/~lynn/2002i.html#45 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002i.html#57 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002k.html#56 Moore law
https://www.garlic.com/~lynn/2002p.html#28 Western Union data communications?
https://www.garlic.com/~lynn/2002p.html#31 Western Union data communications?
https://www.garlic.com/~lynn/2003.html#55 Cluster and I/O Interconnect: Infiniband, PCI-Express, Gibat
https://www.garlic.com/~lynn/2003.html#59 Cluster and I/O Interconnect: Infiniband, PCI-Express, Gibat
https://www.garlic.com/~lynn/2003b.html#44 filesystem structure, was tape format (long post)
https://www.garlic.com/~lynn/2003g.html#54 Rewrite TCP/IP
https://www.garlic.com/~lynn/2003g.html#64 UT200 (CDC RJE) Software for TOPS-10?
https://www.garlic.com/~lynn/2003j.html#1 FAST - Shame On You Caltech!!!
https://www.garlic.com/~lynn/2003j.html#46 Fast TCP
https://www.garlic.com/~lynn/2003p.html#15 packetloss bad for sliding window protocol ?
https://www.garlic.com/~lynn/2004f.html#37 Why doesn't Infiniband supports RDMA multicast
https://www.garlic.com/~lynn/2004k.html#8 FAST TCP makes dialup faster than broadband?
https://www.garlic.com/~lynn/2004k.html#12 FAST TCP makes dialup faster than broadband?
https://www.garlic.com/~lynn/2004k.html#13 FAST TCP makes dialup faster than broadband?
https://www.garlic.com/~lynn/2004k.html#16 FAST TCP makes dialup faster than broadband?
https://www.garlic.com/~lynn/2004k.html#29 CDC STAR-100
https://www.garlic.com/~lynn/2004n.html#35 Shipwrecks
https://www.garlic.com/~lynn/2004o.html#62 360 longevity, was RISCs too close to hardware?
https://www.garlic.com/~lynn/2004q.html#3 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2004q.html#57 high speed network, cross-over from sci.crypt
https://www.garlic.com/~lynn/2005d.html#6 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005g.html#4 Successful remote AES key extraction
https://www.garlic.com/~lynn/2005q.html#22 tcp-ip concept
https://www.garlic.com/~lynn/2005q.html#28 tcp-ip concept
https://www.garlic.com/~lynn/2005q.html#37 Callable Wait State
https://www.garlic.com/~lynn/2005t.html#38 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2006d.html#21 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006g.html#18 TOD Clock the same as the BIOS clock in PCs?
https://www.garlic.com/~lynn/2006m.html#20 Why I use a Mac, anno 2006
https://www.garlic.com/~lynn/2006n.html#21 The System/360 Model 20 Wasn't As Bad As All That
https://www.garlic.com/~lynn/2006o.html#64 The Fate of VM - was: Re: Baby MVS???
https://www.garlic.com/~lynn/2006u.html#44 waiting for acknowledgments
https://www.garlic.com/~lynn/2007m.html#46 Rate Monotonic Scheduling (RMS) vs. OS Scheduling
https://www.garlic.com/~lynn/2007n.html#58 Computer Clocks
https://www.garlic.com/~lynn/2007q.html#19 Fixing our fraying Internet infrastructure
https://www.garlic.com/~lynn/2007q.html#41 Newsweek article--baby boomers and computers
https://www.garlic.com/~lynn/2008e.html#19 MAINFRAME Training with IBM Certification and JOB GUARANTEE
https://www.garlic.com/~lynn/2008e.html#28 MAINFRAME Training with IBM Certification and JOB GUARANTEE
https://www.garlic.com/~lynn/2008f.html#1 independent appraisers
https://www.garlic.com/~lynn/2008g.html#35 Does TCP Need an Overhaul?
https://www.garlic.com/~lynn/2008i.html#45 ARPANet architect: bring "fairness" to traffic management

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Crippleware: hardware examples

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Crippleware: hardware examples
Newsgroups: alt.folklore.computers
Date: Thu, 07 Aug 2008 22:51:38 -0400
bbreynolds <bbreynolds@aol.com> writes:
The SMD disk drive(s) on MAI Basic IV systems could be jumpered so that only half of the cylinders were accessible: the nominal 80mb disks were hobbled to 40mb. The jumper was on the disk controller board in the Basic IV, not on the CDC side of the SMD connection, and was visible without even pulling the board from the chassis. No software change was necessary to use the additional disk space.

we had semi-facetious "fast" 3380 proposal ... a special model of 3380 that was half the capacity and faster than standard 3380 that would sell for a higher price ... actually it was just a microcode tweak to restrict the apparent number of cylinders on a standard 3380; faster was purely from lower avg. arm access (fewer cyls to travel). recent reference
https://www.garlic.com/~lynn/2008e.html#60 z10 presentation on 26 Feb

various installations looked favorably on the proposal since they felt unable to convince executives that better system thruput and therefor system cost effectiveness came from leaving 3380s partially empty.

part of what started this was that internally, there was a program called mdreorg that fed system disk & file activity, would create specification to drive moving stuff around to load-balance activity across 3330 and 3350 drives.

for an installation doing migration from 3350s to 3380s ... mdreorg was used to set things up for the data move from 3350 drives to 3380 drives. however, mdreorg (modeling) showed that completely filling 3380 drives (from 3350 configuration) would result in lower system thruput (than the all 3350 configuration) ... aka the increase in 3380 storage capacity (compared to 3350) was much larger than the increase in the 3380 thrput (compared to 3350). completely filling a 3380 with active data resulted in over all lower thruput than having the same amount of data on (multiple) 3350.

3350, 555 cyls, 578kbytes/cyl, 321mbytes/drive
3380, 885 cyls, 720kbytes/cyl, 638mbytes/drive

past posts in this thread:
https://www.garlic.com/~lynn/2008k.html#64 Crippleware: hardware examples
https://www.garlic.com/~lynn/2008k.html#65 Crippleware: hardware examples
https://www.garlic.com/~lynn/2008k.html#66 Crippleware: hardware examples
https://www.garlic.com/~lynn/2008k.html#69 Crippleware: hardware examples

another approach to this subject was comments that I was making that disk technology over extended period had relative system thrput declined by an order of magnitude ... aka disks got faster ... but the processor got faster ten times that of the increase in disk performance. recent posts mentioning decline in disk relative system thruput
https://www.garlic.com/~lynn/2008i.html#8 pro- foreign key propaganda?
https://www.garlic.com/~lynn/2008j.html#1 OS X Finder windows vs terminal window weirdness
https://www.garlic.com/~lynn/2008k.html#60 recent mentions of 40+ yr old technology

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Blinkylights

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Blinkylights
Newsgroups: alt.folklore.computers
Date: Thu, 07 Aug 2008 23:00:43 -0400
"Rostyslaw J. Lewyckyj" <urjlew@bellsouth.net> writes:
That's the picture I was looking for! A marine with handtruck hauling a 140 kg spool of AWG 30 teflon coated copper wire. A big marine, since adm. Hopper was not a large woman.

a couple recent posts
https://www.garlic.com/~lynn/2007r.html#46 Students mostly not ready for math, science college courses
https://www.garlic.com/~lynn/2008c.html#19 Toyota Sales for 2007 May Surpass GM

mentioning (in high school), three of us unloading flatbed truck trailer w/500 (94lb) cement sacks ... I was carrying four at a time, no handtruck

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

dollar coins

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: dollar coins
Newsgroups: alt.folklore.computers
Date: Fri, 08 Aug 2008 09:53:07 -0400
Anne & Lynn Wheeler <lynn@garlic.com> writes:
... there continue to be some number of news stories about billions in toxic CDOs that merrill unloaded last week at 22cents on the dollar ...

re:
https://www.garlic.com/~lynn/2008l.html#44 dollar coins

business news show this morning was talking about exactly year ago, everybody was still carrying all these stories about how rosy the home mortgage market still looked ... and how long it took for it to come all crashing down

it use to be mortgages were originated by regulated financial institutions (with money from account deposits).

lots of mortgages have been originated by unregulated institutions that could unload them as toxic CDOs ... for nearly unlimited supply of money to keep on originating mortgages (didn't need deposits).

one reason that these toxic CDOs were selling so well was they were getting triple-A ratings ... regardless of the underlying values (CDOs had been used two decades ago in the S&L crisis to obfuscate the underlying value). With no regard to underlying values, and (seemmingly) unlimited source of funds (in large part because of the triple-A rating) ... profit on mortgage origination was effectively how many and fast (and being able to ignore mortgage quality because they were being unloaded as toxic CDOs and became somebody else's problem).

long-winded, decade old post about several related issues including problem with visibility into underlying value of CDO-like instruments.
https://www.garlic.com/~lynn/aepay3.htm#riskm

unregulated (risky) investment banking houses were buying up these (safe) toxic CDOs ... and leveraging 40-50 times; some even more (i.e. borrow against full value of "safe" toxic CDO and buy another ... repeat 40-50 times) ... possibly only 2-3 percent (or less) actual capital involved.

a decade ago, Glass-Steagall had been repealed (Glass-Steagall had been passed in the wake of the '29 crash to keep the safety&soundness of regulated banking separate from risky, unregulated investment banking).

lots of regulated banking now find themselves with (unregulated) risky investment banking units that turned out were enormously leveraged with toxic CDOs (at one time may have had triple-A rating). there supposedly have been about $500bil in writedowns as part of selling off these toxic CDOs (a lot at 22cents on the dollar). News stories have been claiming that citigroup will win the writedown sweepstakes ... citigroup also being instrumental in the repeal of Glass-Steagall
http://www.pbs.org/wgbh/pages/frontline/shows/wallstreet/weill/demise.html

Current buzzword is moral hazard ... the FED bailing out risky behavior... where risky behavior is supposedly both being able to succeed as well as fail ... and moral hazard is behavior that gets worse when there appears to be no downside consequences (i.e. failure) to risky behavior.

for a little drift ... article on bank borrowing from FED; 1910 to this year
http://research.stlouisfed.org/fred2/series/BORROW

related comment (in blog that cited the above)
https://www.garlic.com/~lynn/2008l.html#51 Monetary affairs on free reign, but the horse has Boulton'd

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Taxes

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Taxes
Newsgroups: alt.folklore.computers
Date: Fri, 08 Aug 2008 12:32:58 -0400
kkt <kkt@zipcon.net> writes:
There's no need to go that far back. During the World Trade Organization meeting in Seattle, violent protesters, nonviolent protestors, bystanders, and random people going about their business all indiscriminately got thrown into holding pens for several days. The police (the worst were the suburban police departments called in for help) were eventually found to have been at fault and the city had to pay damages, but only years later.

the "W" in downtown seattle had its grand opening that week and X9 standards organization also had its meeting at the "W" ... and people attending X9 got invitations to attend the "W" grand opening party. "W" was on a corner ... part of it faced the street that had most of the damage from the protesters ... some of which was going on that night. "W" didn't have much damage ... possibly because there were a lot of city & state officials at the opening and there were extra LEOs around the bldg.

the "W" grand opening ceremony reminded me a little of RSA party at the san jose coliseum ... which was billed as the "last great dataprocessing IT party" ... past reference:
https://www.garlic.com/~lynn/2006r.html#15 50th Anniversary of invention of disk drives

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Verifying Verified By Visa - Registration breaks chain of trust

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Verifying Verified By Visa - Registration breaks chain of trust
Newsgroups: uk.finance,uk.tech.electronic-security,comp.security.ssh
Date: Fri, 08 Aug 2008 12:48:20 -0400
"Andy Pandy" <spam8times@wonderful.spam.invalid> writes:
I'm probably missing something here - but I don't understand your concern. Why is the link to the signon page from a normal ("unsecure") http page a problem?

Most banks have links to their interbank banking signon page from a normal http page, and always have done, and sometimes that's the only way to get to the signon page.

Provided they don't ask for the security details on the unsecure page what's the problem?

Or are you thinking of a DNS server/host file hijack type scenario?


same thread in comp.security.misc
https://www.garlic.com/~lynn/2008l.html#28 Verifying Verified By Visa - Registration breaks chain of trust
https://www.garlic.com/~lynn/2008l.html#29 Verifying Verified By Visa - Registration breaks chain of trust
https://www.garlic.com/~lynn/2008l.html#30 Verifying Verified By Visa - Registration breaks chain of trust
https://www.garlic.com/~lynn/2008l.html#31 Authentication in the e-tailer / payment gateway / customer triangle
https://www.garlic.com/~lynn/2008l.html#32 Authentication in the e-tailer / payment gateway / customer triangle
https://www.garlic.com/~lynn/2008l.html#33 Authentication in the e-tailer / payment gateway / customer triangle
https://www.garlic.com/~lynn/2008l.html#34 Authentication in the e-tailer / payment gateway / customer triangle

we had been brought to consult with small client/server company that wanted to do payment transactions on their server and had this technology they had invented called SSL they wanted to use ... the result is now frequently referred to as electronic commerce. Part of what was done was something called a payment gateway ... and we mandated some amount of the usage interface between the webservers and the payment gateway ... including implementing something called "mutual authentication" (which wasn't implemented at the time). misc. past posts mentioning payment gateway for electronic commerce
https://www.garlic.com/~lynn/subnetwork.html#gateway

we also did detailed protocol and business process walk thru of SSL, digital certificates and these new businesses calling themselves certification authorities.

for the payment gateway process, SSL mutual authentication evolved to the point where it was apparent that digital certificates were redundant and superfluous ... and there use was just a side-effect of using the existing SSL software library ... aka the payment gateway had table of all authorized webservers and each webserver had table with details about the payment gateway (so obtaining the corresponding public key from a digital certificate was superfluous).

also, at the time, the use of SSL domain name authentication ... by clients were based on some business process assumptions ... in order to result in:
the webserver that a client is interacting with ... is the webserver that they think they are interacting with

aka

1) the client understood the relationship between the server they wanted to talk to and the server's URL

2) the client supplied the URL to the browser

3) the browser validated the digital certifcate obtained from the server

4) the browser validated the URL corresponded with the URL in the (validated) digital certificate

misc. past posts mentioning SSL domain name digital certficates and/or domain name digital certification
https://www.garlic.com/~lynn/subpubkey.html#sslcerts

Almost immediately electronic commerce webservers discouvered that SSL cut their thruput significantly and they dropped back to using SSL just for payment/checkout. This created a large disconnect in the assumption about the SSL business process and the associated integrity/security that it provided. No longer was SSL being used to validate the URL provided for initial contact.

The payment/checkout paradigm has the (typically completely unvalidated) webserver making claims about a button that is clicked on. The client clicks on a button which results in the webserver supplying a URL to the browser (not the client). This now typically creates a huge disconnect between the webserver that a client thinks they are talking to and the associated URL.

Since the browser is only validating that the authenticated supplied digital certificate corresponds to the supplied URL (not by the client but by the webserver that hasn't been authenticated) ... SSL typical is now
the webserver that a client is interacting with ... is the webserver that the webserver claims to be

There is a huge difference between validating that the webserver is the webserver the client believes it to be vis-a-vis validating that the webserver is the webserver that it claims to be.

This is also at the root of phishing vulnerabilities ... an email has verbage saying clicking on a button takes the client to a banking webserver ... the actual URL is for some webserver under control of an attacker ... who has applied for and obtained a valid domain name digital certificate for that webserver (proving that the webserver is the valid webserver for that URL).

The critical issue in the original SSL deployment was that the client knew & understood the relationship between the webserver they believed they were talking to and that webserver's (SSL validated) URL. That has become increasingly rare in the current environment.

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

dollar coins

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: dollar coins
Newsgroups: alt.folklore.computers
Date: Fri, 08 Aug 2008 14:04:38 -0400
Anne & Lynn Wheeler <lynn@garlic.com> writes:
lots of regulated banking now find themselves with (unregulated) risky investment banking units that turned out were enormously leveraged with toxic CDOs (at one time may have had triple-A rating). there supposedly have been about $500bil in writedowns as part of selling off these toxic CDOs (a lot at 22cents on the dollar). News stories have been claiming that citigroup will win the writedown sweepstakes ... citigroup also being instrumental in the repeal of Glass-Steagall
http://www.pbs.org/wgbh/pages/frontline/shows/wallstreet/weill/demise.html


re:
https://www.garlic.com/~lynn/2008l.html#67 dollar coins

slightly different issue for citi

Banks Back Down
http://www.forbes.com/home/2008/08/07/auction-rate-securities-biz-wallstreet-cx_lm_0807banks2.html
New York Lambasts Citi
http://www.forbes.com/home/2008/08/01/citigroup-sec-cuomo-markets-equity-cx_cg_0801markets32.html
Citi Comes Clean
http://www.forbes.com/business/2008/08/07/auction-rate-securities-biz-wallstreet-cx_lm_0807citi.html
Citigroup returning billions to investors
http://www.forbes.com/topstories/feeds/ap/2008/08/07/ap5300539.html
Banks' settlements: Rare good deal for investors
http://money.cnn.com/2008/08/07/news/companies/citisettle/index.htm?postversion=2008080718

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

md5

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: md5
Newsgroups: alt.folklore.computers
Date: Fri, 08 Aug 2008 17:04:56 -0400
greymaus <greymausg@mail.com> writes:
I suppose the sci.crypt would be the area for this question, but I have lost contact with that so maybe someone here can help?'

there is a great interest in hashing passwords, md5, etc, which seems to be unreversible. One site, at least, is claiming to be able to reverse them.

Now, if one hashed a wordlist (extended by salting) and built up a stonking great database (big hard disks are fairly cheap) and just searched it, would that not solve the problem?


an application of md5 is used to verify whether some software is valid/changed. the issue was can malicious software be combined with other information so that it results in matching md5 for some "valid" software (or other kinds of different information resulting in same md5 hash)

there was presentation on this at crypto 2004 ... and one of the attendees contacted me in real time during the presentation ... asking if i had a list of all RFCs with md5 reference. Old posts with reference
https://www.garlic.com/~lynn/2004j.html#56 RFCs that reference MD5
https://www.garlic.com/~lynn/2004k.html#6 Losing colonies

a later thread:
https://www.garlic.com/~lynn/2005o.html#0 The Chinese MD5 attack
https://www.garlic.com/~lynn/2005o.html#1 The Chinese MD5 attack
https://www.garlic.com/~lynn/2005o.html#3 The Chinese MD5 attack
also article here about same time:
http://www.cryptography.com/cnews/hash.html

my rfc index
https://www.garlic.com/~lynn/rfcietff.htm
list of RFCs that reference md5
https://www.garlic.com/~lynn/rfcmd5.htm

SHA-1 is stronger than md5 ... but there was requirement for even stronger versions ... SHA-224, ..., SHA-512 (collectively referred to as SHA-2). Now open competition for SHA-3 (similar to AES) replacement ... wiki page:
https://en.wikipedia.org/wiki/SHA-1

somewhat related is an (RFC) one-time-password standard based on iterative hashing. some old posts discussing an attack/vulnerability
https://www.garlic.com/~lynn/aadsm20.htm#24 [Clips] Escaping Password Purgatory
https://www.garlic.com/~lynn/2003m.html#50 public key vs passwd authentication?
https://www.garlic.com/~lynn/2003n.html#1 public key vs passwd authentication?
https://www.garlic.com/~lynn/2004b.html#45 Foiling Replay Attacks
https://www.garlic.com/~lynn/2005i.html#50 XOR passphrase with a constant
https://www.garlic.com/~lynn/2005l.html#8 derive key from password
https://www.garlic.com/~lynn/2005o.html#0 The Chinese MD5 attack
https://www.garlic.com/~lynn/2006u.html#4 ssh - password control or key control?

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Error handling for system calls

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Error handling for system calls
Newsgroups: alt.folklore.computers
Date: Fri, 08 Aug 2008 21:16:26 -0400
Rich Alderson <news@alderson.users.panix.com> writes:
Most early system calls on Tops-10 and TOPS-20 feature "skip-return" on success,[1] that is, skip the next instruction in line and continue from the one following, which allows an error-processing routine to be called/branched to if there's no skip. (System calls developed later tended to provide error codes in a return AC instead.) This is part of what makes it very easy to handle system-call error returns--and to ignore them by putting a NOP of some kind (there are several) at the instruction following a system call.

original cms system calls were svc202 ... that would have dc al4(address) immediately following the svc instruction as an error return (transfer to the indicated address). no error would instead return to the instruction at plus four after the instruction. This was 24 bit addressing ... so it could tell if there was an error return address by the first byte immediately following the supervisor call being zero (non-zero byte assumed to be an instruction and no error return was specified).

i had done paged mapped filesystem and a bunch of shared segment enhancements and ported them to vm370 ... old email reference about csc/vm system built on vm370 release two base:
https://www.garlic.com/~lynn/2006w.html#email750102
with subsequent update a couple months later
https://www.garlic.com/~lynn/2006w.html#email750430

one of the things supported was that the same shared, read-only, executable code could appear at different virtual addresses in different virtual address spaces. embedded addresses within such code ... like used by svc202 supervisor call convention gave me lots of heartburn ... i had to rework the code to still be able to still have error return ... while not having code with embedded addresses. lots of past posts about the problems with absolute addresses.
https://www.garlic.com/~lynn/submain.html#adcon

the product group picked up a small subset of the csc/vm shared segment support for release in vm370 release 3 ... the subset didn't include support for same shared image appearing at different addresses in different virtual address spaces.

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Blinkylights

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Blinkylights
Newsgroups: alt.folklore.computers
Date: Sat, 09 Aug 2008 10:21:09 -0400
bbreynolds <bbreynolds@aol.com> writes:
All a matter of balance: note that the bags were on a flatbed truck, which means that they did not have to be LIFTED, only carried (assume on shoulders).

re:
https://www.garlic.com/~lynn/2008l.html#66 Blinkylights

stacked four high carried across the front of the body (hands underneath bottom sack) ... four sacks on the shoulder wasn't stable (or even two on each shoulder) ... also hard to get positioned on the shoulder (one or two sacks on shoulder wasn't bad) ... carried into the warehouse and lowered to the floor.

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Blinkylights

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Blinkylights
Newsgroups: alt.folklore.computers
Date: Sat, 09 Aug 2008 11:07:54 -0400
re:
https://www.garlic.com/~lynn/2008l.html#66 Blinkylights
https://www.garlic.com/~lynn/2008l.html#73 Blinkylights

for another kind of topic drift ... attended the evening ceremonies at 8th&I on the first ... it was hot & muggy.

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Intel: an expensive many-core future is ahead of us

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel: an expensive many-core future is ahead of us
Newsgroups: alt.folklore.computers
Date: Sat, 09 Aug 2008 13:46:51 -0400
Morten Reistad <first@last.name> writes:
That other system was a Prime.

recent post about PCM controllers being motivation for future system project
https://www.garlic.com/~lynn/2008l.html#23 Memories of ACC, IBM Channels and Mainframe Internet Devices

after future system project was killed
https://www.garlic.com/~lynn/submain.html#futuresys

there was mad rush to get stuff back into the 370 product pipeline. some of that contributed to the development group picking up various stuff that i had been doing (all along) on 370 ... and scheduling for ship in product ... stray reference in this recent post:
https://www.garlic.com/~lynn/2008l.html#72 Error handling for system calls

one of the efforts (by favorite son operating system) was to get vm370 product killed, the vm370 development group (in burlington mall) shutdown ... and all the vm370 developers moved to POK and assigned to supporting mvs/xa development (supposedly it was critical required resources in order to meet mvs/xa ship schedule). a few recent references (endicott did manage to save the vm370 product mission, but had to reconstitute the staff):
https://www.garlic.com/~lynn/2008.html#19 Tap and faucet and spellcheckers [was: Re: What do YOU call
https://www.garlic.com/~lynn/2008e.html#30 VMware signs deal to embed software in HP servers
https://www.garlic.com/~lynn/2008g.html#48 How did third-party software companies deal with unbundling being sprung on them?
https://www.garlic.com/~lynn/2008j.html#78 How powerful C64 may have been if it used an 8 Mhz 8088 or 68008 ?microprocessor (with otherwise the same hardware)?

some number of the vm370 developors refused to leave boston area ... some showing up at prime ... others showing up working on vms.

there was a joke that executive decision to shutdown vm370 and burlington mall location contributed significantly to early vms.

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

squirrels

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: squirrels
Newsgroups: alt.folklore.computers
Date: Sat, 09 Aug 2008 15:36:37 -0400
David Powell <ddotpowell@icuknet.co.uk> writes:
I'm still using a -DX4/100 machine on cnc stuff, perhaps that is AMD?

fyi ... Intel 80486DX4:
https://en.wikipedia.org/wiki/Intel_80486DX4

from above:
Intel produced i486DX4s with two clock speed steppings: A 75 MHz version (3× 25 MHz multiplier) in 1994, and a 100 MHz version (usually 3× 33.3 MHz, but sometimes 2.5× 40 MHz or 2× 50 MHz) with an improved write-back CPU cache in 1996. i486 OverDrive editions of the i486DX4 had locked multipliers, and therefore can run only at 3x the external clock-speed.

... snip ...

and ...

Am486:
https://en.wikipedia.org/wiki/Am486

from above:
Am486 DX4-100 100 MHz 3.3 V 8 WT 1995
Am486 DX4-120 120 MHz 3.3 V 8 WT


... snip ...

random past posts mentioning 486dx
https://www.garlic.com/~lynn/94.html#40 process sleeping?
https://www.garlic.com/~lynn/94.html#43 Bloat, elegance, simplicity and other irrelevant concepts
https://www.garlic.com/~lynn/94.html#55 How Do the Old Mainframes Compare to Today's Micros?
https://www.garlic.com/~lynn/2001n.html#82 a.f.c history checkup... (was What specifications will the standard year 2001 PC have?)
https://www.garlic.com/~lynn/2002i.html#12 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002n.html#1 Tweaking old computers?
https://www.garlic.com/~lynn/2003d.html#33 Why only 24 bits on S/360?
https://www.garlic.com/~lynn/2007s.html#20 Ellison Looks Back As Oracle Turns 30
https://www.garlic.com/~lynn/2008k.html#69 Crippleware: hardware examples

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Blinkylights

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Blinkylights
Newsgroups: alt.folklore.computers
Date: Mon, 11 Aug 2008 09:28:37 -0400
"Rostyslaw J. Lewyckyj" <urjlew@bellsouth.net> writes:
Yes, you do like to brag about your accomplishments in your postings. ;)

re:
https://www.garlic.com/~lynn/2008l.html#66 Blinkylights
https://www.garlic.com/~lynn/2008l.html#73 Blinkylights
https://www.garlic.com/~lynn/2008l.html#74 Blinkylights

i guess it was a little too obtuse comment about possible difference in views (related to degree of effort) between white color and manual labor sub-cultures.

bragging is nominally more associated with events that showup in the olympics ... stuff like ...
https://en.wikipedia.org/wiki/Weightlifting

actually having personal experience with something ... might also be construed as issue with other things :) ... possibly like
https://www.garlic.com/~lynn/2008l.html#72 Error handling for system calls

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Yet another squirrel question - Results (very very long post)

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Yet another squirrel question - Results (very very long post)
Newsgroups: alt.folklore.computers
Date: Mon, 11 Aug 2008 10:53:59 -0400
jmfbahciv <jmfbahciv@aol> writes:
interlocked. Also, much data is local to an individual processor,\ and so such per-processor data also require no interlock. The\ only data that must be interlocked are true system-global data.\ An excellent example of such data is the scheduler database -\ scanning, adding processes to, and removing processes from the\ run-queues\ must be single-threaded and is therefore protected in MP by a\ scheduler spin lock.\

this is example of what led charlie to inventing compare&swap instruction when he was working on fine-grain smp locking for cp67:
https://www.garlic.com/~lynn/subtopic.html#545tech

more than 20yrs earlier (i.e. above reference is dated 31oct91). there was then push-back getting compare&swap instruction included in 370 architecture ... claims that the test&set instruction from 360 smp operation (in the 60s) was more than sufficient (used by cp67 smp implementation on 360/67 multiprocessor)

the challenge was to come up with non-smp specific requirement for atomic compare&swap instruction ... and thus was born the description use for multi-threaded applications (independent of whether then ran on smp or non-smp hardware). description still survives in current principles of operation:

A.6 Multiprogramming and Multiprocessing Examples
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/A.6?SHELF=DZ9ZBK03&DT=20040504121320

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

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Book: "Everyone Else Must Fail" --Larry Ellison and Oracle ???

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Book: "Everyone Else Must Fail" --Larry Ellison and Oracle ???
Newsgroups: alt.folklore.computers
Date: Mon, 11 Aug 2008 18:22:24 -0400
hancock4 writes:
I don't think this concept--a central library computer--ever took off because the cost of enough disk space to hold information (as done today) would have simply been too expensive back in the 1960s and 1970s. Also, until the 1990s the cost of terminals, even dumb ones, was still too high for home use.

lot of (mit) project athena (X-windows, kerberos, hesiod, zephyr, etc) was personality-less workstations in the terminal rooms ... with home-directories (individual's personal files) at servers.

DEC & IBM were jointly funding athena ... with assistant directors from respective corporations ... charlie, who had invented compare&swap instruction at the science center ... recent reference
https://www.garlic.com/~lynn/2008l.html#78 Yet another squirrel question - Results (very very long post)

... did a stint as a project athena assistant director

the corporate sponsors also got to periodically review projects ... and we would perform the duties from time to time (one visit, I remember sitting thru early design sessions working out details for cross-domain kerberos).

for other topic drift ... past posts about kerberos pk-init (i.e. using public key and digital signatures in lieu of passwords ... originally w/o digital certificates ... having recorded public key in place of recording password)
https://www.garlic.com/~lynn/subpubkey.html#kerberos

i got a 2741 terminal at home mar70 ... that went thru some number of changes over the years ... cdi miniterm, ibm 3101 ... and eventually ibm/pc in the early 80s ... with terminal emulation (I've got an old picture, circa 80 or 81 with home 3101 on one side of desk and microfiche viewer (about the same size as 3101) on the other side. There was a microfiche output device on the plant site ... and it was about as easy to print on the microfiche printer ... as printing on 3800.

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Book: "Everyone Else Must Fail" --Larry Ellison and Oracle ???

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: Wed, 13 Aug 2008 15:07:09 -0700 (PDT)
Subject: Re: Book: "Everyone Else Must Fail" --Larry Ellison and Oracle ???
hancock4 writes:
I don't think this concept--a central library computer--ever took off because the cost of enough disk space to hold information (as done today) would have simply been too expensive back in the 1960s and 1970s. Also, until the 1990s the cost of terminals, even dumb ones, was still too high for home use.

in the 60s, ONR was given out some number of grants for digital libraries or at least digital card catalogues .... the univ. got one ... and it also got selected by IBM as beta-test site for original CICS product ... and i got tasked to help support/debug CICS as part of the library digital catalogue effort. Data structure was maintained in BDAM. misc. past posts mentioning CICS, BDAM, CICS beta test ...
https://www.garlic.com/~lynn/submain.html#bdam

a little over decade ago ... had chance to get involved with looking at NIH's NLM (national library of medicine) searchable online catalogue ... which was a mainframe BDAM implementation ... but using their own online multi-threaded transaction monitor. Two of the people that had originally done the implementation in the late 60s were still around (they did something very similar, but much larger scope as what i had gotten tasked to support at the univ almost exact same time).

They had noted that sometime in the early 80s ... that their catalogue/index had gotten so big that people were having online query problems .... frequently tending to be very bi-model results at 5-8 boolean search terms .... aka with one fewer terms response would have 100k items ... one more boolean term and response would be zero items. Holy grail was finding query that would result in more than zero ... but less than a thousand.

Supposedly a big advance around '83 was GratefulMed an terminal emulation/query application tat ran on AppleII. Instead of asking for the responses ... GratefulMed would default to asking for the number of responses. The strategy was to do a lot of queries with slight variations until finding one that resulted in a reasonable number of responses. old post mentioning GratefulMed
https://www.garlic.com/~lynn/2001m.html#51 Author seeks help - net in 1981

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Intel: an expensive many-core future is ahead of us

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: Fri, 15 Aug 2008 15:07:09 -0700 (PDT)
Subject: Re: Intel: an expensive many-core future is ahead of us
On Aug 14, 2:35 am, "Charlie Gibbs" wrote:
I was once sent to a customer site to analyze an inventory listing program they had written. Based on the progress it had made when they killed it, they calculated that it was going to take 50 hours to plow through a 32,000-item inventory file. The genius who had written this monster was obviously fresh out of school, with a head crammed full of the latest Structured Programming zealotry, which meant that the program was spending as much time calling and returning from subroutines as it was getting useful work done - and even more time loading and unloading overlays.

i was asked to look at large 450k line cobol program that ran on a few scores fully tricked out mainframes (avg. $30m per). they had large staff that was involved in performance optimization. they heavily used a program that sampled instruction address execution ... looking for code hotspots (to be optimized).

they had also brought in a consultant that had a sophisticated modeling program that would help highlight bottlenecks. Turned out the consultant in the early 90s troubled period ... had acquired rights to a many times descendant of the "performance predicator" ... which was implemented in apl. they had used a apl->c language converter to translate the program and was doing performance consulting work around the world.

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

in the 60s & 70s had done a lot of pioneering work in performance measurement and modeling ... including what was to eventually become capacity planning.

emulation & sampling technology included various technologies that was used by the vs/repack application ... for program reorganization for virtual memory operation.

also there was a lot of analytically modeling implemented in apl ... which eventually was deployed on the hone systems
https://www.garlic.com/~lynn/subtopic.html#hone

as sales & marketing support tool called performance predictor ... local sales reps could enter customer workload and configuration information and then ask "what-if" questions (adding hardware, changing workload, etc).

another technology used extensively at the science center was multiple regression analysis. since this specific (450k line) cobol production system had been so heavily studied with execution samplers and modeling ... i suggested i take a go with multiple regression analysis. I got execution stats for a hundred or so different kinds of transactions and the corresponding resource utiliation during the period.

I was able to find ... a relatively infrequent business transaction that would account for 25% of total resource use. Once this was highlighted ... that business transaction was reworked to use significantly less resources.

The issue (for the other performance technologies) was that the particular business transaction was relatively infrequent (possibly two orders of magnitude less than other operations) and it made extensive use of "common code" ... so the unique code for the transaction never really showed up as execution hotspot. The other characteristic was that the other methodologies were looking at the problems from extremely low-level point-of-view ... and weren't able to identity "mega" issues.

recent post mentioning performance predictor, vs/repack, multiple regression analysis
https://www.garlic.com/~lynn/2008c.html#24 Job ad for z/OS systems programmer trainee

misc. other recent posts mentioning vs/repack:
https://www.garlic.com/~lynn/2008c.html#78 CPU time differences for the same job
https://www.garlic.com/~lynn/2008d.html#35 Interesting Mainframe Article: 5 Myths Exposed
https://www.garlic.com/~lynn/2008e.html#16 Kernels
https://www.garlic.com/~lynn/2008f.html#36 Object-relational impedence

other recent posts in this thread:
https://www.garlic.com/~lynn/2008l.html#47 Intel: an expensive many-core future is ahead of us
https://www.garlic.com/~lynn/2008l.html#48 Intel: an expensive many-core future is ahead of us
https://www.garlic.com/~lynn/2008l.html#55 Intel: an expensive many-core future is ahead of us
https://www.garlic.com/~lynn/2008l.html#56 Intel: an expensive many-core future is ahead of us
https://www.garlic.com/~lynn/2008l.html#58 Intel: an expensive many-core future is ahead of us
https://www.garlic.com/~lynn/2008l.html#59 Intel: an expensive many-core future is ahead of us
https://www.garlic.com/~lynn/2008l.html#62 Intel: an expensive many-core future is ahead of us
https://www.garlic.com/~lynn/2008l.html#75 Intel: an expensive many-core future is ahead of us

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Yet another squirrel question - Results (very very long post)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: Fri, 15 Aug 2008 11:11:52 -0700 (PDT)
Subject: Re: Yet another squirrel question - Results (very very long post)
On Aug 15, 1:32 pm, Bill Pechter wrote:
Later after the 3b20 and 3b2's were sold unsuccessfully against DEC, Bell internally used Pyramid Technology stuff, HP-UX and Sun (and Amdahl at USL). Never did see much AIX and RS6000 stuff at AT&T.

there was at least some unix on stripped down tss/370 (ssup) ... billed as an alternative to gold/uts (i.e. unix on stripped down tss/ 370 microkernel done as special project for at&t). a couple recent posts:
https://www.garlic.com/~lynn/2008e.html#1 Migration from Mainframe to othre platforms - the othe bell?
https://www.garlic.com/~lynn/2008e.html#49 Any benefit to programming a RISC processor by hand?

there were (at least) two "kinds" of AIX ... the aixv2 port of at&t unix (port work done by the company that did pc/ix for the pc) for the pc/rt ... which grew into aixv3 for rs/6000. in addition, academic business unit had done a bsd port to pc/rt (under the name AOS). misc. posts mentioning risc, 801, romp, rios, rs/6000, etc
https://www.garlic.com/~lynn/subtopic.html#801

the other AIX was the UCLA locus port done for intel & mainframe (i.e. aix/386 & aix/370). misc. recent posts mentioning UCLA locus work:
https://www.garlic.com/~lynn/2008c.html#50 Migration from Mainframe to othre platforms - the othe bell?
https://www.garlic.com/~lynn/2008c.html#53 Migration from Mainframe to othre platforms - the othe bell?
https://www.garlic.com/~lynn/2008c.html#59 Govt demands password to personal computer
https://www.garlic.com/~lynn/2008d.html#82 Migration from Mainframe to othre platforms - the othe bell?

For random other ... AT&T longlines had finagled a copy of csc/vm in the 75 timeframe (when both vm370 product and csc/vm shipped with complete source). they apparently managed to migrate it to a quite a few mainframes over a period of years. around '84(?) timeframe, the national marketing rep for AT&T tracked me down ... looking for help in migrating longlines off that (1975) csc/vm system ... because they were now selling 370/xa machines ... which the '75 system didn't have support in it ... recent reference to old csc/vm system
https://www.garlic.com/~lynn/2008l.html#72 Error handling for system calls
& some old email references
https://www.garlic.com/~lynn/2006w.html#email750102
https://www.garlic.com/~lynn/2006w.html#email750430

misc. recent posts mentioning longlines:
https://www.garlic.com/~lynn/2008.html#29 Need Help filtering out sporge in comp.arch
https://www.garlic.com/~lynn/2008.html#30 hacked TOPS-10 monitors
https://www.garlic.com/~lynn/2008.html#41 IT managers stymied by limits of x86 virtualization
https://www.garlic.com/~lynn/2008i.html#14 DASD or TAPE attached via TCP/IP

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

old 370 info

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: Fri, 15 Aug 2008 11:58:24 -0700 (PDT)
Subject: old 370 info
somebody writes:
There is a bit of a discussion among a few of us old programmers as to S/370 instructions.

Would you happen to know when the interruptable instructions (e.g. MVCL/CLCL) were implemented?

Also, what general info do you have for the S/370 models 115-138? It seems to me that the first shipped 115 & 125 models did not have DAT and were missing certain instructions needed by MVS, and so were considered DOS (or DOS/VS) only machines.


mvcl/clcl were part of original 370 architecture ... in first machines ... would have shipped before DAT was announced.

i'm pretty sure that 115 & 125 initially came out at the same time as DAT

the problem with 115 & 125 wasn't that they didn't have the DAT instructions for MVS ... they didn't have enough real storage for MVS. they had maximum of 256k bytes of real storage. MVS couldn't boot in 256k bytes real storage (MVS did get some special instructions later w/3033 for dual-address space support)

115/125 initially shipped with microcode bug for CLCL/MVCL. all 360 instructions first checked parameter start and end addresses. besides CLCL/MVCL being interruptable ... they executed incrementally ... and would interrupt fail when they got to a byte that had problem (fetch protect, store protect, page fault, addressing, etc). Checking the ending address before starting (like traditional 360 instructions) might result in no incremental execution ...

I had done the early kernel size reduction on cp67 and original pageable kernel. A lot of the stuff i did as an undergraduate on cp67 shipped ... but the pageable kernel stuff didn't ship until vm370. With cp67, i had gotten fixed kernel size to 60kbytes ... with the rest pageable.

around mid-75, a customer was trying to run vm370 on 256k 125 and having storage contraint problems (in additional to vm370 not being officially supported on 125) .... vm370 ... even with pageable kernel capability ... had grown so that fixed kernel requirements were up in the 140k byte range. I got called into help out the customer ... and fiddled the vm370 kernel fixed storage back down to 80k bytes (went from about 110k bytes for virtual paging to about 170k bytes for virtual paging).

vm370 system build on real 125 would fail ... since it used MVCL with length of 16mbytes ... to clear and test size of machine. A system build on a different machine would work ... moving the image to the 125 ... or a system build running vm370 in a 370 virtual machine would work. But a vm370 system build on real 125 would fail because the MVCL would interrupt with addressing exception and not have done any incremental execution ... the residual length was still 16mbytes ... so the original value of 16mbytes minus the residual length (of 16mbytes) appeared to be a zero byte machine.

a few recent posts mentioning mvcl/clcl
https://www.garlic.com/~lynn/2008d.html#1 What happened to resumable instructions?
https://www.garlic.com/~lynn/2008e.html#79 Any benefit to programming a RISC processor by hand?
https://www.garlic.com/~lynn/2008f.html#12 Fantasy-Land_Hierarchal_NUMA_Memory-Model_on_Vertical

135/145 had DAT ... and required a different microcode disk to activate DAT. hold-up in announcing DAT was 155/165 implementation ... 165 took the longest ... and those machines required engineering hardware changes to retrofit DAT support.

115/125 were done in germany ... and were cluster architecture ... with a nine-position memory bus ... that had up to nine identical microprocessors with different microcode loads for different functions .... i.e. 370 instruction emulation, various integrated device controller functions. 125 was identical to 115 except the microprocessor doing the 370 microcode emulation was about 50percent faster ... than the other processors .... 115 was about a 80kip 370 machine while 125 was about a 120kip machine .... 370 emulation ran about 10:1 instructions ... so the native 115 engine was around 800kips ... and the 125 engine was around 1.2mips.

138/148 were enhanced machines (vis-a-vis 135/145) with a lot of spare room for microcode loads. As a result there were "performance assists" done for vm370 ... moving part of the vm370 supervisor into native microcode. some old reference:
https://www.garlic.com/~lynn/94.html#21
https://www.garlic.com/~lynn/94.html#27
https://www.garlic.com/~lynn/94.html#28

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Yet another squirrel question - Results (very very long post)

Refed: **, - **, - **
From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: Fri, 15 Aug 2008 14:20:05 -0700 (PDT)
Subject: Re: Yet another squirrel question - Results (very very long post)
On Aug 15, 3:05 pm, (Scott Lurndal) wrote:
lynn writes: > there were (at least) two "kinds" of AIX ... the aixv2 port of at&t > unix (port work done by the company that did pc/ix for the pc) for the

Unisoft?


re:
https://www.garlic.com/~lynn/2008l.html#82 Yet another squirrel question - Results (very very long post)

pc/ix "by interactive" ... a couple old references:
https://www.garlic.com/~lynn/2001f.html#0 Anybody remember the wonderful PC/IX operating system?
https://www.garlic.com/~lynn/2003d.html#54 Filesystems
https://www.garlic.com/~lynn/2003h.html#45 Question about Unix "heritage"

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

old 370 info

Refed: **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: Fri, 15 Aug 2008 14:55:36 -0700 (PDT)
Subject: Re: old 370 info
On Aug 15, 4:39 pm, John Byrns wrote:
Can you comment at all on the architecture of the "native 115 engine" and the type of instructions it executed? Was this engine used in any other machines/devices besides the 115/125 and their integrated device controllers?

re:
https://www.garlic.com/~lynn/2008l.html#83 old 370 info

what i remember was 16-bit instruction "vertical" microcode machine. i had some old 125 engineering books long ago and far away ... i never actually wrote code for the native engine ... i was given some over all specs. and did some feature/function design that would be implemented in the microcode (by others).

other 115/125 info
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP3115.html
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP3125.html

the above has initial machine only available up to 128k bytes real storage ... it wasn't until 125-II that there was 256k bytes real storage available.

and a little web engine use ... turns up this site with old product announcements:
http://ed-thelen.org/comp-hist/IBM-ProdAnn/index.html

including 115 & 125
http://ed-thelen.org/comp-hist/IBM-ProdAnn/370-115.pdf
http://ed-thelen.org/comp-hist/IBM-ProdAnn/370-125.pdf

looking back ... i had gotten pulled into doing stuff for customer 125- ii .... and then the 125 product group was asking if i could do some hardware engineering design enhancements. this was at the same time the vm370 development group was looking at picking up csc/vm stuff for product release. And at the same time there was interest in pok on doing various kinds of hardware enhancements for multiprocessors. Endicott also con'ed me into doing a lot of the investigation and design work for ecps (i.e. m'code enhancement moving parts of vm370 supervisor code into native m'code ... getting 10:1 performance improvement or better).

As i've speculated in the past ... was that a lot of the corporation had focused on future system taking over the world (while i continued to work on 370 and would make disparaging remarks about future system feasibility). When future system project finally imploded
https://www.garlic.com/~lynn/submain.html#futuresys

there was then a mad rush to get stuff back into the 370 product pipeline.

I've also claimed that at least some of John's motivation doing 801/ risc appeared to be to do the exact opposite in hardware complexity to what future system was doing. then about '80, 801/risc was far enough along that there was an attempt to converge the large number of different (internal) microprocessors to 801/risc (including the large number of different native microcode engines used for low & mid-range 370 machines). misc. past posts mentioning 801, risc, romp, rios, fort knox, power/pc, somerset, etc
https://www.garlic.com/~lynn/subtopic.html#801

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Yet another squirrel question - Results (very very long post)

Refed: **, - **, - **
From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: Fri, 15 Aug 2008 18:14:55 -0700 (PDT)
Subject: Re: Yet another squirrel question - Results (very very long post)
On Aug 15, 8:08 pm, Rich Alderson wrote:
We had an 8800 at LOTS (Stanford), running Ultrix. In that configuration it was master/slave rather than SMP. It barked at the moon and chased cars.

old email
https://www.garlic.com/~lynn/2007.html#email880329
in this post
https://www.garlic.com/~lynn/2007.html#46 How many 36-bit Unix ports in the old days?

with summary of 8800 product announcement and vms support for symmetrical multiprocessing.

email in the same post
https://www.garlic.com/~lynn/2007.html#email880324

discussing that vms multiprocessing wasn't considered real commercial dataprocessing until symmetrical multiprocessing support was announced.

other recent posts in the thread:
https://www.garlic.com/~lynn/2008l.html#78 Yet another squirrel question - Results (very very long post)
https://www.garlic.com/~lynn/2008l.html#82 Yet another squirrel question - Results (very very long post)
https://www.garlic.com/~lynn/2008l.html#84 Yet another squirrel question - Results (very very long post)

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Yet another squirrel question - Results (very very long post)

From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: Sat, 16 Aug 2008 08:41:03 -0700 (PDT)
Subject: Re: Yet another squirrel question - Results (very very long post)
re:
https://www.garlic.com/~lynn/2008l.html#86 Yet another squirrel question - Results (very very long post)

this older post
https://www.garlic.com/~lynn/2002f.html#0 Computers in Science Fiction

has summary of '88 gartner report giving vax shipments sliced and diced by model, year, us, non-us, etc (for decade 78-87)

before the referenced announcement of vms support for symmetrical multiprocessing ... old email reference in '88
https://www.garlic.com/~lynn/2007.html#email880329

it shows total of only 80 vax 8800 shipped in '86 and only 420 shipped in '87 (total of 500 shipped by ye87).

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Book: "Everyone Else Must Fail" --Larry Ellison and Oracle ???

Refed: **, - **, - **, - **
From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: Sat, 16 Aug 2008 14:02:26 -0700 (PDT)
Subject: Re: Book: "Everyone Else Must Fail" --Larry Ellison and Oracle ???
On Aug 11, 4:01 pm, hancock4 writes:
I saw this book, by Karen Southwick, and found it interesting. I wonder if anyone had any opinions as to whether it is accurate or not.

I don't think Oracle had the first relational database, I think ADR and IDMS had earlier versions on the mainframe market.


mulitcs had first rdbms product (released jun76):
http://www.mcjones.org/System_R/mrds.html

other relational references
http://www.mcjones.org/System_R/

past posts mentioning system/r
https://www.garlic.com/~lynn/submain.html#systemr

system/r was original relational/sql implementation ... but wasn't released as product. There was technology transfer from research to endicott for SQL/DS ... and then one of the people in the meeting mentioned in this post (happened to be held in Ellison's office):
https://www.garlic.com/~lynn/95.html#13

claimed to have handled much of the technology transfer from endicott/sqlds to STL for what became DB2.

misc. other posts in this thread:
https://www.garlic.com/~lynn/2008l.html#79 Book: "Everyone Else Must Fail" --Larry Ellison and Oracle ???
https://www.garlic.com/~lynn/2008l.html#80 Book: "Everyone Else Must Fail" --Larry Ellison and Oracle ???

there were numerous remembrances of the period at the recent tribute for Jim.
https://www.garlic.com/~lynn/2008i.html#32 A Tribute to Jim Gray: Sometimes Nice Guys Do Finish First
https://www.garlic.com/~lynn/2008i.html#36 A Tribute to Jim Gray: Sometimes Nice Guys Do Finish First
https://www.garlic.com/~lynn/2008i.html#40 A Tribute to Jim Gray: Sometimes Nice Guys Do Finish First

misc. past posts mentioning multics relational:
https://www.garlic.com/~lynn/2003c.html#75 The relational model and relational algebra - why did SQL become the industry standard?
https://www.garlic.com/~lynn/2003c.html#78 The relational model and relational algebra - why did SQL become the industry standard?
https://www.garlic.com/~lynn/2005.html#30 Network databases
https://www.garlic.com/~lynn/2007e.html#1 Designing database tables for performance?
https://www.garlic.com/~lynn/2007s.html#20 Ellison Looks Back As Oracle Turns 30
https://www.garlic.com/~lynn/2007s.html#24 [ClassicMainframes] multics source is now open
https://www.garlic.com/~lynn/2007s.html#33 Age of IBM VM
https://www.garlic.com/~lynn/2008d.html#23 more on (the new 40+ yr old) virtualization

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Fraud due to stupid failure to test for negative

Refed: **, - **, - **, - **
From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: Sat, 16 Aug 2008 15:01:12 -0700 (PDT)
Subject: Re: Fraud due to stupid failure to test for negative
On Aug 14, 12:46 pm, hancock4 wrote:
Actually, historically, industrial concerns like railroads had shops where they could build and maintain most things in house. Railroads maintained their own telephone networks under license from the Bell System, for example, an expection of ther rule

the metro systems let contracts for infrastructures .... recent example in news about london system:
http://www.theregister.co.uk/2008/08/14/eds_restraining_order/

there is an issue that they are metro system proprietary payment sysetms. we were asked in about a decade ago by some of the transit players. we had been working on the x9.59 financial transaction standard
https://www.garlic.com/~lynn/x959.html#x959

and looking at hardware token for financial transactions. transit players asked that we make sure our hardware token could perform a lightweight secure financial transaction ... and that the chip could perform the operations within the power constraints of transit gate proximity (contactless) reader and their elapsed time constraints.
https://www.garlic.com/~lynn/x959.html#aads

the issue is that all the major transit systems are heavily gov. subsidized and the transit systems were being heavily pressured by gov. that they (gov) was going to stop funding closed, proprietary transit payment operations (this is sort of analogous to push starting in the early 80s for "COTS" software and hardware dataprocessing).

the theme was the gov. would be in the business of supporting moving people around ... but it didn't see any reason to subsidize proprietary payment systems. the issue with most of the standard payment systems is they tend to trade-off performance/efficiency against security. the challenge we were given was to not sacrifice any security while making it superfast (and super cheap)

--
40+yrs virtualization experience (since Jan68), online at home since Mar70




previous, next, index - home