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
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
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
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
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
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
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
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
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
-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
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
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
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
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
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.
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
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
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
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
19 matches
Mail list logo
