RE: change management software

Comments in line:

> -----Original Message-----
> From: Nelson Smith [mailto:ncsmith@xxxxxxxxxxxxxxx]
> Sent: Thursday, December 04, 2003 12:17 AM
> To: Midrange Systems Technical Discussion
> Subject: Re: change management software
> 
> 
> 
> 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.

Correct, you can have from 2 to 4 environments.  Production and 
development along with an optional QA and/or Integration.  Could
you elaborate on the "even shadow sets of levels for versioning" 
comment.  I don't understand what you mean by that.  Actually, I'm
having a hard time picturing why you'd want/need more than 4
environments.

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

Yes, the forms-centric processing was very strange.  I can see how 
it could be more flexible.  But I found myself wondering if the 
flexibility was worth the complexity.  Do you have to deal with the
form every time, or is there a default form built?

Case in point would be "Emergency Checkouts"; a big issue where I'm
at now.  It seemed that you needed to take the time to setup a form
before you could do anything.  Whereas with Aldon it was a quick, 
painless process.


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

Aldon does allow custom or new object types.  Though this might 
something relatively new and I don't think it works exactly like
Turnover.  Basically, you could create a new object-type/attribute
combination and tell Aldon which commands to use for that combo.

Prior to the latest version, you needed to do this to handle SQL
defined procedures & functions.  If I remember correctly, Aldon
provided detailed instructions on how to set up SQL defined
procedures written in both SQL or external. I used the 
instructions to set up my own type(*SRVPGM) attrib(UDFSQL) for
UDF's written in SQL.

However, for the example you gave above I don't think a new
type would have been necessary.  Aldon's made quite a few 
improvements to how they handle data, just during the time I
was using the product.  Basically centered around the use of 
data libraries.  For example, the library I had defined to
Aldon as my Production Data library was simply full of empty
files.  My production data actually resided in a set of data
libraries.


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

Correct, I don't think that has changed.  Though perhaps with the
data libraries, multiple applications sharing data might work.  But
I'm not sure.  You can define an application as "shared" meaning
its objects are used by other applications.  But I ended up simply
having a single application defined since all my programs were in
one library, though data was in separate libraries.

Since I was in a small shop, that worked fine since I worked on
everything.  I can see were it might be a problem in a larger 
shop where everyone is assigned to a particular application.
Or if not a problem, then at least easier to deal with if you
only see what you work on.

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

I think that for green-screen, the prices are pretty close.  The
difference seems to be that Turnover does green-screen and PC
in one product.  To get both with Aldon, you have to buy Affiniti
which is significantly higher than their green-screen ACMS product.


Charles