Ref: Your note of Wed, 25 Jun 2014 13:16:54 +0200 John Hartmann wrote: > Are you saying that some code that shoulld have called the pipeline by > CMSCALL actually did a branch and link? If so, let it call EXEC2 and > APAR that. Last I looked (admittedly some thirty years ago) EXEC2 > EXECCOMM trashes all registers except R14 (it is certainly entitled to > do that). I learnt to be very wary of branching to EXECCOMM. > > Or is the problem that the Pipeline's save area has been trashed? Might > it be branched to in 64-bit mode? > > I did run the regression test when "they" built z/CMS originally.
Hi John - good to know you're watching! The code in EDCSYSCM did a CMSCALL with call type CMS, but somehow the 64-bit registers (in the SVCSECT area) were trashed by the time CMSCALL returned. The result of the PIPE appeared to have been stored correctly in the specified storage location. The bad register values mostly pointed to a data area with VMTIMER in it, with DMSEVENT just before it. This is the PIPE command which was being processed before the error (where I've inserted some newlines and spaces for readability): PIPE ( ENDCHAR ? ) CMS GLOBALV SELECT CENV LIST | DROP FIRST 1 | STRIP LEADING BLANK 1 | APPEND LITERAL | JOIN * H00 | STORAGE 06B7CC28 300 E0 | COUNT BYTES | STORAGE 06B7C7F0 11 E0 The second STORAGE location contained a value of 0 and the first was empty at the time of the error. This failure was with the following level of Pipelines: CMS/TSO Pipelines, 5654-030/5655-A17 1.0112 (Version.Release/Mod) - Generated 3 Dec 2010 at 11:10:08. It didn't fail with this version: CMS/TSO Pipelines, 5654-030/5655-A17 1.0110 (Version.Release/Mod) - Generated 20 Sep 1999 at 21:23:56. I have an instruction trace from just before the CMSCALL to the failure, but it's about 90,000 lines. If you want to discuss it in more detail, feel free to email me directly. Regards Jonathan Scott
