Re: error bringing up cloned system
I ran into this problem as well. I went back and re-installed my master image. When I got to the partitioning step, I changed the FSTAB options for dev/dasdx to use device-name instead of device-id. I'm not sure what one selection has over the other but it sure makes cloning a lot easier. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, February 28, 2008 5:49 PM To: IBMVM@LISTSERV.UARK.EDU Subject: error bringing up cloned system Does anyone know what I did wrong here. DDR'd new SLES10 -sp1 system and now receive the following IPL errors.. After the DDR I correctly relabel the pack to reflect its real addr as usual, define the pack to another guest machine and modify the mdisk to match the original. This time it does not work. I took the SLES defaults for installation for storage Device names. If I knew if this info was in a Yast log I could try to find it, if it would help. Waiting for udev to settle... Scanning for LVM volume groups... Reading all physical volumes. This may take a while... Found volume group system using metadata type lvm2 Activating LVM volume groups... 1 logical volume(s) in volume group system now active ..done Waiting for /dev/disk/by-id/ccw-IBM.7500029217.2500.2e-part1 . no more events Checking file systems... fsck 1.38 (30-Jun-2005) Checking all file systems. error on stat() /dev/disk/by-id/ccw-IBM.7500029217.2500.2e-part1: No such f [/sbin/fsck.ext3 (1) -- /boot] fsck.ext3 -a /dev/disk/by-id/ccw-IBM.7500029 error on stat() /dev/disk/by-id/ccw-IBM.7500029217.2500.2e-part1: No such f fsck.ext3: No such file or directory while trying to open /dev/disk/by-id/ccw-I /dev/disk/by-id/ccw-IBM.7500029217.2500.2e-part1: /dev/disk/by-id/ccw-IBM.7500029217.2500.2e-part1: The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 device fsck.ext3 /dev/disk/by-id/ccw-IBM.7500029217.2500.2e-part1 failed (status 0 [1A..failedblogd: no message logging because /var file system is not accessible fsck failed for at least one filesystem (not /).
Re: error bringing up cloned system
I ran into this same problem. The /dev/disk/by-id name for the disk was different on the cloned system from the master image on some (not all) of the clones. I didn't find the source of the difference, but I did switch to /dev/disk/by-path/ccd-0X0391-part1 instead of using the by-id name that the system had chosen on its own. I have no idea what generates the by-id names. Ours look like ccw-IBM.75000CYCY1.c700.2d, and on several of the clones, the c700 portion changed to something else. The by-path names remain consistent from system to system, and would seem to me to be a better choice, if your virtual CCUU addresses will remain the same. Hope this helps. -- Robert P. Nix Mayo Foundation.~. RO-OE-5-55 200 First Street SW/V\ 507-284-0844 Rochester, MN 55905 /( )\ -^^-^^ In theory, theory and practice are the same, but in practice, theory and practice are different. On 2/28/08 4:48 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Does anyone know what I did wrong here. DDR'd new SLES10 -sp1 system and now receive the following IPL errors.. After the DDR I correctly relabel the pack to reflect its real addr as usual, define the pack to another guest machine and modify the mdisk to match the original. This time it does not work. I took the SLES defaults for installation for storage Device names. If I knew if this info was in a Yast log I could try to find it, if it would help. Waiting for udev to settle... Scanning for LVM volume groups... Reading all physical volumes. This may take a while... Found volume group system using metadata type lvm2 Activating LVM volume groups... 1 logical volume(s) in volume group system now active ..done Waiting for /dev/disk/by-id/ccw-IBM.7500029217.2500.2e-part1 . no more events Checking file systems... fsck 1.38 (30-Jun-2005) Checking all file systems. error on stat() /dev/disk/by-id/ccw-IBM.7500029217.2500.2e-part1: No such f [/sbin/fsck.ext3 (1) -- /boot] fsck.ext3 -a /dev/disk/by-id/ccw-IBM.7500029 error on stat() /dev/disk/by-id/ccw-IBM.7500029217.2500.2e-part1: No such f fsck.ext3: No such file or directory while trying to open /dev/disk/by-id/ccw-I /dev/disk/by-id/ccw-IBM.7500029217.2500.2e-part1: /dev/disk/by-id/ccw-IBM.7500029217.2500.2e-part1: The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 device fsck.ext3 /dev/disk/by-id/ccw-IBM.7500029217.2500.2e-part1 failed (status 0 [1A..failedblogd: no message logging because /var file system is not accessible fsck failed for at least one filesystem (not /).
Re: error bringing up cloned system
Zipl.conf is probably fine. Change fstab, not necessarily to /dev/dasda1, but to the /dev/disk/by-path for the CCUU of dasda1, so that, should its order in the list of disks ever change and it were to become, say, /dev/dasdb1 instead, you'll still find it correctly. That's the whole point of the /dev/disk/by- stuff. -- Robert P. Nix Mayo Foundation.~. RO-OE-5-55 200 First Street SW/V\ 507-284-0844 Rochester, MN 55905 /( )\ -^^-^^ In theory, theory and practice are the same, but in practice, theory and practice are different. On 2/29/08 8:40 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Before I trash my system.: ( ..I found the line to change in fstab; from (/dev/disk/by-id...) to (/dev/dasda1/boot ext3 ...) but what to change in zipl.conf? Thanks. zipl.conf # Modified by YaST2. Last modification on Wed Feb 27 17:32:34 EST 2008 [defaultboot] defaultmenu = menu [SLES_10_SP1] image = /boot/image-2.6.16.54-0.2.5-default target = /boot/zipl ramdisk = /boot/initrd-2.6.16.54-0.2.5-default,0x100 parameters = root=/dev/system/lv1 TERM=dumb :menu default = 1 prompt = 1 target = /boot/zipl timeout = 10 1 = SLES_10_SP1 2 = ipl ###Don't change this comment - YaST2 identifier: Original name: ipl### [ipl] image = /boot/image target = /boot/zipl ramdisk = /boot/initrd,0x100 parameters = root=/dev/system/lv1 TERM=dumb Adam Thornton [EMAIL PROTECTED] mine.net To Sent by: The IBM IBMVM@LISTSERV.UARK.EDU z/VM Operating cc System [EMAIL PROTECTED] Subject ARK.EDU Re: error bringing up cloned system 02/28/2008 06:10 PM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU On Feb 28, 2008, at 4:48 PM, [EMAIL PROTECTED] wrote: Does anyone know what I did wrong here. DDR'd new SLES10 -sp1 system and now receive the following IPL errors.. After the DDR I correctly relabel the pack to reflect its real addr as usual, define the pack to another guest machine and modify the mdisk to match the original. This time it does not work. I took the SLES defaults for installation for storage Device names. If I knew if this info was in a Yast log I could try to find it, if it would help. SLES10, stupidy, chooses its filesystems by disk-ID. This is no good if you want to clone, because you will end up with different real underlying IDs on your disk. Waiting for /dev/disk/by-id/ccw-IBM.7500029217.2500.2e-part1 Convert the basic system to use a different scheme that IS OK to use across different disks (I like to use by-path, as I tend to use the same device address conventions on all guests), change zipl.conf and / etc/fstab to reflect that scheme, rerun zipl/mkinitrd, and then clone the resulting system. Adam
Re: something with tn3270 and ssl
Specifying 'HOLD' fixed the problem.. maybe not 'fixed' but at least it works the way I think it should. Thanks Jeff -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Jeff Gribbin, EDS Sent: Friday, February 29, 2008 1:10 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: something with tn3270 and ssl If you specify the HOLD option on your LOGOFF / DISC command: LOGOFF HOLD -- or -- DISC HOLD do the symptoms change at all? To quote from the HELP ... HOld causes the non-SNA TTY display terminal telecommunication connection to remain in effect after your session is disconnected. If you specify the HOLD option from a logical device, you disconnect from the logical device without losing the connection between the logical device and the system.
SFSTAR Package
Anybody got this working on a 5.3 system? The package seems like juyst what I need to do some movement of partial SFS structures, but it does not seem to work consistantly. I have gotten the RXFLOW, TEXTFLOW, REXXCSL, SUPERSAY and PIPEFILE packages. But it still seems to not want to work. Brian
Re: New Forum Available for Discussing IBM's Operations Manager for z/VM
Personally, I had rather see us move off the list processing and move to a forum type thing, but that takes more resources. The main resource it takes, IMO, is my time and effort. A list arrives, all by itself, in my email. A forum is something I have to go to on the web. My experience has shown me that those lists I used to subscribe to which did go over to being fora, I dropped out of. I would only remember every third day, and then less often Shimon
Re: something with tn3270 and ssl
On Thursday, 02/28/2008 at 03:27 EST, Huegel, Thomas [EMAIL PROTECTED] wrote: If it is a SSL secured port that I telnet to, when I logoff I get this: CONNECT= 29:49:25 VIRTCPU= 000:00.69 TOTCPU= 000:00.78 LOGOFF AT 14:21:54 CST THURSDAY 02/28/08 Press enter or clear key to continue But ANY key I hit just locks the keyboard. I have to close the session and start a new one. The same is true for DISCONNECT and UNDIAL.. Is that how it is supposed to work? If you can get an emulator or wireshark trace, you'll see what's happening. It's acting kind of like a close() didn't make it all the way through. With trace in hand that shows a malfing telnet or SSL server, please open a PMR. Alan Altmark z/VM Development IBM Endicott
Re: SFSTAR Package
Hi, Brian. What's the error you're getting? Maybe we can locate the problem and fix it. Brian Ferguson wrote: Anybody got this working on a 5.3 system? The package seems like juyst what I need to do some movement of partial SFS structures, but it does not seem to work consistantly. I have gotten the RXFLOW, TEXTFLOW, REXXCSL, SUPERSAY and PIPEFILE packages. But it still seems to not want to work. Brian -- DJ V/Soft z/VM and mainframe Linux expertise, training, consulting, and software development www.vsoft-software.com
Re: error bringing up cloned system
Before I trash my system.: ( ..I found the line to change in fstab; from (/dev/disk/by-id...) to (/dev/dasda1/boot ext3 ...) but what to change in zipl.conf? Thanks. zipl.conf # Modified by YaST2. Last modification on Wed Feb 27 17:32:34 EST 2008 [defaultboot] defaultmenu = menu [SLES_10_SP1] image = /boot/image-2.6.16.54-0.2.5-default target = /boot/zipl ramdisk = /boot/initrd-2.6.16.54-0.2.5-default,0x100 parameters = root=/dev/system/lv1 TERM=dumb :menu default = 1 prompt = 1 target = /boot/zipl timeout = 10 1 = SLES_10_SP1 2 = ipl ###Don't change this comment - YaST2 identifier: Original name: ipl### [ipl] image = /boot/image target = /boot/zipl ramdisk = /boot/initrd,0x100 parameters = root=/dev/system/lv1 TERM=dumb Adam Thornton [EMAIL PROTECTED] mine.net To Sent by: The IBM IBMVM@LISTSERV.UARK.EDU z/VM Operating cc System [EMAIL PROTECTED] Subject ARK.EDU Re: error bringing up cloned system 02/28/2008 06:10 PM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU On Feb 28, 2008, at 4:48 PM, [EMAIL PROTECTED] wrote: Does anyone know what I did wrong here. DDR'd new SLES10 -sp1 system and now receive the following IPL errors.. After the DDR I correctly relabel the pack to reflect its real addr as usual, define the pack to another guest machine and modify the mdisk to match the original. This time it does not work. I took the SLES defaults for installation for storage Device names. If I knew if this info was in a Yast log I could try to find it, if it would help. SLES10, stupidy, chooses its filesystems by disk-ID. This is no good if you want to clone, because you will end up with different real underlying IDs on your disk. Waiting for /dev/disk/by-id/ccw-IBM.7500029217.2500.2e-part1 Convert the basic system to use a different scheme that IS OK to use across different disks (I like to use by-path, as I tend to use the same device address conventions on all guests), change zipl.conf and / etc/fstab to reflect that scheme, rerun zipl/mkinitrd, and then clone the resulting system. Adam
Re: SFSTAR Package
I had something to SENDFILE my SFS files to another VM system. It were two REXX execs. I can dig that up if you like. 2008/2/29, Brian Ferguson [EMAIL PROTECTED]: Anybody got this working on a 5.3 system? The package seems like juyst what I need to do some movement of partial SFS structures, but it does not seem to work consistantly. I have gotten the RXFLOW, TEXTFLOW, REXXCSL, SUPERSAY and PIPEFILE packages. But it still seems to not want to work. Brian -- Kris Buelens, IBM Belgium, VM customer support
Re: SFSTAR Package
I needed to provide a way for one of our users to recreate an SFS tree in a series of PDSs in MVS. It was a snap to write a VMFTP macro to FTP elements of a subdirectory to members of a PDS having the same name as the subdirectory. The macro is only 129 lines long, with 55 of them being comments or white space. I could probably dig it up and send it if it would suffice. It should be easy enough to adapt it to handle SFS-to-SFS transfers. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Kris Buelens Sent: Friday, February 29, 2008 8:09 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SFSTAR Package I had something to SENDFILE my SFS files to another VM system. It were two REXX execs. I can dig that up if you like. 2008/2/29, Brian Ferguson [EMAIL PROTECTED]: Anybody got this working on a 5.3 system? The package seems like juyst what I need to do some movement of partial SFS structures, but it does not seem to work consistantly. I have gotten the RXFLOW, TEXTFLOW, REXXCSL, SUPERSAY and PIPEFILE packages. But it still seems to not want to work. Brian -- Kris Buelens, IBM Belgium, VM customer support
Re: FTP x86 to SFS
Could it be that SFS considers this one unit of work and is not closing the files until the complete FTP ends? -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Friday, February 29, 2008 12:07 PM To: IBMVM@LISTSERV.UARK.EDU Subject: FTP x86 to SFS I have a process that FTPs two files from a WinXP machine to an SFS directory. The sequence of events is 1. A small file, 10-15 short (80 bytes, each) records is created on the pc. 2. Immediately thereafter, an FTP is started by the script that created the small file. It contains two PUTs, one after the other. The first sends the newly created small file; the second sends a file of nearly 10,000 records ranging in size from 150 to 800 bytes. I have noticed that sometimes, infrequently, the large file arrives first. This transfer is done over an internal network. Tracert from the pc to VM always shows the same 7 hops; from VM to the pc, the same in reverse order. Is there anything that explains this as normal behavior? Or has Chuckie struck? I would love to do the transfer with a virtual machine as the client, but the large file is inaccessible from any pc on the network that is running an approved FTP server. Unapproved FTP servers are frowned upon by Infosec, and thus, by management. Regards, Richard Schuh This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing.
Re: error bringing up cloned system
Novell's sles 10 sp1 release notes actually give a mangled attempt to alert one to this z/VM mdisk issue. When they ran the original text thru the translator to English it must have substituted 'disk' for the non-dictionary 'mdisk' words in these sentences: Using Disks in z/VM If SLES 10 is installed on disks in z/VM, which reside on the same physical disk, the created access path (/dev/disk/by-id/) is not unique. The ID of a disk is the ID of the underlaying disk. So if two or more disk are on the same physical disk, they all have the same ID. To avoid this ambiguity, please use the access path by-path. This can be specified during the installation when the mount points are definied. To change from by-id to by-path please perform the following steps: Modify /etc/zipl.conf to use by-path names, example: parameters = root=/dev/disk/by-path/ccw-0.0.0201-part1 TERM=dumb Have the boot configuration pick up the changes: mkinitrd zipl -V Change all by-id entries in /etc/fstab to by-path entries as well, example: /dev/disk/by-path/ccw-0.0.0201-part1 / ext3 acl,user_xattr 1 1 reboot to pick up changes 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: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Hilliard, Chris Sent: Friday, February 29, 2008 8:14 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: error bringing up cloned system I ran into this problem as well. I went back and re-installed my master image. When I got to the partitioning step, I changed the FSTAB options for dev/dasdx to use device-name instead of device-id. I'm not sure what one selection has over the other but it sure makes cloning a lot easier. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, February 28, 2008 5:49 PM To: IBMVM@LISTSERV.UARK.EDU Subject: error bringing up cloned system Does anyone know what I did wrong here. DDR'd new SLES10 -sp1 system and now receive the following IPL errors.. After the DDR I correctly relabel the pack to reflect its real addr as usual, define the pack to another guest machine and modify the mdisk to match the original. This time it does not work. I took the SLES defaults for installation for storage Device names. If I knew if this info was in a Yast log I could try to find it, if it would help. Waiting for udev to settle... Scanning for LVM volume groups... Reading all physical volumes. This may take a while... Found volume group system using metadata type lvm2 Activating LVM volume groups... 1 logical volume(s) in volume group system now active ..done Waiting for /dev/disk/by-id/ccw-IBM.7500029217.2500.2e-part1 . no more events Checking file systems... fsck 1.38 (30-Jun-2005) Checking all file systems. error on stat() /dev/disk/by-id/ccw-IBM.7500029217.2500.2e-part1: No such f [/sbin/fsck.ext3 (1) -- /boot] fsck.ext3 -a /dev/disk/by-id/ccw-IBM.7500029 error on stat() /dev/disk/by-id/ccw-IBM.7500029217.2500.2e-part1: No such f fsck.ext3: No such file or directory while trying to open /dev/disk/by-id/ccw-I /dev/disk/by-id/ccw-IBM.7500029217.2500.2e-part1: /dev/disk/by-id/ccw-IBM.7500029217.2500.2e-part1: The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 device fsck.ext3 /dev/disk/by-id/ccw-IBM.7500029217.2500.2e-part1 failed (status 0 [1A..failedblogd: no message logging because /var file system is not accessible fsck failed for at least one filesystem (not /).
FTP x86 to SFS
I have a process that FTPs two files from a WinXP machine to an SFS directory. The sequence of events is 1. A small file, 10-15 short (80 bytes, each) records is created on the pc. 2. Immediately thereafter, an FTP is started by the script that created the small file. It contains two PUTs, one after the other. The first sends the newly created small file; the second sends a file of nearly 10,000 records ranging in size from 150 to 800 bytes. I have noticed that sometimes, infrequently, the large file arrives first. This transfer is done over an internal network. Tracert from the pc to VM always shows the same 7 hops; from VM to the pc, the same in reverse order. Is there anything that explains this as normal behavior? Or has Chuckie struck? I would love to do the transfer with a virtual machine as the client, but the large file is inaccessible from any pc on the network that is running an approved FTP server. Unapproved FTP servers are frowned upon by Infosec, and thus, by management. Regards, Richard Schuh
Re: FTP x86 to SFS
I have a WS_FTP Pro where I select two files at one time and FTP them to a z/VM account. I can see from the progress bar that both files are being sent at the same time. This is in passive mode. /Fran Hensler at Slippery Rock University of Pennsylvania USA for 44 years [EMAIL PROTECTED] +1.724.738.2153 Yes, Virginia, there is a Slippery Rock On Fri, 29 Feb 2008 09:07:17 -0800 Schuh, Richard said: I have a process that FTPs two files from a WinXP machine to an SFS directory. The sequence of events is 1. A small file, 10-15 short (80 bytes, each) records is created on the pc. 2. Immediately thereafter, an FTP is started by the script that created the small file. It contains two PUTs, one after the other. The first sends the newly created small file; the second sends a file of nearly 10,000 records ranging in size from 150 to 800 bytes. I have noticed that sometimes, infrequently, the large file arrives first. This transfer is done over an internal network. Tracert from the pc to VM always shows the same 7 hops; from VM to the pc, the same in reverse order. Is there anything that explains this as normal behavior? Or has Chuckie struck? I would love to do the transfer with a virtual machine as the client, but the large file is inaccessible from any pc on the network that is running an approved FTP server. Unapproved FTP servers are frowned upon by Infosec, and thus, by management. Regards, Richard Schuh
Re: something with tn3270 and ssl
Hello Thomas, Interesting. Do you have a connect button on the menu bar? What happens when you press the connect? I agree with Alan, it is as if the close did not finish all the way. Ed Martin 330-588-4723 ext 40441 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas Sent: Thursday, February 28, 2008 4:00 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: something with tn3270 and ssl Everything is the same except for the port number, and a checkmark in the SSL box. The session doesn't appear to disconnect after the LOGOFF.. It just sits. I'm using the Debian SSLSERV I got from Sine Nomine, if that matters.
Re: error bringing up cloned system
Managled is understated. If it said partitions instead of disks it might make more sense to me. But in my case, I have only one volume/dasd/disk with 1 boot partition and 1 logical volume partition. So when you bring a cloned volume/dasd/disk online he must compare the NEW real addr to the by-id label. But, if use by-path he doesn't? Sorry still a little confused about this. What is wrong with old naming conventions? Romanowski, John (OFT) John.Romanowski@ To oft.state.ny.us IBMVM@LISTSERV.UARK.EDU Sent by: The IBM cc z/VM Operating SystemSubject [EMAIL PROTECTED] Re: error bringing up cloned system ARK.EDU 02/29/2008 11:53 AM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU Novell's sles 10 sp1 release notes actually give a mangled attempt to alert one to this z/VM mdisk issue. When they ran the original text thru the translator to English it must have substituted 'disk' for the non-dictionary 'mdisk' words in these sentences: Using Disks in z/VM If SLES 10 is installed on disks in z/VM, which reside on the same physical disk, the created access path (/dev/disk/by-id/) is not unique. The ID of a disk is the ID of the underlaying disk. So if two or more disk are on the same physical disk, they all have the same ID. To avoid this ambiguity, please use the access path by-path. This can be specified during the installation when the mount points are definied. To change from by-id to by-path please perform the following steps: Modify /etc/zipl.conf to use by-path names, example: parameters = root=/dev/disk/by-path/ccw-0.0.0201-part1 TERM=dumb Have the boot configuration pick up the changes: mkinitrd zipl -V Change all by-id entries in /etc/fstab to by-path entries as well, example: /dev/disk/by-path/ccw-0.0.0201-part1 / ext3 acl,user_xattr 1 1 reboot to pick up changes 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: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Hilliard, Chris Sent: Friday, February 29, 2008 8:14 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: error bringing up cloned system I ran into this problem as well. I went back and re-installed my master image. When I got to the partitioning step, I changed the FSTAB options for dev/dasdx to use device-name instead of device-id. I'm not sure what one selection has over the other but it sure makes cloning a lot easier. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, February 28, 2008 5:49 PM To: IBMVM@LISTSERV.UARK.EDU Subject: error bringing up cloned system Does anyone know what I did wrong here. DDR'd new SLES10 -sp1 system and now receive the following IPL errors.. After the DDR I correctly relabel the pack to reflect its real addr as usual, define the pack to another guest machine and modify the mdisk to match the original. This time it does not work. I took the SLES defaults for installation for storage Device names. If I knew if this info was in a Yast log I could try to find it, if it would help. Waiting for udev to
Re: something with tn3270 and ssl
After the logoff in the operator information area it says 'connected', and the keyboard will lock if I hit any key. When I click the connect/disconnect button the screen clears and the OIA changes to 'disconnected'. Clicking the connect button again will cause a reconnect and the z/VM logo screen. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Edward M. Martin Sent: Friday, February 29, 2008 12:32 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: something with tn3270 and ssl Hello Thomas, Interesting. Do you have a connect button on the menu bar? What happens when you press the connect? I agree with Alan, it is as if the close did not finish all the way. Ed Martin 330-588-4723 ext 40441 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas Sent: Thursday, February 28, 2008 4:00 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: something with tn3270 and ssl Everything is the same except for the port number, and a checkmark in the SSL box. The session doesn't appear to disconnect after the LOGOFF.. It just sits. I'm using the Debian SSLSERV I got from Sine Nomine, if that matters.
Re: error bringing up cloned system
I see your point, I was think of the other case where the filesystem is on a mdisk and cloned copy's mdisk is on another pack. I think each z/vm dasd pack has a unique hardware id; your cloned copy's pack has an id different from its parent's id; if /etc/fstab isn't adjusted after cloning to mount the copy's by-id value then the server has trouble booting when it tries to mount using the parent's by-id/ value. If by old naming conventions you mean /dev/dasda,b,c,.. they're not persistent/consistent device names unless you can guarantee the same set of disk addresses come online in the same order. I'm not knocking 'em; I use 'em. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, February 29, 2008 1:33 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: error bringing up cloned system Managled is understated. If it said partitions instead of disks it might make more sense to me. But in my case, I have only one volume/dasd/disk with 1 boot partition and 1 logical volume partition. So when you bring a cloned volume/dasd/disk online he must compare the NEW real addr to the by-id label. But, if use by-path he doesn't? Sorry still a little confused about this. What is wrong with old naming conventions? Romanowski, John (OFT) John.Romanowski@ To oft.state.ny.us IBMVM@LISTSERV.UARK.EDU Sent by: The IBM cc z/VM Operating System Subject [EMAIL PROTECTED] Re: error bringing up cloned system ARK.EDU 02/29/2008 11:53 AM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU Novell's sles 10 sp1 release notes actually give a mangled attempt to alert one to this z/VM mdisk issue. When they ran the original text thru the translator to English it must have substituted 'disk' for the non-dictionary 'mdisk' words in these sentences: Using Disks in z/VM If SLES 10 is installed on disks in z/VM, which reside on the same physical disk, the created access path (/dev/disk/by-id/) is not unique. The ID of a disk is the ID of the underlaying disk. So if two or more disk are on the same physical disk, they all have the same ID. To avoid this ambiguity, please use the access path by-path. This can be specified during the installation when the mount points are definied. To change from by-id to by-path please perform the following steps: Modify /etc/zipl.conf to use by-path names, example: parameters = root=/dev/disk/by-path/ccw-0.0.0201-part1 TERM=dumb Have the boot configuration pick up the changes: mkinitrd zipl -V Change all by-id entries in /etc/fstab to by-path entries as well, example: /dev/disk/by-path/ccw-0.0.0201-part1 / ext3 acl,user_xattr 1 1 reboot to pick up changes 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: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Hilliard, Chris Sent: Friday, February 29, 2008 8:14 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: error bringing up cloned system I ran into this problem as well. I went back and re-installed my master image. When I got to the partitioning step, I changed the FSTAB options for dev/dasdx to use device-name instead of device-id. I'm not sure what one selection has over the other but it sure makes cloning a lot easier. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, February 28, 2008 5:49 PM To: IBMVM@LISTSERV.UARK.EDU Subject: error bringing up cloned system Does anyone know what I did wrong here. DDR'd new SLES10 -sp1 system and now receive the following IPL errors.. After the DDR I correctly relabel the pack to reflect its real addr as usual, define the pack to another guest machine and modify the mdisk to match the original. This time it does not work. I took the SLES defaults for installation for storage Device names. If I knew if this info was in a Yast log I could try to find it, if it would help. Waiting for udev to settle... Scanning for LVM volume groups... Reading all physical volumes. This may take a while... Found volume group system using metadata type lvm2 Activating LVM volume groups... 1 logical volume(s) in volume group system now active ..done Waiting for /dev/disk/by-id/ccw-IBM.7500029217.2500.2e-part1
Re: something with tn3270 and ssl
One option is to use logoff hold instead of logoff. The hold option keeps the connection up, and typically you get a new session as soon as you hit enter. This works on both encrypted and unencrypted tn3270 and even line mode telnet, and is much faster than the reconnect option in most terminal emulators. Victor Victor Strasser [EMAIL PROTECTED] VM and Linux Support Unit California Department of Technology Services Phone: 916-464-4522 From: Huegel, Thomas [mailto:[EMAIL PROTECTED] Sent: Thursday, February 28, 2008 12:26 PM Subject: something with tn3270 and ssl I have a little question that has been on my mind for a while. I have tried this with several tn3270 emumaters and the result is the same. When I telnet to a standard non-secured port, and later logoff my session returns to the VM LOGO sign-on screen. BUT If it is a SSL secured port that I telnet to, when I logoff I get this: CONNECT= 29:49:25 VIRTCPU= 000:00.69 TOTCPU= 000:00.78 LOGOFF AT 14:21:54 CST THURSDAY 02/28/08 Press enter or clear key to continue But ANY key I hit just locks the keyboard. I have to close the session and start a new one. The same is true for DISCONNECT and UNDIAL.. Is that how it is supposed to work?
Re: Nomad and CMS mdisk restrictions
Would SFS work? Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Phil Tully Sent: Friday, February 29, 2008 11:56 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Nomad and CMS mdisk restrictions Hello List, I received a question on how to expand a Nomad database beyond a the CMS limitation of 32k cylinders mdisk. Is there a facility in Nomad to use multiple mdisks for the same db? regards Phil Tully -- 'in media stat virtus' Virtue's in the middle
Nomad and CMS mdisk restrictions
Hello List, I received a question on how to expand a Nomad database beyond a the CMS limitation of 32k cylinders mdisk. Is there a facility in Nomad to use multiple mdisks for the same db? regards Phil Tully -- 'in media stat virtus' Virtue's in the middle
Re: FTP x86 to SFS
Is it using consecutive puts, or does it have some way to do them concurrently? In my case, it is being done via a Perl script that uses consecutive put commands. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Fran Hensler Sent: Friday, February 29, 2008 10:02 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: FTP x86 to SFS I have a WS_FTP Pro where I select two files at one time and FTP them to a z/VM account. I can see from the progress bar that both files are being sent at the same time. This is in passive mode. /Fran Hensler at Slippery Rock University of Pennsylvania USA for 44 years [EMAIL PROTECTED] +1.724.738.2153 Yes, Virginia, there is a Slippery Rock On Fri, 29 Feb 2008 09:07:17 -0800 Schuh, Richard said: I have a process that FTPs two files from a WinXP machine to an SFS directory. The sequence of events is 1. A small file, 10-15 short (80 bytes, each) records is created on the pc. 2. Immediately thereafter, an FTP is started by the script that created the small file. It contains two PUTs, one after the other. The first sends the newly created small file; the second sends a file of nearly 10,000 records ranging in size from 150 to 800 bytes. I have noticed that sometimes, infrequently, the large file arrives first. This transfer is done over an internal network. Tracert from the pc to VM always shows the same 7 hops; from VM to the pc, the same in reverse order. Is there anything that explains this as normal behavior? Or has Chuckie struck? I would love to do the transfer with a virtual machine as the client, but the large file is inaccessible from any pc on the network that is running an approved FTP server. Unapproved FTP servers are frowned upon by Infosec, and thus, by management. Regards, Richard Schuh
Re: something with tn3270 and ssl
Hello Thomas, It would seem that the LOGOFF from the SSL server, is not completely disconnecting. I would if there is some parameter on the SERVER side that needs to be adjusted. Thanks for info. Ed Martin 330-588-4723 ext 40441 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas Sent: Friday, February 29, 2008 1:59 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: something with tn3270 and ssl After the logoff in the operator information area it says 'connected', and the keyboard will lock if I hit any key. When I click the connect/disconnect button the screen clears and the OIA changes to 'disconnected'. Clicking the connect button again will cause a reconnect and the z/VM logo screen.
Re: error bringing up cloned system
The problem all this is trying to get around is that, if you define a system that brings up, say, minidisks at 391, 392 and 393, they become /dev/dasda, dasdb and dasdc. Now you add a new minidisk at 291 If the system puts this at the end of the list, then it would become /dev/dasdd, and this would happen when you add the disk into the running system. But, what if, when you re-boot the entire image, it now finds this disk first? It could become /dev/dasda, pushing the other disks each up one letter, and causing your fstab and other things to fail miserably. But, minidisk 391 is (or at least, should be) always 391, no matter if it is /dev/dasda or /dev/dasdb. Which ever it is, you know you want it to be your root filesystem (or your /boot, or whatever). You don't care a smidge about the letter it lives at. This is where /dev/disk/by-path comes in. You can use this to identify the disk by its CUU address in the virtual machine. Suddenly, you're immune to new disks added at random addresses. The /dev/disk/by-id would be used for the wild and insane among us, that want to change around the minidisk addresses randomly between boots. There's also by-uuid... I think this one is looking at some internal field in the disk's label, but I've no research to back up that statement. Note that if you use LVM for the majority of your system, then this whole issue is only relevant for the /boot disk (and possibly the root filesystem; depends on whose rules you follow). LVM uses the disk's uuid to locate the physical volumes that make up a volume group, and sets everything up accordingly. -- Robert P. Nix Mayo Foundation.~. RO-OE-5-55 200 First Street SW/V\ 507-284-0844 Rochester, MN 55905 /( )\ -^^-^^ In theory, theory and practice are the same, but in practice, theory and practice are different. On 2/29/08 12:33 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Managled is understated. If it said partitions instead of disks it might make more sense to me. But in my case, I have only one volume/dasd/disk with 1 boot partition and 1 logical volume partition. So when you bring a cloned volume/dasd/disk online he must compare the NEW real addr to the by-id label. But, if use by-path he doesn't? Sorry still a little confused about this. What is wrong with old naming conventions? Romanowski, John (OFT) John.Romanowski@ To oft.state.ny.us IBMVM@LISTSERV.UARK.EDU Sent by: The IBM cc z/VM Operating SystemSubject [EMAIL PROTECTED] Re: error bringing up cloned system ARK.EDU 02/29/2008 11:53 AM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU Novell's sles 10 sp1 release notes actually give a mangled attempt to alert one to this z/VM mdisk issue. When they ran the original text thru the translator to English it must have substituted 'disk' for the non-dictionary 'mdisk' words in these sentences: Using Disks in z/VM If SLES 10 is installed on disks in z/VM, which reside on the same physical disk, the created access path (/dev/disk/by-id/) is not unique. The ID of a disk is the ID of the underlaying disk. So if two or more disk are on the same physical disk, they all have the same ID. To avoid this ambiguity, please use the access path by-path. This can be specified during the installation when the mount points are definied. To change from by-id to by-path please perform the following steps: Modify /etc/zipl.conf to use by-path names, example: parameters = root=/dev/disk/by-path/ccw-0.0.0201-part1 TERM=dumb Have the boot configuration pick up the changes: mkinitrd zipl -V Change all by-id entries in /etc/fstab to by-path entries as well, example: /dev/disk/by-path/ccw-0.0.0201-part1 / ext3 acl,user_xattr 1 1 reboot to pick up changes 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: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Hilliard, Chris Sent: Friday, February
Re: Nomad and CMS mdisk restrictions
Rich, I was told Nomad does not support sfs Phil Schuh, Richard wrote: Would SFS work? Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Phil Tully Sent: Friday, February 29, 2008 11:56 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Nomad and CMS mdisk restrictions Hello List, I received a question on how to expand a Nomad database beyond a the CMS limitation of 32k cylinders mdisk. Is there a facility in Nomad to use multiple mdisks for the same db? regards Phil Tully -- 'in media stat virtus' Virtue's in the middle -- 'in media stat virtus' Virtue's in the middle
Re: error bringing up cloned system
From: RPN01 The problem all this is trying to get around is that, if you define a system that brings up, say, minidisks at 391, 392 and 393, they become /dev/dasda, dasdb and dasdc. Now you add a new minidisk at 291 If the system puts this at the end of the list, then it would become /dev/dasdd, and this would happen when you add the disk into the running system. But, what if, when you re-boot the entire image, it now finds this disk first? It could become /dev/dasda, pushing the other disks each up one letter, and causing your fstab and other things to fail miserably. We solved this problem by including dasd=292-2FF with the ipl parameters in zipl.conf -- I inherited this configuration and I suspect it was put into place before there was a mount by-path option. With this in zipl.conf, 292 is always dasda, 2A9 is always dasdx, etc. I have been aware of other installations where parameters like dasd=293,292,294-2FF were specified, so that 293 is dasda, 292 is dasdb, 294 is dasdc, and so on. No doubt they had their reasons, although it seems somewhat gratuitous to me. Solaris handles this problem very well, IMO---especially with the addition of Veritas Volume Manager. The Linux mount by-path does come close to giving Solaris-like behavior, but when I look sideways at it there's something I can't put my finger on which makes me not entirely sure I should convert my systems to it. Perhaps there's nothing there after all, but without our having a real problem to solve here, there's little reason to look closer. ok r.
Re: error bringing up cloned system
The by-path/ name is straight-forward , like /dev/disk/by-path/ccw-0.0.0201-part1 is partituion 1 on virtual dasd address 0201 If your cloning process makes each server run with different virtual addresses I can see what you mean by I don't really know what the by-path name should be at this point and /dev/dasdx is a good choice -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, February 29, 2008 3:20 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: error bringing up cloned system Just wondering outloud. So in this environment (mainframe) there is no reason to worry about whether the dasd come online at the same time since they are already spinning and ready. I think I will stick to the conventional naming /dev/dasdx unless otherwise corrected. Anyway, I don't really know what the by-path name should be at this point, do I? I know the by-id name! Just dont want to do another install since I have my image pretty much where I want it. It would be nice if someone could summerize the different conventions, differences between them, how they work at IPL time, how cloning is impacted and especially how they should be used in a mainframe environment. Thanks. Romanowski, John (OFT) John.Romanowski@ To oft.state.ny.us IBMVM@LISTSERV.UARK.EDU Sent by: The IBM cc z/VM Operating System Subject [EMAIL PROTECTED] Re: error bringing up cloned system ARK.EDU 02/29/2008 02:11 PM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU I see your point, I was think of the other case where the filesystem is on a mdisk and cloned copy's mdisk is on another pack. I think each z/vm dasd pack has a unique hardware id; your cloned copy's pack has an id different from its parent's id; if /etc/fstab isn't adjusted after cloning to mount the copy's by-id value then the server has trouble booting when it tries to mount using the parent's by-id/ value. If by old naming conventions you mean /dev/dasda,b,c,.. they're not persistent/consistent device names unless you can guarantee the same set of disk addresses come online in the same order. I'm not knocking 'em; I use 'em. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, February 29, 2008 1:33 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: error bringing up cloned system Managled is understated. If it said partitions instead of disks it might make more sense to me. But in my case, I have only one volume/dasd/disk with 1 boot partition and 1 logical volume partition. So when you bring a cloned volume/dasd/disk online he must compare the NEW real addr to the by-id label. But, if use by-path he doesn't? Sorry still a little confused about this. What is wrong with old naming conventions? Romanowski, John (OFT) John.Romanowski@ To oft.state.ny.us IBMVM@LISTSERV.UARK.EDU Sent by: The IBM cc z/VM Operating System Subject [EMAIL PROTECTED] Re: error bringing up cloned system ARK.EDU 02/29/2008 11:53 AM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU Novell's sles 10 sp1 release notes actually give a mangled attempt to alert one to this z/VM mdisk issue. When they ran the original text thru the translator to English it must have substituted 'disk' for the non-dictionary 'mdisk' words in these sentences: Using Disks in z/VM If SLES 10 is installed on disks in z/VM, which reside on the same physical disk, the created access path (/dev/disk/by-id/) is not unique. The ID of a disk is the ID of the underlaying disk. So if two or more disk are on the same physical disk, they all have the same ID. To avoid this ambiguity, please use the access path by-path. This can be specified during the installation when the mount points are definied. To change from by-id to by-path please perform the following steps: Modify /etc/zipl.conf to use by-path names, example: parameters = root=/dev/disk/by-path/ccw-0.0.0201-part1 TERM=dumb Have the boot configuration pick up the changes: mkinitrd zipl -V Change all by-id entries in /etc/fstab to by-path entries as well, example: /dev/disk/by-path/ccw-0.0.0201-part1 / ext3 acl,user_xattr 1 1 reboot to pick up changes This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If
Re: FTP x86 to SFS
I do not think so. How would SFS know that a second PUT was to be done? Also, what would it do if the second were to fail? I hope it makes them separate work units. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Stracka, James (GTI) Sent: Friday, February 29, 2008 9:13 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: FTP x86 to SFS Could it be that SFS considers this one unit of work and is not closing the files until the complete FTP ends? -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Friday, February 29, 2008 12:07 PM To: IBMVM@LISTSERV.UARK.EDU Subject: FTP x86 to SFS I have a process that FTPs two files from a WinXP machine to an SFS directory. The sequence of events is 1. A small file, 10-15 short (80 bytes, each) records is created on the pc. 2. Immediately thereafter, an FTP is started by the script that created the small file. It contains two PUTs, one after the other. The first sends the newly created small file; the second sends a file of nearly 10,000 records ranging in size from 150 to 800 bytes. I have noticed that sometimes, infrequently, the large file arrives first. This transfer is done over an internal network. Tracert from the pc to VM always shows the same 7 hops; from VM to the pc, the same in reverse order. Is there anything that explains this as normal behavior? Or has Chuckie struck? I would love to do the transfer with a virtual machine as the client, but the large file is inaccessible from any pc on the network that is running an approved FTP server. Unapproved FTP servers are frowned upon by Infosec, and thus, by management. Regards, Richard Schuh This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing.
Re: Nomad and CMS mdisk restrictions
I haven't looked at NOMAD since about 2003, but I moved all the stuff off to SFS and it worked fine. Don't know that we approached that size at that time. Bob Bates Enterprise Hosting Services - Enterprise Virtualization - z/VM and z/Linux w. (469)892-6660 c. (214) 907-5071 This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Phil Tully Sent: Friday, February 29, 2008 1:56 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Nomad and CMS mdisk restrictions Hello List, I received a question on how to expand a Nomad database beyond a the CMS limitation of 32k cylinders mdisk. Is there a facility in Nomad to use multiple mdisks for the same db? regards Phil Tully -- 'in media stat virtus' Virtue's in the middle
Re: Nomad and CMS mdisk restrictions
That is quite a typo, or was it a Freudian slip? :-) Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Edward M. Martin Sent: Friday, February 29, 2008 1:08 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Nomad and CMS mdisk restrictions Hell Richard and Phil, If you mean to hold the Schema and SIT2, and NOMAD2, then Yes. We have a PROD/TEST/BETA-SYS Nomad2 system using CA-VWGATEWAY to access the Schema's, SIT2, and hold batch reports that I email to the end users. Ed Martin 330-588-4723 ext 40441 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Friday, February 29, 2008 2:59 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Nomad and CMS mdisk restrictions Would SFS work? Regards, Richard Schuh
Re: Nomad and CMS mdisk restrictions
Major Typo. Sorry! Or should I say 'What Typo'? Like the electronic voting machines here in Ohio. No back, logs that could be changed without audits. Ed Martin 330-588-4723 ext 40441 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Friday, February 29, 2008 4:11 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Nomad and CMS mdisk restrictions That is quite a typo, or was it a Freudian slip? :-) Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Edward M. Martin Sent: Friday, February 29, 2008 1:08 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Nomad and CMS mdisk restrictions Hello Richard and Phil, If you mean to hold the Schema and SIT2, and NOMAD2, then Yes. We have a PROD/TEST/BETA-SYS Nomad2 system using CA-VWGATEWAY to access the Schema's, SIT2, and hold batch reports that I email to the end users. Ed Martin 330-588-4723 ext 40441 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Friday, February 29, 2008 2:59 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Nomad and CMS mdisk restrictions Would SFS work? Regards, Richard Schuh
Re: Nomad and CMS mdisk restrictions
Hell Richard and Phil, If you mean to hold the Schema and SIT2, and NOMAD2, then Yes. We have a PROD/TEST/BETA-SYS Nomad2 system using CA-VWGATEWAY to access the Schema's, SIT2, and hold batch reports that I email to the end users. Ed Martin 330-588-4723 ext 40441 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Friday, February 29, 2008 2:59 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Nomad and CMS mdisk restrictions Would SFS work? Regards, Richard Schuh
Re: error bringing up cloned system
Just wondering outloud. So in this environment (mainframe) there is no reason to worry about whether the dasd come online at the same time since they are already spinning and ready. I think I will stick to the conventional naming /dev/dasdx unless otherwise corrected. Anyway, I don't really know what the by-path name should be at this point, do I? I know the by-id name! Just dont want to do another install since I have my image pretty much where I want it. It would be nice if someone could summerize the different conventions, differences between them, how they work at IPL time, how cloning is impacted and especially how they should be used in a mainframe environment. Thanks. Romanowski, John (OFT) John.Romanowski@ To oft.state.ny.us IBMVM@LISTSERV.UARK.EDU Sent by: The IBM cc z/VM Operating SystemSubject [EMAIL PROTECTED] Re: error bringing up cloned system ARK.EDU 02/29/2008 02:11 PM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU I see your point, I was think of the other case where the filesystem is on a mdisk and cloned copy's mdisk is on another pack. I think each z/vm dasd pack has a unique hardware id; your cloned copy's pack has an id different from its parent's id; if /etc/fstab isn't adjusted after cloning to mount the copy's by-id value then the server has trouble booting when it tries to mount using the parent's by-id/ value. If by old naming conventions you mean /dev/dasda,b,c,.. they're not persistent/consistent device names unless you can guarantee the same set of disk addresses come online in the same order. I'm not knocking 'em; I use 'em. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, February 29, 2008 1:33 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: error bringing up cloned system Managled is understated. If it said partitions instead of disks it might make more sense to me. But in my case, I have only one volume/dasd/disk with 1 boot partition and 1 logical volume partition. So when you bring a cloned volume/dasd/disk online he must compare the NEW real addr to the by-id label. But, if use by-path he doesn't? Sorry still a little confused about this. What is wrong with old naming conventions? Romanowski, John (OFT) John.Romanowski@ To oft.state.ny.us IBMVM@LISTSERV.UARK.EDU Sent by: The IBM cc z/VM Operating System Subject [EMAIL PROTECTED] Re: error bringing up cloned system ARK.EDU 02/29/2008 11:53 AM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU Novell's sles 10 sp1 release notes actually give a mangled attempt to alert one to this z/VM mdisk issue. When they ran the original text thru the translator to English it must have substituted 'disk' for the non-dictionary 'mdisk' words in these sentences: Using Disks in z/VM If SLES 10 is installed on disks in z/VM, which reside on the same physical disk, the created access path (/dev/disk/by-id/) is not unique. The ID of a disk is the ID of the underlaying disk. So if two or more disk are on the same physical disk, they all have the same ID. To avoid this ambiguity, please use the access path by-path. This can be specified during the installation when the mount points are definied. To change
Re: Nomad and CMS mdisk restrictions
Thank You for the information. Bob Bates wrote: I haven't looked at NOMAD since about 2003, but I moved all the stuff off to SFS and it worked fine. Don't know that we approached that size at that time. Bob Bates Enterprise Hosting Services - Enterprise Virtualization - z/VM and z/Linux w. (469)892-6660 c. (214) 907-5071 This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Phil Tully Sent: Friday, February 29, 2008 1:56 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Nomad and CMS mdisk restrictions Hello List, I received a question on how to expand a Nomad database beyond a the CMS limitation of 32k cylinders mdisk. Is there a facility in Nomad to use multiple mdisks for the same db? regards Phil Tully -- 'in media stat virtus' Virtue's in the middle -- 'in media stat virtus' Virtue's in the middle
Re: error bringing up cloned system
On Feb 29, 2008, at 12:33 PM, [EMAIL PROTECTED] wrote: Managled is understated. If it said partitions instead of disks it might make more sense to me. But in my case, I have only one volume/dasd/ disk with 1 boot partition and 1 logical volume partition. So when you bring a cloned volume/dasd/disk online he must compare the NEW real addr to the by-id label. But, if use by-path he doesn't? Sorry still a little confused about this. What is wrong with old naming conventions? By-id has *nothing* to do with the device address. It's a terrible idea in a virtualized environment--it tries to synthesize a unique ID from characteristics of the real device it can figure out. This makes cloning impossible. It should not have been the default in SLES for s390x. By-path is the one that corresponds to the device address. You can clone *that* and as long as your device definitions don't change across guests you're fine. It's the one most of us here are recommending. /dev/dasdXp1 is fine, except that if you add a device with a lower device address and aren't very careful about how you force device detection order in zipl.conf, then you will end up being very sorry when your new device shows up as /dev/dasda and bumps your older devices down the chain so that /etc/fstab no longer works. In a VM environment, by-path is usually the addressing method most likely to stay constant. Adam
Re: FTP x86 to SFS
I imagine that WS-FTP is doing concurrent PUTs. /Fran - On Fri, 29 Feb 2008 10:23:56 -0800 Schuh, Richard said: Is it using consecutive puts, or does it have some way to do them concurrently? In my case, it is being done via a Perl script that uses consecutive put commands. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Fran Hensler Sent: Friday, February 29, 2008 10:02 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: FTP x86 to SFS I have a WS_FTP Pro where I select two files at one time and FTP them to a z/VM account. I can see from the progress bar that both files are being sent at the same time. This is in passive mode. /Fran Hensler at Slippery Rock University of Pennsylvania USA for 44 years [EMAIL PROTECTED] +1.724.738.2153 Yes, Virginia, there is a Slippery Rock
Re: Nomad and CMS mdisk restrictions
You may have changed it on this note, but I still have the original. You can run, but you can't hide. :-) Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Edward M. Martin Sent: Friday, February 29, 2008 1:19 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Nomad and CMS mdisk restrictions Major Typo. Sorry! Or should I say 'What Typo'? Like the electronic voting machines here in Ohio. No back, logs that could be changed without audits. Ed Martin 330-588-4723 ext 40441 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Friday, February 29, 2008 4:11 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Nomad and CMS mdisk restrictions That is quite a typo, or was it a Freudian slip? :-) Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Edward M. Martin Sent: Friday, February 29, 2008 1:08 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Nomad and CMS mdisk restrictions Hello Richard and Phil, If you mean to hold the Schema and SIT2, and NOMAD2, then Yes. We have a PROD/TEST/BETA-SYS Nomad2 system using CA-VWGATEWAY to access the Schema's, SIT2, and hold batch reports that I email to the end users. Ed Martin 330-588-4723 ext 40441 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Friday, February 29, 2008 2:59 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Nomad and CMS mdisk restrictions Would SFS work? Regards, Richard Schuh
Re: error bringing up cloned system
Ok, just started another install for a golden image. So far I use device-path for /dev/dasda (/boot) but now I am sitting on the screen for setting fstab options for the lvl. It won't let me chose device-id or device-path (faded out). The default setting is for device-name. I could also choose volume-label or uuid. Should I choose uuid? Romanowski, John (OFT) John.Romanowski@ To oft.state.ny.us IBMVM@LISTSERV.UARK.EDU Sent by: The IBM cc z/VM Operating SystemSubject [EMAIL PROTECTED] Re: error bringing up cloned system ARK.EDU 02/29/2008 03:33 PM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU The by-path/ name is straight-forward , like /dev/disk/by-path/ccw-0.0.0201-part1 is partituion 1 on virtual dasd address 0201 If your cloning process makes each server run with different virtual addresses I can see what you mean by I don't really know what the by-path name should be at this point and /dev/dasdx is a good choice -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, February 29, 2008 3:20 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: error bringing up cloned system Just wondering outloud. So in this environment (mainframe) there is no reason to worry about whether the dasd come online at the same time since they are already spinning and ready. I think I will stick to the conventional naming /dev/dasdx unless otherwise corrected. Anyway, I don't really know what the by-path name should be at this point, do I? I know the by-id name! Just dont want to do another install since I have my image pretty much where I want it. It would be nice if someone could summerize the different conventions, differences between them, how they work at IPL time, how cloning is impacted and especially how they should be used in a mainframe environment. Thanks. Romanowski, John (OFT) John.Romanowski@ To oft.state.ny.us IBMVM@LISTSERV.UARK.EDU Sent by: The IBM cc z/VM Operating System Subject [EMAIL PROTECTED] Re: error bringing up cloned system ARK.EDU 02/29/2008 02:11 PM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU I see your point, I was think of the other case where the filesystem is on a mdisk and cloned copy's mdisk is on another pack. I think each z/vm dasd pack has a unique hardware id; your cloned copy's pack has an id different from its parent's id; if /etc/fstab isn't adjusted after cloning to mount the copy's by-id value then the server has trouble booting when it tries to mount using the parent's by-id/ value. If by old naming conventions you mean /dev/dasda,b,c,.. they're not persistent/consistent device names unless you can guarantee the same set of disk addresses come online in the same order. I'm not knocking 'em; I use 'em. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, February 29, 2008 1:33 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: error bringing up cloned system Managled is understated. If it said partitions instead of disks it might make more sense to me. But in my case, I have only one volume/dasd/disk with 1 boot partition and 1 logical volume partition. So when you bring a
Re: Nomad and CMS mdisk restrictions
SFS is *not* supported for NOMAD databases. In particular, the database RESTORE function (whether issued by a RESTORE command, an UNLOCK RESTORE command, or internally in response to an I/O or other unexpected error) does not work on files stored in SFS. A corrupted database could potentially result from a RESTORE of a NOMAD database stored on SFS. -- Thomas R. Ramsberger Principal Software Engineer Select Business Solutions Product Development (eBIS) 35 Nutmeg Drive Trumbull, CT 06611 [EMAIL PROTECTED] Voice: 203 383-4684 Fax: 203 383-4601
[no subject]
To those who were following a thread last year regarding VM:Secure and VM:Direct caching DASD volume allocation bit maps, and the writing over them when it reorganized the DRCT cylinders, the solution is available... Quoted from z/VM and VM/ESA Newsletter from CA, Version 08.01 February 29, 2008 Object Directory Volume Allocation Map Update Relief for CA VM:Secure® for z/VM and CA VM:Director® for z/VM CA VM:Secure for z/VM and CA VM:Director for z/VM must be shut down if a change needs to be made to the allocation map on the volume that contains your z/VM online object directory. To avoid this requirement and make the changes without shutting down the product server, we have provided a test field update. More details at: https://support.ca.com/irj/portal/anonymous/phpdocs?filePath=0/185/185_techdocindex.html Mike Walter Hewitt Associates The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
Re: error bringing up cloned system
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 RPN01 wrote: | | Note that if you use LVM for the majority of your system, then this whole | issue is only relevant for the /boot disk (and possibly the root filesystem; | depends on whose rules you follow). LVM uses the disk's uuid to locate the | physical volumes that make up a volume group, and sets everything up | accordingly. | And another way to get round this is to mount /boot or other static filesystems by filesystem label: ~ mke2fs -j -L SOMEFILESYS /dev/dasd... in fstab: ~ LABEL=SOMEFILESYS /somefilesys ext3 ... I do this on my distributed platforms which have SAN, and may change disk order when SAN disk is added or removed. - -- Pat -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHyKIyNObCqA8uBswRAqZEAJ95xfLcqqHLh7dghF7lQbkWNKttMgCfSvBF PF5a7uAQUM5R3Xsuj7GFFq8= =nSXJ -END PGP SIGNATURE-
