× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On 24-Jul-2016 05:54 -0500, GioArt wrote:

I'm on a machine with V5R4, i have an SQLRPGLE that i have to
compile with RPGPPOPT(*LVL1);

If in the CRTSQLRPGI command I set RPGPPOPT(*LVL1) there no error
in compilation, instead if I set in the source :

exec SQL set option naming=*SYS,COMPILEOPT='RPGPPOPT(*LVL1)';

A string-value for the COMPILEOPT keyword on that SET OPTION statement is merely an override to the Compile Options COMPILEOPT parameter specification that is available on the various CRTSQLhll commands. That /exec SQL/ request is merely declarative, despite the syntax using the keyword "Exec". The declarative SET OPTION statement functions quite similarly for the SQL pre-compiler, as does an RPG H-Spec for the RPG compiler; in both cases, the specifications made within the source are utilized for the [pre]compiler directives, instead of what was specified on the [pre]compile command invocation.


I have errors like if the COMPILEOPT='RPGPPOPT(*LVL1) is not
recognized

FWiW: An actual spooled joblog showing the command invocation of the pre-compiler to include the final error displayed after control was returned from the failing request is much more concise and revealing than stating merely "errors like …". And if the error(s) appeared in the [pre]compiler spooled output, then that would be similarly worthwhile for specific details. When asking for help in a forum, please provide concrete information\details rather than mere allusions; just because a reader _can_ compose their own source and issue their own pre-compile invocation, they could instead just diagnose the issue with nothing more than the spooled joblog [of which easily could have been included with a copy\paste; probably in this case, even if copy\paste from the interactive joblog].

Regardless, per my earlier description about the given SET OPTION, as to what are the effects, that COMPILEOPT='RPGPPOPT(*LVL1)' specification is the equivalent of having requested from the command-line:

CRTSQLRPGI COMPILEOPT('RPGPPOPT(*LVL1)')

Conspicuously, the above invocation is *not* the equivalent of having specified "CRTSQLRPGI … RPGPPOPT(*LVL1)" for which there was "no error in compilation". Thus if the desire is to invoke the pre-compiler with the RPGPPOPT(*LVL1), then just specify RPGPPOPT(*LVL1) on the command invocation, and remove the ", COMPILEOPT='RPGPPOPT(*LVL1)'" from the current SET OPTION in the source.

If that is understood, then no reason to continue reading; if not understood, or perhaps not entirely cleared up despite being mostly understood, then I offer additionally:

That Compiler Options (COMPILEOPT) parameter available on the Create SQL (CRTSQL*) commands [e.g. on the CRTSQLRPG or CRTSQLRPGI] is the means to pass-through some parameters [each as a combined parameter-Keyword and parameter-Specification], onward to the CRThllObj [e.g. CRTBNDRPG or CRTRPGMOD] HLL compiler command that would be invoked after a successful SQL pre-compile. The string data being provided on COMPILEOPT would be appended to the command-string that gets composed by the SQL pre-compiler; if the pre-compiler had composed a compiler invocation as the command-string "CRTHLLOBJ …", then having specified COMPILEOPT('string_data') would cause the SQL to invoke the compiler instead with the command-string "CRTHLLOBJ … string_data". That 'string_data' is not validated, merely appended; validation of the command-string is left to the command analyzer when the pre-compiler uses that command-string to invoke the HLL compiler.

Thus having passed-in 'KEYWORD(SPECIFICATION)' via the COMPILEOPT parameter on a request to CRTSQLRPGI OBJTYPE(*MODULE), the command string "CRTRPGMOD KEYWORD(SPECIFICATION)" must be supported, else the request to compile will fail; the CRTSQLRPGI request would fail both if the Specification for that parameter Keyword is unsupported, and if the Keyword itself is not recognized\supported on the CRTSQLRPGI command,

In the given scenario we do not know what was the actual invocation, so presuming the request was CRTSQLRPGI COMPILEOPT('RPGPPOPT(*LVL1)') OBJECTYPE(*MODULE), then the command-string generated by the SQL pre-compiler would have been:

CRTRPGMOD RPGPPOPT(*LVL1)

The command-string 'CRTRPGMOD RPGPPOPT(*LVL1)' would result in msg CPD0043 "Keyword RPGPPOPT not valid for this command." being issued when prompted or interpreted. When actually invoked, that diagnostic message would be followed by the error msg CPF0001 "Error found on CRTRPGMOD command." And that [failure] would be expected, because the RPG Pre-Processor Options (RPGPPOPT) parameter is not available on CRTRPGMOD; and is not available on any of the CRThllObj commands.


It is a V5R4 problem or other ?


With that particular string-value as the specification, the /problem/ would be universal; i.e. would fail on any release. That specification on *either* the set-option-keyword COMPILEOPT or the command-parameter-keyword COMPILEOPT, is not valid on any release, whereas the COMPILEOPT keyword [in either context], would be valid only since V5R3. Thus given a valid 'KEYWORD(SPECIFICATION)' was specified as the string data for the COMPILEOPT, then there would be a /problem/ on v5r4 only if the Target Release (TGTRLS) were [the equivalent in effect to] the special value *V5R2M0.

So if the desire\intent [of the invalid specification in the SET OPTIONS] is to cause the SQL pre-compiler to receive a directive that the RPG Pre-Processor Options (RPGPPOPT) should be Level-1 (*LVL1), then that directive must be specified on the CRTSQLhll command in lieu of support for a RPGPPOPT keyword for the SQL SET OPTION statement.

That is to suggest, the SET OPTION from the OP would need to look something like the following [as if even\ever, such a capability were supported]:

exec SQL set option
naming=*SYS
, RPGPPOPT=*LVL1
; --

With that imagined-as-supported declarative, the effect for the CRTSQLRPGI OBJTYPE(*MODULE) would be to have the SQL pre-compiler act as if that request to invoke the pre-compiler had been instead:

CRTSQLRPGI OBJTYPE(*MODULE) RPGPPOPT(*LVL1)

So, just like the opening statements of the quoted message, you will continue to "have to compile with RPGPPOPT(*LVL1)" specified on the CRTSQLRPGI command.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.