Re: What goes where?

We keep program source in our test system, and use Aldon (change management
system) to compile objects and "promote" them to the production system. This
includes, but is not limited to, programs, modules, service programs, QMQRY
objects, source file members for RUNSQLSTM, commands, UIM help and menus,
etc.

Our rationale for not having source in production is due to Sorbanes-Oxley
and internal/external auditors, to "ensure" programs are compiled (and
tested) in the test system then promoted to the production system. We have a
monthly audit report of objects created in production, and must account for
them. (System-generated and transactional-based objects are excluded from
reporting.)

We usually have enough joblog information to make debugging unnecessary, or
to recreate in test if step-by-step debugging is required. The
DBGVIEW(*LIST) compilation flag can be used if debugging is absolutely
required in production.

--Loyd

On Wed, Jun 30, 2010 at 3:29 AM, David FOXWELL <David.FOXWELL@xxxxxxxxx>wrote:

-----Message d'origine-----
[mailto:midrange-l-bounces@xxxxxxxxxxxx] De la part de rob@xxxxxxxxx
Objet : Re: CPYSRCF SRCCHGDATE

Do what we do. Don't keep source on your production lpar.

Hey I've been thinking this over from time to time and I'm a wonderin':

Where then do you keep your production source?
What do you actually push on to the prod lpar? Just objects? What about
modules?
What's the point of DSPOBJD to get the source member used to create the
object? Can it be easily found?
Aren't there any issues with debugging? Aren't the source files needed?

Any more fors and againsts for separating source and objects in this way?

Thanks.