| Clark F Morris 2007-01-26, 6:55 pm |
| On Sat, 13 Jan 2007 00:24:59 -0500, CG
<Carl.Gehr.ButNoSPAMStuff@MCGCG.Com> wrote:
>Clark F Morris wrote:
>Clark,
>I don't know exactly what you mean by IBM position on adding 64-bit to
>COBOL. Since you have not been to SHARE recently, possibly you have not
>heard directly from IBM and are relying on hearsay. Their clear
>statement has been, "Show me exactly what functions you cannot do
>without the COBOL application having direct addressability to 64-bit
>storage." This is the same position they have taken on almost every
>new feature added to the compiler for the last 30 years. [Remember,
>during most of that time, I was on the IBM side of the fence and had to
>defend the IBM position to user groups.]
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.
>
>I have no doubt that, eventually, COBOL will have 64-bit addressability.
> But, in the overall scheme of work that needs to be done by compiler
>developers, 64-bit is not the top of the list. If/when someone comes up
>with the 'killer application' that needs it AND the business case is
>presented, you will see some action.
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.
>
>Frankly, as I look at the COBOL community today, I never cease to be
>amazed at the number of OS/VS COBOL components that are only being
>migrated because they will not run with the latest CICS and/or DB2. It
>is not even 31-bit support that is driving these migrations. Likewise,
>I see a huge number of COBOL II applications that are still running
>RMODE(24) and thus not even exploiting 31-bit addressability when the
>compiler does generate AMODE(31) code.
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.
>
>I know you have pushed your clients and applications to move on. But,
>unfortunately, there are still too many shops that take the "if it ain't
>broke, don't fix it" attitude.
>
>I can see some cases where 64-bit would be advantageous. But, since I
>am not the owner of these applications, any business case I might
>develop is coming from a non-paying user. i.e., I don't count. If you
>have a very specific business case, I urge you to document it to IBM.
>If you would like me to present it to IBM via SHARE, I would be happy to
>do so. And, you still have the ability to create SHARE requirements
>where you have the opportunity to document your case to the rest of the
>SHARE community and solicit their support for your position. But, I
>assure you that, just complaining here on this NG is not going to make
>any difference.
>
>As far as the Gartner Group stats, that happened to be most recent stats
>I've seen and they were the most convenient to cut/paste. Other studies
>have produced similar numbers, though. Even if they are off slightly,
>they are still very large numbers.
>
>Carl
|