On 07-Jul-2016 11:31 -0500, dlclark wrote:
On 07-Jul-2016 07:35 -0500, Justin Taylor wrote:
IIRC, CHGQRYA requires job control authority, so that's not a
practical solution. […]
Somebody can correct me I'm incorrect. But, my understanding is that
CHGQRYA is only required for ease of implementing different QAQQINI
settings at different times for the same job (or session).
More typically, as settings across different jobs.
Meaning: There are two different ways to implement different QAQQINI
setups that don't require the use of CHGQRYA. For either of these to
work, of course, there can be no default QAQQINI setups in the
system portion of the library list.
The default QAQQINI is singular; there can be only one, either the
INI file that is active, or the default. There is always the model-copy
in QSYS, and there [generally should not be, but may be] a copy in
QUSRSYS that serves as the one _default_ settings.
Note: The effect of CHGQRYA may be by an alternate implementation
than the use of the command itself; e.g. as a connection-string setting.
One way is to create multiple QAQQINI setups in different libraries
and include the selected library in the library list for the job that
needs a particular QAQQINI setup.
The Library List (LIBL), system-portion or otherwise, is moot; the
feature requires the explicit specification of a library name only, no
special values [except *SAME which of course means to leave the current
setting\value unchanged].
The other way is to have multiple QAQQINI setups with different names
in the same library (QUSRSYS, for example) and then the job that
needs a particular setup copies the selected xxxQAQQINI setup to
QTEMP and renames it to QAQQINI so that it will be picked up by the
query in question.
I expect more likely\typically, different variations of QAQQINI would
be created with that file name into specific libraries to ease the
specification of redirection to that version, by naming the QRYOPTLIB()
without any pre-requisite copying\naming of that file.
Change Query Attributes (CHGQRYA) will be implicitly in effect *only*
for the _default_ Query Options File Library (QRYOPTLIB) of QUSRSYS;
i.e. upon existence of the properly-created file QAQQINI in QUSRSYS, for
which the effects of the QQPARM and the corresponding QQVAL are globally
in effect [across all jobs], just as if every setting were instead
available as a System Value -- of which, there are only some two or a
few values, including:
• QQRYDEGREE *SYSCTL Parallel processing degree
• QQRYTIMLMT *SYSCTL Query processing time limit
Only those jobs in which the QRYOPTLIB is set\changed [optionally via
the procedure QSYS2.override_qaqqini() vs the CHGQRYA command], will the
effects be specific to that job; having redirected the query engine to
look elsewhere for the parms\value pairs, those values that otherwise
would be obtained from the file in QUSRSYS would instead be obtained
from the lib_name/QAQQINI in the redirected-to library-name.
I recommend against creating a copy of the file in QUSRSYS except
when necessary to implement a specific value-pair as a[n effective]
circumvention; that the INI settings should be established only in jobs
for which there is a known\specific reason. Notably but highly
improbable to be experienced, though I have seen this happen, whereby
because every database open [query or non-query open] refers to the INI
file, that when there is a difficulty to open the INI file that is
exhibited as a failure to open, the system [being highly integrated and
dependent upon the function of the database] is quite near
dead-in-the-water -- as well, quite conspicuously, there is little
reason to open the file [at least once] in every job if not for a
legitimate purpose. I am unsure if a general monitor\handler for access
to the INI file has been coded\verified to avoid the past grand problem
I had experienced.
midrange.com
