My impression was that overall it was not bad. In fact, it was fairly simple. However, I did not install on a real zSeries. I run Hercules/390, a zSeries emulator, on an AMD Athlon64 3800+ at home. From watching the emulator's control panel, it could maintain about 30 emulated MIPS. This resulted in a very slow installation. I basically would leave it alone and check on it periodically. I started late Friday night. Once I got to the part where it was finished asking questions, I just left it. It was complete by Saturday morning when I got back from a drive and walk with my dog.
The installation, other than being slow, was relatively easy. I IPL'ed as if I were IPL'ing from a CDROM. I then did an "ftp" installation. The ftp server was the Linux system running on the same Athlon. I did a loopback mount of the ISO files onto subdirectories on that system (subdirectories cd1..cd4). On the installation screen, I listed the "cd1" subdirectory as the installation source. I don't know if the installation used any of the other "cd?" subdirectories or not. I do know that I was not prompted to change any media. Again, other than simply being very slow, the system (in my very minor testing on Sunday) ran with no problems. I doubt that a Flex-ES licensee would have any use for zSeries Linux, but I know that unless FlexES is significantly "better" than Hercules/390 (which is possible, of course), that they are likely to be disappointed with its performance. The same physical hardware, running MVS 3.8j (31 bit s/390 emulation, not 64 bit zSeries) has much better "responsiveness". I've run TSO (no ISPF, of course) and RPF (a free, mini-ISPF like environment) along with a batch job with acceptable response time. I don't know if this means that Hercules does a better job with 31 bit S/390 emulation or that MVS 3.8j is just more CPU efficient than Linux. Perhaps it is a bit of both since MVS 3.8j contains many assembler based modules instead of being C based. Does anybody have any idea as to what a acceptable "minimum" CPU might be. I know, "It depends on what you want to do." It was a rhetorical question. === I do have a question about the license that come with SLES-10. It states that I will stop using SLES-10: (1) after 90 days or (2) when a new release is available. I am fairly sure that Novell doesn't really much care, one way or another, what I do in the environment described above (emulator on AMD at home, not a real zSeries). But what exactly does that license mean? Why should I be restricted in this way? And to what does the restriction apply? As best as I can tell from the GPL, Novell cannot tell me that I cannot use the kernel or the other bundled GNU utilities after a certain amount of time. In fact, if my understanding of the the various licenses are correct, they cannot restrict my use of any GPL'ed or otherwise freely licensed software. So the above license would only apply to Novell licensed code, such as "yast". Am I correct in this? Not that it really matters, even if not legally bound in all ways, I feel morally bound simply because I agreed to be. Also, I don't really have any use, beyond learning, for SLES-10 on zSeries. So, I'll likely burn the emulated DASD to a DVD for "archival purposes" and eventually erase it from the Athlon. === I wonder if it would be worth while to try to get this installed on my company's z890. We originally had a z800 with an IFL. We did run z/VM for a short while and a very old SLES beta on the IFL. We upgraded to a z890 and so have an unused IFL on the system. I would need to create an LPAR for the Linux system. And I cannot really figure out what I'd use it for, other than my amusement and "training". The other z/OS people here are just "not interested" as best as I can tell. Another question comes up on this point. For those of you who run Linux in multiple LPARs and not z/VM. Does every LPAR have access to all DASD addresses? Or do you "subset" the DASD addresses so that each LPAR is isolated for every other LPAR? If you share DASD addresses, how do you assure yourself that one Linux system does not accidently get access to another Linux system's DASD? That is, do you depend on the sysadmin "being careful"? Or are you as paranoid as I <grin>? === Just a bunch of OT questions. Can anybody tell me the real difference between the SuSE Linux 10.1 that I can buy (for Intel/AMD) versus the downloadable SUSE Linux Enterprise Desktop? It is just a matter of support? Or maintenance levels? Or are there "extras" in SLED that are not in the "home" version? From my cursory reading, it appears that SLED can "join" into a Microsoft "Active Directory" based domain. Is this true? If so, is there any doc as to what it can and cannot do? We do a lot of things here that are based on "trust" and "automatic logon" (or whatever it is called) between our desktops and various MS based servers. Would it be possible for SLED to replace an XP Professional desktop in a very Active Directory centric environment? Very off-topic, so I hope nobody minds the "piggy back" questions. Oh, you might want to respond to these questions directly to me at mailto:[EMAIL PROTECTED] . Many thanks. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
