Need for COBOL 64 bit on mainframe
- From: CG <Carl.Gehr.ButNoSPAMStuff@xxxxxxxxx>
- Date: Fri, 26 Jan 2007 22:11:34 -0500
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:
>> On Fri, 12 Jan 2007 20:27:28 -0500, CG
>> <Carl.Gehr.ButNoSPAMStuff@xxxxxxxxx> wrote:
>>
<<SNIP of original thread...>>
>>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
.
- Prev by Date: Re: [OT] IBM Mainframe - Batch Job to Generate Data Set List?
- Next by Date: Re: [OT] IBM Mainframe - Batch Job to Generate Data Set List?
- Previous by thread: [OT] IBM Mainframe - Batch Job to Generate Data Set List?
- Next by thread: [OT] Of Java and C#
- Index(es):
Relevant Pages
|
