|
View previous topic :: View next topic
|
| Author |
Message |
vijikesavan
Active User
Joined: 04 Oct 2006
Posts: 118
Location: NJ, USA
|
|
|
|
Hi,
I have a KSDS vsam file. I need to extract records which has a 'Y' on the particular position. I tried giving the condition in the sort card, but not getting the desired result.
I am not sure how to paste the contents from the mainframe screen like everyone..Attached all the deatils in the document.
Viji |
|
| Back to top |
|
 |
William Thompson
Global Moderator
Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ
|
|
|
|
| I'm thinking that sort might be treating it a variable, try adding 4 to the displacement.... |
|
| Back to top |
|
|
superk
Global Moderator
Joined: 26 Apr 2004
Posts: 4652
Location: Raleigh, NC, USA
|
|
|
|
I'm extremely leery of opening foreign Microsoft documents (Word or Excel).
| vijikesavan wrote: |
I am not sure how to paste the contents from the mainframe screen like everyone.
|
You use standard Windows cut/paste from your emulator to your desktop. For data and code, in order to make it easy to read and to keep spaces and indentation intact, you use the bbI CODE tags around the data:
[ code ]
my data ...
[ /code ]
Just don't include the spaces as shown.
Using your VSAM definition, data, and SORT JCL, it worked just fine for me. Can you post the output from your SYSOUT DD? |
|
| Back to top |
|
|
Frank Yaeger
DFSORT Developer
Joined: 15 Feb 2005
Posts: 7129
Location: San Jose, CA
|
|
|
|
Viji,
Since you didn't use a RECORD TYPE=x statement to tell DFSORT whether to treat your VSAM input file as F or V, DFSORT used the default of V based on the fact that your input and output files are VSAM. For V processing, DFSORT adds a 4-byte RDW to each record, so the first data byte starts at 5, not 1. Therefore, you have to use position 12 (8+4) for your 'Y' field rather than positon 8. I'd suggest using RECORD TYPE=V for documentation:
| Code: |
OPTION COPY
RECORD TYPE=V
INCLUDE COND=(12,1,CH,EQ,C'Y')
|
For more information on processing VSAM files with DFSORT, see:
publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ICE1CA20/1.8.3.4?SHELF=&DT=20060615185603&CASE= |
|
| Back to top |
|
|
William Thompson
Global Moderator
Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ
|
|
|
|
Frank,
I saw the same thing in Syncsort, but for the life of me I couldn't determine that the output file was VSAM, because if not, Syncsort would have used F for the input. How did you figure it?
Bill |
|
| Back to top |
|
|
Frank Yaeger
DFSORT Developer
Joined: 15 Feb 2005
Posts: 7129
Location: San Jose, CA
|
|
|
|
William,
I just assumed the SORTOUT file was VSAM since it had 'VSAM' in the dataset name. I guess I could have been wrong, but it fit with the "problem". |
|
| Back to top |
|
|
vijikesavan
Active User
Joined: 04 Oct 2006
Posts: 118
Location: NJ, USA
|
|
|
|
Hello everyone,
It worked fine when I gave the position as "12" irrespective of record type = V. (Both worked)
Its really amazing to see the replies so fast....thanks a lot for your help.
-Viji |
|
| Back to top |
|
|
Frank Yaeger
DFSORT Developer
Joined: 15 Feb 2005
Posts: 7129
Location: San Jose, CA
|
|
|
|
| Quote: |
| It worked fine when I gave the position as "12" irrespective of record type = V. (Both worked) |
Yes, as I said, DFSORT will use a default type of V in this case. But it's "safer" to specify RECORD TYPE=V explicitly in case something changes (for example, in case you change the output file to non-VSAM some time in the future). |
|
| Back to top |
|
|
William Thompson
Global Moderator
Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ
|
|
|
|
| Frank Yaeger wrote: |
| I just assumed the SORTOUT file was VSAM since it had 'VSAM' in the dataset name. |
 Jeez, "male vision" again
| Quote: |
| I guess I could have been wrong, but it fit with the "problem". |
I was leaning that way, almost posted, but just didn't feel sure enough, besides I knew the cavalry was coming.....  |
|
| Back to top |
|
|
|
|
