Re: Getting to 64-bit systems *legitimately*...
I do not know if there's a version of Flex-ES that's had its 64-bit emulation recoded from x86 to x86-64. I would not be surprised if Hercules compiled for x86-64 would outperform Flex-ES built for x86 for the same 64-bit workload, but I am not in a position to do more than guess at that. For a PoC I was lucky enough to run a 64 bit version of FLEX-ES on 64 bit hardware running a 64 bit host OS but only a 31 bit bit IBM mainframe OS. Seb. -- 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
Re: Getting to 64-bit systems *legitimately*...
> OTOH I suspect Spanish is probably more useful in most of the world. Perhaps, but Welsh is far more cool! My wife and I spent a Christmas in Cardiff a few years back and fell in love with the place. We're planning another holiday next year to see more of the country. I actually bought a self study language kit recently as well so your timing is perfect! ;) -Sam -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Alan Cox Sent: Tuesday, September 19, 2006 7:56 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Getting to 64-bit systems *legitimately*... Ar Maw, 2006-09-19 am 17:35 -0400, ysgrifennodd Post, Mark K: > I might regret this, but I'm curious as to how one might pronounce _any_ > of that. This is getting off topic a little but for the curious: Well "Ar" is like you'd expect "Maw" is short for "Mawrth" and I guess "Maw" alone would be pronounced like Chairman Mao, not that people would do that anymore than English speakers generally say "Tue 4". Ysgrifennodd [same root as English 'scribe'] Y is usually silent in this case but if not its a "uh!" sound scree [like the piles of rock] ven [like a south african trying to say van] oth (but the buzzy 'th' in this and that not the hissy 'th' in think - so like the "oth" in bother not the "oth" in both) and if you'd like to know more http://www.bbc.co.uk/learnwelsh/.. OTOH I suspect Spanish is probably more useful in most of the world. Alan -- 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
Re: Getting to 64-bit systems *legitimately*...
On Wed, Sep 20, 2006 at 07:46:54AM +0800, John Summerfield wrote: > I don't really understand what Flex-ES is - I have some idea it's some > hardware-plus-software imitation mainframe. As I understand it, it's a software emulator. Fundamental Software does have parallel and ESCON channel hardware to attach real devices, and there's a dongle that's used to authorize execution of the program. > With Hercules, one can in principle choose an 8-way however-many-core > Opteron, or a big Power (or Sparc64/UltraSparc) or other selection from > top500.org. How then would performance compare with Flex-ES? On the same hardware, Flex-ES will outperform Hercules - that is, if it's compiled for the same target. That's because, while Hercules does no emulation in assembler (aside from SMP locking for correctness of execution, which must be done below the level of C), Flex-ES does a lot of its emulation in hand-tuned assembler. This, as Adam noted, was a deliberate design decision, made for portability reasons in the case of Hercules. I do not know if there's a version of Flex-ES that's had its 64-bit emulation recoded from x86 to x86-64. I would not be surprised if Hercules compiled for x86-64 would outperform Flex-ES built for x86 for the same 64-bit workload, but I am not in a position to do more than guess at that. A nice fast 8-way Opteron would probably outrun the average PartnerWorld Flex-ES box, but that's hardly an apples-to-apples comparison. :-) -- Jay Maynard, K5ZChttp://www.conmicro.cx http://jmaynard.livejournal.com http://www.tronguy.net http://www.hercules-390.org (Yes, that's me!) Buy Hercules stuff at http://www.cafepress.com/hercules-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
Re: Getting to 64-bit systems *legitimately*...
Adam Thornton wrote: Yeah, Hercules would let us get around that for the pure-Linux stuff (although for *that* we could also just cross-compile from Intel if we wanted). It doesn't help for the z/VM-integrated-with-Linux or for the Linux-under-z/VM cases. Hercules is also, as far as I know, slower on the same hardware than Flex-ES; one of its design goals has been portability, and it explicitly trades performance for portability. Point is, it's a nonstarter for a shop that wants to do Linux-on-z/VM and not Linux-in-an-LPAR. I don't really understand what Flex-ES is - I have some idea it's some hardware-plus-software imitation mainframe. With Hercules, one can in principle choose an 8-way however-many-core Opteron, or a big Power (or Sparc64/UltraSparc) or other selection from top500.org. How then would performance compare with Flex-ES? -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ Please do not reply off-list -- 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
Re: Getting to 64-bit systems *legitimately*...
Ar Maw, 2006-09-19 am 17:35 -0400, ysgrifennodd Post, Mark K: > I might regret this, but I'm curious as to how one might pronounce _any_ > of that. This is getting off topic a little but for the curious: Well "Ar" is like you'd expect "Maw" is short for "Mawrth" and I guess "Maw" alone would be pronounced like Chairman Mao, not that people would do that anymore than English speakers generally say "Tue 4". Ysgrifennodd [same root as English 'scribe'] Y is usually silent in this case but if not its a "uh!" sound scree [like the piles of rock] ven [like a south african trying to say van] oth (but the buzzy 'th' in this and that not the hissy 'th' in think - so like the "oth" in bother not the "oth" in both) and if you'd like to know more http://www.bbc.co.uk/learnwelsh/.. OTOH I suspect Spanish is probably more useful in most of the world. Alan -- 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
Re: Getting to 64-bit systems *legitimately*...
On Sep 19, 2006, at 2:35 PM, Post, Mark K wrote: I might regret this, but I'm curious as to how one might pronounce _any_ of that. As if you've just been forced to eat someone's leek. _Henry V_, Act 5, scene 1. Adam -- 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
Re: Getting to 64-bit systems *legitimately*...
I might regret this, but I'm curious as to how one might pronounce _any_ of that. Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Alan Cox Sent: Tuesday, September 19, 2006 5:44 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Getting to 64-bit systems *legitimately*... Ar Maw, 2006-09-19 am 16:20 -0400, ysgrifennodd David Boyes: -- 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
Re: YOU and Missing Installable Patches
I suspect it may have something to do with whether or not optional, document, etc., patches are eligible for automatic selection or not. Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Ifurung, [EMAIL PROTECTED] Sent: Tuesday, September 19, 2006 12:08 PM To: LINUX-390@VM.MARIST.EDU Subject: YOU and Missing Installable Patches We have a local YOU server and several vservers in a zVM, all running SUSE9. On some of our vservers when running Yast Online Update (YOU) pointing to our local YOU server, some candidate patches (e.g patch-10747) are missing in the list of installable patches. I know for a fact that the YOU server has the patch available. It is inconsistent; some of our similar vservers do have it listed when doing YOU. The net effect of this is SPident is now reporting "NOT uptodate". Maybe related to this problem is: in the "online_update" help, something is mentioned about patch "default selection algorithm". What exactly is this? Thanks for any help. Ismael -- 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
Re: Getting to 64-bit systems *legitimately*...
Ar Maw, 2006-09-19 am 16:20 -0400, ysgrifennodd David Boyes: > It's annoying, but understandable. At least the requirement has been > voiced and heard, and I can correct the error of the field weenies' ways > that the requirement has not been voiced. You can all buy one IBM share each and each go ask questions about it at the shareholders meeting. Alan ['s evil twin] ;)) -- 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
Re: PL/I and C cross compilers
Yes, it was intended to be a part of the GCC suite at some point in the future. At the time I compiled and tested it, the compiler was not yet to the point of generating any code. All it was doing was syntax checking. I doubt very much it would ever generate code that would be usable on z/VM, unless someone like Neale decided it was worth his time and effort. ;) Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Richard Pinion Sent: Tuesday, September 19, 2006 12:07 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: PL/I and C cross compilers Seems like I remember seeing some discussion on an Open Source PL/I? -- 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
Re: Getting to 64-bit systems *legitimately*...
On Sep 19, 2006, at 1:13 PM, Alan Altmark wrote: On Monday, 09/18/2006 at 04:48 AST, David Boyes <[EMAIL PROTECTED]> wrote: FWIW, VSE/ESA 2.7 will be withdrawn from service on 02/28/2007. The current z/VSE 3.1 is still 31-bit also, though. z/VSE 4.1 will be the first 64-bit version, no availability date on that yet. Given this, I'd like to pose again the question of why IBM has not approved the 64-bit version of FlexES for public sale. It's a business decision, the details of which are unlikely to be discussed outside the company and to which few outside of the Inner Circle are even privy. Sorry. I post this to say that we hear your question, but can only respond officially with "No Comment". That is a much, much better answer than "there is no demand." Adam -- 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
Re: Getting to 64-bit systems *legitimately*...
> > Given this, I'd like to pose again the question of why IBM has not > > approved the 64-bit version of FlexES for public sale. > It's a business decision, the details of which are unlikely to be > discussed outside the company and to which few outside of the Inner Circle > are even privy. Sorry. > I post this to say that we hear your question, but can only respond > officially with "No Comment". Thanks, Alan. It's annoying, but understandable. At least the requirement has been voiced and heard, and I can correct the error of the field weenies' ways that the requirement has not been voiced. -- 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
Re: Getting to 64-bit systems *legitimately*...
On Monday, 09/18/2006 at 04:48 AST, David Boyes <[EMAIL PROTECTED]> wrote: > Could someone please find out what the hold-up is? We've been told one > rumor is that IBM thinks nobody wants it -- I'd like to shout "call!" on > that assertion. Oh, and that rumor is false. I suppose if we plugged our ears, closed our eyes, and went "la-la-la-la-I-can't-hear you", then you might be onto something, but we haven't done that. I know this since I have personally conveyed the message (WAVV requirements, remember?) to the TPTB in HardwareLand. Alan Altmark z/VM Development IBM Endicott -- 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
Re: Getting to 64-bit systems *legitimately*...
On Monday, 09/18/2006 at 04:48 AST, David Boyes <[EMAIL PROTECTED]> wrote: > > FWIW, VSE/ESA 2.7 will be withdrawn from service on 02/28/2007. The > > current z/VSE 3.1 is still 31-bit also, though. z/VSE 4.1 will be the > > first 64-bit version, no availability date on that yet. > > Given this, I'd like to pose again the question of why IBM has not > approved the 64-bit version of FlexES for public sale. It's a business decision, the details of which are unlikely to be discussed outside the company and to which few outside of the Inner Circle are even privy. Sorry. I post this to say that we hear your question, but can only respond officially with "No Comment". Alan Altmark z/VM Development IBM Endicott -- 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
Re: Getting to 64-bit systems *legitimately*...
On Sep 19, 2006, at 11:35 AM, David Boyes wrote: Hercules is also, as far as I know, slower on the same hardware than Flex-ES; one of its design goals has been portability, and it explicitly trades performance for portability. Point is, it's a nonstarter for a shop that wants to do Linux-on-z/VM and not Linux-in-an-LPAR. It's also a violation of the license agreements for z/VM et al. That's why it's a "nonstarter", not a "slow starter." The sentence above those, that you cut, says that it doesn't help for z/VM work at all. The reason it doesn't is that you are going to find it very difficult to legally run z/VM on Hercules (and if you do get it running, you have no reason to believe that it's running *correctly*). Adam -- 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
Re: Getting to 64-bit systems *legitimately*...
Thanks. I appreciate the clarification. Peter -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Adam Thornton Sent: September 19, 2006 14:11 To: LINUX-390@VM.MARIST.EDU Subject: Re: Getting to 64-bit systems *legitimately*... On Sep 19, 2006, at 6:30 AM, Peter Webb, Toronto Transit Commission wrote: > Well, we just had a techy from our local IBM reseller in here > yesterday, > and he said they could sell us a FLEX based system that would run z/VM > 5.2. I'm going to keep my eyes open for a flock of pigs flying past > until they put that one on paper, though. You misunderstand. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon, this information by persons or entities other than the intended recipient or delegate is strictly prohibited. If you received this in error, please contact the sender and delete the material from any computer. The integrity and security of this message cannot by guaranteed on the Internet. The Sender accepts no liability for the content of this e-mail, or for the consequences of any actions taken on basis of the information provided. The recipient should check this e-mail and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this e-mail. This disclaimer is the property of the TTC and must not be altered or circumvented in any manner. -- 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
Re: Getting to 64-bit systems *legitimately*...
> 64-bit guests run on Flex-ES. If you can *get* the 64-bit zSeries enablement code. That's the first (and more critical) problem. > Just much more slowly than they need > to. Separate (but related) problem. > My understanding is that IBM refuses to allow Flex-ES to be licensed > on 64-bit host OSes, at least for PWD members, which we are. No, it's a two part issue -- see above. Once the 64-bit zArch enablement code is accessible, then it's a question of exploitation of 64-bit host capabilities. A 2-way Opteron box could deliver O(150) zSeries MIPS if it was allowed to operate in native 64-bit mode. The Flex code that is accessible to the public is still a) 32-bit only, and b) doesn't enable zArchitecture mode for non-PWD members. > Hercules is also, as far as I know, > slower on the same hardware than Flex-ES; one of its design goals has > been portability, and it explicitly trades performance for > portability. Point is, it's a nonstarter for a shop that wants to do > Linux-on-z/VM and not Linux-in-an-LPAR. It's also a violation of the license agreements for z/VM et al. > We have neither money, space, nor power for a real z9, even a small > one, and its associated disks. This is the largest issue: environmentals. 400 sq ft for z9+disk plus at least 3 dedicated 30A (or more) circuits, versus 4RU for the dual Opteron box AND 3.5TB of disk, both of which run on 110VAC. Add another 4RU for a 3480 autoloader, also 110VAC. That one's easy. -- 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
Re: Getting to 64-bit systems *legitimately*...
Adam Thornton <[EMAIL PROTECTED]> wrote > Yeah, Hercules would let us get around that for the pure-Linux stuff > (although for *that* we could also just cross-compile from Intel if > we wanted). It doesn't help for the z/VM-integrated-with-Linux or > for the Linux-under-z/VM cases. <...snip> There are other cross-compiling options available that can help address the VM stuff... see http://www.dignus.com That is, you spoke of "spiky" CPU usage, due to compiling... if that's the case, we can help. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- 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
Re: Getting to 64-bit systems *legitimately*...
On Sep 19, 2006, at 6:30 AM, Peter Webb, Toronto Transit Commission wrote: Well, we just had a techy from our local IBM reseller in here yesterday, and he said they could sell us a FLEX based system that would run z/VM 5.2. I'm going to keep my eyes open for a flock of pigs flying past until they put that one on paper, though. You misunderstand. 64-bit guests run on Flex-ES. Just much more slowly than they need to. We're running 5.1 right now with plans to install 5.2 soon, and it runs it accurately enough. It works, just not very fast when it's doing 64-bit ops, because it's having to simulate 64-bit operations on 32-bit hardware (or, more accurately, a 32-bit OS, even if the *hardware* supports 64-bit operations), which introduces many, many unnecessary host operations. When they quote you the MIPS for the Flex machine, be *sure* to ask whether they're talking about a mostly-31-bit workload or a mostly-64-bit workload. My understanding is that IBM refuses to allow Flex-ES to be licensed on 64-bit host OSes, at least for PWD members, which we are. This may have something to do with levels of Flex-ES (only post-version-6, I think, can exploit a 64-bit host?) and with PWD entitlement as well (so it may be that you *can* go full 64-bit if you are running a production system on your Flex box, but we *aren't*, so I really don't know). Anyway, the current situation means that every time you use a 64-bit instruction, the host CPU has to go and assert a lock around a bunch of 32-bit operations that together implement a 64-bit operation, versus just, you know, running a 64-bit instruction. This makes performance of 64-bit OSes on Flex-ES much worse than it *could* be on the very same hardware. Remember the performance hell of 16-to-32- bit "thunking" back in the 90s on Windows 3.x with win32s (and from Win95 to 16-bit DLLS)? Same basic idea. This is indeed a problem even for development shops: we may not need 6000 MIPS to run our databases, but we *do* indeed do a lot of compilation and, especially under Linux, a lot of encryption computation, because nearly everything protocol-related we're working with uses SSL. We want to be doing this for 64-bit architectures (since SuSE and Red Hat have already dropped 31-bit, and there is obviously confusion within IBM about the status of ongoing 31-bit support (see the Jim Elliot/Boebligen back-and-forth)), and it's really annoying to be kneecapping our zSeries system because IBM won't let us license an already-extant solution that lets us best use the hardware we have. We don't have large, steady, ongoing CPU requirements: we have spiky CPU requirements that do, occasionally, go quite high. Yeah, Hercules would let us get around that for the pure-Linux stuff (although for *that* we could also just cross-compile from Intel if we wanted). It doesn't help for the z/VM-integrated-with-Linux or for the Linux-under-z/VM cases. Hercules is also, as far as I know, slower on the same hardware than Flex-ES; one of its design goals has been portability, and it explicitly trades performance for portability. Point is, it's a nonstarter for a shop that wants to do Linux-on-z/VM and not Linux-in-an-LPAR. We have neither money, space, nor power for a real z9, even a small one, and its associated disks. Flex-ES is clearly the solution that's the right size for what *we're* doing. IBM has stonewalled, as David said, by saying there's "no demand." This is plainly inaccurate: we're demanding it, and I'd be quite surprised if we're the only ones. It may well be that IBM has other reasons for disallowing it. In that case, I'd like them to come clean about what those reasons actually *are* rather than using the flatly-wrong explanation of "no demand." Adam -- 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
Re: PL/I and C cross compilers
Seems like I remember seeing some discussion on an Open Source PL/I? >>> [EMAIL PROTECTED] 9/19/2006 12:09 PM >>> Hi Ken, For the 'C' part, you can use Systems/C in IBM compatibility mode to use with your existing IBM runtime. Also - Amadeus is already a customer; give us a call - I think we can handle that part for you. PL/I is another story... - Dave Rivers - > > Hi, > > We have various 'C', and PL/I programs that run on our VM systems. Are > there any cross compilers that would compile 'C' and PL/I programs,and > allow the object to run on VM? > > Thanks, > > Ken Vance > Amadeus > -- -- 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
YOU and Missing Installable Patches
We have a local YOU server and several vservers in a zVM, all running SUSE9. On some of our vservers when running Yast Online Update (YOU) pointing to our local YOU server, some candidate patches (e.g patch-10747) are missing in the list of installable patches. I know for a fact that the YOU server has the patch available. It is inconsistent; some of our similar vservers do have it listed when doing YOU. The net effect of this is SPident is now reporting "NOT uptodate". Maybe related to this problem is: in the "online_update" help, something is mentioned about patch "default selection algorithm". What exactly is this? Thanks for any help. Ismael -- 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
Re: PL/I and C cross compilers
Hi Ken, For the 'C' part, you can use Systems/C in IBM compatibility mode to use with your existing IBM runtime. Also - Amadeus is already a customer; give us a call - I think we can handle that part for you. PL/I is another story... - Dave Rivers - > > Hi, > > We have various 'C', and PL/I programs that run on our VM systems. Are > there any cross compilers that would compile 'C' and PL/I programs,and > allow the object to run on VM? > > Thanks, > > Ken Vance > Amadeus > -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- 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
PL/I and C cross compilers
Hi, We have various 'C', and PL/I programs that run on our VM systems. Are there any cross compilers that would compile 'C' and PL/I programs,and allow the object to run on VM? Thanks, Ken Vance Amadeus -- 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
Re: SLES9 scsi multipath initrd-linuxrc question
Hannes, Does multipath= and the scanning issue apply to zSeries using the zfcp driver? If the scanning is initiated in a level sitting on top of (I'm assuming)or higher than zfcp driver and the zfcp driver doesn't support scanning isn't it in effect a sort of null-op that zfcp ignores because it can't do it? " Configuring the zfcp device driver- The zfcp device driver currently does not perform any port discovery or LUN scanning to determine the ports and LUNs in the SAN. Every port and LUN in the SAN that should be accessed via zfcp must be configured explicitly. Once a port and a LUN are properly configured and the adapter is set online a new SCSI device is registered at the SCSI stack." Tia This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Hannes Reinecke Sent: Tuesday, September 19, 2006 10:20 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: SLES9 scsi multipath initrd-linuxrc question On Tue, Sep 19, 2006 at 08:23:54AM -0400, Romanowski, John (OFT) wrote: > Hannes, > I'm confused that SLES 9 added a parameter, multipath=, to switch "off > multipathing in the initrd, > ie for the root fs" > > but Novell says specifically for SLES 9 that "Currently, DM MPIO is not > available for either the rooti > or the boot partition, as the boot loader does not know how to handle MPIO." > Argl. No, it's me getting confused. The multipath parameter in SLES9 is actually an evil hack which switches of the partition detection from the block layer. It's never meant to be a properly documented boot parameter, more something of a performance tweak. Main reason here is that _reading_ from a disk (as the partition scanning code does) might trigger failover on certain arrays, which again might take some time for the failover to occur. And as the devices are scanned sequentially, you might end up failing the path back and forth several times, each time encountering the time penalty for switching paths. We had someone where this partition table scanning alone took several hours to complete. The statement about SLES9 and multipathing on root not supported still stands. Cheers, Hannes -- Dr. Hannes Reinecke [EMAIL PROTECTED] SuSE Linux Products GmbHS390 & zSeries Maxfeldstra e 5 +49 911 74053 688 90409 N rnberg http://www.suse.de -- 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
Re: SLES9 scsi multipath initrd-linuxrc question
On Tue, Sep 19, 2006 at 08:23:54AM -0400, Romanowski, John (OFT) wrote: > Hannes, > I'm confused that SLES 9 added a parameter, multipath=, to switch "off > multipathing in the initrd, > ie for the root fs" > > but Novell says specifically for SLES 9 that "Currently, DM MPIO is not > available for either the rooti > or the boot partition, as the boot loader does not know how to handle MPIO." > Argl. No, it's me getting confused. The multipath parameter in SLES9 is actually an evil hack which switches of the partition detection from the block layer. It's never meant to be a properly documented boot parameter, more something of a performance tweak. Main reason here is that _reading_ from a disk (as the partition scanning code does) might trigger failover on certain arrays, which again might take some time for the failover to occur. And as the devices are scanned sequentially, you might end up failing the path back and forth several times, each time encountering the time penalty for switching paths. We had someone where this partition table scanning alone took several hours to complete. The statement about SLES9 and multipathing on root not supported still stands. Cheers, Hannes -- Dr. Hannes Reinecke [EMAIL PROTECTED] SuSE Linux Products GmbHS390 & zSeries Maxfeldstra�e 5 +49 911 74053 688 90409 N�rnberg http://www.suse.de -- 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
Re: RHEL vs SUSE question again
> Currently we're using RHEL4 on z and Fedora Core for desktops. We keep > running into a wall with Java and different products using different > versions of Java. Between the GNU Java compiler, IBM's Java for Eclipse > with MQ Series to Sun Java for AJAX. We're swimming in too many version > of Java to manage. > Does the need for multiple Java installations exist with all linux > distributions for zSeries (especially SUSE) ? It's not unique to zSeries. The same problem exists on just about every platform that employs Java. The majority of the issues are with testing and certification, and that Java isn't really always the same between releases, and particularly on different platforms. Coping with that in the application would require competent and defensive programmers, which cost more. Test and QA people are less expensive, and defining the support configuration to be the one with the Java interpreter that you have at this moment and only have to test once is cheaper still. You get the picture from there. > Has anyone had really good experience with proprietary software on > Linux systems? If so, did the distribution matter any or just the > comfort and experience level of the staff make the process easier? It has a lot more to do with the application vendor than the Linux distributor. Some app vendors get it. Most don't. IBM and Sun are in the second category most of the time (although in fairness to IBM, they are getting better about it). The distribution really didn't matter much at all -- other than if you know one better than the other, you've tripped over all the stupidity up front and can avoid shooting yourself in the foot again. -- 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
Re: Getting to 64-bit systems *legitimately*...
Well, we just had a techy from our local IBM reseller in here yesterday, and he said they could sell us a FLEX based system that would run z/VM 5.2. I'm going to keep my eyes open for a flock of pigs flying past until they put that one on paper, though. Peter -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: September 18, 2006 17:23 To: LINUX-390@VM.MARIST.EDU Subject: Re: Getting to 64-bit systems *legitimately*... > -Original Message- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On > Behalf Of David Boyes > Sent: Monday, September 18, 2006 3:48 PM > To: LINUX-390@VM.MARIST.EDU > Subject: Getting to 64-bit systems *legitimately*... > > > > FWIW, VSE/ESA 2.7 will be withdrawn from service on 02/28/2007. The > > current z/VSE 3.1 is still 31-bit also, though. z/VSE 4.1 > will be the > > first 64-bit version, no availability date on that yet. > > Given this, I'd like to pose again the question of why IBM > has not approved the 64-bit version of FlexES for public > sale. Yes, you can sell me a z9 with a sub-100 MIPS capacity. > You *can't* sell me one that comes self-contained with disk > at a price-point that is affordable for small shops, nor can > you sell me one that doesn't take up my entire available > machine room space. > > Could someone please find out what the hold-up is? We've been > told one rumor is that IBM thinks nobody wants it -- I'd like > to shout "call!" on that assertion. > > > David Boyes > Sine Nomine Associates The "no one wants it" translates to "no one in z9BC marketting wants it because it might undercut sales." Cynical? Really? Me? Nooo. -- 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 The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon, this information by persons or entities other than the intended recipient or delegate is strictly prohibited. If you received this in error, please contact the sender and delete the material from any computer. The integrity and security of this message cannot by guaranteed on the Internet. The Sender accepts no liability for the content of this e-mail, or for the consequences of any actions taken on basis of the information provided. The recipient should check this e-mail and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this e-mail. This disclaimer is the property of the TTC and must not be altered or circumvented in any manner. -- 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
Re: SLES9 scsi multipath initrd-linuxrc question
Hannes, I'm confused that SLES 9 added a parameter, multipath=, to switch "off multipathing in the initrd, ie for the root fs" but Novell says specifically for SLES 9 that "Currently, DM MPIO is not available for either the root or the boot partition, as the boot loader does not know how to handle MPIO." (see http://support.novell.com/techcenter/sdb/en/2005/04/sles_multipathing.html ) Puzzles me since my experience is coding the multipath= kernel parm on SLES 9 zSeries doesn't suppress, enable, or affect multipathing with multipath-tools. Can you be more detailed about the intent of the multipath= parm? Or point me to some documentation that explains use of this new feature? danke This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Hannes Reinecke Sent: Tuesday, September 19, 2006 2:37 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: SLES9 scsi multipath initrd-linuxrc question Richard Troth wrote: > I'm finding that multipath support in Linux sits above the SCSI layer, and > therefore also above the zFCP layer. Thought I caught a hint of zSeries > specific configuration in the use of the "multipath=" parm. But > experience is showing it to NOT be platform specific. > Well; no. The multipath= parameter is for switching off multipathing in the initrd, ie for the root fs. And as you already pointed out it's platform agnostic. Why did you think it's somewhat platform dependent? Cheers, Hannes -- Dr. Hannes Reinecke [EMAIL PROTECTED] SuSE Linux Products GmbHS390 & zSeries Maxfeldstraße 5 +49 911 74053 688 90409 Nürnberg http://www.suse.de -- 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
Re: RHEL vs SUSE question again
On 9/19/06, Evans, Kevin R <[EMAIL PROTECTED]> wrote: Does the need for multiple Java installations exist with all linux distributions for zSeries (especially SUSE) ? I fear you're correct. I also found middleware come with their own version of Java shipped along with the product. And it may not be just Java but also other dependencies on some components. The good news with Linux on z/VM that there is not much extra cost in running different applications in different virtual servers. That way you can meet the requirements of each application without installing all kind of software that application does not need. Has anyone had really good experience with proprietary software on Linux systems? If so, did the distribution matter any or just the comfort and experience level of the staff make the process easier? You will find many vendors certify (or support) their product only on specific versions of distributions, and often specific kernel levels provided by the distributor. If you pay big money for support, that often is a stronger point than the personal preference of system administrators. My experience is that for most people with Linux background coming to Linux on z/VM, the difference between desktop and server (or even discrete server and virtual server) is way bigger than between SLES and RHEL. Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/ -- 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
RHEL vs SUSE question again
One of the developers who is closer to our XML project here than me (which will run under zLinux and eventually zVM) has been having some issues with RHEL and has asked me to bounce a couple of questions of you more knowledgeable folks. Here goes: Currently we're using RHEL4 on z and Fedora Core for desktops. We keep running into a wall with Java and different products using different versions of Java. Between the GNU Java compiler, IBM's Java for Eclipse with MQ Series to Sun Java for AJAX. We're swimming in too many version of Java to manage. Does the need for multiple Java installations exist with all linux distributions for zSeries (especially SUSE) ? Which leads to the 2nd question: Has anyone had really good experience with proprietary software on Linux systems? If so, did the distribution matter any or just the comfort and experience level of the staff make the process easier? Thanks Kevin Kevin R Evans Software Engineer Staff IV Lockheed Martin Information Technology Federal Bureau of Investigation 1000 Custer Hollow Road Clarksburg WV, 26306 304-625-5870 -- 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
Re: SLES9 out of support?
> Jim Elliott <[EMAIL PROTECTED]> wrote: > > IBM no longer provides updates for Linux for 31-bit (for the 2.6.16 and > > later kernels). On Tue, 19 Sep 2006, Carsten Otte wrote: > This statement clearly is not true. In fact, we do. I really want to thank the Linux team at IBM for this: THANKS! It is important to the health of Linux that they continue to support 31-bit Linux. Obviously there are some IBMers who know this. -- R; -- 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
Re: SLES9 out of support?
Jim Elliott <[EMAIL PROTECTED]> wrote: > IBM no longer provides updates for Linux for 31-bit (for the 2.6.16 and later kernels). Carsten Otte wrote: This statement clearly is not true. In fact, we do. Here is an example to prove my statement. Note the diff from Martin against head31.S which is the kernel startup code used for 31-bit kernel only. This code is heading for integration into 2.6.19+, and directed yield is a feature new in future Linux distributions. http://marc.theaimsgroup.com/?l=linux-arch&m=115858205621775&w=2 cheers, Carsten -- Carsten Otte has stopped smoking: Ich habe in 3 Monate, 3 Wochen und 4 Tage schon 564,91 Euro gespart anstatt 2.353,80 Zigaretten zu kaufen. -- 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
