Next Draft (FINAL CD) available of "next" COBOL revision
in [Cobol]
|
From: Anonymous on 14 Jul 2010 09:10 In article <976q36lh0pnpgkmgjar9ftn6mjpj0vnfkv(a)4ax.com>, Clark F Morris <cfmpublic(a)ns.sympatico.ca> wrote: >On Tue, 13 Jul 2010 08:28:32 -0500, "Bill Klein" ><wmklein(a)noreply.ix.netcom.com> wrote: [snip] >>As far as IBM goes, I think that there is ZERO chance of every seeing the >>(754) Binary Floating Point support for COBOL. As far as decimal floating >>point goes, IBM has already accepted a requirement for that. > >Ah yes, stubbornly holding to COMP-1 and COMP-2 with translation is >good enough to talk to Java. If I thought it would do some good I'd >go to the next annual meeting and ask why they don't get with the >program so that COBOL can communicate to C/C++, Java, etc. without >kludges. I don't write compilers, Mr Morris, not have I much communication with those who do... but my guess would include something like 'backwards compatability' and 'there is a GO TO but not a RETURN FROM'. DD
From: Clark F Morris on 14 Jul 2010 15:13 On Wed, 14 Jul 2010 13:10:29 +0000 (UTC), docdwarf(a)panix.com () wrote: >In article <976q36lh0pnpgkmgjar9ftn6mjpj0vnfkv(a)4ax.com>, >Clark F Morris <cfmpublic(a)ns.sympatico.ca> wrote: >>On Tue, 13 Jul 2010 08:28:32 -0500, "Bill Klein" >><wmklein(a)noreply.ix.netcom.com> wrote: > >[snip] > >>>As far as IBM goes, I think that there is ZERO chance of every seeing the >>>(754) Binary Floating Point support for COBOL. As far as decimal floating >>>point goes, IBM has already accepted a requirement for that. >> >>Ah yes, stubbornly holding to COMP-1 and COMP-2 with translation is >>good enough to talk to Java. If I thought it would do some good I'd >>go to the next annual meeting and ask why they don't get with the >>program so that COBOL can communicate to C/C++, Java, etc. without >>kludges. > >I don't write compilers, Mr Morris, not have I much communication with >those who do... but my guess would include something like 'backwards >compatability' and 'there is a GO TO but not a RETURN FROM'. Since the COMP-1 and COMP-2 usages on IBM z series COBOL would still designate Hex Floating Point, the addition of the new binary and decimal usages in the 2002 and 2010 standards would not affect backward compatibility. That COBOL already claims to communicate with JAVA. Clark Morris > >DD
From: Pete Dashwood on 14 Jul 2010 19:47 docdwarf(a)panix.com wrote: > In article <976q36lh0pnpgkmgjar9ftn6mjpj0vnfkv(a)4ax.com>, > Clark F Morris <cfmpublic(a)ns.sympatico.ca> wrote: >> On Tue, 13 Jul 2010 08:28:32 -0500, "Bill Klein" >> <wmklein(a)noreply.ix.netcom.com> wrote: > > [snip] > >>> As far as IBM goes, I think that there is ZERO chance of every >>> seeing the (754) Binary Floating Point support for COBOL. As far >>> as decimal floating point goes, IBM has already accepted a >>> requirement for that. >> >> Ah yes, stubbornly holding to COMP-1 and COMP-2 with translation is >> good enough to talk to Java. If I thought it would do some good I'd >> go to the next annual meeting and ask why they don't get with the >> program so that COBOL can communicate to C/C++, Java, etc. without >> kludges. > > I don't write compilers, Mr Morris, not have I much communication with > those who do... but my guess would include something like 'backwards > compatability' and 'there is a GO TO but not a RETURN FROM'. > Er... doesn't EXIT PERFORM serve that function? :-) Pete. -- "I used to write COBOL...now I can do anything."
From: Anonymous on 14 Jul 2010 20:02 In article <8a70l2Fn6aU1(a)mid.individual.net>, Pete Dashwood <dashwood(a)removethis.enternet.co.nz> wrote: >docdwarf(a)panix.com wrote: >> In article <976q36lh0pnpgkmgjar9ftn6mjpj0vnfkv(a)4ax.com>, >> Clark F Morris <cfmpublic(a)ns.sympatico.ca> wrote: >>> On Tue, 13 Jul 2010 08:28:32 -0500, "Bill Klein" >>> <wmklein(a)noreply.ix.netcom.com> wrote: >> >> [snip] >> >>>> As far as IBM goes, I think that there is ZERO chance of every >>>> seeing the (754) Binary Floating Point support for COBOL. As far >>>> as decimal floating point goes, IBM has already accepted a >>>> requirement for that. >>> >>> Ah yes, stubbornly holding to COMP-1 and COMP-2 with translation is >>> good enough to talk to Java. If I thought it would do some good I'd >>> go to the next annual meeting and ask why they don't get with the >>> program so that COBOL can communicate to C/C++, Java, etc. without >>> kludges. >> >> I don't write compilers, Mr Morris, not have I much communication with >> those who do... but my guess would include something like 'backwards >> compatability' and 'there is a GO TO but not a RETURN FROM'. >> > >Er... doesn't EXIT PERFORM serve that function? :-) It might were a THROUGH coded, Mr Dashwood... but e'er-so-many folks consider that anathema. DD
From: Kerry Liles on 15 Jul 2010 09:47
<docdwarf(a)panix.com> wrote in message news:i1lj5t$13d$3(a)reader1.panix.com... > In article <8a70l2Fn6aU1(a)mid.individual.net>, > Pete Dashwood <dashwood(a)removethis.enternet.co.nz> wrote: >>docdwarf(a)panix.com wrote: >>> In article <976q36lh0pnpgkmgjar9ftn6mjpj0vnfkv(a)4ax.com>, >>> Clark F Morris <cfmpublic(a)ns.sympatico.ca> wrote: >>>> On Tue, 13 Jul 2010 08:28:32 -0500, "Bill Klein" >>>> <wmklein(a)noreply.ix.netcom.com> wrote: >>> >>> [snip] >>> >>> I don't write compilers, Mr Morris, not have I much communication with >>> those who do... but my guess would include something like 'backwards >>> compatability' and 'there is a GO TO but not a RETURN FROM'. >>> >> >>Er... doesn't EXIT PERFORM serve that function? :-) > > It might were a THROUGH coded, Mr Dashwood... but e'er-so-many folks > consider that anathema. Might be interesting if, upon encountering an EXIT PERFORM, the compiler would just {exit the perform} - regardless of how the PERFORM was invoked... remarkably like English, eh wot? |