RE: Ideas? -- MIDRANGE-L

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
+---
+---
| 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
+---