Re: compile option*NOUNREF -- MIDRANGE-L

Well, using spooled files is a venerable approach - but please note, in my own defense, that I mentioned APIs in my original reply. The spooled file reference was a concession, albeit with a suitable warning about possible problems.

As to this approach, I think you were lucky - you cannot guarantee that the source member type will be SQLRPGLE - really, you can't depend on that. It is a fortunate design that PDM checks the source member type when you use option 14 or 15. But the actual command used does not care about member type.

To test my assertion, change the source member type on one that has embedded SQL. Change it to FOXWELL. You will not be able to use option 14 or 15 - they understand the member type. But the create command does not care about member type. I changed the type to FOXWELL and ran this command, which did attempt the compile.

CRTSQLRPGI OBJ(VERN/DATEDUR) SRCFILE(VERN/QRPGLESRC)
SRCMBR(DATEDUR) OBJTYPE(*PGM) REPLACE(*NO)
That is why some approach that looks for information like the DB2 info in a module or program is preferred. Either by the APIs Chuck and I have referred to, or, for the risk-prone, the spooled file approach.

And, yes, the spooled file approach is ugly when there is an API to use instead.

HTH
Vern

David FOXWELL wrote:

Vern, I did not want to reply ughh as you are always so good to take the time to reply. I must admit though that I was as turned off as Chuck.

Here's what I did.
DSPOBJD of modules.

DSPFD member list of all QRPGLESRC

SELECT ODOBNM FROM dspobjdmod join dspfdMbrLst on mlname=odobnm WHERE MLSEU2 ='SQLRPGLE'
I realise of course that this method may give undesired results, as I'm assuming that there is a relation to a module name and a member name in a QRPGLESRC file. The two files in my sql statement are actually independent of each other.

-----Message d'origine-----
De : midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] De la part de Vern Hamberg
Envoyé : mercredi 28 avril 2010 23:10
À : Midrange Systems Technical Discussion
Objet : Re: compile option*NOUNREF

LOL Chuck

Yes, print/copy/read is my last resort - I did mention the program & service program information APIs generally in the previous paragraph and use them myself in our product code.

I agree that APIs are preferred - and that CPYSPLF is expedient albeit risky.

Vern

CRPence wrote:

Vern Hamberg wrote:

There is no such thing as an "SQLRPGLE" module as such -
there is an
SQLRPGLE source member type, however. Now AFAIK you don't HAVE to have an SQLRPGLE member type in order to compile something with embedded SQL. It's just handier in SEU and WDSC/RDi/etc.
for syntax
checking and all.

Since the SQL portion of compilation is just a pre-compile, and that the module is then created from [pre-compiler
generated] purely
RPGLE source, the object attribute is just the RPGLE. This is the same for the program object type. Just as the WRKMOD
command with its
MODATR() parameter has no SQLRPGLE as selection, the WRKPGM command with its PGMATR() parameter allows RPGLE as selection but
there is no
SQLRPGLE.

And there are DB2/400 attributes in the DSPMOD command, where you get the number of SQL statements, etc. The presence of this would indicate and SQL-ish module (It's called DB2/400 at V5R1 -
maybe IBM
use a different name in more recent releases)

I tested this on an ILE program - didn't do so with an OPM program using embedded SQL. I assume there is something similar.
There are APIs to retrieve program information - different
ones for
ILE and OPM - that give you a module list with attributes,
for ILE,
and program information itself, for OPM.

The PRTSQLINF would notify if the [service] program object has
DB2 SQL information stored\associated with the object. The SQL9011 would result if not, with a previous diagnostic SQL5062
being logged,
although on v5r3 that diagnostic is insufficient in describing possible cause\origin.

Maybe you could run DSPPGM DETAIL(*MODULE) OUTPUT(*PRINT) and work through that spooled output, maybe CPYSPLF first to a PF,
then read
it, looking for the DB2/400 marker - or whatever it is at whatever release. This always has the risk of something being
changed by IBM,
of course.

Ughhh. What sad times these are when people still suggest the spool\copy\read approach, when more often than not, a reply
to suggest
that "there's an API for that" would hopefully be available. ;-)

http://www.google.com/search?q="retrieve+module"+api+v5r4

The above search yields the Retrieve Module Information
(QBNRMODI) API with indication that among the information
the API can
retrieve being "Module SQL attributes":

http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/qbnrm

odi.htm

Regards, Chuck

David FOXWELL wrote:

<<SNIP>>

As for the list of modules, I set up a WDSC connection
and filtered
all the modules into a table. I can then show all the
modules on the
system and sort them on size, etc. But SQLRPGLE modules
still show
up as RPGLE.

David FOXWELL wrote:

I wanted to try the new(ish) compile option *NOUNREF on an RPG module. Is this option not available if the module is SQLRPGLE?

How can I get a list of all modules but distinguish
between SQL and
non SQL module?

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.