Re: QAQQINI file in qusrsys is empty

[CRPence <CRPbottle@xxxxxxxxx>]

On 2/16/11 10:42 AM, Gary Thompson wrote:
> we recently upgraded V5R4 to V7R1 - have qaqqini in QSYS and QUSRSYS
> - both populated

  Might be more interesting to have noted if the file in QUSRSYS 
existed prior to, or only after, the install of the new release.  The 
creation date\time, restore date\time, and change date\time of the *FILE 
and the *MEM might be further enlightening.

> Franz400 on 02/16/2011 11:21 AM wrote:
> >

  The original message does not appear on the newsgroup; using this 
message to provide a comment\reply.

> > While checking sql performance issue, find the qaqqini file in
> > qusrsys is empty.

  Of the effect of CRTDUPOBJ having been used with the default of 
DATA(*NO), which is fine, but its existence is not of value [and in rare 
circumstances possibly problematic] without also having had an INSERT 
performed to provide an override at least one "ini" option.

> > Does anyone know what effect this will have.

  Every thread on the system which performs [any of a variety of; esp. 
"open"] database operations will look for and find the file [and load no 
"ini" option overrides for lack of any rows].

> > At this point do not know if or when records cleared.

  DSPFD QUSRSYS/QAQQINI [the *MBR details] will show member creations 
and update date\time.  The creation [or restore] date\time and change 
date\time of the *FILE object, in comparison, can be used to infer if 
the origin of the file might have been by DATA(*NO) on the create 
duplicate object request or possibly a CLRPFM [but unless created by 
CPYF vs CRTDUPOBJ, a "delete trigger" will prevent CLRPFM].

> > We did not have any specific overrides to the default values.

  The the file QAQQINI in QUSRSYS should not exist.  The file QAQQINI 
in QUSRSYS should exist only if there is some specific system-wide 
option(s) to override query\database actions that should be in place. 
If the database file QAQQINI in QUSRSYS has no data, then the file 
should be deleted; i.e. DLTF QUSRSYS/QAQQINI

> > We do have another copy in a user lib with overrides used by
> > single app.

  If existing prior to the upgrade, I suppose that is apparent evidence 
nothing about the upgrade purged existing data from existing user 
QAQQINI files.

> > Recent upgrade from V5R4 to V6R1.

  The install\upgrade of the OS should have no effect on the data in 
the file, except possibly by some "conversion" program as either part of 
the install or in a background process after the IPL for the install. 
The last I recall, no such conversion processing existed, such that any 
existing user-created copy [by the supported means of CRTDUPOBJ] of 
QAQQINI would be the onus of the user or a [system or database] 
administrator; I do recall design discussions for the possibility of 
similar, to be implemented using the database system jobs or database 
IPL, mimicking other past [post-]install database activity.  I would 
expect a Memo To Users [MTU] would document any automatic 
conversion\change process initiated against user QAQQINI files and\or 
the data in those files.

Regards, Chuck