>When a WTO message ID matches a SLIP MSGID, we issue a 06F-8 abend
>to get into an RTM1 environment (for branch entry WTO) or RTM2
>environment (for SVC entry WTO). This allowed us to avoid the
>development cost of creating a new SLIP environment. We retry
>from the 06F-8 abend without
> Ohhh my. I just asked engineering to set a SLIP as you suggested,
> Jim, hoping it will match. The above is bad news. I will have them
> to run the job with LE TRAP(OFF), but I suspect this will not help.
> I mentioned there it SmartRestart that our appications depend on.
> SmartRestart
>You are right, I have to eat those words. ESPIE processing
translates unresolved program interrupt codes x'10', x'11',
x'38', x'39', x'3A', and x'3B' into program interrupt code 4,
so an ESPIE established for interrupt code 4 will also get control
for any of those access exceptions when they
>Make sure that you have your systrace set at maximum, then (not the default
>64K, and even 1MB will not be enough, especially on a busy system).
I had a look at the size recently but can't remember what it was right now. But
I remember It to be of decent size.
>Did you get the same set of
> > >I don't know how LE plays that game. A SLIP of the 0C4 would have
> true contents.
> > System Trace would also help with this information but it is not
> in the dump produced by the "little"helpers". Setting a SLIP in
> production is a not so short adventure trip; and SLIPping for a 0C4
>
>Since z/OS V1.13, you can add CEEOPTS as a JCL Statement
Yes, I know. It is not that I would not know *what* to do if I was allowed to
do it.
--
Peter Hunkeler
--
For IBM-MAIN subscribe / signoff / archive access
Since z/OS V1.13, you can add CEEOPTS as a JCL Statement
https://www.ibm.com/support/knowledgecenter/SSLTBW_1.13.0/com.ibm.zos.r13.ceea50
0/ceedd.htm
Language Environment allows you to provide additional invocation-level run-time
options using the CEEOPTS DD statement. The CEEOPTS DD can refer
> >I don't know how LE plays that game. A SLIP of the 0C4 would have true
> >contents.
> System Trace would also help with this information but it is not in the dump
> produced by the "little"helpers". Setting a SLIP in production is a not so
> short adventure trip; and SLIPping for a 0C4 is
>You told us that the instruction address where the BASSM goes is correct.
No, I told that the address fetched into R15 matches where the BASSM jumped to
and matches what is seem in the PSW.
>What happens, if you switch off LE dump processing by LE option TRAP(OFF)?
I don't dare to ask
>[snip] I would take a closer look at the call position of the COBOL module at
>level 3, at position 4396.
>The name is HRDRFREA. >>maybe this is all misleading ...
I agree with your findings. Module HRDRFREA is calling DSNHLI at this offset.
So far nothing special. However, the job runs
On 7/26/2016 7:20 AM, Peter Hunkeler wrote:
Thanks, Ed, I wasn't aware of the *trailing* whilte space behaviour. However, I
think apart from that Listserv removes all leading space (and multiple spaces?)
and thus also makes reading the dump output difficult.
It does nothing of the kind! I
>:>That would lead to a S0C4-4 not S0C4-11, wouldn't it?
>
>Program Unit: Entry: Statement: Offset: -01BE8FAE
>Machine State:
>ILC. 0002Interruption Code. 0004
Thanks. I was mislead by the fact the the failure was reported as S0C4 reason
11 in the joblog. Also LE as well as IPCS
Thanks, Ed, I wasn't aware of the *trailing* whilte space behaviour. However, I
think apart from that Listserv removes all leading space (and multiple spaces?)
and thus also makes reading the dump output difficult.
--Peter Hunkeler
>It seems that you branched to a location that is fetch protected and not in
>key 8.
That would lead to a S0C4-4 not S0C4-11, wouldn't it?
>What do you expect to find at 231A7BB8? My guess is that the LE formatter is
>showing all zeroes since it cannot access it.
The storage is
14 matches
Mail list logo
