RELATIVE file type

[Glenn9999]

Does anyone use the RELATIVE file type in real-world practice (ORGANIZATION IS RELATIVE)? If so, what is it useful for? I have my guesses (*), but I wanted some confirmation.

* My guesses: Basically the best example I'm aware of of what would have to be the RELATIVE type in action is the TSQ in CICS. Seems to fit the idea of what the RELATIVE type is. But I'm thinking it would be useful in any kind of table setup that could not be placed into memory very practically.

** For those who don't know, my understanding of this file type is that it doesn't operate on physical record position but logical record assignment (I can have 3 physical records, but they can be designated as any numbers I can basically want like 1, 2, and 10). I would access the third physical record by asking for record #10 in this example.

 

[mrregan]

Relative files are like index files without requiring disk storage for the keys. You can access the nth record directly by loading the record number into the record key. For example, if you had a product file with product codes from 1 to 1000, you could build the file telling the program to use the product code as the relative key. You could write the record for product code 1000 before you wrote any other records if you wanted. I suspect this is no longer of much use since todays disk storage isnt a factor for storing keys.

 

[webrabbit]

The Relative record number does specify the physical position of the record within the file. If a file has record numbers 1, 3, and 10, then there is physical space reserved for record numbers 2 and 4 through 9. The advantage is rapid access. The access method knows exactly where the record is and does not have to search for it, as in an indexed file.

The utility of this file type is very limited. I have been able to use it only a few times in the last 37 years.

 

[k5tm]

Glenn,

I cannot speak for the mainframe world, but relative files are still in use today, on a very limited basis.

I get to see a lot of application suites. Almost without exception there are a (very) few relative files. Some use these to implement virtual tables (as in your first suggestion) and that works well. Others use relative files to store configuration information, and in these cases it is often found that the file description contains many different record descriptions.

Your second 'understanding' is also correct.

Relative files are like index files without requiring disk storage for the keys.

It would be more accurate to state that relative files are like indexed files with implicit keys. One of the most common implementations of relative files simply multiples (the maximum record length plus overhead) by (the relative key value minus one) to obtain a 'disk address' (offset within the file) at which the record is stored. In this style of implementation, you will find (potentially a large amount of) storage devoted to the keys for records that are not logically present in the file. (The overhead mentioned above is due to the requirements of COBOL. If a relative file is being read sequentially, only those records logically in the file may be returned; records that have been logically deleted or have never been written cannot be returned. Also, for variable record length relative files, the record length must be stored along with the record contents.)

It would also be possible, and probably reasonable, to implement relative files using the same B-tree logic that is used for indexed files. This would allow relative files to enjoy the same benefits of data and key compression available in most modern indexed implementations. However, there is not enough market demand to justify a rewrite.

Tom Morrison

http://www.liant.com

 

[webrabbit]

The utility of relative files is very narrow, but why would the industry alter the specifications for them to match those of indexed files when indexed files can already be used if the requirements don't fit relative files well?

 

[fredericofonseca]

A few of my customers still use Relative files.

And if I'm not wrong up to very recently a major company with supplier of software for Air flights companies used MANY relative files. I think they have now changed them to Indexed, but not sure.

Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

 

[k5tm]

Webrabbit,

You miss my point a bit, which is from the viewpoint of the implementor of a file system that conforms to the COBOL standard (as interpreted by the CCVS test suite).

I am not proposing that the standard would change. However, I, as an implementor, could use my indexed file implementation to produce relative files that conform to the standard in every way, but without using the method you impute, viz. the relative record number dictates the physical position of the record within the file.

Tom Morrison

http://www.liant.com

 

[ceh4702]

What would you call a VSAM file? I still dont get the Relative file type. Give a textbook definition. I have not ever seen or used this term.

If you do not like my post feel free to point out your opinion or my errors.

 

[webrabbit]

In IBM mainframe COBOL a relative file is an RRDS VSAM file.

 

[k5tm]

VSAM is an IBM implementation of COBOL indexed files.

Tom Morrison

http://www.liant.com

 

[3gm]

A couple of thoughts:

1. VSAM (Virtual Storage Access Method) is "an access method for the indexed or sequential processing of records on direct access devices. Records can be of fixed-length or variable-length." It is available across z/OS (MVS), VM, and VSE operating systems and is independent of COBOL. Modern IBM COBOL compilers rely on VSAM to provide the implementation of Indexed (KSDS - keyed, sequential data sets) and Relative (RRDS - relative record data sets) files. COBOL can also use VSAM's implementation of sequential data sets (ESDS - entry sequenced data sets), but can also use QSAM (queue sequential access method) or other operating system supplied sequential file IO methods.

2. Back when compiler space (table) limits were a bigger issue, I used a relative file as a large table in a billing application. Use of relative IO reduced the runtime of the program by a factor of 100 over a prior implmentation that relied on indexed IO. That said, relative IO files are a rare bird.

Regards.

Glenn

 

[baruch]

thats good for tables that you dont know its size,
I have a program that at the begining, i open the relative file as output, & hold in the memory the number of active recoreds, & the last one.
SO in a new session most i just to rewrite, the record,

 

[jmanj]

Back then when for ISAM/VSAM machines(like AS400) we use relative files(direct) to create interactive programs. Due to limitation of compiler memory (RPG & Cobol) at 65K, Relative files are the only way we can have multiple workstation active. In early RPG mode you have to create the index separately. Nowadays due to better database management system,
relative files are becoming dinosaurs.

 

[webrabbit]

Actually, the COBOL Indexed file specifications were designed to support IBM VSAM KSDS files. It might seem to be a question of the chicken or the egg, but in this case, VSAM came before ANSI COBOL 85, which IBM had a great deal of influence on. Of course, many of the new IBM-370 instructions (vs the IBM-360) were primarily influenced by COBOL, such as SRP (Shift and Round Packed) which implements the COBOL Rounded function in a single machine instruction, and MVCL and CLCL (MoVe Character Long and Compare Logical Character Long) which can move or compare strings of up to 16 megabytes long, with rules that match the COBOL rules for such moves and compares.

 

[k5tm]

This is an interesting version of history, which I will let Mr Klein review for accuracy.

Indexed files predate the 1985 standard, which made very few changes to the 1974 standard. While I cannot place my hands on a 1968 standard, an appendix in the 1974 standard describes the changes to the indexed I/O module from the 1968 standard, so it too must have had at least a form of indexed files.

So, it would seem that indexed files were being standardized, in at least some now primitive form, while I was busy translating 1401 Autocoder to 360 COBOL at a Dearborn-based large manufacturing concern. I don't seem to remember VSAM KSDS, but we sure moved a lot of tapes.

Tom Morrison

http://www.liant.com

 

[PHV]

but we sure moved a lot of tapes
Lucky you, no punchcards ?

 

[k5tm]

The data were on the tapes, the program was on the (sometimes several trays of) cards. This particular manufacturing concern had IIRC 35 district offices which transmitted financial statements at some enormous speed via 360/20s and created one tape/district office.

The operators were not happy when my job came up!

Tom Morrison

http://www.liant.com

 

[tgreer]

For address correction / mail sorting. The addresses are extracted from a print stream. I make the extraction file relative. The text file is then passed through software that corrects and sequences the records into "mailing sequence". I process that file sequentially. If the first record has a field that says it was orginally the 5th record, then I go get the 5th record from the relative file.

This so I have the original strings to compare against the new strings for search/replace.



Thomas D. Greer

http://www.tgreer.com

http://www.brownfedora.com

Providing PostScript & PDF
Training, Development & Consulting

 

[WMK]

webrabbit (MIS) 14 Jul 05 16:13
Actually, the COBOL Indexed file specifications were designed to support IBM VSAM KSDS files. It might seem to be a question of the chicken or the egg, but in this case, VSAM came before ANSI COBOL 85, which IBM had a great deal of influence on.

As Tom has already mentioned, "COBOL indexed" files LONG predate VSAM - and in fact, IBM's "ANS COBOL" product was (originally) introduced with ISAM (not VSAM) support. (That same compiler used BDAM instead of VSAM RRDS for "relativve file" support)

Also, in fact, (and more relevant to some other parts of the thread), IBM had SERIOUS problems with the '85 Standard as it *required* support for "variable length relative files" - which (at that time - not now) VSAM RRDS did NOT support (on MVS - it did on VSE).

This is WHY IBM's initial '85 Standard compilers were FORCED to introduce the "SIMVRD" ("simulate variable relative datasets") run-time option which DID use "KSDS" *not* RRDS files for this type of relative file. This *did* include the "physical" record key in the file itself. (And, yes, this option did pass the NIST certification tests.)

For more informaiton on this (still supported, but unneeded run-time option), see:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ceea3151/1.2.52

Bill Klein

 

[baruch]

Other useful for a relative file, that i have in many applications.

For example that you have invoce main record & itemes recors.

So the main record will be indexed with a invoice key.
In the main record, there is a field that have the number of itemes, and a vector that linkes to a relativ file, where the items are there.

Barry