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: betten@xxxxxxxxxx
1-240-715-4655, tie line 268-1499
DFSORT/MVSontheweb at http://www.ibm.com/storage/dfsort/

IBM Mainframe Discussion List <IBM-MAIN@xxxxxxxxxxx> 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:IBM-MAIN@xxxxxxxxxxx] On
Behalf Of Frank Yaeger
Sent: 22 Januarie 2008 03:50 nm
To: IBM-MAIN@xxxxxxxxxxx
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) - yaeger@xxxxxxxxxx
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 listserv@xxxxxxxxxxx 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 listserv@xxxxxxxxxxx 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 listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

.

Relevant Pages

  • Re: DFSORT anomaly?
    ... DFSORT Development, Performance Lead ... the SORTIN data set should not be the same ... Elavon Financial Services Limited, trading as Elavon, is regulated ...
    (bit.listserv.ibm-main)
  • Re: DFSORT anomaly?
    ... Subject: DFSORT anomaly? ... the SORTIN data set should not be the same as ... from SORTIN need to be read before we can write anything to SORTOUT. ... I would just try changing your sort step to write a new dataset and see ...
    (bit.listserv.ibm-main)
  • Re: DFSORT anomaly?
    ... Subject: DFSORT anomaly? ... the SORTIN data set should not be the same as ... You SHOULD NOT use the same data set for SORTIN and SORTOUT for a COPY ... You can use the same data set for SORTIN and SORTOUT for a SORT because ...
    (bit.listserv.ibm-main)
  • Re: How do I find the SPANNED indicator in a VB record?
    ... SORTIN DD has an override for RECFM=V or VB, ... data set as SORTIN for a step with: ... DFSORT treated the input data set as RECFM=VS. ...
    (bit.listserv.ibm-main)
  • Re: DFSORT anomaly?
    ... from DFSORT Application Programming Guide ... the SORTIN data set should not be the same as the ... However, when we do a COPY, we can start writing to SORTOUT immediately. ...
    (bit.listserv.ibm-main)