Re: DSP PGM REF Opposite

Thankyou very much for spelling out step by step how to do something that I 
was not familiar with. 

You say that when the user & software actions reach the program, that I am 
interested in, the job will halt.  Several users are running ORD590 several 
times a day foir rather urgent business.  After I get the info needed from 
call stack, can I cause the halted job to continue running, so that we can 
get the info we need without disrupting daily chores for more than a few 
minutes?

I assume that if I locate GO CMDTRC & look at F1 on several options I will 
see if the trace info can be printed & be meaningful.

I expect I will send the DSP PGM REF *ALL to an *OUTFILE with query against 
selected "called" as someone suggested ... I have created quite a few 
*OUTFILE queries in recent months & feel comfortable with that process.

Several people suggested HAWKEYE but my inability to communicate effectively 
with my management means that I settle for them understanding what I am 
proposing from a policy perspective or why this or that problem occurred & 
our options for dealing with it.  What tools would do the best job in gaining 
superior ROI from our computer infrastructure requires a depth of technical 
understanding outside their job descriptions and is one of many reasons 
(Security time bombs being another) why I periodically push for us getting a 
total computer audit.

Sometimes I have many alternative directions I could go in & unsure which is 
best & sometimes have frustration like led to this post - am I using the best 
tools avaiable.

Your thinking might be applicable to another problem we been having.
Far too frequently this scenario repeats.
We have user tasks that are run many times daily
Sometimes one of these tasks encounters a problem but no one seems to notice.
User signs off normally obvlivious to the problem & no joblog
I kill all job logs after backup unless there is a known problem
2-3 days later we find out that there was a problem
playing detective is with woefully inadequate clues

Ideally what I want for the user tasks that seem most susceptible to this 
scenario
is a spool file report every time they run which we would hold a week then 
print only if find out that thre was a problem
& also print to study if I ever have a slow day
The report would show path of which program called what other programs, what 
files getting output by this, and what responses to what messages, so we can 
see at what point something broke, & what triggered it.

We use BPCS 405 CD & we had run into a problem with ORD shipping documents 
(detailed in a BPCS_L thread specific to the shipping documents process, 
where I was looking for clues from other folks familiar with the application 
as to what might be causing our problem) in which we are now using an 
unelegant work around but when I locate where ORD561 is called I can do 
Overide PRTF on it and solve problem the way the users want it solved.  
ORD561 is only one problem in a larger collection, but it will resolve a lot 
of our difficulties.

The *OUTFILE approach will also be useful in another mild crisis that has 
erupted.  We have determined that labor transactions get corrupted in the 
inventory update flow when there is a very unique combination of 
circumstances, involving more than one shop order in concurrent production on 
the same item, & this JIT620 job stream has a depth comparable to the ORD 
investigation, in that I need to figure out what programs are called in what 
sequence & which ones in the string update a particular file (the one that 
gets corrupted leading to bogus inventory transactions from a later program). 
 

Now I may be able to get that same info from DSP PGM REF but it is so tedious 
one level at a time, and while sometimes it says this or that file is only 
read but not updated, more often it says "unknown" of course I can look in 
the source program for more clues ... my inelegant approach has been to copy 
the source to a test library, compile it & look at the output thanks to 
external object contributions.

> Subj:  Re: DSP PGM REF Opposite
>  Date:    01/26/2001 12:03:39 AM Central Standard Time
>  From:    blarkin@wt.net (Bob Larkin)
>  
>  As a consultant, I run across this quite often. Working on an unfamiliar
>  application, you know a problem exists in a given program, but you don't 
> have a clue how the progeam is executed.  
> Assuming the user can recreate the problem,
>  looking at the call stack can provide the answer.
> the problem in your situation,
>  is that you do not know at what split second ORD561 is executing. 
> Here is my solution:
>  
>  Start debug on the program in question(ORD561) . 
> Make sure to use UPDPROD(*YES).
>          (I usually use STRSRVJOB from my workstation over the user's job.
>          Using STRSRVJOB the STRDBG command is executed 
>          over the serviced job.
> 
>          This way you can even use this technique 
>          in batch or interactive jobs.)
>  CHGDBG MAXTRC(1)
>  ADDTRC
>  Have user perform the function.
>  As soon as the program (ORD561) begins, 
>  the trace will be full, and the job will halt.
>          a trace full message will be displayed at your workstation.
>  DSPJOB option 11 on the user's job. You now see the call stack.
>  ENDDBG
>  ENDSRVJOB
>  
>  Not the most elegant way, but it will give you the answer you need.
>  
>  What do you think, a worthwhile technique.
>  
>  Bob
>  
>  MacWheel99@aol.com wrote:
>  
>  > Is there an IBM command that tells me other direction from DSPPGMREF?
>  > I would key in some command (I am making this up <G>) like
>  > DSPCALLME ORD561

 snip

>  > Currently my users get ORD561 report every time they do shipping 
documents
>  > ORD595 & ORD596 which I am told comes from ORD590 menu option, 
>  > and they want me to modify ORD561 PRTF overrides &
>  > I am having a hard time tracing where that is in the ORD590 flow, 
>  > so either the users are mistaken or I am missing something.

 snip


MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)
AS/400 Data Manager & Programmer for BPCS 405 CD Rel-02 mixed mode (twinax 
interactive & batch) @ http://www.cen-elec.com Central Industries of 
Indiana--->Quality manufacturer of wire harnesses and electrical 
sub-assemblies - fax # 812-424-6838

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