On 02-Nov-2015 22:23 -0600, Roger Harman wrote:
<<SNIP>>
The SQL0204 error is what I've seen in my testing if the file does
not exist.
Other than invoking a CHKOBJ from the program, I just wasn't sure if
there were a simple way with minimal overhead instead of forcing an
error.
The system is message-based, and despite the SQL using return-codes,
even the existence checks by the SQL come about by an error condition;
i.e. non-existence always will be manifest as an error, somewhere.
While there exist lower-overhead means to check, than by using the
SQL to perform the check with the processing of the statement that will
be attempted against the possibly-missing-object [and I have listed some
below], this particular scenario is likely not well-served by using any;
skip to the end of my reply for why.
If it doesn't exist, the program just exits - no harm/no foul in
this situation.
While I am not a fan of checking first and then reacting, in this
scenario of the reaction being effectively /no matter/ vs the reaction
being to /create-the-missing-object/, the problems inherent in the
latter [due to concurrency] are avoided. And if the checking for
existence is deferred to the SQL, then that is going to be somewhat
slower than a check performed outside the SQL; but, one must ask,
"Noticeably slower?" Yet, if the table-reference(s) are unqualified,
deferral to the SQL is generally the best choice, because knowing or
figuring out how the SQL is going to resolve the table-reference
depending on use of *SYS vs *SQL naming can be a PITA.
Given the files are apparently permanent, and thus not in QTEMP, and
if the table-references are library-qualified, then a CLLE procedure
that performs the Check Object (CHKOBJ) or perhaps instead just using
the Retrieve Object Description (QUSROBJD) API or even the stat() API or
the Materialize Context (QusMaterializeContext) API, would probably
suffice quite nicely; but if the naming of the files [as described in
the OP] implies possibly the use of SQL /long/ names, then instead using
the Retrieve Short Name (QDBRTVSN) API or a query of SYSTABLES catalog
VIEW [or another query of the underlying data] could be an effective
requirement when not deferring to the SQL statement that refers to the
TABLE by name.
Realistically, the range of retro-active updates should pretty much
guarantee that a non-existence would be a rarity - maybe not worth
the worry - other than trapping the error and allowing a graceful
exit.
That alone implies the best option; that would be, the deferral to
the actual SQL statement doing the DML to test for existence. That is
because the SQL has to verify the existence of the file anyway, for each
statement. And if almost every time the SQL will succeed in that
existence-checking, then the exception-case is rare. Thus if the code
were to be written /presumed-fail/ by adding an existence check prior to
the SQL statement, then the rare exception-case is being doubly-tested
for, on the vast majority of invocations; i.e. approaches doubling the
number of existence checks. So having the code written instead as
/presumed-success/, by simply letting the SQL perform the
existence-check for the SQL statement, and thus the SQL will report the
rare exception-case, the only additional work is limited to those
rare\few exception cases; in this case, being especially inexpensive
additional work, of an effective RETURN statement.
midrange.com
