> 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
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
Just so we're clear...I wasn't blaming PIPE. :-) ... and PARSEM is the
name of our application.
Thanks,
DeWayne
On 12/6/22 15:08, John P. Hartmann wrote:
I wish I had a penny for each time PIPE gets blamed for programs
called from it falling over.
Are those messages from your REXX code, or
Yep, that's CMS release storage, so something stepped on outside the block
and that troubled CMS when chaining the block back into free memory.
I will go through DMSFRR to see what it touched there, but I'm not sure we
can trace that back. If the callpipe was replacing the output file, we've
also
It's REXX code using PIPEs / CALLPIPEs.
IADEDIRB is a CMS userid, and a Filename in this instance.
The socket message shouldn't have been included here, it's just residual
console activity from a previous minute.
The server received a request to promote a file, and as far as I can tell this
I wish I had a penny for each time PIPE gets blamed for programs called
from it falling over.
Are those messages from your REXX code, or what? Looks like some kind
of trace to me.
If not of your doing, I'd find out what the component code IAD is and
look for a call to it.
You might also
I wouldn't be surprised if CMS Pipelines were just the innocent bystander
running some CMS program that program checked.
The ideal would have been to get a VMDUMP at the point where the program
check occurred, but since we're probably past that opportunity, another
idea would be to look what's at
Greetings,
We just received the following in a REXX PIPE stage:
20:04:01.329108 PARSCALL SocketSetStatus rc=0 PARSEM Connected Free 1099
Used 1
20:04:25.569707 IADEDIRB STORE IADEDIR1 FLEXCNTL
DMSABE141T Data exception occurred at 8114620A in routine PIPE
CMS
Any helpful hints on how we
