Just an FYI, since the company is still under contract with Micro Focus, we are going to download their Visual cobol 9 Update 6 to see what they may have messed with. If we move forward with GNUCOBOL once we can get everything compiled and tested, then I want to at least have the most current version of Visual COBOL before we terminate support. From a Development point of view, it only makes sense, to have the latest version that will work with the latest versions of the OS's supported. I will keep you posted on that as well, if you would like. The difficulty I am having now, is they changed their website, and have everything buried, and logging in, and going to my profile, you would think that your products would be listed, but this is NOT the case, and no place to search once you are logged in. The absolute worst website design I have ever seen for user accounts.
Last edit: Simon Sobisch 2024-04-09
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had a free 15 minutes today in-between drafts of Corp tax returns to test
something.
Leaving everything in Test.cob tge same but 1 thing. Instead of having
Compfi.fn as a copy library, I actually removed the Copy command and pasted
it directly into the program as is.
It compiled.
When I replaced the copy library, the same error exists.
So I am pretty stumped. This same copy library works in over 600 programs
in CDMS, compiles just fine.
I have been buried with accounting things as I am our corporate controller
as well, and our outside CPA has a bunch of young clerks working with him
this year, and they are transposing numbers, and never checking anything. I
am on the 5th draft of our returns for federal, have not reviewed our NJ
for the 5th time .
These young ckerks, just punch numbers, rely 100% on the computer to do
everything and if a Calc does not give them the result, they just plug a
number instead of using their brains to figure it out.
I am hoping to be back on this next week, and will try compiling a few more
programs to see what happens.
I still have not looked into getting a RTS for Isam4 or 8 yet.
Mf cobol can do Isam8 files on Visual Cobol.
I've asked for a minimal example, so just take your program, remove
everything after the error, then as much before as possible to still have a
valid program, then provide a zip/tarball with the reproducer (I guess 2
files, but maybe it doesn't even need a copybook).
It looks like you're nearly there, so I can take that and focus on fixing
it.
I am unsure what you are talking about. The actual contents of the 05 and
10 levels end before column 72. the COMPFI.F starts in column 73 through
80 which is allowed.
Only MF COBOL forced us to keep things as strict as not surpassing column
72.
VAX COBOL and TSX COBOL allowed us to go to column 132 or further if needed.
Even if I remove the COMPFI.F from each of the 6 lines of COMPFI.FN, it
still errors out. Nothing in this file defined past column 72, no
continuation code is needed.
I removed the comment in column 73 - 80 that were COMPFI.F and recompiled
again.
As you can plainly see in the .prn attached, it is having a problem with a
file definition structure of
01 filename-table-1.
05 COMP-FIL-ID.
It has a problem with the 05 COMP-FIL-ID because it does not have a PIC
value.
In the attached example test2-41524.prn , i changed the COPY LIB COMPFI.FN
so that the 05 level would be COMP-FIL-ID PIC X(14) VALUE "MST/??COMP ".
05 COMP-FIL-RED REDEFINES COMP-FIL-ID.
It STILL errors out at the same exact place. This has nothing to do with
how this copy library is formatted. When I put the same LIB/COMPFI.FN
after the XXVDCK-FIL-NAME
definition, not changing anything else, the program compiles just fine.
If this was a bad file, then it SHOULD fail the compilation test regardless
where this file is located in the filename-table-1 element, but it does
not, it only fails when it is the first element
defined under 01 filename-table-1.
Again, the error is NOT the column formatting of this file, but where it is
located in the 01 filename-table-1 element. There is some sort of parsing
error in gnucobol.
I had a free 15 minutes today in-between drafts of Corp tax returns to test
something.
Leaving everything in Test.cob tge same but 1 thing. Instead of having
Compfi.fn as a copy library, I actually removed the Copy command and pasted
it directly into the program as is.
It compiled.
When I replaced the copy library, the same error exists.
So I am pretty stumped. This same copy library works in over 600 programs
in CDMS, compiles just fine.
I have been buried with accounting things as I am our corporate controller
as well, and our outside CPA has a bunch of young clerks working with him
this year, and they are transposing numbers, and never checking anything. I
am on the 5th draft of our returns for federal, have not reviewed our NJ
for the 5th time .
These young ckerks, just punch numbers, rely 100% on the computer to do
everything and if a Calc does not give them the result, they just plug a
number instead of using their brains to figure it out.
I am hoping to be back on this next week, and will try compiling a few more
programs to see what happens.
I still have not looked into getting a RTS for Isam4 or 8 yet.
Mf cobol can do Isam8 files on Visual Cobol.
On Fri, Apr 5, 2024, 4:08 PM Simon Sobisch sf-mensch@users.sourceforge.net
wrote:
I've asked for a minimal example, so just take your program, remove
everything after the error, then as much before as possible to still have a
valid program, then provide a zip/tarball with the reproducer (I guess 2
files, but maybe it doesn't even need a copybook).
It looks like you're nearly there, so I can take that and focus on fixing
it.
error: syntax error, unexpected Identifier, expecting AUTOMATIC or
EXCLUSIVE or MANUAL
Please supply the sources to your sample program with all the required
copybooks for it as one archive. I would like to test this on a Linux
based system using GC v3.2 final.
Also advise exactly what the steering commands you are using to compile
the program and any changes to the default gc set ups if any.
Personally I do not do so here as only use the --std=default but this is
omitted from such steering command.
For example is just use for modules : cobc -m progname.cbl -T progname.prn
and for programs cobc -x progname.cbl -T progname.prn
The "-T progname.prn" is only during early compile so as to read all
the warning/error messages otherwise it is omitted.
During testing I do add -d -g -ftraceall -fdump=ALL as well to find any
oddities in use of LINKAGE SECTION and other runtime errors such as
having non numerics if number fields etc. I has proved handy in bug tracing.
The -fdump=all create a dump of all of the stated variables for all WS
areas including file if the program under test does a aborted dump when
running.
Vince
On 15/04/2024 15:03, Cathy Welsh wrote:
I am unsure what you are talking about. The actual contents of the 05 and
10 levels end before column 72. the COMPFI.F starts in column 73 through
80 which is allowed.
Only MF COBOL forced us to keep things as strict as not surpassing column
72.
VAX COBOL and TSX COBOL allowed us to go to column 132 or further if
needed.
Even if I remove the COMPFI.F from each of the 6 lines of COMPFI.FN, it
still errors out. Nothing in this file defined past column 72, no
continuation code is needed.
I removed the comment in column 73 - 80 that were COMPFI.F and recompiled
again.
As you can plainly see in the .prn attached, it is having a problem with a
file definition structure of
01 filename-table-1.
05 COMP-FIL-ID.
It has a problem with the 05 COMP-FIL-ID because it does not have a PIC
value.
In the attached example test2-41524.prn , i changed the COPY LIB COMPFI.FN
so that the 05 level would be COMP-FIL-ID PIC X(14) VALUE "MST/??COMP ".
05 COMP-FIL-RED REDEFINES COMP-FIL-ID.
It STILL errors out at the same exact place. This has nothing to do with
how this copy library is formatted. When I put the same LIB/COMPFI.FN
after the XXVDCK-FIL-NAME
definition, not changing anything else, the program compiles just fine.
If this was a bad file, then it SHOULD fail the compilation test
regardless
where this file is located in the filename-table-1 element, but it does
not, it only fails when it is the first element
defined under 01 filename-table-1.
Again, the error is NOT the column formatting of this file, but where
it is
located in the 01 filename-table-1 element. There is some sort of parsing
error in gnucobol.
I have included everything you need in an unzipped tar ball gnutest.
The only config settings that Simon had me change was
The first and last are obviously errors (I've rechecked the MF docs, too);
this will be fixed in the next version, for now please adjust the installed
"mf-strict.conf" file (see cobc --info where COB_CONFIG_DIR is) as follows:
-assign-variable: unconformable+assign-variable: ok
COB_CONFIG_DIR : /usr/local/share/gnucobol/config
mf-strict.conf
assign-variable: ok
I have not set anything else up. No other settings have been changed, I
have not read enough of the documentation, which is mountainous, to change
anything.
Sometime if I do not want the printout,
cobc -std=mfstrict --debug SRC/TEST.COB
Simon had me 1 time compile with the -i option and he said the reproducer.i
file compiled fine, even though it errored out on the SRC/TEST.COB compile.
But I have not tried the reproducer.i option, as not sure how to deal with
that.
Please supply the sources to your sample program with all the required
copybooks for it as one archive. I would like to test this on a Linux
based system using GC v3.2 final.
Also advise exactly what the steering commands you are using to compile
the program and any changes to the default gc set ups if any.
Personally I do not do so here as only use the --std=default but this is
omitted from such steering command.
For example is just use for modules : cobc -m progname.cbl -T progname.prn
and for programs cobc -x progname.cbl -T progname.prn
The "-T progname.prn" is only during early compile so as to read all
the warning/error messages otherwise it is omitted.
During testing I do add -d -g -ftraceall -fdump=ALL as well to find any
oddities in use of LINKAGE SECTION and other runtime errors such as
having non numerics if number fields etc. I has proved handy in bug
tracing.
The -fdump=all create a dump of all of the stated variables for all WS
areas including file if the program under test does a aborted dump when
running.
Vince
On 15/04/2024 15:03, Cathy Welsh wrote:
I am unsure what you are talking about. The actual contents of the 05 and
10 levels end before column 72. the COMPFI.F starts in column 73 through
80 which is allowed.
Only MF COBOL forced us to keep things as strict as not surpassing column
72.
VAX COBOL and TSX COBOL allowed us to go to column 132 or further if
needed.
Even if I remove the COMPFI.F from each of the 6 lines of COMPFI.FN, it
still errors out. Nothing in this file defined past column 72, no
continuation code is needed.
I removed the comment in column 73 - 80 that were COMPFI.F and recompiled
again.
As you can plainly see in the .prn attached, it is having a problem with a
file definition structure of
01 filename-table-1.
05 COMP-FIL-ID.
It has a problem with the 05 COMP-FIL-ID because it does not have a PIC
value.
In the attached example test2-41524.prn , i changed the COPY LIB COMPFI.FN
so that the 05 level would be COMP-FIL-ID PIC X(14) VALUE "MST/??COMP ".
05 COMP-FIL-RED REDEFINES COMP-FIL-ID.
It STILL errors out at the same exact place. This has nothing to do with
how this copy library is formatted. When I put the same LIB/COMPFI.FN
after the XXVDCK-FIL-NAME
definition, not changing anything else, the program compiles just fine.
If this was a bad file, then it SHOULD fail the compilation test
regardless
where this file is located in the filename-table-1 element, but it does
not, it only fails when it is the first element
defined under 01 filename-table-1.
Again, the error is NOT the column formatting of this file, but where
it is
located in the 01 filename-table-1 element. There is some sort of parsing
error in gnucobol.
And why would that matter only when LiB/COMPFI.FN is listed as the first
element under filename-Table-1, but does not erro out if it is the 2nd
element in the table.
If the GBUCobol compiler is going to error on a space after a period before
the lf, then this is going to be a nightmare, a I am just going to stop
wasting my time and everyone else in this group.
There is nothing in any cobol standard that I have worked on from 1984 that
states you cannot have any spaces after a period before a lf.
For those of you that don't seem to believe that the COMPFI.FN copy library
is fine. I have moved it to below the XXVDCK-FIL-NAME entry in the element
01 FILENAME-TABLE-1.
In this position it compiles fine. I have attached the full listing.
I had a free 15 minutes today in-between drafts of Corp tax returns to test
something.
Leaving everything in Test.cob tge same but 1 thing. Instead of having
Compfi.fn as a copy library, I actually removed the Copy command and pasted
it directly into the program as is.
It compiled.
When I replaced the copy library, the same error exists.
So I am pretty stumped. This same copy library works in over 600 programs
in CDMS, compiles just fine.
I have been buried with accounting things as I am our corporate controller
as well, and our outside CPA has a bunch of young clerks working with him
this year, and they are transposing numbers, and never checking anything. I
am on the 5th draft of our returns for federal, have not reviewed our NJ
for the 5th time .
These young ckerks, just punch numbers, rely 100% on the computer to do
everything and if a Calc does not give them the result, they just plug a
number instead of using their brains to figure it out.
I am hoping to be back on this next week, and will try compiling a few more
programs to see what happens.
I still have not looked into getting a RTS for Isam4 or 8 yet.
Mf cobol can do Isam8 files on Visual Cobol.
On Fri, Apr 5, 2024, 4:08 PM Simon Sobisch sf-mensch@users.sourceforge.net
wrote:
I've asked for a minimal example, so just take your program, remove
everything after the error, then as much before as possible to still have a
valid program, then provide a zip/tarball with the reproducer (I guess 2
files, but maybe it doesn't even need a copybook).
It looks like you're nearly there, so I can take that and focus on fixing
it.
error: syntax error, unexpected Identifier, expecting AUTOMATIC or
EXCLUSIVE or MANUAL
I added the 2 lines to the mf-strict.conf which was located in /usr/local/share/gnucobol/config
-assign-variable: unconformable+assign-variable: ok
I then recompiled the TEST.COB again, and still received the 3 errors when using the cobc SRC/TEST.COB -std=mf-strict
Regarding the Value of ID contained in the MSL/VALUE.ID copy library, I have been using this on MF COBOL v3.259 from 1990, and the RHEL MF VISUAL Cobol v5.07 and no errors whatsoever on compilation.
Until I can get some programs compiled without errors, and am able to see how the screens look and act, I don't really want to change
much at this point, as there is already quite a list of stuff that I will need to change, and it does involve changing all 3800 programs.
Starting another thread on a different set of questions.
Last edit: Simon Sobisch 2024-04-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is a misunderstanding, this was a diff, so take the two additional lines out and make the change for assign-variable from unconformable to ok
Regarding the Value of ID contained in the MSL/VALUE.ID copy library, I have been using this on MF COBOL v3.259 from 1990, and the RHEL MF VISUAL Cobol v5.07 and no errors whatsoever on compilation.
GC won't error (only raise a warning when you increase the warning level). So feel free to keep that as-is.
there is already quite a list of stuff that I will need to change, and it does involve changing all 3800 programs
this shouldn't be the case. I intend to fix the $ thing and the broken $REMOVE soon you could use a 3.3-development snapshot afterwards.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, that was much better, now it just shows that one error:
LIB/COMPFI.FN:1: error: continuation character expected
Regarding the 3.3-development snapshot, that would be fine. I have only tried to compile a few programs to start. Maybe I will try a full compile and see what happens. Might not be something I want to start on a Friday, and then have my head in this all weekend, when I need to get outside. It is finally going to NOT be raining this weekend, and so need some sunshine.
If I do decide to attempt the recompile, I will let you know if I find any other beauties. HA.
Thank you.
Last edit: Simon Sobisch 2024-04-09
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2024-04-05
This is a long shot.
Sometimes unprintable characters such as <np> (null pointer) are embedded in a text file.</np>
This can cause strange errors when these text files are parsed.
You can check the contents of any file using a file viewer-editor such as Ghex.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I added a blank line at the end of the copy library, and it made no
difference.
Funny thing, was when I copied the contents of the LIB/COMPFI.FN directly
into the program as it existed in the LIB it compiles correctly.
I updated Simon on my test yesterday, and am very much stumped. Many of my
programs all use Copy libraries, as we support more than 1 Platform, and
more than 1 compiler.
For the files that are the same across all platforms, they are contained in
LIB, for things that are unique per platform, the MSL copy libraries are
used.
COMPFI.FN is a LIB. This little file has not changed since 1982, and was
brought over to Unix in Late 1988 for Micro Focus Cobol v 3.0 for SCO Unix
3.2.2.
Thank you, it was worth a try. I did post the full listing of the program
the other day.
Have had a similar problem with MF COBOL on windows platform under DOS. Would use a windows based editor save the code then compile in a DOS window. Take a look at a copy file that is working with an editor that will allow HEX mode and compare to the problem file to see if anything is lurking at the end of the file.
Found I had to hit enter a couple of times after the last character to insert a couple of blank lines then select them with ctrl down arrow which appeared to pick up some none displayed rubbish and then hit delete. Just inserting a blank line or 2 without deleting will just move the problem down.
Can't remember what the none displayed characters were now but it was a pain. It may have been that someone else had worked on the files in a different editor.
DaveR
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
These copy files have not been touched since 1989 when they were brought
down to Sco Unix to compile on MF cobol v3.259.
I have tried yesterday, retyping in the copy library in a new file, it
still will not work as the copy file. It only works when I don't use the
copy file, but copy and paste the contents into the program.
These were created using text editor on TSX text edit on Pdp-11 in 1982,
and then transferred using Kermit to Unix in 1989 and then ftp to RHEL in
2018.
This file compiles successfully today on Vaxcobol, Sco Unix on MF cobol
3.259 and Rhel 7.06 on MF visual cobol 5.06.
It only does not work on GNU Cobol.
Have had a similar problem with MF COBOL on windows platform under DOS.
Would use a windows based editor save the code then compile in a DOS
window. Take a look at a copy file that is working with an editor that will
allow HEX mode and compare to the problem file to see if anything is
lurking at the end of the file.
Found I had to hit enter a couple of times after the last character to
insert a couple of blank lines then select them with ctrl down arrow which
appeared to pick up some none displayed rubbish and then hit delete. Just
inserting a blank line or 2 without deleting will just move the problem
down.
Can't remember what the none displayed characters were now but it was a
pain. It may have been that someone else had worked on the files in a
different editor.
Cathy
What editor are you using?
Some editors leave an end of file marker that might be incompatible with how GC does copybooks.
You might look to see in a hex editor what the final characters of the file are.
I don't know how GC handles DOS vs UNIX line endings or file endings.
I am sure it is something simple.
You have my email if you wish to send me the copy book in question and I will take a look
I currently don't have GC running. I need to get something setup soon.
At one time I did have it working on OSR6 MP4, haven't tried on Definitive 2018 or the soon to be released MP and UP's.
Paul
These copy files have not been touched since 1989 when they were brought
down to Sco Unix to compile on MF cobol v3.259.
I have tried yesterday, retyping in the copy library in a new file, it
still will not work as the copy file. It only works when I don't use the
copy file, but copy and paste the contents into the program.
These were created using text editor on TSX text edit on Pdp-11 in 1982,
and then transferred using Kermit to Unix in 1989 and then ftp to RHEL in
2018.
This file compiles successfully today on Vaxcobol, Sco Unix on MF cobol
3.259 and Rhel 7.06 on MF visual cobol 5.06.
It only does not work on GNU Cobol.
On Sat, Apr 13, 2024, 2:58 AM DaveR [ mailto:dave4583@users.sourceforge.net | dave4583@users.sourceforge.net ] wrote:
Have had a similar problem with MF COBOL on windows platform under DOS.
Would use a windows based editor save the code then compile in a DOS
window. Take a look at a copy file that is working with an editor that will
allow HEX mode and compare to the problem file to see if anything is
lurking at the end of the file.
Found I had to hit enter a couple of times after the last character to
insert a couple of blank lines then select them with ctrl down arrow which
appeared to pick up some none displayed rubbish and then hit delete. Just
inserting a blank line or 2 without deleting will just move the problem
down.
Can't remember what the none displayed characters were now but it was a
pain. It may have been that someone else had worked on the files in a
different editor. DaveR
Hi Paul, I sent the actual copy library on this thread yesterday.
I did a hexdemp on the file which as not changed since 1989, saw no
characters other than LF 0a in the file after each line.
I deleted the file, created a new one with the data in exactly the same
position, and recompiled, same error.
When I hard code the contents of the Lib inside the program, it compiles.
I even changed the name of the file thinking that it has an issue with the
names COMP-FIL or value "COMP", changed them to CMPO and it made no
difference.
I used "vi" to put the additional blank line in the file. It was originally
edited on a PDP Rsx cobol in 1982 then transferred with Kermit to Unix in
1989. Again, doing a hexdump -C only shows the additional occurrence of 0A.
I have lots of other copy libs of filename definition, because our
software supports multi company (EIN) function, and that means the filename
contains the company code in the desired location, which a program called
"FILSET" uses, to place the PASSED Company code to the designated position
in the filename. The filler in the filename definition that shows "052"
means that in the 5th position of the filename, substitute for 2 positions
the company code or LINE Number.
I just moved the copy library of LIB/COMPFI.FN to below the definition of
the XXVDCK-FIL-NAME in the 01 filename-table-01 element, and it compiled,
but it will not compile if it is the first element listed in the 01 level
FILENAME-TABLE-1.
This absolutely makes no sense to me. I have also tried changing the
COMPFI.FN so that the first 05 level is COMP-FIL-ID PIC X(14) VALUE
"MST/??COMP ". Then add a REdefine 05 level below that, and it made no
difference.
If this file is the 1st 05 level in the filename-table-1 it will not
compile.
I would have to go into 860 approx programs and re-arrange the
Filename-tables so that if COMPFI.FN is there, to move it out of the first
position. This has only been 1 program that I tried to compile with
gnucobol and am wondering how many others I am going to have different
problems. I am limiting the numbers I am compiling as every single CDMS
programs has the MF COBOL compile directives, and have to remove them in
order to even attempt to get any program even close to compiling.
If you think of anything else to try, please let me know. It is VERY
bizarre that the same identical COPY LIB compiles fine in the program as
long as it is NOT the first 05 level in the filename-table.
I have attached 2 complete Listings of the program. The testorig041324.prn
is when the LIB/COMPFI.FN is the 1st 05 level entry under 01
FILE-NAME-TABLE-1. This one does not compile.
the 2nd file test041324.prn is when I moved the LIB/COMPFI.FN 2nd in the
filename-table-1 under the XXVDCK-FIL-NAME entry. This program compiles
successfully.
Cathy
What editor are you using?
Some editors leave an end of file marker that might be incompatible with
how GC does copybooks.
You might look to see in a hex editor what the final characters of the
file are.
I don't know how GC handles DOS vs UNIX line endings or file endings.
I am sure it is something simple.
You have my email if you wish to send me the copy book in question and I
will take a look
I currently don't have GC running. I need to get something setup soon.
At one time I did have it working on OSR6 MP4, haven't tried on Definitive
2018 or the soon to be released MP and UP's.
Paul
From: "Cathy Welsh" cswelsh-cdms@users.sourceforge.net
To: "gnucobol" help@discussion.gnucobol.p.re.sourceforge.net
Sent: Saturday, April 13, 2024 7:29:54 AM
Subject: [gnucobol:discussion] Re: error: syntax error, unexpected
Identifier, expecting AUTOMATIC or EXCLUSIVE or MANUAL
These copy files have not been touched since 1989 when they were brought
down to Sco Unix to compile on MF cobol v3.259.
I have tried yesterday, retyping in the copy library in a new file, it
still will not work as the copy file. It only works when I don't use the
copy file, but copy and paste the contents into the program.
These were created using text editor on TSX text edit on Pdp-11 in 1982,
and then transferred using Kermit to Unix in 1989 and then ftp to RHEL in
2018.
This file compiles successfully today on Vaxcobol, Sco Unix on MF cobol
3.259 and Rhel 7.06 on MF visual cobol 5.06.
It only does not work on GNU Cobol.
On Sat, Apr 13, 2024, 2:58 AM DaveR [ mailto:
dave4583@users.sourceforge.net | dave4583@users.sourceforge.net ] wrote:
Have had a similar problem with MF COBOL on windows platform under DOS.
Would use a windows based editor save the code then compile in a DOS
window. Take a look at a copy file that is working with an editor that
will
allow HEX mode and compare to the problem file to see if anything is
lurking at the end of the file.
Found I had to hit enter a couple of times after the last character to
insert a couple of blank lines then select them with ctrl down arrow which
appeared to pick up some none displayed rubbish and then hit delete. Just
inserting a blank line or 2 without deleting will just move the problem
down.
Can't remember what the none displayed characters were now but it was a
pain. It may have been that someone else had worked on the files in a
different editor. DaveR
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2024-04-15
I am confused.
Looking at the source code for 'COMPFI.FN' I downloaded from the 'error: continuation character expected' post and I find that 'COMPFI.F' begins in the wrong column.
05 COMP-FIL-ID. COMPFI.F
10 FILLER PIC X(4) VALUE "MST/". COMPFI.F
05 FILLER PIC 999 VALUE 052. COMPFI.F
05 XXVDCK-FIL-NAME PIC X(14) VALUE "APF/*
I can only assume the reason other compilers did not flag this as an error, is that the there is no continuation character ('-') in column 7.
If this is the case then maybe GC should add similar code, with appropriate warnings.
This is the reason I avoid fixed form COBOL code like the plague.
FYI, IBM mandated fixed form so it could be compatible with PUNCH cards, An idiocy it continues to this day.
I never even seen an actual PUNCH card machine.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This allow lines up to 250 chars so negating the problem.
I did a migration of a OE application written in the early 80's over the
last few months and that fixed many issues although finding and tracing
bugs took up most of the time. It did not help that there were three
programs missing that had to be written from scratch that processed
customer maintenance and two others for interaction with A/R.
The idea was to consider including OE into my ACAS (Accounting System)
but the only new functionality it has is support for back ordering and I
have now added it into ACAS so the only other extra was support for
salesman and their commissions but as there is no payroll it would be
pointless to support this.
The use of source variable has saved over 12 hours of recoding to deal
with the possible issues so a bonus.
Should point out that this original system discussed has been migrated
from a lot of differing hardware systems and it is more than possible
that there is some bad hidden chars within the sources although it seems
be be very minor if at all and more likely the way a compiler operated
by being more loose with the Cobol standards of allowing text to go
beyond cc72.
That all said with out the full source code for the program under
discussion it had to be exact with the cause.
V.
On 15/04/2024 14:40, noreply@sourceforge.net wrote:
I am confused.
Looking at the source code for 'COMPFI.FN' I downloaded from the
'error: continuation character expected' post and I find that
'COMPFI.F' begins in the wrong column.
|05 COMP-FIL-ID. COMPFI.F 10 FILLER PIC X(4) VALUE "MST/". COMPFI.F 05
FILLER PIC 999 VALUE 052. COMPFI.F 05 XXVDCK-FIL-NAME PIC X(14) VALUE
"APF/* |
I can only assume the reason other compilers did not flag this as an
error, is that the there is no continuation character ('-') in column 7.
If this is the case then maybe GC should add similar code, with
appropriate warnings.
This is the reason I avoid fixed form COBOL code like the plague.
FYI, IBM mandated fixed form so it could be compatible with PUNCH
cards, An idiocy it continues to this day.
I never even seen an actual PUNCH card machine.
This system has compiled and is in use on RHEL since 2018 running MF Visual
COBOL 5.06, we updated the RHEL in 2020 to 7.06 and still works, just fine.
NONE of these copy books or any other programming had to be reformatted to
be compiled on RHEL using MF Visual COBOL in 2018, other than changing one
value in about 6 programs that was a return code because we are using a
64bit COBOL processor now. Everything worked, I did not have to re-do
anything.
Again, they have been in this format since 1989 when we ported the
VAX-COBOL programs to SCO Unix v 3.22 running MF cobol v 3.0. We wrote a
preprocessor to convert the programs into the 72 column format that MF
cobol used, and they have worked since 1989 and have been sold and
distributed on many customer systems since 1989.
Again, this only fails when the COMP-FIL-ID is the 1st element under the 01
filename-table-1. ONLY TIME it fails. I can put it under the
XXVDCK-FIL-NAME definition and it compiles just fine.
Yes, I can just do that, but then, this Flaw in the GNUCOBOL compiler,
would not be fixed, and may rear its head somewhere else.
I cannot change the name of this file to something else, XXCOMP is the name
of the file where we substitute XX for the customer actual company Code.
This allow lines up to 250 chars so negating the problem.
I did a migration of a OE application written in the early 80's over the
last few months and that fixed many issues although finding and tracing
bugs took up most of the time. It did not help that there were three
programs missing that had to be written from scratch that processed
customer maintenance and two others for interaction with A/R.
The idea was to consider including OE into my ACAS (Accounting System)
but the only new functionality it has is support for back ordering and I
have now added it into ACAS so the only other extra was support for
salesman and their commissions but as there is no payroll it would be
pointless to support this.
The use of source variable has saved over 12 hours of recoding to deal
with the possible issues so a bonus.
Should point out that this original system discussed has been migrated
from a lot of differing hardware systems and it is more than possible
that there is some bad hidden chars within the sources although it seems
be be very minor if at all and more likely the way a compiler operated
by being more loose with the Cobol standards of allowing text to go
beyond cc72.
That all said with out the full source code for the program under
discussion it had to be exact with the cause.
V.
On 15/04/2024 14:40, noreply@sourceforge.net wrote:
I am confused.
Looking at the source code for 'COMPFI.FN' I downloaded from the
'error: continuation character expected' post and I find that
'COMPFI.F' begins in the wrong column.
|05 COMP-FIL-ID. COMPFI.F 10 FILLER PIC X(4) VALUE "MST/". COMPFI.F 05
FILLER PIC 999 VALUE 052. COMPFI.F 05 XXVDCK-FIL-NAME PIC X(14) VALUE
"APF/* |
I can only assume the reason other compilers did not flag this as an
error, is that the there is no continuation character ('-') in column 7.
If this is the case then maybe GC should add similar code, with
appropriate warnings.
This is the reason I avoid fixed form COBOL code like the plague.
FYI, IBM mandated fixed form so it could be compatible with PUNCH
cards, An idiocy it continues to this day.
I never even seen an actual PUNCH card machine.
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.
😕
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just an FYI, since the company is still under contract with Micro Focus, we are going to download their Visual cobol 9 Update 6 to see what they may have messed with. If we move forward with GNUCOBOL once we can get everything compiled and tested, then I want to at least have the most current version of Visual COBOL before we terminate support. From a Development point of view, it only makes sense, to have the latest version that will work with the latest versions of the OS's supported. I will keep you posted on that as well, if you would like. The difficulty I am having now, is they changed their website, and have everything buried, and logging in, and going to my profile, you would think that your products would be listed, but this is NOT the case, and no place to search once you are logged in. The absolute worst website design I have ever seen for user accounts.
Last edit: Simon Sobisch 2024-04-09
I had a free 15 minutes today in-between drafts of Corp tax returns to test
something.
Leaving everything in Test.cob tge same but 1 thing. Instead of having
Compfi.fn as a copy library, I actually removed the Copy command and pasted
it directly into the program as is.
It compiled.
When I replaced the copy library, the same error exists.
So I am pretty stumped. This same copy library works in over 600 programs
in CDMS, compiles just fine.
I have been buried with accounting things as I am our corporate controller
as well, and our outside CPA has a bunch of young clerks working with him
this year, and they are transposing numbers, and never checking anything. I
am on the 5th draft of our returns for federal, have not reviewed our NJ
for the 5th time .
These young ckerks, just punch numbers, rely 100% on the computer to do
everything and if a Calc does not give them the result, they just plug a
number instead of using their brains to figure it out.
I am hoping to be back on this next week, and will try compiling a few more
programs to see what happens.
I still have not looked into getting a RTS for Isam4 or 8 yet.
Mf cobol can do Isam8 files on Visual Cobol.
On Fri, Apr 5, 2024, 4:08 PM Simon Sobisch sf-mensch@users.sourceforge.net
wrote:
I am unsure what you are talking about. The actual contents of the 05 and
10 levels end before column 72. the COMPFI.F starts in column 73 through
80 which is allowed.
Only MF COBOL forced us to keep things as strict as not surpassing column
72.
VAX COBOL and TSX COBOL allowed us to go to column 132 or further if needed.
Even if I remove the COMPFI.F from each of the 6 lines of COMPFI.FN, it
still errors out. Nothing in this file defined past column 72, no
continuation code is needed.
I removed the comment in column 73 - 80 that were COMPFI.F and recompiled
again.
As you can plainly see in the .prn attached, it is having a problem with a
file definition structure of
01 filename-table-1.
05 COMP-FIL-ID.
It has a problem with the 05 COMP-FIL-ID because it does not have a PIC
value.
In the attached example test2-41524.prn , i changed the COPY LIB COMPFI.FN
so that the 05 level would be COMP-FIL-ID PIC X(14) VALUE "MST/??COMP ".
05 COMP-FIL-RED REDEFINES COMP-FIL-ID.
It STILL errors out at the same exact place. This has nothing to do with
how this copy library is formatted. When I put the same LIB/COMPFI.FN
after the XXVDCK-FIL-NAME
definition, not changing anything else, the program compiles just fine.
If this was a bad file, then it SHOULD fail the compilation test regardless
where this file is located in the filename-table-1 element, but it does
not, it only fails when it is the first element
defined under 01 filename-table-1.
Again, the error is NOT the column formatting of this file, but where it is
located in the 01 filename-table-1 element. There is some sort of parsing
error in gnucobol.
On Thu, Apr 11, 2024 at 7:23 PM Cathy Welsh cswelsh-cdms@users.sourceforge.net wrote:
This is taking way too long to resolve.
Please supply the sources to your sample program with all the required
copybooks for it as one archive. I would like to test this on a Linux
based system using GC v3.2 final.
Also advise exactly what the steering commands you are using to compile
the program and any changes to the default gc set ups if any.
Personally I do not do so here as only use the --std=default but this is
omitted from such steering command.
For example is just use for modules : cobc -m progname.cbl -T progname.prn
and for programs cobc -x progname.cbl -T progname.prn
The "-T progname.prn" is only during early compile so as to read all
the warning/error messages otherwise it is omitted.
During testing I do add -d -g -ftraceall -fdump=ALL as well to find any
oddities in use of LINKAGE SECTION and other runtime errors such as
having non numerics if number fields etc. I has proved handy in bug tracing.
The -fdump=all create a dump of all of the stated variables for all WS
areas including file if the program under test does a aborted dump when
running.
Vince
On 15/04/2024 15:03, Cathy Welsh wrote:
I have included everything you need in an unzipped tar ball gnutest.
The only config settings that Simon had me change was
The first and last are obviously errors (I've rechecked the MF docs, too);
this will be fixed in the next version, for now please adjust the installed
"mf-strict.conf" file (see cobc --info where COB_CONFIG_DIR is) as follows:
-assign-variable: unconformable+assign-variable: ok
COB_CONFIG_DIR : /usr/local/share/gnucobol/config
mf-strict.conf
assign-variable: ok
I have not set anything else up. No other settings have been changed, I
have not read enough of the documentation, which is mountainous, to change
anything.
I compile using the following, as instructed.
cobc -std=mf-strict --debug SRC/TEST.COB -T=file.prn
Sometime if I do not want the printout,
cobc -std=mfstrict --debug SRC/TEST.COB
Simon had me 1 time compile with the -i option and he said the reproducer.i
file compiled fine, even though it errored out on the SRC/TEST.COB compile.
But I have not tried the reproducer.i option, as not sure how to deal with
that.
to [gnucobol:discussion]
On Mon, Apr 15, 2024 at 10:42 AM Vincent (Bryan) Coen vcoen@users.sourceforge.net wrote:
Cathy there does appear to be a difference in the first field
There is a space between the period and the LineFeed.
And why would that matter only when LiB/COMPFI.FN is listed as the first
element under filename-Table-1, but does not erro out if it is the 2nd
element in the table.
If the GBUCobol compiler is going to error on a space after a period before
the lf, then this is going to be a nightmare, a I am just going to stop
wasting my time and everyone else in this group.
There is nothing in any cobol standard that I have worked on from 1984 that
states you cannot have any spaces after a period before a lf.
On Mon, Apr 15, 2024, 1:28 PM Mickey White jamesbwhite@users.sourceforge.net wrote:
Well, never mind, that extra space does not appear to make a difference...
For those of you that don't seem to believe that the COMPFI.FN copy library
is fine. I have moved it to below the XXVDCK-FIL-NAME entry in the element
01 FILENAME-TABLE-1.
In this position it compiles fine. I have attached the full listing.
Curious Huh?
On Thu, Apr 11, 2024 at 7:23 PM Cathy Welsh cswelsh-cdms@users.sourceforge.net wrote:
I added the 2 lines to the mf-strict.conf which was located in
/usr/local/share/gnucobol/config-assign-variable: unconformable+assign-variable: okI then recompiled the TEST.COB again, and still received the 3 errors when using the
cobc SRC/TEST.COB -std=mf-strictRegarding the Value of ID contained in the MSL/VALUE.ID copy library, I have been using this on MF COBOL v3.259 from 1990, and the RHEL MF VISUAL Cobol v5.07 and no errors whatsoever on compilation.
Until I can get some programs compiled without errors, and am able to see how the screens look and act, I don't really want to change
much at this point, as there is already quite a list of stuff that I will need to change, and it does involve changing all 3800 programs.
Starting another thread on a different set of questions.
Last edit: Simon Sobisch 2024-04-05
This is a misunderstanding, this was a diff, so take the two additional lines out and make the change for
assign-variablefromunconformabletookGC won't error (only raise a warning when you increase the warning level). So feel free to keep that as-is.
this shouldn't be the case. I intend to fix the
$thing and the broken$REMOVEsoon you could use a 3.3-development snapshot afterwards.Simon,
Ok, that was much better, now it just shows that one error:
LIB/COMPFI.FN:1: error: continuation character expected
Regarding the 3.3-development snapshot, that would be fine. I have only tried to compile a few programs to start. Maybe I will try a full compile and see what happens. Might not be something I want to start on a Friday, and then have my head in this all weekend, when I need to get outside. It is finally going to NOT be raining this weekend, and so need some sunshine.
If I do decide to attempt the recompile, I will let you know if I find any other beauties. HA.
Thank you.
Last edit: Simon Sobisch 2024-04-09
This is a long shot.
Sometimes unprintable characters such as <np> (null pointer) are embedded in a text file.</np>
This can cause strange errors when these text files are parsed.
You can check the contents of any file using a file viewer-editor such as Ghex.
This is not a text output but a filename definition.
Last edit: Simon Sobisch 2024-04-09
All sources, including copybooks, are a text input files, line sequential files delimited by (LF) (UNIX : line feed).
Does the last line of the copy-file ends with a line terminator?
Maybe add a empty line on the end?
I added a blank line at the end of the copy library, and it made no
difference.
Funny thing, was when I copied the contents of the LIB/COMPFI.FN directly
into the program as it existed in the LIB it compiles correctly.
I updated Simon on my test yesterday, and am very much stumped. Many of my
programs all use Copy libraries, as we support more than 1 Platform, and
more than 1 compiler.
For the files that are the same across all platforms, they are contained in
LIB, for things that are unique per platform, the MSL copy libraries are
used.
COMPFI.FN is a LIB. This little file has not changed since 1982, and was
brought over to Unix in Late 1988 for Micro Focus Cobol v 3.0 for SCO Unix
3.2.2.
Thank you, it was worth a try. I did post the full listing of the program
the other day.
On Fri, Apr 12, 2024 at 3:35 PM Michael Sommer msrobots@users.sourceforge.net wrote:
Have had a similar problem with MF COBOL on windows platform under DOS. Would use a windows based editor save the code then compile in a DOS window. Take a look at a copy file that is working with an editor that will allow HEX mode and compare to the problem file to see if anything is lurking at the end of the file.
Found I had to hit enter a couple of times after the last character to insert a couple of blank lines then select them with ctrl down arrow which appeared to pick up some none displayed rubbish and then hit delete. Just inserting a blank line or 2 without deleting will just move the problem down.
Can't remember what the none displayed characters were now but it was a pain. It may have been that someone else had worked on the files in a different editor.
DaveR
These copy files have not been touched since 1989 when they were brought
down to Sco Unix to compile on MF cobol v3.259.
I have tried yesterday, retyping in the copy library in a new file, it
still will not work as the copy file. It only works when I don't use the
copy file, but copy and paste the contents into the program.
These were created using text editor on TSX text edit on Pdp-11 in 1982,
and then transferred using Kermit to Unix in 1989 and then ftp to RHEL in
2018.
This file compiles successfully today on Vaxcobol, Sco Unix on MF cobol
3.259 and Rhel 7.06 on MF visual cobol 5.06.
It only does not work on GNU Cobol.
On Sat, Apr 13, 2024, 2:58 AM DaveR dave4583@users.sourceforge.net wrote:
Cathy
What editor are you using?
Some editors leave an end of file marker that might be incompatible with how GC does copybooks.
You might look to see in a hex editor what the final characters of the file are.
I don't know how GC handles DOS vs UNIX line endings or file endings.
I am sure it is something simple.
You have my email if you wish to send me the copy book in question and I will take a look
I currently don't have GC running. I need to get something setup soon.
At one time I did have it working on OSR6 MP4, haven't tried on Definitive 2018 or the soon to be released MP and UP's.
Paul
From: "Cathy Welsh" cswelsh-cdms@users.sourceforge.net
To: "gnucobol" help@discussion.gnucobol.p.re.sourceforge.net
Sent: Saturday, April 13, 2024 7:29:54 AM
Subject: [gnucobol:discussion] Re: error: syntax error, unexpected Identifier, expecting AUTOMATIC or EXCLUSIVE or MANUAL
These copy files have not been touched since 1989 when they were brought
down to Sco Unix to compile on MF cobol v3.259.
I have tried yesterday, retyping in the copy library in a new file, it
still will not work as the copy file. It only works when I don't use the
copy file, but copy and paste the contents into the program.
These were created using text editor on TSX text edit on Pdp-11 in 1982,
and then transferred using Kermit to Unix in 1989 and then ftp to RHEL in
2018.
This file compiles successfully today on Vaxcobol, Sco Unix on MF cobol
3.259 and Rhel 7.06 on MF visual cobol 5.06.
It only does not work on GNU Cobol.
On Sat, Apr 13, 2024, 2:58 AM DaveR [ mailto:dave4583@users.sourceforge.net | dave4583@users.sourceforge.net ] wrote:
Have had a similar problem with MF COBOL on windows platform under DOS.
Would use a windows based editor save the code then compile in a DOS
window. Take a look at a copy file that is working with an editor that will
allow HEX mode and compare to the problem file to see if anything is
lurking at the end of the file.
Found I had to hit enter a couple of times after the last character to
insert a couple of blank lines then select them with ctrl down arrow which
appeared to pick up some none displayed rubbish and then hit delete. Just
inserting a blank line or 2 without deleting will just move the problem
down.
Can't remember what the none displayed characters were now but it was a
pain. It may have been that someone else had worked on the files in a
different editor. DaveR
error: syntax error, unexpected Identifier, expecting AUTOMATIC or
EXCLUSIVE or MANUAL
[ https://sourceforge.net/p/gnucobol/discussion/help/thread/c93c90a4e7/?limit=25&page=1#b93b/843a/1cc8 | https://sourceforge.net/p/gnucobol/discussion/help/thread/c93c90a4e7/?limit=25&page=1#b93b/843a/1cc8 ]
Sent from sourceforge.net because you indicated interest in
[ https://sourceforge.net/p/gnucobol/discussion/help/ | https://sourceforge.net/p/gnucobol/discussion/help/ ]
To unsubscribe from further messages, please visit
[ https://sourceforge.net/auth/subscriptions/ | https://sourceforge.net/auth/subscriptions/ ]
[ https://sourceforge.net/p/gnucobol/discussion/help/thread/c93c90a4e7/?limit=25&page=1#b93b/843a/1cc8/42b8 | error: syntax error, unexpected Identifier, expecting AUTOMATIC or EXCLUSIVE or MANUAL ]
Sent from sourceforge.net because you indicated interest in [ https://sourceforge.net/p/gnucobol/discussion/help/ | https://sourceforge.net/p/gnucobol/discussion/help/ ]
To unsubscribe from further messages, please visit [ https://sourceforge.net/auth/subscriptions/ | https://sourceforge.net/auth/subscriptions/ ]
Hi Paul, I sent the actual copy library on this thread yesterday.
I did a hexdemp on the file which as not changed since 1989, saw no
characters other than LF 0a in the file after each line.
I deleted the file, created a new one with the data in exactly the same
position, and recompiled, same error.
When I hard code the contents of the Lib inside the program, it compiles.
I even changed the name of the file thinking that it has an issue with the
names COMP-FIL or value "COMP", changed them to CMPO and it made no
difference.
I used "vi" to put the additional blank line in the file. It was originally
edited on a PDP Rsx cobol in 1982 then transferred with Kermit to Unix in
1989. Again, doing a hexdump -C only shows the additional occurrence of 0A.
I have lots of other copy libs of filename definition, because our
software supports multi company (EIN) function, and that means the filename
contains the company code in the desired location, which a program called
"FILSET" uses, to place the PASSED Company code to the designated position
in the filename. The filler in the filename definition that shows "052"
means that in the 5th position of the filename, substitute for 2 positions
the company code or LINE Number.
I just moved the copy library of LIB/COMPFI.FN to below the definition of
the XXVDCK-FIL-NAME in the 01 filename-table-01 element, and it compiled,
but it will not compile if it is the first element listed in the 01 level
FILENAME-TABLE-1.
This absolutely makes no sense to me. I have also tried changing the
COMPFI.FN so that the first 05 level is COMP-FIL-ID PIC X(14) VALUE
"MST/??COMP ". Then add a REdefine 05 level below that, and it made no
difference.
If this file is the 1st 05 level in the filename-table-1 it will not
compile.
I would have to go into 860 approx programs and re-arrange the
Filename-tables so that if COMPFI.FN is there, to move it out of the first
position. This has only been 1 program that I tried to compile with
gnucobol and am wondering how many others I am going to have different
problems. I am limiting the numbers I am compiling as every single CDMS
programs has the MF COBOL compile directives, and have to remove them in
order to even attempt to get any program even close to compiling.
If you think of anything else to try, please let me know. It is VERY
bizarre that the same identical COPY LIB compiles fine in the program as
long as it is NOT the first 05 level in the filename-table.
I have attached 2 complete Listings of the program. The testorig041324.prn
is when the LIB/COMPFI.FN is the 1st 05 level entry under 01
FILE-NAME-TABLE-1. This one does not compile.
the 2nd file test041324.prn is when I moved the LIB/COMPFI.FN 2nd in the
filename-table-1 under the XXVDCK-FIL-NAME entry. This program compiles
successfully.
On Sat, Apr 13, 2024, 2:08 PM Paul McNary pmcnary@users.sourceforge.net
wrote:
I am confused.
Looking at the source code for 'COMPFI.FN' I downloaded from the 'error: continuation character expected' post and I find that 'COMPFI.F' begins in the wrong column.
I can only assume the reason other compilers did not flag this as an error, is that the there is no continuation character ('-') in column 7.
If this is the case then maybe GC should add similar code, with appropriate warnings.
This is the reason I avoid fixed form COBOL code like the plague.
FYI, IBM mandated fixed form so it could be compatible with PUNCH cards, An idiocy it continues to this day.
I never even seen an actual PUNCH card machine.
GC has the benefit of >>source variable
This allow lines up to 250 chars so negating the problem.
I did a migration of a OE application written in the early 80's over the
last few months and that fixed many issues although finding and tracing
bugs took up most of the time. It did not help that there were three
programs missing that had to be written from scratch that processed
customer maintenance and two others for interaction with A/R.
The idea was to consider including OE into my ACAS (Accounting System)
but the only new functionality it has is support for back ordering and I
have now added it into ACAS so the only other extra was support for
salesman and their commissions but as there is no payroll it would be
pointless to support this.
The use of source variable has saved over 12 hours of recoding to deal
with the possible issues so a bonus.
Should point out that this original system discussed has been migrated
from a lot of differing hardware systems and it is more than possible
that there is some bad hidden chars within the sources although it seems
be be very minor if at all and more likely the way a compiler operated
by being more loose with the Cobol standards of allowing text to go
beyond cc72.
That all said with out the full source code for the program under
discussion it had to be exact with the cause.
V.
On 15/04/2024 14:40, noreply@sourceforge.net wrote:
This system has compiled and is in use on RHEL since 2018 running MF Visual
COBOL 5.06, we updated the RHEL in 2020 to 7.06 and still works, just fine.
NONE of these copy books or any other programming had to be reformatted to
be compiled on RHEL using MF Visual COBOL in 2018, other than changing one
value in about 6 programs that was a return code because we are using a
64bit COBOL processor now. Everything worked, I did not have to re-do
anything.
Again, they have been in this format since 1989 when we ported the
VAX-COBOL programs to SCO Unix v 3.22 running MF cobol v 3.0. We wrote a
preprocessor to convert the programs into the 72 column format that MF
cobol used, and they have worked since 1989 and have been sold and
distributed on many customer systems since 1989.
Again, this only fails when the COMP-FIL-ID is the 1st element under the 01
filename-table-1. ONLY TIME it fails. I can put it under the
XXVDCK-FIL-NAME definition and it compiles just fine.
Yes, I can just do that, but then, this Flaw in the GNUCOBOL compiler,
would not be fixed, and may rear its head somewhere else.
I cannot change the name of this file to something else, XXCOMP is the name
of the file where we substitute XX for the customer actual company Code.
On Mon, Apr 15, 2024 at 9:54 AM Vincent (Bryan) Coen vcoen@users.sourceforge.net wrote:
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.