Re: pro- foreign key propaganda?

paul c <toledobysea_at_ac.ooyah> writes:
> In the IBM way of things (which was cloned by several other mfrs, not
> just the mainframe ones, but even Wang, IIRC), there was this thing
> called Count-Key-Data disk architecture and a bunch of 'access
> methods' (which IMS made use of, but could be used by themselves
> without IMS). Likely I recall some of the details wrong, but keys in
> access methods such as VSAM or ISAM or even BDAM if I recall, below
> any logical schemes such as trees, could be stored in segregated disk
> cylinders and there were also little mini-computers called channels
> with very limited instruction sets which would search those disk
> cylinders asynchronously from the main cpu. (Some of those artifacts
> found their way into the higher-level IMS configuration verbiage and
> commands.) All the 'bare-metal' programmers knew about this as well
> as many other physical techniques such as how to avoid hardware
> deadlocks. Much of Codd's audience was within this (dominant) culture
> and he was very much addressing it.
> that deal.)

re:
http://www.garlic.com/~lynn/2008i.html#8 pro- foreign key propaganda?

BDAM ... basic direct access method. basically had 32bit record no/ptr

misc. past posts mentioning BDAM (and/or CICS ... an online transaction monitor originating in the same era and frequently deployed with applications that used BDAM files)
http://www.garlic.com/~lynn/subtopic.html#bdam

online medical library was developed using bdam in the 60s and was still in extensive world-wide use 30 years later ... still being the largest online search facility in the world until being eclipsed by some of the popular internet search engines sometime in the 90s.

one of the processes was that medical knowledge articles were indexed in a large number of different ways, keywords, authors, etc. tables were built of all the different ways articles were indexed. in effect the record number of the article became a unique key for each article. a specific keyword would have a list of all articles that the keyword was applicable for ... i.e. condensed set of 32bit integers ... the record ptr was effectively used as unique key of the article.

boolean keyword searches ... became ANDs and ORs of the sets of unique keys (unique record ptrs). An AND of two keywords becomes the intersection of key/recordptrs from the two lists. An OR of two keywords becomes the join of key/recordptrs from the two lists. This was all built on top of underlying BDAM support.

part of the issue attempting to replace the bdam implementation was that it was highly efficient ... having collapsed the article unique key and the corresponding record pointer into the same value (however, there was significant maintenance activity ... so significant access & thruput was needed to justify the extensive care and support). problems also started creeping in when the number of articles started exceeding the size of the record ptr/key.

...

ISAM ... indexed sequential access method ... had the really complex channel programs. the whole structure of the database was stored on disk. a channel program would be extensive and very complex ... starting out searching for specific index record ... which would be then read into memory location which was the argument of a following search command ... this could continue for multiple search sequences ... in a channel program, until pointer for the approriate data record was found and read/written. Channel programs could have relatively complex condition testing, branching, and looping.

ISAM was an enormously I/O intensive resource hog ... and went out of favor as the trade-off between disk i/o resources and real memory resources shifted (my reference to relative system disk i/o thruput having decline by better than an order of magnitude during the period) ... and it became much more efficient to maintain index structures cached in processor storage.

ISAM channel programs were also were a real bear to provide virtualization support for.

....

for other reference, the wiki IMS page:
http://en.wikipedia.org/wiki/Information_Management_System

from above:

IBM designed IMS with Rockwell and Caterpillar starting in 1966 for the Apollo program. IMS's challenge was to inventory the very large Bill of Materials for the Saturn V moon rocket and Apollo space vehicle.

... snip ...

and:

In fact, much of the world's banking industry relies on IMS, including the U.S. Federal Reserve. For example, chances are that withdrawing money from an automated teller machine (ATM) will trigger an IMS transaction. Several Chinese banks have recently purchased IMS to support that country's burgeoning financial industry. Reportedly IMS alone is a $1 billion (U.S.) per year business for IBM.

... snip ...

bottom line in the wiki article is that IMS outperforms relational for a given task ... but requires more effort to design & maintain.

and CICS wiki page ... for much of their lives ... IMS and CICS have somewhat competed as "transaction monitors": http://en.wikipedia.org/wiki/CICS

for old cics folklore ... the univ. that I was at in the 60s was selected as one of the beta test sites for the original CICS product release ... and one of the things I got tasked as an undergraduate was helping debug CICS.

and BDAM wiki page ...
http://en.wikipedia.org/wiki/Basic_direct_access_method

and ISAM wiki page (although it doesn't talk about the really complex implementation support done in the 60s): http://en.wikipedia.org/wiki/ISAM Received on Wed May 21 2008 - 04:37:44 CEST