RE: Ideas?

WARNING!   WAR STORIES FOLLOW....

Walden, here's how I see it (IMHO):

1) Pgmrs should have read but don't touch rights to production objects.
It's not a matter of trust.  I don't know how many times the 'oops' factor
creeps in.  Like the time I had a test subsystem, QINTERPEM running.  Then,
while talking to someone, I ended subsystem QINTER.  OOPS!  It wasn't what
I -intended- to do, but it happened anyway.  (I tend to hesitate over that
last 'Warning' screen these days...)

2) 3 AM problems?  Well, I have given out a god-like password now and then.
And I've un-installed programs that I've been assured will "work just
fine."

3) Is a test data base worth the cost?  YES!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
I also have a firmly held belief that the test database does NOT have to be
a 100% clone of the live data!  You need 'typical' data, plus the
exceptions you've collected over the years (you know-- the ways the user
'tested' the system that you never counted on...).

4) If the bad data isn't in the test database?  One place I worked we had a
'grabber' program.  Feed it the order number, and it grabbed part master,
product structure, the order, and other information so you could run tests
on the bad data.  *sigh*  You need time and dedication to the idea to make
such a program a reality.  However, if you build it, they will use it.

I agree that you have to trust the programmers.  But between the oops
factor and the auditors you need to have a way to keep the programmers out
of the live data.  It's an issue of control; the 'need to know.'  As much
as you trust people, there are some who will take advantage of that trust.

One time we were installing a new system, and the word came down from the
head of IS:  "Let the programmers have full access to the production
system.  It takes too long to get things into production with your
'install' process."  We got that in writing.  What a mess!  We didn't have
any Change Management System in place, and programmers had no idea who was
working on what program (let alone what version of the code was supposed to
be 'live.').  There were multiple programmers changing the same live
programs, users who had no idea that things were being changed, data was
being scrambled and rebuilt.  AAARRRRGGGHHHH!!!

Never again!  We installed a change management system, locked down security
on the production data bases, and kept the programmers in their own
playground where they can't hurt anything.  It's NECESSARY.  Inexcusable to
do otherwise.

*whew*

Now...  ask me how I feel about RAID.  (:

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


>Paul,
>
>While in general I would agree with you, I have a couple questions.
>
>1) How do you handle cases where data the programmer needs is not
>available on the users screens? (Surrogate keys, audit stamps, journal
>receivers, etc.)
>
>2) How do you fix a problem at 3AM?
>
>3) If you have an image of the database for testing on another machine
>is it worth the cost of 150Gig of disk?
>
>4) If you have an image of the database for testing, what if the "bad"
>data that is causing the problem is newer than the image of the
>database?
>
>I've never found a good solution to these problems. As I see it if I
>can't trust my programmers with my production data why am I employing
>them? Anyway, if they wanted to cause trouble they could always write a
>logic-bomb and drop it into the order entry programs, I'd never know. I
>don't have time to review every changed line of code.
>
>-Walden
>
>-----Original Message-----
>From: PaulMmn [mailto:PaulMmn@ix.netcom.com]
>Sent: Thursday, July 09, 1998 9:43 PM
>To: MIDRANGE-L@midrange.com
>Subject: Re: Ideas?
>
>
>I'm afraid you won't get much sympathy from me.
>
>Programmers SHOULD NOT be able to do much to a production data base.  I
>feel they should be able to read production files (with proper controls
>over sensitive data like Payroll).  They should NOT be able to update
>production files using programmers' tricks or DBU.
>
>If a programmer has any access to a production data base, it should be
>via
>a *USER profile, just like every other user.  This does limit
>programmers'
>playing to using the proper menus and interfaces and controls built into
>the production system, but it's never a good idea to let programmers run
>things that they can program loopholes in.
>
>How -should- testing be handled?  Ideally, you should have a complete
>copy
>of the production environment on a test machine so that -you- can run
>the
>programs, watch yourself do things, and never, Never, NEVER risk damage
>to
>the production data base!
>
>Do you -really- want a user running a program that needs fixing?
>
>--Paul E Musselman
>PaulMmn@ix.netcom.com
>
>-=-=-=-=-=-=-=-=-=-
>
>>Hi folks;
>>I got a question concerning my current programming job.  Here's the
>>scenario:  I am assigned a program that requires fixing, and this
>>program is maybe 4 CLP's and 5 RPG programs deep into CALL's, therefore
>>knowing exactly (dspjob info) the files it is accessing and any
>>variables in a program *ENTRY PLIST is very helpful and a valuable time
>>saver as well as an error preventer.  Normally what I would do is this:
>>a) Have production user sign on to the system.
>>b) Identify the name the AS400 has assigned to this users job.
>>c) Then I would do the STRSRVJOB command on this job.
>>d) Then a STRDBG on the specific program I wanted processing to stop
>on,
>>for my brief (information) collection.
>>e) I would then allow the user to progress to the program area I wanted
>>to look into.
>>e) At program stop time I would view the PARMS in the *ENTRY PLIST of
>>the program and the actual files the program was pointed at.
>>Well guess what!  Programmers at this company are not AUTHORIZED to do
>>this on a production machine, this has me floored!
>>
>>I would appreciate any suggestions my fellow-list-people would offer me
>>to somehow circumvent this perplexing problem.
>>Thanks very much in advance.
>>
>>----
>>Tim & Dana Truax... and Caleb 4 years old.


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---