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

On 26-Oct-2015 08:37 -0500, Steinmetz, Paul wrote:

On Thursday, October 22, 2015 9:59 PM CRPence wrote:

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.

<<SNIP>>

<<SNIP>> when the Watch Option Setting is *MSGID, then the Event
Data will contain:
<<SNIPped comments that presumed *MSGID was from a joblog [for
which capabilities are still rather limited per assumptions in
coding], instead of from a message queue such as QHST>>

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

FWiW: As described, that issue seems to highlight the potential value from having coded the submitted request as a CALL to a CL program coded with the necessary error-handling to effect that work, *instead of* directly having coding the CL commands RNMOBJ and\or DLTLIB on the Command (CMD) parameter of a submitted request [e.g. as on a Submit Job (SBMJOB)]. Of course such a CLP could be invoked as a Command Processing Program (CPP) via a user-defined Command (CMD), rather than coded as a CALL, as an alternative to the Rename Object and\or Delete Library commands. That is to suggest, that rather than relying on a separate asynchronous /watcher/ as the means to attempt dealing with the recovery from the allocation error, just code any desired recovery directly within the compiled CLP, by use of the MONMSG [with EXEC()] statement of the Control Language. Because the Monitor Message (MONMSG) statement follows the failing command request, what was the failing request is known to the coder of the CLP, thus there would be no reliance on the name of a job from which merely _to infer_ what might have been the failing command request, nor resort to redirecting to the failing job[log] trying to determine [vs merely infer] the same.