Page 1 of 1

Multiple INCLUDE conditions not selecting all Recs

PostPosted: Wed Aug 29, 2012 2:00 am
by NicC
Hi

Time to get help! I am trying to select records from a VB file that ahve '>' in cols 46, 48 or 50 or containing the string 'CALCULATING Su' staring in col 16 (all start pos include 4 bytes for the RDW). I am getting all the records with the '>' in the various columns but the string match is not selecting any records. From my job and datasets...
 OPTION COPY,VLSHRT                         
 INCLUDE COND=(48,1,CH,EQ,C'>',OR,         
               50,1,CH,EQ,C'>',OR,         
               46,1,CH,EQ,C'>',OR,         
               16,14,CH,EQ,C'CALCULATING Su')
 

Input VB
----+----1----+----2----+----3----+----4----+
 PROGRAMX: W-TEMP-QX-RATE(W-MOVES-NUM)   >001500000<
 PROGRAMX: ********************************       
 PROGRAMX: START CALCULATING SURVIVAL RATES       
 PROGRAMX: ********************************     
 PROGRAMX: CALCULATING Survival Rate-Joint 0     
 PROGRAMX: W-INTERIM-1                9(5) >00001<
 

Output
 PROGRAMX: W-TEMP-QX-RATE(W-MOVES-NUM)   >001500000<
 PROGRAMX: W-INTERIM-1                9(5) >00001<   

Messages
ICE143I 0 BLOCKSET     COPY  TECHNIQUE SELECTED                               
ICE250I 0 VISIT http://www.ibm.com/storage/dfsort FOR DFSORT PAPERS, EXAMPLES AN
ICE000I 1 - CONTROL STATEMENTS FOR 5694-A01, Z/OS DFSORT V1R10 - 18:47 ON TUE AU
           OPTION COPY,VLSHRT                                                 
           INCLUDE COND=(48,1,CH,EQ,C'>',OR,                                   
                         50,1,CH,EQ,C'>',OR,                                   
                         46,1,CH,EQ,C'>',OR,                                   
                         16,8,CH,EQ,C'CALCULAT')                               
ICE201I G RECORD TYPE IS V - DATA STARTS IN POSITION 5                         
ICE751I 0 C5-K51707 C6-K51707 C7-K54603 C8-K51707 E9-K51707 C9-BASE   E5-K51707
ICE142I 0 SORTMSG  NOT FOUND - SYSOUT USED                                     
ICE193I 0 ICEAM1 INVOCATION ENVIRONMENT IN EFFECT - ICEAM1 ENVIRONMENT SELECTED
ICE252I 1 PARMLIB OPTIONS WERE MERGED WITH INSTALLATION MODULE DEFAULTS       
ICE088I 0 W311REX .STEP010 .        , INPUT LRECL = 240, BLKSIZE = 3120, TYPE =
ICE093I 0 MAIN STORAGE = (MAX,12582912,12582912)                               
ICE156I 0 MAIN STORAGE ABOVE 16MB = (12485872,12485872)                       
ICE127I 0 OPTIONS: OVFLO=RC0 ,PAD=RC0 ,TRUNC=RC0 ,SPANINC=RC16,VLSCMP=N,SZERO=Y,
ICE128I 0 OPTIONS: SIZE=12582912,MAXLIM=2097152,MINLIM=450560,EQUALS=Y,LIST=Y,ER
ICE129I 0 OPTIONS: VIO=N,RESDNT=NONE,SMF=NO   ,WRKSEC=Y,OUTSEC=Y,VERIFY=N,CHALT=
ICE130I 0 OPTIONS: RESALL=4096,RESINV=0,SVC=109 ,CHECK=Y,WRKREL=Y,OUTREL=Y,CKPT=
ICE131I 0 OPTIONS: TMAXLIM=12582912,ARESALL=0,ARESINV=0,OVERRGN=65536,CINV=Y,CFW
ICE132I 0 OPTIONS: VLSHRT=Y,ZDPRINT=Y,IEXIT=N,TEXIT=N,LISTX=N,EFS=NONE    ,EXITC
ICE133I 0 OPTIONS: HIPRMAX=OPTIMAL,DSPSIZE=MAX ,ODMAXBF=0,SOLRF=Y,VLLONG=N,VSAMI
ICE235I 0 OPTIONS: NULLOUT=RC0                                                 
ICE084I 0 EXCP ACCESS METHOD USED FOR SORTOUT                                 
ICE084I 0 EXCP ACCESS METHOD USED FOR SORTIN                                   
ICE751I 1 EF-K49535 F0-K49038 E8-K51707                                       
ICE090I 0 OUTPUT LRECL = 240, BLKSIZE = 27998, TYPE = VBA  (SDB)               
ICE055I 0 INSERT 0, DELETE 59                                                 
ICE054I 0 RECORDS - IN: 450, OUT: 391                                         
ICE052I 0 END OF DFSORT   


All start positions have been triple-checked! What stoopid thing have I done?

Re: Multiple INCLUDE conditions not selecting all Recs

PostPosted: Wed Aug 29, 2012 2:21 am
by Akatsukami
Oddly enough, it seems to work when I cut and paste the input data and control cards from this post. Is it possible that there is a non-displayable character between "CALCULATING" and "Survival"?

(ETA: And your control cards do not match what appears in the messages. Do not re-type your code; please cut and paste, using the Code tags to preserve alignment :mrgreen: )

Re: Multiple INCLUDE conditions not selecting all Recs

PostPosted: Wed Aug 29, 2012 2:35 am
by NicC
Aaaargghh! It was ALL cut and pasted! The messages were from a final desperate attempt but I still do not have records with CALCULATING in them. No special chars - the search string was cut and pasted from the input file. It has not been my day - I overwrote the program that was to post-process the output from the above sort. Fortunately it was Rexx and easily re-written and is only extracting data from the file into a CSV file. But it can only extract if the record is there to extract from! I could nip around the corner and double-check my output but bed calls.

Re: Multiple INCLUDE conditions not selecting all Recs

PostPosted: Wed Aug 29, 2012 4:49 am
by skolusu
Nicc,

You should use VLSCMP instead of VLSHRT. VLSCMP is used for INCLUDE/OMIT and VLSHRT is used for SORT/MERGE.

VLSCMP allows all of the INCLUDE/OMIT comparisons to be performed even if some fields are short. Because short fields are padded with binary zeros, comparisons involving short fields are false (unless a test against binary zero is relevant, as discussed below). Comparisons involving non-short fields can be true or false.

NOVLSCMP and VLSHRT treat the entire INCLUDE/OMIT logical expression as false if any field is short. Thus comparisons involving non-short fields are ignored if any comparison involves a short field.

Check this link which explains the rules of VLSCMP

http://publibz.boulder.ibm.com/cgi-bin/ ... T#FIRSTHIT
 OPTION COPY,VLSCMP
 INCLUDE COND=(48,1,CH,EQ,C'>',OR,         
               50,1,CH,EQ,C'>',OR,         
               46,1,CH,EQ,C'>',OR,         
               16,14,CH,EQ,C'CALCULATING Su')

Re: Multiple INCLUDE conditions not selecting all Recs

PostPosted: Wed Aug 29, 2012 12:59 pm
by NicC
Kolusu, thank you very much - that did the trick. Whilst waiting to get logged into the forum I tried re-arranging the conditions in ascending order of key start position as I suspected that it might be due to a short record with the same results as before, naturally.

I presume it worked for Akatsukami because he cut and pasted from the post and ended up with no short records - beware the cut'n'paste :)