The CP Monitor and VM Perfkit (that gets most of its input from the CP Monitor) do indeed not care about what happens inside a guest. Linux is an exception with its module that forwards things to Perfkit. The majority of MVS systems do not run under VM, hence the handshaking of MVS with VM is not very function rich.
As to find reasons for a crash: that's not Perfkit's role, not even for CMS "guests". As there is no console information, I'd go the same path as for CMS users: CP SEND CP mvsxyz TRACE PROG RUN TERMINAL or CP SEND CP mvsxyz TRACE PROG RUN PRINTER for the first alternative: be sure the have MVS' virtual console started and spooled somewhere. For the second: define a virtual printer at a low address, like CP SEND CP mvsxys DEFINE PRT 00E With this trace, every program check will be reported, but MVS keeps running and can attempt to perform its usual abend recovery. Also abends in user programs will be reported this way. For CMS we often found a first program check occurring, followed by a program check in the abend recovery routines. Such a TRACE has a very low overhead. When you'd fine such an abend just before the MVS crash, you can change the TRACE command and try to be more precise in your trace (e.g. limit the address range), and when an abend happens, take a VMDUMP, or display registers, .... As there can be many traces concurrently, issue CP SEND CP mvsxyz TRACE END ALL before issuing a new trace command. 2011/8/7 saurabh khandelwal <sourabhkhandelwal...@gmail.com> > So, does it mean, by installing z/VM performence tool kit will not tell us > any detail about the guest running under z/VM ( MVS guest) . > > Basically my aim is to find out the reason behind crashing MVS guest > suddenly , which are running under zVM. > > So can you please suggest, what will be the best solution to find root > cause of MVS guest crashing. > > > Thanks & Regards > Saurabh > > > > > On Sun, Aug 7, 2011 at 2:50 AM, Les Koehler <vmr...@tampabay.rr.com>wrote: > >> Kris, >> >> Isn't MVS under VM different than just straight MVS on its own? Or have >> things changed since the old days? >> >> Les >> >> >> Kris Buelens wrote: >> >>> MVS doesn't normally have anything to forward performance info to >>> Perfkit. >>> MVS has its own performance collection and reporting tools. >>> >>> 2011/8/6 saurabh khandelwal >>> <sourabhkhandelwal123@gmail.**com<sourabhkhandelwal...@gmail.com> >>> > >>> >>> Thanks for reply. >>>> >>>> >>>> Yes, I am trying to reach out the person, who has configured Performance >>>> toolkit in my site. So that I can get exact detail, how he configured >>>> this. >>>> >>>> As I am new with performance toolkit, I also wanted to ask is it >>>> possible >>>> to get MVS guest information from performance toolkit , which are >>>> running >>>> under z/VM. >>>> >>>> Thanks & Regards >>>> Saurabh >>>> >>>> >>>> On Sat, Aug 6, 2011 at 1:44 PM, Jeff Gribbin <jeff.grib...@gmail.com >>>> >wrote: >>>> >>>> Saurabh, >>>>> You have almost-certainly indentified the cause of your problem - it is >>>>> NEVER, EVER safe to share the same CMS minidisk accessed in write-mode >>>>> by >>>>> more than one CMS user at the same time - it almost-guarantees that the >>>>> disk >>>>> file system will be damaged. >>>>> >>>>> DASD sharing always requires the sharing systems to be aware that the >>>>> DASD >>>>> is shared and take measures to ensure that the data is not corrupted - >>>>> these >>>>> can be via hardware functions such as RESERVE / RELEASE or via software >>>>> processes that use a communications link to agree amongst themselves >>>>> which >>>>> system has write-permission at any one instant. >>>>> >>>>> CMS contains no sharing mechanism at all for its minidisks (think of a >>>>> CMS >>>>> user as a virtual Personal Computer - write-sharing a minidisk is like >>>>> connecting two personal computers that have no knowledge of each >>>>> others' >>>>> existence to the same hard drive!) >>>>> >>>>> If you wish to share data in write-mode among CMS users then you need >>>>> to >>>>> look at the CMS Shared File System which uses a server to co-ordinate >>>>> the >>>>> I/O among many CMS clients. (In this client/server setup, it's only the >>>>> DATA >>>>> that is shared - the actual DASD is only read/written by the server >>>>> which >>>>> (of course) has complete knowledge of which clients are accessing which >>>>> data.) >>>>> >>>>> Sharing minidisk-containing volumes between separate z/VM systems >>>>> requires >>>>> a lot of care if it is to be successful. If you can tell us a little >>>>> more >>>>> about your configuration and how you run it I'm sure that we can offer >>>>> you >>>>> some suggestions about how to achieve what you wish to do but ... in >>>>> the >>>>> meantime ... yes, each PERFSVM requires a separate 191 (and 195) >>>>> minidisk. >>>>> >>>>> Regards >>>>> Jeff Gribbin >>>>> >>>>> >>>> >>>> -- >>>> Thanks & Regards >>>> Saurabh Khandelwal >>>> >>>> >>> >>> >>> > > > -- > Thanks & Regards > Saurabh Khandelwal > -- Kris Buelens, IBM Belgium, VM customer support
