Ok,
the modules being in read-only storage is currently not supported by our
approach.
Another drawback is, that if there are different callers to the same
routine, every
caller has to do the LOAD once, until it has it's own copy of the EPA in
its static CSECT,
which leads to many unnecessary LOADs.
The EPAs were originally (in the 70s) stored for performance reasons. I
believe that
then, when LOAD was issued, the CDE list was searched sequentially to
lookup the
loaded modules, and this was very slow, when there are some thousand
modules in
the CDE chain (which is the case in our IMS dialogs).
I don't know exactly how LOAD works today. So some ten years ago I
thought about
a solution where I call a service module storing the module names and
EPA addresses
in a balanced tree structure (like AVL tree), to shorten search times -
but management
decided that we stay with the current solution, and I got no budget to
do this. If we had
this, there would be no need to store the EPA address in the caller's
CSECT. There
even would have been the possibility to store some meta data about the
called module
in the tree, for example: programming language (which is examined by
reading the
IDR records today), the AMODE (which was sometimes 24 in prior times),
or the department
which is responsible for this module (which has to get the alarm mail,
in the case
that the module abends).
Another topic:
I don't know if it is possible to put all modules into read-only
storage, because some of
the application modules anyway store statical information (although they
are supposed
to be RENT). At our site it's kind of common that some math modules
store the
entry parms and the results from the last call statically, so that in
case they are called
again with the same parms, they don't have to do the calculation over
and over again.
I don't know, if they all do proper ENQ/DEQs around the critical path ...
well, that's all for performance reasons ...
Kind regards
Bernd
Am 27.06.2013 22:35, schrieb John McKown:
Getting too complicate for this particular need. And cannot dynamically
modify the program itself because we want the programs in CICS to be loaded
into "read only" storage (ERDSA). That's the whole driving force behind
making the HLASM re-entrant. Original problem is memory overlays by errant
CICS user programs. Which, by happy "chance", I found yesterday because the
nasty program tried to overlay a CICS control block and abended S0C4-4. So
I could finally give the programmer an exact cause. The cause: storing
beyond the bounds of a GETMAIN'ed area.
On Thu, Jun 27, 2013 at 3:20 PM, Bernd Oppolzer
<bernd.oppol...@t-online.de>wrote:
To be able do to maintenance to such subroutines that are called from many
other places, we usually put them in a module that is called dynamically.
We do
this using MVS-LOAD and we store the EP address statically in the calling
modules
CSECT (the LOAD is done, if it's zero, if not, it's already there).
If the calling language doesn't support dynamic calls in an easy way, we
link a little
ASSEMBLER stub to the calling module (let it be PL/1 or COBOL or any other
language)
that only does the LOAD and stores the EPA.
This works for us under IMS/DC control, too, and it should work with CICS,
too. The
only concern is, that the modules needed may have to be preloaded prior to
the
start of the CICS main task (don't know much about CICS, but with IMS,
this could be a
problem, because the modules would otherwise disappear).
The modules are never DELETEd
until termination of the main task.
Kind regards
Bernd
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
