Re: GDPS/XRC for z/VM and Linux volumes
Bob, could you please explain your pain points with GDPS/XRC in your Linux/VM setup? While z/VM itself doesn't seem to timestamp its I/O Linux does and z/VM would carry all Linux timestamps out to the storage control unit as it re-issues the Linux I/O requests. Do you have problems with these limitations? Other? Best regards Ingo Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on 28.06.2007 21:03:45: Dave, So what is the reasonable recommended methodology for handling those volumes? Stop everything and do point-in-time? Say it ain't so! :-( Bob Richards -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Dave Jones Sent: Thursday, June 28, 2007 2:51 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: GDPS/XRC for z/VM and Linux volumes Hi, Bob... Sorry, no you wont:-( GDPS/XRC don't play nice in the z/VM and Linux world, at least in my experience at a couple of client sites Richards.Bob wrote: Is anyone here running GDPS/XRC and how are you handling z/VM and Linux volumes? I didn't exactly like what I was reading in the Advanced Copy Services manual. Hopefully, I'll feel better here. grin LEGAL DISCLAIMER The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. SunTrust and Seeing beyond money are federally registered service marks of SunTrust Banks, Inc. [ST:XCL] -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: GDPS/XRC for z/VM and Linux volumes
Bob, AFAIK GDPS/XRC is a supported configuration except that only the Linux I/O is timestamped and hence XRC eligible while I/O on VM's own behalf is not (unless it changed recently). I.e. if this is acceptable for your setup you should be able adding Linux volumes to your XRC configuration. Not sure about the GDPS side of the configuration, hence adding Dave Petersen on copy. He should be able telling us whether he can manage Linux operated minidisks or whether he requires dedicated disks when running Linux under z/VM in a GDPS/XRC setup. Best regards Ingo Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on 28.06.2007 22:04:41: Alan, Unfortunately, my backup site is about 500 miles away. PPRC is not an option here. Does TSA for Linux also require PPRC? Are there any plans to support GDPS/XRC customers? Bob Richards -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Thursday, June 28, 2007 3:59 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: GDPS/XRC for z/VM and Linux volumes On Thursday, 06/28/2007 at 03:03 AST, Richards.Bob [EMAIL PROTECTED] wrote: So what is the reasonable recommended methodology for handling those volumes? Stop everything and do point-in-time? Say it ain't so! :-( Tivoli System Automation for Linux (TSA) will work with GDPS on z/OS to handle LPAR failover and volume failover TSA will monitor VM volumes (user and CP-owned) and work with GDPS and CP HYPERSWAP to recover the failing volume. GDPS uses PPRC (Metro or Global Mirror) rather than XRC (aka z/OS Global Mirror). Alan Altmark z/VM Development IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 LEGAL DISCLAIMER The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. SunTrust and Seeing beyond money are federally registered service marks of SunTrust Banks, Inc. [ST:XCL] -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Backup and Restore Strategies For Z/Linux
We are new to z/Linux here, so I could be wrong in what I'm about to say. Please correct me if I am. We run z/OS in one LPAR and z/VM, with several Linux guests, in another. I don't think that the presences of z/VM makes a difference with respect to backups. We were told by the consultant who helped us install z/VM and SUSE Linux, that Linux makes extensive use of memory caching in handling its file systems. For this reason, he claimed, it is IMPOSSIBLE to get a valid backup from MVS, or any other system, while the Linux machine is running. The backup will run just fine, but upon restoring the DASD, the file system WILL be corrupted. Not MAY be corrupted. WILL be. For that reason, I have setup a virtual machine, with the necessary privilege, that shuts down all the Linux guests at 1:00 am. A backup job is submitted on z/OS at 1:30, and the virtual machine I created restarts the Linux guests at 6:00 am. Our schedule permits this. I realize that others' may not. We are looking into other, more robust and sophisticated backup strategies. Paul Noble, Systems Programmer Cuyahoga County Information Service Center Jones, Russell [EMAIL PROTECTED] 6/28/2007 3:18 PM We are running z/Linux in an LPAR. It is a 1 volume system. We are currently using an MVS batch job to back up the volume while Linux is running. I know that this is not a good idea, and I would like to know how other shops handle backup and restore of their z/Linux systems. So far, our method has worked fine. At our disaster recovery exercises, we simply restore the volume with DFDSS and away we go. We would like the process to be as automated as possible. We could train the operators to shutdown Linux, run the backup, and then bring it back up, but we would like to avoid that if possible. We would also like to avoid bringing a tape drive online to Linux. We don't have the resources to dedicate a drive to Linux fulltime, and switching a drive between MVS and Linux during the batch cycle would difficult. I appreciate any suggestions. Russ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: GDPS/XRC for z/VM and Linux volumes
Mary Anne, Any gotchas in your XRC setup? Bob Richards -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Mary Anne Matyaz Sent: Thursday, June 28, 2007 7:25 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: GDPS/XRC for z/VM and Linux volumes We haven't really tested the GDPS Automation part, but XRC is working pretty well for us, and we have brought up VM and Linuxes at the D/R site. GDPS WILL automate the activation of the LPAR so as long as you have everything set to come up automagically from there you should be fine. The only thing I'm still having trouble with is doing an SFS FILESERV GENERATE while the volumes are in XRC. That was giving me a RC901 and crashing the SDMplex, but IBM has opened an APAR for that. Mary Anne On 6/28/07, Alan Altmark [EMAIL PROTECTED] wrote: On Thursday, 06/28/2007 at 04:04 AST, Richards.Bob [EMAIL PROTECTED] wrote: Unfortunately, my backup site is about 500 miles away. PPRC is not an option here. Does TSA for Linux also require PPRC? Are there any plans to support GDPS/XRC customers? Yes, it requires PPRC. PPRC V2 has Global Mirror for long-distance connections. Alan Altmark z/VM Development IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 LEGAL DISCLAIMER The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. SunTrust and Seeing beyond money are federally registered service marks of SunTrust Banks, Inc. [ST:XCL] -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Backup and Restore Strategies For Z/Linux
On 6/29/07, Rich Smrcina [EMAIL PROTECTED] wrote: It's exactly like rebooting a Linux PC after some sort of crash, it goes through a filesystem check (fsck). There's a big difference. If the PC crashes you have a consistent state as it was at that time. But when you have z/OS on the other end copy the disk track by track, it is not consistent. It's like the panoramic photo's in Google Streetview, composed of multiple pictures taken short after each other from slightly different location. A person walking by could show on adjacent pictures and appear duplicate when you combine the pictures. If you use snapshot on the ESS, you do get a consistent copy. But then you still may loose data. Even on a journaled file system because only meta data is normally recovered. Rob -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: GDPS/XRC for z/VM and Linux volumes
Dave should know. My local IBMer is trying to find out from Noshir Dhondy. Between those two, there should be a good answer! :-) Out of curiosity, Alan, why aren't z/VM writes timestamped? Bob Richards -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Ingo Adlung Sent: Friday, June 29, 2007 3:13 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: GDPS/XRC for z/VM and Linux volumes Bob, AFAIK GDPS/XRC is a supported configuration except that only the Linux I/O is timestamped and hence XRC eligible while I/O on VM's own behalf is not (unless it changed recently). I.e. if this is acceptable for your setup you should be able adding Linux volumes to your XRC configuration. Not sure about the GDPS side of the configuration, hence adding Dave Petersen on copy. He should be able telling us whether he can manage Linux operated minidisks or whether he requires dedicated disks when running Linux under z/VM in a GDPS/XRC setup. Best regards Ingo Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on 28.06.2007 22:04:41: Alan, Unfortunately, my backup site is about 500 miles away. PPRC is not an option here. Does TSA for Linux also require PPRC? Are there any plans to support GDPS/XRC customers? Bob Richards -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Thursday, June 28, 2007 3:59 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: GDPS/XRC for z/VM and Linux volumes On Thursday, 06/28/2007 at 03:03 AST, Richards.Bob [EMAIL PROTECTED] wrote: So what is the reasonable recommended methodology for handling those volumes? Stop everything and do point-in-time? Say it ain't so! :-( Tivoli System Automation for Linux (TSA) will work with GDPS on z/OS to handle LPAR failover and volume failover TSA will monitor VM volumes (user and CP-owned) and work with GDPS and CP HYPERSWAP to recover the failing volume. GDPS uses PPRC (Metro or Global Mirror) rather than XRC (aka z/OS Global Mirror). Alan Altmark z/VM Development IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 LEGAL DISCLAIMER The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. SunTrust and Seeing beyond money are federally registered service marks of SunTrust Banks, Inc. [ST:XCL] -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: GDPS/XRC for z/VM and Linux volumes
Ingo, My setup won't exist for a few weeks yet. What I am trying to find out is how GDPS and XRC can provide failover capability to a z/VM - Linux environment. Based on what you are telling me, in an XRC/SDM pull operation, the timestamps for all Linux volumes should be reassembled just fine on the secondary DASD, same as for z/OS volumes. What I really need to understand then is what are my exposures if I XRC the VM and Linux volumes. What is different/lost when compared to a z/OS setup? Bob Richards -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Ingo Adlung Sent: Friday, June 29, 2007 3:03 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: GDPS/XRC for z/VM and Linux volumes Bob, could you please explain your pain points with GDPS/XRC in your Linux/VM setup? While z/VM itself doesn't seem to timestamp its I/O Linux does and z/VM would carry all Linux timestamps out to the storage control unit as it re-issues the Linux I/O requests. Do you have problems with these limitations? Other? Best regards Ingo Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on 28.06.2007 21:03:45: Dave, So what is the reasonable recommended methodology for handling those volumes? Stop everything and do point-in-time? Say it ain't so! :-( Bob Richards -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Dave Jones Sent: Thursday, June 28, 2007 2:51 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: GDPS/XRC for z/VM and Linux volumes Hi, Bob... Sorry, no you wont:-( GDPS/XRC don't play nice in the z/VM and Linux world, at least in my experience at a couple of client sites Richards.Bob wrote: Is anyone here running GDPS/XRC and how are you handling z/VM and Linux volumes? I didn't exactly like what I was reading in the Advanced Copy Services manual. Hopefully, I'll feel better here. grin LEGAL DISCLAIMER The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. SunTrust and Seeing beyond money are federally registered service marks of SunTrust Banks, Inc. [ST:XCL] -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Backup and Restore Strategies For Z/Linux
Paul, Your method provides you with the best backup possible with the tools that you have. It's benefit is that is that it is a consistent backup, whereas if you did not shut down the Linux machines you would have an inconsistent backup where on startup your Linux machines would have to attempt to recover those filesystems. It's exactly like rebooting a Linux PC after some sort of crash, it goes through a filesystem check (fsck). Some will recover, some won't, why take the chance? Taking the backup from Linux gives you the best of both worlds. Paul Noble wrote: We are new to z/Linux here, so I could be wrong in what I'm about to say. Please correct me if I am. We run z/OS in one LPAR and z/VM, with several Linux guests, in another. I don't think that the presences of z/VM makes a difference with respect to backups. We were told by the consultant who helped us install z/VM and SUSE Linux, that Linux makes extensive use of memory caching in handling its file systems. For this reason, he claimed, it is IMPOSSIBLE to get a valid backup from MVS, or any other system, while the Linux machine is running. The backup will run just fine, but upon restoring the DASD, the file system WILL be corrupted. Not MAY be corrupted. WILL be. For that reason, I have setup a virtual machine, with the necessary privilege, that shuts down all the Linux guests at 1:00 am. A backup job is submitted on z/OS at 1:30, and the virtual machine I created restarts the Linux guests at 6:00 am. Our schedule permits this. I realize that others' may not. We are looking into other, more robust and sophisticated backup strategies. Paul Noble, Systems Programmer Cuyahoga County Information Service Center Jones, Russell [EMAIL PROTECTED] 6/28/2007 3:18 PM We are running z/Linux in an LPAR. It is a 1 volume system. We are currently using an MVS batch job to back up the volume while Linux is running. I know that this is not a good idea, and I would like to know how other shops handle backup and restore of their z/Linux systems. So far, our method has worked fine. At our disaster recovery exercises, we simply restore the volume with DFDSS and away we go. We would like the process to be as automated as possible. We could train the operators to shutdown Linux, run the backup, and then bring it back up, but we would like to avoid that if possible. We would also like to avoid bringing a tape drive online to Linux. We don't have the resources to dedicate a drive to Linux fulltime, and switching a drive between MVS and Linux during the batch cycle would difficult. I appreciate any suggestions. Russ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- 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 2008 - Chattanooga - April 18-22, 2008 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Backup and Restore Strategies For Z/Linux
Well OK, maybe the analogy wasn't absolutely perfect. The point is on reboot Linux will think it crashed, Linux will attempt to rebuild it's filesystem, it may or may not work. Don't take the chance with your corporate data. Rob van der Heij wrote: On 6/29/07, Rich Smrcina [EMAIL PROTECTED] wrote: It's exactly like rebooting a Linux PC after some sort of crash, it goes through a filesystem check (fsck). There's a big difference. If the PC crashes you have a consistent state as it was at that time. But when you have z/OS on the other end copy the disk track by track, it is not consistent. It's like the panoramic photo's in Google Streetview, composed of multiple pictures taken short after each other from slightly different location. A person walking by could show on adjacent pictures and appear duplicate when you combine the pictures. If you use snapshot on the ESS, you do get a consistent copy. But then you still may loose data. Even on a journaled file system because only meta data is normally recovered. Rob -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- 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 2008 - Chattanooga - April 18-22, 2008 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: GDPS/XRC for z/VM and Linux volumes
It should be noted that, as far as we've been able to find out (and there are still IBM'ers working on it, so this may not be true shortly), z/VM cannot participate in GDPS if you are running CSE, or if you have any DASD shared between two z/VM LPARs. As I understand it currently, if our z/OS systems go with GDPS, and if and when they test the fail-over (which they want to do at least twice a year), both of my z/VM systems will crash. -- .~.Robert P. Nix Mayo Foundation /V\RO-OE-5-55200 First Street SW /( )\ 507-284-0844 Rochester, MN 55905 ^^-^^ - In theory, theory and practice are the same, but in practice, theory and practice are different. On 6/29/07 8:36 AM, Richards.Bob [EMAIL PROTECTED] wrote: Dave should know. My local IBMer is trying to find out from Noshir Dhondy. Between those two, there should be a good answer! :-) Out of curiosity, Alan, why aren't z/VM writes timestamped? Bob Richards -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Ingo Adlung Sent: Friday, June 29, 2007 3:13 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: GDPS/XRC for z/VM and Linux volumes Bob, AFAIK GDPS/XRC is a supported configuration except that only the Linux I/O is timestamped and hence XRC eligible while I/O on VM's own behalf is not (unless it changed recently). I.e. if this is acceptable for your setup you should be able adding Linux volumes to your XRC configuration. Not sure about the GDPS side of the configuration, hence adding Dave Petersen on copy. He should be able telling us whether he can manage Linux operated minidisks or whether he requires dedicated disks when running Linux under z/VM in a GDPS/XRC setup. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: GDPS/XRC for z/VM and Linux volumes
could you please explain your pain points with GDPS/XRC in your Linux/VM setup? While z/VM itself doesn't seem to timestamp its I/O Linux does and z/VM would carry all Linux timestamps out to the storage control unit as it re-issues the Linux I/O requests. Do you have problems with these limitations? Other? While I'm not Bob, an observation: The problem here is a common one when having conversations with IBM about virtualization on Z at any real scale. The solution that is offered supports only part of the problem. You've addressed the Linux and z/OS layers, but the z/VM layer -- which is just as important, as it controls the resource allocation to the Linux layer and is directly critical to the cost and ROI cases for having Linux on Z in the first place, is completely left out of the management picture of the solution. If you're trying for a completely managed solution (which is what GDPS is supposed to provide), then omitting a major portion of the solution from the management integration pretty much torpedoes the argument for creating the solution in the first place. If I have to create exceptions to the IBM management infrastructure to *deal with a strategic product made by IBM*, then there is a fundamental design problem here. Having VM be unmanaged in that environment blows the whole premise of completely controllable failover. The same argument applies to EWLM, IRD, and many other things -- GDPS and the tools required to implement really highly-available managed solutions need to be actively cognizant of the presence of VM in scenarios like GDPS, and not treat it as a poor stepchild who can be ignored as a helpless invalid. Treat it as a client, but treat it you must, because it's a critical piece of the plumbing. LPAR isn't an acceptable alternative. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Backup and Restore Strategies For Z/Linux
Correct on all counts. Using a tool like Bacula (open source, but support available and z/OS friendly) or TSM (from IBM) provides the file level backup and recoverability required in this environment. Paul Noble wrote: So, if I'm understanding this correctly, taking a backup of a running Linux system from another LPAR gives you, at best, an unreliable backup. That means that there are only two viable alternatives: Shut down Linux and do the backup from another LPAR or, Use a backup client that runs within Linux and therefore participates in its file system processing, getting all the current and correct data for the backup. Is that about it? The problem, as I see it, with backing up from another LPAR is that there is no incremental or differential backup capability. Nor is there any selective restore capability. Its an all-or-nothing backup/restore. Paul Noble Cuyahoga County Information Service Center -- 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 2008 - Chattanooga - April 18-22, 2008 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Backup and Restore Strategies For Z/Linux
-Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Paul Noble Sent: Friday, June 29, 2007 10:01 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Backup and Restore Strategies For Z/Linux So, if I'm understanding this correctly, taking a backup of a running Linux system from another LPAR gives you, at best, an unreliable backup. That's certainly how I read it. That means that there are only two viable alternatives: Shut down Linux and do the backup from another LPAR or, Yes. The plus is that you can then restore your Linux environment the same way that you restore the z/OS or z/VM environment. Also, you can manage your tapes using your standard tape management software (which doesn't exist at all on Linux, as I understand it). The minus is unavailability of the Linux system during this time (which is shorted by some sort of snap shot, if you have that capability) and well as it being an all or nothing DASD level backup / restore, which is not useful for restoring individual files. Use a backup client that runs within Linux and therefore participates in its file system processing, getting all the current and correct data for the backup. Correct. But, again, Linux does not interface to the normal tape management systems used by other System z operating systems. Is that about it? The problem, as I see it, with backing up from another LPAR is that there is no incremental or differential backup capability. Nor is there any selective restore capability. Its an all-or-nothing backup/restore. Yea. Paul Noble Cuyahoga County Information Service Center -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Backup and Restore Strategies For Z/Linux
So, if I'm understanding this correctly, taking a backup of a running Linux system from another LPAR gives you, at best, an unreliable backup. That means that there are only two viable alternatives: Shut down Linux and do the backup from another LPAR or, Use a backup client that runs within Linux and therefore participates in its file system processing, getting all the current and correct data for the backup. Is that about it? The problem, as I see it, with backing up from another LPAR is that there is no incremental or differential backup capability. Nor is there any selective restore capability. Its an all-or-nothing backup/restore. Paul Noble Cuyahoga County Information Service Center Rich Smrcina [EMAIL PROTECTED] 6/29/2007 10:20 AM Well OK, maybe the analogy wasn't absolutely perfect. The point is on reboot Linux will think it crashed, Linux will attempt to rebuild it's filesystem, it may or may not work. Don't take the chance with your corporate data. Rob van der Heij wrote: On 6/29/07, Rich Smrcina [EMAIL PROTECTED] wrote: It's exactly like rebooting a Linux PC after some sort of crash, it goes through a filesystem check (fsck). There's a big difference. If the PC crashes you have a consistent state as it was at that time. But when you have z/OS on the other end copy the disk track by track, it is not consistent. It's like the panoramic photo's in Google Streetview, composed of multiple pictures taken short after each other from slightly different location. A person walking by could show on adjacent pictures and appear duplicate when you combine the pictures. If you use snapshot on the ESS, you do get a consistent copy. But then you still may loose data. Even on a journaled file system because only meta data is normally recovered. Rob -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- 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 2008 - Chattanooga - April 18-22, 2008 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Backup and Restore Strategies For Z/Linux
So, if I'm understanding this correctly, taking a backup of a running Linux system from another LPAR gives you, at best, an unreliable backup. Yep. That means that there are only two viable alternatives: Shut down Linux and do the backup from another LPAR or, Use a backup client that runs within Linux and therefore participates in its file system processing, getting all the current and correct data for the backup. Is that about it? Admirably put. The problem, as I see it, with backing up from another LPAR is that there is no incremental or differential backup capability. Nor is there any selective restore capability. Its an all-or-nothing backup/restore. The problem there is that none of the IBM-supplied tools can interpret a Linux filesystem. You're dumping physical data, which doesn't include any metadata like what block belongs to what file. The Linux backup clients have that capability because they're privy to the information Linux keeps. That's why there's no incremental or differential capability. An image is an image. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Backup and Restore Strategies For Z/Linux
Along this same track - if one uses a Linux based backup and restore utility, then how does one restore a base image in a disaster situation? D.R. providers generally have a z/OS and z/VM environment. How many have a Linux environment to do the restores? I would ASSuME that if I used Linux to dump a filesystem to an FCP connected tape, that the tape could be read on an FICON or ESCON connected drive (same type, of course). You back up from your client systems that actually do the work over an internal network (hipersocket, shared OSA, guest LAN/VSWITCH) to a designated Linux instance that acts only as a backup server, which you can shut down at will without disrupting real services. You then dump the Linux backup server with ADRDSSU or DDR or FDR as an image. On DR restore, you restore the backup server first, then boot a rescue system in the individual virtual machines that gets you on the network, and then you restore the guest from the backup server. If you can afford a periodic outage, you can take down each Linux guest periodically and do a image dump of it. That can form a base image that can be quickly restored, then use the Linux-based backup server to bring it up to date at a file level. What about tape management on the Linux system? How do you determine what volumes to send off-site? How do you track volumes (scratch vs. in-use, on site vs. off site)? Since there is no concept of media management as we understand it in the mainframe world on any Unix or Linux variant, the applications have to do it themselves (and every application does it differently). Amanda and Bacula manage their own tapes, as does TSM. FDR Upstream communicates with a z/OS process and does the tape I/O on z/OS, so the data storage happens along with the z/OS backups. Is there any way to integrate this with CA-1 (our tape manager)? See above. It's one of the IMHO best selling points for FDR Upstream, but the trick I suggested with DFSMShsm and NFS works with all the Linux-based backup tools without having SCSI tape drives (or any tape at all on Linux, for that matter). The main reason I added IBM and ANSI SL support to Bacula was to make it behave better in the world of managed media. I ask because I've recently seen the work that our tape librarian goes thru managing the open system tapes. It is as bad as back in the OS/360 (MVT) days! Lots of paper work. Yep. Thus the development of the trick, and why it annoys the hell out of me that IBM storage development doesn't provide a way for Linux guests to get better access to channel-attached tape, or that the ISV TMS vendors don't do a better job of providing a mtx extension that can communicate with an existing catalog. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Backup and Restore Strategies For Z/Linux
On Fri, Jun 29, 2007 at 11:59 AM, in message [EMAIL PROTECTED], McKown, John [EMAIL PROTECTED] wrote: Along this same track - if one uses a Linux based backup and restore utility, then how does one restore a base image in a disaster situation? Funny you should ask. http://sinenomine.net/node/587 See DR-for-Linux-Part1-WAVV2007.pdf and DR-for-Linux-Part2-WAVV2007.pdf Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Backup and Restore Strategies For Z/Linux
Along this same track - if one uses a Linux based backup and restore utility, then how does one restore a base image in a disaster situation? D.R. providers generally have a z/OS and z/VM environment. How many have a Linux environment to do the restores? I would ASSuME that if I used Linux to dump a filesystem to an FCP connected tape, that the tape could be read on an FICON or ESCON connected drive (same type, of course). What about tape management on the Linux system? How do you determine what volumes to send off-site? How do you track volumes (scratch vs. in-use, on site vs. off site)? Is there any way to integrate this with CA-1 (our tape manager)? I ask because I've recently seen the work that our tape librarian goes thru managing the open system tapes. It is as bad as back in the OS/360 (MVT) days! Lots of paper work. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Backup and Restore Strategies For Z/Linux
On Fri, Jun 29, 2007 at 11:00 AM, in message [EMAIL PROTECTED], Paul Noble [EMAIL PROTECTED] wrote: -snip- The problem, as I see it, with backing up from another LPAR is that there is no incremental or differential backup capability. Nor is there any selective restore capability. Its an all-or-nothing backup/restore. Backing up from another system, outside of Linux, has only ever been good for DRA backups, not file-level backups. Any backup strategy has to account for both needs, since they're for two entirely different purposes. I hope your SLES guests are working well for you. :) Let me know if they're not. Mark Post Linux Deployment SWAT Team -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: GDPS/XRC for z/VM and Linux volumes
David, After reading your reply, feel free to pass yourself off as me anytime! :-) Extremely well stated! And it is exactly where I was going with this thread. Bob Richards -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of David Boyes Sent: Friday, June 29, 2007 10:55 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: GDPS/XRC for z/VM and Linux volumes could you please explain your pain points with GDPS/XRC in your Linux/VM setup? While z/VM itself doesn't seem to timestamp its I/O Linux does and z/VM would carry all Linux timestamps out to the storage control unit as it re-issues the Linux I/O requests. Do you have problems with these limitations? Other? While I'm not Bob, an observation: The problem here is a common one when having conversations with IBM about virtualization on Z at any real scale. The solution that is offered supports only part of the problem. You've addressed the Linux and z/OS layers, but the z/VM layer -- which is just as important, as it controls the resource allocation to the Linux layer and is directly critical to the cost and ROI cases for having Linux on Z in the first place, is completely left out of the management picture of the solution. If you're trying for a completely managed solution (which is what GDPS is supposed to provide), then omitting a major portion of the solution from the management integration pretty much torpedoes the argument for creating the solution in the first place. If I have to create exceptions to the IBM management infrastructure to *deal with a strategic product made by IBM*, then there is a fundamental design problem here. Having VM be unmanaged in that environment blows the whole premise of completely controllable failover. The same argument applies to EWLM, IRD, and many other things -- GDPS and the tools required to implement really highly-available managed solutions need to be actively cognizant of the presence of VM in scenarios like GDPS, and not treat it as a poor stepchild who can be ignored as a helpless invalid. Treat it as a client, but treat it you must, because it's a critical piece of the plumbing. LPAR isn't an acceptable alternative. LEGAL DISCLAIMER The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. SunTrust and Seeing beyond money are federally registered service marks of SunTrust Banks, Inc. [ST:XCL] -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Backup and Restore Strategies For Z/Linux
I think there is two or more issues, backing up the data using DDR type backup only gives you full backup. therefore you need to install/get software package to do you back. The problems are: - Many linux server where password changes, many other thing get installed on that servers. - Your not the ADMIN in control of those servers. - not all servers are the same. and many others... If you are lucky, only have few hours to do your backup, Sunday from 2am-5am. z/VM we perform the clone, is the same as cratering a golden image or install linux from a network. The problem is keep track all the installed software and what was changed on those servers... /etc/passwd . If you lost you /usr... the backup you did was just waste of time -- you need to boot from recovery disk, chroot . . May be DDR type backup is the best .. Boot linux from a recovery system(disk) and mount that filesystem(s) to correct the problem -- if need, run the restore. I know there is a shop(s) that do there install from a one servers, all ADMINs uses(go thru) that servers to install, config... etc to address this issue . it seems if there is good maintenance procedures then recovery is less pain. McKown, John [EMAIL PROTECTED] thmarkets.com To Sent by: Linux LINUX-390@VM.MARIST.EDU on 390 Portcc [EMAIL PROTECTED] IST.EDU Subject Re: Backup and Restore Strategies For Z/Linux 06/29/2007 11:14 AM Please respond to Linux on 390 Port [EMAIL PROTECTED] IST.EDU -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Paul Noble Sent: Friday, June 29, 2007 10:01 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Backup and Restore Strategies For Z/Linux So, if I'm understanding this correctly, taking a backup of a running Linux system from another LPAR gives you, at best, an unreliable backup. That's certainly how I read it. That means that there are only two viable alternatives: Shut down Linux and do the backup from another LPAR or, Yes. The plus is that you can then restore your Linux environment the same way that you restore the z/OS or z/VM environment. Also, you can manage your tapes using your standard tape management software (which doesn't exist at all on Linux, as I understand it). The minus is unavailability of the Linux system during this time (which is shorted by some sort of snap shot, if you have that capability) and well as it being an all or nothing DASD level backup / restore, which is not useful for restoring individual files. Use a backup client that runs within Linux and therefore participates in its file system processing, getting all the current and correct data for the backup. Correct. But, again, Linux does not interface to the normal tape management systems used by other System z operating systems. Is that about it? The problem, as I see it, with backing up from another LPAR is that there is no incremental or differential backup capability. Nor is there any selective restore capability. Its an all-or-nothing backup/restore. Yea. Paul Noble Cuyahoga County Information Service Center -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 Visit our website at http://www.nyse.com Note: The information contained in this message and any attachment to it is privileged, confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received
Re: GDPS/XRC for z/VM and Linux volumes
Robert, I do not understand your last sentence. Why would your z/VM systems crash? Is it because they are on DASD that is under XRC? Bob Richards -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of RPN01 Sent: Friday, June 29, 2007 10:53 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: GDPS/XRC for z/VM and Linux volumes It should be noted that, as far as we've been able to find out (and there are still IBM'ers working on it, so this may not be true shortly), z/VM cannot participate in GDPS if you are running CSE, or if you have any DASD shared between two z/VM LPARs. As I understand it currently, if our z/OS systems go with GDPS, and if and when they test the fail-over (which they want to do at least twice a year), both of my z/VM systems will crash. -- .~.Robert P. Nix Mayo Foundation /V\RO-OE-5-55200 First Street SW /( )\ 507-284-0844 Rochester, MN 55905 ^^-^^ - In theory, theory and practice are the same, but in practice, theory and practice are different. On 6/29/07 8:36 AM, Richards.Bob [EMAIL PROTECTED] wrote: Dave should know. My local IBMer is trying to find out from Noshir Dhondy. Between those two, there should be a good answer! :-) Out of curiosity, Alan, why aren't z/VM writes timestamped? Bob Richards -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Ingo Adlung Sent: Friday, June 29, 2007 3:13 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: GDPS/XRC for z/VM and Linux volumes Bob, AFAIK GDPS/XRC is a supported configuration except that only the Linux I/O is timestamped and hence XRC eligible while I/O on VM's own behalf is not (unless it changed recently). I.e. if this is acceptable for your setup you should be able adding Linux volumes to your XRC configuration. Not sure about the GDPS side of the configuration, hence adding Dave Petersen on copy. He should be able telling us whether he can manage Linux operated minidisks or whether he requires dedicated disks when running Linux under z/VM in a GDPS/XRC setup. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 LEGAL DISCLAIMER The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. SunTrust and Seeing beyond money are federally registered service marks of SunTrust Banks, Inc. [ST:XCL] -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Backup and Restore Strategies For Z/Linux
The ultimate, I think, would be a VM based backup tool that plays nice with the Linux file system. It would: 1. Recognize if Linux is running. 2. If Linux is running, tell it to purge it's file cache and 'go to sleep'. 3. Access a Linux minidisk and understand the file system that resides there. 4. Run full / incremental backup or restore. 5. Tell Linux to wake up when it's over. This would also allow easy recovery of dead penguins, as well as take advantage of proven backup tools. Sounds simple on paper at least. Ray Mrohs U.S. Department of Justice 202-307-6896 -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Eddie Chen Sent: Friday, June 29, 2007 2:29 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Backup and Restore Strategies For Z/Linux I think there is two or more issues, backing up the data using DDR type backup only gives you full backup. therefore you need to install/get software package to do you back. The problems are: - Many linux server where password changes, many other thing get installed on that servers. - Your not the ADMIN in control of those servers. - not all servers are the same. and many others... If you are lucky, only have few hours to do your backup, Sunday from 2am-5am. z/VM we perform the clone, is the same as cratering a golden image or install linux from a network. The problem is keep track all the installed software and what was changed on those servers... /etc/passwd . If you lost you /usr... the backup you did was just waste of time -- you need to boot from recovery disk, chroot . . May be DDR type backup is the best .. Boot linux from a recovery system(disk) and mount that filesystem(s) to correct the problem -- if need, run the restore. I know there is a shop(s) that do there install from a one servers, all ADMINs uses(go thru) that servers to install, config... etc to address this issue . it seems if there is good maintenance procedures then recovery is less pain. McKown, John [EMAIL PROTECTED] thmarkets.com To Sent by: Linux LINUX-390@VM.MARIST.EDU on 390 Port cc [EMAIL PROTECTED] IST.EDU Subject Re: Backup and Restore Strategies For Z/Linux 06/29/2007 11:14 AM Please respond to Linux on 390 Port [EMAIL PROTECTED] IST.EDU -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Paul Noble Sent: Friday, June 29, 2007 10:01 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Backup and Restore Strategies For Z/Linux So, if I'm understanding this correctly, taking a backup of a running Linux system from another LPAR gives you, at best, an unreliable backup. That's certainly how I read it. That means that there are only two viable alternatives: Shut down Linux and do the backup from another LPAR or, Yes. The plus is that you can then restore your Linux environment the same way that you restore the z/OS or z/VM environment. Also, you can manage your tapes using your standard tape management software (which doesn't exist at all on Linux, as I understand it). The minus is unavailability of the Linux system during this time (which is shorted by some sort of snap shot, if you have that capability) and well as it being an all or nothing DASD level backup / restore, which is not useful for restoring individual files. Use a backup client that runs within Linux and therefore participates in its file system processing, getting all the current and correct data for the backup. Correct. But, again, Linux does not interface to the normal tape management systems used by other System z operating systems. Is that about it? The problem, as I see it, with backing up from another LPAR is that there is no incremental or differential backup capability. Nor is there any selective restore capability. Its an all-or-nothing backup/restore. Yea. Paul Noble Cuyahoga County Information Service Center -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in
qeth ipv6 dependency
A customer has a security policy that only allows ipv4, so they can't assign an ipv6 address to eth0, and can't have an ipv6 over ipv4 tunnel. Ideally, they'd like to remove the ipv6 kernel module altogether. In RHEL 4 and SLES 9, they were able to do this. In RHEL 5 and SLES 10, they're finding that dependencies don't allow them to do this. It appears there are too many hard linkages between qeth and ipv6. When they alias ipv6 off in modprobe.conf, they get messages like: qeth: Unknown symbol in6_dev_finish_destroy qeth: Unknown symbol addrconf_lock qeth: Unknown symbol unregister_inet6addr_notifier qeth: Unknown symbol ndisc_mc_map qeth: Unknown symbol register_inet6addr_notifier qeth: Unknown symbol in6_dev_finish_destroy qeth: Unknown symbol addrconf_lock qeth: Unknown symbol unregister_inet6addr_notifier qeth: Unknown symbol ndisc_mc_map qeth: Unknown symbol register_inet6addr_notifier qeth: Unknown symbol in6_dev_finish_destroy qeth: Unknown symbol addrconf_lock qeth: Unknown symbol unregister_inet6addr_notifier qeth: Unknown symbol ndisc_mc_map qeth: Unknown symbol register_inet6addr_notifier I found this link, so it seems someone has asked this question before: http://www.ibm.com/developerworks/linux/linux390/linux-2.6.5-s390-32-april2004.html Specifically, Problem-ID 19880: Description: qeth: customer wants qeth driver to be loaded and running without ipv6 module loaded prior to. Symptom: qeth module built with ipv6 support will not load when ipv6 module is not loaded. Problem: qeth driver is using basic ipv6 functions which are needed to register IPv6 IP addresses. These functions are not available when ipv6 module is not loaded. Solution: Use symbol_put/symbol_get and get function addresses when available and call them. Use wrapper functions then in qeth. - So the question is: Does anyone know when this change happened in the qeth code? i.e. What was the decision/feature in the module that necessitated this dependency? Was the patch in the link above ever proposed upstream? Thanks, -Brad -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Backup and Restore Strategies For Z/Linux
On Fri, Jun 29, 2007 at 3:09 PM, in message [EMAIL PROTECTED], Mrohs, Ray [EMAIL PROTECTED] wrote: The ultimate, I think, would be a VM based backup tool that plays nice with the Linux file system. It would: 1. Recognize if Linux is running. 2. If Linux is running, tell it to purge it's file cache and 'go to sleep'. 3. Access a Linux minidisk and understand the file system that resides there. You mean something like this? http://sinenomine.net/vm/ext2free 4. Run full / incremental backup or restore. 5. Tell Linux to wake up when it's over. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: qeth ipv6 dependency
On Fri, Jun 29, 2007 at 3:42 PM, in message [EMAIL PROTECTED], Brad Hinson [EMAIL PROTECTED] wrote: A customer has a security policy that only allows ipv4, so they can't assign an ipv6 address to eth0, and can't have an ipv6 over ipv4 tunnel. Ideally, they'd like to remove the ipv6 kernel module altogether. -snip- So the question is: Does anyone know when this change happened in the qeth code? i.e. What was the decision/feature in the module that necessitated this dependency? Was the patch in the link above ever proposed upstream? It looks like it was implemented, and then modified later on. I see a good number of #ifdef CONFIG_QETH_IPV6 statements in drivers/s390/net/qeth_main.c. I checked, and it was turned on for SLES10 kernels, which I suppose would be why they can't get by without the ipv6 module. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
vmcp during boot results in Error: Could not open device /dev/vmcp: No such device
Hi Listers. I am trying to issue a vmcp command within a boot script and receive the following message during boot: Error: Could not open device /dev/vmcp: No such device +++ RC=3 +++ Once the system is booted, I can see the device... Any ideas on how to make this device permanent? Thanks in advance for any help. Susan -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: vmcp during boot results in Error: Could not open device /dev/vmcp: No such device
On Fri, Jun 29, 2007 at 4:31 PM, in message [EMAIL PROTECTED], Susan Zimmerman [EMAIL PROTECTED] wrote: Hi Listers. I am trying to issue a vmcp command within a boot script and receive the following message during boot: Error: Could not open device /dev/vmcp: No such device +++ RC=3 +++ Once the system is booted, I can see the device... Any ideas on how to make this device permanent? Which distribution are you running? On SLES, you can add vmcp to the list of modules that need to be in the initrd by editing /etc/sysconfig/kernel INITRD_MODULES=vmcp Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: GDPS/XRC for z/VM and Linux volumes
On Friday, 06/29/2007 at 09:36 AST, Richards.Bob [EMAIL PROTECTED] wrote: Out of curiosity, Alan, why aren't z/VM writes timestamped? Host-generated timestamps are part of the older XRC architecture (z/OS Global Mirror) that z/VM can't really use. When multiple LPARs or CECs are involved, you need a single time source (Sysplex Timer or STP) to ensure that I/Os will be reordered properly at the other end. z/VM doesn't do time synchronization. Also, XRC is not available to Open systems, and CP has to be able to operate in a SCSI environment (z/OS does not). We didn't want to invest in two technologies. XRC rebranding to z/OS Global Mirror helps us drive home the point that it is intended for use only by z/OS. Alan Altmark z/VM Development IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Backup and Restore Strategies For Z/Linux
I think we should ask at what condition that we want to do the restore. If a users lost some data... DDR types restore is not a good ideal... again you need software that are friendly to the user. And this is the same for system ADMIN erase the /etc. Then ADMIN would wish it had done a find with atime, then tar the stuff. If something real bad, Then you best thing is the backup form z/OS/VM tape. And hope it will come up... most likely it well. depend on the size of the shop, backup the DATA using DDR type(full backup) is limited.. only have the Saturday/Sunday backup. . better than nothing, restore what has changed since M-F. In other environments it will need to rebuild the filesystem and then restore form tape .. If you can't backup the DATA using DDR, Then you will need to backup the data as if it your server is a DL585. The DDR type of backing up system files is not as bad as DATA... some system has /boot and then /rootvg that can be a problem because when you add a dasd to that server you need to make sure is in the list. - In the old days, and I am sure that most shop shutdown there linux thru the operator #cp shutdown.. not the shutdown -h now In the environment that has many DL585 how do they restore there server and identify what is on that server so it can be rebuild and be up to date.. or if the sysadmin erase something in the /etc Mrohs, Ray [EMAIL PROTECTED] gov To Sent by: Linux LINUX-390@VM.MARIST.EDU on 390 Portcc [EMAIL PROTECTED] IST.EDU Subject Re: Backup and Restore Strategies For Z/Linux 06/29/2007 03:09 PM Please respond to Linux on 390 Port [EMAIL PROTECTED] IST.EDU The ultimate, I think, would be a VM based backup tool that plays nice with the Linux file system. It would: 1. Recognize if Linux is running. 2. If Linux is running, tell it to purge it's file cache and 'go to sleep'. 3. Access a Linux minidisk and understand the file system that resides there. 4. Run full / incremental backup or restore. 5. Tell Linux to wake up when it's over. This would also allow easy recovery of dead penguins, as well as take advantage of proven backup tools. Sounds simple on paper at least. Ray Mrohs U.S. Department of Justice 202-307-6896 -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Eddie Chen Sent: Friday, June 29, 2007 2:29 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Backup and Restore Strategies For Z/Linux I think there is two or more issues, backing up the data using DDR type backup only gives you full backup. therefore you need to install/get software package to do you back. The problems are: - Many linux server where password changes, many other thing get installed on that servers. - Your not the ADMIN in control of those servers. - not all servers are the same. and many others... If you are lucky, only have few hours to do your backup, Sunday from 2am-5am. z/VM we perform the clone, is the same as cratering a golden image or install linux from a network. The problem is keep track all the installed software and what was changed on those servers... /etc/passwd . If you lost you /usr... the backup you did was just waste of time -- you need to boot from recovery disk, chroot . . May be DDR type backup is the best .. Boot linux from a recovery system(disk) and mount that filesystem(s) to correct the problem -- if need, run the restore. I know there is a shop(s) that do there install from a one servers, all ADMINs uses(go thru) that servers to install, config... etc to address this issue . it seems if there is good maintenance procedures then recovery is less pain. McKown, John [EMAIL PROTECTED] thmarkets.com To Sent by: Linux LINUX-390@VM.MARIST.EDU on 390 Port cc [EMAIL PROTECTED] IST.EDU Subject Re: Backup and Restore Strategies For Z/Linux 06/29/2007 11:14 AM Please respond to Linux on 390 Port [EMAIL PROTECTED] IST.EDU -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Paul Noble Sent: Friday, June 29, 2007 10:01 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Backup and Restore Strategies For Z/Linux
Re: vmcp during boot results in Error: Could not open device /dev/vmcp: No such device
On Fri, 2007-06-29 at 14:34 -0600, Mark Post wrote: On Fri, Jun 29, 2007 at 4:31 PM, in message [EMAIL PROTECTED], Susan Zimmerman [EMAIL PROTECTED] wrote: Hi Listers. I am trying to issue a vmcp command within a boot script and receive the following message during boot: Error: Could not open device /dev/vmcp: No such device +++ RC=3 +++ Once the system is booted, I can see the device... Any ideas on how to make this device permanent? Which distribution are you running? On SLES, you can add vmcp to the list of modules that need to be in the initrd by editing /etc/sysconfig/kernel INITRD_MODULES=vmcp Mark Post In RHEL, you can modprobe vmcp in /etc/rc.local, or you can do this directly in your startup script. Early versions of RHEL 4 have a delay between loading the module and the device node showing up in /dev, so you can do something like the attached clone script from the RHEL 4 Redbook (see the function wait_for_device). RHEL 4.5 and beyond shouldn't have this delay. -Brad -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 clone Description: application/shellscript
Re: Backup and Restore Strategies For Z/Linux
Well, I back up both ways... DDR type backup of the Linux system disk (/hda). Sometimes I throw in a tar of the system disk as well. But all data, I backup logically. Either tar for NFS and Samba, or the database backup utilities that come with DB2/UDB and Oracle. Not only this keeps the data in a known good state, but you can logically restore one or more files without restoring everything. The DDRs are good for the disaster side. So far, the tar of the system disk hasn't proved useful. When I blow it, either the system won't come up (hence the DDR restore) or so many files have changed that a logical restore of some files, is just too cumbersome. I experimented with using the Linux install system (when you IPL the reader when under VM), to link over to the bad system. That seemed to work. It was fine for manual editing of configuration files, but didn't include all the software necessary to access my restore media and the restore programs. I thought about, but haven't gotten around to it yet, of having a Linux image as a repair facility. An image that can have access to all Linux disks, and procedures setup for repairing a damaged image (either manually or by a logical restore). But so far, haven't had the time. Tom Duerbusch THD Consulting Eddie Chen [EMAIL PROTECTED] 6/29/2007 4:01 PM I think we should ask at what condition that we want to do the restore. If a users lost some data... DDR types restore is not a good ideal... again you need software that are friendly to the user. And this is the same for system ADMIN erase the /etc. Then ADMIN would wish it had done a find with atime, then tar the stuff. If something real bad, Then you best thing is the backup form z/OS/VM tape. And hope it will come up... most likely it well. depend on the size of the shop, backup the DATA using DDR type(full backup) is limited.. only have the Saturday/Sunday backup. . better than nothing, restore what has changed since M-F. In other environments it will need to rebuild the filesystem and then restore form tape .. If you can't backup the DATA using DDR, Then you will need to backup the data as if it your server is a DL585. The DDR type of backing up system files is not as bad as DATA... some system has /boot and then /rootvg that can be a problem because when you add a dasd to that server you need to make sure is in the list. - In the old days, and I am sure that most shop shutdown there linux thru the operator #cp shutdown.. not the shutdown -h now In the environment that has many DL585 how do they restore there server and identify what is on that server so it can be rebuild and be up to date.. or if the sysadmin erase something in the /etc Mrohs, Ray [EMAIL PROTECTED] gov To Sent by: Linux LINUX-390@VM.MARIST.EDU on 390 Portcc [EMAIL PROTECTED] IST.EDU Subject Re: Backup and Restore Strategies For Z/Linux 06/29/2007 03:09 PM Please respond to Linux on 390 Port [EMAIL PROTECTED] IST.EDU The ultimate, I think, would be a VM based backup tool that plays nice with the Linux file system. It would: 1. Recognize if Linux is running. 2. If Linux is running, tell it to purge it's file cache and 'go to sleep'. 3. Access a Linux minidisk and understand the file system that resides there. 4. Run full / incremental backup or restore. 5. Tell Linux to wake up when it's over. This would also allow easy recovery of dead penguins, as well as take advantage of proven backup tools. Sounds simple on paper at least. Ray Mrohs U.S. Department of Justice 202-307-6896 -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Eddie Chen Sent: Friday, June 29, 2007 2:29 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Backup and Restore Strategies For Z/Linux I think there is two or more issues, backing up the data using DDR type backup only gives you full backup. therefore you need to install/get software package to do you back. The problems are: - Many linux server where password changes, many other thing get installed on that servers. - Your not the ADMIN in control of those servers. - not all servers are the same. and many others... If you are lucky, only have few hours to do your backup, Sunday from 2am-5am. z/VM we perform the clone, is the same as cratering a golden image or install linux from a network. The problem is keep track all the installed software and what was changed on those servers... /etc/passwd . If you lost you
Re: Backup and Restore Strategies For Z/Linux
An alternative to An image that can have access to all Linux disks is a sharable rescue system on read-only dasd that any Linux VM userid can LINK and boot from. Like the Linux install system IPL-ed from the guest's reader, it has access to all the guest's disks. This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system. -Original Message- From: Linux on 390 Port on behalf of Tom Duerbusch Sent: Fri 6/29/2007 5:34 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Backup and Restore Strategies For Z/Linux snip I experimented with using the Linux install system (when you IPL the reader when under VM), to link over to the bad system. That seemed to work. It was fine for manual editing of configuration files, but didn't include all the software necessary to access my restore media and the restore programs. I thought about, but haven't gotten around to it yet, of having a Linux image as a repair facility. An image that can have access to all Linux disks, and procedures setup for repairing a damaged image (either manually or by a logical restore). But so far, haven't had the time. Tom Duerbusch THD Consulting -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Backup and Restore Strategies For Z/Linux
Mrohs, Ray wrote: The ultimate, I think, would be a VM based backup tool that plays nice with the Linux file system. It would: 1. Recognize if Linux is running. 2. If Linux is running, tell it to purge it's file cache and 'go to sleep'. Suspend to disk. Linux does it on Intellish systems. 3. Access a Linux minidisk and understand the file system that resides there. Another Linux guest (or boot disk) can do that. 4. Run full / incremental backup or restore. 5. Tell Linux to wake up when it's over. This would also allow easy recovery of dead penguins, as well as take advantage of proven backup tools. Sounds simple on paper at least. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Please do not reply off-list -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Hercules 3.05 announcement
I built 3.05 on SUSE 10.2 x64. Running Suse s390x, my compile test went from 7+ hours to just under 3 hours. Well done! Paul -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Hipersockets Conundrum
We are starting our Linux POC and all has been going well. Until I got to the Hipersockets, that is. We are trying to talk to two z/OS LPARs, one development and one production. in our IFL LPAR, z/VM 5.2 RSU 0701 and SLES9x SP3. POC is a Java app that gets messages via MQ Series and reformats into XML and queries a site on the web via https. The initial test worked well with MQ talking over the OSAs out to our internal network and back in the other OSA (why don't we share them? Don't ask!). Now we want to modify that use a Hipersocket interface. Initial: z/OS -- OSA -- network -- OSA -- Linux (on vswitch) Wanted: z/OS -- Hipersockets -- Linux Hipersockets were defined on CHPID 50 (addresses 5000-500F) . xxx.yyy.zzz are the same for all the following addresses: Both z/OS systems are v1.6. and have addresses xxx,yyy,zzz,101 and xxx,yyy,zzz,102 (development and production, respectively) using addresses 500-5002. The z/OS systems can ping each other. I set up the z/VM guest to use 5004-5006 through dedicate statements in the SYSTEM CONFIG and used yast to add configure the interface as xxx.yyy.zzz,103. All indications are that the interface is fine: q osa OSA 2130 ATTACHED TO DTCVSW2 2130 DEVTYPE OSA CHPID F3 OSD OSA 2131 ATTACHED TO DTCVSW2 2131 DEVTYPE OSA CHPID F3 OSD OSA 2132 ATTACHED TO DTCVSW2 2132 DEVTYPE OSA CHPID F3 OSD OSA 5004 ATTACHED TO LINUX001 5000 DEVTYPE HIPER CHPID 50 IQD OSA 5005 ATTACHED TO LINUX001 5001 DEVTYPE HIPER CHPID 50 IQD OSA 5006 ATTACHED TO LINUX001 5002 DEVTYPE HIPER CHPID 50 IQD lnxa0001:/home/otsgold # ifconfig hsi0 hsi0 Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet addr:172.20.1.103 Bcast:172.20.1.255 Mask:255.255.255.0 inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link UP BROADCAST RUNNING NOARP MULTICAST MTU:8192 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:10 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:1048 (1.0 Kb) SLES9x info: lnxa0001:/home/otsgold # uname -a Linux lnxa0001 2.6.5-7.244-s390x #1 SMP Mon Dec 12 18:32:25 UTC 2005 s390x s390x s390x GNU/Linux Any ideas as to why the SLES9x will not talk to z/OS? Any thing I should look for, ask or z/OS network people, etc.? Kim -- Kim Goldenberg Systems Programmer I State of NJ - OIT 609-777-3722 [EMAIL PROTECTED] [EMAIL PROTECTED] -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Hipersockets Conundrum
So are your OSA devices and Hipersocket devices all on the same network? In other words do they all have a 172.20.1.x address with a netmask of 255.255.255.0? Kim Goldenberg wrote: We are starting our Linux POC and all has been going well. Until I got to the Hipersockets, that is. We are trying to talk to two z/OS LPARs, one development and one production. in our IFL LPAR, z/VM 5.2 RSU 0701 and SLES9x SP3. POC is a Java app that gets messages via MQ Series and reformats into XML and queries a site on the web via https. The initial test worked well with MQ talking over the OSAs out to our internal network and back in the other OSA (why don't we share them? Don't ask!). Now we want to modify that use a Hipersocket interface. Initial: z/OS -- OSA -- network -- OSA -- Linux (on vswitch) Wanted: z/OS -- Hipersockets -- Linux Hipersockets were defined on CHPID 50 (addresses 5000-500F) . xxx.yyy.zzz are the same for all the following addresses: Both z/OS systems are v1.6. and have addresses xxx,yyy,zzz,101 and xxx,yyy,zzz,102 (development and production, respectively) using addresses 500-5002. The z/OS systems can ping each other. I set up the z/VM guest to use 5004-5006 through dedicate statements in the SYSTEM CONFIG and used yast to add configure the interface as xxx.yyy.zzz,103. All indications are that the interface is fine: q osa OSA 2130 ATTACHED TO DTCVSW2 2130 DEVTYPE OSA CHPID F3 OSD OSA 2131 ATTACHED TO DTCVSW2 2131 DEVTYPE OSA CHPID F3 OSD OSA 2132 ATTACHED TO DTCVSW2 2132 DEVTYPE OSA CHPID F3 OSD OSA 5004 ATTACHED TO LINUX001 5000 DEVTYPE HIPER CHPID 50 IQD OSA 5005 ATTACHED TO LINUX001 5001 DEVTYPE HIPER CHPID 50 IQD OSA 5006 ATTACHED TO LINUX001 5002 DEVTYPE HIPER CHPID 50 IQD lnxa0001:/home/otsgold # ifconfig hsi0 hsi0 Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet addr:172.20.1.103 Bcast:172.20.1.255 Mask:255.255.255.0 inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link UP BROADCAST RUNNING NOARP MULTICAST MTU:8192 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:10 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:1048 (1.0 Kb) SLES9x info: lnxa0001:/home/otsgold # uname -a Linux lnxa0001 2.6.5-7.244-s390x #1 SMP Mon Dec 12 18:32:25 UTC 2005 s390x s390x s390x GNU/Linux Any ideas as to why the SLES9x will not talk to z/OS? Any thing I should look for, ask or z/OS network people, etc.? Kim -- Kim Goldenberg Systems Programmer I State of NJ - OIT 609-777-3722 [EMAIL PROTECTED] [EMAIL PROTECTED] -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- 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 2008 - Chattanooga - April 18-22, 2008 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
