Thanks, This way I will not have to impact the jobs lower down the stream...
Regards Herbie -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David Betten Sent: 22 Januarie 2008 04:36 nm To: [email protected] Subject: Re: DFSORT anomaly? I would change the dataset names instead of changing the copy to a sort. Today, probably not much difference but if the file size grows over time, the copy is going to be faster and require less resources than a sort. I'd change the following Add a DD5 to your initial DEL005 step with a new data set named something like PECT.TBC.SE.ALC.TEMP.IMPOUT Change NCP0511 step to create PECT.TBC.SE.ALC.TEMP.IMPOUT Change IDCAM020 step's FILEIN to PECT.TBC.SE.ALC.TEMP.IMPOUT Change SORT01 step's SORTIN to PECT.TBC.SE.ALC.TEMP.IMPOUT You could also add another BR14 step right after the SORT01 step to delete the TEMP.IMPOUT if you want to avoid that extra copy occupying space. Have a nice day, Dave Betten DFSORT Development, Performance Lead IBM Corporation email: [EMAIL PROTECTED] 1-240-715-4655, tie line 268-1499 DFSORT/MVSontheweb at http://www.ibm.com/storage/dfsort/ IBM Mainframe Discussion List <[email protected]> wrote on 01/22/2008 11:04:26 AM: > Thanks to everyone for replying to this. I am definitely going to get > the apps guys to change the JCL. I just haven't whether it would be to > change it to a sort, or create a second dataset. Will read the > recommendations between the lines of the DFSORT manual... > > Regards > > Herbie > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Frank Yaeger > Sent: 22 Januarie 2008 03:50 nm > To: [email protected] > Subject: Re: DFSORT anomaly? > > David Betten wrote on 01/22/2008 06:53:52 AM: > > I haven't seen any job output yet but I wanted to share this > information > > from DFSORT Application Programming Guide > > > > *** > > For a copy application, the SORTIN data set should not be the same as > the > > SORTOUT data set or any OUTFIL data set because this can cause lost or > > incorrect data or unpredictable results. > > *** > > > > Frank probably knows more about this but it makes sense to me why we > could > > have problems for COPY. When we do a SORT, all of the records from > SORTIN > > need to be read before we can write anything to SORTOUT. This is > because > > that last record read could potentially be the first record written. > > However, when we do a COPY, we can start writing to SORTOUT > immediately. > > I would just try changing your sort step to write a new dataset and > see > > what the results are. > > Dave has it right. I just got here and was going to write a similar > post. > You SHOULD NOT use the same data set for SORTIN and SORTOUT for a COPY > for > the reason Dave states that we are doing parallel read/write. Depending > on > how the data is arranged, you may get away with it, but you're taking a > risk. > We can't guarantee that you won't lose records. So just don't do it. > > You can use the same data set for SORTIN and SORTOUT for a SORT because > we > don't do parallel read/write. This is commonly known as a "suicide > sort" > because the "input" data set is overwritten so if something goes wrong > (e.g. an I/O error) you don't have the input data set anymore. So you > would want to be sure you have a backup for the input data set if you do > a suicide sort. > > Frank Yaeger - DFSORT Development Team (IBM) - [EMAIL PROTECTED] > Specialties: PARSE, JFY, SQZ, ICETOOL, IFTHEN, OVERLAY, Symbols, > Migration > > => DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort/ > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > Elavon Financial Services Limited > Registered in Ireland: Number 418442 > Registered Office: Block E, 1st Floor, Cherrywood Business Park, > Loughlinstown, Co. Dublin, Ireland > Directors: Robert Abele (USA), John Collins, Terrance Dolan (USA), > Pamela Joseph (USA), Declan Lynch, John McNally, Malcolm Towlson > Elavon Financial Services Limited, trading as Elavon, is regulated > by the Financial Regulator > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Elavon Financial Services Limited Registered in Ireland: Number 418442 Registered Office: Block E, 1st Floor, Cherrywood Business Park, Loughlinstown, Co. Dublin, Ireland Directors: Robert Abele (USA), John Collins, Terrance Dolan (USA), Pamela Joseph (USA), Declan Lynch, John McNally, Malcolm Towlson Elavon Financial Services Limited, trading as Elavon, is regulated by the Financial Regulator ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
