>The reason is that we sometimes we get a deadly embrace where two SMFDUMP
>issue those ENQs and then while the system is doing its 'I SMF' things, >it still scans the DASD despite that we do not record SMF type 19. > >In the end I need to cancel one of those SMF jobs, let the other run and >retry with possible loss of data. You wrote about "your" SMFDUMP program. What is that? The one provided by z/OS does not use that ENQ. Regardless, the ENQ you show is a SYSTEM level ENQ, not a SYSTEMS level ENQ. Thus reserve is not appropriate and holding of this ENQ on one LPAR will have no effect on another LPAR. It makes no sense to have unique names per LPAR for a system-level ENQ (or any correctly needed ENQ, of course). 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. Since the system's "I SMF" does not get this ENQ as far as I know, it cannot be waiting for completion of your SMFDUMP. If you are converting ENQ's to reserves, I could imagine general cases where you would get into deadlocks. But I don't think that would happen in a case where each process gets only one serializing resource (e.g., ENQ). A "deadly embrace" is typically where process A holds resource RA and goes after a resource RB held by process B, while process B holds resource RB and goes after resource RA held by process A. Obviously it can be far more complex than that. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
