How to avoid storage accumulation under REXX's Adress LINKMVS ?
Jan Vanbrabant
Hi,
I have a REXX program, calling an assembler pgm, via
Address LINKMVS "SBSY100" msg .
It executes fine ... a couple of times,
BUT after a while I get this abend:
IEW4000I FETCH FOR MODULE DBINFPR FROM DDNAME STEPLIB FAILED BECAUSE
INSUFFICIENT STORAGE WAS AVAILABLE.
CSV031I LIBRARY ACCESS FAILED FOR MODULE DBINFPR , RETURN CODE 24,
REASON CODE 26080021, DDNAME STEPLIB
CSV028I ABEND106-0C JOBNAME=S783RPNG STEPNAME=G
$HASP375 S783RPNG ESTIMATED LINES EXCEEDED
IEA995I SYMPTOM DUMP OUTPUT 753
SYSTEM COMPLETION CODE=106 REASON CODE=0000000C
TIME=19.22.34 SEQ=15296 CPU=0000 ASID=0045
PSW AT TIME OF ERROR 070C1000 813C8F5E ILC 2 INTC 0D
NO ACTIVE MODULE FOUND
NAME=UNKNOWN
DATA AT PSW 013C8F58 - 8400181E 0A0D18FB 180C181D
AR/GR 0: 93B18D66/00001E00 1: 00000000/84106000
2: 00000000/26080021 3: 00000000/0000000C
4: 00000000/00000014 5: 00000000/008FD6E8
6: 00000000/00892200 7: 00000000/0000000C
8: 00000000/00892250 9: 00000000/013C9448
A: 00000000/00000024 B: 00000000/00000014
C: 00000000/00000000 D: 00000000/00892250
E: 00000000/84106000 F: 00000000/0000000C
END OF SYMPTOM DUMP
It looks to me as if a new version gets loaded at each 'Address LINKMVS' .
How can I avoid this?
Is it possible one way or another to load that pgm just once under
REXX and then reuse each time that loaded copy?
Did't find anything under rexx to get at this?!?
If not possible under rexx, should I look elsewhere? Any hint?
Jan
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX
Bob Stark
Regards,
Bob Stark
ProTech - When you're serious about Systems Management
Consulting, Software, and Training for z/OS, UNIX and Internet
www.protechtraining.com 800-373-9188 x151 Cell: 412-445-8072
Hi,
Jan
--
If this email is spam, report it here:
http://www.onlymyemail.com/view/?action=reportSpam&Id=Mzg3MzE6MTA0ODc1OTMwNTpic3RhcmtAcHJvdGVjaHB0cy5jb20%3D
Bob Bridges
I'm pretty sure LINKMVS isn't involved because I hardly ever have cause to
use it. For me it usually happen when I'm reading data in big gulps; I can
run it a couple times but after two or three executions there seems to be an
end to the available storage, and I have to log out of TSO and back in.
Since I've never heard anyone explain how I can get around it, that I can
recall, I just log off TSO and back on again when that happens.
Wait, sorry, I should have added: This happens when I'm DEVELOPING a
program that reads data in large gulps. Once the program is up and running,
not so much. Maybe not at all.
---
Bob Bridges, rhb...@attglobal.net, cell 336 382-7313
/* Q: Why is there no such organization as Chocoholics Anonymous? A:
Because no one wants to quit. */
-----Original Message-----
From: Jan Vanbrabant
Sent: Monday, February 22, 2010 13:40
I have a REXX program, calling an assembler pgm, via Address LINKMVS
"SBSY100" msg. It executes fine ... a couple of times, BUT after a while I
get this abend:
IEW4000I FETCH FOR MODULE DBINFPR FROM DDNAME STEPLIB FAILED BECAUSE
INSUFFICIENT STORAGE WAS AVAILABLE.
CSV031I LIBRARY ACCESS FAILED FOR MODULE DBINFPR , RETURN CODE 24,
REASON CODE 26080021, DDNAME STEPLIB
CSV028I ABEND106-0C JOBNAME=S783RPNG STEPNAME=G
$HASP375 S783RPNG ESTIMATED LINES EXCEEDED
IEA995I SYMPTOM DUMP OUTPUT 753
SYSTEM COMPLETION CODE=106 REASON CODE=0000000C
TIME=19.22.34 SEQ=15296 CPU=0000 ASID=0045
PSW AT TIME OF ERROR 070C1000 813C8F5E ILC 2 INTC 0D
NO ACTIVE MODULE FOUND
NAME=UNKNOWN
DATA AT PSW 013C8F58 - 8400181E 0A0D18FB 180C181D
AR/GR 0: 93B18D66/00001E00 1: 00000000/84106000
2: 00000000/26080021 3: 00000000/0000000C
4: 00000000/00000014 5: 00000000/008FD6E8
6: 00000000/00892200 7: 00000000/0000000C
8: 00000000/00892250 9: 00000000/013C9448
A: 00000000/00000024 B: 00000000/00000014
C: 00000000/00000000 D: 00000000/00892250
E: 00000000/84106000 F: 00000000/0000000C
END OF SYMPTOM DUMP
----------------------------------------------------------------------
Mike Shaw
> ***** CROSS-POSTED on IBM-MAIN *****
>
>
> IEW4000I FETCH FOR MODULE DBINFPR FROM DDNAME STEPLIB FAILED BECAUSE
> INSUFFICIENT STORAGE WAS AVAILABLE.
> CSV031I LIBRARY ACCESS FAILED FOR MODULE DBINFPR , RETURN CODE 24,
> REASON CODE 26080021, DDNAME STEPLIB
> CSV028I ABEND106-0C JOBNAME=S783RPNG STEPNAME=G
Jan:
I don't know what your app is doing, but we ran into a similar problem
involving recursive execution of a REXX exec that invoked a REXX
function written in Assembler. The Assembler function performed QSAM
I/O, and did NOT issue a FREEPOOL macro after CLOSE on the QSAM file.
We found out the hard way that QSAM I/O buffers (all 10 of'em) are NOT
freed by CLOSE; you must issue FREEPOOL to free them. This not a problem
in a batch job that is not using a recursion process, but in REXX where
recursion is common it can become a problem.
Anyway, adding the FREEPOOL for the QSAM buffer pool after CLOSE of the
QSAM file fixed the problem.
If your non-REXX programs are doing QSAM I/O, this is worth investigating.
Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.
Jeremy Nicoll - LStsrx
> Is the assembler program reentrant? If so, the original copy can be
> reused.
I'm not sure that reentrancy is relevant. Certainly reusability (which for
a non-reentrant program - ie a typical user one, as opposed to a typical
systems-programming program - seemed more relevant) didn't give the control
I expected.
I discussed this with IBM in a PMR way back in 1997. Of course things may
have changed since then. The PMR text includes detailed descriptions of
what goes on in both REXX and MVS terms, for programs linked in variuous
ways, called from REXX or COBOL. One of the significant comments an IBMer
made was:
"Nothing in REUS says that a module will only be loaded once for the
life of an address space, but rather that when there are multiple
requestors, only one user will be able to execute the copy at any
one time."
That's said quite a long way into the PMR. There is a suggested workaround
too, but it's not elegant...
The PMR text, slightly edited to remove installation-specific details, was:
TITLE Limitations of REXX parm-passing in ADDRESS environments
Abstract: tso / rexx / address linkpgm
OPERATING SYSTEM : mvs 522 SERVICE LEVEL : _______________
PRODUCT : tso / rexx SERVICE LEVEL : _______________
In a rexx exec which does the following several times:
do p = 1 to n
testprog = "MYPROG" || p ie a range of pgm names
address linkpgm testprog "myparm1 myparm2"
end
Taking a single pgm as an example, eg MYPROG3, I'd expect the pgm to
get LOADed into the address space, then LINKed to, on the first call.
On subsequent calls I'd expect it still to be there unless MVS does a
DELETE at the end of the 'address linkpgm' processing.
Can you find out whether tso/rexx's address linkpgm is issuing DELETE?
The program we are testing appears to run a fresh copy each time & we
do not know if this is rexx's fault or the pgm's fault!
-FIELD, MICHAEL S CH-5752SC1C5 - 97/08/13-10:31-
Jeremy,
Is the user program (MYPROG3 or whatever) linkedited as reentrant or
reusable? If so, I would expect the in-storage copy to be reused, but
if not, you would get a new copy each time.
Mike Field
-CUSTOMER 0000000 -5752SC1C5 - 97/08/13-14:38-
The code certainly isn't reentrant and so it is not linked that way.
It is meant to be reusable, and isn't linked that way either, whoops!
If it were relinked to flag it reusable, can you confirm that rexx's
'address linkpgm' would not cause module deletion? Also is there any
difference between:
address linkpgm
testprog "myparm1 myparm2"
testprog "myparm3 myparm4"
and
address linkpgm testprog "myparm1 myparm2"
address linkpgm testprog "myparm3 myparm4"
-FIELD, MICHAEL S CH-566528501 - 97/08/13-15:05-
Jeremy,
1. LINKPGM internally just issues an MVS LINK macro.
So if the module is marked reusable it will not be deleted.
2. There is no difference in the operation of the two examples you
give.
Regards, Mike Field
-CUSTOMER 0000000 -566528501 - 97/09/04-07:54-
Yup, ok, well can you explain this:
We are testing variants of a date-processing program which is meant to
be loaded once, then when called to be able to return either the date
that was current when it was first loaded, or the date that is current
at the time of a call. If the calling program runs past midnight then
on the first day, both types of date request should produce the same
result; on subsequent days the results should differ. We have six
variants of the program:
- 2 24-bit ones, one RU the other not
- 2 31-bit ones, one RU the other not, equivalent to 24-bit ones
- 2 31-bit ones, one RU the other not, older version of date pgm
a) a rexx exec which makes calls to 6 variants of the program that is
being tested, then waits a while, and repeats the set of calls
-- with these: day 1 - produces day 1's date both times
day 2 - produces day 2's date both times
-- our conclusion is that module has been reloaded for the 2nd day's
calls
b) a cobol-2 program which calls the 6, waits and does the calls again
-- with these: day 1 - produces day 1's date both times
day 2 - produces day 1's date for first-call date
day 2 - produces day 2's date for instantaneous date
So: I don't know why, but whether the module is marked RU or not doesn't
seem to matter, AND, address linkpgm does appear to cause the linked-to
pgm to be deleted. Can you check this with the tso/rexx change team or
mvs contents-supervision if that is more appropriate?
-CUSTOMER 0000000 -566528501 - 97/09/04-08:56-
I've run the following job to experiment to see if modules get reloaded:
//JOBSTEP0 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//SYSUT2 DD DISP=(,PASS),DSN=&&EXECS(THINGY),
// UNIT=VIO,SPACE=(TRK,(1,1,1)),DCB=(RECFM=FB,LRECL=80)
//SYSUT1 DD *,DLM=$$
/* REXX */
parse arg envt .
p2codes = "2199" ; p2odate = left("",19)
address linkpgm "THING#1 p2codes p2odate"
say envt "call 1:" rc "result is" p2odate"."
say envt "wait start" time() ; hhmmss = "000030"
address linkmvs "SSCWAIT hhmmss" ; say envt "wait done:" time()
/* while this wait happens I manually rename THING#1 to CRAP */
p2codes = "2199" ; p2odate = left("",19)
address linkpgm "THING#1 p2codes p2odate"
say envt "call 2:" rc "result is" p2odate"."
$$
//*
//JOBSTEP1 EXEC PGM=IRXJCL,PARM='THINGY IRX'
//STEPLIB DD DISP=SHR,DSN=SYJN.REXX.LOAD
//SYSEXEC DD DISP=(SHR,PASS),DSN=&&EXECS
//SYSTSPRT DD SYSOUT=*,OUTLIM=0
//*
//JOBSTEP2 EXEC PGM=SPGMAINT
//SYSLIST DD SYSOUT=*
//PDS DD DISP=SHR,DSN=SYJN.REXX.LOAD
//SYSRDR DD *
R CRAP TO THING#1
//*
//JOBSTEP3 EXEC PGM=IKJEFT01,PARM='%THINGY TSO'
//STEPLIB DD DISP=SHR,DSN=SYJN.REXX.LOAD
//SYSEXEC DD DISP=(SHR,PASS),DSN=&&EXECS
//SYSTSPRT DD SYSOUT=*,OUTLIM=0
At start SYJN.REXX.LOAD contains THING#1. First test step runs exec
under MVS. Exec calls THING#1 then waits 30 seconds; while it does
that I rename THING#1 to CRAP (in ispf). Exec tries to make 2nd call
& fails because when it tries to reload THING#1 it can't find it. We
then rename CRAP back to THING#1 for the second test step where I do
the same things but exec runs under tso.
IRXJCL output:
IRX call 1: 0 result is 19970904 .
IRX wait start 09:39:13
IRX wait done: 09:39:43
13 *-* address linkpgm "THING#1 p2codes p2odate"
+++ RC(-3) +++
IRX call 2: -3 result is .
TSO output:
ACF0C038 ACF2 LOGONID ATTRIBUTES HAVE REPLACED DEFAU
TSO call 1: 0 result is 19970904 .
TSO wait start 09:39:44
TSO wait done: 09:40:14
13 *-* address linkpgm "THING#1 p2codes p2odate"
+++ RC(-3) +++
TSO call 2: -3 result is .
READY
END
In this case THING#1 was a 31-bit pgm, not marked RU. I repeated the
process with a copy of the same pgm which is marked RU, with exactly
the same results. I think this demonstrates that address linkpgm
does cause module reload, despite your earlier answers.
-FIELD, MICHAEL S CH-566528501 - 97/09/04-11:00-
Hi UK390,
It appears the REXX ADDRESS LINKPGM statement is not honouring the
reusability attribute of the program linked to, but is loading a new
copy each time. See above for details. Can you help?
Regards
Mike Field
-WILKINS, CHARLES SC-566528501 - 97/09/04-15:04-
Hi Jeremy,
I've started looking into this problem.
Is the library containing "THINKY#1" apf authorised ?
If so are the results the same from a non-apf authorised library?
Module IRXSTAMP is the routine that handles the LINKPGM command for REXX
could you supply its RMID.
Having looked at a copy of IRXSTAMP it may be necessary to run a trace
through it to understand what going on, would that be okay with you?
Charles Wilkins
-CUSTOMER 0000000 -566528501 - 97/09/05-07:39-
Library is not apf-authorised as pgm doesn't need it.
IRXSTAMP is fmid/rmid/umid all equal to HTE25D2.
Trace is ok if you tell us how to define it, and if it won't hurt the
rest of the system.
-WILKINS, CHARLES SC-566528508 - 97/09/05-11:19-
Hi Jeremy,
This is what I think is happening, please pass the call back to me and
I will bounce it off the c/t for confirmation and suggestions on a way
to retain the copy of the module (unless you can think of a way).
.
REXX calls modules IRXSTAMP to handle the LINKPGM command (and the other
link and attach commands). IRXSTAMP searches ALTLIB, then LPA/JPA and
finally LINKLIB/STEPLIB for the module to be linked to. It invokes the
LINK svc to perform the link using either the DE or EP option, depending
on where it found the module.
In manual GC28-1466-02 ASSEMBER SERVICE GUIDE - it states that LINK
maintains a module use count - which is used in the same way as the use
count maintained by the LOAD macro.
In the description of LOAD it states that when the use count is
decremented to zero the storage is release (the module is deleted).
.
So, Given you issue the LINKPGM serially there is only one use of the
module at any given time, return from the module decrements the count to
zero - so the module is deleted. I dont think the REUS attriubute causes
the module to be kept in storage, as you are seeing.
The problem remains - how to keep the module in storage.
Charles
-CUSTOMER 0000000 -566528508 - 97/09/10-12:35-
Hmm; if linkpgm is 'working properly', perhaps you'd explain how my
program can be called dynamically from a cobol-2 main program and
on successive calls find the same loaded copy of the test program?
...and also how the cobol-2 runtime environment can do this for
both the non-reusable and the reusable test programs? Does it not
use LINK too under the covers?
-WILKINS, CHARLES SC-566528508 - 97/09/10-13:29-
Hi,
Apparently not, it seems cobol uses LOAD rather thank LINK.
I found this reply to another question about Cobol loading subprograms:-
"Both VS COBOL II and OS/VS COBOL call subprograms with a
load and balr. What happens is that both COBOLs load the
subprogram only once (on the first call) and then keep track
of the address by placing it in a load list. With the subprogram's
address available, the subprogram doesn't have to be reloaded
on subsequent calls."
Charles.
-CUSTOMER 0000000 -566528508 - 97/09/10-15:24-
If the module loaded in this way isn't marked reusable why doesn't
mvs(?) delete it after it has been called once?
-WILKINS, CHARLES SC-566528508 - 97/09/11-12:53-
Hi,
The LOAD SVC builds, during the first load of a module, a control block
that contains a module use count, as well as other information about the
load module. The use count is really just a count of LOADs issued for
the module. The use count is drecremented each time a DELETE svc is
issued for the module, when the use count reaches zero the module is
physically deleted from storage (by releasing the storage). Subtask
termination implicitly reduces the use count as well. The LINK SVC uses
a different use count, but the process is the same.
The load SVC returns the entry point address of the module loaded. The
module can then be called by branching to the entry point address. Calls
to the module are not reflected in the use count - This is the mechanism
Cobol uses. So return from the module does not affect the use count so
the module is not deleted by the return. I guess Cobol never issues a
DELETE.
.
Its the LOAD/LINK process that react to the modules attributes, loading
fresh copies or reusing existing ones as appropriate.
.
Regarding the problem of LINKPGM reloading the module. I've asked around
and it is suggested you either modify the module to issue a LOAD for
itself the first time its called or have something else LOAD it.
Charles
-CUSTOMER 0000000 -566528508 - 97/09/16-09:33-
Hmmm. COBOL - is it documented anywhere that OS/VS COBOL and COBOL-2
both only load sub-programs once? Also has this always been their way
of behaving? I'm surprised that the problem we've seen hasn't caused
anyone else grief bearing in mind that I have found that our 'legacy'
assembler code is often self-modifying (if only in that as the program
progresses intruction storage is overlaid by data). Suppose you want a
fresh copy each time, I suppose the only way to get it is, from your
cobol program, to call another asm subroutine to issue a DELETE for the
first subroutine - it seems pretty clumsy!
As for LINKPGM, we can live with it whatever it does, but I'd like to
know if this aspect was considered when it was written, and then, I'd
suggest that the manuals be updated to make it clear how it works. As
a sysprog I'd expect it to emulate LINK (indeed that's what you guys
said at first too), and we now use rexx to write test harnesses for
assembler functions when we'd previously have written them in assembler.
Other people will fall down this hole too, I think. Alternatively,
how about revising LINKPGM to obey module reusability?
-WARREN, KEN SC-566528508 - 97/09/16-10:10-
Hello Jeremy,
Unfortunately Charles is on holiday now. If this has come down to
incomplete or unclear documentation then the Reader's Comment Form
is the best vehicle to address that. I believe they accept email now.
If you want to discuss the programming issues further just let me know.
Regards, Ken Warren
-CUSTOMER 0000000 -566528508 - 97/09/16-11:23-
Before I pursue the email readers comment (who to, anyway?) I'd like to
know if LINKPGM's behaviour is working properly or if IBM might concede
that reusability should have been considered, and that therefore, there
is a need for a fix to the way that LINKPGM works.
-WARREN, KEN SW-566528508 - 97/09/16-14:49-
Hello Jeremy,
:
I can ask the TSO change-team whether they think LINKPGM is handling
REUS modules correctly. Please confirm my understanding - is it that
REUS modules are being needlessly reloaded every time? Can it be as
simply stated as that?
Thanks, Ken
-CUSTOMER 0000000 -566528508 - 97/09/17-09:32-
Yes, it is that simple.
-WARREN, KEN SW-566528508 - 97/09/17-10:35-
Hello TSO,
Can you please comment on the customer's finding that REXX LINKPGM
is needlessly reloading REUS modules. Please see PMR text for details
of testing done. What MVS contents supervisor service does LINKPGM
invoke?
Many thanks,
Ken Warren
-YURKOVIC, BILL -566528508 - 97/09/17-17:43-
Hello Ken,
I've reviewed the PMR and the various concerns. Charles' explanation
of how LINK works with regard to REUS on pages 17-18 is very good.
With this information as background, it seems clear that REXX
LINKPGM behaves exactly as one would expect regarding using LINK to
invoke a reusable program. Note that it is not REXX which enforces the
REUS attribute, but rather the MVS LINK macro which REXX uses to invoke
a program being called from address LINKPGM. Nothing in REUS
says that a module will only be loaded once for the life of an address
space, but rather that when there are multiple requestors, only one
user will be able to execute the copy at any one time.
.
From the discussion of COBOL (on page 20-21) using LOAD and BALR,
that procedure will not honor the REUS attribute. It is true that
only one LOAD will be issued for the module, but BALR to a module
will not ensure REUS (ie Serial Reusability with a single invoker at
any one time).
.
I think the key is that when you issue
address LINKPGM 'mypgm'
REXX will issue a LINK to 'mypgm'. The MVS LINK macro will look to see
if a copy is already available in storage. If so, and if that copy has
not already been given control by another LINK (or other MVS macro),
then LINK will use it. If the module is not in storage, LINK will
load a copy, pass control to it, and after the program is done, if
there is no other requestor, the module is deleted. That is just normal
LINK macro processing, nothing special that REXX does.
.
Now to achieve the results you want, I believe Charles' suggestion
on page 21 would produce the behavior you desire. That is, have your
program issue a LOAD for itself on the first (and only the first)
invocation. This will increment the LOAD Use Count by 1 so that when
LINK finishes, there would still be 1 outstanding LOAD for the module.
This would cause Contents Supervisor to retain this copy in storage.
The next LINK would use this copy, as long as it wasn't already in use.
Finally, when the task where the LOAD was done eventually terminates,
the copy would then be DELETEd by MVS Task Termination.
Regards, Bill/TSO
-CUSTOMER 0000000 -566528508 - 97/09/18-09:36-
Ok I'll live with that. Thanks for all your effort; please close this.
--
Jeremy C B Nicoll - my opinions are my own.
Paul Gilmartin
> One of the significant comments an IBMer made was:
>
> "Nothing in REUS says that a module will only be loaded once for the
> life of an address space, but rather that when there are multiple
> requestors, only one user will be able to execute the copy at any
> one time."
>
> That's said quite a long way into the PMR. There is a suggested workaround
> too, but it's not elegant...
>
Them's the rules. Live with it. It's exactly the behavior
you could expect from LINK in an assembler program, so it's
ideal for your intended testing purpose of replacing an
assembler testframe.
That said, I've often wanted some load modules to remain
resident for performance reasons as well as for preserving
static variables. One approach might be to create a
function package containing LOAD and DELETE facilities.
-- gil
Jeremy Nicoll - LStsrx
> On Feb 24, 2010, at 07:36, Jeremy Nicoll - LStsrx wrote:
> > That's said quite a long way into the PMR. There is a suggested
> > workaround too, but it's not elegant...
> >
> Them's the rules. Live with it.
I don't need to now; the PMR was 12 years ago...
> It's exactly the behavior you could expect from LINK in an assembler
> program, so it's ideal for your intended testing purpose of replacing an
> assembler testframe.
The problem is, it isn't 'ideal'. In an assembler test harness you've the
ability to include the preliminary extra LOAD that means the module doesn't
get DELETEd until you choose, whereas in REXX you can't do that unless you
...
> That said, I've often wanted some load modules to remain
> resident for performance reasons as well as for preserving
> static variables. One approach might be to create a
> function package containing LOAD and DELETE facilities.
... (as you say) separately LOAD the module and DELETE it after all the uses
have been made.
--
Jeremy C B Nicoll - my opinions are my own.
----------------------------------------------------------------------