Subject changed ...
In our shop we have no static linkage at all - all modules are linked
dynamically
during run time by means of MVS LOAD and BASR - this is done by home grown
interface modules which do the transfer of program control. This was
first implemented
for an ASSEMBLER only environment and then promoted to PL/1 and C - with
PL/1
in the beginning, dynamic calls were not supported over more than one
level, but
with our interface modules, it was always possible.
This enables us to use the same modules in online environments like IMS
and in
batch, no difference. The batch main programs only do the global
control, normally,
and for the detail work, they call the modules dynamically - which are
the same as
in the online environment.
Modules can be changed without changing the callers, as long as the
interfaces
(parameters etc.) stay the same. To minimize errors with parameter
communication,
we generate macros from a repository which have to be included by the
callers
and by the called modules - so there is no misunderstanding about the
interfaces.
The interfaces do some sort of version control. There is even some kind of
automatic version switching, if interface versions are different (only
for a limited
amount of time, to support a smooth interface migration - if desired). The
language of the caller and the callee can be any of the three supported
languages - doesn't matter.
Static linkage is no option for us, because the modules which are used
in many
contexts would be duplicated this way - and because, if a module is
changed which is
used in some hundred batch programs, you would have to relink them all.
We never
have to do this.
BTW: NORENT option in PL/1 and C, no DLLs. The load libraries are
traditional
PDS datasets (no PDSE at the moment). The interface modules which do the
transfer support PDSEs and the RENT option, because we had it from 2003 to
2006 - with an early version of the PL/1 Enterprise Compiler - but at
the moment
we don't use it.
Regarding error handling: we have home grown error diagnostic routines
(LE exits)
that do a pretty good job in diagnosing and recovering errors, so it is
no problem
for our developers to diagnose the errors - if any - which come from
possible
parameter or interface differences. It is necessary to do this, because
due to the
large applications we have, there are some ten or twenty persons
involved in every
single batch application (of course, there are also some simple applications
which are coded by only one person, but that is the exceptional case).
Kind regards
Bernd
Am 26.10.2013 22:52, schrieb Ed Gould:
John.
The companies I have worked (except for one) were all COBOL.
They learned early on that when one of the COBOL subroutines abended
(started with the ILC modules if memory serves me)) at 0030 in the AM
someone got rolled out of bed to fix it. COBOL programmers that I have
worked for are risk adverse and did not want things like this to
happen. They wanted an environment that once tested it worked
*FOREVER* which was likely not to happen with DYNAM. Forget load
module size they wanted write once run forever. They would much rather
have a S0C4 in the daytime hours to debug than at 0030 . I have worked
in banking (granted 40 years years ago) and the few COBOL programs
that I was exposed to were linked statically and thus was standard.
I personally have been rolled out at 0100 many times because of a S0CX
in one of the cobol subroutines (I didn't write it the main program)
since it was an IBM module I got called and had to hand hold the
programmer to get it it running again. It was *usually* a combination
of relinking a cross release of ILC programs that were were not friendly.
Statically linked programs were also at risk but usually not to badly
and were not fun to track down as a result, so there are no universal
rules). It was simple to just recompile and relink all the programs in
question.
Assembler programmers were less likely to have issues as they were
well aware of "foreign" changes and were not likes to point the finger
at IBM software.
I would have to disagree (to a point) about measurements for loadlibs
because at several places I had QCM and it would publish numbers at
step termination time about I/O times about JOBLIB/STEPLIB times and
you could actually tell how how much time fetch took for each
library. Granted QCM is no longer sold but we did use it to its full
use when it was available.
Ed
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
