Re: Using IFL processor
Gordon: Choose "Linux only". You might as well dedicate the processor, unless you want to create a test LPAR. Romney On Mon, 17 Dec 2001 15:41:40 -0800 Wolfe, Gordon W said: >We just recently upgraded to a G5 processor and got an IFL engine with the >other processors. Just last night I did an I/O gen with an IOCDS that >created a separate LPAR that will run z/VM 4.2 and will eventually have all >of our Linux servers as guests on this one z/VM LPAR. > >We have just obtained z/VM 4.2 (currently running on z/VM 3.1.0 on our other >LPARs) and so we can't test this new LPAR yet since we don't have a VM that >will IPL on it yet. We have five other LPARs that share three 390 >processors, but we want the Linux LPAR to use just the IFL processor. > >Since I've never done this before with an IFL processor, my question is, how >do I tell the LPAR controls to use the IFL engine for this LPAR? When >creating the LPAR image profile on the HMC console, under the "General" tab, >I went into the "Mode" window and I see four choices there: > >ESA/390 >ESA/390 TPF >Coupling Facility >Linux Only > >Do I choose the IFL engine by selecting 'Linux Only"? I don't see any other >choice anywhere in the image profile that would indicate an IFL processor. >Is there something else I have to do? Should I dedicate this processor to >the LPAR? > >The only manual we have for the HMC is for our old G4 processor. I'd >appreciate any help from someone who's done this before, or perhaps someone >from IBM who's in the know. > >"Christmas is a funny season. What other time of the year do you sit in >front of a dead tree and eat candy out of your socks?" >Gordon Wolfe, Ph.D. (425)865-5940 >VM Technical Services, The Boeing Company
Re: VM and Linux time of day
Ross: I'm not sure what you're referring to. There is no hardware restriction to setting the TOD clock without human intervention. Bit 10 of CR 14 is the TOD-Clock-control-override control and can be set to allow software to set the TOD Clock without manual intervention. This is how z/VM sets it at IPL, even though we ask the operator for permission first. There are certainly software considerations required if one wants to change the clock out from under a running system. Romney On Mon, 14 Jan 2002 16:07:03 -0500 Patterson, Ross said: >Gregg C Levine <[EMAIL PROTECTED]> writes: >> Haven't we been beating this issue over the head with gaffi sticks far >> too long? > >Yup, we have. George hit the nail on the head. I don't >care what software you run to synch up the clock, or which >clocks you choose to synch against. The problem is a >hardware one - System/390 and zSeries boxes won't change >the clock without the permission of a human. Until and >unless IBM changes that, arguments about which NTP server >or client to use are moot. Unless you want to hire someone >to press the TOD-Enable switch or execute the system console/HMC >TOD Enable function every few minutes! :-) > >Ross Patterson >Computer Associates
Re: Linuxvm.org Hits the Big Time
Mark: Pam Christina ([EMAIL PROTECTED]) is probably responsible for this change. Romney On Fri, 18 Jan 2002 12:09:07 -0500 Post, Mark K said: >Hey! I just noticed that the web page at http://www.vm.ibm.com/linux/ >points to linuxvm.org. Cool! Now I can start putting up some banner ads >and making some money off the site! :) Who at IBM do I have to thank for >this? > >Mark Post
Re: SLES Beta and HiperSockets ? - now MTU size question
Marcy: The MTU size allowed is limited by the large envelope size. Try changing your LargeEnvelopePoolSize specification. Romney On Tue, 12 Feb 2002 11:33:39 PST Marcy Cortes said: >Thanks everyone for you help, esp. Jeremy. I got a fix from >Suse and now VM Guest LAN is working just fine. > >Question about MTU sizes, though. I let MFS default to 16k >on the CP DEFINE LAN command. And so, in z/VM's MPROUTE CONFIG >I specified an MTU size of 16384 and in Linux's /etc/rc.config >I specified an MTU of 16384 as well. When I issue an >ifconfig from linux, I see the MTU size is 8192. Is that the max? >Should I go back and change the DEFINE LAN command and >the MPROUTE config to match? > >ifconfig >hsi0 Link encap:Ethernet HWaddr 00:00:00:00:00:00 > inet addr:10.12.7.2 Mask:255.255.255.128 > inet6 addr: fe80::200:ff:fe00:0/10 Scope:Link > UP RUNNING NOARP MTU:8192 Metric:1 > RX packets:219 errors:0 dropped:0 overruns:0 frame:0 > TX packets:217 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:100 > RX bytes:9969 (9.7 Kb) TX bytes:27025 (26.3 Kb) > Interrupt:11 > >Marcy Cortes >Wells Fargo Services Company >VM Systems Programming
Re: SLES Beta and HiperSockets ? - now MTU size question
Marcy: I would add the word "enough" after "large" in Alan's first comment. It makes no difference if your MTU is 1500 bytes or 56K bytes if the longest packet you send is 500 bytes. Romney On Tue, 12 Feb 2002 17:29:48 -0500 Alan Altmark said: >On Tuesday, 02/12/2002 at 01:42 PST, Marcy Cortes <[EMAIL PROTECTED]> >wrote: >> Now, one more question! In the TCP/IP P&C manual, p.508 lists >> some recommended MTU sizes for various types of interfaces. What's >> a good MTU size for guest lan? (our primary app at this point >> is apache webserving). > >For guests that communicate with *each other* on the guest LAN, a large >MTU is best. When routing traffic to a real LAN, use the MTU of the real >LAN. Otherwise you get packet fragmentation which just steals cycles from >the machine. > >Linux had "dynamic path MTU discovery" so the apache server will >automatically discover the best MTU to use. With this model, feel free to >use a larger MTU on the guest LAN. Fragmentation will occur initially, >but will disappear as Linux reduces the MTU automatically. Just make sure >the initial MTU size specified on the apache server matches the MTU >specified on VM TCP/IP. > >Regards, >Alan > >IBM Senior Software Engineer >z/VM Development, Endicott, NY >Phone 607.752.6027fax 607.752.1497 t/l 852
Re: TCP/IP and Linux
Bill: The message is documenting the fact that Linux sent a malformed block of packets across the CTCA. The blocks may be up to 32K (32768 bytes) long, so a packet starting at 33134 is clearly an error. The offending packet is at offset 31628 in the buffer. I presume that there is a mismatch in the buffer size between Linux and VM TCP/IP and hope there is a control you can set on the Linux side to use a buffer size of 32K. Romney On Wed, 13 Feb 2002 10:55:27 -0500 Scully, William said: >(Cross-posted to the VM and Linux on 390 lists) > >We find a lot of the following messages on TCP/IP's console (FL 3A0) >regarding the CTCs for Linux servers: > >22:50:10 DTCCTC008E CTCA device LINUX016: UnpackReads: Inv blk hdr 33134 >from input position 31628. Last blk hdr 0. Discarding remainder of block. > > >Are others of you out there seeing this? The message doesn't seem to be >documented. What does it mean? It appears that some (but not all) servers >loose connectivity when this happens. > >William P. Scully >Systems Programmer >Computer Associates International, Inc >[EMAIL PROTECTED]
Re: FW: TCP/IP and Linux
Bill: This has nothing to do with MTU size. MTU size determines the maximum size of a datagram. The datagrams are packed into a 32K buffer for transport across the CTCA. That's where the problem is occurring. Romney On Wed, 13 Feb 2002 11:49:03 -0500 Scully, William said: >Thanks for the info Romney! On one of the Linux servers where I get the >error, I did an IFCONFIG and I find: > > >linux017:~ # ifconfig >ctc0 Link encap:Serial Line IP > inet addr:141.202.232.131 P-t-P:141.202.198.101 >Mask:255.255.255.255 > UP POINTOPOINT RUNNING NOARP MTU:1500 Metric:1 > RX packets:7407345 errors:0 dropped:0 overruns:0 frame:0 > TX packets:13113625 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:100 > >loLink encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > UP LOOPBACK RUNNING MTU:3924 Metric:1 > RX packets:2629004 errors:0 dropped:0 overruns:0 frame:0 > TX packets:2629004 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > > >I see an MTU of 1500 on ctc0. So how did such a large packet end up on the >CTC between Linux and VM? > >-Original Message- >From: Romney White [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, February 13, 2002 11:02 AM >To: [EMAIL PROTECTED] >Subject: Re: TCP/IP and Linux > > >Bill: > >The message is documenting the fact that Linux sent a malformed block >of packets across the CTCA. The blocks may be up to 32K (32768 bytes) >long, so a packet starting at 33134 is clearly an error. The offending >packet is at offset 31628 in the buffer. > >I presume that there is a mismatch in the buffer size between Linux >and VM TCP/IP and hope there is a control you can set on the Linux >side to use a buffer size of 32K. > >Romney > >On Wed, 13 Feb 2002 10:55:27 -0500 Scully, William said: >>(Cross-posted to the VM and Linux on 390 lists) >> >>We find a lot of the following messages on TCP/IP's console (FL 3A0) >>regarding the CTCs for Linux servers: >> >>22:50:10 DTCCTC008E CTCA device LINUX016: UnpackReads: Inv blk hdr 33134 >>from input position 31628. Last blk hdr 0. Discarding remainder of block. >> >> >>Are others of you out there seeing this? The message doesn't seem to be >>documented. What does it mean? It appears that some (but not all) servers >>loose connectivity when this happens. >> >>William P. Scully >>Systems Programmer >>Computer Associates International, Inc >>[EMAIL PROTECTED]
Re: VM for Intel?
Mark: Conceptually, there are bound to be similarities. From a code base point of view, there is no feasible means of integration, if only because z/VM is Assembler and PL/X. Of course, the architectural differences present a much more significant barrier to having any commonality in the code base. Romney On Tue, 19 Feb 2002 10:16:42 -0500 Post, Mark K said: >I received this item today from InfoWorld. I'm wondering if anyone on the >IBM VM development team could comment if any part of z/VM is being >integrated into this software. (Alan, Romney?) > >Mark Post > >- - - - - - - - - - - - - - - - - - - - - - - - - - - - >PARTNERWORLD - IBM AND VMWARE WORK ON PARTITIONING TOOLS > >Posted February 19, 2002 03:38 Pacific Time > >SAN FRANCISCO -- - IBM Corp. and VMware Inc. announced a partnership Tuesday >to work on improving partitioning software for high end Intel-based servers. > >Partitioning tools, once only common on mainframes, have made their way to >higher-end Unix servers, and now IBM and VMware are looking to add the same >software to servers with 16 or fewer Intel Corp. processors, said Jay >Bretzmann, director of xSeries server marketing at IBM. The companies have >developed a version of the software for IBM's x360 server and plan an update >to the software for the third quarter that will be aimed at the high end of >the xSeries line. > > >For the full story: >http://www.infoworld.com/articles/hn/xml/02/02/19/020219hnibmvm.xml?0219tuam
Re: VM for Intel?
Mark: No reason other than performance, which of course is a perfectly adequate roadblock to the whole idea of Intel emulation. Romney On Tue, 19 Feb 2002 11:05:34 -0500 Post, Mark K said: >But that was my question. Since IBM and VMWare are partnering on this >effort, would IBM have contributed any sort of functionality lifted from >z/VM? If not, why the partnership? Romney has stated that there are going >to be certain conceptual similarities, and I realized that from the >beginning. I was curious about just _how much_ similarity was going to wind >up being there. There's been some discussion in the past (I think David >Boyes brought it up) that there's no reason why z/VM couldn't emulate >non-S/390 instructions on an S/390. Hercules is already providing the >foundation for the converse. > >Mark Post > >-Original Message- >From: David Goodenough [mailto:[EMAIL PROTECTED]] >Sent: Tuesday, February 19, 2002 3:59 PM >To: [EMAIL PROTECTED] >Subject: Re: VM for Intel? > > >But VMware and z/VM are entirely separate. They both do much the same >thing, in fact one could almost say that z/VM and its ancestors inspired >VMware, but VMware is not produced by IBM, rather - as the item says, by >VMware Inc. > > > > >"Post, Mark K" >com> cc: >Sent by: Linux Subject: VM for Intel? >on 390 Port ><[EMAIL PROTECTED] >ARIST.EDU> > > >02/19/02 03:16 >PM >Please respond >to Linux on 390 >Port > > > > > > >I received this item today from InfoWorld. I'm wondering if anyone on the >IBM VM development team could comment if any part of z/VM is being >integrated into this software. (Alan, Romney?) > >Mark Post > >- - - - - - - - - - - - - - - - - - - - - - - - - - - - >PARTNERWORLD - IBM AND VMWARE WORK ON PARTITIONING TOOLS > >Posted February 19, 2002 03:38 Pacific Time > >SAN FRANCISCO -- - IBM Corp. and VMware Inc. announced a partnership >Tuesday >to work on improving partitioning software for high end Intel-based >servers. > >Partitioning tools, once only common on mainframes, have made their way to >higher-end Unix servers, and now IBM and VMware are looking to add the same >software to servers with 16 or fewer Intel Corp. processors, said Jay >Bretzmann, director of xSeries server marketing at IBM. The companies have >developed a version of the software for IBM's x360 server and plan an >update >to the software for the third quarter that will be aimed at the high end of >the xSeries line. > > >For the full story: >http://www.infoworld.com/articles/hn/xml/02/02/19/020219hnibmvm.xml?0219tuam
Re: Running 31bit SuSE 7.0 2.2.16 under 64 bit z/VM 4.2
Richard: Yes. 64-bit z/VM supports 31-bit guests, as well as 64-bit guests. Romney On Fri, 1 Mar 2002 11:27:27 -0700 Richard Feldman (WFF) said: >To: LINUXLST--WFFCAL Linux 390 Discussi > >Subject: Running 31bit SuSE 7.0 2.2.16 under 64 bit z/VM 4.2 > >Currently we are running SuSE 7.0 2.2.16 under VM/ESA 2.4. I'm >building a new z/VM 4.2 system that will initially run 31bit. I will soon >test my Linux box in the 4.2 machine. We are currently only running it as >a secondary DNS server, very handy for a low cost DNS. I assume I can run >as is in the 31bit mode - question being - will my current Linux run in >a 64bit environment. > >Thanks, > >Richard Feldman >Systems Programmer, Technical Services >Kelly, Douglas / Westfair Foods Ltd. >Ph:(403)291-6339 Fax:(403)291-6585 E-Mail:[EMAIL PROTECTED]
Re: Attempting first IPL after initial SuSE install
Jim: The device status is Channel End + Device End, which is normal. The subchannel status is Incorrect Length, which may indicate that you have something wrong with your image on disk. The associated channel program should start at absolute location 8. See "Initial Program Loading" in the Principles of Operation for details. You aren't booting "from" the SE, by the way. You're booting via the SE from DASD. The SE is just the messenger. Romney On Mon, 11 Mar 2002 10:05:22 -0600 James Melin said: >Has anyone seen this message on the SE console when attempting to ipl a >freshly installed Linux? > >The load control unit or device is busy. Device status is 0C and >subchannel status is 40. > >This is in a G5 with Ficon to a ficon director and from there into an IBM >'shark' dasd box. > >I'm having trouble finding the device status codes and subchannel status >codes as they might pertain to an initial load from the service element.
Re: Attempting first IPL after initial SuSE install
Jim: Someone with better Linux skills than I will need to jump in here to address your questions about YaST and silo. It sure sounds like you either don't have a good IPL record or what it points to is bogus. Romney On Mon, 11 Mar 2002 10:57:35 -0600 James Melin said: >Right. That's a semantic misnomer from my part. I said that because that's >where the LPAR is told what load device to run from is. The thing is that >the ramdisk image worked and accessed the devices properly. Should I >manually run a silo command with the T2 option specified? I am unsure if >YaST did that all properly. > >Thanks for the info on the subchannel status. That give me someplace to >start. > > >Jim: > >The device status is Channel End + Device End, which is normal. The >subchannel status is Incorrect Length, which may indicate that you >have something wrong with your image on disk. The associated channel >program should start at absolute location 8. See "Initial Program >Loading" in the Principles of Operation for details. > >You aren't booting "from" the SE, by the way. You're booting via the >SE from DASD. The SE is just the messenger. > >Romney > >On Mon, 11 Mar 2002 10:05:22 -0600 James Melin said: >>Has anyone seen this message on the SE console when attempting to ipl a >>freshly installed Linux? >> >>The load control unit or device is busy. Device status is 0C and >>subchannel status is 40. >> >>This is in a G5 with Ficon to a ficon director and from there into an IBM >>'shark' dasd box. >> >>I'm having trouble finding the device status codes and subchannel status >>codes as they might pertain to an initial load from the service element.
Re: RH 7.2 Install Issues
Chet: The user name under VIF for TCP/IP is $TCPIP, *not* TCPIP. You need to change the iucv parameter to specify $TCPIP. Romney On Fri, 19 Apr 2002 03:43:01 -0700 Chet Norris said: >I can't Telnet into the image, so I'm not getting far enough to do >either. IBM says that the user name under VIF for tcpip is TCPIP. >$TCPIP is only an alias, so it should find it, but it doesn't, and I >can't get to the image through ping from the master image or telnet. > iucv0: 'TCPIP' > NETIUCV driver Version: 1.12 initialized > iucv0: User TCPIP is currently not available. > > >--- "Post, Mark K" <[EMAIL PROTECTED]> wrote: >> Chet, >> >> Are you using rhsetup, or loader to start the installation? >> >> Mark > > >= >Chet Norris >Marriott International,Inc. > >__ >Do You Yahoo!? >Yahoo! Tax Center - online filing with TurboTax >http://taxes.yahoo.com/
Re: RH 7.2 Install Issues
Chet: $ is a valid character in a user identifier and should be being accepted (it certainly used to be). What exactly is the error message you receive? Romney On Fri, 19 Apr 2002 06:17:30 -0700 Chet Norris said: >That's where I started. Per >ftp://ftp.redhat.com/pub/redhat/linux/7.2/en/os/s390/README/ , the >HOST= for iucv0 connections should specify $TCPIP for VIF users. But >the install issues an error saying that $ is an invalid character. And >I've tried leaving the HOST statement out, but I can't respond to the >message under VIF logon. I just get a CP response to my reply and the >install just sits there waiting. > >--- Romney White <[EMAIL PROTECTED]> wrote: >> Chet: >> >> The user name under VIF for TCP/IP is $TCPIP, *not* TCPIP. You need >> to >> change the iucv parameter to specify $TCPIP. >> >> Romney >> >> On Fri, 19 Apr 2002 03:43:01 -0700 Chet Norris said: >> >I can't Telnet into the image, so I'm not getting far enough to do >> >either. IBM says that the user name under VIF for tcpip is TCPIP. >> >$TCPIP is only an alias, so it should find it, but it doesn't, and I >> >can't get to the image through ping from the master image or telnet. >> > iucv0: 'TCPIP' >> > NETIUCV driver Version: 1.12 initialized >> > iucv0: User TCPIP is currently not available. >> > >> > >> >--- "Post, Mark K" <[EMAIL PROTECTED]> wrote: >> >> Chet, >> >> >> >> Are you using rhsetup, or loader to start the installation? >> >> >> >> Mark >> > >> > >> >= >> >Chet Norris >> >Marriott International,Inc. >> > >> >__ >> >Do You Yahoo!? >> >Yahoo! Tax Center - online filing with TurboTax >> >http://taxes.yahoo.com/ > > >= >Chet Norris >Marriott International,Inc. > >__ >Do You Yahoo!? >Yahoo! Tax Center - online filing with TurboTax >http://taxes.yahoo.com/
Re: RH 7.2 Install Issues
Chet: You'r right - RedHat built their kernel for stand-alone installation only, requiring the use of the HMC integrated console, whereas VIF is built to provide Linux images with a 3215 console. You need a kernel with 3215 support to install under VIF. Romney On Mon, 22 Apr 2002 07:13:36 -0700 Chet Norris said: > >>. Any time you see a posting from Alan Altmark, or >>Romney White about some aspect of VM or VIF, pay particular attention, >>as they're intimately familiar with the product from the inside out. > >Sorry Romney, I sent the reply to a prior note before reading yours. >I've been talking to IBM, Endicott, and was echoing their conversation. > >> Rob van der Heij wrote: >> If you don't want to recompile the driver yourself first: >> >> echo '$TCPIP' > /proc/net/iucv/iucv0/username > >I'm not sure if I can do what you said. Not only can I not telnet into >the image, but I also cannot communicate with the image through any >console facility. The way I understand it RedHat assumes that the >install is going to be performed from a HMC console, and VIF defines >the console as a 3215 device for the image. There is some mis-match in >device types that prevents me from entering any commands when logged on >through VIF. > >= >Chet Norris >Marriott International,Inc. > >__ >Do You Yahoo!? >Yahoo! Games - play chess, backgammon, pool and more >http://games.yahoo.com/
Re: SAF in zVM V4R2 Express Installation
Lionel: I think it's easy to say that SAF could eliminate its control of the directory but also trivial to construct a counterexample situation that would deliver you to the base VM tools rather rudely, with no way of going back. If you're right, an existence proof would be (a) easy and (b) incontrovertible proof. Romney On Mon, 13 May 2002 15:03:25 -0700 Lionel Dyck said: >Let me add that it wouldn't take much, imho, for IBM to make SAF >semi-usable. If they would remove the lock down on the user direct so >that one could add other vm guests (e.g. cms, perf monitor, ...) then it >would be nearly ok. > > >Lionel B. Dyck, Systems Software Lead >Kaiser Permanente Information Technology >25 N. Via Monte Ave >Walnut Creek, Ca 94598 > >Phone: (925) 926-5332 (tie line 8/473-5332) >E-Mail:[EMAIL PROTECTED] >Sametime: (use Lotus Notes address) >AIM:lbdyck > >Linux on 390 Port <[EMAIL PROTECTED]> wrote on 05/13/2002 02:34:34 >PM: > >> Hank, >> >> You really don't want to try to manage your Linux/390 guests with SAF. >It >> wasn't meant for that, and IBM won't enhance it beyond its current >> functionality. It was intended solely for the purpose of migrating from >VIF >> to z/VM, and has caused Lionel Dyck an untold amount of grief whenever >he >> tries to push it beyond that. It's your choice, of course, but you can >burn >> a lot of time trying to get it to do what you need and it's not meant to >> provide. >> >> Mark Post >> -Original Message- >> From: Hank Calzaretta [mailto:[EMAIL PROTECTED]] >> Sent: Monday, May 13, 2002 5:03 PM >> To: [EMAIL PROTECTED] >> Subject: SAF in zVM V4R2 Express Installation >> >> >> Hello, >> >> I've just installed zVM V4R2 using the "Express Installation Method". I >> would like to use the "System Administration Facility" (SAF) to manage >Linux >> instances. I sign on as MAINT and issue the command "VMADMCTL START" >and I >> get "Unknow CP/CMS Command". Is anyone aware of any special "LINKs" I >have >> to do to locate the VMADMCTL or VMADMIN commands? >> >> Thanks in advance, >> Hank Calzaretta
Re: SAF in zVM V4R2 Express Installation
Lionel: SAF is a tool for customers migrating from VIF to z/VM. In that respect, it meets its objectives (and apparently doesn't meet yours). I'm sorry, but I think you're trying to use a screwdriver to remove a nail. Romney On Mon, 13 May 2002 19:58:12 -0700 Lionel Dyck said: >My comments was based on how I would have architected SAF - I have no idea >how SAF was actually architected but the results indicate to me that there >was no extensive functionality/usability design effort for SAF >architecture. > > >Lionel B. Dyck, Systems Software Lead >Kaiser Permanente Information Technology >25 N. Via Monte Ave >Walnut Creek, Ca 94598 > >Phone: (925) 926-5332 (tie line 8/473-5332) >E-Mail:[EMAIL PROTECTED] >Sametime: (use Lotus Notes address) >AIM:lbdyck > > > >Romney White <[EMAIL PROTECTED]> >Sent by: Linux on 390 Port <[EMAIL PROTECTED]> >05/13/2002 05:27 PM >Please respond to Linux on 390 Port > > >To >[EMAIL PROTECTED] >cc > >bcc > >Subject >Re: SAF in zVM V4R2 Express Installation > > > >Lionel: > >I think it's easy to say that SAF could eliminate its control of the >directory but also trivial to construct a counterexample situation >that would deliver you to the base VM tools rather rudely, with no way >of going back. If you're right, an existence proof would be (a) easy >and (b) incontrovertible proof. > >Romney > >On Mon, 13 May 2002 15:03:25 -0700 Lionel Dyck said: >>Let me add that it wouldn't take much, imho, for IBM to make SAF >>semi-usable. If they would remove the lock down on the user direct so >>that one could add other vm guests (e.g. cms, perf monitor, ...) then it >>would be nearly ok. >> >> >>Lionel B. Dyck, Systems Software Lead >>Kaiser Permanente Information Technology >>25 N. Via Monte Ave >>Walnut Creek, Ca 94598 >> >>Phone: (925) 926-5332 (tie line 8/473-5332) >>E-Mail:[EMAIL PROTECTED] >>Sametime: (use Lotus Notes address) >>AIM:lbdyck >> >>Linux on 390 Port <[EMAIL PROTECTED]> wrote on 05/13/2002 02:34:34 >>PM: >> >>> Hank, >>> >>> You really don't want to try to manage your Linux/390 guests with SAF. >>It >>> wasn't meant for that, and IBM won't enhance it beyond its current >>> functionality. It was intended solely for the purpose of migrating >from >>VIF >>> to z/VM, and has caused Lionel Dyck an untold amount of grief whenever >>he >>> tries to push it beyond that. It's your choice, of course, but you can >>burn >>> a lot of time trying to get it to do what you need and it's not meant >to >>> provide. >>> >>> Mark Post >>> -Original Message- >>> From: Hank Calzaretta [mailto:[EMAIL PROTECTED]] >>> Sent: Monday, May 13, 2002 5:03 PM >>> To: [EMAIL PROTECTED] >>> Subject: SAF in zVM V4R2 Express Installation >>> >>> >>> Hello, >>> >>> I've just installed zVM V4R2 using the "Express Installation Method". I >>> would like to use the "System Administration Facility" (SAF) to manage >>Linux >>> instances. I sign on as MAINT and issue the command "VMADMCTL START" >>and I >>> get "Unknow CP/CMS Command". Is anyone aware of any special "LINKs" I >>have >>> to do to locate the VMADMCTL or VMADMIN commands? >>> >>> Thanks in advance, >>> Hank Calzaretta
Re: High working set
Lionel: Without the timer patch, Linux wakes up every 100 milliseconds or so. That causes VM to assume it's actually doing something, so its working set never gets trimmed. Your best bet is to apply the timer patch. Romney On Thu, 16 May 2002 09:51:18 -0700 Lionel Dyck said: >Is there any reason for a basically inactive linux guest to have a high vm >working set? > >I have several linux guests under z/vm that for the past 30 minutes have >had zero activity with no users logged in and yet the working set is >fairly high (as reported by velocity softwares esamon). > >thx > >Lionel B. Dyck, Systems Software Lead >Kaiser Permanente Information Technology >25 N. Via Monte Ave >Walnut Creek, Ca 94598 > >Phone: (925) 926-5332 (tie line 8/473-5332) >E-Mail:[EMAIL PROTECTED] >Sametime: (use Lotus Notes address) >AIM:lbdyck
Re: Communicating with "Console" on HMC (SERVC instruction?)
Brad: I'm not aware of any published documentation that describes the integrated console interface. I believe that the intellectual property associated with this interface was released by virtue of its disclosure in the GPL source code for the console driver in Linux for S/390. However, I'm not aware of any associated documentation. Romney On Tue, 21 May 2002 08:42:15 -0400 Snyder, Bradley (LNG) said: >Does anyone know how to send messages to the "console" (i.e. operating >system messages item) on the HMC? Please DO NOT, and I repeat DO NOT >respond to this with any GPL-licensed code examples. I'm looking for a >general description or a pointer in the right direction. The closest I have >come is the SERVC instruction, which is undocumented, and, as far as I can >tell, not supported in GAS. > >Thanks, >--Brad
Re: SuSE 7.0 Installation Telnet Problem
Max: What kind of network. For 802.3 Ethernet, use MTU 1492. Otherwise, use 1500. Smaller is not better; correct is better, so find out how the rest of your network is configured (ask your PC, for example). Romney On Tue, 28 May 2002 19:06:59 -0400 Post, Mark K said: >Max, > >The fact that you're getting traffic back and forth between your desktop and >the system means that the basic configuration is OK: "If I send a wrong >password system send me a message with invalid Login" What might be >keeping you from proceeding with your installation, I really don't know. > >If you can ping your desktop from the SuSE 7.0 system, and the SuSE 7.0 >system from your desktop, that might show you if you're getting very long >network times. What that will tell us I don't know, but hey... > >If you logon with the userid and password of root, you should be able to see >that from the VM console by doing a "ps ax" command. > >Check to make sure you have all your VM TCP/IP maintenance installed. Check >this at http://www.vm.ibm.com/related/tcpip/tclnxsvc.html > > >Mark Post > >-Original Message- >From: Massimiliano Belardi [mailto:[EMAIL PROTECTED]] >Sent: Tuesday, May 28, 2002 4:23 AM >To: [EMAIL PROTECTED] >Subject: Re: SuSE 7.0 Installation Telnet Problem > > >I decreased to 1024 the MTU size but problem isn't solved. Trying a lower >value a get erroro during communication. Is there a suggestion about mtu >size value? Is possible that the problem is caused for some PTF not >installed on VM? I have vmesa 2.3 >I have also another kind of configuration about TCPIP networking. I've not >an OSA attached on VM. I've a ctc connection between VM and OS390 from an IP >addree to an IP address. To communicate between Linux and VM, network >specialist configured a virtual ctc between Linux and another IP address of >VM. So there are two IP on VM environment. One to communicate with OS390 and >one to communicate with Linux. I've some doubt about this conf. May ths >configuration create problem with telnet??? >Thank's to everybody! >Max > > > >- Original Message - >From: "Sergey Korzhevsky" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Friday, May 24, 2002 2:31 PM >Subject: Re: SuSE 7.0 Installation Telnet Problem > > >> Maybe log messages on system console of Linux (under VM 3270 screen) can >> explain your problem. If no, check MTU size of TCP/IP under Linux and VM, >> and decrease it. >> >> >> WBR, Sergey >> >> >> >> Massimiliano >> BelardiTo: [EMAIL PROTECTED] >> > sogei.it> Subject: SuSE 7.0 >Installation Telnet Problem >> Sent by: Linux >> on 390 Port >> <[EMAIL PROTECTED] >> ARIST.EDU> >> >> >> 24.05.02 13:17 >> Please respond >> to Linux on 390 >> Port >> >> >> >> >> >> >> Hello, >> I'm experienced a new "strange" problem. I'm just running the first >istance >> on a VM/ESA 2.3, after run LIN EXEC file, I set up network and root >> password for the installation. After complete the initial configuration, I >> try to telnet with PuTTY to Linux but after send password I receive NO >> response. Netstat command show the connection between Linux and PC where >> I'm trying to login is established. >>Somebody experienced this problem? >> >> Thank's >> Max >> >> PS.. If I send a wrong password system send me a message with invalid >> Login
Re: Kernel 2.4.17 "May 2002 stream" recommended
There's a new contribution to the VM Download library called SHUTTRAP. It provides a mechanism for exploiting the automated shutdown facility from CMS. Enjoy! Romney On Fri, 31 May 2002 11:20:05 -0600 Ferguson, Neale said: >I didn't see any reference in the "Whats New" stuff but I have a patch for >2.4.7 that supports automated shutdown of the Linux system when: > >1. CP SHUTDOWN (z/VM 4.3) >2. CP SIGNAL SHUTDOWN (z/VM 4.3) >3. LPAR shutdown > >is encountered. It uses the SERVC facility to tell VM/LPAR that it is >interested in being informed when the system is going down. At such a time >an external interrupt is received (0x2401 - same as used by hwc) with an >indicator of how long the system has got before the underlying hypervisor >and/or hardware will "vanish". The code, as I've written it, will invoke the >ctrl-alt-del processing. If you have the following entry in /etc/inittab: > ># Powerdown >ca:12345:ctrlaltdel:/sbin/shutdown -t1 -h now > >You should be in business. > >I'm sure IBM are working on their own "all-singing" and "all-dancing" >version that will do a more complete or aesthetically pleasing job, but in >the interim you may find this useful. You may have additional work to do for >2.4.17. snipÙ
Re: Your mail
Jim: DEFINE CPU does not cause a reset. CPUs can be added dynamically, just like the real hardware. Maybe you're thinking of DETACH CPU, which does cause a reset. Romney On Thu, 13 Jun 2002 12:11:39 EDT Jim Elliott said: >From: Nish Deodhar <[EMAIL PROTECTED]> >Subject: Re: Addition of new CPUs > >> I'm not sure if this is even possible, but I've defined additional >> CPUs under VM and would like them enabled for Linux WITHOUT having to >> re-IPL the Linux guest image. Is there a command within Linux or >> otherwise that will let me do this > >Nish: I am not sure what you are asking. > >If you mean that you defined additional virtual CPUs on a Linux image by >updating the directory MACHINE and CPU statements, then you have to >logoff/logon the Linux guest to pick up the new definitions. If you mean >you issued the virtual machine DEFINE CPU command, I thought that would >have caused a CPU reset which would force a re-IPL, but in any case a >re-IPL would be required. > >Regards, Jim
Re: Connecting Linux VM's via Distributed IUCV
Mark: Insofar as your first question is concerned, the last I knew, the VM:* products all expressly prohibit using distributed IUCV (i.e., they specify LOCAL=YES on the IUCV CONNECT). Romney On Thu, 13 Jun 2002 10:53:15 -0500 Mark Wheeler said: >I have customers interested in clustering virtual Linux systems for high >availability. I have VM systems in two different buildings, connected via >ESCON CTCs. The idea is to set up pairs of Linux guests, one in each >building, with the absolute minimum hardware in between. One approach would >be to assign each pair of Linux guests its own CTC address pair, but I >could quickly run out of CTC addresses. Since the two systems already have >an ISFC connection, it would seem that Distributed IUCV would be an >interesting option. I'm hesitant about just setting "DISTRIBUTE IUCV YES" >in SYSTEM CONFIG because of concern about messing up all the traditional >IUCV applications (VM:Secure, VM:Backup, etc), so "DISTRIBUTE IUCV >TOLERATE" looks like a safer choice. >1) Is it safe to assume that traditional IUCV applications will not be >affected if I turn on TOLERATE? >2) Does the Linux IUCV driver support Distributed IUCV connections in >general? >3) Does the Linux IUCV driver support Distributed IUCV connections when >running in TOLERATE mode, which I understand requires that the application >specify the system that it wants to talk to? If yes, how would that be >coded? > >TIA! > >Mark Wheeler >3M Company ( celebrating our 100th anniversary today!)
Re: z800 Storage
Scott: Yes. z/VM supports expanded storage with both its 32-bit and 64-bit Nucleus builds. Romney On Thu, 13 Jun 2002 13:01:16 -0400 Scott Chapman said: >z/OS 64-bit implies no expanded storage. Is z/VM different in that regard? > >Scott Chapman >American Electric Power > > > > >Michael >Short/Towers To: [EMAIL PROTECTED] >Perrincc: >.com> >Sent by: Linux >on 390 Port ><[EMAIL PROTECTED] >ARIST.EDU> > > >06/13/02 11:09 >AM >Please respond >to Linux on 390 >Port > > > > > > >If z/VM and LINUX are to run in 64-bit mode I would use 6 MB main and 2MB >expanded. > >If both are 31-bit mode I would use 2MB main and 6MB expanded. > >If z/VM is in 64-bit mode I would go some higher in main storage to give >storage relief for things the have to be below the 2G line.
Re: Question on HIPERS vs QDIO
Vic: I'm told (by someone who knows duct tape) that Hipersockets Guest LANs perform better than QDIO Guest LANs, largely because the former are synchronous and the latter are asynchronous. However, I don't believe the differences are enough to worry about, particularly if (as you say) broadcast is a consideration. Romney On Fri, 21 Jun 2002 10:27:51 +1000 Vic Cross said: >Phil, > >type=qdio is the new QDIO Guest LAN that emulates a 'real' LAN, including >broadcast support. To Linux it looks like an OSA-Express in QDIO mode. > >type=hiper is the original Guest LAN based on the Hipersockets microcode of >the zSeries. > >Which one you use is likely to depend on the type of application you run -- >specifically, whether you need broadcast support. Just for getting >connectivity between Penguins and a z/VM TCPIP it should not matter greatly >which one you use. > >I'm not aware of performance differences. > >Cheers, >Vic Cross > > >- Original Message - >From: "Philip J. Tully" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Friday, June 21, 2002 12:42 AM >Subject: Question on HIPERS vs QDIO > > >> Cross posted to VMESA-L and Linux-390 lists >> >> Hello all, >> >> I just created an LPAR for development of Linux/390 applications. We >> have installed z/VM 4.3. >> Now VLANs can be created as either type=hiper or type=qdio. >> I was wondering which definition should be used for communication >> amongst linux guests and the VM Tcpip stack? >> Are there performance differences between the 2? >> Are there functional differences now that Hiper supports multicast? >> >> regards >> Phil Tully >>
Re: System "Hang"
Mark: One useful alternative to the standalone dump utility is the VMDUMP command. It produces a core image dump as a spool file that can be loaded onto disk using the CMS DUMPLOAD command and examined using the Dump Viewing Facility and (soon) the VM Dump Tool. While there's no Linux-specific support in the dump readers, developing some would not be a huge effort (they both provide macro facilities and control block mapping functions). Two of the best advantages of VMDUMP are (1) it's always available, and (2) one command (VMDUMP 0-END) gets the information you need in almost all situations. Romney On Sat, 13 Jul 2002 11:47:09 -0400 Post, Mark K said: >Rob, > >I can't help too much with the VM-specific stuff, but I would recommend that >you investigate the Linux/390 2.4 standalone dump utility. If this ever >happens again, and they're going to force the machine off and re-boot it, >they should use the SAD to get some diagnostic information before doing >that. In the past, we've had to do things such as tell operations "if you >don't have any diagnostic data for us, we're not accepting any problems >records," to get the message across. > >Mark Post > >-Original Message- >From: Rob Schwartz [mailto:[EMAIL PROTECTED]] >Sent: Friday, July 12, 2002 4:58 PM >To: [EMAIL PROTECTED] >Subject: System "Hang" > > >We are running SUSE 7.2 in an IFL with z/VM 4.1. On this machine we are >running UDBEE 7.2.Early this morning the machine hung up. I have very >little information to go on. Here is what I have. > >/var/log/messages >After 01:13 there were no new messages. The last message showed an REXEC >session starting. This REXEC is started from an OS/390 machine and has >worked fine for weeks. > >Telnet connections would time-out. > >I do NOT know if the VM user was consuming CPU or doing I/O. > >The machine was recycled and now the REXEC-started procedure works. > >I instructed the people involved with this on how to do an INDICATE USER >command to gather some VM-perspective information. Are there any logs >other than /var/log/messages that could be helpful?Is there something >that I could turn on to further trace activity on the system? > >Regards, >Rob
Re: /proc/dasd/devices
Rob: So doesn't the question become whether the requirement is important enough to warrant a redesign? How important is this requirement, Mark? Romney On Tue, 24 Sep 2002 22:53:36 +0200 Rob van der Heij said: >At 18:49 24-09-02, Post, Mark K wrote: > >>I would like to see a "remove device" command that would go one step further >>and require another "add device" before the volume is usable again. I'm not >>sure why, it just seems "right" to me. Perhaps a little bit of professional >>paranoia. > >With the normal risks that one runs as a messenger... > >The designer of the code feels that this would disturb the mapping of >virtual address to minor number and make it unpredictable. I would >immediately agree that it could have been designed differently, but >it was not. >While it does most of the job for me, the dynamic interface is >dangerous if you use it too casual. > >Rob
Re: Antwort: Max number of dasd devices
World hunger comes to mind. Romney On Wed, 16 Oct 2002 05:21:43 +0800 John Summerfield said: >On Tue, 15 Oct 2002, Mark Perry wrote: > >> I've been trying to understand the headache that Jim mentions relating to >> the lack of devfs support in SuSE zinux. All that devfs buys you is the >> ability to refer to the device address rather than some drive letter in >> non-devfs, and the fact that drive letters get reallocated when device >> addresses are removed and/or added. Thus the real issue is being able to use >> an fstab that contains specific device addresses rather than drive letters, >> right? > >Is there a problem filesystem labels cannot solve? > > >-- > > >Cheers >John. > >Please, no off-list mail. You will fall foul of my spam treatment. >Join the "Linux Support by Small Businesses" list at >http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Re: Proxyarp Challenge (OSA2 FDDI)
Moloko: What level of VM TCP/IP are you running? APAR PQ41584 addressed this problem, but that was in TCP/IP FL 310 and FL 320 and is part of the base of VM TCP/IP in z/VM V4. Romney On Wed, 6 Nov 2002 09:34:48 +0200 Moloko Monyepao said: >I am running the following Redhat 7.2 kernel under VM 4.3 connected via the OSA2 FDDI >network >Linux version 2.4.9-17 ([EMAIL PROTECTED]) (gcc version 2.95.320010315 >(release)) #1 SMP Fri Nov 23 19:45:36 CET 2001 >The following is the challenge I am getting >It appears as if proxy ARP is replying for ARP requests for the wrong MAC/IP address >combination. The machine responds to ARP requests for the 2216's >which causes all connectivity to the production mainframes to fail from devices on >the FDDI ring. The problem can be seen on any UNIX machine on the >FDDI >ring by looking at the ARP table - the IP address for the 2216's point to the test >mainframe instance. When we remove our VM from the ring everything >works fine. > >Any extra info needed I will be happy to provide. > >Thanx >Moloko Monyepao >OS390 System Programmer >arivia.kom >Tel : +27 11 800 3372
Re: Missing telnet output (another stupid newbie question)
Steve: Sounds like you need to turn on local echo in your Telnet client. Romney On Fri, 22 Nov 2002 18:34:17 -0600 Steve Marak said: >Adam, Mark, thanks for your quick responses both of which suggested MTU >size as the culprit. I left it out of my previous post, but we are >explicitly specifying MTU size of 1492 both in the VM TCP/IP config for >that CTC link and when the Linux code boots. (No reason other than that's >what the redbooks suggested.) > >Adam, you'd win the bet about TCPIP maint, however - the VM system has >little maint above the base level. We found the list of recommended >service for running Linux and have pulled it, but haven't yet put it on. >(We didn't build this VM LPAR, and technically don't own it, so we can't >act unilaterally.) > >Since you both immediately pointed to MTU size I need to look at that some >more. (I'll check the Linux settings via ifconfig.) The MTU size for the >link out the other side of VM's TCPIP is defaulted. Given that it will be >a bit before we can apply ip maint, what would you consider the easiest >circumvention? > >Thanks again for your quick replies. > >Steve > > > >On Fri, 22 Nov 2002, Post, Mark K wrote: > >> Steve, >> >> This sounds like an MTU mis-match between the Linux/390 guest and the VM >> TCP/IP stack. Don't default the MTU size in the VM TCP/IP definitions for >> your guest. Define it explicitly. Make it match what the rest of your >> network is expecting. Then, make sure your Linux/390 network definitions >> include that value as well. You can check it with an "ifconfig" command. >> >> Mark Post >> >> -Original Message- >> From: Steve Marak [mailto:[EMAIL PROTECTED]] >> Sent: Friday, November 22, 2002 6:12 PM >> To: [EMAIL PROTECTED] >> Subject: Missing telnet output (another stupid newbie question) >> >... >> But when we telnet into the Linux guest from elsewhere in the network (not >> on the same subnet as either the Linux guest or the VM system due to >> network configuration) things get odd. We are prompted for and provide >> userid and password. Having hit return after entering the password, we >> then show as logged on (according to who or ps from the console). We can >> enter commands and, based on various trials, they are executed just fine. >> But we never see another character of output on the telnet session - no >> shell prompts, no command responses, nothing. >> >> This happens no matter which of several telnet clients we use (including >> putty), which of several terminal types we select (ANSI, VT100, etc.) or >> whether the userid is root or another that we add on the fly (with >> non-zero uid and gid). >... >> Config stuff: SuSE 7 ipl deck from the ISO CD images we downloaded (cat >> /proc/version -> Linux version 2.2.16 ([EMAIL PROTECTED]) (gcc version >> 2.95.2 19991024 (release)) #1 SMP Fri Nov 3 09:38:59 GMT 2000). Booting >> under VM/ESA 2.4, using virtual CTCs for networking via the VM ip stack. >> Network connectivity appears good by every test we've tried. MP3000 P30 >> hardware. > > >-- Steve Marak >-- [EMAIL PROTECTED]
Re: Missing telnet output (another stupid newbie question)
Mark: Well, echo sertainly isn;t the problem, since it's output that isn't appearing, not input (d'Oh), but it isn't MTU size either, since in fact the input is processed just fine, despite the lack of output. Romney On Fri, 22 Nov 2002 19:56:56 -0500 Post, Mark K said: >Romney, > >I hate to argue with you, but the fact that they stop getting responses from >any commands would indicate it's something more than just local echo >problems. If they're not up to maintenance level, it's probably that, >assuming their MTU is really set to 1492 on the Linux/390 end in the MP3000. > >Mark Post > >-Original Message- >From: Romney White [mailto:[EMAIL PROTECTED]] >Sent: Friday, November 22, 2002 7:38 PM >To: [EMAIL PROTECTED] >Subject: Re: Missing telnet output (another stupid newbie question) > > >Steve: > >Sounds like you need to turn on local echo in your Telnet client. > >Romney > >On Fri, 22 Nov 2002 18:34:17 -0600 Steve Marak said: >>Adam, Mark, thanks for your quick responses both of which suggested MTU >>size as the culprit. I left it out of my previous post, but we are >>explicitly specifying MTU size of 1492 both in the VM TCP/IP config for >>that CTC link and when the Linux code boots. (No reason other than that's >>what the redbooks suggested.) >> >>Adam, you'd win the bet about TCPIP maint, however - the VM system has >>little maint above the base level. We found the list of recommended >>service for running Linux and have pulled it, but haven't yet put it on. >>(We didn't build this VM LPAR, and technically don't own it, so we can't >>act unilaterally.) >> >>Since you both immediately pointed to MTU size I need to look at that some >>more. (I'll check the Linux settings via ifconfig.) The MTU size for the >>link out the other side of VM's TCPIP is defaulted. Given that it will be >>a bit before we can apply ip maint, what would you consider the easiest >>circumvention? >> >>Thanks again for your quick replies. >> >>Steve >> >> >> >>On Fri, 22 Nov 2002, Post, Mark K wrote: >> >>> Steve, >>> >>> This sounds like an MTU mis-match between the Linux/390 guest and the VM >>> TCP/IP stack. Don't default the MTU size in the VM TCP/IP definitions >for >>> your guest. Define it explicitly. Make it match what the rest of your >>> network is expecting. Then, make sure your Linux/390 network definitions >>> include that value as well. You can check it with an "ifconfig" command. >>> >>> Mark Post >>> >>> -Original Message- >>> From: Steve Marak [mailto:[EMAIL PROTECTED]] >>> Sent: Friday, November 22, 2002 6:12 PM >>> To: [EMAIL PROTECTED] >>> Subject: Missing telnet output (another stupid newbie question) >>> >>... >>> But when we telnet into the Linux guest from elsewhere in the network >(not >>> on the same subnet as either the Linux guest or the VM system due to >>> network configuration) things get odd. We are prompted for and provide >>> userid and password. Having hit return after entering the password, we >>> then show as logged on (according to who or ps from the console). We can >>> enter commands and, based on various trials, they are executed just fine. >>> But we never see another character of output on the telnet session - no >>> shell prompts, no command responses, nothing. >>> >>> This happens no matter which of several telnet clients we use (including >>> putty), which of several terminal types we select (ANSI, VT100, etc.) or >>> whether the userid is root or another that we add on the fly (with >>> non-zero uid and gid). >>... >>> Config stuff: SuSE 7 ipl deck from the ISO CD images we downloaded (cat >>> /proc/version -> Linux version 2.2.16 ([EMAIL PROTECTED]) (gcc version >>> 2.95.2 19991024 (release)) #1 SMP Fri Nov 3 09:38:59 GMT 2000). Booting >>> under VM/ESA 2.4, using virtual CTCs for networking via the VM ip stack. >>> Network connectivity appears good by every test we've tried. MP3000 P30 >>> hardware. >> >> >>-- Steve Marak >>-- [EMAIL PROTECTED]
Re: Odd TraceRoute To Linux/390 Guests via VM TCPIP
Michael: Run the test with TRACE IPUP IPDOWN ICMP enabled. It looks as though the packet is being dropped by VM TCP/IP. The trace will show what is going on. Romney On Wed, 18 Dec 2002 10:45:19 -0500 Coffin Michael C said: >Hi Rob, > >Yes, pinging works fine to/from the guests. In fact all IP traffic to/from >the guests works fine - but traceroute shows this timeout at .46 (the VM >TCPIP server). I'd just like to understand why it times out and clear it up >if possible. > >I'm not sure what you mean by "the status of the VCTC device". It's pairs >are coupled and working fine or we wouldn't be able to talk between the >Linux/390 and VM TCPIP machines. > >-TIA > >Michael Coffin, VM Systems Programmer >Internal Revenue Service - Room 6527 > Constitution Avenue, N.W. >Washington, D.C. 20224 > >Voice: (202) 927-4188 FAX: (202) 622-3123 >[EMAIL PROTECTED] > > > >-Original Message- >From: Rob Schwartz [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, December 18, 2002 10:43 AM >To: [EMAIL PROTECTED] >Subject: Re: Odd TraceRoute To Linux/390 Guests via VM TCPIP > > >Can you ping from VM to .49? > >What's the status of the VCTC device? > >Can you ping from the .49 Linux machine to .46? > > >Robert C Schwartz >Technical Services >Boscovs Department Stores LLC >610-929-7387 >[EMAIL PROTECTED] > >- Original Message - >From: "Coffin Michael C" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Wednesday, December 18, 2002 10:20 AM >Subject: Re: Odd TraceRoute To Linux/390 Guests via VM TCPIP > > >> Arrggh - I have guests at both .49 and .50, I evidently included the >> trace to .49 (same results). Strike .50 in my note and replace it >> with .49 >(sorry >> for the confusion). >> >> Michael Coffin, VM Systems Programmer >> Internal Revenue Service - Room 6527 >> Constitution Avenue, N.W. >> Washington, D.C. 20224 >> >> Voice: (202) 927-4188 FAX: (202) 622-3123 >> [EMAIL PROTECTED] >> >> >> >> -Original Message- >> From: Rob Schwartz [mailto:[EMAIL PROTECTED]] >> Sent: Wednesday, December 18, 2002 10:21 AM >> To: [EMAIL PROTECTED] >> Subject: Re: Odd TraceRoute To Linux/390 Guests via VM TCPIP >> >> >> Hey Michael, >> >> Am I missing something here... What is 152.225.118.49 >> >> Rob >> >> Robert C Schwartz >> Technical Services >> Boscovs Department Stores LLC >> 610-929-7387 >> [EMAIL PROTECTED] >> >> - Original Message - >> From: "Michael Coffin" <[EMAIL PROTECTED]> >> To: <[EMAIL PROTECTED]> >> Sent: Wednesday, December 18, 2002 10:02 AM >> Subject: Odd TraceRoute To Linux/390 Guests via VM TCPIP >> >> >> > (Crossposted on VMESA-L and Linux-VM) >> > >> > Hi Folks, >> > >> > I'm in the process of implementing gigabit ethernet for a client and >> > am very curious about something. I have a TCPIP stack on VM (VM/ESA >> > 2.4.0) with a dedicated gigabit card at IP address 152.225.118.46. >> > I have a Linux/390 guest virtual machine VCTC coupled to this TCPIP >> > virtual machine at IP address 152.225.118.50. Take a look at the >> > traceroute below, when I trace to .46 it's nice and clean. However >> > when I trace to .50 .46 times out. Any idea what causes this? VM's >> > TCPIP is proxyarping for these guests, by the way. >> > >> > I:\>tracert 152.225.118.46 >> > >> > Tracing route to 152.225.118.46 over a maximum of 30 hops >> > >> > 1 <10 ms <10 ms <10 ms 152.225.39.2 >> > 2 <10 ms <10 ms <10 ms 152.225.119.194 >> > 3 <10 ms <10 ms <10 ms 152.225.46.36 >> > 4 <10 ms <10 ms <10 ms 152.225.118.46 >> > >> > Trace complete. >> > >> > I:\>tracert 152.225.118.49 >> > >> > Tracing route to 152.225.118.49 over a maximum of 30 hops >> > >> > 1 <10 ms <10 ms <10 ms 152.225.39.2 >> > 2 <10 ms <10 ms <10 ms 152.225.119.194 >> > 3 <10 ms <10 ms <10 ms 152.225.46.36 >> > 4 *** Request timed out. >> > 5 <10 ms <10 ms <10 ms 152.225.118.49 >> > >> > Trace complete. >> > >> > Thanks in advance. :) >> > >> > -Michael Coffin
Re: Odd TraceRoute To Linux/390 Guests via VM TCPIP
Michael: This looks fine. What we're interested in finding in the trace output is the reception and handling of the packet that TRACERTE sends to the VM system (the one that times out). Romney On Wed, 18 Dec 2002 12:19:34 -0500 Coffin Michael C said: >Hi Romney, > >I ran a trace which is too big to include here, but I'm seeing "Passed Route >F" and "DontRoute F" in the trace, here's a snip: > >DTCPDO065I DispatchDatagram: Dest 152.225.118.49, protocol 17 dispatch mode >0, P >assed Route F, DontRoute F > >DTCPDO066I DispatchDatagram releases LastRouteEntry > >DTCPDO080I FindRoute looking for route for: 152.225.118.49 > >DTCPDO077I FindRoute found HostRTE for 152.225.118.49 on interface CTC504 > >DTCPDO067I DispatchDatagram allocates LastRouteEntry > >DTCPDO044I Ipdown: Link: Link Name: CTC504, Link Type: CTC, Dev Name: >CTC504, De >v Type: CTC, Queuesize: 0 > >DTCPDO046I Ipdown: FirstHop 152.225.118.49 > >DTCPDO027I IP-down: ShouldFragment: Datagram: 78 Packet size:1492 >DTCPRC001I version: 4 >DTCPRC002I Internet Header Length: 5 = 20 bytes >DTCPRC009I Type of Service:Precedence = Routine >DTCPRC010I Total Length: 78 bytes >DTCPRC011I Identification: 37557 >DTCPRC009I Flags: May Fragment, Last Fragment >DTCPRC009I Fragment Offset: 0 >DTCPRC019I Time To Live: 124 >DTCPRC020I Protocol: UDP >DTCPRC021I Header CheckSum: 56509 >DTCPRC022I Source Address: 98E12738 >DTCPRC023I Destination Address: 98E17631 >DTCIPU031IIP-up examining: >DTCPRC001I version: 4 >DTCPRC002I Internet Header Length: 5 = 20 bytes >DTCPRC009I Type of Service:Precedence = Internetwork control >DTCPRC010I Total Length: 106 bytes >DTCPRC011I Identification: 1057 >DTCPRC009I Flags: May Fragment, Last Fragment >DTCPRC009I Fragment Offset: 0 > >DTCPRC019I Time To Live: 255 > >DTCPRC020I Protocol: ICMP > >DTCPRC021I Header CheckSum: 59269 > >DTCPRC022I Source Address: 98E17631 > >DTCPRC023I Destination Address: 98E12738 > >DTCIPU037IIP-up: datagram ID 1057, len 106, Protocol ICMP from >152.225.118.4 >9 > >DTCIPU040IIP-up: forward datagram > >DTCPDO065I DispatchDatagram: Dest 152.225.39.56, protocol 1 dispatch mode 0, >Pas >sed Route F, DontRoute F > >DTCPDO066I DispatchDatagram releases LastRouteEntry > >DTCPDO080I FindRoute looking for route for: 152.225.39.56 > >DTCPDO077I FindRoute found DefaultRTE for * on interface SHUTTLE3 > >DTCPDO067I DispatchDatagram allocates LastRouteEntry > >DTCPDO044I Ipdown: Link: Link Name: SHUTTLE3, Link Type: ETHERNET, Dev Name: >SHU >TTLE3, Dev Type: LCS, Queuesize: 0 > >DTCPDO046I Ipdown: FirstHop 152.225.118.1 > > >In the trace "SHUTTLE3" is our gigabit connection, 152.225.39.56 is the IP >address of the Win2K workstation I ran the tracert from, 152.225.118.49 is >the address I was tracing (a Linux/390 guest VCTC'd to the TCPIP at >152.225.118.46). > >Is this perhaphs because I have not provided explicit routing, but rather >use the "DefaultRoute" in VM's TCPIP configuration? > > >Michael Coffin, VM Systems Programmer >Internal Revenue Service - Room 6527 > Constitution Avenue, N.W. >Washington, D.C. 20224 > >Voice: (202) 927-4188 FAX: (202) 622-3123 >[EMAIL PROTECTED] > > > >-Original Message- >From: Romney White [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, December 18, 2002 10:59 AM >To: [EMAIL PROTECTED] >Subject: Re: Odd TraceRoute To Linux/390 Guests via VM TCPIP > > >Michael: > >Run the test with TRACE IPUP IPDOWN ICMP enabled. It looks as though the >packet is being dropped by VM TCP/IP. The trace will show what is going on. > >Romney > >On Wed, 18 Dec 2002 10:45:19 -0500 Coffin Michael C said: >>Hi Rob, >> >>Yes, pinging works fine to/from the guests. In fact all IP traffic >>to/from the guests works fine - but traceroute shows this timeout at >>.46 (the VM TCPIP server). I'd just like to understand why it times >>out and clear it up if possible. >> >>I'm not sure what you mean by "the status of the VCTC device". It's >>pairs are coupled and working fine or we wouldn't be able to talk >>between the Linux/390 and VM TCPIP machines. >> >>-TIA >> >>Michael Coffin, VM Systems Programmer >>Internal Revenue Service - Room 6527 >> Constitution Avenue, N.W. >>Washington, D.C. 20224 >> >>Voice: (202) 927-4188 FAX: (202) 622-3123 >>[EMAIL PROTECTED] >> >> >> >>-Orig
Re: Odd TraceRoute To Linux/390 Guests via VM TCPIP
Michael: Well, it's likely that VM dropped the packet. You should look for ICMP packets with a destination address of 152.225.118.46. If you'd like me to look at it, you can send the trace via anonymous FTP to our drop-off site (testcase.boulder.ibm.com/s390/toibm/vm). Transfer the file in binary and COPYFILE (PACK it first. Romney On Wed, 18 Dec 2002 12:30:14 -0500 Coffin Michael C said: >Hi Romney, > >That's just it, I don't see anything in the VM TCPIP trace that suggests a >timeout (at least no verbage that clearly says "timed out" or anything like >that). Is there a keyword I can use to scan for that would indicate a >timeout? Maybe it's there and I'm just not seeing it (the trace is very >chatty, just running it for a few seconds generates thousands of lines of >trace data). > >Michael Coffin, VM Systems Programmer >Internal Revenue Service - Room 6527 > Constitution Avenue, N.W. >Washington, D.C. 20224 > >Voice: (202) 927-4188 FAX: (202) 622-3123 >[EMAIL PROTECTED] > > > >-Original Message- >From: Romney White [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, December 18, 2002 12:30 PM >To: [EMAIL PROTECTED] >Subject: Re: Odd TraceRoute To Linux/390 Guests via VM TCPIP > > >Michael: > >This looks fine. What we're interested in finding in the trace output is the >reception and handling of the packet that TRACERTE sends to the VM system >(the one that times out). > >Romney > >On Wed, 18 Dec 2002 12:19:34 -0500 Coffin Michael C said: >>Hi Romney, >> >>I ran a trace which is too big to include here, but I'm seeing "Passed >>Route F" and "DontRoute F" in the trace, here's a snip: >> >>DTCPDO065I DispatchDatagram: Dest 152.225.118.49, protocol 17 dispatch >>mode 0, P assed Route F, DontRoute F >> >>DTCPDO066I DispatchDatagram releases LastRouteEntry >> >>DTCPDO080I FindRoute looking for route for: 152.225.118.49 >> >>DTCPDO077I FindRoute found HostRTE for 152.225.118.49 on interface >>CTC504 >> >>DTCPDO067I DispatchDatagram allocates LastRouteEntry >> >>DTCPDO044I Ipdown: Link: Link Name: CTC504, Link Type: CTC, Dev Name: >>CTC504, De v Type: CTC, Queuesize: 0 >> >>DTCPDO046I Ipdown: FirstHop 152.225.118.49 >> >>DTCPDO027I IP-down: ShouldFragment: Datagram: 78 Packet size:1492 >>DTCPRC001I version: 4 >>DTCPRC002I Internet Header Length: 5 = 20 bytes >>DTCPRC009I Type of Service:Precedence = Routine >>DTCPRC010I Total Length: 78 bytes >>DTCPRC011I Identification: 37557 >>DTCPRC009I Flags: May Fragment, Last Fragment >>DTCPRC009I Fragment Offset: 0 >>DTCPRC019I Time To Live: 124 >>DTCPRC020I Protocol: UDP >>DTCPRC021I Header CheckSum: 56509 >>DTCPRC022I Source Address: 98E12738 >>DTCPRC023I Destination Address: 98E17631 >>DTCIPU031IIP-up examining: >>DTCPRC001I version: 4 >>DTCPRC002I Internet Header Length: 5 = 20 bytes >>DTCPRC009I Type of Service:Precedence = Internetwork control >>DTCPRC010I Total Length: 106 bytes >>DTCPRC011I Identification: 1057 >>DTCPRC009I Flags: May Fragment, Last Fragment >>DTCPRC009I Fragment Offset: 0 >> >>DTCPRC019I Time To Live: 255 >> >>DTCPRC020I Protocol: ICMP >> >>DTCPRC021I Header CheckSum: 59269 >> >>DTCPRC022I Source Address: 98E17631 >> >>DTCPRC023I Destination Address: 98E12738 >> >>DTCIPU037IIP-up: datagram ID 1057, len 106, Protocol ICMP from >>152.225.118.4 >>9 >> >>DTCIPU040IIP-up: forward datagram >> >>DTCPDO065I DispatchDatagram: Dest 152.225.39.56, protocol 1 dispatch >>mode 0, Pas sed Route F, DontRoute F >> >>DTCPDO066I DispatchDatagram releases LastRouteEntry >> >>DTCPDO080I FindRoute looking for route for: 152.225.39.56 >> >>DTCPDO077I FindRoute found DefaultRTE for * on interface SHUTTLE3 >> >>DTCPDO067I DispatchDatagram allocates LastRouteEntry >> >>DTCPDO044I Ipdown: Link: Link Name: SHUTTLE3, Link Type: ETHERNET, Dev >>Name: SHU TTLE3, Dev Type: LCS, Queuesize: 0 >> >>DTCPDO046I Ipdown: FirstHop 152.225.118.1 >> >> >>In the trace "SHUTTLE3" is our gigabit connection, 152.225.39.56 is the >>IP address of the Win2K workstation I ran the tracert from, >>152.225.118.49 is the address I was tracing (a Linux/390 guest VCTC'd >>to the TCPIP at 152.225.118.46). >> >>Is this perhaphs because I have not provided explicit
Re: 3270 emulation packages
Mark: That's one answer, but the other is to use a 2074, which allows you to Telnet to your host and look like a locally attached 3270 device, which is what z/VM requires for installation. Romney On Wed, 8 Jan 2003 17:57:11 -0500 Post, Mark K said: >Well, then you have your answer. :) > >Mark Post > >-Original Message- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, January 08, 2003 12:37 PM >To: [EMAIL PROTECTED] >Subject: Re: 3270 emulation packages > > >Right. That is our problem. :) We need to get z/VM installed. > > >On Wed, 2003-01-08 at 17:41, Post, Mark K wrote: >> You need one to perform the z/VM installation. You do not need one for >> normal day to day operations. >> >> Mark Post >> >> -Original Message- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] >> Sent: Wednesday, January 08, 2003 12:25 PM >> To: [EMAIL PROTECTED] >> Subject: Re: 3270 emulation packages >> >> >> it is absolutely necessary to have a 3174 controller with a console >> attached to manage/control z/VM? I know on the newer s/390s you can >> have a terminal emulated right on the HMC that can be used as a >> console. Can anyone offer input on this? >> >> - Jason Herne
Re: SuSE patch-3858
Mark: I think it's probably referring to z/VM TCP/IP APAR PQ34318. However, that doesn't look to me like the problem you're having. Refer to http://www.vm.ibm.com/related/tcpip/tclnxsvc.html#lxsstack for details about recommended TCP/IP stack service. Romney On Fri, 10 Jan 2003 16:45:48 -0500 Mark D Pace said: >I've applied SuSE kernel patch-3858. When you apply it there is a note >that you should be sure that have applied the latest VM APAR. >Well once I apply the patch, run zipl and reboot , my VCTC adapter to VM >stops working. See output below. >My question is - What APAR are they referring to? There is no mention of >the number. I have z/VM 3.1 service level 0101. As far as I know that is >the latest RSU. I have had no luck getting a response from SuSE. > > >Setting up network device ctc0:" >insmod: /lib/modules/2.4.7-SuSE-SMP/kernel/drivers/s390/net/ctc.o: insmod >ctc0 >SIOCSIFADDR: No such device" >insmod: /lib/modules/2.4.7-SuSE-SMP/kernel/drivers/s390/net/ctc.o: insmod >ctc0 >ctc0: unknown interface: No such device" >insmod: /lib/modules/2.4.7-SuSE-SMP/kernel/drivers/s390/net/ctc.o: in >SIOCSIFDSTADDR: No such device" >insmod: /lib/modules/2.4.7-SuSE-SMP/kernel/drivers/s390/net/ctc.o: insmod >ctc0 >ctc0: unknown interface: No such device" >insmod: /lib/modules/2.4.7-SuSE-SMP/kernel/drivers/s390/net/ctc.o: insmod >ctc0 >SIOCSIFMTU: No such device" >insmod: /lib/modules/2.4.7-SuSE-SMP/kernel/drivers/s390/net/ctc.o: in >ctc0: unknown interface: No such device" >..failed" >Waiting for connection on ctc0.insmod: >/lib/modules/2.4.7-SuSE-SMP/kernel/drive >ctc0: error fetching interface information: Device not found" >usage: ping [-DdfLnqRrv] [-c count] [-I ifaddr] [-i wait]" >[-l preload] [-p pattern] [-s packetsize] [-t ttl] [-w maxwait] >host" > > >Mark D Pace >Senior Systems Engineer >Mainline Information Systems >1700 Summit Lake Drive >Tallahassee, FL. 32317 >[EMAIL PROTECTED] >Office: 850.219.5184 >Fax: 850.219.5050 >http://www.mainline.com
Re: 2074 and the HMC
I'm pretty sure we understand the need. A formal SHARE requirement is unnecessary (though whether one is written is, of course, up to the user community). Romney On Wed, 15 Jan 2003 11:37:24 -0500 Peter Webb, Toronto Transit Commission said: >Sounds like someone needs to start writing a SHARE requirement! > >> -Original Message- >> From: Robert Morrison [SMTP:[EMAIL PROTECTED]] >> Sent: Wednesday, January 15, 2003 11:31 AM >> To: [EMAIL PROTECTED] >> Subject: Re: 2074 and the HMC >> >> Actually, IBM has come close in the past. >> >> The MP3000 service element (not HMC) did provide this functionality. As >> far as I know, it was the predecessor to the 2074. In fact the >> configuration program and file in the 2074 are the same as what you would >> see in the Service element in the MP3000. >> >> You were / are able to configure a virtual channel and virtual devices via >> the microcode of the 3000 enabling you to create these 3270 sessions >> without the expense of the 2074 and or 3x74. The design of the zSeries, >> although it supports virtual coupling facility links does not have the >> same feature for it's Service elements. >> >> My hope is that some day in the not so distant future, this virtual >> feature will be there. >> >> Bob Morrison >> >> >> >> >> >> - >> Do you Yahoo!? >> Yahoo! Mail Plus - Powerful. Affordable. Sign up now
Re: VLAN not supported?
Brian: It sounds as though you got HiperSockets *Guest LAN* working. Hipersockets (real or virtual) currently does not support IEEE 802.1q VLAN, and in z/VM 4.2, it does not support multicast (z/VM 4.3 adds this, as well as QDIO type Guest LANs, which support broadcast). That's what the Linux messages are reporting. Romney On Fri, 24 Jan 2003 09:55:05 -0700 Jones, Brian P said: >We finally got VLAN working on SLES8... It's the best thing to come out >since Logon HERE! >Anyway I am curous as to why I am getting apparent failures out of qeth yet >all seems to work ok (haven't tested broadcast). >Is anyone else seeing these "not supported" messages? >qeth: Trying to use card with devnos 0x7000/0x7001/0x7002 >qdio : Adapter interruption facility not installed. >qdio : Not all CHSCs supported. Continuing. >qeth: Device 0x7000/0x7001/0x7002 is a HiperSockets card with link type >magic (portname: ) >qeth: VLAN not supported on hsi0 >qeth: multicasting not supported on hsi0 >qeth: IPv6 not supported on hsi0 >qeth: Broadcasting not supported on hsi0 >IP/Netmask: 129.80.45.228 / 255.255.255.224 ..done >Thanks in advance, >Brian Jones >(303) 661-4626 phone >StorageTek >INFORMATION made POWERFUL
Re: URGENT! really low performance. A related question...
Leland: One method is to duplicate the disk and apply your changes to the copy. When you are happy that what you have is what you want, change the User Directory entries of all the guests who use the shared disk to LINK to the new one or simply interchange the addresses of the two mindisisks in the owning user's directory entry. As the sharing Linux guests recycle over the next period of time, their use of the old disk will fade away until eventually it becomes available to hold the next version of its contents. The QUERY LINKS command will show you who is using which disk. This has the advantage of letting you customize it at your leisure and put new applications into production only when you're ready. Romney On Wed, 19 Feb 2003 10:39:25 -0600 Lucius, Leland said: >> With disk sharing and VM, the apparent outage for maintenance >> of Linux can be "virtually" eliminated. >> >Forgive me for being dumb here, but I'd like to ask "How?" If you're >sharing a VM minidisk among several Linux guests, how can you update the >contents without having all of the guests brought down? > >Thanks, > >Leland
Re: Kernel patch to add VM IPL PARM support
Lucius: The string provided by z/VM is terminated by a byte of binary zero, at least according to the CP Command and Utility Reference. If it is, it should be easy to find the end of the values supplied on IPL.I would recommend ensuring the high-order byte of GR0 is zero when the SAVESYS command is issued to create the NSS. The "case thing" is a problem if you issue the IPL command manually. In an EXEC, you can pass the parameter value in the case you prefer. Romney On Wed, 5 Mar 2003 19:12:46 -0600 Lucius, Leland said: >Sorry, I took so long to get back. "Real" work go in the way of all my fun >today. I hate when that happens. ;-) > >> >> The patch seems to work, although I tend to get junk at the end of the >> parm line if I specify it, and the capitalization all goes away. >> >> For example, if I do >> >> ipl deb24m parm line VMPOFF='IPL CMS' >> >> what shows up is >> >> Kernel command line: root=/dev/dasd/0150/part1 ro noinitrd >> dasd=0150-015f vmpoff="LOGOFF" vmpoff='ipl cms'1 q >> >> So, what's that '1 q' doing at the end? And how can I make the parm >> line respect my capitalization (that's probably a CMS thing, >> isn't it?)? >> >When you did the DEFSYS, did you include the PARMREGS=0-15 parameter? >Leaving it off does work, but CP doesn't terminate the parms with a hex zero >which is required by the patch. Including PARMREGS=0-15 causes CP to clear >all registers to zero before loading the IPL PARMs. > >The case thing IS indeed a problem. It places some restrictions on what can >be included in the IPL PARMs. CP seems to convert the entire command line >to uppercase before processing it. Unfortunately, most kernel parameters >are expected to be in lowercase. So, the patch converts the parms to >lowercase when appending to the kernel parameters. I wish I knew a way to >get around it, but I couldn't find anything in the books. > >Leland
Re: Kernel patch to add VM IPL PARM support
Leland: If you don't specify PARMREGS then you don't get a trailing X'00'. And, you only get a trailing X'00' if the PARM is shorter than the size that the PARMREGS value implies. The documentation doesb't say this, but the code does. Romney On Wed, 5 Mar 2003 22:00:38 -0600 Lucius, Leland said: >> -----Original Message- >> From: Romney White [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, March 05, 2003 7:49 PM >> To: [EMAIL PROTECTED] >> Subject: Re: Kernel patch to add VM IPL PARM support >> >> >> Lucius: >> >> The string provided by z/VM is terminated by a byte of binary zero, at >> least according to the CP Command and Utility Reference. If it is, it >> should be easy to find the end of the values supplied on IPL.I would >> recommend ensuring the high-order byte of GR0 is zero when the SAVESYS >> command is issued to create the NSS. >> >I'd read that bit in the manual too, but when Adam got the garbage at the >end of the kernel parms, I thought I'd verify it for myself. > >So, I set a trace and started up Linux: > >tr i r 1 >Ready; T=0.01/0.01 03:28:53 > >i 4000 clear >Tracing active at IPL > -> 0001 LM980F01800180CC 0 > >Took a look at the registers, and, de to the "clear", zeros made since : > >d g0-3 >GPR 0 = > >So, I set GR0-3 to a known value of x'': > >st g0 g1 g2 g3 >Store complete. > >d g0-3 >GPR 0 = > >And saved the system (without PARMREGS): > >defsys LX24M 0-ff ew 100-2ff sr 300-4ff ew minsize=64m >HCPNSD440I The Named Saved System (NSS) LX24M was successfully defined >in fileid 0073. > >savesys LX24M >HCPNSS440I Named Saved System (NSS) LX24M was successfully saved in >fileid 0073. > >To show that the registers were truly saved with x'', I IPL'd the >NSS and took a look: > >tr all > >i LX24M >Tracing active at IPL >00010004 STM 900F0180 >> 0180CC 0 > >d g0-3 >GPR 0 = > >So, now for the true test: > >i LX24M parm 123 >Tracing active at IPL > -> 00010004 STM 900F0180 >> 0180CC 0 > >d g0-3 >GPR 0 = F1F2F3FF > >You'll notice that an x'00' is NOT supplied at the end of the PARM value as >is indicated by the manual. Suprised the heck out of me, but it certainly >explained why Adam was getting the garbage characters. > >You're suggestion of setting the high byte of GR0 would work for the case >when no PARMs were supplied, but the idea would need to be extended to all >registers in case any PARMs were supplied to ensure a null terminated >string. PARMREGS=0-15 seems to take care of this, but either way would work >fine. (As does the IPL ... CLEAR.) > >> The "case thing" is a problem if you issue the IPL command >> manually. In >> an EXEC, you can pass the parameter value in the case you prefer. >> >Excellent and bummer. It's great that there's an ASIS way of doing it, but >the bummer is now I gotta figure out how to handle it in the kernel for both >cases. > >Thanks much, > >Leland
Re: IFL speed.
Rich: They are not just supposed to be the same speed - they are :-) (with the exception you noted). Romney On Thu, 6 Mar 2003 11:21:10 -0600 Rich Smrcina said: >They are supposed to be the same speed as the other engines. Except in the >case of the MP3000, which has a full speed IFL (as opposed to the H30 engine >which is half speed) > >On Thursday 06 March 2003 11:04 am, you wrote: >> Hello all, >> >> Are IFL engines slowed down compared to a GP engine? >> >> Phil > >-- >Rich Smrcina >Sr. Systems Engineer >Sytek Services, A Division of DSG >Milwaukee, WI >[EMAIL PROTECTED] >[EMAIL PROTECTED] > >Catch the WAVV! Stay for Requirements and the Free for All! >Update your S/390 skills in 4 days for a very reasonable price. >WAVV 2003 in Winston-Salem, NC. >April 25-29, 2003 >For details see http://www.wavv.org
Re: ESALPS vs. VMRTM/VMPRF
Performance Toolkit *is* FCON with added function. Romney On Thu, 12 Jun 2003 16:46:22 -0400 David Boyes said: >> Has anyone running Linux under VM attempted to compare or evaluate the >> differences between the Velocity Software's ESALPS and IBM's VMRTM/VMPRF? > >RTM and PRF are going away, replaced by the Performance Toolkit (aka >FCON/ESA). > >> What were your conclusions as far as function and value? > >ESALPS has far more features (in general, it's probably the most >comprehensive VM-hosted monitor and performance tool), but like most >powerful tools, the learning curve to master it is fairly steep. >Fortunately, Barton is usually available to help you through that part. > >FCON is probably easier to learn and use (and I find the interface a little >more intuitive), but it doesn't do quite as much. > >Performance Toolkit is probably cheaper, but it's like any tool -- you get >what you pay for. > >-- db
Re: ESALPS vs. VMRTM/VMPRF
Yes, and then by my reading you went on to say that somehow there was a difference in function and ease of use in FCON's favor, apparently because it is more expensive than the toolkit. Romney On Thu, 12 Jun 2003 20:44:44 -0400 David Boyes said: >On Thu, Jun 12, 2003 at 09:15:05PM -0400, Romney White wrote: >> Performance Toolkit *is* FCON with added function. >> Romney > >Which is exactly what I said. > >> On Thu, 12 Jun 2003 16:46:22 -0400 David Boyes said: > >> >RTM and PRF are going away, replaced by the Performance Toolkit (aka >> >FCON/ESA). > > >-- db
Re: z/Linux and Parallel Sysplex [was Linux390 + VM + Tape 3490]
All it takes is for Linux to issue the appropriate Assign and Unassign channel commands to the shared tape. Sysplex would be serious overkill. Romney On Fri, 13 Jun 2003 12:46:28 -0500 James Melin said: >I am forking this particular item because mostly, my deep dark subconscious >floated a question up to my rational mind, and I have decided to ask it >here... > >What would it take to allow/have/make z/Linux cooperate in a parallel >sysplex environment, so that tape devices in use by os/390, could also be >used by Linux without having to vary devices off-line to z/OS to use on >z/Linux and vice versa. > >I know this is a nontrivial undertaking, I'm just wondering if it would be >useful to provide parallel sysplex participation for tape devices in a >mixed bag environment.
Re: Mach in user direct
Mark: Maybe it was incorrectly defined as an XC-mode guest. Romney On Thu, 2 Oct 2003 13:38:37 -0400 Post, Mark K said: >Something about this rings a bell. Someone recently had a problem, and the >fix was to define the Linux guest as a machine type of ESA, not XA. I can't >remember if that came up on this list, or in a private email. I'll do some >poking around and see if I can find the note. > > >Mark Post > >-Original Message- >From: Rich Smrcina [mailto:[EMAIL PROTECTED] >Sent: Thursday, October 02, 2003 11:11 AM >To: [EMAIL PROTECTED] >Subject: Re: Mach in user direct > > >According to z/VM 4.3 CP Planning and Administration under the MACHINE >statement of the user directory: > >XA >designates an XA virtual machine, which is functionally equivalent to an >ESA virtual machine. > >On Thu, 2003-10-02 at 07:34, Daniel Jarboe wrote: >> We are running linux images with 31 bit addressing under z/VM. The >> machine arch for our linux images has been defined by our VM sysprog as >> XA. Is there any disadvantage/advantage of this vs. ESA or some other >> architecture as far as the linux images are concerned? My initial >> thought was that the compiler/assembler may choose different >> instructions for increased effeciency depending on the architecture it's >> building for, but I don't know if there's any truth to that thought or >> if there'd even be any differences. Is there any reason to change the >> architecture, and if so, could the change have any adverse impact? >> >> Thanks, >> ~ Daniel >> >> >> >> >> >> >> --- >> >> This message is the property of Time Inc. or its affiliates. It may be >> legally privileged and/or confidential and is intended only for the use >> of the addressee(s). No addressee should forward, print, copy, or >> otherwise reproduce this message in any manner that would allow it to be >> viewed by any individual not originally listed as a recipient. If the >> reader of this message is not the intended recipient, you are hereby >> notified that any unauthorized disclosure, dissemination, distribution, >> copying or the taking of any action in reliance on the information >> herein is strictly prohibited. If you have received this communication >> in error, please immediately notify the sender and delete this message. >> Thank you. >-- >Rich Smrcina >Sr. Systems Engineer >Sytek Services - A Division of DSG >Milwaukee, WI >rsmrcina at wi.rr.com >rsmrcina at dsgroup.com > >Catch the WAVV! Stay for requirements and the free-for-all. >Update your zSeries skills in 4 days for a very reasonable price. >WAVV 2004 in Chattanooga, TN >April 30-May 4, 2004 >For details see http://www.wavv.org
Re: SCO Attacks Open Source License
Adam: On behalf of all Canadians, I request that you please visit http://22minutes.com/realwrapper.php?target=apology_256.rm We're all sorry. Really. And keep your head up, especially on the ice. Romney On Tue, 4 Nov 2003 09:19:47 -0600 Adam Thornton said: >On Tue, 2003-11-04 at 09:10, McKown, John wrote: >> What do you have against Canada? > >"It's not even a real country, anyway!" > >Adam > >P.S. If you haven't heard the song "Blame Canada" from the _South Park_ >movie, you really should go find it and give it a listen.
Re: First time Linux install
Mark: VSWITCH has an *optional* associated OSA Express device. If you don't have one, you don't have external connectivity, but a VSWITCH is just really a QDIO Guest LAN with an optional associated real QDIO device. Romney On Wed, 3 Dec 2003 18:18:22 -0500 Post, Mark K said: >Hmm. I didn't realize the Vswitch needed a real OSA card. Bummer. > > >Mark Post > >-Original Message- >From: Adam Thornton [mailto:[EMAIL PROTECTED] >Sent: Wednesday, December 03, 2003 6:11 PM >To: [EMAIL PROTECTED] >Subject: Re: First time Linux install > > >On Wed, 2003-12-03 at 16:45, Post, Mark K wrote: >> Your MP3K should work fine for your testing. If it's very heavily loaded >> performance for your Linux/390 workload may not be acceptable. If you can >> get approval, you'll want to upgrade your system to z/VM 4.4. That will >get >> you a lot of very nice features such as Guest LANs, Virtual Switches, etc. > >You won't get VSWITCH. > >That's because it relies on a real OSA-Express to do its magic and I'm >thinking that's going to be tough to manage on a Multiprise. > >But you do get Guest LANs, which are absolutely marvellous. > >Adam
Re: First time Linux install
Adam: A VSWITCH has a few other unique characteristics compared to a Guest LAN (IEEE VLAN support, for example) but that wasn't my point. It was that you get VSWITCH support on any platform that supports z/VM. Romney On Wed, 3 Dec 2003 19:20:52 -0600 Adam Thornton said: >On Wed, 2003-12-03 at 18:54, Romney White wrote: >> Mark: >> >> VSWITCH has an *optional* associated OSA Express device. If you don't >> have one, you don't have external connectivity, but a VSWITCH is just >> really a QDIO Guest LAN with an optional associated real QDIO device. > >Fair enough, but isn't the point of the VSWITCH to bridge your Linux >guests into an external LAN, rather than VM (or Linux) having to act as >a router? In which case, a VSWITCH without external connectivity is, >well, a guest LAN, innit? > >Adam
Re: Technical Specs
Tom: Actually, I believe the answer is "It monitors itself". Romney On Wed, 10 Dec 2003 11:19:14 -0600 Tom Duerbusch said: >You can't anymore? The IBM 4341 use to show you its temperature when >you went into CEKEY mode on the console. > >Tom Duerbusch >THD Consulting > >This question is right up there with the one our ops manager wanted to >know: >"How do I monitor the z800's CPU temperature like I do the Intel >servers?" >Answer: "You don't" > > >>
Re: Format disk and mount FS : lost space
I assume that other disk architectures simply don't report the amount of waster space per track because it isn't accessible (e.g., on SCSI disk). The very real benefits of being able to write variable-length blocks on a disk is something the Unix crowd hasn't discovered, I guess. Romney On Thu, 18 Mar 2004 13:23:08 -0500 Daniel Jarboe said: >Carsten Otte wrote: >> Daniel wrote: >> >The larger the number of cyls for the device, the worse the >> ratio gets :(. >> >> That's not true: CDL uses track0 and track1 for internal purposes, the >> rest (number of 4k blocks that fit on a track multiplied with amount >of >> tracks) is available for partitions. For people who do not like that >> overhead can just use LDL which only uses 2 blocks (8 kilobytes) as >> overhead. > >Sorry to be unclear, I was referring to the 49152 bytes/track (12 * 4K) >vs. the true 56664 bytes/track for emulated/real ECKD devices, not the >CDL/partition overhead. > >I said, "The CDL, partition, filesystem/journal overhead is really quite >tiny in comparison." > >The whole comment about the ratio getting worse as volume size increases >was due to: >A1. CDL/partition overhead is fixed, no increase in overhead. >A2. Journal overhead is fixed, unless you use a larger journal. >A3. Filesystem overhead may vary with the data, but again tiny compared >to... > >B1. A constant lost of 112,680 bytes for every ECKD cylinder (13.25%), >which is what I was sniveling about. > >~ Daniel > > > > > > > > >--- > >This message is the property of Time Inc. or its affiliates. It may be >legally privileged and/or confidential and is intended only for the use >of the addressee(s). No addressee should forward, print, copy, or >otherwise reproduce this message in any manner that would allow it to be >viewed by any individual not originally listed as a recipient. If the >reader of this message is not the intended recipient, you are hereby >notified that any unauthorized disclosure, dissemination, distribution, >copying or the taking of any action in reliance on the information >herein is strictly prohibited. If you have received this communication >in error, please immediately notify the sender and delete this message. >Thank you. > >-- >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
z Systems opportunities on bountysource.com
Folks: Have some z Systems and Linux skills? IBM is paying bounties to fix bugs and provide new features in Open Source Software packages for Linux on z Systems. IBM is utilizing Bountysource.com to pay bounties (financial rewards) to developers who fix issues or enhance functionality in Open Source Software on z Systems. https://www.bountysource.com/teams/ibm https://www.bountysource.com/teams/ibm/bounties The idea is to tap into existing z Systems developers and attract new ones in order to make the Open Source Software Ecosystem on z Systems great -- ensuring that all relevant Open Source Software packages run on Linux on z Systems and exploit all of its advantages. Romney Romney White Senior Technical Staff Member z Systems Architecture and Technology 607-785-3873 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
IP Configuration
I believe that a lot of customers have developed their own schemes for dynamically configuring Linux guest IP addresses during boot, accommodating different environments (such as production, DR, and test). Does anyone have such a mechanism that they would be willing to share (scripts, configuration file structure, brief description)? New clients would prefer to start from something that is known to work rather than inventing their own approach from scratch. If you are willing to share, please get in touch with me off list. Romney Romney White Senior Technical Staff Member z Systems Architecture and Technology 607-785-3873 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Fw: Help shape the future of development for z Systems
Folks: Please forward to the appropriate individuals in your organizations. Romney Romney White Senior Technical Staff Member z Systems Architecture and Technology 607-785-3873 - Forwarded by Romney White/Endicott/IBM on 09/22/2015 09:49 AM - From: Marcel Mitran/Toronto/IBM To: zChamp_all@WWPDL Date: 09/21/2015 11:54 PM Subject:Help shape the future of development for z Systems Hi, apologies to anyone who is getting a duplicate of this Please take a few minutes to fill in the following Java on z survey, and feel free to forward to others who may be interested, or have insight. Link: https://ibm.biz/java_on_z Survey: z Systems software values your feedback! Audience: Anyone who has been interested in using Java on z Systems Purpose: Learn about our client's experience with Java and new programming languages on z Deadline: Saturday, Sept 25 Duration: 5-7 minutes Incentives: Help define the future of development on z, sign up for early program feedback Thanks, Marcel Thanks, Marcel Mitran Distinguished Engineer - CTO z Systems Software Performance and Linux Ecosystem IBM Systems Phone: 1-905-413-5566 IBM E-mail: mmit...@ca.ibm.com Find me on: LinkedIn:8200 Warden Ave http://www.linkedin.com/pub/marcel-mitran/29/35b/105 Markham, ON L6G 1C7 Twitter: https://twitter.com/ibm_jtc YouTube: Canada http://www.youtube.com/ibmjtc -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
SHARE LVM TSC Survey
The SHARE Linux and VM Program Technical Steering Committee needs your input! Please point your browser to http://www.surveygizmo.com/s3/2853089/facaa86f1b27 and complete a short survey there. Romney Romney White Senior Technical Staff Member z Systems Architecture and Technology 607-785-3873 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
