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



Scott,
Thanks for the detailed explanation as usual.

Here is what was happening. My program was in a named activation group
calling a program in the default activation group. So when I did the
OVRDBF, (which I agree is kludgy), I didn't specify the scope.

The called program is called not only from my program but other CL
programs so instead of changing the interface to the program I just added
the H-SPECS DFTACTGRP(*NO) ACTGRP(*CALLER) and that solved my problem. No
need to change any of the code anywhere else.


Thanks
Bryce Martin
Programmer/Analyst I
570-546-4777



Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
04/28/2010 03:00 PM
Please respond to
RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>


To
RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>
cc

Subject
Re: How to get called program to write records to physical file member.






Howdy Bryce,

I have a program, in that program I use QCMDEXC to create a new member
on
a physical file. Then I do an OVRDBF to that member. I then call
another
program - yes program, not a module or service program, to write some
records to that file.

Did the called program already have the file open before the ovrdbf ran?
If not, is the called program running in the same activation group, or
a different one? If it's a different one, did you set the ovrscope
parameter to include other activation groups?

Have you considered passing a parameter with the member name, and using
the EXTMBR keyword in the called program? IMHO, that would be a lot
cleaner than OVRDBF.

Then I call a procedure from a module that is bound to my program to
do some stuff and read from that member I just created and populated.

Which program is it bound to? The first one? Or the called one that
writes the records?

If it's the first one, then the problem seems to be the override
scope/activation group. If it's the second one, the problem seems to be
the file being open before the OVRDBF is issued.


Can someone explain why the called program doesn't retain the OVRDBF to
the proper member and what I can do to fix this?

OVRDBF only applies to a file when the file is opened. It has no impact
any other time.

The default value for the OVRSCOPE parameter of OVRDBF is *ACTGRPDFN
meaning that the behavior is "activation group defined" (i.e. it depends
on which activation group the OVRDBF was issued from.)

When issued from the *DFTACTGRP (the OPM activation group) the OVRSCOPE
parameter will be *CALLLVL, meaning that it affects programs called from
the one that does OVRDBF as well as any programs called by that called
program, and so forth, recursively.

When issued from an ILE activation group, it only affects opens that
occur in that activation group.

Changing the OVRSCOPE parameter to OVRSCOPE(*CALLLVL) makes it work in
ILE the same way it did in OPM.

Is the only way to do it
by passing the member name to the called program so it can do its own
OVRDBF?

I would eliminate OVRDBF which I've always thought was a yucky kludge.
Pass the member name as a parameter, and use EXTMBR on the F-spec to
control which member is accessed. Much cleaner.

But, no... the OVRDBF from the caller will also work, if coded correctly.

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