Ref: Your note of Wed, 25 Jun 2014 23:24:20 +0200
I had a look through the trace to find out what happened to the
registers. Turns out it's quite simple. They are copied from
the 64-bit first level register save area to a system save area
near the start and restored to the DFHITS 64-bit first l
IMO there's an incompatibility between something in the LE support and
plastic pipes. I suffered similar abends a couple of years ago calling
LDAPSRCH (GLDSRCH module) from a pipe until I reverted to the product (ESA)
version of pipelines. I beat on it a while, and discussed it with John,
but eve
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 envir
I'm getting tired of fighting the CMS stage and the address CMS (statement
or REXX' default).
Kris Buelens,
--- freelance z/VM consultant, Belgium ---
---
2014-06-25 21:34 GMT+02:00 Shimon Lebowitz :
> As soon as I saw th
As soon as I saw that "CMS GLOBALV" I sort of gasped, and
was sure Kris would immediately respond. :)
It does seem easy enough to create a GLOBALV EXEC and then open
an APAR when the compiler fails.
Shimon
On Wed, Jun 25, 2014 at 9:14 PM, Rob van der Heij wrote:
> Or maybe have a GLOBALV EXE
Or maybe have a GLOBALV EXEC on your A-disk that does not produce more than
1 line of output... ;-)
If this is how they access the GLOBALV variables, I'm not sure I want to
sit next to them at dinner (sharp steak knifes etc)
On 25 June 2014 20:08, Glenn Knickerbocker wrote:
> On 6/25/2014 8:08
On 6/25/2014 8:08 AM, Jonathan Scott wrote:
> 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
D'oh! I don't know why it didn't occur to
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,
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 t
If you have PER-3:
d bear
HCPCDH6164E PER-3 hardware facility is not installed
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
I get the same error (except for a different address).
The 0C1 occurs when a PIPE command is issued via the C system()
interface EDCSYSCM, which issues a CMSCALL. On return to
EDCSYSCM, the base register has been changed (and so have the
other registers) causing a wild branch. The command D BEAR
We're getting ready for the new level of PL/X and learned the compiler
only runs in z/CMS. This means, of course, testing out everything else
that needs to be used along with it in z/CMS. Here's a wacky one: The
v2r4 levels of the PL/X compiler abend in z/CMS if the uplevel Pipelines
is loaded.
12 matches
Mail list logo
