Re: Growing Programs - Second Attempt

On 31-Aug-2011 05:20 , rob@xxxxxxxxx wrote:

<<SNIP>> All that information is stored with the program. One simple
program has 5 pages of information for PRTSQLINF.

Note:
Change date/time . . . . . . . . . . : 12/30/10 09:37:39
SQL4021 Access plan last saved on 08/30/11 at 10:18:39.

So, obviously saving the access plan into the *PGM object itself
does not constitute a "change". Good thing. I'd hate to have to give
the users change authority to an object just to run the program.

Of course the DB2 for i SQL adopts QSYS authority to 'change' the associated space of the program because the user does not have authority. That was not always the case.

FWiW, going beyond that reply which suggests no need to GRTOBJAUT even if the updated access plan were an object "change"...

Should a user not authorized be able to update the access plan? Long ago the answer was no, and a negative side-effect was a message in QHST [similar to T-AF audit logging] which informed of the failure. The resolution could have been to test for the required authority [though ephemeral for no locking] and simply skip the write of the updated plan, or to adopt the necessary authority to ensure the updated plan can be saved without any authority errors.

Writing to the program associated space is the "same" as writing to a user space; i.e. neither is a "change" to the object, merely a change to the data. Changes to "data" in other object types will more logically track as a "change", but not a 'space', which is just a location where a *SPP [space pointer] points. For every write into 'space' one should not expect that the LIC SM would have to update the owning segment or ask the owning-component of a complex segment-type to update the change date of the primary segment and\or external object(s).

The database SQL could have chosen to effect the update to the change-date of the object after each time the program associated space was updated, but then like with the confusion for authority failures for 'change' activity during CALLs, there would be similar mystery for characterizing changes which can not be easily correlated. How is a CALL a CHGxxx.? While a growth issue might easily seem a mystery, I think the current implementation is probably already the least confusing.

Regards, Chuck