Unless the physical location of the R, V and Z are already discreet from the other data, this will give you different output (records will be in a different order).
On what you have:
Code:
INCLUDE COND=((5,1,CH,EQ,C'R',
OR,
5,1,CH,EQ,C'V',
OR,
5,1,CH,EQ,C'Z'),
OR,
(17,1,CH,EQ,C'2',
AND,
18,6,Y2T,GE,Y'DATE1'-750))
Swapping the test of 5.1 removes the need for negation of that test in the other "leg". Why do the date test, and only then check a simple one-byte value? So reverse, only do the (more complex) date-checking when you know the rest of the test is true.
The test for three values on the same position can be simplified with SS, but...
Last edited by William Collins on Thu Mar 05, 2015 2:33 pm; edited 1 time in total
In the original first step, there are two OUTFILs each with an INCLUDE=.
First OUTFIL gets just the R. V or Z irrespective of anything else.
Second OUTFIL does the date and 2 selection, but wants to ignore the R, V or Z.
I have only just noticed the names of the OUTFILs
And the SUM FIELDS=NONE on the subsequent COPY step...
So I could have missed anything
The two OUTFIL DSNs are then concatenated. Effectively "sorting" all the R, V and Z to the beginning of the output file, which will include stuff which satisfies and date and 2 checking, followed by non-R, S, V which matches the date and 2 checking.
In one step, that order cannot be produced unless the data on the original input is in that order.
But, the same selection can be done. If it is R. S or V, use it, otherwise if 2 and date, use it.
I've run the original, the new, and my version (correcting the original missing comma, now edited in original) and they produce the same output (all records selected) in the same order (since your data allows for that).
If you are trying to reduce resource use, you could consider just concatenating your two files each time you need the one logical file, rather than copying to one, and rather than dealing with the change in order.
Joined: 26 Nov 2002 Posts: 12376 Topics: 75 Location: San Jose
Posted: Fri Mar 06, 2015 12:11 pm Post subject:
Magesh_J wrote:
Code sugested by you is workng good. Only once challenge we have is records are not in same sequence.
Magesh_J,
If you are just writing to a single output file, I don't think the sequence of the records change. Are you seeing a different sequence when writing to a single file? _________________ Kolusu
www.linkedin.com/in/kolusu
I think i miss communicated, In Current jcl when we compare sortout1 and sortout2 with single sort condition, the sequence mismatch. i.e. current jcl sortout1 and sortout2 will have different sequence of records, when compare to single sort condition.
also please advise why sortout1 and sortout2 should not be used ?
Joined: 26 Nov 2002 Posts: 12376 Topics: 75 Location: San Jose
Posted: Mon Mar 09, 2015 10:47 am Post subject:
Magesh_J wrote:
Kolusu,
I think i miss communicated, In Current jcl when we compare sortout1 and sortout2 with single sort condition, the sequence mismatch. i.e. current jcl sortout1 and sortout2 will have different sequence of records, when compare to single sort condition.
Magesh_J,
Ideally I would remove the 2 OUTFIL processing and go with a single step using INCLUDE COND. By doing so you are avoiding the out of sequence issue as well avoiding multiple passes of data.
Magesh_J wrote:
also please advise why sortout1 and sortout2 should not be used ?
Magesh
I don't remember giving any such advise. You can use them without any issue. _________________ Kolusu
www.linkedin.com/in/kolusu
Joined: 26 Nov 2002 Posts: 12376 Topics: 75 Location: San Jose
Posted: Tue Mar 10, 2015 12:07 pm Post subject:
Magesh_J wrote:
Thanks Kolusu,
Could you please advise,is there any option parameter we can pass to below sort step to improve CPU.
Magesh_J,
Is there a reason that you chose RECORD TYPE=V ? According to your Listcat info your AVGLRECL is 80 and all of your Include condition fields are within that range. Do you need the Output file to be VB?
Can you try running the following control cards? I changed the control cards to read the VSAM file as RECORD TYPE=F which is the default and adjusted the positions of the INCLUDE condition to remove the RDW length.
Code:
//SYSIN DD *
OPTION COPY
INCLUDE COND=((1,1,SS,EQ,C'R,V,Z'),
OR,
(13,1,CH,EQ,C'2',AND,
14,6,Y2T,GE,Y'DATE1'-750))
also please advise why sortout1 and sortout2 should not be used ?
That was me misremembering the manual. Sorry.
I'd still not do it personally, too much tendency for the next reader to think it is something "official" when they look at the JCL
It looks like your KSDS has been read lots of times sequentially. I hope that is not your testing. If not, it would look possible that making it a flat file early would give benefit.
Make yourself a large-ish file with small fixed-length records, then test my INCLUDE against yours.
Where are the usage stats for your index component?[/list]
***************************
*******************************************************************************
*
END TERMINATION REPORTING *
HH.MM.SS.TH MMM.THT *
CPU SERVICE 8,537,771 JOB VECTOR TIME 00.00.00.00 *
SRB SERVICE 27,298 INIT VECTOR TIME 00.00.00.00 *
MSO SERVICE 0 CPU TCB TIME 00.06.58.78 6.979 *
I/O SERVICE 52,600 CPU SRB TIME 00.00.01.34 0.022 *
TOT SERVICE 8,617,669 CPU TIME 386.285 *
*
*******************************************************************************
SDSF OUTPUT DISPLAY JOINKEYS JOB06571 DSID 102 LINE 9 COLUMNS 02- 81
COMMAND INPUT ===> SCROLL ===> CSR
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 - 10:45 ON MON MA
OPTION COPY
INCLUDE COND=((1,1,SS,EQ,C'R,V,Z'),
OR,
(13,1,CH,EQ,C'2',AND,
14,6,Y2T,GE,Y'DATE1'-750))
SDSF OUTPUT DISPLAY JOINKEYS JOB06571 DSID 4 LINE 31 COLUMNS 02- 81
COMMAND INPUT ===> SCROLL ===> CSR
*
* UNIT-T-DDNAME------EXCP CNT---MB TRANSFER UNIT-T-DDNAME------EXCP CNT---MB T
* A655 SORTIN 40,060 619.968 A65C SORTIN 39,716
* 2565 T SORTOUT 157,258 5,151.772
*
* EXCP TOTAL 258,794 TOTAL DASD MB TRANSFERS 1,
*
***************************
*******************************************************************************
*
END TERMINATION REPORTING *
HH.MM.SS.TH MMM.THT *
CPU SERVICE 7,846,286 JOB VECTOR TIME 00.00.00.00 *
SRB SERVICE 48,143 INIT VECTOR TIME 00.00.00.00 *
MSO SERVICE 0 CPU TCB TIME 00.06.24.86 6.414 *
I/O SERVICE 129,497 CPU SRB TIME 00.00.02.36 0.039 *
TOT SERVICE 8,023,926 CPU TIME 356.048 *
*
I see another job using the same file, with different include condition.
So i have thought, if we include the same here, then read once, write into two files will save lot of cpu, If that is the case, i think we need to use OUTFIL FNAMES= and INCLUDE as follows. Please advise
But in prod for below code it is taking it as Variable. Please advise in what way it is considering VB/FB
Code:
ICE250I 0 VISIT http://www.ibm.com/storage/dfsort FOR DFSORT PAPERS, EXAMPLES A
ICE000I 1 - CONTROL STATEMENTS FOR 5694-A01, Z/OS DFSORT V1R10 - 21:06 ON FRI M
SORT FIELDS=COPY
OUTFIL FNAMES=SORTOUT1,
INCLUDE=(5,1,CH,EQ,C'R',OR,5,1,CH,EQ,C'V',OR,5,1,CH,EQ,C'Z')
OUTFIL FNAMES=SORTOUT2,
INCLUDE=(18,6,Y2T,GE,Y'DATE1'-750,AND,17,1,CH,EQ,C'2',AND,
5,1,CH,NE,C'R',AND,5,1,CH,NE,C'V',AND,5,1,CH,NE,C'Z')
ICE201I H RECORD TYPE IS V - DATA STARTS IN POSITION 5
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
FAQ
Search
Quick Manuals
Register
Profile
Log in to check your private messages
Log in
