Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Don't have time to test, but by making the "dummy" tests for the first and last, which can be generated from HEADERn and TRAILERn, the construction of the actual tests you want is simplified. Read the conditions file and for every line generate the same with the contents of the data from your file being placed within the quotes of the literal in the INCLUDE tests.
Code:
INCLUDE COND=(1,1,CH,NE,1,1,CH,OR,
SYMBOL,EQ,C'TYPE1',OR,
SYMBOL,EQ,C'TYPE2',OR,
....
SYMBOL,EQ,C'TYPEn',OR,
1,1,CH,NE,1,1,CH)
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
The test for the first byte not equal to the first byte is just a "placeholder". It will never be true, and combining it by using OR will not affect the processing of the selection actually desired in the INCLUDE.
<Some necessary opening stuff>NOT TRUE, OR
SOME CONDITION,OR,
SOME CONDITION,OR,
SOME CONDITION,OR,
NOT TRUE<some necessary closing stuff>
Purpose just to simplify the generation of the SOME CONDITION stuff, so no need to worry about first/last.
I saw Frank Yaeger using something like it and had no time to search for the example so "imagined" what it had to be :-)
The test for the first byte not equal to the first byte is just a "placeholder". It will never be true, and combining it by using OR will not affect the processing of the selection actually desired in the INCLUDE.
If this was a response to my question, why does OP want to add extra condition and processing? If the condition is never going to be true, why bother to have it in the card itself?
I was merely implying typo on OP's end when i asked that question.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
I think everything is in the original post and in my reply.
Perhaps an even simpler way is to use concatenation:
//SYSIN DD "top of the cards"
// DD generated cards
// DD bottom of the cards
More "set up" this way.
The HEADERn and TRAILERn can be modified to generate any other control statements required, so a general "quick way of generating a sort deck with data from a file". Yes, slows down a little with the never-true tests, but gets the job done and is "reusable".
If the selection file is
Code:
TYPE1
TYPE2
and the data is
Code:
TYPE1
TYPE2
TYPE3
then testing for NUM is going to get too much.
My reading is that the selection file is more like
Code:
TYPE1
TOPEX
IJDK3
11111
From the original:
Quote:
I don't know how many there will be, but I do know, that they are all different.
Joined: 07 Dec 2007 Posts: 2205 Location: San Jose
Claes Norreen wrote:
Sqlcode1,
I think you misunderstand the task I wish to do. I don't know I would use JOINKEYS here, anyway?
I agree with SQLCODE that you can use JOINKEYS as you are looking for TYPE field which is at the same position for every record. So why not match the 2 files (extract file and Look up file) on the type field and get the matching records?
Ah, I see now. Maybe "diverse" was not correct English.. I have a few types I wish to include from a dataset, and I don't want to sort it by TYPE, but keep it the way it is. Hence, a copy operation makes sense.