Re: ILE and locked file -- RPG400-L

Thanks Jon,

The very first thing I did was implement the rclactgrp myActGrp after the
first procedure call from my CLLE.
Ran into "try to refer to an item previously in memory" error... not the
correct working but I'm sure you know the one I'm talking about. (common
with ILE actgrp stuff)

So I have moved my code from the *SRVPGM to a *PGM that now runs as *CALLER
(like the calling pgms)... about to test.
I'm sure it will probably work.

Jay

On Wed, Jul 20, 2022 at 12:30 PM Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:

The big difference is that with *New the whole AG is collapsed on exit.

With running in the DAG the only time anything gets cleaned up is when the
job ends.

So there are two possibilities. 1) Your code has problems and is leaving
files open. 2) IBM has problems and under the covers is leaving things
open.

You can get past it by running in a named AG (which *New is) and
reclaiming on return. That means either your problem program has to run in
a named AG or the program that calls it does. If that causing problems
(overrides maybe?) then they need to be fixed.

If you are sure there are no problems with your code then call IBM and in
the meantime decide what is the problem with the workaround and deal with
it.

Jon P.

On Jul 20, 2022, at 10:59 AM, Jay Vaughn <jeffersonvaughn@xxxxxxxxx>

wrote:

Daniel, and yes the pgm that calls the *CALLER does run in the DFTACTGRP.
So let's go with this is a bad idea (I did not implement this btw :))
How can that be impacting my situation? Not really concerned about other
adverse reactions from this... I need to identify my issue.

Jay

On Wed, Jul 20, 2022 at 10:46 AM Jay Vaughn <jeffersonvaughn@xxxxxxxxx>
wrote:

Daniel,

I did try the rclactgrp of my named actgrp prior to each subsequent
callprc and that caused even bigger issues.

in my *MODULE source I have the following...
exec sql
set option
commit = *NONE,

so commitment control should not be an issue, I wouldn't think.

Jay

On Wed, Jul 20, 2022 at 10:37 AM Daniel Gross <daniel@xxxxxxxx> wrote:

Hi Jay,

just a thought, but "who" is calling the CLLE with *CALLER? Is the

caller

in the DAG? With *CALLER it is possible that the CLLE is running in

the DAG

- which is most probably a bad idea.

Does it help, if you do a RCLACTGRP <your_named_actgrp> ?

Another thought - what about commitment control? Have you committed or
rolled back your changes?

Without the concrete source source, it's hard to diagnose that issue.

HTH
Daniel

Am 20.07.2022 um 16:18 schrieb Jay Vaughn <jeffersonvaughn@xxxxxxxxx

:

I have a *SRVPGM that runs in a named activation group.
It contains a procedure that does the following...
- dltf qtemp.file
- create table qtemp.file
- inserts/updates the qtemp.file

From a CLLE pgm that runs in *NEW, I am testing this procedure call in

the

*SRVPGM.
The procedure is called 4 different times with no issues. Expected

results

for each call.

Now I place those same 4 calls to the procedure into a different CLLE

that

runs in *CALLER (this may have nothing to do with it but just throwing

it

out there).
On the 2nd call to the procedure when it tries to do the DLTF, it

cannot

allocate the file and fails.
I have tried to DLCOBJ the file from lock state *SHRRD prior but that

does

not work.
(when i do a wrkobjlck on the qtemp.file I see it is locked with

*SHRRD)

What are my other options to overcome this? Why does it not do this

in

my

test CLLE?

tia

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

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription

related questions.

Help support midrange.com by shopping at amazon.com with our

affiliate

link: https://amazon.midrange.com

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

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription

related

questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com

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

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription

related questions.

Help support midrange.com by shopping at amazon.com with our affiliate

link: https://amazon.midrange.com

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

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com