Static vs Dynamic Linking ? 
Author Message
 Static vs Dynamic Linking ?

Hi all,

I'm on contract at Ford Motor Company in England at present. Here, we use
static linking, with COBOL/370, IMS-DC & DB2. At my last place, it was
also static linking. At the place before that (where I was permanent), we
used dynamic linking.

Now, to my mind, dynamic linking is far superior to static linking.
Anyone else have any comments, or reasons why it isn't ?

--
Andy Styles.

     /o/-------------------------------------/o/


   \o\. . . . . . . . . . . . . . . . . . .\o\
   /o/ My opinions are my own, and do not  /o/
  /o/ reflect those of Ford Motor Company /o/



Tue, 26 Jan 1999 03:00:00 GMT  
 Static vs Dynamic Linking ?

dynamic linking and static linking server different purposes. You have
to choose the method best suited for the environment in which your
programs will run.  You mention IMS DC, which since version 4.1 of
IMS/ESA is now referred to as IMS TM (Transaction Manager); apologies if
you already knew that :-).              

Anyway... in an on-line environment like IMS TM additional overhead is
occurred when calling a module which is dynamically loaded.  Unless
memory is extremely tight and unable to accomodate a load module
produced with everything static linked - unlikely - static linking is
preferred for performance reasons; your transactions will run faster.



Tue, 26 Jan 1999 03:00:00 GMT  
 Static vs Dynamic Linking ?

Static Linking Versus Dynamic Linking - a topic near and dear to Topic 4
of my Planning COBOL Migration course.

Dynamic linking:  upsides -
instant effectiveness of any change to subroutines across multiple callers

Rex Widmer
Builder of software archeology tools and other strange programs to help
survive in a legacy based world.



Wed, 27 Jan 1999 03:00:00 GMT  
 Static vs Dynamic Linking ?

Static versus dynamic linkage to subroutines.

(at least for IBM mainframe users)

A small extract of several hours of discussion from my Planning COBOL
Migration course materials...

Static Linkage:  
   Plusses
      Best Performance (especially in online environments)
      Ability to automatically generate routine cross-references
      using only load modules (usefull for impact analysis)
   Minuses
      Easy to miss usage of routines used across many programs.
      (A tool that I developed solves this problem automatically)
      Necissity to relink all users of a routine
      (same tool fixes this as well).
      No "built-in" feature in run-times to handle AMODE / RMODE
      mismatch issues.
Dynamic Linkage
   Plusses
      Automatic update of all users of a routine
      Run-time handles most AMODE / RMODE difference issues
      across CALLs
      May be able to acheive better performance by pre-loading
      common routines (i.e. date converters) used across many
      applications.
   Minuses
      Performance is lower, especially with very intense call to other
      verb density, or online, response oriented applications.
      No way to easily dictionay CALL tree structure.  
          source analysis will help for CALL 'literal'
          no help for CALL dataname

Bottom line - Without (blatent commercial) auto - relinker and impact
anaysis tool Static CALLs were turkeys to manage, especially when a
routine was deployed across dozens to hundreds to thousands of load
modules.  Static structures nearly always provide higher levels of
performance.

Dynamic Calls are simpler, especially in a test environment.
Cross-reference issue can be a significant factor in both static and
dynamic environment.

Auto mode switching / checking can be a significant factor in cases where
old technology (OS/VS COBOL or earlier) must be mixed with 31-bit
capability (VS COBOL II, COBOL/370 or COBOL for MVS and VM).

Rex Widmer
Builder of software archeology tools and other strange programs to help
survive in a legacy based world.



Thu, 28 Jan 1999 03:00:00 GMT  
 Static vs Dynamic Linking ?

Quote:

>Static versus dynamic linkage to subroutines.

>(at least for IBM mainframe users)

>A small extract of several hours of discussion from my Planning COBOL
>Migration course materials...

>Static Linkage:  
>   Plusses
>      Best Performance (especially in online environments)
>      Ability to automatically generate routine cross-references
>      using only load modules (usefull for impact analysis)
>   Minuses
>      Easy to miss usage of routines used across many programs.
>      (A tool that I developed solves this problem automatically)
>      Necissity to relink all users of a routine
>      (same tool fixes this as well).
>      No "built-in" feature in run-times to handle AMODE / RMODE
>      mismatch issues.
>Dynamic Linkage
>   Plusses
>      Automatic update of all users of a routine
>      Run-time handles most AMODE / RMODE difference issues
>      across CALLs
>      May be able to acheive better performance by pre-loading
>      common routines (i.e. date converters) used across many
>      applications.
>   Minuses
>      Performance is lower, especially with very intense call to other
>      verb density, or online, response oriented applications.
>      No way to easily dictionay CALL tree structure.  
>          source analysis will help for CALL 'literal'
>          no help for CALL dataname

>Bottom line - Without (blatent commercial) auto - relinker and impact
>anaysis tool Static CALLs were turkeys to manage, especially when a
>routine was deployed across dozens to hundreds to thousands of load
>modules.  Static structures nearly always provide higher levels of
>performance.

>Dynamic Calls are simpler, especially in a test environment.
>Cross-reference issue can be a significant factor in both static and
>dynamic environment.

>Auto mode switching / checking can be a significant factor in cases where
>old technology (OS/VS COBOL or earlier) must be mixed with 31-bit
>capability (VS COBOL II, COBOL/370 or COBOL for MVS and VM).

>Rex Widmer
>Builder of software archeology tools and other strange programs to help
>survive in a legacy based world.

This is good information.  If the question is, should I use static or
dynamic subprogram linkage in an IBM mainframe environment, then I would
suggest the following recommendations:

If the subprogram is general purpose, and will be called by many
different programs (like a date routine, for example), it should be
dynamically linked.  You don't want to re-link every calling program if
the subprogram changes.  This is true even in a CICS environment.  The
overhead is small compared to the maintenance nightmares.

If the subprogram is only called from one program (for example, you want
to break up a very large program into smaller modules for ease of
understanding or to put multiple programmers on the same program), then
static linking is okay.  It will execute slightly faster, and you don't
have the same maintenance headaches.  You still have to re-link the main
program if any subprogram is changed.

Just my two cents.

Arnold Trembley
Software Engineer I (just a job title, still a programmer)
MasterCard International
St. Louis, Missouri



Fri, 29 Jan 1999 03:00:00 GMT  
 Static vs Dynamic Linking ?

Quote:

> Static versus dynamic linkage to subroutines.

> (at least for IBM mainframe users)

> A small extract of several hours of discussion from my Planning COBOL
> Migration course materials...

> Static Linkage:  
>    Plusses
>       Best Performance (especially in online environments)
>       Ability to automatically generate routine cross-references
>       using only load modules (usefull for impact analysis)
>    Minuses
>       Easy to miss usage of routines used across many programs.
>       (A tool that I developed solves this problem automatically)
>       Necissity to relink all users of a routine
>       (same tool fixes this as well).
>       No "built-in" feature in run-times to handle AMODE / RMODE
>       mismatch issues.
> Dynamic Linkage
>    Plusses
>       Automatic update of all users of a routine
>       Run-time handles most AMODE / RMODE difference issues
>       across CALLs
>       May be able to acheive better performance by pre-loading
>       common routines (i.e. date converters) used across many
>       applications.
>    Minuses
>       Performance is lower, especially with very intense call to other
>       verb density, or online, response oriented applications.
>       No way to easily dictionay CALL tree structure.  
>           source analysis will help for CALL 'literal'
>           no help for CALL dataname

> Bottom line - Without (blatent commercial) auto - relinker and impact
> anaysis tool Static CALLs were turkeys to manage, especially when a
> routine was deployed across dozens to hundreds to thousands of load
> modules.  Static structures nearly always provide higher levels of
> performance.

> Dynamic Calls are simpler, especially in a test environment.
> Cross-reference issue can be a significant factor in both static and
> dynamic environment.

> Auto mode switching / checking can be a significant factor in cases where
> old technology (OS/VS COBOL or earlier) must be mixed with 31-bit
> capability (VS COBOL II, COBOL/370 or COBOL for MVS and VM).

> Rex Widmer
> Builder of software archeology tools and other strange programs to help
> survive in a legacy based world.

In general, these are all true and correct. But in some specific cases the
tradeoffs might be more complicated: Static linkages provide better performance
than dynamic calls that search many large libraries for many subroutines; but
for a large number of big, infrequently used subroutines the initial load time
of the static module that includes them all might outweigh any savings. Or a big
load module might cause the memory management routine to thrash around and push
other modules out.

The change control issue also varies for every shop. Dynamic subprogram calls
are not used in some places because they take effect without relinking,
possibly skipping a quality assurance regression test step.



Fri, 29 Jan 1999 03:00:00 GMT  
 Static vs Dynamic Linking ?

You can use static for everything if you have the auto-relinker, and gain
the advantage of easy automated dictionaring of "where used".

Auto-relinker - a part of the Edge Portfolio Analyzer

Software archaeology - digging thru the bonepile to find gems.

Rex Widmer
Builder of software archeology tools and other strange programs to help
survive in a legacy based world.



Sat, 30 Jan 1999 03:00:00 GMT  
 Static vs Dynamic Linking ?

To complicate it even further, one can now (if one is really adventurous)
use the binder and program objects to create stuff that may be only
partially loaded at first, then demand loaded later.

You are of course correct about the tradeoffs between load time (of large
static program structures) and the cost of dynamic calls.  I beleive that
I published a paper about 15 years ago - the Miami GUIDE conference - on
"High Level Language Performance Effects on Online Systems" that detailed
the facts as they were then.  The paper is probably still sitting around
in some dusty old GUIDE proceedings books.

Of course, no cached DASD, no E-store, no LLA/VLF, but the general idea
was - if you could avoid loading lots of code (i.e. month end routines) on
each tran, then the rare times that you needed it you could afford the
price.  Another concept in that long forgotten paper was "called groups",
where groups of subroutines were linked together statically, then called
dynamically.  Thus the number of dynamic calls (which were quite expensive
due to directory search times) could be minimized, yet the load time
savings could still be realized.

Rex Widmer
Builder of software archeology tools and other strange programs to help
survive in a legacy based world.



Sat, 30 Jan 1999 03:00:00 GMT  
 Static vs Dynamic Linking ?

Quote:

>You are of course correct about the tradeoffs between load time (of large
>static program structures) and the cost of dynamic calls.

I suspect that it is not 100% directly equivalent but it might be worth
considering IBM's behaviour as far as the RES/NORES compile option is
concerned.  My understanding of the RES option is that it controls
whether the COBOL library routines are located dynamically at run time,
or are link-edited in to the same load module with the COBOL program.
Compare this with DYNAM/NODYNAM and as far as I can see the difference
is in who wrote the program.  An IBM 'subroutine', which we'll call a
library routine, is controlled via the RES option whereas our
subroutines are controlled via the DYNAM option.

Now the important bit.  All 'COBOL for MVS and VM' programs are going to
be RES, the compiler will not accept a RES/NORES parameter. So, in IBMs
opinion, the cost of locating and loading the library routines is
preferrable over having big, static load modules, which require
relinking to gain any benefits from any run-time environment changes.
I know there are options of placing the modules into shared storage,
LPAs etc, but then you can do this with your own subroutines. The
'COBPACK' appears to be history as well, but I am not swearing to that.

So, the benefit/cost argument over dynamic/static linking, as far as
library routines are concerned, has been won in favour of 'dynamic'
locating and loading at ru time.

This does skate over a few issues but the general principle holds true
(I think!).

Jon



Sat, 30 Jan 1999 03:00:00 GMT  
 Static vs Dynamic Linking ?

Must be carefull....

DYNAM only affects CALL 'literal', makes such calls dynamic resolution

CALL dataname is always dynamic, and has required RES since it was first
available (ANSI COBOL V4, circa 1972).

RES is the only game in town for COBOL/370 and later compilers...

COBPACK is still quite real, it greatly reduces the overhead to
iniitialize the run-time system, since most of the run-time interconnects
are pre-resolved within the COBPACK.

BTW, I recommend taking a dozen or so modules out of one's COBPACK so that
the resultant COBPACKs wind up with RMODE(ANY) and can live above the
line.  This is still needed with LE - especially important when run-time
is in LPA/ELPA.

Rex Widmer
Builder of software archeology tools and other strange programs to help
survive in a legacy based world.



Tue, 02 Feb 1999 03:00:00 GMT  
 
 [ 13 post ] 

 Relevant Pages 

1. static vs dynamic linking with GNAT

2. Static vs Dynamic Linking

3. Static vs Shared: Linking tcl83s.lib vs tcl83.lib

4. Interesting link on static/dynamic typing...

5. Static/dynamic linking with Fujitsu COBOL V3.0

6. static and dynamic linking

7. Static vs Dynamic Typing: Effects on Productivity?

8. Dynamic vs. static type checking

9. Types, types: static vs. dynamic -- classification

10. Types, types: static vs. dynamic --

11. Types, types: static vs. dynamic -- classification

12. Static vs Dynamic Typing: Effects on Productivity?

 

 
Powered by phpBB® Forum Software