Need some expertise please
What is the Gnu hex value for NULL ?
x'00'(s), x'3F'(s), x'FF'(s)
A bizarre defect on my behalf - sort of.
I compiled a .DLL module with 3.1 Dev
The foreign .EXE unknowingly executed the .DLL via the 3.0 RC1 RTS
An error message is generated - however it is never displayed because the caller (a foreign .EXE) was not a GnuCOBOL module.
I knew about this from WINIDE development but I was focused on vetting WINZOS.
Apparently the active console handles (STDIN, STDOUT, STDERR) are owned by the "foreign" .EXE but are unavailable to the GnuCOBOL RTS . I presume the effect to be that the Gnu RTS is communicating with a console device that is not physically available.
It took took forever to understand why a return to Windows (instead of the caller) with no indication as to why ? No abend, no interrupt message but rather a return to the command line.
Ralph
Last edit: Ralph Linkletter 2021-05-30
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Need some expertise please
What is the Gnu hex value for NULL ?
x'00'(s), x'3F'(s), x'FF'(s)
A bizarre defect on my behalf - sort of.
I compiled a .DLL module with 3.1 Dev
The foreign .EXE unknowingly executed the .DLL via the 3.0 RC1 RTS
An error message is generated - however it is never displayed because the caller (a foreign .EXE) was not a GnuCOBOL module.
I knew about this from WINIDE development but I was focused on vetting WINZOS.
Apparently the active console handles (STDIN, STDOUT, STDERR) are owned by the "foreign" .EXE but are unavailable to the GnuCOBOL RTS . I presume the effect to be that the Gnu RTS is communicating with a console device that is not physically available.
It took took forever to understand why a return to Windows (instead of the caller) with no indication as to why ? No abend, no interrupt message but rather a return to the command line.
Ralph
Last edit: Ralph Linkletter 2021-05-30