Re: DSPPGMREF and SQLRPG

David,

I've been told that one of the advantages of embedded SQL over traditional
I/O is that there will not be a level check if the file layout changes.

Of course, if your program uses fields that are dropped or have a
different type (numeric instead of character), you'll still be in trouble.

That's why I don't trust on DSPPGMREF alone (for instance it doesn't know
of OVRDBF or EXTFILE), but do a string search on the source instead.

A well implemented change management system should cover all bases,
though.

HTH,

Peter Colpaert
Application Developer, Consumer Luminaires

Industrieterrein Satenrozen 11, 2550 Kontich, Belgium
Tel. +32/ 3 450 74 09, Fax +32/ 3 450 74 33,
peter.colpaert@xxxxxxxxxxx, www.philips.com



The information contained in this message is confidential and may be
legally privileged. The message is intended solely for the addressee(s).
If you are not the intended recipient, you are hereby notified that any
use, dissemination, or reproduction is strictly prohibited and may be
unlawful. If you are not the intended recipient, please contact the sender
by return e-mail and destroy all copies of the original message.






David FOXWELL <David.FOXWELL@xxxxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx
03/03/2008 15:06
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
"MIDRANGE-L@xxxxxxxxxxxx" <MIDRANGE-L@xxxxxxxxxxxx>
cc

Subject
DSPPGMREF and SQLRPG






Hi,

We are also currently interested in SQL in our RPG programs.

Can anyone explain this, please.

EXEC SQL
SELECT COUNT ( * ) INTO : wVar
FROM FILE_X;

DSPPGMREF indicates that the program uses FILE_X but gives no information
as to its record format.



wSQL = 'SELECT COUNT ( * ) FROM FILE_Y'
EXEC SQL
PREPARE S1 FROM : wSQL;

DSPPGMREF gives no indacation that the program uses FILE_Y.


Does this mean we can no longer depend upon DSPPGMREF to find the programs
impacted by a changed PF?

TIA.