On Thu, 21 Jun 2012 08:17:33 -0500, Elardus Engelbrecht wrote: >Peter Relson wrote: > >>... the ENQ you show is a SYSTEM level ENQ, not a SYSTEMS level ENQ. > >Indeed, from source this: > ENQ (SMFQNAME,SMFRNAME,E,,SYSTEM) > >>... holding of this ENQ on one LPAR will have no effect on another LPAR. > >Thanks. This is what I also understand after reading MVS Programming: >Authorized Assembler Services Reference, Volume 2 (EDTINFO-IXGWRITE). > > >>What exactly is the "deadly embrace" here? If the two SMFDUMP's both >>go after the ENQ, one will get it and one will wait. That is expected. > >Of course, I see one SMFDUMP with exclusive ENQ while other SMFDUMP >on other LPARS are waiting for it.
Not the SYSTEM level ENQ that you have shown, unless you have added IPOSMF01 to the INCLude list in GRSRNKxx. > >If one LPAR SMFDUMP finish a 'I SMF', it release the ENQ. Then ANOTHER >SMFDUMP on another LPAR which is waiting for the ENQ name, picks up >the ENQ and do its own 'I SMF' and so on on all the LPARs. Eventually the >first SMFDUMP obtains the ENQ and so on. All the SMFDUMP program are >getting a turn to do a 'I SMF'. It goes on until no SMF datasets are >remaining in DUMP status. So, the problem is not a deadly embrace, but delays in processing. I think you need to determine what is causing the delays. What is the impact of the delay? Is this happening because all of the LPARs are doing this processing at the same time? If, for example, this is happening because the SMF records for the whole day are being dumped on every LPAR at midnight, perhaps you could stagger the dumping somehow. -- Tom Marchant ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
