For the archives.

The CPF2113 only shows up in QSYSOPR and HSTLOG only when the job is run from AJS.
If run as a SBMJOB, only shows up in that job's joblog.
WRKWCH would have to be redefined to look at joblog instead of *sysopr.

I was able to determine by the original job's name which job was the DLTLIB and which was the RNMOBJ.

What I could not easily determine in the WRKWCH was the NEWOBJ for the RNMOBJ, (did not appear in the WRKWCH).


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Thursday, October 22, 2015 9:59 PM
To: midrange-l@xxxxxxxxxxxx
Subject: 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.


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

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.



Event data


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].

Regards, Chuck

This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].