Re: (slightly OT - Linux) Did IBM bet on the wrong OS?
BSD would have been interesting, the environmental differences between Berkley and Armonk. That would have been something that I would have payed good money to watch. Matter of fact I'd still pay good money. B On Sat, Apr 24, 2010 at 6:30 PM, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In o2l1a208dd1004200306oe33d7275gc56199a0ef19f...@mail.gmail.com, on 04/20/2010 at 03:06 AM, Bob goolsby bob.gool...@gmail.com said: And what would have been the alternative OS for IBM to have backed? OS/2??? Yes. Barring that, what about *bsd? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Bob Goolsby bob.gool...@gmail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Calling unauthorized code from an authorized address space
On Sat, Apr 24, 2010 at 2:17 PM, Binyamin Dissen bdis...@dissensoftware.com wrote: : There is no way to dance around it or pretend :otherwise. The only way you could avoid the exposure would be to guarantee :that no authorized code code could ever run within the address space after :you have allowed the unauthorized code to run. There is no way to guarantee :that in general and in any case, it would effectively eliminate the value of :that address space as a server for hosting this function. Why this requirement? It is fairly clear that it is a requirement for the OP's proposed application - else why bother with the elaborate schemes to temporarily remove authorization? He wants to run his authorized code and his client's unauthorized exit code within the same address space, presumably without restarting his server address space each time he gets a new client request. And since that can't be done safely, there's no point. The only case that leaves open is a garden variety key 8 APF authorized :address space. If you turn off JSCBAUTH before invoking the unauthorized :code, then it is true that code would NOT be able to MODESET to a system key :or get into supervisor state while it is running, however that isn't the :only exposure. While they are running, they can easily diddle with the data :belonging to the other tasks providing the privileged application :functionality in that space. Most of the system owned data areas will be key :0, 1 or 5 (and thus whey would be safe) but most of the areas owned by the :worker tasks will be in key 8. All of those areas would be susceptible to :modification by your unauthorized code when it runs. If such a modification :occurred and ANY privileged code continued to run, their data would :potentially be invalid and that is an integrity violation in and of itself. :Beyond that, a little creativity would get your unauthorized code back in :control in a privileged condition - thus violating integrity. Why must the authorized work areas be in key 8? It isn't that they MUST be. Merely that the (initially APF-authorized) application running within the address space WILL get key 8 storage for every task or step-owned low private subpool allocation UNLESS it goes out of its way to run in a system key and use only key-selectable subpools (kind of an odd exercise given they chose not to have a system key assigned via PPT, but I'll play along). However, even if it did attempt to avoid using task-key storage there would still potentially be an unknowable number of task or step owned data areas laying around in key 8. That's the deal breaker. If you let unauthorized code run within that same address space, you cannot guarantee that the unauthorized code won't be able inspect or modify the authorized application's data. In fact, it is guaranteed that the unauthorized code could do exactly that, which is by definition an integrity exposure just on its own merit. But even worse, if any of the APF application's tasks had already switched to supervisor state and continued to run during or after when the unauthorized code had been allowed to run, then there's a very high likelihood that the unauthorized code could fool that supervisor state code into violating integrity. You could do it. I could do it. There just isn't any safe way to avoid that in general. There are too many moving parts in a typical address space and not all of those parts (e.g. home grown exits and/or ISV code) are going to be in on the secret of what's supposed to be going on. Disagree if you like but you would be flying in the face of literally decades of integrity studies. While we're at it, let's not forget that (again, unless the authorized application goes out of its way) the unauthorized code is going to get control with the security identity of the server where it is running (usually some sort of production ID) Of course, that can be handled too, but the number of things that have to go just right in order for the OP's idea to work out is enormous and it only takes one slip for the whole house of cards to fall down. :Removing authorization must therefore be a complete one-way trip :because other tasks in the address space may have already switched into :supervisor state and be running independently of your unauthorized code. I :am deadly serious about this. If you (knew enough to) do the thought :experiment you would soon realize that there is literally no way to prevent :these exposures. Abandon hope. False. : Abandon hope. It won't be easy. : Now a question about TCB creation. After control is returned from the : problem state program to the caller, it should be possible to see if it : ATTACHed any new TCBs. If new TCBs were created, I could abend the entire : process instead of flipping the JSCBAUTH bit back on. This would ensure : that when the user exit returned to the caller, none of the
Re: Turning on ACF2 SECURITY Privilege through an exit . . .
On Fri, 23 Apr 2010 14:25:20 -0400, Bathmaker, Jon jon.bathma...@credit- SUISSE.COM wrote: I can handle the truth. You could get the effect you desire by turning on the SECURITY flag in the in- storage copy of the user's LID. The LID is pointed to by ACULRECP in the ACUCB, and there is a macro, ACFGUCB, which will give you the ACUCB address. Of course, the LID is in protected storage so it would require an APF authorized program or something like exit running in key zero in order to update it. Once you do that the user will be treated as if they have SECURITY - subject to any scope list that might be set on the LID unless your code messes with that too. As others have said, doing this in a way that cannot be abused is the tricky part. Doing it under ISPF will be just about impossible, and even if you did manage it, you will find you have removed access to all the things that make ISPF a pleasure to use. Disclaimer: It has been a while since I was anywhere near ACF2. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Calling unauthorized code from an authorized address space
On Sun, 25 Apr 2010 02:00:42 -0500 Chris Craddock crashlu...@gmail.com wrote: :On Sat, Apr 24, 2010 at 2:17 PM, Binyamin Dissen bdis...@dissensoftware.com : wrote: : : There is no way to dance around it or pretend : :otherwise. The only way you could avoid the exposure would be to : guarantee : :that no authorized code code could ever run within the address space : after : :you have allowed the unauthorized code to run. There is no way to : guarantee : :that in general and in any case, it would effectively eliminate the value : of : :that address space as a server for hosting this function. : Why this requirement? :It is fairly clear that it is a requirement for the OP's proposed :application - else why bother with the elaborate schemes to temporarily :remove authorization? He wants to run his authorized code and his client's :unauthorized exit code within the same address space, presumably without :restarting his server address space each time he gets a new client request. :And since that can't be done safely, there's no point. Why is there a requirement that no authorized code could ever run in the address space afterwards? : The only case that leaves open is a garden variety key 8 APF authorized : :address space. If you turn off JSCBAUTH before invoking the unauthorized : :code, then it is true that code would NOT be able to MODESET to a system : key : :or get into supervisor state while it is running, however that isn't the : :only exposure. While they are running, they can easily diddle with the : data : :belonging to the other tasks providing the privileged application : :functionality in that space. Most of the system owned data areas will be : key : :0, 1 or 5 (and thus whey would be safe) but most of the areas owned by : the : :worker tasks will be in key 8. All of those areas would be susceptible to : :modification by your unauthorized code when it runs. If such a : modification : :occurred and ANY privileged code continued to run, their data would : :potentially be invalid and that is an integrity violation in and of : itself. : :Beyond that, a little creativity would get your unauthorized code back in : :control in a privileged condition - thus violating integrity. : Why must the authorized work areas be in key 8? :It isn't that they MUST be. Merely that the (initially APF-authorized) :application running within the address space WILL get key 8 storage for :every task or step-owned low private subpool allocation UNLESS it goes out :of its way to run in a system key and use only key-selectable subpools (kind :of an odd exercise given they chose not to have a system key assigned via :PPT, but I'll play along). I don't know that it is possible to prevent (logical) APF when running in a system key. : However, even if it did attempt to avoid using :task-key storage there would still potentially be an unknowable number of :task or step owned data areas laying around in key 8. That's the deal :breaker. If you let unauthorized code run within that same address space, :you cannot guarantee that the unauthorized code won't be able inspect or :modify the authorized application's data. In fact, it is guaranteed that the :unauthorized code could do exactly that, which is by definition an integrity :exposure just on its own merit. I don't understand the insistence that the authorized program MUST use key 8 storage. Yes, some will be assigned by the system - but it need not be used. Return via SVC 3 rather than RETURN using the passed save area (which is in key8 and may have been altered). Getmain all working storage in 229/230. Etc. :But even worse, if any of the APF application's tasks had already switched :to supervisor state and continued to run during or after when the :unauthorized code had been allowed to run, then there's a very high :likelihood that the unauthorized code could fool that supervisor state code :into violating integrity. You could do it. I could do it. Not if written properly. For example, SVCs run all the time - and unauthorized code runs both before and after the SVCs do their stuff. : There just isn't :any safe way to avoid that in general. There are too many moving parts in a :typical address space and not all of those parts (e.g. home grown exits :and/or ISV code) are going to be in on the secret of what's supposed to be :going on. What would be your case? If the exits can be fooled by this, they can be fooled by other things. : Disagree if you like but you would be flying in the face of :literally decades of integrity studies. While we're at it, let's not forget :that (again, unless the authorized application goes out of its way) the :unauthorized code is going to get control with the security identity of the :server where it is running (usually some sort of production ID) Of course, :that can be handled too, but the number of things that have to
Re: Multiple logon SMCS possibility
Dr. Alan Scherr told me over dinner years ago that on the final night of testing TSO before it's first release, they had taken a dinner break at 2am, and when he came back, he logged on and could enter commands, but there was no reply to his terminal, until, many minutes later, a co-worker across the room noticed that there were a bunch of replies to his commands on a different terminal. Alan then realized he had previously been logged on at that terminal, and after dinner had logged on at a different terminal, and there was no protection nor design for multiple logons, so at 3am he added the exclusive enqueure for userid in SYS1.UADS to prevent multiple logons, and TSO shipped at 7am on schedule to PID. As an aside, he reminded me that when the initial TSO performance did not match his model, his team modified the product to match the model. He then went on to develop VS2/MVS, immortalized in John Chapman's 1976 SHARE button http://www.mxg.com/thebuttonman/resultPOP.asp?d1=buttond2=167 Barry Merrill Herbert W. Barry Merrill, PhD President-Programmer Merrill Consultants MXG Software 10717 Cromwell Drive Dallas TX 75229 214 351 1966 tel 214 350 3695 fax www.mxg.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SMP/E RECEIVE ORDER outage
Looks like IBM's RECEIVE ORDER system is not working this weekend. I've been running RECEIVE ORDER jobs since 4/24 and all I get back is GIM69147S SMP/E WAITED 120 MINUTES BUT ORDER order IS NOT READY FOR DOWNLOAD. Further, RECEIVE ORDER(PENDING order) continue to fail after 120 minutes, more than 24 hours after placing the original order. I've opened a ticket - no response thus far. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 45 years of Mainframe
Shmuel Metz (Seymour J.) wrote: In m38w8m5ki2@garlic.com, on 04/17/2010 at 08:30 AM, Anne Lynn Wheeler l...@garlic.com said: I didn't remember block-mux being on 360 Consider the model number of the fixed-head disk. The 2 says that it's a S/360 device. -snip I suspect that 2305 was an outgrowth of the 2302, not necessarily a new device. The 2305 was available with selector channel interfaces before the blk-mux interfaces. At NCSS we were told that it took a complete selector subchannel, with eight exposures, to function properly so we configured them (16 devices) to run off 2860 Selector channels hanging off a 370/168 system. We did some strange things with those devices, using multiple exposures to access individual blocks on the track, etc. via software. A gentleman named Grant Tegtmeier wrote the CP67/CMS suppport for the device, complete with our strange usage, over the course of two weekends, while subsisting entirely on coffee and Chesterfield Kings. The man was best characterized as hours of boring nothingness, punctuated by moments of sheer absolute genious. I knew him in college, at MTU. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Calling unauthorized code from an authorized address space
On Sun, Apr 25, 2010 at 2:56 AM, Binyamin Dissen bdis...@dissensoftware.com wrote: Why is there a requirement that no authorized code could ever run in the address space afterwards? Because the unauthorized code could have modified storage and/or code belonging to the authorized code. Non-reentrant code (if any) will be loaded in job step key (8) and any data areas that are not specifically requested in another key will also be in key 8. Once those have been exposed to unauthorized code there's no going back. I don't know that it is possible to prevent (logical) APF when running in a system key. It isn't possible. In fact, being in a system key is considered to be privileged, even if you're running in problem state and with JSCBAUTH off. You can MODESET to sup stat in that condition. I don't understand the insistence that the authorized program MUST use key 8 storage. I'm not insisting that it must use key 8 I am merely observing that that is the default and you can't assume that all of the code running in that address space will be clued in on what you're up to. If you're writing the mainline application code you can certainly run in a system key for everything you do, but running in a key that is different than the job step key requires exception vigilance in the choice of storage keys and subpools and EVEN WITH that level of vigilance, there are a lot of things that just don't work out. For example, any externally called code (e.g. access methods, home grown exits, ISV code... etc etc) that mindlessly assumes that it is running in a completely unprivileged environment will potentially fail in a variety of ways. You can't predict what assumptions that code may make that would be ok in a true APF environment and in a non-APF environment, but not both at the same time. Yes, some will be assigned by the system - but it need not be used. Return via SVC 3 rather than RETURN using the passed save area (which is in key8 and may have been altered). Getmain all working storage in 229/230. Etc. Once again true in the abstract, but you can't assume everyone else is in on the secret. If you're mixing auth/sup code and unauth code in the same address space you're begging for trouble. :But even worse, if any of the APF application's tasks had already switched :to supervisor state and continued to run during or after when the :unauthorized code had been allowed to run, then there's a very high :likelihood that the unauthorized code could fool that supervisor state code :into violating integrity. You could do it. I could do it. Not if written properly. For example, SVCs run all the time - and unauthorized code runs both before and after the SVCs do their stuff. Sorry you're missing the point entirely. There is a huge difference between an SVC that is being called out of mainline task code maintaining integrity over the narrow function that it is performing and having the mainline task code maintain integrity over whatever it does during the life of the application. The SVC (or PC) is encapsulated from the rest of the logic and it follows the rules to the letter. It receives control in sup state and key zero from the OS or the hardware and it remains that way throughout. Inputs are checked and moved to fetch protected key zero storage, results are moved back to the caller's storage using the caller's PSW key (not zero) etc. It is a closed and bounded environment. If it needs to do something non-privileged, it will SYNCH to a new RB that runs that work and the system returns control to the SVC/PC in the same state it left. So if the SVC/PC is done right, the unauthorized code can't touch anything that its caller doesn't allow it to. In contrast to that, the code that runs from initial startup through mainline operation in an arbitrary task is not closed or bounded. With exceptional diligence you might make it so, but even then you would likely be undone by assumptions made by code that you did not write that you ended up calling, e.g. library routines, or by other system services, exits, ISV code etc. etc. that you don't control and can't predict what it is going to do. : There just isn't :any safe way to avoid that in general. There are too many moving parts in a :typical address space and not all of those parts (e.g. home grown exits :and/or ISV code) are going to be in on the secret of what's supposed to be :going on. What would be your case? If the exits can be fooled by this, they can be fooled by other things. How many times does the question come up here on ibm-main about choice of subpools for exits, or whether exit code has to be reentrant? There are a huge variety of ways that authorized code can be spoofed if it makes assumptions about the environment that are invalid because somebody is trying to do something fundamentally stupid like running privileged and unprivileged work alongside
Re: SMP/E RECEIVE ORDER outage
Quite a few weekends it is down, up to and including first thing Monday mornings. It used to be one of my Monday morning rituals, to download weekly maintenance. _ Dave Jousma Assistant Vice President, Mainframe Services david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB1G p 616.653.8429 f 616.653.8497 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Brian Peterson Sent: Sunday, April 25, 2010 12:17 PM To: IBM-MAIN@bama.ua.edu Subject: SMP/E RECEIVE ORDER outage Looks like IBM's RECEIVE ORDER system is not working this weekend. I've been running RECEIVE ORDER jobs since 4/24 and all I get back is GIM69147S SMP/E WAITED 120 MINUTES BUT ORDER order IS NOT READY FOR DOWNLOAD. Further, RECEIVE ORDER(PENDING order) continue to fail after 120 minutes, more than 24 hours after placing the original order. I've opened a ticket - no response thus far. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Calling unauthorized code from an authorized address space
On Sun, 25 Apr 2010 14:38:14 -0500 Chris Craddock crashlu...@gmail.com wrote: :On Sun, Apr 25, 2010 at 2:56 AM, Binyamin Dissen bdis...@dissensoftware.com : wrote: : Why is there a requirement that no authorized code could ever run in the : address space afterwards? :Because the unauthorized code could have modified storage and/or code :belonging to the authorized code. Non-reentrant code (if any) will be loaded :in job step key (8) and any data areas that are not specifically requested :in another key will also be in key 8. Once those have been exposed to :unauthorized code there's no going back. Only if the authorized section is badly written, i.e., not written for this case. That is not to say that an APF program, in general, should be aware of this - but if it is expected to run in this environment it must make sure all programs and data are in a system key. : I don't know that it is possible to prevent (logical) APF when running in a : system key. :It isn't possible. In fact, being in a system key is considered to be :privileged, even if you're running in problem state and with JSCBAUTH off. :You can MODESET to sup stat in that condition. Thus that is not an option. : I don't understand the insistence that the authorized program MUST use key : 8 : storage. :I'm not insisting that it must use key 8 I am merely observing that that :is the default and you can't assume that all of the code running in that :address space will be clued in on what you're up to. If you're writing the :mainline application code you can certainly run in a system key for :everything you do, but running in a key that is different than the job step :key requires exception vigilance in the choice of storage keys and subpools :and EVEN WITH that level of vigilance, there are a lot of things that just :don't work out. For example, any externally called code (e.g. access :methods, home grown exits, ISV code... etc etc) that mindlessly assumes that :it is running in a completely unprivileged environment will potentially fail :in a variety of ways. You can't predict what assumptions that code may make :that would be ok in a true APF environment and in a non-APF environment, but :not both at the same time. I am curious about this exit or ISV code (that gets control authorized) will use a key8 storage area. That is an exposure by itself. : Yes, some will be assigned by the system - but it need not be used. : Return via SVC 3 rather than RETURN using the passed save area (which is in : key8 and may have been altered). Getmain all working storage in 229/230. : Etc. :Once again true in the abstract, but you can't assume everyone else is in on :the secret. If you're mixing auth/sup code and unauth code in the same :address space you're begging for trouble. We are discussing a case where it is designed for that. I am not suggesting moving an arbitrary APF program into this environment. : :But even worse, if any of the APF application's tasks had already : switched : :to supervisor state and continued to run during or after when the : :unauthorized code had been allowed to run, then there's a very high : :likelihood that the unauthorized code could fool that supervisor state : code : :into violating integrity. You could do it. I could do it. : Not if written properly. : For example, SVCs run all the time - and unauthorized code runs both before : and after the SVCs do their stuff. :Sorry you're missing the point entirely. There is a huge difference between :an SVC that is being called out of mainline task code maintaining integrity :over the narrow function that it is performing and having the mainline task :code maintain integrity over whatever it does during the life of the :application. The SVC (or PC) is encapsulated from the rest of the logic and :it follows the rules to the letter. It receives control in sup state and key :zero from the OS or the hardware and it remains that way throughout. Inputs :are checked and moved to fetch protected key zero storage, results are moved :back to the caller's storage using the caller's PSW key (not zero) etc. It :is a closed and bounded environment. If it needs to do something :non-privileged, it will SYNCH to a new RB that runs that work and the system :returns control to the SVC/PC in the same state it left. So if the SVC/PC is :done right, the unauthorized code can't touch anything that its caller :doesn't allow it to. There may be other tasks running concurrently, so it must make sure that all of its data and code are in system key. Just like this application. :In contrast to that, the code that runs from initial startup through :mainline operation in an arbitrary task is not closed or bounded. With :exceptional diligence you might make it so, but even then you would likely :be undone by assumptions made by code that you did not write that you ended :up calling, e.g. library routines, or by other system services, exits, ISV :code etc. etc. that you don't control and can't
Vinu's email has been hacked. Kindly ignore the message asking for money. Ashan DSouza
I was quite desperate to get the message across and hence included everyone in my contacts. Kindly ignore this mail if you didnt get a mail stating Vinu was in London and that she was robbed, and then asking for money. She is fine and in bed fast asleep. To all those who called thank you very much for taking the time. @sh. ps: i hope this doesnt get hacked tonight. :-( -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Vinu's email has been hacked. Kindly ingore the request for money. Ashan DSouza.
I was quite desperate to get the message across and hence included everyone in my contacts. Kindly ignore this mail if you didnt get a mail stating Vinu was in London and that she was robbed, and then asking for money. She is fine and in bed fast asleep. To all those who called thank you very much for taking the time. @sh. ps: i hope this doesnt get hacked tonight. :-( -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 25 reasons why hardware is still hot at IBM
To the point of TCO including administrative costs, it is interesting to look at a recent Novell case study around Miami-Dade County. I've provided some samples of the very interesting article which includes multiple aspects of TCO. http://www.novell.com/success/miami-dade-county.html The county's IBM mainframe had already proven itself a stable and cost-effective platform for many years. The IBM System z has a small footprint with a huge payback, said DiPrima. We have compute-intensive applications and billions of lines of code running on the System z. It performs very well, responding to spikes and heavy processing on the fly. With the IBM System z, there is no practical limit to what you can do. To support its growing needs, the county upgraded its two IBM System z990 machines to System z10, running five z/OS LPARS and two z/VM LPARS dedicated to SUSE® Linux Enterprise Server for System z. The price/performance of SUSE Linux Enterprise Server for System z is significantly lower than other UNIX platforms, said Anita Nolan, senior operating systems programmer, Strategic Technologies Support for Miami-Dade County. The IBM System z10 also consumes 30 percent less power over our previous System z mainframe, and orders of magnitude less than other platforms. Miami-Dade County now runs Cognos, HostOn-Demand, CCL and Tivoli applications on SUSE Linux Enterprise Server for System z. Having a Linux-based open enterprise brings greater agility to the IT department. The IBM/Novell solution also helps the county keep support costs low. SUSE Linux Enterprise Server for System z provides a very efficient platform, said DiPrima. We have two people supporting the entire z/VM and z/Linux infrastructure on a part-time basis, compared to more than a dozen required to maintain each of our AIX and Windows environments. Jon Nolting - System z IT Architect (zITA) zChampion IBM US West IMT based near Seattle (206) 587-2244 (Work) - T/L 277-244 (425) 281-5750 (Cell) (206) 587-2244 (Fax) (425) 222-7969 (Home) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: (slightly OT - Linux) Did IBM bet on the wrong OS?
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Bob goolsby Sent: Sunday, April 25, 2010 1:20 AM To: IBM-MAIN@bama.ua.edu Subject: Re: (slightly OT - Linux) Did IBM bet on the wrong OS? BSD would have been interesting, the environmental differences between Berkley and Armonk. That would have been something that I would have payed good money to watch. Matter of fact I'd still pay good money. From the IBM viewpoint, *BSD would be superior to Linux due to the BSD license allowing for OCO distribution. IBN, or at least the historic z systems area, loves OCO and seems to dislike releasing source. However, from my limited knowledge, the z/Linux effort was a skunk works project by a group in IBM Germany. I don't know why they chose Linux. There already was a Linux for 370 development going on by another group of non-IBM people. This project still has a web page at http://linas.org/linux/i370.html . -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
