Re: Trigger program - open / close file question -- RPG400-L

Well what you're describing isn't what the OP has.

But in general it is allowed. Trigger programs can be called recursively,
(so you really shouldn't create one with a simple CRTBNDRPG/CRTRPGPGM as RPG
programs aren't recursive.)

You can't update the same record, and you can only recurse up to 200 levels,
but it does work and might be useful for example in a Bill-of-Materials type
file. Say you update the cost of component A, any sub-assemblies that use
it would be updated, and sub-assemblies that use those would then need
updated, and so on.

Exceptions:
An attempt to do any input/output operation to a file that a trigger program
has opened with *SHARE and is the file that caused the trigger program to be
called.

HTH,
Charles

On Tue, Dec 16, 2008 at 3:56 PM, <Asher613Smith@xxxxxxx> wrote:

Do I have this right?

A program updates a file.
The file has a trigger on it, thus causing the trigger program to be
invoked.
The trigger program then updates the same PF (via an LF).
Which, guess what, causes the same trigger program to be invoked.

If I have this right, when is this process supposed to end?

I sure hope I have this wrong.

In a message dated 12/16/2008 9:43:05 P.M. Jerusalem Standard Time,
charles.wilt@xxxxxxxxx writes:

I don't understand why the trigger program having the file opened for
input
would affect another program opening the file for update....

Looking at the CPF5125 message....

Is the file defined as SHARE(*YES) or is there an OVRDBF in effect?

If so, then either
1) get rid of the SHARE(*YES)
2) have the trigger open the file for update even thought it doesn't plan
to
update it. Make sure when the trigger does a READ or CHAIN you include
the
(n) op-extender so that the record isn't locked.

Charles

On Tue, Dec 16, 2008 at 1:52 PM, Brown, Stephen GRNRC <
Stephen.Brown@xxxxxxxxx> wrote:

We have recently made some extensive changes to a Trigger program. Part
of these changes meant adding a series of system control files for input
only purposes.
These control file are used throughout our system for various things
like holding next numbers, environment codes etc so sometimes they are
defined for input and sometimes for update.

Anyway, we are having a problem because the control files in the trigger
pgm are currently being left open as the trigger is just issuing a
return. This is causing an issue in that in some programs these control
files are being open / closed within the calling program and some are
not. e.g Pgm 1 open / closes ctrlfile1 ( ctrlfile1 defined for Update).
Closes CtrlFile1 - invokes trigger - trigger opens ctrfile1 leaves open
- return to pgm1 - pgm1 tries to open ctrlfile1 again for update - can't
fails with CPF5125.

Now I don't want to have to review all usages of the control files in
conjunction with where the file hat has the trigger program associates
with it so best option would be to have a fit all solution made within
the trigger. ( I hope)

I need to make sure that if the trigger program is called that it
doesn't "upset" the calling programs i/o of the control files. I thought
the best way to do this would be to user define the control files in the
trigger and ensure they are closed prior to the return to the calling
program. I'm now questioning myself as I'm unsure that by closing the
file in the trigger will close it in the calling program and therefore
still give me an error ?

I then thought of checking the status of the control files in the
trigger using %OPEN but I'm not sure if this only applies to the status
of the file in the trigger program or in the call stack. If it does it
within the call stack fine if it doesn't then what does my close in the
trigger close it in the calling pgm ?

Can anyone offer some words of wisdom.

Thanks

------------------------------------------------------------------------------

CONFIDENTIALITY NOTICE: If you have received this email in error,

please

immediately notify the sender by e-mail at the address shown. This

email

transmission may contain confidential information. This information is
intended only for the use of the individual(s) or entity to whom it is
intended even if addressed incorrectly. Please delete it from your

files
if

you are not the intended recipient. Thank you for your compliance.
Copyright 2008 CIGNA

==============================================================================

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing

list

To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing
list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

**************Make your life easier with all your friends, email, and
favorite sites in one place. Try it now.
(
http://www.aol.com/?optin=new-dp&icid=aolcom40vanity&ncid=emlcntaolcom00000010
)
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.