---------------SNIP-----------------.
> 
> Things have, of course, changed a lot for both products in
> 10 years.
> I never understand why you think what happened 10 years ago
> is relevant
> today.

A lot of my experience stands. I still talk to other sysprogs and they are 
fighting the same battles we did back then. Not too surprising (in this context 
I had a friend call me up 2 weeks ago and asked me about issues in the 
conversion process. He told me I was spot on in everything that I said. He 
asked me to send the document that we used for justification to go to DFSORT. I 
said sure just make sure you attribute the thing to me that I had in the paper. 
He said not a problem. Last week he called up again and said the document went 
over well with his management and they decided to go with DFSORT. I suggested 
that if there was a great use of synctool to go slowly and make sure the output 
was the same as the the output to ICETOOL. Yes he did run into some issues but 
nothing major and doing some small changes they were then made compatible. 
So I do experience real life and people learn from my experience and it didn't 
cost the company anything (but a few phone calls).

Frank of all the people to pipe up I am surprised as I have always said good 
things about DFSORT. If I said anything bad (I reread it) and couldn't see 
anything negative. If all you have to say are unkind words I will to 
re-evaluate the sort issue.   
> 


> > Syncsort sorts a little differently than DFSORT in
> some cases. This
> > showed up with any records with equal keys. IIRC
> syncsort sorted
> > them FIFO and DFSORT sorted them equally. We resolved
> this issue
> > with the EQUALS install option.
> 
> Both products have EQUALS and NOEQUALS options. 
> EQUALS guarantees
> FIFO order.  NOEQUALS does not.  The difference
> you saw was probably
> due to different default installation settings and can
> easily be
> handled by setting the same installaion default for both
> products.
> That was true then and it's true now.

No where did I say it wasn't an option, just that we had to turn it on for 
DFSORT to get the same exact output with SYNCSORT. It appears there is nit 
picking going on where non is needed, IMO. 
> 
> > ...
> > One thing that I really liked about SYNCSORT is that
> you could
> > override any sort parameters with a $ortparm dd
> statement. I used
> > that quite often debugging sorts invoked by cobol. I
> do not remember
> > off the top of my head if DFSORT ever came up with a
> similar option,
> > memory says maybe but check the books to make sure.
> 
> DFSORT has had the DFSPARM DD statement since 1988 for that
> and also
> supports $ORTPARM as an alias of DFSPARM.

I thought so thanks for confirming it. 

Its basically a good option do not down play it. I did send the reader to the 
books so I did NOT mislead. Again I think you are nitpicking where you should 
be happy with it. Chill out.

Ed




      

----------------------------------------------------------------------
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

Reply via email to