On Oct 26, 2013, at 5:27 PM, Bernd Oppolzer wrote:
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.
Good examples. Way back when (1970's) COBOL modules for the most part
were "standalone" (except for one assembler subroutine which handled
"database" calls).
The subroutine was not used extensively in all cobol programs. My
memory says it was dynamic (but I could be wrong) so 90++ percent of
programs were statically linked.
That was true that when the routine changes (very sporadically and
nobody had to be consulted) I don't recall of the routine ever having
an issue (I probably only would have known if it bombed) the code was
well written.
Ed
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
