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



I was under the impression that a new instance of a service program (with
AG *CALLER) would be activated for each activation group. I thought the
activation group boundaries would prevent any kind of file collision or ODP
sharing between activation groups.
Is that not correct?
Unless of course a specific OVRDBF scoped to *JOB was in place.
This has been a very interesting thread.

Thanks everyone....


On Thu, Aug 21, 2014 at 9:42 AM, <j.beckeringh@xxxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:

OP also claimed: "... all the programs (CLLE & RPGLE) in the job stream
have the same defined activation group" :-)

In my scenario I only tried to demonstrate the possibility that the
service program could have been called in more than one activation group,
which might have caused the problem. Alternative scenario: P1 called P2
and P3; P2 processed a few records and P3 blew up.

Joep Beckeringh


CRPence <CRPbottle@xxxxxxxxx>

Subject:

Re: Why would a file in a service program get closed?

On 21-Aug-2014 04:30 -0500, j.beckeringh wrote:

Imagine this scenario:

1: Program P1 calls the initialization routine <ed: of the srvpgm>
2: Program P1 calls program P2
3: Program P2 calls another routine in the service program that
reads a file
4: Program P1 calls the exit routine

Assuming the service program has *CALLER it opens the files in the
activation group P1 runs in. But it reads the file in the activation
group P2 runs in. So as long as P1 and P2 run in the same activation
group everything is hunky dory. But when they don't, step 3 blows
up.

Roger stated 'At this point, I'm thinking I screwed up the named
AG.'


Yet surely that scenario contradicts the claim that "As to the file
never being opened - not the case. This occurs a few records into the
process so the procedure already executed several times."? As I
understand the scenario presented above whereby the AG were setup
incorrectly, then the P2 never could have processed "a few records"
because the file was never opened [to the AG in which the READ activity
runs]; i.e. the first I/O would have failed with the same error status,
such that only _zero records_ could have been processed.

--
Regards, Chuck
--
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (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 ...

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.