Tom Marchant wrote:
>Not the SYSTEM level ENQ that you have shown, unless you have added IPOSMF01
>to the INCLude list in GRSRNKxx.
It is not there in GRSRNLxx (or GRSRNKxx which you wrote... ;-D ).
>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?
This why I asked if the usage of that GRS is causing delays or not. Is that
SMFDUMP WAD?
What is more, I forgot to post this to Peter Relson this:
IEF196I IOS071I 6F85,**,*MASTER*, START PENDING
IOS071I 6F85,**,*MASTER*, START PENDING 203
IOS431I DEVICE 6F85 RESERVED TO CPU=.....,LPAR ID=04 205
SYSTEM=????
IEA630I OPERATOR SYSIOSRS NOW ACTIVE, SYSTEM=???? , LU=IOSAS
ISG343I 00.32.11 GRS STATUS 713 208
DEVICE:6F85 VOLUME:SMF004 RESERVED BY SYSTEM ????
S=SYSTEMS IPOSMF01 DUMPOUT
SYSNAME JOBNAME ASID TCBADDR EXC/SHR STATUS
???? SMF???? 0048 00AFF048 EXCLUSIVE OWN
This, the S=SYSTEMS is NOT the same as in the source which is S=SYSTEM.
Majorname is the same in the source, but not the Minor name (RNAME).
>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.
All my SMF datasets are dumped during the 24 hours as soon as a *single*
dataset get DUMP marked (IEE391A). Then just after midnight all my SMFDUMP jobs
(emptying all SMF datasets) are staggered about 5 - 15 minutes apart.
Thanks to all. I'm beginning to wonder if the SMFDUMP program may be corrupt
and need to be re-assembled from scratch. Or tryout file 686 from cbttape.org.
Or I need to stagger them further apart... Hmmm... anyone have a good idea?
Groete / Greetings
Elardus Engelbrecht
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
