Re: Yet Another IBM Conspiracy Theory
I will also like a copy Mark! -Original Message- From: Mark Post [SMTP:[EMAIL PROTECTED]] Sent: 2002 12 18 01:28 To: [EMAIL PROTECTED] Subject: Re: Yet Another IBM Conspiracy Theory Are you sure about that? If I try to access the first URL, it just bounces me to the second one. I may have been too slow. Mark Post -Original Message- From: Mike Ross [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 17, 2002 5:48 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Yet Another IBM Conspiracy Theory Fortunately it's still available from IBM Taiwan, who it seems aren't singing from quite the same hymnsheet as the folks in the USA :) http://www2.tw.ibm.com/cgi-bin/db2www/techdoc/check.d2w/report?No=194 See also http://www2.tw.ibm.com/cgi-bin/db2www/techdoc/index.d2w/report Grab it before the Revisionists erase it too... a copy will be going up at http://www.corestore.org/sg245944.zip but I don't have infinite bandwidth... Mike (CC'ed to Mark in case I'm still banned from posting to Linux-390) http://www.corestore.org The book itself is not in the cache at Google, but I and a number of other people have copies (I know it was one of the more popular downloads). But, I did come across a pointer this message, dated October 24 2002, on the IBM-Main listserv: http://www.marist.edu/htbin/wlvtype?MVS-OE.33139 It's Mike MacIsaac, the lead author of that book explaining that he's been ordered not to talk about why the book and the software were removed. Sigh. Sometimes I really _want_ to be wrong, and this was one of them. Well, I'll offer to send a copy of the book to anyone that wants one, and doesn't have it (it's a little under 3MB in size). Maybe Giorgio Bellussi will host this one too, if enough people think it's worthwhile. Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED]]On Behalf Of John Summerfield Sent: Tuesday, December 17, 2002 4:51 PM To: [EMAIL PROTECTED] Subject: Re: Yet Another IBM Conspiracy Theory On Tue, 17 Dec 2002, Mark Post wrote: Ok, now someone's stolen an entire Redbook, and all the Open Source tools that came with it (at least as far as _I_ can tell). Someone sent me an offlist email indicating that the Open Source Software for z/OS and OS/390 Redbook has been made to disappear, as well as the software that it discusses. I checked the FTP server, and there was a readme.txt file there indicating that all the software had been moved to IBM's UNIX Tools Toys web page, which was what I recalled had been done with it. When I went to that page, though, there was a notice that said The Ported Tools section is being serviced and is not available at this time. Now, just what that means is unclear to me, but taken with the Redbook being missing, it's rather odd. Does anyone know how long the Ported Tools section has been down for service? Does anyone know where to find the official copy of the Redbook? Is this time to disseminate unofficial copies? Is it in the Google cache? -- Cheers John. Join the Linux Support by Small Businesses list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb _ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail
Re: HOW define another OSA Interface ?
At 12:44 17-12-02 +0100, Seifert, Harald wrote. Harald, Here are definitions that we used to activate an OSA-Gbit, OSA-Feth as well as a Hypersockets connection: 1) Update /etc/chandev.conf Noauto;qeth0,0x0400,0x0401,0x0402;addparms,0x10,0x0400,0x402,portname:GBPORT1 Noauto;qeth1,0x0800,0x0801,0x0802;addparms,0x10,0x0800,0x802,portname:FEPORT1 Noauto;qeth2,0x0500,0x0501,0x0502;addparms,0x10,0x0500,0x502,portname:GBPORT2 Noauto;qeth3,0xf400,0xf401,0xf402;addparms,0x10,0xf400,0xf402,portname:HIPER1 in addition you need to update: 2) /etc/route.conf with devicenames (eth0 ? hsi3) 3) /etc/modules.conf 4) /etc/hosts Jaap Grift Linux for zSeries
Re: Yet Another IBM Conspiracy Theory
Mark, I'll be happy to host this one, too. Please send a copy to me offline and I'll upload it immediatly. Mark Post wrote: The book itself is not in the cache at Google, but I and a number of other people have copies (I know it was one of the more popular downloads). But, I did come across a pointer this message, dated October 24 2002, on the IBM-Main listserv: http://www.marist.edu/htbin/wlvtype?MVS-OE.33139 It's Mike MacIsaac, the lead author of that book explaining that he's been ordered not to talk about why the book and the software were removed. Sigh. Sometimes I really _want_ to be wrong, and this was one of them. Well, I'll offer to send a copy of the book to anyone that wants one, and doesn't have it (it's a little under 3MB in size). Maybe Giorgio Bellussi will host this one too, if enough people think it's worthwhile. Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED]]On Behalf Of John Summerfield Sent: Tuesday, December 17, 2002 4:51 PM To: [EMAIL PROTECTED] Subject: Re: Yet Another IBM Conspiracy Theory On Tue, 17 Dec 2002, Mark Post wrote: Ok, now someone's stolen an entire Redbook, and all the Open Source tools that came with it (at least as far as _I_ can tell). Someone sent me an offlist email indicating that the Open Source Software for z/OS and OS/390 Redbook has been made to disappear, as well as the software that it discusses. I checked the FTP server, and there was a readme.txt file there indicating that all the software had been moved to IBM's UNIX Tools Toys web page, which was what I recalled had been done with it. When I went to that page, though, there was a notice that said The Ported Tools section is being serviced and is not available at this time. Now, just what that means is unclear to me, but taken with the Redbook being missing, it's rather odd. Does anyone know how long the Ported Tools section has been down for service? Does anyone know where to find the official copy of the Redbook? Is this time to disseminate unofficial copies? Is it in the Google cache? -- Cheers John. Join the Linux Support by Small Businesses list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Re: Yet Another IBM Conspiracy Theory... unmasked
My first post on this subject didn't make it through moderation... You can get a copy from IBM, on their Taiwanese website (the Redbook IS in English!) - go to: http://www2.tw.ibm.com/cgi-bin/db2www/techdoc/index.d2w/report You'll see it listed about four items up from the bottom. Click on it, and a download process will start, eventually - it's a bit slow. I've put a copy on my website in case it is 'disappeared' from the Taiwan site - http://www.corestore.org/sg245944.zip is where to get it, but go easy - my bandwidth isn't infinite! Mike http://www.corestore.org That's OK, but it's not the final, released version. That's a preliminary copy, hence the redpiece name in the directory. I would really like to see the final release version. Anyone else? Mark Post _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail
Re: Yet Another IBM Conspiracy Theory
It's slow. Go to the second URL, looks for the redbook title (left side near bottom), click on it, eventually a little 'download' window (in Chinese) pops up, and the download starts automatically. Eventually. Let me know how it goes. Mike http://www.corestore.org Are you sure about that? If I try to access the first URL, it just bounces me to the second one. I may have been too slow. Mark Post -Original Message- From: Mike Ross [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 17, 2002 5:48 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Yet Another IBM Conspiracy Theory Fortunately it's still available from IBM Taiwan, who it seems aren't singing from quite the same hymnsheet as the folks in the USA :) http://www2.tw.ibm.com/cgi-bin/db2www/techdoc/check.d2w/report?No=194 See also http://www2.tw.ibm.com/cgi-bin/db2www/techdoc/index.d2w/report Grab it before the Revisionists erase it too... a copy will be going up at http://www.corestore.org/sg245944.zip but I don't have infinite bandwidth... Mike (CC'ed to Mark in case I'm still banned from posting to Linux-390) http://www.corestore.org The book itself is not in the cache at Google, but I and a number of other people have copies (I know it was one of the more popular downloads). But, I did come across a pointer this message, dated October 24 2002, on the IBM-Main listserv: http://www.marist.edu/htbin/wlvtype?MVS-OE.33139 It's Mike MacIsaac, the lead author of that book explaining that he's been ordered not to talk about why the book and the software were removed. Sigh. Sometimes I really _want_ to be wrong, and this was one of them. Well, I'll offer to send a copy of the book to anyone that wants one, and doesn't have it (it's a little under 3MB in size). Maybe Giorgio Bellussi will host this one too, if enough people think it's worthwhile. Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED]]On Behalf Of John Summerfield Sent: Tuesday, December 17, 2002 4:51 PM To: [EMAIL PROTECTED] Subject: Re: Yet Another IBM Conspiracy Theory On Tue, 17 Dec 2002, Mark Post wrote: Ok, now someone's stolen an entire Redbook, and all the Open Source tools that came with it (at least as far as _I_ can tell). Someone sent me an offlist email indicating that the Open Source Software for z/OS and OS/390 Redbook has been made to disappear, as well as the software that it discusses. I checked the FTP server, and there was a readme.txt file there indicating that all the software had been moved to IBM's UNIX Tools Toys web page, which was what I recalled had been done with it. When I went to that page, though, there was a notice that said The Ported Tools section is being serviced and is not available at this time. Now, just what that means is unclear to me, but taken with the Redbook being missing, it's rather odd. Does anyone know how long the Ported Tools section has been down for service? Does anyone know where to find the official copy of the Redbook? Is this time to disseminate unofficial copies? Is it in the Google cache? -- Cheers John. Join the Linux Support by Small Businesses list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb _ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail _ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail
Re: Yet Another IBM Conspiracy Theory
Fortunately it's still available from IBM Taiwan, who it seems aren't singing from quite the same hymnsheet as the folks in the USA :) http://www2.tw.ibm.com/cgi-bin/db2www/techdoc/check.d2w/report?No=194 See also http://www2.tw.ibm.com/cgi-bin/db2www/techdoc/index.d2w/report Grab it before the Revisionists erase it too... a copy will be going up at http://www.corestore.org/sg245944.zip but I don't have infinite bandwidth... Mike (CC'ed to Mark in case I'm still banned from posting to Linux-390) http://www.corestore.org The book itself is not in the cache at Google, but I and a number of other people have copies (I know it was one of the more popular downloads). But, I did come across a pointer this message, dated October 24 2002, on the IBM-Main listserv: http://www.marist.edu/htbin/wlvtype?MVS-OE.33139 It's Mike MacIsaac, the lead author of that book explaining that he's been ordered not to talk about why the book and the software were removed. Sigh. Sometimes I really _want_ to be wrong, and this was one of them. Well, I'll offer to send a copy of the book to anyone that wants one, and doesn't have it (it's a little under 3MB in size). Maybe Giorgio Bellussi will host this one too, if enough people think it's worthwhile. Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED]]On Behalf Of John Summerfield Sent: Tuesday, December 17, 2002 4:51 PM To: [EMAIL PROTECTED] Subject: Re: Yet Another IBM Conspiracy Theory On Tue, 17 Dec 2002, Mark Post wrote: Ok, now someone's stolen an entire Redbook, and all the Open Source tools that came with it (at least as far as _I_ can tell). Someone sent me an offlist email indicating that the Open Source Software for z/OS and OS/390 Redbook has been made to disappear, as well as the software that it discusses. I checked the FTP server, and there was a readme.txt file there indicating that all the software had been moved to IBM's UNIX Tools Toys web page, which was what I recalled had been done with it. When I went to that page, though, there was a notice that said The Ported Tools section is being serviced and is not available at this time. Now, just what that means is unclear to me, but taken with the Redbook being missing, it's rather odd. Does anyone know how long the Ported Tools section has been down for service? Does anyone know where to find the official copy of the Redbook? Is this time to disseminate unofficial copies? Is it in the Google cache? -- Cheers John. Join the Linux Support by Small Businesses list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb _ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail
Re: Yet Another IBM Conspiracy Theory
I would like a copy also Thank. LOGO BIYCSA V1.jpg
Re: Yet Another IBM Conspiracy Theory... unmasked
The availablilty, then disappearance, then pending availability of the UNIX Tools Toys web page brings to mind a few thoughts I keep having about open source and USS. 1) I really appreaciated the website and redbook because it helped me greatly to get a handle on porting tools to USS. 2) Its disappearance forced me to research and experiment more with porting to USS since a number of tools at the website really are very valuable. 3) The biggest thing that repeatedly struck me, though, was the static nature of the website's tools. (And this is NOT knock against anyone at IBM. As I said in #1, I greatly appreciated the site.) I also work with the Linux world and and watch frequent notices and then frequent updates for various tools (Samba for example is at what? 2.2.7a?). Would it not be nice to have some website and process by which the tools were more current? How this would be done, not sure. Have a place in the site for us to stick more current ports? Dave -Original Message- From: Steve Stiert [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 1:29 AM To: [EMAIL PROTECTED] Subject: Re: [LINUX-390] Yet Another IBM Conspiracy Theory... unmasked Hi Folks: I hate to ruin the intrigue of a good conspiracy theory :-) but the packages should be back online by the end of the day Wednesday. Feel free to contact me if you have don't find what you're looking for after that time. regards, Steve Tools and Toys Website Maintainer
Re: HOWTO define a network printer to Linux S/390 ?
Use yast2. It's a perfect tool for tasks like this. Maciek -- Maciej Ksiezycki Systems Programmer Unizeto Sp. z o.o. http://www.unizeto.pl Mark Post [EMAIL PROTECTED]wrote: Harald, It was kind of hard to tell because of all the MIME quoting, but it looks as though your first line is wrong. There should not be a blank between BH0D and lp on that line. All names should be separated by the pipe character |. Second, you really should consider listening to the SuSE support people when they say use YaST. That tool is designed to perform tasks such as this, and will likely make the job a lot easier. Mark Post -Original Message- I'm running SuSE Linux zSLES7 in a LPAR of a z900 machine with Kernel 2.4.17. I have tried to define a network printer to the BSD spooling system and as a newbie with no success. The printer, I have, is an LEXMARK Optra S1855 and I have tried the following definition in /etc/printcap remote|lp1|BH0D lp:\ :lp=:\ :rm=PRT1.huk-domain.de:\ :rp=raw:\ :sd=/var/spool/lpd/BH0D-lp:\ :lf=/var/spool/lpd/BH0D-lp/log:\ :af=/var/sppol/lpd/BH0D-lp/acct:\ :ar:bk:mx#0:\ :tr=:c1:sh: The lpd daemon is up and running. I put a job to the printer with lpr -Premote /etc/fstab. Doing a lpc status , I see the following: remote: queuing is enabled printing is enabled 1 entry in spool area no daemon present . Also I did a PING to BH0D (the name of the Printer) to see the full name of the printer it's PRT1.huk-domain.de and it's TCP/IP address. It seems that something is missing. The SuSE support says simply: Define the remote printer with YAST. Has anyone done similiar things or knows a HOWTO ? Any suggestions appreciated. N.B. Or should I try CUPS or SAMBA. Regards Harald Seifert Informatik-Systemprogrammierung HUK Coburg Bahnhofsplatz 96444 Coburg Phone +049 (0)9561-961787 Fax+049 (0)9561-963671 Mailto [EMAIL PROTECTED]
AW: Yet Another IBM Conspiracy Theory
I would like a copy also. Thanks. -Ursprüngliche Nachricht- Von: Nestor Acosta [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 18. Dezember 2002 14:15 An: [EMAIL PROTECTED] Betreff: Re: Yet Another IBM Conspiracy Theory I would like a copy also Thank. BEGIN:VCARD VERSION:2.1 N:Seifert;Harald FN:Seifert, Harald ORG:HUK-COBURG;Abteilung IT TITLE: NOTE: TEL;WORK;VOICE:09561 96-1787 TEL;WORK;FAX:09561 96-3671 ADR;WORK:;;Bahnhofsplatz;Coburg; ;96444 EMAIL;OREF;INTERNET:[EMAIL PROTECTED] END:VCARD
Re: Yet Another IBM Conspiracy Theory
Mark, put this book to http://www.linuxvm.org/. So, they'll stop bother you :) WBR, Sergey
Loss of space in formated Filesystem
Hi Folks, Anyone have a table of comparison between Filesystems (Ext2, JFS, ReiserFs, etc) and loss of space in formated filesystems ? TIA Evandro Vargas - IBM Brasil
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: sna-linux
Please try to send email to group mailing list: [EMAIL PROTECTED] NJ __ Reply Separator _ Subject: Re: sna-linux Author: markkp ([EMAIL PROTECTED]) at Internet Date:12/18/02 1:51 AM Which also seems to come up MIA. :( Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED]]On Behalf Of David Boyes Sent: Wednesday, December 18, 2002 1:23 AM To: [EMAIL PROTECTED] Subject: Re: sna-linux The correct url is www.linux-sna.org. -- db - Original Message - From: Mitchell McKenna [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, December 17, 2002 5:57 PM Subject: Re: sna-linux Paul, Proxy server is unable to locate the server: www.sna-linux.org. The server does not have a DNS entry. Check the server name in the Location (URL) and try again. Sporadic is an understatement - Is there anywhere else we can obtain these RPM's from ? thanks again Mitch From: Paul Landay [EMAIL PROTECTED] Reply-To: Linux on 390 Port [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: sna-linux Date: Tue, 17 Dec 2002 06:21:51 -0500 Mitchell McKenna wrote: sna-linux - where art thou ? IBM has a sna for linux PRPQ (CS/Linux = Communications Server for Linux), but currently only for intel-32bit: http://www.ibm.com/software/network/commserver There is an open source project which is supposed to work on zSeries linux, but activity on it is sporadic: http://www.linux-sna.org Paul Landay _ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail Please note that this e-mail and any files transmitted with it are privileged, confidential, and protected from disclosure under applicable law. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this communication or any of its attachments is strictly prohibited. If you have received this communication in error, please notify the sender immediately by replying to this message and deleting this message, any attachments, and all copies and backups from your computer.
LVM problem
Hi, I use SuSE Linux/390 7 (2.2.16, quite old I know). I had two 3390 disks put together in a volume group and several logical volumes running. I added a third 3390 disk to the linux (VM minidisk and added to parmfile, ran silo etc). During reboot vgscan reports that no volume groups can be found and after that of course the logical volumes are not existent. When I remove the new disk from my parmfile the lvm devices are found again...Any hint or help would be greatly appreciated. mit freundlichen Grüßen/with best regards Thomas
Re: Linux on the Mainframe BOF at LinuxWorld, NYC, Jan *23*, 2003
Montgomery, Are you sure on the January 30th date? LinuxWorld runs January 21-24 in NYC. You are right - the date should be January 23rd. Thanks for the catch. -Mike MacIsaac, IBM [EMAIL PROTECTED] (845) 433-7061
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
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
Yet Another IBM Conspiracy Theory... light shed
Hi list, I speak for myself and not for IBM. I should be working on CUPS and Samba printing, but this thread has created an itch I just have to scratch. I'll shed some light on the conspiracy theory, though you won't find a smoking gun :)) I proposed the redbook Open Source Software for OS/390 UNIX in 1999 after finishing a couple of redbooks which dabbled in open source. To my delight it was funded for the year 2000 and the *next month* Linux hit the scene. We ran an ITSO residency in February and March with Sandor Barany, Ralf Schandl and Egon Terwedow working hard on vim, openss*, groff, gnats, Perl and many others. Jim Tison caught wind of the project and happened to be on the same floor. He chipped in the autoconf and automake chapters. A lot of open source for OS/390 was available for the picking on the Web, especially on the MKS Web site (to MKS' credit, still online at ftp://ftp.mks.com/pub/s390/gnu/). It was a fun project. There was a lot of work done, but it was only a 6 week residency. If you've done software development, you know that six weeks is not a lot of time - oh and we had to write a book as well as work on the code. The first book was published in October of 2000 and was moderately successful as a book. I felt the code was more valuable than the book. Getting legal approval was a lot of work and it probably would never have happened were it not for GNU and Linux and IBM's new religion. For a background on this, see page 4 especially (http://dir.salon.com/tech/fsp/2000/09/12/chapter_7_part_one/index.html?pn=4) of How Big Blue Fell for Linux - an excellent article by Andrew Leonard. I proposed an update to the redbook and code which was funded for 2001. By now Linux on zSeries had critical mass and was a whole lot more UNIX-like and fun than z/OS UNIX Systems Services. Regardless, we had a project to complete. This time the residents were Thorsten Brockmeier, Guillermo Freige, Stefan Koesling, Kiran Madnani and Fulvio Malfatto all of whom did a great job. In retrospect, we bit off more than we could chew. We should have focused more on code quality and less on quantity (OpenSSL and OpenSSH have problems. The randomness of OpenSSL is not always adequate. SSH works with version 1 not version 2, sftp and scp do not work I believe.). The book ran into 2002 and was published in March. Both books had CDs in the back; a feature that the ITSO no longer supports. One of the complaints of the first book was that the source and binaries were distributed each as two large tar files with every package in each. So for the second book we split out the source packages and binaries at least on the tools and toys Web site - another chunk of work - especially packaging up tar files for the binaries of individual packages. In October of this year, both the redbook and the code were pulled from IBM Web sites (apparently not as thoroughly as possible :) to be serviced. Steve Stiert is the Webmaster of Tools and Toys and the good news is that the code is going back on Web soon, per his append. I coincidentally just asked yesterday about the status of the redbook going back on the Web. There are some deletions to be made that would take the excellent editors at the ITSO perhaps a couple of hours to complete and turn the crank to make the book available. So the book should or at least could have been available by now. The holiday season is also the editors' busiest season as ITSO project leaders scramble to get their projects completed by the calendar year and move on to newly funded projects. So there's a queue to get this two hours of work done. The book might have been able to jump the queue, however the snag is that the ITSO no longer includes CDs in hard copies of books. Because of this a lot more deletions have to be made of references to the CD included with the hard copy of the book (interestingly the astounding number of 60 hard copies of this redbook were ever sold). Given these factors, I'm guessing the book will be available on the ITSO Web site early next year. I now wanted to step back and comment and just noticed David Froberg's append, so, thanks for that - I'll use it as a springboard: 1) I really appreciated the web site and redbook because it helped me greatly to get a handle on porting tools to USS. 2) Its disappearance forced me to research and experiment more with porting to USS since a number of tools at the web site really are very valuable. Thanks, that's good to hear. 3) The biggest thing that repeatedly struck me, though, was the static nature of the web site's tools. (And this is NOT knock against anyone at IBM. As I said in #1, I greatly appreciated the site.) I also work with the Linux world and and watch frequent notices and then frequent updates for various tools (Samba for example is at what? 2.2.7a?). Would it not be nice to have some web site and process by which the tools were more current? How this would be done, not
Problem with Redhat OSA/QDIO recognition
Hi, I am experiencing a problem when installing RedHat Linux 7.2 in VM. I am trying to initialize a GigEthernet OSA card. I followed all procedures as far as linking the IBM OCO modules with the RedHat distribution. Also, all microcode and VM maintenance should be up to date. A few months ago I had attempted the same thing with an ATM OSA with no luck. Any idea what could be the problem? What other debugging can be done? Thanks, Ken Maxtutis Senior Systems Programmer Konica Business Technologies Windsor, CT. USA email: [EMAIL PROTECTED] Here's the error I'm getting: lib/qeth.o: init_module: %m Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters SIOCSIFADDR: No such device eth0: unknown interface: No such device SIOCSIFMTU: No such device SIOCSIFNETMASK: No such device SIOCSIFBRDADDR: No such device eth0: unknown interface: No such device SIOCADDRT: No such device SIOCADDRT: No such device loLink encap:Local Loopback Here's my parm file: root=/dev/ram0 ro ip=off ramdisk_size=12000 DASD=200-20f CHANDEV=qeth1,0xe200,0xe201,0xe202 HOST=mflinux1.konicabt.com:eth0:10.3.13.50:1500 NETWORK=10.3.13.0:255.255.255.0:10.255.255.255:10.3.13.1 DNS=10.1.250.20:10.1.250.21 SEARCHDNS=konicabt.com RPMSERVER=ftp://anonymous:XXX@[EMAIL PROTECTED]/pub/rh390-7.2/RedHat/RPMS QETHPARM=add_parms,0x10,0xe200,0xe202,portname:OSAFD And a copy of proc/chandev: cat chandev chan_type key bitfield ctc=0x1,escon=0x2,lcs=0x4,osad=0x8,qeth=0x10,claw=0x20 *'s for cu/dev type/models indicate don't cares cautious_auto_detect: on persist = 0x00 use_devno_names: off Channels enabled for detection chan cu cu dev devmax checksum use hw auto recovery typetypemodel type model port_no. received stats type == 0x20 0x3088 0x61 ** 0 no no not_operational,no_path,revalidate,device_gone 0x08 0x3088 0x62 ** 0 no no not_operational,no_path,revalidate,device_gone 0x10 0x1731 0x05 0x1732 0x050 no no not_operational,no_path,revalidate,device_gone 0x10 0x1731 0x01 0x1732 0x010 no no not_operational,no_path,revalidate,device_gone 0x04 0x3088 0x60 ** 1 no no not_operational,no_path,revalidate,device_gone 0x06 0x3088 0x1f **15 no no not_operational,no_path,revalidate,device_gone 0x05 0x3088 0x08 **15 no no not_operational,no_path,revalidate,device_gone 0x04 0x3088 0x01 **15 no no not_operational,no_path,revalidate,device_gone Forced devices chan defif read write data memory port iphw host adapter api type num devno devno devno usage(k) protocol no. chksum stats name name name === 0x101 0xe200 0xe201 0xe202 default 0 00 # MORE...
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: sna-linux
Weird. Resolves from here...I wonder if it's a routing issue. -- db David Boyes Sine Nomine Associates -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED]]On Behalf Of Mark Post Sent: Wednesday, December 18, 2002 1:51 AM To: [EMAIL PROTECTED] Subject: Re: sna-linux Which also seems to come up MIA. :( Mark Post
Re: Odd TraceRoute To Linux/390 Guests via VM TCPIP
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: 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: Yet Another IBM Conspiracy Theory... light shed
Thanks for the good news Mike! I speak for myself and not for IBM. I should be working on CUPS and Samba printing, but this thread has created an itch I just have to scratch. I'll shed some light on the conspiracy theory, though you won't find a smoking gun :)) Snip a bunch of good news In October of this year, both the redbook and the code were pulled from IBM Web sites (apparently not as thoroughly as possible :) to be serviced. Thanks for the update. I'm just rather perplexed at why such an apparently straightforward situation caused you to say (on IBM-MAIN): 'Indeed, the redbook and the associated code are no longer available. As to the reason, I was told what I could *not* say, but not what I could say, so you might guess as to the area of the business that decree came from.' That's a rather 'sinister' statement for a simple temporary withdrawal for update. I think you can understand where the conspiracy theory came from... given there have been other intimations of tension between open-sourcers and, shall we say, 'Luddites' in various bits of IBMs mainframe business? Like the folks who decided Hercules was an excellent development platform for Linux, and the folks who subsequently issued a Decree that It Never Happened... :) Mike _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail
Re: Odd TraceRoute To Linux/390 Guests via VM TCPIP
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] -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
Installing RedHat Linux
I've just started installing 2.4.7 of Redhat, and I've answered the network typ (escon etc,) with ETH0. It then is asking me for a device and port pair thing like escon0,0x600,0x601 etc. I know it should be eth0,0x???,0x??? but the install instructions I found on the CD are quite thin How should I know the port #? The device is chp 34, device 831. The other linux partiion is using device 831 any insight?
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] -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
Re: Odd TraceRoute To Linux/390 Guests via VM TCPIP
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 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)
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 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
Re: Odd TraceRoute To Linux/390 Guests via VM TCPIP
On Wed, 18 Dec 2002, Coffin Michael C wrote: 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. It's not responmding to the icmp messages used by traceroute. I often see it when checking sites on ADSL: [root@Nectarine root]# traceroute terad.net traceroute to terad.net (203.15.140.104), 30 hops max, 38 byte packets 1 gw.home.Computerdatasafe.com.au (192.168.2.1) 0.808 ms 0.543 ms 1.065 ms 2 gw.home.Computerdatasafe.com.au (192.168.1.1) 176.685 ms 137.014 ms 139.944 ms 3 172.31.22.178 (172.31.22.178) 169.992 ms 158.247 ms 159.929 ms 4 172.31.24.178 (172.31.24.178) 159.992 ms 158.260 ms 172.31.25.178 (172.31.25.178) 160.026 ms 5 atm2-0-37.perth.westnet.com.au (202.72.130.145) 168.286 ms 157.388 ms atm2-0-36.perth.westnet.com.au (202.72.130.149) 169.889 ms 6 bdr1.westnet.com.au (203.10.1.1) 177.083 ms 157.272 ms 160.139 ms 7 198.32.212.49 (198.32.212.49) 169.821 ms 168.238 ms 159.930 ms 8 tarantula-adsl-trunk.arach.net.au (203.30.44.222) 189.993 ms 177.257 ms 179.926 ms 9 * * * 10 * * * 11 terad.net (203.15.140.104) 206.853 ms 187.227 ms 189.935 ms [root@Nectarine root]# -- Cheers John. Join the Linux Support by Small Businesses list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
FTP - Painful lesson
If you have an anonymous FTP server be sure that your the lost+found directory in /pub has attributes set to 700. There is an exploit that allows evil hackers to create their own directories as an anonymous user. 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: Yet Another IBM Conspiracy Theory
Sergey, I really can't do that without asking permission of the site's host/sponsor, Velocity Software. And, while Barton and his team have been really great to me and the mailing list over the years, I don't see that this is particularly related to Linux/390, so I wasn't going to ask. In the meantime, Georgio has volunteered to do that, so it's taken care of anyway. Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED]]On Behalf Of Sergey Korzhevsky Sent: Wednesday, December 18, 2002 9:04 AM To: [EMAIL PROTECTED] Subject: Re: Yet Another IBM Conspiracy Theory Mark, put this book to http://www.linuxvm.org/. So, they'll stop bother you :) WBR, Sergey
Debian cant find OSA adapter files
I have installed Debian woody with the IBM OCO QETH and QDIO modules for 2.4.17. Installation went fine and able to telnet in and to do install. Upon booting from dasd the first time, I get the following error: Setting up IP spoofing protection: rp_filter. Configuring network interfaces: modprobe: modprobe: Can't locate module eth0 SIOCSIFADDR: No such device modprobe: modprobe: Can't locate module eth0 eth0: ERROR while getting interface flags: No such device modprobe: modprobe: Can't locate module eth0 SIOCSIFNETMASK: No such device modprobe: modprobe: Can't locate module eth0 SIOCSIFBRDADDR: No such device modprobe: modprobe: Can't locate module eth0 eth0: ERROR while getting interface flags: No such device modprobe: modprobe: Can't locate module eth0 eth0: ERROR while getting interface flags: No such device done. The parms used at OSA setup are add_parms,0x10,0xc40,0xc42,portname=OSA1 qeth,0xc40,0xc41,0xc42 have also tried eth0,0xc40,0xc41,0xc42 Anybody been here or have any suggestions? Glen Crowley Lead Systems Programmer Arkansas Blue Cross Blue Shield 501-378-2432 [EMAIL PROTECTED]
Re: Problem with Redhat OSA/QDIO recognition
Ken, There might be more information in the kernel ring buffer. Do a dmesg command (if there's one on the initrd) and post the output from that (the relevant parts should be at the end). Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED]]On Behalf Of Ken Maxtutis Sent: Wednesday, December 18, 2002 10:42 AM To: [EMAIL PROTECTED] Subject: Problem with Redhat OSA/QDIO recognition Hi, I am experiencing a problem when installing RedHat Linux 7.2 in VM. I am trying to initialize a GigEthernet OSA card. I followed all procedures as far as linking the IBM OCO modules with the RedHat distribution. Also, all microcode and VM maintenance should be up to date. A few months ago I had attempted the same thing with an ATM OSA with no luck. Any idea what could be the problem? What other debugging can be done? Thanks, Ken Maxtutis Senior Systems Programmer Konica Business Technologies Windsor, CT. USA email: [EMAIL PROTECTED] Here's the error I'm getting: lib/qeth.o: init_module: %m Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters SIOCSIFADDR: No such device eth0: unknown interface: No such device SIOCSIFMTU: No such device SIOCSIFNETMASK: No such device SIOCSIFBRDADDR: No such device eth0: unknown interface: No such device SIOCADDRT: No such device SIOCADDRT: No such device loLink encap:Local Loopback Here's my parm file: root=/dev/ram0 ro ip=off ramdisk_size=12000 DASD=200-20f CHANDEV=qeth1,0xe200,0xe201,0xe202 HOST=mflinux1.konicabt.com:eth0:10.3.13.50:1500 NETWORK=10.3.13.0:255.255.255.0:10.255.255.255:10.3.13.1 DNS=10.1.250.20:10.1.250.21 SEARCHDNS=konicabt.com RPMSERVER=ftp://anonymous:XXX@[EMAIL PROTECTED]/pub/rh390-7.2/RedHat/RPMS QETHPARM=add_parms,0x10,0xe200,0xe202,portname:OSAFD And a copy of proc/chandev: cat chandev chan_type key bitfield ctc=0x1,escon=0x2,lcs=0x4,osad=0x8,qeth=0x10,claw=0x20 *'s for cu/dev type/models indicate don't cares cautious_auto_detect: on persist = 0x00 use_devno_names: off Channels enabled for detection chan cu cu dev devmax checksum use hw auto recovery typetypemodel type model port_no. received stats type == 0x20 0x3088 0x61 ** 0 no no not_operational,no_path,revalidate,device_gone 0x08 0x3088 0x62 ** 0 no no not_operational,no_path,revalidate,device_gone 0x10 0x1731 0x05 0x1732 0x050 no no not_operational,no_path,revalidate,device_gone 0x10 0x1731 0x01 0x1732 0x010 no no not_operational,no_path,revalidate,device_gone 0x04 0x3088 0x60 ** 1 no no not_operational,no_path,revalidate,device_gone 0x06 0x3088 0x1f **15 no no not_operational,no_path,revalidate,device_gone 0x05 0x3088 0x08 **15 no no not_operational,no_path,revalidate,device_gone 0x04 0x3088 0x01 **15 no no not_operational,no_path,revalidate,device_gone Forced devices chan defif read write data memory port iphw host adapter api type num devno devno devno usage(k) protocol no. chksum stats name name name === 0x101 0xe200 0xe201 0xe202 default 0 00 # MORE...
Re: Debian cant find OSA adapter files
Should be portname: , not portname= ... From recent traffic on this list, that and add_parms seem to be commonly mistyped. ~ Daniel -Original Message- From: Crowley, Glen L [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 2:00 PM To: [EMAIL PROTECTED] Subject: Debian cant find OSA adapter files I have installed Debian woody with the IBM OCO QETH and QDIO modules for 2.4.17. Installation went fine and able to telnet in and to do install. Upon booting from dasd the first time, I get the following error: Setting up IP spoofing protection: rp_filter. Configuring network interfaces: modprobe: modprobe: Can't locate module eth0 SIOCSIFADDR: No such device modprobe: modprobe: Can't locate module eth0 eth0: ERROR while getting interface flags: No such device modprobe: modprobe: Can't locate module eth0 SIOCSIFNETMASK: No such device modprobe: modprobe: Can't locate module eth0 SIOCSIFBRDADDR: No such device modprobe: modprobe: Can't locate module eth0 eth0: ERROR while getting interface flags: No such device modprobe: modprobe: Can't locate module eth0 eth0: ERROR while getting interface flags: No such device done. The parms used at OSA setup are add_parms,0x10,0xc40,0xc42,portname=OSA1 qeth,0xc40,0xc41,0xc42 have also tried eth0,0xc40,0xc41,0xc42 Anybody been here or have any suggestions? Glen Crowley Lead Systems Programmer Arkansas Blue Cross Blue Shield 501-378-2432 [EMAIL PROTECTED] --- 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.
Re: Debian cant find OSA adapter files
What is in /etc/modules.conf? Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED]]On Behalf Of Crowley, Glen L Sent: Wednesday, December 18, 2002 2:00 PM To: [EMAIL PROTECTED] Subject: Debian cant find OSA adapter files I have installed Debian woody with the IBM OCO QETH and QDIO modules for 2.4.17. Installation went fine and able to telnet in and to do install. Upon booting from dasd the first time, I get the following error: Setting up IP spoofing protection: rp_filter. Configuring network interfaces: modprobe: modprobe: Can't locate module eth0 SIOCSIFADDR: No such device modprobe: modprobe: Can't locate module eth0 eth0: ERROR while getting interface flags: No such device modprobe: modprobe: Can't locate module eth0 SIOCSIFNETMASK: No such device modprobe: modprobe: Can't locate module eth0 SIOCSIFBRDADDR: No such device modprobe: modprobe: Can't locate module eth0 eth0: ERROR while getting interface flags: No such device modprobe: modprobe: Can't locate module eth0 eth0: ERROR while getting interface flags: No such device done. The parms used at OSA setup are add_parms,0x10,0xc40,0xc42,portname=OSA1 qeth,0xc40,0xc41,0xc42 have also tried eth0,0xc40,0xc41,0xc42 Anybody been here or have any suggestions? Glen Crowley Lead Systems Programmer Arkansas Blue Cross Blue Shield 501-378-2432 [EMAIL PROTECTED]
Re: Debian cant find OSA adapter files
cat /etc/modules.conf ### This file is automatically generated by update-modules # # Please do not edit this file directly. If you want to change or add # anything please take a look at the files in /etc/modutils and read # the manpage for update-modules. # ### update-modules: start processing /etc/modutils/0keep # DO NOT MODIFY THIS FILE! # This file is not marked as conffile to make sure if you upgrade modutils # it will be restored in case some modifications have been made. # # The keep command is necessary to prevent insmod and friends from ignoring # the builtin defaults of a path-statement is encountered. Until all other # packages use the new `add path'-statement this keep-statement is essential # to keep your system working keep ### update-modules: end processing /etc/modutils/0keep ### update-modules: start processing /etc/modutils/actions # Special actions that are needed for some modules # The BTTV module does not load the tuner module automatically, # so do that in here post-install bttv insmod tuner post-remove bttv rmmod tuner ### update-modules: end processing /etc/modutils/actions ### update-modules: start processing /etc/modutils/aliases # Aliases to tell insmod/modprobe which modules to use # Uncomment the network protocols you don't want loaded: # alias net-pf-1 off# Unix # alias net-pf-2 off# IPv4 # alias net-pf-3 off# Amateur Radio AX.25 # alias net-pf-4 off# IPX # alias net-pf-5 off# DDP / appletalk # alias net-pf-6 off# Amateur Radio NET/ROM # alias net-pf-9 off# X.25 # alias net-pf-10 off # IPv6 # alias net-pf-11 off # ROSE / Amateur Radio X.25 PLP # alias net-pf-19 off # Acorn Econet alias char-major-10-175 agpgart alias char-major-10-200 tun alias char-major-81 bttv alias char-major-108ppp_generic alias /dev/ppp ppp_generic alias tty-ldisc-3 ppp_async alias tty-ldisc-14 ppp_synctty alias ppp-compress-21 bsd_comp alias ppp-compress-24 ppp_deflate alias ppp-compress-26 ppp_deflate # Crypto modules (see http://www.kerneli.org/) alias loop-xfer-gen-0 loop_gen alias loop-xfer-3 loop_fish2 alias loop-xfer-gen-10 loop_gen alias cipher-2 des alias cipher-3 fish2 alias cipher-4 blowfish alias cipher-6 idea alias cipher-7 serp6f alias cipher-8 mars6 alias cipher-11 rc62 alias cipher-15 dfc2 alias cipher-16 rijndael alias cipher-17 rc5 ### update-modules: end processing /etc/modutils/aliases ### update-modules: start processing /etc/modutils/paths # This file contains a list of paths that modprobe should scan, # beside the once that are compiled into the modutils tools # themselves. ### update-modules: end processing /etc/modutils/paths ### update-modules: start processing /etc/modutils/qeth-2.4.17-s390-3 alias eth0 qeth-2.4.17-s390-3 ### update-modules: end processing /etc/modutils/qeth-2.4.17-s390-3 ### update-modules: start processing /etc/modutils/arch/s390 # # /etc/modutils/arch/s390 # # For details concering configuration options of S/390 specific drivers # see the LINUX for S/390 Device Drivers and Installation Commands book # on http://oss.software.ibm.com/developerworks/opensource/linux390/docu.html # alias tr0lcs #alias eth0 lcs alias eth0 qeth alias ctc0 ctc alias escon0 ctc alias iucv0 netiucv ### update-modules: end processing /etc/modutils/arch/s390 -Original Message- From: Mark Post [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 1:23 PM To: [EMAIL PROTECTED] Subject: Re: Debian cant find OSA adapter files What is in /etc/modules.conf? Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED]]On Behalf Of Crowley, Glen L Sent: Wednesday, December 18, 2002 2:00 PM To: [EMAIL PROTECTED] Subject: Debian cant find OSA adapter files I have installed Debian woody with the IBM OCO QETH and QDIO modules for 2.4.17. Installation went fine and able to telnet in and to do install. Upon booting from dasd the first time, I get the following error: Setting up IP spoofing protection: rp_filter. Configuring network interfaces: modprobe: modprobe: Can't locate module eth0 SIOCSIFADDR: No such device modprobe: modprobe: Can't locate module eth0 eth0: ERROR while getting interface flags: No such device modprobe: modprobe: Can't locate module eth0 SIOCSIFNETMASK: No such device modprobe: modprobe: Can't locate module eth0 SIOCSIFBRDADDR: No such device modprobe: modprobe: Can't locate module eth0 eth0: ERROR while getting interface flags: No such device modprobe: modprobe: Can't locate module eth0 eth0: ERROR while getting interface flags: No such device done. The parms used at OSA setup are add_parms,0x10,0xc40,0xc42,portname=OSA1 qeth,0xc40,0xc41,0xc42 have also tried eth0,0xc40,0xc41,0xc42 Anybody been here or have any suggestions? Glen Crowley Lead Systems Programmer
Re: Debian cant find OSA adapter files
I missed typed it in the email, during the install I used portname:OSA1 Glen -Original Message- From: Daniel Jarboe [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 1:20 PM To: [EMAIL PROTECTED] Subject: Re: Debian cant find OSA adapter files Should be portname: , not portname= ... From recent traffic on this list, that and add_parms seem to be commonly mistyped. ~ Daniel -Original Message- From: Crowley, Glen L [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 2:00 PM To: [EMAIL PROTECTED] Subject: Debian cant find OSA adapter files I have installed Debian woody with the IBM OCO QETH and QDIO modules for 2.4.17. Installation went fine and able to telnet in and to do install. Upon booting from dasd the first time, I get the following error: Setting up IP spoofing protection: rp_filter. Configuring network interfaces: modprobe: modprobe: Can't locate module eth0 SIOCSIFADDR: No such device modprobe: modprobe: Can't locate module eth0 eth0: ERROR while getting interface flags: No such device modprobe: modprobe: Can't locate module eth0 SIOCSIFNETMASK: No such device modprobe: modprobe: Can't locate module eth0 SIOCSIFBRDADDR: No such device modprobe: modprobe: Can't locate module eth0 eth0: ERROR while getting interface flags: No such device modprobe: modprobe: Can't locate module eth0 eth0: ERROR while getting interface flags: No such device done. The parms used at OSA setup are add_parms,0x10,0xc40,0xc42,portname=OSA1 qeth,0xc40,0xc41,0xc42 have also tried eth0,0xc40,0xc41,0xc42 Anybody been here or have any suggestions? Glen Crowley Lead Systems Programmer Arkansas Blue Cross Blue Shield 501-378-2432 [EMAIL PROTECTED] --- 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.
Re: Debian cant find OSA adapter files
Well, there are two entries in there for eth0. I'm not sure which one wins, the first or last. I would verify which module name you have, either qeth.o or qeth-2.4.17-s390-3.o in /lib/modules, and delete the other one. Run depmod -a just for no good reason, and try it again. Also, just as I mentioned with Ken, try doing a dmesg to see if there are any hints in there. Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED]]On Behalf Of Crowley, Glen L Sent: Wednesday, December 18, 2002 2:25 PM To: [EMAIL PROTECTED] Subject: Re: Debian cant find OSA adapter files cat /etc/modules.conf -snip- ### update-modules: end processing /etc/modutils/paths ### update-modules: start processing /etc/modutils/qeth-2.4.17-s390-3 alias eth0 qeth-2.4.17-s390-3 ### update-modules: end processing /etc/modutils/qeth-2.4.17-s390-3 ### update-modules: start processing /etc/modutils/arch/s390 # # /etc/modutils/arch/s390 # # For details concering configuration options of S/390 specific drivers # see the LINUX for S/390 Device Drivers and Installation Commands book # on http://oss.software.ibm.com/developerworks/opensource/linux390/docu.html # alias tr0lcs #alias eth0 lcs alias eth0 qeth alias ctc0 ctc alias escon0 ctc alias iucv0 netiucv ### update-modules: end processing /etc/modutils/arch/s390 -Original Message- From: Mark Post [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 1:23 PM To: [EMAIL PROTECTED] Subject: Re: Debian cant find OSA adapter files What is in /etc/modules.conf? Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED]]On Behalf Of Crowley, Glen L Sent: Wednesday, December 18, 2002 2:00 PM To: [EMAIL PROTECTED] Subject: Debian cant find OSA adapter files I have installed Debian woody with the IBM OCO QETH and QDIO modules for 2.4.17. Installation went fine and able to telnet in and to do install. Upon booting from dasd the first time, I get the following error: Setting up IP spoofing protection: rp_filter. Configuring network interfaces: modprobe: modprobe: Can't locate module eth0 SIOCSIFADDR: No such device modprobe: modprobe: Can't locate module eth0 eth0: ERROR while getting interface flags: No such device modprobe: modprobe: Can't locate module eth0 SIOCSIFNETMASK: No such device modprobe: modprobe: Can't locate module eth0 SIOCSIFBRDADDR: No such device modprobe: modprobe: Can't locate module eth0 eth0: ERROR while getting interface flags: No such device modprobe: modprobe: Can't locate module eth0 eth0: ERROR while getting interface flags: No such device done. The parms used at OSA setup are add_parms,0x10,0xc40,0xc42,portname=OSA1 qeth,0xc40,0xc41,0xc42 have also tried eth0,0xc40,0xc41,0xc42 Anybody been here or have any suggestions? Glen Crowley Lead Systems Programmer Arkansas Blue Cross Blue Shield 501-378-2432 [EMAIL PROTECTED]
Updates to linuxvm.org
I've been making a little progress on getting updates made. I'm still about 3 months behind, though. I'm up to September 18th, and will be trying to make more updates over the next few weeks. Mark Post
Re: Installing RedHat Linux
James, Is this a qeth/qdio card, or an LCS card? For qeth/qdio, the port numbers are the device numbers, and have to start on an even boundary. For LCS, you have to specify both the device number and the actual port. For more help, try the Device Drivers and Installation Commands manual at http://www10.software.ibm.com/developerworks/opensource/linux390/docu/l390dd 08.pdf Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED]]On Behalf Of James Melin Sent: Wednesday, December 18, 2002 12:26 PM To: [EMAIL PROTECTED] Subject: Installing RedHat Linux I've just started installing 2.4.7 of Redhat, and I've answered the network typ (escon etc,) with ETH0. It then is asking me for a device and port pair thing like escon0,0x600,0x601 etc. I know it should be eth0,0x???,0x??? but the install instructions I found on the CD are quite thin How should I know the port #? The device is chp 34, device 831. The other linux partiion is using device 831 any insight?
Re: Updates to linuxvm.org
Lucky for you Christmas is coming up... :) On Wednesday 18 December 2002 02:01 pm, you wrote: I've been making a little progress on getting updates made. I'm still about 3 months behind, though. I'm up to September 18th, and will be trying to make more updates over the next few weeks. Mark Post -- Rich Smrcina Sytek Services, Inc. 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: Installing RedHat Linux
Um, I don't know how to answer that question except that the OTHER port on it worked with suse 7.0 and auto :) The car itself is an OSA ENTR card running with both ethernet ports as ethernet I have my Suse 7.0 in port 0, and this one plugged into port 1. The chipid is 34, devices 830-83F. |-+ | | Mark Post| | | [EMAIL PROTECTED]| | | et | | | Sent by: Linux on| | | 390 Port | | | [EMAIL PROTECTED]| | | IST.EDU | | || | || | | 12/18/2002 02:10 | | | PM | | | Please respond to| | | Linux on 390 Port| | || |-+ --| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: Installing RedHat Linux | --| James, Is this a qeth/qdio card, or an LCS card? For qeth/qdio, the port numbers are the device numbers, and have to start on an even boundary. For LCS, you have to specify both the device number and the actual port. For more help, try the Device Drivers and Installation Commands manual at http://www10.software.ibm.com/developerworks/opensource/linux390/docu/l390dd 08.pdf Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED]]On Behalf Of James Melin Sent: Wednesday, December 18, 2002 12:26 PM To: [EMAIL PROTECTED] Subject: Installing RedHat Linux I've just started installing 2.4.7 of Redhat, and I've answered the network typ (escon etc,) with ETH0. It then is asking me for a device and port pair thing like escon0,0x600,0x601 etc. I know it should be eth0,0x???,0x??? but the install instructions I found on the CD are quite thin How should I know the port #? The device is chp 34, device 831. The other linux partiion is using device 831 any insight?
Re: LVM problem
Thomas, What does your parmfile look like when it works, and what does your parmfile look like when it fails? Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED]]On Behalf Of Thomas Emde Sent: Wednesday, December 18, 2002 10:05 AM To: [EMAIL PROTECTED] Subject: LVM problem Hi, I use SuSE Linux/390 7 (2.2.16, quite old I know). I had two 3390 disks put together in a volume group and several logical volumes running. I added a third 3390 disk to the linux (VM minidisk and added to parmfile, ran silo etc). During reboot vgscan reports that no volume groups can be found and after that of course the logical volumes are not existent. When I remove the new disk from my parmfile the lvm devices are found again...Any hint or help would be greatly appreciated. mit freundlichen Grüßen/with best regards Thomas =
High Availability
What kind of software do people run on Linux/390 for high-availability clustering? We're considering setting up two Linux servers on two different 390/IFL processors as printservers and want to be able to failover to the other processor when one fails or is taken down for service. And of course, we want to test it on our single IFL engine first. 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: High Availability
Gordon, look into using VM's CSE (Cross System Extensions) technology. It allows for implementing just such a failover technique and it's already included in your VM system. You can easily test your implementation by using two 2nd level VM guests coupled via a (v)CTC adapter. Contact me offline for all of the gory setup and configuration details. Dave Jones Sine Nomine Associates Houston - Original Message - From: Wolfe, Gordon WE [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 18, 2002 3:54 PM Subject: High Availability What kind of software do people run on Linux/390 for high-availability clustering? We're considering setting up two Linux servers on two different 390/IFL processors as printservers and want to be able to failover to the other processor when one fails or is taken down for service. And of course, we want to test it on our single IFL engine first. 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
Can I setup guestlan with zVM and the SUSE LINUX RAM system
Is it possible to setup a GUESTLAN between zVM and the SuSE SLES7 RAM SYSTEM (i.e. initial starter system)? Or do I have to use CTC first, then install the SuSE 2.4.7 system and then implement the guestlan between Linux and VM ??? Tia Dave
Re: Can I setup guestlan with zVM and the SUSE LINUX RAM system
Yes, this can be done. Just define the NIC and couple it to the lan before you IPL. James Johnson Email: [EMAIL PROTECTED] Systems Programmer Voice: 660-543-8065 Central Missouri State University Fax: 660-543-8123 - Original Message - From: Dave Myers [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 18, 2002 4:32 PM Subject: Can I setup guestlan with zVM and the SUSE LINUX RAM system Is it possible to setup a GUESTLAN between zVM and the SuSE SLES7 RAM SYSTEM (i.e. initial starter system)? Or do I have to use CTC first, then install the SuSE 2.4.7 system and then implement the guestlan between Linux and VM ??? Tia Dave
Re: Can I setup guestlan with zVM and the SUSE LINUX RAM system
In a message dated 12/18/2002 3:51:15 PM Mountain Standard Time, [EMAIL PROTECTED] writes: Yes, this can be done. Just define the NIC and couple it to the lan before you IPL. James Johnson Email: [EMAIL PROTECTED] Systems Programmer Voice: 660-543-8065 Central Missouri State University Fax:660-543-8123 - Original Message - From: Dave Myers [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 18, 2002 4:32 PM Subject: Can I setup guestlan with zVM and the SUSE LINUX RAM system you're sure that the SuSE RAM system will support this and you don't need the full SuSE system. I was wondering if the RAM system has the proper qdio qeth drivers for guestlan??
Re: Can I setup guestlan with zVM and the SUSE LINUX RAM system
I have done it. I use option 8, HIPERSOCKETS, on the network setup menu. James Johnson Email: [EMAIL PROTECTED] Systems Programmer Voice: 660-543-8065 Central Missouri State University Fax: 660-543-8123 - Original Message - From: Dave Myers [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 18, 2002 4:56 PM Subject: Re: Can I setup guestlan with zVM and the SUSE LINUX RAM system In a message dated 12/18/2002 3:51:15 PM Mountain Standard Time, [EMAIL PROTECTED] writes: Yes, this can be done. Just define the NIC and couple it to the lan before you IPL. James Johnson Email: [EMAIL PROTECTED] Systems Programmer Voice: 660-543-8065 Central Missouri State University Fax:660-543-8123 - Original Message - From: Dave Myers [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 18, 2002 4:32 PM Subject: Can I setup guestlan with zVM and the SUSE LINUX RAM system you're sure that the SuSE RAM system will support this and you don't need the full SuSE system. I was wondering if the RAM system has the proper qdio qeth drivers for guestlan??
Re: High Availability
Dave, Thanks for the reply. We've actually already looked into using CSE if it happens to go on two VM systems. Other possibilities are vm/linux and rs-6000/linux or intel-linux, or even a Unix system. In other words, one on a VM guest linux and one somewhere else as the failover site. So, the question still remains, What kind of software do people use on Linux/390 for high-availability clustering? 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 -- From: Dave Jones Reply To: Linux on 390 Port Sent: Wednesday, December 18, 2002 2:04 PM To: [EMAIL PROTECTED] Subject: Re: High Availability Gordon, look into using VM's CSE (Cross System Extensions) technology. It allows for implementing just such a failover technique and it's already included in your VM system. You can easily test your implementation by using two 2nd level VM guests coupled via a (v)CTC adapter. Contact me offline for all of the gory setup and configuration details. Dave Jones Sine Nomine Associates Houston - Original Message - From: Wolfe, Gordon WE [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 18, 2002 3:54 PM Subject: High Availability What kind of software do people run on Linux/390 for high-availability clustering? We're considering setting up two Linux servers on two different 390/IFL processors as printservers and want to be able to failover to the other processor when one fails or is taken down for service. And of course, we want to test it on our single IFL engine first. 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: Can I setup guestlan with zVM and the SUSE LINUX RAM system
On Wed, 18 Dec 2002, James Johnson wrote: I have done it. I use option 8, HIPERSOCKETS, on the network setup menu. Dave, if your z/VM is 4.3 and you are using the so-called QDIO Guest LAN (DEFINE LAN xxx QDIO), you will define your connection to the LAN as if it was an OSA-Express. If your using z/VM 4.2, or you have defined a HiperSockets Guest LAN on z/VM 4.3 (DEFINE LAN xxx HIPER), the option you will use is the one James mentioned. Regardless, the installation system contains the required drivers. It is when installing Red Hat that special action needs to be taken to include the qeth.o driver. Cheers, Vic Cross
Re: Debian cant find OSA adapter files
On Wed, 18 Dec 2002, Mark Post wrote: Well, there are two entries in there for eth0. I'm not sure which one wins, the first or last. The first, IIRC. I would verify which module name you have, either qeth.o or qeth-2.4.17-s390-3.o in /lib/modules, and delete the other one. Run depmod -a just for no good reason, and try it again. Yep. Most likely it will be under a subdirectory, but find /lib/modules -name qeth* will tell you which one it is. Your modules.conf entry must give the correct name, without the trailing '.o'. Keep in mind that on a Debian system you cannot make changes to /etc/modules.conf directly. For testing it's fine, but during your next reboot your file will be rewritten by a boot-time process. Look for the comments in your modules.conf that indicate filenames in /etc/modutils/ -- these are the files that you must edit in order to have your changes committed to /etc/modules.conf at the next reboot. Cheers, Vic Cross
Re: High Availability
Take a look at http://openmosix.sourceforge.net/ That is the open source product of choice since Beowulf, and others, decided to start selling the product. Unfortunately, I don't see an S/390 port for this product so I apologize of being off-topic with this reply. On Wednesday 18 December 2002 03:24 pm, you wrote: Dave, Thanks for the reply. We've actually already looked into using CSE if it happens to go on two VM systems. Other possibilities are vm/linux and rs-6000/linux or intel-linux, or even a Unix system. In other words, one on a VM guest linux and one somewhere else as the failover site. So, the question still remains, What kind of software do people use on Linux/390 for high-availability clustering? 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 -- From: Dave Jones Reply To: Linux on 390 Port Sent: Wednesday, December 18, 2002 2:04 PM To: [EMAIL PROTECTED] Subject: Re: High Availability Gordon, look into using VM's CSE (Cross System Extensions) technology. It allows for implementing just such a failover technique and it's already included in your VM system. You can easily test your implementation by using two 2nd level VM guests coupled via a (v)CTC adapter. Contact me offline for all of the gory setup and configuration details. Dave Jones Sine Nomine Associates Houston - Original Message - From: Wolfe, Gordon WE [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 18, 2002 3:54 PM Subject: High Availability What kind of software do people run on Linux/390 for high-availability clustering? We're considering setting up two Linux servers on two different 390/IFL processors as printservers and want to be able to failover to the other processor when one fails or is taken down for service. And of course, we want to test it on our single IFL engine first. 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: High Availability
Thanks for the reply. We've actually already looked into using CSE if it happens to go on two VM systems. Other possibilities are vm/linux and rs-6000/linux or intel-linux, or even a Unix system. In other words, one on a VM guest linux and one somewhere else as the failover site. So, the question still remains, What kind of software do people use on Linux/390 for high-availability clustering? It's a multipart problem. As Dave J mentioned, CSE is one part of the solution when there are Linux/390 systems involved, but there are some missing pieces before you can consider doing HA beyond a trivial load-balancing solution, primarily the ability to do frame-based bridging between internal LANs and external V:LAN infrastructure without paying a huge computational penalty. I think there's a couple of cases here: Case 1: HA for virtual machine implementations only. This has three sub-cases, VM HA, Linux HA, and application HA. Case 2: HA for mixed virtual machine/discrete machine, both Linux systems. This has several sub-cases as well, VM HA, Linux HA, application HA, HA signaling processes. Case 3: HA for mixed virtual machine/discrete machine, differing operating system. This has many sub-cases, some of which are VM HA, n cases of discrete machine HA, network HA, HA signaling, etc. At a crude level, layer 4 content switching (devices such as the Cisco Content Switch (aka Local Director and Distributed Director) or the Alteon/Big IP style solutions) is vendor neutral, and applies equally well to all three cases for handling distribution of incoming traffic to a set of systems. It addresses only 1 way traffic (from the outside to the server farm), and requires an agent of some type to run on the systems to detect heartbeat and feed back load information to balance work. Failover is handled in two sub-classes: system failure and system overload, both of which are handled by eliminating the failing or overloaded server from receiving new work. One still needs a HSRP/VRRP-style virtual address HA network solution for outgoing traffic as well. The current VRRP code does not work on Linux/390 systems using OSAs because the adapters do not return an error when attempting to set a duplicate IP address on multiple adapters. Adam Thornton has written a stopgap solution (VRT, available for download from www.sinenomine.net) that provides a limited virtual address takeover capability for Linux TCP stacks, and has recently added preferred interface processing for virtual addresses that allow better utilization of multiple adapters. Most people doing HA for Linux/390 are using this type of mechanism today, via an external load-balancing system. In a more detailed case, you need to address each level in turn. At the VM layer, you need both local clustering and remote clustering capabilities. CSE provides the local capability in that systems in a CSE cluster can share a CP directory and disk resources, allowing systems that normally reside on a failed VM node to be brought up quickly on one of the remaining nodes in the complex without having to worry about moving data around. ISFC, another CP feature, provides distributed IUCV processing which allows separating the TCP stack from the applications processing, which can be scaled independently of the network node processing (the old SNA CHOST concept, where one system owned the FEPs and everyone else did cross-domain sessions is alive and well here). If a particular node fails, ISFC can reroute IUCV traffic via other links to remaining systems (think of a crude counterrotating token ring architecture where the ISFC cluster is connected in a ring and one node fails). By starting with the VM layer and handling the basic structure, you take advantage of a lot of goodies that Linux doesn't necessarily need to know about -- it just sees the system keep running. Once that's done, then you can apply the existing Linux clustering tools over the top of the VM tools. The RH cluster tool works ok (if you have zVM 4.3) if you have dedicated Linux systems configured as layer 2 bridges (not routers -- just frame forwarders) to connect guest LANs between machines. This is ugly and expensive in terms of CPU cycles, as these tools tend to use a lot of broadcast and multicast techniques to keep things syncd up. Within a single box, they're fine, however that doesn't help the HA problem much. Other clustering tools exist, but have similar problems. Individual applications also have clustering capabilities (BEA uses a multicast based scheme, etc). Once you have the first two layers set up, it's up to the application to play nicely, and each one works differently. The basic assumption for most of them is that there be a broadcast/multicast capable network for scalability reasons. That's kind of the crux of the problem if you want to extend a solution outside the box; the cost of doing layer 2 frame-forwarding into a external VLAN is prohibitive -- you either have to dedicate a
Re: High Availability
Gordon, Dave and David have given you a lot of information already, but I wanted to at least mention the High Availability using clusters chapter in the Distributions Redbook that Carlos Ordonez wrote. It covers the topic at a readable level and may help you assimilate some of what's been discussed here. Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED]]On Behalf Of Wolfe, Gordon W Sent: Wednesday, December 18, 2002 4:55 PM To: [EMAIL PROTECTED] Subject: High Availability What kind of software do people run on Linux/390 for high-availability clustering? We're considering setting up two Linux servers on two different 390/IFL processors as printservers and want to be able to failover to the other processor when one fails or is taken down for service. And of course, we want to test it on our single IFL engine first. 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: High Availability
I don't know about anybody else, but my reaction to this was that it's a great blueprint for a really interesting SHARE session. :) Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED]]On Behalf Of David Boyes Sent: Wednesday, December 18, 2002 10:00 PM To: [EMAIL PROTECTED] Subject: Re: High Availability Thanks for the reply. We've actually already looked into using CSE if it happens to go on two VM systems. Other possibilities are vm/linux and rs-6000/linux or intel-linux, or even a Unix system. In other words, one on a VM guest linux and one somewhere else as the failover site. So, the question still remains, What kind of software do people use on Linux/390 for high-availability clustering? It's a multipart problem. As Dave J mentioned, CSE is one part of the solution when there are Linux/390 systems involved, but there are some missing pieces before you can consider doing HA beyond a trivial load-balancing solution, primarily the ability to do frame-based bridging between internal LANs and external V:LAN infrastructure without paying a huge computational penalty. I think there's a couple of cases here: Case 1: HA for virtual machine implementations only. This has three sub-cases, VM HA, Linux HA, and application HA. Case 2: HA for mixed virtual machine/discrete machine, both Linux systems. This has several sub-cases as well, VM HA, Linux HA, application HA, HA signaling processes. Case 3: HA for mixed virtual machine/discrete machine, differing operating system. This has many sub-cases, some of which are VM HA, n cases of discrete machine HA, network HA, HA signaling, etc. At a crude level, layer 4 content switching (devices such as the Cisco Content Switch (aka Local Director and Distributed Director) or the Alteon/Big IP style solutions) is vendor neutral, and applies equally well to all three cases for handling distribution of incoming traffic to a set of systems. It addresses only 1 way traffic (from the outside to the server farm), and requires an agent of some type to run on the systems to detect heartbeat and feed back load information to balance work. Failover is handled in two sub-classes: system failure and system overload, both of which are handled by eliminating the failing or overloaded server from receiving new work. One still needs a HSRP/VRRP-style virtual address HA network solution for outgoing traffic as well. The current VRRP code does not work on Linux/390 systems using OSAs because the adapters do not return an error when attempting to set a duplicate IP address on multiple adapters. Adam Thornton has written a stopgap solution (VRT, available for download from www.sinenomine.net) that provides a limited virtual address takeover capability for Linux TCP stacks, and has recently added preferred interface processing for virtual addresses that allow better utilization of multiple adapters. Most people doing HA for Linux/390 are using this type of mechanism today, via an external load-balancing system. In a more detailed case, you need to address each level in turn. At the VM layer, you need both local clustering and remote clustering capabilities. CSE provides the local capability in that systems in a CSE cluster can share a CP directory and disk resources, allowing systems that normally reside on a failed VM node to be brought up quickly on one of the remaining nodes in the complex without having to worry about moving data around. ISFC, another CP feature, provides distributed IUCV processing which allows separating the TCP stack from the applications processing, which can be scaled independently of the network node processing (the old SNA CHOST concept, where one system owned the FEPs and everyone else did cross-domain sessions is alive and well here). If a particular node fails, ISFC can reroute IUCV traffic via other links to remaining systems (think of a crude counterrotating token ring architecture where the ISFC cluster is connected in a ring and one node fails). By starting with the VM layer and handling the basic structure, you take advantage of a lot of goodies that Linux doesn't necessarily need to know about -- it just sees the system keep running. Once that's done, then you can apply the existing Linux clustering tools over the top of the VM tools. The RH cluster tool works ok (if you have zVM 4.3) if you have dedicated Linux systems configured as layer 2 bridges (not routers -- just frame forwarders) to connect guest LANs between machines. This is ugly and expensive in terms of CPU cycles, as these tools tend to use a lot of broadcast and multicast techniques to keep things syncd up. Within a single box, they're fine, however that doesn't help the HA problem much. Other clustering tools exist, but have similar problems. Individual applications also have clustering capabilities (BEA uses a multicast based scheme, etc). Once you have the first two layers set up, it's up to the application to play nicely, and
Antwort: Re: LVM problem
Hi, it looks as follows when it's working: dasd=400,410,440 root=/dev/dasda1 noinitrd ctc=noauto vmhalt=M OPERATOR LINUX DOWN vmpoff=M OPERATOR LINUX DOWN and like this when not: dasd=400,410,440,450 root=/dev/dasda1 noinitrd ctc=noauto vmhalt=M OPERATOR LINUX DOWN vmpoff=M OPERATOR LINUX DOWN 410 and 440 are the pv's which I put together in my vg. best regards, Thomas An: [EMAIL PROTECTED] Kopie: Thema: Re: LVM problem [EMAIL PROTECTED] DU Received : 2002-12-18 21:56 Bitte antworten an Linux on 390 Port Thomas, What does your parmfile look like when it works, and what does your parmfile look like when it fails? Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED]]On Behalf Of Thomas Emde Sent: Wednesday, December 18, 2002 10:05 AM To: [EMAIL PROTECTED] Subject: LVM problem Hi, I use SuSE Linux/390 7 (2.2.16, quite old I know). I had two 3390 disks put together in a volume group and several logical volumes running. I added a third 3390 disk to the linux (VM minidisk and added to parmfile, ran silo etc). During reboot vgscan reports that no volume groups can be found and after that of course the logical volumes are not existent. When I remove the new disk from my parmfile the lvm devices are found again...Any hint or help would be greatly appreciated. mit freundlichen Grüßen/with best regards Thomas =
Re: Can I setup guestlan with zVM and the SUSE LINUX RAM system
At 17:56 18-12-02 -0500, Dave Myers wrote: I was wondering if the RAM system has the proper qdio qeth drivers for guestlan?? Yes, it does not ;-) The anonymous beta trial (or whatever SuSE defined it) is from Oct 31, 2001 as far as I know. That one does support Hipersockets and has the 'Option 8' in the installer but AFAIK it did not work with z/VM Guest LAN. My notes say qeth-2.4.7-s390-8.o was the first that worked with Guest LAN (and we also needed VM maintenance for that) and that is from Feb 28, 2002. I believe that when you ordered an evaluation copy from SuSE after May 20th or so, then you should have received a CD that has an updated initrd and default kernel. This version also offers the kernel with 'on demand timer' patch enabled. And if I am wrong that is because it is not on the public pages and I cannot tell what SuSE send others. So the old version has two problems w.r.t. Guest LAN: 1. The starter system fails to establish a connection through Guest LAN 2. The kernel you install with the starter system cannot use Guest LAN If you really want to make this work with the public beta, then you could open up the initrd from suse/images and put fresh OCO modules in. After you used it to install the supplied default kernel, you mount the disks again and copy the qdio and qeth from your ramdisk system onto the installed system. You'll also need the -f option on insmod. Rob
