Re: IBM GRS Monitor report
You only get to update such volumes from one system. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Allan Staller > Sent: Wednesday, November 22, 2017 8:18 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: IBM GRS Monitor report > > There is no safe way to do this with the use of *RESERVE* (or CA-MIM). > > This is the source of you VTOC errors, etc. > > USE RNLDEF RNL(EXCL) for relevant QNAME, RNAME, and Volume. > Suggested Queues are SYSVTOC, SYSZVVDS as a minimum. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of PINION, RICHARD W. > Sent: Wednesday, November 22, 2017 10:06 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: IBM GRS Monitor report > > Yes > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Allan Staller > Sent: Wednesday, November 22, 2017 11:05 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: IBM GRS Monitor report > > [External Email] > > Are you sharing the volume across sysplex boundaries? > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of PINION, RICHARD W. > Sent: Wednesday, November 22, 2017 9:30 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: IBM GRS Monitor report > > We ran IBM's GRS Monitor batch reports and noticed something in one of > the reports. Notice the second entry, it has a x'004D'. The reason this is > interesting to us is because we are sharing this particular volume between > two systems. The second system is not in the GRS Star configuration of the > first system. > > We are using RESERVES to protect the integrity of the resources. And this > particular volume has encountered errors, i.e. VTOC entries but no SMS NVR > records. And yes, this volume is in a SMS SG which is defined to the two > systems. > > ** RESOURCES USAGE REPORT ** > > > ** MAJOR SYSZVVDS ** > - > COUNT MAJOR > > 8260SYSZVVDSSCOPE=RESERVE > SMFID=DEVA > > > RNL (ML) COUNT MAJOR MINOR > > 006 0032 SYSZVVDS TS0007 > 008 0004 SYSZVVDS TS0007 ( > FIRST TENNESSEE > > Confidentiality notice: > This e-mail message, including any attachments, may contain legally > privileged and/or confidential information. If you are not the intended > recipient(s), or the employee or agent responsible for delivery of this > message to the intended recipient(s), you are hereby notified that any > dissemination, distribution, or copying of this e-mail message is strictly > prohibited. If you have received this message in error, please immediately > notify the sender and delete this e-mail message from your computer. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > ::DISCLAIMER:: > > > > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. > E-mail transmission is not guaranteed to be secure or error-free as > information could be intercepted, corrupted, lost, destroyed, arrive late or > incomplete, or may contain viruses in transmission. The e mail and its > contents (with or without referred errors) shall therefore not attach any > liability on the originator or HCL or its affiliates. > Views or opinions, if any, presented in this email are solely those of the > author and may not necessarily reflect the views or opinions of HCL or its > affiliates. Any form of reproduction, dissemination, copying, disclosure, > modification, distribution and / or publication of this message without the > prior written consent of authorized representative of HCL is strictly > prohibited. If you have received this email in error please delete it and > notify > the sender immediately. > Before opening any email and/or attachments, please check them for viruses > and other defects. > > > > > -- > For IBM-MAIN subscrib
Re: IBM GRS Monitor report
There is no safe way to do this with the use of *RESERVE* (or CA-MIM). This is the source of you VTOC errors, etc. USE RNLDEF RNL(EXCL) for relevant QNAME, RNAME, and Volume. Suggested Queues are SYSVTOC, SYSZVVDS as a minimum. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of PINION, RICHARD W. Sent: Wednesday, November 22, 2017 10:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM GRS Monitor report Yes -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Wednesday, November 22, 2017 11:05 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM GRS Monitor report [External Email] Are you sharing the volume across sysplex boundaries? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of PINION, RICHARD W. Sent: Wednesday, November 22, 2017 9:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IBM GRS Monitor report We ran IBM's GRS Monitor batch reports and noticed something in one of the reports. Notice the second entry, it has a x'004D'. The reason this is interesting to us is because we are sharing this particular volume between two systems. The second system is not in the GRS Star configuration of the first system. We are using RESERVES to protect the integrity of the resources. And this particular volume has encountered errors, i.e. VTOC entries but no SMS NVR records. And yes, this volume is in a SMS SG which is defined to the two systems. ** RESOURCES USAGE REPORT ** ** MAJOR SYSZVVDS ** - COUNT MAJOR 8260SYSZVVDSSCOPE=RESERVE SMFID=DEVA RNL (ML) COUNT MAJOR MINOR 006 0032 SYSZVVDS TS0007 008 0004 SYSZVVDS TS0007 ( FIRST TENNESSEE Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM GRS Monitor report
Yes -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Wednesday, November 22, 2017 11:05 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM GRS Monitor report [External Email] Are you sharing the volume across sysplex boundaries? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of PINION, RICHARD W. Sent: Wednesday, November 22, 2017 9:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IBM GRS Monitor report We ran IBM's GRS Monitor batch reports and noticed something in one of the reports. Notice the second entry, it has a x'004D'. The reason this is interesting to us is because we are sharing this particular volume between two systems. The second system is not in the GRS Star configuration of the first system. We are using RESERVES to protect the integrity of the resources. And this particular volume has encountered errors, i.e. VTOC entries but no SMS NVR records. And yes, this volume is in a SMS SG which is defined to the two systems. ** RESOURCES USAGE REPORT ** ** MAJOR SYSZVVDS ** - COUNT MAJOR 8260SYSZVVDSSCOPE=RESERVE SMFID=DEVA RNL (ML) COUNT MAJOR MINOR 006 0032 SYSZVVDS TS0007 008 0004 SYSZVVDS TS0007 ( FIRST TENNESSEE Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM GRS Monitor report
Are you sharing the volume across sysplex boundaries? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of PINION, RICHARD W. Sent: Wednesday, November 22, 2017 9:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IBM GRS Monitor report We ran IBM's GRS Monitor batch reports and noticed something in one of the reports. Notice the second entry, it has a x'004D'. The reason this is interesting to us is because we are sharing this particular volume between two systems. The second system is not in the GRS Star configuration of the first system. We are using RESERVES to protect the integrity of the resources. And this particular volume has encountered errors, i.e. VTOC entries but no SMS NVR records. And yes, this volume is in a SMS SG which is defined to the two systems. ** RESOURCES USAGE REPORT ** ** MAJOR SYSZVVDS ** - COUNT MAJOR 8260SYSZVVDSSCOPE=RESERVE SMFID=DEVA RNL (ML) COUNT MAJOR MINOR 006 0032 SYSZVVDS TS0007 008 0004 SYSZVVDS TS0007 ( FIRST TENNESSEE Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM GRS Monitor report
some products or utilities will reserve the volume but if you are not in the same MIM PLEX or GRS, I think you're taking a big chance, I'll assume this volume is not a critical, or I'd hope a non critical volume and does not contain any PDS/E's or PDS/E sharing is turned off for that system . if the SMS environment is always the same, this volume is in the same storage pool name and the SMS configuration is kept identical should be OK, I've done it, don't like it but sometime you have to. I'D really be careful not putting anything that NEEDS to be shared , catalogs , loadlibs (PDS/E) TMC, or control datasets that are needed for both system on this volume, but I'll assume its not if its SMS managed. in a perfect world all system should be in the same plex and GRS=STAR, if not don't share datasets/volumes, but working for an outsourcer some clients LPARS did not want to play in the PLEX but there was a need to share some volumes, on this system we turned off PDSE sharing and used MIM to manage resources. Carmen - Original Message - From: "RICHARD W. PINION" <rpin...@firsttennessee.com> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, November 22, 2017 9:44:42 AM Subject: Re: IBM GRS Monitor report It's a long story. But yes we are doing this. The ACDS, COMMDS, and SCDS are not shared. The second system's ACDS and SCDS were derived from the first system's ACDS and SCDS. It was our thinking, perhaps we are wrong, that hardware reserves would protect the integrity of the volume. Using IBM's GRS Monitor, we can see that SYSZVVDS, SYSIGGV2, and SYSVTOC have a scope of reserve. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Carmen Vitullo Sent: Wednesday, November 22, 2017 10:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM GRS Monitor report [External Email] I must not have had enough coffee, you said you share an SMS managed volume between two systems but they are no in the same plex? is the SMS ACDS and SCDS shared? how do you manage to use RESERVES to manage this volume if not in a GRS environment? MIM? Carmen - Original Message - From: "RICHARD W. PINION" <rpin...@firsttennessee.com> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, November 22, 2017 9:30:10 AM Subject: IBM GRS Monitor report We ran IBM's GRS Monitor batch reports and noticed something in one of the reports. Notice the second entry, it has a x'004D'. The reason this is interesting to us is because we are sharing this particular volume between two systems. The second system is not in the GRS Star configuration of the first system. We are using RESERVES to protect the integrity of the resources. And this particular volume has encountered errors, i.e. VTOC entries but no SMS NVR records. And yes, this volume is in a SMS SG which is defined to the two systems. ** RESOURCES USAGE REPORT ** ** MAJOR SYSZVVDS ** - COUNT MAJOR 8260 SYSZVVDS SCOPE=RESERVE SMFID=DEVA RNL (ML) COUNT MAJOR MINOR 006 0032 SYSZVVDS TS0007 008 0004 SYSZVVDS TS0007 ( FIRST TENNESSEE Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM GRS Monitor report
It's a long story. But yes we are doing this. The ACDS, COMMDS, and SCDS are not shared. The second system's ACDS and SCDS were derived from the first system's ACDS and SCDS. It was our thinking, perhaps we are wrong, that hardware reserves would protect the integrity of the volume. Using IBM's GRS Monitor, we can see that SYSZVVDS, SYSIGGV2, and SYSVTOC have a scope of reserve. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Carmen Vitullo Sent: Wednesday, November 22, 2017 10:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM GRS Monitor report [External Email] I must not have had enough coffee, you said you share an SMS managed volume between two systems but they are no in the same plex? is the SMS ACDS and SCDS shared? how do you manage to use RESERVES to manage this volume if not in a GRS environment? MIM? Carmen - Original Message - From: "RICHARD W. PINION" <rpin...@firsttennessee.com> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, November 22, 2017 9:30:10 AM Subject: IBM GRS Monitor report We ran IBM's GRS Monitor batch reports and noticed something in one of the reports. Notice the second entry, it has a x'004D'. The reason this is interesting to us is because we are sharing this particular volume between two systems. The second system is not in the GRS Star configuration of the first system. We are using RESERVES to protect the integrity of the resources. And this particular volume has encountered errors, i.e. VTOC entries but no SMS NVR records. And yes, this volume is in a SMS SG which is defined to the two systems. ** RESOURCES USAGE REPORT ** ** MAJOR SYSZVVDS ** - COUNT MAJOR 8260 SYSZVVDS SCOPE=RESERVE SMFID=DEVA RNL (ML) COUNT MAJOR MINOR 006 0032 SYSZVVDS TS0007 008 0004 SYSZVVDS TS0007 ( FIRST TENNESSEE Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM GRS Monitor report
I must not have had enough coffee, you said you share an SMS managed volume between two systems but they are no in the same plex? is the SMS ACDS and SCDS shared? how do you manage to use RESERVES to manage this volume if not in a GRS environment? MIM? Carmen - Original Message - From: "RICHARD W. PINION"To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, November 22, 2017 9:30:10 AM Subject: IBM GRS Monitor report We ran IBM's GRS Monitor batch reports and noticed something in one of the reports. Notice the second entry, it has a x'004D'. The reason this is interesting to us is because we are sharing this particular volume between two systems. The second system is not in the GRS Star configuration of the first system. We are using RESERVES to protect the integrity of the resources. And this particular volume has encountered errors, i.e. VTOC entries but no SMS NVR records. And yes, this volume is in a SMS SG which is defined to the two systems. ** RESOURCES USAGE REPORT ** ** MAJOR SYSZVVDS ** - COUNT MAJOR 8260 SYSZVVDS SCOPE=RESERVE SMFID=DEVA RNL (ML) COUNT MAJOR MINOR 006 0032 SYSZVVDS TS0007 008 0004 SYSZVVDS TS0007 ( FIRST TENNESSEE Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN