Re: Fw: COBOL and Floating Point (was: SHARE Session 8194: z390 and zcobol Portable Mainframe COBOL Compiler written in structured macro assembler
On 9 Jan 2009 08:26:20 -0800, in bit.listserv.ibm-main you wrote: Clark, When you bring up Java, this confuses me. Currently IBM does all the required conversion for floating point items shared between COBOL and Java in a z/OS environment. Do you have real-world evidence that this does isn't working. I assume it works at the cost of unnecessary overhead. *** As far as SHARE requirements go, Requirement SSLNGC0413617, ISO 2002 defined floating point data types from 2004 includes the following information, Again, it is important to state that not all of these reasons are valid for all SHARE installations; some installations would find one or more of these reasons compelling; while other installations would find only a single reason their motivation in setting the priority as it is. Finally, to avoid continuing confusion about whether or not this requirement is asking for IEEE floating point support, a separate requirement (SSLNGC0413621 That requirement currently has a response of RECOGNIZED (the lowest -non-REJECT response). the requirement SSLNGC0413621, COBOL (optional) support for IEEE Floating Point also has a response of RECOGNIZED. My assumption is that IBM is treating the older requirement as against the binary format as the newer requirement SSLNGC07005 COBOL support for Hardware decimal floating point already has an ACCEPT response. As currently written, I would *think* that it would be clear to IBM that this is asking for the ONLY format of IEEE floating point data that was available IN 2004. However, there is nothing in the requirement that actually says that it needs to be old-style binary IEEE floating-point and that the requirement would NOT be met by providing decimal floating point support. I would sincerely hope that the 2002 standard floating point usages would be implemented as binary (IEEE) leaving COMP-1 and COMP-2 for hex floating point (and a COMP-n for longer floating point items). The 2002 standard floating point provides a way for floating point data to described in the same way to COBOL and other languages. I believe that there is a move afoot to provide a standard way in COBOL to handle the new decimal floating point and that is the route that I would want to take. Based on the actual actions by IBM, I believe that they agree with Peter Dashwood who believes COBOL is dying and will be dead by 2015. Peter, who Bill knows, is a major contributor on comp.lang.cobol and COBOL expert who has moved to C#. In regard to the cost of upgrades to at least select parts of the 2002 standard, I believe that the current license fees should more than cover the cost. In many cases they would be needed to enable migration from other platforms to z/OS. They also would be in support of stated IBM goals and directions. Clark Morris cfmpub...@ns.sympatico.ca wrote in message news:6tkem45k95u9c18tmoutc4o98cs772i...@4ax.com... On 7 Jan 2009 15:25:56 -0800, in bit.listserv.ibm-main you wrote: Clark, Easy answer, there have been no recent changes to IBM's responses on floating point (or bit) support. Harder answer is that you keep getting confused about different terms and requirements. In the '02 Standard there are 3 new USAGEs FLOAT-SHORT FLOAT-LONG FLOAT-EXTENDED IBM (or anyone else) *COULD* implement these as any format of floating point they wanted, e.g. FLOAT-SHORT *could* equal COMP-1 and both FLOAT-LONG and FLOAT-EXTENDED *could* equal COMP-2 There is no requirement in the Standard they be implemented in any IEEE format (or any other portable format). There isn't even any requirement that float-extended take more storage than float-long (but it can't be smaller). I understand that IBM could implement these usages as hex floating point. However, this would be short-sighted and shoot self in foot implementation. IBM COBOL already has the requirement to communicate with JAVA which uses IEEE binary floating point. Thus implementing the new usages as IEEE is upward compatible with existing programs and in fact allows them to have both types of floating point in a single program. *** OK, now for the terminology IEEE floating point. I think (but won't swear to it) that you are talking about the OLD (not decimal based) floating point format. Adding support for this would certainly aid in communication with other z/OS languages and facilities that already support this - as well as in handling files created in other environment. Exactly However, before you see that in COBOL, it would be my best guess that IBM is likely to implement the IEEE *decimal* floating-point formats already available in Assembler, PL/I, DB2 and possibly other z/OS languages/facilities. Not only does this seem to be a strategic direction for IBM, but it also provides a data-type that retains COBOL's historic interest in decimal arithmetic accuracy that can be lost in both the traditional IBM hex
Re: COBOL and Floating Point (was: SHARE Session 8194: z390 and zcobol Portable Mainframe COBOL Compiler written in structured macro assembler
On 7 Jan 2009 15:25:56 -0800, in bit.listserv.ibm-main you wrote: Clark, Easy answer, there have been no recent changes to IBM's responses on floating point (or bit) support. Harder answer is that you keep getting confused about different terms and requirements. In the '02 Standard there are 3 new USAGEs FLOAT-SHORT FLOAT-LONG FLOAT-EXTENDED IBM (or anyone else) *COULD* implement these as any format of floating point they wanted, e.g. FLOAT-SHORT *could* equal COMP-1 and both FLOAT-LONG and FLOAT-EXTENDED *could* equal COMP-2 There is no requirement in the Standard they be implemented in any IEEE format (or any other portable format). There isn't even any requirement that float-extended take more storage than float-long (but it can't be smaller). I understand that IBM could implement these usages as hex floating point. However, this would be short-sighted and shoot self in foot implementation. IBM COBOL already has the requirement to communicate with JAVA which uses IEEE binary floating point. Thus implementing the new usages as IEEE is upward compatible with existing programs and in fact allows them to have both types of floating point in a single program. *** OK, now for the terminology IEEE floating point. I think (but won't swear to it) that you are talking about the OLD (not decimal based) floating point format. Adding support for this would certainly aid in communication with other z/OS languages and facilities that already support this - as well as in handling files created in other environment. Exactly However, before you see that in COBOL, it would be my best guess that IBM is likely to implement the IEEE *decimal* floating-point formats already available in Assembler, PL/I, DB2 and possibly other z/OS languages/facilities. Not only does this seem to be a strategic direction for IBM, but it also provides a data-type that retains COBOL's historic interest in decimal arithmetic accuracy that can be lost in both the traditional IBM hex floating point and the older IEEE binary based floating point. Why not do both at the same time. I believe JAVA now has the decimal floating point and JAVA COBOL co-existence was strategic at one point. Maybe the requirements for implementing various of the 2002 standard features should updated to point to JAVA co-existence and IBM strategic directions. While the last time I touched COBOL was late 2006, I would be willing to update any of the requirements I submitted. I certainly do not know when this latter may show up, but I would expect it sooner than later. As far as the older IEEE support, I wouldn't be surprised if that NEVER shows up in COBOL (and I am not positive that there is a requirement that explicitly asks for it). I thought that I submitted one in the 2002 - 2004 time frame. Clark Morris cfmpub...@ns.sympatico.ca wrote in message news:ht7am41ddtc4r8c3cij01vdugok96c4...@4ax.com... On 6 Jan 2009 13:09:50 -0800, in bit.listserv.ibm-main you wrote: for zcobol initial release at SHARE. It doesn't test things like EXEC CICS or Enterprise COBOL extensions such as EXTENDED-FLOAT, but it sure looks like There is no EXTENDED-FLOAT in Enterprise COBOL. There are floating-point data types, COMP-1, COMP-2, and external floating-point. There is a FLOAT-EXTENDED that is a part of the 2002 COBOL Standard that we have not yet implemented in Enterprise COBOL, maybe you are thinking of that? So what is the status of USAGE BIT and the other usages related to the 2002 standard for which there are existing SHARE requirements? Proper implementation of the standard floating point USAGEs (IEEE floating point) would allow COBOL to cleanly communicate with JAVA while leaving any existing COMP-1 and COMP-2 data as hex floating point. And is IBM COBOL going to support the decimal floating point that has been implemented at least on the z series and that was sponsored by IBM? Cheers, TomR COBOL is the Language of the Future! -- 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 -- 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 -- 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
Fw: COBOL and Floating Point (was: SHARE Session 8194: z390 and zcobol Portable Mainframe COBOL Compiler written in structured macro assembler
Clark, When you bring up Java, this confuses me. Currently IBM does all the required conversion for floating point items shared between COBOL and Java in a z/OS environment. Do you have real-world evidence that this does isn't working. *** As far as SHARE requirements go, Requirement SSLNGC0413617, ISO 2002 defined floating point data types from 2004 includes the following information, Again, it is important to state that not all of these reasons are valid for all SHARE installations; some installations would find one or more of these reasons compelling; while other installations would find only a single reason their motivation in setting the priority as it is. Finally, to avoid continuing confusion about whether or not this requirement is asking for IEEE floating point support, a separate requirement (SSLNGC0413621 That requirement currently has a response of RECOGNIZED (the lowest -non-REJECT response). the requirement SSLNGC0413621, COBOL (optional) support for IEEE Floating Point also has a response of RECOGNIZED. My assumption is that IBM is treating the older requirement as against the binary format as the newer requirement SSLNGC07005 COBOL support for Hardware decimal floating point already has an ACCEPT response. As currently written, I would *think* that it would be clear to IBM that this is asking for the ONLY format of IEEE floating point data that was available IN 2004. However, there is nothing in the requirement that actually says that it needs to be old-style binary IEEE floating-point and that the requirement would NOT be met by providing decimal floating point support. Clark Morris cfmpub...@ns.sympatico.ca wrote in message news:6tkem45k95u9c18tmoutc4o98cs772i...@4ax.com... On 7 Jan 2009 15:25:56 -0800, in bit.listserv.ibm-main you wrote: Clark, Easy answer, there have been no recent changes to IBM's responses on floating point (or bit) support. Harder answer is that you keep getting confused about different terms and requirements. In the '02 Standard there are 3 new USAGEs FLOAT-SHORT FLOAT-LONG FLOAT-EXTENDED IBM (or anyone else) *COULD* implement these as any format of floating point they wanted, e.g. FLOAT-SHORT *could* equal COMP-1 and both FLOAT-LONG and FLOAT-EXTENDED *could* equal COMP-2 There is no requirement in the Standard they be implemented in any IEEE format (or any other portable format). There isn't even any requirement that float-extended take more storage than float-long (but it can't be smaller). I understand that IBM could implement these usages as hex floating point. However, this would be short-sighted and shoot self in foot implementation. IBM COBOL already has the requirement to communicate with JAVA which uses IEEE binary floating point. Thus implementing the new usages as IEEE is upward compatible with existing programs and in fact allows them to have both types of floating point in a single program. *** OK, now for the terminology IEEE floating point. I think (but won't swear to it) that you are talking about the OLD (not decimal based) floating point format. Adding support for this would certainly aid in communication with other z/OS languages and facilities that already support this - as well as in handling files created in other environment. Exactly However, before you see that in COBOL, it would be my best guess that IBM is likely to implement the IEEE *decimal* floating-point formats already available in Assembler, PL/I, DB2 and possibly other z/OS languages/facilities. Not only does this seem to be a strategic direction for IBM, but it also provides a data-type that retains COBOL's historic interest in decimal arithmetic accuracy that can be lost in both the traditional IBM hex floating point and the older IEEE binary based floating point. Why not do both at the same time. I believe JAVA now has the decimal floating point and JAVA COBOL co-existence was strategic at one point. Maybe the requirements for implementing various of the 2002 standard features should updated to point to JAVA co-existence and IBM strategic directions. While the last time I touched COBOL was late 2006, I would be willing to update any of the requirements I submitted. I certainly do not know when this latter may show up, but I would expect it sooner than later. As far as the older IEEE support, I wouldn't be surprised if that NEVER shows up in COBOL (and I am not positive that there is a requirement that explicitly asks for it). I thought that I submitted one in the 2002 - 2004 time frame. Clark Morris cfmpub...@ns.sympatico.ca wrote in message news:ht7am41ddtc4r8c3cij01vdugok96c4...@4ax.com... On 6 Jan 2009 13:09:50 -0800, in bit.listserv.ibm-main you wrote: for zcobol initial release at SHARE. It doesn't test things like EXEC CICS or Enterprise COBOL extensions such as EXTENDED-FLOAT, but it sure looks like
Re: SHARE Session 8194: z390 and zcobol Portable Mainframe COBOL Compiler written in structured macro assembler
Hi Tim We've met at several of your COBOL SHARE sessions in the past, and I hope to see you in Austin. You are correct, zcobol first release will have FLOAT-SHORT, FLOAT-LONG, and FLOAT-EXTENDED usage options with global option to choose between HFP, BFP, or DFP with DFP as the default. Some might want HFP for compatibility with older COBOL compiler results. Some might want BFP for IEEE compatibility with floating point in other target execution language environments. I think DFP is the preferred choice barring other constraints since it gives precise decimal results up to 34 digits. Don Higgins d...@higgins.net www.zcobol.org -- 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
Re: SHARE Session 8194: z390 and zcobol Portable Mainframe COBOL Compiler written in structured macro assembler
On 6 Jan 2009 13:09:50 -0800, in bit.listserv.ibm-main you wrote: for zcobol initial release at SHARE. It doesn't test things like EXEC CICS or Enterprise COBOL extensions such as EXTENDED-FLOAT, but it sure looks like There is no EXTENDED-FLOAT in Enterprise COBOL. There are floating-point data types, COMP-1, COMP-2, and external floating-point. There is a FLOAT-EXTENDED that is a part of the 2002 COBOL Standard that we have not yet implemented in Enterprise COBOL, maybe you are thinking of that? So what is the status of USAGE BIT and the other usages related to the 2002 standard for which there are existing SHARE requirements? Proper implementation of the standard floating point USAGEs (IEEE floating point) would allow COBOL to cleanly communicate with JAVA while leaving any existing COMP-1 and COMP-2 data as hex floating point. And is IBM COBOL going to support the decimal floating point that has been implemented at least on the z series and that was sponsored by IBM? Cheers, TomR COBOL is the Language of the Future! -- 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
COBOL and Floating Point (was: SHARE Session 8194: z390 and zcobol Portable Mainframe COBOL Compiler written in structured macro assembler
Clark, Easy answer, there have been no recent changes to IBM's responses on floating point (or bit) support. Harder answer is that you keep getting confused about different terms and requirements. In the '02 Standard there are 3 new USAGEs FLOAT-SHORT FLOAT-LONG FLOAT-EXTENDED IBM (or anyone else) *COULD* implement these as any format of floating point they wanted, e.g. FLOAT-SHORT *could* equal COMP-1 and both FLOAT-LONG and FLOAT-EXTENDED *could* equal COMP-2 There is no requirement in the Standard they be implemented in any IEEE format (or any other portable format). There isn't even any requirement that float-extended take more storage than float-long (but it can't be smaller). *** OK, now for the terminology IEEE floating point. I think (but won't swear to it) that you are talking about the OLD (not decimal based) floating point format. Adding support for this would certainly aid in communication with other z/OS languages and facilities that already support this - as well as in handling files created in other environment. However, before you see that in COBOL, it would be my best guess that IBM is likely to implement the IEEE *decimal* floating-point formats already available in Assembler, PL/I, DB2 and possibly other z/OS languages/facilities. Not only does this seem to be a strategic direction for IBM, but it also provides a data-type that retains COBOL's historic interest in decimal arithmetic accuracy that can be lost in both the traditional IBM hex floating point and the older IEEE binary based floating point. I certainly do not know when this latter may show up, but I would expect it sooner than later. As far as the older IEEE support, I wouldn't be surprised if that NEVER shows up in COBOL (and I am not positive that there is a requirement that explicitly asks for it). Clark Morris cfmpub...@ns.sympatico.ca wrote in message news:ht7am41ddtc4r8c3cij01vdugok96c4...@4ax.com... On 6 Jan 2009 13:09:50 -0800, in bit.listserv.ibm-main you wrote: for zcobol initial release at SHARE. It doesn't test things like EXEC CICS or Enterprise COBOL extensions such as EXTENDED-FLOAT, but it sure looks like There is no EXTENDED-FLOAT in Enterprise COBOL. There are floating-point data types, COMP-1, COMP-2, and external floating-point. There is a FLOAT-EXTENDED that is a part of the 2002 COBOL Standard that we have not yet implemented in Enterprise COBOL, maybe you are thinking of that? So what is the status of USAGE BIT and the other usages related to the 2002 standard for which there are existing SHARE requirements? Proper implementation of the standard floating point USAGEs (IEEE floating point) would allow COBOL to cleanly communicate with JAVA while leaving any existing COMP-1 and COMP-2 data as hex floating point. And is IBM COBOL going to support the decimal floating point that has been implemented at least on the z series and that was sponsored by IBM? Cheers, TomR COBOL is the Language of the Future! -- 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 -- 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
Re: SHARE Session 8194: z390 and zcobol Portable Mainframe COBOL Compiler written in structured macro assembler
for zcobol initial release at SHARE. It doesn't test things like EXEC CICS or Enterprise COBOL extensions such as EXTENDED-FLOAT, but it sure looks like There is no EXTENDED-FLOAT in Enterprise COBOL. There are floating-point data types, COMP-1, COMP-2, and external floating-point. There is a FLOAT-EXTENDED that is a part of the 2002 COBOL Standard that we have not yet implemented in Enterprise COBOL, maybe you are thinking of that? Cheers, TomR COBOL is the Language of the Future! -- 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
Re: SHARE Session 8194: z390 and zcobol Portable Mainframe COBOL Compiler written in structured macro assembler
John, all Well its flattering to think that IBM, Micro Focus, or Variant all of which have taken an interest in z390, might be interested in trying to buy rights to zcobol. But no offers so far. The plan is still to release zcobol as part of z390 under GPL in time for SHARE presentation on March 3. At the suggestion of Bill Klein, I've started work this week on testing zcobol with the NIST ANSII COBOL 85 tests available here: http://www.itl.nist.gov/div897/ctg/cobol_form.htm It comes in 2 GB z type zip (I used Winzip on Windows) which expands to 28 GB single ascii source file with the first program being EXEC85.CBL (2256 lines) which extracts all the other COBOL test programs. I'll have a report on results for zcobol initial release at SHARE. It doesn't test things like EXEC CICS or Enterprise COBOL extensions such as EXTENDED-FLOAT, but it sure looks like a great test of basic COBOL syntax options such as OPTIONAL on SELECT, comment phases in INSTALLATION, and use of double versus single quotes (now all supported). Don Higgins d...@higgins.net www.zcobol.org -- 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
Re: SHARE Session 8194: z390 and zcobol Portable Mainframe COBOL Compiler written in structured macro assembler
In 495e03bc026d00062...@sinclair.provo.novell.com, on 01/02/2009 at 10:08 AM, Mark Post mp...@novell.com said: Probably not true, assuming the two developers are the only ones who have contributed to the package, and they agree on selling the rights to it. Once they've distributed the software under the GPL they can't stop others from distributing it. However, if they have permission from all of the contributors then they can certainly issue new versions under a different license. Unless someone was willing to maintain the old fork, it might not be as attractive as the new one. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: SHARE Session 8194: z390 and zcobol Portable Mainframe COBOL Compiler written in structured macro assembler
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Tony Harminc [ snip ] My wild guess is that if zcobol looks like a real threat, IBM will just buy it. And maybe that wouldn't be such a bad thing from its developer's point of view... But zcobol is touted as open source. If it is licensed in the way Linux is licensed, then IBM couldn't buy it any more than they can buy Linux. -jc- -- 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
Re: SHARE Session 8194: z390 and zcobol Portable Mainframe COBOL Compiler written in structured macro assembler
On 1/2/2009 at 7:44 AM, Chase, John jch...@ussco.com wrote: -snip- But zcobol is touted as open source. If it is licensed in the way Linux is licensed, then IBM couldn't buy it any more than they can buy Linux. Probably not true, assuming the two developers are the only ones who have contributed to the package, and they agree on selling the rights to it. If other people have contributed, their permission would also be necessary. Obviously as the number of contributors goes up, the likelihood of getting everyone's permission becomes rather dim, which is the case of the Linux kernel. The examples of where such a sale has happened are quite numerous: JBoss, BerkelyDB, MySQL, InnoDB and so on. Mark Post -- 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
Re: SHARE Session 8194: z390 and zcobol Portable Mainframe COBOL Compiler written in structured macro assembler
On Fri, 2 Jan 2009 10:08:28 -0700, Mark Post mp...@novell.com wrote: On 1/2/2009 at 7:44 AM, Chase, John jch...@ussco.com wrote: -snip- But zcobol is touted as open source. If it is licensed in the way Linux is licensed, then IBM couldn't buy it any more than they can buy Linux. Probably not true, assuming the two developers are the only ones who have contributed to the package, and they agree on selling the rights to it. If other people have contributed, their permission would also be necessary. Obviously as the number of contributors goes up, the likelihood of getting everyone's permission becomes rather dim, which is the case of the Linux kernel. The examples of where such a sale has happened are quite numerous: JBoss, BerkelyDB, MySQL, InnoDB and so on. Mark Post True. However, anything that is GPL'ed can be forked. IBM could buy zcobol from the owners. They could then then add proprietary extentions to it and sell it without source code. However, the original zcobol would still be available for others to fork on their own. IOW, IBM could not come to people using the GPL version of zcobol and say either pay us for this version or stop using it immediately! IOW - once a particular version of the code is GPL'ed, then that version is forever GPL'ed. With the permission of the copyright holders an alternate version can be made which is not GPL'ed. IIRC, this sort of thing is what is going on with MySQL. There is still the GPL version in addition to the SUN version. Same with OpenOffice versus StarOffice. -- John -- 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
Re: SHARE Session 8194: z390 and zcobol Portable Mainframe COBOL Compiler written in structured macro assembler
Does this mean that it might be possible to use zcobol to compile some of our current z/OS COBOL programs into Java classes and run them on a zAAP? 3. C++ for Windows platforms 4. HLA/MASM assembler for Intel platforms John Yes, the zcobol framework provides for alternate code generation macro libraries for HLASM, Java, C++, and HLA. And we may add PL/I as well based on request on ASLIST earlier. But understand that the initial release is focused primarily on HLASM code generation and only a few demo COBOL programs will be included which have all the necessary code generation macros to compile the same COBOL program to any of the target language environments. The good news is that when the HLASM support is done, you can copy all the HLASM code generation macros to another target language library and just change the generated code model statements in the structured conditional macro code without having to chanage higher lavel shared COBOL language macros or any logic (Well I'm sure that's an exerageration as the different languages will required some different logic as well but it beats replicating the whole compiler). Don Higgins d...@higgins.net -- 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
Re: SHARE Session 8194: z390 and zcobol Portable Mainframe COBOL Compiler written in structured macro assembler
All of the specialty engines types except zAAP have technological and contractual means of restricting their use to the IBM-desired new workloads. But an engine that runs Java by design in order to attract new work (hopefully from Sun or HP boxes) can't really look at your JVM bytecodes and say this looks like something that was originally written in COBOL so we won't run it, any more than an airline can say you look like a business traveller, so we'll charge you five times the rate your seatmates are paying for this flight. My wild guess is that if zcobol looks like a real threat, IBM will just buy it. And maybe that wouldn't be such a bad thing from its developer's point of view... Tony, all Thanks for the vote of support for zcobol as a tool potentially worth buying. There are no plans to sell it and once it is released under open source GPL license as part of z390 starting March 3, 2009 coinciding with the official announcement and demo at SHARE sesssion 8194, it will be available to everyone including all existing COBOL language tool providers to add to their set of COBOL modernization tools. Of course it helps to know how the tool works, so Melvyn Maltz and I might entertain some contract work going forward to help users and vendors utilize the tool. Right now it is a really exciting and challenging development effort that I look forward to sharing at SHARE. Don Higgins d...@higgins.net -- 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
Re: SHARE Session 8194: z390 and zcobol Portable Mainframe COBOL Compiler written in structured macro assembler
A commercial Cobol compiler that targets Java byte codes have been available for a long time: http://www.legacyj.com/lgcyj_perc1.html As far as I can tell, it runs as pure Java byte codes and on z/OS and would therefore take advantage of zAAP. But, one should contact the company for details. Kirk Wolf Dovetailed Technologies -- 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
SHARE Session 8194: z390 and zcobol Portable Mainframe COBOL Compiler written in structured macro assembler
The last that I heard (which was quite a while ago) if you tried using that product on z/OS, it could work with line sequential (HFS) files but *NOT* with normal QSAM files (and I am not even certain about VSAM KSDS or RRDS files). Kirk Wolf k...@dovetail.com wrote in message news:b2b367b60901011611r46c53193t12c0356a33485...@mail.gmail.com... A commercial Cobol compiler that targets Java byte codes have been available for a long time: http://www.legacyj.com/lgcyj_perc1.html As far as I can tell, it runs as pure Java byte codes and on z/OS and would therefore take advantage of zAAP. But, one should contact the company for details. Kirk Wolf Dovetailed Technologies -- 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
Re: SHARE Session 8194: z390 and zcobol Portable Mainframe COBOL Compiler written in structured macro assembler
On Tue, 30 Dec 2008 16:16:25 -0600, Don Higgins d...@higgins.net wrote: Here is something new and something old for 2009. Come to SHARE session 8194 in Austin TX on March 3, 2009 at 8 AM for the first live demonstration of zcobol portable mainframe COBOL compiler which is written in z390 structured conditional macro assembler. zcobol supports multiple dialects of mainframe COBOL with the option to generate source and executable program code in any one of the following target languages: 1. HLASM compatible mainframe assembler for z390/z9/z10 2. Java for any J2SE platform Does this mean that it might be possible to use zcobol to compile some of our current z/OS COBOL programs into Java classes and run them on a zAAP? 3. C++ for Windows platforms 4. HLA/MASM assembler for Intel platforms snip Don Higgins d...@higgins.net -- 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
Re: SHARE Session 8194: z390 and zcobol Portable Mainframe COBOL Compiler written in structured macro assembler
2008/12/31 John McKown joa...@swbell.net: On Tue, 30 Dec 2008 16:16:25 -0600, Don Higgins d...@higgins.net wrote: Here is something new and something old for 2009. Come to SHARE session 8194 in Austin TX on March 3, 2009 at 8 AM for the first live demonstration of zcobol portable mainframe COBOL compiler which is written in z390 structured conditional macro assembler. zcobol supports multiple dialects of mainframe COBOL with the option to generate source and executable program code in any one of the following target languages: 1. HLASM compatible mainframe assembler for z390/z9/z10 2. Java for any J2SE platform Does this mean that it might be possible to use zcobol to compile some of our current z/OS COBOL programs into Java classes and run them on a zAAP? Heh heh heh... The specialty engine can o' worms arises yet again. I have no doubt that IBM has applied people much smarter than I am and equipped with all the best tools, to this situation, because it has been inevitable that someone would produce a COBOL to Java compiler (whether the compiler output is Java source, or JVM bytecodes) just to exploit this situation. I believe there are a couple of existing commercial offerings along these lines, but they are probably geared to running COBOL on non-mainframe platforms, and don't really provide any threat of moving workload from regular (expensive) z engines to specialty (cheap) ones. But here comes a compiler that is written by mainframe knowledgable people, with a clear understanding of what's needed for such a transition, including the supporting environment items like CICS. My guess is that IBM won't do anything at the moment, because zcobol is probably too difficult for production shops to use, and isn't (yet?) supported in the way that big commercial users would require. And of course there's the performance question. But clearly IBM does have a problem if it becomes fairly easy to move existing (dare I say legacy?) workload to a cheaper and maybe even faster engine. All of the specialty engines types except zAAP have technological and contractual means of restricting their use to the IBM-desired new workloads. But an engine that runs Java by design in order to attract new work (hopefully from Sun or HP boxes) can't really look at your JVM bytecodes and say this looks like something that was originally written in COBOL so we won't run it, any more than an airline can say you look like a business traveller, so we'll charge you five times the rate your seatmates are paying for this flight. My wild guess is that if zcobol looks like a real threat, IBM will just buy it. And maybe that wouldn't be such a bad thing from its developer's point of view... Tony H. -- 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
SHARE Session 8194: z390 and zcobol Portable Mainframe COBOL Compiler written in structured macro assembler
Here is something new and something old for 2009. Come to SHARE session 8194 in Austin TX on March 3, 2009 at 8 AM for the first live demonstration of zcobol portable mainframe COBOL compiler which is written in z390 structured conditional macro assembler. zcobol supports multiple dialects of mainframe COBOL with the option to generate source and executable program code in any one of the following target languages: 1. HLASM compatible mainframe assembler for z390/z9/z10 2. Java for any J2SE platform 3. C++ for Windows platforms 4. HLA/MASM assembler for Intel platforms The intermediate source code generated by the zcobol compiler includes all data labels and paragraph labels for use in debugging when required. The initial release of zcobol is focused primarily on generating HLASM compatible assembler source and executable programs. The first release includes support for static and dynamic linking of both COBOL and assembler programs, EXEC CICS, and extensions for SOA messaging support to run called programs on remote servers. There are demo programs which can be compiled and executed in all 4 target language environments. And there are a rapidly growing number of regression tests. There is a dynamically loaded zcobol runtime module for complex functions and all the source code is included. Starting March 3, 2009, zcobol will be included in z390 releases and can be downloaded via www.z390.org. For more information on zcobol, visit www.zcobol.org and join the user discussion group: zcobol-subscr...@yahoogroups.com zcobol is an open source project on sourceforge.net and volunteer developers interested in expanding zcobol support include code generation, code optimization, regression testing, documentation, demos, training materials, etc. are all welcome. Melvyn Maltz and I will be at SHARE for the presentation and demo and look forward to seeing you there. Don Higgins d...@higgins.net -- 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
