Thank you for your response and also seeing that this is a problem.
I am a very technical debugger, and know many simple things to try. I tried
all of them. It simply did not make sense that this copy library works fine
when it is not the first 17 bytes of Filename-table-1, but compiles fine
when it starts in byte 18.
My tests using v3.2 final and playing around with the continuation lines
clearly shows a problem with the compiler with FIXED format and usage of
continuations lines.
I therefore take this as a BUG.
@Simon, have you had a play with this code as Cathy supplied in her post 6
hours ago in the file gnutest (created by tar).
Produces 3 errors and warnings for no good reason.
Vincent, any idea when there may be something for me to test that might
address this bug? Since the majority of the programs I have tried to
compile blow up with this error, I do not want to continue.
My tests using v3.2 final and playing around with the continuation lines
clearly shows a problem with the compiler with FIXED format and usage of
continuations lines.
I therefore take this as a BUG.
@Simon, have you had a play with this code as Cathy supplied in her post 6
hours ago in the file gnutest (created by tar).
Produces 3 errors and warnings for no good reason.
Vincent, any idea when there may be something for me to test that might
address this bug? Since the majority of the programs I have tried to
compile blow up with this error, I do not want to continue.
On Mon, Apr 15, 2024 at 5:20 PM Vincent (Bryan) Coen
vcoen@users.sourceforge.net wrote:
I am thoroughly confused by your response, because the last email on this
Discussion was from you. Stating your exact words "
"I therefore take this as a BUG."
what else do I need to do on this side. Since you determined this was
a BUG, is there a different area on gnucobol
that I need to report a bug????
On Mon, Apr 15, 2024 at 5:20 PM Vincent (Bryan) Coen
My tests using v3.2 final and playing around with the
continuation
lines clearly shows a problem with the compiler with FIXED
format and usage of continuations lines.
I therefore take this as a BUG.
@Simon, have you had a play with this code as Cathy supplied in
her post 6 hours ago in the file gnutest (created by tar).
Vincent, any idea when there may be something for me to test that might
address this bug? Since the majority of the programs I have tried to
compile blow up with this error, I do not want to continue.
On Mon, Apr 15, 2024 at 5:20 PM Vincent (Bryan) Coen
vcoen@users.sourceforge.net wrote:
My tests using v3.2 final and playing around with the continuationlinesclearly shows a problem with the compiler with FIXED format andusage ofcontinuations lines.
I therefore take this as a BUG.
@Simon, have you had a play with this code as Cathy supplied inher post 6hours ago in the file gnutest (created by tar).
Another possible solution is to write a small Cobol program that reads
in a file, changes the extension to .bac then :
opens as input (LS) as pic x(80) stores in WS-rec-area pic x(250).
Opens output file (LS) pic x(250)
create new record with:
>>source variable
Then for each record read inspect for all quotes tallying in A.
if A = 1
perform merge-lines
else if in-rec (1:72) not = spaces and numeric *> possible numeric lit
perform Merge-Lines-Number
merge sections read in next rec and if In-Rec (1:7) = "-"
odd extra if test or more,
move Length-of-Chars in cc(12:61) to A
move In-Rec (12:A) to WS-Rec-Area (73:178)
write out-rec from WS-rec-area
repeat etc.
At EOF close files goback.
Create a script that for every Cobol source file calls program passing
in and out file names such as :
!/bin/bash
for i in ls *.CBL; do special-prog $i
You should clean up above prog to provide o/p file name with extension
.CBL or what ever you wish to use.
Rename all input files to *.bac (for back up) avoid any issues if you
use a editor that create a .bak file which looses the original backed up
file.
Note that you are only moving over the first 72 chars of a source file
dropping cc73-80.
I have made NO attempt at checking the above logic and there is likely
to be more coding required.
Now you can compile all
On 19/04/2024 16:41, Cathy Welsh wrote:
Vincent, any idea when there may be something for me to test that might
address this bug? Since the majority of the programs I have tried to
compile blow up with this error, I do not want to continue.
On Mon, Apr 15, 2024 at 5:20 PM Vincent (Bryan) Coen
vcoen@users.sourceforge.net wrote:
What?????
So you want me to create a new Pre-parse routine, to go through all of my
programs that will change them to not be formatted in the 72 column format
that ONLY Microfocus COBOL required.
CDMS wrote the pre-parsing program to convert these into 72 column as
MICROFOCUS v 3..0 required it. Before that we used RSX-COBOL and VAX-COBOL
and they did not require the 72 column format.
This is just nuts. The documentation for GNU COBOL was described as being
MF Cobol compatible. there are 2 STD that pertain to MF COBOL MF and
MF-STRICT. I compile this in DEFAULT, and there is the same 3 errors,
which on the std=mf-strict there is only 1 ERROR.
Why would the names of the COBOL programs need to be changed? A COBOL
compiler should be able to convert any COBOL program as long as you supply
the name.
NONE of my application programs have an extension of .COB, they have an
extension of what Module in CDMS they are, such AR for Accounts Receivable,
AP for Accounts Payable, PR for Payroll, IN for Inventory and so on.
Another possible solution is to write a small Cobol program that reads
in a file, changes the extension to .bac then :
opens as input (LS) as pic x(80) stores in WS-rec-area pic x(250).
Opens output file (LS) pic x(250)
create new record with:
>>source variable
Then for each record read inspect for all quotes tallying in A.
if A = 1
perform merge-lines
else if in-rec (1:72) not = spaces and numeric *> possible numeric lit
perform Merge-Lines-Number
merge sections read in next rec and if In-Rec (1:7) = "-"
odd extra if test or more,
move Length-of-Chars in cc(12:61) to A
move In-Rec (12:A) to WS-Rec-Area (73:178)
write out-rec from WS-rec-area
repeat etc.
At EOF close files goback.
Create a script that for every Cobol source file calls program passing
in and out file names such as :
!/bin/bash
for i in ls *.CBL; do special-prog $i
You should clean up above prog to provide o/p file name with extension
.CBL or what ever you wish to use.
Rename all input files to *.bac (for back up) avoid any issues if you
use a editor that create a .bak file which looses the original backed up
file.
Note that you are only moving over the first 72 chars of a source file
dropping cc73-80.
I have made NO attempt at checking the above logic and there is likely
to be more coding required.
Now you can compile all
On 19/04/2024 16:41, Cathy Welsh wrote:
Vincent, any idea when there may be something for me to test that might
address this bug? Since the majority of the programs I have tried to
compile blow up with this error, I do not want to continue.
On Mon, Apr 15, 2024 at 5:20 PM Vincent (Bryan) Coen
vcoen@users.sourceforge.net wrote:
My tests using v3.2 final and playing around with the continuationlinesclearly shows a problem with the compiler with FIXED format andusage ofcontinuations lines.
I therefore take this as a BUG.
@Simon, have you had a play with this code as Cathy supplied inher post 6hours ago in the file gnutest (created by tar).
My example of a Cobol program to deal with the issue NOW while waiting
for the fix is
a time saver for you.
My example of using .COB is just that change the script to capture what
ever extension your company uses.
on the basis of you wishing to create something like it.
It is just one possible solution to your immediate issue.
I need to point out that the source formats available for any program in
gnucobol (as per the PG) is:
FIXED - 80 column split as Areas A and B with cc73-80 no care
VARIABLE - 250 column as FIXED for CC 1 through 72 but but the rest is
extensions of the area available for source code.
FREE - 250+ columns using the free format where fixed cc 1 - 6 is
removed, cc7 removed or replaced for comment as *>
GnuCobol is more up to date regarding the Cobol standards than any other
compiler out there and that includes IBM and MF
There are a few more available when migrating from very old kit.
If you wish to wait for a fix then fair enough.
Regardless you must file a BUG report via the website and the Tickets->
Bugs facility.
Do not forget to include the version of the compiler you are using such
as v3.2 final etc.
Sorry I do not have the time to do it for you as I am busy with my own
applications of some 1000+ programs and that includes testing, manual
writing, bug fixing etc and I am also on my own doing this - and I do
NOT get paid as retired.
When creating the bug report only cover the area that is related to the
problems i.e the extension of both numbers and literals / constants on
fixed format sources.
On 19/04/2024 18:26, Cathy Welsh wrote:
What?????
So you want me to create a new Pre-parse routine, to go through all of my
programs that will change them to not be formatted in the 72 column format
that ONLY Microfocus COBOL required.
CDMS wrote the pre-parsing program to convert these into 72 column as
MICROFOCUS v 3..0 required it. Before that we used RSX-COBOL and VAX-COBOL
and they did not require the 72 column format.
This is just nuts. The documentation for GNU COBOL was described as being
MF Cobol compatible. there are 2 STD that pertain to MF COBOL MF and
MF-STRICT. I compile this in DEFAULT, and there is the same 3 errors,
which on the std=mf-strict there is only 1 ERROR.
Why would the names of the COBOL programs need to be changed? A COBOL
compiler should be able to convert any COBOL program as long as you supply
the name.
NONE of my application programs have an extension of .COB, they have an
extension of what Module in CDMS they are, such AR for Accounts
Receivable,
AP for Accounts Payable, PR for Payroll, IN for Inventory and so on.
Thank you for your response and also seeing that this is a problem.
I am a very technical debugger, and know many simple things to try. I tried
all of them. It simply did not make sense that this copy library works fine
when it is not the first 17 bytes of Filename-table-1, but compiles fine
when it starts in byte 18.
On Mon, Apr 15, 2024, 5:20 PM Vincent (Bryan) Coen vcoen@users.sourceforge.net wrote:
Vincent, any idea when there may be something for me to test that might
address this bug? Since the majority of the programs I have tried to
compile blow up with this error, I do not want to continue.
On Mon, Apr 15, 2024 at 5:20 PM Vincent (Bryan) Coen vcoen@users.sourceforge.net wrote:
I cannot find you bug report for this problem.
If you do not report it - it cannot be fixed :)
On 19/04/2024 16:41, Cathy Welsh wrote:
I am thoroughly confused by your response, because the last email on this
Discussion was from you. Stating your exact words "
"I therefore take this as a BUG."
what else do I need to do on this side. Since you determined this was
a BUG, is there a different area on gnucobol
that I need to report a bug????
continuation
format and usage of continuations lines.
I therefore take this as a BUG.
@Simon, have you had a play with this code as Cathy supplied in
her post 6 hours ago in the file gnutest (created by tar).
On Fri, Apr 19, 2024 at 12:57 PM Vincent (Bryan) Coen vcoen@users.sourceforge.net wrote:
Another possible solution is to write a small Cobol program that reads
in a file, changes the extension to .bac then :
opens as input (LS) as pic x(80) stores in WS-rec-area pic x(250).
Opens output file (LS) pic x(250)
create new record with:
>>source variable
Then for each record read inspect for all quotes tallying in A.
if A = 1
perform merge-lines
else if in-rec (1:72) not = spaces and numeric *> possible numeric lit
perform Merge-Lines-Number
merge sections read in next rec and if In-Rec (1:7) = "-"
odd extra if test or more,
move Length-of-Chars in cc(12:61) to A
move In-Rec (12:A) to WS-Rec-Area (73:178)
write out-rec from WS-rec-area
repeat etc.
At EOF close files goback.
Create a script that for every Cobol source file calls program passing
in and out file names such as :
!/bin/bash
for i in
ls *.CBL; do special-prog $iYou should clean up above prog to provide o/p file name with extension
.CBL or what ever you wish to use.
Rename all input files to *.bac (for back up) avoid any issues if you
use a editor that create a .bak file which looses the original backed up
file.
Note that you are only moving over the first 72 chars of a source file
dropping cc73-80.
I have made NO attempt at checking the above logic and there is likely
to be more coding required.
Now you can compile all
On 19/04/2024 16:41, Cathy Welsh wrote:
What?????
So you want me to create a new Pre-parse routine, to go through all of my
programs that will change them to not be formatted in the 72 column format
that ONLY Microfocus COBOL required.
CDMS wrote the pre-parsing program to convert these into 72 column as
MICROFOCUS v 3..0 required it. Before that we used RSX-COBOL and VAX-COBOL
and they did not require the 72 column format.
This is just nuts. The documentation for GNU COBOL was described as being
MF Cobol compatible. there are 2 STD that pertain to MF COBOL MF and
MF-STRICT. I compile this in DEFAULT, and there is the same 3 errors,
which on the std=mf-strict there is only 1 ERROR.
Why would the names of the COBOL programs need to be changed? A COBOL
compiler should be able to convert any COBOL program as long as you supply
the name.
NONE of my application programs have an extension of .COB, they have an
extension of what Module in CDMS they are, such AR for Accounts Receivable,
AP for Accounts Payable, PR for Payroll, IN for Inventory and so on.
On Fri, Apr 19, 2024 at 1:18 PM Vincent (Bryan) Coen vcoen@users.sourceforge.net wrote:
My example of a Cobol program to deal with the issue NOW while waiting
for the fix is
a time saver for you.
My example of using .COB is just that change the script to capture what
ever extension your company uses.
on the basis of you wishing to create something like it.
It is just one possible solution to your immediate issue.
I need to point out that the source formats available for any program in
gnucobol (as per the PG) is:
FIXED - 80 column split as Areas A and B with cc73-80 no care
VARIABLE - 250 column as FIXED for CC 1 through 72 but but the rest is
extensions of the area available for source code.
FREE - 250+ columns using the free format where fixed cc 1 - 6 is
removed, cc7 removed or replaced for comment as *>
GnuCobol is more up to date regarding the Cobol standards than any other
compiler out there and that includes IBM and MF
There are a few more available when migrating from very old kit.
If you wish to wait for a fix then fair enough.
Regardless you must file a BUG report via the website and the Tickets->
Bugs facility.
Do not forget to include the version of the compiler you are using such
as v3.2 final etc.
Sorry I do not have the time to do it for you as I am busy with my own
applications of some 1000+ programs and that includes testing, manual
writing, bug fixing etc and I am also on my own doing this - and I do
NOT get paid as retired.
When creating the bug report only cover the area that is related to the
problems i.e the extension of both numbers and literals / constants on
fixed format sources.
On 19/04/2024 18:26, Cathy Welsh wrote: