Hi ,
I have two files with a common PD field. when i tried to match the files using the common PD field, i am not getting the intended result. Can someone clarify , whether we can use PD field in JOINKEYS, otherwise , how to use the PD fields in the JOINKEYS.
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
Quote:
FIELDS=(p,m,s<,p,m,s>...)
Must be specified to indicate the starting position, length and order (ascending or descending) of the keys in the
input file. The keys will be treated as binary, so they must be "normalized". For example, if the keys are actually
zoned decimal, they must have all C and D signs, or all F and D signs. You can use an INREC statement in
JNF1CNTL and/or JNF2CNTL to normalize the keys for the F1 file and/or F2 file, respectively, if appropriate.
Each pair of keys for the F1 and F2 files must match with respect to length and order, but can start in different
positions. For example, if the first key for the F1 file is 5 bytes ascending and the second key for the F1 file is 3
bytes descending, the first key for the F2 file must be 5 bytes ascending and the second key for the F2 file must be
3 bytes descending.
p specifies the starting position of the key. The first data byte of a fixed-length record is in position 1.
The first data byte of a variable-length record is in position 5 after the 4-byte RDW. p can be 1 to 32752 but all fields must
be completely contained within the first 32752 bytes of the record.
This is the Sort card i am using, Both the files have PD fields @ the position, 11,8. Even i tried to view the whole record (1:4010)..... but none of the records are matching between the two files based on the fields i have used for matching. 1,8 is a date field, and 11,8 is a PD field in both the files.
When i tried to view the whole reformatted record, i.e, 1:4010, F2:11,8 are spaces for all the records. That means , the keys are itself not matching... right?
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
dbz wrote:
FIELDS=(p,m,s<,p,m,s>...)
Must be specified to indicate the starting position, length and order (ascending or descending) of the keys in the input file.
The keys will be treated as binary, so they must be "normalized". For example, if the keys are actually zoned decimal, they must have all C and D signs, or all F and D signs. You can use an INREC statement in
JNF1CNTL and/or JNF2CNTL to normalize the keys for the F1 file and/or F2 file, respectively, if appropriate.
now, how to do it? someone else will have to provide you syntax for the INREC statement.
by the way, congratulations on figuring out what your problem is.
Change a C sign to an F sign in PD values
A customer asked the following question:
I have three 5-byte packed decimal fields starting in positions 1, 6 and 11.
The positive values have a C sign (e.g X'123456789C'), but I need them to have an F sign.
The negative values have a D sign which I don't want to change.
Can DFSORT change the sign from C to F for the positive values?
DFSORT's TO=PDF feature makes it easy to change the C sign to an F sign in your PD values.
In this case, we can use OVERLAY to change the signs in the three specified fields
without changing anything else in each record.
Here's the control statements we'd use:
OPTION COPY
INREC OVERLAY=(1:1,5,PD,TO=PDF,
6:6,5,PD,TO=PDF,
11:11,5,PD,TO=PDF)
TO=PDF sets an F sign for each positive PD value regardless of whether it originally had an F sign or a C sign.
TO=PDC sets a C sign for positive PD values.
TO=ZDF sets an F sign for positive ZD values.
TO=ZDC sets a C sign for positive ZD values. the D sign is kept for negative values in all cases.
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Dick,
It's not that I don't appreciate people trying to help - it's just that I get in later then everyone else because I'm on the U.S. West Coast and then I have to plow through all of the posts which is kind of counterproductive for me. There are 22 posts here in this thread. It should only have taken less than 5 at the most if I could have just asked the right questions myself. I just get a little tired of plowing through all these "good intentions". Even if the 22 posts helped clarify what was needed, that's a lot of posts. I think I can hone in on the problem and provide a solution more quickly in most cases, so I think the long discussions (and metadiscussions resulting from the discussions) are more of a distraction then a help. I hope you understand.
Thanks for your help.
