I have an input file with filename , volume and size in bytes.
My requirement is to sort the file and have only the volume and sum of size of all the files in the volume as output.
The size in bytes should be converted to KB/GB/MB based on the sum.
Could you please help me in this.
2. Please, provide any sample: what did you try so far?
If you did not try at all, then: why do you think SORT is good for you?
3. Some initial hints:
- resort your data by volume name - SORT FIELDS=
- provide detection of record groups with the same volume name - WHEN=GROUP or SECTIONS=(...)
- calculate total amount of bytes per each volume - TOT=(...)
- if needed, convert bytes amount to KB/MB/GB - IFTHEN=(WHEN=(...))
The size is in KB. I converted them by multiplying the sum of the size with 1024. I want them in KB/GB/MB based on the size.
I used the sort card.
Code:
SUM FIELDS=(46,11,ZD)
OUTFIL FNAMES=OUTPUT,
OUTREC=(1:58,6,1X,((46,11,ZD,MUL,+1000),DIV,+1024),
EDIT=(IIIIIIIT.TTT),C'K',
Here 46,11 is the size in bytes
58,6 is the volume,
P.S.
Adding the dot '.' in the middle of the result of multiplication - is the best way to create unbelievable mess in the next steps.
In your first post you planned to use all of them: KB/MB/GB?
Apologies for not reposting. My requirement is to convert the bytes to KB/MB/GB based on the sum.
[P.S.
Adding the dot '.' in the middle of the result of multiplication - is the best way to create unbelievable mess in the next steps. In your first post you planned to use all of them: KB/MB/GB]
2. Did you try using the suggested SECTIONS=(...) or WHEN=GROUP to calculate partial amounts per volume?
If not, there is no sense to start thinking about KB/MB/GB at this point.
Joined: 15 Aug 2015 Posts: 1255 Location: Bamberg, Germany
If your input is from DCOLLECT Data, you SHOULD check if the fields are in 31 bit, or 63 bit in length. Before summing, also make sure the target field is large enough to hold the result.
There is only one non-obvious trick in this task: after the total amounts by volumes has been calculated, SORT cannot provide re-calculation of bytes to KB/MB/GB in the same SORT pass.
Either two SORT JCL steps may be needed, or two SORT passes can be combined into one step for ICETOOL/SYNCTOOL.
Also need to take care of the required number of digits during re-calculation involved multiplication and division. If not enough, hi-order digits may just disappear without any trace...
SUMS@: intermediate results, for verification only.
Code:
********************************* TOP OF DATA ************
VOL01G 01073741824
VOL01K 00000001024
VOL01M 00001048576
VOL071 04401577003
VOL072 00010008503
VOL073 00000086674
******************************** BOTTOM OF DATA **********
SORTOUT:
Code:
********************************* TOP OF DATA *******
VOL01G 1.000G
VOL01K 1.000K
VOL01M 1.000M
VOL071 4.099G
VOL072 9.544M
VOL073 84.642K
******************************** BOTTOM OF DATA *****
Joined: 15 Aug 2015 Posts: 1255 Location: Bamberg, Germany
I would not go this way, you may face deviations. It's better to multiply first, then divide. I am not that quick providing solutions, it's a day off for me today.
I would not go this way, you may face deviations. It's better to multiply first, then divide. I am not that quick providing solutions, it's a day off for me today.
It is multiplied FIRST: in INREC statement.
It is divided NEXT: in OUTREC statement.
