Limiting exported procedures:

By using the export keyword on the procedure but not putting it in the
binder source you have set the scope of the procedure to the service
program only. Means that you can call the procedure from any other
procedure in the same or other modules IN the serviceprogram but not
from OUTSIDE the service program.

This technique only matters if you are using multiple modules in one
serviceprogram.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of David FOXWELL
Sent: Monday, September 28, 2009 1:51 PM
To: Midrange Systems Technical Discussion
Subject: RE: Binder Source

-----Message d'origine-----
De : midrange-l-bounces@xxxxxxxxxxxx
No. Binder source defines the public interface for the
service program.

Thanks, I'm reading Who Knew You Could Do That with RPG IV and wondering
why I would use binder source to limit the number of procedures
available. Why would you have an exported procedure if it wasn't
available? Also, it suggests to use binder source and not use
EXPORT(*ALL). I'm confused.


Program code is demand paged so only a small proportion
of the program code will be in main storage at any one time.
Program code is shared between users. All static variables
will require separate storage in each job.

Looked closer at the 2 versions of the program and found in program
statistics, static memory size has gone from 19872 to 4441296. Is that
worse? That's 223 times more.

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