Chris Phinicarides wrote:
Hello!
We use relocatable routines which are called from within our programs.
The routines' compilation produce object (not load module), which, as I
know, is used during the programs' link-edit.
As far as I understand, when a relocatable changes (and is recompiled for
the production of a new OBJ), the programs using it have to be re-compiled
for "attaching" its object to their load module (during link-edit).
Not at all. You can not run without linking (although the Linkage
Editor is dead; long live the program binder).
For some reason, PL/I shops have tended to keep object code
and they do a lot of re-linking (excuse me, re-binding). But
the need for working this way is long gone. You have two
major choices:
1. If you call your routines statically, then when you
change a subroutine its source must be recompiled
and bound; then you can do a re-bind of the caller
and your back together; no need to do a recompile
2. If you call your routines dynamically, then when
you change a subroutine its source must be recompiled
and bound; that's it. The caller always gets the
one and only most current version automatically,
so no need to touch the calling program at all.
Although there are times when static calls may be
required, generally speaking dynamic calls are the
way to go.
The first question is whether my understanding is right.
No. see above.
My second question regards DB2 relocatables used within DB2 programs: How
should they correctly be treated for having their DB2 BIND in sync with the
programs' corresponding load module?
When you have a DB2 program that has embedded SQL, you must
pre-compile; this produces a DBRM and a modified version of
your source; the DBRM must be [DB2] bound to produce a plan
or a package that is part of a plan; the modified source
must be compiled and [program] bound (link edited; too bad
about using the word "bind" for both processes).
When you run a DB2 program, you specify the program name
and the plan name, directly or indirectly, and DB2 checks
they are in sync. Again, if a subroutine has SQL calls in
it, but its caller does not, it is only important that
the subroutine be kept in sync with its plan; the caller
does not matter.
Hope this helps.
Kind regards,
Any explanation and/or reference is welcome.
Thank you.
Chris.
--
-Steve Comstock
The Trainer's Friend, Inc.
303-393-8716
http://www.trainersfriend.com
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
