Re: RPGLE with embeded SQL cursor over file with *READ trigger

Hi, again:

(Replying to my own post ...)

I now refute what I just said ... there is a lock on the "read trigger" program after all ...

I fooled myself because I had a little "test trigger" that just calls the QUSCMDLN API and I was able to compile and replace the trigger from that command line ... within the same job that had the "lock" on the *PGM ... :-o

Just an update for the archives and for anyone interested in this topic.

Mark

> On 10/23/2012 11:21 AM, Mark S Waterbury wrote:

Hi, Chuck:

Well, now, this is interesting ..

I just ran a quick test, and I was able to recompile and replace a "read
trigger" *PGM while it was "in use" -- I had the file "open" ... and was
browsing the records in this file ...

So, apparently, IBM has not enforced the same "protection" for the
"after read" trigger as they do for all other (insert, update, delete)
triggers?

I wonder if this was an oversight, since support for read triggers was
added some time after the initial implementation of triggers in OS/400
DB2/400, or if this was "intentional"?

Fascinating ...

Mark S. Waterbury

> On 10/23/2012 11:06 AM, CRPence wrote:

On 22 Oct 2012 22:16, Mark S Waterbury wrote:

The OS (IBM i or OS/400) does not "protect" *PGM objects (or
*SRVPGMs), e.g. by placing a *SHRRD (*USE) lock on them when
they are "in use" (e.g. called or activated in some jobs).

However as I recall, the OS, specifically the database component of
the OS, *does* lock a "trigger" program when a database file, one which
previously was associated with that program as a trigger [ADDPFTRG; or
CREATE TRIGGER, but there is no *READ for SQL triggers], is opened for
the type of I\O covered by that trigger.