Currently working on a update to provide support for copy library inclusion via the COPY verb.
Taken a lot longer than expected and still a mess but now considering using a modified version of printcbl that is included with the source to preprocess a user supplied Cobol source file creating a temporary source file which is input to cobxref for processing.
This provides up to nine levels of COPY processing that is a copy calling a copy calling a copy etc and this includes the original source file. This limit of nine is higher than the compiler - in fact most if not all that is out there.
Might save me a lot of time and headaches.
Must remember to take a look at the cobc sources to see if is in one place and see if that can be used.
Very wishfull dreaming :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Progress -
Tested with basic COPY verbs (no replacing) for free format all ok.
Tested with copy replacing using var by var for free format all ok.
Thats the good news as copy replacing using the ==abcd== by ==efg== is broken.
Once solved then testing again but using fixed format.
During testing found bugs in Printcbl in various areas and these have been fixed as for cobxref but again the repacing ==abcd== etc is broken and not tested yet fixed format.
Yes that means I an testing both cobxref and printcbl as all bugs now found relate to the copy verb processing.
That is 'assuming' testing for FIXED format does not produce any more.
Famous last words.
.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is an independent program - it is not callable from the compiler - all such code is being removed.
It is run using standard commands such as:
cobxref sfn.cbl sfn.lst -FREE | -free | -FIXED | - fixed
It will create additional files -
sfn.lst - source listing plus xref reports.
sfn.pco - contains all expanded copy books) - Can be deleted after EOJ.
Part1.tmp created in your ./tmp directory - These are used for sort processing .
Part2.tmp and may be deleted after EOJ.
For source containing nested programs / modules on EOJ the PARTn.tmp files only hold data for the last module processed.
It starts byrunning the printcbl inbedded module which reads cobol source file (sfn.cbl) creating first an updated source file sfn .pco this is then read by cobxref to create the listings followed by all of the xref output.
The extra functions have been added to the xref output - Functions (minor update) and user and system functions/ Calls along with increased table holding ALL forms of current compiler reserved words.
Yes, I have omitted some steps here.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The new version of cobxref has been release and uploaded to sourceforge as v2.01.01.
This supports fixed and free format and COPY verb down nine levels with all reportedand found bugs fixed .
As it uses a version of printcbl to do the processing of the COPY CDF facility that too has been updated along with various bug fixes so that the two are inline with each other as much as possible.
It has been tested against some 1,000 productions programs including some that are over 40,000 lines long as well as various test sources.
There has not been any changes to the MVS version as that ony uses fixed format sources.
Last edit: Vincent (Bryan) Coen 2019-03-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A new version has been released as v2.02..01 this covers:
Bug fix for report page numbering with odd values after the count reaches 127 - due to a data field as binary-char, changed to binary-long. This will cover large program listings along with one containing nested programs.
Support for user words of up to a length of 63 characters where used for data, section, paragraph, program and module / function names.
This has only been tested against cobxref itself which does not have words beyond current standards. The current code base for GnuCobol dated on or after 11th May 2019 supports this facilty.
Cobxref processes long data, section and paragraph names by printing it on a line by it self before printing the definitions and references etc.
Minor support for same with program or module names in heading but there is a total limit of 64 chars for both, where nested sources are in use and included in char count is extra 2 chars for '(' & ')' literals used i.e., cobxref (printcbl) so could be cut off if size is exceeded as print line takes in to account users with ink jet / Laser printer and not Matrix / line printers with 160 column paper.
If you can please test this new function (along with latest GnuCobol code base and report any issues.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Update v2.02.03 fixes a small but significant error when source program has >>SOURCE statement in the wrong column such as cc9 and is ignored when cobxref is run without -free parameter. This error caused a msg2 error as cobxref was trying to use FIXED format to read a free format source.
SVN and archive has been uploaded.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Bug found by David Wall in zz180-Check-For-Param-Errors where a perform search was using 128 for a field that is only 64 characters and that produced a runtime out of bounds error.
At some point I changed the size but did not find in all other testing, but it may be, he had -g (runtime checks) set for during the compile.
Thanks, David.
In bc000-Test-For-Missing-Replace and when running with -g, produces a runtime failure so now checking if not > 1 in bc000-Test-For-Missing-Replace. {Incident waiting to happen]
Added test for X"0A" along with the test for X"0D" in case running under Windows - needs testing though as I do not do so.
Added 'continue in empty perform - end-perform blocks if nothing else will get rid of the silly warning regarding 'warning: inline PERFORM without imperative statement used'.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
All known bugs cleared, including duplicate reference numbers, for same variable.
Included support for CDF statements :
DEFINE CONSTANT
SET CONSTANT
Increased the number of referenced occurrences per report line from 8 to 12 and added a total reference count per variable to make it easier for testing against other cross reference programs including the internal one.
Included feature to produce both block xref lists at end of program and the normal one by group, section etc, more to aid testing but programmers might find it useful.
Some other very minor changes I have forgotten about :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When using the CDF statements >>DEFINE and >>SET with CONSTANT cobxref transfers these to the GIT (Global/External) table as soon as it finds them - so far so good. It then uses them by adding them into the sort input file, runs sort then produces the source and xref listings etc
I have now found out that both of these CDF statements are only in scope up to the point of an
END PROGRAM progname statement when they are terminated.
cobxref does no such thing, it retains them until the end, so if you have nested programs in your source where such CDF elements are used they will appear in the xref's throughout all nested programs.
As this will involve some time for coding around it, it has been put on the back burner as a very low priority item.
There again it depends on how many programmers use nested programs and CDF commands >>DEFINE and/or >>SET
If it does, get in touch and tell me what you are using cobxref for.
Needless to say at time of writing the gc internal xref does not handle CDF at all.
Last edit: Vincent (Bryan) Coen 2022-03-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Referring to post 2022-03-27 version is updated to v2.03.05 where some code was added to support tidying up the issue with CDF >>DEFINE and >>SET for the git table but as no one has commented or complained about this functionality it has not been progress further.
I.e, any CDF >>DEFINE etc set at the top of a nest program group will remain in effect for all nested programs.
As very few programmers make use of the nested program feature this issue is not likely to come up, although I do make use of it in some of my Cobol tools, i.e., cobxref :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am pleased to announce V2.03.05 has been released today directly here and in GC contribs.
This version will now remove the CDF >>DEFINE | SET vars from the Global table when reading an END PROGRAM statement. A extra error message has been added if the Global count after remove said CDF words means that the count is negative and no it should not happen:
Also cleaned up msg3 - 6 by putting them in correct logical order - the manual has been so updated.
svn has been updated with the files changed and a new archive cobxref-2.03.05.zip added to the files section.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Version 2.03.12 -> v2.04, hopefully will be released in a few weeks / month, once some bugs have been traced and fixed.
This introduces facilities for nested programs to have GLOBAL, EXTERNAL and CDF DEFINEs etc showing up in the right places in the xref listings.
Note that an END PROGRAM | FUNCTION terminates any CDF DEFINEs (>>DEFINE or $SET DEFINE for that program as the compiler should be doing at least according to @Simon.
Of course, this does NOT apply to the use of GLOBAL or EXTERNAL for files and any variables so set up.
Also see tracker reference #2 for possible more info.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Update v2.03.15 has been uploaded to the file area.
This fixes bugs where cobxref processes verb CALL where there is a reserved word pre routine name such as STATIC or STDCALL where these reserved words would be used instead of the routine.
I have tried to update the SVN system but keep getting a message that the first file being commited is out of date and it is not. I cannot see a way of fixing this issue.
That said the current version is present in the GnuCobol contrib area - that works.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello to the general discussion area.
Covers just about anything including any issues found for all versions/platforms.
Hello to you too! Will be participating here as I start to get back into COBOL again. And once and phor all.
Currently working on a update to provide support for copy library inclusion via the COPY verb.
Taken a lot longer than expected and still a mess but now considering using a modified version of printcbl that is included with the source to preprocess a user supplied Cobol source file creating a temporary source file which is input to cobxref for processing.
This provides up to nine levels of COPY processing that is a copy calling a copy calling a copy etc and this includes the original source file. This limit of nine is higher than the compiler - in fact most if not all that is out there.
Might save me a lot of time and headaches.
Must remember to take a look at the cobc sources to see if is in one place and see if that can be used.
Very wishfull dreaming :)
Progress -
Tested with basic COPY verbs (no replacing) for free format all ok.
Tested with copy replacing using var by var for free format all ok.
Thats the good news as copy replacing using the ==abcd== by ==efg== is broken.
Once solved then testing again but using fixed format.
During testing found bugs in Printcbl in various areas and these have been fixed as for cobxref but again the repacing ==abcd== etc is broken and not tested yet fixed format.
Yes that means I an testing both cobxref and printcbl as all bugs now found relate to the copy verb processing.
That is 'assuming' testing for FIXED format does not produce any more.
Famous last words.
.
Forgot to add - this new version does/or not:
Is an independent program - it is not callable from the compiler - all such code is being removed.
It is run using standard commands such as:
cobxref sfn.cbl sfn.lst -FREE | -free | -FIXED | - fixed
It will create additional files -
sfn.lst - source listing plus xref reports.
sfn.pco - contains all expanded copy books) - Can be deleted after EOJ.
Part1.tmp created in your ./tmp directory - These are used for sort processing .
Part2.tmp and may be deleted after EOJ.
For source containing nested programs / modules on EOJ the PARTn.tmp files only hold data for the last module processed.
It starts byrunning the printcbl inbedded module which reads cobol source file (sfn.cbl) creating first an updated source file sfn .pco this is then read by cobxref to create the listings followed by all of the xref output.
The extra functions have been added to the xref output - Functions (minor update) and user and system functions/ Calls along with increased table holding ALL forms of current compiler reserved words.
Yes, I have omitted some steps here.
The new version of cobxref has been release and uploaded to sourceforge as v2.01.01.
This supports fixed and free format and COPY verb down nine levels with all reportedand found bugs fixed .
As it uses a version of printcbl to do the processing of the COPY CDF facility that too has been updated along with various bug fixes so that the two are inline with each other as much as possible.
It has been tested against some 1,000 productions programs including some that are over 40,000 lines long as well as various test sources.
There has not been any changes to the MVS version as that ony uses fixed format sources.
Last edit: Vincent (Bryan) Coen 2019-03-11
A new version has been released as v2.02..01 this covers:
Bug fix for report page numbering with odd values after the count reaches 127 - due to a data field as binary-char, changed to binary-long. This will cover large program listings along with one containing nested programs.
Support for user words of up to a length of 63 characters where used for data, section, paragraph, program and module / function names.
This has only been tested against cobxref itself which does not have words beyond current standards. The current code base for GnuCobol dated on or after 11th May 2019 supports this facilty.
Cobxref processes long data, section and paragraph names by printing it on a line by it self before printing the definitions and references etc.
Minor support for same with program or module names in heading but there is a total limit of 64 chars for both, where nested sources are in use and included in char count is extra 2 chars for '(' & ')' literals used i.e., cobxref (printcbl) so could be cut off if size is exceeded as print line takes in to account users with ink jet / Laser printer and not Matrix / line printers with 160 column paper.
If you can please test this new function (along with latest GnuCobol code base and report any issues.
Update v2.02.02 fixes a small problem with an updated manual - nothing heavy.
See files section.
Last edit: Vincent (Bryan) Coen 2019-06-24
Update v2.02.03 fixes a small but significant error when source program has >>SOURCE statement in the wrong column such as cc9 and is ignored when cobxref is run without -free parameter. This error caused a msg2 error as cobxref was trying to use FIXED format to read a free format source.
SVN and archive has been uploaded.
Update v2.02.04 - December 2021.
Bug found by David Wall in zz180-Check-For-Param-Errors where a perform search was using 128 for a field that is only 64 characters and that produced a runtime out of bounds error.
At some point I changed the size but did not find in all other testing, but it may be, he had -g (runtime checks) set for during the compile.
Thanks, David.
In bc000-Test-For-Missing-Replace and when running with -g, produces a runtime failure so now checking if not > 1 in bc000-Test-For-Missing-Replace. {Incident waiting to happen]
Added test for X"0A" along with the test for X"0D" in case running under Windows - needs testing though as I do not do so.
Added 'continue in empty perform - end-perform blocks if nothing else will get rid of the silly warning regarding 'warning: inline PERFORM without imperative statement used'.
Update v2.03.04 - 27th March 2022
All known bugs cleared, including duplicate reference numbers, for same variable.
Included support for CDF statements :
Increased the number of referenced occurrences per report line from 8 to 12 and added a total reference count per variable to make it easier for testing against other cross reference programs including the internal one.
Included feature to produce both block xref lists at end of program and the normal one by group, section etc, more to aid testing but programmers might find it useful.
Some other very minor changes I have forgotten about :)
One very minor problem has come to pass in that :
When using the CDF statements >>DEFINE and >>SET with CONSTANT cobxref transfers these to the GIT (Global/External) table as soon as it finds them - so far so good. It then uses them by adding them into the sort input file, runs sort then produces the source and xref listings etc
I have now found out that both of these CDF statements are only in scope up to the point of an
END PROGRAM progname statement when they are terminated.
cobxref does no such thing, it retains them until the end, so if you have nested programs in your source where such CDF elements are used they will appear in the xref's throughout all nested programs.
As this will involve some time for coding around it, it has been put on the back burner as a very low priority item.
There again it depends on how many programmers use nested programs and CDF commands >>DEFINE and/or >>SET
If it does, get in touch and tell me what you are using cobxref for.
Needless to say at time of writing the gc internal xref does not handle CDF at all.
Last edit: Vincent (Bryan) Coen 2022-03-27
Referring to post 2022-03-27 version is updated to v2.03.05 where some code was added to support tidying up the issue with CDF >>DEFINE and >>SET for the git table but as no one has commented or complained about this functionality it has not been progress further.
I.e, any CDF >>DEFINE etc set at the top of a nest program group will remain in effect for all nested programs.
As very few programmers make use of the nested program feature this issue is not likely to come up, although I do make use of it in some of my Cobol tools, i.e., cobxref :)
I am pleased to announce V2.03.05 has been released today directly here and in GC contribs.
This version will now remove the CDF >>DEFINE | SET vars from the Global table when reading an END PROGRAM statement. A extra error message has been added if the Global count after remove said CDF words means that the count is negative and no it should not happen:
Also cleaned up msg3 - 6 by putting them in correct logical order - the manual has been so updated.
svn has been updated with the files changed and a new archive cobxref-2.03.05.zip added to the files section.
Version 2.03.12 -> v2.04, hopefully will be released in a few weeks / month, once some bugs have been traced and fixed.
This introduces facilities for nested programs to have GLOBAL, EXTERNAL and CDF DEFINEs etc showing up in the right places in the xref listings.
Note that an END PROGRAM | FUNCTION terminates any CDF DEFINEs (>>DEFINE or $SET DEFINE for that program as the compiler should be doing at least according to @Simon.
Of course, this does NOT apply to the use of GLOBAL or EXTERNAL for files and any variables so set up.
Also see tracker reference #2 for possible more info.
Update v2.03.15 has been uploaded to the file area.
This fixes bugs where cobxref processes verb CALL where there is a reserved word pre routine name such as STATIC or STDCALL where these reserved words would be used instead of the routine.
I have tried to update the SVN system but keep getting a message that the first file being commited is out of date and it is not. I cannot see a way of fixing this issue.
That said the current version is present in the GnuCobol contrib area - that works.