PDSE processing has its own latch manager, which predates the design and
implementation of GRS latches.
Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY
> And yes, we definitely had PDSE Latch contention, and *something*
> was very wrong. Note that there is n
Hi Greg,
>A FORCE command becomes a CALLRTM TYPE=MEMTERM request which will drive
>address space level resource manager routines in the *MASTER* address
>space for the memterm'd address space. Ideally a resource manager
>routine should never need, or at least wait for, serialization of a
>resourc
d the dump
that I took 17 minutes later shows the address space still up with ASCBEWST (address
space last lost control) about 1s after $HASP310 INIT TERMINATED AT END OF MEMORY. I
do see the initiator restarted 25 minutes after.
Barbara,
FORCE processing does not know or care what an add
Barbara Nitz wrote:
>Apparently we ran into another of those PDSE latch contention bugs. While
>terminating the holder of the latch, we had to force the batch job since
>cancel had absolutely no effect.
[ ... snipped ... ]
At what z/OS version are you? Latest fix level?
What is your PDSESHAR
0040
IEF743I AUTO39P FORCED - CODE SA22 - IN ADDRESS SPACE 0040
$HASP310 AUTO39P TERMINATED AT END OF MEMORY
$HASP310 INIT TERMINATED AT END OF MEMORY
According to the books, IEF743I means "System action: The job and address space
end." Unfortunately that does not seem to be the c
- IN ADDRESS SPACE 0040
$HASP310 AUTO39P TERMINATED AT END OF MEMORY
$HASP310 INIT TERMINATED AT END OF MEMORY
According to the books, IEF743I means "System action: The job and address space
end." Unfortunately that does not seem to be the case. There is no indication
that I c
