I'm working on a code that have a déclaration of a variable as : 01 W-NB-FICHIER-AR PIC 9(03) VALUE ZERO.
The code is compile on version 3.0-rc1 but fail to execute correctly. In fact i can find miss value on it. display "1 W-NB-FICHIER-AR=<" W-NB-FICHIER-AR "> for exemple will print 1 W-NB-FICHIER-AR=<000>.
But after a add as ADD 1 TO W-NB-FICHIER-AR will print a 1 W-NB-FICHIER-AR=<anc>.
A fix that seem to work is to re-initialize the variable out of the WORKING-STORAGE SECTION. with a MOVE 0 TO W-NB-FICHIER-AR.
With that the variable will not contain char in place of a numeral.
I there a problème by declaring and initialize the variable in the WORKING-STORAGE SECTION.?
If you want i can clean and send the code that i'm using.
Thank you!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No problems known other than things related to OCCURS which are all solved in 3.1.2 with one exception (related to level 01 OCCURS, which is already in the bug tracker and also solved "locally").
In General: 3.0rc1 is very old and 3.0 never had a release, so it is very reasonable to update to 3.1.2 (3.0 modules are believed to be compatible, you normally should be fine by replacing libcob/cobc and then only recompile "problematic" programs).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Pardon me for the delay but this code was a little bit strong for me to debug.
Af far as i've understood the probleme some of my variables are not fill with the right type.
In the file MDAAD30.cob, i can find four variables impacted by this behviour: W-NB-FICHIER-AR, PRESENCE-COMMENTAIRES, PRESENCE-ENTETE, PRESENCE-ACCUSE.
The first one (W-NB-FICHIER-AR) got a strange behavior if i comment the MOVE line 64. But seem's to have a good execution with the the double initialisation (line 51/ line 64).
For the other i've tried the same fix to double initialize it (line 107 and line 108,109,110) but this time that don't match my attemps.
The to différent output and executable can be find in the tar with a sample file for execution.
My interpration, maybe a bad one :), about the output is there is something wrong with the Inspect and Tallying.
I can see on my counter some part of the file that is read. I ve try to reinitialize these counter into the read instruction (not the desired behavior) to see if that fix the execution.
And it fact that fix it and don't put any other file part into my PIC 9 variable but that program will no more do the thing that is disigned to do.
My knowledge of READ and INSPECT call is not really advanced i may miss some thing. And i do not understand why the file part can be found in the W-NB-FICHIER-AR variable.
This code have been test on verison 3.1.2.
Thank you, I remain available if you need more informations.
I'll leave others to inspect the code, just one thing ADAR00E-R00 looks like XML with a size up to 500 bytes. In this case you may want to change it to
Well just a quick look and thought. From my experience with XML files, the file really is one big record that you read into a table and the xmlparser goes thru the table and lists the individual elements to your description. (I have only done One xml file on mainframe and microfocus)
I changed the record length max to 6872 and ran your program. Here are the results.
Yes you are right, if i upgrade the number of byte read no variable is lost, as in my exemple i can this the first pass through the file fill right the variable.
But i case i want to read multiple fiel i can't change in evry execution the amount of the byte read.
Maybe if you have more tips on how i can investigate further?
Thank you!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
M_D, I have a sample program for you. I am doing memory mapping of the input file, it works on Linux. I do not know how to memory map on windows. (but believe that it is possible)
It should work for any size file. In the 9000-init paragraph, I memory map the file name that was in your FD. As long as other input files names are the same ( ADAR00E-R00 ) it should work.
Basically I made the file a table of 1 occurrence of 1 byte for the file size length. So your INSPECT will just look for something within the whole record (1:file-size)
It may work for you, if you are Linux.
That is about all I know.
IF the files you are parsing are XML, you may look for XML parsers on the sourceforge www site, or google it.... We were using the Mainframe IBM cobol parser and then the MicoFocus cobol parser. When we went to GnuCOBOL, we had to rewrite it in Perl. ( I believe there are plans to have an XML parser for GnuCOBOL soon?)
Anyway, if you are linux, this may work.
My hacking is not pretty as I seldom use -Free....
Mickey
Ok thank you this solution fonction on my centos environment!
But evry time i want to read a file with a unknown size i've go to map it entierly. I can't make it with the READ and INSPECT, is that how cobc was disigned or is a unwanted behavior ?
Thanks for the help!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I'm working on a code that have a déclaration of a variable as :
01 W-NB-FICHIER-AR PIC 9(03) VALUE ZERO.The code is compile on version 3.0-rc1 but fail to execute correctly. In fact i can find miss value on it.
display "1 W-NB-FICHIER-AR=<" W-NB-FICHIER-AR ">for exemple will print1 W-NB-FICHIER-AR=<000>.But after a add as
ADD 1 TO W-NB-FICHIER-ARwill print a1 W-NB-FICHIER-AR=<anc>.A fix that seem to work is to re-initialize the variable out of the
WORKING-STORAGE SECTION.with aMOVE 0 TO W-NB-FICHIER-AR.With that the variable will not contain char in place of a numeral.
I there a problème by declaring and initialize the variable in the
WORKING-STORAGE SECTION.?If you want i can clean and send the code that i'm using.
Thank you!
If you can clean & send the code - it'll generally be answered within minutes.
No problems known other than things related to
OCCURSwhich are all solved in 3.1.2 with one exception (related to level 01OCCURS, which is already in the bug tracker and also solved "locally").In General: 3.0rc1 is very old and 3.0 never had a release, so it is very reasonable to update to 3.1.2 (3.0 modules are believed to be compatible, you normally should be fine by replacing libcob/cobc and then only recompile "problematic" programs).
Hello,
Pardon me for the delay but this code was a little bit strong for me to debug.
Af far as i've understood the probleme some of my variables are not fill with the right type.
In the file MDAAD30.cob, i can find four variables impacted by this behviour: W-NB-FICHIER-AR, PRESENCE-COMMENTAIRES, PRESENCE-ENTETE, PRESENCE-ACCUSE.
The first one (W-NB-FICHIER-AR) got a strange behavior if i comment the MOVE line 64. But seem's to have a good execution with the the double initialisation (line 51/ line 64).
For the other i've tried the same fix to double initialize it (line 107 and line 108,109,110) but this time that don't match my attemps.
The to différent output and executable can be find in the tar with a sample file for execution.
My interpration, maybe a bad one :), about the output is there is something wrong with the Inspect and Tallying.
I can see on my counter some part of the file that is read. I ve try to reinitialize these counter into the read instruction (not the desired behavior) to see if that fix the execution.
And it fact that fix it and don't put any other file part into my PIC 9 variable but that program will no more do the thing that is disigned to do.
My knowledge of READ and INSPECT call is not really advanced i may miss some thing. And i do not understand why the file part can be found in the W-NB-FICHIER-AR variable.
This code have been test on verison 3.1.2.
Thank you, I remain available if you need more informations.
I'll leave others to inspect the code, just one thing ADAR00E-R00 looks like XML with a size up to 500 bytes. In this case you may want to change it to
(with LRECL removed if you don't access it directly)
I'm looking forward to learn more about the issue you see, maybe @davewall or @jamesbwhite or someone else will go this though in more detail.
Well just a quick look and thought. From my experience with XML files, the file really is one big record that you read into a table and the xmlparser goes thru the table and lists the individual elements to your description. (I have only done One xml file on mainframe and microfocus)
I changed the record length max to 6872 and ran your program. Here are the results.
Yes you are right, if i upgrade the number of byte read no variable is lost, as in my exemple i can this the first pass through the file fill right the variable.
But i case i want to read multiple fiel i can't change in evry execution the amount of the byte read.
Maybe if you have more tips on how i can investigate further?
Thank you!
M_D, I have a sample program for you. I am doing memory mapping of the input file, it works on Linux. I do not know how to memory map on windows. (but believe that it is possible)
It should work for any size file. In the 9000-init paragraph, I memory map the file name that was in your FD. As long as other input files names are the same ( ADAR00E-R00 ) it should work.
Basically I made the file a table of 1 occurrence of 1 byte for the file size length. So your INSPECT will just look for something within the whole record (1:file-size)
It may work for you, if you are Linux.
That is about all I know.
IF the files you are parsing are XML, you may look for XML parsers on the sourceforge www site, or google it.... We were using the Mainframe IBM cobol parser and then the MicoFocus cobol parser. When we went to GnuCOBOL, we had to rewrite it in Perl. ( I believe there are plans to have an XML parser for GnuCOBOL soon?)
Anyway, if you are linux, this may work.
My hacking is not pretty as I seldom use -Free....
Mickey
Ok thank you this solution fonction on my centos environment!
But evry time i want to read a file with a unknown size i've go to map it entierly. I can't make it with the READ and INSPECT, is that how cobc was disigned or is a unwanted behavior ?
Thanks for the help!
In this case, when I compile with valgrind with the debugs flags, I can see that:
Maybe it's this unaddressable byte that's causing this problem?
I created an issue here: link
Last edit: sbelondr 2022-02-01