Just to follow up on this thread:
> >The response was:
> >"The developer has decided not to change the message type for this
messag
> >e."
>
>
> That's a totally BS answer. Call them back and challenge it.
>
> There should at least be a justification for why the developer refused
to
> change
On 12/27/10 11:18 AM, "Mike Walter" wrote:
>
>The response was:
>"The developer has decided not to change the message type for this messag
>e."
That's a totally BS answer. Call them back and challenge it.
There should at least be a justification for why the developer refused to
change it, espe
lect option which
> would go a long way to making the z/VM IPL much less error prone.
>
>
>
> *"Schuh, Richard" *
> Sent by: The IBM z/VM Operating System
>
> 12/27/2010 12:03 PM
> Please respond to
> The IBM z/VM Operating System
>
> To
> IBMV
LISTSERV.UARK.EDU
cc
Subject
Re: Duplicate VOLSERs at IPL
Which begs the question, what are the criteria for determining the level
of a message?
I would think that something that could cause potentially serious system
problems, like getting an incorrect CP OWNED volume, would warrant an E.
O
system.
Regards,
Richard Schuh
> -Original Message-
> From: The IBM z/VM Operating System
> [mailto:ib...@listserv.uark.edu] On Behalf Of Mike Walter
> Sent: Monday, December 27, 2010 8:18 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Duplicate VOLSERs at IPL
>
Just closing the loop on this thread... I did open a Sev 3 (should have
been Sev 4) PMR for this issue on November 20, 2010, pasting pretty much
the same text as posted earler to justify the W-level ("Warning") message
type on this mesesage. The PMR response was received today, December 27,
Instead of UUID I like the idea of a user supplied (maintained) passcode
that would be used by all OS's whenever AVR routines were used. Maybe 20
characters long.. copy programs could ask if you wanted to change it. Put
something in there like 'RSU 1002' or 'Joe's test vol'.
On Wed, Oct 20, 2010
ot;
10/20/2010 01:27 PM
Please respond to
"The IBM z/VM Operating System"
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: Duplicate VOLSERs at IPL
On Fri, 27 Aug 2010 14:38:24 -0400, Alan Altmark wrote:
> Rich Corak has explained on previous occasions how volser recognition
> work
On Fri, 27 Aug 2010 14:38:24 -0400, Alan Altmark wrote:
> Rich Corak has explained on previous occasions how volser recognition
> works. If CP detects a duplicate volser for a device to be attached to
> SYSTEM at IPL, you will get
>
> HCP954I DASD rdev1 VOLID volid IS A DUPLICATE OF DASD rdev
ot my employer's.
"Frank M. Ramaekers"
Sent by: "The IBM z/VM Operating System"
10/20/2010 12:44 PM
Please respond to
"The IBM z/VM Operating System"
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: Duplicate VOLSERs at IPL
IBM has stated that this is not
On Wednesday, October 20, 2010 11:44 AM, August Carideo wrote:
>
> and I thought all you need to do was make sure the duplicates where at a
> higher address on the string
> and it would hit the lower ones 1st and advise there was a dupe
> after reading these posts I wonder
I have not looked at th
On Wednesday, 10/20/2010 at 12:52 EDT, "Schuh, Richard"
wrote:
> Not adequate. What happens if one of the devices at the lower address
fails to
> respond to the IPL roll call? That is a case of having only 1 device,
the wrong
> one, with the volser.
Mantra: Only volumes that you WANT online
IBMVM@LISTSERV.UARK.EDU
z/VM Operating
cc
System
Re: Duplicate VOLSERs at IPL
10/20/2010 12:38
PM
Please respond to
The IBM z/VM
Operating System
t;The IBM z/VM Operating System"
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: Duplicate VOLSERs at IPL
Good point
Yes from other posts I can see that
will most likely at least rename so called fallback
and look into that exec
thanks
Augie
"Schuh,
cc
Subject
Re: Duplicate VOLSERs at IPL
10/20/2010 12:52
mailto:ib...@listserv.uark.edu] On Behalf Of August Carideo
> Sent: Wednesday, October 20, 2010 9:44 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Duplicate VOLSERs at IPL
>
>
>
> and I thought all you need to do was make sure the duplicates
> where at a higher address o
Re: Duplicate VOLSERs at IPL
10/20/2010 12:38
PM
Re: Duplicate VOLSERs at IPL
10/20/2010 12
eorge Henke/NYLIC
Sent: Wednesday, October 20, 2010 10:24 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Duplicate VOLSERs at IPL
I plan to DDRed my system disks 540RES, 540SPL, 540W01, 540W02, before I apply
maintenance to Level 1 and PUT2PROD, so that I have a *hot* fallback when I
IPL. the maintenance.
Where can one pick up that wonderful exec?
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Frank M. Ramaekers
Sent: Wednesday, October 20, 2010 10:35 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Duplicate VOLSERs at IPL
Here's what I do (I think you rem
n
Sent by: The IBM z/VM Operating System
10/20/2010 11:41 AM
Please respond to
The IBM z/VM Operating System
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: Duplicate VOLSERs at IPL
Relabel your “standby disks”, maybe put an X in the first character. WRITE
DOWN the addresses of your system packs
: IBMVM@LISTSERV.UARK.EDU
Subject: Duplicate VOLSERs at IPL
I plan to DDRed my system disks 540RES, 540SPL, 540W01, 540W02, before I
apply maintenance to Level 1 and PUT2PROD, so that I have a *hot* fallback
when I IPL. the maintenance.
How can I be sure the IPL will not pick up these standby di
to
The IBM z/VM Operating System
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: Duplicate VOLSERs at IPL
Here’s what I do (I think you remember my FLASH2ND EXEC):
1) Use FLASH2ND to create a 2nd level/backup system
a. This will use a new prefixed VOLID of ‘54B’ (rep
That's slllick.
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Frank M. Ramaekers
Sent: Wednesday, October 20, 2010 10:35 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Duplicate VOLSERs at IPL
Here's what I d
Frank M. Ramaekers Jr.
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of George Henke/NYLIC
Sent: Wednesday, October 20, 2010 10:24 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Duplicate VOLSERs at IPL
I plan to DDRed my syst
I plan to DDRed my system disks 540RES, 540SPL, 540W01, 540W02, before I
apply maintenance to Level 1 and PUT2PROD, so that I have a *hot* fallback
when I IPL. the maintenance.
How can I be sure the IPL will not pick up these standby disks but WILL
pick them up if I need them for fallback? Is
26 matches
Mail list logo
