On Thu, 29 May 2003, Tom Duerbusch wrote: > > My way was and still is, SMB under Windows. But, Sles8 requires Win/98 > or above for SMB support.
My personal thinking is that M*S dropped support Win95 long years ago, it's no excuse however, but I can't find Win95 anywere near. I assume it should be possible to install from Win95 with special guidiance, but it at least needs a special mount command which you have to do by hand and behind the covers. I'm sorry that I can't say more. Side note: Two years ago I have been told that it's really useful having a Notebook which can take some CDs which has (preferably) Linux Installed and a known to be good SMB/FTP/NFS server running together with good tools for remote login. I think this is still true today if it's not sure which installation servers are available. My apologizes to all for all the installation problems and changes the update from SLES7 to SLES8 brings and I think it should be possible to fill a little book with all the changes. For now, the only thing I can do is to suggest to create a stable installaton environment for such cases which you can take with you and ask for support if you encounter problems with this environment. > And having to issue a STOP and START to the TCPIP machine everytime I > boot Sles8 is really a pain. CTC was the first connection which worked for VM connectiviy with Linux, but as others also told, IUCV has grown up. It connects instantaneous, you don't have to take care of coupling and don't have to wait for emulated hardware negotiation to complete before you can talk to the other side. The other thing I know is that this type of problem does not happen if the other side of the CTC connection is not VM TCPIP but another Linux guest and if both Linux Guests have the CTC I/O Error retry fix which has been developed at my suggestion by the Linux CTC driver maintainer. It adds a timer which restarts the CTC setup after I/O errors. This fix has been integrated into SLES8 GA and SLES7 maintenance. If you run kernels with this fix on all CTC machines and the router is also a CTC machine with this fix, all CTC machines will properly recover from a reboot on the the other side. I have tested this on a big CTC setup with many guests where we changed the Router of the CTC connection from VM TCPIP to SLES7. The thing was(like in your case) that if one side of the CTC connection is rebooted, it is possible that the other is get's an I/O Error, e.g., if it tries to send a message while the other side is rebooting. Recovery from an I/O Error was not implemented, because an I/O Error was sonsidered as an Hardware error which is not recoverable. Now, without the recovery patch I suggested, if you reported some of the Linux Guests, they sometimes did came back like what I have seen here: It comes up, reports no error but there is no connection. Now, if I looked what happened at the Linux Router side of the CTC connection, I saw an I/O error, which was not recovered as it was thought it is a non-recoverable hardware error. But if you did an ifconfig down and an ifconfig up(to restart the ctc setup manually) for the ctc interface on the Router side, there has been a chance that they reconnected. Of course there was the possibility that the Linux Guest not got an I/O error and you play the recovery game again. I suggested to fix this to do the action which ifconfig down->up causes in the driver on a timed interval if an I/O error occured, and the implemetation of it and install of the fix on both Linux guests of the CTC connection fixed this problem. This looks like to me as if VM TCPIP does not set such recovery timer up to restart the CTC setup on a regular interval if the CTC connection on the VM TCPIP side terminated because of an I/O error which was caused by the Linux Guest reboot. I have no idea why this did not happen with SLES7 in your cases, I see either changes in the hardware setup between the August 2001 code stream which SLES7 is based on and the May 2002 code stream from Developerworks which SLES8 is based or an VM update in combination with this. On a personal note, I also think that using Linux Guest(s) with QETH as Router(s) for Linux Guests are more powerful than using VM TCPIP: VM TCPIP needs less disk space and memory, but on the other side, if you use Linux Guest(s) instead of VM TCPIP for routing, you have some other benefits: - You can implement a redundant two-router failover configuration in which e.g. if something bad happens to one router (Cable pull on the OSA Express card or other Hardware Failure which affects the OSA Express card) the other Router can detect this and automatically take over. This is also nice if you need to do a Micorcode Update or the OSA Express cards which is not concurrent for the card so that you have to vary the card off and on in order to load the new microcode. In this situation the fallback router (even if not setup automatically) comes handy. This is especially nice if you use Hipersockets/VM Guest Lan and not CTC as connection because then you connect both Linux Routers and all other Machines which support the Internal LAN to the same internal LAN and you can do the failover of the router without having to recouple the CTC connections, the fallback router can just take over if the router in charge stops working for some reason. If you have such setup, you can even see live that VM's TCPIP goes down because of an Hardware/Cabe failure or an non-concurrent OSA Express Microcode update while having your Linux Guests working unpertubed from the VM TCPIP restart... (Ok, except for the 3215/3270 consoles of your Guests, but one day in the future, it may be possible to do this over iQDIO or some other facility as well, maybe even with character oriented console so that you can use real curses applications on the Linux Console on S/390 in a redudant way some day...) (( Of course the console server should be Linux as well )) - You can do things like NAT, firewalling, transparent proxying, whatever. - You can login into the router, change and fix CTC/IUCV/HSI interfaces without having to touch VM TCPIP! - You can teach this to Linux network people without to tell them about 3270 and what to do there. > Now, I understand CD2 and CD3 has other code on it. But just what is a > "supplemental CD1 and CD2"? Things which have not been identified as components of SLES8 but might be needed for some things but as they are not part of SLES8, we put them on separate CD so you can used them if you need. It includes things like profiling libraries for glibc, dejagnu, doxygen, GNU Objective C(only to name a few known things) cpint(to name one which you might find useful) and many other things I and most of you have never heard before. It's a free add-on gift, nothing more, Supplemental CD2 contains the sources for the RPMs on Supplemental CD1. Bernhard (usual disclaimer about my opinions, other opinions, ...)
