Re: Performance question and SQL SERVER - RESOLVED

On 06 Jun 2013 09:51, Mike Cunningham wrote:

CRPence on Thursday, June 06, 2013 11:45 AM

In general, a QAQQINI should *not* even exist in QUSRSYS; i.e.
none should exist to be deleted. Ideally any copy of QAQQINI in
QUSRSYS could and would be deleted on most every system. The one
to *not* delete is the file in QSYS.

We have never done anything with this file from what IBM ships and
we have one in QSYS and one in QUSRSYS, The one in QSYS is dated
8/10/09 V7R1 and in QUSRSYS 22/21/06 V5R3. So I should probably
delete the one in QUSRSYS?

Besides the /release created on/ already shared, I expect that the /created by user/ and the /created on system/ information, plus also perhaps the /owner/ of the object, will reveal who was responsible for the copy that was created in QUSRSYS [on that conspicuously /suspect/ date, presumably in 2006]. Before deleting a copy of the file from QUSRSYS, the non-*DEFAULT values should be investigated to determine if or what of any of those modified INI settings should be maintained system-wide, or instead should be applied only to the query activity of specific application(s). Most systems should have no need, nor even a desire, to override a value system-wide; I believe some ERP provider requests a system-wide override under the assumption that all work on the system *might* utilize their ERP software and files [with queries], and thus claim that the overrides effectively /must/ be implemented system-wide.

FWiW: If I purposely had a QAQQINI in QUSRSYS which effected a system-wide override to the attributes, then I would include that in my System Change Management; i.e. upon an upgrade, deleting the down-level copy of the file and then creating the new\duplicate copy [with data] from the new-release copy from QSYS, and then re-applying the updates. I would probably do the same for a QAQQINI maintained for an important application. That way I would have the new attributes included and could use an UPDATE vs an INSERT statement, to *change* from the /default/ value for any shipped attribute; i.e. newer attributes represented by the rows, would exist to be changed. That would also avoid any dependencies on any conversions the OS might need to apply to down-level QAQQINI files, and avoid any hassles in effecting that activity as a recovery action, if instead the OS deemed all or some of these files must be re-created because they do not offer any conversion for those user-copies or the conversion that is offered would be applied successfully only to those still maintaining record format sharing... but the copy of the QAQQINI being used, for some [and perfectly simple and legitimate] reason, did not maintain that shared format.