Re: Binding Directory question

Have you considered using my Make tool at www.think400.dk/downloads?
Look for COMPILE.

COMPILE just allows you to put the instructions for how to create the
program in the header like so.

*_> CNLLSTSPLF SRCFILE(@2/@1) SRCMBR(@3)
*_> DLTPGM PGM(@5/@4)
*_> CRTPGM PGM(@5/@4) MODULE(EDI204_M01 EDI204_M02 +
*_> EDI204_M03 EDI204_M04 EDI204_M05 EDI204_M06 EDI204_M07 +
*_> EDI204_M08 EDI204_M09 EDI204_M10) +
*_> ENTMOD(*FIRST) BNDDIR(ILBNDDIR) +
*_> ACTGRP(QILE)

This clear advantage here is that what you need to bind for each
program is in the header.

You indicated you had some sort of build tool now. What I have done is
modify out check tool to look in the header and if finds the *_>
flags, it uses COMPILE to create the object.

I agree with Birgitta though. Get to service programs as soon as possible.

The one problem I see is that the way you write a service program is
different in many ways to how you write a procedure in a program.

In the procedure in the program you know what is coming in. In a
service program, how the program gets called may be different in
different programs.

Makes it a lot more interesting.


On Fri, Jan 23, 2009 at 11:05 AM, Birgitta Hauser
<Hauser@xxxxxxxxxxxxxxx> wrote:

May be not over night but in a week end, assumed there are no duplicate
exported procedure names:
1. create a binder source for each module, where the exported procedures are
listed. (This can be done without changing anything)
2. create a service program for each module that is not directly called,
i.e. bound to one or several programs (Service program name = module name)
As long as only the modules are bound to the programs there will be no
problem.
3. Create a new binding directory where all your service programs are listed
4. Recreate your programs (all those modules that are directly called) by
using this binding directory.
CRTBNDRPG with specifying the new binder directory will be enough.
5. Delete all your modules

It will work as long as you have no duplicated exported procedure names.

Mit freundlichen Grüßen / Best regards

Birgitta Hauser

"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"

-----Ursprüngliche Nachricht-----
Von: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] Im Auftrag von David FOXWELL
Gesendet: Friday, 23. January 2009 15:55
An: Midrange Systems Technical Discussion
Betreff: RE: Binding directory question

Jon, I have understood the problem for quite a while now, thanks to this
list.

But when you have already 2500 modules that are shared in this way, ie
copied many times in many programs, how many exactly I don't know, you can't
just change to service programs overnight. It's like a big ocean-going
liner. 5 mile turning circle and all that.

-----Message d'origine-----
De : midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] De la part de Jon Paris
Envoyé : vendredi 23 janvier 2009 14:48
À : midrange-l@xxxxxxxxxxxx
Objet : Re: Binding directory question


On 23-Jan-09, at 6:54 AM, midrange-l-request@xxxxxxxxxxxx wrote:

All our modules are bound by copy.
When a module is modified, all programs using that module are rebound
automatically by our installation tool.
This is causing more and more headaches, ...

Without wanting to sound rude - this question is really in the category of
"Doctor, doctor - it hurts when I bang my head on the wall".

Binding by copy is primarily intended to provide the best call performance
in a "one caller to one callee" situation. Bind by reference (Service
programs) is intended for the "Many callers one callee" situation - i.e.
code reuse of the kind you describe.


So the basic solution is the same as that to the doctor question "Stop doing
it" and start using service programs.


Jon Paris

www.Partner400.com
www.SystemiDeveloper.com


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

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


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