Re: Determining command resulting from WRKWCH for CPF2113 - Cannot allocate library XXXXXX

On 22-Oct-2015 19:47 -0500, Steinmetz, Paul wrote:

I have a WRKWCH running for CPF2113 - Cannot allocate library XXXXXX
I use this as a trigger to call a CL which ends the jobs causing the
locks when doing a DLTLIB.

I recently discovered that a RNMOBJ of a library results in the same
message, CPF2113.

The problem I'm having is that the command, DLTLIB or RNMOBJ, is not
passed to the WRKWCH pgm.
I need to know in the WRKWCH pgm which command (DLTLIB or RNMOBJ)
caused the CPF2113.

The following are passed to the WRKWCH pgm.

DCL VAR(&WCHOPTSET) TYPE(*CHAR) LEN(10)
DCL VAR(&SESSIONID) TYPE(*CHAR) LEN(10)
DCL VAR(&ERRDETECT) TYPE(*CHAR) LEN(10)
DCL VAR(&EVENTDATA) TYPE(*CHAR) LEN(1024)

I did a DMPCLPGM, but did not find/see the command in any of the
four variables.

Any thoughts from the group.

Pretty safe bet, though solely according to the Library Component (LI) naming [somewhat reflecting a conspicuous convention], that when the Watch Option Setting is *MSGID, then the Event Data will contain:

• When the message was for an issue for a Rename Object (RNMOBJ) request then the COND(%sst(&EventData 63 5) *eq 'QLIRN') likely will be true.

• When the message was for an issue for a Delete Library (DLTLIB) request then the COND(%sst(&EventData 63 5) *eq 'QLICL') likely will be true.

[http://www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_72/apis/xwchevnt.htm]

...

Event data

INPUT; CHAR(*)

The format of the watch information depends on the Watch option setting causing the exit program to be called.

The format of the Event data is as follows if the Watch option setting is *MSGID:

+-------------------------------------------------+
| Offset | Type | Field |
| Dec | Hex | | |
+-------------------------------------------------+
...

| 62 3E | CHAR(256) | Sending program name |
| 318 13E | CHAR(10) | Sending module name |

..."

Notably: the system program names QLICLLIB as CPP for DLTLIB and QLIRNOBJ as CPP for RNMOBJ. Then there are the Delete Object (QLIDLTO) API that should invoke QLICLLIB [presumably by effective Transfer Control (TFRCTL)] to effect the same as DLTLIB and the Rename Object (QLIRNMO) API [irrespective of possible invocation of the CPP for RNMOBJ, shares the same prefix].