#853 Problem reading negative COMP-3 field from File ( Organization is Line Sequentail )

[mauro cesar piva]

The COBOL program reads from a sequential file with values ​​of type PIC S9(15)v99 COMP-3,
Fields with a positive sign (Hec 0C) the reading works correctly.
Fields with negative sign (Hex 0D) the reading returns with error (non-numeric field),
We performed some tests, if the file does not have organization is Line Sequential reading
of negative value occurs without problems.

Does anyone have any idea how to get around the problem?

[Simon Sobisch]

A line sequential file may contain both x'0a' and x'0d0a'as line terminators; line sequential files are commonly there to make them readable for a human and computational fields commonly aren't.

So the primary question is: Why would you combine both?
Is there an old environment where this worked?

Wouldn't it be reasonable to either use record sequential files with COMPUTATIONAL fields or line-sequential fields with USAGE DISPLAY - possibly by using editing/de-editing when writing/reading the file?

In theory there is a way around that by adjusting your GnuCOBOL installation, libcob/fileio.c (lineseq_read), removing the following lines:

older versions:

-           if (n == '\r') {
-               continue;
-           }

GnuCOBOL 3.2+ additional remove:

-               if (n == '\r') {
-                   n = getc ((FILE *)f->file);
-                   k++;
-               }

If there is an old environment where this worked which is comparable to GnuCOBOL then this could be a configurable option (either as a runtime setting only or a flag which would be set by dialect option).

[Simon Sobisch]

Thinking again: we could also make the x'0d' "conditionally" part of the data; could you please adjust libcob/fileio.c as following and re-test?

            if (n == '\r') {
-               continue;
+               int next = getc ((FILE*)f->file);
+               if (next == '\n') {
+                   /* next is LF -> so ignore CR */
+                   n = '\n';
+               } else {
+                   /* looks like \r was part of the data,
+                      re-position and pass to COBOL data */
+                   fseek ((FILE*)f->file, -1, SEEK_CUR);
+               }
            }

(and no other change in that file)

This change is relative small and it leaves every x'0D' in that does not directly come before x' 0A'. If it works out I'll apply it to the 3.2 release.

Note: after checking 4.x I see that x'0c' (as \f - new page) is also skipped on read, we may need an option to adjust this as this is not conforming to the upcoming COBOL2022 standard (which is the first standard that defines a LINE SEQUENTIALfile type).

[mauro cesar piva]

Hi Simon

Thanks for the feedback... We are trying to compile the libcob/fileio.c library with your suggestion, but we are having problems compiling in our environment

[Simon Sobisch]

I suggest to post compile issues at https://sourceforge.net/p/gnucobol/discussion/help/, there are other people that are likely to help and don't inspect this bug issue.

[mauro cesar piva]

Tks

[Vincent (Bryan) Coen]

On 16/09/2022 02:42, mauro cesar piva wrote:

The COBOL program reads from a sequential file with values ​​of type PIC
S9(15)v99 COMP-3,
Fields with a positive sign (Hec 0C) the reading works correctly.
Fields with negative sign (Hex 0D) the reading returns with error
(non-numeric field),
We performed some tests, if the file does not have organization is Line
Sequential reading
of negative value occurs without problems.

Does anyone have any idea how to get around the problem?

Change file type to Sequential as you found out - LS uses text
terminators of LF and CR on Windows and only one of them for *nix,
and therefore you should NEVER have binary fields present, i.e., only
standard text using PIC A, X, 9, etc NO comp fields or BINARY.

If nothing else the code that extracts each record can and will get
confused when seeing binary fields that match up with the LF, CR values
and you will end up with short length records for processing.

Seq, ISAM, Random etc all works fine for all type of binary data.

This is not special to the GnuCobol as it goes back to mainframe
compiler of the 60's or when ever LS first started - sorry memory is a
bit weak
these days for historic facts but also happens with Micro focus and
other vendor compilers for micro based platforms..

[Ron Norman]

Correct, you should never use BINARY, PACKED, FLOAT etc data in a LINE SEQUENTIAL file.

[Simon Sobisch]

"Fixed" as part of [r4705] as mentioned before - a read with LSQ files will still skip \r, but only if it is followed by \n.
Note: this is only a minor part of that revision, the biggest is a commit of merging several LSQ features from rw/trunk with COB_LS_VALIDATE being the default (COBOL 2022 LSQ support) - I have not rechecked, but I guess to not get a file error you'd have to disable that via COB_LS_VALIDATE=false.

Additional note: if COBOL both reads and writes the file (and only COBOL does this) you can enable COB_LS_NULLS (it mimic an extension from Micro Focus) - this will lead to all those binary data < SPACE to be prefixed by hex-null on [re-]write which is removed on reading. This way "every data" can be stored - even if this effectively drops the option to useful view the file in an editor or use it for import/export.