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 no data set name in the display: > V SMS,PDSE1,ANALYSIS > IGW031I PDSE ANALYSIS Start of Report(SMSPDSE1) 214 > ---------data set name---------------------- -----vsgt------- > 01-ASPIL0-00011C > ++ Unable to latch DIB:000000007E9BE0A0 > Latch:000000007F7D5F08 Holder(0040:009C7248) > Holding Job:AUTO39P > CallingSequence:IGWLHJIN IGWDACND IGWDBPAR IGWFARR3 > ++ Unable to latch LSDLTDW:000000007F6BF680 > Latch:000000007F6BF798 Holder(0040:009C7248) > Holding Job:AUTO39P > ++ Lock GLOBAL DIRECTORY SHARED > held for at least 842 seconds > Hl1b:7F7D5DB0 HOLDER(0040:009C7248) > Holding Job:AUTO39P > ++ Lock GLOBAL FORMATWRITE SHARED > held for at least 842 seconds > Hl1b:7F7D5DB0 HOLDER(0040:009C7248) > Holding Job:AUTO39P > > There was no ENQ contention when we first had this latch contention. > It looks a bit like oa51460, except the address space in question > never got canceled. There was an abend913 earlier in PDSE processing > showing the same calling sequence as mentioned in oa5160, but that > was another address space. > I have no clue if or how MIM handles Latches. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
