Re: [open-cobol-list] Are keys for COBOL INDEXED files by definition PIC X (implicitly)?

[Vincent Coen]

On Sunday 17 Nov 2013 21:30:22 Joe Robbins wrote:

It has been a while since I have used such but yes it is legal subject to the compiler.

 

I do seem to remember doing so with OC but cannot remember the version. Try it and see what happens remembering what for binary field use on your systems e.g., big or little indian, HOWEVER if you ever have a need to dump the file you might want to consider using display only but that is more cosmetic and saves (at least for me) trying to work out one more field than I have to.

 

 

 

 

I am hoping one of you old hands can confirm an aspect of KEYS used on COBOL INDEXED files.

 

The Micro Focus manual we have states that all INDEXED FILE keys must be declared PIC X (alphanumeric) - explicitly or as a group item. It does not elaborate on how the subsidiary fields must be typed. Another MF manual  (http://supportline.microfocus.com/documentation/books/oc41books/fhform.htm) states that "Key comparisons are made on a byte-by-byte basis from right to left using the ASCII collating sequence". (Does the author know right from left?)

 

The question I have is: Is it legal for a (compound) key to contain non alphanumeric fields? Or am I safe in assuming that keys are alphanumerics?

 

For example would code such as this be expected to operate "sensibly" and return ordered keys:

 

        SELECT F ORGANISATION IS INDEXED PRIMARY KEY IS P-KEY.

 

        FD F.

        1              F-RECORD.

          2            P-KEY.

           3           ACCTNO PIC X(6).

           3           BRANCHNO PIC 9(6) COMP-3.

          2            F-DATA  PIC X(100).

 

Our programs would always define BRANCHNO as PIC 9(6) - that is full ASCII numeric because it is part of a key. But perhaps this is just local custom. Is it assumed in the COBOL spec that the entire key will be full characters and is "so obvious" as to not even get a mention in most manuals?

 

My reason for asking is that we have completed tests (the COBOL85 suite) on a module under fileio that substitutes an ODBC driver (onto a SQL database) in place of VBISAM, BDB, etc. I believe - there are too many to check - that COBOL 85 uses keys containing only (ASCII) characters (no COMP/BINARY). If we have to cater for any combination of encoding within the key, it gives us problems getting the ODBC, SQL and Database to behave predictably, in the sense of valid characters for conversion and/or collating sequences.

 

I would be grateful to hear any opinions on this.

 

Regards: Joe Robbins
 
Bawtry Computer Services
 www.bawtry.net