× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.