Fw: z/LINUX Infrastructure Meeting - Wednesday, 08/13/08 @ 11:00 a.m. in NJ 13-09 - #6003
We will hold the regularly scheduled z/LINUX Infrastructure Meeting - tomorrow - same time - same place Bill Munson Brown Brothers Harriman z/VM System Programmer 201-418-7588 - Forwarded by William Munson/JerseyCity/BBH on 08/12/2008 08:16 AM - Ashley George/JerseyCity/BBH 08/05/2008 05:11 PM To William Munson/JerseyCity/[EMAIL PROTECTED] cc ESS zVM-LINUX Subject z/LINUX Infrastructure Meeting - Wednesday, 08/13/08 @ 11:00 a.m. in NJ 13-09 - #6003 Bill, Attached is the meeting notes for next week's z/LINUX Infrastructure Meeting (saved in the s:\opsysspt\zVM and Linux\Linux Infrastructure Meeting directory). As per our conversation in today's staff meeting, please send an e-mail to the 'LINUX' address next Tuesday, 08/12/08, with this attachment and facilitate the meeting. Thanks. Ashley *** 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. 081308 Linux Infrastructure Meeting.xls Description: MS-Excel spreadsheet
Re: Fw: z/LINUX Infrastructure Meeting - Wednesday, 08/13/08 @ 11:00 a.m. in NJ 13-09 - #6003
oops - sorry well there is something to laugh about munson *** 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.
Re: Fw: z/LINUX Infrastructure Meeting
I can't make it, I'm at SHARE this week... :) Bill Munson wrote: oops - sorry well there is something to laugh about munson -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2009 - Orlando, FL - May 15-19, 2009
Who is using DTIPDDSO in z/VM530 ?
Hi, I'm looking for someone who uses DTIPDDSO (VSCS SUPPRESS PSW display when logging). I have a version written in 95 that I used to compile. But now it looks l ike it doesn't work anymore with z/VM530... If someone could send me his source, that would be great. If you want to know what I'm talking about go there in the VM part : www.nrsinc.com/tnd420/tnd0220.pdf alain Benveniste
Re: Safety Reminder: If you are planning disk upgrades, make sure you switch your Linux guests to by-path IDs in /etc/fstab BEFORE you switch
I second that! -- R;
Re: Safety Reminder: If you are planning disk upgrades, make sure you switch your Linux guests to by-path IDs in /etc/fstab BEFORE you switch
Two questions that anyone who is new enough to need your reminder will ask are: What default do you suggest? When changing it, how should it be changed? The old timers here will know the answers. David Boyes wrote: A safety reminder: If you’re planning to replace disk subsystems, make sure your Linux guests (particularly any SLES 10 or above) guests do NOT use by-ID paths in /etc/fstab. Fix this BEFORE the new disk goes in, both RH and SuSE (Debian, too), or your guests will not be able to find their filesystems (and thus won’t boot or run). This really should be in IBM and other DASD vendors planning information for new installs, and I’d demand a fix from your Linux vendors. By-ID is a stupid default for this architecture (for any architecture, I’d argue…) and needs a fix ASAP. IBM, EMC, Hitachi: how do we get this added to your planning guides? RH, Novell, how about it? -- db -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us
OT: Date bug kills VMware systems | The Register
Gee, very interesting bug in VMWare. quote Irate VMware customers were left unable to power up their virtual servers this morning because of a bug that killed their systems when the clock clicked round to 12 August. The bug was sent out to customers in ESX 3.5 update 2, VMware's latest hypervisor, which went out on 27 July. The version could have been downloaded and installed by thousands of customers since then. /quote http://www.theregister.co.uk/2008/08/12/vmware_12_august_esx_cockup/
Re: Safety Reminder: If you are planning disk upgrades, make sure you switch your Linux guests to by-path IDs in /etc/fstab BEFORE you switch
I'm new enough to ask. What? Bobby Bauer Center for Information Technology National Institutes of Health Bethesda, MD 20892-5628 301-594-7474 -Original Message- From: Stephen Frazier [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 12, 2008 12:47 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Safety Reminder: If you are planning disk upgrades, make sure you switch your Linux guests to by-path IDs in /etc/fstab BEFORE you switch Two questions that anyone who is new enough to need your reminder will ask are: What default do you suggest? When changing it, how should it be changed? The old timers here will know the answers. David Boyes wrote: A safety reminder: If you're planning to replace disk subsystems, make sure your Linux guests (particularly any SLES 10 or above) guests do NOT use by-ID paths in /etc/fstab. Fix this BEFORE the new disk goes in, both RH and SuSE (Debian, too), or your guests will not be able to find their filesystems (and thus won't boot or run). This really should be in IBM and other DASD vendors planning information for new installs, and I'd demand a fix from your Linux vendors. By-ID is a stupid default for this architecture (for any architecture, I'd argue...) and needs a fix ASAP. IBM, EMC, Hitachi: how do we get this added to your planning guides? RH, Novell, how about it? -- db -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us
Re: Safety Reminder: If you are planning disk upgrades, make sure you switch your Linux guests to by-path IDs in /etc/fstab BEFORE you switch
Also important if you use a data replication warm site disaster recovery process like EMC's SRDF and whatever the IBM equivalent is. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Boyes Sent: Tuesday, August 12, 2008 12:22 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Safety Reminder: If you are planning disk upgrades, make sure you switch your Linux guests to by-path IDs in /etc/fstab BEFORE you switch A safety reminder: If you're planning to replace disk subsystems, make sure your Linux guests (particularly any SLES 10 or above) guests do NOT use by-ID paths in /etc/fstab. Fix this BEFORE the new disk goes in, both RH and SuSE (Debian, too), or your guests will not be able to find their filesystems (and thus won't boot or run). This really should be in IBM and other DASD vendors planning information for new installs, and I'd demand a fix from your Linux vendors. By-ID is a stupid default for this architecture (for any architecture, I'd argue...) and needs a fix ASAP. IBM, EMC, Hitachi: how do we get this added to your planning guides? RH, Novell, how about it? -- db
Re: Safety Reminder: If you are planning disk upgrades, make sure you switch your Linux guests to by-path IDs in /etc/fstab BEFORE you switch
On Aug 12, 2008, at 11:47 AM, Stephen Frazier wrote: Two questions that anyone who is new enough to need your reminder will ask are: What default do you suggest? When changing it, how should it be changed? The old timers here will know the answers. *I* suggest using the /dev/disk/by-path filename. (I think RH is /dev/ dasd/by-path). Change it with your favorite text editor in /etc/fstab *and* in /etc/ zipl.conf, and don't forget to rerun zipl! Adam
Re: Safety Reminder: If you are planning disk upgrades, make sure you switch your Linux guests to by-path IDs in /etc/fstab BEFORE you switch
.and whatever the IBM equivalent is. PPRC (Peer to Peer Remote Copy). Regards, Rick Giz [EMAIL PROTECTED] 770-781-3206 _ From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Quay, Jonathan (IHG) Sent: Tuesday, August 12, 2008 12:58 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Safety Reminder: If you are planning disk upgrades, make sure you switch your Linux guests to by-path IDs in /etc/fstab BEFORE you switch Also important if you use a data replication warm site disaster recovery process like EMC's SRDF and whatever the IBM equivalent is. _ From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Boyes Sent: Tuesday, August 12, 2008 12:22 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Safety Reminder: If you are planning disk upgrades, make sure you switch your Linux guests to by-path IDs in /etc/fstab BEFORE you switch A safety reminder: If you're planning to replace disk subsystems, make sure your Linux guests (particularly any SLES 10 or above) guests do NOT use by-ID paths in /etc/fstab. Fix this BEFORE the new disk goes in, both RH and SuSE (Debian, too), or your guests will not be able to find their filesystems (and thus won't boot or run). This really should be in IBM and other DASD vendors planning information for new installs, and I'd demand a fix from your Linux vendors. By-ID is a stupid default for this architecture (for any architecture, I'd argue.) and needs a fix ASAP. IBM, EMC, Hitachi: how do we get this added to your planning guides? RH, Novell, how about it? -- db
Re: Date bug kills VMware systems | The Register
Hello! I agree! Now I wonder what the folks at VMWare will say to explain why their virtual servers are on a vacation of some sort. -- Gregg C Levine [EMAIL PROTECTED] The Force will be with you always. Obi-Wan Kenobi -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Tuesday, August 12, 2008 12:50 PM To: IBMVM@LISTSERV.UARK.EDU Subject: OT: Date bug kills VMware systems | The Register Gee, very interesting bug in VMWare. quote Irate VMware customers were left unable to power up their virtual servers this morning because of a bug that killed their systems when the clock clicked round to 12 August. The bug was sent out to customers in ESX 3.5 update 2, VMware's latest hypervisor, which went out on 27 July. The version could have been downloaded and installed by thousands of customers since then. /quote http://www.theregister.co.uk/2008/08/12/vmware_12_august_esx_cockup/
Re: Safety Reminder: If you are planning disk upgrades, make sure you switch your Linux guests to by-path IDs in /etc/fstab BEFORE you switch
On Aug 12, 2008, at 12:25 PM, Thomas Kern wrote: I have been using /dev/dasd?1 where ? goes from a to zz. Is by-path the /dev/disk/0.0.0591 syntax? Yeah, although it's more like /dev/disk/by-path/ccw-0.0.0591-part1 these days. Ada,
Re: Safety Reminder: If you are planning disk upgrades, make sure you switch your Linux guests to by-path IDs in /etc/fstab BEFORE you switch
/dev/disk/by-path/ccw-0.0.8002-part1 The /dev/dasd?1 will still work. Just annoyingly can move if you add disks. In fact, if you are upgrading from sles9 to sles10 you're going to want to have it that anyway since SLES9 uses /dev/disk/by-path/ccw-0.0.8006p1 and the upgrade process won't find that (boo hiss). Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Kern Sent: Tuesday, August 12, 2008 10:26 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Safety Reminder: If you are planning disk upgrades, make sure you switch your Linux guests to by-path IDs in /etc/fstab BEFORE you switch I have been using /dev/dasd?1 where ? goes from a to zz. Is by-path the /dev/disk/0.0.0591 syntax? /Tom Kern On Tue, 12 Aug 2008 12:11:43 -0500, Adam Thornton [EMAIL PROTECTED] et wrote: *I* suggest using the /dev/disk/by-path filename. (I think RH is /dev/ dasd/by-path). Change it with your favorite text editor in /etc/fstab *and* in /etc/ zipl.conf, and don't forget to rerun zipl! Adam = ==
Re: Safety Reminder: If you are planning disk upgrades, make sure you switch your Linux guests to by-path IDs in /etc/fstab BEFORE you switch
And thank you Bobby for admitting that you didn't understand David's reminder. You probably helped lots of other newbies that were wondering what this was about but were afraid to ask. Bauer, Bobby (NIH/CIT) [E] wrote: Thanks David, something new to look into. Bobby Bauer Center for Information Technology National Institutes of Health Bethesda, MD 20892-5628 301-594-7474 I'm new enough to ask. What? Bobby Bauer Center for Information Technology National Institutes of Health Bethesda, MD 20892-5628 301-594-7474 -Original Message- From: Stephen Frazier [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 12, 2008 12:47 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Safety Reminder: If you are planning disk upgrades, make sure you switch your Linux guests to by-path IDs in /etc/fstab BEFORE you switch Two questions that anyone who is new enough to need your reminder will ask are: What default do you suggest? When changing it, how should it be changed? The old timers here will know the answers. -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us
OT: Alan has a pony.
I would just like to point out that Alan Altmark's long-standing wish for a pony has been satisfied. A brown and white pony has been delivered, and he has no need for further ponies. 8-) -- db
Re: OT: Alan has a pony.
Wow, that must be one HECK of a SHARE!! ;- Christine Brogan - TPF/VM Systems Support Information Technology Services Americas Phone: 623-505-5366, Cell: 623-512-5883, IBM tieline 273-4647 Email: [EMAIL PROTECTED] The end of fear is where we begin - the moment we decided to let Love in... Goo Goo Dolls David Boyes [EMAIL PROTECTED] e.net To Sent by: The IBM IBMVM@LISTSERV.UARK.EDU z/VM Operating cc System [EMAIL PROTECTED] Subject ARK.EDU OT: Alan has a pony. 08/12/2008 02:31 PM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU I would just like to point out that Alan Altmark’s long-standing wish for a pony has been satisfied. A brown and white pony has been delivered, and he has no need for further ponies. 8-) -- db
Re: OT: Alan has a pony.
On Aug 12, 2008, at 4:31 PM, David Boyes wrote: I would just like to point out that Alan Altmark’s long-standing wish for a pony has been satisfied. A brown and white pony has been delivered, and he has no need for further ponies. 8-) Uh oh. See, it wasn't Alan who wanted the pony. It was Chucky. That poor, poor pony. Adam
Re: TCPIP PCOMM 658 Code
I thought I'd do a follow up on this problem for anyone who might be interested and who may have a similar setupto the onewe do. I was fairly confident that VM:Operator wasn't to blame for the problem but contactedCA anyway since the only error codes we ever got were from VM:Operator. AfterCA andIdiscounted him as the culprit I decided to focus on TCPIP as I always thought he was to blame. After reading through both the Planning and Configuration manual and the User's Guide I zeroed in on the POOLSIZE part of the PROFILE TCPIP. After issuing the NETSTAT POOLSIZE command I noticed that the system was trying to useSmallDataBufferwhich we had set to zero in the #Alloc column. I say the system was trying to use it only because there was a "1" in the Permit Size column. This was without anyone being logged on via TELNET. At any rate, setting the #Alloc to 10 on my test system seems to have fixed the problem. Logging on multiple users via TELNET and issuing NETSTAT POOLSIZE shows that the numbers in all the other columns do indeed change depending on the number of remote logons I have. For any production machines the #Alloc will be set to 100 as they have many more users. This was never a problem on our 43XX or 9221 systems nor our PC Server based P/390s but for some reason, the Integrated Servers we have are a rather sensitive lot. Either that or PCOMM is more sensitive than Communications Manager/2 but my money is still on TCPIP. One day I hope to be able to work on more modernsystems but for now I'm stuck trying to support unsupported hardware and software.Karl SeversonRaytheon CompanyEl Segundo, California
