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



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?


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.