I don't come from a mainframe background so thanks for the info.....:)) ----- Original Message ----- From: "Wade Curry" <[EMAIL PROTECTED]> To: "Main Discussion List for KPLUG" <[email protected]> Subject: Mainframe clarifications Was: VM and hypervisor clarifications....... Date: Sat, 22 Oct 2005 21:15:10 -0700
> > Randall Shimizu([EMAIL PROTECTED])@Sat, Oct 22, 2005 at > 02:54:19PM -0800: > > There seemed to be a lot of confusion regarding the functiona > > definiton of a hypervisor so I will elucidate: > > > > Hypervisor: (http://en.wikipedia.org/wiki/Hypervisor )A > > hypervisors main function is manage different VM's. Hypersvisors > > is also responsible for the instantiation and termination of a > > VM. Now there is both a software and hardware based hypervisor. > > VMware and IBM's DLPAR (Dynamic logical partitioning) technoogy > > are both of this iteration. The hardware based hypervisor is it's > > own OS. This allows the system to remain up even if the other > > VM's crash. IBM"s has had hardware hypervisors ever since the > > introduction of S/390. > > I had to read that a couple of times. The last statement is > misleading. S/390 is the previous line of mainframe systems from > IBM. That is, I think, the first version that could create LPARs. I believe that hardware hypervisors were introduced after the introduction of the S/390's. > That is, the hardware could be partitioned up to 15(?) ways. The > technology that allows that is called: PR/SM (Processor > Resource/System Manager). It is tempting to simply say that this > is just a harware hypervisor by another name, but I don't think > that is accurate because the main reason for its existence is to > isolate the hardware resources. The purpose is isolate VM and OS resources, although hardware is seperated virtually. So, what you have is a very > strictly divided system. Clearly there is some system > virtualisation going on, but I don't think that's all there is to a > hypervisor. > > I'm not sure why you would think that this hardware capability > constitutes its own OS. Well on VMWare's ESX you are loading actual OS on the ESX card itself, which acts as the host OS. > > > > > DLPAR is highly advance load balancing VM technology on IBM's > > Power and PPC platforms. DLPAR has the ability start or end new > > VM's as the systems requirements is changing. VM technoogy is not > > a new technology at least for IBM Z-Series. > > IBM"s MVS (Multiple Virtual Systems) refers to multiple VM's > > running multiple instances of S/390. > > MVS *really* stands for "Multiple Virtual Storage". The name > existed before LPAR functionality, and was first used to refer to > OS/370. The S/360 was able to address a whopping 16MB of central > storage (memory, in mainframe jargon). The OS/370 saw that > increase to 64MB, but that was only the half of it. It also included > a hardware feature that translated the address space for each of > the programs that were running (there was a limit of 15 concurrent > programs). Each running program actually was swapped out to DASD > (hard disk) and each one "thought" it had the run of "all 16 MB", > because it had its own addressable virtual storage. Hence the > name. > > S/390 refers to hardware, while OS/390 refers to one of the IBM > operating systems that runs on it. The current hardware is called > z/Series, and the OS is z/OS (all 64-bit, and still called MVS most > of the time). The other mainframe OS that hasn't been mentioned is > z/VM. That one has a hypervisor. > > > But beyond all this the > > S/390 can run simultaneous parallel trancations > > I'm not sure what you're getting at here. It sounds like you're > talking about multitasking. You don't need a parallel sysplex for > that. > > > (IBM parallel > > sysplex: allows for clustered Z-series boxes) > > They can be kind of like clusters. Often times they are not like > clusters so much. For example, all the LPARs I work on are part of > some sysplex, but they remain mostly distinct. LPARs share the > storage complex, and they can share processor cycles, too. > Sometimes you'll see one LPAR usng 125% of it's processor cycles. > This is because another LPAR in the sysplex gave some up for it to > use. As far as I know, in clusters, you'd usually expect > _processes_ to be shared rather than cpu cycles, so this is > somewhat different. I am pretty sure this is done at a couple of > different levels. Part of it may be done by JES2 (system software > that controls the availability of resources and job execution--This > is the software that you are talking to when you write JCL). > > > as well with full > > rollback cability. > > Back to transactions. This is important in some areas of MVS > software, but it isn't everywhere. IMS and CICS are two different > (ubiquitous) ways to provide an application framework and the > ability to connect. I'm more familiar with IMS, and it does have > checkpointing plus copious logging of the transactions and all the > resources and datasets (files) that were used. > > > So in other words a enterprise has not only > > system fault tolerance, but application fault tolerance as well. > > So it becomes clearer why so many forturne 500 enterprises still > > run mainframes. > Well for one thing mainframes can deliver up to 7 9's of reliability. IBM's line holds record for the longest uptime of any system. I heard awhile back that one S/390 was up for almost 7 years I believe. The x86 platform can still only deliver 5 9's of reliability.... It's getting much better, but there is still system throughput issues that is unresolved.. > Mainframes are much more popular than is widely known outside big > business. I don't think stability is the main reason for the > businesses' heavy reliance on them, though (although it is a > factor). I believe it has to do with the fact mainframes have > specific features that "pointy-hairs" and "bean-counters" love. > > Nearly every facet of mainframe system software is extremly > modular, configurable, and customizable. Also, everything is > logged. You think you have seen lots of logs in /var/log? You > ain't seen nothing. Further, you can configure exactly what > processes/jobs get what resources first at several levels. In a > business where they are continually scrutinizing costs (licensing > for each LPAR, CPU cycles, DASD disk space, ad nauseam) the > logging, configurability and control is essential. > > MVS mainframes have a menu-driven user interface, a reliance on > JCL, and a much less flexible end-user environment overall. On the > other hand, *nix shines in its flexibility and user interface, IMO. > It just wasn't developed with business in mind. Even the clusters > that are being built now seem to me to be much more directed at > research than business. The software that businesses rely on > strongly to run their mainframes and applications are either just > getting started, or are non-existent in the unix world. > > Just for the sake of completeness, z/VM (which I am not familiar > with) started out as a skunk works project at IBM, and wasn't > released until long after MVS. Besides being used as a regular OS, > it provides a hypervisor and virtual machine capabilities in > addition to what the hardware offers. It is the OS that is used > when people set up linux server farms on a mainframe. It is also > generally considered to be less stable than MVS by the folks I work > with. I can't tell if that is a justifiable bias, or not. > > I hope that was clear, and interesting to at least one other > person ;) > > Wade Curry > syntaxman > > > -- > [email protected] > http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list -- ___________________________________________________ Play 100s of games for FREE! http://games.mail.com/ -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
