Re: Performance question and SQL SERVER - RESOLVED

[CRPence <CRPbottle@xxxxxxxxx>]

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.