Re: QAQQINI file in qusrsys is empty

Chuck - thanks for the detail.
The QUSRSYS QAQQINI files (multiple partitions) did exist before
the upgrade, but each has a change date = upgrade date. Right now we
believe they were cleared before the upgrade. We had a project during
v5r4 to test various options.
We will either use the QUSRSYS file or remove it.
Jim Franz

---- CRPence <CRPbottle@xxxxxxxxx> wrote:

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
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.