Oh - and make sure you FORMAT the entire volume or that it's already formatted when you do the allocation -- otherwise, you'll get paging errors and likely abend.
(That would be CPFMTXA 9F88 - answer FORMAT - answer 0 END - give it label - after format - answer PAGE 1 END - followed by END for the allocation.) Scott Rohling On Thu, Sep 16, 2010 at 11:10 AM, Scott Rohling <[email protected]>wrote: > It appears that you didn't allocate any cylinders VM6PG2 as page space. > Not sure how safe it is to detach that volume - or if a DRAIN will even work > .. For now - you may want to sacrifice another volume (VM6PG3) - allocate > it correctly (PAGE 1 END) -- do the DEF CPOWN SLOT x VM6PG3.. Then you > can relabel things later so PG2 is being used and has page space. > > Scott Rohling > > > On Thu, Sep 16, 2010 at 10:58 AM, Daniel Tate <[email protected]>wrote: > >> EXTENT EXTENT TOTAL PAGES HIGH % >> >> VOLID RDEV START END PAGES IN USE PAGE USED >> >> ------ ---- ---------- ---------- ------ ------ ------ ---- >> >> VM6PG1 9F86 1 10016 1761K 1175K 1761K 66% >> >> VM6PG2 9F87 0 0 180 180 180 100% >> >> ------ ------ ---- >> >> SUMMARY 1761K 1175K 66% >> >> USABLE 1761K 1175K 66% >> >> Ready; T=0.01/0.01 11:56:46 >> >> >> On Thu, Sep 16, 2010 at 11:30 AM, Mike At HammockTree >> <[email protected]> wrote: >> > (I use MAINT too much......) >> > >> > If your SRM STORBUFF values are as you say, then STORBUFF is unlikely to >> be >> > causing the problem, although still possible. The next time the problem >> > occurs, do the >> > CP IND >> > and check for an Eligible list. If the E3 numbers are non-zero, then >> try >> > raising the STORBUFF values further, as Davd suggested (300% 300% >> 300%). >> > >> > Mike >> > ----- Original Message ----- From: "Daniel Tate" <[email protected] >> > >> > To: <[email protected]> >> > Sent: Thursday, September 16, 2010 11:42 AM >> > Subject: Re: CP unresponsive on certain guests >> > >> > >> > CP Q ALLOC PAGE gives me "invalid option - alloc". >> > >> > I didnt set the SRM variables; the consultant who initially came in to >> > set this up might have. >> > >> > >> > On Thu, Sep 16, 2010 at 10:29 AM, Mike At HammockTree >> > <[email protected]> wrote: >> >> >> >> Yeah, that is probably where he needs to end up Dave, but I'm a little >> >> hesitant to recommend the 300% for Q3 without feeling more comfortable >> >> about >> >> his paging subsystem... Moving a couple of large guests from the E-list >> to >> >> in-Q could cause a increase in paging that he may or may not be >> configured >> >> to handle. >> >> >> >> Mike >> >> ----- Original Message ----- From: "Dave Jones" < >> [email protected]> >> >> To: <[email protected]> >> >> Sent: Thursday, September 16, 2010 11:08 AM >> >> Subject: Re: CP unresponsive on certain guests >> >> >> >> >> >>> Actually, Mike, he may be better off (a bit, at least) by setting >> >>> STORBUFF 300 300 300. >> >>> >> >>> On 09/16/2010 09:58 AM, Mike At HammockTree wrote: >> >>>> >> >>>> Since the STORBUF setting is exactly the values I suggested, I >> suspect >> >>>> you applied the >> >>>> SET SRM STORBUFF 300% 250% 200% >> >>>> prior to doing the >> >>>> Q SRM >> >>>> >> >>>> With the current setting for STORBUFF, are you still experiencing the >> >>>> problem? >> >>>> >> >>>> Also, on a related note, what does your zVM paging system look like? >> >>>> The output of >> >>>> CP Q ALLOC PAGE >> >>>> will provide the information >> >>>> >> >>>> Mike >> >>>> ----- Original Message ----- From: "Daniel Tate" < >> [email protected]> >> >>>> To: <[email protected]> >> >>>> Sent: Thursday, September 16, 2010 10:52 AM >> >>>> Subject: Re: CP unresponsive on certain guests >> >>>> >> >>>> >> >>>> Output of Q SRM >> >>>> >> >>>> q srm >> >>>> IABIAS : INTENSITY=90%; DURATION=2 >> >>>> LDUBUF : Q1=100% Q2=75% Q3=60% >> >>>> STORBUF: Q1=300% Q2=250% Q3=200% >> >>>> DSPBUF : Q1=32767 Q2=32767 Q3=32767 >> >>>> DISPATCHING MINOR TIMESLICE = 5 MS >> >>>> MAXWSS : LIMIT=9999% >> >>>> ...... : PAGES=999999 >> >>>> XSTORE : 0% >> >>>> Ready; T=0.01/0.01 09:49:05 >> >>>> >> >>>> >> >>>> On Wed, Sep 15, 2010 at 5:47 PM, Dave Jones <[email protected] >> > >> >>>> wrote: >> >>>>> >> >>>>> Hi, Daniel. >> >>>>> >> >>>>> The answer to your first question is to use the CP FORCE command >> (HELP >> >>>>> CP FORCE will tell you all about it.) The VM user id issuing the >> FORCE >> >>>>> command needs to have privilege class A as well. Usually this is >> done >> >>>>> from either MAINT or OPERATOR. >> >>>>> >> >>>>> The answer to your second question is a bit more difficult, I'm >> afraid. >> >>>>> As Marcy has already suggested, what does a Q SRM command show? My >> >>>>> first >> >>>>> guess would be that your SLES11 guest is falling into Q3 and never >> >>>>> given >> >>>>> an opportunity to run. >> >>>>> >> >>>>> To find out *why* the guest is not able to run, you need the >> services >> >>>>> of >> >>>>> a good z/VM performance monitor.....IBM offers the Performance >> Monitor >> >>>>> (it comes bundles with z/VM, but it's an extra cost offering) and >> >>>>> Velocity Software (http://www.velocity-software.com/) has a very >> good >> >>>>> suite of products as well. IMHO it' practically impossible to run a >> >>>>> modern production grade z/VM-zLinux system without a good >> performance >> >>>>> monitor to help solve issues like the one your having now. >> >>>>> >> >>>>> On 09/15/2010 05:14 PM, Daniel Tate wrote: >> >>>>>> >> >>>>>> We're starting to run apps on the servers now. From time to time a >> >>>>>> guest will become unresponsive - to be more precise, ,the CP will >> not >> >>>>>> respond to commands, and neither will the guest OS (SLES11). not >> >>>>>> even #CP LOGOFF is acknowledged. from another login, CP INDIIC LOAD >> >>>>>> shows no appreciable load. >> >>>>>> >> >>>>>> Two questions from this: >> >>>>>> >> >>>>>> 1) how would I force a logoff of a user from another user? Is this >> >>>>>> possible? >> >>>>>> 2) if we are not paging and the IFLs are not loaded (2-3% >> utilization >> >>>>>> as a matter of fact) what could the bottleneck be? >> >>>>>> >> >>>>> >> >>>>> -- >> >>>>> Dave Jones >> >>>>> V/Soft Software >> >>>>> www.vsoft-software.com >> >>>>> Houston, TX >> >>>>> 281.578.7544 >> >>>>> >> >>>> >> >>> >> >>> -- >> >>> Dave Jones >> >>> V/Soft Software >> >>> www.vsoft-software.com >> >>> Houston, TX >> >>> 281.578.7544 >> >>> >> >>> >> >> >> > >> > >
