I regularly use the internal xref program in my other programs to get access to datanames etc:
I recently started using a particular copy module of mine with a replacing leading to get another
copy but with different internal names.
When looking at the xref file produced I noticed that although 'all' the fields in the original copy
module were referenced as 'external' - the xref file only showed some of them as such - and it
didn't appear to me to have any particular rhythm - some were identified - some not.
Also - since i'd also done the copy replacing - the duplicated copy module had all the correct
changed internal names - but 'NONE' of the items were designated as 'external'.
see extract from xref attached.
I tried creating a sample program using that same copy module but it refused to produce any
reference to an 'external' data item - even though they all were such.
I then thought it was to do with the fields being referenced in the actual program - but they are
'all' referenced at some time or other.
Just strange
The bug in the symbol listing you've shown is that the EXTERNAL(and BASED and GLOBAL?) attribute(s) should only be printed on the level 01/77 level. I guess this also happens in other places - a reproducible example where those are wrong would help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As I said above:
I tried creating a sample program using that same copy module but it refused to produce any reference to an 'external' data item - even though they all were such.
I then thought it was to do with the fields being referenced in the actual program - but they are 'all' referenced at some time or other.
Just strange
I'll keep playing & see if I can get it to reproduce 'other' than with my somewhat large program.
❤️
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@sf-mensch - attached source code & xref listing together with MIN (minimal display).
Sorry - it's hardly a small program but it's reproducible - I think it's overflowing something since I tried with another large program that produced similar results but as I reduced the PD code the problem disappeared ????. Please ignore the code - it was a program I wrote for my wife to store her crossstitch collection - some years ago. (my coding still has not improved.)
Found the place where the external attribute is set likely wrongly (as a shortcut for later places), it is set in codegen.c (output_param), so only if used in an internal or direct CALL.
So it even differs if you have -fsyntax-only (level 01/77 external) or full codegen...
For the listing to be correct it is enough (and reasonable in any case) to have cobc.c (print_fields) to wrap the code doing the output EXTERNAL/GLOBAL/BASED in if (top->level == 1 || top->level == 77) {, same for codegen.c(output_field_display), there also for ANYLENGTH.
The possibly removement of the internal assignment in (output_param) needs more checks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have tried cobxref but I don't think it gives quite the same output as the internal & I've become accustomed to coding for the internal.
I 'will' give it a try & let you know the results - back shortly.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well - that didn't get very far: Compiled the cobxref & moved it into the cobol\bin folder
then ran a batch file to set the parameters for cobc etc - see below : result was:
libcob: cobxref.cob:3966: error: offset of 'SourceFileName' out of bounds: 128, maximum: 64
Last statement of "cobxref" was at line 3966 of cobxref.cob
Started by cobxref
DEMOMATH.cob
Press any key to continue . . .
I downloaded your Cobol src file and then just ran :
[vince@applewood tmp]$ cobxref DEMOMATH.COB
Msg13 Intrinsic word table was successfully updated
Msg14 Reserve word table was successfully updated
Msg16 System word table was successfully updated
The o/p as a .lst file is attached.
The program completed correctly, suggest you retry but omit the unneeded set statements in your batch file which might be getting in the way and no, no idea :)
Other wise the only oddity is that 'console' is not defined as shown in the listing.
Am I getting confused, I thought you had used GLOBAL, EXTERNAL on some data fields but non are shown of source.
You're right - the demomath program ran fine after I changed the 128 to 64 - I reran it 'using my batch file' and it ran fine.
The batch file sets the parameters for running cobol exe from a dos prompt in my system - it works for my programs.
Your program did run but crashed - (when trying on the two larger programs) - that's different from saying it couldn't find a .dll which is what happens if I run it at a dos prompt without the batch file.
I agree that the demomath didn't have any external used - I was only testing to see if it ran.
When I tried it with a larger program that had an external it crashed - with or without the external.
try it against the attached - see if it works - not my program though. you'll have to unpack it & there are a few other files as well as the source and copy modules.
All I tried was to add external to the first 01 level item - but it crashed anyway.
I realise it's a bit moot anyway since I need the para names as well but you asked if I'd tried it.
Edited the 128 to 64 & recompiled & reran & appeared to work.
Reran with a larger program & got the following:
libcob: cobxref.cob:5993: error: subscript of 'CRT-Instance' out of bounds: 2
note: current maximum subscript for 'CRT-Instance': 1
libcob: cobxref.cob:5993: warning: implicit CLOSE of Print-File ('COBOLPR1.pro')
Last statement of "printcbl" was at line 5993 of cobxref.cob
Last statement of "cobxref" was at line 4131 of cobxref.cob
Started by cobxref
COBOLPR1.cob
-FREE
Press any key to continue . . .
It produced a .pro file that only got as far as the end of the first copy module ??????????
Also - the listing doesn't do anything with the procedure names - which is vital for my use.
Last edit: David Wall 2021-12-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Tried it with a fixed format file - somewhat similar results. - in fact identical. ???
libcob: cobxref.cob:5993: error: subscript of 'CRT-Instance' out of bounds: 2
note: current maximum subscript for 'CRT-Instance': 1
libcob: cobxref.cob:5993: warning: implicit CLOSE of Print-File ('COBOLSEQ.pro')
Last statement of "printcbl" was at line 5993 of cobxref.cob
Last statement of "cobxref" was at line 4131 of cobxref.cob
Started by cobxref
COBOLSEQ.cob
Press any key to continue . . .
Again crashed at end of first copy module - ah well..
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
From the earlier post with the source file and a batch file which is FIXED format.
So do not have the sources you used and therefore cannot test it here.
Vince
Last edit: Simon Sobisch 2021-12-15
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unwanted EXTERNAL attribute in cobc fixed with [r4490].
For COPY REPLACING there is another change (sub-words) which I need to finish (adjust the testsuite expectations), may do that tonight or over the week.
@sf-mensch - apologies - for some reason I never received this as an email so missed it.
Yes - the latest version of 3.2 fixes up the odd extra External references. Thank you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I retried it - with and without a copy module statement.
Crashed with the statement & went thru albeit with some displays when I removed the copy statement.
If you're wondering what copy statement could possibly crash it - screenio.cpy - default with GnuCOBOL 3.2.
With the copy statement it crashes.
E:\COB32\bin>cobxref cobolpr1.cob
libcob: cobxref.cob:5993: error: subscript of 'CRT-Instance' out of bounds: 2
note: current maximum subscript for 'CRT-Instance': 1
libcob: cobxref.cob:5993: warning: implicit CLOSE of Print-File ('cobolpr1.pro')
Last statement of "printcbl" was at line 5993 of cobxref.cob
Last statement of "cobxref" was at line 4131 of cobxref.cob
Started by cobxref
cobolpr1.cob
Without the copy statement it runs thru - obviously program doesn't compile.
E:\COB32\bin>cobxref cobolpr1.cob
configuration error:
/mingw/share/gnucobol/config\default.conf: No such file or directory
configuration error:
/mingw/share/gnucobol/config\default.conf: No such file or directory
configuration error:
/mingw/share/gnucobol/config\default.conf: No such file or directory
E:\COB32\bin>
I've also attached the .pro file showing it only gets as far as the end of the copy statement - so it's nothing to do with whatever is in the actual program causing it.
By the way - I've also attached some of the .lst file from when it worked .
It 'doesn't' print the program name after the first line - prom then on it shows 'PROGRAM' which although it's correct - probably should be the actual name of the program.
The .lst file prints some strange names as not being referenced in the program - such as command-line, division, end-perform, giving, stop, thru, varying.
These aren't datanames anyway so why are they referenced at all ??.
Similarly things like access, dynamic , indexed aren't WS symbols - they're in the IO section.
see the x file attached.
By the way Vincent - is it your program that does the extra line skip on the .pro file - I'm getting a 0D0D0A on the end of each line of that but not on the .lst file.
Strange because they're all described as line sequential.
Maybe another bug in 3.2 ??. - I'll try again with the latest (this one was Dec 03 2021.)
Ok - tried with the absolute latest 3.2 - just built from Simons update - above.
E:\COBV32\bin>cobxref cobolpr1.cob
libcob: cobxref.cob:3966: error: offset of 'SourceFileName' out of bounds: 128, maximum: 64
Last statement of "cobxref" was at line 3966 of cobxref.cob
Started by cobxref
cobolpr1.cob
Edited to change the 128 to 64 recompiled & reran.
E:\COBV32\bin>
E:\COBV32\bin>cobxref cobolpr1.cob
libcob: cobxref.cob:5993: error: subscript of 'CRT-Instance' out of bounds: 2
note: current maximum subscript for 'CRT-Instance': 1
libcob: cobxref.cob:5993: warning: implicit CLOSE of Print-File ('cobolpr1.pro')
Last statement of "printcbl" was at line 5993 of cobxref.cob
Last statement of "cobxref" was at line 4131 of cobxref.cob
Started by cobxref
cobolpr1.cob
Crashed with the .pro file double spaced ending at the last line of the copy module.
commented out the copy module & reran.
E:\COBV32\bin>
E:\COBV32\bin>cobxref cobolpr1.cob
Msg13 Intrinsic word table was successfully updated
Msg14 Reserve word table was successfully updated
Msg16 System word table was successfully updated
Seems to have worked although the double spacing of the .pro file still exists.
>>SOURCE FREE
IDENTIFICATION DIVISION.
PROGRAM-ID. PROGRAM.
And so it goes on. ??.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Found the 128 value against a field size of 64. Never came up before in mine and everyone else testing
Did you have -g (runtime debug and stack checks) set when compiling ?
Fixed now for v2.02.04 and I will update the sources later tonight.
Now regarding the CRLF (carriage return, line feed) etc yes this is an issue with the compiler not changing the value used at the end of a line for a LS file depending on if its under Windows..
So the end result unless the file gets cleaned up when transferring to Windows produces a blank line between printed lines.
I cannot solve this within the program as the end of chars is not controlled by the Cobol code but a library routine somewhere.
I have not seen it with v3.1.2 but there again I do not compile under Windows despite having installed a a year to so ago - I do not like using a Linux environment within Windows to get around a supposed problem that should be fixed using a native Windows compile i.e., Visual Studio and no I have not even tried that as my one and only attempt resulted in issue with libraries and SDK's some where.
Now to look for the CRT-Instance issue.
Which if found and fixed will be added to the v2.03.04 version of cobxref.
More may be later,
Vince
Last edit: Simon Sobisch 2021-12-15
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I must admit having to compare files produced under MIngw with those under Windows caused me some hassle till I started running a sfk (swiss file knife) against them to completely remove all 0D & 0A from both files - leaves a single long record occasionally but can actually be compared & match.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
He might well have done but I am still on 3.1.2 and I am guessing it is in fileio.c somewhere.
I have put tests in the cobxref code to check for X'0d or X'0A and replace with a space so will have to see if that works when I upload it for you to grab.
Vince
Last edit: Simon Sobisch 2021-12-15
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I regularly use the internal xref program in my other programs to get access to datanames etc:
I recently started using a particular copy module of mine with a replacing leading to get another
copy but with different internal names.
When looking at the xref file produced I noticed that although 'all' the fields in the original copy
module were referenced as 'external' - the xref file only showed some of them as such - and it
didn't appear to me to have any particular rhythm - some were identified - some not.
Also - since i'd also done the copy replacing - the duplicated copy module had all the correct
changed internal names - but 'NONE' of the items were designated as 'external'.
see extract from xref attached.
I tried creating a sample program using that same copy module but it refused to produce any
reference to an 'external' data item - even though they all were such.
I then thought it was to do with the fields being referenced in the actual program - but they are
'all' referenced at some time or other.
Just strange
Out of interest, does it work using cobxref ?
Vince
Last edit: Simon Sobisch 2021-12-14
The bug in the symbol listing you've shown is that the
EXTERNAL(andBASEDandGLOBAL?) attribute(s) should only be printed on the level 01/77 level. I guess this also happens in other places - a reproducible example where those are wrong would help.As I said above:
I tried creating a sample program using that same copy module but it refused to produce any reference to an 'external' data item - even though they all were such.
I then thought it was to do with the fields being referenced in the actual program - but they are 'all' referenced at some time or other.
Just strange
I'll keep playing & see if I can get it to reproduce 'other' than with my somewhat large program.
@sf-mensch - attached source code & xref listing together with MIN (minimal display).
Sorry - it's hardly a small program but it's reproducible - I think it's overflowing something since I tried with another large program that produced similar results but as I reduced the PD code the problem disappeared ????. Please ignore the code - it was a program I wrote for my wife to store her crossstitch collection - some years ago. (my coding still has not improved.)
Thank you I'll have a look at this now.
Found the place where the external attribute is set likely wrongly (as a shortcut for later places), it is set in codegen.c (output_param), so only if used in an internal or direct CALL.
So it even differs if you have
-fsyntax-only(level 01/77 external) or full codegen...For the listing to be correct it is enough (and reasonable in any case) to have cobc.c (print_fields) to wrap the code doing the output EXTERNAL/GLOBAL/BASED in
if (top->level == 1 || top->level == 77) {, same for codegen.c(output_field_display), there also forANYLENGTH.The possibly removement of the internal assignment in (output_param) needs more checks.
Simon - I love it when you talk dirty to me - even if it's about 1km above my head :)
I have tried cobxref but I don't think it gives quite the same output as the internal & I've become accustomed to coding for the internal.
I 'will' give it a try & let you know the results - back shortly.
Well - that didn't get very far: Compiled the cobxref & moved it into the cobol\bin folder
then ran a batch file to set the parameters for cobc etc - see below : result was:
libcob: cobxref.cob:3966: error: offset of 'SourceFileName' out of bounds: 128, maximum: 64
Last statement of "cobxref" was at line 3966 of cobxref.cob
Started by cobxref
DEMOMATH.cob
Press any key to continue . . .
I downloaded your Cobol src file and then just ran :
[vince@applewood tmp]$ cobxref DEMOMATH.COB
Msg13 Intrinsic word table was successfully updated
Msg14 Reserve word table was successfully updated
Msg16 System word table was successfully updated
The o/p as a .lst file is attached.
The program completed correctly, suggest you retry but omit the unneeded set statements in your batch file which might be getting in the way and no, no idea :)
Other wise the only oddity is that 'console' is not defined as shown in the listing.
Am I getting confused, I thought you had used GLOBAL, EXTERNAL on some data fields but non are shown of source.
Vince
Last edit: Simon Sobisch 2021-12-15
You're right - the demomath program ran fine after I changed the 128 to 64 - I reran it 'using my batch file' and it ran fine.
The batch file sets the parameters for running cobol exe from a dos prompt in my system - it works for my programs.
Your program did run but crashed - (when trying on the two larger programs) - that's different from saying it couldn't find a .dll which is what happens if I run it at a dos prompt without the batch file.
I agree that the demomath didn't have any external used - I was only testing to see if it ran.
When I tried it with a larger program that had an external it crashed - with or without the external.
try it against the attached - see if it works - not my program though. you'll have to unpack it & there are a few other files as well as the source and copy modules.
All I tried was to add external to the first 01 level item - but it crashed anyway.
I realise it's a bit moot anyway since I need the para names as well but you asked if I'd tried it.
What '128' did you change to '64' ?
The only primary thing I can find is a table that is used in various places.
I will try this program (COBOLSEQ.7Z) source next as soon as I work out how to read this archive.
Vince
Last edit: Simon Sobisch 2021-12-15
Edited the 128 to 64 & recompiled & reran & appeared to work.
Reran with a larger program & got the following:
libcob: cobxref.cob:5993: error: subscript of 'CRT-Instance' out of bounds: 2
note: current maximum subscript for 'CRT-Instance': 1
libcob: cobxref.cob:5993: warning: implicit CLOSE of Print-File ('COBOLPR1.pro')
Last statement of "printcbl" was at line 5993 of cobxref.cob
Last statement of "cobxref" was at line 4131 of cobxref.cob
Started by cobxref
COBOLPR1.cob
-FREE
Press any key to continue . . .
It produced a .pro file that only got as far as the end of the first copy module ??????????
Also - the listing doesn't do anything with the procedure names - which is vital for my use.
Last edit: David Wall 2021-12-14
Tried it with a fixed format file - somewhat similar results. - in fact identical. ???
libcob: cobxref.cob:5993: error: subscript of 'CRT-Instance' out of bounds: 2
note: current maximum subscript for 'CRT-Instance': 1
libcob: cobxref.cob:5993: warning: implicit CLOSE of Print-File ('COBOLSEQ.pro')
Last statement of "printcbl" was at line 5993 of cobxref.cob
Last statement of "cobxref" was at line 4131 of cobxref.cob
Started by cobxref
COBOLSEQ.cob
Press any key to continue . . .
Again crashed at end of first copy module - ah well..
From the earlier post with the source file and a batch file which is FIXED format.
So do not have the sources you used and therefore cannot test it here.
Vince
Last edit: Simon Sobisch 2021-12-15
Unwanted EXTERNAL attribute in cobc fixed with [r4490].
For
COPY REPLACINGthere is another change (sub-words) which I need to finish (adjust the testsuite expectations), may do that tonight or over the week.Related
Commit: [r4490]
@sf-mensch - apologies - for some reason I never received this as an email so missed it.
Yes - the latest version of 3.2 fixes up the odd extra External references. Thank you.
I retried it - with and without a copy module statement.
Crashed with the statement & went thru albeit with some displays when I removed the copy statement.
If you're wondering what copy statement could possibly crash it - screenio.cpy - default with GnuCOBOL 3.2.
With the copy statement it crashes.
E:\COB32\bin>cobxref cobolpr1.cob
libcob: cobxref.cob:5993: error: subscript of 'CRT-Instance' out of bounds: 2
note: current maximum subscript for 'CRT-Instance': 1
libcob: cobxref.cob:5993: warning: implicit CLOSE of Print-File ('cobolpr1.pro')
Last statement of "printcbl" was at line 5993 of cobxref.cob
Last statement of "cobxref" was at line 4131 of cobxref.cob
Started by cobxref
cobolpr1.cob
Without the copy statement it runs thru - obviously program doesn't compile.
E:\COB32\bin>cobxref cobolpr1.cob
configuration error:
/mingw/share/gnucobol/config\default.conf: No such file or directory
configuration error:
/mingw/share/gnucobol/config\default.conf: No such file or directory
configuration error:
/mingw/share/gnucobol/config\default.conf: No such file or directory
E:\COB32\bin>
I've also attached the .pro file showing it only gets as far as the end of the copy statement - so it's nothing to do with whatever is in the actual program causing it.
By the way - I've also attached some of the .lst file from when it worked .
It 'doesn't' print the program name after the first line - prom then on it shows 'PROGRAM' which although it's correct - probably should be the actual name of the program.
The .lst file prints some strange names as not being referenced in the program - such as command-line, division, end-perform, giving, stop, thru, varying.
These aren't datanames anyway so why are they referenced at all ??.
Similarly things like access, dynamic , indexed aren't WS symbols - they're in the IO section.
see the x file attached.
By the way Vincent - is it your program that does the extra line skip on the .pro file - I'm getting a 0D0D0A on the end of each line of that but not on the .lst file.
Strange because they're all described as line sequential.
Maybe another bug in 3.2 ??. - I'll try again with the latest (this one was Dec 03 2021.)
Ok - tried with the absolute latest 3.2 - just built from Simons update - above.
E:\COBV32\bin>cobxref cobolpr1.cob
libcob: cobxref.cob:3966: error: offset of 'SourceFileName' out of bounds: 128, maximum: 64
Last statement of "cobxref" was at line 3966 of cobxref.cob
Started by cobxref
cobolpr1.cob
Edited to change the 128 to 64 recompiled & reran.
E:\COBV32\bin>
E:\COBV32\bin>cobxref cobolpr1.cob
libcob: cobxref.cob:5993: error: subscript of 'CRT-Instance' out of bounds: 2
note: current maximum subscript for 'CRT-Instance': 1
libcob: cobxref.cob:5993: warning: implicit CLOSE of Print-File ('cobolpr1.pro')
Last statement of "printcbl" was at line 5993 of cobxref.cob
Last statement of "cobxref" was at line 4131 of cobxref.cob
Started by cobxref
cobolpr1.cob
Crashed with the .pro file double spaced ending at the last line of the copy module.
commented out the copy module & reran.
E:\COBV32\bin>
E:\COBV32\bin>cobxref cobolpr1.cob
Msg13 Intrinsic word table was successfully updated
Msg14 Reserve word table was successfully updated
Msg16 System word table was successfully updated
Seems to have worked although the double spacing of the .pro file still exists.
>>SOURCE FREE
IDENTIFICATION DIVISION.
PROGRAM-ID. PROGRAM.
And so it goes on. ??.
Hi David;
Found the 128 value against a field size of 64. Never came up before in mine and everyone else testing
Did you have -g (runtime debug and stack checks) set when compiling ?
Fixed now for v2.02.04 and I will update the sources later tonight.
Now regarding the CRLF (carriage return, line feed) etc yes this is an issue with the compiler not changing the value used at the end of a line for a LS file depending on if its under Windows..
So the end result unless the file gets cleaned up when transferring to Windows produces a blank line between printed lines.
I cannot solve this within the program as the end of chars is not controlled by the Cobol code but a library routine somewhere.
I have not seen it with v3.1.2 but there again I do not compile under Windows despite having installed a a year to so ago - I do not like using a Linux environment within Windows to get around a supposed problem that should be fixed using a native Windows compile i.e., Visual Studio and no I have not even tried that as my one and only attempt resulted in issue with libraries and SDK's some where.
Now to look for the CRT-Instance issue.
Which if found and fixed will be added to the v2.03.04 version of cobxref.
More may be later,
Vince
Last edit: Simon Sobisch 2021-12-15
Hi;
Found a few instances where only testing for X"0D" now added X"0A" but this needs testing to confirm no adverse effects.
will be available as v2.03.04
Please retest all those sources against this new release , will add it to Contribs and cobxref own SF areas later tonight (based on GMT+0).
Vince
Last edit: Simon Sobisch 2021-12-15
Vincent - I thought this extra 0D only occurred in 3.2 or 4.x ?? & was fixed recently by Ron N.
see:
https://sourceforge.net/p/gnucobol/discussion/cobol/thread/584b210bde/?limit=25&page=2#a06f
I must admit having to compare files produced under MIngw with those under Windows caused me some hassle till I started running a sfk (swiss file knife) against them to completely remove all 0D & 0A from both files - leaves a single long record occasionally but can actually be compared & match.
He might well have done but I am still on 3.1.2 and I am guessing it is in fileio.c somewhere.
I have put tests in the cobxref code to check for X'0d or X'0A and replace with a space so will have to see if that works when I upload it for you to grab.
Vince
Last edit: Simon Sobisch 2021-12-15
I don't believe they backported the changes Ron N was working on.
In fact it may only have been to 4.x - refer:
https://sourceforge.net/p/gnucobol/discussion/cobol/thread/584b210bde/?page=1&limit=25#8044
Not sure now..