Re: CHGPF locks db2 and web page

Presumably the CHGPF was canceled [aka interrupted] after the change had already started; i.e. the request to SysRqs-2 effected ENDRQS, after the CHGPF had placed the object in recovery. While "started" might normally be considered only to have occured after all of the locks were acquired, there is a window-of-time in which the operation is partially claimed by the database recovery; no specific operation type is identified, letting concurrent work to effectively poll for availability, but /open/ is normally not prevented except by locks. If the object was placed under recovery with a known operation type, there would be a message in the history and in the joblog of either the followup CHGPF request that was able to complete or another job that encountered the /recovery object/ which was able to progress the interrupted change request. The message would be in the range 3200 [prefix likely CPF, but maybe CPD or CPC], suggesting that the pending "recovery completed" for the file.

That does not however, intend to suggest that all of the described effects would be expected. The effect seems possibly to describe an /orphaned/ lock, still held by the requester of the CHGPF; the lock need not have been the physical database *FILE object itself, and the LCKW condition shown in other jobs could have been reviewed to see what specific locks were in status REQ [requested] rather than HLD [held], to possibly expose what was locked. Because the displays show only external object types, that may not have assisted. As already suggested in other replies, the WRKOBJLCK needed to at least /show member locks/ in addition to the *FILE lock, and the CHGPF gets an exclusive lock on the PF plus each dependent LF to ensure there are no conflicts with other work. There is other tooling as part of a TestFix from the lab [DSPSYSLCK and DSPJOBLCK or DSPLCKSTS; possibly munged names with LK to prevent false inference they are part of the OS] and I seem to recall something like job locks in iNav which like the tooling included Space Location Locks [SLLs]. Note: I do not recall an SLL as part of the Database Recovery processing, but IIRC they are used for a seize prevention protocol for things like RGZPFM, CLRPFM, and index rebuilds.?

Did this occur for an old release down-level on fixes?

FWiW the column headings can be changed with the SQL LABEL ON instead of CHGPF; also enabling the updated source to match the actual change. I believe both interfaces utilize QDBCHGFI. However the LABEL ON can be performed with isolation [like ALTER TABLE], and that could help. Because although the implementation of the actual work for CHGPF SRCFILE(specified) operates under commitment control, it is only for the work performed after starting the request under standard non-commit DB recovery. The locking and unlocking performed for\under isolation is implemented differently than that done for standard DB recovery; it is removed due to ROLLBACK, whereas the non-commit interface must ensure unlocking is performed in its cancel handler processing.