Some final bits of advice. As the SMPPTS% libraries are opened in order to store a new sysmod, you will get an x37 abend for each one that has insufficient space. This is a totally cosmetic issue unless you (1) allow SVC dump for x37 abend or (2) allow SMP/E to compress the library.
For (1), you should have a SLIP trap in your system to suppress *all* x37 dumps. Whoever learned anything from such a dump unless you are troubleshooting a software problem? For (2), you should tell SMP/E not to compress a PTS...OK, having asserted that, I looked at my GLOBAL zone and do not see how to do it. I know I took such action in the past because compressing a PTS is pretty much guaranteed to be hopeless. Hmm. Anyway, if a PTS can benefit from compress, say after ACCEPT, should be handled manually outside of RECEIVE processing. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Alan Schwartz Sent: Friday, March 17, 2017 11:18 AM To: [email protected] Subject: (External):Re: Can SMPPTS datasets be consolidated? The one place where spill datasets don't work as a logical concatenation is when using GIMCPTS as SYSUT1 has to point to a pds member so I try SMPPTS then SMPPTS1 and so on until I get the correct PTS. I can get the correct PTS first by using the panels. It just depends on what I'm doing at the time ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
