|
| Since this has gotten so far off the original topic, I'm moving it to a
new thread... [SECOND ATTEMPT to CREATE A NEW THREAD...]
Clark, while, I had promised myself I was not going to go on a long
dissertation about this, and since you have not yet provided a specific
example of a programing case where 64-bit is _required_ or even where
the program will be severely hampered by only operating in 31-bit mode,
I think there are some questions that I'd like you to answer so that,
possibly, we can get to some specific inhibitors due to no 64-bit
support for COBOL. And, please limit your responses to COBOL, because
C/C++ has its own set of requirements in a z/OS environment that are not
applicable to COBOL.
Question: Do you understand the differences and implications of XPLINK
under z/OS? [I will say no more at this point in order to avoid any
bias to your answer.]
Question: With the one possible exception being the processing of
extremely large XML structures, what specific problem(s) do you see that
a COBOL program operating in 31-bit mode exhibits that would be
alleviated by being in 64-bit mode. [Just saying it needs to address
'above the bar' is, in my opinion not an answer. I want to understand
'why' you believe this to be the case, ideally with a specific example.]
[I'm sure this will go much further, but the above must be used to
establish a base for discussion.]
Carl
> Clark F Morris wrote:
<<SNIP of original thread...>>[color=darkred]
[color=darkred]
>
> In this case, the drive should be internal within IBM. The customer
> need is to have COBOL work well with Websphere, take advantage of 64
> bit DB2, work well with Java and interface with 64 bit C/C++.
> Apparently there is no 64 bit Java yet so there isn't a problem yet in
> that regard. The need is for COBOL programs to play nicely in the
> environment where they may be dealing with very large data entities.
> If C/C++ needs to have 64 bit addressability, then reasons and C/C++
> uses should be reviewed internally by IBM to see which considerations
> are applicable to COBOL. Already we see the KLUDGE of using the
> COMP-1 and COMP-2 data types to interchange floating point with JAVA
> and having hex to IEEE (and vice-versa) conversion rather than using
> the new floating point definitions ALREADY IN THE STANDARD to define
> the IEEE floating point and avoid conversions. This would NOT have
> impacted existing programs AND THERE IS A SHARE REQUIREMENT FOR THIS.
[color=darkred]
[color=darkred]
> The KILLER APPLICATION is interoperability with Websphere and Java so
> COBOL 64 bit should be available on day 1 of 64 bit Websphere and z/OS
> Java.
>
>
> I agree that there are managements that believe in chasing the latest
> silver bullet but keeping their programmers, their mainframe and their
> programs in the 1970's.
|
|