List of Archived Posts

2005 Newsgroup Postings (06/01 - 06/11)

private key encryption - doubts

The 8008

Interesting P4 pipeline article ("replay")

Request for comments - anti-phishing approach

private key encryption - doubts

The 8008

private key encryption - doubts

TSO replacement?

TSO replacement?

Determinstic OpenSSL signature

Request for comments - anti-phishing approach

The 8008

Performance and Capacity Planning

Performance and Capacity Planning

The 8008

The 8008

Performance and Capacity Planning

Performance and Capacity Planning

Repository for digital certificates

Performance and Capacity Planning

Blinky lights WAS: The SR-71 Blackbird was designed ENTIRELY

Blinky lights WAS: The SR-71 Blackbird was designed ENTIRELY

Public disclosure of discovered vulnerabilities

Public disclosure of discovered vulnerabilities

Public disclosure of discovered vulnerabilities

IBM Plugs Big Iron to the College Crowd

IBM Plugs Big Iron to the College Crowd

Public disclosure of discovered vulnerabilities

NASA Discovers Space Spies From the 60's

IBM Plugs Big Iron to the College Crowd

IBM Plugs Big Iron to the College Crowd

Three-Address RISC, and Really Fast Addressing

IBM Plugs Big Iron to the College Crowd

IBM Plugs Big Iron to the College Crowd

IBM Plugs Big Iron to the College Crowd

IBM Plugs Big Iron to the College Crowd

A second look at memory access alignment

A second look at memory access alignment

virtual 360/67 support in cp67

A second look at memory access alignment

A second look at memory access alignment

TSO replacement?

Public disclosure of discovered vulnerabilities

A second look at memory access alignment

A second look at memory access alignment

Where should the type information be?

Public disclosure of discovered vulnerabilities

Where should the type information be?

Public disclosure of discovered vulnerabilities

Public disclosure of discovered vulnerabilities

virtual 360/67 support in cp67

Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP

Banks

Banks

Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP

Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP

Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP

Ancient history

Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP

Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP

Ancient history

Ancient history

More on garbage collection

The 8008

More on garbage

private key encryption - doubts

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: private key encryption - doubts
Newsgroups: comp.security.ssh
Date: Wed, 01 Jun 2005 09:59:12 -0600

"Yogee" writes:

Alice creates a one-way hash and encrypt it with her private key
->sends it to bob. Bob decrypts it with public key (available every
where i guess). So Bob now knows the private key of Alice. So its no
longer private.

Whats the trick in this. I think one can encode a message using public
key but only one having private key can decript it.

I need to know what exactly is a digital signature. A one-way hash and
digest.

asymmetric cryptography uses a pair of keys, what one encodes, the
other decodes (as opposed of symmetrical cryptography that uses the
same symmetric key for both encryption and decryption).

there is a business process that defines one of asymmetric
cryptography key pair as "public" and makes it generally available,
the other of the key pair is designated "private" and consistantly
kept confidential and never divulged.

in the digital signature business process ... a hash of a message is
computed and encoded with the private key. the message and the digital
signature (encoded hash) is transmitted. the recipient recomputes the
hash of the message and decodes the digital signature with the
(corresponding) public key and then compares the two hashes. if the
two hashes are the same, then the recipient

1) knows the message hasn't been modified in transit

2) implies something you have authentication about the originator,
aka that the originator has access to and use of the corresponding
private key

from 3-factor authentication paradigm

• something you have
• something you know
• something you are

verification of a digital signature implies something you have
authentication regarding the originator ... that they have access to
and use of the corresponding private key.

in the purely digital signature verification case, the actual message
isn't necessarily encrypted/encoded. when there is a requirement to
also encrypt/encode the message ... frequently a randomly generated
symmetric key is created and actually encrypts the message
(symmetrical key encryption tends to be much more efficient than
asymmetrical key encryption). In the situation for both encrypting and
digitally signing the message ... the originator transmits the
encrypted message (with the randomly generate symmetric key), the
symmetric key encoded with the recipients public key, and the digital
signature (hash encoded with the originator's private key). The
recipient can verify the digital signature with the originator's
public key. The recipient then can decode the symmetric key (which has
been encoded with the recipient's public key) with their private
key. Having decoded the symmetric key with their private key, the
recipient can use the decoded symmetric key to decrypt the actual
message.

fips186-2 has DSA and ECDSA
http://csrc.nist.gov/cryptval/dss.htm

which is definition of public/private key pairs for digital signature
process only. in DSA/ECDSA, the hash and a randomly generated number
are combined and encoded, resulting in two values (two consecutive
digital signatures encodings of the same message will result in
different digital signature values) ... think of it as somewhat two
equations in two unknowns. DSA/ECDSA have been vulnerable to weak
random number generators which can expose the private key (quality
random numbers generation is essential to DSA/ECDSA digital signature
operation).

in the past, most hardware tokens have had very inadequate random
number generators. as a result you've seen such hardware tokens
deployed with RSA-based digital signature for authentication.  The RSA
key pairs would be generated externally (using quality ranodm number
generator) and injected into the hardware token.  With the advent of
hardware tokens with quality random number generation ... you can use
the random number generator for both on-token key pair generation as
well as DSA/ECDSA digital signature operations.

shared-secrets and pin/password based authentication systems
http://www.garlic.com/~lynn/subintegrity.html#secrets

have the issue that the originator and the recipient both have access
to the same value ... and therefor the recipient can also use the
value to impersonate the originator. as a result, you tend to have a
requirement that such infrastructures require a unique
pin/password/key for every unique security domain. As a result there
is a huge proliferation in the number of shared-secrets that an
individual has to remember.

In the digital signature scenario, only the value that is used to
verify the digital signature is ever divulged (which can't be used to
impersonate the originator). The private key which is used to
originate digital signatures is never divulged and is only available
to the specific originator (the vulnerability is any compromise of the
originator's private key).

there has been a lot published PKI, digital certificate based
public/private key business processes.

there is a lot less published on certificate-less public/private
key business process
http://www.garlic.com/~lynn/subpubkey.html#certless

although typical ssh deployments of public/private key are
certificate-less based.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

The 8008

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The 8008
Newsgroups: alt.folklore.urban,alt.folklore.computers
Date: Wed, 01 Jun 2005 11:44:06 -0600

forbin@dev.nul (Colonel Forbin) writes:

Sadly, my main well developed professional skill is making computers
and the humans who produce and support them run fast and that isn't
in great demand for some reason.  I can't recall ever working at a
place where the management had any sense of something remotely
resembling vision, including HP.  OTOH, I'm not a bad manager, I
just don't enjoy it.  If Seymour Cray had me at his side (well,
probably more likely kicking his ass) at CCC, he wouldn't have bet
the farm on the Cray-4 in a bad market, would have outbid HP on the
Convex acquisition, and might not have died like the SUV version of
James Dean because we would likely have been sitting in the
treehouse at Megatest smoking a doobie and reflecting on our
success.

a couple months after i graduated and joined the science center
http://www.garlic.com/~lynn/subtopic.html#545tech
(... this was in the era of rapid corporate expansion ... and they
were constantly trying to promote current employees into management
... to handle the new crop of incoming) .... i asked to read the
manager's manual (3in thick, 3ring binder with lots & lots of stuff in
it). i then explained that i had worked various kinds of construction
jobs as a kid ... and my first summer in college was forman on project
with crew of 27-30 people. i mentioned that my "training" and
background for managing/motivating people seemed to be inconsistant
with what was laid out in the manager's manual.

that sort of put an end to promoting me to manager ... i never was one
... although i was given a lot of opportunity to provide technical
direction.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Interesting P4 pipeline article ("replay")

From: Anne & Lynn Wheeler  <spamtrap@crayne.org>
Subject: Re: Interesting P4 pipeline article ("replay")
Newsgroups: comp.lang.asm.x86,comp.arch
Date: Wed, 1 Jun 2005 17:25:43 +0000 (UTC)

Terje Mathisen  writes:

This is actually quite well-known in the literature and in
comp.arch, it is called data speculation: The instruction scheduler
tries to guess when a given data item will become available, and
schedules the next instruction to start at that very moment.

in the high-end 360/370s horizontal microcoded engines ... it was a
little harder, the programmer had to count the cycles and not make
reference to value in registers until the appropriate number of cycles
had passed (after fetch or other asynchronous operation).

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Request for comments - anti-phishing approach

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Request for comments - anti-phishing approach
Newsgroups: comp.security.misc
Date: Wed, 01 Jun 2005 19:50:07 -0600

"douglas.ross@gmail.com" writes:

Here's a refined version of the anti-phishing approach, with
screenshots.  It revolves around making the phisher solve a
captcha-like problem:

some recent postings in the cryptography mailing list on
phishing vulnerabilities and countermeasures:
http://www.garlic.com/~lynn/aadsm19.htm#17
http://www.garlic.com/~lynn/aadsm19.htm#18
http://www.garlic.com/~lynn/aadsm19.htm#19
http://www.garlic.com/~lynn/aadsm19.htm#20
http://www.garlic.com/~lynn/aadsm19.htm#21
http://www.garlic.com/~lynn/aadsm19.htm#22
http://www.garlic.com/~lynn/aadsm19.htm#23
http://www.garlic.com/~lynn/aadsm19.htm#24
http://www.garlic.com/~lynn/aadsm19.htm#25
http://www.garlic.com/~lynn/aadsm19.htm#26
http://www.garlic.com/~lynn/aadsm19.htm#27

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

private key encryption - doubts

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: private key encryption - doubts
Newsgroups: comp.security.ssh
Date: Wed, 01 Jun 2005 22:59:02 -0600

"Yogee" writes:

How is the symmetric key generated? What algorithms are used?
Suppose I finally got the symmetric key decided by the originator. Do I
have to know how the key was created for continuing the encryption or
its just a key that will be used for encryption. Is the ALGO for
encrypting be same for both the parties.

What is the basic difference between RSA/DSA?
Actually I did ssh without password. I was able to do it successfully
but didnt understood how it happened. So I tried to dig into it.

... you are now past the overview stage and into read-the-manual
stage. i already provided the URL for nist fips182 ... which goes into
detail on dsa, ecdsa, and rsa digitlal signatures (and lots of
additional details).

you should now read the detailed documentation.

with quicky use of search engine ... here is openssh
http://www.openssh.com/

here is reference for openSSL
http://www2.psy.uq.edu.au/~ftp/Crypto/

SSL2 from the netscape web site
http://wp.netscape.com/eng/security/SSL_2.html

we were aksed to consult with this small client/server startup in
silicon valley that wanted to do payment transactions on their
"commerce" server. in the year we worked with them, they moved to
mountain view and changed their name. trivia question ... who had the
rights to their new name at the time? also what corporation was
providing substantial amount of funding for the commerce server?

minor posting drift with regard to the above period
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

SSL3 from the netscape web site
http://wp.netscape.com/eng/ssl3/ssl-toc.html

for TLS internet standards (aka standards version of SSL)
... there is my rfc index

http://www.garlic.com/~lynn/rfcietff.htm

in the RFCs listed by section, click on Term (term->RFC#)

in the Acronym fastpath, select "TLS"

transport layer security  (TLS )
 see also encryption , security
 3943 3788 3749 3734 3546 3436 3268 3207 2847 2830 2818 2817 2716
 2712 2595 2487 2246

clicking on the rfc number brings up the RFC summary. clicking on the
".txt=nnn" field in a RFC summary fetches the actual RFC.

with a little more searching you should be able to find detailed
descriptions of the various kinds of asymmetric cryptography and the
basic fundamentals involved (for instance ... you might start looking
for stuff about RSA at the RSA web site ... also certicom is possibly
a place to start looking for details about elliptical curve
(asymmetrical) cryptography.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

The 8008

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The 8008
Newsgroups: alt.folklore.urban,alt.folklore.computers
Date: Thu, 02 Jun 2005 07:38:32 -0600

forbin@dev.nul (Colonel Forbin) writes:

Lynn, you are a national treasure.

long ago and far away in another life/galaxy ... datamation had an
article claiming something about me being worth my weight in gold (not
sure who ... hasn't been for me) ... anyway sounded better than
national treasure.

some were blaming me for something that was being called *tandem
memos* (sort of an early mailing list, newsgroup thing ... about 25
yrs ago).

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

private key encryption - doubts

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: private key encryption - doubts
Newsgroups: comp.security.ssh
Date: Thu, 02 Jun 2005 07:42:28 -0600

"Yogee" writes:

I wanted to know about some open source projects, small ones which I
can study & if possible contribute something.

It would be of great help.
Just wanted to know more. You guys seem to be very much into this.

some history on charging for software (it used to be that almost all
... or at least large amounts of software was open source):
http://www.garlic.com/~lynn/2005g.html#51
http://www.garlic.com/~lynn/2005g.html#53
http://www.garlic.com/~lynn/2005g.html#54
http://www.garlic.com/~lynn/2005g.html#57

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

TSO replacement?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: TSO replacement?
Newsgroups: bit.listserv.ibm-main
Date: Thu, 02 Jun 2005 12:42:25 -0600

bblack@ibm-main.lst (Bruce Black) writes:

I think Ed has overstated it.  TSO is stabilized but supported, not
dead.  And ISPF is still being enhanced (although few enhancements
in recent years). --

guess who used to pay for ISPF development? it is an inside joke.
when every business operation had to show a profit ... a "strategic"
product that couldn't cover its own bills (customers would nver pay
what was actually necesary to cover the run rate of the operation
doing the development) would be combined with some real profit making
product(s) ... so the overall business operation showed a profit. at
one point ISPF was frequently held up as a prime example.

somewhat related to change-over to priced software that was permeating
the industry
http://www.garlic.com/~lynn/2005g.html#51
http://www.garlic.com/~lynn/2005g.html#53
http://www.garlic.com/~lynn/2005g.html#54
http://www.garlic.com/~lynn/2005g.html#57

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

TSO replacement?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: TSO replacement?
Newsgroups: bit.listserv.ibm-main
Date: Thu, 02 Jun 2005 13:50:58 -0600

howard@ibm-main.lst (Howard Brazee) writes:

Programmers are used to persuading our companies that they need to
pay for projects that individual customers are not willing to pay
for.

If people in charge of making purchases of systems believe TSO is
dead, then they will be more likely to go with systems that they
perceive having a future.  Which means IBM doesn't sell as many
systems, and our skills have less value.

this was picking up steam on in the mid to late 70s ... stuff deemed
strategic like ISPF ... previously could just be done because somebody
decided it should be done. in the mid to late 70s ... some number of
products got put on sound business footing with profit, cost
management, etc. this was extremely difficult transition for some
number of product operations that hadn't been used to operating under
such constraints.  thus was born the co-mingling gimmick for some
number of products.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Determinstic OpenSSL signature

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Determinstic OpenSSL signature
Newsgroups: sci.crypt
Date: Thu, 02 Jun 2005 15:27:44 -0600

bmoeller@acm.org (Bodo Moeller) writes:

Other examples: Apart from SSL, you must expect to find this kind of
padding in X.509 certificates using RSA signatures (it's not the
only scheme in use, but very common).  Also RSA signing in PGP uses
it.

one of the somewhat legacies of the 90s has been use of RSA in
infrastructures that might consider deploying hardware tokens (as a
integrity mechanism). the tokens from the era typically had very poor
random number capability ... which is required for key generation
... but also required by dsa and ecdsa for every signature generated.

In the RSA scenario, the infrastructures could implement token key
injection with the key generation happening on an external device with
reasonable random number capability.

there are some peculiarities of dsa/ecdsa signatures (because of the
random number) vis-a-vis RSA ... if somebody signed the same exact
data multiple times ... all the signatures would be different (and
non-deterministic)

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Request for comments - anti-phishing approach

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Request for comments - anti-phishing approach
Newsgroups: comp.security.misc
Date: Thu, 02 Jun 2005 19:27:05 -0600

Barry Margolin writes:

It says New Hampshire, but I'm in Massachusetts.  Better than New
Jersey, but still pretty far off.

I guess they have a list of the regions that Comcast has assigned
portions of their address space to, so they know this block is for New
England.  Durham is probably where some regional headquarters are.

and this is w/o even trying hard ... between the zombie armys that
could possibly be used as flavor of proxy/redirection ... and
rerouting traffic thru a remote dialup POP ... the geographic
discrepancies could get really significant

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

The 8008

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The 8008
Newsgroups: alt.folklore.computers
Date: Fri, 03 Jun 2005 07:58:54 -0600

Alexander Schreiber writes:

During my service time, I've had people explain to me that they
wanted to be tankers because of the supposedly pretty clear-cut
outcomes of battles: you either survive and get out pretty much
unharmed or if the tank gets killed you die pretty quick. No being
dragged from the battle field with body parts missing, a handfull of
shrapnel in your flesh, almost but not quite dying to survive as a
ruined wreck of a man crippled in war.

one of boyd's analysis
http://www.garlic.com/~lynn/subboyd.html#boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2

was the sherman/tiger duing ww2. he claimed that the tiger had
something like 5:1 kill ratio over the sherman ... but there was
conscious decision to stay with the shermans because they could
manufactur, crew, and deploy ten times as many ... more than making up
any 5:1 losses.

i had an uncle who lied about his age and went into army early and was
deployed tank maint. crew for effectively the whole period of the US
involvement in that conflict in europe.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Performance and Capacity Planning

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Performance and Capacity Planning
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 03 Jun 2005 08:05:44 -0600

p_hanrahan@ibm-main.lst (Paul Hanrahan) writes:

Anyone want to discuss LSPR, MIPS, RMF and SMF ? I found a free mips msu
chart at :

http://www.isham-research.co.uk/mips_z990.html

lots of past postings on performance tuning and management also
evolving into stuff they started calling capacity planning
http://www.garlic.com/~lynn/subtopic.html#bench

the HONE system
http://www.garlic.com/~lynn/subtopic.html#hone

eventually grew into worldwide field, sales, and marketing
support. one of the applications was an analytical model called the
performance predictor. salesman could take customer configuration,
workload, and performance data and feed it into the performance
predictor and ask what if questions about the effect of changing
hardware and/or workload.

of course, there were also the configurators ... which became
prerequisite for a salesman to even create a customer hardware order.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Performance and Capacity Planning

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Performance and Capacity Planning
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 03 Jun 2005 12:31:09 -0600

Eric-PHmining@ibm-main.lst (Eric Bielefeld) writes:

Two things.

1.  What is a NUMA machine.  How does being NUMA affect performance
or MIPS values.

2.  I still think that MIPS is a good measure of performance, if
used within the same line of computers.  If you compare the z/890,
or z/990 models, MIPS gives a good relative value of what to expect.
If you compare them to a 9672, it probably isn't as relevant.  The
fact the IBM, when announcing new hardware, usually prints MIPS in
their charts says that it is still a valid number.  I'm not saying
it is best, or that there isn't problems with MIPS, but the MIPS
numbers still make more sense to me than any other indicators.

Eric Bielefeld
P&H Mining Equipment

NUMA is non-uniform memory architecture.

basically take a small CEC (say one to four processor board) with its
own private memory. then create a second order memory bus that
interconnects multiple of the memories of multiple of such CECs in a
uniform memory addressing architecture.

the latency for a CEC to get at its local memory is much shorter than
the latency to get at memory located at a different CEC. the
addressing is uniform ... but the latency is different.

this is somewhat analogous to extended store on the 3090 ... where it
was the same memory technology but futher away and higher latency
... however in the 3090, it wasn't uniform addressing ... local memory
and extended store used different memory addressing and explicity
software management.

from an operational standpoint ... it somewhat harks back to LCS from
the 360 days. You could get 8mbytes of 8mic letency memory from Ampex
(and other vendors) that attached to various 360 models.  (they were
found on some number of 360/65s and 360/75s where the normal memory
latency was .75mics ... 750ns).

in the late 80s time-frame and early 90s ... about the same time LLNL
was pushing serial fiber channel into becoming a standard, people at
SLAC was pushing SCI into being a standard. FCS & SCI used similar
fiber hardware technology .... however, SCI developed architectures
for asynchronous bus operation over fiber links (rather than just
simply asynchronous i/o operation over fiber links). SCI asynchronous
memory bus architecture supported 64 ports.

Convex used SCI and HP two-processor snake boards to build 128-way
system. Sequent and DG used SCI and pentium 4-processor boards to
build 256-way systems.

Convex evolved a version of MACH (from CMU) for support the 128-way
Exampler ... and supported some of the same thruput trade-off
decisions that should be familiar to people doing LCS support in 360
days (did you execute directly in LCS ... or copy to higher-speed
storage for execution). Some of NUMA thruput issues are analogous to
cache considerations ... thruput is affected by latency.

Sequent enhanced their Dynix UNIX system that they had developed for
supporting up to 32-way "uniform" SMP operation.

Since that time, HP absorbed Convex, DG has gone away (there is some
legacy of their disk raid products around) and IBM has bought
Sequent.

We were somewhat involved in both of these fiber efforts (fiber
channel standard and SCI).

random past fcs, sci, &/or numa posts:
http://www.garlic.com/~lynn/95.html#13 SSA
http://www.garlic.com/~lynn/96.html#8 Why Do Mainframes Exist ???
http://www.garlic.com/~lynn/96.html#15 tcp/ip
http://www.garlic.com/~lynn/96.html#25 SGI O2 and Origin system announcements
http://www.garlic.com/~lynn/98.html#40 Comparison Cluster vs SMP?
http://www.garlic.com/~lynn/99.html#126 Dispute about Internet's origins
http://www.garlic.com/~lynn/2000c.html#56 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000e.html#17 X.25 lost out to the Internet - Why?
http://www.garlic.com/~lynn/2001b.html#39 John Mashey's greatest hits
http://www.garlic.com/~lynn/2001b.html#85 what makes a cpu fast
http://www.garlic.com/~lynn/2001f.html#11 Climate, US, Japan & supers query
http://www.garlic.com/~lynn/2001j.html#12 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001j.html#17 I hate Compaq
http://www.garlic.com/~lynn/2001l.html#16 Disappointed
http://www.garlic.com/~lynn/2001m.html#25 ESCON Data Transfer Rate
http://www.garlic.com/~lynn/2002e.html#32 What goes into a 3090?
http://www.garlic.com/~lynn/2002g.html#10 "Soul of a New Machine" Computer?
http://www.garlic.com/~lynn/2002h.html#42 Looking for Software/Documentation for an Opus 32032 Card
http://www.garlic.com/~lynn/2002h.html#78 Q: Is there any interest for vintage Byte Magazines from 1983
http://www.garlic.com/~lynn/2002i.html#83 HONE
http://www.garlic.com/~lynn/2002j.html#45 M$ SMP and old time IBM's LCMP
http://www.garlic.com/~lynn/2002j.html#78 Future interconnects
http://www.garlic.com/~lynn/2002l.html#52 Itanium2 performance data from SGI
http://www.garlic.com/~lynn/2002p.html#8 Sci Fi again
http://www.garlic.com/~lynn/2002p.html#30 Sci Fi again
http://www.garlic.com/~lynn/2002q.html#6 Sci Fi again was:  THIS WEEKEND: VINTAGE
http://www.garlic.com/~lynn/2002q.html#8 Sci Fi again was:  THIS WEEKEND: VINTAGE
http://www.garlic.com/~lynn/2003b.html#2 Disk drives as commodities. Was Re: Yamhill
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/2003.html#0 Clustering ( was Re: Interconnect speeds )
http://www.garlic.com/~lynn/2003.html#6 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#39 Flex Question
http://www.garlic.com/~lynn/2003j.html#65 Cost of Message Passing ?
http://www.garlic.com/~lynn/2003p.html#16 Star Trek, time travel, and such
http://www.garlic.com/~lynn/2003p.html#30 Not A Survey Question
http://www.garlic.com/~lynn/2004c.html#37 Memory Affinity
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/2004e.html#2 Expanded Storage
http://www.garlic.com/~lynn/2004.html#0 comp.arch classic: the 10-bit byte
http://www.garlic.com/~lynn/2004.html#1 Saturation Design Point
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/2005e.html#12 Device and channel
http://www.garlic.com/~lynn/2005e.html#19 Device and channel
http://www.garlic.com/~lynn/2005f.html#18 Is Supercomputing Possible?
http://www.garlic.com/~lynn/2005h.html#7 IBM 360 channel assignments
http://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new?
http://www.garlic.com/~lynn/2005.html#38 something like a CTC on a PC
http://www.garlic.com/~lynn/2005.html#40 clusters vs shared-memory (was: Re: CAS and LL/SC (was Re: High Level Assembler for MVS & VM & VSE))
http://www.garlic.com/~lynn/2005.html#48 [OT?] FBI Virtual Case File is even possible?
http://www.garlic.com/~lynn/2005.html#50 something like a CTC on a PC

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

The 8008

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The 8008
Newsgroups: alt.folklore.computers
Date: Fri, 03 Jun 2005 12:36:32 -0600

rpl writes:

Shermans were *much* more maneuverable (and numerous) than Tigers; I
don't think that figure is based on Sherman/Tiger confrontations
which would be the ideal metric, but possibly "total armour kills",
calculated by number of enemy armour kills per Tiger vs number of
enemy armour kills per Sherman.

one comment was that tiger could take out a sherman ... hitting it
just about anyplace ... but the sherman couldn't take out a tiger
front-on ... sherman was pretty much limited to shooting a tiger in
the back from behind to be effective (relative size of the guns and
the placement and amount of armor).

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

The 8008

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The 8008
Newsgroups: alt.folklore.computers
Date: Fri, 03 Jun 2005 13:38:54 -0600

boyd did get something of his way on the tank use subject ...  winning
out with the battle plan for desert storm (I). rumor is that a quote
about a problem going into desert storm (II) was that boyd had died
during the interval.

my boyd related posts
http://www.garlic.com/~lynn/subboyd.html#boyd

one of my first boyd postings ... although i had met him
many years earlier
http://www.garlic.com/~lynn/94.html#8

it mentions a US News & Report article about John during desert
storm "The Fight To Change How America Fights" with minor reference to
the new crops of maj. & cols. (that may have heard him in some war
college class or another) as his jedi knights.

other boyd related posts from around the web
http://www.garlic.com/~lynn/subboyd.html#boyd2

some specific from above:
How Col. John Boyd Beat the Generals
http://www.insightmag.com/media/paper441/news/2002/09/02/National/How-Col.John.Boyd.Beat.The.Generals-260509.shtml
Don't take John Boyd's name in vain
http://www.enterstageright.com/archive/articles/0503/0503boyd.htm
Col. John R. Boyd, USAF (ret.) died in West Palm Beach Florida on
Sunday, 9 March 1997.
http://www.belisarius.com/

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Performance and Capacity Planning

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Performance and Capacity Planning
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 03 Jun 2005 14:24:39 -0600

Eric-PHmining@ibm-main.lst (Eric Bielefeld) writes:

MIPS have been around a lot longer than MSUs.  They are more
familiar to me, which is why I like them.  I still remember my 158
with an attached processor.  The main CPU alone gave 1 MIP, and with
the AP, it was 1.8 MIPS.  Back in 1980, that was a good sized
machine.

ok, nominal 158 was nominally one mip machine based on various kinds
of avg. workload mixes and avg. measure cache hit/miss ratios.

ibm two-way processors were extremely strict memory coherency
archiecture .... most of the numa architectures had slightly more
relaxed memory coherency architecutre ... another posting from
this thread:
http://www.garlic.com/~lynn/2005j.html#13 Performance and Capacity Planning

in any case, when IBM did two processor smp (on 370 cache machines)
... they slowed each processor down by 10% to allow for cross-cache
chatter latency (used to maintain strong memory chherency). There
might be additional cache degradation if the caches were actually
broadcasting cross cache invalidates. As a result ... an 370
two-processor system was rated at basic 1.8 of a single processor
system (to account for the minimum, basic delays for handling
cross-cache chatter). There may be additional hardware degradation
from actually running two caches spitting cross-cache invalidates back
& forth at each other. Then there was most SMP kernels had additional
cross-cpu chatter protocols which further limited workload
thruput. Actual workload thruput on a two-process 370 smp could be
expected to be 1.5 times or less than that of a one processor.

so i did a lot of work on doing SMP kernel support and one of my early
test machines was a production 158AP at the consolidated US HONE
complex in cal (when 158AP was first announced and shipped)
http://www.garlic.com/~lynn/subtopic.html#hone

... HONE was by then the worldwide field, sales, and marketing support
vehicle.

I did some slight of hand in the SMP support ... and (from hardware
monitor) was getting about 1.5MIPS out of one processor and 0.9MIPS
out of the other processor (or a 2.4 aggregate MIPS). Some of the
slight of hand was to schedule various parts of the workload so it ran
for longer consecutive periods ... as a result had higher cache hit
rate ... and therefor higher MIP rate. That was coupled with hiding
and/or making the kernel cross-processor chatter almost non-existant
... so the effective workload thruput characteristics on a SMP was
very close to a UP kernel workload thruput (drastically minimizing
kernel overhead for operating multiprocessor configuration). lots
of SMP postings
http://www.garlic.com/~lynn/subtopic.html#smp

Note this was different than a TSS/360 claim from the early 70s.
TSS/360 on the 360/67 was supposedly the strategic product ... and
cp/67 (virtual machines, precursor to lpars, etc) from the cambridge
science center
http://www.garlic.com/~lynn/subtopic.html#545tech

was an uninvited interloper ... at one point when there was 12 people
working on cp/cms there were supposedly 1200 people working on
tss/360.

In any case, on a uniprocessor 360/67, tss/360 was getting worse
performnce supporting 4 interactive users doing approx. the same mixed
workload (edit, complie, exec) as cp/cms was doing supporting 35
users.  Part of the problem was that on a 1mbyte 360/67 ... the
tss/360 fixed kernel requirements left very little for application
paging.

In any case, tss/360 did a benchmark on a 2mbyte, 2processor 360/67
that showed 3.8 times the thruput of tss/360 on a 1mbyte 1 processor
360/67. The result was a big claim that tss/360 had fantastic
multiprocessor support ... that could make two processors run four
times faster. The actual issue was that on a 2mbyte configuration,
tss/360 almost had enuf room (left over after fixed kernel
requirements) for executing application programs.

now along comes 3081 ... which is suppose to never have a uniprocessor
version ... only the two processor 3081 (and a pair of 3081s for a
four-processor 3084). the 3081 had the typical slowed down processor
running at 90 percent to allow for the cross-cache chatter. However
TPF (airline control program, acp, etc), didn't have multiprocessor
support at the time ... and many TPF systems were already running on
the largest uniprocessors available (although in cluster mode ...
something like the big, massive HONE complexes ... which were some of
the biggest single-system-images at the time). TPF customers couldn't
really utilize 3081s ... they either ran with the 2nd cpu idle ... or
they ran under VM/370 ... with effectively two copies of TPF in
virtual machines ... one for each real processor. Although it wasn't
planned, IBM finally came out with a single-processor 3083 (primarily
for the TPF crowd) ... with the 2nd processor removed and slow-down
for cross-cache chatter removed ... so the processor ran at full-speed
rather than 90percent.

there was some additional work done in the 3081 on kernel structures.
prior to 3081 ... most kernels storage allication was done w/o regard
to cache line boundaries. there was some analysis that if two
different storage areas were allocated overlapping in the same cache
line ... and two different processors were accessing the two different
areas concurrently .... processor performance radically degraded.
There was a big effort to re-organize kernel storage allocation so
that it was cache alined and in multiples of cache lines (minimizing
the cross-cache thrashing that was going on) This change is claimed to
have improved overall customer thruput by five percent.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Performance and Capacity Planning

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Performance and Capacity Planning
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 03 Jun 2005 15:39:04 -0600

ibm-main@ibm-main.lst (ibm-main) writes:

These issues are not new - all the "joined" complexes (APs and MPs)
showed the same problem.  Attempts were even made to amerliorate
this (in the field) via CPU affinity.  Running on the "wrong"
(i.e. attached) processor on an AP involved significant overhead.
The effect can be best seen by comparing the MIP rating of a
(partitionable) MP with it's component "halves".

Learn from history folks.

however, the 370 two-processor afinity was not because of non-uniform
memory access ... afinity was oriented towards

1) cache hit consistency ... constantly swtiching from one processor
to another, could play havoc with cache hit ratios ... memory latency
introduced by cache misses is similar but different to variation in
memory latency because of NUMA).

2) on two-processor, AP ... only one processor had connected channels,
the other processor had no channels and no i/o capability and had to
pass off i/o requests to the i/o capable processor. i/o intensive
application could benefit with afinity to the processor with attached
channels. In some cases, there could be similar situation in MP
configuration, where there wasn't exactly symmetrical channel
configurations on the two processors and one processor had unique I/O
capability not found on the other.

recent posts
http://www.garlic.com/~lynn/2005j.html#12 Performance and Capacity Planning
http://www.garlic.com/~lynn/2005j.html#13 Performance and Capacity Planning
http://www.garlic.com/~lynn/2005j.html#16 Performance and Capacity Planning

now there is some more to the 3081 tale started in an earlier post.
as a temporary patch for TPF not having SMP support ... they reworked
the VM multiprocessor support ... putting in some stuff tailored
specifically for TPF under VM (that degraded the thruput for almost
everybody else).

Normally, when TPF did an I/O operation, it would enter the VM kernel
and do all the I/O emulation, ccwtrans, etc ... before returning to
executing the TPF virtual machine. If the only workload was a single
TPF virtual machine ... this left the other 3081 processor idle with
little or nothing to do. So they reworked the VM kernel SMP support so
that very shortly after entering the kernel ... it would do a SIGP
(signal processor) to the other processor ... and then if it try and
pass off the I/O emulation workload to kernel code running on the
other processor ... while returning immediately to the TPF virtual
machine (all falling with the architecture constraints defined for
asynchronous operation of the SIOF instruction). This way you got some
two processor concurrent operation ... one processor doing some VM
kernel I/O emulation overlapped with the other processor running the
TPF virtual machine.

The downside was that the majority of the customers that had normal
workload mix and had already been keeping both 3081 processors busy
anyway ... started seeing (a new) ten percent (elapsed time) of both
processors being spent on the new SIGP signalling and the SIGP
interrupt handling and processing (just about the sole purpose was to
provide some processing overlap specifically for customers with only a
single TPF virtual machine as the primary workload).

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Repository for digital certificates

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Repository for digital certificates
Newsgroups: comp.security.misc
Date: Fri, 03 Jun 2005 15:17:25 -0600

smveloso writes:

First of all, I apologize if this is not the right forum to post this
question...

I need to create a repository to allow users (and programs) access to
digital certificates. I thought about an LDAP server, a database with a
web front-end, etc... but is there a *standard* way to do this ?

supposedly x.500 dap and x.509 identity digital certificates went
hand-in-hand. first time i remember paying much attention when the
subject was brought up at an acm sigmod conference and somebody
explained it as a bunch of networking engineers attempting to recreate
1960s database technology.

one of the things that started to dawn about these x.500/x.509
design points were that horendous amounts of identity related information in
x.500 & x.509 raised significant privacy concerns.

later ... "lightweight" dap (ldap) came along.

there is this funny cross-over between trusted repositories of
certificates and trusted repositories of certificatelss public keys
...  making the original design point of x.509 certificates, redundant
and superfluous.

from my rfc index
http://www.garlic.com/~lynn/rfcietff.htm

in the RFCs listed by click on Term (term->RFC#)

and select "LDAP" from the Acronym fastpath

lightweight directory access protocol  (LDAP ) (LDAPv2) (LDAPv3 )
  see also ITU directory service protocol , directory
  3928 3909 3876 3866 3829 3771 3727 3712 3703 3698 3687 3674 3673
  3672 3671 3663 3494 3384 3383 3377 3352 3296 3112 3088 3062 3060
  3045 2927 2926 2891 2849 2830 2829 2820 2798 2739 2714 2713 2696
  2657 2649 2596 2589 2587 2559 2307 2256 2255 2254 2253 2252 2251
  2247 2164 1960 1959 1823 1798 1778 1777 1558 1487 1249

selecting on any of the RFC numbers brings up the RFC summary.
selecting on the ".txt=nnnn" field retrieves the actual RFC.

another kind of certificate-less approach
http://www.garlic.com/~lynn/subpubkey.html#certless

for public key authenticatin ... is to register public keys in a
RADIUS infrastructure ... in lieu of shared-secrets, passwords, etc
and perform digital signature verification with the onfile public key.
RADIUS supports lots of authentication clients accessing a RADIUS
trusted repository for both authentication as well as authorization
information (w/o necessarily exposing sensitive information to
wide-open population).

again from my RFC index ... in the Term (term->RFC#) page,
select "RADIUS" from the Acronym fastpath.

remote authentication dial in user service  (RADIUS )
  see also authentication , network access server , network services
  4014 3580 3579 3576 3575 3162 2882 2869 2868 2867 2866 2865 2809
  2621 2620 2619 2618 2548 2139 2138 2059 2058

note that RADIUS was originally developed by Livingston for their line
of dail-up modem pool products. It has since become an IETF standard
and expanded to meet much more generalized authentication and
authorization requirements.

and (also from the Term (term->RFC#) page, standards work
on generalized authentication, authorization and
accounting

Authentication, Authorization and Accounting
  see also accounting , authentication , authorization
  3588 3539 3127 2989 2977 2906 2905 2904 2903

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Performance and Capacity Planning

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Performance and Capacity Planning
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 03 Jun 2005 18:17:57 -0600

edjaffe@ibm-main.lst (Edward E. Jaffe) writes:

From
http://bama.ua.edu/cgi-bin/wa?A2=ind0506&L=ibm-main&P=R11281

"Customers generally prefer software that can help them ensure the
terms and conditions of their license agreements are being met. Such
software helps customers avoid liability and breach of contract
issues. For capacity-based licenses, hardware reporting of serial
numbers, LPAR names, and capacity (in MSU) makes that possible!"

then for a little more drift ... some recent posts on (some)
history of software licensing/pricing
http://www.garlic.com/~lynn/2005g.html#51
http://www.garlic.com/~lynn/2005g.html#53
http://www.garlic.com/~lynn/2005g.html#54
http://www.garlic.com/~lynn/2005g.html#55
http://www.garlic.com/~lynn/2005g.html#57

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Blinky lights WAS: The SR-71 Blackbird was designed ENTIRELY

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Blinky lights  WAS: The SR-71 Blackbird was designed ENTIRELY
 with slide rules. (fwd)
Newsgroups: alt.folklore.computers
Date: Sat, 04 Jun 2005 10:48:20 -0600

Charles Shannon Hendrix writes:

The same thing applies to things like LDAP: *lightweight* directory
access protocol.

LDAP is a heavy protocol despite the name.

However, if you look at the X.500 stuff where it came from, then it does
appear to be light after all.

recent post in different n.g. on the subject
http://www.garlic.com/~lynn/2004j.html#18 Repository for digital signatures

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Blinky lights WAS: The SR-71 Blackbird was designed ENTIRELY

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Blinky lights  WAS: The SR-71 Blackbird was designed ENTIRELY
 with slide rules. (fwd)
Newsgroups: alt.folklore.computers
Date: Sat, 04 Jun 2005 11:05:05 -0600

Anne & Lynn Wheeler writes:

recent post in different n.g. on the subject
http://www.garlic.com/~lynn/2004j.html#18 Repository for digital signatures

finger slip
http://www.garlic.com/~lynn/2005j.html#18 Repository for digital signatures

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Public disclosure of discovered vulnerabilities

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Public disclosure of discovered vulnerabilities
Newsgroups: sci.crypt,comp.arch
Date: Sat, 04 Jun 2005 11:00:37 -0600

"John E. Hadstate" writes:

I disagree, David.  It is pretty much that simple.  It's
just common sense.  If C were a "terribly flawed" language,
who would use it?  In one way or another, it would be a too
expensive luxury, and people would have long ago moved on to
less flawed languages.

For some purposes, there are better languages, better in the
sense that they restrict the range of implementation options
and thus reduce the number of instances of results that are
implementation-dependent.  The leading candidate in this
category is Java.  But people who program in Java do so
because they like the portability (lack of variation among
implementations) and they have no need to do the things that
Java and the JVM prevent them from doing.

there are some things that can require very little upfront effort and
ease of use ... that might not be applicable for industrial strength
operations .... in another domain ... say like using vw beetle for
heavy freight hauling. something can have enormous short comings
... and be terribly flawed for industrial operations ... and still
become widespread, if the up front effort to use it is very low

a little thread drift related to industry strength data processing
thread in c.d.t
http://www.garlic.com/~lynn/2005i.html#42
http://www.garlic.com/~lynn/2005i.html#43

it doesn't mean that it is impossible to use a beetle for heavy
freight hauling ... in fact ... one could imagine all sorts of
folklore growing up about the tricks, optimization and procedures for
heavy freight hauling with beetles.

however, the ease of entry level use can be more than offset by
extensive and time-consuming manual compensation required when
applying the solution to industrial operations.

lots of past postings on buffer overflow vulnerabilities and exploits
http://www.garlic.com/~lynn/subintegrity.html#overflow

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Public disclosure of discovered vulnerabilities

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Public disclosure of discovered vulnerabilities
Newsgroups: sci.crypt,comp.arch
Date: Sat, 04 Jun 2005 11:03:31 -0600

"Del Cecchi" writes:

For the same reason we put airbags in cars and blade guards on table
saws and GFIs on outlets: so that a mistake doesn't have such
disasterous consequences.  If you don't understand that there is no
help for you or anything you touch.

the seatbelt (and similar) analogy has been repeatedly used in
numerous of these threads ... large collection from the past
http://www.garlic.com/~lynn/subintegrity.html#overflow

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Public disclosure of discovered vulnerabilities

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Public disclosure of discovered vulnerabilities
Newsgroups: sci.crypt,comp.arch
Date: Sat, 04 Jun 2005 11:33:46 -0600

... this actually might be a case of real programmers ...

past posting of real programmers don't eat quiche in this n.g.
http://www.garlic.com/~lynn/2001e.html#31 High Level Language Systems

i got complaints because of the mountain boot issue ... when research
was still in bldg. 28 and before 85 was built, i would walk to work
along cottle ..  where 85 currently is had no sidewalks ... and during
the rainy season the treads of my boots would pick up quite a bit of
mud ... which during the course of the day would be deposited in the
halls of bldg. 28.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

IBM Plugs Big Iron to the College Crowd

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Plugs Big Iron to the College Crowd
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 04 Jun 2005 13:42:51 -0600

bob.shannon@ibm-main.lst (Bob Shannon) writes:

> I have been told that most of the folks at the Cambridge Scientific
> Center who were asked, post-decree, to transfer to
> Yorktown Heights ended up at Route 128 minicomputer
> companies.

Some years ago Melinda Varian published a paper on the History of VM. It
chronicles the activities at the Cambridge Scientific Center.
Fascinating story.

http://www.princeton.edu/~melinda/25paper.pdf

Bob Shannon

the cp67 group was split off from the science center and morphed into
vm370 group and took over the boston programming center on the 3rd
floor (absorbing most of the people). they outgrew the 3rd floor and
moved out to the old sbc bldg. in burlington mall.

in one of the attacks that there were going for there to be no more
vm370 product (and that to meet the 370-xa schedule, mvs/xa needed
virtual machine support), the decision was made to close down the
burlingon mall group (and vm370 product) and move all the people to
pok to work on the internal only "vmtool" (would never be released as
a product and only be used for internal mvs/xa development).

there was lots of protests from various corners ... and it was
somewhat decided that endicott could have a few of the people and
continue along a little with a vm370 product (the rest were still
needed in pok to support mvs/xa development) .

lots of past posts about science center
http://www.garlic.com/~lynn/subtopic.html#545tech

there is some joke that the person that made the decision to close
burlington mall and kill vm370 was a major contributor to vms (in
terms of number of people).

somebody had leaked the decision about closing burlington and killing
the vm370 product to the people at burlington mall a couple months
before it was announced.  there was a big investigation for the source
of that leak (sort of a mini deep throat).

there was also some jokes about the person who was given the task of
actually closing burlington location ... not too long earlier they had
the job of closing down the programming language group (in the time
bldg in manhatten).

later the science center moved out of 545 tech sq. down a couple
blocks to 101 main street. before that happened, some number of us
had transferred to the west coast

later, my wife and I had started ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp

and began subcontracting some of the work to three former people from
the science center who had formed a small software company. this grew
in size and scope ... so that when the science center was actually
shutdown ... they were able to move in and take over the science
center qtrs at 101 main st. at this point you are into the OSF
time-frame ... so you find some number of the science center people
show up in OSF organization (as well as the ha/cmp subcontractor
hiring some).  quite some number now appear to be working at state
street.

other stuff from the science center was the invention of gml (& sgml)
... the precursor to current xml
http://www.garlic.com/~lynn/subtopic.html#sgml

and the internal network ... which was larger than the arpanet/internet
from just about the start until sometime mid-85
http://www.garlic.com/~lynn/subnetwork.html#internalnet

and the technology basis used in bitnet/earn
http://www.garlic.com/~lynn/subnetwork.html#bitnet

the science center also did the port of apl\360 to cms\apl and rewrote
various bits and pieces to adapt it to virtual memory environment.
this became the original basis for HONE ... original cp67/cms and a
lot of cms\apl applications ... which evolved into world-wide platform
supporting all field, sales, and marketing (eventually mainframe order
contracts couldn't even being generated w/o being run on HONE)
http://www.garlic.com/~lynn/subtopic.html#hone

also out of the sciecne center was a lot of the performance tuning
and management technology morphing into capacity planning
http://www.garlic.com/~lynn/subtopic.html#bench

and of course compare&swap was invented by charlie at the science
center (the choice of compare&swap mnemonic are because "CAS" are
charlie's initials:
http://www.garlic.com/~lynn/subtopic.html#smp

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

IBM Plugs Big Iron to the College Crowd

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Plugs Big Iron to the College Crowd
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 04 Jun 2005 14:18:05 -0600

j.grout@ibm-main.lst (John R. Grout) writes:

Until a consent decree made them keep their distance, IBM did lots
of university work, including discounts, donations and collaborative
research.  I have been told that most of the folks at the Cambridge
Scientific Center who were asked, post-decree, to transfer to
Yorktown Heights ended up at Route 128 minicomputer companies.

ref:
http://www.garlic.com/~lynn/2005j.html#25 IBM Plugs Big Iron to the College Crowd

note in the early 80s, ibm had formed "ACIS" ... which was told to
hire a couple people to give away $XXXm to universities.

out of that ... IBM (equally with DEC) funded project athena to the
tune of $25m (matched by $25m from dec). out of that you got
x-windows, kerberos, and some number of other things.

cmu got $50m ... out of that came mach, camelot, andrew filesystem,
andrew widgets, etc. mach was used by convex for exampler numa
machine ... recent mention:
http://www.garlic.com/~lynn/2005j.html#13 Performance and Capacity Planning
mach was also used for NeXT machine and is the basis for current
apple operating system.

acis group also started doing a port of bsd to 370. along the way that
was retargeted to pc/rt and named "AOS". this caused a little
heartburn for the AIX group in austin ... since they had claimed that
something like 120 people were needed to program the VRM in PL.8 as an
abstract machine layer for speeding up and simplifying the porting
(AT&T) unix to the pc/rt (acis group doing the bsd port to bare
hardware faster and less resources).

The acis group also redid JFS filesystem so that it didn't use the
special 6000 hardware. The austin AIX group claimed the special 6000
hardware was required to make JFS perform ... ACIS showed JFS w/o the
special hardware outperforming JFS using the special hardware.

ACIS also did the work that took UCLAs locus and produced AIX/370 and
AIX/PS2.

a few other past posts mentioning acis:
http://www.garlic.com/~lynn/98.html#35a Drive letters
http://www.garlic.com/~lynn/98.html#37 What is MVS/ESA?
http://www.garlic.com/~lynn/99.html#64 Old naked woman ASCII art
http://www.garlic.com/~lynn/2001f.html#1 Anybody remember the wonderful PC/IX operating system?
http://www.garlic.com/~lynn/2003d.html#9 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003h.html#52 Question about Unix "heritage"
http://www.garlic.com/~lynn/2003h.html#53 Question about Unix "heritage"
http://www.garlic.com/~lynn/2004d.html#57 If you're going to bullshit, eschew moderation
http://www.garlic.com/~lynn/2004n.html#19 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#20 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#30 First single chip 32-bit microprocessor
http://www.garlic.com/~lynn/2004p.html#53 Integer types for 128-bit addressing
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?

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Public disclosure of discovered vulnerabilities

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Public disclosure of discovered vulnerabilities
Newsgroups: sci.crypt,comp.arch
Date: Sat, 04 Jun 2005 14:40:40 -0600

"Del Cecchi" writes:

I was replying to the assertion that C "is not that bad", and it is a
long way from "terribly flawed" when in fact if it was a power tool,
the manufacturer would long ago have been bankrupted by the product
liability lawsuits.  In fact I might go so far as to like C to
Asbestos.  It was really great and useful and widely used for many
years.  It wasn't until much later that the problems were realized.

there is also some similarity to the argument about the new (at the
time) safety requirements for farm machinary .... everybody knew that
the only poeple who stuck body parts into exposed machinary and got
themselves killed were total dullards (besides a little darwinism is
supposedly good for the species). futhermore, the extra cost for all
those extra safety doodads were going to put farmers out of business.

... and any subsequent statistically "evidence" about resulting
decrease in death rates wasn't actually proof. i managed to make it to
majority after having started operating various kinds of farm & other
heavy equipment around eight (when i could reach the starter peddle on
the floor ... some early electic starter motors ... before they were
connected to the key switch).

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

NASA Discovers Space Spies From the 60's

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: NASA Discovers Space Spies From the 60's
Newsgroups: alt.folklore.computers,bit.listserv.ibm-main
Date: Sat, 04 Jun 2005 15:32:44 -0600

NASA Discovers Space Spies From the 60's
http://science.slashdot.org/science/05/06/04/1721241.shtml?tid=160&tid=103&tid=1

the project was never explained to me that way ... but what do i know
(and besides, i was only an undergraduate at the time)

360/67 was announced with up to four-way smp. for the most part only
two-way smp processors were built as part of the standard product
line.

the standard 360/65 two-way processors were basically two standard
machines joined together with uniform addressing of all combined
memory (but each processor was otherwise mostly a uniprocessor with
private i/o channels ... multiprocessor i/o was simulated by having
control units with multi-channel connectivity ... one to a channel
connected to each processor).

the 360/67 multiprocessor was a different beast. it had independent
paths to memory for processors and the "channel controller". the
"channel controller" was a specialized box that could be configured to
put the configuration into multiprocessor configuration or split into
individual single processors ... with the switches set to what
components were offline/online and/or what resources were partitioned
to which configuration. a 360/67 multiprocessor not only could have
single, uniform addressing for all memory ... but also single uniform
addressing for all available channels in the configuration (all this
fancy stuff was dropped in the 370 generation and some of it didn't
reappear until 370/xa and 3081).

the standard 360/67 "control registers" allowed "sensing" of the
channel controller switches (i.e. storing specific control registers
gave you the switch settings on the channel controller).

Lockheed had part of the "MOL" contract ... and for them, a special
360/67 triplex was built. Among other special features, not only could
the channel controller switch settings be "sensed" (by storing the
appropriate control registers) ... but it was also possible for
software reconfiguration by loading different values into the
appropriate control registers.

in current architecture ... most of the control registers defined in
360/67 for channel controller operation ... have now been given over
to defining multiple virtual address spaces ... in support of all the
fancy cross virtual address space operation stuff.

a little mention of 360/67 control register use:
http://www.garlic.com/~lynn/2001.html#69 what is interrupt mask register?

scan of 360/67 functional characteristics
http://bitsavers.org/pdf/ibm/360/funcChar/A27-2719-0_360-67_funcChar.pdf

control registers are on page 16 ... 8-14 are the "Partitioning
Sensing Registers" (although it says to reference 2167 manual for
details)

misc. other past posting mentioning 360/67 "blue card"
http://www.garlic.com/~lynn/99.html#11 Old Computers
http://www.garlic.com/~lynn/2000g.html#16 360/370 instruction cycle time
http://www.garlic.com/~lynn/2001c.html#15 OS/360 (was LINUS for S/390)
http://www.garlic.com/~lynn/2001d.html#42 IBM was/is: Imitation...
http://www.garlic.com/~lynn/2001.html#71 what is interrupt mask register?
http://www.garlic.com/~lynn/2002f.html#54 WATFOR's Silver Anniversary
http://www.garlic.com/~lynn/2003l.html#25 IBM Manuals from the 1940's and 1950's
http://www.garlic.com/~lynn/2003m.html#31 SR 15,15 was: IEFBR14 Problems
http://www.garlic.com/~lynn/2003m.html#35 SR 15,15 was: IEFBR14 Problems
http://www.garlic.com/~lynn/2004e.html#51 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004.html#7 Dyadic
http://www.garlic.com/~lynn/2004l.html#65 computer industry scenairo before the invention of the PC?
http://www.garlic.com/~lynn/2005f.html#41 Moving assembler programs above the line

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

IBM Plugs Big Iron to the College Crowd

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Plugs Big Iron to the College Crowd
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sun, 05 Jun 2005 09:45:25 -0600

p_hanrahan@ibm-main.lst (Paul Hanrahan) writes:

The academic community made huge contributions to VM. However, the VM
developers did their share also.

Many of the IBM developers who were laid off in the early to mid
90's when IBM took a nose dive were excellent programmers.

IBM management was very wise in encouraging the user community to
develop a sense of ownership in products like VM.

there was the joke that (at one time) a significant percentage of ibm
products originated at datacenters (both customer and internal) which
were then handed over to "development" groups to maintain and support
as products.

at various times during the late 70s and the 80s, there were studies
of customer enhancements to VM (not in the product) compared to
internal corporate enhancements to VM (also not in the product).  the
summary was that the KLOCs of internally distributed vm enhancements
were about the same size as the KLOCs of customer distributed
enhancements (on things like share tape).

over the years there were sometimes easier avenues for internally
developed code to leak into the product (as opposed to customer
developed enhancements leaking into the product). part of the context
was that cp67 (and then vm) shipped as source and source
maintained. it wasn't until the OCO (object code only) issues starting
in the very late 70s that started to turn that around

the internal network was mostly VM-based machines and VM-based
networking ... with the batch operating system machines (& their
networking paradigm) mostly restricted to edge nodes.  some mention of
'83 and internal network hitting 1000th node:
http://www.garlic.com/~lynn/internet.htm#22

other internal network posts
http://www.garlic.com/~lynn/subnetwork.html#internalnet

besides the huge proliferation of vm use inside the company ...  there
was also the custom tailored HONE system that provided worldwide
support for field, sales, and marketing people (it quickly came to
pass that mainframe orders couldn't even be submitted w/o having
passed thru HONE). HONE was a large vm-based time-sharing service
supporting sales and marketing world wide.
http://www.garlic.com/~lynn/subtopic.html#hone

for over a decade, i had a hobby providing custom tailed operating
system and other stuff for HONE. i also assisted in the proliferation
around the world.  when EMEA hqtrs moved from the states to paris
... I handled much of the HONE cloning for the new hdqtrs in the new
bldg. in La Defense.  I got to work on the initial hone installation
in Japan.

in the 80s, some new, incoming HONE executive ran across some
reference to me ... and raised the issues about the worldwide HONE
infrastructure having dependency on single person's hobby, who wasn't
part of the organization and there were no MOUs between the different
responsible organizational executives (between HONE and whoever my
current chain of command might be at the time ...  who possibly didn't
even know what HONE was and/or that it existed).

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

IBM Plugs Big Iron to the College Crowd

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Plugs Big Iron to the College Crowd
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sun, 05 Jun 2005 09:21:32 -0600

ibm-main.04@ibm-main.lst (Leonard Woren) writes:

Back when I was working at the University of Southern California, which
had institutionalized animosity towards mainframes and IBM, I once got
a call from an MVS systems programmer working in the real world who was
interested in one of my freebie programs.  He had graduated from USC
with a degree in Computer Science and until he came across my program,
he didn't even know that USC had an IBM mainframe!  In USC Engineering,
it was taboo to even mention it.  From stories that I heard, I believe
this anti-IBM, anti-mainframe attitude was largely due to the high
costs of IBM systems and lack of meaningful educational discounts.  As
already mentioned here, IBM was giving 15% HESC discounts (but only
for VM software, none for MVS software!), while Sun was giving 85%
discounts.  And I don't think that IBM discounted the hardware at all.

So Aker's fixation on current quarter results came home to roost.
(Before that, IBM, like Japanese companies, understood that sometimes
you had forgo a little profit now to generate more later.)

back in the 60s ... there were regular 60 percent educational
discounts ... this was before the fed. gov. action and the unbundling
announcement of 6/23/69 .... which also started the process of
eliminating free software and moving to charge/license for software.

recent past posts about a view of transition from free software to
pricing/charging for software.
http://www.garlic.com/~lynn/2005g.html#51
http://www.garlic.com/~lynn/2005g.html#53
http://www.garlic.com/~lynn/2005g.html#54
http://www.garlic.com/~lynn/2005g.html#55
http://www.garlic.com/~lynn/2005g.html#57

the big acis money give-away to universities in the 80s ... never
really involved mainframes ... mostly lots of money (presumably tax
deductable but possibly various fed. redtape may have precluded
various kinds of restrictions on what the money could be spent for
... pure speculation ... I have no facts or information).

previous acis post in this thread
http://www.garlic.com/~lynn/2005j.html#26

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

was restricted from directly bidding on nsfnet1 rfp (i.e. high speed
backbone ... and also later nsfnet2 rfp upgrade) ...  although we did
get a nsf technical audit of what we had running which made some claim
that what we had running was at least five years ahead of all RFP
responses to build something new
http://www.garlic.com/~lynn/internet.htm#0

... there was other corporate involvement in pouring lots of resources
into nsfnet backbone (way over and above what nsf was actually paying
out on the rfp) ... again not particularly mainframe related. a few
posts related to nsfnet rfp (aka backbone that tied together the
regional networks, setting the stage for an "operational" internet
... in contrast to internet "technology"):
http://www.garlic.com/~lynn/2002k.html#12
http://www.garlic.com/~lynn/2000e.html#10

lots of other internet related posts
http://www.garlic.com/~lynn/subnetwork.html#internet

in the 80s ... ibm also a pumped a lot of resources into bitnet (in
the us) and earn (in europe)
http://www.garlic.com/~lynn/subnetwork.html#bitnet

old post specifically referring to the formation of earn
http://www.garlic.com/~lynn/2001h.html#65

bitnet/earn was oriented to using the technology used in the internal
network ... the internal network was larger than arpanet/bitnet
from just about the beginning until sometime mid-85
http://www.garlic.com/~lynn/subnetwork.html#internalnet

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Three-Address RISC, and Really Fast Addressing

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Three-Address RISC, and Really Fast Addressing
Newsgroups: comp.arch
Date: Sun, 05 Jun 2005 08:51:17 -0600

jsavard@excxn.aNOSPAMb.cdn.invalid (John Savard) writes:

It seemed to me that load-store RISC architectures were hugely
inefficient, requiring three instructions to do what a CISC machine can
do in one.

But RISC instructions do naturally map to what processors can dispatch
to pipelines.

i've characterized that 801/RISC was in some sense a re-action to
the failure of FS
http://www.garlic.com/~lynn/subtopic.html#futuresys

and its aggresively complex hardware design.

there were repeatedly statements about 801/risc in mid to late 70s
... about trading off software complexity for hardware simplicity (aka
moving stuff from hardware to software) ...  effectively a one-to-one
relationship between an instruction and simple hardware component
... which aided the compiler in laying out the optimization.  (this
was also in the days of chips with relatively minimum circuit counts
... so single chip cores couldn't be doing a lot anyway)/

besides software complexity being moved into pl.8 compiler ... the
chip also didn't have any security domain protection features; the
compiler would only generate secure code ... and the cp.r operating
system would only load and execute valid code.

later for romp chip ... some things had to be retrofitted to the chip
when it was decided to retarget it to the workstation market with a
relatively vanilla unix operating system with conventional security
domain requirements (separation of kernel and application).

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

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

IBM Plugs Big Iron to the College Crowd

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Plugs Big Iron to the College Crowd
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sun, 05 Jun 2005 10:59:44 -0600

ibm-main.04@ibm-main.lst (Leonard Woren) writes:

So Aker's fixation on current quarter results came home to roost.
(Before that, IBM, like Japanese companies, understood that sometimes
you had forgo a little profit now to generate more later.)

that really isn't fair to akers. during the 80s, ibm was pouring huge
amounts of money into universities and places like nsf projects
... with substantial productivity and long term benefits ... the
benefits just weren't mainframe and/or necessarily ibm specific.

misc. recent postings
http://www.garlic.com/~lynn/2005j.html#25 IBM Plugs Big Iron to the College Crowd
http://www.garlic.com/~lynn/2005j.html#26 IBM Plugs Big Iron to the College Crowd
http://www.garlic.com/~lynn/2005j.html#29 IBM Plugs Big Iron to the College Crowd
http://www.garlic.com/~lynn/2005j.html#30 IBM Plugs Big Iron to the College Crowd

in the mid-80s there were predictions that the business was going to
double its world-wide revenue from $60b/annum to $120b/annum and the
corporation embarked on massive new manufacturing facility building
program (in anticipation of doubling mainframe hardware sales). i
possibly made a career limiting move (at that time) by doing a
economic analysis of the commoditizing of computer hardware and
suggesting that the company was (instead) headed into the red.

it was similar ... but different to the analysis from 1970-era that
supposedly motivated FS
http://www.garlic.com/~lynn/subtopic.html#futuresys

attempted to do such an aggresive new technology and integration that
the controller clones wouldn't be able to keep up ... a couple
specific references on the subject (references to huge ibm R&D
overhead and not being competitive with the clone makers):
http://www.garlic.com/~lynn/2000f.html#16 [OT] FS - IBM Future System
http://www.garlic.com/~lynn/2003l.html#30 Secure OS Thoughts
http://www.garlic.com/~lynn/2003p.html#25 Mainframe Training

having worked on one of the original clone controller projects as an
undergraduate ... which subsequently was blamed for the clone/pcm
controller business market (and subsequently what motivated FS effort):
http://www.garlic.com/~lynn/subtopic.html#360pcm

it probably also wasn't very political during FS to characterize the
project as being a case of the inmates in charge of the institution
... somewhat referring to a long running cult film down in central sq.

from 88 into 92 or so ... when we were pitching 3-tier architecture
that we had invented (while many were pushing SAA and that real
client/server really wasn't needed ... just a thin, gui presentation
capability):
http://www.garlic.com/~lynn/subnetwork.html#3tier
and were doing the ha/cmp project
http://www.garlic.com/~lynn/subtopic.html#hacmp
as well as keeping our hand in networking and the hsdt project
http://www.garlic.com/~lynn/subnetwork.html#hsdt

we would periodically drop in on staff and executives in the new
somer's "pyramid power" building and talk about the unfolding
commoditizing of computer hardware and the effects it would have on
the computer business. i don't think it was a problem that they didn't
understand the issues ... it was possibly that so many had their
lifelong experiences and careers tied to mainframe business segment
... that they couldn't see a way to (personally) adapt.  i suspected
that many were (secretly?) hoping to retire before having to directly
confront the issues and then it would be somebody else's problem.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

IBM Plugs Big Iron to the College Crowd

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Plugs Big Iron to the College Crowd
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sun, 05 Jun 2005 16:12:53 -0600

Efinnell15 writes:

Early to mid 90's things really started going south. When BOCA
folded lots of them were reassigned to Back-office at Redmond and I
guess are still there. Then they decided to terminate HESC and
charge us commercial rates for everything while Sun and others were
discounting 85%. Then they took away PSR's and SE's and farmed out
the Marketing to ISV's competing against themselves and spreading
lots of FUD. As Windows matured and got colossal penetration, the CS
departments started teaching html and WEBdesign with JAVA and C++
and Frontpage as follow ups. No COBOL, ASM, Fortran, PL/1, JCL, etc
to be seen.

SAA in the late 80s and early 90s was still trying to put the
client/server genie back in the bottle
http://www.garlic.com/~lynn/subnetwork.html#3tier

along with pushing T/R configurations with 300 stations ... which help
support the concept of just sufficient aggregate bandwidth for doing
GUI to relatively thin clients.

this was also helping protect the established terminal emulation
paradigm and installed market.

in the mid-80s one of the senior people from the disk division gave a
presentation at an an annual, internal world-wide communication
division conference ... where he made the claim that the head of the
communication division was going to be responsible for the death of
the disk division.

the scenario was that terminal emulation provided an effective initial
market penetration stategy for the original PCs ... but as PCs
sophistication and PC applications matured ... the terminal emulation
paradigm was becoming a boat anchor. lots of environments with
evolving distributed applications were finding the terminal emulation
spiggot way too restrictive and were starting to replicate data out in
the distributed environment.  this created a big explosion in the
demand for disk drives out in the distributed environment and at the
same time contributed to a flatning of glass house disk (and
eventually application and other hardware) growth

the disk division created a number of products that would drastically
improve the ability for distributed processing to access data in the
glass house ... and nearly all of them were vetoed by the
communication division .... the disk division having strategic
responsibility for data within the glass house ... but the
communication division had strategic responsibility for connectivity
in excess of some distance, effectively anything leaving/entering the
glass house.

collection of past postings on the terminal emulation subject
http://www.garlic.com/~lynn/subnetwork.html#emulation

besides having proprietary protocols and terminal emulation install
base to protect ... a contributing issue was some number of large
establishments believed the official decrees by numerous world govs.
that tcp/ip would be eliminated and replaced by osi.

we were inolved in trying to get HSP (high speed protocol) as a work
iterm in x3s3.3 (iso chartered ansi organization responsible for
protocols relating to osi layer 3 & 4). ISO (& ISO chartered
organizations) had directive that standardization work couldn't be
done on stuff that violated the OSI model. HSP violated and was turned
down because of (at least):

1) hsp would go directly from transport interface to the lan mac
interface. the lan mac interface corresponded to somewhere in the
middle of layer 3/networking. hsp bypassed the layer3/layer4 interface
and therefor violated osi.

2) hsp would support internetworking (aka IP). internetworking doesn't
exist at all in the OSI model. supporting internetworking violates the
OSI model.

3) hsp would go directly from the transport interface to the lan mac
interface. the lan mac interface corresponds to approx. something in
the middle of osi layer 3/networking. lan mac interfaces violate OSI
model, therefor hsp supporting lan/mac interface also violated OSI
model.

misc collected postings on hsp, osi, etc
http://www.garlic.com/~lynn/subnetwork.html#xtphsp

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

IBM Plugs Big Iron to the College Crowd

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Plugs Big Iron to the College Crowd
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 06 Jun 2005 07:38:55 -0600

Efinnell15 writes:

Her Master Plumber Webpage(/~melinda) is instructional
in many aspects of 360/370 and 390 architecture. Hmm, where's
380?

370-xa ... introduced 31-bit virtual and uniform shared channel
addressing for multiprocessing.

note the 360/67 had both 24-bit and 32-bit virtual memory options
... and single uniform channel addressing capability for
multiprocessoring .

other 360 multiprocessing (and later 370) had a shared single uniform
addressing for memory ... but io/channels were processor specific.
shared i/o configuration was emulated by having multiple channel
attachments on control units (with different processor specific
channels going to shared control units).

it wasn't until you got to 370-xa ... that larger virtual memory
addressing re-appeared and all processors being able to uniformly
address all channels.

370-xa internally was commoningly referred to as 811 ... for 11/78
date on the various architecture/design documents. each copy was
individually numbered and had to be kept under double lock & key.
they were registered and periodically site security would come by and
"audit" all such documents.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

IBM Plugs Big Iron to the College Crowd

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Plugs Big Iron to the College Crowd
Newsgroups: bit.listserv.ibm-main
Date: Mon, 06 Jun 2005 09:26:31 -0600

Efinnell15 writes:

Her Master Plumber Webpage(/~melinda) is instructional
in many aspects of 360/370 and 390 architecture. Hmm, where's
380?

aka 370xa (or 811); part of this may have been ambivalence about
signaling any generation change. remember that 1/3rd to 1/2 of the 70s
had been taken up by FS ... which was killed before it was even
announced. FS was going to have been a bigger departure from 360/370
... than the 360 departure had been from prior generations.
http://www.garlic.com/~lynn/subtopic.html#futuresys

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

A second look at memory access alignment

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: A second look at memory access alignment
Newsgroups: comp.arch
Date: Mon, 06 Jun 2005 11:13:42 -0600

glen herrmannsfeldt writes:

There are some interesting cases in S/370 related to page
boundaries.  For most instructions, it is easy to see in advance
which pages are needed and to interrupt if they aren't available.
TR (translate) is one of the harder cases.  TR uses a 256 byte
translation table, and looks up each operand byte in the table and
replaces it with the value in the table.  As defined for S/360, it
isn't allowed to fail for parts of the translation table that aren't
actually used.  If the table crosses a page boundary a trial
execution is needed to determine which page will actually be
referenced, before any data is modified.

on 360/67 virtual memory hardware ... worst case was 8 page references
... execute instruction that crossed page boundary (2), target
instruction (of the execute) that crosse page boundary (2), SS
instruction where both storage operands crossed page boundaryh (4).
if fetch/store protect feature was installed on standard 360 ...  both
starting and ending storage operand locations would be checked for
permission before starting the instruction. in the 360/67 case, in
addition to checking starting and ending storage operand permissions,
it would check starting and ending storage operand for available page
(before starting instruction). for 360 maximum storage operand size
was 256 bytes ... standard 360 fetch/store protection feature was on
2k boundaries ... so storage operand couldn't overlap more than two
such 2k blocks; so only start and end checking was necessary.
Similarly, 360/67 used 4k virtual pages and 256 byte storage operand
could also only overlap maximum of two virtual pages (requiring only
start and end address of storage operand to be checked).

370 introduced a couple "long" instructions ... which were
interruptable and nominally defined to operate a byte at a time (with
the corresponding registers specified for address and length being
updated as the instruction progressed). "long" instructions were not
to precheck starting and ending storage operand addresses (as was the
case for 360 and all other 370 instructions) ... but check each
updated storage operand address as the instruction execution
progressed.

there was an early microcode bug in 370 models 115/125 ... where long
instructions were prechecking ending storage operand address prior to
starting instruction execution (contrary to architecture definition).
this caused problems for some coding sequence which was using fault
interrupt from a long instruction to determine available accessable
memory. Example was clearing available memory to zero ... and
interrupt with pointer to last allowable memory location. with 115/125
bug, it would interrupt before the instruction even started (and so
register pointer/length would not have been changed and appear to
indicate no allowable memory).

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

A second look at memory access alignment

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: A second look at memory access alignment
Newsgroups: comp.arch
Date: Mon, 06 Jun 2005 12:14:52 -0600

glen herrmannsfeldt writes:

What did the 360/67 do with TR?  Pages not referenced by actual
translation table entries are not required to exist.  S/370 carefully
defines this case, but I don't know that it was done for the 360/67.

the "table" storage operand was treated as a single 256 byte operand
... and prechecked the starting and ending address. a page fault
interrupt could occur for either the starting or ending
address. standard 360 fetch/store protect optional feature worked
similarly ...  the start & ending address of each storage operand
would be prechecked (and could result in store or fetch protection
interrupt ... only fetch protection in the case of the TR "table"
operand).

note that two successive page faults could happen in the case of the
TR table storage operand (or for that fact, any storage operand that
crossed a page boundary) ... the first page fault on the starting
address ... and then after the instruction was restarted, a second on
the ending address.

there was theoritical possibility that starting page could be stolen
during the fetch of the ending page ... resulting in additional page
faults.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

virtual 360/67 support in cp67

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: virtual 360/67 support in cp67
Newsgroups: alt.folklore.computers
Date: Mon, 06 Jun 2005 12:42:36 -0600

the early cp67 releases just provided support for "regular" 360
virtual machines .... i.e. virtual machines with standard 360 real
memory ... and did not support virtual machines with address
relocation hardware architecture found in 360/67 (aka you could run
cp67 on a real 360/67, but running cp67 in a virtual machine wasn't
supported).

in recent post about networking, bitnet, & earn
http://www.garlic.com/~lynn/2005j.html#30 IBM plugs Big Iron to the College Crowd

there was a reference to an old posting that included email
about the formation of earn
http://www.garlic.com/~lynn/2001h.html#65

the author of the subject email had many years earlier been on
assignment to the cambridge science center
http://www.garlic.com/~lynn/subtopic.html#545tech

and was responsible for adding support in cp67 for virtual machines
with address relocation hardware architecture. basically the
360/67 control registers had to be simulated ... recent reference:
http://www.garlic.com/~lynn/2005j.html#28 NASA Discovers Space Spies From the 60's

as well as "virtual" segment and page tables. Virtual address space
segment and page tables in the memory of the virtual machine would
have address translation from a virtual machine's virtual address
space (3rd level addresses) to some address within the memory of the
virtual machine (which was also virtual, aka 2nd level addresses).

Considering the real memory as "1st level addresses", and the virtual
machine addresses as "2nd level addresses", then a virtual machines,
virtual address space tables specified "3rd level
addresses". Simulating virtual machine address space relocation
hardware required building shadow segment and page tables (for the
3rd level addresses). The virtual address space tables in the virtual
machine translated from 3rd level addresses to 2nd level addresses.
The shadow segment and page tables, translated from 3rd level
addresses directly to (real machine) 1st level addresses. whenever the
virtual machine thought it was switching to its virtual address space
tables (in the memory of the virtual machine), the cp67 simulation
would actually switch to the shadow tables (that gave the 3rd level
to 1st level address translation).

misc. past posts mentioning virtual address space simulation with
shadow tables
http://www.garlic.com/~lynn/94.html#48 Rethinking Virtual Memory
http://www.garlic.com/~lynn/2002l.html#51 Handling variable page sizes?
http://www.garlic.com/~lynn/2003b.html#0 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003d.html#69 unix
http://www.garlic.com/~lynn/2003g.html#18 Multiple layers of virtual address translation
http://www.garlic.com/~lynn/2004c.html#35 Computer-oriented license plates
http://www.garlic.com/~lynn/2004l.html#67 Lock-free algorithms
http://www.garlic.com/~lynn/2004o.html#18 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005d.html#58 Virtual Machine Hardware
http://www.garlic.com/~lynn/2005d.html#66 Virtual Machine Hardware
http://www.garlic.com/~lynn/2005d.html#70 Virtual Machine Hardware
http://www.garlic.com/~lynn/2005h.html#11 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005h.html#17 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005h.html#18 Exceptions at basic block boundaries

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

A second look at memory access alignment

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: A second look at memory access alignment
Newsgroups: comp.arch
Date: Mon, 06 Jun 2005 18:05:45 -0600

glen herrmannsfeldt writes:

http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/dz9zr003/7.5.141

For TR it isn't supposed to access table entries not needed by
the source string.  For protection, that can be done during execution,
as there is no guarantee against partial execution before a protection
violation.   I suppose the likelihood of a translate table overlapping
the beginning or end of a region, such that one page does not exist,
is low.   This is described in Nick Tredennick's book describing
the design of the Micro/370 processor.

that is in current "Z/architecture" PoP ...  the original 360 PoP
doesn't make that statement about TR ... I remember being told that
for 360 ... all storage operands had their start&end addresses
prechecked ... and that incremental checking didn't occur until later
models.

the architecture redbook would have had the specifics ... the
architecture readbook was done in cms script with conditional
formating for whether you got the full architecture manual ... or just
printed the subsections that resulted in the PoP.

it use to have a section on instruction termination, cancel,
abrogation, etc.

The Z/architecture pop implies that you could have a partially
executed TR instruction i.e. fetch protection fault after some number
of bytes had been substituted/translated. This would be a problem for
page fault since there is no updated current pointer & length
field (as in the long instructions) for restarting the instruction ...
if you took a page fault after partial execution. In 360 ... the start
and end bounds were just checked before the instruction was even
started and incremental byte-by-byte checking didn't occur in 360.

The quoted Z/architecture pop description implies that if the 256 byte
table operate crosses a 4k boundary ... that the TR instruction will
make a preliminary dry run of every individual byte in the (to be
translated) source operand ... to see if a data pattern specific page
fault occurs (avoiding the case of a page fault with a partially
executed instruction that couldn't be correctly restarted).

I don't know when byte-by-byte TR instruction exution operand checking
was introduced ... but (modulo fading memory) I'm reasonably sure that
it wasn't on 360 or even 370. Neither the 360 nor the 370 PoP TR
instruction writeup makes references to the implied Z/architecture
case of interruption of a partially executed instruction (and/or
implied dry run execution for table within 256 bytes of the end of a
4k page). The precursor (to Z/architecutre) ESA/390 PoP does mention
it.

A frequent/common application for short table was half-byte hex to
character hex in storage displays ... i.e. expand half-byte nibbles
into adjacent bytes and translate hex nubmers x'0'-x'F' into
characters 0-9,A-F (only needed 16byte table ... and didn't need the
whole 256 byte table).

topic drift warning ....

all this has turned up something of possible interest.

segment protection (a bit in the segment table entry) and the ISTE and
IPTE instructions were dropped from the 370 virtual memory
architecture when the 165 engineers claimed that it would take an
extra six months for them to re-engineer the virtual memory retrofit
to 370/165s in the field (i.e. announced and shipped before 370
virtual memory). However, it was fully documented in the 370 redbook
(only with numerous other unannounced bits & pieces) ...  but not in
the PoP for general availability (all 370s that had already
implemented the dropped features were retrofitted to disable them so
that there was a common architecture across all 370s.

this caused a severe hardship for CMS ... which had been planning on
making use of segment protection for shared segments (lots of cms
interactive virtual machines all utilizing common kernel code
... instead of requiring a unique copy for every virtual address
space).

now check this out in the esa/390 PoP appendix section on differences
between 370 and 370/xa
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/F.1.4?SHELF=EZ2HW125&DT=19970613131822

F.1.4 Page Protection

 A page-protection bit is provided in the page-table entry.  Page
 protection can be used in a manner similar to the System/370
 segment protection, which is not included in 370-XA.

......

W/o the planned segment protection bit for 370 ... CMS had to go thru
extremely painful contortions in order to provide shared segment
protection across different virtual address spaces.

I just checked 370 PoP, GA22-7000-4, Sep75 (revsied 9/1/75, by TNL
GN22-0498) (originally pulled off bitsavers.org), pg. 59 that gives
format/definition of segment-table entries ... which specifies that
the bits have to be zero (no segment protection defined).

I believe that "page protection" comment from the appendix is a
slip-of-the-tongue since there was no such segment protection made
available on 370.

this is reference to "segment protection" finally being made available
in 1982 on 308x and 4381 (running in 370 mode). 370-xa was also
introduced with 308x ... which means as soon as a customer upgraded
their 308x from running in 370 mode to running in 370-xa mode ... they
lost segment protect (replaced by page protect, so i guess that they
can get away with the comment).
http://66.102.7.104/search?q=cache:YMNfiNYnhoYJ:www.research.ibm.com/journal/sj/234/ibmsj2304G.pdf+%2B%22segment+protect%22+%2Bibm&hl=en

it is also mentioned in melinda's vm history.
http://www.princeton.edu/~melinda/25paper.pdf

segment protect provided for permissions at the per address space
level, in a per-address-space segment table ... with everybody sharing
the same page table, same page table entries and same real pages
(regardless of permissions). moving to page table protection, the
permissions are in the shared table entries ... as opposed to the
virtual address specific tables (aka everybody sharing the entries
have common permissions). original 370 architecture tried to be
careful by seperating the per address space permissions from the
actual shared entries.

misc. past postings discussing the problems and hardships created when
segment protection feature was dropped from original 370:
http://www.garlic.com/~lynn/2004p.html#8 vm/370 smp support and shared segment protection hack
http://www.garlic.com/~lynn/2004p.html#9 vm/370 smp support and shared segment protection hack
http://www.garlic.com/~lynn/2004p.html#10 vm/370 smp support and shared segment protection hack
http://www.garlic.com/~lynn/2004p.html#14 vm/370 smp support and shared segment protection hack
http://www.garlic.com/~lynn/2004q.html#37 A Glimpse into PC Development Philosophy
http://www.garlic.com/~lynn/2005c.html#20 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005d.html#61 Virtual Machine Hardware
http://www.garlic.com/~lynn/2005f.html#45 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005f.html#46 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005h.html#9 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005h.html#10 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new?

--
Anne & Lynn Wheeler |  http://www.garlic.com/~lynn/

A second look at memory access alignment

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: A second look at memory access alignment
Newsgroups: comp.arch
Date: Mon, 06 Jun 2005 19:13:39 -0600

Anne & Lynn Wheeler writes:

The quoted Z/architecture pop description implies that if the 256 byte
table operate crosses a 4k boundary ... that the TR instruction will
make a preliminary dry run of every individual byte in the (to be
translated) source operand ... to see if a data pattern specific page
fault occurs (avoiding the case of a page fault with a partially
executed instruction that couldn't be correctly restarted).

an aside observation ... such an implementation should theoritically
allow a translate table that crosses a page boundary ... and all bytes
"to be translated" resolve to table entries in the 2nd page ... and no
entries resolve to table entries in the 1st page.avoiding fetch & page
faults for the 1st page.

while there are short tables involving translating byte values x'00'
thru x'0f" ... i've also seen "short" tables involving translating
byte values x'f0' thru x'ff" ... where the tr instruction is given a
table origin address minus 240 bytes the starting address of the
actual (short) table.

aka

                TR    source,table-240

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

TSO replacement?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: TSO replacement?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 07 Jun 2005 07:36:16 -0600

Jim.S.Horne@ibm-main.lst (Horne, Jim - James S) writes:

Rexx under TSO was available as of TSO v2.  On VM,it was available by
VM/SP release 3 - I don't think it was in release 2.

from melinda's
http://www.princeton.edu/~melinda/25paper.pdf

By the time we celebrated VM/370's tenth birthday at SHARE 59 in New
Orleans in August, 1982, IBM had declared VM strategic, and the number
of licenses was growing wildly. Our installations had already begun to
enjoy some fruits of IBM's new commitment to VM, such as XEDIT, the
enhanced file system, and Pass-thru. Although IBM had been to SHARE to
discuss the possibility of distributing only object code for its
software, the general view was that it would soon realize how unwise
that was. In 1982, the VM community had a lot to celebrate. Most of us
believed that CMS was about to take over the world, so we gave it a
wonderful birthday party.

And we soon got a very big reason to celebrate. Early in February,
1983, IBM announced VM/SP Release 3. After years of pleading, we would
finally get REXX!

Mike Cowlishaw had made the decision to write a new CMS executor on
March 20, 1979. two months later, he began circulating the first
implementation of the new language, which was then called "REX".
Once Mike made REX available over VNET, users spontaneously formed the
REX Language Committee, which Mike consulted before making further
enhancements to the language. He was deluged with feedback from REX
users, to the extent of about 350 mail files a day. By consulting with
the Committee to decide which of the suggestions should be
implemented, he rather quickly created a monumentally successful piece
of software.

VM customers fell in love with REXX the moment they got it. REXX
quickly became the language of choice for CMS applications. In no
time, we began seeing REXX applications consisting of hundreds of
thousands of lines of code, and few of us wanted to work in any other
language.

By the time REXX celebrated its tenth birthday in 1989, it had been
designated the SAA Procedures Language and had long since begun
spreading to other systems, including MVS.  Today, it is available on
essentially every significant platform and continues to delight more
users

.....

some postings about large rex app done spring of 81 (I had then done
a Share presentation on it ... one of the points in the early days
of the OCO wars ... was that if it ever shipped, it would have to
ship with source):
http://www.garlic.com/~lynn/subtopic.html#dumprx

some postings about coming up with 3-tier architecture and
having to deal with saa folks
http://www.garlic.com/~lynn/subnetwork.html#3tier

lots of postings about internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Public disclosure of discovered vulnerabilities

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Public disclosure of discovered vulnerabilities
Newsgroups: sci.crypt,comp.arch
Date: Tue, 07 Jun 2005 07:52:04 -0600

nmm1@cus.cam.ac.uk (Nick Maclaren) writes:

1) C was designed as a portable, high-level assembler, and its
scope for user error is the same as assembler.  It is several times
faster to code, but not much faster to debug - as it was designed
for use as a workbench, that was fine.

frequent exploits in the world involve c-based applications are
buffer overflows
http://www.garlic.com/~lynn/subintegrity.html#overflow

a frequent "mistake" is that target buffer locations lack any
infrastructure defined lengths ... and operations just run over the
end of the buffer.

there are assembler based operations where the underlying
infrastructure have default convention that buffer locations have
encoded lengths and conventional libraries and system support routines
utilize buffer length information whenever buffer operations are
involved ... and the probability of buffer overrun mistakes is
radically less than in typical c language environment.

it is possible, even in assembler coding ... to drastically reduce
certain kinds of coding mistakes if the underlying infrastructure
conventions include simple additional structure ... aka even assembler
environments can have established coding conventions that contributed
to significantly reduced coding errors.

some previous point was that C-language buffer length coding mistakes
can be eliminated if the coder just memorizes all buffer lengths and
faithfully applies that information to every available buffer.  Even
in assembler language environments where the buffers carry esplicit
length information, the probability of buffer overrun mistakes can be
drastically reduced ... because of reduced dependancy on human memory
based accounting operations.

i might even assert that the c-language related buffer length
dependancy on humans memorizing every buffer length ... and possibly
having to rememorize them after not having worked on a program for a
period of months ... is analogous to the security shared-secret
conventions ... where people are assumed to correctly memorize scores
of passwords ... even those that they use infrequently:
http://www.garlic.com/~lynn/subintegrity.html#secrets

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

A second look at memory access alignment

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: A second look at memory access alignment
Newsgroups: comp.arch
Date: Tue, 07 Jun 2005 10:01:26 -0600

since TR was never originally designed to be an incremental execution,
interruptable, and restartable instruction (like the "long"
instructions introduced with 370) ... presumably TR has to pre-resolve
all possible real addresses before starting (when running with DAT
on).

the standard 360/370 scenario was doing start/end bounds checking
would also resolve real address (when running with DAT on) ... so the
real addresses were all available during the actual instruction
execution w/o having to re-interrogate the TLB.

If another CPU had done global tlb entry invalidate (PTLB was
introduced in 370 to do this globally for all entries in all TLBs,
originally there was also selective invalidate ISTE & IPTE, but they
were dropped before 370 shipped)... unless whole processor complex
interlocked until in-flight instructions completed, system software
would have to assume that there could be some dangling use of the
associated real page addresses from instructions in-flight. this would
seem to be at preferrable to having a non-interruptable,
non-restartable instruction like TR ... re-interrogate the TLB for a
real address (while in progress) and find the required entry had
evaporated.

the 370 architecture redbook had some number of instructions scenarios
where the instruction could be abrogated, but that gets difficult for
instruction that is incrementally doing storage modifications.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

A second look at memory access alignment

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: A second look at memory access alignment
Newsgroups: comp.arch
Date: Tue, 07 Jun 2005 10:23:39 -0600

just for completeness ... from 360/67 functional characteristics
(obtained from bitsavers.org), a27-2719.

in Instruction Timings section, starting pg. 43

... there are mentions for some special instruction timings but no
mention of the dry run for TR (some amount on EDMK) ... as in the
Z/architecture & esa/390 PoP.

there is on pg. 44,

7. Instructions times for STM, STMC, LM, LMC, VFL Decimal, and Logical
SS format instructions are modified as follows. When translation is
indicated, the beginning and ending address of each field is tested by
the translation process before instruction execution. Execution times
is exposed to one of the following increments of additional time.

...

and TR from pg. 53 of Instruction Timings section

                                      Model 67-1       Model 67-2
Instruction      Form   Mnemonic      Times (us)       Times (us)
Translate         SS     TR           1.94+1.78N       2.06+1.78N

there is 2nd level detail on the above on pg. 55

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Where should the type information be?

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: Tue, 07 Jun 2005 12:35:16 -0600

pg_nh@0502.exp.sabi.UK (Peter Grandi) writes:

This reminds me (very bemusedly) of a consulting assignment I had
once trying to help a large oil company sort out their repository of
drilling data tapes.

Several hundred thousand tapes, housed in a large dedicated
building, and as I investigated the circumstances it turned out that
nobody had much of an idea what was the format of data on about a
third of those tapes :-). Fortunately my assignment was about as-is
media migration, not trying to reverse engineer them. :-).

I have always been a believer in putting the metadata and/or
documentation with the data too, just in case :-).

at the ieee metadata meetings we were going to in the early 90s
... there were fairly good representation from the oil industry.

at one point somebody from the oil industry had said that they had a
project to define metadata for oil industry ... hoping that it would
be used for recording as the data was recorded ... aka the Bob Adair
model in the 60s at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

one big issue was trying to use an RDBMS as a repository for the oil
industry metadata description. now most RDBMS have been pretty good at
representing relatively uniform and homogeneous information ... minor
collections of posts about origins of RDBMS and SQL
http://www.garlic.com/~lynn/subtopic.html#systemr

however, RDBMS can quicly get convoluted when trying to represent
non-uniform and/or non-homogeneous information. they mentioned using
something like 995 tables for representing the oil industry metadata
in RDBMS form.

NIH NLM has had a somewhat similar activity with UMLS
http://www.nlm.nih.gov/research/umls/about_umls.html

there was some joke from the early 90s about it taking 18 months
elapsed time attempting to (relational) "normalize" new metadata
changes corresponding with 9 months of new/changed medical know