I saw no mention of either COBOL or TSO. A potentially good thing. The caveat is that such would be used only in support of the qualifying application. Reasonable, since that LPAR would be running only qualified applications in the first place.
I saw nothing that precludes existing applications. The only requirement was that the application be commercially offered (and supported) on certain other platforms. In house applications would not be eligible. But, as another noted, the devil is in the details. I daresay that there might be some changes as IBM starts to receive feedback form the customer community. IBM's marketing folks don't seem to have a good feel for how data centers actually operate and the realities of the management process. My overall take is positive. But we shall see. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Timothy Sipples Sent: Thursday, January 11, 2007 3:12 AM To: [email protected] Subject: Re: zNALC in an LPAR and z/VSE V4 Sub-Capacity Pricing On the question of "Is COBOL eligible?" for zNALC, yes, it is possible as I read it. For example, let's suppose you're going to buy a new core banking application, and you choose FNS BANCS to pick a random example. My understanding is that FNS BANCS is technically capable of running in a CICS/DB2 environment or on UNIX boxes. It's COBOL-based. Assuming FNS BANCS appears on the eligible new workload list, there you are. (Apparently doesn't work if you're already running BANCS, though, unless you're moving it from UNIX.) I would also expect there would be cases where an eligible application has Java components and then uses COBOL for batch. (That's a fairly common split for enterprise line-of-business applications.) Again, if it's on the list, you can choose zNALC. Then there are middleware products that support COBOL. WebSphere Application Server for z/OS is one example. Did you know you can run COBOL inside WAS? Yep. Technically possible, anyway. Another one that I can think of is WebSphere Message Broker for z/OS -- I believe there are ways to write compute nodes in COBOL. Move some Oracle databases to z/OS from UNIX and you can write some new COBOL stored procedures or batch alongside it, looks like. Like anything else both the spirit and the letter of the rules are important. It's important to adhere to both. This zNALC looks like a good way to get rid of a bunch of complexity and to expand the universe of eligible workloads at least a bit. It also gets away from technical definitions and moves into more business-oriented definitions. It's not model-specific, so I don't have weird things like trying to figure out how to upgrade from a z890 to a z9 EC and growing z/OS.e. The z/VSE V4 stuff is also really nice because I don't have weird conditions where I have to fence VSE on a separate box if I'm also a z/OS shop (as one small example). Testing should be simplified: some shops were considering z/OS.e to require its own unique (and near 100% redundant) testing. And, to be totally selfish, this also makes my personal z800 mainframe that I configured with z/OS.e that much more interesting with zNALC. :-) It's also aimed squarely at the UNIX and Windows servers: shift that workload to z/OS and you've got a zNALC benefit. I'll have to dig deeper, but I think that even includes work that moved from mainframe to UNIX or Windows in the past. I'm still digesting all this, but it looks like a positive development. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [EMAIL PROTECTED] NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
