Re: DFDSS Backups
>>> On Tue, Jun 24, 2008 at 8:41 PM, in message <[EMAIL PROTECTED]>, "Walters, Gene P" <[EMAIL PROTECTED]> wrote: -snip- > I don't know that they use CPFORMAT to format the DASD before telling me > it's available. Should they? Yes, since that is what will make the volume available to z/OS. Just a note, but questions like this are far better addressed on the IBMVM mailing list. While there's a good amount of overlap in subscribers between that list and this one, there's still move VM expertise on IBMVM than here. 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: Zebra
Goodwin, Derric wrote: Anyone use zebra? We are trying to set it up on our z/guests for network redundancy and when trying to set the hello timer interval with Ip ospf hello-interval 3 We are getting Error occured during reading below line. hello-interval 3 Below are my conf files. Any ideas? Zebra.conf hostname quagga password quagga enable password quagga log file /var/log/quagga/quagga.log ospfd.conf hostname quagga password quagga enable password quagga log file /var/log/quagga/ospfd.log router ospf ospf router-id 10.120.40.214 ip ospf hello-interval 3 network 10.120.40.0/24 area 0 network 10.124.100.0/24 area 0 interface dummy0 interface eth0 Hello Derric, the "ip ospf hello-interval 3" is an interface command, as such it should follow the interface statement to which it should apply. e.g. interface eth0 ip ospf hello-interval 3 If you use SLES10 I would recommend using the quagga rpm from the SP2 DVD , its at 0.99.9 and has a lot of bugs fixed in it. mark -- 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: DFDSS Backups
Anyway. I found this excerpt from the DFSMSdss Storage Administration Guide, from the chapter on Linux Dump and Restore. The disk label, VOL1, indicates that a z/OS system can process this volume Mine all have VOL1 as their Disk Label. We have tried Full Volume Dumps as well, and they fail. We typically do the dasdfmt and take the default it gives us of two(2) for where to start. From: Linux on 390 Port on behalf of Stewart Thomas J Sent: Tue 6/24/2008 9:36 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: DFDSS Backups I struggled with this too. The full-pack disks for Linux write out a semi-standard VTOC that z/OS understands so it can see the various partitions as data sets that it can backup individually. If the minidisk starts anywhere other than cyl 0, Linux will put a VTOC there but it isn't in the right spot for z/OS to find it (not at cyl 0), so no data set names show up. Did you see this section in the DFSMS manual? That's where I eventually found some of this explanation when I was trying this out. http://tinyurl.com/6cj6rm We ended up just taking full volume dumps if needed and not trying to use the data set name. Although to make this easier we only give each Linux whole disks. This might have to change as disk sizes get larger. __ Tom Stewart Infrastructure Analyst John Deere - z/OS Support Services __ -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of LJ Mace Sent: Tuesday, June 24, 2008 7:54 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: DFDSS Backups I'll try to answer some of the question. > How does that name get generated on the Z/OS side? When the pack is backed-up the jcl has a specific pack ddname associated with it ie(DSN=PROD.BACKUP.FULLVOL.VMUS01(+1) and in your case LINUX.VLX1047.PART0001.NATIVE and this is more than likely a full volume backup. Also they are pointed to a specific vol ser in your case I'll guess the pack name is VLX1047 This is usually a gdg so after a certain number of backups older ones roll off Then next two questions I'll take a stab at: I going to assume the mini disks are only a portion of your 3390 so I'm going to guess that the mini disks are backed-up but on a different vol ser or it is a logical backup . This means that only a portion/certain dataset is pulled(backed-up) but I don't know how this could be unless your z/os guys are backing up certain cyl/trk numbers. We do full pack backups here. I hope this helps Mace --- On Tue, 6/24/08, Walters, Gene P <[EMAIL PROTECTED]> wrote: > From: Walters, Gene P <[EMAIL PROTECTED]> > Subject: DFDSS Backups > To: LINUX-390@VM.MARIST.EDU > Date: Tuesday, June 24, 2008, 8:01 AM > We use DFDSS to do preliminary full volume backups of Linux volumes. > In doing so, we have had a few problems backing up some of our mod-9's > that we setup as minidisks, as opposed to dedicated. For some reason, > some of our volumes will show a z/os dataset name such as > LINUX.VLX114B.PART0001.NATIVE, some do not show a z/os dataset name at > all. It is the one that do not show a z/os dataset name, that we have > problems backing up. When I do an fdasd with the P option on the > problem volumes, it looks like this: > > Cylinders . 10016 > Tracks per cylinder ... 15 > Blocks per track .. 12 > Bytes per block ... 4096 > Volume label .. VOL1 > Volume serial . LX1047 > Max partitions 3 > > -- tracks --- > Device start end lengthid system >/de/dasdc1 2 150239 150238 1 Linux > Native > > The S option shows me > Device .. /dev/dasdc > Volume label VOL1 > Volume serial ... LX1047 > > /dev/dasdc1 - LINUX.VLX1047.PART0001.NATIVE > > How does that name get generated on the Z/OS side? > Why does it get generated on the Z/OS side for dedicated dasd, but not > for mini-disks? > How can I get it on the Z/OS side for the mini-disks? > > Thanks > > -- > 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 -- For LINUX-390 subscribe / signoff / archive acc
Re: DFDSS Backups
Sorry for the delay in responding. My old PC was disposed of and I got a new one. I don't know that they use CPFORMAT to format the DASD before telling me it's available. Should they? Anyway. I found this excerpt from the DFSMSdss Storage Administration Guide, from the chapter on Linux Dump and Restore. The disk label, VOL1, indicates that a z/OS system can process this volume Mine all have VOL1 as their Disk Label, so I guess I'm still confused. From: Linux on 390 Port on behalf of Mark Post Sent: Tue 6/24/2008 9:37 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: DFDSS Backups >>> On Tue, Jun 24, 2008 at 8:01 AM, in message <[EMAIL PROTECTED]>, "Walters, Gene P" <[EMAIL PROTECTED]> wrote: > We use DFDSS to do preliminary full volume backups of Linux volumes. In > doing so, we have had a few problems backing up some of our mod-9's that > we setup as minidisks, as opposed to dedicated. For some reason, some > of our volumes will show a z/os dataset name such as > LINUX.VLX114B.PART0001.NATIVE, some do not show a z/os dataset name at > all. It is the one that do not show a z/os dataset name, that we have > problems backing up. -snip- > How does that name get generated on the Z/OS side? It is created by running the Linux dasdfmt and fdasd commands. > Why does it get generated on the Z/OS side for dedicated dasd, but not > for mini-disks? Because for mini-disks, the z/VM systems programmer does not allocate cylinder 0 to the Linux guest. So, when Linux writes the VTOC on what it thinks is cylinder 0, it is really writing it somewhere else. > How can I get it on the Z/OS side for the mini-disks? It should have been created by z/VM when it was CP formatted by the z/VM systems programmer. If it was not, they need to look at how they're initializing the volumes. 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 -- 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: Zebra
On Jun 24, 2008, at 1:14 PM, Goodwin, Derric wrote: Anyone use zebra? We are trying to set it up on our z/guests for network redundancy and when trying to set the hello timer interval with Zebra or Quagga? What version? Maybe you're just running something so old that it doesn't recognize the parameter? Does it work if you leave that line out? You might want to try it with ip ospf dead-interval minimal hello-multiplier 2 And see if that helps (that's a one-second dead-interval and 2 hellos per second, which *should* give you reliable subsecond convergence). The other thing to consider, though: this will ensure that your z/ Linux guests *never* go idle from the VM perspective, which is bad news for your ability to overcommit CPU and memory. Adam -- 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
Zebra
Anyone use zebra? We are trying to set it up on our z/guests for network redundancy and when trying to set the hello timer interval with Ip ospf hello-interval 3 We are getting Error occured during reading below line. hello-interval 3 Below are my conf files. Any ideas? Zebra.conf hostname quagga password quagga enable password quagga log file /var/log/quagga/quagga.log ospfd.conf hostname quagga password quagga enable password quagga log file /var/log/quagga/ospfd.log router ospf ospf router-id 10.120.40.214 ip ospf hello-interval 3 network 10.120.40.0/24 area 0 network 10.124.100.0/24 area 0 interface dummy0 interface eth0 --- Derric Goodwin Open Systems Engineering TransUnion, LLC 555 w. Adams, Chicago Il. 60661 (312)985-3312 -- 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: DFDSS Backups
>>> On Tue, Jun 24, 2008 at 8:01 AM, in message <[EMAIL PROTECTED]>, "Walters, Gene P" <[EMAIL PROTECTED]> wrote: > We use DFDSS to do preliminary full volume backups of Linux volumes. In > doing so, we have had a few problems backing up some of our mod-9's that > we setup as minidisks, as opposed to dedicated. For some reason, some > of our volumes will show a z/os dataset name such as > LINUX.VLX114B.PART0001.NATIVE, some do not show a z/os dataset name at > all. It is the one that do not show a z/os dataset name, that we have > problems backing up. -snip- > How does that name get generated on the Z/OS side? It is created by running the Linux dasdfmt and fdasd commands. > Why does it get generated on the Z/OS side for dedicated dasd, but not > for mini-disks? Because for mini-disks, the z/VM systems programmer does not allocate cylinder 0 to the Linux guest. So, when Linux writes the VTOC on what it thinks is cylinder 0, it is really writing it somewhere else. > How can I get it on the Z/OS side for the mini-disks? It should have been created by z/VM when it was CP formatted by the z/VM systems programmer. If it was not, they need to look at how they're initializing the volumes. 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: DFDSS Backups
I struggled with this too. The full-pack disks for Linux write out a semi-standard VTOC that z/OS understands so it can see the various partitions as data sets that it can backup individually. If the minidisk starts anywhere other than cyl 0, Linux will put a VTOC there but it isn't in the right spot for z/OS to find it (not at cyl 0), so no data set names show up. Did you see this section in the DFSMS manual? That's where I eventually found some of this explanation when I was trying this out. http://tinyurl.com/6cj6rm We ended up just taking full volume dumps if needed and not trying to use the data set name. Although to make this easier we only give each Linux whole disks. This might have to change as disk sizes get larger. __ Tom Stewart Infrastructure Analyst John Deere - z/OS Support Services __ -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of LJ Mace Sent: Tuesday, June 24, 2008 7:54 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: DFDSS Backups I'll try to answer some of the question. > How does that name get generated on the Z/OS side? When the pack is backed-up the jcl has a specific pack ddname associated with it ie(DSN=PROD.BACKUP.FULLVOL.VMUS01(+1) and in your case LINUX.VLX1047.PART0001.NATIVE and this is more than likely a full volume backup. Also they are pointed to a specific vol ser in your case I'll guess the pack name is VLX1047 This is usually a gdg so after a certain number of backups older ones roll off Then next two questions I'll take a stab at: I going to assume the mini disks are only a portion of your 3390 so I'm going to guess that the mini disks are backed-up but on a different vol ser or it is a logical backup . This means that only a portion/certain dataset is pulled(backed-up) but I don't know how this could be unless your z/os guys are backing up certain cyl/trk numbers. We do full pack backups here. I hope this helps Mace --- On Tue, 6/24/08, Walters, Gene P <[EMAIL PROTECTED]> wrote: > From: Walters, Gene P <[EMAIL PROTECTED]> > Subject: DFDSS Backups > To: LINUX-390@VM.MARIST.EDU > Date: Tuesday, June 24, 2008, 8:01 AM > We use DFDSS to do preliminary full volume backups of Linux volumes. > In doing so, we have had a few problems backing up some of our mod-9's > that we setup as minidisks, as opposed to dedicated. For some reason, > some of our volumes will show a z/os dataset name such as > LINUX.VLX114B.PART0001.NATIVE, some do not show a z/os dataset name at > all. It is the one that do not show a z/os dataset name, that we have > problems backing up. When I do an fdasd with the P option on the > problem volumes, it looks like this: > > Cylinders . 10016 > Tracks per cylinder ... 15 > Blocks per track .. 12 > Bytes per block ... 4096 > Volume label .. VOL1 > Volume serial . LX1047 > Max partitions 3 > > -- tracks --- > Device start end lengthid system >/de/dasdc1 2 150239 150238 1 Linux > Native > > The S option shows me > Device .. /dev/dasdc > Volume label VOL1 > Volume serial ... LX1047 > > /dev/dasdc1 - LINUX.VLX1047.PART0001.NATIVE > > How does that name get generated on the Z/OS side? > Why does it get generated on the Z/OS side for dedicated dasd, but not > for mini-disks? > How can I get it on the Z/OS side for the mini-disks? > > Thanks > > -- > 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: DFDSS Backups
I'll try to answer some of the question. > How does that name get generated on the Z/OS side? When the pack is backed-up the jcl has a specific pack ddname associated with it ie(DSN=PROD.BACKUP.FULLVOL.VMUS01(+1) and in your case LINUX.VLX1047.PART0001.NATIVE and this is more than likely a full volume backup. Also they are pointed to a specific vol ser in your case I'll guess the pack name is VLX1047 This is usually a gdg so after a certain number of backups older ones roll off Then next two questions I'll take a stab at: I going to assume the mini disks are only a portion of your 3390 so I'm going to guess that the mini disks are backed-up but on a different vol ser or it is a logical backup . This means that only a portion/certain dataset is pulled(backed-up) but I don't know how this could be unless your z/os guys are backing up certain cyl/trk numbers. We do full pack backups here. I hope this helps Mace --- On Tue, 6/24/08, Walters, Gene P <[EMAIL PROTECTED]> wrote: > From: Walters, Gene P <[EMAIL PROTECTED]> > Subject: DFDSS Backups > To: LINUX-390@VM.MARIST.EDU > Date: Tuesday, June 24, 2008, 8:01 AM > We use DFDSS to do preliminary full volume backups of Linux > volumes. In > doing so, we have had a few problems backing up some of our > mod-9's that > we setup as minidisks, as opposed to dedicated. For some > reason, some > of our volumes will show a z/os dataset name such as > LINUX.VLX114B.PART0001.NATIVE, some do not show a z/os > dataset name at > all. It is the one that do not show a z/os dataset name, > that we have > problems backing up. When I do an fdasd with the P option > on the > problem volumes, it looks like this: > > Cylinders . 10016 > Tracks per cylinder ... 15 > Blocks per track .. 12 > Bytes per block ... 4096 > Volume label .. VOL1 > Volume serial . LX1047 > Max partitions 3 > > -- tracks --- > Device start end lengthid system >/de/dasdc1 2 150239 150238 1 Linux > Native > > The S option shows me > Device .. /dev/dasdc > Volume label VOL1 > Volume serial ... LX1047 > > /dev/dasdc1 - LINUX.VLX1047.PART0001.NATIVE > > How does that name get generated on the Z/OS side? > Why does it get generated on the Z/OS side for dedicated > dasd, but not > for mini-disks? > How can I get it on the Z/OS side for the mini-disks? > > Thanks > > -- > 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
DFDSS Backups
We use DFDSS to do preliminary full volume backups of Linux volumes. In doing so, we have had a few problems backing up some of our mod-9's that we setup as minidisks, as opposed to dedicated. For some reason, some of our volumes will show a z/os dataset name such as LINUX.VLX114B.PART0001.NATIVE, some do not show a z/os dataset name at all. It is the one that do not show a z/os dataset name, that we have problems backing up. When I do an fdasd with the P option on the problem volumes, it looks like this: Cylinders . 10016 Tracks per cylinder ... 15 Blocks per track .. 12 Bytes per block ... 4096 Volume label .. VOL1 Volume serial . LX1047 Max partitions 3 -- tracks --- Device start end lengthid system /de/dasdc1 2 150239 150238 1 Linux Native The S option shows me Device .. /dev/dasdc Volume label VOL1 Volume serial ... LX1047 /dev/dasdc1 - LINUX.VLX1047.PART0001.NATIVE How does that name get generated on the Z/OS side? Why does it get generated on the Z/OS side for dedicated dasd, but not for mini-disks? How can I get it on the Z/OS side for the mini-disks? Thanks -- 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: question on s390-tools
LJ Mace wrote: I've downloaded the most recent tools package and have unzipped it. I looked through the readme file but didn't find the install instructions. I have gotten use to yast and also have done the rpm thing(thanks to Mark Post) but I am unsure with this product. What do I need to do to install this package After unzipping, changing into the s390tools subdirectory and typing a "make install" as root user should do the trick. so long, Carsten -- 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
