COBOL file open problem

[Hitesh Rawal]

I have recently recompiled a very old program and on execution, I get the following error:

%COB-F-KEYNOTMAT, attempting to open indexed file PROG_ROOT:[RAWALH.RMG.REVAL.TR
IBALSEL]XTAMST.DAT;3 whose actual keys do not match those declared

as far as I understand, this means that the file has more or less keys than have been declared in the program.

The program was last compiled in 1991 and the previously created executable works fine. When recompiling the source, I get a different sized EXE, which does not inpire confidence.

I have done an ANALYZE/RMS/FDL and compared against the original FDL (created in 1989) and there do not appear to be any changes there.

FDL

IDENT "26-JUL-2006 10:30:47 OpenVMS ANALYZE/RMS_FILE Utility"

SYSTEM
SOURCE OpenVMS

FILE
ALLOCATION 630
BEST_TRY_CONTIGUOUS no
BUCKET_SIZE 2
CLUSTER_SIZE 35
CONTIGUOUS no
EXTENSION 0
FILE_MONITORING no
GLOBAL_BUFFER_COUNT 0
NAME "PROG_ROOT:[RAWALH.RMG.REVAL.TRIBALSEL]XTAMST.DA
T;2"
ORGANIZATION indexed
OWNER [30,*]
PROTECTION (system:RWED, owner:RWED, group:RWE, world:)

RECORD
BLOCK_SPAN yes
CARRIAGE_CONTROL carriage_return
FORMAT fixed
SIZE 34

AREA 0
ALLOCATION 560
BUCKET_SIZE 2
EXTENSION 0

KEY 0
CHANGES no
DATA_KEY_COMPRESSION yes
DATA_RECORD_COMPRESSION yes
DATA_AREA 0
DATA_FILL 100
DUPLICATES no
INDEX_AREA 0
INDEX_COMPRESSION yes
INDEX_FILL 100
LEVEL1_INDEX_AREA 0
NAME "XTA-KEY"
NULL_KEY no
PROLOG 3
SEG0_LENGTH 22
SEG0_POSITION 0
TYPE string

KEY 1
CHANGES yes
DATA_KEY_COMPRESSION yes
DATA_AREA 0
DATA_FILL 100
DUPLICATES yes
INDEX_AREA 0
INDEX_COMPRESSION yes
INDEX_FILL 100
LEVEL1_INDEX_AREA 0
NAME "GLNO"
NULL_KEY yes
NULL_VALUE 32
SEG0_LENGTH 6
SEG0_POSITION 28
TYPE string

ANALYSIS_OF_AREA 0
RECLAIMED_SPACE 0

ANALYSIS_OF_KEY 0
DATA_FILL 82
DATA_KEY_COMPRESSION 58
DATA_RECORD_COMPRESSION -8
DATA_RECORD_COUNT 4687
DATA_SPACE_OCCUPIED 392
DEPTH 2
INDEX_COMPRESSION 14
INDEX_FILL 52
INDEX_SPACE_OCCUPIED 16
LEVEL1_RECORD_COUNT 196
MEAN_DATA_LENGTH 34
MEAN_INDEX_LENGTH 24

ANALYSIS_OF_KEY 1
DATA_FILL 75
DATA_KEY_COMPRESSION 44
DATA_RECORD_COUNT 2889
DATA_SPACE_OCCUPIED 126
DEPTH 1
DUPLICATES_PER_SIDR 1
INDEX_COMPRESSION 11
INDEX_FILL 44
INDEX_SPACE_OCCUPIED 2
LEVEL1_RECORD_COUNT 62
MEAN_DATA_LENGTH 17
MEAN_INDEX_LENGTH 8

(two keys defined)

The file is declared as follows:

SELECT XTAMST ASSIGN TO "XTAMST"
ACCESS DYNAMIC
ORGANIZATION INDEXED
RECORD KEY XTA-KEY
ALTERNATE RECORD XTA-GLNO.

(two keys)

The record description is as follows:

01 XTA-REC.
03 XTA-KEY.
05 XTA-ACTYPE PIC 9(2).
05 XTA-BOOK PIC X(4).
05 XTA-PRODUCT PIC 9(2).
05 XTA-PAID-RCVD PIC X.
05 XTA-CTYPE PIC 9(2).
05 XTA-HDG-UNHDG PIC X.
05 XTA-LOCO PIC X(4).
05 XTA-CUR-METAL PIC X.
05 XTA-CHARGE-TYPE PIC 9(2).
05 XTA-CONTRA-CUR PIC X(3).
03 FILLER PIC X(6).
03 XTA-SEC-KEY.
05 XTA-GLNO PIC 9(6).

Does anybody know why the program fails to open the file?

A host of other program also use this file and have not had the same error after recompilation?


Regards
Hitesh

[Phil.Howell]

You probably compiled with different alignment options than the original.
Compile with /list/map=declared qualifiers,
then compare the fdl and the map of the record definition.
Phil

[Wim Van den Wyngaert · Accepted solution]

If the program was compiled with the /CHECK=DUPLICATE_KEYS qualifier on the command line, and the duplicate key specification on a file's FD (in other words, specified in the WITH DUPLICATES phrase) does not match that of the actual file, a run-time diagnostic will be issued when an attempt is made to open the file with an OPEN statement.

Did you specify /check or /check=all or /check=dup ?

Wim

[Hein van den Heuvel]

Hello Hitesh,

Let me first compliment you on such a well documented question: An actual error message, sources, relevant environment data. Refreshing!

Ok, the compiler and OS version details are missing, but this is just amongst friends, not a support call.

Anyway...

At first glance the key definitions in the cobol seem to match the relevant FDL data (position, size, type)
The FDL has a NULL key defined, which cobol can not define, but that will not cause a mismatch.

Maybe the duplicates on KEY 1?

Like Phil wrote, alignment comes to mind, but the record does nto seem to have comp fields. CHeck the listing to be sure.

My advice would be to temporarely change the open to OPEN FOR OUTPUT and have Cobol create the file, then compare the FDL's.

Further free advice: Tune that FDL!
- Disable record compression (its effect is negative)
- Drop this index compression (faster lookup)
- Pick a bucket size larger than 4 (8?) to drop the primary key index a level.
- Convert

Good luck,
Hein.

[Hitesh Rawal]

Thanks everyone.

The problem was due to /CHECK=ALL parameter on the compile.

We have compile/link command procedures and these were created in 2004, hence original compile was probably from the command line.

I have now added the WITH DUPLICATES onto the declaration i.e.:

SELECT XTAMST ASSIGN TO "XTAMST"
ACCESS DYNAMIC
ORGANIZATION INDEXED
RECORD KEY XTA-KEY
ALTERNATE RECORD XTA-GLNO
WITH DUPLICATES.

and all is well.

Once again thanks for all your help.
Points submission to follow.

Hitesh

[Phil.Howell]

perhaps it uses a compiler option that causes it to check the name of the secondary key? I always thought this was for reference only.
Phil

[Wim Van den Wyngaert]

To my knowledge, your data items will not be realligned. Only comp etc fields are.

Do not forget to check the already compiled programs. They might encounter the same problem after a conditional statement.

Wim

[Hitesh Rawal]

The compiler option /CHECK=ALL is used.

As the secondary key has a duplicates = yes, this must be defined in the SELECT.

VMS Help on COBOL/CHECK :
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
COBOL

/CHECK

/CHECK[=(option[,...])]
/NOCHECK (D)

Specifies conditions to be checked at execution time. Controls whether the system checks PERFORM statements, indexes, subscripts, reference modifications, the depending-item and
indexed file keys for specific run-time errors.
.
.
.
.
[NO]DUPLICATE_KEYS
Verifies that the duplicate key
specification for indexed file keys
in the source program matches
the duplicate key specification
in the physical file.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

As the WITH DUPLICATES was not specified, at runtime there was a mismatch between the programs definition of the file indexes and the file indexes themselves.