List of Archived Posts
2008 Newsgroup Postings (05/17 - 06/23)
- Has anyone got a rule of thumb for calculation data center sizing
- Do you belive Information Security Risk Assessment has shortcoming like
- Microsoft versus Digital Equipment Corporation
- Microsoft versus Digital Equipment Corporation
- A Merit based system of reward -Does anybody ( or any executive) really want to be judged on merit?
- Microsoft versus Digital Equipment Corporation
- Removing the Big Kernel Lock
- Annoying Processor Pricing
- pro- foreign key propaganda?
- Obfuscation was: Definition of file spec in commands
- Different Implementations of VLIW
- Different Implementations of VLIW
- pro- foreign key propaganda?
- pro- foreign key propaganda?
- DASD or TAPE attached via TCP/IP
- DASD or TAPE attached via TCP/IP
- should I encrypt over a private network?
- Does anyone have any IT data center disaster stories?
- Microsoft versus Digital Equipment Corporation
- American Airlines
- Microsoft versus Digital Equipment Corporation
- Worst Security Threats?
- Microsoft versus Digital Equipment Corporation
- Microsoft versus Digital Equipment Corporation
- Credit Card Fraud
- Microsoft versus Digital Equipment Corporation
- Microsoft versus Digital Equipment Corporation
- Microsoft versus Digital Equipment Corporation
- Scalable Nonblocking Data Structures
- What is your definition of "Information"?
- subprime write-down sweepstakes
- Mastering the Dynamics of Innovation
- A Tribute to Jim Gray: Sometimes Nice Guys Do Finish First
- Mainframe Project management
- American Airlines
- American Airlines
- A Tribute to Jim Gray: Sometimes Nice Guys Do Finish First
- American Airlines
- American Airlines
- American Airlines
- A Tribute to Jim Gray: Sometimes Nice Guys Do Finish First
- American Airlines
- Security Breaches
- IT Security Statistics
- Are multicore processors driving application developers to explore multithreaded programming options?
- ARPANet architect: bring "fairness" to traffic management
- Definition of file spec in commands
- Seeking (former) Adventurers
- Anyone know of some good internet Listserv's?
- Can I ask you to list the HPC/SC (i.e. th High performace computers) which are dedicated to a problem?
- Microsoft versus Digital Equipment Corporation
- Microsoft versus Digital Equipment Corporation
- Microsoft versus Digital Equipment Corporation
- Digital cash is the future?
- Trusted (mainframe) online transactions
- Is data classification the right approach to pursue a risk based information security program?
- The Price Of Oil --- going beyong US$130 a barrel
- Microsoft versus Digital Equipment Corporation
- I am trying to find out how CPU burst time is caluculated based on which CPU scheduling algorithms are created ?
- Microsoft versus Digital Equipment Corporation
- Threat assessment Versus Risk assessment
- Could you please name sources of information you trust on RFID and/or other Wireless technologies?
- Ransomware
- DB2 25 anniversary
- Is the credit crunch a short term aberation
- How do you manage your value statement?
- How do you manage your value statement?
- Do you have other examples of how people evade taking resp. for risk
- EXCP access methos
- EXCP access methos
- Next Generation Security
- The End of Privacy?
- Outsourcing dilemma or debacle, you decide
- Should The CEO Have the Lowest Pay In Senior Management?
- Should The CEO Have the Lowest Pay In Senior Management?
- Outsourcing dilemma or debacle, you decide
- Security Awareness
- Do you think the change in bankrupcy laws has exacerbated the problems in the housing market leading more people into forclosure?
- Hypothesis #4 -- The First Requirement of Security is Usability
- OS X Finder windows vs terminal window weirdness
- Certificate Purpose
- Selling Security using Prospect Theory. Or not
- parallel computing book
- Certificate Purpose
- Stephen Morse: Father of the 8086 Processor
- Which of the latest browsers do you prefer and why?
- Own a piece of the crypto wars
- Historical copy of PGP 5.0i for sale -- reminder of the war we lost
- squirrels
- Technologists on signatures: looking in the wrong place
- Certificate Purpose
- Certificate Purpose
- Certificate Purpose
- Certificate Purpose
- Lynn - You keep using the term "we" - who is "we"?
- Accidentally Deleted or Overwrote Files?
- A Blast from the Past
- We're losing the battle
- dollar coins
- We're losing the battle
- OS X Finder windows vs terminal window weirdness
- We're losing the battle
- OS X Finder windows vs terminal window weirdness
- OS X Finder windows vs terminal window weirdness
- dollar coins
Has anyone got a rule of thumb for calculation data center sizing
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 17, 2008
Subject: Has anyone got a rule of thumb for calculation data center sizing.
Blog: Computer Networking
When we were doing our ha/cmp product ... we had coined the terms
disaster survivability and geographic survivability ... lots of old
posts
http://www.garlic.com/~lynn/subtopic.html#hacmp
... and also worked ha/cmp cluster scaleup, misc. old email
http://www.garlic.com/~lynn/lhwemail.html#medusa
as hardware and software became more reliable, the major remaining
failure/outage causes were becoming environmental ... which required
countermeasures like geographic separation. lots of old posts
specifically related to continuous availability
http://www.garlic.com/~lynn/subtopic.html#available
part of ha/cmp scaleup was physical packaging more computing into
smaller footprint. Recent answer discussing BLADE/GRID theme
increasing amount of computing in smaller & smaller footprint.
http://www.linkedin.com/answers/technology/information-technology/information-storage/TCH_ITS_IST/217659-23436977
Some number of datacenters can run multiple billions of dollars in a
single location ... but if there is significant business dependency on
dataprocessing availability ... the trend is to separating the
operation into multiple different locations.
For old historical reference there was a 1970 datacenter that was
characterized as being a $2.5billion "windfall" for IBM (in 1970
dollars).
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
Do you belive Information Security Risk Assessment has shortcoming like
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 17, 2008
Subject: Do you belive Information Security Risk Assessment has shortcoming like
Blog: Information Security
one of the things that we worked on was what we called parameterized
risk management. it basically did things link in-depth threat and
vulnerability analysis and kept the individual threat/vulnerability of
the individual components. parameterized risk management including the
concept of threats/vulnerabilities could change over time ... i.e. as
technology advances are made the threat/vulnerability of specific
components can change.
one of the things that parameterized risk management allowed for was a
large variety of different technologies in use across the
infrastructure ... and the possibility that the integrity of any
specific component can be affected in real time (in order to support
real-time changes, original threat/vulnerability and integrity
characteristics/profile have to be maintain so that changes can be
mapped in real time, and include the sense of more semantic meaning as
opposed to purely numeric)... which, in turn, might require real time
changes in operations (possibly additional compensating procedures).
parameterized risk management was some of the work including in the
aads patent portfolio reference here
http://www.garlic.com/~lynn/x959.html#aads
parameterized risk management was some of the work including in the
aads patent portfolio reference here
http://www.garlic.com/~lynn/x959.html#aads
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
Microsoft versus Digital Equipment Corporation
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Microsoft versus Digital Equipment Corporation
Newsgroups: alt.folklore.computers,alt.sys.pdp10
Date: Sat, 17 May 2008 19:19:43 -0400
Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
Do you have a cite on how these are doing it? My students seem to
regard having to read the Alewife paper every semester as a punishment
inflicted on them by an evil antique professor. Having a more recent,
clearly described, directory-based protocol would be good.
recent posts with SCI reference:
http://www.garlic.com/~lynn/2008e.html#24 Berkeley researcher describes parallel path
http://www.garlic.com/~lynn/2008e.html#40 Fantasy-Land_Hierarchal_NUMA_Memory-Model_on_Vertical
http://www.garlic.com/~lynn/2008h.html#91 Microsoft versus Digital Equipment Corporation
SCI cache consistency directory mechanism was written up in the standard
... from approx. same period. Standard SCI was 64-way, convex used it
with 64 two-processor pa-risc boards (exemplar) and sequent used it with
64 four-processor intel boards (numa-q).
SCI reference:
http://www.scizzl.com/Perspectives.html
above mentions SGI using SCI w/o mentioning SCI
Silicon Graphics Makes the Arguments for Using SCI!
http://www.scizzl.com/SGIarguesForSCI.html
for other drift, acm article from '97 ...
A Hierarchical Memory Directory Scheme Via Extending SCI for Large-Scale
Multiprocessors
http://portal.acm.org/citation.cfm?id=523549.822844
abstract for above:
SCI (Scalable Coherent Interface) is a pointer-based coherent directory
scheme for large-scale multiprocessors. Large message latency is one of
the problems with SCI because of its linked list structure: the
searching latency can grow as a linear order of the number of
processors.In this paper, we focus on a hierarchical architecture to
propose a new scheme - EST(Extending SCI-Tree), which may reduce the
message traffic and also take the advantages of the topology
property. Simulation results show that the EST scheme is effective in
reducing message latency and communication cost when compared with other
schemes.
... snip ...
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
Microsoft versus Digital Equipment Corporation
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Microsoft versus Digital Equipment Corporation
Newsgroups: alt.folklore.computers,alt.sys.pdp10
Date: Sun, 18 May 2008 00:16:53 -0400
Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
Sure -- and Alewife and DASH are the two really well described
directory-based systems. What's really nice about them is that the
papers take exactly backwards approaches to describing them: Alewife
just gives the messages and state transitions and leaves it up to the
reader to figure out the sequence of events, while DASH gives the
sequence really well and completely omits exactly what the states
actually are. I like to assign them both. Unfortunately, when they
read the specs on the hardware implementations (why does this seem to
be required for any paper about a real system?) they tend to start
snickering and talking about vacuum tubes. A clear description of a
system in current use would be really nice.
re:
http://www.garlic.com/~lynn/2008e.html#24 Berkeley researcher describes parallel path
http://www.garlic.com/~lynn/2008e.html#40 Fantasy-Land_Hierarchal_NUMA_Memory-Model_on_Vertical
http://www.garlic.com/~lynn/2008h.html#91 Microsoft versus Digital Equipment Corporation
http://www.garlic.com/~lynn/2008i.html#2 Microsoft versus Digital Equipment Corporation
alewife and dash were university research projects ... SCI was passed
as standard with extensive write up in the standard and used by
several vendors in shipped computer products.
i've commented before that at one point, we were asked if we would be
interested in heading up effort to commercialize (SUN's object-oriented)
SPRING operating system, turning it out as product (this was in the
era when object-oriented was all the rage ... apple was doing
PINK). It would have been done in conjunction with product that had
possibly thousands of sparc processors interconnected with SCI.
I've got early writeup of the SCI directory cache consistency protocol
from before standard was passed ... and just doing some picking around
on the SCI website for more information ...
http://www.scizzl.com/
also from above:
At long last the IEC/IEEE publications deadlock has been resolved, and
the corrected SCI spec has been published by the IEC as "ISO/IEC
Standard 13961 IEEE". Unfortunately, the updated diskette was not
incorporated. However, the updated C code is online, at sciCode.c text
file (1114K). This release does not have the separate index file that
shipped on the original diskette, because with the passage of time we
lost the right of access to the particular software that generated that
index. (People change employers.)
Unfortunately, the IEEE completely bungled the update, reprinting the
old uncorrected standard with a new cover and a few cosmetic
changes. Until this has been corrected, the IEEE spec should be avoided.
... snip ...
i've commented before in that period was that a lot of hippi standard
work was backed by LANL, fcs standard work was backed by LLNL and SCI
work came out of SLAC ... all furthering/contributing to commoditizing
various aspects of high-performance computing.
the scizzl.com web site also lists SCI book
http://www.amazon.com/exec/obidos/ASIN/3540666966/qid=956090056/sr=1-1/103-0276094-5848643
from above:
Scalable Coherent Interface (SCI) is an innovative interconnect standard
(ANSI/IEEE Std 1596-1992) addressing the high-performance computing and
networking domain. This book describes in depth one specific application
of SCI: its use as a high-speed interconnection network (often called a
system area network, SAN) for compute clusters built from commodity
workstation nodes. The editors and authors, coming from both academia
and industry, have been instrumental in the SCI standardization process,
the development and deployment of SCI adapter cards, switches, fully
integrated clusters, and software systems, and are closely involved in
various research projects on this important interconnect. This
thoroughly cross-reviewed state-of-the-art survey covers the complete
hardware/software spectrum of SCI clusters, from the major concepts of
SCI, through SCI hardware, networking, and low-level software issues,
various programming models and environments, up to tools and application
experiences.
... snip ...
besides sci defining directory protocol for memory/cache consistancy, it
also defined a number of other uses.
Comparison of ATM, FibreChannel, HIPPI, Serialbus, SerialPlus SCI/LAMP
http://www.scizzl.com/SCIvsEtc.html
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
A Merit based system of reward -Does anybody (or any executive) really want to be judged on merit?
Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 18, 2008
Subject: A Merit based system of reward -Does anybody ( or any executive) really want to be judged on merit?
Blog: Organizational Development
this business school article mentions that there are about 1000 CEOs
that are responsible for about 80% of the current financial mess (and
it would go a long way to fixing the mess if the gov. could figure out
how for them to loose their job)
http://knowledge.wharton.upenn.edu/article.cfm?articleid=1933
while this article points out there was $137 billion in bonus paid out
in the period that the current financial mess was being created (in
large to those creating the current financial mess)
http://www.businessweek.com/investor/content/mar2008/pi20080318_697440.htm?chan=top+news_top+news+index_businessweek+exclusive
For slight drift ... the current financial mess heavily
involved toxic CDOs which were also used two decades ago during
the S&L crisis to hide the underlying value ... and I've used the
analogy about toxic CDOs being used to obfuscate the "observe"
in Boyd's OODA-loop.
This article includes mention of SECDEF recently honoring Boyd (to the
horror of the air force)
http://www.time.com/time/nation/article/0,8599,1733747,00.htm
Now one of the things that Boyd use to tell young officers was that
they had to choose between doing and being. Being led to all
sorts of rewards and positions of honor ... while if you were
effective at doing ... frequently the reward would be a kick in
the stomach (a little cleaned up in the following):
http://www.d-n-i.net/dni/john-r-boyd/to-be-or-to-do/
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
Microsoft versus Digital Equipment Corporation
From: lynn@garlic.com
Subject: Re: Microsoft versus Digital Equipment Corporation
Newsgroups: alt.folklore.computers,alt.sys.pdp10
Date: Sun, 18 May 2008 22:16:15 -0700 (PDT)
On May 18, 10:09=A0am, Quadibloc <jsav...@ecn.ab.ca> wrote:
Bad news, though; although the site didn't say so, downloading the
Tving thesis seems to require a password - and the link to register to
get E-mails, which might also serve to establish such a password, is
broken.
The main page explains that due to the tragic passing of a researcher,
and more mundane matters such as people changing jobs, the site has
some limitations, but apparently there is a state of desuetude beyond
those limitations at present.
John Savard
the standard should also be available from the ieee site ... and
various vendors who have shipped products may have stuff .... although
the products date back decade or more ... convex used 128 pa-risc
chips with sci in the exemplar ... but hp bought convex and it is no
longer around; sequent used 256 intel chips with sci in the numa-q
... and ibm bought sequent ... data general (which is also long gone)
had a 256 intel chip processor with sci (emc seemed to have bought up
data general for the disk array products). sgi name is still around.
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
Removing the Big Kernel Lock
From: lynn@garlic.com
Subject: Removing the Big Kernel Lock
Newsgroups: alt.folklore.computers
Date: Mon, 19 May 2008 07:00:37 -0700 (PDT)
Removing the Big Kernel Lock
http://tech.slashdot.org/tech/08/05/17/1446219.shtml
from above:
"There is a big discussion going on over removing a bit of
non-preemptable code from the Linux kernel. 'As some of the latency
junkies on lkml already know, commit 8e3e076 in v2.6.26-rc2 removed
the preemptable BKL feature and made the Big Kernel Lock a spinlock
and thus turned it into non-preemptable code again. "This commit
returned the BKL code to the 2.6.7 state of affairs in essence," began
Ingo Molnar. He noted that this had a very negative effect on the real
time kernel efforts, adding that Linux creator Linus Torvalds
indicated the only acceptable way forward was to completely remove the
BKL.'"
... snip ...
when charlie was doing fine grain locking work on cp67 smp
support at the science center in the late 60s and early 70s
http://www.garlic.com/~lynn/subtopic.html#545tech
one of the things he invented was the compare&swap instruction
http://www.garlic.com/~lynn/subtopic.html#smp
BKL or global system/kernel lock was (really) the state of the art at
that time.
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
Annoying Processor Pricing
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Annoying Processor Pricing
Newsgroups: alt.folklore.computers,comp.arch
Date: Tue, 20 May 2008 12:52:06 -0400
"Sarr J. Blumson" <sarr.blumson@alum.dartmouth.org> writes:
The mistaken assumption that price is somehow connected to cost is one we
engineers often fall into. :-) Here's a story that I know is true because
I was there:
To convert a GE 255 system into a more expensive GE 265, you replaced the
OS with a version that didn't have the delay loop to reduce apparent CPU
performance.
The worst part is that GE actually made a slower CPU (the 225 vs th 235)
but they were slightly different and we (Dartmouth) had removed all the
code that supported the 225.
i've mentioned before, this was big problem transitioning to "high-speed"
internet.
telco infrastructures had large fixed infrastructre, staff, and costs
... with the costs being recovered by useage charges. deployment of
large amount of (dark) fiber in the early 80s ... significantly
increased the capacity ... but there was a huge chicken/egg situation.
huge increases in useage wouldn't come w/o huge decreases in useage
charges. huge increases in useage wouldn't come w/o whole new generation
of bandwidth hungry applications ... but those wouldn't be invented
without demand, and there wouldn't be demand w/o huge useage charge
decreases.
just dropping the useage charges ... would still take maybe a decade for
the demand to evolve along with new generation of bandwidth hungry
applications (a decade where infrastructure might otherwise operate at
enormous losses ... because of relatively fixed costs).
one of the scenarios was the educational/nsf infrastructure. provide
significant resources for "sandbox" operation with limitations that the
contributed resources weren't usurp standard commercial operation. this
would provide "incubator" environment for development/evolution of
bandwidth hungry applications w/o any significant impact on regular
commercial revenue.
much of the links in that period were 56kbits ... but we were running
T1 and higher speed links internally in the hsdt project
http://www.garlic.com/~lynn/subnetwork.html#hsdt
recent hsdt topic drift posts mentioning encryption requirement:
http://www.garlic.com/~lynn/2008.html#79 Rotary phones
http://www.garlic.com/~lynn/2008e.html#6 1998 vs. 2008: A Tech Retrospective
http://www.garlic.com/~lynn/2008h.html#87 New test attempt
and we feel that strongly influenced nsfnet backbone rfp to specify
t1 ... some old email
http://www.garlic.com/~lynn/lhwemail.html#nsfnet
however, eventually we weren't allowed to bid on nsfnet ... director of
nsf thot that writing a letter to our ceo (including statements that
what we already had running was at least five yrs ahead of all nsfnet
backbone bids) ... but that just aggravated the internal politics.
misc. past nsfnet posts
http://www.garlic.com/~lynn/subnetwork.html#nsfnet
the winning bid actually put in 440kbit liinks (not t1) ... but somewhat
to meet the letter of the bid ... they put in T1 trunks and used
telco-type multiplexors to operate multiple 440kbit links over the T1
trunks (we made some disparaging remarks that the T1 trunks may have in
turn, actually been multiplexed at some point over T5 trunks ... which
then they could make claims about nsfnet backbone being T5 network???).
however, we've also commented that possibly resources, 4-5 times the
amount of the nsfnet backbone bid was actually used (effectively
improving the incubator atmosphere encouraging the development and use
of bandwidth hungry applications ... w/o impacting existing commerical
useage-based revenue).
there was even more significant resources contributed to many of the
local networks (that were interconnected by the nsfnet backbone) as
well to the bitnet & earn academic networks
http://www.garlic.com/~lynn/subnetwork.html#bitnet
a corresponding (processor specific) charging in the 60s, was the
cpu-meter used for charging ... most of the machines were leased/rented
and charging based on useage.
this impacting the migration to 7x24 commercial time-sharing use. in the
virtual machine based offerings (cp67 and then morphing into vm370)
http://www.garlic.com/~lynn/subtopic.html#timeshare
normal 1st shift useage charges was enough to cover the fixed operating
costs. a problem was frequently that offshift useage (revenue) wouldn't
cover the corresponding useage charges (including vendor cpu-meter based
charges). the 360/370 cpu-meter would run whenever the processor was
active and/or when there was active channel i/o operations (and would
continue to "coast" for 400millseconds after all activity ceased). A
challenge was to significantly reduce off-shift and weekend costs
... while still leaving the system available for use ... including
remote & home access ... i.e. I've had home dialup access starting in
mar70 into the science center service
http://www.garlic.com/~lynn/subtopic.html#545tech
one of the issues was migration to "lights-out" operation ... i.e. the
machine being able to operate/run w/o actually having a human present to
perform operations (more & more automated operator).
the other was "channel i/o programs" that would be sufficiently active
to allow/accept incoming characters ... but otherwise sufficiently idle
that the cpu-meter to come to a stop (i.e. being "prepared" to accept
incoming characters).
a corresponding phenomena was that off-shift charging (at various
levels) has frequently been a fraction of 1st shift useage. The issue is
that a lot of the infrastructure costs are fixed regardless of the
time-of-day ... and there has tended to be heavy provisioning to handle
(peak) 1st shift operation (in the past, cost of peak computer useage
provisioning was much larger because computer hardware was significantly
more expensive). off-shift charging policies were frequently focused at
attempting to migrate useage in order to utilize otherwise idle
capacity.
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
pro- foreign key propaganda?
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: pro- foreign key propaganda?
Newsgroups: comp.databases.theory,alt.folklore.computers
Date: Tue, 20 May 2008 15:37:52 -0400
paul c <toledobysea@ac.ooyah> writes:
In the 1970 mainframe culture that Codd was trapped in, 'key' had an
extremely physical connotation, in fact some hardware supported 'keys'
directly with dedicated machine-level operators. Many practitioners
had grown up depending on file-level keys, as for IMS, its various
keys were all encumbered with various navigational meanings. I think
Codd was just as much a pragmatist as a theorist and even though his
keys weren't at all the same thing he might have used continued the
term to ease his 'sales pitch'. If he had called them, say, the
inference set', he might have expected even more resistance than he
did from the ignorants of the day. While academics embraced his ideas
quickly, he suffered many personal attacks from the powerful
marketeers at a time when IBM was maybe more dominant than microsoft
is today. Ironic, because IMS was used as way to help sell then big
IO-oriented slow-cpu iron and the implementations that followed Codd
were attacked for supposedly needing more hardware than IMS did. I
remember an Amdahl salesman saying, "give me more of this relational
stuff, I'll sell more cpu's!".
I've commented before that the 60s era databases had direct pointers
exposed as part of the record.
Also the underlying disk technology had made a trade-off between
relatively abundant i/o capability and the limited availability of
real/electronic storage in the "CKD" ... count-key-data architecture
... misc. past posts
http://www.garlic.com/~lynn/subtopic.html#dasd
... it was possible to create i/o requests that performed extended
searches for data &/or key pattern matches on disk ... w/o having
to know specific location for some piece of information. This was used
extensively in various kinds of directories (kept on disk w/o needing
to use extremely scarce real storage).
However the 60s era databases tended to have direct record pointers
exposed in database records (independent of the multi-track
"searching" operations which would tell the disk to try and find the
record).
I've posted several times before about the discussions between the IMS
group in STL/bldg90 and the (original relational/SQL) System/R group in
SJR/bldg28 (where Codd was located). Misc. past posts mentioning
System/R
http://www.garlic.com/~lynn/subtopic.html#systemr
The IMS group pointed out that the index implementation in relational
(which contributed to eliminating exposed record pointers as part of
the database schema) typically doubled the physical disk space
... vis-a-vis IMS ... and greatly increased the number of physical
disk i/os (as part of processing the index to find actual record
location). The relational counter-argument was that eliminating the
exposed record pointers as part of the database schema significantly
reduced the administrative and management costs for large complex
databases.
Going into the 80s, there was significant increases in availability of
electronic stoarge and also significant decline in computer hardware
costs (especially compared to increasing people costs). This shift
helped with the uptake of relational ... the reduction in disk costs
(and significant increase in bytes/disk) eliminated much of the
argument about the disk space requirements issue for relational
index. The increases in sizes of computer memories (and reduction in
cost) allowed for significant amounts of relational indexes to be
cached in real storage (mitigating the significant increase in i/os
that had been needed to process the indexes). The significant
reduction in administrative and management for relational (vis-a-vis
IMS) was not only a cost issue but also became a skills availability
issue (it became much easier to obtain and justify skills for
relational deployment).
The database direct record pointers as well as the extensive
"searching" capability (both from the 60s) could be considered a
result of the extremely constrained amount of available system
memory/storage.
The shift in relative amounts of system memory/storage vis-a-vis i/o
capacity actually started by the mid-70s. in the early 80s, I was making
statements that relative disk thruput had declined by better than an
order of magnitude (ten times) over a period of 10-15 yrs (i.e. memory
and cpu had increased by a factor of 40-50, disk thruput had only
increase by factor of 3-5). This got me into some amount of trouble with
the executives that ran the disk division. at one point they assigned
their performance group to refute my statements. After a couple of
weeks ... they came back and observed that I had actually somewhat
understated the technology shift. on the other hand ... they did let me
periodically play disk engineer in the disk engineering and product test
labs ... misc. past posts
http://www.garlic.com/~lynn/subtopic.html#disk
Other purely historical topic drift ... the first relational product
was for Multics ... from the 5th flr at 545 tech sq.
The science center was on the 4th flr of 545 tech sq.
http://www.garlic.com/~lynn/subtopic.html#545tech
which had come up with the original virtual machine operating systems
... thru various generations cp40, cp67, vm370, etc. it was also where
(gml) markup language was invented in 1969 (subsequently morphing in
various sgml, html, xml, etc).
And all the System/R development was done on vm370 virtual machine
operating system at SJR.
The march in the increases in system real storage has seen another
transition. Relational implementations during the 70s and 80s were
mostly oriented towards primary location of information was on disk and
copies were kept cached in real storage. However, in the 90s there
started appearing implementations that assumed the whole database was in
real storage and disks were purely for transaction integrity.
These claimed ten times the performance of the earlier generation of
"caching" oriented implementations (even on the same hardware where the
caching oriented implementations had their complete database also
resident in real storage).
These high-performance relational databases saw some uptake in the telco
and cellphone markets ... used for large number of call detail/charge
records. There was also some speculation in this period that telcos
might be able to move into the payment transaction market ... leveraging
their highly efficient call transaction database implementations to
first gain a foothold with "micro-payments" and then moving into the
rest of the payment transaction market (being able to process
significantly larger volume of transactions at a significantly lower
cost). The big inhibitor for telcos pulling this off seems to be
figuring out how to deal with the financial liability issues with regard
to handling payments.
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
Obfuscation was: Definition of file spec in commands
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Obfuscation was: Definition of file spec in commands
Newsgroups: alt.folklore.computers
Date: Tue, 20 May 2008 15:58:45 -0400
Walter Bushell <proto@xxx.com> writes:
That is the reason for time machine, of course. Of course, everyone is
an idiot sometimes. Pulling 25 hour days for a few weeks can lead to
weird thinking.
in the 60s, the univ. use to turn over the datacenter to me for the
weekend ... basically mainframes as personal computers from 8am
sat. until 8am monday ... however, pulling a straight 48hr shift then
made it little difficult attending classes on monday.
a couple decades later there were some jokes about my 4shift week,
1st shift in sjr/bldg. 28 ... things like System/R
http://www.garlic.com/~lynn/subtopic.html#systemr
2nd shift in bldgs 14&15 (disk engineering and product test lab)
http://www.garlic.com/~lynn/subtopic.html#disk
frequent 3rd shift in bldg90/stl on various activities
and 4th shift (weekends) up at HONE (virtual machine based time-sharing
service providing online sales & marketing support)
http://www.garlic.com/~lynn/subtopic.html#hone
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
Different Implementations of VLIW
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Different Implementations of VLIW .
Newsgroups: comp.arch,alt.folklore.computers
Date: Tue, 20 May 2008 18:45:02 -0400
"Phil Weldon" <not.disclosed@example.com> writes:
In 1979 the price of RAM for the IBM System/360 was cut from $75,000
US to $50,000 US per MByte.
By 1985 IBM had the System/370 3090-200 and the 1 Mbit SAMOS chip,
with a dual processor 64 MByte system priced at $5,000,000 US [IBM
Archives]. In the same year IBM shipped its 4,000,000th PC (and
discontinued the PC Jr.) Memory was not upgraded separately from the
system in this class of mainframes; the next step up was to the 3090 -
400 field upgrade with twice the memory and twice the number of
processors for an additional $4,000,000.
But for mainframes of this class the memory and consequently power
density required heroic cooling that added significantly to the cost;
a cost that was not incurred by lower densities (the IBM PC, for
example - or a VAX.)
3090 had a separate memory issue ... in order to meet "capacity
planning" thruput ... it needed more memory ... than the technology (of
the period) could easily package ... as normal processor memory ... so
they did sort of a numa architecture ... that was under software control
... called *extended store* (bascially the same chips as in processor
memory ... but on a different bus).
the software paradigm to support it was sort of like an electronic
paging disk ... except, instead of asynchronous i/o operations ... it
had synchronous move instructions (the claim being that while the
instruction took some amount of time ... it was way less than
traditional asynchronous i/o interrupt handling pathlengths).
it was a "fast", wide bus between extended store (placing the extended
store futher away with longer latency) and processor memory that moved
4k bytes at a time ... could also think of processor memory as software
controlled (store-in) cache with 4kbyte cache lines ... although the
amount of extended store tended to be about the same as regular
processor memory.
the extended store bus came in handy when they went to add hippi i/o
support to 3090. the standard channel interfaces wouldn't handle the i/o
rate. they cut into the side of the extended store bus to add hippi.
however, the mainframe interface was still 4k move instruction ... so
hippi i/o programming was done with a kind of peek/poke paradigm using
4k move to/from instructions to reserved extended store addresses.
later generations, memory densities and packaging technology eliminated
the need for extended store ... however, there continued to be LPAR
configuration support for emulated extended store (using standard
memory) ... apparently because of various legacy software implementation
considerations.
LPAR has been evoluation of PR/SM introduced in 3090s ... somewhat in
response to Amdahl's hypervisor. LPARs ... or Logical PARtitions
implement a significant subset of virtual machine capability directly in
the "hardware" (doesn't require a *software* virtual machine operating
system).
... i don't have recollection of costs ... however 3090 archives
web page:
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP3090.html
the above mentions the (two) 3092 processor controller ... service
processor ... which were really a pair of 4361s running a modified
version of vm370 release 6 ... recent post discussion 3090 of
(4361) service processors
http://www.garlic.com/~lynn/2008h.html#80 Microsoft versus Digital Equipment Corporation
the 3090 archive also mentions that the (4361) 3092 processor controller
required two 3370 Model A2 disks ... and access to 3420 tape drives (for
read/write files).
for other memory topic drift x-over, post from today in c.d.t about
rdbms
http://www.garlic.com/~lynn/2008i.html#8 pro- foreign key propaganda?
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
Different Implementations of VLIW
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Different Implementations of VLIW .
Newsgroups: comp.arch,alt.folklore.computers
Date: Tue, 20 May 2008 18:57:20 -0400
Anne & Lynn Wheeler <lynn@garlic.com> writes:
3090 had a separate memory issue ... in order to meet "capacity
planning" thruput ... it needed more memory ... than the technology (of
the period) could easily package ... as normal processor memory ... so
they did sort of a numa architecture ... that was under software control
... called *extended store* (bascially the same chips as in processor
memory ... but on a different bus).
re:
http://www.garlic.com/~lynn/2008i.html#10 Different Implementations of VLIW
for a different 3090 "capacity planning" issue ... was number of
channels (w/o regard to peak transfer rate and not being able to support
hippi).
3090s were built with large modules ... and had been profiled to have
balanced system thruput with a specific number of i/o channels.
however, fairly late in the development cycle ... it was "discovered"
that the new disk controller (3880) had significantly higher protocol
processing overhead ... significantly increasing channel busy time (even
tho the data transfer rate had increased to 3mbytes/sec, the disk
control processor handling i/o commands was quite slow).
The revised system thruput profile (using the actual 3880 controller
overhead channel busy numbers) required a significant increase in the
number of channels (in order to meet aggregate thruput objectives). This
required that 3090 manufacturing required an extra module ... which
noticeably increased the 3090 manufacturing costs.
There was joke that the incremental manufacturing costs for each 3090,
should be charged off against the disk business unit's bottom line
... rather than the processor business unit's bottom line.
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
pro- foreign key propaganda?
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: pro- foreign key propaganda?
Newsgroups: comp.databases.theory,alt.folklore.computers
Date: Tue, 20 May 2008 22:37:44 -0400
paul c <toledobysea@ac.ooyah> writes:
In the IBM way of things (which was cloned by several other mfrs, not
just the mainframe ones, but even Wang, IIRC), there was this thing
called Count-Key-Data disk architecture and a bunch of 'access
methods' (which IMS made use of, but could be used by themselves
without IMS). Likely I recall some of the details wrong, but keys in
access methods such as VSAM or ISAM or even BDAM if I recall, below
any logical schemes such as trees, could be stored in segregated disk
cylinders and there were also little mini-computers called channels
with very limited instruction sets which would search those disk
cylinders asynchronously from the main cpu. (Some of those artifacts
found their way into the higher-level IMS configuration verbiage and
commands.) All the 'bare-metal' programmers knew about this as well
as many other physical techniques such as how to avoid hardware
deadlocks. Much of Codd's audience was within this (dominant) culture
and he was very much addressing it.
that deal.)
re:
http://www.garlic.com/~lynn/2008i.html#8 pro- foreign key propaganda?
BDAM ... basic direct access method. basically had 32bit record no/ptr
Misc. past posts mentioning BDAM (and/or CICS ... an online transaction
monitor originating in the same era and frequently deployed with
applications that used BDAM files)
http://www.garlic.com/~lynn/subtopic.html#bdam
Online medical library was developed using bdam in the 60s and was
still in extensive world-wide use 30 years later ... still being the
largest online search facility in the world until being eclipsed by
some of the popular internet search engines sometime in the 90s.
One of the processes was that medical knowledge articles were indexed
in a large number of different ways, keywords, authors, etc. Tables
were built of all the different ways articles were indexed. In effect
the record number of the article became a unique key for each
article. A specific keyword would have a list of all articles that the
keyword was applicable for ... i.e. condensed set of 32bit integers
... the record ptr was effectively used as unique key of the article.
Boolean keyword searches ... became ANDs and ORs of the sets of unique
keys (unique record ptrs). An AND of two keywords becomes the
intersection of key/recordptrs from the two lists. An OR of two
keywords becomes the join of key/recordptrs from the two lists. This
was all built on top of underlying BDAM support.
Part of the issue attempting to replace the bdam implementation was
that it was highly efficient ... having collapsed the article unique
key and the corresponding record pointer into the same value (however,
there was significant maintenance activity ... so significant access
& thruput was needed to justify the extensive care and
support). Problems also started creeping in when the number of
articles started exceeding the size of the record ptr/key.
...
ISAM ... indexed sequential access method ... had the really complex
channel programs. the whole structure of the database was stored on
disk. a channel program would be extensive and very complex ...
starting out searching for specific index record ... which would be then
read into memory location which was the argument of a following search
command ... this could continue for multiple search sequences ... in a
channel program, until pointer for the approriate data record was found
and read/written. Channel programs could have relatively complex
condition testing, branching, and looping.
ISAM was an enormously I/O intensive resource hog ... and went out of
favor as the trade-off between disk i/o resources and real memory
resources shifted (my reference to relative system disk i/o thruput
having declined by better than an order of magnitude during the period)
... and it became much more efficient to maintain index structures
cached in processor storage.
ISAM channel programs were also were a real bear to provide
virtualization support for.
....
for other reference, the wiki IMS page:
http://en.wikipedia.org/wiki/Information_Management_System
from above:
IBM designed IMS with Rockwell and Caterpillar starting in 1966 for the
Apollo program. IMS's challenge was to inventory the very large Bill of
Materials for the Saturn V moon rocket and Apollo space vehicle.
... snip ...
and:
In fact, much of the world's banking industry relies on IMS, including
the U.S. Federal Reserve. For example, chances are that withdrawing
money from an automated teller machine (ATM) will trigger an IMS
transaction. Several Chinese banks have recently purchased IMS to
support that country's burgeoning financial industry. Reportedly IMS
alone is a $1 billion (U.S.) per year business for IBM.
... snip ...
Bottom line in the wiki article is that IMS outperforms relational for a
given task ... but requires more effort to design & maintain.
And CICS wiki page ... for much of their lives ... IMS and CICS have
somewhat competed as "transaction monitors":
http://en.wikipedia.org/wiki/CICS
For old CICS folklore ... the univ. that I was at in the 60s was
selected as one of the beta test sites for the original CICS product
release ... and one of the things I got tasked as an undergraduate was
helping debug CICS.
and BDAM wiki page ...
http://en.wikipedia.org/wiki/Basic_direct_access_method
and ISAM wiki page (although it doesn't talk about the really
complex channel program implementation support done in the 60s):
http://en.wikipedia.org/wiki/ISAM
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
pro- foreign key propaganda?
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: pro- foreign key propaganda?
Newsgroups: comp.databases.theory,alt.folklore.computers
Date: Wed, 21 May 2008 08:17:47 -0400
Anne & Lynn Wheeler <lynn@garlic.com> writes:
part of the issue attempting to replace the bdam implementation was
that it was highly efficient ... having collapsed the article unique
key and the corresponding record pointer into the same value (however,
there was significant maintenance activity ... so significant access &
thruput was needed to justify the extensive care and
support). problems also started creeping in when the number of
articles started exceeding the size of the record ptr/key.
re:
http://www.garlic.com/~lynn/2008i.html#8 pro- foreign key propaganda?
http://www.garlic.com/~lynn/2008i.html#12 pro- foreign key propaganda?
aka ... overloading a value with multiple characteristics can
significantly improve runtime operation ... but can become an
administrative burden to maintain the consistency of all the different
characteristics.
reducing the number of different characteristics a value has to
represent will reduce the consistency administrative burden but will
typically increase the runtime overhead (navigating internal tables
relating the different characteristics).
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
DASD or TAPE attached via TCP/IP
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: DASD or TAPE attached via TCP/IP
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 21 May 2008 10:02:07 -0400
Michael.Knigge@SET-SOFTWARE.DE (Michael Knigge) writes:
I wonder how it is possible to attach DASD- or TAPE-Devives via
TCP/IP. There is a product called mfnetdisk (see mknetdisk.com) that
is able to "emulate" a 3390 that resides on a PC and is accessed via
TCP/IP.
So... I ask myself how this is possible. And (for me) even more
interesting, would it also be possible to do the same for a Tape?
for historical reference ... the internal "csc/vm" vm370 release
... mentioned in this old email
http://www.garlic.com/~lynn/2006v.html#email731212
http://www.garlic.com/~lynn/2006w.html#email750102
http://www.garlic.com/~lynn/2006w.html#email750430
was somehow leaked to at&t longlines circa 1975. they took this
highly modified "csc/vm" vm370 release and made numerous local
modifications ... including remote device support ... that would run
over various kinds of communication links. basically virtual machine
channel program simulation would forward the stuff to remote site for
actual execution on the real locally attached device. this system
manage to propagate to a number of at&t longline machines. Nearly
a decade later, the at&t national account manager managed to track
me down ... longlines had continued to migrate the vm370 system thru
various generations of mainframes ... but it came to an end with move
to 370/XA ... and he was looking for assistance in helping move
longlines off that vm370 system.
this isn't all that much difference with standard i/o virtualization,
aka a copy of the "virtual" channel programs are replicated with real
address substituted for virtual addresses. in the case of remote
device, the replicated "real" channel programs are run on remote
system ... with appropriate fiddling of virtual pages on the
application machine and the real pages on the machine where the device
was attached.
some amount of the fiddling was handled by services running in a
separate virtual machine. note this isn't all that different from what
is done by various virtual machine mainframe simulators that run on
various other kinds of platforms ... and include simulation of various
kinds of mainframe i/o devices on completely different kinds of
devices.
the specific communication mechanism used is the least of the issues.
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
DASD or TAPE attached via TCP/IP
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: DASD or TAPE attached via TCP/IP
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 21 May 2008 12:07:53 -0400
R.Skorupka@BREMULTIBANK.COM.PL (R.S.) writes:
The key is "on other systems". iSCSI is not supported on z/OS.
So, on z/OS it is still impossible. However - in general - it is possible.
It remains me a dialog with DB2 admin:
- DB2 uses VSAM datasets, how would you imagine a database without VSAM?
- I don't know, but others imagine *and do it*. On other platforms.
re:
http://www.garlic.com/~lynn/2008i.html#14 DASD or TAPE attached via TCP/IP
for some topic drift ... posts in a recent thread in
comp.databases.theory:
http://www.garlic.com/~lynn/2008i.html#8 pro- foreign key propaganda?
http://www.garlic.com/~lynn/2008i.html#12 pro- foreign key propaganda?
http://www.garlic.com/~lynn/2008i.html#13 pro- foreign key propaganda?
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
should I encrypt over a private network?
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: should I encrypt over a private network?
Newsgroups: comp.security.misc
Date: Fri, 23 May 2008 09:49:46 -0400
marlow.andrew writes:
Suppose a company has 2 sites, A and B, one is primary, the other is
secondary for DR reasons. A and B are separated significantly
geographically. Both A and B use a SAN for their data. A and B are
connected by a private network. The SAN data is replicated between A
and B over this private network using some replication product. My
question is, "should I be worried about the fact that the SAN
replication product does not do encryption?". When I raised these
concerns the answer I was given was "its a private network so its not
a problem". I am still not sure. Maybe I'm paranoid but I thought most
security jobs were inside jobs and this is made easier if the data
going over the wire is always in plaintext. But then again, data sent
around the LAN using NFS is not encrypted either.
in the mid-80s, there were claims that the corporate internal network
had over half of all the link encryptors in the world (basically any
link leaving corporate premise had to be encrypted) ... this was
about the time that the size of arpanet/internet finally exceeded
the internal network (which had been larger from just about the
beginning until sometime mid-85) ... misc. posts mentioning internal
network:
http://www.garlic.com/~lynn/subnetwork.html#internalnet
in that period there was a story about a foreign consulate location, in
one of the major city, apparently was chosen because it had line-of-site
of a large microwave communication antenna array for major cross-country
communication. there were comments that a lot of foreign government
espionage was heavily intertwined with industrial espionage.
slightly earlier, in the early part of the 80s ... was looking at
deploying dial-up access into the corporate network for both (actually
major expansion for) home access (since i've had dial-up access at home
since mar70) and hotel/travel access. a detailed study found that hotel
pbx rooms were frequently especially vulnerable ... and as a result
encryption requirement was extended to all dial-up access ... which
required designing and building a custom encrypting dial-up modem for
these uses.
a lot of the internet hype seems to have distracted attention from both
other forms of external compromises as well as internal attackers.
for a little additional topic drift:
http://www.garlic.com/~lynn/2008h.html#87 New test attempt
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
Does anyone have any IT data center disaster stories?
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 23, 2008
Subject: Does anyone have any IT data center disaster stories?
Blog: Information Security
When we were doing the high availability HA/CMP product we looked at
all kinds of ways that things could fail. One of the things was that
over the decades, both software and hardware reliability had increased
significantly. As a result the remaining failure modes tended to be
human mistakes and environmental. As part of HA/CMP marketing, we had
coined the terms disaster survivability and geographical
survivability (to differentiate from disaster/recovery).
http://www.garlic.com/~lynn/subtopic.html#available
An example in this period, there was the garage bombing at the World
Trade Center ... which included taking out a "disaster/recovery"
datacenter that was located in lower floors. Later there was a large
financial transaction processing center that had its roof collapse
because of snow loading. Its disaster/recovery datacenter was the one
in the World Trade Center (that was no longer operational).
On the other hand, long ago and far away, my wife had been con'ed into
going to POK to be in charge of loosely-coupled architecture
(mainframe for cluster). While there she created peer-coupled
shared data architecture ... which, except for IMS hotstandby,
didn't see any takeup until SYSPLEX.
http://www.garlic.com/~lynn/subtopic.html#shareddata
There has been another very large financial transaction processing
operation that has triple replicated locations and has attributed its
100percent availability to
• automated operator
• ims hot-standby
posts from slightly related discussion in comp.database.theory forum:
http://www.garlic.com/~lynn/2008i.html#8
http://www.garlic.com/~lynn/2008i.html#12
http://www.garlic.com/~lynn/2008i.html#13
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
Microsoft versus Digital Equipment Corporation
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Microsoft versus Digital Equipment Corporation
Newsgroups: alt.folklore.computers,alt.sys.pdp10
Date: Sat, 24 May 2008 11:30:39 -0400
Johnny Billquist <bqt@update.uu.se> writes:
No. I don't think they could have done it either. Cache coherency
between several processors had to be done in software back then. The
whole theory behind cache coherency protocols hadn't been thought out
yet, and also, implementing that in hardware back then would have been
a big box.
or at least at dec.
note that the 370 cache coherency resulted in slowing processor cycle
down by ten percent ... a basic two-processor smp started out at 1.8
times a single processor because each processor running ten percent
slower allowing for signaling and listening to the other cache. the
processing of cache invalidate signals received from another cache
further degraded performance (over and above the ten percent slow-down
just to allow for signaling and listening).
favorite son operating system for two-processor smp typically was quoted
at 1.4-1.5 times thruput a single processor ... after throwing in kernel
serialization, locking, and kernel software signaling overhead.
the stuff i had done, with some slight of hand, i had gotten very close
to 1.8 hardware thruput ... and in few cases got two times or better
(because of some cache affinity and cache hit ratio effects).
misc. past smp posts and/or references to charlie inventing the
compare&swap instruction while working on cp67 kernel smp fine-grain
locking
http://www.garlic.com/~lynn/subtopic.html#smp
old email referencing dec announcement of symmetrical
multiprocessing (and some commencts about not considered "real"
commercial until it supported symmetrical ... vax 8800)
http://www.garlic.com/~lynn/2007.html#email880324
http://www.garlic.com/~lynn/2007.html#email880329
in this post
http://www.garlic.com/~lynn/2007.html#46 How many 36-bit Unix ports in the old days?
i've frequently claimed that john's 801/risc design (trade-offs) were
based on both the heavy multiprocessor cache consistency overhead
(that didn't scale well as number of processors increase) ... and
doing the exact (KISS) opposite of what had been attempted in
the (failed) future system effort
http://www.garlic.com/~lynn/subtopic.html#futuresys
which was attempted to combine lots of advanced features, borrowing from
tss/360, multics, and some very complex hardware interfaces. some sense
of that showed up in the subsequent system/38 effort ... while 801/risc
tried to do the exact opposite.
it wasn't until later generations with things like directory cache
consistencyh and numa that started to see scaleup in number of
processors
the work on (hardware) cache consistency implementations was also useful
in working out details of distributed lock manager for ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp
as well as a process that would allow (database) cache-to-cache copying
(w/o first having to write to disk) while still being able to preserve
acid properties
some recent posts mentioning DLM work:
http://www.garlic.com/~lynn/2008b.html#69 How does ATTACH pass address of ECB to child?
http://www.garlic.com/~lynn/2008c.html#81 Random thoughts
http://www.garlic.com/~lynn/2008d.html#25 Remembering The Search For Jim Gray, A Year Later
http://www.garlic.com/~lynn/2008d.html#70 Time to rewrite DBMS, says Ingres founder
http://www.garlic.com/~lynn/2008g.html#56 performance of hardware dynamic scheduling
http://www.garlic.com/~lynn/2008h.html#91 Microsoft versus Digital Equipment Corporation
some recent numa/sci posts:
http://www.garlic.com/~lynn/2008e.html#40 Fantasy-Land_Hierarchal_NUMA_Memory-Model_on_Vertical
http://www.garlic.com/~lynn/2008f.html#3 Fantasy-Land_Hierarchal_NUMA_Memory-Model_on_Vertical
http://www.garlic.com/~lynn/2008f.html#6 Fantasy-Land_Hierarchal_NUMA_Memory-Model_on_Vertical
http://www.garlic.com/~lynn/2008f.html#8 Fantasy-Land_Hierarchal_NUMA_Memory-Model_on_Vertical
http://www.garlic.com/~lynn/2008f.html#12 Fantasy-Land_Hierarchal_NUMA_Memory-Model_on_Vertical
http://www.garlic.com/~lynn/2008f.html#19 Fantasy-Land_Hierarchal_NUMA_Memory-Model_on_Vertical
http://www.garlic.com/~lynn/2008f.html#21 Fantasy-Land_Hierarchal_NUMA_Memory-Model_on_Vertical
http://www.garlic.com/~lynn/2008h.html#80 Microsoft versus Digital Equipment Corporation
http://www.garlic.com/~lynn/2008h.html#84 Microsoft versus Digital Equipment Corporation
http://www.garlic.com/~lynn/2008i.html#2 Microsoft versus Digital Equipment Corporation
http://www.garlic.com/~lynn/2008i.html#3 Microsoft versus Digital Equipment Corporation
http://www.garlic.com/~lynn/2008i.html#5 Microsoft versus Digital Equipment Corporation
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
American Airlines
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: American Airlines
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 24 May 2008 11:49:22 -0400
lists@AKPHS.COM (Phil Smith III) writes:
That would be the problem today; back in 1989 when SABRE (to the best
of my knowledge) was the main airline reservation system, they didn't
have that option.
But it was long ago and far away, and my memory may be faulty!
sabre was "main" for several airlines ... but there also was united's
reservation system (Apollo) ... and in that time-frame, my wife had
done a brief stint as chief architect for amadeus (which started off
with the old eastern airlines reservation system, SystemOne)
one of the things that cut her stint short with amadeus was that she
side with the decision to use x.25 rather than sna as the main
communication protocol ... which brought out a lot of opposition from
certain quarters. it didn't do them much good since amadeus went with
x.25 anyway.
current amadeus website
http://www.amadeus.com/
for other archeological notes ... eastern airlines res system had been
running on 370/195. one of the things that help put the final nails
in the future system project coffin
http://www.garlic.com/~lynn/subtopic.html#futuresys
was analysis that if a future system machine was implemented out of
the same performance technology as used in 370/195 ... and the eastern
airlines res. system moved over to it ... it would have the thruput of
370/145.
wiki computer res system page
http://en.wikipedia.org/wiki/Computer_reservations_system
from above:
European airlines also began to invest in the field in the 1980s,
propelled by growth in demand for travel as well as technological
advances which allowed GDSes to offer ever-increasing services and
searching power. In 1987, a consortium led by Air France and West
Germany's Lufthansa developed Amadeus, modeled on SystemOne. In 1990,
Delta, Northwest Airlines, and Trans World Airlines formed Worldspan,
and in 1993, another consortium (including British Airways, KLM, and
United Airlines, among others) formed the competing company Galileo
International based on Apollo. Numerous smaller companies have also
formed, aimed at niche markets the four largest networks do not cater
to.
... snip ...
for totally unrelated topic drift ... at one point we were asked to
consult with one of the main reservation systems about redoing
various parts of the implementation. recent posts mentioning
doing a paradigm change in the implementation of routes:
http://www.garlic.com/~lynn/2008h.html#61 Up, Up, ... and Gone?
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
Microsoft versus Digital Equipment Corporation
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Microsoft versus Digital Equipment Corporation
Newsgroups: alt.folklore.computers,alt.sys.pdp10
Date: Sat, 24 May 2008 11:52:22 -0400
peter@taronga.com (Peter da Silva) writes:
The 11/44 and 11/60 could support about 8 users under RSTS, about 4 under
2BSD or 3BSD UNIX. Most of the Berkeley 11/70s could support 10-30 users
under 3BSD, but they started sucking at the high end. The Cory 11/70, the
undergrad EECS machine, had up to 70 users on it during finals week and
it was definitely way past "unhappy" at that point.
i remember somebody sending me email from one of the USB machines when
it was loaded at that level and mentioning "response" (that should
have been subsecond) was on the order of minute.
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
Worst Security Threats?
Refed: **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 25, 2008
Subject: Worst Security Threats?
Blog: Information Security
we had been asked to come in and help word smith the cal. electronic
signature legislation (and later the fed. legislation).
http://www.garlic.com/~lynn/subpubkey.html#signature
Some of the parties involved were also working on privacy issues and
had done in depth consumer surveys ... and found the two most
important issues were
• identity theft (mostly account fraud, fraudulent transactions
against existing account)
• denial of service (institutions using personal information to the
detriment of the individual
studies have regularly found that upwards of 70percent of identity
theft involve "insiders".
part of the lack of attention to identity theft problem was at the
basis of the subsequent cal. state. breach notification legislation
(which has since also shown up in many other states).
recent article
Most Retailer Breaches Are Not Disclosed, Gartner Says
http://www.pcworld.com/businesscenter/article/146278/most_retailer_breaches_are_not_disclosed_gartner_says.html
Most retailer breaches are not disclosed, Gartner says
http://www.networkworld.com/news/2008/052408-most-retailer-breaches-are-not.html
in the mid-90s, the x9a10 financial standard working group had been
given the requirement to preserve the integrity of the financial
infrastructure for all retail payments. part of that effort was
detailed study of threats & vulnerabilities related to fraudulent
transactions. the product of the x9a10 financial standard working
group was the x9.59 financial transaction standard
http://www.garlic.com/~lynn/x959.html#x959
part of the detail threat and vulnerability study was identifying lots
of infrastructure & paradigm issues ... including transaction
information having diametrically opposing requirements. For security
reasons, existing transaction & account information has to be kept
completely confidential and never divulged. However, there are a large
number of business processes that require access to the transaction
and account information in order to perform transaction
processing. This has led to our periodic comment that even if the
planet were buried under miles of information hiding encryption ... it
still wouldn't be possible to prevent breaches.
As a result, x9.59 standard slightly modified the transaction
processing paradigm ... making previous transaction information
useless to attackers for performing fraudulent transactions. x9.59 did
nothing regarding trying to hide such information ... but x9.59
standard eliminated such breaches as threat & vulnerability.
another aspect of the detailed vulnerability and threat analysis
(besides diametrically opposing requirements on transaction
information, both can never be divulged and at the same time required
for numerous business processes) ... was security proportional to
risk. Huge part of existing attacks (both insiders and outsiders) are
directed at these breaches since the results represent significant
financial gain to the attackers (from the fraudulent transactions).
We've estimated that the value of the information to the attackers
(steal all the money in the account or run up transactions to the
credit limit) is hundreds of times greater than the value of the
information to the retailers (profit margin on the transaction). As a
result, the attackers (insiders and outsiders) can afford to outspend
the defenders possibly 100:1. In effect, the x9.59 financial standard
corrected this imbalance also by removing the value of the information
to the attackers. This also eliminates much of the motivation behind
the phishing attacks (i.e. doesn't eliminate the attacks, just
eliminates the usefulness of the information for fraudulent
transaction purposes).
part of security proportional to risk came from having been asked to
consult with small client/server startup that wanted to do payments
transactions on their server and had this technology they had invented
and wanted to use called SSL. Most people now refer to the result as
electronic commerce.
One of the things that we kept running into was that none of the
server operators could afford what we were specifying as the necessary
minimum security (proportional to the financial risk). This was later
confirmed by the x9a10 financial standard working group detail threat
and vulnerabiilty studies ... and helped motivate the paradigm tweak
in the x9.59 financial standard (which removed most phishing and
breaches as a vulnerability, didn't eliminate phishing and breaches,
just removed most of the basic financial motivation behind the
phishing and breach efforts).
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
Microsoft versus Digital Equipment Corporation
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Microsoft versus Digital Equipment Corporation
Newsgroups: alt.folklore.computers,alt.sys.pdp10
Date: Mon, 26 May 2008 09:48:17 -0400
jmfbah <jmfbahciv@aol> writes:
Shouldn't the monitor (or exec or kernel) know a physical location is
shared?
caches are where subsets of information contained in local store with
some sort of identification ... in fact, the location in local store is
frequently selected by using subset/index bits from the identification.
a physical mapped cache uses the physical address to identify things in
the cache ... and bits from the physical address to index location
in the cache.
a virtual mapped cache uses the virtual address to identify things in
the cache ... and bits from the virtual address to index location in
the cache. this can start cache lookup w/o waiting to perform virtual
to physical address translation from the table/translation lookaside
buffer.
the virtual mapped cache sharing problem is aliasing ... where the same
shared (physical) location can be known by multiple different virtual
addresses. this opens the possibility that the same physical data
indexes to different locations in a virtual cache (because of different
virtual addresses) and is known/named by different (virtual address)
name/alias
the monitor will know a physical address is shared ... when it sets up
the (virtual to real) translation tables ... but that doesn't mean that
a virtual cache can easily figure out that a physical address is shared
and known by multiple different aliases (major point of having a virtual
cache is doing a quicker lookup w/o having to wait for the virtual to
real translation delay from the tlb).
the issue is somewhat analogous to multiprocessor cache consistency
protocols ... i.e. how to maintain consistency where the same physical
data may be in different caches ... but in this case, it is the same
physical data in the same cache ... but at different locations because
of being known by multiple different names/aliases.
the assumption here is that the cache is large enuf that it attempts
to maintain locations for multiple different virtual address spaces
(and doesn't flush the cache whenever there is virtual address space
or context switch). this is analogous to table/translation look aside
buffer keeping virtual to physical address mappings for multiple
different virtual address spaces (as opposed to flushing all mappings
whenever there is context or virtual address space change). this is
the problem where different people have the same name and it is
necessary to differentiate which person you are talking about (as
opposed to the situation where the same person has multiple different
aliases).
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
Microsoft versus Digital Equipment Corporation
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Microsoft versus Digital Equipment Corporation
Newsgroups: alt.folklore.computers,alt.sys.pdp10
Date: Mon, 26 May 2008 09:52:32 -0400
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
I believe it was "Translation Lookaside Buffer" since virtual
storage was added to S/370. I am sometimes surprised when IBM
names for things stick, as this one seems to have done.
No-one else calls their disks DASD, and rarely starting
a system up through IPL.
from z-architecture principles of operation
3.11.4 Translation-Lookaside Buffer
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/3.11.4?SHELF=DZ9ZBK03&DT=20040504121320
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
Credit Card Fraud
Refed: **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 26, 2008
Subject: Credit Card Fraud
Blog: Information Security
In the mid-90s, the x9a10 financial standard working group had been
given the requirement to preserve the integrity of the financial
infrastructure for all retail payments. part of the effort was
detailed end-to-end threat & vulnerability study.
one of the major threats & vulnerabilities identified was being able
to use information from previous transactions enabling fraudulent
transactions (i.e. skimming at pos, evesdropping on the internet,
security breaches and data breaches of log files, and lots of other
kinds of compromises). we have sort of made reference to the general
phenomena as the "naked transaction" (where ever it exists, it is
vulnerable).
the x9a10 financial standard working group produced the x9.59 financial standard
http://www.garlic.com/~lynn/x959.html#x959
... which slightly tweaked the paradigm, eliminating the "naked
transaction" phenomena ...
http://www.garlic.com/~lynn/subintegrity.html#payments
aka it didn't do anything about attempting to hide the information
(from previous transactions) ... it just eliminated attackers being
able to use the information for fraudulent transactions.
somewhat related answer
http://www.linkedin.com/answers/technology/information-technology/information-security/TCH_ITS_ISC/237628-24760462
also
http://www.garlic.com/~lynn/2008i.html#21 Worst Security Threats?
part of the x9.59 financial standard protocol had been based on the
earlier work we had done on what is now usually referred to as
electronic commerce. we were asked to consult with a small
client/server startup that wanted to do financial transactions on
their servers and had this technology called SSL they had invented and
wated to use. The major use of SSL in the world today is involved with
this thing called electronic commerce and hiding information related
to the transactions.
Part of the x9.59 standard was eliminating the need to hide financial
transaction information as countermeasure to fraudulent
transactions ... which then can be viewed as also eliminating the
major use of SSL in the world today.
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
Microsoft versus Digital Equipment Corporation
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Microsoft versus Digital Equipment Corporation
Newsgroups: alt.folklore.computers,alt.sys.pdp10
Date: Tue, 27 May 2008 08:58:34 -0400
Johnny Billquist <bqt@update.uu.se> writes:
Caching on virtual addresses is messy in so many ways...
Oh, and caches with more than one cache line for each address isn't in
any way unusual (can someone help me remember the correct term
here?). The cache in the PDP-11/70 is 2-way associative, which means
that for each cache line, there are two memory cells that can hold the
data. So, two different addresses that hash to the same cache line can
be in the cache simultaneously. Which is a good thing.
re:
http://www.garlic.com/~lynn/2008i.html#22 Microsoft versus Digital Equipment Corporation
so virtual cache problem can be akin to the multiprocessor cache
coherency ... the same physical location can appear in multiple
different places.
typically a group of cache lines is "indexed" by a set of bits from the
location address (and then that set is check to see if the required
information is already loaded ... and if not ... one of the cache lines
is selected for replacement).
in a virtual cache ... some of the bits may come from the "page"
displacement ... i.e. that part of the address that is from the page
displacement from of the virtual address. those set of bits would be the
same for a physical address that might be known/loaded by different
virtual addresses. other parts of the cache index bits may come from
that part of the location address that is greater than the page
displacement ... and may be different for physical location that is
shared in different virtual address spaces at different location (alias
problem).
so one of the approaches to virtual cache coherency is if the desired
location isn't in the cache ... it is a miss and has to start a real
storage fetch. however, overlapped (which might take thousands of
cycles) it could check the other possible alias locations. it has to
interrogate the TLB to get the real address (for the missing cache line)
in order to do the real memory fetch. it then could also look at all the
possible alias locations for the same physical data ... while it is
waiting for the real storage fetch (alternatively it could simply
invalidate all virtual cache lines that might be an alias).
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
Microsoft versus Digital Equipment Corporation
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Microsoft versus Digital Equipment Corporation
Newsgroups: alt.folklore.computers,alt.sys.pdp10
Date: Tue, 27 May 2008 09:13:55 -0400
jmfbah <jmfbahciv@aol> writes:
So, when the contents of a virtual address has to be written back
to physical memory, does the monitor do the virtual-to-physical
calculation or does the cache? I think I would hope that the monitor
does this...but I'm not sure why.
re:
http://www.garlic.com/~lynn/2008i.html#22 Microsoft versus Digital Equipment Corporation
if it is a hardware managed cache ... on a cache miss (can't find it),
the hardware interrogates the TLB for the real address ... and sends out
a request to real memory to load the cache line for that real address.
similarly, when a (store into) cache line is being replaced and the
(changed) information has to be flushed to real storage ... it can
interrogate the TLB for the real address.
however, some virtual caches may keep the virtual cache line "tagged"
with both the virtual address as well as the real address (when it is
loaded) ... even thot the cache line isn't "indexed" by the real
address; i.e. in virtual cache that is simultaneously keeping track of
cache lines from multiple different virtual address spaces ... it
already has to track the virtual address space identifier and virtual
address for each cache line ... in addition it might also remember the
physical address (even tho the real address isn't used to index the
cache line). when a (modified) cache line has to be written back to
storage ... this allows the operation to start immediately w/o the
hardware having to do a separate interrogation of the TLB to get the
corresponding real address.
so in this discussion about analogy between multiprocessor cache
coherency and virtual caches that support aliases (same real
address known by multiple different virtual addresses)
http://www.garlic.com/~lynn/2008i.html#25 Microsoft versus Digital Equipment Corporation
if the cache is keeping the real address as part of a cache line tag,
then it can look at all possible alternative alias locations that
the same real address might appear and only invalidate/remove it
if it has a matching real address.
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
Microsoft versus Digital Equipment Corporation
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Microsoft versus Digital Equipment Corporation
Newsgroups: alt.folklore.computers,alt.sys.pdp10
Date: Tue, 27 May 2008 09:58:01 -0400
jmfbah <jmfbahciv@aol> writes:
But associative memory is nothing new. it used to be considered a
feature.
re:
http://www.garlic.com/~lynn/2008i.html#22 Microsoft versus Digital Equipment Corporation
http://www.garlic.com/~lynn/2008i.html#24 Microsoft versus Digital Equipment Corporation
http://www.garlic.com/~lynn/2008i.html#26 Microsoft versus Digital Equipment Corporation
both caches and TLBs are frequently partially associative. TLBs
sometimes are hardware managed cache of translation table information
(virtual address to real address mapping) that are located in real
storage (although some TLBs are software managed ... and require the
monitor to load values).
typical cache entries (and hardware TLB managed entries) are broken into
sets of entries. say a 2mbyte cache with 128 byte cache lines ... has
16,384 cache lines. If the cache is 4-way associative, the cache is
broken up into 4096 sets of fur cache lines each. The cache then needs
to use 12 bits from the original address (real or virtual) to index one
of the 4096 set of four cache lines ... and then check all four of those
cache lines (i.e. associative) whether they match the desired address.
(hardware) TLBs tend to work similarly (caching virtual to real address
information), they have a set of entries that may be 2-way or 4-way.
Bits from the address are used to index a specific set of entries and
then all entries in that set are check for match.
This is a trade-off between the circuits/delay required to do a fully
associative check and the interference that can happen when a whole set
of different addresses map to the same, single entry and start
"thrashing".
there was an issue with 370/168 TLB in the bits it used to index the
TLB. These were 16mbyte/24bit virtual address machines. There were 128
TLB entries ... and one of the bits used to index TLB entries was the "8
mbyte bit" (i.e 24bits, numbered 0-23, the first or zero bit). The
favorite son operating system was designed that the kernel occupied
8mbytes of each virtual address space and (supposedly) the kernel had
the other 8mbytes. The result was that typically half of the TLB entries
were filled with kernel virtual addresses and half the TLB was filled
with appication virtual addresses. However, for vm370/cms, the cms
virtual address space start at zero ... and extended upwards ... and
most applications rarely crossed the 8mbyte line ... so frequently half
the 370/168 TLB entries would go unused.
370 TLBs were indexed with low associative ... however, 360/67
"look-aside" (hardware virtual to real mapping) wasn't referred to as
TLB ... it was called the associative array ... since it was fully
associative (all entries interrogated in parallel).
there was sort of a virtual/real cache issue with the introduction of
the 370/168-3 which doubled the 32k cache (from 370/168-1) to 64k
cache. The number of sets of cache line were such that the index bits
could be taken purely from the page displacement of the address ...
which would be the same whether it was a virtual address or a real
address.
370 had support for both 2k virtual page size mode and 4k virtual page
size mode. With 32k cache ... there was no difference for 2k & 4k page
sizes ... however for 64k cache, they took the "2k" bit as part of cache
line indexing. As a result, a 168-3, when operating in 4k virtual page
mode would use the full 64k cache ... but when operating in 2k virtual
page mode would only use 32k cache. And in any transition between 2k and
4k modes ... the cache would be flushed ... since the mappings were
different. Now some customers running vm370 with VS1 virtual guest
(batch operating system that ran with 2k virtual page sized) on 168-1,
upgraded to 168-3 and performance got much worse.
Nominally, VS1 would run on 168-3 with 32k cache ... just like it was a
168-1 ... and shouldn't have seen any performance improvement (as
opposed to performance decrease). The problem was that vm370 defaulted
hardware settings to 4k page mode ... except when 2k page mode was
specifically requested. The result was that vm370 (when running virtual
VS1 or DOS/VS) was frequently making hardware switch back and forth
between 2k and 4k page modes. On all other machines ... this wasn't a
problem ... but on 168-3 ... this resulted in the cache having to be
flushed (everytime the switch occurred).
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
Scalable Nonblocking Data Structures
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Scalable Nonblocking Data Structures
Newsgroups: alt.folklore.computers
Date: Tue, 27 May 2008 19:36:49 -0400
Scalable Nonblocking Data Structures
http://developers.slashdot.org/article.pl?sid=08/05/27/1916235
Cliff Click on a Scalable Non-Blocking Coding Style
http://www.infoq.com/news/2008/05/click_non_blocking
from above:
The major components of Click's work are:
...
2. Atomic-update on those array words (using
java.util.concurrent.Atomic.*). The Atomic update will use either
Compare and Sweep (CAS) if the processor is Azul/Sparc/x86, or Load
Linked/Store-conditional (LL/SC) on the IBM platform.
... snip ..
or maybe compare&swap ... invented by charlie (i.e. CAS are charlie's
initials) when he was doing work on multiprocessing fine-grain locking
for cp67 virtual machine system at the science center. misc. past posts
mentioning smp and/or compare&swap
http://www.garlic.com/~lynn/subtopic.html#smp
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
What is your definition of "Information"?
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 27, 2008
Subject: What is your definition of "Information"?
Blog: Information Storage
old definition we used from 15-20 yrs ago:
metadata of data is information
metadata of information is knowledge
metadata of knowledge is wisdom
metadata of wisdom is enlightenment
....
we had looked at copyrighting the term business science in the early
90s, somewhat in conjunction with this graph ... old post from 1995
archived here ...
http://www.garlic.com/~lynn/95.html#8aa
subsequently there have been more simplified version of the above
diagram
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
subprime write-down sweepstakes
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: subprime write-down sweepstakes
Newsgroups: alt.folklore.computers
Date: May 29, 11:59 am
lynn wrote:
one of the business shows commented on Bernanke's statements today
saying that he has gotten quite repetitive about new regulations (like
Basel2) fixing the situation.
they then went on to say that american bankers are the most inventive in
the world ... that they have managed to totally screwup the system at
least once a decade regardless of the measures put in place attempting
to prevent it.
re:
http://www.garlic.com/~lynn/2008h.html#90 subprime write-down sweepstakes
Did Wall Street Wreck The Economy?, Congress, regulators start to
connect the dots
http://www.consumeraffairs.com/news04/2008/05/wall_street.html
from above:
If so, that thread may lead to Wall Street. Increasingly, everyone
from lawmakers to industry insiders has been connecting the dots to
reveal how some investors' actions have had huge repercussions on the
economy.
... snip ...
as mentioned previously .... toxic CDOs were used two decades
ago in the S&L crisis to obfuscate the underlying value ... and in
this decade-old, long-winded post .... there is discussion about need
for visibility into CDO-like instruments
http://www.garlic.com/~lynn/aepay3.htm#riskm
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
Mastering the Dynamics of Innovation
Refed: **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 30, 2008
Subject: Mastering the Dynamics of Innovation
Blog: Change Management
Many times, existing processes represent some organization,
technology, and/or business trade-offs that occurred at some point in
time. such trade-offs become institutionalized ... and there is
frequently failure to recognize that when the environment has changed
(that original trade-off assumptions were based on) ... that the
resulting trade-off decisions are no longer valid.
for truely off the wall way for viewing this is myers-briggs
personality traits ... where the majority of the population tends to
be personality types that operate on previous experience ... and only
an extremely small percentage of the population routinely operate
based on analytical analysis. it is much more difficult for
experiential personality types to operate out of the box and routinely
view and operate purely analytically. It is much easier to for the
analytically oriented to recognize that basis for originally trade-off
decisions to have totally changed.
this also can show up as generational issues where the young
experiential personality types (that still need to be molded by
experience) tend to be much more open to different ways of doing
things (but that tends to gradually change as they gain experience).
Analytically oriented personalities tend to live their whole life
questioning rules and authorities (not just in youth).
I've periodically commented that from an evolutionary aspect, in a
static, stable environment ... constantly having to analyze and figure
out the reason why things are done, represents duplication of effort
(effectively waste of energy). However in a changing environment, it
can represent a significant more efficient means of adapting to change
(compared to experimental trial and error approach). One possible
study might be are their shifts in the ratio of different personality
types based on whether the environment is static or rapidly changing.
Circa 1990, one of the large US auto manufacturing companies had a C4
effort that was to look at radically changing how they did businesses
and they invited some number of technology vendors to participate. One
of their observations was that US industry was (still) on 7-8 yr new
product cycle while foreign competition radically reduced the elapsed
time to turn out new products. Being faster also makes it easier to
address all sorts of other issues (including quality). Introducing
change is easier if it is done in new cycle... and if the new cycles
are happening faster and much more frequently ... it promotes
agility/change.
... aka being able to operate Boyd's OODA-loop faster than the
competition. lots of past posts mentioning Boyd and/or OODA-loops
http://www.garlic.com/~lynn/subboyd.html
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
A Tribute to Jim Gray: Sometimes Nice Guys Do Finish First
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: Sun, 1 Jun 2008 14:12:40 -0700 (PDT)
Subject: A Tribute to Jim Gray: Sometimes Nice Guys Do Finish First
A Tribute to Jim Gray: Sometimes Nice Guys Do Finish First
http://bits.blogs.nytimes.com/2008/05/31/a-tribute-to-jim-gray-sometimes-nice-guys-do-finish-first/
from above:
During the 1970s and '80s at I.B.M. and Tandem Computer, he helped
lead the creation of modern database and transaction processing
technologies that today underlie all electronic commerce and more
generally, the organization of digital information. Yet, for all of
his impact on the world, Jim was both remarkably low-key and
approachable. He was always willing to take time to explain technical
concepts and offer independent perspective on various issues in the
computer industry
... snip ...
Tribute to Honor Jim Gray
http://www.eecs.berkeley.edu/IPRO/JimGrayTribute/pressrelease.html
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
Mainframe Project management
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: June 1, 2008
Subject: Mainframe Project management
Blog: Computers and Software
Mainframe efforts have tended to be much more business critical and
therefor have tended to spend a lot more time making sure that there
are no problems and/or if problems might possibly show up, functions
are provided that anticipate and can handle the problems.
As part of the support for the internet payment gateway as part of
what is now referred to as electronic commerce (and the original SOA)
... the initial implementation involved high quality code development
and testing.
http://www.garlic.com/~lynn/subnetwork.html#gateway
However, we have ofter commented to take a traditional application
and turn it into a business critical service can require 4-10 times
the base development effort. Part of the subsequent payment gateway
effort we developed a failure matrix ... all possible ways that we
could think of that a failure might occur involving the payment
gateway ... and all the possible states that a failure could occur
in. It was then required that the payment gateway show that it could
automatically handle/recover all possible failure modes in all
possible states ... and/or demonstrate that the problem could be
isolated and identified within a very few minutes.
A much earlier example ... as part of turning out the mainframe
resource management product,
http://www.garlic.com/~lynn/subtopic.html#fairshare
the final phase involved a set of over 2000 validation and calibration
benchmarks that took over 3 months elapsed time to run. This included
a sophisticated analytical system performance model which would
predict how the system was expected to operate under various
conditions (workload and configuration) ... automatically configure
for that benchmark, automatically run the benchmark and then validate
whether the results matched the predicted.
http://www.garlic.com/~lynn/subtopic.html#benchmark
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
American Airlines
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Newsgroups: bit.listserv.ibm-main, alt.folklore.computers
Date: Sun, 1 Jun 2008 20:29:51 -0700 (PDT)
Subject: Re: American Airlines
hancock4 writes:
Question:
SABRE took years to develop. Did it take equally long to develop
systems for competing airlines? For those using IBM platforms, could
they use any code or designs for SABRE or were they propriety to
American Airlines?
re:
http://www.garlic.com/~lynn/2008i.html#19 American Airlines
there was airline control program (ACP) that was (vendor) operating
system used for many of these online systems .... wiki page
http://en.wikipedia.org/wiki/Airlines_Control_Program
there was long period of evolution of the ACP operating system as well
as the customer applications built on the operating system. In some
sense SABRE is a brand which is a whole bunch of online applications
that were (initially) built on ACP. Some number of the other airline
res "systems" were also whole set of applications built using the ACP
operating system. Currently, some number of the applications have been
migrated to other platforms.
circa 1980 or so ... there were some number of financial institutions
using ACP for financial transactions ... which led to renaming ACP to
TPF (transaction processing facility) ... wiki page
http://en.wikipedia.org/wiki/Z/TPF
from above:
Current users include Sabre (reservations), Amadeus (reservations),
VISA Inc (authorizations), Holiday Inn (central reservations), CBOE
(order routing), Singapore Airlines, KLM, Qantas, Amtrak, Marriott
International , worldspan and the NYPD (911 system).
... snip ...
For some "transaction" drift ... yesterday, a tribute was held for Jim
Gray
http://www.garlic.com/~lynn/2008i.html#32 A Tribute to Jim Gray: Sometimes Nice Guys Do Finish First
Bruce Lindsay gave a great talk about Jim formalizing transactions and
databases management ... to provide sufficient integrity and
reliability that they could be trusted in lieu of paper entries ...
which was required to make things like online transaction processing
possible (i.e. it was necessary to demonstrate high enough integrity
and reliability that it would be trusted in place of paper and
human/manual operations).
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
American Airlines
From: lynn@garlic.com
Newsgroups: bit.listserv.ibm-main, alt.folklore.computers
Date: Sun, 1 Jun 2008 21:00:29 -0700 (PDT)
Subject: Re: American Airlines
On May 31, 7:42 am, wrote:
Don't forget that the first one is always the one that figures
out everything that can't be done. The "can't be dones" take
an enormous amount of calendar time to do. Sometimes it can
take 2 or 3 software releases (in those days that was usually
2 years) to get it "right".
re:
http://www.garlic.com/~lynn/2008i.html#19 American Airlines
http://www.garlic.com/~lynn/2008i.html#34 American Airlines
the reference to doing 10 impossible things
http://www.garlic.com/~lynn/2008h.html#61 Up, Up, ... and Gone?
mentions having to do a major paradigm change in how things were
implemented. Part of the 10 impossible things were because of heavy
manual involvement in how the information was preprocessed for use by
the system. Part of the major paradigm change involved effectively
totally eliminating all that manual preprocessing ... making it all
automated.
Some number of the 10 impossible things were also performance/thruput
limitations related. So part of the paradigm change was to make some
things run 100 times faster. This allowed 3-4 separate queries to be
collapsed into a single operation, improving human factors (since it
was now possible to do a lot more, a lot of back&forth interaction
with an agent could all be automated).
A combination of the human involvement in data preprocessing and
performance limitations resulted in limitation on the number of flight
segments that could be considered. Change in paradigm resulted in all
flt segments in the world being easily handled
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
A Tribute to Jim Gray: Sometimes Nice Guys Do Finish First
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: Sun, 1 Jun 2008 21:15:55 -0700 (PDT)
Subject: Re: A Tribute to Jim Gray: Sometimes Nice Guys Do Finish First
re:
http://www.garlic.com/~lynn/2008i.html#32 A Tribute to Jim Gray: Sometimes Nice Guys Do Finish First
http://www.garlic.com/~lynn/2008i.html#34 American Airlines
lynn wrote:
http://www.eecs.berkeley.edu/IPRO/JimGrayTribute/pressrelease.html
from above:
Gray is known for his groundbreaking work as a programmer, database
expert and Microsoft engineer. Gray's work helped make possible such
technologies as the cash machine, ecommerce, online ticketing, and
deep databases like Google. In 1998, he received the ACM A.M. Turing
Award, the most prestigious honor in computer science. He was
appointed an IEEE Fellow in 1982, and also received IEEE Charles
Babbage Award.
... snip ...
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
American Airlines
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Newsgroups: bit.listserv.ibm-main, alt.folklore.computers
Date: Mon, 2 Jun 2008 07:54:43 -0700 (PDT)
Subject: Re: American Airlines
Warren Brown wrote:
Actually, IBM built special hardware for this type of software to run on.
re:
http://www.garlic.com/~lynn/2008i.html#19 American Airlines
http://www.garlic.com/~lynn/2008i.html#34 American Airlines
http://www.garlic.com/~lynn/2008i.html#36 American Airlines
I was recently reviewing some old email exchanges with Jim Gray from
late 70s and there was one discussing the 3830 (disk controller) ACP
(lock) RPQ ... which basically provided logical locking function in
the controller ... for coordinating multiple loosely-coupled
(i,.e. mainframe for cluster) processors.
the old research bldg. 28, ... where the original relational/sql work
was done
http://www.garlic.com/~lynn/subtopic.html#systemr
was just across the street from bldg 14 (disk engineering lab) and
bldg. 15 (disk product test lab) ... and they let me play disk
engineer over there
http://www.garlic.com/~lynn/subtopic.html#disk
During Jim's tribute, people were asked to come up and tell
stories. The story I told was that Jim and I use to have friday
evening sessions at some of the local establishments in the area (when
eric's deli opened across from the plant site, they let us use the
back room and gave us pitchers of anchor steam at half price). One
Friday evening we were discussing what kind of "silver bullet"
application could we deploy that would entice more of the corporation
(especially executives) to actually use computers (primarily online
vm370) and we came up with the online telephone book. However one of
the requirements was that Jim would implement his half in 8hrs and I
would implement my half in 8hrs.
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
American Airlines
Refed: **, - **, - **
From: lynn@garlic.com
Newsgroups: bit.listserv.ibm-main, alt.folklore.computers
Date: 2 Jun 2008 10:15:34 -0700
Subject: Re: American Airlines
Eric Chevalier wrote:
However, we were using 2314s attached to these boxes, and I believe
there _was_ a hardware RPQ on the drives. Called something like
"Airlines Control Buffer", I _think_ the feature allowed the drive to
disconnect from the channel while doing a seek. Whatever the details,
it was something that became standard on later mainframe drives from
IBM.
re:
http://www.garlic.com/~lynn/2008i.html#19 American Airlines
http://www.garlic.com/~lynn/2008i.html#34 American Airlines
http://www.garlic.com/~lynn/2008i.html#36 American Airlines
http://www.garlic.com/~lynn/2008i.html#37 American Airlines
w/o the ACP RQP, loosely-coupled operation required reserve/release
commands ... which reserved the whole device for the duration of the
i/o operation. Actually reserve could be issued and possibly multiple
operations performed before issuing the release (traditional loosely-
coupled opeation ... locking out all other processors/channels in the
complex).
since it was logical name locks, there was significant latitude it
choosing lock names ... could be very low level like record name
... i.e. cchhr .... or something higher level like PNR.
note that while ACP/TPF did a lot of work on loosely-coupled, it took
them quite awhile to getting around to doing tightly-coupled
multiprocessor support. The result was quite a bit of consternation in
the 3081 timeframe ... which originally wasn't going to have a single
processor offering. One of the side-effects was that there were a
whole bunch of changes that went into vm370 for enhancing TPF thruput
in a 3081 environment ... changes that tended to degrade thruput for
all the non-TPF customers. Eventually, there was enough pressure, that
a 3083 (single processor) was offered ... primarily for ACP/TPF
customers.
There was another technique for loosely-coupled operation ...
originally developed for HONE (avoiding the performance impact of
reserce/release but w/o the airlines controller RPQ). HONE was the
world-wide, online (vm370-based) sales & marketing support system.
http://www.garlic.com/~lynn/subtopic.html#hone
The technique was basically a special CCW sequence that leveraged CKD
search commands to simulate the semantics of the mainframe
compare&swap instruction (but for DASD i/o operation). The US HONE
datacenter provided possibly the largest singie system image at the
time (combination of multple loosely-coupled, tightly-coupled
processor complex) with load-balancing and fall-over across the
complex. Later this was extended to geographic distance with
replicated center in Dallas and then a 3rd in Boulder.
There was then talks with the JES2 multi-access spool people about
them using the same CCW technique in their loosely-coupled operation.
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
American Airlines
Refed: **, - **, - **, - **, - **
From: lynn@garlic.com
Newsgroups: bit.listserv.ibm-main, alt.folklore.computers
Date: Mon, 2 Jun 2008 17:04:42 -0700 (PDT)
Subject: Re: American Airlines
John P. Baker wrote:
I seem to recall something called the "Limited Lock Facility (LLF)", which
provided some specialized CCW support in the controller.
Was it developed for use in situation such as that described here?
re:
http://www.garlic.com/~lynn/2008i.html#19 American Airlines
http://www.garlic.com/~lynn/2008i.html#34 American Airlines
http://www.garlic.com/~lynn/2008i.html#36 American Airlines
http://www.garlic.com/~lynn/2008i.html#37 American Airlines
http://www.garlic.com/~lynn/2008i.html#38 American Airlines
note by comparison, reserve will be a CCW that "locks" the whole
device ... which typically will be followed by some sort of
seek/search/read. That ends and the processor then operates/updates
the data read and then writes it back ... finally releasing the
device.
The other approach mentioned ... developed at HONE was simulation of
multiprocessor compare&swap instruction ... using "search key& data
equal" ... the data is read (w/o lock or reserve), a copy is made and
the update is applied. then a channel program with search key&data
equal ... using the original read image .... chained to write of the
updated data.
the following from long ago and far away ...
Subject: DASD sharing in ACP using the RPQ
Date: March 25, 1980
On Monday I bumped into xxxx & yyyy. They were both interested in
shared DASD for availability and load sharing. I mentioned the ACP
RPQ which puts a lock manager in the microcode for the disk
controller. They were real interested in that and so I began
telephoning.
My first contact was xxxxx of GPD San Jose who wrote the microcode
(nnn-nnnn). He explained that the RPQ "has a low profile" because it
is not part of the IBM strategy and is inconsistent with things like
string switching. The basic idea is that Lock commands have been
added to the controller's repertoire of commands. One issues LOCK
READ CCW pair and later issues WRITE UNLOCK CCW pair. If the lock
fails the read fails and the CPU will poll for the lock later. xxx
has documented all this in the technical report TR 02.859 "Limitied
Lock Facility in a DASD Control Unit" xxxxx, xxxxx, xxxxx (Oct. 1979).
xxx pointed me to xxx xxxxx at the IBM Tulsa branch office (nnn-nnnn).
xxxx wrote the channel programs in ACP which use the RPQ. He said
they lock at the record level, and that it works nicely. We also
discussed restart. He said that the code to reconfigure after CPU or
controller failure was not hard. For duplexed files they lock the
primary if available, if not they lock the secondary. ACP allows only
one lock at a time and most writes are not undone or redone at restart
(most records are not "critical"). xxx said that their biggest
problem was with on-line utilities. One which moves a volume from
pack to pack added 50% to their total effort! xxx in turn pointed me
to two of the architects.
xxxxxx at White Plains DPD (nnn-nnnn) knows all about ACP and promised
to send me the documentation on the changes to ACP. He said the
changes are now being integrated into the standard ACP system. He
observed that there is little degradation with the RPQ and prefers it
to the MP approach. He mentioned that there are about 65 ACP
customers and over 100 ACP systems. xxxxx is also at White Plains
(nnn-nnnn). He told me lots of numbers (I love numbers).
He described a 120 transaction/second system.
The database is spread over about 100 spindles.
Each transaction does 10 I/O.
10% of such I/O involve a lock or unlock command.
The average hold time of a lock is 100 ms.
1.7 lock requests wait per second.
That implies that 14% of transactions wait for a lock.
This is similar to the System R number that 10% of transactions wait.
ACP has deadlock avoidance (only hold one lock at a time).
There are 60 lock requests per second (and 60 unlocks) and so there
are about 6 locks set at any instant.
This is not a heavy load on the lock managers (a controller is likely
to have no locks set.)
... snip ...
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
A Tribute to Jim Gray: Sometimes Nice Guys Do Finish First
Refed: **, - **, - **, - **, - **
From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: Tue, 3 Jun 2008 08:05:21 -0700 (PDT)
Subject: Re: A Tribute to Jim Gray: Sometimes Nice Guys Do Finish First
re:
http://www.garlic.com/~lynn/2008i.html#32 A Tribute to Jim Gray: Sometimes Nice Guys Do Finish First
http://www.garlic.com/~lynn/2008i.html#36 A Tribute to Jim Gray: Sometimes Nice Guys Do Finish First
and a little related drift in this thread:
http://www.garlic.com/~lynn/2008i.html#37 American Airlines
another article
Tech luminaries honor database god Jim Gray
http://www.theregister.co.uk/2008/06/03/jim_gray_tribute/
from above:
"A lot of the core concepts that we take for granted in the database
industry - and even more broadly in the computer industry - are
concepts that Jim helped to create," Vaskevitch says, "But I really
don't think that's his main contribution."
... snip ...
and some old email references when Jim was leaving for Tandem and
tyring to hand off some number of responsibilities to me:
http://www.garlic.com/~lynn/2007.html#email801006
http://www.garlic.com/~lynn/2007.html#email801016
thread from last year on Jim having gone missing:
http://www.garlic.com/~lynn/2007d.html#4 Jim Gray Is Missing
http://www.garlic.com/~lynn/2007d.html#6 Jim Gray Is Missing
http://www.garlic.com/~lynn/2007d.html#8 Jim Gray Is Missing
http://www.garlic.com/~lynn/2007d.html#17 Jim Gray Is Missing
http://www.garlic.com/~lynn/2007d.html#33 Jim Gray Is Missing
http://www.garlic.com/~lynn/2007g.html#28 Jim Gray Is Missing
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
American Airlines
From: lynn@garlic.com
Newsgroups: bit.listserv.ibm-main, alt.folklore.computers
Date: Tue, 3 Jun 2008 09:23:19 -0700 (PDT)
Subject: Re: American Airlines
Shmuel Metz , Seymour J. wrote:
More like a precursor to the cache on a 3880-12.
splitting the difference :-)
3880-11 was "ironwood" ... 8mbyte 4k, "page" record cache
3880-13 was "sheriff" ... 8mbyte, full-track cache
later they were both upgraded to 32mbyte as -21 & -23
old post with some product "code" names
http://www.garlic.com/~lynn/2007e.html#38 FBA rant
there were some early -13 (& -23) literature showing 90percent cache
hit rate. i pointed out that the example was actually 3880 with 10
records per track and reading sequentially. the first record read for
a track would have a miss and bring in the whole track and then the
subsequent 9 reads would all be hits. I raised the issue that if the
application were to do full-track buffer reads ... that the same
sequently read would drop to zero percent hit rate.
past posts in this thread:
http://www.garlic.com/~lynn/2008i.html#19 American Airlines
http://www.garlic.com/~lynn/2008i.html#34 American Airlines
http://www.garlic.com/~lynn/2008i.html#35 American Airlines
http://www.garlic.com/~lynn/2008i.html#37 American Airlines
http://www.garlic.com/~lynn/2008i.html#38 American Airlines
http://www.garlic.com/~lynn/2008i.html#39 American Airlines
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
Security Breaches
Refed: **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: June 3, 2008
Subject: Security Breaches
Blog: Information Security
We had been called in to help word smith the cal. state electronic
signature (and later federal) legislation. past refs
http://www.garlic.com/~lynn/subpubkey.html#signature
Some of the involved organizations were also involved in privacy
issues and had done in-depth consumer surveys and found that the two
major issues were
1) identity theft ... account fraudulent transactions affecting most
people and stats have been that upwards of 70percent of the incidents
involved insiders
2) denial of service ... institutions using personal information to
the detriment of the individual
because so little attention was being paid to the root causes behind
these activities, it became major motivation for the cal. state
breach notification legislation (and subsequent similar
legislation in other states) ... hoping that the mandated breach
notification and associated publicity would start to result in
something being done about the problems.
Earlier we had been asked to consult with a small client/server
startup that wanted to do payment transactions on their server and had
this technology called SSL they had invented and wanted to use (now
frequently referred to as electronic commerce). Some number of past
posts referring to the activity
http://www.garlic.com/~lynn/subnetwork.html#gateway
We then got roped into working on the x9.59 financial transaction in
the x9a10 financial standard working group. In the mid-90s, X9A10 had
been given the requirement to preserve the integrity of the
financial infrastructure for all retail payments ... misc. past
references
http://www.garlic.com/~lynn/x959.html#x959
part of the activity involved in-depth, end-to-end threat and
vulnerability studies. this including focusing on the types of
problems that have represented the majority of the breaches
reported in the news over the past several years.
There were (at least) two characteristics
1) in the current paradigm, account information, including previous
transaction information, represents diametrically opposing security
requirements. on one side, the information has to be kept completely
confidential and never divulged to anybody. on the other side, the
information has to be readily available for numerous business
processes in order to execute transactions (like presenting/divulging
information at point of sale).
2) the value of the account related information in (merchant)
transaction logs can be 100 times more valuable to the crooks than to
the merchant. Basically to the merchant, the information is worth some
part of the profit off the transaction. To the crook the information
can be worth the credit limit and/or account balance for the related
account. As a result, the crooks may be able to afford to spend 100
times attacking the system as the merchants can afford to spend
(on security) defending the system.
So, one of the parts of x9.59 financial standard was to tweak the
paradigm and eliminate the value of the information to the crooks and
therefor also the necessity to have to hide the information at all (it
didn't do anything to prevent what has been the majority of the
breaches in the past several years ... it just eliminated any of the
fraud that could occur from those breaches ... and therefor any threat
the breach would represent).
misc. past posts mentioning fraud, exploits, threats, vulnerabilities,
and/or risk
http://www.garlic.com/~lynn/subintegrity.html#fruad
the major use of SSL in the world today is this thing we worked on now
comingly referred to as electronic commerce ... lots of past
references to various aspects of SSL
http://www.garlic.com/~lynn/subpubkey.html#sslcerts
where SSL is primarily being used to hide the account and transaction
information. Since x9.59 financial standard eliminates the need to
hide that information (as a countermeasure to fraudulent financial
transactions) .... it not only eliminates the threat from
security/data breaches but also eliminates the major use of SSL in the
world today
some late breaking news:
Researchers say notification laws not lowering ID theft
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9093659
Researchers say notification laws not lowering ID theft
http://www.networkworld.com/news/2008/060508-researchers-say-notification-laws-not.html
Researchers Say Notification Laws Not Lowering ID Theft
http://news.yahoo.com/s/pcworld/146738
Researchers say notification laws not lowering ID theft
http://www.infoworld.com/article/08/06/05/Notification-laws-not-lowering-ID-theft_1.html
Researchers Say Notification Laws Not Lowering ID Theft
http://www.pcworld.com/bu