It is certainly also good to know you are watching, Jonathan.
If the trashed storage has key F0 and pipelines uses only key E0, it
ain't me, Sir.
Perhaps you could put an address stop at the PIPE nucleus extension and
then use x'520' to find the SVCSECT and then trace store into it?
Cheers,
j.
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
