List of Archived Posts
2005 Newsgroup Postings (3/16 - 4/5)
- [Lit.] Buffer overruns
- [Lit.] Buffer overruns
- [Lit.] Buffer overruns
- Computerworld Article: Dress for Success?
- Thou shalt have no other gods before the ANSI C standard
- He Who Thought He Knew Something About DASD
- He Who Thought He Knew Something About DASD
- Misuse of word "microcode"
- [Lit.] Buffer overruns
- Making History
- He Who Thought He Knew Something About DASD
- He Who Thought He Knew Something About DASD
- Device and channel
- Device and channel
- Misuse of word "microcode"
- Device and channel
- Device and channel
- Where should the type information be?
- Thou shalt have no other gods before the ANSI C standard
- Device and channel
- He Who Thought He Knew Something About DASD
- He Who Thought He Knew Something About DASD
- PKI: the end
- Where should the type information be?
- PKI: the end
- PKI: the end
- PKI: the end
- PKI: the end
- Computerworld Article: Dress for Success?
- Using the Cache to Change the Width of Memory
- Computerworld Article: Dress for Success?
- Public/Private key pair protection on Windows
- Stop Me If You've Heard This One Before
- Stop Me If You've Heard This One Before
- Thou shalt have no other gods before the ANSI C standard
- Thou shalt have no other gods before the ANSI C standard
- Where should the type information be?
- Where should the type information be?
- xml-security vs. native security
- xml-security vs. native security
- xml-security vs. native security
- xml-security vs. native security
- xml-security vs. native security
- Actual difference between RSA public and private keys?
- Using the Cache to Change the Width of Memory
- TLS-certificates and interoperability-issues sendmail/Exchange/postfix
- Using the Cache to Change the Width of Memory
- Using the Cache to Change the Width of Memory
- Mozilla v Firefox
- Mozilla v Firefox
- Mozilla v Firefox
- TLS-certificates and interoperability-issues sendmail/Exchange/postfix
- Where should the type information be?
- System/360; Hardwired vs. Microcoded
- Mozilla v Firefox
- Mozilla v Firefox
- Where should the type information be?
- System/360; Hardwired vs. Microcoded
- Mozilla v Firefox
- System/360; Hardwired vs. Microcoded
- Mozilla v Firefox
- Mozilla v Firefox
- TLS-certificates and interoperability-issues sendmail/Exchange/postfix
- Mozilla v Firefox
- Graphics on the IBM 2260?
- Mozilla v Firefox
- Mozilla v Firefox
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [Lit.] Buffer overruns
Newsgroups: sci.crypt,alt.folklore.computers
Date: Wed, 16 Mar 2005 09:26:07 -0700
CBFalconer writes:
You were on the right track, but late. Unfortunately Bowles & Co.
had done a fouled job of it some time earlier, and Brinch Hansen had
pointed the way, but failed to implement the application (sequential
Pascal) language correctly (at least from the Pascal communities
viewpoint). Too bad.
the los gatos vlsi lab had been using metaware to develop language
technology for a number of things ... customized grammers for some
specialized things ... language for developing design tools,
applications, specialized database technology targeted at integrating
logical and physical design, etc.
the language/compiler was first released to customers as pascal "iup"
(installed user program) and eventually evolved into vs/pascal
(available on both mainframe and aix).
when the language work was somewhat first starting off ... i was also
involved in some of the system/r (original relational/sql) stuff in
bldg. 28
http://www.garlic.com/~lynn/subtopic.html#systemr
as well as some of the bldg.29 (los gatos lab) stuff for doing a
different kind of database for various uses (including attempting to
integrate logical and physical chip design). some of that is the
precusor to the knowledge stuff i currently use for glossaries,
taxonomies and the rfc index:
http://www.garlic.com/~lynn/index.html
reference to metaware's tws manual
http://www.garlic.com/~lynn/2004d.html#71 What terminology reflects the "first" computer language ?
other metaware references:
http://www.garlic.com/~lynn/2000e.html#20 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2002n.html#66 Mainframe Spreadsheets - 1980's History
http://www.garlic.com/~lynn/2002q.html#19 Beyond 8+3
http://www.garlic.com/~lynn/2003h.html#52 Question about Unix "heritage"
http://www.garlic.com/~lynn/2004f.html#42 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004n.html#30 First single chip 32-bit microprocessor
http://www.garlic.com/~lynn/2004q.html#35 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2004q.html#38 CAS and LL/SC
http://www.garlic.com/~lynn/2004q.html#39 CAS and LL/SC
http://www.garlic.com/~lynn/2004q.html#61 will there every be another commerically signficant new ISA?
http://www.garlic.com/~lynn/2005b.html#14 something like a CTC on a PC
other vs/pascal refs:
http://www.garlic.com/~lynn/99.html#36 why is there an "@" key?
http://www.garlic.com/~lynn/2000.html#15 Computer of the century
http://www.garlic.com/~lynn/2002d.html#18 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2002q.html#27 Beyond 8+3
http://www.garlic.com/~lynn/2003b.html#33 dasd full cylinder transfer (long post warning)
http://www.garlic.com/~lynn/2003b.html#44 filesystem structure, was tape format (long post)
http://www.garlic.com/~lynn/2003c.html#77 COMTEN- IBM networking boxes
http://www.garlic.com/~lynn/2003k.html#26 Microkernels are not "all or nothing". Re: Multics Concepts For
http://www.garlic.com/~lynn/2003k.html#63 SPXTAPE status from REXX
http://www.garlic.com/~lynn/2003o.html#16 When nerds were nerds
http://www.garlic.com/~lynn/2003o.html#21 TSO alternative
http://www.garlic.com/~lynn/2004c.html#25 More complex operations now a better choice?
http://www.garlic.com/~lynn/2004d.html#41 REXX still going strong after 25 years
http://www.garlic.com/~lynn/2004g.html#19 HERCULES
http://www.garlic.com/~lynn/2004g.html#27 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004k.html#34 August 23, 1957
http://www.garlic.com/~lynn/2004m.html#33 Shipwrecks
http://www.garlic.com/~lynn/2004q.html#33 Listserv for TCPIP
http://www.garlic.com/~lynn/2005.html#51 something like a CTC on a PC
http://www.garlic.com/~lynn/2005b.html#20 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005b.html#63 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005b.html#65 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005d.html#11 Cerf and Kahn receive Turing award
http://www.garlic.com/~lynn/2005d.html#30 The Mainframe and its future.. or furniture
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [Lit.] Buffer overruns
Newsgroups: sci.crypt,alt.folklore.computers
Date: Wed, 16 Mar 2005 12:17:41 -0700
Anne & Lynn Wheeler writes:
i had put together a proposal in the 82/83 time-frame to address
most of these issues ... but it became involved in large corporation
politics and got way too much attention and one characterization
would be that it reached (blackhole) critical mass and
imploded. there was some study of various (portable?) languages that
could be used for operating system implementation and their
associated integrity characteristics. I did a couple demos of taking
existing kernel components (implemented in assembler) and
redesigning and recoding them from scratch in (enhanced) pascal.
reference to an internal conference i held at research in march
of '82 on the theme
http://www.garlic.com/~lynn/96.html#4a John Hartmann's Birthday Party
there is also mention of review that was held for a proposal by some
people in the valley for the corporation to build some of these new
workstation machines. there were a number of internal groups that were
claiming they were already doing something better, so the offer was
declined, and people making the proposal had to go off and do their
own startup (three letters, 1st is an S).
minor bibliography from one of the documents later in '83:
The C Programming Language, Kernighan and Ritchie, Prentice-Hall, 1978
A comparison of Language C and Pascal, Allen xxxxxxxx, IBM Cambridge
Scientific Center, G320-2128, Aug. 1979
A comparison of Modula-2 and Pascal/VS, A. xxxxxxxx, IBM Palo Alto
Scientific Center, March 1983
Comparison of Various Pascals, Internal IBM document, Diane xxxxxxxx,
21G/032, Boca Raton, Sept. 1982
Computer-Mediated Communication Systems, Kerr and Hiltz, Academic
Press, 1982
A Dump Reader (DR/I), Internal IBM document, Marc xxxxxx,
YKTVMV/xxxxxx
The Evolution of User Behavior in a Computerized Conferencing System,
Hiltz and Turoff, Comm. of ACM, Nov. 1981
FAPL Language Manual, Internal IBM Document, David xxxxxxxx, Research
Triangle Park, Raleigh, Dec. 1982
Introduction To The PL.8 Language, Internal IBM document, Martin
xxxxxxxx, YKTVMX/xxxxxxxx, May, 1979
MetaWare(tm) TWS User's Manual, Franklin L. DeRemer, Thomas
J. Pennello, Santa Cruz
The Network Nation -- Human Communication via Computer, Hiltz and
Turoff, Addison-Wesley, 1978
Invitation to ADA & ADA Refernce Manual, Harry Katzan, Jr., Petrocelli
Books, July 1980
The LSRAD Report, SHARE Inc., December 1979
Modula-2, Niklaus Wirth, Springer-Verlag, 1982.
Organic Design for Command and Control, Col. John Boyd (ret), talk
given in May, 1983 at IBM Los Gatos Lab.
Paltry, Internal IBM computer conference system, Ron xxxxxxxx,
YKTVMV/xxxxxxxx
Pascal/VS Language Reference Manual, IBM Corp. SH20-6168, April 1981
Pascal/VS Programmer's Guide, IBM Corp. SH20-6162, April 1981
Pascal User Manual and Report, Jensen and Wirth, Springer-Verlag, 1974
PL/S III Language Reference Manual, IBM Corp. ZZ28-7001, March 1980
Program Verification using ADA, A.D. McGettrick, Cambridge University
Press, 1982
Programming Language/Advanced Systems (PLAS) Specification,
T. xxxxxxxx, IBM PL/AS Development, January 1983.
Proving Concurrent Systems Correct, Richard Karp, Stanford
Verification Group Report No. 14, November 1979.
REX Reference Manual, Internal IBM document, Mike xxxxxxxx,
VENTA/xxxxxxxx.
SCOPE 3.1.2 Reference Manual, Control Data Corporation, 60189400,
Oct. 1968
Smalltalk-80 - The Language and its Implementation, Goldberg and
Robson, Addison-Wesley, 1983
Software Engineering Notes, ACM SIGSOFT, Vol 6, no. 4, August 1981
Source Level Debug User's Guide, Internal IBM Document, xxxxxxxx, et
al. (PLKSB/xxxxxxxx), Jan. 1983
Stanford Pascal Verifier User Manual, Stanford Verification Group
Report No. 11, March 1979.
STL-Debugging-Tool User Manual, xxxxxxxx & xxxxxxxx, IBM internal
document, 1982
System Product Editor, Command and Macro Reference, IBM Corp.
SC24-5221, March 1982
Systems Inventory Manager, Bob xxxxxxxx, IBM San Jose GPD TR03.038,
August 1977.
Theory of Compiler Specification and Verification, Wolfgang Polak,
Stanford Program Verification Group Report No. 17, May 1980.
TSS Time Sharing Support System PLM, IBM Corp. GY28-2022, Sept. 1971.
Trends in the Design and Implementation of Programming Languages,
William Wulf, Computer, January 1980.
VM/Interactive Problem Control System Extension, IBM Corp. SC34-2020,
Sept. 1979.
Why Pascal is Not My Favorite Programming Language, Bruce Kernighan,
Bell Laboratories, Computer Science Report No. 100,
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [Lit.] Buffer overruns
Newsgroups: sci.crypt,alt.folklore.computers
Date: Wed, 16 Mar 2005 12:32:03 -0700
Anne & Lynn Wheeler writes:
Organic Design for Command and Control, Col. John Boyd (ret), talk
given in May, 1983 at IBM Los Gatos Lab.
and, of course, some of postings mentioning john boyd
http://www.garlic.com/~lynn/subboyd.html#boyd
and various other web pages that also mention boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computerworld Article: Dress for Success?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 17 Mar 2005 08:55:42 -0700
dnobles@ibm-main.lst (David Nobles) writes:
There was an article in the Washington Post a couple of years ago
where the author stated you could correlate the decline of the US
with the decline in dress standards. In essence, that sloppy dress
= sloppy attitudes = sloppy work ethics.
I personally tend to fall between the author and Bob. I definitely
prefer casual dress, live with business casual on most sites but
agree there are times to dress up and not just for interviews.
Regardless of my views I need to take in account those of my
intended audience.
similar assertions of been made regarding language use.
note, however, both dress and language use have tended to be
correlated with high degree of team-related compatibility,
interaction, uniformity, etc.
one of boyd's themes in the early 80s
http://www.garlic.com/~lynn/subboyd.html#boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2
was significant amount of the american corporate culture was heavily
influenced by organization structure and training from ww2
(significant percentage of corporate executives having gotten their
early training in large organization management during ww2).
The issue at the start of ww2 was that there was a huge and rapid
build-up in personnel but there were few numbers with significant
experience. this led to trying to create a rigidly top-down control
structure ... attempting to create uniform, interchangeable units (at
the low level because of their lack of experience) that operated in
unison under direction of the few individuals available with any
experience.
Boyd contrasted this with guderian's orders for the blitzkrieg which
were directed at giving the people on the spot the greatest
independent (tactical) autonomyy and decision latitude. the contrast
was that guderian's forces were supposedly had much more experience in
their craft. One of points that Boyd used in support of his thesis was
that the german army was something like 3 percent officers compared to
something like 15-17 percent officers in the american army. The claim
was that the significantly larger percent of officers was necessary in
order to maintain the ridid, top-down, heavily structured control
operation. Part of this was the theme of Boyd's talk on Organic Design
for Command and Control.
In any case, the large organization management command and control at
the start of WW2 was specifically oriented towards operations
involving large number of people that had no experience at what they
were doing ... and therefor it was necessary to have the minimum
amount of local autonomy and maximum amount of uniformity and
top-down, rigid, structured control.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Thou shalt have no other gods before the ANSI C standard
Newsgroups: sci.crypt,alt.folklore.computers
Date: Thu, 17 Mar 2005 10:03:08 -0700
"Hank Oredson" writes:
At one place I worked they really really wanted me to have the title
"Senior Computer Scientist". Didn't argue with them, the culture
needed that title to explain what it was that I was expected to
do. There was little "science" involved in what I did, and quite a
lot of cat herding. A better title would have been "Cat Herder" or
"Advisor to the Less Senior Peons". At a couple other places I did
essentially the same work but was called "Principal Application
Analyst" and "Senior Member of the Technical Staff". That last one
seemed to make sense, since I was over 50 and not doing managment at
the time :-)
for most of my career, i managed to get by with no title on my
business card (although it was one of the first business cards to have
an email address) or at most 'staff member'. for a time, i worked for
somebody that the ceo had box of business cards made up for him that
had a title of corporate gadfly.
we were once on a business trip overseas visiting a company/culture
that was very sensitive to rank and had carefully orchistrated seating
on both sides of a long table. after the morning coffee break, he
switches seats with me (which places me opposite their ceo).
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: He Who Thought He Knew Something About DASD
Newsgroups: bit.listserv.ibm-main
Date: Fri, 18 Mar 2005 08:25:11 -0700
shmuel+ibm-main@ibm-main.lst (Shmuel Metz , Seymour J.) writes:
1. DASD need not be disk, and some, e.g., 2301, 2321, have not been.
I suspect that eventually nonrotating DASD will displace disks.
2. I'd be worried if drives were failing frequently, even if the
failures were nondisruptive.
3. These days people have huge DASD farms, so even with higher
reliability I'd expect them to see more failures unless the
reliability improvements keep pace with the growth.
in the early 80s, there was a 1655 (sjr/bldg. 28 had a couple, they
were from another vendor) ... which emulated 2305 fixed-head ... and
was nonrotating ... dram, volitile, so primarily targeted as paging
device.
the story i was told was that they were dram that had failed normal
memory acceptance tests in various ways ... but were suitable for use
as an i/o device using various compensating processes by the i/o
device controller.
a couple years ago, the mtbf failure numbers i saw for commodity
drives had gone from tens of thousands of hrs to nearing a million
hrs. some number of vendors then started packaging raid arrays of such
devices ... so even such failures were masked.
numerous past dasd related posts:
http://www.garlic.com/~lynn/subtopic.html#dasd
misc. post about work with the dasd engineering lab (bldg. 14)
and dasd product test lab (bldg. 15)
http://www.garlic.com/~lynn/subtopic.html#disk
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: He Who Thought He Knew Something About DASD
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 18 Mar 2005 08:48:34 -0700
Anne & Lynn Wheeler writes:
a couple years ago, the mtbf failure numbers i saw for commodity
drives had gone from tens of thousands of hrs to nearing a million
hrs. some number of vendors then started packaging raid arrays of such
devices ... so even such failures were masked.
... aka improved by a factor of 10-20 times ... however you have
some configurations where the number of drives have gone up by
a hundred times.
for some topic drift, there typically is an assumption with raid that
the variance/distribution in mtbf is at least some minimum value
.... you hopefully don't have specific failure modes that once one
drive fails there is a high probability that you will have other drive
failures within a short period of time (in the past there has been
specific cases where that has been known to happen). even if the mtbf
is a million hrs ... raid would still have a problem if there is a
failure mode that clusters a large number of drive failures at exactly
a million hrs.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Misuse of word "microcode"
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 18 Mar 2005 09:02:21 -0700
Roger Ivie writes:
You missed it. He was pointing out that in current AS/400 systems, the
microcode is executed by a PowerPC.
which is what the fort knox and other projects from 1980 were going to
do ... the objective was to take the myriad of corporate
microprocessors and transition them all to 801 (controllers, devices,
low-end 370s, etc). in some sense, the whole power thing was an
outgrowth of that. romp was originally targeted as the processor for
an opd displaywriter follow-on. when that project got killed, it was
decided to retarget the platform to the unix workstation market. they
hired the company that had done the at&t unix port for the pc (pc/ix)
to do one for romp ... which was then announced as pc/rt and aix.
rios/power chips were the followon for pc/rt (romp).
somerset was then a spawned to do single chip 801/powerpc ... that
also did things like change some amount of the cache semantics to
support cache coherency in smp shared-memory configurations (aka
rios/power cache semantics were strictly non-cache coherent).
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [Lit.] Buffer overruns
Newsgroups: sci.crypt,alt.folklore.computers
Date: Fri, 18 Mar 2005 10:44:54 -0700
Lawrence Statton N1GAK/XE2 writes:
I respectfully disagree.
I think that is an over-generalization.
It has nothing to do with whether the customers are internal or
external, or whether there is money involved, but the variance among
the customer needs, and the organizations' dedication to the
product.
As to the "make any money" part: Some organizations, including the
one I work for, *do* apportion the cost of internal software across
the various departments. While it all comes out of the same pie at
the top of the organization, if the operations people want the
engineering group to implement some special feature, they will have
to allocate some fraction of this year's budget to that feature, and
will have to consume so many fewer paper clips, or whatever other
cutbacks they need.
lots of organization have oscillated between the two spectrums
.... in-house operations required to provide significant competitive
advantage to various business units as opposed to being a distraction
from the core business focus and don't provide sufficient competitive
advantage to justify the distraction. this extends all the way down to
there being a signficant culture clash between the core business
people and people in various in-house services. in addition, numerous
corporate cultures feel more at ease with contractual relationships
(with things like penalties) which can be a major problem when dealing
with internal organizations.
purely internal operations have typically been viewed as cost centers
and it has been frequently difficult for them to demonstrate return on
investment. this is behind a great deal of the outsourcing that
periodically goes on.
i got involved in a different approach back as an undergraduate.
boeing was spinning off much of their dataprocessing into BCS ... to
operate as an independent business operation ... being able to market
to both "internal" customers as well as "external". spring break i was
conned into giving one week class to the initial bcs technical staff
(bcs was still getting off the ground and was still working on
absorbing/digesting existing datacenters).
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Making History
Newsgroups: alt.folklore.computers
Date: Fri, 18 Mar 2005 10:56:32 -0700
some possibly archeological interest; Making History
http://www.ibmsystemsmag.com/mainframe/marchapril05/stoprun/10020p1.aspx
part of the above refers to lots of postings in this newsgroup.
there is slight misprint ... I joined CSC (as in cambridge science
center as opposed to any other CSC) ... before transfering to SJR
after seven years.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: He Who Thought He Knew Something About DASD
Newsgroups: bit.listserv.ibm-main
Date: Fri, 18 Mar 2005 12:15:01 -0700
ptduffy042@ibm-main.lst (Peter Duffy) writes:
Are you refering to situations with RAID5? As I understand how
RAID5 works one disk isn't useful in recovering anything.
frequently you have N+1 drives in RAID5 (for no single point of
failure ... any single failed disk can be reconstructure from the N
remaining disks) ... there have also been things like 32+8 raid disk
configurations for more robust levels of recovery.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: He Who Thought He Knew Something About DASD
Newsgroups: bit.listserv.ibm-main
Date: Fri, 18 Mar 2005 12:31:44 -0700
ptduffy042@ibm-main.lst (Peter Duffy) writes:
Are you refering to situations with RAID5? As I understand how
RAID5 works one disk isn't useful in recovering anything.
the issue is like some of those crime shows where the police recover
segment fragments and garner interesting pieces of information from
the fragments ... there is no intention of implying that a production
system/volume could be reconstructed from a single drive.
RAID5 is a variation on the N+M ... frequently N+1. In the dedicated
parity drive(s) configuration ... the parity drive(s) doesn't get
accessed except for writes and failures. RAID5 rotates the records
around so that parity records are spread across all drives. In a
transaction oriented system where individual transaction records can
be 1/N of a block ... then all transaction traffic can be spread
across N+M arms ... as opposed to just N arms ... and individual arms
independently scheduled for transaction read traffic.
transaction writes in raid5 can be a little more complicated. a
typical scenario is to first read both the individual transaction
record to be replaced and the parity record for that block. the parity
record is then recomputed w/o the contents of the record being
replaced ... and then recomputed again with the contents of the
new/replaced record. then both the new record and the parity record
are written (to their respective disks). of course when you are
replacing all N records in a raid5 block ... then it is possible to
directly compute the new M parity records and then perform the N+M
writes w/o first having to do any reads.
all of this is further complicated by possible failure scenarios where
there is something like a power failure ... and some subset of the
records have been written but not all. special procedures are
necessary for recovery for partial writes caused by various types of
interruptions.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Device and channel
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 18 Mar 2005 13:49:41 -0700
ronhawkins@ibm-main.lst (Ron and Jenny Hawkins) writes:
ESCON runs at 200Mb/sec which translates to 20MB/sec. The standards
definition of FCP is very strict, with rates defined at 1Gb, 2Gb,
4Gb and soon 10Gb. This is not advertising, it is how FCP is defined
and is the common usage in the industry - no one buys a 200MB/sec
HBA or a 100MB/sec switch - they buy 1Gb or 2Gb.
Interesting enough, the Gb in this case is binary, meaning
1073741824 bits/sec. FCP also uses a 10 bit byte, which means it is
a 107MB/sec, 215MB/sec or 429MB/sec protocol. Using 100, 200 and
400MB/sec is simply rounding and does not represent the full frame
rate.
escon was also half-duplex (maintain compatibility with bus&tag?) and
frequently is rated at 17mbytes/sec (aggregate) ... the half-duplex
characteristic then also made effective thruput sensitive to distance
latency.
escon had been laying around pok for quite a while before it got out
(some of it possibly dating back to when my wife did her stint in POK
in charge of loosely-coupled architecture).
one of the austin engineers had taken much of the escon spec, turned
it into full-duplex, up'ed its thruput by about 10% to 220mbits/sec,
and converted to much less expensive optical drivers. this was
available as "SLA" (or serial link adapter) on original rs/6000.
then he started work on upgrading it to 800mbits/sec. at that time my
wife and i had been doing some stuff with LLNL with respect to their
filesystem in conjunction with cluster operation
http://www.garlic.com/~lynn/subtopic.html#hacmp
which eventually became a product called unitree (we also spent some
time with ncar on mesa archival and some number of other locations
that had developed cluster environment filesystem support).
in that time-frame LANL was doing work to standardize cray channel as
HiPPI, LLNL was trying to standardize some serial-copper technology
they were involved in as fiber channel standard, and slac was backing
fiber SCI (scalable coherent interface).
we helped convince the SLA engineer to give up the 800mbits/sec SLA
and go to work on FCS standards commitee ... where he quickly became
the editor of the FCS standards document. FCS started out being 1gbit
full-duplex (simultaneous in each direction, 2gbit aggregate, as
compared to escon's 200mbit half-duplex).
full-duplex operation not only provided twice the aggregate thruput
(compared to half-duplex operation), but most of the full-duplex
protocols also involved asynchronous operation ... which significantly
mitigated any long-haul latency that might be involved in some FCS
deployments.
later some number of POK channel engineers become involved in the FCS
standards effort and there was lots of contention (mailing list as
well as meetings) were they were attempting to map traditional IBM
half-duplex device I/O operation on top of native asynchronous
operational environment (for one thing, state that was expected is be
preserved in an half-duplex environment is prone to being reset in a
full-duplex, asynchronous environment).
total SLA business trivia ... we had an interesting business problem
with SLA ... trying to convince other vendors to incorporate SLA
hardware into their products (and allow interoperability with
rs/6000). Turns out that there is an internal business process between
locations about transfer of pieces (in this case the SLA chips) that
resulted in an N-times cost multiplier.
Unfortunately from the plant producing the SLA chip to outside vendors
there was three internal location transfers ... with each location
following the internal business process transfer rules which resulted
in a 3*N-cost multipler for SLA chips to outside companies.
random past posts mention escon, ficon, fcs, sci, hippi, etc:
http://www.garlic.com/~lynn/96.html#5 360 "channels" and "multiplexers"?
http://www.garlic.com/~lynn/96.html#15 tcp/ip
http://www.garlic.com/~lynn/97.html#5 360/44 (was Re: IBM 1130 (was Re: IBM 7090--used for business or
http://www.garlic.com/~lynn/98.html#30 Drive letters
http://www.garlic.com/~lynn/98.html#40 Comparison Cluster vs SMP?
http://www.garlic.com/~lynn/98.html#49 Edsger Dijkstra: the blackest week of his professional life
http://www.garlic.com/~lynn/99.html#54 Fault Tolerance
http://www.garlic.com/~lynn/2000c.html#22 Cache coherence [was Re: TF-1]
http://www.garlic.com/~lynn/2000c.html#56 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#59 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#68 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000d.html#14 FW: RS6000 vs IBM Mainframe
http://www.garlic.com/~lynn/2000f.html#31 OT?
http://www.garlic.com/~lynn/2001c.html#69 Wheeler and Wheeler
http://www.garlic.com/~lynn/2001e.html#22 High Level Language Systems was Re: computer books/authors (Re: FA:
http://www.garlic.com/~lynn/2001.html#12 Small IBM shops
http://www.garlic.com/~lynn/2001.html#18 Disk caching and file systems. Disk history...people forget
http://www.garlic.com/~lynn/2001.html#46 Small IBM shops
http://www.garlic.com/~lynn/2001j.html#17 I hate Compaq
http://www.garlic.com/~lynn/2001j.html#23 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001k.html#5 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001k.html#22 ESCON Channel Limits
http://www.garlic.com/~lynn/2001l.html#14 mainframe question
http://www.garlic.com/~lynn/2001m.html#25 ESCON Data Transfer Rate
http://www.garlic.com/~lynn/2001m.html#56 Contiguous file system
http://www.garlic.com/~lynn/2002d.html#7 IBM Mainframe at home
http://www.garlic.com/~lynn/2002e.html#5 What goes into a 3090?
http://www.garlic.com/~lynn/2002e.html#7 Bus & Tag, possible length/distance?
http://www.garlic.com/~lynn/2002e.html#26 Crazy idea: has it been done?
http://www.garlic.com/~lynn/2002e.html#31 Hardest Mistake in Comp Arch to Fix
http://www.garlic.com/~lynn/2002e.html#32 What goes into a 3090?
http://www.garlic.com/~lynn/2002f.html#6 Blade architectures
http://www.garlic.com/~lynn/2002f.html#7 Blade architectures
http://www.garlic.com/~lynn/2002f.html#11 Blade architectures
http://www.garlic.com/~lynn/2002f.html#60 Mainframes and "mini-computers"
http://www.garlic.com/~lynn/2002g.html#33 ESCON Distance Limitations - Why ?
http://www.garlic.com/~lynn/2002h.html#78 Q: Is there any interest for vintage Byte Magazines from 1983
http://www.garlic.com/~lynn/2002.html#10 index searching
http://www.garlic.com/~lynn/2002j.html#30 Weird
http://www.garlic.com/~lynn/2002j.html#78 Future interconnects
http://www.garlic.com/~lynn/2002k.html#42 MVS 3.8J and NJE via CTC
http://www.garlic.com/~lynn/2002l.html#13 notwork
http://www.garlic.com/~lynn/2002m.html#20 A new e-commerce security proposal
http://www.garlic.com/~lynn/2002m.html#73 VLSI and "the real world"
http://www.garlic.com/~lynn/2002n.html#50 EXCP
http://www.garlic.com/~lynn/2002o.html#11 Home mainframes
http://www.garlic.com/~lynn/2002q.html#40 ibm time machine in new york times?
http://www.garlic.com/~lynn/2003b.html#29 360/370 disk drives
http://www.garlic.com/~lynn/2003d.html#37 Why only 24 bits on S/360?
http://www.garlic.com/~lynn/2003d.html#57 Another light on the map going out
http://www.garlic.com/~lynn/2003h.html#0 Escon vs Ficon Cost
http://www.garlic.com/~lynn/2003h.html#3 Calculations involing very large decimals
http://www.garlic.com/~lynn/2003j.html#2 Fix the shuttle or fly it unmanned
http://www.garlic.com/~lynn/2003m.html#20 360 Microde Floating Point Fix
http://www.garlic.com/~lynn/2003o.html#54 An entirely new proprietary hardware strategy
http://www.garlic.com/~lynn/2003o.html#64 1teraflops cell processor possible?
http://www.garlic.com/~lynn/2004d.html#6 Memory Affinity
http://www.garlic.com/~lynn/2004d.html#68 bits, bytes, half-duplex, dual-simplex, etc
http://www.garlic.com/~lynn/2004h.html#29 BLKSIZE question
http://www.garlic.com/~lynn/2004j.html#19 Wars against bad things
http://www.garlic.com/~lynn/2004n.html#45 Shipwrecks
http://www.garlic.com/~lynn/2004p.html#29 FW: Is FICON good enough, or is it the only choice we get?
http://www.garlic.com/~lynn/2005d.html#20 shared memory programming on distributed memory model?
http://www.garlic.com/~lynn/2005.html#38 something like a CTC on a PC
http://www.garlic.com/~lynn/2005.html#50 something like a CTC on a PC
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Device and channel
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 18 Mar 2005 18:55:13 -0700
bblack@ibm-main.lst (Bruce Black) writes:
On FICON, all the CCWs in a chain are sent to the control unit in
one frame (very long CCW chains can be sent in multiple frames, but
that is unusual). Then the data blocks for each CCW are sent or
received. So the channel protocol is quite different and not just
sending the ESCON protocol over FCP. I suppose it would be more
accurate to say that FICON is "CCWs over FCP", where CCWs are the
channel protocol used since S/360 days. --
note that the ficon description is nearly identical to the
HYPERChannel remote device adapters (A51x) boxes starting around 1980
or so.
when a couple hundred people from the IMS group in STL/bldg90 were
remoted to a bldg about 10miles away ... they looked at the
performance of remote 3270s ... and decided to go with HYPERChannel
and "local" 3270s instead. I got to write the device driver to
download the CCWs into the memory of the A51x boxes ... which had
loads of attach (local) 3270 controllers.
the configuration had HYPERChannel A220s on the local mainframe
channels and then pairs of HYPERChannel A71x boxes with T1 (1.5mbit)
link and finally some number of A51x boxes at the remote site.
The people that were remoted didn't see any observable 3270 response
characteristics between real local 3270s and HYPERChannel local 3270s
(over T1 link). However, there was a side benefit ... getting the
local 3274s off the local mainframe channels and replacing them with
HYPERChannel A22x adapters improved overall system thruput about
10-15%. It turns out that the HYPERChannel A22x had significantly
lower channel busy time (for the same operation) than did real 3274
controllers directly attached to mainframe channels (getting the real
3274s directly off the mainframe channels significantly lowered
channel busy time for doing 327x operations and improved overall
system thruput).
There was a problem tho using A510 boxes for disk operations because
of the timing dependeing nature of doing search-id/tic operations.
Finally NSC came out with the HYPERChannel A515 channel adapter box
that was used by NCAR for their cluster filesystems. They sort of used
the IBM mainframe as a hierarchical filesystem controller. Various
supercomputers on the HYPERChannel network could make a request for
some data. The ibm mainframe would stage the data to disk (if no
already) and then download the dasd channel program into the memory of
an HYPERChannel A515 box ... and then return a pointer to the channel
program. The supercomputer would address the specific A515 invoking
the specified channel program ... resulting in the data read/writes
being directly between the supercomputer memory and DASD (w/o having
to pass thru the memory of the ibm mainframe).
numerous past posts on HYPERChannel, HSDT, etc.
http://www.garlic.com/~lynn/subnetwork.html#hsdt
for some topic drift ... the original mainframe tcp/ip support could
consume a full 3090 cpu getting about 44kbytes/sec thruput. I added
RFC1044 (NSC adapter) support to tcp/ip and in tuning at cray research
was getting 1mbyte/sec sustained between a cray and a 4341-clone
(using only a modest amount of the 4341).
misc rfc1044 posts
http://www.garlic.com/~lynn/subnetwork.html#1044
some other random HYPERChannel drift ... for original HYPERChannel
driver i had done for STL/bld.90 ... if there was an error that couldn't
recover within the driver ... a channel check i/o interrupt was
simulated. some years later ... something like a year after 3090 first
customer ship ... some ras guy from pok tracked me down. turns out the
industry erep reporting service was showing something like five times
the expected number of channel checks for customer 3090 operation. It
turned out they had tracked it down to some small number of
HYPERChannel drivers simulating channel checks (for things like
unrecoverable HYPERChannel channel extender over telco T1 links). The
point in simulating channel check was to kick off various operating
system retry operations. After some analysis, I determined that
simulating IFCC (interface control check) instead of channel check
would result in effectively the same retry operations.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Misuse of word "microcode"
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 18 Mar 2005 19:13:19 -0700
"del cecchi" writes:
Gee, you didn't mention the other fiascos, like workplace os and pink.
Or Bach and Beethoven. Ahh the lies that were told, the foils that were
pitched.
Gee my old lasalle ran great. Those were the days.
they've created a reputation for me to uphold
http://www.ibmsystemsmag.com/mainframe/marchapril05/stoprun/10020p1.aspx
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Device and channel
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 19 Mar 2005 08:02:08 -0700
cruff@ruffspot.net () writes:
The NCAR Mass Storage System (MSS) is an archive server abused by
being treated as a shared file system server. The mainframe (now an
used early model z/8xx something, I can't ever remember the model
number even though I walk past it several times a week) runs the
PL/1 software that manages the operation of the system. The user
submits a request to a local daemon, which contacts the management
software on OS/390 (we've not quite gotten to z/OS yet). The
management software mounts a tape if necessary, allocates data path
resources and gives the location of the data on the device
(disk/tape) to the daemon on the user's system, which then manages
the transfer by directly building the CCW programs on the remote
system and driving the storage device directly.
i think it was the early 80s that had some fed. gov. legislation pass
regarding technology re-use and commercialization ... trying to
promote technology transfer into the commercial sector (some of the
early internet commercialization may have benefited from such
legislative action).
llnl lincs -> unitree was another such effort ... we contributed some
of the funding and support for that activity.
another was ncar's mesa archival (attempted?) spin-off ... which we
also spent some amount of time with. some place we may have some of
their old market studies and business plan. big part of mesa archival
effort was porting the mainframe code to a unix platform.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Device and channel
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 19 Mar 2005 08:15:15 -0700
Anne & Lynn Wheeler writes:
llnl lincs -> unitree was another such effort ... we contributed some
of the funding and support for that activity.
another was ncar's mesa archival (attempted?) spin-off ... which we
also spent some amount of time with. some place we may have some of
their old market studies and business plan. big part of mesa archival
effort was porting the mainframe code to a unix platform.
and sort of the first spin-off in this genre was LANL's. they had a
similar ibm mainframe as a dasd/tape controller serving supercomputers
which general atomics was marketing as datatree ... which then
somewhat led to the choice of unitree (aka unix) name for llnl's
lincs.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Where should the type information be?
Newsgroups: comp.arch.arithmetic,comp.arch,alt.folklore.computers
Date: Sat, 19 Mar 2005 10:25:05 -0700
"Edward A. Feustel" writes:
I agree with you that many of the problems associated with computers
and debugging might be eliminated if data was either described by
descriptors or typed with tags, or both. I wrote a paper in 1973:
E.A. Feustel, "On the Advantages of Tagged Architectures",
I.E.E.E. Transactions on Computers, Vol. 22, pp. 644-652(Jul 73).
In which I advanced a number of arguments for doing this and for
providing "Self-Describing Data". Note that XML seems to have taken
up this idea for data to be transferred between machines.
fs (future system) was an effort that was targeted at all sorts of
complex hardware descriptors ... there was some analysis that the
worst case could have five levels of indirection (in the hardware) for
each argument. one of the nails in the fs coffin was some analysis
that if you took the highest performance technology available at the
time from 195s for building an FS machine, the resulting application
thruput would be about that of 370/145 (possibly 10:1 or 20:1
slow-down). in any case, fs was killed before even being announced
or publicized. specific refs:
http://www.garlic.com/~lynn/2000f.html#16 FS - IBM Future System
misc. other references
http://www.garlic.com/~lynn/subtopic.html#futuresys
to some extent, the start of 801/risc effort in the 70s was born to
try and do the exact opposite of the FS effort ... and all complexity
was moved to the (PL.8) compiler. misc. past 801
http://www.garlic.com/~lynn/subtopic.html#801
the precursor to XML was SGML
http://www.garlic.com/~lynn/subtopic.html#sgml
and before that was GML which was invented at the science center
in 1969:
http://www.garlic.com/~lynn/subtopic.html#545tech
g, m, & l are the last name initials of three of the people at the
science center ... but officially was "generalized markup language"
... and an implementation was added to the cms "script" command for
document formating (script had originally started off with dot-command
formating controls) ... and gml allowed the separtion/independence of
the specification of the document components from the specification of
the formating of those compoents ... and some applications started
using the specification of the document components for things other
than formating. however there were other efforts at the science center
along the lines of self-describing data ... one involved years of 7x24
performance monitoring data.
total trivia, the w3c offices are now only a couple blocks from the
old science center location at 545 tech sq.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Thou shalt have no other gods before the ANSI C standard
Newsgroups: sci.crypt,alt.folklore.computers
Date: Sat, 19 Mar 2005 13:18:22 -0700
CBFalconer writes:
Sixty plus years ago I learned not to take a healthy swing at a nail
held between thumb and forefinger. This involved various noises,
applications of cold water, etc. Today I cannot possibly remember
any of the specific instances, but I do retain the lesson reasonably
well. Since you distrust this mechanism, please go forth, grasp a
nail firmly with the left hand, raise a hammer high and smash the
nail into place with at most two blows.
in my youth i did learn to tap/slam an 8penny box ... it took a little
longer to get to the point where i could tap/slam a 16penny common
(20oz instead of 16oz hammer helped some).
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Device and channel
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 19 Mar 2005 16:52:05 -0700
cruff@ruffspot.net () writes:
Apparently Mesa Archival had a very short life. The NCAR side of the
spin off happened just before I started to work there. It was part
of the commercialization of federally funded creations. They (Mesa)
may have had one customer, but I don't recall if they ever delivered
any successful product. Of course, that could all be wrong too, as
I only have second hand commentary to go by. I did recently need to
recycle a bunch of old green bar printouts of very early MSS code that
had been used in support of the spinoff activities.
At NCAR we are still in the progress of slowly evolving the MSS by
migrating the OS/390 resident PL/1 functionallity to C/C++ code on
POSIX systems. The next large piece being migrated is the
ISAM-resident Master File Directory (MFD) and associated code, which
is being retargeted to use DB2 running on Unix. The idea is to be
able to run on a wide variety of hardware with POSIX compatible
operating environments so that the archived data is not stranded if
vendors go out of business.
well it is now been over 15 years since mesa archival was going to
port the code from mvs to a unix platform.
some meetings and discussions with people at Mesa Archival had occured
in '88
middle layer was what we started out calling what became 3layer
architecture, misc. refs
http://www.garlic.com/~lynn/subnetwork.html#3tier
minor ref.
http://www.garlic.com/~lynn/99.html#201 Middleware - where did that come from?
http://www.garlic.com/~lynn/99.html#202 Middleware - where did that come from?
http://www.garlic.com/~lynn/96.html#16 middle layer
http://www.garlic.com/~lynn/96.html#17 middle layer
and from long ago and far away ...
From: wheeler
Date: Wed, 8 Mar 1989 09:16:22 PST
To: xxxxxxxx
xxxxxxxx, I'm planning on being on the east coast the 1st 2-3 days of next
week. On monday we have a NSF meeting. We then will be giving the
middle layer software and hardware pitch to several people. We are
also looking to meet with xxxxxx (xxxxxx's assistant) to follow-up
on details of the middle layer/"file server" presentation.
We are also looking to meet with xxxxxx (who is on the ES file server
task force) to at least provide some degree of coordination.
The original intention was to spend the rest of the week in San Jose
on the gpd/awd "system" file server task force (which is going to run
somewhat in parallel with the GPD dasd task force that is currently
going on). However, we now find that most of those (gpd) people will
be on the east coast for the week on some (other) ES task force.
Because of the ES task force, we are now attempting to get xxxxxx's
schedule set-up for a visit to Seattle so we can finally follow-up on
the xxxxxx software for the middle layer strategy. While we are in
Seattle, we have requests to meet with both Boeing's SCI group (super
computer intergration) and some people in BCS (which we would
follow-up on). This is assuming that we can get it coordinated with
xxxxxx.
The week following next (3/20th) will probably be spent all week in
San Jose covering both the DASD taskforce as well as the fileserver
taskforce. I'm hoping to get Almaden server people involved in this as
well as getting the total middle layer strategy on the table for
investigating areas of mutual interest.
In conjunction with both the middle layer strategy and high-speed
interconnect we also have pending requests for follow-up meetings with
SLAC (on the SLAC/FERMI/CERN connection) and Los Alamos (on the
Mesa/archival and middle layer subjects).
... snip ... top of post, old email index
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: He Who Thought He Knew Something About DASD
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 21 Mar 2005 11:51:51 -0700
John_Mattson writes:
This reminds me of something that happened in the early 3380 days.
As I remember an installations nice new drives kept dying at a
certain time of the day, and they finally traced it to the delivery
dock. The doors to the data center were closed when the trucks
drove in and out, but when they opened after delivery there was
still enough diesel soot in the air to kill the drives. So, have
you checked YOUR environmentals lately?
there is the (famous?) folktale of the cdc6600 powering down at
berkeley the same time every week. turns out the whole machine room
would thermal (tuesday at 10am or some such) .... turns out that
coincided with grass watering schedule and a class break (the typical
flushing water use problem).
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: He Who Thought He Knew Something About DASD
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 21 Mar 2005 12:09:16 -0700
edgould@ibm-main.lst (Ed Gould) writes:
Not DASD but semi related. We had a T1 line that would go bonkers at
various times of the day. Turns out that the Blankity blank NYers
didn't use insulated wire. Everytime the freight elevator would go
by the T1 would drop. Grrrrrr I had IBM tied up for weeks looking at
traces etc.. I was *NOT* a happy camper.
in the reference about supporting a couple hundred IMS people
moving from bldg.90/STL to a location about 10 miles away:
http://www.garlic.com/~lynn/2005e.html#13 Device and channel
... a similar configuration was installed when the FE IMS service
people in boulder were being relocated to a bldg. across the street
(from the bldg. they had been in that housed the datacenter).
Bascially HYPERChannel (channel extension) over T1 link ... but in
this case it was using infrared modems on poles on the top of the
respective bldgs (aka effectively providing channel extensive so that
people would be using and experiencing local 3270 response ... as
opposed to what they would get if they were to be subjected to remote
3270 operation).
there was concern that because of the weather in the boulder area,
that it might adversely affect the signal quality. it turns out to not
being as bad as people feared. in a white-out blizzard when nobody was
able to make it into work ... we started seeing slight elevation in
the bit-error rate.
this was one of our HSDT efforts
http://www.garlic.com/~lynn/subnetwork.html#hsdt
on so we had multiplexer on the T1 link with (fireberd) bit-error
testers running constantly on a 56kbit side-channel monitoring
signal/transmission quality. i had written a program that ran on a pc
... and simulated a terminal to the serial port of the bit-error
tester ... logging all the data and then reducing and plotting the
information.
for a little topic drift, there was a different problem that resulted
in signal loss. turns out that the infrared modems have a fairly tight
footprint and it didn't take much to get the modems out of alignment.
It wasn't wind nor rain that was identified as causing the problem.
It turns out that in the course of the day ... the sun unevenly heated
the sides of the building ... causing first one side to
expand/contract and then the other side. This asymmetrical
expansion/contraction of sides of the building resulting in the poles
(that the modems were mounted on) to lean enuf during the course of
the day (to get out of alignment).
from some turbo pascal archive, long ago and far away (all of this was
before snmp) ....
{$V+,R+,B-,C-,U-} {note: the C- & U- aviods losing type-ahead}
(*
FIREBERD
minimize ERROR entries in cases of prolonged
high-error rate conditions. Calculate ERRORs/sec
Make no more than one entry in ERROR per 15 minutes
unless ERRORs/sec change by more than 50%.
minimize ERROR entries for sync lost/sync acquired
loops.
ULTRAMUX
recognize alarm messages
define status flags for various alarm messages
when sync. is lost, include fireberd information in screen
COM2 asynch interrupt
check for Asynch card interrupt
... if not asynch, restore status/regs and
goto saved IRA (i.e. cascaded IRQ4 interrupt routines)
*)
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PKI: the end
Newsgroups: sci.crypt
Date: Mon, 21 Mar 2005 13:23:01 -0700
"tomicmilan@gmail.com" writes:
Today, PKI rely on primary numbers. Humans don't know how to
calculate primary numbers. We humans don't know nothing about
primary numbers. We can only take all numbers in a range (from
10000000000 to 999999999999) and validate if some of those numbers
are primary nums.
One day someone figure out how primary numbers work: it will be the
end of PKI. The end of SSL, X.509 certificates, digital signature
and encryption as we know it.
Are there algorithms for digital signature and encryption which
doesn't require private/public key pairs? That doesn't rely on
primary numbers? I know for HMAC, enything else?
PKI is a business process that makes use of asymmetric key
cryptography (aka something is used for encryption, something else is
used for decryption and it is difficult to determine the something
used for encryption based on either the encrypted information and/or
what is used for decryption).
the fundamental business process for PKI is taking a asymmetric key
pair, that one of the keys is consistently kept private and the other
key is allowed to be public.
assuming that the fundamental business processes for protecting and
use of the "private key" are met, then a relying party may infer from
the verification of a digital signature, something regarding the
access and use of the "private key" as satisfying some form of
3-factor authentication.
besides rsa ... fips186-2 also defines ec/dsa for digital signature
algorithm ... see nist digital signature standard reference for more
information:
http://csrc.nist.gov/cryptval/dss.htm
within the context of 3-factor authentication
- something you know
- something you have
- something you are
... misc. other posts
http://www.garlic.com/~lynn/subintegrity.html#3factor
most deployed PKIs don't require people to memorize the private key,
so that eliminates something you know authentication. also most
deployed PKIs don't make the private key dependent on some biometric
characteristics ... which then rules out something you are
authentication. fundamentally that leaves the "private key" being
something you have authentication. Since a "private key" is just a
sequence of numbers ... they are somewhat prone to replication and
once that happens, it will be difficult to assert something you have
authentication. it is the business process of public/private key
infrastructure that takes asymmetric key cryptography and creates the
requirement that one of the asymmetric key pairs is to be uniquely
kept private.
as mention in other contexts:
http://www.garlic.com/~lynn/aadsm19.htm#1 Do You Need a Digital ID?
http://www.garlic.com/~lynn/aadsm19.htm#2 Do You Need a Digital ID?
http://www.garlic.com/~lynn/aadsm19.htm#3 Do You Need a Digital ID?
one of the issues from the early 90s in associated with x.509 identity
digital certificates was that the descriptions frequently concentrated
on the process of a certification authority creating a digital
certificate and would totally gloss over the business process
foundation for public/private key infrastructures (establishing the
convention that one of an asymmetric key pair is to be kept uniquely
private).
the business process foundation for public/private key infrastructure
and the convention for keeping one of the keys uniquely private, in
fact is totally independent of digital certificates. It is possible to
take an existing something you know (pin/password) authentication
infrastructure and substitute the registration of a public key in lieu
of a pin/password. it is then possible for the relying party to make
use of the registered public key to verify a digital signature.
Assuming that the other characteristics of public/private key
infrastructure has been met, then the relying party may infer that the
private key was accessed and used in an appropriate manner ... and
therefor there is something you have authentication (i.e. the
public/private key business process defining the unique access and use
of the private key).
in the above example, the fundamental foundation for public/private
key business process is that of maintaining the "private key" as
private (and has nothing at all to do with digital certificates).
as an adjunct to public/private key business process authentication,
there was a business process defined for digital certificates for use
in the scenario where the originating party and the relying party have
had no prior relationship and that the relying party has no recourse
to information about the originating party (either locally or by any
online mechanism). the digital certificate is an analogy to letters of
credit from the sailing ship days and were targeted at the offline
email environment of the early 80s; aka a call was made to the local
electronic post office, email exchanged, line was dropped and the
receiving party now must authenticate email received from a totally
unexpected source having no prior contact.
another issues raised with the identity digital certificates of the
early 90s was the problem that a certification authority would be
certifying various identity characteristics and including the
certified information in the digital certificate. for 3rd party
certification authorities who would be doing this process long before
any relying party was going to depend on the information and
furthermore, the 3rd party CAs might not have any fore-knowledge of
what relying parties there might be and what identity information they
might require ... there was a tendancy to start overloading identity
digital certificates with all possible identity information ... on the
off chance some relying party might find it useful for some purpose.
by the mid-90s, it started to become apparent that identity digital
certificates overloaded with all sorts of identity information
represented a significant privacy (and possibly liability) problem So
you saw, at least financial institutions, retrenching to
relying-party-only certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo
.... effectively containing nothing more than an account number and a
public key. however it was useally trivial to demonstrate that such
relying-party-only digital certificates were redundant and superfluous
... aka somebody registers their public key with the relying party,
the relying party records the public key in an account record,
generates a digital certificate and returns it to the key owner. The
key owner originates some transaction (that includes an account
number), digitally signs the transactions and packages up the
transaction, the digital signature, and the digital certificate and
sends the triple off to the relying party.
the relying party, receives the triple, extracts the account number
from the transaction, retrieves the account record (that includes the
public key) and verifies the digital signature with the public key.
the redundant and superfluous nature of such digital certificates in
financial transactions was further exasberated by the fact that a
traditional 8583 financial transaction has been on the order of 60-80
bytes. the typical redudandant and superfluous relying-party-only
digital certificates from the mid-90s were on the order of 6k to 12k
bytes. not only where such relying-party-only digital certificates
redundant and superfluous, their sole contribution in 8583 financial
transactions was to cause extreme payload bloat, increasing typical
transaction message size by one hundred times.
the funny thing that even today you run across descriptions referring
to digital signatures being created with digital certificates.
another example of digital certificates is their use in SSL operations
http://www.garlic.com/~lynn/subpubkey.html#sslcert
we were somewhat involved in putting together the business process
and various components of the use of SSL for this thing that was
going to be called electronic commerce:
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
thre predominate SSL use supposedly is a browser validates a digital
certificate (using a registered public key that is on file in a
trusted public key store maintained by the browser), then checks to
see if the domain name is the same that was typed into the browser aka
"is the website i'm visiting really the website i think i'm visiting".
the issue, at the time, were concerns with the integrity of the domain
name infrastructure.
well, it turns out that a typical certification authority isn't
actually the authority for the information being certified. in the
case of domain name SSL certificates, the certification authority has
to contact the domain name infrastructure to validate the entity
applying for a SSL domain name certificate, actually is associated
with that domain name (the same domain name infrastructure that has
integrity issues that give rise to the need for SSL domain name
certificates).
so somewhat motivated by the certification authority industry there is
this proposal that when somebody applies for a domain name they also
register a public key. this will not only improve the integrity of the
domain name infrastructure but also reduce processing costs for the
certification authority. Currently, a certificate authority needs an
application to supply a bunch of identity information ... which the CA
then has an expensive and error-prone process cross-checking with the
information on file at the domain name infrastructure. If there was an
onfile public key, the SSL certificate applicant would just need to
digital sign the application. Then the CA retrieves the online,
on-file public key from the domain name infrastructure and validates
the digital signature (turning a complex, error-prone and costly
identification process into a much simpler, more reliable, and cheaper
authentication process).
a catch-22 for the certification authority industry is that if the CAs
can retrieve online, on-file public keys in real time from the domain
name infrastructure ... in theory there is nothing preventing
everybody else from also retrieving online, on-file public
keys. Registering public keys in an online, on-file repository goes a
long way to eliminating the original justification for having SSL
domain name certificates at all ... i.e. as per certification
authority industry
1) registering public keys (and using them in various business
processes) improves the integrity of the domain name infrastructure
(so that the certification authority industry can rely on it for
checking the owners of certificate applications). however, one of the
original justifications for SSL domain name certificates were concerns
about the integrity level of the domain name infrastructure. improving
that integrity reduces the justification for SSL domain name
certificates.
2) everybody being able to retrieve online, on-file, registered,
trusted public keys from the domain name infrastructure can eliminate
the requirement for getting public keys out of stale, static,
redundant and superfluous digital certificates.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Where should the type information be?
Newsgroups: alt.folklore.computers
Date: Mon, 21 Mar 2005 13:43:30 -0700
Brian Inglis writes:
How do you implement read, write, or fetch breaks on addresses using
breakpoints, particularly on architectures that supports nested
indirect addressing combined with indexing? See other posts on single
instruction multidimensional array element fetch. You need to use the
address and data bus monitors that were built into mainframes, rarely
available on minis, and only recently added to some micros AFAICT.
IBM 370s (perhaps 360s) had a similar feature called Program Event
Recording that allowed conditions to be set up in control registers to
be checked by the microcode and that included DMA I/O accesses AFAIR.
some number of the 370 PER events could be performed using the
switches and dials on the front panel of 360s (address compare stop)
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PKI: the end
Newsgroups: sci.crypt
Date: Tue, 22 Mar 2005 07:50:28 -0700
Jean-Luc Cooke writes:
PKI infers only the 2nd of your factors above. PKI doesn't require any
biometric or password unless you go out of your way to add it in.
I saw you went into this a bit later in your post with some references
to your site. But you're extrapolating requirments from your view of
how the technology should be deployed.
What's with the "business process" terminology? PKI isn't a
"business process" it's a branch of mathematics. Examples of
"business process" are:
asymmetric cryptography is technology. public/private key
infrastructure is a business process application of asymmetric
cryptography that specifies one of the keys of a asymmetric
cryptography key-pair is to be kept consistantly private. the
convention of consistantly maintaining the privacy of a specific key
in an asymmetric cryptography key is a business process specification.
a relying-party, relies on the belief that the business process
specification is being followed when assuming that the verification of
a digital signature with a public key implies the something you have
authentication (i.e. some entity uniquely is in possession of the
corresponding private key).
the convention of consistantly maintaining the privacy and
confidentiality of a specific key of a asymmetric key pair is a
business process, not a technology. the measures used to maintain the
privacy and confidentiality of a private key may be technology.
asymmetric cryptography is technology.
the convention of consistantly maintaining the privacy and
confidentiality of a specific key of a public/private key pair is a
business process. the assumption by a relying-party that the
verification of some encoded pieces of data (called a digital
signature) by a specific key of a asymmetric key pair (called a public
key) implies something you have authentication is a business
process. the business process defines the requirements of consistantly
maintaining the privacy of a specific key in an asymmetric key pair as
part of the business infrastructure where a relying-party can assume
that the verification of a "digital signature" with a "public key"
implies something you have authentication (from 3-factor
authentication paradigm) dependent on some entity being uniquely in
possession (access and use) of the corresponding "private key".
there might be other business process mechanisms that might also be
specific as part of a 3-factor authentication paradigm (aka a specific
authentication infrastructure may not include three unique factors for
determining authentication, but a specific authentication
infrastructure may be characterized using the 3-factor authentication
paradigm).
as part of a basic public/private key authentication infrastructure,
the relying parties are assuming that the business process
requirements for consistantly maintaining the privacy and
confidentiality of a specific key (the "private key") are being met
(just because he is told to assume it).
A relying party might also be told that they could assume that as part
of a specific authentication infrastructure, a "private key" is
uniquely housed in a specific kind of hardware token (say as opposed
to an encrypted file). In such a case, the relying party might infer a
higher level of integrity and confidence in the associated
authentication events (and for example, the relying party might be
willing to approve large value transaction amounts than they would if
they assumed the overall infrastructure had lower integrity
characteristics).
The residence of a private key in a hardware token can be considered
technology. The ability for a relying party to assume
"a private key is housed in a specific kind of hardware token with a
specific level of hardware integirty and that the specific private key
is, in fact, kept unique and private to a specific entity"
is a characteristic of the relying parties belief in the associated
(authentication) business process operation.
Various kinds of authentication business process requirements that a
relying party could reliably assume to exist might be:
- specific key of an asymmetric cryptography key-pair is
consistantly, and reliably kept private and confidential.
- specific key is uniquely and reliably housed in a hardware
token of specific integrity characteristics, that the key(s)
were generated internally inside the hardware token and there
are no provisions for a specified "private key" to be exported
from the token
- a specific hardware token only operates in a specific
way when a pin or password has been provided to the token
- a specific hardware token only operates in a specific
way when a biometric value is matched to a template
inside the token
the ability for a relying party to assume "from the verification of a
digital signature with a specific public key" might imply any of the
above conditions to be true, is a characteristic of business process
... not just the technology.
a business process can be any operations or sequence of steps that the
parties have aggreed it to be. keeping a specific key of an asymmetric
cryptography key pair, reliably and consistantly private and
confidential isn't an attribute of the asymmetric cryptography
technology, it is an attribute of the public/private infrastructure
business process (which makes use of assymmetric cryptography
technology).
in my original posting ... i may have created some confusion by
sometimes referring to an authentication infrastructure within the
context of a 3-factor authentication paradigm ... by just typing
3-factor authentication ... w/o intending to mean that all three
factors were actually involved in any specific authentication
infrastructure instance and/or deployment.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PKI: the end
Newsgroups: sci.crypt
Date: Tue, 22 Mar 2005 08:18:32 -0700
Jean-Luc Cooke writes:
VeriSign owns Network Solutions. Details, I know.
at the time we were doing the stuff that was to become
called e-commerce:
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
we were asked to work with this little client/server startup that
wanted to have their server do payments and they had this technology
that they called SSL.
as part of working out the business process for e-commerce relying on
SSL technology, we did detailed walk-thrus and audits of the various
business processes ... including the major entities that were
supplying these things called SSL domain name digital certificates.
http://www.garlic.com/~lynn/subpubkey.html#sslcert
in general, none of the trusted 3rd party certification authorities
(whether issuing SSL domain name digital certificates or certifying
other kinds of information) were the actual authoritative agency for
the information they were certifying.
much later, one of the major trusted 3rd party certification
authorities that we had done a detailed audit on, did buy one of the
authoritative agencies for domain name ownership information. It was
also in that time-frame that you found a big push for having a domain
name applicant register a public key at the same time they registered
their domain name.
just because one of the 3rd party certification authority business
operations purchased one of the authoritative agencies responsible for
domain name ownership didn't negate the fact that their business
operation involved in issuing SSL domain name infrastructure had to
contact various authoriative agencies responsible for domain name
ownership information (including the criteria that not all domain name
ownerships were handled thru a single domain name infrastructure
business operation).
in any case, the business operations responsible for issuing SSL
domain name certificates were still having to contact (one or more)
authoritative business operations responsible for the information
being certified. At the heart of it was that there was identification
information included with the domain name registration. There was also
identification information included with the SSL domain name
certificate application. The problem facing the SSL domain name
certificate (certification authority) industry was
- integrity issues with the operation of the domain name
infrastructure that might affect the validaty of any certification and
therefor any SSL domain name certificate that was issued (issues that
also contributed to the requirement for SSL domain name certificates)
- error-prone, complex, and expensive process of matching the
identification information provided with the SSL domain name
certificate application to the identification information provided
with the domain name application.
A solution (in part backed by the certification authority
business/industry) was that domain name applications register a public
key at the same time they registered the domain name. This would
- improve the overall integrity of the domain name infrastructure by
requiring that various business processes be digitally signed by the
domain name owner (and the domain name infrastructure could verify
with the on-file public key)
- the certification authority indistry then could require that SSL
domain name certificate applications be digital signed. The
certification authority industry then could change an error-prone,
complex and expensive identification business process into a much
simpler and less expensive authentication business process (by
retreaving the on-file public key from the domain name infrastructure
and verifying the digital signature on the SSL domain name certificate
application).
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PKI: the end
Newsgroups: sci.crypt
Date: Tue, 22 Mar 2005 10:12:04 -0700
Jean-Luc Cooke writes:
What's with the "business process" terminology? PKI isn't a "business
process" it's a branch of mathematics. Examples of "business process" are:
- "mass production",
- "universal pricing", and
- "third world labour producing goods to the first world"
ref:
http://www.garlic.com/~lynn/2005e.html#24 PKI: the end
http://www.garlic.com/~lynn/2005e.html#25 PKI: the end
aka ... "public" and "private" are business process constructs.
a digital certificate may be implemented using asymmetric cryptography
technology ... but what an identity x.509 certificate represents is a
business process defintion. the certification authority operation and
its certifying of infomration, as well as much of the processes
surrounding identity are business processes.
during one of the early audits we did on one of the certification
authority businesses, they commented that they had started out
thinking that certification authority was mostly mathematics but they
quickly found out that it was a service business and that possibly 95%
of the business operation involves adminstrative and business process
procedures and that technology is only a very small miniscule portion.
and for a little topic drift ... another flavor of 3-factor
authentication discussion:
http://www.garlic.com/~lynn/aadsm19.htm#1 Do You Need a Digital ID?
http://www.garlic.com/~lynn/aadsm19.htm#2 Do You Need a Digital ID?
http://www.garlic.com/~lynn/aadsm19.htm#3 Do You Need a Digital ID?
http://www.garlic.com/~lynn/aadsm19.htm#4 Do You Need a Digital ID?
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PKI: the end
Newsgroups: sci.crypt
Date: Tue, 22 Mar 2005 10:34:57 -0700
Anne & Lynn Wheeler writes:
during one of the early audits we did on one of the certification
authority businesses, they commented that they had started out
thinking that certification authority was mostly mathematics but they
quickly found out that it was a service business and that possibly 95%
of the business operation involves adminstrative and business process
procedures and that technology is only a very small miniscule portion.
also as further aside, the major trusted 3rd party certification
authority at the time asked if we knew any organization (that was
already in serious, industrial strength service business) that might
be interested in outsourcing their complete operation.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computerworld Article: Dress for Success?
Newsgroups: alt.folklore.computers
Date: Tue, 22 Mar 2005 19:14:18 -0700
Brian Boutel writes:
When my son got married, he refused to wear a tie for the ceremony,
choosing a beautiful suit with an open-necked shirt, as did my other
son, who was best man. The bride decided to be traditional, so wore a
lacy and bejewelled gown by Reem Acra, while her father insisted on
formality and wore a morning suit. This left me in a bit of a dilemma,
so I compromised on a suit with a tie. Black tie was specified for the
big evening dinner, but most people removed, or at least untied, them
when the dancing started.
did you know you can get a boot cut tux made?
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Using the Cache to Change the Width of Memory
Newsgroups: comp.arch,alt.folklore.computers
Date: Wed, 23 Mar 2005 15:04:01 -0700
Brian Inglis writes:
Although it wouldn't surprise me if someone, somewhere wasn't still
running the software emulators on crufty old binaries, rather than
pay for redevelopment.
I've also known managers whose primary function seemed to be to
block any possible replacement for some dusty old deck they created
when they were a youngster.
when amdahl was starting his mainframe clone company in the early 70s,
he gave a talk at mit. he was asked about how he got venture
funding. he said something about his business plan pointing out that
there was already over $100b spent on 360 applications and that even
if ibm walked away from 360 architecture at that moment (could be
construed as a thinly veiled reference to the radically different FS
architecture being worked on), that customers would still be buying
360 processors 30 years later (i.e. 2000).
the issue was that a large number of applications are meeting
requirements and the cost of rewrite as well as possibly opportunity
lost cost (putting scarce resources to work on rewriting a working
application rather than getting out something brand new) wasn't less
than any expected cost savings.
in some cases, there was significant risk issue also considered ...
i.e. the current implementations are known to do the job ... there
have been numerious mainframe "modernization" (rewirte) projects where
hundreds of millions (and even billions) have been spent ... and the
projects failed.
misc. past FS (future system) posts:
http://www.garlic.com/~lynn/subtopic.html#futuresys
in the late 60s, i saw a case of a university administrative payroll
application appear to have a problem. It had started out as a 407
plug-board application ... which got translated by something (? I
don't remember the details), which got translated to 709 cobol, which
got translated to 360 cobol. at the end of the program it was still
outputting emulated 407 sense settings on the printer. one day the
operators notice that the 407 values were differen't than they had
been. everything was stopped and the whole datacenter was put on hold
while they tried to contact somebody in administrative dataprocessing
to see what might need to happen (did it fail and payroll would have
to be run again?). They finally found somebody, but couldn't find
anybody that knew what the 407 values were supposed to indicate ... so
the decision was to run the program again ... and if they came out the
same, assume everything was ok.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computerworld Article: Dress for Success?
Newsgroups: alt.folklore.computers
Date: Wed, 23 Mar 2005 18:22:47 -0700
Greg Menke <gregm-news@toadmail.com> writes:
Yeah, those hats also include holders for 2 beer cans and a plastic tube
that the wearer can use to siphon beer into their mouth. Texan formal
wear- cool. :)
how far is it from austin to dallas?
the texans claimed it was three six-packs.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Public/Private key pair protection on Windows
Newsgroups: alt.computer.security
Date: Fri, 25 Mar 2005 08:29:50 -0700
"Edward A. Feustel" writes:
For best results, generate your private key in a token (2048 bits or
more preferred) and NEVER export it to a Windows machine. Only
insert the token in the USB port when you must and only as long as
it must be there. Further, be certain that any buffering of the key
by Windows is erased when you are done using the private key, i.e.,
close the session, or turn off the power for at least 20
seconds. This will minimize the chances that someone else will
acquire access to your key or be able to tale end your sessions. Ed
for rsa key-pair ... there is also specification for ecdsa, related thread
reference with pointer to nist fips186-2 ecdsa
http://www.garlic.com/~lynn/2005e.html#22 PKI: the end
because of various issues with pc vulnerabilities .... there is
the EU FINREAD standard ... misc posts:
http://www.garlic.com/~lynn/subintegrity.html#finread
... where you have a separate unit connected to pc with display and
keypad that directly talks to the token ... for accurately displaying
transaction and safely entering a token's pin/password.
use of hardware token addresses direct copying of the private key. EU
FINREAD attempts to address a couple additional vulnerabilities:
- various kinds of keyloggers capturing the token pin/password and
being able to execute transactions while the token is connected w/o
your knowledge. EU FINREAD has its own keybad for pin/password
entering.
- virus corrupting the transaction where the screen displays some
transaction supposedly to be digitally signed, but what gets sent to
the token for signing is totally different. EU FINREAD has its own
(small) display for presenting transaction (somewhat oriented towards
financial transactions ... akin to what you might find a supermarket
checkout counter).
there is also a dual-use attack.
digital signature infrastructure primarily is a mode from 3-factor
authentication ...
http://www.garlic.com/~lynn/subintegrity.html#3factor
- something you know
- something you have
- something you are
where the relying party succesfully validating the digital signature
can assume that the originating party is in possession of the
corresponding private key (aka something you have authentication).
A digital signature authentication scheme may be a flavor of
challenge/response (countermeasure for replay attacks) ... where the
relying party transmits some random bits which the other end digitally
signs and returns the digital signature. the relying party then
validates the digital signature with the public key ... which is proof
that the other end is in possession of the corresponding private key
(aka something you have authentication).
Some infrastructures have also looked at use of public/private key
digital signatures to imply more than simple authentication ... aka
that verification of a digital signature is equivalent to a human
signature ... which not only implies something you have
authentication, but also implies something similar to a human
signature, aka implication of reading, understanding, approving,
agreement, and/or authorization.
A dual-use attack is when the same private key is used for both 1)
authentication events where random bits (that are never viewed, read,
or understood) are digitally signed and 2) human signature events
where there isn't some additional additional proof that some human has
actually read, understood, arpproved, agreed, and/or authorized the
related bits being digitally signed.
So a dual-use attack is for some attacker, in a supposedly purely
authentication operation, transmit some bits for digital signing that
purports to be random ... when the bits actually can be interpreted to
represent some obligation as in a human signing event. A possible
analogy is in the MASH show where Radar is getting the col. to sign
stuff where the col. isn't actually reading what he is signing.
Part of the issue may be the semantic ambiquity with the term "digital
signature" ... where the use of the word "signature" is automatically
taken to imply some relation to "human signature" ... even tho
"digital signature" can be commonly used in situations where there is
no implication at all of the equivalent conditions for human signature
(read, understood, agreed, approved, and/or authorized).
somewhat unrelated, hardware tokens can also be considered a phishing
countermeasure. A lot of phishing is social engineering,
convincing people to perform electronic act that makes them vulnerable
(divulging their userids and passwords and other information that
enables things like account theft and/or id-theft ... where
transactions and/or other obligations happen w/o the person's
knowledge).
When a hardware token is also required, it is probably going to be
somewhat more difficult to convince a victim to mail off their
hardware token. It still doesn't eliminate the social engineering
where the attacker convinces the victim to directly execute the
transactions for the benefit of the crook (however, it does somewhat
minimize the ability for the crook to do their own fraudulent
transactions w/o the owner's knowledge).
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Stop Me If You've Heard This One Before
Newsgroups: alt.folklore.computers
Date: Fri, 25 Mar 2005 09:54:48 -0700
Peter Flass writes:
I recently got into this with someone else. I don't have the
reference handy, though I can look it up, but IBM has a manual on line
with lots of 3270 keyboard layouts, including, IIRC, the 3278. Of
ouurse there isn't "a" 3278 keyboard layout, but you probably want
something like the"US text keyboard." Let me know offline if you
can't find what you want, and I should be able to track down a link to
the manual or a hardcopy of it.
we got into a battle with kingston when they were bringing out 3278
about PF keys moving to the top (vis-a-vis the 3277). their argument
was that the 3278 was designed primarily for data entry (clerks)
rather than interactive computing or programming.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Stop Me If You've Heard This One Before
Newsgroups: alt.folklore.computers
Date: Fri, 25 Mar 2005 10:22:03 -0700
originally, there was 3278 with no PFKEYS at all and they had taken
the PFKEYS location on the 3277 and turned it into numeric keypad for
data entry applications.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Thou shalt have no other gods before the ANSI C standard
Newsgroups: sci.crypt,alt.folklore.computers
Date: Sun, 27 Mar 2005 10:16:24 -0700
Andrew Swallow writes:
I also found out about XML (Extended Markup Language) format. That
may be a modern alternative to RTF format.
the original was GML (generalize markup language) invented in '69
at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech
... the letters G, M, and L actually stand for the initials of the
last names of three people at the science center.
Madnick had done script command in the mid-60s for CMS ... which had
"dot" commands for document formating. GML tag support was then added
to script command. The difference between the dot commands and GML was
that dot commands explicitly defined document formating while GML tags
could label the data independent of the specific formating rules for
that type of data. This enabled that the tagging/labeling of data to
be used for other than purely formated. There were loads of documents
done in script and later script/gml in the 70s.
this was eventually standardized in ISO as sgml in the late '70s
http://www.garlic.com/~lynn/subtopic.html#sgml
there has been some postings on the web showing the evolution of early
html from sgml origins ... highlighting various waterloo script/gml
documents at cern.
cern and slac were somewhat sister organizations sharing applications
and development of some of the applications. they both had large
vm/cms installations. univ. of waterloo was also a large vm/cms shop
and had done some number of enhanced and/or alternative
implementations of various standard vendor vm/cms products (this was
still from the period of open source ... before more heavily trend
into object-code-only). misc.
early history of html
http://infomesh.net/html/history/early/
a history of scientific text processing at cern
http://ref.web.cern.ch/ref/CERN/CNL/2001/001/tp_history/
somewhat as an aside ... slac then had the first webserver in the US.
the early world web web at slac
http://www.slac.stanford.edu/history/earlyweb/history.shtml
somewhat as a pure aside, the current w3c offices in cambridge are
only a couple blocks from the old science center offices.
some subject drift ... some recent xml posts in comp.databases.theory
http://www.garlic.com/~lynn/2004l.html#72 Specifying all biz rules in relational data
http://www.garlic.com/~lynn/2004m.html#3 Specifying all biz rules in relational data
http://www.garlic.com/~lynn/2004n.html#11 XML: The good, the bad, and the ugly
http://www.garlic.com/~lynn/2004n.html#12 XML: The good, the bad, and the ugly
http://www.garlic.com/~lynn/2004p.html#38 funny article
http://www.garlic.com/~lynn/2004q.html#6 XML Data Model
http://www.garlic.com/~lynn/2005.html#25 Network databases
http://www.garlic.com/~lynn/2005.html#26 Network databases
http://www.garlic.com/~lynn/2005.html#27 Network databases
http://www.garlic.com/~lynn/2005.html#29 Network databases
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Thou shalt have no other gods before the ANSI C standard
Newsgroups: sci.crypt,alt.folklore.computers
Date: Sun, 27 Mar 2005 13:20:28 -0700
Anne & Lynn Wheeler writes:
cern and slac were somewhat sister organizations sharing applications
and development of some of the applications. they both had large
vm/cms installations. univ. of waterloo was also a large vm/cms shop
and had done some number of enhanced and/or alternative
implementations of various standard vendor vm/cms products (this was
still from the period of open source ... before more heavily trend
into object-code-only).
some open source topic drift.
in the '60s you found lots of software being distributed for free, in
many cases along with the source.
federal gov. was bearing down on big mainframe about charging for the
computer but giving away the software ... as a form of bundling. so
june 23rd, 1969 was the big "unbundling" announcement ... helping to
satisfy the federal gov. wishes. application software started being
charged for separately from the computer hardware. kernel software
continued to be free (or bundled) on the theory that the kernel was a
part of being able to operate the hardware.
one of the projects i worked on as an undergraduate was reverse
engineering the mainframe channel interface and building our own
channel board and putting it in an interdata/3 that was programmed to
emulate a mainframe telecommunication controller. this gotten written
up someplace as the four of us spawning the pcm/oem/clone mainframe
controller business.
http://www.garlic.com/~lynn/subtopic.html#360pcm
later the future system project was spawned to create a brand new
mainframe product offering ... radically different than the existing.
one of the main driving factors behind FS project was the
pcm/oem/clone controllers ... and that FS would provide a degree of
integration between all the system components that would make it
extremely difficult for individual pieces to be substituted by other
vendors.
http://www.garlic.com/~lynn/subtopic.html#futuresys
in the early 70s, gene amdahl gave a talk at mit auditorium about
starting his new mainframe clone computer company. when asked about
the VC business justificaion one of his points was that there had
already been at least $100b spent on software applications by
customers and even if ibm totally walked away from the existing
mainframe business that day (can be construed as veiled reference to
the future system project), there would be still customer demand for
buying 360/370 mainframes thru at least 2000. there are various other
rumors that what prompted gene to leave and start his clone computer
company was the FS project ... he wanted to build a better, faster 360
and disagreed with the FS direction.
So by the time gene started shipping his clone mainframe, there was
started to be some pressure to take a new look at whether to price for
kernel software. You were just starting to see the leading edge of
hardware technology where it was becoming significantly cheaper to
design and manufactur a new computer than it was to design and
develop a new operating system (kernel). Up until that time, the
majority of the operating systems had been mostly proprietary to the
mainframe vendors. You are now just starting to see hardware vendors
producing a new computer and not wanting the expense of also doing a
whole operating system from scratch.
about this time they were deciding about making my operating system
resource manager a product. I got to do it almost like a one person
startup; algorithms, architecture, design, develop, code, test,
validate, benchmark, document, teach classes, releases, maintenance,
business cases, pricing, etc ... except i got to do it within a large
corporate infrastructure and needing to interface with the established
processes. So the resource manager got elected to be the first guinea
pig for pricing kernel software. i got to spend some amount of time
over six month period doing business, pricing and forcasting stuff for
kernel priced software. This particular exercise resulted in policy
that kernel software could be priced (analogous to application
software) as long as it wasn't directly required for hardware support
(aka stuff like device drivers).
Over the next several years, more and more stuff fell into the
"priced" category and less stuff in the "free" category ... until the
policies had changed so that the complete kernel was priced. Part of
the issue was that for some components, the issue of independent
pricing resulted in billing costs (given the billing processes at the
time) compareable or larger than the actual revenue stream.
also, with pricing for all components, there started to be a big push
for object-code-only ... no more shipping source and/or using source
maintenance processes.
in this period there were studies that claimed things like there were
as many lines of "kernel" code (enhancements) on the share/waterloo
"tape" (distribution) as there was (lines of code) in the base kernel
product shipped directly from the vendor.
so much of the '80s and 90s was object-code-only and priced software
(as opposed to the earlier period of freely distributed software and
source).
misc. posts related to resource manager:
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock
and benchmarking/validation ...
http://www.garlic.com/~lynn/subtopic.html#bench
some topic drift about pricing/forcasting .... there was a floor limit
from the federal gov. that the price had to cover the costs ... people
design & development, ongoing support, etc. Major part were upfront
costs which then were amortized over the per unit sales. Given some
experience and a lot of data, typically there was a "low", "medium"
and "high" price selected and then a total number of unit sales
forcast based on price (in part to see if there was any price
elasticity in the market). Each price level times the forcasted market
size had to at least cover all the (including significant upfront)
costs.
there were a number of other pricing guidelines. in the mid-70s
one of the reasons given for killing the VAMPS (5-way smp) project
http://www.garlic.com/~lynn/subtopic.html#bounce
was that we could only show something like $8b-$9b total revenue over
five years ... and the supposed corporate requirement for any distinct
mainframe offering was minium $10b revenue over five years (if you
couldn't show at least $10b revenue, it wasn't worth doing).
there was a totally different problem that showed up with the kernel
software pricing policy. I was designing the VAMPS 5-way smp
architecture and also including some of the design features in the
resource manager code. The resource manager shipped as standard kernel
product and VAMPS was killed. However, it was later decided to do a
more conventional, purely software SMP implementation. in VAMPS i got
to have some latitude with implementing SMP constructs in the
microcode of the machine. This required some remapping when it was
decided to do a purely software only kernel implementation supporting
SMP.
Then it came time to ship the release with SMP support in it. It is
fairly obvious that kernel multiprocessor support is directly
supporting hardware features and therefor according to the policy at
the time had to be "free". The problem was the design and
implementation had been done assuming a lot of the code in the
resource manager, which was already shipping to customers as "priced"
software. Having "free" software with a prerequisite on "priced"
software was a violation of the pricing policy for kernel software.
The eventual result was that something like 80-90 percent of the code
in the resource manager was repackaged as part of the "free" kernel.
http://www.garlic.com/~lynn/subtopic.html#smp
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Where should the type information be?
Newsgroups: comp.arch.arithmetic,comp.arch,alt.folklore.computers
Date: Mon, 28 Mar 2005 07:57:15 -0700
Peter Flass writes:
Sorry to disappoint you. I first started working with PL/I about
1966, and it wasn't my first language. Let the young folks have the
new ideas.
i have vaque memories of ibm coming by the university and
demonstrating as yet unreleased PLI product ... but i didn't think it
was until mid or late '67. they had loaded it from tape on a 2314 and
left it there for a week while they gave talks and demos. they then
were careful to make sure it was all scratched before they left.
later there was some issue raised about whether the pack had been
backed up during the period that PLI had been loaded.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Where should the type information be?
Newsgroups: comp.arch.arithmetic,comp.arch,alt.folklore.computers
Date: Mon, 28 Mar 2005 10:35:11 -0700
iain-3 writes:
So here's a question for you: what sort of machine instruction would be
useful to tell the CPU how to do a multidimensional interpolated table
lookup? Since it's probably got too many inputs, and maybe too many
outputs, and too many variations (dimensions, interpolation datatype,
interpolation scheme, etc), it should probably be factored into a few
ops. What are those ops?
not a table ... but tree stuff, is luther woodrum's tree stuff
that got put in mainframe
sorting instructions:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/A.7?SHELF=EZ2HW125&DT=19970613131822#HDRAA4H1
tree format
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/A.7?SHELF=EZ2HW125&DT=19970613131822#HDRAA4H1
example of use of sort instructions
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/A.7.2?SHELF=EZ2HW125&DT=19970613131822&CASE=
compare and form code word
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/7.5.21?SHELF=EZ2HW125&DT=19970613131822
update tree
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/7.5.99?SHELF=EZ2HW125&DT=19970613131822
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: xml-security vs. native security
Newsgroups: sci.crypt
Date: Mon, 28 Mar 2005 10:51:31 -0700
securenix writes:
I am involving in the development of an application framework
focusing on web services. Messages excnahged among framework
principals are SOAP messages.
For security issues like encrypting, signing, etc. I am planing to
use native byte[]-oriented cryptographic techniques. But I see
around xml-security solutions (e.g. WS-Security, etc.). I wonder
what advantages the xml-security bring us over native-security
solutions? Do native-solutions cause any bottleneck for web
services?
an earlier issue with asn.1 vis-a-vis xml for digital signatures
were in financial transactions.
there were a number of applications that asn.1 encoded the transaction
for digitally signing, and then transmitted the transaction in its
basic format along with the digital signature. the receiver would take
the transmitted transaction, re-encode in asn.1 and then check the
digital signature.
part of the issue was that many financial transactions were/are on the
order of 60-80 bytes and that asn.1 encoding would significantly
increase the size ... as well as a lot of intermediate legacy
processes weren't prepared to handle a transaction in asn.1 encoded
format.
the objective was to simple add message integrity and origina
authentication to existing financial infrastructure ... with a digital
signature ... w/o having to totally scrap the existing legacy
financial transaction infrastructures.
the problem with using xml encoding (at the time) rather than asn.1
was that the xml encoding rules weren't deterministic ... aka the
origin took a basic financial transaction message and encoded it
before digitally signing ... and the destination had to take the same
financial transaction message and (re)encode it and come up with the
same, exact bit-stream for the digital signature to verify (which
couldn't be guaranteed with xml at the time).
FSTC created FSML to provide deterministic XML encoding rules for
digitally signed financial transactions ... this was later donated to
w3c and absorbed into the XML digital signature specification.
a separate issue from the mid-90s was not only the xml encoding rules
of a financial transaction (to avoid the payload bloat of transmitting
the encoded format as well as replacing all the legacy financial
transaction software) ... but also trying to use digital signatures
for financial transactions ... where the origin also included a
digital certificate with every transmission (even tho the
destination/relying-party was already in possession of a registered
public key for the origin). In the mid-90s, digital signature
financial transaction pilots, the typical size of the certificates
used were in the range of 6kbytes to 12kbytes.
given a base financial transaction of 60-80 bytes, not only were the
appended certificates redundant and superfluous (since the destination
already had a registered public key for the originator) but their
apparent primary purpose was to cause enormous payload bloat and
increase the financial transaction message size by a factor of one
hundred times.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: xml-security vs. native security
Newsgroups: sci.crypt
Date: Mon, 28 Mar 2005 12:36:59 -0700
Bruce Stephens <bruce+usenet@cenderis.demon.co.uk> writes:
My guess is that it's the same kind of difference as with OSI: rather
than checking the signature of the bytes (in BER) you got over the
wire, you can encode the abstract value in a particular way (DER) and
check the signature of that.
which OSI is this ... open system interconnect? ... ISO (international
standards organization) model for networking?
ISO has standards for certificates, including requirements for
including ASN.1 encoded digital certificates with the transmission of
digitally signed financial transactions ... previous reference:
http://www.garlic.com/~lynn/2005e.html#38 xml-security vs. native security
misc. other references:
http://www.garlic.com/~lynn/subpubkey.html#rpo
OSI (as in ISO's OSI model) evolved in the late 70s and early 80s
concurrently with the internetworking protocol ... the
arpanet/internet had the great switch-over from an early homogeneous
(much more OSI-model like) to internetworking on 1/1/83.
in the late '80s several govs. had mandates that the internet be
eliminated and the whole thing switched to OSI (US federal government
had various "GOSIP" mandates).
in the late '80s I was evolved with trying to get HSP (high speed
protocol) accepted as a work item in x3s3.3 (ISO charterd ansi
standards body responsible for networking related standards). at the
time, ISO had a mandate that networking related standards couldn't
deviate/violate from the OSI model.
HSP would:
1) go directly from transport/level4 to mac/lan interface
2) support internetworking (aka tcp/ip)
3) support max/lan interface
HSP was rejected based on the ISO mandates because
1) it violated OSI model by skipping the transport/network,
level 3/4 interface
2) it violated OSI model by supporting tcp/ip ... aka OSI was
traditional private homogeneous networking model and didn't include
provisions for internetworking, gateway, etc. ... and therefor HSP
violated the OSI model by supporting internetworking
3) mac/lan interface violates the OSI model with the mac/lan
interface corresponding to approx. the middle of layer 3.
Anything supporting mac/lan interface violates the OSI model.
HSP supported the mac/lan interface, therefore HSP violated
the OSI model.
misc. past comments:
http://www.garlic.com/~lynn/subnetwork.html#xtphsp
for a little topic drift ... an unrelated recent post
on xml
http://www.garlic.com/~lynn/2005e.html#34 Thou shalt have no other gods before the ANSI C standard
misc other xml, html, sgml, gml posts
http://www.garlic.com/~lynn/subtopic.html#sgml
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: xml-security vs. native security
Newsgroups: sci.crypt
Date: Mon, 28 Mar 2005 15:54:23 -0700
Bruce Stephens <bruce+usenet@cenderis.demon.co.uk> writes:
That may be so. I was thinking of the ITU standards (some of which
may be reflected in ISO standards, too). In particular, those for
X.500 strong authentication and signed operations (X.509, X.511).
They used to specify that signatures were of the DER encoding of the
abstract values (i.e., it would be OK for a recipient to decode the
received values, reencode them using DER, and then check the
signature). But more recently it seems that the signature is supposed
to be checked against the actual received encoding. (Presumably
there's still some place for DER, but it seems a much smaller one,
IMHO.)
i was at the acm sigmod conference in the very early 90s and somebody
asked what was this x.500/x.509 stuff that was happening in ISO and
somebody else explained that it was a bunch of networking engineers
attempting t