John McKown writes: >A zAAP runs only JVM based code. The z/OS XML System Services can exploit zAAP as well, and thus many software products and applications which use the XML System Services can exploit zAAP. DB2 9's XML processing is one example.
>My desire, perhaps insane, is to migrate some code for >COBOL/CICS to Java/Websphere (or Tomcat or Jboss). Let me put it this way: that is generally not anywhere near the first and best investment (time and/or other resources) your organization could make. It's very typically a deeply negative return on investment, in fact. Code development/redevelopment (and testing) is very high on the list of most expensive IT investments you can make, in any language. Moreover, COBOL applications are typically very efficient, and how would that migration influence peak monthly MSUs? If it did, they would probably increase. Nothing *wrong* with that at all, but peak MSU increases imply some incremental costs, and so that cost increase should be justified. And I'd say exactly the same thing when talking about adding distributed servers, hubs and routers, disk and tape, software licenses, expanding data centers, adding IT staff, or any other increase in IT expenditures on or off the mainframe. Increasing costs is not a bad thing provided the benefits to the business outweigh the costs, and provided the project is undertaken most efficiently. That said, for delivering *new* business functions (or possibly a significantly updated function where the existing function has fundamentally diverged from the business function requirement), you have a tremendous "painter's pallete" with a rainbow of colors to choose from. One of those many colors is Enterprise COBOL V-latest and all the wonderful new things it does. Billions of lines of COBOL are being added to the world's enterprise application portfolio every year. Another one of those many colors is Java, in all its forms. (I happen to be very fond of JCICS, as an example -- something you also already have. It's very useful in many situations.) Yet another one of those many colors is *not* coding at all. The variety and scope of middleware functionality has exploded (and continues to grow), so stuff you had to write last year or a decade ago is often quite absurd to code today. Again, you already have some middleware (e.g. CICS Transaction Server), and newer versions have new functions (e.g. the Service Flow Feature) which neatly (and often with strongly favorable economics) eliminate much of the need to code. There may be also strong reasons to "buy" rather than "build." Fewer and fewer new business function delivery requirements should be coding problems as time and technology marches on. ....I can suggest a sane alternative: seek out existing Java workloads running elsewhere (i.e. on other servers) that have strong "affinities" with what's already running on your mainframe. Or, put more simply, what Java application components (EJBs, etc.) are out there in your organization's application portfolio that interact with CICS, DB2, or other mainframe-based applications and databases? Pick the most "mainframe chatty" couple or three first, particularly the ones that do lots of updates (writes), and try relocating them to z/OS (and to zAAP -- or perhaps zAAP-on-zIIP if you're ready). That's probably the first and best place to invest for highest return, within the domain of pre-existing Java code. Another good place to look for cost savings and service delivery improvement is in the largest "N-tier" applications your organization runs, where N is a large number. Collapse the physical tiers through consolidation, and establish a medium-term strategy to rationalize (and probably collapse) the logical tiers as well. Find out what is causing tier proliferation -- often failure to implement industry-standard application and data interfaces on the mainframe (and in "enterprise bus" form), which are often already present but unused, as one bad pattern -- and fix that, too. I'm familiar with a large bank that has implemented a (not very functional) Internet banking application. A customer's account balance (to pick a simple example) is stored in DB2 and accessible through a CICS transaction. Simple, right? Yet somehow this bank's IT team had managed to install 10+ physical server tiers (clustered, server farmed, triplicated, etc.) for Internet banking. The only communication with CICS is via an LU0 "straw." Sure, I suppose that "works," but what ends up happening is that 99+% of the Internet banking function gets developed and deployed elsewhere to try to work around the highly inconvenient (for the Internet banking developers) LU0 interface. Expensive? Difficult to manage? Prone to service quality problems? Insecure? Yes, those high N-tier application deployments are routinely all of that. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Based in Tokyo, Serving IBM Japan / Asia-Pacific E-Mail: timothy.sipp...@us.ibm.com ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
