×
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 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
midrange.com
