Re: DSPPGMREF info (was Re: qstrup cl question/bug)

Actually my code was RPG. Didn't look like it?

But if it was a fixed command it would not be better to include a dummycommand 
with a parameter 'If Program name, then how used', would it?

The problem is that a program object's program ref is too static. 

Yes - of cause all my commands using files defines theese as files. 
Another solution I have used is to include in the weekly pgmref-rebuild a 
program that writes a source to QTEMP with the same name as the menu FILE with 
something like IF 5=7.. then call all programs from the menu file, compile it 
and  include it in the rebuild where-used-file. 

But - I found no 100% secure way to get a complete x-ref.

Henrik


----- Original Message ----- 
> date: Fri, 14 Nov 2003 22:39:33 +0000
> from: Martin Rowe <martin@xxxxxxxxxx>
> subject: DSPPGMREF info (was Re: qstrup cl question/bug)
Martin wrote about:

> > CALL PGM
> > IF 5 = 7
> > CALL 'PGM1'
> > CALL 'PGM2'
> > CALL 'PGM3'
> > ENDIF
> >
> > Guess why?
> >
> > You're right: PGM1, -2 and -3 are included in DSPPGMREF.
> > Not nice really, cause the first line is ment to be flexible. Some day
> > the variable PGM might have a fourth value 'PGM4', but the DSPPGMREF
> > does not follow.
> 
> I recently noticed that a DSPPGMREF had picked up a file for output from a 
> CL, when that file wasn't on a DCLF. It had identified a file used on a 
> command's OUTFILE parameter. The weird thing was that the command wasn't 
> an IBM one, but one of my own. I'm presuming that it was the OUTFILE parm 
> that was recognised. Are there any other tricks like this? Could you 
> maybe create a dummy command DCLPGM PGM(*N) to get a PGM object appear in 
> the references, instead of CALLs in a never entered IF block?
> 
> Regards, Martin