Circling back around on this topic. After a lot of back and forth with IBM,
it appears that at the V2.4 OS level, IDCAMS does have a memory leak that
wouldn’t necessarily be noticed in a typical batch execution. We use Netview
automation in our FTP process that calls IDCAMS 10's of thousands of times a
week from the Netview address space. We tested this APAR in our non-prod
environment, and it does indeed appear to fix the problem.
APAR Identifier ...... OA59421 Last Changed ........ 20/06/18
MEMORY LEAK WITH IDCAMS REPRO EXECUTION AT 2.4
Symptom ...... AB ABEND878 Status ........... CLOSED PER
Severity ................... 3 Date Closed ......... 20/06/02
Component .......... 5695DF103 Duplicate of ........
Reported Release ......... 240 Fixed Release ............ 999
Component Name ACCESS METHOD S Special Notice
Current Target Date ..20/09/30 Flags
SCP ...................
Platform ............
Status Detail: APARCLOSURE - APAR is being closed.
PE PTF List:
PTF List:
Release 240 : UJ03097 available 20/06/18 (1000 )
Parent APAR:
Child APAR list:
ERROR DESCRIPTION:
At the 2.4 release, every execution of REPRO may leave a block
of SP252 Key0 btl user region storage. This becomes an issue
when 10's of thousands of REPROs are executed from a single
jobstep.
This APAR will also address issues with other commands such as
DCOLLECT (but not limited to) that uses similar 'AR' control
blocks. In the case of DCOLLECT for instance, the orphaned
storage is in SP0 Key8. In all cases, orphaned storage will
contain similar 'AR' identifiers.
| ...................... ........ |
| ..AR.............. ....\........ | <-
| ....8 SA...q...0................ |
| volser.......................... |
Applications that execute IDCAMS internally such as NETVIEW may
experience storage creep without executing 1000s of commands in
a single step due to the nature of each individual command
orphaning a block at a time.
ADDITIONAL SYMPTOMS:
IEC340I - IGC0002F, INSUFFICIENT STORAGE FOR THE CATALOG
WORKAREA
ABENDS106
CATKEYS: IDC2020 IDCABEND IDCREPRO IDCDCOLL
LOCAL FIX:
BYPASS/CIRCUMVENTION:
split REPRO commands into multiple job steps
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
* All DFSMS users of release V24 and up affect. *
****************************************************************
* PROBLEM DESCRIPTION: *
* When customers executed a large amount of REPRO commands in *
* a single job step , for example more than 10's of thousands *
* of REPRO commands, the abend106 occurred as results of *
* insufficient storage for the catalog workarea. *
* The problem occurred because the pool id was assigned *
* incorrectly in getting storage to process/retrieve the data *
* set information (UIOINFO macro). *
****************************************************************
* RECOMMENDATION: *
****************************************************************
PROBLEM CONCLUSION:
The problem is solved by assignment of a correct storage pool
id.
_____________________________________________________________________________________________________
Dave Jousma
AVP | Manager, Systems Engineering
Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI
49546
616.653.8429 | fax: 616.653.2717
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of
Dave Jousma
Sent: Wednesday, May 20, 2020 7:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: REXX assistance
**CAUTION EXTERNAL EMAIL**
**DO NOT open attachments or click on links from unknown senders or unexpected
emails**
All,
We have some relatively new Netview automation to process inbound FTP
processing that is written in REXX, and over time we’ve seen Netview abends
with 878’s, etc. IBM indicates we may have a problem below the line,
specifically SP0 being exhausted. They are seeing a lot junk that looks like
workpack volser’s PCWxxxx, temp dataset names, etc. It is my belief that it
is the remnants of calling IDCAMS to do our FTP processing to create special
dataset catalog entries amongst other stuff and cleanup is not occurring that
over time causes our problems.
Here is the bit of rexx code I am looking at. Look at how IDCAMS is being
called in line 318. I’m not a REXX coding expert by any means. Is that the
equivalent of just a standard CALL? Or like entering TSO IDCAMS at a command
line in TSO? I’m wondering if there is a better way to call IDCAMS? I see
references to LINK, ATTACH, LINKMVS, ATTCHMVS, LINKPGM, ATTCHPGM. I’m
embarrassed to say that I do not know the nuances of each of these, and when
appropriate to use. Do any of these create a new environment, do the
function, and then tear the environment down upon exit? It seems like this is
what we need to use to fix this issue.
000308 /* */
000309 /* We have now created all the IDCAMS statements, we now write them*/
000310 /* to our dataset to be used as SYSIN for IDCAMS command */
000311 /* */
000312 Say "Number of Queued Lines is " QueuedLines
000313 Address MVS 'EXECIO 'QueuedLines' DISKW 'Infile' (FINIS'
000314 /* */
000315 /* The IDCAMS statement calls IDCAMS using the 2 DD names listed */
000316 /* after the command as SYSIN and SYSPRINT */
000317 /* */
000318 IDCAMS Infile Outfile
000319 Say "IDCAMS RC for File Rename = " RC
000320 If RC > 4 Then
000321 Do
000322 Address MVS 'EXECIO * DISKR 'Outfile' (STEM Prtrex. FINIS'
000323 do xy = 1 to Prtrex.0
000324 Say "Idcams output = " Prtrex.xy
000325 end
000326 end
000327 "free fi("Infile")"
000328 "free fi("Outfile")"
000329
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL
EMAIL**
**DO NOT open attachments or click on links from unknown senders or unexpected
emails**
This e-mail transmission contains information that is confidential and may be
privileged. It is intended only for the addressee(s) named above. If you
receive this e-mail in error, please do not read, copy or disseminate it in any
manner. If you are not the intended recipient, any disclosure, copying,
distribution or use of the contents of this information is prohibited. Please
reply to the message immediately by informing the sender that the message was
misdirected. After replying, please erase it from your computer system. Your
assistance in correcting this error is appreciated.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
