Splitted key as prime key 3

[Patten]

I am looking in a cobol application and this application uses splitted keys. However, for prime keys, splitted keys are never used. They do use instead a group field which combines a number of fields.
Nobody remembers why this is developped in this way. Does somebody has an idea why it could be? Are there known gotcha's about using splitted keys as prime key?

 

[theotyflos]

Hi Patten,

Split keys are often used (among other reasons) if the programmer needs to add another "sorting" in an existing file without modifying the FD.

e.g.

    Select SomeFile-Fil Assign To ...
           Organization ....
           Record Key SF-Code
           Alternate Key SF-OtherCode Duplicates
           :
           :
    FD  SomeFile-Fil.
    01  SomeFile-Rec.
        02  SF-Code          Pic 9(..).
        02  SF-Data          Pic x(...).
        02  SF-Group         Pic 9(..).
        02  SF-OtherCode     Pic 9(..).
        02  SF-OtherData     Pic x(...).

With split keys, to add a new "sorting" all you have to do is alter the Select (convert the file and recompile also of course). You don't have to instert new (duplicated) fields in the file or check every program to be sure that these new fields are synchronized with the original:

    Select SomeFile-Fil Assign To ...
           Organization ....
           Record Key SF-Code
           Alternate Record Key SF-OtherCode Duplicates

           Alternate Record Key SF-Key2 =
                                SF-Group
                                SF-Code

:

Using split keys for the prime key, I think is either a result of VERY BAD design or maybe some MAJOR changes some time after the application was first created.

Theophilos.

 

[Patten]

Theotyflos,

in the application they never use splitted keys as prime key.

It is like this:

FD
03 WKN-KEY
05 WKN-NR-WKG PIC 9(04)
05 WKN-NR-WKN PIC 9(10)

SELECT ....
KEY IS WKN-KEY

Could there be a reason why they don't use:
SELECT ....
KEY IS PRIME-KEY = WKN-NR-WKG
,WKN-NR-WKN

in stead of using the group field as prime key?

And if using the second option: is it a bad choice to do it that way? If so, why?

 

[theotyflos]

Patten,

I'll answer your last question first: IMHO, yes there are some reasons: Speed and unnessecity.

WKN-KEY is one "key segment", while a split key is 2 or more.

If the items that construct the key (prime or not) are contigious then there is ABSOLUTELY NO REASON to define the key as split. It is NOT an error, but a complete waste of time for you and the runtime.

You use split keys only when the items that construct the key aren't contigious.

 

[etom]

To re-state what theotyflos said, coding the example as a split key causes the compiler to generate additional instructions to perform the task which can affect run time when processing large amounts of data.

etom

 

[webrabbit]

Not just additiional instructions, but additional space in the index, which means the file is larger and i/o time is longer. Plus, on many platforms and with many compilers, the prime key cannot be split.

 

[Patten]

Thanks for the feedback guys! Helps me a lot.
In fact, I do understand there is no reason to split a prime key Cobol wise speaking. But the reason I am considering it, is I am trying to migrate an existing Cobol application using C-Isam files to using Btrieve files/Pervasive SQL Software and thus leveraging SQL capabilities to my application. I want to do this with as less changing in the source code of the original application as possible. For this I need to split the prime keys.
But an interesting remark of webrabbit: some platforms do not support splitted prime keys. I am working with RM/Cobol from Liant. I don't know if you know by accident which platforms for RM/Cobol do not support splitted prime keys?

 

[theotyflos]

Rm/Cobol supports primary split key (since v7 I think) for -as far as I know- Sco Openserver, Dos, Windoze. One of RM/Cobol's main advantage is compatibility thus, I suppose, it supports primary split keys for all platforms.

 

[k5tm]

Patten,

theotyflos is correct. All current versions of RM/COBOL support split keys.

For SQL access to your RM/COBOL data, may I suggest Relativity?

http://www.liant.com/products/relativity/

This might be a better approach, with quicker time to market, than a conversion to Pervasive's file system. (Sorry about the advertising, Theophilos )

Tom Morrison

http://www.liant.com

 

[k5tm]

And some small corrections...at least for RM/COBOL:

Split keys do not cause the compiler to generate extra instructions. There is a very, very small runtime cost resulting from the need to gather key information from more than one location in the record, but my guess is that one cannot measure this in any real situation, as it is a tiny fraction of the total 'cost' of an I/O operation.

Split keys do not take any more space in the file. RM/COBOL uses multiple algorithms to compress keys, thereby making the index trees smaller (by placing more key values at each level of the tree). Split keys will take no more space, or i/o processing time, than contiguous keys containing identical data. (BTW, it is smaller index trees that improve indexed file performance.)

Hope this helps clarify technical issues.

As to coding style, split keys came very late in the COBOL language evolution, so most programs use the contiguous approach. Clearly the contiguous approach has led to some truly convoluted record definitions where a simple split key declaration would have allowed the placement of some fields in a record layout in a more 'natural' place (such as last name near first name) within the record. But there is too much history in the COBOL legacy data to unwind this now.

Tom Morrison

http://www.liant.com

 

[theotyflos]

Tom,

I think after all the help you give here, you deserve to advertise from time to time

 

[Patten]

Thanks Tom,

clarifies a lot! And is wonderful news for us!

 

[k5tm]

Patten,

I was just looking at your user profile, and noticed that you are also in the XML and CSS forums. If these are interests that involve the RM/COBOL application you should also be interested in the RM/COBOL XML Toolkit and perhaps the new product which will be announced Any Day Now...

I am happy to have been the bearer of good news!

Tom Morrison

http://www.liant.com

 

[Patten]

Thanks Tom,

other people in my company are already testing and using the RM/Cobol XML Toolkit. And we are looking forward for any new products.