Re: change management software -- MIDRANGE-L

Comments in line:

----- Original Message ----- 
From: "Wilt, Charles" <CWilt@xxxxxxxxxxxx>
>
> I have 5+ years working with and administering Aldon at my previous
> position. At my new position, we recently demo'd both Aldon and Turnover.
> I'd agree with Nelson that administering Aldon is easy.  But I'd like to
> hear more about the changes Nelson wanted to make to how it worked that he
> couldn't with Aldon but could with Turnover.

My memory is a little hazy, but it seems like most of the limitations to the
things we could change were due to Aldon's strict reliance on a set library
list, or at least the libraries for the various levels.  Also, if recall
correctly, the levels were rather set in concrete too. Only three or four of
them, is that right?  In TurnOver, you can set up unlimited numbers of
levels and even shadow sets of levels for versioning, etc.

TurnOver's processing is Forms-centric. Forms seemed like a very strange
animal at first, but now I love their flexibility.  You setup a form to
process all movements from one level to another, and then run the form like
running a job. The forms are completely customizable.  They also have great
facilities for promoting test data up with forms and distributing data only
to test libraries.

A lot of the flexibility comes from the ability to create your own versions
of object types.  You can then use these pseudo-object types to do custom
things to those particular objects.  For example, in one application, we
have a need for certain high record-count files to go into a different data
library (for different backup processing) than the majority of files.  These
objects get created as *file objects with a PF2 attribute rather than PF.
The PF2 attribute is only known within TurnOver processing, but allows us to
have those objects follow completely different processing criteria.  Both
the IBM attribute and the TurnOver attribute get stamped on the object.

Another thing we are able to do is to have more than one Application share a
production library and still get along ok. As I recall with Aldon, you had
to specify a library, and it took "control" of everything in it.

As I said earlier, Aldon's set methods did make it easier to administer
because you didn't have very many choices, and it kept you out of trouble,
but it also limited your flexibility.  With TurnOver, anything goes, but
because of that you have to be a lot more careful.

> During my time using Aldon,
> about the only problems I ran into was that it seemed to be a bit behind
in
> SQL support.

I also had great tech support from both companies.

> The thing I noticed about Turnover, was that it did seem more configurable
> up front.  The green screen interface seemed considerably less cleaner and
> harder to use than what Aldon was.  What was simple to do in Aldon, seemed
> to not be so simple in Turnover.  Note: I wasn't the only one left with
that
> impression, the rest of our team including those without experience in
> either package felt the same.

You're not wrong here.  The problem is that there are so many controls and
they are scattered around in so many nooks and crannies, that is does take
some time to figure out where everything is.  After you get in to it, you
find it is sort of like RPG. There are usually 3-4 different ways to do
whatever you need to do, which just adds to the confusion. It's menu-driven,
and command-driven, and exit-point controled.  There are global settings,
and application level overrides, and project level overrides, and your own
exit program overrides. The things you can do are virtually unlimited, but
you may not want to do that much work.

> Granted a web-demo isn't the best way to eval a product.  We hope to get
> both installed at some point for a little hands on.
>
> While I'd like to see Aldon, simply because I'm familiar with it.  I'd be
> happy to get any CMS in here that fits our needs.  Biggest problem with
> Aldon at the moment is it's price.  What we're hearing is a couple of
times
> higher than Turnover's.  It seems very strange that the two products don't
> seem to even be in the same ballpark when it comes to pricing.

We also compared all three systems initially, and as I recall the prices
were close when you kept apples to apples. I too was an Aldon bigot at the
time, but TurnOver's flexibility won me over.  Of course, I like to tinker
more than most.

> Lastly, let me specifically point out that we are looking at Turnover vs.
> Affiniti.  Multi-platform is one reason, but more importantly is the WDSC
> integration for green screen RPG and for non-RPG iSeries development.

I haven't had a chance to use their WDS plugins yet, but I hear good things
about them.