Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
If Pat's reply is jumping onto a cold thread, being only three days late, how does this one rate? I've been cleaning out my reader - sorry inbox - and I guess I kept this one because of the insight Pat offered on the comparison - and effectiveness - of TCP and SNA timers. Reading through, I've a couple of extra comments: I had a look at checking back to the original thread but it's rather large and there's a strong possibility the characteristics of Ted's famous application when being transported over IP will not be revealed. Ted said his application worked reliably under SNA but unreliably under TCP/IP. This may just be an illustration of why TCP/IP is a bad way to describe the suite of functions/protocols which make up the TCP/IP suite - and it looks like I've manoeuvred myself into being a word policeman again - how tragic! It may be that it has simply been assumed that Ted's application uses the TCP protocol and hence should benefit from TCP reliability when it may be that the UDP protocol is used and the writer of the application - converted from SNA - hasn't written sufficient reliability into it. It may have been assumed that the application uses TCP because Ted said in all innocence that the application uses TCP/IP. However he probably intended to refer to, using the today's product names, the Communications Server IP component rather than the Communications Server SNA component. Thus he isn't necessarily claiming the application is using the TCP protocol. It was Pat's but the app may not be willing or able to wait that triggered the idea that UDP may be being used. - I thought Pat, confused by jumping between TCP and SNA, had incorrectly used the word route rather than link when he said that, in SNA, data gets through or the route is declared dead. In SNA data gets through or the *link* is declared dead but, in addition, any route using the link - being connection-oriented they know who they are - will also be declared dead[1] - so Pat wasn't necessarily confused - and I hope that applies also to anyone reading this. g [1] Unless we are dealing with APPN/HPR, of course, where an alternative path can be found, if one exists, and the logical connection (link) over a number of nodes and real links remains active. - One answer to the question What would an SNA name server do? is the ANAME application from the APPC Application Suite the manuals which greet us first whenever we select the Communications Server bookshelf - and we skip right over them. Chris Mason - Original Message - From: Patrick O'Keefe [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Thursday, 15 June, 2006 8:47 PM Subject: Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?) On Mon, 12 Jun 2006 00:00:00 GMT, Ted MacNEIL [EMAIL PROTECTED] wrote: TCP keeps track of it all, requesting a resend of dropped/lost/missing packets. NOT in this case! The packets are dropped! They are not re-sent and the app is blown off the air. It works under SNA; it bellies up under TCP/IP. Every time! Repeatable! ... I'm way behind on on IBM-Main so am probably jumping onto a cold thread, but want to add my belated 2 cents worth. Ted is probably right about the behavior of the application and is spot-on with Repeatable!, but is a bit off on his criticizm of TCP/IP. Yes, IP drops packets. But also, yes, TCP keeps track of it all and requests retransmissions. The reason this works much better in SNA (IM not so HO) is that the error detection and correction in SNA happens at a much lower level than in TCP/IP - at what would be the IP level - at the level where timers can match line characteristics - very short timers. There is guaranteed delivery at a very low level; data gets through or the route is declared dead. On the other hand, IP does not guarantee delivery. It is left up to the higher (TCP) level to detect need for retransmission. And since any 2 packets can flow across different routes with very different speeds, it has to have very long timers or risk requesting unneeded retransmissions. If the retransmission timers are longer than timers in the application (something completely unneeded in an SNA app), the app may choke even though data is on the way. In other words, TCP guarrentees delivery of data, but the app may not be willing or able to wait. One aspect of this is that behavior of an SNA network is MUCH more predictable than a TCP/IP behavior. Network management is self- contradictory in TCP/IP because behavior is too random. And in regard to the DNS issues in this thread, that's sort of a red herring. IP addressing is based on numeric addresses. SNA addressing is based on netid.resource names (with numeric addresses used within a domain, and to a lesser extent, between domains in SNI configurations). What would an SNA name server do? A bigger issue is that a public network like the internet does not map well
Re: Mainframe Linux Mythbusting
I don't have any success stories yet -- just war stories. We are trying a couple different things on VM and Linux at the moment, but we haven't gotten up to speed in either of them. (One of the projects -- an app from a third-party -- had some disk performance problems that we are trying to iron out; the other project is just now getting started.) The whole z/VM/Linux thing has a lot to recommend it, but there are a lot of potential cultural considerations in addition to the technical ones. One great part for me is that z/VM allows me to be responsive: What's that? You need another Linux box? OK, give me a couple of hours and you'll have it. One bad part is that sometimes I can look not so responsive: Well, yes, we could give that Linux guest 8 GB of memory, and I know you think you need it, but -- trust me on this -- you wouldn't like it. Another plus is that it allows me to try some new ideas, or it would if I could get just a little more research time. If we ever get our current projects up and going, I'll be sure to post the results here. Jon snip On another note... I tried to go back and look for any responses to my question about linux success stories or war stories. Only found the one from Alan at Supervalue (but he didn't mention anything about how on-time the project was or how smoothly it ran). I know there are many others success stories and others similar to my experience. I'm surprised there were not more responses from IBM-MAINers. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting
On Thu, 8 Jun 2006 01:36:06 +0900, Timothy Sipples [EMAIL PROTECTED] wrote: Mark Zelden writes: Without getting into too much detail.. there were two projects (POCs) going on. One was related to moving TSM off of z/OS to run on zLinux under z/VM and the other was moving TAMe from AIX (I think.. it could have been Wintel). Rule of thumb (oversimplification? :-)): moving something from z/OS onto mainframe Linux is not usually a good idea. Tivoli Storage Manager would probably be a particularly bad candidate, so your outcome would have been predicted. Do you happen to know what the thinking was on that? It's a very odd choice. Storage management is extremely highly evolved and very efficient on z/OS. (sorry for delay in responing... just got back from 2 weeks of vacation) The idea mostly came from IBM - probably when selling us the engines. :-) The #1 reason? Probably because it it was supposed to save $$$. Isn't TSM supposed to work better or at least be easier to manage on open systems? Maybe that is just a perception I've heard around here because the TSM admin(s) work mostly on *nix. Also, 90% of other TSM workloads are on AIX. One particular workload (TSM to backup AIX SAP servers) was on AIX but moved to the mainframe when we consolidated our mainframes out to LA. The SAP AIX servers moved along with the mainframe (because of how tightly coupled they were with the MF) but the AIX TSM servers remained in the Chicago area since they were still being used with all the other AIX servers that were staying. TSM was already in use on the MF for LPARs that already existed in the LA data center, so we just implemented it on an additional LPAR to backup SAP AIX. Oh, did I mention it was supposed to save $$$? On another note... I tried to go back and look for any responses to my question about linux success stories or war stories. Only found the one from Alan at Supervalue (but he didn't mention anything about how on-time the project was or how smoothly it ran). I know there are many others success stories and others similar to my experience. I'm surprised there were not more responses from IBM-MAINers. I did note that the 2 threads went far off topic from the subject line but what else is new? Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group mailto: [EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
Ted MacNEIL wrote: Yes, IP drops packets. But also, yes, TCP keeps track of it all and requests retransmissions. Not according to the traces. If TCP/IP is so robust, why has it NEVER happened in 7 years under SNA (how long we've had the TN3270 client we use), and it always happens under TCP/IP. We have MACROS (scripts) coded for call centres to screen scrape an old CICS application and answer customers' questions. They have never failed under SNA. The only change we make (and I know it's the only change because I am co-ordinating it and controlling it), is we make the TN3270 client talk to TCP/IP. Invoke the MACRO and BOOM!. Corrupted (incomplete) data sent to the host, the application session gets terminated and the user is blown to a blank sign-on screen. Doesn't even have the logo and sign-on crap we display when the PC first connects to the mainframe. Every time. Not intermittent. No re-transmission requests. No session. No data. IMHO it is *not* a proof that TCP/IP is bad and SNA is good. The only thing it proves is you have a problem with some macro when switched from SAN to TCP/IP. It can happen because of error in the script, emulator, emulator settings, even network configuration (i.e. some packets could be filtered). I'm far from claiming that TCP/IP is the best solution, however single case, especially not analyzed one is not a proof. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
Ted MacNEIL wrote: I obviously can't comment on traces I haven't seen. I can say that TCP provides guaranteed delivery ... if you (and your software) are willing to cope with some very ugly timings. We have no guaranteed delivery! Period! And, the only change was SNA to TCP/IP. If TCP/IP is so robust, why has it NEVER happened in 7 years under SNA (how long we've had the TN3270 client we use), and it always happens under TCP/IP. I don't understand that statement. If you've been using Tn3270 for 7 years you've been using TCP/IP. By definition, Tn3270 is 3270 over TCP/IP. Not being a network person, I may be tripping over terminology. It's been the same desktop client for 7 years. First, in my VERY unhumble opinion, anybody using screen scraping gets what he or she deserves. (BOOM!) That was as true under pure SNA as under TCP/IP. All well and good! It doesn't fly with the business or my mangement. If I could get away with that, we would be TCP/IP on the mainframe, tomorrow. And, we would have a whole lot of scrap 3745's and 3174's. (If you went for 7 years without screen reformatting you lived in a very static world, indeed. Never said that we did. We have people who re-do the MACROS when the screens change. (Just did it for Germany) That sounds like a problem with the Tn3270 client, or some kind of incompatability between the Tn3270 client and server, or some such. I can reproduce the problem manually (with 5 minutes of effort). It has to do with the lack of think time. Just pound a PFKey until the host barfs. It happens with: RUMBA ATTACHMATE Hummingbird, and at least three different web-clients: 2 in JAVA and on in ACTIVEx. I could imagine this is a problem with the PC OS (presumably Windows). Did you try to : change OS on PC, change OS on host (yes, there are errors in z/OS!) change *whole* network connectivity, i.e. connect PC directly to the subnetwork, where OSA is connected, change networking cards, drivers, switches, firewalls, routers, rules on those devices, etc. Next question: What was the result? Answer: No matter what client I used, if I typed 'too fast', my session got forcibly disconnected. This indicates that script has nothing to do with the problem. The reason is rather speed of 'typing'. It was *never* an issue in environments I worked. Including some scripting on PC, even huge batch script, which issued millions of CICS transaction using 3270 emulator. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
On Thu, 15 Jun 2006 00:00:00 GMT, Ted MacNEIL [EMAIL PROTECTED] wrote: Yes, IP drops packets. But also, yes, TCP keeps track of it all and requests retransmissions. Not according to the traces. I obviously can't comment on traces I haven't seen. I can say that TCP provides guaranteed delivery ... if you (and your software) are willing to cope with some very ugly timings. If TCP/IP is so robust, why has it NEVER happened in 7 years under SNA (how long we've had the TN3270 client we use), and it always happens under TCP/IP. I don't understand that statement. If you've been using Tn3270 for 7 years you've been using TCP/IP. By definition, Tn3270 is 3270 over TCP/IP. We have MACROS (scripts) coded for call centres to screen scrape an old CICS application and answer customers' questions. They have never failed under SNA. The only change we make (and I know it's the only change because I am co- ordinating it and controlling it), is we make the TN3270 client talk to TCP/IP. Invoke the MACRO and BOOM!. First, in my VERY unhumble opinion, anybody using screen scraping gets what he or she deserves. (BOOM!) That was as true under pure SNA as under TCP/IP. (If you went for 7 years without screen reformatting you lived in a very static world, indeed. Corrupted (incomplete) data sent to the host, the application session gets terminated and the user is blown to a blank sign-on screen. Doesn't even have the logo and sign-on crap we display when the PC first connects to the mainframe. Every time. Not intermittent. No re-transmission requests. No session. No data. That sounds like a problem with the Tn3270 client, or some kind of incompatability between the Tn3270 client and server, or some such. If this is not an intermittant problem it is absurd to blame it on dropped IP packets. Dropped packets are not a repeatable issue ... unless you are violating the protocol or have something misconfigured. (Sending packets too large for a level-2 switch will be dropped every time. And trying to set up an SNA connection between mismatched ends will fail, too. Remember NRZI vs non-NRZI?) I happen to be an SNA bigot and have no love for TCP/IP, but don't like seeing bogus arguments against TCP/IP. Crying wolf helps nobody. Find more specifics about your failure; there is something more specific than just TCP/IP here. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
I obviously can't comment on traces I haven't seen. I can say that TCP provides guaranteed delivery ... if you (and your software) are willing to cope with some very ugly timings. We have no guaranteed delivery! Period! And, the only change was SNA to TCP/IP. If TCP/IP is so robust, why has it NEVER happened in 7 years under SNA (how long we've had the TN3270 client we use), and it always happens under TCP/IP. I don't understand that statement. If you've been using Tn3270 for 7 years you've been using TCP/IP. By definition, Tn3270 is 3270 over TCP/IP. Not being a network person, I may be tripping over terminology. It's been the same desktop client for 7 years. First, in my VERY unhumble opinion, anybody using screen scraping gets what he or she deserves. (BOOM!) That was as true under pure SNA as under TCP/IP. All well and good! It doesn't fly with the business or my mangement. If I could get away with that, we would be TCP/IP on the mainframe, tomorrow. And, we would have a whole lot of scrap 3745's and 3174's. (If you went for 7 years without screen reformatting you lived in a very static world, indeed. Never said that we did. We have people who re-do the MACROS when the screens change. (Just did it for Germany) That sounds like a problem with the Tn3270 client, or some kind of incompatability between the Tn3270 client and server, or some such. I can reproduce the problem manually (with 5 minutes of effort). It has to do with the lack of think time. Just pound a PFKey until the host barfs. It happens with: RUMBA ATTACHMATE Hummingbird, and at least three different web-clients: 2 in JAVA and on in ACTIVEx. If this is not an intermittant problem it is absurd to blame it on dropped IP packets. Dropped packets are not a repeatable issue ... unless you are violating the protocol or have something misconfigured. The packet drops (not always the same one), but with no think time the desktop is sending the data too fast. (Sending packets too large for a level-2 switch will be dropped every time. And trying to set up an SNA connection between mismatched ends will fail, too. Remember NRZI vs non-NRZI?) I don't know what you just said. And, no, I don't remember. The packets are one PFKey. I happen to be an SNA bigot and have no love for TCP/IP, but don't like seeing bogus arguments against TCP/IP. It's not bogus. I explained the issue to a z/OS TCP/IP consultant, at CMG Canada in April. Even with my poor grasp of terminology, she knew what the issue was. Something about NAGLE (spelling?) and host settle-time. Crying wolf helps nobody. I am not crying wolf. Also, I was not asking for help here. I was just pointing out that TCP/IP sucks, is a weak protocol and is going to take over the market. Find more specifics about your failure; there is something more specific than just TCP/IP here. If I knew what questions to ask, I would. Standard Problem Determination question: What changed? Answer: I changed to protocol on the desktop to communicate through TCP/IP, rather than SNA. Next question: What was the result? Answer: No matter what client I used, if I typed 'too fast', my session got forcibly disconnected. Secondary Answer: When I used scripts, it happened immediately! IPSO FACTO! Q.E.D. . -teD Marching to the beat of a different flute -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
On Fri, 16 Jun 2006 00:00:00 GMT, Ted MacNEIL wrote: ...snipped... I happen to be an SNA bigot and have no love for TCP/IP, but don't like seeing bogus arguments against TCP/IP. It's not bogus. I explained the issue to a z/OS TCP/IP consultant, at CMG Canada in April. Even with my poor grasp of terminology, she knew what the issue was. Something about NAGLE (spelling?) and host settle-time. Read a little about John Nagle's observations on network performance here: http://www.port80software.com/200ok/archive/2005/01/31/317.aspx That particular link hyperlinks to a Microsoft page that gives you a clue how to change your registery settings to alter the PC's settle time. Perhaps that will help you? (If not, RFC896 is Mr. Nagle's original RFC on the subject. Use 'RFC896' as a search argument in your TCPIP terminal emulator documentation to see if they offer help there.) -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
Tom Schmidt wrote: Read a little about John Nagle's observations on network performance here: http://www.port80software.com/200ok/archive/2005/01/31/317.aspx That particular link hyperlinks to a Microsoft page that gives you a clue how to change your registery settings to alter the PC's settle time. Perhaps that will help you? (If not, RFC896 is Mr. Nagle's original RFC on the subject. Use 'RFC896' as a search argument in your TCPIP terminal emulator documentation to see if they offer help there.) my ietf RFC index (frames mode) http://www.garlic.com/~lynn/rfcietff.htm normally RFC summaries load in the lower frame. clicking on the .txt=nnn field in the summaries retrieves the actual RFC. RFC 896 http://www.garlic.com/~lynn/rfcidx2.htm#896 896 Congestion control in IP/TCP internetworks, Nagle J., 1984/01/06 (9pp) (.txt=26782) (Ref'ed By 985, 1016, 1072, 1122, 1254, 1323, 1812, 2126, 2309, 2525, 2556, 2914, 3539, 3714, 4138, 4172, 4413) however, see several implementation discussions in 1122 related to Nagle. http://www.garlic.com/~lynn/rfcidx3.htm#1122 1122 S Requirements for Internet hosts - communication layers, Braden R., 1989/10/01 (116pp) (.txt=289148) (STD-3) (Updated by 4379) (See Also 1123) (Refs 768, 791, 792, 793, 813, 814, 815, 816, 817, 826, 879, 893, 894, 896, 922, 950, 963, 964, 980, 994, 995, 1009, 1010, 1011, 1016, 1042, 1071, 1072, 1108, 1112) (Ref'ed By 1127, 1180, 1190, 1191, 1207, 1219, 1254, 1256, 1329, 1349, 1370, 1379, 1385, 1403, 1433, 1455, 1517, 1531, 1533, 1541, 1561, 1577, 1620, 1626, 1644, 1716, 1745, 1755, 1770, 1812, 1819, 1885, 1933, 1937, 1970, 2001, 2131, 2132, 2176, 2225, 2309, 2331, 2353, 2360, 2391, 2414, 2461, 2463, 2474, 2481, 2488, 2498, 2521, 2525, 2581, 2663, 2678, 2694, 2757, 2760, 2784, 2822, 2834, 2835, 2893, 2914, 2923, 2988, 3021, 3022, 3081, 3135, 3154, 3155, 3168, 3175, 3259, 3260, 3360, 3366, 3390, 3435, 3449, 3465, 3481, 3490, 3522, 3684, 3720, 3821, 3884, 3948, 4035, 4172, 4302, 4367, 4379, 4391, 4413, 4443, 4459, 4460) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
1122 S Requirements for Internet hosts - communication layers, Braden R., Abbott Costello: Costello: I can speak any language in the world, except Greek. Abbott: Say something in Spanish. Costello: That's Greek to me! . -teD Marching to the beat of a different flute -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
On Mon, 12 Jun 2006 00:00:00 GMT, Ted MacNEIL [EMAIL PROTECTED] wrote: TCP keeps track of it all, requesting a resend of dropped/lost/missing packets. NOT in this case! The packets are dropped! They are not re-sent and the app is blown off the air. It works under SNA; it bellies up under TCP/IP. Every time! Repeatable! ... I'm way behind on on IBM-Main so am probably jumping onto a cold thread, but want to add my belated 2 cents worth. Ted is probably right about the behavior of the application and is spot-on with Repeatable!, but is a bit off on his criticizm of TCP/IP. Yes, IP drops packets. But also, yes, TCP keeps track of it all and requests retransmissions. The reason this works much better in SNA (IM not so HO) is that the error detection and correction in SNA happens at a much lower level than in TCP/IP - at what would be the IP level - at the level where timers can match line characteristics - very short timers. There is guaranteed delivery at a very low level; data gets through or the route is declared dead. On the other hand, IP does not guarantee delivery. It is left up to the higher (TCP) level to detect need for retransmission. And since any 2 packets can flow across different routes with very different speeds, it has to have very long timers or risk requesting unneeded retransmissions. If the retransmission timers are longer than timers in the application (something completely unneeded in an SNA app), the app may choke even though data is on the way. In other words, TCP guarrentees delivery of data, but the app may not be willing or able to wait. One aspect of this is that behavior of an SNA network is MUCH more predictable than a TCP/IP behavior. Network management is self- contradictory in TCP/IP because behavior is too random. And in regard to the DNS issues in this thread, that's sort of a red herring. IP addressing is based on numeric addresses. SNA addressing is based on netid.resource names (with numeric addresses used within a domain, and to a lesser extent, between domains in SNI configurations). What would an SNA name server do? A bigger issue is that a public network like the internet does not map well to SNA's 2-level name structure. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
Yes, IP drops packets. But also, yes, TCP keeps track of it all and requests retransmissions. Not according to the traces. If TCP/IP is so robust, why has it NEVER happened in 7 years under SNA (how long we've had the TN3270 client we use), and it always happens under TCP/IP. We have MACROS (scripts) coded for call centres to screen scrape an old CICS application and answer customers' questions. They have never failed under SNA. The only change we make (and I know it's the only change because I am co-ordinating it and controlling it), is we make the TN3270 client talk to TCP/IP. Invoke the MACRO and BOOM!. Corrupted (incomplete) data sent to the host, the application session gets terminated and the user is blown to a blank sign-on screen. Doesn't even have the logo and sign-on crap we display when the PC first connects to the mainframe. Every time. Not intermittent. No re-transmission requests. No session. No data. . -teD Marching to the beat of a different flute -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
I'm going to ask a dumb question about the TN3270 client - is it somehow using UDP instead of TCP? I don't even know what UDP is. I'm not a network person. I'm stuck on this project because I'm the only Mainframe Techie for our company. The rest are outsourced. The traces show some kind of stutter. Then a 'terminate session' request is sent back to the client workstation. The terminology is not from our service provider's staff, rather from a second (or third) hand explanation. I mentioned our problem to a z/OS TCP/IP consultant I met at a CMG Canada seminar, two months ago. She understood what the problem was (or so it seemed). She mentioned something called a 'nagle' (spelling?). She mentioned that we could engage her through IGS. We have tried to engage IGS and they have been hesitant to take our money. They suggested a PMR. We've been that route with no success. . -teD Marching to the beat of a different flute -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
In [EMAIL PROTECTED], on 06/15/2006 at 02:47 PM, Patrick O'Keefe [EMAIL PROTECTED] said: What would an SNA name server do? Map a tree structured name space into a two level name space, of course. -- 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
In [EMAIL PROTECTED], on 06/12/2006 at 07:21 AM, Anne Lynn Wheeler [EMAIL PROTECTED] said: SNA isn't networking Not originally, but that changed with MSNF and changed more with SNI. -- 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
Can you envision running the Internet on SNA? o 8-character flat namespace? o No DNS? If you build it, they will come. But, the biggest problem is data integrity, as far as I'm concerned. We have a problem where data is dropped under TCP/IP and it is not under SNA. Same circumstances. Fully repeatable. The issue is caused by user written macros (scripts), that are needed for the business. The data comes in so fast that TCP/IP cannot handle it and the users session is blown out of the water. Under SNA it does not happen. - -teD 300,000 Kilometres per Second Not only is it a good idea! It's the LAW!!! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
Paul Gilmartin wrote: Can you envision running the Internet on SNA? o 8-character flat namespace? o No DNS? Or am I mistaking attributes of VTAM for SNA? (But still, where's SNA's DNS?) SNA isn't networking ... at least in the sense used by most of the rest of the world. SNA is quite good at managing large number of terminals ... or things effectively emulating large number of terminals http://www.garlic.com/~lynn/subnetwork.html#emulation in heavily SNA centric environment, the term peer-to-peer networking was invented to describe standard networking (as understood by most of the rest of the world) differentiated from SNA communication infrastructures. in the early SNA days, my wife had co-authored peer-to-peer networking architecture with Bert Moldow ... AWP39 (which never got announced as product, sna group possibly viewed it as competition). Later, when she was con'ed into going to POK to be in charge of loosely-coupled architecture ... she originated peer-coupled shared data http://www.garlic.com/~lynn/subtopic.html#shareddata which didn't see a lot of uptake ... except for the guys doing IMS hot-standby ... at least until parallel sysplex came along. the closest thing to networking within any kind of SNA context was AWP169 ... which the SNA organization non-concurred with announcing. After some escalation, AWP169 announcement letter ... APPN was carefully crafted to not imply any relationship between AWP169/APPN and SNA. I used to chide the person responsible for AWP169 that he was wasting his time trying to craft networking into SNA context ... they were never going to appreciate and/or accept him ... he would be much better off spending his time working within a real networking context like the internet. note that the explosion in the internal corporate network in the 70s and early 80s ... wasn't an SNA implementation either however it had a form of gateway capability implemented in every node. slight drift ... it was another product brought to you courtesy of the science center http://www.garlic.com/~lynn/subtopic.html#545tech as was virtual machines, the (smp) compare-and-swap instruction, the invention of GML (original ancestor of sgml, html, xml, etc), and numerous interactive technologies. i've also asserted that all the performance measurement, modeling, workload profiling, etc, etc ... evolved into what is now called capacity planning http://www.garlic.com/~lynn/subtopic.html#benchmark in any case (in part because of the gateway like function), the internal network http://www.garlic.com/~lynn/subnetwork.html#internalnet was larger than arpanet/internet from just about the beginning until possibly mid-85. the arpanet got its gateway capability with the great switchover to internetworking protocol on 1/1/83. http://www.garlic.com/~lynn/subnetwork.html#internet recent thread that discussed the size of the internal network vis-a-vis the size of the arpanet http://www.garlic.com/~lynn/2006j.html#34 Arpa address http://www.garlic.com/~lynn/2006j.html#45 Arpa address http://www.garlic.com/~lynn/2006j.html#46 Arpa address http://www.garlic.com/~lynn/2006j.html#49 Arpa address http://www.garlic.com/~lynn/2006j.html#50 Arpa address http://www.garlic.com/~lynn/2006j.html#53 Arpa address http://www.garlic.com/~lynn/2006k.html#3 Arpa address http://www.garlic.com/~lynn/2006k.html#8 Arpa address http://www.garlic.com/~lynn/2006k.html#9 Arpa address http://www.garlic.com/~lynn/2006k.html#10 Arpa address http://www.garlic.com/~lynn/2006k.html#12 Arpa address http://www.garlic.com/~lynn/2006k.html#40 Arpa address http://www.garlic.com/~lynn/2006k.html#42 Arpa address http://www.garlic.com/~lynn/2006k.html#43 Arpa address misc. past posts mentioning awp39 and/or awp169 (appn): http://www.garlic.com/~lynn/2004n.html#38 RS/6000 in Sysplex Environment http://www.garlic.com/~lynn/2004p.html#31 IBM 3705 and UC.5 http://www.garlic.com/~lynn/2005p.html#8 EBCDIC to 6-bit and back http://www.garlic.com/~lynn/2005p.html#15 DUMP Datasets and SMS http://www.garlic.com/~lynn/2005p.html#17 DUMP Datasets and SMS http://www.garlic.com/~lynn/2005q.html#27 What ever happened to Tandem and NonStop OS ? http://www.garlic.com/~lynn/2005u.html#23 Channel Distances http://www.garlic.com/~lynn/2006h.html#52 Need Help defining an AS400 with an IP address to the mainframe http://www.garlic.com/~lynn/2006j.html#31 virtual memory http://www.garlic.com/~lynn/2006k.html#9 Arpa address http://www.garlic.com/~lynn/2006k.html#21 Sending CONSOLE/SYSLOG To Off-Mainframe Server http://www.garlic.com/~lynn/2006l.html#4 Google Architecture -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
But, the biggest problem is data integrity, as far as I'm concerned. We have a problem where data is dropped under TCP/IP and it is not under SNA. Pardon? TCP and IP are not the same thing. TCP is a stateful protocol that is implemented over the top of IP which isn't. It is perfectly ok for IP to drop a packet or thirty. TCP keeps track of it all, requesting a resend of dropped/lost/missing packets. In practical terms there isn't a lot of difference between an SNA session and a TCP/IP session - except that the TCP/IP one is vastly easier to set up and manage. I can't believe you guys are waxing lyrical about SNA. Have you forgotten what a royal PITA it is to set up and manage? CC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Ted MacNEIL I think it also was due (in part at least) to the late 80's/early 90's Anything but IBM attitude, Possibly, but I also see the same attitude with TCP/IP. This is the standard? Why? Compared to SNA, it sucks! Not even that good, yet. Unrelated question: Why do you preset the Reply-to: for offlist replies? -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
Ed Gould wrote: I don't think SNA has anything like a DNS (warning my info is old). The last time I did a 3745 gen you had to hardcode a lot of subareas. Although I do think they have updated it since then (hope so anyway). There were some route tables that could get hairy. I had access to the RTG tool and it made a complicated map reasonably easy. IIRC, SNI was another mess that helped, but it was still complicated. JES2 could add complexity as he could start routing output via another node that you didn't expect if you weren't careful. To most (all?) nodes in my 200+ node JES2 network I turned off the JES2 routing as we were connected all over the place and I did not want the output to be done through a 3rd party node. I suppose if the nodes were all one company it wouldn't make a difference. But financial information was too important to let others see it. re: http://www.garlic.com/~lynn/2006l.html#45 Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?) a lot of the original hasp/jes2 networking code running originally on the internal network still carried the TUCC identifier on source code cards. HASP had a 255 entry table for psuedo devices. the hasp/jes2 support started out defining networking nodes using unused entries in the psuedo device table. that typically allowed JES2 to defined something like 160-200 networking nodes. misc. past hasp /or jes2 postings http://www.garlic.com/~lynn/subtopic.html#hasp by the time JES2 networking was announced as a product, the internal network had over 255 nodes http://www.garlic.com/~lynn/subnetwork.html#internalnet and by the time JES2 had support for 999 nodes, the internal network was over 1000 nodes, and by the time JES2 had support for 1999 nodes, the internal network was over 2000 nodes. JES2 would trash any network traffic that came thru the node, where JES2 didn't have the destination node in its local table. However, JES2 also would trash any network traffic where the originating node wasn't in its local table. This made JES2 almost unusable on the internal network except as carefully controlled end-node (not as any sort of intermediate storeforward node). the other problem was that JES2 network architecture was notorious for getting networking mixed up with work load processing. relatively minor changes in header formats between releases could result in one JES2 system crashing another JES2 (and associated MVS) system. there is an infamous case on the internal network where a JES2 system in San Jose was causing a MVS system in Hursley to crash. since the primary mainstay of the internal network had implemented gateway-like capability ... it also implemented a large array of different interfaces/gateways to JES2 systems allowing JES2 networking some modicum of participation in the internal network. because of the problem with one jes2 system causing other jes2/mvs systems to crash (due to even minor from changes in version/releases) ... there grew up compensating processes in the internal network jes2 gateway interfaces. basically a canonical jes format representation. An internal network interface that talked directly to a real JES2 node ... would be specific to that version/release of jes2 ... and eventually had the code that converted from canonical JES2 format to the format needed by that specific JES2 system (as countermeasure preventing different JES2 systems causing each other to crash). as an aside ... the corporate requirements for the internal network required all transmission leaving a corporate facility to be encrypted. at one point there was the claim that the internal network had over half of all the link encryptors in the world. one of the harder issues getting internal network connectivity in various parts of the world was the issue of encrypted links crossing national boundaries ... it was frequently a really tough sell to get two (or more) different government agencies to all agree that a link going from one corporate location (in one country) to another corporate location (in a different country) could be encrypted. disclaimer ... during part of this period my wife served a stint in the g'burg jes group. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
TCP keeps track of it all, requesting a resend of dropped/lost/missing packets. NOT in this case! The packets are dropped! They are not re-sent and the app is blown off the air. It works under SNA; it bellies up under TCP/IP. Every time! Repeatable! - -teD 300,000 Kilometres per Second Not only is it a good idea! It's the LAW!!! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on
In a recent note, Ted MacNEIL said: Date: Mon, 12 Jun 2006 00:00:00 GMT o No DNS? If you build it, they will come. So, then, IBM elected not to build it, and they stayed away. And the Wheelers attribute grave architectural paralysis to political infighting within IBM. Pity. If it were a usable alternative to TCP/IP, and more reliable, it would be valuable. -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
Ted MacNEIL wrote: NOT in this case! The packets are dropped! They are not re-sent and the app is blown off the air. It works under SNA; it bellies up under TCP/IP. Every time! Repeatable! there were some amount of dirty tricks ... not all that can be repeated in polite company. with respect to the previous post about running sna thru a real (peer-to-peer) infrastructure http://www.garlic.com/~lynn/2006.html#50 Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?) and eliminating the communication groups whole 37xx business the obvious reaction was to get corporate to make sure all of my funding was cut. the couldn't actually kill the project because it came out of another organization and most of the work was going to be subcontracted to the original (RBOC) implementers. so showing a little ingenuity ... we went to one of the largest SNA customers. they had a huge annual budget devoted to operational and infrastructure things to compensate for SNA shortcomings. we showed that the fully funded costs for development, ship, and support of this other thing ... plus the hardware costs replacing all the 37xx boxes ... was less than their first year savings on all the add-on stuff that they could now eliminate (i.e. the customer would fund the total product development and product ship costs ... because they would easily recover that within the first year of operation). getting that part stop required other measures. so there was an early mainframe tcp/ip implementation. in the late 80s, it would get about 44kbyte/sec aggregate thruput and consume just about a whole 3090 processor. i added rfc 1044 support to the implementation and in some tuning tests at cray research between a 4341 (clone) and a cray machine was able to show sustained effective thruput of approx. 1mbyte/sec using only a modest amount of the 4341 processor (limited to the controller hardware interface to the 4341 channel); i.e. about 25 times the thruput for maybe 1/10th the pathlength. was somehow able to sneak out rfc 1044 support in the product when nobody was looking. misc. past posts mentioning rfc 1044 support: http://www.garlic.com/~lynn/subnetwork.html#1044 the communication division finally came out and said that even tho sna and OSI were strategic (govs. and large institutions and organizations were all publicly claiming that all that internetworking stuff was going to be eliminated and replaced by osi) http://www.garlic.com/~lynn/subnetwork.html#xtphsp ... that they were doing a tcp/ip implementation support in vtam. there was an organization in palo alto sq (corner of page mill and el camino) that was sometimes referred to as communication west. they got the job of subcontracting the vtam implementation to a contractor. the first/original (vtam) implementation had tcp/ip thruput significantly higher than lu6.2. it was then explained to the contractor that all protocol analysis have shown that lu6.2 has higher thruput than tcp/ip ... and therefor any tcp/ip implementation that benchmarked tcp/ip with substantially higher thruput than lu6.2 was incorrect ... and the company wasn't going to pay for an incorrect tcp/ip implementation. so what did the contractor do? in that time-frame there was some analysis of NFS implementation running on top of typical tcp/ip ... common bsd tahoe/reno workstation implementation. there was a range of implementations from a low of 5k instruction pathlength (and five buffer copies) to something like 40k instruction pathlength ... to do a typical NFS operation. in some detailed comparisons, it was claimed that somewhat equivalent mainframe function (not NFS, but the closest that SAA had to NFS capability) implemented on top of LU6.2 required 160k instructions and 15 buffer copies. Also, at the time, one of the issues in doing an 8kbyte buffer copy (involved in a NFS equivalent operation) was that 15 8k buffer copies could add more processor cycles than executing the 160k instructions. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
I think it also was due (in part at least) to the late 80's/early 90's Anything but IBM attitude, driven in part by the OS2/MCA debacle. Wayne Driscoll Product Developer JME Software LLC NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Thursday, June 08, 2006 12:48 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?) Froberg, David C wrote: I think another author who addressed very well the issue of changes in the paradigm is Clayton Christensen in The Innovator's Dilemma in which he made a compelling case that paradigm shifts occur when new technologies become cheap enough to do a good enough job, become increasingly adopted and adapted, and the established interests wait to long to respond. I'm dealing _right now_ with network performance issues in a mixed-media network and wondering _how on earth_ Ethernet managed to gain so much market acceptance and prevail over Token-Ring. It certainly wasn't due to technical superiority. (Far from it!) From what I can gather, it was price, price, and ... oh yeah ... price... -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
I think it also was due (in part at least) to the late 80's/early 90's Anything but IBM attitude, Possibly, but I also see the same attitude with TCP/IP. This is the standard? Why? Compared to SNA, it sucks! - -teD 300,000 Kilometres per Second Not only is it a good idea! It's the LAW!!! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
In a recent note [EMAIL PROTECTED] said: Date: Sun, 11 Jun 2006 00:00:00 GMT I think it also was due (in part at least) to the late 80's/early 90's Anything but IBM attitude, Possibly, but I also see the same attitude with TCP/IP. This is the standard? Why? Compared to SNA, it sucks! Can you envision running the Internet on SNA? o 8-character flat namespace? o No DNS? Or am I mistaking attributes of VTAM for SNA? (But still, where's SNA's DNS?) -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
On Jun 11, 2006, at 10:55 PM, Paul Gilmartin wrote: In a recent note [EMAIL PROTECTED] said: Date: Sun, 11 Jun 2006 00:00:00 GMT I think it also was due (in part at least) to the late 80's/early 90's Anything but IBM attitude, Possibly, but I also see the same attitude with TCP/IP. This is the standard? Why? Compared to SNA, it sucks! Can you envision running the Internet on SNA? o 8-character flat namespace? o No DNS? Or am I mistaking attributes of VTAM for SNA? (But still, where's SNA's DNS?) -- gil Gil, I don't think SNA has anything like a DNS (warning my info is old). The last time I did a 3745 gen you had to hardcode a lot of subareas. Although I do think they have updated it since then (hope so anyway). There were some route tables that could get hairy. I had access to the RTG tool and it made a complicated map reasonably easy. IIRC, SNI was another mess that helped, but it was still complicated. JES2 could add complexity as he could start routing output via another node that you didn't expect if you weren't careful. To most (all?) nodes in my 200+ node JES2 network I turned off the JES2 routing as we were connected all over the place and I did not want the output to be done through a 3rd party node. I suppose if the nodes were all one company it wouldn't make a difference. But financial information was too important to let others see it. Ed -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
On Thu, 8 Jun 2006 10:48:04 -0700, Edward Jaffe [EMAIL PROTECTED] wrote: I'm dealing _right now_ with network performance issues in a mixed-media network and wondering _how on earth_ Ethernet managed to gain so much market acceptance and prevail over Token-Ring. It certainly wasn't due to technical superiority. (Far from it!) From what I can gather, it was price, price, and ... oh yeah ... price... The same reason people are moving away from the mainframe. Look at any mainframe shop and you'll see an explosive growth in computing power. The mainframes are staying about the same while *ix and Microslop gain. Not trying to open the debate about TCO... The perception is that the mainframe is expensive. It's really unfortunate that IBM isn't pricing software aggressively to stop the hemorrhage. Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
On Thu, 8 Jun 2006 11:16:06 -0400, Jon Brock [EMAIL PROTECTED] wrote: This shows some of the good and some of the bad with using open-source technologies. You can do some very useful and exciting stuff, but it is not as mature as what we are used to with z/OS. Linux and Unix are nowhere near what MVS is, but I'll take Linux and other Open source software over Microsoft any day. Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
The same reason people are moving away from the mainframe. Look at any mainframe shop and you'll see an explosive growth in computing power. The mainframes are staying about the same while *ix and Microslop gain.. That may be true in your situation, but certainly not everywhere. Some mainframe shops have stagnated. Others are seeing tremendous growth. Are server MIPS growing faster than mainframe MIPS? Probably, but that doesn't mean mainframes aren't growing. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
On Fri, 9 Jun 2006 08:28:57 -0400, Bob Shannon [EMAIL PROTECTED] wrote: The same reason people are moving away from the mainframe. Look at any mainframe shop and you'll see an explosive growth in computing power. The mainframes are staying about the same while *ix and Microslop gain.. That may be true in your situation, but certainly not everywhere. Some mainframe shops have stagnated. Others are seeing tremendous growth. Are server MIPS growing faster than mainframe MIPS? Probably, but that doesn't mean mainframes aren't growing. I'd like to see the shop where the mainframe is growing even half as fast as the other platforms. I'd also like to see the number of mainframe shops increasing. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
But it's a totally diffrent paradigm, IMHumbleO. In our shop, we have many unixen. But their CP is tied to memory. Each unixen CP has to have xMB memory, and they come in fours. You want more memory? 4 More CP + 4 * xMB. And so on. That's costly. Mainframe is diffrent. Much Diffrent. And the people? For twenty unix boxen, 1 sysprog/admin. Not Gartner, but close to real. Big shops, two - three hundred unix boxen, some maybe 'super-domes', really 30 -35 per seat - tough job, really tough. Close to mainframe? I think totally diffrent. For Multi-Sysplex MainFrame Production system, how many sysprogs to change a light bulb? I love my job. On 6/9/06, Bob Shannon [EMAIL PROTECTED] wrote: The same reason people are moving away from the mainframe. Look at any mainframe shop and you'll see an explosive growth in computing power. The mainframes are staying about the same while *ix and Microslop gain.. That may be true in your situation, but certainly not everywhere. Some mainframe shops have stagnated. Others are seeing tremendous growth. Are server MIPS growing faster than mainframe MIPS? Probably, but that doesn't mean mainframes aren't growing. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Tom Marchant Sent: Friday, June 09, 2006 7:17 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?) On Thu, 8 Jun 2006 11:16:06 -0400, Jon Brock [EMAIL PROTECTED] wrote: This shows some of the good and some of the bad with using open-source technologies. You can do some very useful and exciting stuff, but it is not as mature as what we are used to with z/OS. Linux and Unix are nowhere near what MVS is, but I'll take Linux and other Open source software over Microsoft any day. Tom Marchant Yes, YOU will take Linux over Windows, as would I. Are you the decision maker? Unfortunately, in many cases, the decision makers have a herd mentality. I remember when it was Nobody got fired for buying IBM.. Now it is Nobody got fired for buying Microsoft. -- 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 IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
John McKown wrote: Yes, YOU will take Linux over Windows, as would I. Are you the decision maker? Unfortunately, in many cases, the decision makers have a herd mentality. I remember when it was Nobody got fired for buying IBM.. Now it is Nobody got fired for buying Microsoft. Well, OK, but there's a mighty big (and still fast growing) Linux herd. There's plenty of market research data on that from Gartner, IDC, etc. Your particular company may be different -- maybe your herd got separated from the bigger herd -- but there's no lack of big herd here. Maybe three to five years ago, maybe. Actually if you do a quick Google search -- and if the results are consistent :-) -- you'd see that, indeed, there are plenty of people who got fired for buying Microsoft. My Google says Cardsystems, National Westminster Bank, Commonwealth Bank of Australia, and the unnamed CIO in the story I posted not too long ago, among others. You don't buy Linux, so it's impossible to get fired for buying Linux. (Or maybe you should always get fired for buying Linux because you don't have to buy Linux. :-)) You buy (or don't buy) Linux support. - - - - - Timothy F. Sipples Consulting Enterprise Software Architect, z9/zSeries IBM Japan, Ltd. E-Mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
Why are mainframe people so reluctant to change ? Not all of us are reluctant. I remember being in an SHARE session about OpenEdition (gee, was it ESA 4.3 or 5.1, about 10 years ago). It was in a small hotel room where the speaker was talking about this new feature called OpenEdition and the room was packed. As soon as I got back to work, I was scrambling to get OE on to our system. Unix and Open Standards clearly had a future on the mainframe. In due time, I dug into Linux and TCP/IP too. Oh to use Samba, SMB, or NFS to make the MF a big fileserver to the client/server flock. New applications on the MF? Would have loved too. But, when you work at shops where management has determined to leave the mainframe for whatever reason, there's only so much you can do. very Boyd and ooda-loop oriented http://www.garlic.com/~lynn/subboyd.html#boyd http://www.garlic.com/~lynn/subboyd.html#boyd2 Thank you for the links about Boyd. Your references to him are very appropriate. Boyd was brilliant and gutsy and not studied enough. I think another author who addressed very well the issue of changes in the paradigm is Clayton Christensen in The Innovator's Dilemma in which he made a compelling case that paradigm shifts occur when new technologies become cheap enough to do a good enough job, become increasingly adopted and adapted, and the established interests wait to long to respond. Dave -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
I have had some squirrely results with both NFS and Samba. In the latest case, I was mounting a CD on a desktop Linux system and exporting the CD-RW drive. I could never get the NFS file system mounted on my client platform (I need to go back and check on this at some point). When I switched to Samba, I could mount it just fine, but using it to drive a WebSphere graphical install did not work. I eventually used the SMB-mounted file system to copy the CD over to the target VM/Linux system and installed from there. Worked great. This shows some of the good and some of the bad with using open-source technologies. You can do some very useful and exciting stuff, but it is not as mature as what we are used to with z/OS. Jon snip Oh to use Samba, SMB, or NFS to make the MF a big fileserver to the client/server flock. New applications on the MF? Would have loved too. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
On Thu, 8 Jun 2006 09:13:10 -0400, Froberg, David C [EMAIL PROTECTED] wrote: I think another author who addressed very well the issue of changes in the paradigm is Clayton Christensen in The Innovator's Dilemma in which he made a compelling case that paradigm shifts occur when new technologies become cheap enough to do a good enough job, become increasingly adopted and adapted, and the established interests wait to long to respond. Read The Tipping Point by Malcolm Gladwell for some interesting thoughts on what brings about change. Fascinating book. Bill Seubert zSeries Software I/T Architect IBM Corp [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
Froberg, David C wrote: I think another author who addressed very well the issue of changes in the paradigm is Clayton Christensen in The Innovator's Dilemma in which he made a compelling case that paradigm shifts occur when new technologies become cheap enough to do a good enough job, become increasingly adopted and adapted, and the established interests wait to long to respond. I'm dealing _right now_ with network performance issues in a mixed-media network and wondering _how on earth_ Ethernet managed to gain so much market acceptance and prevail over Token-Ring. It certainly wasn't due to technical superiority. (Far from it!) From what I can gather, it was price, price, and ... oh yeah ... price... -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
In a message dated 6/8/2006 12:48:33 P.M. Central Standard Time, [EMAIL PROTECTED] writes: to technical superiority. (Far from it!) From what I can gather, it was price, price, and ... oh yeah ... price... And graphics -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Edward Jaffe Froberg, David C wrote: I think another author who addressed very well the issue of changes in the paradigm is Clayton Christensen in The Innovator's Dilemma in which he made a compelling case that paradigm shifts occur when new technologies become cheap enough to do a good enough job, become increasingly adopted and adapted, and the established interests wait to long to respond. I'm dealing _right now_ with network performance issues in a mixed-media network and wondering _how on earth_ Ethernet managed to gain so much market acceptance and prevail over Token-Ring. It certainly wasn't due to technical superiority. (Far from it!) From what I can gather, it was price, price, and ... oh yeah ... price... Good enough is. So it was with VHS over BETA, TCPIP over SNA, Windows over OS/2, (E)ISA over MicroChannel Who's your favorite between HD-DVD and Blue-Ray? -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
Browsed that book this past Sunday but did not buy it. Maybe I'll take another look. Jon snip Read The Tipping Point by Malcolm Gladwell for some interesting thoughts on what brings about change. Fascinating book. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting
Quote from IBM US Announcement letter 201-163 release may 29th, 2001: z/VM Version 4 offers a great opportunity for customers to exploit S/390® or zSeries servers at a substantially lower cost. This new version of z/VM will be priced on a per-engine basis and will support IBM Integrated Facility for Linux (IFL) processor features for Linux-based workloads and standard engines for all other zSeries and S/390 workloads (an engine is also referred to as a Central Processor). Birger Heede (not an IBM spokesperson) IBM SWG Ted MacNEIL wrote: z/VM is the only IBM-provided OS that will run on either an IFL or a standard CP Show me the documentation. I have never seen/heard this, and I have been doing everything I can do to steer my management towards LINUX on z! - -teD 300,000 Kilometres per Second Not only is it a good idea! It's the LAW!!! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
I'm not disagreeing, just emphasizing your point: Other-platform folk happily proceed with projects whose problems they can't anticipate and (maybe) solve the problems later. Mainframers are better at seeing problems with proposed projects. And it's the mainframers who need their attitudes adjusted, not the other-platform folk who management thinks should do better project analysis. Sad but likely true. I've worked in no-bad-news settings where messengers bearing unhappy news had a poor survival rate. Marian Gasparovic [EMAIL PROTECTED] said: If you come with an idea of new application or solution, people from other platform see no problem, mainframe people show what are pitfalls. I don't say it is bad, I know it is because of their responsibility and experience to see the problems way ahead, but unfortunately today's market doesn't work this way. Everybody wants everything as fast as possible, problems are solved later, during production. Yes, it is totaly wrong, but it is reality. -- Gabriel Goldberg, Computers and Publishing, Inc. (703) 204-0433 3401 Silver Maple Place, Falls Church, VA 22042[EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting
Mark Post writes: One other thing for people to consider: even on machines that have standard CPs running at sub-capacity, IFL processors _always_ run at full-rated speed, without increasing your IBM or ISV software charges for the workload running on the standard CPs. (See the first link listed for documentation of this.) Another nice benefit is that IFLs (and zIIPs and zAAPs) carry forward one-for-one with a model upgrade, and they get faster in the process. Mark Zelden writes: Without getting into too much detail.. there were two projects (POCs) going on. One was related to moving TSM off of z/OS to run on zLinux under z/VM and the other was moving TAMe from AIX (I think.. it could have been Wintel). Rule of thumb (oversimplification? :-)): moving something from z/OS onto mainframe Linux is not usually a good idea. Tivoli Storage Manager would probably be a particularly bad candidate, so your outcome would have been predicted. Do you happen to know what the thinking was on that? It's a very odd choice. Storage management is extremely highly evolved and very efficient on z/OS. Tivoli Access Manager for e-business is usually a good fit for Linux on z, but it sounds like you never got there because of the TSM project woes. Another rule of thumb: in no way is Linux a substitute or replacement for z/OS. It frequently complements z/OS, but it's very, very hard to compete against z/OS for performance efficiency, capabilities, and qualities of service. One possible exception is IBI Web Focus (a reporting tool) which seems to be a bit of a problem child for some under z/OS, as Robert Nix alluded to. WebSphere Application Server is interesting. In the post-zAAP world with WAS V5 or V6 I think z/OS is awfully nice. WAS is no longer a reason to create your first mainframe Linux installation. There are other reasons instead. WebSphere Commerce Server, for example. Or SAP. - - - - - Timothy F. Sipples Consulting Enterprise Software Architect, z9/zSeries IBM Japan, Ltd. E-Mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
Anton wrote: Does this type of talk work for you in Japan these days because I visited the University of Tokyo in 1985 and I was impressed with the way they did their research and the way they understood the technical claims from the American companies. Japan is one of the most successful markets for mainframe Linux. The largest mainframe Linux installation in the world (to my knowledge) happens to be in Japan. If Japanese research impresses you, perhaps mainframe Linux should as well. Re: The system programmer job loss fears, with all due respect, what?!?! Where have I said that system programmers are not required? I'd much rather have more mainframe people employed, quite honestly. Maybe my hint wasn't big enough. Does anybody seriously dispute that Linux is popular? That Linux is growing? Including the mainframe? What I am suggesting is the following: 1. More people here should add Linux to their knowledge base -- ideally leading efforts in your shops to implement Linux for certain projects. Ostrich strategies do not work, IMHO. 2. Many of you are already learning Linux (in effect) and just don't know it. USS skills are quite transferable. (And you need at least a little bit of USS knowledge to be a competent z/OS system programmer, in all candor.) 3. Difficulty implementing Linux is exaggerated by many in this forum, truly. It's not zero, but it's also not the Apollo Space Program nor the Manhattan Project. [ Speaking for myself, if that wasn't obvious. :-) ] - - - - - Timothy F. Sipples Consulting Enterprise Software Architect, z9/zSeries IBM Japan, Ltd. E-Mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
Difficulty implementing Linux is exaggerated by many in this forum, truly. It's not zero, but it's also not the Apollo Space Program nor the Manhattan Project. I think, after talking to a few, that the exaggeration is coming from IBM. It's not just the implementation. It's also the care and feeding. AND, the (hidden) costs of z/VM. And, its care and feeding. - -teD 300,000 Kilometres per Second Not only is it a good idea! It's the LAW!!! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
Why are mainframe people so reluctant to change ? I know cases where mainframe people refused to implement new applications, so they were implemented on different platform, old applications were removed as well as mainframe. I witnessed this situation personaly at one customer before I joined IBM. Now when I work for IBM in mainframe market I know the fights we have to fight. Mainframe platform and people are perceived as least flexible. I repeat - we are perceived as least flexible. If you come with an idea of new application or solution, people from other platform see no problem, mainframe people show what are pitfalls. I don't say it is bad, I know it is because of their responsibility and experience to see the problems way ahead, but unfortunately today's market doesn't work this way. Everybody wants everything as fast as possible, problems are solved later, during production. Yes, it is totaly wrong, but it is reality. Linux is growing, it is a fact. Mainframe won several awards for being the best hw platform for Linux. Why do we see so many posts about 'our mainframe will be removed' ? I don't say all, but part of them is just because new applications were developed elsewhere. Here we remove one small 'unimportant' application and give it to unix, after two years it is one of core applications, needing new machines etc. Why not to develop it under Linux on mainframe ? And of course well known problem - new managers are taught UNIX and Linux, not JCL. Yes, even z/VM has a learning curve. But here you pinpoint it as a hidden cost, on different platforms (mainly windows) they are not counted as costs ? Everybody knows other OS out of the box ? Yes, Timothy is right, installing z/VM *is* easy. Also basic config is easy. And yes, production config and maintenance needs more knowledge, as others mention. It is a difference to install something and to tune it. As everywhere. Unfortunately, people from other platforms don't care, defaults are too often 'good enough'. But refusing everything only because it is different, is wrong. Don't take Linux on mainframe as competition, it is not meant so. z/OS (z/VSE etc) is 'main' OS on mainframe, but if you can run application server on Linux on z or on unix, why not to choose Linux on z ? DB2 on z/OS, WAS on Linux on z is a great combination. Less footprint, less cables etc(insert all marketing stuff, but part of it is true, even more true if you grow images). z/VM is not needed for 1-2 LPARs, but it helps a lot with monitoring, managing, backup etc. You can look at IBM pages for references. Flame me, you have full right to do so, compared to most of you I am still freshmen in wonderful mainframe world. Marian Gasparovic IBM Slovakia (speaking for myself of course, disclaimers, legal notices etc are all applicable) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting
On Tue, 2006-06-06 at 10:00 +0200, Marian Gasparovic wrote: Why are mainframe people so reluctant to change ? ... Linux is growing, it is a fact. Mainframe won several awards for being the best hw platform for Linux. Why do we see so many posts about 'our mainframe will be removed' ? We installed Linux (thanks to Marist) on a 9672 well before IBM even got Linux into their collective heads. *Before* the skunkworks efforts escaped from the Boeblingen labs - and on a machine that IBMs efforts would not support. Customers telling us they do not want Linux is *their* decision. They pay the bucks, they call the game. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
With the dumbing down of the MVS Sysprog, I welcome anything that still requires some technical competence to implement. Otherwisewell you know the rest. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Monday, June 05, 2006 8:00 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?) Difficulty implementing Linux is exaggerated by many in this forum, truly. It's not zero, but it's also not the Apollo Space Program nor the Manhattan Project. I think, after talking to a few, that the exaggeration is coming from IBM. It's not just the implementation. It's also the care and feeding. AND, the (hidden) costs of z/VM. And, its care and feeding. - -teD 300,000 Kilometres per Second Not only is it a good idea! It's the LAW!!! LEGAL DISCLAIMER The information transmitted is intended solely for the individual 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 action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. Seeing Beyond Money is a service mark of SunTrust Banks, Inc. [ST:XCL] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting
Sure. Any company can choose what to run using whatever criteria for their choice. If they buy icecream machine for production, it is their choice and their money. I don't talk to customers here, I talk to fellow technical people. There are several thousand people on this list, so we can have several thousand opinions what works well and what doesn't. I just try to point out what I see around. I ran Marist distribution too, on MP2000 several months before IBM announced it. Image written to tape from z/OS, lot of fun with broken RPM etc :) Now it is part of my official work. On 6/6/06, Shane [EMAIL PROTECTED] wrote: On Tue, 2006-06-06 at 10:00 +0200, Marian Gasparovic wrote: Why are mainframe people so reluctant to change ? ... Linux is growing, it is a fact. Mainframe won several awards for being the best hw platform for Linux. Why do we see so many posts about 'our mainframe will be removed' ? We installed Linux (thanks to Marist) on a 9672 well before IBM even got Linux into their collective heads. *Before* the skunkworks efforts escaped from the Boeblingen labs - and on a machine that IBMs efforts would not support. Customers telling us they do not want Linux is *their* decision. They pay the bucks, they call the game. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting
Why are mainframe people so reluctant to change? Because our management sees the change as too expensive. Cost of z/VM. Cost of IFL's. Cost of one General Purpose CP. Cost of z/VM training. The only constant cost is that of learning LINUX. I haven't been able to convince my management, yet. And, IBM isn't helping! - -teD 300,000 Kilometres per Second Not only is it a good idea! It's the LAW!!! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
McKown, John wrote: snip Does anybody seriously dispute that Linux is popular? That Linux is growing? Including the mainframe? What I am suggesting is the following: 1. More people here should add Linux to their knowledge base -- ideally leading efforts in your shops to implement Linux for certain projects. Ostrich strategies do not work, IMHO. I've been trying here, but the Windows people (at least in the past) have been driving the boat. The new CIO is more platform agnostic, but as a voice crying in the wilderness, I'm fairly ineffective in getting anyone interested. 2. Many of you are already learning Linux (in effect) and just don't know it. USS skills are quite transferable. (And you need at least a little bit of USS knowledge to be a competent z/OS system programmer, in all candor.) My was the reverse. I have been using Linux/Intel at home for quite a while (finally 99.9% off of Windows!). z/OS UNIX was very easy to pick up. The other z/OS sysprogs here basically don't like UNIX. I may need to suggest a minor class on UNIX concepts for them (even invite interested programmers - what a concept!) Well, I know you're not going to offer one of our classes, but perhaps they would be intrigued by my paper on hosting a web site on z/OS, just as a teaser to get them hooked. Look at: http://www.trainersfriend.com/General_content/Book_site.htm and scroll down to the next-to-last entry in the first table. Kind regards, -Steve Comstock -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Steve Comstock Sent: Tuesday, June 06, 2006 8:30 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?) snip Well, I know you're not going to offer one of our classes, but perhaps they would be intrigued by my paper on hosting a web site on z/OS, just as a teaser to get them hooked. Look at: http://www.trainersfriend.com/General_content/Book_site.htm and scroll down to the next-to-last entry in the first table. Kind regards, -Steve Comstock Thanks. I already have a web site on our z/OS system. I have even written a web based application to do our standard RACF stuff such as creating a new userid, deleteing an existing id, resume an id, revoke an id, etc. It uses REXX CGI programs. I am looking at Java (JZOS) right now. Not too bad, but could use a zAAP. But even presenting it to my team gets a yawn. What good is it? There is an entire 'nother thread on this. I can imagine some really NICE things if we did some CICS/Java for our XML and web based stuff. Just plain no interest. And, to be honest, we cannot integrate it into our current Endevor change environment (as best as I can tell). I am only one person, with very poor sales skills. And I have not been able to present a fool proof plan of how to implement any of this so that it would be usable out of the box and completely integrated into our current development methodology. I.e. develop Java using ISPF (in PDS libraries), then submit batch jobs to compile it into yet another PDS. Remember, no liking around here for UNIX stuff. Just to be honest, the programmers have a point. They are swamped (as are most) just trying to keep the boat afloat. They don't usually have time to do fancy scrollwork on the stair rails while the boat sinks. -- 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 IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
Marian Gasparovic wrote: Why are mainframe people so reluctant to change ? I know cases where mainframe people refused to implement new applications, so they were implemented on different platform, old applications were removed as well as mainframe. I witnessed this situation personaly at one customer before I joined IBM. Now when I work for IBM in mainframe market I know the fights we have to fight. Mainframe platform and people are perceived as least flexible. I repeat - we are perceived as least flexible. [...] Fully agreed. Mainframe specialists I met are most conservative folks I know. How many of us never used USS shell, how many still prefer IOCP coding over HCD, how many still use NOEGN, haven't migrated to SMS, etc. From the other hand: IBM pushes customers to use Linux on z/Series, no doubt. Otherwise IFL would cost the same as general CP. It's even funny to observe IBM conferences in Poland: most speaker talk about Linux, zIIP, etc. while majority of customers listening it use 'the most legacy' applications on z/OS (or OS/390), CICS, VSAM, Adabas, sometimes DB2. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
This new thread started after I wrote that Timothy tends to oversimplify things. Based on my experience here with a zLinux project and some (I admit now outdated) experience elsewhere, I am sticking to my guns on that. Without getting into too much detail.. there were two projects (POCs) going on. One was related to moving TSM off of z/OS to run on zLinux under z/VM and the other was moving TAMe from AIX (I think.. it could have been Wintel). I did not work on the projects myself, but one of my team members did pretty much exclusively for a year. BTW, there was a part time consultant with z/VM and Linux expertise that was thrown in by whomever (IBM?) as part of the POC. Although my team member was always telling me he didn't get much support from him. As others have suggested, z/VM installation customization was probably not a big deal. But I can see long term support being a little more of an issue. Things like applying / rolling out maintenance, backup / recovery, etc. However, the TSM / Linux part was a big deal. There were constant issues with driver levels vs. kernel levels, re-installs, trouble obtaining the proper levels, and issues with some third party software that was involved in interfacing to STK tape drives in a 9310 SILO. This of course was on top of the learning curve issues of an unfamiliar environment to the zOS sysprog working on the project (he was working with one of the VTAM sysprogs who had some VM and unix experience). This project was eventually canned. The TAMe POC never really got off the ground to begin with. 18 months after the start I'm not even sure where we are now. z/VM and zLinux still aren't dead yet. There is just nothing production running on it at the moment. I'm pretty sure they are still looking at other opportunities and perhaps even testing WAS on zLinux as I write. I'm not saying that our experience is typical. Part of the problem was lack of solid commitment by management with these projects and getting the resources needed. All I am saying is what I said to begin with - I think Timothy oversimplified how easy it is to get an application running on Linux or Linux under z/VM. Remember, these were only POCs, which to me is still quite a bit away from an enterprise ready production application. So, any others care to tell about their Linux on Z POCs or implementations? Did your projects stay on schedule and run smoothly? Did you have to hire new people or were the existing zOS or *nix people in your shop able to handle it? How much help did you need / get from IBM or other consultants? Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group mailto: [EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
I agree. I began to learn Unix with UTS, and the experience made it easier to pick up Unix System Services. That, in turn made it easier when I installed Linux on three of our computers at home. Certainly, Linux is a huge improvement over Windows. Even my kids use it. Linux, like Unix, is in a different league than z/OS, but that is no reason to dismiss it outright. On Tue, 6 Jun 2006 15:37:00 +0900, Timothy Sipples [EMAIL PROTECTED] wrote: Anton wrote: Does this type of talk work for you in Japan these days because I visited the University of Tokyo in 1985 and I was impressed with the way they did their research and the way they understood the technical claims from the American companies. snip! Does anybody seriously dispute that Linux is popular? That Linux is growing? Including the mainframe? What I am suggesting is the following: 1. More people here should add Linux to their knowledge base -- ideally leading efforts in your shops to implement Linux for certain projects. Ostrich strategies do not work, IMHO. 2. Many of you are already learning Linux (in effect) and just don't know it. USS skills are quite transferable. (And you need at least a little bit of USS knowledge to be a competent z/OS system programmer, in all candor.) 3. Difficulty implementing Linux is exaggerated by many in this forum, truly. It's not zero, but it's also not the Apollo Space Program nor the Manhattan Project. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
Marian Gasparovic wrote: Why are mainframe people so reluctant to change ? I know cases where mainframe people refused to implement new applications, so they were implemented on different platform, old applications were removed as well as mainframe. I witnessed this situation personaly at one customer before I joined IBM. Now when I work for IBM in mainframe market I know the fights we have to fight. Mainframe platform and people are perceived as least flexible. I repeat - we are perceived as least flexible. very Boyd and ooda-loop oriented http://www.garlic.com/~lynn/subboyd.html#boyd http://www.garlic.com/~lynn/subboyd.html#boyd2 I sponsored Boyd a number of times at internal corporate seminars in the early 80s (it started out being slightly less than full day, but as Boyd evolved some of his talks it began harder and harder to get it all crammed into a single day) some number of people would go in thinking it would be a very non-civilian oriented talk and were surprised to find how applicable it was to all sorts of business endeavors (it has since become much more acceptable to reference boyd's ooda-loop concepts in business settings, especially where rapid adaptation and agility to deal with changing circumstances is required). having projected in the late 80s that things were headed into the red and things would have to change ... in the early 90s, we would periodically visit places like somers for discussions on the subject. nobody would really disagree that things were going to have to change ... but you go back a couple months later and found nothing was changing. one possible observation was that there were a large number of senior people with possibly 25-30 years experience and their perceived value was based experience in on a long standing, relatively consistent paradigm. any significant changes in the paradigm would significantly reduce the perceived value of these individuals' experience. there appeared to be a large contingent of people that didn't disagree that things were going to have to change ... but they were doing everything possible to forestall it until at least after they, personally had retired (and then it would be somebody else's problem) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
So, any others care to tell about their Linux on Z POCs or implementations? Did your projects stay on schedule and run smoothly? Did you have to hire new people or were the existing zOS or *nix people in your shop able to handle it? How much help did you need / get from IBM or other consultants? I'll tell: We have 4 lpars running z/VM 5.1 and 5.2. on two footprints. Memory wise they are our largest LPARs (about 3 times as big as the z/OS ones). Using shared IFLs. Two of the lpars are production, two are development/ test. Each LPAR has between 20 and 30 Linux servers running. We grew our own z/VM support (two people who worked with VM eons ago). The Linux side of things is handled by the group that does the *IX support. No consultants that I am aware of but possibly IBM help. I think there were some turf battles initially, but management is solidly behind the zSeries and it is working well for us. Alan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS ?)
We did a POC using zVM 4.4 and both RedHat and SuSE images, and ran that way on one IFL for close to a year (things move slowly here). We had just retired zVM and OfficeVision shortly after this started, so we had two zVM people with fairly extensive experience. We currently have two LPARs in two separate CECs, with two IFLs in each, and 10Gig of memory in each, running zVM 5.1 and about 50 Linux guests. All the significant guests are SuSE SLES. We run both version 8 and 9, depending on what the application dictates. I've been rolled from the Mainframe support group into the Unix support group, and there are now two of us doing Linux support, both for the mainframe and for Intel and Blade servers. (The Linux person is learning zVM much faster than I'm learning Linux.) The two main projects we are working on in the mainframe Linux are Tivoli support, along with Tivoli's DB2 servers, and IBI I-Way servers. Our main objective was to remove usage from our zOS LPARs to extend the life of the system (I-Way accounted for 100 MIPS in zOS, and moving it to zLinux releases those resources). For what we've been working in, Linux is Linux, and virtual hardware is much easier to come by than real hardware. Where an Intel or Blade project has a several week lead-time before the applications people even get to touch the box, a zLinux system can be built and handed over in about a day. And, we're working on cutting that time down, via cloning instead of full Linux installs. Interesting bits and pieces: We're IPLing both LPARs from the same zVM sysres volume. We're working on converting everything to vSwitch, and the two vSwitches are attached to the same subnet and external switch, so we should be able to move a guest from one LPAR to the other just by bringing it down on one LPAR and then autologging it on the other (untested as yet). We're interested in Hipersockets to talk to the zOS DB2, but we haven't been able to sell our DB2 Connect support people on the idea as yet (They support DB2 Connect server on Windows, and aren't interested in supporting it on another platform.) We're looking at the cloning model described in the Virtualization Cookbook Redbook. And our Oracle people are interested in kicking the tires, so we may have an Oracle in a zLinux image shortly. That's about all I can think of that might be of interest to anyone here. If you don't have Linux in your shop... This probably isn't for you. Don't do it just for the sake of doing it. If you have a lot of Linux already, then this is something to think about, as it can cut down on your floor space and resource consumption. If you're just getting interested in Linux, do Intel first, and keep this in the back of your mind as an option for later on. Just to apply scale, for comparison to your own shop: We run two z990's running zOS and zVM in two separate data centers. We also have about 300 Unix servers supporting various tasks, and about 1,400 Windows servers. We have somewhere around 28,000 Windows desktops here on this campus; I'm not sure of the numbers at the other two sites. Mayo here in Rochester employs about 31,000 people. -- Robert P. Nix Mayo Foundation RO-OC-1-13 200 First Street SW 507-284-0844Rochester, MN 55905 - In theory, theory and practice are the same, but in practice, theory and practice are different. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Alan C. Field Sent: Tuesday, June 06, 2006 2:21 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?) So, any others care to tell about their Linux on Z POCs or implementations? Did your projects stay on schedule and run smoothly? Did you have to hire new people or were the existing zOS or *nix people in your shop able to handle it? How much help did you need / get from IBM or other consultants? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting
On Tue, 6 Jun 2006 20:48:04 +1000, Shane [EMAIL PROTECTED] wrote: -snip- We installed Linux (thanks to Marist) on a 9672 well before IBM even got Linux into their collective heads. *Before* the skunkworks efforts escaped from the Boeblingen labs - and on a machine that IBMs efforts would not support. I think you've got your history a little mixed up. The Marist file system did not become available until after the IBM developers published their patches in December of 1999. Indeed, the Marist file system was really a tar dump of an IBM Linux/390 system. Mark Post -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting
On Tue, 6 Jun 2006 00:00:00 GMT, Ted MacNEIL [EMAIL PROTECTED] wrote: Why are mainframe people so reluctant to change? Because our management sees the change as too expensive. Cost of z/VM. Cost of IFL's. Cost of one General Purpose CP. Cost of z/VM training. Why in the world would you need to buy a standard CP on top of an IFL? You can't use them together in the same LPAR. And, lets be clear about the cost of z/VM. It's a one time charge of $2,250 per value unit (God I hate IBM pricing lingo/strategies), with 10 value units per IFL. You'll actually wind up paying more, starting in year two, for your Linux license, unless you go with one of the non-commercial versions. Now, if you want to gripe about _that_, then I'm right there with you. Mark Post -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
In [EMAIL PROTECTED], on 06/05/2006 at 04:05 PM, Anton Britz [EMAIL PROTECTED] said: a. 1700 installations Pay close attention. That number refers to Linux on zSeries, not to the total Linux usage. d. Not in the USA And you know that how? How do you account for the rise in browsers claiming to be running under Linux? -- 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
In [EMAIL PROTECTED], on 06/06/2006 at 10:00 AM, Marian Gasparovic [EMAIL PROTECTED] said: Flame me, I refuse! I certainly have no objection to adding another platform to my repertoire. -- 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting
Why in the world would you need to buy a standard CP on top of an IFL? You can't use them together in the same LPAR. What does z/VM run on? Air? - -teD 300,000 Kilometres per Second Not only is it a good idea! It's the LAW!!! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting
z/VM needs a General Purpose CP. LINUX runs on the IFL. Or, so I've been told. The last time at the IBM z9 roadshow. - -teD 300,000 Kilometres per Second Not only is it a good idea! It's the LAW!!! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
John, I can relate to your Endevor problems... I worked with client to get this set up, and it just doesn't support HFS file systems well enough to be usable for Java source control. In the end, they decided to check in a distribution tar file into Endevor and then wrote JCL/scripts to allow Endevor to handle the deployment/promotions. The source is maintained in either CVS or PVCS and builds of the tar distributions were done via a Ant script on a Unix system, which was kicked off by a MVS job. As far as development tools, I would encourage you to look at using the Eclipse IDE for z/OS Java development. We have put up some documentation and examples (from our SHARE presentations) on how to do this on our web sites: http://jzos.com/docs/eclipseSetup.html http://dovetail.com/downloads.html (see the Batch XML Sample project download) With Eclipse setup properly, you can code/compile your Java in a fantastic (and free) IDE, and then use ANT to one-click deploy the code to z/OS via FTP. Regards, Kirk McKown, John wrote: Thanks. I already have a web site on our z/OS system. I have even written a web based application to do our standard RACF stuff such as creating a new userid, deleteing an existing id, resume an id, revoke an id, etc. It uses REXX CGI programs. I am looking at Java (JZOS) right now. Not too bad, but could use a zAAP. But even presenting it to my team gets a yawn. What good is it? There is an entire 'nother thread on this. I can imagine some really NICE things if we did some CICS/Java for our XML and web based stuff. Just plain no interest. And, to be honest, we cannot integrate it into our current Endevor change environment (as best as I can tell). I am only one person, with very poor sales skills. And I have not been able to present a fool proof plan of how to implement any of this so that it would be usable out of the box and completely integrated into our current development methodology. I.e. develop Java using ISPF (in PDS libraries), then submit batch jobs to compile it into yet another PDS. Remember, no liking around here for UNIX stuff. Just to be honest, the programmers have a point. They are swamped (as are most) just trying to keep the boat afloat. They don't usually have time to do fancy scrollwork on the stair rails while the boat sinks. --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting
On Tue, 6 Jun 2006 00:00:00 GMT, Ted MacNEIL [EMAIL PROTECTED] wrote: Why in the world would you need to buy a standard CP on top of an IFL? You can't use them together in the same LPAR. What does z/VM run on? Air? No, it runs on the IFL. z/VM is the only IBM-provided OS that will run on either an IFL or a standard CP. If you want to run Linux guests, z/VM has to run on an IFL. As I said, you cannot mix the two processor types within a single LPAR. Mark Post -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting
On Tue, 6 Jun 2006 00:00:00 GMT, Ted MacNEIL [EMAIL PROTECTED] wrote: z/VM needs a General Purpose CP. LINUX runs on the IFL. Or, so I've been told. The last time at the IBM z9 roadshow. If you would send me the name (or names) of whoever told you that (off list), I know several people in IBM that would love to set them straight. Heck, I'll do it myself. No one needs people spreading nonsense like that around. Mark Post -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting
Who ever told you that mis-spoke, or you misunderstood. z/VM and Linux run on the SAME CP. It can be a General Purpose CP, or it can be an IFL CP. But, regardless, z/VM and Linux run on the same engine. If the LPAR has more than one engine defined, then both z/VM and Linux will run on all the engines defined to that LPAR. An LPAR can only have one KIND of engine defined to it. Brian On Tue, 6 Jun 2006 00:00:00 GMT, Ted MacNEIL [EMAIL PROTECTED] wrote: z/VM needs a General Purpose CP. LINUX runs on the IFL. Or, so I've been told. The last time at the IBM z9 roadshow. - -teD -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting
z/VM is the only IBM-provided OS that will run on either an IFL or a standard CP Show me the documentation. I have never seen/heard this, and I have been doing everything I can do to steer my management towards LINUX on z! - -teD 300,000 Kilometres per Second Not only is it a good idea! It's the LAW!!! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting
Brian, That may be true for IFL engines, but, of necessity, zIIPs and zAAPs must be defined to an LPAR with general purpose CPs. Right? Brian Peterson wrote: An LPAR can only have one KIND of engine defined to it. Brian On Tue, 6 Jun 2006 00:00:00 GMT, Ted MacNEIL [EMAIL PROTECTED] wrote: z/VM needs a General Purpose CP. LINUX runs on the IFL. Or, so I've been told. The last time at the IBM z9 roadshow. - -teD -- | Jim Phoenix | Voice: (310) 338-0400 x316 | | Senior Software Developer| Fax: (310) 338-0801| | Phoenix Software International | Alt fax: (310) 337-2685| | 5200 W. Century Blvd., Suite 800 | [EMAIL PROTECTED] | | Los Angeles, CA 90045| http://www.phoenixsoftware.com | Opinions expressed by this individual are not necessarily those of the Company. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting
An LPAR can only have one KIND of engine defined to it Actually, that's not true. You can have zAAPs defined to the same LPAR as GP's. Whereas my mistake was I though at least 1 GP was required for the zVM/zLINUX combo. - -teD 300,000 Kilometres per Second Not only is it a good idea! It's the LAW!!! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting
I don't have VM manuals handy but I can assure you we have been running z/VM and Linuxen on a single IFL on a 2066 for almost three years. Bob Ted MacNEIL wrote: z/VM is the only IBM-provided OS that will run on either an IFL or a standard CP Show me the documentation. I have never seen/heard this, and I have been doing everything I can do to steer my management towards LINUX on z! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting
I don't have VM manuals handy but I can assure you we have been running z/VM and Linuxen on a single IFL on a 2066 for almost three years. That's a good thing! Maybe I've gone down the wrong path, because I thought you needed one of each, and I couldn't find any doc to show otherwise. But, there are still (minimised by IBM Marketting) other costs. After, the roadshow on May 9, I got the standard call from IBM. They asked what they could do to help, offered their contact information and a whole load of consultation. I said send it along! I'm still waiting for their information. They DID NOT follow up. They left me out in the cold. We have over 100 UNIX/LINUX servers. The LINUX on z solution makes sense. But, only with help from IBM! I'm here! Where are they? - -teD 300,000 Kilometres per Second Not only is it a good idea! It's the LAW!!! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting
On Tue, 6 Jun 2006 00:00:00 GMT, Ted MacNEIL [EMAIL PROTECTED] wrote: We have over 100 UNIX/LINUX servers. The LINUX on z solution makes sense. But, only with help from IBM! I'm sorry, but IBM isn't the only source of information for this type of work. And as you've seen, IBM employees can be a source of mis-information. (This isn't the first time I've run into this. I don't blame IBM as a company. It's just too big for everyone to get the information they need to appropriately advice people. I blame the individual IBM employees who aren't willing to say I don't know but I'll find out for you.) If you want to do this, there are a number of other choices available. One of them is subscribing to the linux-390 mailing list at http://www.marist.edu/htbin/wlvindex?linux-390, and asking questions there. A whole range of people hang out there, with all the expertise you'll ever need to figure out how to effectively run Linux on the mainframe. There are even people there who can show you how to get copies of the various Linux distributions at no cost (such as myself and z/Journal). Reading through the various SHARE proceedings will show you just how much information is available. If you're able to attend SHARE in Baltimore, you'll be floored by the number of hands-on labs you can attend, including ones that let you install Linux on the mainframe, as well as other sessions. Linux on the mainframe didn't originate with IBM (there was an Open Source project working towards the same end before IBM published their patches). There's no reason why people should think IBM is the only organization that can advise them on how to get it up and running well. Mark Post -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting
On Tue, 6 Jun 2006 00:00:00 GMT, Ted MacNEIL [EMAIL PROTECTED] wrote: z/VM is the only IBM-provided OS that will run on either an IFL or a standard CP Show me the documentation. I have never seen/heard this, and I have been doing everything I can do to steer my management towards LINUX on z! Try: http://www-03.ibm.com/servers/eserver/zseries/os/linux/ifl.html http://www-03.ibm.com/servers/eserver/zseries/faq/zvm_faq.html#3 http://www-306.ibm.com/software/success/cssdb.nsf/CS/DNSD-65WC72?OpenDocumentSite=eserverzseries Or just try asking on the linux-390 mailing list, although the first link should be enough to satisfy you. One other thing for people to consider: even on machines that have standard CPs running at sub-capacity, IFL processors _always_ run at full-rated speed, without increasing your IBM or ISV software charges for the workload running on the standard CPs. (See the first link listed for documentation of this.) Mark Post -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting
On Jun 6, 2006, at 10:42 PM, Mark Post wrote: SNIP One other thing for people to consider: even on machines that have standard CPs running at sub-capacity, IFL processors _always_ run at full-rated speed, without increasing your IBM or ISV software charges for the workload running on the standard CPs. (See the first link listed for documentation of this.) Just out of curiosity how are vendors charging for software on z/linux? Mark Post -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting
Usualy per engine. There is no subcapacity for specialty engines, they always run on the full speed. Marian Gasparovic IBM Slovakia On 6/7/06, Ed Gould [EMAIL PROTECTED] wrote: On Jun 6, 2006, at 10:42 PM, Mark Post wrote: SNIP One other thing for people to consider: even on machines that have standard CPs running at sub-capacity, IFL processors _always_ run at full-rated speed, without increasing your IBM or ISV software charges for the workload running on the standard CPs. (See the first link listed for documentation of this.) Just out of curiosity how are vendors charging for software on z/linux? Mark Post -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting
I think Brian ment only CPs versus IFLs. So you both are right. You can have any number of IFLs regardless of the number of regular CPs (there is an exeption, z9 BC model R has to have at least one regular CP, marketing/pricing/whatever requirement). Besides this model, you can have machine IFL only (there are customers who use this path). Of course, no z/OS on IFL only machine. And you cannot mix CPs and IFLs in one LPAR. zIIPs and zAAPs are different story. You cannot have more zIIPs or zAAPs then regular CPs in your machine. So if you have 3 CPs, you can have max 3 zAAPs and max 3 zIIPs. However, on LPAR level you can have more zIIPs or zAAPs then CPs (if it makes sense) but there must be at least one CP, otherwise you have no engine to IPL. Marian Gasparovic IBM Slovakia On 6/7/06, Jim Phoenix [EMAIL PROTECTED] wrote: Brian, That may be true for IFL engines, but, of necessity, zIIPs and zAAPs must be defined to an LPAR with general purpose CPs. Right? Brian Peterson wrote: An LPAR can only have one KIND of engine defined to it. Brian On Tue, 6 Jun 2006 00:00:00 GMT, Ted MacNEIL [EMAIL PROTECTED] wrote: z/VM needs a General Purpose CP. LINUX runs on the IFL. Or, so I've been told. The last time at the IBM z9 roadshow. - -teD -- | Jim Phoenix | Voice: (310) 338-0400 x316 | | Senior Software Developer| Fax: (310) 338-0801| | Phoenix Software International | Alt fax: (310) 337-2685| | 5200 W. Century Blvd., Suite 800 | [EMAIL PROTECTED] | | Los Angeles, CA 90045| http://www.phoenixsoftware.com | Opinions expressed by this individual are not necessarily those of the Company. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting
There's no reason why people should think IBM is the only organization that can advise them on how to get it up and running well. I agree, but our circumstances require IBM. We're out-sourced, and management is not very technical. I'm the only techie on our side. - -teD 300,000 Kilometres per Second Not only is it a good idea! It's the LAW!!! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
So please don't say the install is easy as it is only about a 1/3 (1/4?) of the job. You are making a broad statement And, doing the whole thing a disservice. If IBM keeps claiming complex tasks are simple, when they are not, then how's it going to look when the customer finds out the truth? So, please tell us the real story (and costs) up front, so that we (and you) don't like idiots when it fails to meet expectations. If it is truly so simple, show us how. But, not with high consultation fees (another disservice)! - -teD 300,000 Kilometres per Second Not only is it a good idea! It's the LAW!!! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
Ed Gould wrote: Timothy: I profess I have never installed VM (unless you count once 30 years ago). That being said, its never the d/l'ing that is the difficult part .. its always the post downloading that gets to be a PITA and always requires some (some say quite a bit) expertise. The VM system I helped set up was on a 4331 (w/3310's IIRC) was not a breeze by any stretch. IIRC it was a IPO (but I could be remembering incorrectly). But to get back to MVS the same thing can be said with a SERVPAC. I won't talk too much about servpac's as I have already indicated my dislike for them on here in the past. The d/l is almost never hard the customization is always the gotcha IMO. So please don't say the install is easy as it is only about a 1/3 (1/4?) of the job. You are making a broad statement, IMO, and putting a broad brush on the effort and thereby making it seem like any idiot can do so. This seems to be an effort by IBM (starting in the 1990's) that sysprogs are no longer needed. IBM (even in the SERVPAC classes) discussed that they are no longer needed that any joe blow can do a servpac. I am not picking on LE but if you take the defaults that LE put out, a lot of your batch programs will not work correctly. The same can be said for other optional customization items that need careful monitoring at customization times. Most likely an untrained sysprog would take all the defaults. I was training a sysprog at the time of the servpac and I gave him the chore to determine which customization jobs were needed and he didn't have a clue. Like I said I don't wish to pick on ONE component but LE is a good target (sigh). IBM (and you) seems to be sending out signals that we sysprogs are no longer needed. I am lucky to be in retirement and not have to put up with this BS from IBM anymore. we did a lot of work for vm originally on 138/148 besides ecps http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist there was a lot of investigation trying to make it almost as transparently part of the machine as current day LPAR. ... basically pre-installed with lots of useability stuff on every machine that went out the door however this was back in the days when corporate still thot they had a chance to kill vm ... and while they allowed endicott to ship ecps support, the idea that every machine that went out the door had it pre-installed was blocked (along with the lots of the usability stuff) POK had the vm development group in burlington mall shutdown and all the people were told they had to move to POK to work on the (internal only) VMTOOL supporting mvs/xa development (justification was that mvs/xa development couldn't meet schedule unless they had all the vm developers working on it also) ... and there would be no more vm products for customers. endicott managed to pickup some of the vm370 mission and rescue some of the people from having to move to POK (although quite a few stayed in the boston area and went to places like DEC to work on what was to became VMS). however, this (138/148) was the leading edge of some companies starting to order the boxes in large numbers. this really accelerated in the 4331/4341 time-frame where it wasn't unusual to have customers ordering the boxes in a couple hundred at a time. old reference to one such situation http://www.garlic.com/~lynn/2001m.html#15 departmental servers the issue started becoming if the number of machines increase by two orders of magnitude (100 times) ... where does the two orders of magnitude increase in the number of support people come from? this period also saw a big explosion in the number of vm/4341s on the internal network http://www.garlic.com/~lynn/subnetwork.html#internal which was nearly almost all vm machines already. at the time the arpanet cutover to internetworking protocol on 1/1/83, there was possibly 100 arpanet nodes with somewhere between 100 and 255 connected system hosts http://www.garlic.com/~lynn/subnetwork.html#internet however the internal network was almost 1000 nodes by that time ... almost all vm (and non-sna) machines. a recent thread http://www.garlic.com/~lynn/2006k.html#40 Arpa address http://www.garlic.com/~lynn/2006k.html#42 Arpa address http://www.garlic.com/~lynn/2006k.html#43 Arpa address vax was also selling into that same mid-range market (as 4331 and 4341). there was some study that 4341 was better price/performance and a claim that something like 11,000 vax sales should have been 4341s ... recent post mentioning the subject: http://www.garlic.com/~lynn/2006l.html#17 virtual memory however, in that period there was a SHARE study/report that found that a lot of customers were buying vax (instead of vm/4341s) because of much less resources/skills were needed to install, support and maintain the systems (although overall 4331/4341 did still sell more total than vax, in part because of large customers ordering them a couple hundred
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
Linux is extremely popular at universities and colleges worldwide. ? a. 1700 installations b. Gartner says... Have you read all the BS that Gartner publishes ? Please come back James Martin c. Extremely popular ? Where .. in the libraries or in the Game Club d. Not in the USA Does this type of talk work for you in Japan these days because I visited the University of Tokyo in 1985 and I was impressed with the way they did their research and the way they understood the technical claims from the American companies. Anton -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
I saw some clients up here demonstrate an initial interest after the first 'sales pitch'. Once it dawned on them that installing z/VM to host linux wasn't quite the same as installing windoze the interest waned One client even mentioned running z/OS under z/VM until 'the penny dropped' and he realized a) he had no z/VM expertise on-site and b) that no reasonable level of z/VM support was available in-country. Jim S -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Shane Sent: 03 June 2006 18:39 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?) On Sat, 2006-06-03 at 07:23 +0900, Timothy Sipples wrote: Mark Zelden writes: No brainer? How about the staff, time, learning curve, etc. to support an operating system and environment that is new to the shop? Three points: ... Three more points: I'm with Mark. My customers say z/Linux isn't on the horizon. In fact most of them say mainframe is not in their future. Those that are (planning) getting off the mainframe are talking M$oft - *NOT* linux; on any platform. They *will not* consider a conversion to Linux. No training, no wasted investment, no interest. Period. Having techos (me included) dicking around with Linux on PCs counts for zero. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
Timothy Sipples wrote: [...] FWIW, I'm typing this e-mail from my Linux PC. I installed it. I even hacked some driver source code, recompiled it, and recompiled my kernel to get a special wireless card working. That's why Linux is not as popular as Windows on homeoffice computers. My secretary is not able to hack some driver source code and compile it. However she wants to send receive mails, print Word documents etc. Even IT folks prefer Windows here. I mean all the helpdesk stuff and 'one man band IT dept' in small companies. Of course there are exceptions, sometimes single Linux specialist can set up small company IT environment on Linux and everybody will be happy of that. But it is uncommon in my observation. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
In [EMAIL PROTECTED], on 06/04/2006 at 02:35 PM, james smith [EMAIL PROTECTED] said: One client even mentioned running z/OS under z/VM until 'the penny dropped' and he realized a) he had no z/VM expertise on-site and b) that no reasonable level of z/VM support was available in-country. What country? -- 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
On Sat, 2006-06-03 at 07:23 +0900, Timothy Sipples wrote: Mark Zelden writes: No brainer? How about the staff, time, learning curve, etc. to support an operating system and environment that is new to the shop? Three points: ... Three more points: I'm with Mark. My customers say z/Linux isn't on the horizon. In fact most of them say mainframe is not in their future. Those that are (planning) getting off the mainframe are talking M$oft - *NOT* linux; on any platform. They *will not* consider a conversion to Linux. No training, no wasted investment, no interest. Period. Having techos (me included) dicking around with Linux on PCs counts for zero. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
Mark Zelden writes: No brainer? How about the staff, time, learning curve, etc. to support an operating system and environment that is new to the shop? Three points: 1. If you aren't running Linux now...well, check your TiVo and your Linksys router. :-) Seriously, Linux is not exactly uncommon and getting more common. 2. Usually paid for. (Does z/OS work more or less hard when requests arrive via HiperSocket v. network? What might the response time be like for each scenario? How about security, reliability, availability, etc?) 3. That support has got to go somewhere today, even if it is familiar. Is it easier or harder to support lots of little servers? Lots of smart people think it's harder. There's also DB2 support to consider. How many calls start with the database is slow -- it's the mainframe's fault or I can't connect -- it's the mainframe's fault? :-) While there may be *nix people that could support Linux or help support it, it's probably not just Linux that would be new, it's also z/VM. Three more points: 1. z/VM is not required to run Linux. It's awfully nice but not required. For a couple or three Linux instances, you could go without. 2. Getting sufficient z/VM knowledge to run Linux is really not a big deal. IBM thought it was about 6 years ago and released a Linux-only virtual machine product, but it flopped. Nobody could tell the difference in learning curve. IBM thinks there are about 1,700 mainframe customers actually running Linux in production. That's some evidence this stuff isn't like building a fusion reactor. 3. To know z/OS these days you have to know USS. That's a skill set that works well for Linux, too. I'm not saying using Linux on z is a bad idea, but you really tend to over simplify things and look at things like a salesman, not a technician. I wish! Sadly I don't get commissions. FWIW, I'm typing this e-mail from my Linux PC. I installed it. I even hacked some driver source code, recompiled it, and recompiled my kernel to get a special wireless card working. I've also installed and IPLed Linux under z/VM, and installed and configured software products on Linux under z/VM -- for a major bank, as it happens. Yeah, it's easy. Why, even a salesman can do it. :-) Generally good choices to run on mainframe Linux (z/OS also of course great for many of these as well): - DB2 Connect - Utility servers (DHCP, DNS, NTPD, LDAP, etc.) - SAP and other data-intensive LOB applications (that can enjoy HiperSockets to DB2 z/OS, CICS, IMS, etc.) - File servers (Samba, NFS) - Certain security services (e.g. Tivoli Access Manager for e-business) - Monitoring-related software (e.g. Tivoli Enterprise Console) - Lotus Domino (and other e-mail servers) - Rational ClearCase/ClearQuest, CVS, etc. - other servers to support application development and testing - WebSphere Commerce - most integration software - simplification of lots of little databases (distributed DB2, Oracle, Informix, etc.) - reporting tools (e.g. IBI WebFocus) [ Speaking for myself...because I can't afford to pay someone else to speak for me. :-) ] - - - - - Timothy F. Sipples Consulting Enterprise Software Architect, z9/zSeries IBM Japan, Ltd. E-Mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
