×
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.
My understanding of the case for using binder language in the case of having multiple modules in one service program is that one can restrict the scope of the exported procedures to only the service program itself so that the modules can use each others procedurs without having to share them with the rest of the world.
If you have just one module you don't have to share the procedures within the service program, so you just don't export them from the module. So no binder language is needed.
Mihael
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Barbara Morris
Sent: Thursday, January 13, 2011 11:30 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: CRTSRVPGM
On 2011/1/13 7:32 AM, dieter.bender@xxxxxxxxxxxx wrote:
there are very few cases binder language might be usefull:
- binding multiple modules to one SRVPGM
I don't see how a one-module-per-srvpgm rule helps to avoid binder language.
If you are willing to recompile all the programs when you change a
service program, then you don't need binder language no matter how many
modules are in the service programs.
But if you want to avoid recompiling all the programs, then it isn't
sufficient to have only one module in each service program. You also
need to limit it to only one exported procedure per module. I think the
awkwardness of binder language is trivial compared to the awkwardness of
a constraint that only allows one procedure per module.
midrange.com
