DUMP using mvsdasd

2006-12-01 Thread Sergey Korzhevsky
Hello Jacob. Is it possible to use your driver for dumping MVS disks, something like dd if=/dev/mvsdasdc of=/myfile and then restore them back with another dd command? Thank you. WBR, Sergey -- For LINUX-390 subscribe

Booting from mirrored DASD

2006-12-01 Thread Fuhrmann Anna
Hi list, We have RHEL4 installed in a z/os partition (no VM). This is what I would like to do: boot from a mirrored DASD as part of a catastrophe scenario when DASDs fail or crash or whatever. I have no idea how to accomplish this. zLinux does take the mirror-load-adress, but as the log

Re: Booting from mirrored DASD

2006-12-01 Thread Rob van der Heij
On 12/1/06, Fuhrmann Anna [EMAIL PROTECTED] wrote: This is what I would like to do: boot from a mirrored DASD as part of a catastrophe scenario when DASDs fail or crash or whatever. I have no idea how to accomplish this. zLinux does take the mirror-load-adress, but as the log messages and

AW: Booting from mirrored DASD

2006-12-01 Thread Fuhrmann Anna
Hi Rob, to be honest, I understand maybe half of what you tell me ... I mean I am awfully grateful for that half too ;-) - but I have questions: Look at options for the boot menu. You could create 2 entries in your boot menu, one where dasd= lists your primaries and one where it has your

Re: Booting from mirrored DASD

2006-12-01 Thread Rob van der Heij
On 12/1/06, Fuhrmann Anna [EMAIL PROTECTED] wrote: Boot menu - is where? I only know of a generic.ins file used when installing RHEL4. - and well, yes, I *am* pretty unexperienced. It's in your /etc/zipl.conf The way YaST generates it, there probably is no menu. The documentation is in the

Re: DUMP using mvsdasd

2006-12-01 Thread Jacob Dekel
Hi Sergey, Unfortunately, this is not possible yet. Mvsdasd is currently read-only, so even if 'myfile' could have been created (and it can not[1]), then you would not have been able to restore (write) the volume back in the same manner. Best wishes, Jacob.

2006-12-01 Recommended Linux on System z code manual drop to developerWorks

2006-12-01 Thread Gerhard Hiller
Please refer to: http://www.ibm.com/developerworks/linux/linux390/whatsnew.html for the 2006-12-01 change summary: April 2004 stream: Recommended kernel 2.6.5 patches: - Patch 41 with kernel bug fixes - Patch 42 with new functionality Updated documentation: - Device

AW: Booting from mirrored DASD

2006-12-01 Thread Fuhrmann Anna
Thank you Rob, this more verbose second answer seems to help me a lot. My zipl.conf looks like this: [defaultboot] default=2.6.9-42.0.3.EL target=/boot/ [2.6.9-42.0.3.EL] image=/boot/vmlinuz-2.6.9-42.0.3.EL ramdisk=/boot/initrd-2.6.9-42.0.3.EL.img

Re: Oracle install

2006-12-01 Thread McKown, John
-Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of O'Brien, Dennis L Sent: Thursday, November 30, 2006 4:35 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Oracle install John, Make those decisions (naming conventions, etc) yourself. There's

Re: Booting from mirrored DASD

2006-12-01 Thread Rob van der Heij
On 12/1/06, Fuhrmann Anna [EMAIL PROTECTED] wrote: Thank you Rob, this more verbose second answer seems to help me a lot. I often get obscure when I try to be brief :-) I would suggest to duplicate the section for your current kernel and ramdisk with a section title like

SNA via OSA - Best option?

2006-12-01 Thread Lee Stewart
Hi all... (Posted on both the Linux-390 and IBMVM lists.) I have a client who is putting up a SNA terminal server on Linux (tn3270 via TCP/IP to the terminal server which then connects it to VTAM via SNA out out the other side... The TCP/IP traffic in is easy via an existing vswitch. I'm

Re: SNA via OSA - Best option?

2006-12-01 Thread David Boyes
I have a client who is putting up a SNA terminal server on Linux (tn3270 via TCP/IP to the terminal server which then connects it to VTAM via SNA out out the other side... The TCP/IP traffic in is easy via an existing vswitch. Kind of an expensive solution to a problem with a much simpler

Re: SNA via OSA - Best option?

2006-12-01 Thread Tim Hare
Gotta ask - why aren't you going directly to the TN3270E server in z/OS Comm. Server? Seems like you're adding a Linux layer you don't really need. Tim Hare Senior Systems Programmer Florida Department of Transportation (850) 414-4209 David Boyes [EMAIL PROTECTED] Sent by: Linux on 390 Port

Re: Booting from mirrored DASD

2006-12-01 Thread Brad Hinson
You should duplicate the sections as Rob mentioned, but instead of adding multiple dasd=, you'll need to use multiple initrd images based on different values in modprobe.conf. For example, 1) edit /etc/modprobe.conf for the original dasd range: options dasd_mod dasd=xxx,xxx-xxx 2) generate an

Re: SNA via OSA - Best option?

2006-12-01 Thread Alan Altmark
On Friday, 12/01/2006 at 08:27 MST, Lee Stewart [EMAIL PROTECTED] wrote: - We could set up a new vswitch as layer 2, but is it worth it to set up a vswitch for one userid? IMO, no, unless you anticipate adding more CS Linux servers. - We could also dedicate an OSA attachment (just 3 unused

Re: Booting from mirrored DASD

2006-12-01 Thread John Summerfield
Fuhrmann Anna wrote: Hi list, We have RHEL4 installed in a z/os partition (no VM). This is what I would like to do: boot from a mirrored DASD as part of a catastrophe scenario when DASDs fail or crash or whatever. I have no idea how to accomplish this. zLinux does take the mirror-load-adress,

Re: Booting from mirrored DASD

2006-12-01 Thread John Summerfield
Rob van der Heij wrote: On 12/1/06, John Summerfield [EMAIL PROTECTED] wrote: It's only /boot that needs special attention, and the solution on IA32 boxes is basically to use dd to copy the boot partition. If ever disk0 fails, boot from Disk 1. I'm actually interested in such a

Best Practices for zSeries linux ISVs?

2006-12-01 Thread Kirk Wolf
We are preparing to release a new commercial application which will support zSeries linux distros, and are hoping to get some advice and/or suggestions for packaging the product for zSeries. Our current thinking is to make the following distribution formats available: 1) s390 (31 bit)

Re: Best Practices for zSeries linux ISVs?

2006-12-01 Thread Tom Shilson
I work for a large-ish company with a relatively small, but growing, Linux (Lintel and Lin-z) farm. Considering our range of skills, we should have an rpm that will install in hands-off, quiet mode. If it is binary or source it doesn't matter, just so it doesn't require thought or knowledge on

Re: Best Practices for zSeries linux ISVs?

2006-12-01 Thread David Boyes
Our current thinking is to make the following distribution formats available: 1) s390 (31 bit) architecture LSB 3.0 compatible RPM 2) s390x (64 bit) architecture LSB 3.0 compatible RPM 3) source rpm 4) source tarball Good! Thanks for allowing the tarballs. You should also test on Debian,

Re: Best Practices for zSeries linux ISVs?

2006-12-01 Thread Kris Van Hees
On Fri, Dec 01, 2006 at 08:53:49PM -0500, David Boyes wrote: Based on feedback, we can really decide to ship the package formats that users seem to want/need, but we would *really* like to keep the binary packages to a small number. We would like to be able to use a single zLinux image

Re: Best Practices for zSeries linux ISVs?

2006-12-01 Thread David Boyes
We would like to be able to use a single zLinux image to build binary packages. While you *could* do that, I think you'll find that you'll need at least one RH and one SuSE guest, and you'll need to build the packages independently on both. There are still some small and subtle