--- On Fri, 1/30/09, Mark Zelden <[email protected]> wrote:
Date: Friday, January 30, 2009, 2:29 PM
> On Fri, 30 Jan 2009 12:18:25 -0600,
> Lupher, Fred <[email protected]>
> wrote:
>
> >We are a long time Syncsort customer. Our
> contract with them will be up
> for renewal soon, so this is a good time to consider the
> competitors. Does
> anyone have experience migrating away from Syncsort you'd
> care to share? Or
> if you looked into switching but decided not to, I'd be
> interested in
> knowing what stopped you?
> >
I have done a couple of conversions but that was more than 10 years ago so
anything I write could be out of date so take it for what its worth.
During various conversions we ran into some interesting (yet small IMO)
differences.
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.
The other thing that stopped most people from converting (one way or the other
way) was that SYNCSORT's language was slightly different than DFSORT. The
"language" I am talking about is the reporting language (forgot the name it
been so long). One of the issues in this was that SYNCSORT would come up with
something and it would take DFSORT a few months to do the same it was a leap
frog type environment so a programmer could do something in SYNCSORT and it may
or may not be available in DFSORT. At one installation we discouraged the use
of the language so it was pretty trivial conversion. At one time DFSORT was
cheaper but SYNCSORT used less resources. Once they became equal as far as
resources we went DFSORT.
This is a personal observation and no grounds to prove it. Both support teams
were good but the issue with SYNCSORT (again this was 10+ years ago)
was that they sent zaps out and you had to key in the zaps by hand. This was
prone to errors and IIRC they used checksum (superzap ) to verify the zaps were
coded correctly. The side issue was that at times a module had so many zaps on
it that you had to relink the module by hand to accommodate the zap (extra
IDRDATA). IBM sent out module replacements that made SMPE work easy to do. It
was a little bit easier to figure out what was on (maintenance wise) with
DFSORT. Again this is old information.
Both products work well and at least (again 10+ years ago) performance wise
DFSORT narrowly beat SYNCSORT . I am trying to think back if we ever had to
call the syncsort people in the middle of the night and I cannot remember doing
so (if we did the support must have been OK or else I would have moved to get
us off SYNCSORT sooner.
A long time ago SYNCSORT was really fast and efficient and it would beat the
pants off of DFSORT but the DFSORT people equalled and maybe a little bit
surpassed SYNCSORT.
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.
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
