The behavior of your systems that you described sounds as if you have a global enqueue that is systems-wide rather than an enqueue that should only affect one system. The source code snippet you posted shows what looks correct for a local enqueue (within one system) rather than a global enqueue. You might also investigate whether your source code matches the load module that is executing. You can do this in at least two ways. The first way is to obtain a superzap dump of the load module, find the enqueue macro within the load module, disassemble the parameter list of the ENQ macro with the aid of the parameter list contents as shown in the MVS Diagnosis: Reference book (GA22-7588) for SVC 56, paying special attention to the bits involved with the SCOPE parameter. If the executable load module shows SCOPE=SYSTEMS, then that would explain your systems' behavior and also signal that your source code is down level. The second way is to run GTF on any one of the systems in! volved and trace only SVC 56 for the jobname of your SMF dump; then find the parameter list in the GTF trace and disassemble it as described above. I am not sure that this second way will work, however, as I do not remember if GTF traces the parameter list for SVC 56.
The issuance of multiple START PENDING messages does not automatically mean that there are performance problems anywhere. START PENDING means that some shared DASD data set is either being very heavily used or is RESERVEd on one system while another system is trying to do some kind of I/O to the same device, and the second system might even be trying to access a different data set from the one that the first system is using heavily or has reserved. A START PENDING message is one possible clue as to what is causing a performance problem, but don't go investigating any given START PENDING message unless you already know for some other reason that you are having a performance problem. One possible problem indicator would be that other work on the system with START PENDING messages is stopped because it is has an I/O request in the queue for the problem device. This situation will show up as an abnormally high average IOS queue length on that one device on a system with the! START PENDING messages. There are many other messages or indicators that can be used to diagnose a performance problem, but they do not automatically mean there is a problem. There is no performance problem anywhere unless someone is complaining. Bill Fairchild Programmer Rocket Software 408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA t: +1.617.614.4503 * e: [email protected] * w: www.rocketsoftware.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Tom Marchant Sent: Thursday, June 21, 2012 9:10 AM To: [email protected] Subject: Re: Why is GRS ENQ needed in SMFDUMP program? 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 [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
