| Arnold Trembley 2004-12-17, 8:55 am |
|
Pete Dashwood wrote:
> "Howard Brazee" <howard@brazee.net> wrote in message
> news:cpk9lv$jfm$1@peabody.colorado.edu...
>
>
> only
>
>
> and
>
>
> Disagree Howard. That's not how I remember it. VSAM/KSDS may have duplicated
> the functionality of ISAM but there were no other systems around at the time
> (with the possible exception of BTRIEVE, and that was largely Academic) that
> had the capability to reorganize themselves with CA/CI splits and reclaim
> freespace. I worked on many other mainframes around this time (IBM and the
> BUNCH) and NOBODY as I recall had this capability. Burroughs (later Unisys)
> had an access method called Indexed Random that periodically reorganized
> itself in the background by sorting the latest additions to a file and
> chaining them. When you closed the file the whole thing was sorted ready for
> the next use. On Control Data Cybers the SCOPE operating system allowed
> files to be managed across drives (if you allowed it to) and would write
> data wherever the next track was available, then remember where it had put
> it (a bit like FAT tables on a PC). NCR required a separate reorg utility as
> did Honeywell at the time. I can't speak for Univac as my experience of it
> was limited.
>
> VSAM was quite revolutionary in it's capability. The fact that it is still
> used today without major changes to it, testifies to its success.
>
> VSAM/RRDS was a very good implemenation for COBOL relative files, and I
> remember writng an access method called RAM which used it, for the South
> London branch of a major international Bank.
>
> As for replacing flat files I don't think so. VSAM/ESDS was never going to
> do that and I don't believe IBM saw it as a competitor for QSAM or even
> BSAM. Obviously, our experiences and memory differ here.
>
> Pete.
VSAM ESDS (VSAM sequential files) are used very commonly in CICS for
writing transaction logs. That's because using QSAM files in CICS is
a bit...difficult. A VSAM ESDS file can easily be open for both input
and output in CICS. Not so for QSAM which requires CICS DCT entries
(Destination Control Table).
In CICS you can specify in the FCT entry that a VSAM file is a data
table. You must specify the maximum number of records. The entire
file is cached in memory, which means access is much faster, but the
programs need to be recompiled. There are two types of VSAM data
tables - CICS maintained, where CICS periodically flushes buffers to
the disk, and User maintained, where the file is never copied back to
disk.
I support applications with both CICS maintained and User Maintained
VSAM data tables. For User Maintained tables we define an extra FCT
entry that points to the same file, without defining it as a data
table. We have "sweeper" programs that run at timed intervals to read
from the UMT and write to the disk version of the file.
It's still a good idea to reorg VSAM KSDS files periodically,
especially if there's a high volume of insert and delete activity, but
you can go for quite a while before performance degrades.
I have never needed to use a VSAM RRDS file, and I'm not sure if RRDS
supports variable length records. Obviously, variable length records
are well supported for VSAM KSDS and ESDS files.
And as was stated elsewhere, I can easily define my own VSAM file, but
I cannot get a new DB2 table created. Only a DBA can do that for me.
With kindest regards,
--
http://arnold.trembley.home.att.net/
|