MACHINE XC means that the user can make use of VM dataspaces. DB2 can create them and SFS severs too. CMS end-users can have an advantage with machine XC too when they use SFS.
To make SFS use dataspaces, you need to change seldom changed SFS directories into DIRControl directories (DIRATTR can do that), and you also need to issue a command to tell the SFS server that a given DIRC directory must be placed in a dataspace (DATASPACE ASSIGN could be that command). Then an only then will SFS use dataspaces. Q SPACES USER VMSERx can tell you if your have such directories that are actively being used.
Once you have such directories, CMS end-users with MACHINE XC can directly access the CMS files hosted in the dataspace, otherwise datatransfer takes place using APPC.
The performance pages of the VM website still contain a document of me and my collegue Guy De Ceulaer that should give some more details:
http://www.vm.ibm.com/perf/tips/dim.html
This XC stuff has nothing to do wth XSTORE. For VM itself, XSTORE is only a fast paging space or as buffer for MDC. XC provides a way to share data (SFS) or to have larger buffers (DB2)
And by the way, VSE does not support XSTORE either.
Kris,
IBM Belgium, VM customer support
| Steve Gentry <[EMAIL PROTECTED]>
Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> 2006-10-24 21:55
|
|
Respectfully, Richard, I ran across some doc somewhere that recommended that the MACHINE TYPE for VMSERx (U and S) machines be set to XC so that
they can use XSTORE. Whether VMSERx actually uses x storeage or VM itself handles these moves to and from x storage is another matter.
If necessary, I will look up the doc. regarding the XC recommendation. VMSERVS and VMSERVU come shipped this way (MACHINE XC) from
IBM. VMSERVR is MACHINE XA , which, of course, makes sense.
Regards,
Steve
| "Schuh, Richard"
<[EMAIL PROTECTED]>
Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> 10/24/2006 01:20 PM Please respond to The IBM z/VM Operating System |
To: IBMVM@LISTSERV.UARK.EDU cc: Subject: Re: Extended storage question. |
VMSERVx machines are CMS. They are in the list of those who cannot use it. They can benefit from having space allocated for MDC; however, it is probably better to have MDC allocated from main storage rather than XSTORE.
There are few operating systems that benefit from XSTORE, any flavor of VM being principal among them. I do not know whether VSE can use XSTORE, but you can add CMS, TPF and GCS to the list of non-users.
Regards,
Richard Schuh
-----Original Message-----
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]On Behalf Of Steve Gentry
Sent: Tuesday, October 24, 2006 12:05 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Extended storage question.
You are correct, DASD paging is near 0.
"The only reason to attach XSTORE to a user is if that user can actually do something with it."
So, are you saying that DB2, VMSERVS, VMSERVU, etc, need to have some XSTORE attached to
them so that they will use it? On our system, these users have a USER DIRECTORY with a MACHINE TYPE XC
Steve
| Marty Zimelis <[EMAIL PROTECTED]>
Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> 10/24/2006 10:03 AM Please respond to The IBM z/VM Operating System |
To: IBMVM@LISTSERV.UARK.EDU cc: Subject: Re: Extended storage question. |
Steve,
It sounds like you're a little confused about what Q XSTORE [MAP] reports. In your current situation, you correctly point out that no XSTORE is attached to any user. What this means is that it's all available to CP for its two uses: primary page space and minidisk cache (MDC). Judging from the third line of the result of Q XSTORE, you have MDC shut off for your system. Thus, all of XSTORE is available as page space. The demands of your system are such that only 21% of the available 4608M are needed. (I suspect that your DASD paging rate is at or near 0.)
The only reason to attach XSTORE to a user is if that user can actually do something with it. A CMS-based application cannot. Nor can z/OS these days. My ignorance of VSE is complete enough that I don't know if it can use XSTORE either.
The only additional information that Q XSTORE MAP gives you is to show *which* pieces of XSTORE are attached to users, thus telling you what the largest remaining contiguous chunk is. It does not (as you seemed to assume) tell you whose pages are in the CP area used for page space. That information is available in the Monitor data.
Marty
____________________
Martin Zimelis
Principal
maz/Consultancy
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Steve Gentry
Sent: Tuesday, October 24, 2006 11:02 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Extended storage question.
I trying to figure out what information I'm getting when I issue the Q XSTORE MAP command.
My current XSTORAGE is setup as follows:
q xstore
XSTORE= 4608M
XSTORE= 4608M userid= SYSTEM usage= 21% retained= 0M pending= 0M
XSTORE MDC min=0M, max=0M, usage=0%
XSTORE= 4608M userid= (none) max. attach= 4608M
I don't have any assigned to a specific user so I assume that the system (cp?) is in control
of it and is thus allocating it as it sees fit.
As shown above, 21% is in use. But, who is using it?
I issue the Q XSTORE MAP command and get the following:
q xstore map
START SIZE STATUS %-IN-USE %-UNUSABLE
0M 4608M CP 21% 0%
I was hoping that it would tell me that userX was using so much, userY was using so much, etc.
Or does a user show up in the q xstore map when the storage has been attached to a
specific user? Say for instance I attach 1000M to a db2 machine/user. Will that userid then
show up in the list generated by the Q XSTORE MAP command? If this is the case is there
a command that will tell me who is using XSTORE and how much (either a percentage or a
total amount used).
And should I let the system allocate it or should I issue the attach statement? I can see using the
attach statement if you absolutely want a user to have a specific amount of XSTORE because of
a constrained environment. But what about non-constrained?
Thanks,
Steve G.
