Re: Change Control -- MIDRANGE-L

I used to work at a shop where one of our managers used the "Load and
go!" style of testing--  program, compile, install, run live.
AARRGGHH!

The issue is not one of trust-- if we didn't trust our programmers,
they wouldn't be here!  The issue is the OOPS! factor.  (One OOPS
cancels out 20 ATTABOYS!).

Before we started paying for a 'real' Change Management System, we
had our own Cheap 'n' Dirty system:

1) Create a test environment, where the production environment is
duplicated 100%.

2) Each programmer needs to have a personal library, with a complete
set of source files.

3) Create a set of commands to migrate the objects and source to
production.  We created 'Archive' commands.  One works like the
MOVOBJ command, but if the object already exists, the old object is
renamed and left in place; the new object takes its place.  Another
does something similar, but for source file members.  These 2
commands handle the bulk of daily changes.  (We used a series of
renames--  we tack on $$$$ or #### or @@@@ to the name (if it's
already 10 characters, the last position is overwritten); this gave
us 3 prior versions for safety)

4) Lock down the production libraries-- Users can do what they want,
but Programmers can only read the live files and the live source
code.  They need to be able to see the data, and copy the source code
to their library for

5) moving PF and LF to production will be a problem!  You have to
handle the data, and any LFs already in place.

6) You may want to give the commands in #3 the right to automatically
install something in production, or you may want to restrict its use
to a particular person.

Once your programmers are brought (kicking and screaming) into
compliance, it's not as bad as they fear!  Granting them read rights
to the production files should alleviate the fear of not being able
to  do their work.  Plus, being able to -test- without fear of
damaging things accidentally (the OOPS! factor) should make things
easier, not harder.

Even now, with a commercial CMS system, there are times when we sign
a programmer on to the production environment when they have a number
of data changes to make (Yes, I know-- if we did it the right way
we'd make them write a program to patch things--- or make them write
code that never mangled live data.     (:    )

Of course, to create a test environment you'll need more disk space....

--Paul E Musselman
PaulMmn@ix.netcom.nospam.com



>In a message dated 6/3/02 3:55:00 PM Eastern Daylight Time,
>hsanchez@driscollchildrens.org writes:
>
>
>>  I work for a Children's Hospital in South Texas.  We are a pretty small shop
>>  as far as the AS/400 goes.  3 programmers and 2 operators.  I used to work
>>  for our Electric Utility and in a much bigger shop.  None of the
>>  Programmers/Analyst had Security Rights to Change Live Objects, Source Code
>>  or Files.  Everything was done in Test and we had someone in charge of
>>  Change Control to move everything over once we got the proper signatures.
>>
>>  Recently we had an I/S audit and the auditors are requiring us to use some
>>  form of Change Control.  The other 2 programmers are very much against this
>>  and so far we have avoided doing such.  So my question is this, are most
>>  400 shops small and dont do Change Control, or are we unique in not doing
>  > so?