Re: Setting on *inlr in a service program's module..

I would consider programming a service program this way as c**p programming
of the highest order.

The other question I would have is why anyone would write a service program
these days using file I/O instead of SQL. The issue doesn't even exist but
I see people still using subroutines. I have used a subroutine exactly once
in 15 years inside of a procedure.




On Mon, Nov 13, 2017 at 12:15 PM, Hiebert, Chris <
chris.hiebert@xxxxxxxxxxxxxx> wrote:

From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Alan
Campin
--yea, but how does a *ENTRY module fit into that. You can do that and I
have seen people doing it.


Alan,
I just had to know, so tested this.
I created a module out of a *ENTRY PLIST program.
Then created the service program to export all.
Made a binding directory for the service program.

Then created an RPG program that bound to the binding directory and ran
the procedure.
In this case, LR in the procedure did allow the service program close its
files.

I also tested a DCL-PR EXTPGM/DCL-PI setup and had the same result.


So Alan is correct, *ENTRY modules do allow you to create a Service
Program that relies on LR to close files.
This works because the Module creation generates the export procedure with
same name as the module.

So there appears to be at least one way to generate a Service Program that
uses the cycle.

I have never considered creating modules out of *ENTRY programs before.



So back to the original question about setting INLR on in a module of a
service program..
It really would depend on how the modules are created.

Don't set LR if you always create service programs out of NOMAIN modules.
Most would always suggest creating service programs out of NOMAIN modules.


If you create modules out of cycle programs, then you could use INLR to
close files. Or you could code you're closes yourself.
I imagine there are some performance differences with using NOMAIN modules
vs Cycle Modules in a service program.

Chris Hiebert
Senior Programmer/Analyst
Disclaimer: Any views or opinions presented are solely those of the author
and do not necessarily represent those of the company.

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

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD