my input is like
4693.83 ABC
2983.54 ABC
5635.39 ABC
2053.03 ABC
2053.03 DEF
I want to sum all these fields based on the last three digits.. i.e my output should be
13311.96 ABC
2053.03 DEF
i tried giving SORT FIELDS=(12,3,ch,a)
SUM FIELDS=(1,4,ZD,6,2,ZD)
I gave like this because When i tried to give the full length of the amount field, it was giving SOC7 because of the decimal point present.
Now, I am facing a problem. When the positions after decimal point(6,2) adds up to a valur greater than 99, then that record is not getting summed up.
i.e. in this case, the first record has a value of .83 and second record has .54 after the decimal point. So these records are not getting summed and are coming individually.
But i am facing a small issue here. the problem is the second field which is of 7 byte lenfth should start from output file's 3rd column.(same as in input file).
but when i use the above card, the second field is getting displaced and is starting from column no 11.
I need the 2nd field to start from column no:3 and third field to start from column no:11. ( as in the input file.) also 2nd field is of length 7 bytes and 3rd field is of length 9(09)v99.
What change should i make to the code to correct this?
hope i am clear in communicating my problem.[/code]
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Krisprems,
You have:
Code:
SUM FIELDS=(3,7,ZD,11,12,ZD)
OUTREC OVERLAY=(3:3,7,UFF,M10,LENGTH=7,
11:11,12,UFF,EDIT=(TTTTTTTTT.TT))
Since you are converting the values to ZD and summing on the values as ZD, why are you using UFF instead of ZD in OVERLAY? UFF is for non-standard values (like those with a decimal point). ZD is a standard value. And ZD is actually more efficient than UFF. So your statements should be:
Code:
SUM FIELDS=(3,7,ZD,11,12,ZD)
OUTREC OVERLAY=(3:3,7,ZD,M10,LENGTH=7,
11:11,12,ZD,EDIT=(TTTTTTTTT.TT))
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Quote:
I didnt really realize that even the specification of data format would mark the efficiency.
Yes, the "fancy" formats like FS, UFF and SFF while very useful for non-standard types of data involve more processing than the "standard" types of data like BI, FI, ZD and PD. So if you have a choice, the standard types are preferable.
Also, note that once you convert values to ZD, using non-ZD formats for the converted values can cause problems. For example, if you used SFF to convert '-123.41' to ZD, you'd get X'F1F2F3F4D1' = '1234J'. This is a ZD value of -12341, but it is NOT an SFF value of -12341 - in fact, '1234J' would be interpreted as +1234 with SFF.
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
Hello,
Quote:
For example, if you used SFF to convert '-123.41' to ZD, you'd get X'F1F2F3F4D1' = '1234J'. This is a ZD value of -12341, but it is NOT an SFF value of -12341 - in fact, '1234J' would be interpreted as +1234 with SFF.
Is there some way to tell DFSORT to abend if this condition (i.e. letters in a numeric field) is found while processing (U0016?)?
For my $.02 an abend with an explanatory message would be far preferable to an incorrect calculation being used.
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Quote:
Is there some way to tell DFSORT to abend if this condition (i.e. letters in a numeric field) is found while processing (U0016?)?
No. SFF is signed free form format. It's purpose is to pick out the digits from any set of characters so letters, commas, decimal points, etc would be expected. If you want straight digits, use ZD, not SFF. Sounds like you're asking for a format where you can specify exactly which characters you want to be considered valid and which you don't. I'm not sure that would actually be practical and it certainly wouldn't be very efficient.
