Alternate key sort?

[cg53]

Starting and reading an indexed file by using the alternate key ( alpha by last name >. Works great but when you have 50 - 60 records with the same last name is looks bad because the records show in the order in which they were added.

Do not want to redo the file layout. Can I read by the alternate key but also have it in the primary key order for all duplicates?

Using the latest, or close to it, rmcobol from liant.

 

[PHV]

One usual way is to have the alternate key a composite one with last name, primary key and thus duplicates are avoided ...

Hope This Helps, PH.
Want to get great answers to your Tek-Tips questions? Have a look at FAQ219-2884 or FAQ181-2886

 

[cg53]

Not sure that I follow you on this. I have never used a composit key - does that need to be defined when the file is created or is it a method to read an existing file in a different order. If so could you show me a sample of the code that uses it.

Record key is Account-no

Alternate record key is Last-Name ( for alpha search )

Thanks

 

[k5tm]

cg53,

The terminology is split key and, yes, you would need to define this when the file is created (but there is a workaround -- see below). This is accomplished in the FILE-CONTROL paragraph as follows:

        RECORD KEY IS ACCOUNT-NO
        ALTERNATE RECORD KEY 
            LAST-NAME DUPLICATES
        ALTERNATE RECORD KEY 
            NICE-LAST-NAME = LAST-NAME ACCOUNT-NO

Use the new alternate key as you would any other:

        MOVE [i]some-name[/i] TO LAST-NAME
        MOVE ZEROS TO ACCOUNT-NO
        START [i]filename[/i] KEY GREATER OR EQUAL NICE-LAST-NAME
        READ [i]filename[/i] NEXT

Since this does not change the record layout, you can use the recover1 utility to reindex the file for you to add the new split key index. See the RM/COBOL User's Guide, Appendix G, Indexed File Recovery, and check out the K option for details.

Tom Morrison

http://www.liant.com

 

[cg53]

Sounds good - last question - will I need to insert the new alternate key phrase

ALTERNATE RECORD KEY
NICE-LAST-NAME = LAST-NAME ACCOUNT-NO

line in all programs that access this file?

 

[k5tm]

Yes.

Tom Morrison

http://www.liant.com

 

[rearl306]

A better solution would be to put the SELECT and the file description into a pair of copybooks. Then you would change your programs to use the copybooks instead of putting the actual SELECT and file description into your code.

That way if you need to make changes to the file in the future, you only have to change it in one place and then just recompile everything that uses those copybooks and the changes will be picked up automatically.

 

[WMK]

Just to clarify (or expand) a little.

The original quesiton specifically asked about rmcobol. Tom Morrison gave an answer - and I consider him "definitive" about rmcobol.

HOWEVER, so others reading this thread know:

1) "split" (or composite) keys are NOT part of the ANSI '85 Standard, but are a common - NOT universal extension to it.

2) They *are* included in the '02 Standard, but NOT in the exact same way that SOME implementations previously implemented them.

3) All "fixed file attributes" are determined by the VENDOR (implementor) and may or may not be the same acroos COBOL compilers. Therefore, whether a "slit key - alternate key" would (or would NOT) need to be defined in every program accessing the file - is up to the implementor - even in an '02 conforming compiler.

***

Again, believe Tom for rmcobol, but don't "generalize" this approach without checking first - for other compilers.

Bill Klein

 

[k5tm]

Bill,

With regard to your item (3), I disagree.

9.1.6 Fixed file attributes
A physical file has several attributes that apply to the file at the time it is created and cannot be changed throughout the lifetime of the file. The primary attribute is the organization of the file, that describes its logical structure. There are three organizations: sequential, relative, and indexed. Other fixed attributes of the physical file provided through COBOL are prime record key, alternate record keys, code set, the minimum and maximum logical record size in bytes, the record type (fixed or variable), the collating sequence of the keys for indexed files, the minimum and maximum physical record size in bytes, and the record delimiter. The implementor shall specify whether the ability to share a physical file is a fixed file attribute.

This is from the 2002 standard, and is very similar to the language used in the 1985 standard.


Now it is indeed true that it up to the vendor to determine if an extension, which by definition is not part of the standard, should join the set of fixed file attributes, but it seems clear that split keys are part of the fixed file attributes.

Tom Morrison

http://www.liant.com

 

[WMK]

This goes back to an interpretation of the '85 Standard. (I can get the exact CIB reference for you - if you need it). However, from the '02 Standard

B.1 Implementor-defined language element list

(page 684)

102) OPEN statement (validation of fixed file attributes). This item is required. This item shall be documented in the implementor's user documentation. (14.8.26, OPEN statement, general rule 8)

and (page 486)

The implementor defines which of the fixed-file attributes are validated during the execution of the OPEN statement.

So, yes, you are (probably) correct that it IS a fixed file attribute, BUT, that doesn't mean that conforming implementations need to "check" it.

Bill Klein

 

[k5tm]

Bill,

IIRC the FIPS CCVS tests (which of course do not apply to the '02 standard) actually did check, which means that if a conforming compiler also wanted to be FIPS compliant, some, if not all, of the implementor's wiggle room was removed. (It might even be the case -- don't know -- that this particular aspect of FIPS testing spawned the need for an interpretation.)

Tom Morrison

http://www.liant.com

 

[WMK]

Certainly the FINAL FIPS ('85 & '89 & '91) tests did NOT test alternate key "consistancy". I know this as IBM's mainframe compilers do NOT issue a FS=39 for inconsistencies in this area (and never did - and always passed the tests)

It is certainly possible that SOMETHING was tested for a FS=39.

Bill Klein

 

[k5tm]

Well, Bill, you finally forced me to go look. :-D

The only test for status 39 appears to be a change in record length, in the IX111 test.

Tom Morrison

http://www.liant.com