I've had the same type of problems. Documentation, what documentation.

For an installation that changed so much between Sles7 and Sles8, you
think they could have written something.

My way was and still is, SMB under Windows.  But, Sles8 requires Win/98
or above for SMB support.

Then during installation source, select Samba, give it your SMB IP
stuff, then it can't find it which gives you another screen that
includes SMB, then give all the info again and you finally get it.

Of course, you can't use PUTTY at this point.  You need a GUI interface,
VNC or VNC under a browser.  Great, they at least told us about VNC, but
didn't explain anything.  I guess I was suppose to have sufficient
Linux knowledge to know about VNC.

And don't try using PUTTY from Sles7, you need the PUTTY from Sles8 to
support ssl.

All of these stupid little things, that should have been documented,
sure took a quick install and turn it into a process spanning two weeks
(of course not full time).

It is nice they include the Redbooks with CD1.  Too bad none of the
installation stuff applies to Sles8.

It would have been nice to have a document of "what has changed" and how
to work around it.

I thought for sure that the FTP server in Sles7 automatically came up.
I had to enable it via YaST for Sles8.  I spent a few hours looking at
it from a security item (ssl for FTP?) instead of it just not being up.

And having to issue a STOP and START to the TCPIP machine everytime I
boot Sles8 is really a pain.

I havn't had any abends.  (yet)  I'm on the November 2002 distribution
that I down loaded from the maintenance web site.

Now, I understand CD2 and CD3 has other code on it.  But just what is a
"supplemental CD1 and CD2"?  What is the difference between the
supplemental cds and the regular cds?  I haven't found any documentation
on it, but I haven't looked at the supplemental CDs either.

Tom Duerbusch
THD Consulting

Steve Brouse wrote:

We have been using SuSE on our Z900 on an IFL running zVM.  We have worked
with S390 version 1, SLES7 and now SLES8.  We did get their Premium support
contract with SLES7 which gave us a upgrade to SLES8.  SLES8 has not been
going very well.  The documentation they provide on CD1 is poor.  It does
not cover anything in any detail about the installation.  We could not get
the install to work using SAMBA, worked with their support and they had no
idea how to fix it.  We copied the image of CD1 and CD2 to another Linux
server and tried the FTP install method.  It went thru CD1 but never did
CD2.  The current install method has only 2 choices for what to install,
the instance size now takes about 2 gb.  We have been working with their
support structure again but get poor responses and lots of questions, few
answers.  Even with their newest kernel (k_deflt) fix it abends after a few
hours of operation.  Their premium support says they guarantee 2 hour
turnaround, 7 x 24, that all most never happens.  YAST has been totally
redone, the doc in the SLES8 Installation guide is only several pages.
Lots of things that used to work by default, (ftp, kde, apache), do not
anymore, no documentation at all.  In my opinion SuSe has not gotten
better, but worse.  I have found out that IBM offers a support contract and
we may pursuit that when this one runs out.  I to am interested in Red Hat
because we may even drop SuSe all together.  If anyone has gotten SLES8
working I would like to hear about that also.

Thanks,
Steve Brouse
Manager of Mainframe Operating Systems Group
AES/PHEAA







                     "Hall, Ken (IDS
                     ECCS)"                   To:      [EMAIL PROTECTED]
                     <[EMAIL PROTECTED]         cc:
                     .ml.com>                 Subject: Re: RedHat vs Suse
                     Sent by: Linux
                     on 390 Port
                     <[EMAIL PROTECTED]
                     RIST.EDU>


05/29/03 08:51 AM Please respond to Linux on 390 Port






For Intel, I'm partial to Redhat, but on 390:


1) The SuSE distribution (SLES8) has more current versions of components
like the kernel.

2) The networking OCO modules are already part of the package.

A number of fairly annoying bugs have been fixed in SLES8 too.

The folks here were never able to get Redhat working, but SuSE has gone in
fairly easily on both SLES7 and 8.

The downside of SuSE is that you have to pay for the maintenance agreement
to get it, where Redhat can be downloaded for nothing.



-----Original Message-----
From: Post, Mark K [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 28, 2003 4:08 PM
To: [EMAIL PROTECTED]
Subject: Re: [LINUX-390] RedHat vs Suse


Duane,


I would not say that any of the Linux/390 distributions "work
better with
VM" than any of the others.  I also have my doubts that
DSPACE (what ever
that is) would "run better" on one Linux/390 distribution
versus another.
Without more information, that sounds a lot like magical
thinking rather
than anything else.

Use the distribution that you're most comfortable with
overall (using what
ever criteria you might have for that).


Mark Post


-----Original Message-----
From: Duane Weaver [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 28, 2003 1:34 PM
To: [EMAIL PROTECTED]
Subject: RedHat vs Suse


We installed SuSe Linux under z/VM on a z800 box, under the belief that SuSe Linux worked better with VM and the hardware. There is a desire to put something called the MIT DSPACE project. There is a belief that DSPACE would run better on RedHat.

I am interested in talking to anyone who installed RedHat Linux under
VM.    HAve you had any trouble with  RedHat.  Did you have to do any
modifications to make RedHat run under VM?

Is there any truth to the belief that SuSe Linux works better with VM?

duane


>




This message contains privileged and confidential information intended for the above addressees only. If you receive this message in error please delete or destroy this message and any accompanying documentation after contacting the sender. The sender of this message will fully cooperate in the civil and criminal prosecution of any individual engaging in the unauthorized use of this message.



Reply via email to