Barbara,
thanks for your response!
I will try to elaborate a little.
@one module per SRVPGM and Binder language:
RPG has two scopes for a procedure private and exported, using Binder
language exported is divided in SRVPGM and public. If you have only one
module in a SRVPGM both scopes are the same.
@binding by copy and binding by reference:
Having more than 1 module in a SRVPGM means, to bind some modules by copy
together, to bind this bundle (called SRVPGM) by reference to other SRVPGMS
and PGMs. Binding by copy has 2 serious drawbacks, you could have version
conflicts and the impact of changes of signatures is greater. One way to
solve this, the easy way, is to avoid binding by copy - with this you are at
the point to have many SRVPGMs, each containing one module!
@compile:
Most of us using Java, are using Eclipse and with this, you never would
press a button compile. Every Snippet of Code is compiled by this tool, as
you are typing in Code. Changing a signature of a method (= procedure),
other classes in the project are compiled in the background, as you are
typing and no binder language or similar funny things are used. There is a
Compiler working in the background, compiling the complete project if
needed, or a single class, if sufficent. If the compiler could not decide,
what has to be compiled, it compiles everything, maybe more than once if
classes depend on each other.
Compiling one source or many is no work for the programmer, but for the
machine and compiling the whole project for every deployment has a big
advantage: there would never be a delta between your sources and your
application running in production.
As a conclusion of this, my recommendation is: don't invest any effort in
minimizing compile or bind, invest the effort in automizing compile and
bind!!!
@simple strategy:
- don't use bind by Copy
- write the compile command with all parameters as a comment in the Source
- mark this part of the comment
- use a precompiler to create the objects by pulling out the marked comments
from the source
- write make files to compile a sub project or project
With this you don't need Binder language and no Binding directories and your
compiles are completely reproducable!!!
BTW: such a simple precompiler is to be found at my Freeware Sitte (sorry:
german) www.bender-dv.de)
@midsized strategy:
- write some simple CLs to extract a repository with cross references (based
on DSPMOD ...)
- write a generic make to minimize compile and bind
BTW: I didn't find the time up to now to put this stuff to my Freeware site,
but it took me only a few days to write it!
@who needs more:
thats a very interesting topic and I have discussed this with Mihael a
couple of hours, its a never ending story, whenever we meet together,
somewhere in Germany.
Mihael needs more, because he provides SRVPGMs with many exported procedures
(have a look to his great Freeware Site rpgnextgen.com). His SRVPGMS are
used as components in applications he doesn't even know, so he can't rebind
anything, if a SRVPGM is extended. Using Binder language, he could package
some modules into one SRVPGM to simplify deployment and to controll which
procedures could be reached by applications he doesn't even know of.
I needed more for ArdGate as a possibility to make it run without adding
anything to the LIBL. I have bound two modules by copy to one Program, but
here I didn't need binder language.
Application providers could need more to have fewer Objects to deploy, I'm
in a process of thinking about this: in Java you would deploy simply a jar
archive (or even a ear or war package). Maybe it would be better to enhance
the deploy process itself, by sending install packages for automatic
deployment...
Dieter
--------------------------------------------------
From: "Barbara Morris" <bmorris@xxxxxxxxxx>
Sent: Thursday, January 13, 2011 11:30 PM
Newsgroups: midrange.midrange-l
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.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
midrange.com
