We don't need a thumb drive on the mainframewe need a fist drive on the
mainframe.
Just something a lot bigger G.
Tom Duerbusch
THD Consulting
Huegel, Thomas thue...@kable.com 3/5/2009 11:02 AM
If it was dynamic to configure XSTORE one could experiment a bit.
Or if the Z11 comes
AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: XSTORE
We don't need a thumb drive on the mainframewe need a
fist drive on the mainframe.
Just something a lot bigger G.
Tom Duerbusch
THD Consulting
Huegel, Thomas thue...@kable.com 3/5/2009 11:02 AM
If it was dynamic to configure
On 3/6/09 11:32 AM, Schuh, Richard rsc...@visa.com wrote:
What size does it have to be to become a fist? There are USB flash
memory drives that are at least 64GB.
OK, it has to be said:
It's not the size. It's what you do with it.
(Is it time to go home yet?)
--d b
Of David Boyes
Sent: Friday, March 06, 2009 8:36 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: XSTORE
On 3/6/09 11:32 AM, Schuh, Richard rsc...@visa.com wrote:
What size does it have to be to become a fist? There are USB flash
memory drives that are at least 64GB.
OK, it has
Let's call them flash drives.
-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu]on
Behalf Of Schuh, Richard
Sent: Friday, March 06, 2009 10:39 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: XSTORE
You should have said that before. I was responding
that are at least 64GB.
Regards,
Richard Schuh
-Original Message-
From: The IBM z/VM Operating System
[mailto:ib...@listserv.uark.edu] On Behalf Of Tom Duerbusch
Sent: Friday, March 06, 2009 8:29 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: XSTORE
We don't need a thumb drive
You could always use duct tape to secure the usb fist
Mace
-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Tom Duerbusch
Sent: Friday, March 06, 2009 1:19 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: XSTORE
16 TB or better G.
I wonder
Schuh, Richard wrote:
What size does it have to be to become a fist? There are USB flash
memory drives that are at least 64GB.
Regards,
Richard Schuh
I have one that is 1000GB. Thats very close to a TB. :)
Mine is bigger than yours. :)
--
Stephen Frazier
Information Technology Unit
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: XSTORE
Schuh, Richard wrote:
What size does it have to be to become a fist? There are USB flash
memory drives that are at least 64GB.
Regards,
Richard Schuh
I have one that is 1000GB. Thats very close to a TB. :)
Mine is bigger than
One minor correction David...
Since OS/390 became z/OS it has not used XSTORE in any way. If you give
XSTORE to z/OS it spits out a message at IPL time that it has detected some
XSTORE but will not use it.
Mike
C. M. (Mike) Hammock
Sr. Technical Advisor
IBM System Z Solutions
Mainline
@LISTSERV.UARK.EDU
Subject: Re: XSTORE
Understanding that CP uses an algorithm that handles XSTORE as a
preferred paging area the question arises as to why?
Since XSTORE is just a piece of main memory the reason for it's
existence is no longer that it is some cheaper slower memory that can be
used
Hi Mike,
Many experts have talked about XSTORE and VM using it for paging. All
our defined XSTORE is being used for MDCACHE. It made a noticable
difference to I/O performance for our VSE production guest. We could
have done it all in regular storage but until a recent processor
change, we didn't
That may not be a good thing. The most frequent advice I have heard/seen in
that area is to do all MDC to main and only use XSTORE for paging.
Regards,
Richard Schuh
-Original Message-
From: The IBM z/VM Operating System
[mailto:ib...@listserv.uark.edu] On Behalf Of Ron
US)
Sent: Thursday, March 05, 2009 6:58 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: XSTORE
I agree. Then we would not have to reconfigure LPAR storage
definitions when testing OS/390 and z/VM
If it was dynamic to configure XSTORE one could experiment a bit.
Or if the Z11 comes with a USB port that one could plug a thumb drive into and
be back to what XSTORE used to be .. I digress we really don't need USB ports
on the mainframe.
-Original Message-
From: The IBM z/VM
On 3/5/09 12:02 PM, Huegel, Thomas thue...@kable.com wrote:
If it was dynamic to configure XSTORE one could experiment a bit.
Or if the Z11 comes with a USB port that one could plug a thumb drive into and
be back to what XSTORE used to be .. I digress we really don't need USB ports
We should remember that there is no one right answer to the allocation
(or not) of XSTORE and whether it's used solely, partially, or not at
all for MDCACHE. It's all an it depends (Wonder if Bill Bitner has
copyrighted that). We should just be thankful that it's one of the
tuning knobs
On Thu, Mar 5, 2009 at 5:54 PM, Schuh, Richard rsc...@visa.com wrote:
That may not be a good thing. The most frequent advice I have heard/seen in
that area is to do all MDC to main and only use XSTORE for paging.
It is correct that you should not define XSTORE to be used for MDC. It
does
/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Jim Bohnsack
Sent: Thursday, March 05, 2009 1:32 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: XSTORE
We should remember that there is no one right answer to the allocation
(or not) of XSTORE and whether it's used solely, partially
Hi Folks,
What value is there in defining XSTORE these days? Aside from the
ability to attach XSTORE to specific virtual machines, wouldn't it be
best to just make it all DPA and let CP manage it?
Also, assuming you aren't paging much - is attaching XSTORE to a userid
going to provide a VERY
Paging hierarchy. Think of XSTORE as a really highspeed buffer between main
storage and real disk. If you hit a spike in paging activity (like when all
your Linux guests wake up near the same time to do something cron-related), you
dramatically increase the probability that the pages you want
I don't think that z/OS uses XSTORE. Our MVS sysprogs expressed surprise
that we had some defined for VM.
Regards,
Richard Schuh
From: The IBM z/VM Operating System
[mailto:ib...@listserv.uark.edu] On Behalf Of David Boyes
Sent
z/OS does not use Xstore anymore.
Jerry Whitteridge
Mainframe Engineering
Safeway Inc
925 951 4184
jerry.whitteri...@safeway.com
If everything seems under control, you're just not going fast enough.
From: The IBM z/VM Operating System
Attaching XSTORE to a user: you can, but it is up to the user to do
something with it, CMS doesn't use it at all, z/OS no longer supports it,
and I don't know about Linux.
To define some XSTORE fo CP is still a good thing if VM starts paging:
XSTORE is managed differently than central storage
Understanding that CP uses an algorithm that handles XSTORE as a preferred
paging area the question arises as to why?
Since XSTORE is just a piece of main memory the reason for it's existence is no
longer that it is some cheaper slower memory that can be used for paging.
I think we all look
I like the idea of a dynamically configurable parm for xstore. It would make
it easier to test tuning options. Could be something like the SET MDC cache
command.
The only thing I've gleamed from the whole XSTORE for paging thing is that it
helps with block paging out. We demand page
On 3/4/2009 at 2:42 PM, Kris Buelens kris.buel...@gmail.com wrote:
Attaching XSTORE to a user: you can, but it is up to the user to do
something with it, CMS doesn't use it at all, z/OS no longer supports it,
and I don't know about Linux.
Yes, Linux can use it, with the xpram driver
Older versions did. As you say, current z/OS does not.
On 3/4/09 5:40 PM, Schuh, Richard rsc...@visa.com wrote:
I don't think that z/OS uses XSTORE. Our MVS sysprogs expressed surprise that
we had some defined for VM.
Schuh, Richard wrote:
I don't think that z/OS uses XSTORE. Our MVS sysprogs expressed surprise
that we had some defined for VM.
As others have noted, indeed it doesn't. I (and others) have repeatedly had to
explain to skeptical MVSers why it's A Good Thing for z/VM. Just because z/OS
doesn't
Brian, when you say 'relative performance metrics' are you asking about
the CPU cost associated with the various paths? If so, I don't think
I have any current data on that. Partly because, it does depend on a lot
of different things. My suggestion there is to find a virtual machine
that is fairly
Brian, you raise an interesting question about tuning MDC on a
per user basis vs. a system basis vs. a combination. A single
solve all algorithm would be cool, but beyond my imagination
to make it perfect. I believe there was a lot of research
originally about
While MDC is a write-through cache,
For dasd cache, all writes are hits unless there is a non-volatile
storage full (error) condition.
If you have dedicated dasd addresses for linux guests, the dasd
cache report (ESADSD5) shows percent of I/O that is read vs
write, and the percent of each that are hits.
The seek reports show by
On 7/13/06, Bill Bitner [EMAIL PROTECTED] wrote:
While MDC is a write-through cache, it does not automatically
insert writes into the cache if the disk location being
I have done some experiments with Linux that seem to work differently.
I flushed the cache and then had Linux sequentially
On the, Get close to the application thread, remember that any I/O
request satisfied from MDC is likely to be satisfied (on modern boxes) in
less than a microsecond. Even cached, anything that involves a
conversation with a channel is going to experience a service time that is
several orders
Hello And thanks to everyone,
I do appreciate everyone's input and opinions. We have the
memory.
8 gig total, 5 gig defined for storage, 2 gig to xstore, and the rest
used
by the HMC.
I do think that the problem is the MDC is only hitting 77-80%
and the
cpu gets driven
I think that the answer is probably a little of it depends (thank you
Bill Bitner). The it depends I think is related to your I/O rate and I/O
requirements. An example, and even tho it is very old, I think would still
apply, is that back in the late '80's I had some 3090's as well as some
. We have the
memory.
8 gig total, 5 gig defined for storage, 2 gig to xstore, and the rest
used=20
by the HMC. =20
I do think that the problem is the MDC is only hitting 77-80%
and the=20
cpu gets driven up to 100%. It was at 92% before I do the SET MDC
SYSTEM ON. I am weighting
On Wed, 12 Jul 2006 10:16:09 -0400, Edward M. Martin wrote:
Hello And thanks to everyone,
I do appreciate everyone's input and opinions. We have the
memory.
8 gig total, 5 gig defined for storage, 2 gig to xstore, and the rest
used
by the HMC.
I do think that the problem
]
ext. 40441
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
On
Behalf Of Jim Bohnsack
Sent: Wednesday, July 12, 2006 10:48 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: MDC, Storage, xstore, and cache on External dasd.
Your results when using MDC
Now that I had time to think about it a little more.
80% MDC cache hit ratio isn't that good. How much memory would it take
to get the hit ratio up to 95% (and can you afford the memory).
My concern now, is that your application mix may not be a good caching
candidate. i.e. if you have large
. the architecture limits xstore operations to page boundaries
So if guest I/O buffers are page aligned, movement can be directly
from xstore to the guest pages. Otherwise, the data is moved into
cstore and then into the guest pages. A lot of CMS applications
and workloads have buffers page aligned; less so
Title: MDC, Storage, xstore, and cache on External dasd.
Hello Everyone,
I have found some time here to re-evaluate some parameters.
We have a large amount of Cache (6 gig) on the EMC box. The EMC is doing lots of
caching.
I am wondering about the overhead of the dual caching
Your concern is justified.
The question isreal memory vs CPU.
You shouldn't have much of an I/O bottleneck with your caching
controller, assumming you have ficon or better channel speeds.
But if your read I/O is satisfied from MDC, you won't go thru the I/O
boundry which is a saving in
43 matches
Mail list logo
