(fwd) RE: IBM Announces WebSphere Application Server V6.1 for z/OS
Clark Morris wrote: I find not having an email address for contact to be a turn-off. Me too, but I imagine it's done for the same reason IBM-MAIN chooses to hide e-mail addresses when viewed from the Web: as an anti-spam measure. Such is the world we live in. :-( 3. What is the Integrated Development Environment for z/OS? Is it ISPF under TSO, Websphere or other? Both. Lately IBM is actively promoting the Eclipse-based WebSphere Developer for zSeries (WDz), although IBM acquired SPIFFY a.k.a. IBM ISPF Productivity Tool. I would recommend WDz if you're doing extensive work with XML, to pick one example, and new developers will probably gravitate to WDz. However, use whichever makes you (personally) most productive. That might even be both. 4. When are the basic limits in entity naming going to be expanded? 8 bytes looks ludicrous to those used to other environments. As internationalization becomes more important, Unicode and an expanded character set will be needed just to keep z/OS from looking crippled compared to what I have today on my Windows 98 PC. These limits make for confusion as the number of concurrent tasks grow on our systems. I think I agree, but HFS and zFS have been around for quite a long time now, and You.CAN-Name.AnY.File-_Something.Ridiculous. :-) (Head to zFS, though. HFS is beginning its waning years.) Windows still has short name (8.3) support, by the way. It'll probably be there just about forever so older applications don't break. In a semi-related area, DB2 V8 increased the length of column names among other entities. - - - - - Timothy F. Sipples Consulting Enterprise Software Architect, z9/zSeries IBM Japan, Ltd. E-Mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
(fwd) RE: IBM Announces WebSphere Application Server V6.1 for z/OS
On 13 Apr 2006 05:36:13 -0700, in bit.listserv.ibm-main [EMAIL PROTECTED] (Bob Shannon) wrote: We have not heard of any customers requiring 64-bit addressing in COBOL programs. If you have a need for that, please send your requirements to us with details about why 31-bit addressing is not enough. Please use the Contact z/OS link below. This answer shows that the responders neither understand the problem nor the strategic implications. Most if not all existing COBOL programs by themselves are not in any need of 64 bit addressing. So have you sent your comments to the link mentioned or not? I am going to cut and paste my comments below to the online form they provide. I find not having an email address for contact to be a turn-off. While I will be getting hooked up to the high speed in my house when I upgrade my computer, I find online forms not conducive to sending anything other than short messages which don't require much thought. Bob Shannon I am semi-retired (collecting pensions but could be tempted by money) MVS systems programmer, COBOL programmer analyst, and SHARE participant. I still have an interest in the future of z/OS and the future of COBOL. The following concerns assume that there is a business rationale for keeping z/OS as a premier system and that it is worth making major expenditures to move it into new areas. 1. Enterprise COBOL is not being enhanced to generate code for a 64 bit world using XPlink and is not even being given true IEEE floating point. In this case the enhancement should not be driven by customer request but by IBM strategy. If there is a business case for retaining COBOL code and moving it into the Websphere arena, etc., then it makes no sense to add overhead in Java invocations to and from COBOL. It makes no sense to add overhead in a 64 bit Websphere environment or even worse to restrict COBOL routines to the 31 bit environment. There is a way to add IEEE floating point to existing programs while leaving hex floating point alone and that is SIMPLY IMPLEMENT the 2002 COBOL Standard. See existing SHARE requirements for details. 2. It was short sighted and parochial 20+ years ago not to implement Fixed Block Architecture in MVS and lack of it is even more limiting today. Does it really make sense to limit a mainframe volume to 54 gigabytes allocated in an arcane manner when we can get laptops with 100 gigabyte drives and terabyte drives are being announced for desktops. FBA devices don't have to support BDAM, BPAM or even QSAM files. They only have to support those data set types that are being carried forward. They have to support PDSE, VSAM and the various Unix like file systems, not necessarily mixed on the same volume. SYS1.NUCLEUS could be made a part of a 1 gigabyte IPL text (100 megabytes to n gigabytes actually for all that anyone would really care). We need to be able to have the same logical access with at most a recompile of our higher level language programs (COBOL, PL1, C/C++, BAP from SAP, etc.) and a utility copy of the file. We need mechanisms which do a better job of allocating space than the current VSAM mechanisms (hopefully the SMS basic mechanisms are better but somehow there is enough arcanity in even them that SMS is not as universal as I would hope). We need storage management that can be applied to the systems volumes as well as the applications volumes. 3. What is the Integrated Development Environment for z/OS? Is it ISPF under TSO, Websphere or other? 4. When are the basic limits in entity naming going to be expanded? 8 bytes looks ludicrous to those used to other environments. As internationalization becomes more important, Unicode and an expanded character set will be needed just to keep z/OS from looking crippled compared to what I have today on my Windows 98 PC. These limits make for confusion as the number of concurrent tasks grow on our systems. 5. Does SMP/E currently support being able to use RECEIVE, APPLY, ACCEPT for all maintenance and does it finally recognize such things as Dialog Tag Language Compiling in ISPF? One of my frustrations in the early 1990's was the amount of work that had to be done outside of SMP to support ISPF performance optimization (panel prepping, etc.). The maintenance process seems much improved from what I see on ibm-main and at SHARE conferences but I still have the feeling that it hasn't fully come to grips with the Unix side. In closing, back when I was in systems programming, an applications person claimed I was the systems janitor because I was doing such things as watching disk space usage and getting them to clean up unused files. I agreed with the characterization and thus my interest in the plumbing in regard to the future of z/OS. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search
Re: IBM Announces WebSphere Application Server V6.1 for z/OS
On 12 Apr 2006 21:45:26 -0700, [EMAIL PROTECTED] (Timothy Sipples) wrote: Clark Morris writes: So will you be able to compile COBOL programs that can run in 64 bit mode inside of Websphere? Can they interoperate with JAVA and will they finally recognize IEEE floating point so that NO conversions are needed to work with JAVA. Really good questions. All I know at this point is that IBM provided a technology preview (starting a couple years ago) describing how you could compile COBOL in such a way as to run as EJBs inside WebSphere Application Server for z/OS. You had to follow certain rules (thread-safe, extreme care in how to do I/O, etc.), but it's an intriguing technology. Before anyone asks, no, I don't have the reference for this technology. IBM may be hiding the information now -- it's not popping up in my searches of the IBM Internet Web sites. Talk with your friendly local WebSphere and/or mainframe specialist about it. Just because it's possible doesn't mean it's necessarily a good idea, especially post-zAAP. As you might know, here's what IBM is officially saying about 64-bit COBOL: - - - - - http://www-03.ibm.com/servers/eserver/zseries/zos/installation/zos_cobol_faqs.html Question: Will there be a version of COBOL and/or the BINDER that will create 64-bit COBOL load modules to run under z/OS? Answer: We have no plans for 64-bit addressing support in COBOL. The BINDER already supports 64-bit assembler programs and will support 64-bit C/C++ programs in the future. We have not heard of any customers requiring 64-bit addressing in COBOL programs. If you have a need for that, please send your requirements to us with details about why 31-bit addressing is not enough. Please use the Contact z/OS link below. This answer shows that the responders neither understand the problem nor the strategic implications. Most if not all existing COBOL programs by themselves are not in any need of 64 bit addressing. However as data requirements expand (take a look at the maximum size data area expansion in Enterprise COBOL) and the number of data areas for a COBOL routine within an instance expand (Websphere, CICS region, etc.) the pressure for COBOL to have data areas that can live above the BAR will grow. This in most ways is transparent to the COBOL application and is driven by IBM strategy. Failure to be able to exist in a 64 bit environment eventually will introduce limitations in use and a requirement to rewrite in some other language. In short COBOL developers see no need to play nice in the new world. - - - - - Now, is this a problem (with respect to the COBOL EJB technology preview)? I don't know, but it's interesting that we'll have both 31-bit and 64-bit Java support in the same WebSphere Application Server release. I was thinking in terms of how it'd be useful for smooth Java migration (especially for ultra-cautious customers), but COBOL interoperability (with COBOL EJBs) might be another such area. If you're working with the COBOL EJB technology then I would check with your IBM contact on that to see what he/she says. I guess we'll all find out more as the 64-bit delivery gets closer how this all fits together in the various mixed-mode permutations. It's a little early for me yet. My educated guess is that it will be very flexible. With respect to the IEEE floating point question, obviously the current situation functions just fine, but I think you're referring to a question of overhead and efficiency (which I get the impression is good, but engineers always look for better). I believe the official line on this is, We understand. For slightly less official information I'd recommend SHARE forums, possibly combined with alcohol. :-) Again, there are certain boundary conditions where the floating points don't translate but the basic issue is why should we have to put up with the overhead of translation of parameters that from the COBOL point of view are NEW with the Java interface. There has been since 2002 an ANSI/ISO approved way to add IEEE floating point to COBOL. And to others, there are SHARE requirements on record requesting all of these with justifications that include the points that I have just made. - - - - - Timothy F. Sipples Consulting Enterprise Software Architect, z9/zSeries IBM Japan, Ltd. E-Mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM Announces WebSphere Application Server V6.1 for z/OS
We have not heard of any customers requiring 64-bit addressing in COBOL programs. If you have a need for that, please send your requirements to us with details about why 31-bit addressing is not enough. Please use the Contact z/OS link below. This answer shows that the responders neither understand the problem nor the strategic implications. Most if not all existing COBOL programs by themselves are not in any need of 64 bit addressing. So have you sent your comments to the link mentioned or not? Bob Shannon -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM Announces WebSphere Application Server V6.1 for z/OS
Timothy, I don't see the SOD re: Apache in the referenced announcement. Can you provide a link? Thanks, Kirk Wolf On 4/11/06, Timothy Sipples [EMAIL PROTECTED] wrote: Version 6.1 announced today. Details here: http://www.ibm.com/common/ssi/rep_ca/7/897/ENUS206-077/ENUS206-077.PDF GA date is June 30, 2006. I'm still quickly reading through the announcement, but there are lots of interesting bits: 1. This release promises 64-bit support, although that support will be delivered post-GA (in a PTF, presumably). So WebSphere follows DB2 as the second major z/OS subsystem to fully exercise 64-bit z/Architecture. What's interesting (speculation mode here) is that it might be possible to mix and match 31-bit and 64-bit WebSphere instances on the same system with this release, and I could see how that would be useful. I guess we'll have to wait and see. 2. Probably because of the 64-bit Java support this WebSphere release will require a minimum of z/OS 1.6. (It also happens that zAAPs require 1.6 or higher, although this will be the third WebSphere release to support zAAPs.) 3. This release will use the new Java V5 (a.k.a. 1.5) for z/OS, announced in November. 4. There's a statement of direction that IBM will deliver an Apache-derived HTTP server for z/OS designed to work with this release of WebSphere Application Server. The current IBM HTTP Server for z/OS is perfectly fine for the majority, but we had some customers asking for Apache-derived code, so this announcement indicates it's coming. 5. The Linux on z9/zSeries version (and other platforms) also got announced today. (See http://www.ibm.com/common/ssi/rep_ca/6/897/ENUS206-076/ENUS206-076.PDF for details.) The Linux version is upgraded to 64-bit and will be available in 64-bit mode for electronic delivery on May 26, 2006. (The 31-bit version will also be available.) I know some shops run both z/OS and Linux on z9/zSeries, so this schedule means you can get going immediately with the new 64-bit support for development then roll through testing and into production on Linux, z/OS, or both. - - - - - Timothy F. Sipples Consulting Enterprise Software Architect, z9/zSeries IBM Japan, Ltd. E-Mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM Announces WebSphere Application Server V6.1 for z/OS
Page six of the referenced link, left side, bulleted item: IBM currently intends to deliver the following items for WebSphere Application Server for z/OS, V6.1 in a post GA timeframe: - 64-bit enablement for WebSphere Application Server for z/OS - A Web server for z/OS, powered by Apache for use with WebSphere Application Server for z/OS At the time IBM releases this new function, a new z/OS announcement will be provided. Part of the Statement of Direction begun on page 5. Aaron On Wed, 12 Apr 2006 07:44:31 -0500, Kirk Wolf [EMAIL PROTECTED] wrote: Timothy, I don't see the SOD re: Apache in the referenced announcement. Can you provide a link? Thanks, Kirk Wolf On 4/11/06, Timothy Sipples [EMAIL PROTECTED] wrote: Version 6.1 announced today. Details here: http://www.ibm.com/common/ssi/rep_ca/7/897/ENUS206-077/ENUS206-077.PDF -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM Announces WebSphere Application Server V6.1 for z/OS
Kirk Wolf writes: I don't see the SOD re: Apache in the referenced announcement. Can you provide a link? It's on page 6 (left hand column, about 40% from the top) in the announcement letter: http://www.ibm.com/common/ssi/rep_ca/7/897/ENUS206-077/ENUS206-077.PDF Just search on Apache if you cannot find it easily and it'll pop up (as the second hit, I think). Hope that helps! - - - - - Timothy F. Sipples Consulting Enterprise Software Architect, z9/zSeries IBM Japan, Ltd. E-Mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM Announces WebSphere Application Server V6.1 for z/OS
Clark Morris writes: So will you be able to compile COBOL programs that can run in 64 bit mode inside of Websphere? Can they interoperate with JAVA and will they finally recognize IEEE floating point so that NO conversions are needed to work with JAVA. Really good questions. All I know at this point is that IBM provided a technology preview (starting a couple years ago) describing how you could compile COBOL in such a way as to run as EJBs inside WebSphere Application Server for z/OS. You had to follow certain rules (thread-safe, extreme care in how to do I/O, etc.), but it's an intriguing technology. Before anyone asks, no, I don't have the reference for this technology. IBM may be hiding the information now -- it's not popping up in my searches of the IBM Internet Web sites. Talk with your friendly local WebSphere and/or mainframe specialist about it. Just because it's possible doesn't mean it's necessarily a good idea, especially post-zAAP. As you might know, here's what IBM is officially saying about 64-bit COBOL: - - - - - http://www-03.ibm.com/servers/eserver/zseries/zos/installation/zos_cobol_faqs.html Question: Will there be a version of COBOL and/or the BINDER that will create 64-bit COBOL load modules to run under z/OS? Answer: We have no plans for 64-bit addressing support in COBOL. The BINDER already supports 64-bit assembler programs and will support 64-bit C/C++ programs in the future. We have not heard of any customers requiring 64-bit addressing in COBOL programs. If you have a need for that, please send your requirements to us with details about why 31-bit addressing is not enough. Please use the Contact z/OS link below. - - - - - Now, is this a problem (with respect to the COBOL EJB technology preview)? I don't know, but it's interesting that we'll have both 31-bit and 64-bit Java support in the same WebSphere Application Server release. I was thinking in terms of how it'd be useful for smooth Java migration (especially for ultra-cautious customers), but COBOL interoperability (with COBOL EJBs) might be another such area. If you're working with the COBOL EJB technology then I would check with your IBM contact on that to see what he/she says. I guess we'll all find out more as the 64-bit delivery gets closer how this all fits together in the various mixed-mode permutations. It's a little early for me yet. My educated guess is that it will be very flexible. With respect to the IEEE floating point question, obviously the current situation functions just fine, but I think you're referring to a question of overhead and efficiency (which I get the impression is good, but engineers always look for better). I believe the official line on this is, We understand. For slightly less official information I'd recommend SHARE forums, possibly combined with alcohol. :-) - - - - - Timothy F. Sipples Consulting Enterprise Software Architect, z9/zSeries IBM Japan, Ltd. E-Mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
