Hi All, One thing I have noticed from the report is that most of the user ID are the reason for volume contentions.
Name Reason Critical val. Possible cause or action DOV0053 DEV -Z18RS1 93.0 % delay May be reserved by another system. DOV0061 DEV -Z18RS1 92.0 % delay May be reserved by another system. DOV0065 DEV -Z18RS1 91.0 % delay May be reserved by another system. Is it something I need to look into user's Proc ? Could anyone please throw some light on this. Jags On Mon, Jan 2, 2012 at 11:49 AM, jagadishan perumal <jagadish...@gmail.com>wrote: > Hi Mark, > > "Are you in a shared DASD environment? If not, is there a test / sandbox > LPAR up accessing that volume? Even so, I've shared / share the sysres > between different monoplex systems without any problems because it > is "read only" and much of the access comes from the LNKLST / LLA / VLF > which means there is also no I/O contention." > > Yes we in a shared DASD environment. > > On Thu, Dec 29, 2011 at 7:21 PM, Mark Zelden <m...@mzelden.com> wrote: > >> On Thu, 29 Dec 2011 12:39:44 +0530, jagadishan perumal < >> jagadish...@gmail.com> wrote: >> >> >Hi, >> > >> >I was examining the RMF delay report where below is the report : >> > >> > Speed of 100 = Maximum, 0 = Stopped Average CPU Util: >> >19 % >> >Name Users Active Speed Name Users Active >> >Speed >> >*SYSTEM 203 58 8 *DEV 107 >> >54 8 >> >ALL TSO 119 52 5 *MASTER* 1 0 >> >56 >> >ALL STC 74 3 >> >40 >> >ALL BATCH 8 4 >> >21 >> >ALL ASCH Not >> >avail >> >ALL OMVS 2 0 No >> >work >> >*PROC 129 3 >> >7 >> > >> > >> >------------------------------ Exceptions >> >------------------------------------- >> >Name Reason Critical val. Possible cause or >> >action >> >DOV0053 DEV -Z18RS1 93.0 % delay May be reserved by another >> >system. >> >DOV0061 DEV -Z18RS1 92.0 % delay May be reserved by another >> >system. >> >DOV0065 DEV -Z18RS1 91.0 % delay May be reserved by another >> >system. >> > >> >The above exceptions shows lot of device contention due to which often we >> >are facing a session hang. Also, Device display shows the status as >> >BSY(busy). Could anyone please throw some light on the above issue. >> > >> >Jags >> > >> >> >> Are you in a shared DASD environment? If not, is there a test / sandbox >> LPAR up accessing that volume? Even so, I've shared / share the sysres >> between different monoplex systems without any problems because it >> is "read only" and much of the access comes from the LNKLST / LLA / VLF >> which means there is also no I/O contention. >> >> If you are sharing it in some way, it looks like there is a data set on >> that volume >> that is subject to RESERVE. You can check what it is from the other >> system(s) >> using RMF post processor reports if you have the option turned on or look >> real time via "TSO RMFMON" SENQR option (PF9) and keep hitting >> enter until you see it, or use the RMF III ENQR command. >> >> The big problem here isn't that there is a RESERVE, it is that going by >> the volser name this looks like your sysres volume or part of the sysres >> set. There should be no data sets on your sysres subject to RESERVE >> (except the VTOC and VVDS if you have your zFS files on there). >> >> >> Regards, >> >> Mark >> -- >> Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS >> mailto:m...@mzelden.com >> Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html >> Systems Programming expert at http://expertanswercenter.techtarget.com/ >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN >> > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
