Re: Why all the max length constraints?

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.

no, it's not a DBMS. let me see if i can test what little memory i have left. others could give a more technical explanation but from using it up 'til about ten years ago and supporting it from time to time, from the programmer's point of view it was merely an access method /file system and mostly invisible to users (invisible in a way that most dbms could never be). it was also used to implement a system 'catalog' by several IBM os's but not in the sense of a dbms catalog more as a way to keep track of what files were on what disks. it had verbs like get, put (sequential access), read, write (random and keyed access). you'd open and close each file individually and usually also specify whether you were going to update it, in which case other users couldn't share it. record access was one-at-a-time referring always to the file handles/control blocks that were obtained at open time. files were usually 'defined' in terms of record lengths using the arcane interfaces that came with OS/MVS/DOSVS and so forth, such as JCL, clists. there was no notion of combining records or files other than at a file level such as concatenation. this was often done with the obscurely-named utility programs that came with those OS'es.

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.

> Is VSAM really bound to SQL as an interface language?
> ...

since there are SQL's that run on systems that don't have VSAM, i'd say no.

> I'd like to nail this down before I deal with the original question.
> ...

good luck, i think it's just one more red herring.

p Received on Mon May 29 2006 - 18:38:09 CEST