Re: Why all the max length constraints?
Date: Mon, 29 May 2006 23:46:27 GMT
Message-ID: <nJLeg.2687$4I3.1738_at_trndny08>
"paul c" <toledobythesea_at_oohay.ac> wrote in message
news:RrFeg.204979$7a.156481_at_pd7tw1no...
> David Cressey wrote:
> > "dawn" <dawnwolthuis_at_gmail.com> wrote in message
> > news:1148773922.267863.170930_at_j55g2000cwa.googlegroups.com...
> >
> >>[OK, here is my next "stupid question" as I cut a path in my study of
> >>the RM. Those teachers who just want to tell this student how ignorant
> >>she is are welcome to sit this out as I really am hoping to
> >>understand.]
> >>
> >>In SQL-DBMS's, like VSAM (and other indexed sequential files before
> >>them) a lot of attributes are specified with max length constraints.
> >>While there are some attributes where this constraint is related to a
> >>conceptual constraint (from the analysis phase), these lengths are
> >>often introduced for the logical model or implemenation in the DBMS.
> >
> >
> > Is VSAM really a DBMS? I looked up VSAM in wikipedia, and the
definition I
> > found suggests that VSAM is NOT a DBMS, although both IMS and DB2 are
> > layered upon it.
> > ...
>
> no, it's not a DBMS.
[snip long, but good thumbnail of VSAM]
> there were three forms of file organization, a sequential one where
> entry order was preserved, a random one you supplied a record number and
> a keyed one that was based on a dense btree. these forms continued the
> three basic access methods that the first System 360's used (ISAM, QSAM
> and BDAM) but the btree-style index was an improvement over ISAM which
> was tightly coupled with IBM's disk and programmable controller design
> that had some hardware support for physical 'key' records that the
> hardware actually distinguised from 'data' records. that was part and
> parcel of the early IBM approach to achieving IO and CPU overlap by
> letting a programmer off-load disk cylinder searches to the disk
> controller.
>
> starting in the late 1960's, IBM pushed VSAM hard, partly by putting it
> underneath IMS. part of the reason must have been to discourage the
> older access methods which were even more closely tied to hardware -
> disk vtocs - "volume table of contents" that were much more hw-specific
> than the directories we see in the popular os'es today. i could be
> wrong, but i believe the system R people built on top of it too because
> it was familiar. it became virtually impossible to package MVS and most
> of the other 'program products' without including VSAM in your monthly
> license fees.
>
> from a programmer's point of view i think it's fair to say that vsam is
> comparable, say, to a commercial package such as one whose name i think
> was 'btrieve' or somesuch. really just a low-level doorway to disk
drives.
>
> > In the world of DEC, which I know better, both Rdb/VMS and VAX DBMS
were
> > layered on KODA. KODA was not a DBMS but a useful building block.
> > ...
>
> around 1990 i had to make some drivers to talk to Dec's (VMS) access
> method. i don't remember what it was called but i was very impressed
> with it, granted as a mere file system. it had everything VSAM had,
> plus transactions at a file level. but it was still nothing more than
> a file system, no notion of 'columns' or 'attributes' in the dbms sense
> and appl'n programs had to map the files byte by byte.
>
You were probably dealing with RMS (Record management System).
This was layered on top of the VMS file system, and treated files as containers for records. There were sequential files, random access files and indexed files. It wasn't a DBMS, nor was it used as the layer underneath Rdb. As I said in another response, KODA was used for that.
Index files were impressive, although very simple. That plus Datatrieve is what taught me to think in terms of joins. Received on Tue May 30 2006 - 01:46:27 CEST