×
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.
True, but do so means circumventing the "scoping rules" which is what I was
saying. Normal methods don't let you do it. This would be just like saying you
can't access local variables from outside the subprocedure--certainly if you
circumvent the scoping rules you can do anything you want. It is software after
all.
-Bob
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [
mailto:rpg400-l-bounces@xxxxxxxxxxxx] On
Behalf Of Jon Paris
Sent: Thursday, May 31, 2007 5:44 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: RE: Calling a Procedure from Another Program
However, other scoping rules apply. The next scoping rule is that
subprocedures can not be called from outside of their *PGM.
This isn't completely true Bob. It is perfectly possible to have a
conventional *PGM object act as a SRVPGM - with the advantage (?) that the
normal LR rules etc. can be applied.
I worked with a UK business partner some years ago to implement a system
based on this notion. Admittedly you cannot simply call the exported
procedures in the "conventional" way since the *PGM requires activation
before its subprocedures can be called.
The method is simply to call the *PGM and have it hand back one or more
procedure pointers to its subprocedure(s). They can then be called with no
problems. The procedures do not need the EXPORT keyword - actually they
don't in a *SRVPGM either if it called by procedure pointer.
Jon Paris
Partner400
www.Partner400.com
midrange.com
