#1239 GCSORT behaviour with null-terminated strings

[Ralph Linkletter]

Problems with the E15 exit
I have attached the input file. the E15 exit source, the take file.
You must edit the files to reflect the folder / directory of your testing.

The MODS exit E15 is found by GCSORT and executed.
RETURN CODE 4 and RETURN CODE 0 or 20 are functional.
Functional implies that the record returned to the sort is updated.
However RETURN CODE 8 fails to sort the input dataset - it acts as if FIELDS=COPY
No sorting is executed

This is a simplified take file - no concatenated datasets - the sorting was not executed

USE C:\WINZOS\DATA\SORTIN03.DAT RECORD F,00400 ORG SQ
GIVE C:\WINZOS\ZOSICF\S2121958.DAT RECORD F,00400 ORG SQ
OPTION MODS E15=(TESTAE15)

These are screen shots taken as the E15 Exit is processing.

The screen shots attest to executing a functional E15 exit

This screen shot indicates a successful replacement

This is a screen shot when RETURN CODE 8 is passed back to the sort
No sort has been done

The dataset created by the exit when 3 concatenated data sets are presented.
Today's date, time, and size (which is correct)

[Ralph Linkletter]

Adding the attached files - I guess one at a time - strange

[Sauro Menna]

Hi,
I recompiled the COBOL program and used the TAKEFILE.TXT file and input file, even in debug mode, and the sort runs successfully.
In fact, the last records have the character ‘A’ as the first character.
I ran an additional check to sort the gcsort output to verify for errors, but even in this case, the sort is correct.
gcsort USE ..\files\S2121958.DAT RECORD F,00400 ORG SQ GIVE ..\files\S2121958sorted.DAT RECORD F,00400 ORG SQ SORT FIELDS=(1,6,CH,A)

GCSORT Version 01.04.12b
Total Records Number..............: 258
Total Records Write Sort..........: 0
Total Records Write Output........: 258
GCSORT - Sort OK

Compare binary file
..\bin>fc /b ..\files\S2121958.DAT ..\files\S2121958sorted.DAT
Comparing files ..\FILES\S2121958.DAT and ..\FILES\S2121958SORTED.DAT
FC: no differences found

It appears that the last line containing the sort command is not being passed to gcsort: SORT FIELDS=(1,6,CH,A)

I think the sort section [SORT FIELDS=(1,6,CH,A)] is missing from the report:
USE C:\WINZOS\DATA\SORTIN03.DAT RECORD F,00400 ORG SQ
GIVE C:\WINZOS\ZOSICF\S2121958.DAT RECORD F,00400 ORG SQ
OPTION MODS E15= (TESTAE15)
SORT FIELDS=(1,6,CH,A)

Could you check this?
Thank you.
Sauro

[Sauro Menna]

Hi,
That's great.
You can use E15 with multiple streams.
Each stream is processed separately, and GCSort recognizes the value x'08' at the E15 output for each individual stream; therefore, if three files are concatenated, GCSort detects three x'08' values at the E15 output.
Best regards,
Sauro

Il 07/08/2026 16:17 CEST Ralph ralph.linkletter@wincobol.com ha scritto:

This is the batch file that is executed
It specifies the take file

@ECHO OFF
DEL \WINZOS\ZOSICF\GNUERR.TXT
SET GCSORT_STATISTICS=2
GCSORT TAKE \WINZOS\ZOSICF\TAKEFILE.TXT 1>\WINZOS\ZOSICF\SORTAUDIT.TXT
SET RETURNSAVE=%ERRORLEVEL%
IF %RETURNSAVE%==0 EXIT /B 0
@echo ERROR LEVEL=%RETURNSAVE%
ECHO SORT FAILED > \WINZOS\ZOSICF\SORTFAILURE.TXT
COPY \WINZOS\ZOSICF\SORTFAILURE.TXT \WINZOS\ZOSICF\GNUERR.TXT
EXIT /B %RETURNSAVE%

This the the take file (via copy / paste)
USE C:\WINZOS\DATA\SORTIN03.DAT RECORD F,00400 ORG SQ
GIVE C:\WINZOS\ZOSICF\S2122035.DAT RECORD F,00400 ORG SQ
OPTION MODS E15=(TESTAE15)

Notice that sort fields= is missing

This is an edit of take file.txt

The sort fields is present

I am researching
GCSORT does not "see" the sort fields = yet the field is present

Checking to see if it some line sequential text file incompatibility

I see the problem
My sort required null terminated text to be presented to my sort primitives (a "C" driver to the RAAT sort)
That persisted - note the x'00' after the E15)
I will remove the null termination and give it another test

With the null termination removed the sortin data is indeed sorted

Good find Sauro !

I detest line sequential files - precisely because of undetectable error like this.

Is there a problem with concatenated sortin datasets and an E15 sort exit ?

As previously noted each EOF that is detected by GCSORT presents a Flag code of x'08'
Hence if 3 files are concatenated three x'08' are recognized by the E15 EXIT

Is it that your are sorting each concatenation and then merging the sorted subsets or is this not the behavior you would expect ?

I will test that again.

Again good find Sauro !

Thank you !

Ralph / Bruce

[Ralph Linkletter]

You close this
I presented a null terminated parameter - the cause of the issue.
Fixed in my code

[Simon Sobisch]

Can/should the null-terminated parameter be ignored by GCSORT?
Would DFSORT/MFSORT/... handle it differently?

[Ralph Linkletter]

GCSORT stopped reading the parameter file after having encountered a x'00'
DFSORT would continue because there is no LSEQ file organization with
TCB zOS - would require a special ISPF action to edit in a x'00'
MFSORT would require a test.

GnuCOBOL reads the null terminated parameter.

I presume GCSORT is using a "C" function to read the file.
It apparently stopped reading after the x'00'.

The LSEQ record file organization is complicated enough already - it is
really not a portable media.

• CR/LF - Windows
• LF - Linux
• x'1A' not being recognized as EOF but rather a character to be
  processed - it is EOF
• Tab, x'09' that lack context outside of a specific editor / interface

The issue was pointed out by Sauro - A good catch
The resolution - a program update from me.

You can close the bug

Thanks
Bruce

On 8/7/2026 2:22 PM, Simon Sobisch wrote:

Can/should the null-terminated parameter be ignored by GCSORT?
Would DFSORT/MFSORT/... handle it differently?

---

[bugs:#1239] GCSORT behaviour with null-terminated strings

Status: pending
Group: contrib
Labels: GCSORT
Created: Thu Aug 06, 2026 03:55 PM UTC by Ralph Linkletter
Last Updated: Fri Aug 07, 2026 06:22 PM UTC
Owner: Sauro Menna
Attachments:

• E15PROOF1.PNG (sourceforge.net) (6.4 kB; image/png)
• E15PROOF2.PNG (sourceforge.net) (31.4 kB; image/png)
• E15PROOF3.png (sourceforge.net) (56.0 kB; image/png)

Problems with the E15 exit
I have attached the input file. the E15 exit source, the take file.
You must edit the files to reflect the folder / directory of your testing.

The MODS exit E15 is found by GCSORT and executed.
RETURN CODE 4 and RETURN CODE 0 or 20 are functional.
Functional implies that the record returned to the sort is updated.
However RETURN CODE 8 fails to sort the input dataset - it acts as if FIELDS=COPY
No sorting is executed

This is a simplified take file - no concatenated datasets - the sorting was not executed

USE C:\WINZOS\DATA\SORTIN03.DAT RECORD F,00400 ORG SQ
GIVE C:\WINZOS\ZOSICF\S2121958.DAT RECORD F,00400 ORG SQ
OPTION MODS E15=(TESTAE15)

These are screen shots taken as the E15 Exit is processing.

The screen shots attest to executing a functional E15 exit

This screen shot indicates a successful replacement

This is a screen shot when RETURN CODE 8 is passed back to the sort
No sort has been done

The dataset created by the exit when 3 concatenated data sets are presented.
Today's date, time, and size (which is correct)

---

Sent from sourceforge.net because you indicated interest inhttps://sourceforge.net/p/gnucobol/bugs/1239/

To unsubscribe from further messages, please visithttps://sourceforge.net/auth/subscriptions/

[Simon Sobisch]

@smenna if you know where the 0x00 is an issue we could have a look at inspecting that together

@zosralph: Not sure if MF stops at 0x1A (if there is any content behind it like follow-up lines) - can you please check and report back? We could make that configurable via runtime options in GnuCOBOL

[Sauro Menna]

Hi,
Thanks, Simon.
I’ve identified the issue that prevents the use of input files containing binary characters.
The TAKE file used to be opened as text; now it’s opened as a binary file, and the system checks for the presence of ‘0x00’ characters.
I’ve released version 1.04.12c.
Bruce, could you run a test again?
Thanks.
Sauro

[Ralph Linkletter]

Chuck H. and A. Trembley are the only resources I know of that can use
MinGW to do a build.
Mickey tried it for me - no luck.

I know nada about Linux :-(

Chuck is on holiday

I will wait for his return

Thanks for the update

On 8/8/2026 10:55 AM, Sauro Menna wrote:

Hi,
Thanks, Simon.
I’ve identified the issue that prevents the use of input files containing binary characters.
The TAKE file used to be opened as text; now it’s opened as a binary file, and the system checks for the presence of ‘0x00’ characters.
I’ve released version 1.04.12c.
Bruce, could you run a test again?
Thanks.
Sauro

---

[bugs:#1239] GCSORT behaviour with null-terminated strings

Status: closed
Group: contrib
Labels: GCSORT
Created: Thu Aug 06, 2026 03:55 PM UTC by Ralph Linkletter
Last Updated: Fri Aug 07, 2026 08:04 PM UTC
Owner: Sauro Menna
Attachments:

• E15PROOF1.PNG (sourceforge.net) (6.4 kB; image/png)
• E15PROOF2.PNG (sourceforge.net) (31.4 kB; image/png)
• E15PROOF3.png (sourceforge.net) (56.0 kB; image/png)

Problems with the E15 exit
I have attached the input file. the E15 exit source, the take file.
You must edit the files to reflect the folder / directory of your testing.

The MODS exit E15 is found by GCSORT and executed.
RETURN CODE 4 and RETURN CODE 0 or 20 are functional.
Functional implies that the record returned to the sort is updated.
However RETURN CODE 8 fails to sort the input dataset - it acts as if FIELDS=COPY
No sorting is executed

This is a simplified take file - no concatenated datasets - the sorting was not executed

USE C:\WINZOS\DATA\SORTIN03.DAT RECORD F,00400 ORG SQ
GIVE C:\WINZOS\ZOSICF\S2121958.DAT RECORD F,00400 ORG SQ
OPTION MODS E15=(TESTAE15)

These are screen shots taken as the E15 Exit is processing.

The screen shots attest to executing a functional E15 exit

This screen shot indicates a successful replacement

This is a screen shot when RETURN CODE 8 is passed back to the sort
No sort has been done

The dataset created by the exit when 3 concatenated data sets are presented.
Today's date, time, and size (which is correct)

---

Sent from sourceforge.net because you indicated interest inhttps://sourceforge.net/p/gnucobol/bugs/1239/

To unsubscribe from further messages, please visithttps://sourceforge.net/auth/subscriptions/