Sorry it has taken me a while to get back with my retorts.  I had to
wait until after lunch to be able to digest all the great info you
sent.


"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."

True.  But SLES7 worked with Win/95's SMB support.  And since there
wasn't any documentation that I found that said that Win/98 or better
was needed, I tried my tried and true Win/95 box.

Part of this is after being shot in the foot many times, I try to keep
the number of changes to a bare minimum when installing a new release.
Once I see everything is up, I may reinstall again, with newer ideas.

I have a Win/2000 workstation sitting next to the Win/95 box.  Once
support told me of the Win/98 miminum, I added SMB support to the 2000
box and on my way.

"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."

I agree, but sometimes just not doable.  Acquiring a laptop from a
client for Linux, adds to the perceived cost of Linux.  If I buy one (my
laptop is dedicated to OS/2), then the client wonders if they can
support Linux without my laptop.  So, that is why Windows with SMB on
the client supplied PC, seems to work better...politically.

"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."

Once I documented the new install process with SMB, it worked just
fine.  I have done full installs 4 times using this process.  Just
playing.  Now working on installing with /usr and /var on separate disks
for sharing purposes.

"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."

Again, the reason why I didn't use IUCV, was to minimize changes during
an unfamilar install process.  Now that I have SLES8 up and running, I
plan on installing another copy with IUCV enabled.

"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."

Well, some of what you have mentioned is over my head at this point.
But as we have a single IBM 3172 with a single ethernet card, we
currently have no redundency.  We have had problems with Samba trying to
broadcast over a point to point link (VCTCA), but the Redhat web site
had a fix for it.  I do expect to implement guest lan support, but the
IP address for the VM (205.235.227 subnet) is different than the subnets
used for VSE and Linux guests (192.168.99).  Seems to though another set
of "changes" to the implimentation of Guest Lan Support.

> 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."

OK, if the Supplemental CDs contain these things, what does CD2 and CD3
contain?  I mean, what's the difference in the code?  Does CD2 and CD3
contain code that Suse supports and the Supplemental CDs contains code
from other venders?

To me, being a mainframe type, all that stuff looks the same to me.


Thanks

Tom Duerbusch
THD Consulting

Reply via email to