Re: Trap CPF4128 message via monmsg in a clle pgm, put message into variable.

On Tue04-Apr-2011 13:20 , Rusling, John wrote:

Help, it's been too long.

In a CLLE program, I am trying to catch when CPF4128 occurs. (Not
able to allocate objects needed for file &2 in library &3 member or
program device &4.)

This gets bubbled up from 3rd party software and we want to try catch
it as it occurs or very shortly thereafter in an effort to see what
is denying the allocation.

I can use monmsg to do this.

What I'd like to know is how to dump the message into a variable in
the cl program, then possibly pass the msg to an rpg program to parse
it out and try, like run wrkobjlck or something, -or- find some
mechanism to tell me what the conflicting job/pgm is.

Any algorithm or direction or other ideas is appreciated.

For long-held locks blocking activity that should otherwise complete quickly, I typically increase the wait time to be a very large value to enable SysRqs-3 to DSPJOB and then option-12 to view the locks to see the WAIT, and then 8="Work with job locks" to see the conflicting lock; when the process is taking abnormally long, that is the cue to perform the DSPJOB. But since locks and thus conflicts are mostly transitory, that may not work so well... but then, attempts to "catch" the holder by a programmed response to perform WRKOBJLCK or other actions often have the same difficulty.

If the monitored message is really the CPF4128, then just RCVMSG and parse the message data from the MSGDTA() parameter according to the "field data" layout of the replacement variables per DSPMSGD CPF4128. Assuming a database file name:

chgvar &fn %sst(&mdta 11 10) /* file name &2 */
chgvar &fl %sst(&mdta 21 10) /* libr name &3 */
chgvar &fm %sst(&mdta 31 10) /* mbr name &4 */
wrkobjlck &fl/&fn *file mbr(&fm)

Or perhaps... I expect a valid succinct response for receiving the message could depend significantly on how the condition plays out, how the messages are "bubbled up", in the job message queue. Perhaps making a spooled joblog available to reference, plus the name of the CLLE program which should receive the message(s), would be worthwhile for anyone who might make some suggestions. Otherwise there is the option of getting the data from DSPJOBLOG OUTPUT(*OUTFILE) or receive messages by message key since a known key, if the message is not sent directly to the program; i.e. the message is on a program message queue that is no longer on the stack.

Regards, Chuck