Rob, You sent it to the right place the first time. I thought I responded to it. At any rate, I've asked IBM if netview will support an ATTCHMVS. We are doing additional problem identification with tracing, so hopefully that will turn something up, and we can definitively find the culprit.
_____________________________________________________________________________________________________ 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 Robert Garrett Sent: Friday, May 22, 2020 10:08 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: FW: REXX assistance **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Somehow, I managed to send this suggestion to the wrong mailing list a few days ago – my bad… Hi Dave, I've seen that kind of problem before myself invoking various IBM utilities repeatedly. A lot of them assume that they will always run at the jobstep level and don't ever freemain their SP0 storage, instead "assuming" step termination will handle it for them. That can cause problems like the one you're seeing (if you’re repeatedly calling them from a parent REXX exec). The solution I've implemented in the past is to invoke those utilities using ATTCHMVS, which will run then under a new TCB which thus will obtain its own SP0 storage. When the utility finishes and that TCB gets detached, that separate SP0 storage will get freemain'ed even if the utility doesn't clean up after itself, thus avoiding the problem. I also wrote my own custom version of ATTCHMVS that allowed me to pass a loadlib to be used as a TASKLIB on the ATTACH. In my case, I was repeatedly invoking the CICS DFHCSDUP utility and needed to be able to call different releases of it dynamically from the parent exec. Try using ATTCHMVS and see if that doesn't solve your problem. Rob ________________________________ From: Dave Jousma <000001a0403c5dc1-dmarc-requ...@listserv.ua.edu<mailto:000001a0403c5dc1-dmarc-requ...@listserv.ua.edu>> Sent: Wed May 20 06:48:49 CDT 2020 To: "IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>" Subject: REXX assistance 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<mailto:lists...@listserv.ua.edu> with the message: INFO IBM-MAIN ---------------------------------------------------------------------- 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
