Here are the overrides for the open query files, which are in effect before the RPGLE program is compiled and executed...
ovrdbf openqryf1 tofile(A123456789) share(*yes) ovrscope(*job)
ovrdbf openqryf2 tofile(F123456789) share(*yes) ovrscope(*job)

I am moving to a Power7 server using v7r3 to see of there is any difference in function...

-----Original Message-----
From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Daniel Gross
Sent: Friday, January 17, 2025 9:46 AM
To: rpg400-l@xxxxxxxxxxxxxxxxxx
Subject: Re: RPG Cycle doesnt work, then it does

Hi Thomas,

if I had to place a bet, I would bet on an OVRSCOPE problem.

We also had some problems with that, since the latest TR, and we had to make some changes, so everything works again. I think the default value for OVRSCOPE has changed to *ACTGRP - and maybe, in the process, the program gets called in the wrong activation group, whereas your call from the command line, might be in the right activation group.

But to be more specific, I would need to see some code.

Regards,
Daniel

BTW:
Who still uses program generators with MR functionality?
And why is the program re-generated every time?


Am 17.01.2025 um 16:09 schrieb tgarvey@xxxxxxxxxx:

Back again, from late 2024.

I appreciate all the responses to my original issue from late last year.
I've tried all of them to no avail.
I have to try being more specific in what is being done here, in the
hopes a light will go off for someone.

We have a process which generates RPGLE source code which uses the RPG
matching records function.
The files being matched are files generated using the OPENQRYF
command. The Open Query files appear as f specs in the RPGLE source
code as primary and secondary files.

The necessary overrides are all done appropriately before the source
code is generated and compiled.

While I have been primarily testing and debugging this process
interactively, I've also tested it in batch mode. The results are the same.

When the generated program is called (BTW the program object is in
QTEMP), only the INZSR is executed. The two primary and secondary
files are both in status 0011 (end of file on a read) and I know this
because I have the INFDS structures for both. So, LR is set on and
nothing in the C specs gets executed.

Since I am testing this interactively and using debug, as soon as the
first execution ends I can call up a command line and issue the very
same call command to the same generated program, as it is in QTEMP and
all the overrides are intact.
When I do that, the two input primary and secondary files have data in
them and the program executes correctly. LR is not set on until both
files have actually reached end of file.

So, how/why would the two input files, which are the results of using
openqryf, apparently NOT have data in them, and then suddenly have
data in them when the program is called from a command line?

BTW, I modified the process to call the generated program back to back
and both executions result in the apparent empty primary and secondary files.
But even then I can call the program from the command line, in the
middle of the debug session, and it works.

Any ideas?

Warm Regards and thanks in advance

Thomas Garvey
--
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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2025 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.