AW: problems with program binding -- MIDRANGE-L

sorry for mixing binder language and binding directory. of course they don't 
have the same purpose and functions.

overhead with using binder language: for some people it ain't a problem and 
some just doesn't like to use it and say it is too much overhead. it all 
depends on the laziness of the developer =)))

but it seems binder language is the way to go.

thanx for the answers.

mihael

-----Ursprüngliche Nachricht-----
Von: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] 
Im Auftrag von Scott Klement
Gesendet: Freitag, 8. Dezember 2006 20:31
An: Midrange Systems Technical Discussion
Betreff: Re: problems with program binding

but now he calls the program (which is in prod) and it brings an error
(MCH4431). translation: Invalid programsignature.

it seems that the program tries to call the procedures from the
serviceprogram in test (which is in libl before prod).


This isn't any different from any other situation where the library list 
is used.  IF he tried to open a file that exists in both test and prod, 
he'd get the one in test because it's higher in his library list.  If he 
tried to access a display file, same problem.  Call a program, same 
problem, read a data area, same problem.

That's just how library lists work, they find objects in order of the 
libraries listed in the library list.  If you want to access the one in 
the production library, either specify the library name explicitly, or 
remote the test library from the library list!

how can this dilemma be solved? is the only way out the use of the
binder language? that seems a lot more development overhead than having
a binding directory.


Binder language controls the signature(s) that are associated with a 
service program.  Binding directories tell a program where to find service 
programs or modules so that they can find a particular subprocedure.

The two serve very different purposes.  You can't replace binder language 
with a binding directory or vice-versa!

Furthermore, binder language does NOT require any significant overhead. 
Binder language consists of 3 fields that you can set, followed by a list 
of exported subprocedures.  That's it:  3 fields, and a list.  For someone 
who is familiar with binder language, it requires almost no time.  I've 
been using them for 10 years now, and have written more than 1000 service 
programs.  I think the total time I spent working with binder language 
over those 10 years is under an hour.  I don't mean 1 hour per project -- 
I mean 1 hour total for everything I've done in 10 years.

The amount of time that binder language SAVES, however...   It has easily 
saved me more than 500 hours of time, because I can keep my service 
programs backward compatible, and therefore can avoid recompiling programs 
everytime the service program, a file definition, etc, changes. Binder 
language is one of the simplest tools in the world of ILE, and one of the 
ones that has saved me the most development time!