Re: journal receiver maintenance

On 24-Apr-2015 13:43 -0500, Voris, John wrote:

On 24-Apr-2015 12:44 -0500, rob wrote:

<<SNIP>>
And once you're satisfied with those results:

Select
a.*
, qcmdexc('DLTJRNRCV JRNRCV(' concat %trim(Receiver_Library)
concat '/' concat %trim(Receiver_Name) concat ')')
<<SNIP>>

<<SNIP>>
I did not know that you could embed a call to QCMDEXC to run an
OS/400 cmd within a SQL statement.

The example is a bit deceptive, given QCMDEXC is more likely to exist only as a procedure name rather than as a scalar function.

The name QCMDEXC, even if unregistered as a procedure [routine] to the SQL, can be invoked using the SQL CALL if the PATH allows finding the *PGM object QCMDEXC in QSYS. However I am confident there is no similar implicit means to invoke existing procedures [of a service program] as a function [with a return value], without first registering the interface to the SQL; so effectively, the above example invocation necessarily implies that a scalar function was created previously [with that name, but unlike the program by that name, as being capable of accepting just one parameter].

For reference, a couple links to messages in two branches of an archived message thread:

<http://archive.midrange.com/midrange-l/201103/msg00584.html>
Using QCMDEXC in an SQL SELECT statement Was: Disabled User Profiles

<http://archive.midrange.com/midrange-l/201103/msg00579.html>
Disabled User Profiles

My question then is . . . Does a documentation package like Hawkeye
see the reference to this usage in its screens if it is invoked from
within a RUNSQLSTM command or similar ?

Such a /where-used/ feature would have the opportunity to parse the SQL statements that are coded in sources, to look for such function invocations, but obviously statements that are generated at run-time from variables are not so easily [and quite likely are rarely able to be] identified only via source-scanning.