Re: Resistance to Java.
Or to use the modern term political correctness. snip Orwell made this point, better than I can make it: The purpose of Newspeak was not only to provide a medium of expression for the world-view and mental habits proper to the devotees of Ingsoc, but to make all other modes of thought impossible. It was intended that when Newspeak had been adopted once and for all and Oldspeak forgotten, a heretical thought---that is a thought diverging from the principles of Ingsoc---should be literally unthinkable, at least so far as thought is dependent upon words. Its vocabulary was so constructed as to give exact and often very subtle expression to every meaning that a Party member could properly wish to express, while excluding all other meanings and also the possibility of arriving at them by indirect means. This was done partly by inventing new words but chiefly by eliminating undesirable words . . . Quite apart from the suppression of definitely heretical words, reduction of vocabulary was regarded as an end in itself, and no word that could be dispensed with was allowed to survive. Newspeak was designed not to extend but to diminish the range of thought, and this purpose was indirectly assisted by cutting the choice of words down to a minimum. (From the Ingsoc appendix to his novel, 1984) /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
edja...@phoenixsoftware.com (Ed Jaffe) writes: I've often wondered what the state of the mainframe would be today if IBM had actually done a halfway decent job developing ISPF Client/Server, mSys for Setup, and other similar GUI-based initiatives from the 1990s. re: http://www.garlic.com/~lynn/2014b.html#39 Resistance to Java a primary communication group effort fighting off distributed computing and client/server was SAA (I've periodically mentioned senior disk engineer getting talk at annual worldwide internal communication group conferencing and opening with the statement that the communication group was going to be responsible for the demise of the disk division ... among other things the disk division was seeing drop in disk sales with data fleeing the datacenter for more distributed computing friendly platforms ... and communication group veto'ing all the solutions the disk division would come up ... the communication group had strategic ownership for everything that crossed data center wall). http://en.wikipedia.org/wiki/IBM_Systems_Application_Architecture Father of SAA no relation ... and the executive put in charge of doing SAA in the early 90s ... I had worked with many years earlier on 138/148 microcode assist and would periodically drop by his office on top floor of somers and ridicule SAA. part of the issue was we had come up with 3-tier architecture ... initially written into response for large, distributed, super-secure government program ... and then out making pitches to customer executives ... and getting lots of arrows in the back (and other FUD) from the communication group. past posts mentioning 3-tier (and SAA) http://www.garlic.com/~lynn/subnetwork.html#3tier part of the issue was 3tier was all tcp/ip (and not SNA). at the same time SAA was kicked off, the communication group was also out distributing a lot of misinformation inside the corporation about how SNA could be used for the the NSFNET backbone (precursor to modern internet). old NSFNET backbone email http://www.garlic.com/~lynn/lhwemail.html#nsfnet and past posts http://www.garlic.com/~lynn/subnetwork.html#nsfnet and other misinformation that if the internal network wasn't converted to SNA, the internal network would stop working. internal network old email http://www.garlic.com/~lynn/subnetwork.html#vnet and past posts http://www.garlic.com/~lynn/subnetwork.html#internalnet -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
On Sun, 26 Jan 2014 10:57:00 -0500, Anne Lynn Wheeler wrote: (Ed Jaffe) writes: I've often wondered what the state of the mainframe would be today if IBM had actually done a halfway decent job developing ISPF Client/Server, mSys for Setup, and other similar GUI-based initiatives from the 1990s. And, please, support a portable GUI protocol such as X11 (perhaps VNC; perhaps HTTP -- is that what HoD does?) Don't require an idiosyncratic agent for every desktop OS. re: http://www.garlic.com/~lynn/2014b.html#39 Resistance to Java a primary communication group effort fighting off distributed computing and client/server was SAA ... http://en.wikipedia.org/wiki/IBM_Systems_Application_Architecture Ah! Is that what the misbegotten thing was for? To demonstrate the nonviability of distributed computing by exhibiting a nonviable distributed computing product? part of the issue was 3tier was all tcp/ip (and not SNA). at the same time SAA was kicked off, the communication group was also out distributing a lot of misinformation inside the corporation about how SNA could be used for the the NSFNET backbone (precursor to modern internet). old NSFNET backbone email http://www.garlic.com/~lynn/lhwemail.html#nsfnet and past posts http://www.garlic.com/~lynn/subnetwork.html#nsfnet Why did that fail? Just too little, too late? NIH? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
paulgboul...@aim.com (Paul Gilmartin) writes: Why did that fail? Just too little, too late? NIH? re: http://www.garlic.com/~lynn/2014b.html#39 Resistance to Java http://www.garlic.com/~lynn/2014b.html#44 Resistance to Java internal network was larger than the arpanet/internet from just about the beginning until sometime late '85 or early '86. Part of the reason was that the (vm370 vnet-based) internal network had a form of gateway in everynode (which didn't exist in the arpanet host protocol, sna, and/or osi model). Arpanet/internet got internetworking protcol as part of the great change-over to tcp/ip on 1jan1983. this ibm-main discussion group originated on univ. bitnet which used technology similar to the internal network ... and about the same time the communication group was forcing the internal network to convert to SNA ... bitnet was converting to tcp/ip for bitnet2 ... which is what the internal network should have done also. http://en.wikipedia.org/wiki/BITNET i had project i called hsdt with T1 (1.5mbit/sec) and faster speed links ... started doing T1 in 1980s. http://www.garlic.com/~lynn/subnetwork.html#hsdt the initial mainframe tcp/ip product (mentioned upthread, implemented in vs/pascal) has some performance issues getting about 44kbytes/sec effective using nearly full 3090 processor. I did the enhancements to support RFC1044 and in some tuning tests at cray research got 1mbyte/sec channel sustained throughput between 4341 and cray using only modest amount of 4341 processor (possibly 500 times improvement in bytes moved per instruction executed) http://www.garlic.com/~lynn/subnetwork.html#1044 standard mainframe 37xx product only supported up to 56kbits/sec. communication group prepared a report for corporate hdqtrs that customers didn't want much more than 56kbits/sec and wouldn't need T1 (1.5mbits/sec) until well into the 90s. At the same time, HSDT didn't superficial customer survey and found 200 customer T1 links connected to IBM mainframes (but using non-ibm controllers). The communication group kept up the facade for a time ... but eventually was forced to came out with the rube-goldberg 3737 hack supporting T1. SNA/VTAM had a separate problem with latency handling in communication links. It was unable to get only a very small fraction of T1 throughput capacity. To get around it the 3737 supported a CTCA link to another local mainframe. Inside the 3737 it had a bunch of processing and enormous amount of buffering (including four 68k, 100k lines of code) ... it would simulate ACK on data RUs to the local VTAM (as if the data had already arrived at the remote end) trying to compenstate for the lack of latency compensation in SNA VTAM. some past posts detailing 3737 http://www.garlic.com/~lynn/2011g.html#75 We list every company in the world that has a mainframe computer http://www.garlic.com/~lynn/2011g.html#77 Is the magic and romance killed by Windows (and Linux)? with these old email http://www.garlic.oom/~lynn/2011g.html#email880130 http://www.garlic.oom/~lynn/2011g.html#email880606 http://www.garlic.oom/~lynn/2011g.html#email881005 the claims were the 3737 could just barely support 1.5mbit/sec throughput ... even though full-duplex T1 is 3mbits/sec aggregate (1.5mbit/sec concurrent in both direction) and european T1 is 4mbits/sec aggregate other trivia ... I had been blamed for online computer conferencing on the internal network in the late 70s and early 80s. folklore is that when the corporate executive committee was informed of computer conferencing (and the internal network), 5of6 wanted to fire me. http://www.garlic.com/~lynn/subnetwork.html#cmc old email from person charged with setting up EARN (bitnet in europe) looking for network apps http://www.garlic.com/~lynn/2001h.html#email840320 posts mentioning bitnet http://www.garlic.com/~lynn/subnetwork.html#bitnet as part of HSDT, we was also working with NSF and NSF supercomputer centers. We were suppose to get $20M from NSF to tie together the supercomputer centers, then congress cut the budget and several other things happened. Finally NSF releases an RFP ... but internal politics (large amount from communication group) prevent us from bidding. The director of NSF tries to help by writting the company a letter (co-signed by some other agency CTOs) ... but that just makes the internal politics worse (as does comments that what we already had running was at least five years ahead of all bid submissions). -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
re: http://www.garlic.com/~lynn/2014b.html#39 Resistance to Java http://www.garlic.com/~lynn/2014b.html#44 Resistance to Java http://www.garlic.com/~lynn/2014b.html#46 Resistance to Java part of the issue SNA was pretty much dictated by VTAM/NCP ... which was a low-speed, dumb terminal communication paradigm. It was a herculean task to do anything approaching networking. it was one of the reasons I called HSDT (high-speed data transport) to differentiate from SNA http://www.garlic.com/~lynn/subnetwork.html#hsdt also, arpanet IMP networking (before 1jan1983 internetworking tcp/ip), sna, and OSI were pretty much all single administrative domain (no internetworking). note that it wasn't just sna that lost out to tcp/ip in the late 80s ... also in the late 80s the federal government had mandated the elimination of the internet and move over to GOSIP (aka OSI) which also didn't happen. old email mentioning NSFNET backbone (precusor to modern internet) http://www.garlic.com/~lynn/lhwemail.html#nsfnet NSFNET backbone related posts http://www.garlic.com/~lynn/subnetwork.html#nsfnet internet related posts http://www.garlic.com/~lynn/subnetwork.html#internet past article from MIT that the original purpose of NSFNET backbone was to hook together the NSF supercomputer centers ... sort of the foundation of GRID computing and modern cloud computing http://www.technologyreview.com/featuredstory/401444/grid-computing/ other trivia ... before he passed, the long time RFC (aka internet standards) Editor (Postel) use to let me do some of STD1 ... based on some of the stuff i do for RFC index http://www.garlic.com/~lynn/rfcietff.htm -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
Ed Jaffe writes: Speaking of Eclipse, we've written some ANT scripts to fully integrated Eclipse (the free one, not IBM's _expensive_ RDz) with mainframe-resident versions of Apache Tomcat, the Java and C/C++ compilers, and GIT (for source code management). Ed, I think you meant that your ANT scripts work with Eclipse, including both the freely downloadable Eclipse distributions and Eclipse-based products (free and fee), such as IBM Rational Developer for zEnterprise and IBM z/OS Explorer. You wouldn't want to inadvertently wipe out much of the market for your scripts, would you? Timothy Sipples GMU VCT Architect Executive (Based in Singapore) E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
On 1/26/2014 4:42 PM, Timothy Sipples wrote: You wouldn't want to inadvertently wipe out much of the market for your scripts, would you? Couldn't care less. Those Ant scripts are for our internal use only. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
Dijkstra's fulminations against PL/I are well known. They are also without merit. An even more general formulation is possible. Theoretical computer science, which elucidates algorithms, is often enormously valuable. Equally, like other kinds of mathematics, it can be obvious and boring; but it is unlikely to offend in any more serious way. Academics' opinions about programming languages and the languages they design are usually, on the other hand, nearly worthless and often pernicious. Moreover, with some few but conspicuous exceptions, they are poor, even execrable programmers. Why this is the case is not entirely clear. Programming is very like theorem proving in many ways, and they are often good at that. Typically, they are also intelligent enough to program well; and many programmers are not. One key to the problem is to be found in Mr Crayford's quotation. Dijkstra was obsessed with minimality, with keeping languages small and, like Wirth, with the curious notion that interdictions are helpful: What I do not find interesting or judge susceptible of abuse, you must not use. Orwell made this point, better than I can make it: The purpose of Newspeak was not only to provide a medium of expression for the world-view and mental habits proper to the devotees of Ingsoc, but to make all other modes of thought impossible. It was intended that when Newspeak had been adopted once and for all and Oldspeak forgotten, a heretical thought---that is a thought diverging from the principles of Ingsoc---should be literally unthinkable, at least so far as thought is dependent upon words. Its vocabulary was so constructed as to give exact and often very subtle expression to every meaning that a Party member could properly wish to express, while excluding all other meanings and also the possibility of arriving at them by indirect means. This was done partly by inventing new words but chiefly by eliminating undesirable words . . . Quite apart from the suppression of definitely heretical words, reduction of vocabulary was regarded as an end in itself, and no word that could be dispensed with was allowed to survive. Newspeak was designed not to extend but to diminish the range of thought, and this purpose was indirectly assisted by cutting the choice of words down to a minimum. (From the Ingsoc appendix to his novel, 1984) I am always pleased to see one of Mr Crayford's posts; I read them all; but it is fair to warn readers of this one that I often, even usually, disagree, roots and branches, with his views. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
On 1/25/14, John Gilmore jwgli...@gmail.com wrote: Dijkstra's fulminations against PL/I are well known. They are also without merit. An even more general formulation is possible. Theoretical computer science, which elucidates algorithms, is often enormously valuable. Equally, like other kinds of mathematics, it can be obvious and boring; but it is unlikely to offend in any more serious way. Academics' opinions about programming languages and the languages they design are usually, on the other hand, nearly worthless and often pernicious. Moreover, with some few but conspicuous exceptions, they are poor, even execrable programmers. Why this is the case is not entirely clear. Programming is very like theorem proving in many ways, and they are often good at that. Typically, they are also intelligent enough to program well; and many programmers are not. One key to the problem is to be found in Mr Crayford's quotation. Dijkstra was obsessed with minimality, with keeping languages small and, like Wirth, with the curious notion that interdictions are helpful: What I do not find interesting or judge susceptible of abuse, you must not use. Orwell made this point, better than I can make it: The purpose of Newspeak was not only to provide a medium of expression for the world-view and mental habits proper to the devotees of Ingsoc, but to make all other modes of thought impossible. It was intended that when Newspeak had been adopted once and for all and Oldspeak forgotten, a heretical thought---that is a thought diverging from the principles of Ingsoc---should be literally unthinkable, at least so far as thought is dependent upon words. Its vocabulary was so constructed as to give exact and often very subtle expression to every meaning that a Party member could properly wish to express, while excluding all other meanings and also the possibility of arriving at them by indirect means. This was done partly by inventing new words but chiefly by eliminating undesirable words . . . Quite apart from the suppression of definitely heretical words, reduction of vocabulary was regarded as an end in itself, and no word that could be dispensed with was allowed to survive. Newspeak was designed not to extend but to diminish the range of thought, and this purpose was indirectly assisted by cutting the choice of words down to a minimum. (From the Ingsoc appendix to his novel, 1984) I am always pleased to see one of Mr Crayford's posts; I read them all; but it is fair to warn readers of this one that I often, even usually, disagree, roots and branches, with his views. John Gilmore, Ashland, MA 01721 - USA -- John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Byte-code COBOL [was:RE: Resistance to Java.]
All For an example of open source byte COBOL check out the zcobol Portable Mainframe COBOL compiler and runtime which comes with the z390 Portable Mainframe Assembler and Emulator which currently runs on Windows, Linux, and Apple OSX host systems with J2SE 6.0+ runtime installed. An assembler program executing BR loop runs at about 30 MIPS on an Intel I7 processor. Of course it's slower when executing HFP, BFP, or DFP which is supported using BigInteger and BigDecimal classes. The zcobol tool only has one native java component zc390.java which reads COBOL source program with CBL suffix and generates equivelant z390 source macro assembler program with MLC suffix. For example a COBOL program with MOVE A to B generates MLC statement MOVE A,TO,B. The MLC program is then assembled using zcobol macro libraries containing maros for all COBOL verbs. THe resulting object code is then linked into z390 390 load module containing standard mainframe object such as MVC or MVCL instruction depending on definition of A and B fields in data division. The zcobol tool is a work in process and does not fully support all the COBOL verbs. However, it does support enough to support compiling and running sequential file or simple vsam indexed file and producing report. There are a number of regression test and demo programs included with the tool: http://www.z390.org/zcobol/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
dcrayf...@gmail.com (David Crayford) writes: That's because there are no viable alternatives. It probably wouldn't be the case if there was a zIIP enabled Ruby on Rails, Python Django or node.js framework available. trivia when java came out ... the director of the business group was somebody use to work with at ibm (we were invited to the JAVA announcement party) He had been in the los gatos vlsi chip design group and was one of two people responsible for implementing mainframe pascal ... which was used internally for lots of chip design tools (requiring significant performance) ... eventually being released to customers as vs/pascal. the original mainframe tcp/ip product was also implemented in vs/pascal (and had none of the buffer length exploits that have been epidemic in c language implementations). He then left to do a 3270 clone controller startup ... TSO operation was so bad that they had a bunch of TSO stuff implemented in the controller ... which they figured would have big market ... but the IBM/PC overtook them. He then went on to be VP of MIPS software development ... and when SGI bought MIPS ... went to SUN. This was age when everybody seemed to be doing object-oriented operating systems ... apple had pink and sun had spring. Before spring was shutdown ... we were approached about running the group and commercializing spring and turning it out as product ... but declined. When spring was shutdown ... all the people were moved over to JAVA. There was some amount of synergy between spring and green (which morphs into JAVA) ... a major objective of spring was highly distributed computing model http://en.wikibooks.org/wiki/Java_Programming/History from spring papers, gone 404, but live on at wayback machine http://web.archive.org/web/20030404182953/http://java.sun.com/people/kgh/spring/ A Client-Side Stub Interpreter We have built a research operating system in which all services are presented through interfaces described by an interface description language. The system consists of a micro-kernel that supports a small number of these interfaces, and a large number of interfaces that are implemented by user-level code. A typical service implements one or more interfaces, but is a client of many other interfaces that are implemented elsewhere in the system. We have an interface compiler that generates client-side and service-side stubs to deliver calls from clients to services providing location transparency if the client and server are in different address spaces. The code for client-side stubs was occupying a large amount of the text space on our clients, so a stub interpreter was written to replace the client-side stub methods. The result was that we traded 125k bytes of stub code for 13k bytes of stub descriptions and 4k bytes of stub interpreter. This paper describes the stub interpreter, the stub descriptions, and discusses some alternatives. ... snip ... 125kbytes of code was significant percent of real storage on many machines of the period. there were a couple operations in silicon valley that did a lot of work on JIT (just in time) compiling for various mainframe 370 emulators (on the fly translating 370 code segments into native code) ... eventually similar techniques start to appear for JAVA ... with increasing levels of performance. http://en.wikipedia.org/wiki/Java_performance -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
On Sat, 25 Jan 2014 13:40:16 +0800, David Crayford wrote: On 25/01/2014 3:52 AM, Ed Jaffe wrote: Most mainframe modernization efforts are rooted in Java. That's because there are no viable alternatives. It probably wouldn't be the case if there was a zIIP enabled Ruby on Rails, Python Django or node.js framework available. What would be required to entice IBM to enable any of these, even assuming the FOSS community stepped in to provide the coding effort? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
On 1/24/2014 9:40 PM, David Crayford wrote: I can speak from personal experience that our emerging Java-based mainframe offerings have been well received by our customer base. http://phoenixsoftware.com/ejes/ejes_future.htm Nice to see a product use a browser UI and not a dreaded Eclipse plug-in. We love Eclipse! So do many of our customers and some have already requested a full-featured Eclipse plug-in for (E)JES. We hope to be able to provide them with that during phase II of the roll-out. We want to give our customers what they ask for, but I think the browser UI will be more popular since only developers use Eclipse. Speaking of Eclipse, we've written some ANT scripts to fully integrated Eclipse (the free one, not IBM's _expensive_ RDz) with mainframe-resident versions of Apache Tomcat, the Java and C/C++ compilers, and GIT (for source code management). With the push of a button, a developer can obtain a code branch from the mainframe-resident GIT repository, build it, create a unique execution environment on the mainframe, and interactively debug his/her code running on the mainframe from the desktop. It's very cool (and cloudy) stuff! Personally, I can't wait to have a mobile (E)JES client running on my HTC One. Talk about a conversation starter! Have you published your REST API so your customers can use it? Not yet. The Sep 2013 deliverable was classified as a Technology Preview. The REST API should be documented when the final rolls out. Thanks for asking... :) -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
On 1/25/2014 at 01:09 AM, David Crayford dcrayf...@gmail.com wrote: On 25/01/2014 1:57 PM, Mark Post wrote: -snip- Given who I work for, I would truly like to believe that, but I have grave doubts about such statements unless the sources are cited, etc. I know for a fact that Java on Linux for System z can be as much of a resource hog as on any other platform. It all really boils down to whether there are good performance tools to work with, application programmers that are willing to not treat hardware as an infinite resource and all groups involved able to work together. http://www.dovetail.com/docs/coz/zos_hybrid_batch_zes30_ibm.pdf page 35. I'm looking at that document, and I see the system involved was a 2094-405. So, a reduced-capacity system to start with. The improvement with the addition of a zIIP (in zAAP) mode increased throughput because specialty processors run at full speed, but they only process the part of the workload that's eligible. The IFL, on the other hand, will be running _everything_ at full speed, which is definitely going to skew the results. So, while I support the idea of offloading cycles from z/OS to Linux where it makes sense, I am not going to say the z/OS software stack is a performance bottleneck. More likely, in my mind, a combination of capacity capping, system load, and whatever percentage of the workload being eligible for the zIIP limiting the throughput. One thing to keep in mind is that z/OS and z/VM are written in a language far closer to assembler code than Linux, with decades of effort into optimizing the code for performance. That's why z/VM could support thousands of interactive CMS users on pre-System z hardware, but Linux ran like a pig on the same hardware. It wasn't until IBM began cranking up the CPU speeds with System z and adding hardware instructions that were specific to the workload that Linux got to a really good level of performance on the mainframe. Mark Post -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
On 1/24/2014 9:40 PM, David Crayford wrote: I heard that a resource intensive Java program was run on both a z/OS zIIP and zLinux IFL. zLinux was x10 faster. The conclusion was that the z/OS software stack was the bottle neck. I'm highly skeptical of this claim. On our zBC12 we run 64-bit Java on both IFL (Linux for z) and zIIP (z/OS) and there does not seem to be any noticeable difference in performance. For the record, we have not run benchmark tests to officially compare these two environments, but if there was a 10x difference in performance I'm pretty sure we would have noticed. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
On 26/01/2014 1:38 AM, Ed Jaffe wrote: On 1/24/2014 9:40 PM, David Crayford wrote: I can speak from personal experience that our emerging Java-based mainframe offerings have been well received by our customer base. http://phoenixsoftware.com/ejes/ejes_future.htm Nice to see a product use a browser UI and not a dreaded Eclipse plug-in. We love Eclipse! So do many of our customers and some have already requested a full-featured Eclipse plug-in for (E)JES. We hope to be able to provide them with that during phase II of the roll-out. We want to give our customers what they ask for, but I think the browser UI will be more popular since only developers use Eclipse. My issue with most of the Eclipse PDT plug-ins I've seen in RDz is that they are actually worse than the 3270 user interfaces that they are attempting to replace. Not to mention that I can't run Eclipse on my iPad, which is where I spend almost as much time as I do on my PC these days. The desktop UI has become a second class citizen with the rise of HTML5, Javascript and mobile devices. Speaking of Eclipse, we've written some ANT scripts to fully integrated Eclipse (the free one, not IBM's _expensive_ RDz) with mainframe-resident versions of Apache Tomcat, the Java and C/C++ compilers, and GIT (for source code management). With the push of a button, a developer can obtain a code branch from the mainframe-resident GIT repository, build it, create a unique execution environment on the mainframe, and interactively debug his/her code running on the mainframe from the desktop. It's very cool (and cloudy) stuff! Wow, that does sound cool! When you consider that Cloud 9 already has 250,000 user includes https://c9.io/ it does seem that in a few years time we will all be using our browsers for everything. Maybe even 3270 emulation via websockets. HTML5 is a game changer with offline apps, local storage, sockets, vector graphics etc. Personally, I can't wait to have a mobile (E)JES client running on my HTC One. Talk about a conversation starter! It's amazing how excited the mainframe community gets about mobile z/OS apps. With your REST API a decent web developer should be able to knock up a Single Page Application in Javascript using something like backbone.js. It would be pretty cool scrolling through syslog using touch gestures. You'll be the talk of the town at SHARE! Have you published your REST API so your customers can use it? Not yet. The Sep 2013 deliverable was classified as a Technology Preview. The REST API should be documented when the final rolls out. Thanks for asking... :) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
On 25/01/2014 11:43 PM, Paul Gilmartin wrote: On Sat, 25 Jan 2014 13:40:16 +0800, David Crayford wrote: On 25/01/2014 3:52 AM, Ed Jaffe wrote: Most mainframe modernization efforts are rooted in Java. That's because there are no viable alternatives. It probably wouldn't be the case if there was a zIIP enabled Ruby on Rails, Python Django or node.js framework available. What would be required to entice IBM to enable any of these, even assuming the FOSS community stepped in to provide the coding effort? Good question. I think IBM are more than happy to allow modern workloads to run on zIIP engines so long as they can still charge a premium for legacy workloads. As far as the technical details go we would have to ask someone like Russ Teubner from Hostbridge. They ported and zIIP enabled the SpiderMonkey Javascript engine to z/OS. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
On 1/25/2014 6:43 PM, David Crayford wrote: On 26/01/2014 1:38 AM, Ed Jaffe wrote: We love Eclipse! So do many of our customers and some have already requested a full-featured Eclipse plug-in for (E)JES. We hope to be able to provide them with that during phase II of the roll-out. We want to give our customers what they ask for, but I think the browser UI will be more popular since only developers use Eclipse. My issue with most of the Eclipse PDT plug-ins I've seen in RDz is that they are actually worse than the 3270 user interfaces that they are attempting to replace. Agreed - this has been a common thread among IBM-developed 3270 replacement GUIs. Some were so bad, mainframers were literally laughing out loud before they'd ever heard the term LOL. I've often wondered what the state of the mainframe would be today if IBM had actually done a halfway decent job developing ISPF Client/Server, mSys for Setup, and other similar GUI-based initiatives from the 1990s. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
John von Neumann on the baroque: As a mathematical discipline travels far from its empirical source, or still more, if it is a second and third generation only indirectly inspired from ideas coming from 'reality', it is beset with very grave dangers. It becomes more and more purely aestheticizing, more and more purely l'art pour l'art. This need not be bad, if the field is surrounded by correlated subjects, which still have closer empirical connections, or if the discipline is under the influence of men with an exceptionally well-developed taste. But there is a grave danger that the subject will develop along the line of least resistance, that the stream, so far from its source, will separate into a multitude of insignificant branches, and that the discipline will become a disorganized mass of details and complexities. In other words, at a great distance from its empirical source, or after much 'abstract' inbreeding, a mathematical subject is in danger of degeneration. At the inception the style is usually classical; when it shows signs of becoming baroque the danger signal is up. It would be easy to give examples, to trace specific evolutions into the baroque and the very high baroque, but this would be too technical. In any event, whenever this stage is reached, the only remedy seems to me to be the rejuvenating return to the source: the reinjection of more or less directly empirical ideas. I am convinced that this is a necessary condition to conserve the freshness and the vitality of the subject, and that this will remain so in the future. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
About root to branch, root and branch and, I think more appositely, roots and|to branches (one root and one branch are surely a very special case), a petition to the Long Parliament of 1640 from a group of Londoners concludes with the peroration We therefore most humbly pray, and beseech this honourable assembly, the premises considered, that the said government with all its dependencies, roots and branches, may be abolished, and all laws in their behalf made void, and the government according to God's word may be rightly placed amongst us: and we your humble suppliants, as in duty we are bound, will daily pray for his majesty's long and happy reign over us, and for the prosperous success of this high and honourable Court of Parliament. The 'government' to be abolished was that of the Church I don't know that IBM has an established, formal procedure for accepting such petitions, but those who want to abolish the zIIP and zAAP roots and branches may be able to find a place within it where such a petition can be lodged. As usual, they should first reflect briefly on what would happen if their petition were granted. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Byte-code COBOL [was:RE: Resistance to Java.]
The only one that was really an issue was the Neon software. Clearly IBM took a pretty aggressive move to quash it. Can't remember the name of it now. I am guessing that even if you had a perfect cobol-to-java-byte-code conversion.. you'd skip an upgrade.. maybe two. (Unless your business is extremely small growth.) And then the need to move to the next processor level would catch up. Reality check.. anyone even know of a shop that is 100% cobol? No assembler.. no utilities.. no SAS or other report writer / output reformatter.. or a variety of other utilities that wouldn't fit in a zIIP/zAAP? Of course there would undoubtably be at least a few intensive programs that were just too much of a performance/critical to be converted which had to stay on GP. Not that it is a bad idea.. it would be cool to be able to pick and choose certain cobol programs to run as java... wait isn't that what IBM's EGL does? Allows code to be written in EGL then compiled as cobol or java? Now.. if they were smart.. there would be a cobol-to-EGL-to-java conversion as well. Of course it would probably work more like You know how when you make a copy of a copy, it's not as sharp as... well... the original. - Multiplicity quote VBG Rob Schramm Rob Schramm Senior Systems Consultant Imperium Group On Wed, Jan 22, 2014 at 4:04 PM, Farley, Peter x23353 peter.far...@broadridge.com wrote: A byte-code COBOL object program might not be as efficient as even the just-previous generation (4.x) of Enterprise COBOL, given the JVM's stack-oriented runtime structure and (so I heard somewhere) less-than-efficient packed-decimal support. Less cost to run on a cheaper processor could be overwhelmed by elapsed-time increases affecting SLA's, especially for larger shops who do not run knee-capped GP's. But as usual, I could be quite wrong about that. In any case, I agree with you that if IBM saw a decrease in revenue from such a product they would either buy it and bury it or T C it out of existence. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Wednesday, January 22, 2014 3:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Resistance to Java. On 22 January 2014 08:36, John McKown john.archie.mck...@gmail.com wrote: Now wouldn't that be a kick? An Enterprise COBOL compatible compiler which produced Java byte code. That would likely sell a lot of zAAPs. Don't think it hasn't been seriously considered by more than one party... But as with any number of other such approaches, it would be limited by its own success. If it managed to displace any significant amount of IBM revenue by shifting legacy workloads to cheaper processors, IBM would put a stop to it, either technically or by new Ts Cs of some sort. Tony H. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
On 1/21/2014 10:39 AM, John McKown wrote: This is a curiosity question. I am wondering how resistant shops are to even having the Java JDK installed on their system. Not in being resistant to writing application code in Java, but just to having it available. In particular, are there many shops who would reject a useful product because it was written in Java versus in C, C++, or some other language? The only reason that I can think of that they would reject Java is due to the high CPU needed versus C or whatever. I would _assume_ that a shop with a zAAP (or zIIP for zAAP on zIIP) would not be resistant, and maybe even glad, to have Java because it could offload work from the general CPs onto the full speed zIIP or zAAP processor. Most mainframe modernization efforts are rooted in Java. z/OSMF is a prime example from IBM. Chorus Software Manager is a good example from CA. I can speak from personal experience that our emerging Java-based mainframe offerings have been well received by our customer base. http://phoenixsoftware.com/ejes/ejes_future.htm From a strategic standpoint, IBM has given z/OS Java highly preferential treatment in both System z hardware/software design and customer terms and conditions. This trend is expected to continue, making z/OS Java a solid language/platform choice with good investment protection for the foreseeable future. I still remember when at times it seemed that DB2 was the ONLY driver of new innovations on the platform. Of course, DB2 is still an important contributor. But, in my view, it has taken somewhat of a back seat to more numerous performance enhancements aimed squarely at Websphere/Java. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
I've always enjoyed reading Dijkstra http://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html. He said of PL/I: Finally, although the subject is not a pleasant one, I must mention PL/1, a programming language for which the defining documentation is of a frightening size and complexity. Using PL/1 must be like flying a plane with 7000 buttons, switches and handles to manipulate in the cockpit. I absolutely fail to see how we can keep our growing programs firmly within our intellectual grip when by its sheer baroqueness the programming language —our basic tool, mind you!— already escapes our intellectual control. Wow, I wonder what he thought of C++? On 24/01/2014 8:47 PM, John Gilmore wrote: John von Neumann on the baroque: As a mathematical discipline travels far from its empirical source, or still more, if it is a second and third generation only indirectly inspired from ideas coming from 'reality', it is beset with very grave dangers. It becomes more and more purely aestheticizing, more and more purely l'art pour l'art. This need not be bad, if the field is surrounded by correlated subjects, which still have closer empirical connections, or if the discipline is under the influence of men with an exceptionally well-developed taste. But there is a grave danger that the subject will develop along the line of least resistance, that the stream, so far from its source, will separate into a multitude of insignificant branches, and that the discipline will become a disorganized mass of details and complexities. In other words, at a great distance from its empirical source, or after much 'abstract' inbreeding, a mathematical subject is in danger of degeneration. At the inception the style is usually classical; when it shows signs of becoming baroque the danger signal is up. It would be easy to give examples, to trace specific evolutions into the baroque and the very high baroque, but this would be too technical. In any event, whenever this stage is reached, the only remedy seems to me to be the rejuvenating return to the source: the reinjection of more or less directly empirical ideas. I am convinced that this is a necessary condition to conserve the freshness and the vitality of the subject, and that this will remain so in the future. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
On 24/01/2014 10:23 AM, Shane Ginnane wrote: On Thu, 23 Jan 2014 21:26:04 +0800, David Crayford wrote: +1 for Martins blog post, which is excellent. Having said that, the whole zIIP concept is baroque from root to branch. Why couldn't IBM have come up with something much simpler? baroque implies (to me) some degree of ornate. Given the contortions both the hardware and (operating system) software architects have had to perform to support both DB2 and java, perhaps Rube Goldberg might be closer to the mark. http://en.wikipedia.org/wiki/Baroque#Modern_usage just about sums it up Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
On 25/01/2014 3:52 AM, Ed Jaffe wrote: Most mainframe modernization efforts are rooted in Java. That's because there are no viable alternatives. It probably wouldn't be the case if there was a zIIP enabled Ruby on Rails, Python Django or node.js framework available. One of the most impressive mainframe modernization products I've seen recently is an ISV integration solution that uses a server side JavaScript engine (zIIP enabled) that runs in CICS. I wish IBM would do stuff like that. Dynamic languages are just so productive. Java is about as agile as an oil tanker. I can speak from personal experience that our emerging Java-based mainframe offerings have been well received by our customer base. http://phoenixsoftware.com/ejes/ejes_future.htm Nice to see a product use a browser UI and not a dreaded Eclipse plug-in. Have you published your REST API so your customers can use it? From a strategic standpoint, IBM has given z/OS Java highly preferential treatment in both System z hardware/software design and customer terms and conditions. This trend is expected to continue, making z/OS Java a solid language/platform choice with good investment protection for the foreseeable future. I still remember when at times it seemed that DB2 was the ONLY driver of new innovations on the platform. Of course, DB2 is still an important contributor. But, in my view, it has taken somewhat of a back seat to more numerous performance enhancements aimed squarely at Websphere/Java. I heard that a resource intensive Java program was run on both a z/OS zIIP and zLinux IFL. zLinux was x10 faster. The conclusion was that the z/OS software stack was the bottle neck. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
On 1/25/2014 at 12:40 AM, David Crayford dcrayf...@gmail.com wrote: I heard that a resource intensive Java program was run on both a z/OS zIIP and zLinux IFL. zLinux was x10 faster. The conclusion was that the z/OS software stack was the bottle neck. Given who I work for, I would truly like to believe that, but I have grave doubts about such statements unless the sources are cited, etc. I know for a fact that Java on Linux for System z can be as much of a resource hog as on any other platform. It all really boils down to whether there are good performance tools to work with, application programmers that are willing to not treat hardware as an infinite resource and all groups involved able to work together. I'm pretty sure it's true with any platform: application changes can bring orders of magnitude improvements in performance. System, JVM, or other tuning can at best provide percentage improvements. Mark Post -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
On 22/01/2014 11:53 PM, Skip Robinson wrote: IBM is currently warning customers that over-using ZIIPs may lead to serious performance problems because of the way z/OS manages them vs. the way it manages general purpose CPs. Can you supply a link wrt that information? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
On Thu, 23 Jan 2014 15:59:23 +0800, David Crayford wrote: On 22/01/2014 11:53 PM, Skip Robinson wrote: IBM is currently warning customers that over-using ZIIPs may lead to serious performance problems because of the way z/OS manages them vs. the way it manages general purpose CPs. Can you supply a link wrt that information? Google found: https://www.ibm.com/developerworks/community/blogs/22586cb0-8817-4d2c-ae74-0ddcc2a409bc/entry/december_17_2012_6_07_am3?lang=en http://ibmdatamag.com/2013/04/performance-and-capacity-considerations-for-ziip-engines/ Norbert Friemel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
I'm also talking about this. In the final throes of having a presentation I aim to put on Slideshare (and give at any suitable venue). The message is important: DB2 V10 changes the way we view zIIP capacity. The other message is important: zIIP Capacity Planning IS very feasible. And at the risk of annoying people with blatant self promotion :-) see: https://www.ibm.com/developerworks/community/blogs/MartinPacker/entry/ziip_address_space_instrumentation?lang=en Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: Norbert Friemel nf.ibmm...@web.de To: IBM-MAIN@listserv.ua.edu Date: 23/01/2014 09:01 Subject:Re: Resistance to Java. Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu On Thu, 23 Jan 2014 15:59:23 +0800, David Crayford wrote: On 22/01/2014 11:53 PM, Skip Robinson wrote: IBM is currently warning customers that over-using ZIIPs may lead to serious performance problems because of the way z/OS manages them vs. the way it manages general purpose CPs. Can you supply a link wrt that information? Google found: https://www.ibm.com/developerworks/community/blogs/22586cb0-8817-4d2c-ae74-0ddcc2a409bc/entry/december_17_2012_6_07_am3?lang=en http://ibmdatamag.com/2013/04/performance-and-capacity-considerations-for-ziip-engines/ Norbert Friemel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
I think that's a better overview of the issue Martin, because you bring out the important fact that z/OS doesn't forget about how to prioritize work just because it's on a specialty engine. It's probably would also be a similarly good rule of thumb that you shouldn't let your GPs get over 50% busy with the most important system-related work. And having more dispatchable CPUs than less has been better in my experience. One small point though relative to your blog post: each DDF transaction actually now creates two enclaves: an indepedent enclave and a work-dependent enclave. It seems that the work-dependent enclave runs only on the GCP and does 40% of the work, while the independent enclave runs 100% on the zIIP and does 60% of the work. But it does appear from the doc and data that work dependent enclave CPU time is captured in the indepedent enclave CPU time buckets, which makes sense. Scott On Thu, 23 Jan 2014 09:46:18 +, Martin Packer martin_pac...@uk.ibm.com wrote: I'm also talking about this. In the final throes of having a presentation I aim to put on Slideshare (and give at any suitable venue). The message is important: DB2 V10 changes the way we view zIIP capacity. The other message is important: zIIP Capacity Planning IS very feasible. And at the risk of annoying people with blatant self promotion :-) see: https://www.ibm.com/developerworks/community/blogs/MartinPacker/entry/ziip_address_space_instrumentation?lang=en Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: Norbert Friemel nf.ibmm...@web.de To: IBM-MAIN@listserv.ua.edu Date: 23/01/2014 09:01 Subject:Re: Resistance to Java. Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu On Thu, 23 Jan 2014 15:59:23 +0800, David Crayford wrote: On 22/01/2014 11:53 PM, Skip Robinson wrote: IBM is currently warning customers that over-using ZIIPs may lead to serious performance problems because of the way z/OS manages them vs. the way it manages general purpose CPs. Can you supply a link wrt that information? Google found: https://www.ibm.com/developerworks/community/blogs/22586cb0-8817-4d2c-ae74-0ddcc2a409bc/entry/december_17_2012_6_07_am3?lang=en http://ibmdatamag.com/2013/04/performance-and-capacity-considerations-for-ziip-engines/ Norbert Friemel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
+1 for Martins blog post, which is excellent. Having said that, the whole zIIP concept is baroque from root to branch. Why couldn't IBM have come up with something much simpler? On 23/01/2014 8:29 PM, Scott Chapman wrote: I think that's a better overview of the issue Martin, because you bring out the important fact that z/OS doesn't forget about how to prioritize work just because it's on a specialty engine. It's probably would also be a similarly good rule of thumb that you shouldn't let your GPs get over 50% busy with the most important system-related work. And having more dispatchable CPUs than less has been better in my experience. One small point though relative to your blog post: each DDF transaction actually now creates two enclaves: an indepedent enclave and a work-dependent enclave. It seems that the work-dependent enclave runs only on the GCP and does 40% of the work, while the independent enclave runs 100% on the zIIP and does 60% of the work. But it does appear from the doc and data that work dependent enclave CPU time is captured in the indepedent enclave CPU time buckets, which makes sense. Scott On Thu, 23 Jan 2014 09:46:18 +, Martin Packer martin_pac...@uk.ibm.com wrote: I'm also talking about this. In the final throes of having a presentation I aim to put on Slideshare (and give at any suitable venue). The message is important: DB2 V10 changes the way we view zIIP capacity. The other message is important: zIIP Capacity Planning IS very feasible. And at the risk of annoying people with blatant self promotion :-) see: https://www.ibm.com/developerworks/community/blogs/MartinPacker/entry/ziip_address_space_instrumentation?lang=en Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: Norbert Friemel nf.ibmm...@web.de To: IBM-MAIN@listserv.ua.edu Date: 23/01/2014 09:01 Subject:Re: Resistance to Java. Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu On Thu, 23 Jan 2014 15:59:23 +0800, David Crayford wrote: On 22/01/2014 11:53 PM, Skip Robinson wrote: IBM is currently warning customers that over-using ZIIPs may lead to serious performance problems because of the way z/OS manages them vs. the way it manages general purpose CPs. Can you supply a link wrt that information? Google found: https://www.ibm.com/developerworks/community/blogs/22586cb0-8817-4d2c-ae74-0ddcc2a409bc/entry/december_17_2012_6_07_am3?lang=en http://ibmdatamag.com/2013/04/performance-and-capacity-considerations-for-ziip-engines/ Norbert Friemel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
Since us technicians don't see the benefits, they must be non-technical, and will probably be marketing... Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Thursday, January 23, 2014 14:26 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Resistance to Java. +1 for Martins blog post, which is excellent. Having said that, the whole zIIP concept is baroque from root to branch. Why couldn't IBM have come up with something much simpler? On 23/01/2014 8:29 PM, Scott Chapman wrote: I think that's a better overview of the issue Martin, because you bring out the important fact that z/OS doesn't forget about how to prioritize work just because it's on a specialty engine. It's probably would also be a similarly good rule of thumb that you shouldn't let your GPs get over 50% busy with the most important system-related work. And having more dispatchable CPUs than less has been better in my experience. One small point though relative to your blog post: each DDF transaction actually now creates two enclaves: an indepedent enclave and a work-dependent enclave. It seems that the work-dependent enclave runs only on the GCP and does 40% of the work, while the independent enclave runs 100% on the zIIP and does 60% of the work. But it does appear from the doc and data that work dependent enclave CPU time is captured in the indepedent enclave CPU time buckets, which makes sense. Scott On Thu, 23 Jan 2014 09:46:18 +, Martin Packer martin_pac...@uk.ibm.com wrote: I'm also talking about this. In the final throes of having a presentation I aim to put on Slideshare (and give at any suitable venue). The message is important: DB2 V10 changes the way we view zIIP capacity. The other message is important: zIIP Capacity Planning IS very feasible. And at the risk of annoying people with blatant self promotion :-) see: https://www.ibm.com/developerworks/community/blogs/MartinPacker/entry /ziip_address_space_instrumentation?lang=en Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacke r From: Norbert Friemel nf.ibmm...@web.de To: IBM-MAIN@listserv.ua.edu Date: 23/01/2014 09:01 Subject:Re: Resistance to Java. Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu On Thu, 23 Jan 2014 15:59:23 +0800, David Crayford wrote: On 22/01/2014 11:53 PM, Skip Robinson wrote: IBM is currently warning customers that over-using ZIIPs may lead to serious performance problems because of the way z/OS manages them vs. the way it manages general purpose CPs. Can you supply a link wrt that information? Google found: https://www.ibm.com/developerworks/community/blogs/22586cb0-8817-4d2c -ae74-0ddcc2a409bc/entry/december_17_2012_6_07_am3?lang=en http://ibmdatamag.com/2013/04/performance-and-capacity-considerations -for-ziip-engines/ Norbert Friemel - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete
Re: Resistance to Java.
In order to cut the delays with a busy zIIP, wouldn't another workaround be to reduce to the delay from 3200 microseconds? Experiment with 2500, 2000, 1500, 1000, 700, 500, 400, ... until delay is reduced. Then creep it up by 100 if the zIIP utilization drops or GP rises and a little more delay is acceptable. On Thu, Jan 23, 2014 at 3:46 AM, Martin Packer martin_pac...@uk.ibm.com wrote: I'm also talking about this. In the final throes of having a presentation I aim to put on Slideshare (and give at any suitable venue). The message is important: DB2 V10 changes the way we view zIIP capacity. The other message is important: zIIP Capacity Planning IS very feasible. And at the risk of annoying people with blatant self promotion :-) see: https://www.ibm.com/developerworks/community/blogs/MartinPacker/entry/ziip_address_space_instrumentation?lang=en Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: Norbert Friemel nf.ibmm...@web.de To: IBM-MAIN@listserv.ua.edu Date: 23/01/2014 09:01 Subject:Re: Resistance to Java. Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu On Thu, 23 Jan 2014 15:59:23 +0800, David Crayford wrote: On 22/01/2014 11:53 PM, Skip Robinson wrote: IBM is currently warning customers that over-using ZIIPs may lead to serious performance problems because of the way z/OS manages them vs. the way it manages general purpose CPs. Can you supply a link wrt that information? Google found: https://www.ibm.com/developerworks/community/blogs/22586cb0-8817-4d2c-ae74-0ddcc2a409bc/entry/december_17_2012_6_07_am3?lang=en http://ibmdatamag.com/2013/04/performance-and-capacity-considerations-for-ziip-engines/ Norbert Friemel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
ZIIPAWMT fiddling has issues as well as limits: With Hiperdispatch it's 3.2ms, double the 1.6ms without. That is the limit part of it. The issues part is, I think, to avoid too much IIPCP time and also I would expect undesirable cache effects. I actually don't cover ZIIPAWMT in the new presentation. Largely because I don't want people fiddling with it. Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: Mike Schwab mike.a.sch...@gmail.com To: IBM-MAIN@listserv.ua.edu Date: 23/01/2014 15:57 Subject:Re: Resistance to Java. Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu In order to cut the delays with a busy zIIP, wouldn't another workaround be to reduce to the delay from 3200 microseconds? Experiment with 2500, 2000, 1500, 1000, 700, 500, 400, ... until delay is reduced. Then creep it up by 100 if the zIIP utilization drops or GP rises and a little more delay is acceptable. On Thu, Jan 23, 2014 at 3:46 AM, Martin Packer martin_pac...@uk.ibm.com wrote: I'm also talking about this. In the final throes of having a presentation I aim to put on Slideshare (and give at any suitable venue). The message is important: DB2 V10 changes the way we view zIIP capacity. The other message is important: zIIP Capacity Planning IS very feasible. And at the risk of annoying people with blatant self promotion :-) see: https://www.ibm.com/developerworks/community/blogs/MartinPacker/entry/ziip_address_space_instrumentation?lang=en Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: Norbert Friemel nf.ibmm...@web.de To: IBM-MAIN@listserv.ua.edu Date: 23/01/2014 09:01 Subject:Re: Resistance to Java. Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu On Thu, 23 Jan 2014 15:59:23 +0800, David Crayford wrote: On 22/01/2014 11:53 PM, Skip Robinson wrote: IBM is currently warning customers that over-using ZIIPs may lead to serious performance problems because of the way z/OS manages them vs. the way it manages general purpose CPs. Can you supply a link wrt that information? Google found: https://www.ibm.com/developerworks/community/blogs/22586cb0-8817-4d2c-ae74-0ddcc2a409bc/entry/december_17_2012_6_07_am3?lang=en http://ibmdatamag.com/2013/04/performance-and-capacity-considerations-for-ziip-engines/ Norbert Friemel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
On Thu, 23 Jan 2014 21:26:04 +0800, David Crayford wrote: +1 for Martins blog post, which is excellent. Having said that, the whole zIIP concept is baroque from root to branch. Why couldn't IBM have come up with something much simpler? baroque implies (to me) some degree of ornate. Given the contortions both the hardware and (operating system) software architects have had to perform to support both DB2 and java, perhaps Rube Goldberg might be closer to the mark. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
On Tue, Jan 21, 2014 at 7:53 PM, David Crayford dcrayf...@gmail.com wrote: snip Of course, if you don't have a zIIP you wouldn't go near it with a ten foot barge pole. total agreement. It is why we don't use it. Well, other than the usual we have never used it in the past! which is also articulated by our programmer as But it's not COBOL! Now wouldn't that be a kick? An Enterprise COBOL compatible compiler which produced Java byte code. That would likely sell a lot of zAAPs. I've never been of fan of Java the language. IMO, C# was Java done properly. The JVM is another matter. The original designers of Java got it right separating the language from the runtime. It means I have the choice of lots of much nicer languages like Javascript, Jython, JRuby, Groovy, Clojure and my particular favorite Scala. Ah, good point. I guess I should have phrased the question better. I was mainly interested in whether shops would reject a product because it required the use of the Java JVM to run some of the programs. I didn't really mean to imply Java as the source, but as the run time. -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
In our case, we are looking for Java solutions so that we can utilize an underutilized ZIIP (and try and curb MLC charges and postpone future upgrades). On 22 January 2014 15:36, John McKown john.archie.mck...@gmail.com wrote: On Tue, Jan 21, 2014 at 7:53 PM, David Crayford dcrayf...@gmail.com wrote: snip Of course, if you don't have a zIIP you wouldn't go near it with a ten foot barge pole. total agreement. It is why we don't use it. Well, other than the usual we have never used it in the past! which is also articulated by our programmer as But it's not COBOL! Now wouldn't that be a kick? An Enterprise COBOL compatible compiler which produced Java byte code. That would likely sell a lot of zAAPs. I've never been of fan of Java the language. IMO, C# was Java done properly. The JVM is another matter. The original designers of Java got it right separating the language from the runtime. It means I have the choice of lots of much nicer languages like Javascript, Jython, JRuby, Groovy, Clojure and my particular favorite Scala. Ah, good point. I guess I should have phrased the question better. I was mainly interested in whether shops would reject a product because it required the use of the Java JVM to run some of the programs. I didn't really mean to imply Java as the source, but as the run time. -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
If you need to ramp up your ZIIP usage, DB2 V10 may be riding to your rescue. IBM is currently warning customers that over-using ZIIPs may lead to serious performance problems because of the way z/OS manages them vs. the way it manages general purpose CPs. You can't be too rich, too thin, or too ZIIPped. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Mike Shorkend mike.shork...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 01/22/2014 06:11 AM Subject:Re: Resistance to Java. Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU In our case, we are looking for Java solutions so that we can utilize an underutilized ZIIP (and try and curb MLC charges and postpone future upgrades). On 22 January 2014 15:36, John McKown john.archie.mck...@gmail.com wrote: On Tue, Jan 21, 2014 at 7:53 PM, David Crayford dcrayf...@gmail.com wrote: snip Of course, if you don't have a zIIP you wouldn't go near it with a ten foot barge pole. total agreement. It is why we don't use it. Well, other than the usual we have never used it in the past! which is also articulated by our programmer as But it's not COBOL! Now wouldn't that be a kick? An Enterprise COBOL compatible compiler which produced Java byte code. That would likely sell a lot of zAAPs. I've never been of fan of Java the language. IMO, C# was Java done properly. The JVM is another matter. The original designers of Java got it right separating the language from the runtime. It means I have the choice of lots of much nicer languages like Javascript, Jython, JRuby, Groovy, Clojure and my particular favorite Scala. Ah, good point. I guess I should have phrased the question better. I was mainly interested in whether shops would reject a product because it required the use of the Java JVM to run some of the programs. I didn't really mean to imply Java as the source, but as the run time. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
On 22 January 2014 08:36, John McKown john.archie.mck...@gmail.com wrote: Now wouldn't that be a kick? An Enterprise COBOL compatible compiler which produced Java byte code. That would likely sell a lot of zAAPs. Don't think it hasn't been seriously considered by more than one party... But as with any number of other such approaches, it would be limited by its own success. If it managed to displace any significant amount of IBM revenue by shifting legacy workloads to cheaper processors, IBM would put a stop to it, either technically or by new Ts Cs of some sort. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
On Wed, 22 Jan 2014 15:14:30 -0500, Tony Harminc wrote: On 22 January 2014 08:36, John McKown wrote: Now wouldn't that be a kick? An Enterprise COBOL compatible compiler which produced Java byte code. That would likely sell a lot of zAAPs. Don't think it hasn't been seriously considered by more than one party... But as with any number of other such approaches, it would be limited by its own success. If it managed to displace any significant amount of IBM revenue by shifting legacy workloads to cheaper processors, IBM would put a stop to it, either technically or by new Ts Cs of some sort. Does IBM have any IP protection on COBOL? I'd assume, can't, except for IBM's extensions and idiosyncrasies. But it would be pretty hard to market against IBM without those extensions. Ts Cs, of course, are orthogonal to any protection provided by USPTO. Micro Focus? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Byte-code COBOL [was:RE: Resistance to Java.]
A byte-code COBOL object program might not be as efficient as even the just-previous generation (4.x) of Enterprise COBOL, given the JVM's stack-oriented runtime structure and (so I heard somewhere) less-than-efficient packed-decimal support. Less cost to run on a cheaper processor could be overwhelmed by elapsed-time increases affecting SLA's, especially for larger shops who do not run knee-capped GP's. But as usual, I could be quite wrong about that. In any case, I agree with you that if IBM saw a decrease in revenue from such a product they would either buy it and bury it or T C it out of existence. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Wednesday, January 22, 2014 3:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Resistance to Java. On 22 January 2014 08:36, John McKown john.archie.mck...@gmail.com wrote: Now wouldn't that be a kick? An Enterprise COBOL compatible compiler which produced Java byte code. That would likely sell a lot of zAAPs. Don't think it hasn't been seriously considered by more than one party... But as with any number of other such approaches, it would be limited by its own success. If it managed to displace any significant amount of IBM revenue by shifting legacy workloads to cheaper processors, IBM would put a stop to it, either technically or by new Ts Cs of some sort. Tony H. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
I imagine one could use Micro Focus COBOL and its JVM support. I suppose mainframe file I/O might be a problem, though. There's also this: http://www.veryant.com/products/iscobol/cobol-compiler.php. There was also one called PERCobol from LegacyJ, but I can't find their website, so it may have gone the way of the dodo. I've not tried any of them. From: Tony Harminc t...@harminc.net To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, January 22, 2014 1:14 PM Subject: Re: Resistance to Java. On 22 January 2014 08:36, John McKown john.archie.mck...@gmail.com wrote: Now wouldn't that be a kick? An Enterprise COBOL compatible compiler which produced Java byte code. That would likely sell a lot of zAAPs. Don't think it hasn't been seriously considered by more than one party... But as with any number of other such approaches, it would be limited by its own success. If it managed to displace any significant amount of IBM revenue by shifting legacy workloads to cheaper processors, IBM would put a stop to it, either technically or by new Ts Cs of some sort. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
What of GNU COBOL? Is free. Graham Hobbs On 22/01/2014 4:48 PM, Frank Swarbrick wrote: I imagine one could use Micro Focus COBOL and its JVM support. I suppose mainframe file I/O might be a problem, though. There's also this: http://www.veryant.com/products/iscobol/cobol-compiler.php. There was also one called PERCobol from LegacyJ, but I can't find their website, so it may have gone the way of the dodo. I've not tried any of them. From: Tony Harminc t...@harminc.net To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, January 22, 2014 1:14 PM Subject: Re: Resistance to Java. On 22 January 2014 08:36, John McKown john.archie.mck...@gmail.com wrote: Now wouldn't that be a kick? An Enterprise COBOL compatible compiler which produced Java byte code. That would likely sell a lot of zAAPs. Don't think it hasn't been seriously considered by more than one party... But as with any number of other such approaches, it would be limited by its own success. If it managed to displace any significant amount of IBM revenue by shifting legacy workloads to cheaper processors, IBM would put a stop to it, either technically or by new Ts Cs of some sort. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
http://sourceforge.net/projects/universalcobol/ On 22 January 2014 22:41, Graham Hobbs gho...@cdpwise.net wrote: What of GNU COBOL? Is free. Graham Hobbs On 22/01/2014 4:48 PM, Frank Swarbrick wrote: I imagine one could use Micro Focus COBOL and its JVM support. I suppose mainframe file I/O might be a problem, though. There's also this: http://www.veryant.com/products/iscobol/cobol- compiler.php. There was also one called PERCobol from LegacyJ, but I can't find their website, so it may have gone the way of the dodo. I've not tried any of them. From: Tony Harminc t...@harminc.net To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, January 22, 2014 1:14 PM Subject: Re: Resistance to Java. On 22 January 2014 08:36, John McKown john.archie.mck...@gmail.com wrote: Now wouldn't that be a kick? An Enterprise COBOL compatible compiler which produced Java byte code. That would likely sell a lot of zAAPs. Don't think it hasn't been seriously considered by more than one party... But as with any number of other such approaches, it would be limited by its own success. If it managed to displace any significant amount of IBM revenue by shifting legacy workloads to cheaper processors, IBM would put a stop to it, either technically or by new Ts Cs of some sort. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
I'm going to look at that. Not for z/OS use, but for me on my Linux/Intel system. On Wed, Jan 22, 2014 at 5:22 PM, Graham Harris harris...@gmail.com wrote: http://sourceforge.net/projects/universalcobol/ -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
Is Graham Harris talking about what I use? Haven't got time to dig. If you mean the GNU COBOL compiler, I installed it on a W7. Partial agony, but it works well, no CICS emulation yet. BUT for you Linuxy types all the gurus there are that way inclined:-). URL I access is http://sourceforge.net/p/open-cobol/discussion/ Graham On 22/01/2014 7:34 PM, John McKown wrote: I'm going to look at that. Not for z/OS use, but for me on my Linux/Intel system. On Wed, Jan 22, 2014 at 5:22 PM, Graham Harris harris...@gmail.com wrote: http://sourceforge.net/projects/universalcobol/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
On 22 January 2014 19:34, John McKown john.archie.mck...@gmail.com wrote: I'm going to look at that. Not for z/OS use, but for me on my Linux/Intel system. On Wed, Jan 22, 2014 at 5:22 PM, Graham Harris harris...@gmail.com wrote: http://sourceforge.net/projects/universalcobol/ As it says on that page, dated five years ago, Initial checkin. It all appears to compile, but doesn't run at the moment. Not to say it mightn't be fun to play with. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
To my knowledge it does not compile to JVM bytecode. From: Graham Hobbs gho...@cdpwise.net To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, January 22, 2014 3:41 PM Subject: Re: Resistance to Java. What of GNU COBOL? Is free. Graham Hobbs On 22/01/2014 4:48 PM, Frank Swarbrick wrote: I imagine one could use Micro Focus COBOL and its JVM support. I suppose mainframe file I/O might be a problem, though. There's also this: http://www.veryant.com/products/iscobol/cobol-compiler.php. There was also one called PERCobol from LegacyJ, but I can't find their website, so it may have gone the way of the dodo. I've not tried any of them. From: Tony Harminc t...@harminc.net To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, January 22, 2014 1:14 PM Subject: Re: Resistance to Java. On 22 January 2014 08:36, John McKown john.archie.mck...@gmail.com wrote: Now wouldn't that be a kick? An Enterprise COBOL compatible compiler which produced Java byte code. That would likely sell a lot of zAAPs. Don't think it hasn't been seriously considered by more than one party... But as with any number of other such approaches, it would be limited by its own success. If it managed to displace any significant amount of IBM revenue by shifting legacy workloads to cheaper processors, IBM would put a stop to it, either technically or by new Ts Cs of some sort. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
http://www.z390.org/ CICS emulation, BC12 user instruction emulation, z/OS 1.13 user macro emulation. No actual IBM code. On Wed, Jan 22, 2014 at 6:55 PM, Graham Hobbs gho...@cdpwise.net wrote: Is Graham Harris talking about what I use? Haven't got time to dig. If you mean the GNU COBOL compiler, I installed it on a W7. Partial agony, but it works well, no CICS emulation yet. BUT for you Linuxy types all the gurus there are that way inclined:-). URL I access is http://sourceforge.net/p/open-cobol/discussion/ Graham On 22/01/2014 7:34 PM, John McKown wrote: I'm going to look at that. Not for z/OS use, but for me on my Linux/Intel system. On Wed, Jan 22, 2014 at 5:22 PM, Graham Harris harris...@gmail.com wrote: http://sourceforge.net/projects/universalcobol/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Resistance to Java.
This is a curiosity question. I am wondering how resistant shops are to even having the Java JDK installed on their system. Not in being resistant to writing application code in Java, but just to having it available. In particular, are there many shops who would reject a useful product because it was written in Java versus in C, C++, or some other language? The only reason that I can think of that they would reject Java is due to the high CPU needed versus C or whatever. I would _assume_ that a shop with a zAAP (or zIIP for zAAP on zIIP) would not be resistant, and maybe even glad, to have Java because it could offload work from the general CPs onto the full speed zIIP or zAAP processor. Or am I wander about in a daze again? -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
On 21 January 2014 13:39, John McKown john.archie.mck...@gmail.com wrote: This is a curiosity question. I am wondering how resistant shops are to even having the Java JDK installed on their system. Not in being resistant to writing application code in Java, but just to having it available. In particular, are there many shops who would reject a useful product because it was written in Java versus in C, C++, or some other language? Two quite separate questions, since you can do all your compiles on the desktop or wherever, and just run on the z. I don't work at a z production shop, so regardless, I have no idea what the answers are. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
On 22/01/2014 2:39 AM, John McKown wrote: This is a curiosity question. I am wondering how resistant shops are to even having the Java JDK installed on their system. Not in being resistant to writing application code in Java, but just to having it available. In particular, are there many shops who would reject a useful product because it was written in Java versus in C, C++, or some other language? The only reason that I can think of that they would reject Java is due to the high CPU needed versus C or whatever. I would _assume_ that a shop with a zAAP (or zIIP for zAAP on zIIP) would not be resistant, and maybe even glad, to have Java because it could offload work from the general CPs onto the full speed zIIP or zAAP processor. Of course, if you don't have a zIIP you wouldn't go near it with a ten foot barge pole. I've never been of fan of Java the language. IMO, C# was Java done properly. The JVM is another matter. The original designers of Java got it right separating the language from the runtime. It means I have the choice of lots of much nicer languages like Javascript, Jython, JRuby, Groovy, Clojure and my particular favorite Scala. Or am I wander about in a daze again? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
