Re: Ideas?

It sounds to me like Tim won't be changing any production data, just viewing
the parameters passed to a program so that he could duplicate the problem in
testing.

Recently I did an application for a customer where we voice enabled some of
his existing applications.  For instance, a caller could enter his invoice
number and hear the specific charges involved, or delivery information, etc.
That info was available from the database in one file, so it was simple to
implement.

The second phase of the app involved reading back rate quotes to the caller.
The application had to make a call to a large RPG program that accepted over
50 parms and returned the rates and other data in a parameter that was
passed as a data structure.  I debugged an existing interactive application
that performed the steps needed and put a breakpoint on the *ENTRY
statement.  Then I ran DSPPGMVAR for all of the fields that I needed to see.
I then let the program continue.

It was also very valuable to do a DSPJOB at the time and see which files
were open.

The only documentation available for this program was the comments.

Admittedly this was only an inquiry app, but I would not mind doing this to
an app that updates data.  The programmer would need to be sure that he lets
the program continue to its normal end without interrupting it so that the
data gets updated normally.

It sounds to me like Tim just wants to view a program while its running, not
change it or interrupt it in anyway.

What's wrong with that?

Art Tostaine, Jr.
CCA, Inc.
Parlin, NJ 08859

-----Original Message-----
From: Vernon Hamberg <hambergv@goldengate.net>
To: MIDRANGE-L@midrange.com <MIDRANGE-L@midrange.com>
Cc: truax@usaor.net <truax@usaor.net>
Date: Saturday, July 11, 1998 8:03 PM
Subject: Re: Ideas?


>Tim
>
>At 07:50 PM 7/9/1998 -0400, you wrote:
>>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.
>
>It doesn't sound like you're going after production data—although you could
>while in a debug session. We have a system in place (similar to what Dean
>mentioned) whereby a programmer must call help desk, who log the request
>for extra authority. Help desk executes a command called Authorize
>Programmer (AUTPGMR). Then the programmer signs on and executes a command
>called Log Command (LOGCMD). The programmer ends up at a command line
>(QCMD) with full authority until he/she exits from said command line.
>Should they not do so, the next morning (IPL in our case—don't ask), that
>user is removed from the authorization list for the LOGCMD command.
>Security auditing is activated for the user. Of course, someone needs to
>LOOK at the security audit journal! :-(
>
>The code is based on an article in NEWS/400. I can get it to you if you
>want. Contact me privately, please.
>
>I think you could get the authority you need to do your job, if you can
>present a way to create an audit trail of any activities performed under
>extraordinary circumstances.
>
>Good luck
>
>Vernon Hamberg
>Systems Software Programmer
>Old Republic National Title Insurance Company
>400 Second Avenue South
>Minneapolis, MN  55401-2499
>(612) 371-1111 x480
>
>
>+---
>| 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
+---