One option is to use -Xref and -ftsymbols (I have forgotten if it shows length of group items) and another is to use a small programm with each data block in it then use the snippit :
move function length (value-record) to we-error.
move we-error to disp9.
display "value-record " disp9
and here attached is a baby example prog I wrote ealier - OK a lot earlier !
Note that the COPY 's bring in the group and rest for each File def or record etc.
One option is to use -Xref and -ftsymbols (I have forgotten if it shows
length of group items) and another is to use a small programm with each
data block in it then use the snippit :
Follow on : Now run GC with the test-length.cbl code with -Xref -ftsymbols etc and it does NOT provide lengths of group items. It really should do as well as the byte lengths of items instead of COMP names etc's.
My own product cobxref does not do any breakdowns of sizing as I have never needed it other than as produced by runing a variant of test-length as my main use is to check what vars and procs are not called when a program / suite is finished for minor tidy ups of the code base and some times where a var is used.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks Vince. That was a feature I liked about mainframe. Compiler, for example, is telling me my redefines are uneven sizes. I will recount and correct; but was nice to know the exact count of each.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Now run GC with the test-length.cbl code with -Xref -ftsymbols etc and it does NOT provide lengths of group items.
???
cobc -t test.lst -ftsymbols test-lengt.cbl
produces a full listing including diagnostic messages and the symbol list:
SIZE TYPE LVL NAME PICTURE
WORKING-STORAGE SECTION
00016 ALPHANUMERIC 77 prog-name X(16)
00005 NUMERIC 77 disp9 9(5)
00058 GROUP 01 ws-data
00001 ALPHANUMERIC 03 ws-reply X
00001 NUMERIC 03 a 99 COMP
00050 ALPHANUMERIC 03 option-list X(50)
00006 GROUP 03 wsmaps-ser
00002 ALPHANUMERIC 05 wsmaps-ser-xx XX
00004 NUMERIC 05 wsmaps-ser-nn 9(4)
I'd say that the group size of ws-data as shown is 58 bytes, and wsmaps-ser is 6 bytes.
Did I miss something?
... and in case you only want the symbols add -fno-tsymbols -fno-tsource -fno-theader and if you really want you may even trash away the messages and output to stdout:
You still confuse me. The size of the group is shown (58) and the size of the PIC 99 COMP field is shown (1).
I must miss to see something you miss, what is it, please?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
oh, it is on the left, the mainframe is on the right.. Guess they may
think the number on the left are line numbers. But I SEE 58.
That all said if some one could sort out the crazy date i.e., DATE TIME
and not time embedded inside the date.
Every time I see it I cringe and that is putting it mildly !
Vince
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@vcoen: you won ;-) see [r4387] - year is before the time now and you can adjust this to remove the time or otherwise format (just keep in mind the max of 26 bytes).
There is a compiler directive that will affect the number of bytes allocated to comp / comp-4 and comp-5 fields.
The default appears to be -fbinary-size=1-2-4-8
Any mainframe (zOS) app will use -fbinary-size=2-4-8
Thus:
00001 NUMERIC 03 a 99 COMP
Would allocate 2 bytes in a mainframe environment.
00002 NUMERIC 03 a 99 COMP
I don't know what vanilla "C" allocations are for int declarations.
The listing files properly account for the binary-size in effect at compile time.
Just sayin :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Would like to know the length of all the fields in the pgoram, if possible.. to double check my math.
Is there an easy way?
cobc -t -fsymbols prog.cob(you can omit a bunch of entries in the listing by using-fno-tset of options).One option is to use -Xref and -ftsymbols (I have forgotten if it shows length of group items) and another is to use a small programm with each data block in it then use the snippit :
and here attached is a baby example prog I wrote ealier - OK a lot earlier !
Note that the COPY 's bring in the group and rest for each File def or record etc.
Thank you VInce.
On Thu, Sep 9, 2021 at 7:35 AM Vincent (Bryan) Coen vcoen@users.sourceforge.net wrote:
mod edit to remove some reply-to
Last edit: Brian Tiffin 2021-09-11
Follow on : Now run GC with the test-length.cbl code with -Xref -ftsymbols etc and it does NOT provide lengths of group items. It really should do as well as the byte lengths of items instead of COMP names etc's.
My own product cobxref does not do any breakdowns of sizing as I have never needed it other than as produced by runing a variant of test-length as my main use is to check what vars and procs are not called when a program / suite is finished for minor tidy ups of the code base and some times where a var is used.
Thanks Vince. That was a feature I liked about mainframe. Compiler, for example, is telling me my redefines are uneven sizes. I will recount and correct; but was nice to know the exact count of each.
???
cobc -t test.lst -ftsymbols test-lengt.cblproduces a full listing including diagnostic messages and the symbol list:
I'd say that the group size of ws-data as shown is 58 bytes, and wsmaps-ser is 6 bytes.
Did I miss something?
... and in case you only want the symbols add
-fno-tsymbols -fno-tsource -fno-theaderand if you really want you may even trash away the messages and output to stdout:Yes, it is NOT showing the sizing of binary fields i.e., COMP.
So "Assumes" the programmer knows them all - not a given at least when
s/he want a quick total.
Vince
mod edit to remove some reply-to
Last edit: Brian Tiffin 2021-09-11
You still confuse me. The size of the group is shown (58) and the size of the
PIC 99 COMPfield is shown (1).I must miss to see something you miss, what is it, please?
oh, it is on the left, the mainframe is on the right.. Guess they may think the number on the left are line numbers. But I SEE 58.
On 09/09/2021 23:04, Mickey White wrote:
Now that you have mentioned it I have now seen it and yes I would have
expected it on the Right side.
Thanks for pointing it out and @Simon same for you.
Vince
On 09/09/2021 23:04, Mickey White wrote:
That all said if some one could sort out the crazy date i.e., DATE TIME
and not time embedded inside the date.
Every time I see it I cringe and that is putting it mildly !
Vince
@vcoen: you won ;-) see [r4387] - year is before the time now and you can adjust this to remove the time or otherwise format (just keep in mind the max of 26 bytes).
Related
Commit: [r4387]
On 28/09/2021 17:05, Simon Sobisch wrote:
Date followed by time (in 24hr form) is spot on.
I will grab the latest in a few days.
Thank you.
Vince
Related
Commit: [r4387]
@sf-mensch I did what you proposed and definitely see it now.. Thank you!! That is what I was looking for.
There is a compiler directive that will affect the number of bytes allocated to comp / comp-4 and comp-5 fields.
The default appears to be -fbinary-size=1-2-4-8
Any mainframe (zOS) app will use -fbinary-size=2-4-8
Thus:
00001 NUMERIC 03 a 99 COMP
Would allocate 2 bytes in a mainframe environment.
00002 NUMERIC 03 a 99 COMP
I don't know what vanilla "C" allocations are for int declarations.
The listing files properly account for the binary-size in effect at compile time.
Just sayin :-)