Re: Test Development System Survey

Many of the problems regarding test systems on a production machine can
easily be avoided by not allowing programmers to have access to the
production libraries.  That is to say, there needs to be an automated way to
promote from dev/test to production which does not involve a programmer
manually doing MOVOBJ or variations thereof.  There also needs to be an
automated way for the programmer to request an extract from the production
database into her test database for use during testing.

Having these things automated means that you can audit significant events
(PGMX promoted July 17 2003, database extract occurred July 14 2003) as well
as have repeatable procedures that don't rely on the programmer having got
enough sleep the night before (fewer mechanical errors.)  It allows one to
implement one's own security scheme regardless of the user profile used for
development.  Finally, it allows for multiple test environments so that
multiple projects can proceed simultaneously (this can be useful even for a
one person development group, when the boss suddenly has a new 'priority
one' issue.)

There is very real pressure from programmers to retain access to production
libraries, but if the infrastructure were sufficiently robust (the
automation good enough) then this perception would go away because the
programmer can get her job done without having to summon the Powers That Be
in order to get data or promote projects.

Often, programmers use the 'but I cannot debug this unless I have access'
ploy.  Have a spare USER-class user profile attached to the production group
profile.  They can sign on with that for debugging, but that profile can't
be used for programming, as it should not have access to dev/test libraries.

I prefer it when the machine tells me that I'm making a mistake, rather than
wait 'til the end of the quarter to find out that I've manually created a
cross-library logical and inadvertently destroyed 3 months of invoice
records.
  --buck