Re: Address of Variable in Service Program Exported Procedure

[Buck Calabro <kc2hiz@xxxxxxxxx>]

It's hard to tell what the business problem is, so this is generic advice.

One reason for a service program is to keep variables that are inside
the service program isolated from outside callers.
One can defeat this with EXPORT and IMPORT but I never, ever do this:
not even once.

If the outside needs to know something about the inside of a service
program, make it a parameter.
One way to do that is to make a SET and GET subprocedure which lets a
caller change and inspect internal variables. One synthetic example:

service program
// service program global variables
dcl-s files_opened ind inz(*off);
...
if files_opened = *off;
  open file1;
  open file2;
  files_opened = *on;
endif;

Say a caller has some reason that it needs to know the value of
files_opened. I'd make a GET subprocedure and add it into the service
program:

dcl-proc getFiles_opened export;
  dcl-pi *n ind;
  end-pi;

  return files_opened;
end-proc;

Now when the caller wants to know if the service program has files
opened or not, it does:

dcl-s sp_files_opened ind inz;
sp_files_opened = getFiles_opened();

The caller can't mess about with internal variables in the service
program, and it doesn't need to know anything about how the service
program maintains internal state.
  --buck

On Mon, 7 Nov 2022 at 09:53, Vinay Gavankar <vinaygav@xxxxxxxxx> wrote:
> Hi,
>
> We have an exported procedure in a Service program (RPG) which needs to
> pass back the address of a variable, so that the calling program can
> use the value in that variable.
>
> Can the calling program (RPG) access the value of the variable if it is
> defined within that exportable procedure, or does the variable need to be
> 'global' in the Service Program?
>
> TIA
> Vinay
> --
> 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