problem i'm having with sorting a file and encountering duplicate records where too much money is present in the fields i am summing.
Organization . . . : PS
Record format . . . : FB
Record length . . . : 70
Block size . . . . : 6230
example of data
TOP OF DATA
waiting on Bill Parcells commitment before ticket purchase!
If SUM FIELDS is all you are doing, you can use SECTIONS/TRAILER3 function with TOT to expand field size while summing. Alternatively, you can expand the field size in advance and then do summing as well.
You would have received ICE152I message. Read explanation for that under Programmer Response:
If appropriate, redesign the records so that summary fields do not overflow, or, if possible, use INREC to increase the size of the summary fields (see z/OS DFSORT Application Programming Guide ), or specify the OVFLO=RC0, OVFLO=RC4, or OVFLO=RC16 run-time option to provide
a different return code for this situation.
OP is referring to the situation where DFSort, upon overflow condition, sets RC4 (if OVFLO=RC4 installation is set) and creates/splits record in to multiples.
For better answer, please provide complete sort card.
thanks guys, did make some progress, but only on one of the fields, using this inrec
the field in question (tb-gross-tax) did not overflow, guess i need to use same method on the other fields!
You've made that more complicated than it need be by specifying columns at the same position in the INREC record as you already are at the time. You specify 41: when 41 is already the next position, same with 42: and 48:.
However, if I take out the columns it becomes clear that you have built a couple of bytes twice. 41,6 and 46,24 have an overlap, bytes 46 and 47 being used twice. Did you want that?