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



What does "PGM1 has CTRFILE1 closed at the point it updates file with
associated trigger" mean? If the file is closed, how is it updating it? The trigger
file is NOT CTRFILE?

Also, Trigger returns to PGM1 is misleading. PGM1 does not call trigger,
though it is true that they are in the same call stack. Only communication
between Trigger pgm and PGM1 would be via messages. Trigger can determine which
program caused the invocation by looking two levels up the call stack.


In a message dated 12/16/2008 11:20:58 P.M. Jerusalem Standard Time,
Stephen.Brown@xxxxxxxxx writes:

Yep you got that wrong. I sent a second mail detailing issue....

PGM1 - has CTRFILE1 - defined for UPDATE and as USROPN.

PGM1 has CTRFILE1 closed at the point it updates file with
associted trigger.
Trigger opens CTRFILE for input - leaves open and returns to
PGM1.
PGM1 then tries to open CTRFILE1 and fails with CPF5125.


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of
Asher613Smith@xxxxxxx
Sent: 16 December 2008 20:57
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Trigger program - open / close file question


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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.