RE: binding directories

Barbra,
>From early ILE days I began creating modules for application logic that was
previously in a subroutine but might be useful to include in similar or
subsequent application. It seemed prudent to create a binding with the same
name as the program so that I could use a PDM option to submit a CRTBNDRPG
as usual. I figured that this would also benefit subsequent developers who
could recompile the program without having to understand all the binding
details.

It appears that more recent developers have really got the ILE bug and have
seem to have developed a penchant for deciding that everything they code
must be such a good idea that they try to make it generic and either create
a new service program or add the procedure to another service program for
posterity. My observation is that it takes a month of Sundays to jump in and
out of source members to figure out what's going on.

It seems difficult for me to argue why developers should not create so many
service programs since they argue the benefits of maintenance without
recompiling.

I would value your sage advice as to when you would use modules and/or
service programs.

Cheers, Peter

-----Original Message-----
From: bmorris@ca.ibm.com [mailto:bmorris@ca.ibm.com]
Sent: Tuesday, October 23, 2001 3:23 AM
To: rpg400-l@midrange.com
Subject: RE: binding directories



>Date: Sat, 20 Oct 2001 20:28:51 -0400
>From: "M. Lazarus" <mlazarus@ttec.com>
>
>At 10/19/01 11:29 AM -0400, you wrote:
>>I would never put service programs and modules into the same binding
>>directory.  The risk in combining them is that you accidentally bind
>>the same module into more than one program.  Shudder.
>
>  How?  I'm assuming that you mean that the module is contained in the
>*SRVPGM and that the *MODULE exists on its own and that the *MODULE is an
>earlier entry in the binding directory.

mark, I was thinking about the case where a program is created from
multiple program-specific modules, possibly also using service
programs.  Those program-specific modules wouldn't be also in service
programs, since they would only be needed by one program.

In a perfect world, those program-specific modules would never have any
functions useful for other programs, so the danger I was talking about
would never arise.  But you'd still need perfect testing, so that one
program couldn't say by accident reference by name an exception handler
intended for another program, with the error never found until long after
it goes into production.  For example, say programA has an exception
handler called file_not_found, and programB needs such an exception handler
too, but needs it to do something else.  Programmer B writes his program
to use a handler called file_not_found but forgets to write it and
forgets to write a testcase for it; the binder finds it, and the program
compiles and everything seems fine.

I realize that some people create service programs even for program-
specific sub-modules, but that has never made sense to me.  The danger
of putting program-specific code into a service program, especially
one put into a common binding directory, is the same problem I just
talked about: that programA picks up a procedure meant only for programB.
Requiring every submodule to be generic so this situation could never
arise seems unnecessarily harsh.

Barbara Morris

_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
or email: RPG400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

This communication is confidential and may be legally privileged.
If it is not addressed to you, you are on notice of its status.
Please immediately contact us at our cost and destroy it.
Please do not use, disclose, copy, distribute or retain any of it
without our authority - to do so could be a breach of confidence.
Thank you for your co-operation.
Please contact us on (09) 356 5800 if you need assistance.