I tried it out and it seems like, if SORT finds the first condition matches for a particular row, it would not take into consideration that row for the next evaluation.
The above could be due to the fact that the conditions are not exactly mutually exclusive.
This above criteria - eventhough, mutually exclusive - didn't work. The count for the first instance was set to 0 itself, whereas the second field came up just fine.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
cybertaurean wrote:
[...]
I tried it out and it seems like, if SORT finds the first condition matches for a particular row, it would not take into consideration that row for the next evaluation.
[...]
When there is something that "should" reasonably work, and it doesn't, that is the time to hit the manual to find out what you are doing wrong. If you take your above thought to the manual and read-up on the IFTHEN, you should be able to get to what you want.
"Why doesn't that work?" is usually better as "What I am not doing properly?" and sometimes "What idiotic rubbish did I invent to think that that would work?". The manual usually resolves which of the real questions it is.
By default the processing of IFTHEN stops when a condition is satisfied. In order to continue the validation you need to code HIT=NEXT parameter. Check your manual/search the forum on more details about this parameter.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Mmmm.... Kratos gave you a bigger "hint".
So you were right in how you were thinking, and are now aware how to code for it. Hopefully you found it in the manual yourself first, and got that extra "glow" from confirming it for yourself.
It's a useful process, let's call it a tool. Think, manual, think again, manual - then colleagues, techies, ibmmainframes. Use the web at any point you like as well. That'll get the majority of your problems solved, and quicker each time as you get more experience with it. Applies to all software/systems.
Now you can sum the fields at pos 4 and pos 10 for a length of 5 bytes which would give you the desired results. In order to the summing you need to sort which is a moot point as you only A records. So it is better to use the reporting features and get the counts.
@Bill: Yeah... I had come across that, and got that "glow" feel after it worked . Thanks!!!
Special Thanks to Kratos86 for the insight!!!
@Kolusu: Thanks, as always
BTW... Had to be tweaked per the requirement (HIT NEXT at the right places)... The entire thingy listed below (with all the "confidential" (if any) stuff removed, ofcourse) -
Joined: 07 Dec 2007 Posts: 2205 Location: San Jose
cybertaurean,
I see that you are validating 4 contiguous bytes, so why not search the entire 4 bytes as a single filed? If you have any data in pos 35 for 2 bytes you can force it to have spaces when the field doesn't contain 'D ' and you can avoid coding the HIT=NEXT on every IFTHEN statement.
The initial When=INIT will force 2 spaces in pos 35 if the value does not contain 'D ' , with a CHANGE parm. By doing so you are validating the complete 4 bytes as a single field and it becomes unique. Also you don't have to specify the positions and complete length to initialize the values to zero. You have 22 fields to be initialized to zero each with a length of 5 bytes (22 X 5 = 110 ). So 110C'0' will put 110 zeros from pos 37. since your intention is to put '1' on the last byte you don't have to specify the entire 5 bytes on the overlay as we already initialized the values to zero, you can simply code the pos of the last byte to have '1' . You have to overlay '1' for every 5 bytes starting from pos 41. ie ( 41, 46, 51, 56,....146).
Also since we know the summing fields all have the same format we can specify it just once using FORMAT=ZD like shown below.