On 23 Jan 2009 17:43:53 -0800, in bit.listserv.ibm-main you wrote: >Tom Ross wrote: >> XML features of COBOL have been the most quickly adopted new features of >> COBOL in my 25 years of IBM COBOL development. We shipped AMODE 31 in >> 1984, Intrinsic Functions in 1991, OO in 1995, but many users are still >> running below the line, don't use built-in functions, never tried OO, and >> are not even using EVALUATE or END-IF. On the other hand, just a few weeks >> after we shipped XML PARSE support (yes, XML parsing done directly by >> the COBOL object program) we had customers telling us "This is great, >> when can I do a validating parse against a DTD?". The month after we >> shipped XML GENERATE, we had similar requests for more function. There >> are thousands of z/OS COBOL programs producing and processing XML >> documents today! We can't keep up with demand. > >I too was surprised to hear the "Why XML for COBOL" question. I'm glad >your support has been so well accepted. XML adoption is important to the >future of our platform. > >> On the other hand, >> we know that we need to do AMODE 64 COBOL someday, but not one customer >> has asked IBM COBOL development to do it yet. >> > >I find that difficult to believe. Perhaps the validity of your assertion >depends on one's definition of the word "asked".
As the person who started this, unfortunately I can believe it. 64 bit is a "techie" thing and thus in the background. XML is something management is told they need to have in order to communicate with their customers or suppliers. What I find interesting is that calls to existing packages and functions were not adequate to do all of the things that are being built into IBM COBOL. It shows what I don't know about XML (everything). In one sense as someone who is sem-retired, I have no vested interest other than as someone who believes that COBOL still MAY have a future. My belief is that in order for that future to exist, COBOL programs or routines have to be able to exist in a 64 bit Websphere address space, communicate with 64 bit Java and take advantage of 64 bit DB2. If C/C++ can be mixed mode 31/64, then COBOL needs to be 31/64. If an address space must be either all 31 or all 64, then mixed mode doesn't become valuable until there is need for mode mixing within the run unit. Basically COBOL programs need to be able to live nicely in the newer environments and be able to integrate day zero. In one sense, IBM by not having invested in 64 bit were stating that Websphere and other new environments were going to be used by packages written for 64 bit in C/C++, Java or proprietary languages and COBOL was going to fade away. This is certainly the view of at least one poster on comp.lang.cobol who has found C# far superior to COBOL for the things he needs to do. He is predicting COBOL will be virtually dead by 2015 and I tend to agree with him. I see most new development being done in other languages and much of the current inventory being replaced by packages, most of which are not in COBOL. Incidentally, I also believe that COBOL needed to support a BIT data type and that the 2002 standard is only finally recognizing that business applications do have files with bit switches. I had to deal with bit switches (and wrote assembler pack and unpack byte routines) for use with customer, product and open account files over 40 years ago. Thus I find it frustrating that IBM has not implemented USAGE BIT and the related logical operations. I also consider the work around for dealing with floating point from Java frustrating. ---------------------------------------------------------------------- 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
