Re: Change Control

[PaulMmn <PaulMmn@xxxxxxxxxxxxx>]

Before we invested in the Aldon CMS package, we had our own Install 
procedure.  The heart of our system relied on a few key items:

- authority to update production source and programs revoked from programmers
- only a 'gatekeeper' (in our case the security officer) had Change 
access to production programs and source
- programmers had only Read access to production data.  This allowed 
them to read the files to check for problems &c.
- programmers had Read access to production source (ie the ability to 
copy source code to the source files in their own libraries.
- Testing was -never- done in the production files!!!!!!!!!!
- Once ready to go live, we had a program that performed the Install.

We had a few key commands that we built to make the Install process work:

The ARCHIVE command.  This works just like a MOVOBJ, but if the 
object already exists in the destination library, the destination 
copy is renamed out of the way before the move.  We allowed for 3 
prior versions:  the original, FRED, was renamed as FRED$$$$$$, which 
became FRED###### then FRED@@@@@@.  (If you list the library, the 
names show in 'age sequence.'

A similar ARCHIVESRC command to do the same thing with the source members.

Both commands check for existence of members, files, destination 
library, destination source file, etc. etc.

Then there was the wrapper to archive the old source/obj to a backup 
library, archive the new source/obj to the production library, etc. 
etc.

There was no 'checkout' procedure per se; we relied on the 
programmers 'knowing' who was working on what objects.  The 'checkin' 
procedure through a gatekeeper was the main control we were 
interested in.

Although the process isn't used for much anymore, the ARCHIVE 
commands still get used from time to time.

Of course, it worked best when everything worked fine.  We kept 
adding more error checking as we went along.

--Paul E Musselman
PaulMmn@xxxxxxxxxxxxxxxxxxxx