I've been looking at this from time to time.  I think that the pipeline
is trying to create the C environment from globalv.  It takes the
caution of storing the length of the environment, perhaps to guard
against it overflowing the 300 bytes allowed, but perhaps it does not
process a missing environment correctly.  But then again, if there is a
zero appended at all times, the storing of a zero at the second address
makes no sense.

On 25/06/14 14:08, Jonathan Scott wrote:
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

Reply via email to