I don't think the analogy to a ping attack is a particularly fair
one. Yes, from the perspective of an innocent third user, they
look the same, perhaps, but they aren't.
??? In both cases, normal function of the innocent guest is disrupted by a
force beyond it's control through no fault of
Now THAT would have exposed the problem. :-) Actually, he already tried that
and the result has been this discussion.
Regards,
Richard Schuh
I'm sure that there are a couple other ways of preventing the
problem, like IPL'ing the machine first and doing a Q V ALL
to see what resources
: Monday, September 21, 2009 11:32 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Storage Management Enhancement Ideas (was: VM lockup due to
storage typo)
These are very interesting ideas, but I suspect (no way to prove, since no
doc will be forthcoming) that the hang was not a paging issue, but rather
I don't think the analogy to a ping attack is a particularly fair
one. Yes, from the perspective of an innocent third user, they
look the same, perhaps, but they aren't. If the attack were made
through some sort of security gate that defaults to closed state
which the sysadmin had
On Sat, Sep 19, 2009 at 6:21 PM, John P. Baker jbaker...@comporium.net wrote:
I recommend that the idea of splitting page space into multiple pools be
considered, where individual users can be assigned to different pools. For
the purposes of discussion, let us consider that following
: Storage Management Enhancement Ideas (was: VM lockup due to
storage typo)
On Sat, Sep 19, 2009 at 6:21 PM, John P. Baker jbaker...@comporium.net
wrote:
I don't like the idea to use only a subset of your paging capacity for
part of the workload. It's not just about space but also about
throughput
On 9/20/09 4:26 AM, Rob van der Heij rvdh...@velocitysoftware.com wrote:
Most performance tuning gets harder when you split resources and
consumers in different groups and manage them separately. Sharing is
easier with large numbers.
Rob
Although with SSD coming back into vogue, the idea of
All,
Since we have now beat the issue of storage management to death, I would
like to set forth some concrete ideas for consideration.
First, it has been pointed out that it may not currently be possible to
LOGON to MAINT or OPERATOR or to some other service machine in order to
diagnose
Nicely written
John P. Baker wrote:
All,
Since we have now beat the issue of storage management to death, I
would like to set forth some concrete ideas for consideration.
First, it has been pointed out that it may not currently be possible
to LOGON to MAINT or OPERATOR or to some other
into spool space.
John P. Baker
-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Rich Smrcina
Sent: Saturday, September 19, 2009 1:19 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Storage Management Enhancement Ideas (was: VM lockup due
That is indeed one important question, but there was another one, the
question of whether this was a denial of service attack exposure, which i
t
is not. I'm not disagreeing that it would be nice if there were some sor
t
of are you sure safety net before the system proceeded to try to do
due to storage typo
On 9/17/09 2:16 PM, Adam Thornton athorn...@sinenomine.net wrote:
Administrator typo is not a failure mode the operating system is
designed to protect you from.
That may be true now, but I think the point of the argument is that it
should not be.
On VMS, if you have
I see this as three separate questions (with my answers):
Is it a denial of service attack exposure?
- Clearly not.
Is it a defect?
- I don't believe so, for the base issue of whether VM
should allow a privileged user do do something destructive,
though there may well be defects or
On 9/18/09 9:32 AM, Bill Holder hold...@us.ibm.com wrote:
That is indeed one important question, but there was another one, the
question of whether this was a denial of service attack exposure, which i
t
is not.
I think that's a point of view question.
If I am another user on the same VM
On 9/18/09 9:38 AM, Huegel, Thomas thue...@kable.com wrote:
A little OT, but curiosity calls.. What is the max. storage that z/LINUX
can use?
Last time I looked at the Linux memory management code (a while back) it was
4TB, but that's probably expanded by now. The documented z/VM limit of 8TB
On Sep 18, 2009, at 9:11 AM, David Boyes wrote:
I think we're all in violent agreement on that point. Now, the
question is
what is the best way to put a safety on that gun?
Oooh! Oooh! Pick me! Mandatory User Access Control dialog boxes
that pop up and make you click OK any time you
On Fri, Sep 18, 2009 at 4:11 PM, David Boyes dbo...@sinenomine.net wrote:
I think we're all in violent agreement on that point. Now, the question is
what is the best way to put a safety on that gun?
IMHO the suggested solutions so far merely bend the barrel upwards.
This may deflect the bullet
On Fri, 18 Sep 2009 10:11:58 -0400, David Boyes dbo...@sinenomine.net
wrote:
I think we're all in violent agreement on that point. Now, the question
is
what is the best way to put a safety on that gun?
Poetic Justice
Since the Linux OOM model is to kill a process, just kill some Linux
On Fri, 18 Sep 2009 10:11:58 -0400, David Boyes dbo...@sinenomine.net w
rote:
...
I think we're all in violent agreement on that point. Now, the question
is
what is the best way to put a safety on that gun?
=
===
Is this a
the IBM vernacular years
ago.)
Regards,
Richard Schuh
-Original Message-
From: The IBM z/VM Operating System
[mailto:ib...@listserv.uark.edu] On Behalf Of David Boyes
Sent: Friday, September 18, 2009 7:12 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: VM lockup due to storage typo
Personally, I have always preferred BAC (Broken As Coded).
John P. Baker
-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Schuh, Richard
Sent: Friday, September 18, 2009 11:58 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: VM lockup due
the system so I
can straighten things out.
Bob.
-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Schuh, Richard
Sent: Friday, September 18, 2009 12:11 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: VM lockup due to storage typo
While you
On 9/18/09 11:58 AM, Schuh, Richard rsc...@visa.com wrote:
Hey Zeke Boyes, who is Bill Schuh? I don't even know of a relative by that
name :-)
It's your lawful good alter ego, arch nemesis of Chuckie. The Saturday
morning cartoon starring the Billster debuts next TV season, along with
Danger
On Fri, 18 Sep 2009 13:49:27 -0400, David Boyes dbo...@sinenomine.net
wrote:
On 9/18/09 11:38 AM, Bill Holder hold...@us.ibm.com wrote:
On Fri, 18 Sep 2009 10:11:58 -0400, David Boyes dbo...@sinenomine.net
w
rote:
I think we're all in violent agreement on that point. Now, the questi
on
The problem I would have, is my MAINT user is defined with 1 GB. That is so I
can process large reader files.
The very vast majority of the time, I'm only using a few MB.
Would you fix, prevent MAINT from logging on, when we are at, or near the
discussed problem?
Operations also has some
: Re: VM lockup due to storage typo
On 9/18/09 11:38 AM, Bill Holder hold...@us.ibm.com wrote:
On Fri, 18 Sep 2009 10:11:58 -0400, David Boyes
dbo...@sinenomine.net w
rote:
I think we're all in violent agreement on that point. Now, the
question
is
what is the best way to put
for
your cooperation.
-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf
Of Schuh, Richard
Sent: Friday, September 18, 2009 1:28 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: [IBMVM] VM lockup due to storage typo
Does the current physical storage
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: VM lockup due to storage typo
VM64461 puts the brakes on console spooling by detecting that
something crazy is going on and may exhaust all of vm's
memory and pauses the virtual machine to allow the writes to
disk to take place and the memory to get back
On 9/18/09 4:27 PM, Schuh, Richard rsc...@visa.com wrote:
Does the current physical storage refer to main or main + xstore? Also, is
there any consideration of the total virtual storage or working sets of the
in-Queue, in-memory, or logged-on users in the calculation? I wouldn't want a
dozen
On 9/18/09 3:41 PM, Brian Nielsen bniel...@sco.idaho.gov wrote:
A scenario that hasn't been mentioned deals with draining a PAGE volume.
The calculation of defined paging space might be considered fuzzy if a
PAGE volume is being DRAINed. Of course, you could be strict and conside
r
On 9/18/09 3:50 PM, Tom Duerbusch duerbus...@stlouiscity.com wrote:
The problem I would have, is my MAINT user is defined with 1 GB. That is so I
can process large reader files.
The very vast majority of the time, I'm only using a few MB.
Would you fix, prevent MAINT from logging on, when we
While I agree it's not a DoS attack exposure, the system issued no
messages and allowed no input on any console (via tn3270, OSA ICC
console, HMC 3270 or HMC Operating system messages). If we had a way to
enter a command or two (probably an IND first), we could have forced off
the offender
Adam Thornton wrote:
On Sep 18, 2009, at 9:11 AM, David Boyes wrote:
I think we're all in violent agreement on that point. Now, the
question is
what is the best way to put a safety on that gun?
Oooh! Oooh! Pick me! Mandatory User Access Control dialog boxes
that pop up and make you
On Friday, 09/18/2009 at 10:13 EDT, David Boyes dbo...@sinenomine.net
wrote:
On 9/18/09 9:32 AM, Bill Holder hold...@us.ibm.com wrote:
That is indeed one important question, but there was another one, the
question of whether this was a denial of service attack exposure,
which
it is not.
Subject: Re: VM lockup due to storage typo
CP wouldn't know at IPL time, the guest would, not could, but
would cause such harm.
Just because you say you can use xxx GB, doesn't mean you
would actually use them.
When page fills, it over flows to spool.
When spool fills, CP abends
On Thu, Sep 17, 2009 at 9:14 AM, Bill Holder hold...@us.ibm.com wrote:
I don't entirely agree. The action of the guest did not cause harm
to CP, it was the action of the operations staff which did. This
is not a denial of service case that I can see.
Hm. So by that rationale, we can make
I should point out that this hang is likely being misunderstood here.
While this scenario will indeed drive paging over the edge, that's not
likely what happened. If paging had been driven to that point, the
system would have quickly taken a PGT004 abend and restarted. Instead,
I believe
@LISTSERV.UARK.EDU
Subject: Re: VM lockup due to storage typo
I should point out that this hang is likely being misunderstood here. =
While this scenario will indeed drive paging over the edge, that's not =
likely what happened. If paging had been driven to that point, the
system would have
On Thu, Sep 17, 2009 at 6:34 PM, Bill Holder hold...@us.ibm.com wrote:
Occurrences of this sort of problem are likely to result in temporary
or permanent hangs of both individual users and eventually the entire
system, which supports the theory in this case. I'd really need to
see a dump of
No, not at all, that's not what I was saying; what you propose would
obviously be an exposure. A privileged user (operations staff) can issue
that today. Putting a loaded gun in the hands of a class G user is not a
t
all the same thing. Anything a user at a keyboard can do, a guest progra
m
: The IBM z/VM Operating System
[mailto:ib...@listserv.uark.edu] On Behalf Of Bill Holder
Sent: Thursday, September 17, 2009 9:14 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: VM lockup due to storage typo
I don't entirely agree. The action of the guest did not
cause harm to CP, it was the action
@LISTSERV.UARK.EDU
Subject: Re: VM lockup due to storage typo
I don't entirely agree. The action of the guest did not
cause harm to CP, it was the action of the operations staff
which did. This is not a denial of service case that I can see.
Bill Holder
z/VM Development, Memory Management team
-Original Message-
From: The IBM z/VM Operating System
[mailto:ib...@listserv.uark.edu] On Behalf Of Bill Holder
Sent: Thursday, September 17, 2009 10:35 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: VM lockup due to storage typo
Sure, true enough, but the exposure was not caused
I'd agree with that point in cases where it's less clear, but in
this case, it's perfectly clear that the user action would have
been harmless if not for the administrator typo. I don't disagree
that more protection at the user action level would be nice in
this case, that's really different
On Thu, Sep 17, 2009 at 10:58 AM, Bill Holder hold...@us.ibm.com wrote:
I'd agree with that point in cases where it's less clear, but in
this case, it's perfectly clear that the user action would have
been harmless if not for the administrator typo. I don't disagree
that more protection at
FYI, the system in question had about 175GB of page space - 22 mod 9s.
Currently the system does NO paging. All the guests fit within real
storage. (Of course there will eventually be more guests on that LPAR,
so sooner or later we'll start to page.)
Lee
Rob van der Heij wrote:
On Thu,
On Sep 17, 2009, at 1:58 PM, Bill Holder wrote:
I'd agree with that point in cases where it's less clear, but in
this case, it's perfectly clear that the user action would have
been harmless if not for the administrator typo
Yabbut
Administrator typo is not a failure mode the operating
On 9/17/09 2:16 PM, Adam Thornton athorn...@sinenomine.net wrote:
Administrator typo is not a failure mode the operating system is
designed to protect you from.
That may be true now, but I think the point of the argument is that it
should not be.
On VMS, if you have a SYSTEM priv bit set,
On Sep 17, 2009, at 5:36 PM, David Boyes wrote:
Whether it should march off a cliff without at least questioning the
order
is the question at hand.
Of course it should.
Yes, my Unix is showing.
Adam
Well, there is precedence here of VM dev fixing things that are too large/too
much that take down VM
See VM64461 and VM6
I'll probably look into the possibility of a vmsecure exit to add a safety to
my gun for now.
Marcy
This message may contain confidential and/or privileged
On Tuesday, 09/15/2009 at 04:50 EDT, Marcy Cortes
marcy.d.cor...@wellsfargo.com wrote:
So are you saying that what Lee and I both did to shoot our systems
should
APAR'able? Or should it be a requirement? Or is it going to be a your
gun,
your foot answer?
I was just answering the Is it
2009/9/15 Schuh, Richard rsc...@visa.com
The same might be said for page space. Someone could access a dataspace
enabled directory and take up page space. We could easily take up 48G of
page space here by starting 24 machines that each access different d/s
directories at 2G each.
Dataspace
I don't think, in this case, it is the user causing the problem at all. The
user didn't define their storage allocation, and in practice can't do that
at all. So the user didn't set up the situation which caused the integrity
issue, the system administrator did.
The system administrator is in
expressed herein are mine alone, not my employer's.
RPN01 nix.rob...@mayo.edu
Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU
09/16/2009 08:13 AM
Please respond to
The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: VM lockup due to storage
Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU
09/16/2009 08:13 AM
Please respond to
The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: VM lockup due to storage typo
I don't think, in this case, it is the user causing the problem
This gun has been pointing in the same direction forever, but it *is*
a fact that with 64-bit CP the bullets are a lot bigger.
I am sure folks in Edicott are as creative as most of us (or worse,
take a look at ... ;-) but we know that any safety that CP adds will
annoy people because they forgot
...@mayo.edu
Date: Wed, 16 Sep 2009 08:13:57
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: VM lockup due to storage typo
I don't think, in this case, it is the user causing the problem at all. The
user didn't define their storage allocation, and in practice can't do that
at all. So the user didn't set
On Wednesday, 09/16/2009 at 09:14 EDT, RPN01 nix.rob...@mayo.edu wrote:
I don't think, in this case, it is the user causing the problem at all.
The
user didn't define their storage allocation, and in practice can't do
that
at all. So the user didn't set up the situation which caused the
-Original Message-
From: The IBM z/VM Operating System
[mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark
Sent: Wednesday, September 16, 2009 10:20 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: VM lockup due to storage typo
On Wednesday, 09/16/2009 at 09:14 EDT, RPN01
On Wed, Sep 16, 2009 at 10:42 AM, Schuh, Richard rsc...@visa.com wrote:
Logon would not be the right or only place to put it. DEF STOR is another
possible place to err if the maximum storage was too high. Perhaps a check of
virtual storage at IPL time. That is a common point that must be
and/or a special 'hook' into the HMC.. I'll leave that up to the
developers.
-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of P S
Sent: Wednesday, September 16, 2009 12:53 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: VM lockup due to storage typo
On 9/15/09 12:09 PM, Daniel P. Martin dmar...@gizmoworks.com wrote:
*cough*SHARE requirement?*cough*
WAVV requirement WRIBDB04 submitted.
I suggested a SYSTEM CONFIG option and corresponding SET command to warn
user/operator and optionally halt IPL if a user requested LOGON or issued an
IPL
I guess as the one who got bit, I'd offer one easy suggestion...
The finger check asked for 9728G (9.7+T), VM unceremoniously chopped it
to 8T as the architecture limit. Why not have an option (not enabled by
default) in the SYSTEM CONFIG file that says Max_Virt_Size. It could
take numbers
to the
developers.
-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of P S
Sent: Wednesday, September 16, 2009 12:53 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: VM lockup due to storage typo
On Wed, Sep 16, 2009 at 10:42 AM, Schuh, Richard rsc
On Wednesday, 09/16/2009 at 04:44 EDT, Lee Stewart
lstewart.dsgr...@attglobal.net wrote:
I guess as the one who got bit, I'd offer one easy suggestion...
The finger check asked for 9728G (9.7+T), VM unceremoniously chopped it
to 8T as the architecture limit. Why not have an option (not
I've been trying to follow the discussion and wondering if the
directory control statement
MAXSTORAGE
would have provided some protection from the finger check problem?
On Wed, Sep 16, 2009 at 2:59 PM, Alan Altmark alan_altm...@us.ibm.com wrote:
On Wednesday, 09/16/2009 at 04:44 EDT, Lee
Sent: Wednesday, September 16, 2009 2:20 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: VM lockup due to storage typo
I've been trying to follow the discussion and wondering if
the directory control statement
MAXSTORAGE
would have provided some protection from the finger check problem
Not really as we were dealing with a lot of guests. So the only
practical place to put it would be in a profile. But according to usage
note #1: A maximum storage setting on a USER statement overrides a
MAXSTORAGE statement in a profile.
So it would have no effect...
Lee
Ron Schmiedge
Unless you set MAXSTORAGE in the profile and used * as the upper limit
in the USER entry. Then if you change the lower limit to be higher
than the setting in the profile, you get an error.
On Wed, Sep 16, 2009 at 3:48 PM, Lee Stewart
lstewart.dsgr...@attglobal.net wrote:
Not really as we were
Does anyone have an idea of how we might have gotten out of this without
an IPL?
VM LPAR has 175G of memory and a flock of Linux Oracle guests...
Several guests needed more memory added so the directory was updated and
one by one the guests shutdown, logged off and back on. So far, so good.
this message. Thank you for
your cooperation.
-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf
Of Lee Stewart
Sent: Tuesday, September 15, 2009 8:39 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: [IBMVM] VM lockup due to storage typo
Does anyone
for me in kickboxing.
-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf
Of Lee Stewart
Sent: Tuesday, September 15, 2009 08:39
To: IBMVM@LISTSERV.UARK.EDU
Subject: [IBMVM] VM lockup due to storage typo
Does anyone have an idea of how we might
:39
To: IBMVM@LISTSERV.UARK.EDU
Subject: [IBMVM] VM lockup due to storage typo
Does anyone have an idea of how we might have gotten out of this without
an IPL?
VM LPAR has 175G of memory and a flock of Linux Oracle guests...
Several guests needed more memory added so the directory was updated
Subject: [IBMVM] VM lockup due to storage typo
Does anyone have an idea of how we might have gotten out of this without
an IPL?
VM LPAR has 175G of memory and a flock of Linux Oracle guests...
Several guests needed more memory added so the directory was updated and
one by one the guests shutdown
Of Marcy Cortes
Sent: Tuesday, September 15, 2009 9:03 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: VM lockup due to storage typo
See a thread on this list with subject Sanity check? from
Oct 2007 for what happened when I did the same thing ;)
You probably filled page space.
I still think
: [IBMVM] VM lockup due to storage typo
Does anyone have an idea of how we might have gotten out of this without
an IPL?
VM LPAR has 175G of memory and a flock of Linux Oracle guests...
Several guests needed more memory added so the directory was updated and
one by one the guests shutdown
. Martin
Sent: Tuesday, September 15, 2009 9:09 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: VM lockup due to storage typo
*cough*SHARE requirement?*cough*
Marcy Cortes wrote:
See a thread on this list with subject Sanity check? from
Oct 2007
for what happened when I did the same
, September 15, 2009 8:39 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: [IBMVM] VM lockup due to storage typo
Does anyone have an idea of how we might have gotten out of
this without an IPL?
VM LPAR has 175G of memory and a flock of Linux Oracle guests...
Several guests needed more memory added so
The difference between CMS and Linux in this case is just a matter of tim
e
before problems occur. Linux wants to use all of its storage early, CMS u
ses
all of its storage over time. Both will use all of their storage eventual
ly.
CP is built to overcommit storage. It just lets you REALLY
CMS will free its storage after the command is complete.
However, do a peek on a very large reader element, such as a OS dump, and CMS
just might use up all of its storage, just like any other guest might.
It isn't a matter of time, it is a matter of usage.
Tom Duerbusch
THD Consulting
CMS, being a 32-bit system, will probably never use 3TB of memory. Perhaps
z/CMS, when it becomes a reality, might but the current CMS is another story.
Regards,
Richard Schuh
CMS u= ses all of its storage over
time. Both will use all of their storage eventual= ly.
Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Schuh, Richard
Sent: Tuesday, September 15, 2009 12:59 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: VM lockup due to storage typo
Maybe CP couldn't know that the guest would do something bad, but it
should know that it has opened itself
I agree with that (the guest cannot be allowed to harm CP) but has that
actually been formally - or even informally - accepted by the Powers That
Be?
I ask because I still remember, as though it were yesterday, opening a
security/integrity APAR against VM back in the mid-1980's because any
, September 15, 2009 12:59 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: VM lockup due to storage typo
Maybe CP couldn't know that the guest would do something bad, but it
should know that it has opened itself to the possibility that the guest
could, in normal operation, cause the problem.
One
On Tuesday, 09/15/2009 at 03:27 EDT, Steve Marak sama...@gizmoworks.com
wrote:
I agree with that (the guest cannot be allowed to harm CP) but has
that
actually been formally - or even informally - accepted by the Powers
That
Be?
Yes, it is in the Statement of System Integrity in the General
.
-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf
Of Alan Altmark
Sent: Tuesday, September 15, 2009 1:45 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: [IBMVM] VM lockup due to storage typo
On Tuesday, 09/15/2009 at 03:27 EDT, Steve Marak sama
or a severe warning is issued.
Steve
-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Schuh, Richard
Sent: Tuesday, September 15, 2009 12:59 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: VM lockup due to storage typo
Maybe CP couldn't know
@LISTSERV.UARK.EDU
Subject: [IBMVM] VM lockup due to storage typo
Does anyone have an idea of how we might have gotten out of this without
an IPL?
VM LPAR has 175G of memory and a flock of Linux Oracle guests...
Several guests needed more memory added so the directory was updated and
one by one
: Tuesday, September 15, 2009 1:50 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: VM lockup due to storage typo
So are you saying that what Lee and I both did to shoot our
systems should APAR'able? Or should it be a requirement? Or
is it going to be a your gun, your foot answer?
Marcy
@LISTSERV.UARK.EDU
Subject: Re: VM lockup due to storage typo
Seems to me that he said it was either an integrity problem or a defect.
I would think that either would me meat for the APAR grinder.
Regards,
Richard Schuh
-Original Message-
From: The IBM z/VM Operating System
[mailto:ib
@LISTSERV.UARK.EDU
Subject: Re: VM lockup due to storage typo
Gee, I guess we're in good company! ;-)
You betcha! (I'm in MN today, I can say that).
At least mine was a test/dev system :) If had done it to a
prod system, I'm sure someone here would have had IBM
answering questions ... It's one
On Tue, Sep 15, 2009 at 11:18 PM, Robert J Brenneman bren...@gmail.com wrote:
Admittedly - not 8TB in a 200G box, as Lee tried to do, and it was on
z/VM 5.1, so it didn't have the system execution space stuff of later
z/VM releases. It did teach the lesson that more page packs can only
get
One of the problems with booting Linux is that it determines
the size of the virtual machine by testing pages rather than
ask CP about it.
It only took TPF and its predecessors 35 years to get this right. :-)
Way back in VM/370 R3 I had a diag that could be used. We did talk
the ACP
93 matches
Mail list logo
