#911 BDB backend: file status 02 is broken

[Cyril]

When writing a second line with an alternative key with duplicate option enable, file status is 00 when it should be 02.

I found this rule : "For a REWRITE or WRITE statement, the record just written created a duplicate key value for at least one alternate record key for which duplicates are allowed."

Here is a sample program to reproduce the case :

       IDENTIFICATION DIVISION.
       PROGRAM-ID. MYPGM.

       ENVIRONMENT DIVISION.
       CONFIGURATION SECTION.
       INPUT-OUTPUT SECTION.
       FILE-CONTROL.
           SELECT FILE01 ASSIGN "vsam.dat" 
                  ORGANIZATION INDEXED
                  ACCESS DYNAMIC
                  RECORD KEY ID-CUSTOMER
                  ALTERNATE KEY CUSTOMER-NAME WITH DUPLICATES
                  FILE STATUS IS FS-FILE01.

       DATA DIVISION.
       FILE SECTION.
       FD FILE01.
       01 REC-FILE01.
           05 ID-CUSTOMER PIC 9(8).
           05 CUSTOMER-NAME PIC X(20).

       WORKING-STORAGE SECTION.
       01 FS-FILE01 PIC 9(2).

       PROCEDURE DIVISION.
           OPEN OUTPUT FILE01

           MOVE 1 TO ID-CUSTOMER
           MOVE "SMITH" TO CUSTOMER-NAME
           WRITE REC-FILE01   
           DISPLAY "FileStatus=" FS-FILE01 

           MOVE 2 TO ID-CUSTOMER
           MOVE "SMITH" TO CUSTOMER-NAME
           WRITE REC-FILE01   
           DISPLAY "FileStatus=" FS-FILE01

           CLOSE FILE01        
           .

       END PROGRAM MYPGM.

Here is the result :

FileStatus=00
FileStatus=00

[Simon Sobisch]

Yes, there should be a file status 02.
GC depends on the underlying library to catch that scenario.

What is the output of cobcrun --info?

[Cyril]

Here is the output :

libcob (GnuCOBOL) 3.2-dev.0
Copyright (C) 2022 Free Software Foundation, Inc.
License LGPLv3+: GNU LGPL version 3 or later <https://gnu.org/licenses/lgpl.html>
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Keisuke Nishida, Roger While, Ron Norman, Simon Sobisch, Edward Hart
Built     Dec 07 2022 13:01:01
Packaged  Dec 07 2022 09:19:19 UTC

build information
build environment        : x86_64-pc-linux-gnu
CC                       : gcc
C version                : "11.3.0"
CPPFLAGS                 : 
CFLAGS                   : -O2 -pipe -finline-functions -fsigned-char -Wall
                           -Wwrite-strings -Wmissing-prototypes
                           -Wno-format-y2k
LD                       : /usr/bin/ld -m elf_x86_64
LDFLAGS                  :  -Wl,-z,relro,-z,now,-O1

GnuCOBOL information
COB_MODULE_EXT           : so
dynamic loading          : system
64bit-mode               : yes
BINARY-C-LONG            : 8 bytes
endianness               : little-endian
native EBCDIC            : no
variable file format     : 0
sequential file handler  : built-in
indexed file handler     : BDB, version 5.3.28
mathematical library     : GMP, version 6.2.1
XML library              : disabled
JSON library             : disabled
extended screen I/O      : ncursesw, version 6.3.20211021 (CHTYPE=32, WIDE=1)
mouse support            : unknown

[Simon Sobisch]

Hm, this dev version should not be used in general as we have a final 3.2, so I highly suggest to update.

Nonetheless - the changes in this area (indexed_write_internal for BDB) which I've spotted were done in [r4746] (Oct 2022)... and rechecking with a debugger - that revision actually dropped status 02 (it is correctly set internally, then overwritten by zero).

I'm working on a fix for that (and suggest to update GC in the meantime). Expect something until Monday.

[Simon Sobisch]

broken with [r4746], fix is to adjust indexed_write_internal to not overwrite ret = COB_STATUS_02_SUCCESS_DUPLICATE;

Will be solved by hand-merge [r3893] changes for this function that include dupcnt.

[Cyril]

Thanks Simon for the answer and the advice.

[Simon Sobisch]

Just came back to inspecting this - some ISAM handlers don't return status 02, so our testsuite check both 02 and 00 - so this issue wasn't seen before.

To really fix this (and on the way return status 00 in case someone expects that) the new setting in the referenced commit helps, and also provide the option to spare some cpy clycles for a computation that may not be wanted at all (but after [feature-requests:#455] this really will only be "some cycles" for BDB.