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