RE: change management software -- MIDRANGE-L

"Form" is just a term, if we had called it "Promotion Request" or "Job" 
would that have made it more obvious or less confusing?  Form was an apt 
term in 1989, as this stuff was often done with paper forms given to a 
code librarian   :)

Typically you never look at the form, you just select the items you want 
to promote, which creates the form, and then you run/schedule the form. 
The form is simply a database/mechanism for identifying what you want to 
promote.  No matter what the product, there has to be some way of 
communicating what you selected in the UI, and what the batch job 
processes.  Most likely all of the products use a database for that, we 
simply expose the database and take advantage of it.

The form is a permanent audit trail for the promotion
It allows you to very easily see what happened or is going to happen 
during the promotion job
You can insert commands, such as OVRDBF, or CRTDUPOBJ, or CALL a database 
conversion routine at appropriate points in the promotion job

The form makes it easier for role/responsibilty based workflow, if you 
desire it.  The developer, who has the real knowledge of the change can 
create the form, inserting the OVRDBF commands or data conversion CALL's 
as appropriate.  The form can then be routed to project leader for 
approval.  They can easily see the details of what will be done if 
desired.  Upon approval, the form can then be actually run by an 
operations staff.

All that being said, it would be just as likely to have a developer just 
create and run the form all at once without doing any of this.

Finally, subsequent promotions for the same request such as from QA to 
Production can just copy that form and run it again.  So if any special 
steps were added, like commands, they can be copied forward.  We can also 
leverage that information and remember it in the future for other 
developers and their changes.  Likewise, commands like an OVRDBF are 
typically "captured" during the development phase and automatically added 
to the form.  So even then, it is usually not needed to edit the form. 
Finally, any dependent objects that need to be recompiled or rebound such 
as ILE programs or service programs are also added to the form 
automatically, but also with that visibility of what will be done. 

If you have any further questions, feel free to email me offline.

Mark Phippard
Director of Development
SoftLanding Systems










CWilt@xxxxxxxxxxxx
Sent by: midrange-l-bounces@xxxxxxxxxxxx
12/05/2003 10:34 AM
Please respond to Midrange Systems Technical Discussion
 
        To:     midrange-l@xxxxxxxxxxxx
        cc: 
        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.

> 
> 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
_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.