RE: compile option*NOUNREF

[David FOXWELL <David.FOXWELL@xxxxxxxxx>]

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.