On Sat, 12 Sep 2015, at 16:42, Roland Kinsman wrote: > Point taken, Peter. Here are the messages that led me to this > conclusion: > > IEW4000I FETCH FOR MODULE CWPZDRVR FROM DDNAME -LNKLST- FAILED BECAUSE > INSUFFICIENT STORAGE WAS AVAILABLE. > CSV031I LIBRARY ACCESS FAILED FOR MODULE CWPZDRVR, RETURN CODE 24, REASON > CODE 26080021, DDNAME *LNKLST* > CSV028I ABEND106-0C JOBNAME=EADITBAT STEPNAME=STEP1 > > This occurred after the loop had executed successfully about 250 times, > leading me to conclude there is some kind of storage leak.
I have a distant memory of problems like this maybe being solvable if you can stop the module fetch from being done at all. So perhaps a small assembler program that does a single load of the relevant module then uses umm... digs around in fading brain... maybe the tso service routine, if not an IRX... module to call the main rexx exec, which in turn calls the subsidiary ones. If the module loaded by the assembler routine doesn't get unloaded until much later when all the rexxex have run, there's a possibility that none of the vendor programs will actually load another copy of that module; of course that might also depend on the module's attributes - whether it's re-entrant, refreshable etc. Alternatively, why not use the mainline rexx routine to generate some subsidiary jobstreams each of which will process - say - 200 members? -- Jeremy Nicoll - my opinions are my own. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
