I've fixed the bug that caused the assert failure. Stupid oversight of mine. (And lack of test case.)
I also changed COMMAND/CMS to issue error messages related to recursions by way of CMS MSG * so they don't get harvested by an outer COMMAND stage. Rob is putting up a VM archive that contains a revised NXPIPE and news. He will append here when done. That was the good news. The bad news is that PING still abends, only now we don't get to know why. Though one should not blame PING; the bug clearly is in LE as specifying POSIX(OFF) to LE circumvents it. Why PING is generated with POSIX(ON) and shipped that way is beyond me. Serves no purpose at all. Most likely a test that got into the wild. Either way, the original pipeline runs in the commands process; LE (or the C runtime) initialisation obtains some global variables by a pipeline that has another CMS [sic!] stage, but this runs in a different process. As I know this will result in CMS going belly-up when the command finishes, I reject the call with a message. Perhaps LE/C does not inspect the return code and uses uninitialised storage; or perhaps it decides it cannot continue and ABENDS. Would someone who is more conversant with LE please re-run the test and explain what the reason code means? I know this particular test case runs on the Endicott pipeline, which is only tolerant of MT. A few years ago Mike Walter provided a series of test cases that showed this to break down and I amended my implementation to support MT as properly as one can. Anyhow, thanks for the test case. I'll see what I can do to accommodate it. By way of this message I am also asking for other MT related test cases. A Hello, world! module that is compiled generated with POSIX on would be very nice. On 09/08/2014 11:34 PM, Michael Harding wrote: > Just a hunch, based on John's statement referencing threads, my own > observation that ping and other programs having the problem seem to be > LE-based, and some reading of the LE Programmer's Guide. > > -- > Mike Harding > z/VM System Support > /sp > > > CMSTSO Pipelines Discussion List <[email protected]> wrote on > 09/08/2014 01:53:11 PM: > >> From: "Ackerman, Alan" <[email protected]> >> To: [email protected] >> Date: 09/08/2014 01:53 PM >> Subject: Re: Assert failure? >> Sent by: CMSTSO Pipelines Discussion List <[email protected]> >> >> Same here. Where did you get the POSIX(OFF)? >> >> I cannot find it in either HELP TCPIP PING or PIPE AHELP COMMAND. >> >> PIPE COMMAND PING POSIX(OFF) / zvmxp30040 | CONS >> Ping Level 620: Pinging host ZVMXP30040 (165.36.189.70). >> Enter #CP EXT to interrupt. >> PING: Ping #1 response took 0.034 seconds. Successes so far 1. >> <vmlnx1/ackerman>; T=0.01/0.01 13:46:05 >> PIPE COMMAND PING / zvmxp30040 | CONS >> FPLINX409E Assert failure 000001C6 at 01A4F582. >> FPLINX411I ... In CMSCMD; offset 00000B0A in FPLCOM 11/18/11 12.33. >> FPLINX412I ... GPR0: 00000000 00E7C858 01F6AFD8 0000001D. >> FPLINX412I ... GPR4: 00000000 00000000 3402000F 01F6AD18. >> FPLINX412I ... GPR8: 00000000 01F47230 01F6C518 00E7C710. >> FPLINX412I ... GPRC: 81A4F4D4 00E7CEB0 81A4F572 00000000. >> FPLINX413I ... Store 01A4F578: 58009644 4780C0B0 000001C6 9104B13E > 47E0C0BC. >> DMSABE141T Operation exception occurred at 81A4F582 in routine PIPE >> CMS >> >> -----Original Message----- >> From: CMSTSO Pipelines Discussion List > [mailto:[email protected] >> ] On Behalf Of Michael Harding >> Sent: Monday, September 08, 2014 1:29 PM >> To: [email protected] >> Subject: Re: [CMS-PIPELINES] Assert failure? >> >> Poking around a bit more, and based on my own LE comment, I discovered > that >> most at least of the problem children run ok if the LE runtime option > POSIX >> (OFF) is specified. >> >> That is, where "PIPE COMMAND PING somehost | CONS" gets the assert > failure, >> "PIPE COMMAND PING POSIX(OFF) / somehost | CONS" doesn't. >> >> -- >> Mike Harding >> z/VM System Support >> /sp >> >> >> CMSTSO Pipelines Discussion List <[email protected]> wrote on >> 09/08/2014 12:36:18 PM: >> >>> From: Michael Harding/Oakland/IBM@IBMUS >>> To: [email protected] >>> Date: 09/08/2014 12:36 PM >>> Subject: Re: Assert failure? >>> Sent by: CMSTSO Pipelines Discussion List <[email protected]> >>> >>> Actually, NETSTAT is fine. The problem seems to occur with many of the >> LE >>> modules on the tcpip public disk. >>> >>> CMSTSO Pipelines Discussion List <[email protected]> wrote on >>> 09/08/2014 12:14:21 PM: >>> >>>> From: "John P. Hartmann" <[email protected]> >>>> To: [email protected] >>>> Date: 09/08/2014 12:18 PM >>>> Subject: Re: Assert failure? >>>> Sent by: CMSTSO Pipelines Discussion List > <[email protected]> >>>> >>>> Can reproduce on 5.2. >>>> >>>> The assert means: >>>> >>>> :dt.1C6:dd.FPLCOM >>>> >>>> CMS command destroyed pointer to pipeline set running :fref command. > or >>>> :fref cms. >>>> >>>> So perhaps NETSTAT is trying to multitask or does something it >> shouldn't >>>> have done to be able to run its own pipeline. Or perhaps NETSTAT > drops >>>> the current pipeline to load the standard CMS one. Perhaps you can > ask >>>> around? >>>> >>>> The actual test is whether the pipeline header pointer for the thread >>>> survives the command. In this case there is no pipeline header >>>> associated with the thread after the command (R0) and there [clearly] >>>> was one before the command (R10). >>>> >>>> I added the assert in November, 2011, so DMSPIPE won't have that >>>> failure, but it is likely to have another one. Did you try? >>>> >>>> On 09/08/2014 08:34 PM, Bob Cronin wrote: >>>>> pipe command PING 9.80.104.193 | console >>>> >>> >> >> ---------------------------------------------------------------------- >> This message, and any attachments, is for the intended recipient(s) >> only, may contain information that is privileged, confidential and/ >> or proprietary and subject to important terms and conditions available at > >> http://www.bankofamerica.com/emaildisclaimer. If you are not the >> intended recipient, please delete this message. >>
