In <[log in to unmask]> [log in to unmask] writes:
 
> We've been directed to restrict programming staff's access to
> production data to read-only if possible.  The only method which makes
> sense to me - sure it's brute force, but it should work - is to create
> a separate account for them and allow Read and Lock access to the
> production accounts and selected groups within those accounts.
 
[snip]
 
> Can anyone shoot holes in this scheme?  Please feel free to do so, but
> only if you can offer a reasonable alternative!   :) :)     Thanks!!
 
Having been through this myself a couple times (and doing exactly that for
a number of years) we found in the end it was much more reliable (and can
even be cheaper) to buy a separate development machine (and only buy/maintain
the compilers/development tools on that machine vs. the larger production
system). If you're running on a real large 3000, then the cost difference
for one or two compilers might pay for a used 917/918 system (which can be
had for under about $8k if you shop around).
 
When we were battling the programmer accounts on the same system, it seemed
we were constantly battling programmers trying to get into data "quicker"
than going through "channels"; code getting rolled into production accounts
with hidden references to files/groups in the "development" accounts; and
of course you have to battle the cpu/machine resources of programmers doing
compiles while payroll (or whatever your critical apps) are trying to get
done. And every now and then, someone would "somehow" "accidentally" release
a production database, and a test program would get hold of it and wipe out
hours (or days) of live data. It just wasn't worth it.
 
             -Chris