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/

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.

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.

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.

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

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.

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.

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.

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

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.