Need to check Packed decimal value 4 at position 871.
The include condition is coded after adding four (VB file requirement).
However not a single record satisfying the condition is obtained though the file contains such records. I feel the problem is in Packed Decimal format (PD) comparisson. It would be great and helpful if anybody can provide a solution.
That OUTREC parameter would result in an error message for a VB file, because 1,4 must be included in the first field and it isn't. So that would lead to the conclusion that you actually have an FB file, not a VB file, which would mean that you have the wrong position for the PD field.
Check the SYSOUT messages. They'll tell you if the input file is FB or VB.
If it's really VB, then I don't see how you managed to get that OUTREC parameter to work.
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
jai,
In the future, please start a new thread for a different topic rather than adding it to an unrelated topic.
If the record lengths can vary from 87 to 1000 bytes, then you should treat the VSAM data set as variable. For more information on using VSAM data sets with DFSORT, see:
U mean for the sortin input file we need to specify(add) 4 bytes to the positions that we want to check the conditions like in include control card. sort won't add 4 bytes automatically to positions during comarision/checking condition.
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Jai,
Did you read the doc at the link I gave above. It answers your questions. I'll quote the relevant section here:
Quote:
Variable-length processing: An RRDS, KSDS, ESDS or VRRDS can always be processed as variable-length. For VSAM input, DFSORT reads each record and prepends a record descriptor word (RDW) to it. For VSAM output, DFSORT removes the RDW before writing each record. Since DFSORT uses an RDW in positions 1-4 to process variable-length records, the data starts in position 5. Control statement positions should be specified accordingly.
As it says, for variable record processing, you need to add 4 to the starting position of the fields you specify to account for the RDW that DFSORT adds to each input record. Put another way, for variable processing the first data byte starts in position 5, whereas for fixed processing the first data byte starts in position 1.
That OUTREC parameter would result in an error message for a VB file, because 1,4 must be included in the first field and it isn't. So that would lead to the conclusion that you actually have an FB file, not a VB file, which would mean that you have the wrong position for the PD field.
Check the SYSOUT messages. They'll tell you if the input file is FB or VB.
If it's really VB, then I don't see how you managed to get that OUTREC parameter to work.
Frank The output file is a FB file and hence the 1-4 bytes havent been included..
Iam using VSAM file for my input which has got min length as80 bytes and maximun of around 900 bytes.
when i use that file has input file at dd name sortin it taking as fixed length file insted if treating variable length file. any specific reason reason to treat as FB. If i included 4 bytes to length iam zero records i.e treating as variable, if i treat as fixed len file iam getting 5lac records.
the following control stmts are for fixed len file:
find below my control card used for sort. and the spool messages
OUTREC FIELDS=(18X,15,4,19,3,22,1,23,2)
SORT FIELDS=COPY
INCLUDE COND=(((23,2,PD,EQ,300,AND,19,3,PD,GE,50041),AND,
(23,2,PD,EQ,300,AND,19,3,PD,LE,51219)),OR,
((23,2,PD,EQ,300,AND,1,3,PD,GE,50041),AND,
(23,2,PD,EQ,300,AND,19,3,PD,LE,50041)))
spool messages:
12K BYTES OF EMERGENCY SPACE ALLOCATED
SORTIN : RECFM=F ; LRECL= 1000; CISIZE = 16384
OUTREC RECORD LENGTH = 28
SORTOUT : RECFM=FB ; LRECL= 28; BLKSIZE= 27972
.jpg)
