> -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Pfister, Nathan > Sent: Thursday, June 09, 2016 10:45 AM > To: [email protected] > Subject: DFSORT Question > > We have a sort on a file with LRECL 80 that is FB. > > The sort statements are as follows: > SORT FIELDS=(1,35,A,44,37,A),FORMAT=CH > SUM FIELDS=(36,8,ZD) > > This failed last night for the first time with a S0C7, and the applications team asked me to > look at it. I started looking at it and, not being the most sort knowledgeable person, I don't > understand why it failed or how it even ran in the first place. > > The data looks like this: > P0095WCI0029909070003616WC 0004707000047000160609 11491100160000 > P0095WCI8927171000004536WC 0162620000813100160605 99000100010751E > 57500 > P0087FAM8017732138500119APV0003590000035900160609 99000100010206I > P0087FAM8018524148500328APV0004630000023150160519 99000100010207C > P0087FAM8277753138500529APV0001315000013150160604 99000100010208E > 57500
I'm confused. Those are not 80 byte records. The records are not fixed length. > There are spaces (x'40') in the columns that are being summed (36,8). This normally works. Do you reformat the output record? There are no blanks in positions 36-43 in the data you show us. (The blanks you do show are in columns 27 and 50.) The manual does state that blanks anywhere but the final digit will be treated as zeros. > Last night this failed, and the only difference was that those rows with blanks were > identical numbers (which never happened before). > > > My questions are this: > My fundamental understanding of sort might be flawed here. How does this work to begin > with? Shouldn't I be getting a S0C7 regardless of the value of the first 5 columns of the > data? Except for the last column being summed, the high order nibble is ignored. Due to how DFSORT produces the sum, as long as the low order nibble is between 0 and 9 no exception will occur. > Second, why would I get a S0C7 when these rows have the same value? The data you shown us does support this assertion. Not having access to the source code for DFSORT, I am nonetheless very confident that DFSORT does not care that values in a non-sort field are repeated. > Third, if I run this as two separate steps first SORT > FIELDS=(1,35,A,44,37,A),FORMAT=CH then SORT FIELDS=COPY with the SUM > FIELDS=(36,8,ZD) statement, it works. Why would it work this way and not as a > combined sort? Do any of the summed fields contain negative values? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
