Re: WRKQRY ends with MCH3203

On 04 Dec 2012 21:21, John McKee wrote:

Just a bit more weirdness. Without signing off and back on, I reran
the same query. No errors at all. Does that make any sense?

Because the error was diagnosed by the RMSL [Resource Management ¿Seize\Lock?] LIC component, /transient/ issues would be normal. Both locks and seizes, obtained and released by requests to the RM feature by other LIC features, are transient. Additionally because the optimization could have been different per [even nuanced] changes to the job\system\work\data environment, or even due to an /autonomic/ adjustment as reaction to the prior failure, such change could have seen the next seemingly identical query request complete without errors even while the origin for a prior failure remained unchanged [i.e. a problematic RM status had not yet transitioned].

The RM naming RmslReleaseSeizeNoToken seems IMO, to suggest that the likely problem origin is that the database inquiry had requested to release a seize that was not held, and therefore the RM likely issued a "failed assumption" aka "assertion failure" for a precondition; i.e. if a component requests to release a seize when none is held, then fail and log the request, because it is "assumed" that _logically_ nobody should ask to release unless they currently hold.

To avoid encountering the same issue in the future, either a preventive PTF would need to be applied, or [unlikely\improbably] the usage issue giving rise to the error would need to be avoided or an object\data that is in error would need to be corrected. At a minimum, PTFs for probable matches to the symptom should be applied as preventive, and if none are available [e.g. the one I mentioned in a prior reply, and any other PTFs, are already applied] then the VLog(s) would need to be reviewed by [the LIC RM and DB level-3] IBM support; sent as part of doc collection with a PMR opened with IBM. However being a transient issue [whether per optimizer or per RM activity itself], the origin likely is not so easily inferred [from just VLogs] without also the query\implementation and some details of other resource allocators\deallocators with doc collections for any errors they encountered and activities they performed; possibly even requiring re-create with active RM trace of the lock\seize transitions.