Re: Printers to 2nd Level VM
Clumsy phrasing on my part (slapped wrist accepted) ... should have said, 'No longer supports real 1403'. Apologies for lack of precision.
Re: IPLing z/VM 2nd level with many lines and columns
On Wed, Jun 15, 2011 at 7:30 AM, Michael MacIsaac mike...@us.ibm.com wrote: We ran into a problem IPLing a z/VM 2nd level using a 3270 emulator (PComm) with a setting of 62x160 (LINESxCOLS). Setting it back to 43x80 worked around the problem. Is this a known issue? Thanks. You're being vague. What is on the business end of your connection? Connecting to first level TCPIP and then dial into the guest works for me with large 3270 screens. If you connect to the TCPIP inside the guest, then maybe you forgot to raise the databufferpoolsize there? That would cause problems when the screen fills. Rob
Re: IPLing z/VM 2nd level with many lines and columns
Rob, You're being vague. What is on the business end of your connection? A SAPL screen. So we do a: == IPL 200 CLEAR And z/VM starts to IPL. Press F10. With an emulator that has the large screen size, the session gets disconnected. Mike MacIsaac mike...@us.ibm.com (845) 433-7061
Re: IPLing z/VM 2nd level with many lines and columns
On Wed, Jun 15, 2011 at 10:33 AM, Michael MacIsaac mike...@us.ibm.com wrote: Rob, You're being vague. What is on the business end of your connection? A SAPL screen. So we do a: == IPL 200 CLEAR And z/VM starts to IPL. Press F10. With an emulator that has the large screen size, the session gets disconnected. Buffer size of the 1st level TCPIP maybe? Have you been able to do very large writes already there? I believe XEDIT of a wide file with real content would show. I just tried it myself with Tom Brennan's Vista TN3270. SAPL forces a 24x80 formatted screen, and after PF10 the system console then is an unformatted screen in default size. When OPERATOR is there, my XEDIT session sees the 60x150 logical screen as well. Rob
Re: IPLing z/VM 2nd level with many lines and columns
An incorrect mtu specification somewhere along the data path can cause this, as might pcomm v6. See the internal pcomm forum. Regards, Alan Altmark IBM Lab Services - Sent from my BlackBerry Handheld. - Original Message - From: Michael MacIsaac Sent: 06/15/2011 01:30 AM AST To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] IPLing z/VM 2nd level with many lines and columns Hi, We ran into a problem IPLing a z/VM 2nd level using a 3270 emulator (PComm) with a setting of 62x160 (LINESxCOLS). Setting it back to 43x80 worked around the problem. Is this a known issue? Thanks. (I know, I know, Doctor it hurts when I do this - So don't do this :)) Mike MacIsaac mike...@us.ibm.com (845) 433-7061
zVM crash update
The LPAR had been up and running for weeks, minding its own business, and chugging right along. Then, 3:30 PM Monday, kaboom, disabled wait. IBM has determined we had a tight loop condition that triggered the processor being taken offline. We did get a MCW002 abend and dump. Dump analysis should lead IBM and us to fixing the loop and thus stopping it from happening again. Best theory so far is that zVM tried to restart following the MCW002 abend, couldn't find a console, thus the 1010 disabled wait. Thanks for all the suggestions! -Original Message- From: Burton, Randy Sent: Tuesday, June 14, 2011 9:47 AM To: 'IBMVM@LISTSERV.UARK.EDU' Subject: zVM crash I'm curious if this error rings a bell with any of you. We of course have an ETR open and are working with IBM. No hardware errors on the HMC, so we believe this was software and not hardware. Here's the last operator log message before the LPAR went into a disabled wait: HCPMPG9152E PROCESSOR 01 IS BEING VARIED OFFLINE BECAUSE IT IS NOT RESPONSIVE. Disabled wait PSW was: 00021010 HMC message was: Central processor (CP) 0 in partition VMD1, entered disabled wait state. Fortunately this was our development (test) zVM system, running a bunch of test zLinux guests. We're running zVM 6.1 on a z10. Of course we are nervous because what happens in test can happen in production. We IPLed and so far so good. Thanks in advance for any help/suggestions! Randy Burton BBT Bank
Re: zVM crash update
Randy, Thank you for the update munson From: Burton, Randy rbur...@bbandt.com To: IBMVM@LISTSERV.UARK.EDU Date: 06/15/2011 09:52 AM Subject:zVM crash update Sent by:The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU The LPAR had been up and running for weeks, minding its own business, and chugging right along. Then, 3:30 PM Monday, kaboom, disabled wait. IBM has determined we had a tight loop condition that triggered the processor being taken offline. We did get a MCW002 abend and dump. Dump analysis should lead IBM and us to fixing the loop and thus stopping it from happening again. Best theory so far is that zVM tried to restart following the MCW002 abend, couldn't find a console, thus the 1010 disabled wait. Thanks for all the suggestions! -Original Message- From: Burton, Randy Sent: Tuesday, June 14, 2011 9:47 AM To: 'IBMVM@LISTSERV.UARK.EDU' Subject: zVM crash I'm curious if this error rings a bell with any of you. We of course have an ETR open and are working with IBM. No hardware errors on the HMC, so we believe this was software and not hardware. Here's the last operator log message before the LPAR went into a disabled wait: HCPMPG9152E PROCESSOR 01 IS BEING VARIED OFFLINE BECAUSE IT IS NOT RESPONSIVE. Disabled wait PSW was: 00021010 HMC message was: Central processor (CP) 0 in partition VMD1, entered disabled wait state. Fortunately this was our development (test) zVM system, running a bunch of test zLinux guests. We're running zVM 6.1 on a z10. Of course we are nervous because what happens in test can happen in production. We IPLed and so far so good. Thanks in advance for any help/suggestions! Randy Burton BBT Bank *** IMPORTANT NOTE*-- The opinions expressed in this message and/or any attachments are those of the author and not necessarily those of Brown Brothers Harriman Co., its subsidiaries and affiliates (BBH). There is no guarantee that this message is either private or confidential, and it may have been altered by unauthorized sources without your or our knowledge. Nothing in the message is capable or intended to create any legally binding obligations on either party and it is not intended to provide legal advice. BBH accepts no responsibility for loss or damage from its use, including damage from virus.
CLONEBKP: New package at zVM/downloads
Hi, friends. I put a new package on the zVM downloads page (my debut): CLONEBKP. See:http://www.vm.ibm.com/download/packages/ I hope it is useful to you. For who will use it: suggestions, improvements or bugs found, are all welcome. Follow the description: CLONEBKP is a REXX exec that create an IPLable copy (CLONE) of the running ZVM system. This package uses DDR to copy the specified dasds of a running zVM system to FREE dasds. After the copy, the new dasds are renamed to a new volser, based on a prefix (3 or 4 letters), and the exec updates the source and compile USER DIRECT into the new dasds. Also update the new SYSTEM CONFIG. The new set of dasds is a backup of the original zVM and can be IPLed without duplicate volsers. If DIRMAINT is logged at original VM, a new USER INPUT is also created. The new volsers (6 positions) are the prefix padded with the remainder letters of the original dasds, right justified. Ex. Using BKP as prefix, the new 610RES will be renamed to BKPRES. One file, CLONEBKP CONFIG, is supplied as a model how to specify the prefix and the Input/Output dasds. Is possible to keep several CONFIG files, with different configurations. Also, there are a model of one machine to test IPL in second level: VMBKP SAMPDIR Best regards, __ Clovis
Re: CLONEBKP: New package at zVM/downloads
Great Package Big Clóvis, we already using it ;) Thank You!! On Wed, Jun 15, 2011 at 4:45 PM, gclo...@br.ibm.com wrote: Hi, friends. I put a new package on the zVM downloads page (my debut): *CLONEBKP*. See:http://www.vm.ibm.com/download/packages/ I hope it is useful to you. For who will use it: suggestions, improvements or bugs found, are all welcome. Follow the description: CLONEBKP is a REXX exec that create an IPLable copy (CLONE) of the running ZVM system. This package uses DDR to copy the specified dasds of a running zVM system to FREE dasds. After the copy, the new dasds are renamed to a new volser, based on a prefix (3 or 4 letters), and the exec updates the source and compile USER DIRECT into the new dasds. Also update the new SYSTEM CONFIG. The new set of dasds is a backup of the original zVM and can be IPLed without duplicate volsers. If DIRMAINT is logged at original VM, a new USER INPUT is also created. The new volsers (6 positions) are the prefix padded with the remainder letters of the original dasds, right justified. Ex. Using BKP as prefix, the new 610RES will be renamed to BKPRES. One file, CLONEBKP CONFIG, is supplied as a model how to specify the prefix and the Input/Output dasds. Is possible to keep several CONFIG files, with different configurations. Also, there are a model of one machine to test IPL in second level: VMBKP SAMPDIR Best regards, __ Clovis
z/OS 1.4 running under z/VM 5.4 over a z890
Hello. I need to prepare a migration from an old OS/390 2.5 to z/OS 1.4 over a z890 machine. Can I use z/VM 5.4 as host to a z/OS 1.4 guest? OS/390 2.5 will continue to run over a 9672 until all has been migrated to z/OS. z/OS 1.4 could run in compatibility mode or not, but this is another question to z/OS list. Thanks in advance -- Carlos Bodra IBM Certified Specialist System z Sao Paulo - Brazil
Re: z/OS 1.4 running under z/VM 5.4 over a z890
On Wednesday, 06/15/2011 at 04:23 EDT, Carlos Bodra - Pessoal cbo...@terra.com.br wrote: Can I use z/VM 5.4 as host to a z/OS 1.4 guest? z/OS 1.8 is the oldest release that is *supported* by z/VM 5.4. See Appendix B of the Running Guest Operating Systems book. Will z/OS 1.4 *run*? I don't see why not, as long as you have the z990 Exploitation support installed per http://www-03.ibm.com/systems/z/os/zos/support/zos_server_support.html. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: z/VM page space
On Tue, 14 Jun 2011 11:04:25 -0700, Schuh, Richard rsc...@visa.com wrot e: A good decision, probably not a difficult one, by Mr. Holder and friends . Untangling that can of worms should not be a high priority use of development $$. Regards, Richard Schuh There are, of course, other reasons one might want this (or similar) function, such as supporting paging devices with dramatically different response times and bandwidths - load balancing new outbound writes which we already do) isn't really sufficient for such a scenario - in order to prevent the fastest devices from filling up with the oldest data over time, a migration function would be required to move those now older pages off to slower devices (since they're not being re-referenced, you really don't want them taking up space on the faster devices). Also, the real design issue is that there's simply not enough real estate to maintain backward pointers up the structures in order to be able to easily determine, from a paging slot (4K record) on a paging volume back up to the owner of the page it contains - the storage overhead becomes astronomical rather quickly, and you don't want to be spending lots of storage representing things that are themselves paged out. So the only way to find the pages is to run all of the translation structures for all virtual storage from the top down scanning for them (this is indeed how expanded storage migration works, which is why ATTACH XSTORE often takes so long). One further comment on the idea of bootlegging the migration function by touching user pages - it's not just user pages that are out there, it's quite likely that the target paging volume also contains some pageable CP owned pages (especially PGMBKs), some of which are simply not touchable by any action from a guest. So even if you could figure out which users had pages on the volume, it would still likely be impossible to get all of the pages off of it. Anyway, there are long standing requirements open for the drain migrate function, we know it would be useful, but thus far, there have always seemed to be more pressing needs. Bill Holder, Senior Software Engineer IBM z/VM Development, Memory Management, Endicott, NY Phone: 607-429-3640
Re: CLONEBKP: New package at zVM/downloads
Greetings and Nice work! I definitely plan on stealing (borrowing) a couple of your routines. Your process is similar in many respects to what we do here (though your code is much prettier). Ours flash-copies the CP volumes with the savelabel parameter to our backup disk volumes every night and we then DDR the copies off to virtual tape for DR purposes. These newly copied volumes are owned by a second level VM userid and are easily IPL'able as I've set up a special System Config on the third extent (maint CF3) to point at these copies as my CP volumes. I've also used SYSRES in my user directory in a few places so that maint will get access to his needed volumes no matter what they are named. Once the system is IPL'd (either second level or first), I run an xedit from maint to change the remaining cp mdisks in the directory to their new names and put the directory online. Once this is done, a quick change to autolog1 to recognize the new system name and I can bring up the rest of my service machines and users can log on. That's the gist of it. The best part is I can bring my DR system up second level whenever I want with very little effort. Bob From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Rogério Soares Sent: Wednesday, June 15, 2011 3:16 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: CLONEBKP: New package at zVM/downloads Great Package Big Clóvis, we already using it ;) Thank You!! On Wed, Jun 15, 2011 at 4:45 PM, gclo...@br.ibm.commailto:gclo...@br.ibm.com wrote: Hi, friends. I put a new package on the zVM downloads page (my debut): CLONEBKP. See:http://www.vm.ibm.com/download/packages/ I hope it is useful to you. For who will use it: suggestions, improvements or bugs found, are all welcome. Follow the description: CLONEBKP is a REXX exec that create an IPLable copy (CLONE) of the running ZVM system. This package uses DDR to copy the specified dasds of a running zVM system to FREE dasds. After the copy, the new dasds are renamed to a new volser, based on a prefix (3 or 4 letters), and the exec updates the source and compile USER DIRECT into the new dasds. Also update the new SYSTEM CONFIG. The new set of dasds is a backup of the original zVM and can be IPLed without duplicate volsers. If DIRMAINT is logged at original VM, a new USER INPUT is also created. The new volsers (6 positions) are the prefix padded with the remainder letters of the original dasds, right justified. Ex. Using BKP as prefix, the new 610RES will be renamed to BKPRES. One file, CLONEBKP CONFIG, is supplied as a model how to specify the prefix and the Input/Output dasds. Is possible to keep several CONFIG files, with different configurations. Also, there are a model of one machine to test IPL in second level: VMBKP SAMPDIR Best regards, __ Clovis This electronic transmission and any documents accompanying this electronic transmission contain confidential information belonging to the sender. This information may be legally privileged. The information is intended only for the use of the individual or entity named above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or the taking of any action in reliance on or regarding the contents of this electronically transmitted information is strictly prohibited.
Re: IPLing z/VM 2nd level with many lines and columns
Rob, Alan, Thanks, your feedback helps! Mike MacIsaac mike...@us.ibm.com (845) 433-7061
