Re: change management software

Charles,

See below...
----- Original Message ----- 
From: <CWilt@xxxxxxxxxxxx>
To: <midrange-l@xxxxxxxxxxxx>
Sent: Friday, December 05, 2003 10:34 AM
Subject: 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.

We generally use four levels. Developement, Integration, QA, Production.
However, on one application recently, we had a need (demand?) for a fifth
level in between QA and Production, for a "User Testing and Acceptance
Level".  To set that up only required defining the level and what libraries
it should use.

The Shadow sets (that's not the correct terminology for it) we use for
controlling different versions of the same application.  While Version 3 is
in production, Version 4 is in development.  Version 3 is always needing
"maintenance" changes, while Version 4 must keep up with any of those
"maintenance" type changes while at the same time adding new features not
supported in Version 3. Each version has the same four levels designated,
but after objects are promoted thru QA in Version 4 they remain in a
"Holding" level until the entire new version is ready to go into production.
At that point, Version 4's Production level overlays Version 3's Production
level and a new Version 5 set of can be set up to start shadowing the
maintenance changes in Version 4.  It's easier to envision when you see all
the levels laid out in front of you.

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

All forms are run-once and they become nothing more than historical
documents.  However, it is easy to copy one to create a new one and most of
the forms creation stuff is rather automatic.  The flexibility comes from
the fact that each object becomes a line item on a form and you then go in
and add any sort pre or post run commands to each object or the form as
whole.  In real life, however, if you stick to doing things the way the
application was designed to run, you rarely need these extra commands.

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

It's pretty much up to you how you want to design the system to handle
emergency situations.  We chose (it's an option) to allow object to only be
checked out in one application, by only one programmer, and in only one
project at a time.  The only exception to this is the emergency system we
set up which is only available to "Team Leaders" (project managers) and not
to programmers.  This is mostly for "middle-of-the-night" stuff.

A Team Leader can check out an object and it goes to a special emergency
development environment where it is worked on and upon promotion it bypasses
Integration & QA and goes directly to an overriding production area on the
production boxes. These libraries are higher in the user's libraries library
lists, so new users see the new version immediately, while users who were
already in a program continue to use the old version.  A process at night
"sweeps" everything in the temporary area into regular production.  (We
don't allow files to use this process, BTW.)

Meanwhile, back in the regular applications, TurnOver puts a "hold" on the
objects that just got changed in emergency and they are not allowed to go to
production until the programmer "signs off" that they have incorporated the
emergency changes.  Like I said, each detail of this scenario is optional
and things that we have chosen to set up for our own protection. TurnOver
just offers the environment, but you don't have to do anything in a manner
dictated by them.  If I recall correctly, with Aldon, you had no choice but
to do everything their way.  That may not be bad, since they probably have
more experience at doing it than you do and they will keep you out of
trouble.  I'm just one who likes the flexibility of being able to do it "my"
way (although, I have been burned a few times).

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

All in all, I would favor Aldon if you can enforce strict guidelines with
your developers (which is something I was not allowed to do) and you don't
mind following Aldons methods and you want the administration to be cut and
dried.  If you like writing a lot of special exit programs, and doing
exception processing,  and doing things your own way, go with TurnOver.  All
this is from an administrator's view, of course, and the developers might
take exception.