David - thanks. This is what that I was looking for.
-----Original Message----- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of David Boyes Sent: Thursday, February 10, 2005 1:17 PM To: [email protected] Subject: Re: Why Zseries > What I was looking for is why choose Zseries Linux over ANY OTHER > operating system's Linux ? Well, to take your original question: The main reasons for running zSeries Linux are: 1) Direct application compatibility from other platforms while adding the reliability of the zSeries hardware. USS is POSIX-compatible, but I'd challenge you to name any major applications that claim "POSIX" compatibility -- developers still write for Unix dialects, and the Linux dialect has become the dominant Unix API dialect format. USS doesn't even show up on the radar for most developers. 2) Close binding with existing mainframe-hosted data without incurring major data update and synchronization hassles (one copy, one update point, no worries about out-of-sync data). The data stays on the mainframe, and things. 3) Hardware investment avoidance. Most shops have *some* spare zSeries capacity that can be pressed into use, and intelligent use of IFL cycles to augment existing applications can allow you to significantly delay increases in z/OS or other IBM OS investment, or even actively reduce the size of your standard engine committment by moving workload to the IFL side of the machine at about a 75% decrease in the cost of additional capacity (eg a IFL costs about 25% of a standard engine). 4) Development tool sophistication and availability. Linux has some of the best development tools in existance bundled with the OS, and more are written (and a "make; make install" sequence places them on the zSeries platform as soon as they are available) every day. USS has almost none, and the porting process is time-consuming and annoying, resulting in almost zero new or interesting tools for USS. 5) Cost of training. USS is very specialized, and very rare. You are highly unlikely to find people who understand USS at any price, let alone the $30/hr that most shops seem to want to pay for developers/operators/systems people. Linux-trained people are a dime-a-dozen, and teaching someone who already knows the Linux environment "just enough" mainframe skills to get Linux going is a lot less expensive than teaching someone "just enough" z/OS skills to get by in USS-land. On the other side, USS does have some positive aspects: 1) If the application absolutely, postively *can* *not* *break* for any reason, USS wins hands-down on out of the box resilience. USS can take advantage of all the power of sysplexes, XCF, PPRC, all that good stuff that z/OS can do for RAS right out of the box. It inherits it from the z/OS base. You still have to do some programming to be aware of these features and react appropriately when something happens, but the kind of reliability that these features provide is unmatched anywhere else, no matter what any of the clustering vendors say. 2) USS software maintenance is included in your z/OS bill. You need to purchase from and manage an additional vendor (yes, I know you can buy Linux maintenance from IBM, but it's still really expensive for what you get). The vendor "support" from the big players isn't all that terrific either, so you really need to go outside that environment to get in-depth support for Linux on Z. 3) USS is much more integrated with z/OS data and access methods. You can access USS-managed data from z/OS batch, directly in JCL like normal. WRT your second question: Much of the advantage of zSeries Linux is tied to exposing mainframe-hosted data in more friendly ways. Most of the advantages I listed above apply also to Linux on other systems, but the fact that the Linux system does not share the same hardware as the z/OS system gets you into the data management and synchronization problems I mentioned, and it also incurrs additional hw and physical equipment maintenance, plus provisioning costs which (by the time you actually deploy an application and all the additional hw necessary to really support the application -- development servers, QA and test, regression, etc) don't really make it much of a savings. The big wins for Linux on Z are flexibility and cost-avoidance, played against inexpensive acquisition and familiarity of Intel hardware. YMMV, and Linux on Z isn't right for everyone. Right tool, right job. -- db ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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
