> Since CMS still says PIPE is running, the call (if it is one) was made > by BALR rather than CMSCALL.
I'm really not sure how this occurs? PARSEM doesn't obtain storage, AT ALL!! The DMSFRR storage handling is being done by CMS, not PARSEM. PARSEM has a large DS area so that it can completely avoid getting and releasing storage. The program is NUCXLOAD'ed and uses the same DS area, completely avoiding SVC calls for storage. Definitely no running of key zero, no rules violations here :-) There must be some other reason that CMS says PIPE is running? Anyway, thanks all for Trace and VMDUMP suggestions, which we'll look into if this problem persists. -----Original Message----- From: CMSTSO Pipelines Discussion List <[email protected]> On Behalf Of John P. Hartmann Sent: Tuesday, December 6, 2022 6:27 PM To: [email protected] Subject: Re: Debugging a data exception On 12/6/22 23:57, Rob van der Heij wrote: > Yep, that's CMS release storage, So PARSEM runs key zero so that it can CMMSSTOR RELEASE,TYPE=BALR. Shouldn't that be fixed so that the application cannot walk all over CMS? :soapbox. Running key zero "for performance reasons" was never in my book; in this day and age, it shouldn't be in anyone's. :esoapbox.
