× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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

This mailing list archive is Copyright 1997-2024 by midrange.com 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].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.