Re: Clarification on Sysres Volumes(RMF)
Jags, If you have an active HASCKPT dataset on your RES volume, then move it. Once that is done you can see if there are other problems. There is no question of whether a HASCKPT will cause performance problems, if JES2 is using it then it will cause problems. It does not belong there and needs to be moved. On Wed, Jan 4, 2012 at 2:24 AM, jagadishan perumal jagadish...@gmail.comwrote: Hi All, I ran a report Against a TSO ID which had a volume contention and found the below as the result : Samples: 100 System: ZOSB Date: 01/04/12 Time: 12.43.20 Range: 100 Sec Job: *TCHN039* Primary delay: Excessive pending time on volume Z18RS1. Probable causes: 1) Contention with another system for use of the volume. 2) Overutilized channel, control unit or head of string. -- Volume Z18RS1 Device Data -- Number:D700Active: 80%Pending: 69% Average Users Device:33903 Connect: 11%Delay DB: 0% Delayed Shared:Yes Disconnect: 0%Delay CM: 0% 9.9 --- Job Performance Summary --- Service WFL -Using%- DLY IDL UKN % Delayed for Primary CX ASID ClassP Cr % PRC DEV % % % PRC DEV STR SUB OPR ENQ Reason T 0264 TSO * 90 4 42 45 9 1 41 0 0 0 0 Z18RS1 TSO 1 220 4 14 45 8 0 14 0 0 0 0 Z18RS1 TSO 2 00 0 28 0 1 1 27 0 0 0 0 Z18RS1 Probable cause says as : 1) Contention with another system for use of the volume.- Volume is not shared 2) Overutilized channel, control unit or head of string. - We have two channels operational but is it again we need to re-look into channel activities ? Regards, Jags On Wed, Jan 4, 2012 at 5:11 AM, Gibney, Dave gib...@wsu.edu wrote: Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Lizette Koehler Sent: Tuesday, January 03, 2012 5:47 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Clarification on Sysres Volumes(RMF) Hi Lizette, Apology for not being precise. Datasets found in SYSRES are : are some BCP related datasets , assembler datasets,language environment datasets,IBM book manager datasets First failure Support technology(FFST) datasets are found. During This Situation when I do : /D GRS,C It does really produces any information about Volume or Dataset Contention. As per Mark advise I did TSO RMFMON and Found some SYS1.HASCKPT datasets used by JES2, some User Job using their Assigned volumes. Jags Jags, It is important to provide information when asked. We cannot see your environment. When you ask a question - How can I fix this. We must ask questions to help. The areas you need to research are 1) GRS entries. Is your GRSRNLxx member setup correctly for your environment. 2) Verify what files are accessed when this occurs 3) Verify you only have z/OS TLIB datasets on your SYSRES volume. If you have other datasets, you need to determine the impact to your SYSRES volume. 4) Verify if you have any HFS or zFS files on your SYSRES volume. 5) Verify if you have any SYS1.DUMPxx datasets on your SYSRES volume 6) Verify if you have any Security (RACF, Top Secret, ACF2) Data bases on your SYSRES volume 7) Run performance reports on your volume to see what is open during the time of RMF issue. Identify what datasets have the highest access during the RMF issue. I would add and move elsewhere after the word Verify in the above advice. :) Dave Gibney Information Technology Services Washington State University Are you saying you have the JES2 HASPCKPT dataset on your SYSRES Volume? That needs to move. It should be on a separate volume. You must do these steps. You must review your system. You will need to do the analysis to determine your issue. When starting to understand I/O issues with volumes, this is a good overview http://publib.boulder.ibm.com/tividd/td/TDS390/SH19-6818- 08/en_US/HTML/DRLM9 mst61.htm And the following REDBOOKs should help Effective zSeries Performance Monitoring Using Resource Measurement Facility http://www.redbooks.ibm.com/abstracts/sg246645.html?Open Using Resource Measurement Facility Monitor III Efficiently http://www.redbooks.ibm.com/abstracts/gg244131.html?Open Parallel Sysplex Performance Healthcheck Case Study: DMData/Danske Data http://www.redbooks.ibm.com/abstracts/sg245373.html?Open The only datasets on a SYSRES IMHO are the Tlibs from
Re: Clarification on Sysres Volumes(RMF)
Hi All, One thing I have noticed from the report is that most of the user ID are the reason for volume contentions. Name ReasonCritical val. Possible cause or action DOV0053DEV -Z18RS193.0 % delay May be reserved by another system. DOV0061DEV -Z18RS192.0 % delay May be reserved by another system. DOV0065DEV -Z18RS191.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 Jags, Have you tried to see what datasets are open and enq'd during this time? What research have you done? What datasets are on your SYSRES volume? You have not answered these qestions. Have you issued a D GRS,C to see if anything is obvious? Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Clarification on Sysres Volumes(RMF)
Little Correction : During This Situation when I do : /D GRS,C It does really produces any information about Volume or Dataset Contention. I meant It doesnt Produces any result pertaining to dataset or volume contentions. Jags On Tue, Jan 3, 2012 at 1:43 PM, jagadishan perumal jagadish...@gmail.comwrote: Hi Lizette, Apology for not being precise. Datasets found in SYSRES are : are some BCP related datasets , assembler datasets,language environment datasets,IBM book manager datasets First failure Support technology(FFST) datasets are found. During This Situation when I do : /D GRS,C It does really produces any information about Volume or Dataset Contention. As per Mark advise I did TSO RMFMON and Found some SYS1.HASCKPT datasets used by JES2, some User Job using their Assigned volumes. Jags On Tue, Jan 3, 2012 at 1:21 PM, Lizette Koehler stars...@mindspring.com wrote: Hi All, One thing I have noticed from the report is that most of the user ID are the reason for volume contentions. Name ReasonCritical val. Possible cause or action DOV0053DEV -Z18RS193.0 % delay May be reserved by another system. DOV0061DEV -Z18RS192.0 % delay May be reserved by another system. DOV0065DEV -Z18RS191.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 Jags, Have you tried to see what datasets are open and enq'd during this time? What research have you done? What datasets are on your SYSRES volume? You have not answered these qestions. Have you issued a D GRS,C to see if anything is obvious? Lizette -- 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
Re: Clarification on Sysres Volumes(RMF)
Hi Lizette, Apology for not being precise. Datasets found in SYSRES are : are some BCP related datasets , assembler datasets,language environment datasets,IBM book manager datasets First failure Support technology(FFST) datasets are found. During This Situation when I do : /D GRS,C It does really produces any information about Volume or Dataset Contention. As per Mark advise I did TSO RMFMON and Found some SYS1.HASCKPT datasets used by JES2, some User Job using their Assigned volumes. Jags On Tue, Jan 3, 2012 at 1:21 PM, Lizette Koehler stars...@mindspring.comwrote: Hi All, One thing I have noticed from the report is that most of the user ID are the reason for volume contentions. Name ReasonCritical val. Possible cause or action DOV0053DEV -Z18RS193.0 % delay May be reserved by another system. DOV0061DEV -Z18RS192.0 % delay May be reserved by another system. DOV0065DEV -Z18RS191.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 Jags, Have you tried to see what datasets are open and enq'd during this time? What research have you done? What datasets are on your SYSRES volume? You have not answered these qestions. Have you issued a D GRS,C to see if anything is obvious? Lizette -- 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
Re: Clarification on Sysres Volumes(RMF)
I believe JES2 uses physical reserves on entire volume when accessing HASPCKPT datasets and depending on your JES PARMLIB member may hold it for a significant time -- not a good dataset type to put on a SYSRES shared with other systems. Others may be able to suggest JES PARMLIB changes to shorten the hold time, but I would move all HASPCKPT datasets to volumes that have minimal shared access with another system, or at very least off volumes like SYSRES that contain many performance-critical datasets needed by all systems sharing that SYSRES. I suspect the usual z/OS manual recommendations are to put HASPCKPT on a volume by itself, but a sufficiently quiet volume is good enough. JC Ewing On 01/03/2012 02:13 AM, jagadishan perumal wrote: Hi Lizette, Apology for not being precise. Datasets found in SYSRES are : are some BCP related datasets , assembler datasets,language environment datasets,IBM book manager datasets First failure Support technology(FFST) datasets are found. During This Situation when I do : /D GRS,C It does really produces any information about Volume or Dataset Contention. As per Mark advise I did TSO RMFMON and Found some SYS1.HASCKPT datasets used by JES2, some User Job using their Assigned volumes. Jags On Tue, Jan 3, 2012 at 1:21 PM, Lizette Koehlerstars...@mindspring.comwrote: Hi All, One thing I have noticed from the report is that most of the user ID are the reason for volume contentions. Name ReasonCritical val. Possible cause or action DOV0053DEV -Z18RS193.0 % delay May be reserved by another system. DOV0061DEV -Z18RS192.0 % delay May be reserved by another system. DOV0065DEV -Z18RS191.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 Jags, Have you tried to see what datasets are open and enq'd during this time? What research have you done? What datasets are on your SYSRES volume? You have not answered these qestions. Have you issued a D GRS,C to see if anything is obvious? Lizette -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Clarification on Sysres Volumes(RMF)
Hi Lizette, Apology for not being precise. Datasets found in SYSRES are : are some BCP related datasets , assembler datasets,language environment datasets,IBM book manager datasets First failure Support technology(FFST) datasets are found. During This Situation when I do : /D GRS,C It does really produces any information about Volume or Dataset Contention. As per Mark advise I did TSO RMFMON and Found some SYS1.HASCKPT datasets used by JES2, some User Job using their Assigned volumes. Jags Jags, It is important to provide information when asked. We cannot see your environment. When you ask a question - How can I fix this. We must ask questions to help. The areas you need to research are 1) GRS entries. Is your GRSRNLxx member setup correctly for your environment. 2) Verify what files are accessed when this occurs 3) Verify you only have z/OS TLIB datasets on your SYSRES volume. If you have other datasets, you need to determine the impact to your SYSRES volume. 4) Verify if you have any HFS or zFS files on your SYSRES volume. 5) Verify if you have any SYS1.DUMPxx datasets on your SYSRES volume 6) Verify if you have any Security (RACF, Top Secret, ACF2) Data bases on your SYSRES volume 7) Run performance reports on your volume to see what is open during the time of RMF issue. Identify what datasets have the highest access during the RMF issue. Are you saying you have the JES2 HASPCKPT dataset on your SYSRES Volume? That needs to move. It should be on a separate volume. You must do these steps. You must review your system. You will need to do the analysis to determine your issue. When starting to understand I/O issues with volumes, this is a good overview http://publib.boulder.ibm.com/tividd/td/TDS390/SH19-6818-08/en_US/HTML/DRLM9 mst61.htm And the following REDBOOKs should help Effective zSeries Performance Monitoring Using Resource Measurement Facility http://www.redbooks.ibm.com/abstracts/sg246645.html?Open Using Resource Measurement Facility Monitor III Efficiently http://www.redbooks.ibm.com/abstracts/gg244131.html?Open Parallel Sysplex Performance Healthcheck Case Study: DMData/Danske Data http://www.redbooks.ibm.com/abstracts/sg245373.html?Open The only datasets on a SYSRES IMHO are the Tlibs from the serverpac/cpac or initial install. All other datasets should be on a separate volume(s). Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Clarification on Sysres Volumes(RMF)
On Tue, 3 Jan 2012 13:43:02 +0530, jagadishan perumal jagadish...@gmail.com wrote: Apology for not being precise. . As per Mark advise I did TSO RMFMON and Found some SYS1.HASCKPT datasets used by JES2, some User Job using their Assigned volumes. chuckle (sorry). That will do it! No operational data sets should be on your sysres. Especially one that is subject to RESERVE like the HASPCKPT will be. Since it is subject to RESERVE, if you have the space, it should be on its own volume or on a volume with data sets that are rarely accessed. Read the JES2 manuals about using $TCKPTDEF to set up a NEWCKPT1 (if you don't already have one) and the reconfiguration dialogs ($TCKPTDEF,RECONFIG=YES) to move the checkpoint to another volume. 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
Re: Clarification on Sysres Volumes(RMF)
Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Lizette Koehler Sent: Tuesday, January 03, 2012 5:47 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Clarification on Sysres Volumes(RMF) Hi Lizette, Apology for not being precise. Datasets found in SYSRES are : are some BCP related datasets , assembler datasets,language environment datasets,IBM book manager datasets First failure Support technology(FFST) datasets are found. During This Situation when I do : /D GRS,C It does really produces any information about Volume or Dataset Contention. As per Mark advise I did TSO RMFMON and Found some SYS1.HASCKPT datasets used by JES2, some User Job using their Assigned volumes. Jags Jags, It is important to provide information when asked. We cannot see your environment. When you ask a question - How can I fix this. We must ask questions to help. The areas you need to research are 1) GRS entries. Is your GRSRNLxx member setup correctly for your environment. 2) Verify what files are accessed when this occurs 3) Verify you only have z/OS TLIB datasets on your SYSRES volume. If you have other datasets, you need to determine the impact to your SYSRES volume. 4) Verify if you have any HFS or zFS files on your SYSRES volume. 5) Verify if you have any SYS1.DUMPxx datasets on your SYSRES volume 6) Verify if you have any Security (RACF, Top Secret, ACF2) Data bases on your SYSRES volume 7) Run performance reports on your volume to see what is open during the time of RMF issue. Identify what datasets have the highest access during the RMF issue. I would add and move elsewhere after the word Verify in the above advice. :) Dave Gibney Information Technology Services Washington State University Are you saying you have the JES2 HASPCKPT dataset on your SYSRES Volume? That needs to move. It should be on a separate volume. You must do these steps. You must review your system. You will need to do the analysis to determine your issue. When starting to understand I/O issues with volumes, this is a good overview http://publib.boulder.ibm.com/tividd/td/TDS390/SH19-6818- 08/en_US/HTML/DRLM9 mst61.htm And the following REDBOOKs should help Effective zSeries Performance Monitoring Using Resource Measurement Facility http://www.redbooks.ibm.com/abstracts/sg246645.html?Open Using Resource Measurement Facility Monitor III Efficiently http://www.redbooks.ibm.com/abstracts/gg244131.html?Open Parallel Sysplex Performance Healthcheck Case Study: DMData/Danske Data http://www.redbooks.ibm.com/abstracts/sg245373.html?Open The only datasets on a SYSRES IMHO are the Tlibs from the serverpac/cpac or initial install. All other datasets should be on a separate volume(s). Lizette -- 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
Re: Clarification on Sysres Volumes(RMF)
Hi All, I ran a report Against a TSO ID which had a volume contention and found the below as the result : Samples: 100 System: ZOSB Date: 01/04/12 Time: 12.43.20 Range: 100 Sec Job: *TCHN039* Primary delay: Excessive pending time on volume Z18RS1. Probable causes: 1) Contention with another system for use of the volume. 2) Overutilized channel, control unit or head of string. -- Volume Z18RS1 Device Data -- Number:D700Active: 80%Pending: 69% Average Users Device:33903 Connect: 11%Delay DB: 0% Delayed Shared:Yes Disconnect: 0%Delay CM: 0% 9.9 --- Job Performance Summary --- Service WFL -Using%- DLY IDL UKN % Delayed for Primary CX ASID ClassP Cr % PRC DEV % % % PRC DEV STR SUB OPR ENQ Reason T 0264 TSO * 90 4 42 45 9 1 41 0 0 0 0 Z18RS1 TSO 1 220 4 14 45 8 0 14 0 0 0 0 Z18RS1 TSO 2 00 0 28 0 1 1 27 0 0 0 0 Z18RS1 Probable cause says as : 1) Contention with another system for use of the volume.- Volume is not shared 2) Overutilized channel, control unit or head of string. - We have two channels operational but is it again we need to re-look into channel activities ? Regards, Jags On Wed, Jan 4, 2012 at 5:11 AM, Gibney, Dave gib...@wsu.edu wrote: Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Lizette Koehler Sent: Tuesday, January 03, 2012 5:47 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Clarification on Sysres Volumes(RMF) Hi Lizette, Apology for not being precise. Datasets found in SYSRES are : are some BCP related datasets , assembler datasets,language environment datasets,IBM book manager datasets First failure Support technology(FFST) datasets are found. During This Situation when I do : /D GRS,C It does really produces any information about Volume or Dataset Contention. As per Mark advise I did TSO RMFMON and Found some SYS1.HASCKPT datasets used by JES2, some User Job using their Assigned volumes. Jags Jags, It is important to provide information when asked. We cannot see your environment. When you ask a question - How can I fix this. We must ask questions to help. The areas you need to research are 1) GRS entries. Is your GRSRNLxx member setup correctly for your environment. 2) Verify what files are accessed when this occurs 3) Verify you only have z/OS TLIB datasets on your SYSRES volume. If you have other datasets, you need to determine the impact to your SYSRES volume. 4) Verify if you have any HFS or zFS files on your SYSRES volume. 5) Verify if you have any SYS1.DUMPxx datasets on your SYSRES volume 6) Verify if you have any Security (RACF, Top Secret, ACF2) Data bases on your SYSRES volume 7) Run performance reports on your volume to see what is open during the time of RMF issue. Identify what datasets have the highest access during the RMF issue. I would add and move elsewhere after the word Verify in the above advice. :) Dave Gibney Information Technology Services Washington State University Are you saying you have the JES2 HASPCKPT dataset on your SYSRES Volume? That needs to move. It should be on a separate volume. You must do these steps. You must review your system. You will need to do the analysis to determine your issue. When starting to understand I/O issues with volumes, this is a good overview http://publib.boulder.ibm.com/tividd/td/TDS390/SH19-6818- 08/en_US/HTML/DRLM9 mst61.htm And the following REDBOOKs should help Effective zSeries Performance Monitoring Using Resource Measurement Facility http://www.redbooks.ibm.com/abstracts/sg246645.html?Open Using Resource Measurement Facility Monitor III Efficiently http://www.redbooks.ibm.com/abstracts/gg244131.html?Open Parallel Sysplex Performance Healthcheck Case Study: DMData/Danske Data http://www.redbooks.ibm.com/abstracts/sg245373.html?Open The only datasets on a SYSRES IMHO are the Tlibs from the serverpac/cpac or initial install. All other datasets should be on a separate volume(s). Lizette -- 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
Re: Clarification on Sysres Volumes(RMF)
Hi All, One thing I have noticed from the report is that most of the user ID are the reason for volume contentions. Name ReasonCritical val. Possible cause or action DOV0053DEV -Z18RS193.0 % delay May be reserved by another system. DOV0061DEV -Z18RS192.0 % delay May be reserved by another system. DOV0065DEV -Z18RS191.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.comwrote: 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 0No work *PROC129 3 7 -- Exceptions - Name ReasonCritical val. Possible cause or action DOV0053DEV -Z18RS193.0 % delay May be reserved by another system. DOV0061DEV -Z18RS192.0 % delay May be reserved by another system. DOV0065DEV -Z18RS191.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
Re: Clarification on Sysres Volumes(RMF)
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 0No work *PROC129 3 7 -- Exceptions - Name ReasonCritical val. Possible cause or action DOV0053DEV -Z18RS193.0 % delay May be reserved by another system. DOV0061DEV -Z18RS192.0 % delay May be reserved by another system. DOV0065DEV -Z18RS191.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
Re: Clarification on Sysres Volumes(RMF)
Jags, Is your GRS-plex set up properly to propagate ENQs and RESERVEs across all the systems in your shared DASD complex? IMHO, under normal conditions, you should not have hard RESERVEs on a disk impacting your systems. Regards, Ulrich Krueger -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of jagadishan perumal Sent: Wednesday, December 28, 2011 11:10 PM To: IBM-MAIN@bama.ua.edu Subject: Clarification on Sysres Volumes(RMF) 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 0No work *PROC129 3 7 -- Exceptions - Name ReasonCritical val. Possible cause or action DOV0053DEV -Z18RS193.0 % delay May be reserved by another system. DOV0061DEV -Z18RS192.0 % delay May be reserved by another system. DOV0065DEV -Z18RS191.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 -- 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
Re: Clarification on Sysres Volumes(RMF)
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 0No work *PROC129 3 7 -- Exceptions - Name ReasonCritical val. Possible cause or action DOV0053DEV -Z18RS193.0 % delay May be reserved by another system. DOV0061DEV -Z18RS192.0 % delay May be reserved by another system. DOV0065DEV -Z18RS191.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
Re: Clarification on Sysres Volumes(RMF)
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 0No work *PROC129 3 7 -- Exceptions - Name ReasonCritical val. Possible cause or action DOV0053DEV -Z18RS193.0 % delay May be reserved by another system. DOV0061DEV -Z18RS192.0 % delay May be reserved by another system. DOV0065DEV -Z18RS191.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 Jags, What is on your SYSRES Volume? Do you have datasets that get updated there? You have to review the datasets and see which ones are getting hit the most. What do you have on your sysres volume that has a high usage? If you have MXG or MICS it can help you answer that question. You need to research this and see what is impacting the sysres volume. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Clarification on Sysres Volumes(RMF)
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 0No work *PROC129 3 7 -- Exceptions - Name ReasonCritical val. Possible cause or action DOV0053DEV -Z18RS193.0 % delay May be reserved by another system. DOV0061DEV -Z18RS192.0 % delay May be reserved by another system. DOV0065DEV -Z18RS191.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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
