Peter Relson wrote:
>You wrote about "your" SMFDUMP program. What is that? The one provided by z/OS
>does not use that ENQ.
The one as supplied by IBM. See copyright statement:
MODULE NAME = SMFDUMP
DESCRIPTIVE NAME = CUSTOM-BUILT IPO SUPPLIED
ROUTINE TO DUMP THE SMF DATASETS
COPYRIGHT = 5751-CS1
INTERNATIONAL BUSINESS MACHINES
CORPORATION, 1983, 1988
and modification history:
$MOD=(SMFDUMP) COMP(SMF) HDLD(MVS):
$CC= REASONCD,RELEASE#,DATECHGD,CINIT: DESCRIPTION
$D1= MSPIPOG, , , CHANGED IN MVS/SP IPO 3.8 G
$D2= MSPIPOF, , , CHANGED IN MVS/SP IPO 3.8 F
$D3= MSPIPOH, , , ...........................
$D4= MSPIPOI, , , ...........................
$D5= MSEIPO4, , , CHANGED TO SUPPORT MVS/SE2
$D6=CR#I70140, , , INSURE INTEGERITY OF SMFDUMPW
$D6= -------------------------------- DATASET.
$D7= CR24926, 9402,04/25/94, FJB SUPPORT 44 CHARACTER DSNAMES
$D7= -------------------------------- FOR SMF DUMP DATASETS, AND
$D7= -------------------------------- FOR VERSION 5.1 CHANGES.
$D8= PR01623, 9402P,09/20/94, WGL FIX MULTILINE WTO
$D9= PR02195, 9601P,01/18/96, JMC FIXED RDS OFFSETS
I'm using V5 not V4. it could be that someone modified it before my time...
>Regardless, the ENQ you show is a SYSTEM level ENQ, not a SYSTEMS level ENQ.
Indeed, from source this:
ENQ (SMFQNAME,SMFRNAME,E,,SYSTEM)
>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).
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.
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.
The problem is that overall performance on all the LPARs are suffering due to
START PENDING messages. Another problem, the operator and the MVS Team are
canceling my jobs thinking there is an error despite my instructions to leave
them out.
>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).
I'm not doing any converting. In fact, I asked about a strange name, SYSSMF01,
I saw in our GRSRNLxx. I'm very sure I'm not using it or any converting.
In any case, thanks for your kind reply. It will help me much!
Groete / Greetings
Elardus Engelbrecht
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
