Re: IBM GRS Monitor report

2017-11-22 Thread Gibney, Dave
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

2017-11-22 Thread Allan Staller
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

2017-11-22 Thread PINION, RICHARD W.
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

2017-11-22 Thread Allan Staller
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

2017-11-22 Thread Carmen Vitullo
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

2017-11-22 Thread PINION, RICHARD W.
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

2017-11-22 Thread Carmen Vitullo
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