Re: Problem with MONMSG

Chuck,
As usual, thanks for the illumination of what's really going on.
It helps a great deal.
Jim Franz

----- Original Message ----- From: "CRPence" <CRPbottle@xxxxxxxxx>
Newsgroups: midrange.midrange-l
To: <midrange-l@xxxxxxxxxxxx>
Sent: Wednesday, January 06, 2010 5:33 PM
Subject: Re: Problem with MONMSG

Comments aside from the message handling [which with a spooled
joblog and trace would probably expose the error]...

Uhhh... Be aware that the ALCOBJ allocates the *FILE with only a
*READ, the *MEM with *READ, and only the *data* exclusively per use
of special value *EXCL. And for the given invocation, which member
chosen to be locked, will be defaulted to *FIRST; given no changed
defaults. There is unfortunately, no ability to lock the *FILE
exclusively from other activity; I had long advocated *NONE as a
special value for the member to imply the "lock state" should apply
to the *FILE. This means the request to add the trigger can still
fail with an allocation error, even if the allocate object request
succeeds; due to any activity against the file not related to the
exclusively held data. So given the add of the trigger can still
fail even if allocated, it is usually best to just defer the
allocation activity to the function being requested; i.e. allow the
add trigger [ADDPFTRG] to perform the necessary allocations and
diagnose any failure to effect the allocate portion of the add
request. The only way to ensure the locks preventing conflicting
activity are held across multiple actions [e.g. the series of
trigger activity], is to perform them under commitment control.
However there is no support for cmtctl on the use of the trigger
commands. The *FILE will be locked exclusively across SQL trigger
activity when performed under isolation [i.e. commitment control],
until the COMMIT.

Regards, Chuck

Mark Walter wrote:

<<SNIP>>

Basically the program will allocate a file, apply a series
of PF triggers, then deallocate. I added the triggers
manually, but I still can retest tomorrow when I know
someone's in the file. I'll change the job to log the CL Program.

Mark Walter wrote:

I'm trying to monitor for CPF1002 when allocating an object.
OS/400 seems to be ignoring the MONMSG Command. Here is the
code:

lmp: /* LMP - Location Master File */
alcobj obj((lmp *file *excl)) wait(10)
monmsg msgid(CPF1002) exec(do)
chgvar var(&counter) value(&counter + 1)
if cond(&counter = 60) then(do)
sndpgmmsg msg('Cannot Allocate file LMP')
goto cmdlbl(pmp)

Any ideas why the alcobj command is throwing an exception
message CPF1002 when I'm monitoring for it?

--
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,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.