gnucobol-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[open-cobol-list] Are keys for COBOL INDEXED files by definition PIC X (


From: Joe Robbins
Subject: [open-cobol-list] Are keys for COBOL INDEXED files by definition PIC X (implicitly)?
Date: Sun, 17 Nov 2013 21:30:22 +0000

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
 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]