Re: Need for COBOL 64 bit on mainframe


"Clark F Morris" <cfmpublic@xxxxxxxxxxxxxxx> wrote in message
news:1iqnr254jd1jvvq2mh436mi38tbnsg917s@xxxxxxxxxx
On Sun, 28 Jan 2007 12:57:34 +1300, "Pete Dashwood"
<dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:


"Clark F Morris" <cfmpublic@xxxxxxxxxxxxxxx> wrote in message
news:fsomr2htaac6apeh281srg24eoqftsqkib@xxxxxxxxxx
On Fri, 26 Jan 2007 21:41:18 -0500, CG
<Carl.Gehr.ButNoSPAMStuff@xxxxxxxxx> wrote:

Since this has gotten so far off the original topic, I'm moving it to 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.]

While what I know about XPLINK is from a Friday morning SHARE session
with the LE developers in 2001 or 2002, I would say that it means a
noticeable change in COBOL programs underneath the covers. The
overhead in switching between XPLINK and non-XPLINK environments is
not trivial and there would probably have to be XPLINK and non-XPLINK
versions of all routines invoked by COBOL programs. The save restore
paradigm differences alone are interesting. It could have the side
effect of making OO COBOL performance better to a greater extent than
it makes non OO COBOL performance better.

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.]

The reasoning is the same as to why Philips Lighting North America
believed it was necessary to move to XA in the latter part of the
1980's. We believed that there was not enough address space in SP to
run all of the concurrently executing transactions in a CICS
Applications Owning Region and store the aggregate of the data areas
needed. Websphere 31 bit has work arounds for the same type of
problem. Having pictures on a product file wasn't even considered
back in the 1980's. Today we are dealing with them in some
environments. It is not a question of the memory address space
footprint of one COBOL transaction program (code, obtained data areas
and shared data areas) but rather the footprint of the aggregate of
the transaction programs COBOL, JAVA, C/C++ etc. that for whatever
reason should share the same Websphere, CICS, IMS, etc. LE Enclave. If
the power of LE is to be realized and the goals of the Guide SHARE
Language Futures Task Force are to be realized COBOL must be an equal
player in the new environments. If the IBM and user strategy is to
use COBOL for existing environment but migrate the code to newer
languages for use in Websphere, etc., then there is no need for 64 bit
COBOL. In reading a website discussing Websphere, they noted that 31
bit had caused work arounds (parallel instances or the use of data
spaces) that were not necessary in other environments. It was in the
past week or so and it was an IBM site since I was looking for whether
there was a 64 bit JAVA for z/OS. In short the need is not for
addressability so much as it is for interoperability with new IBM
environments and functions. By the time the customers recognize the
need it may be too late for COBOL. If the existing COBOL programs
can't interface efficiently with 64 bit JAVA which the ibm-main
postings indicate is available, there will be a push to convert those
programs to JAVA. This of course would fit the mentality of those
shops that insist on keeping COBOL at the 74 standard and coding rules
reflecting that environment but experiment with every new fad.

Frank,

Pete, how did you know Frank is my middle name.

Oops, sorry... :-)

The CIA let me use their database on the express condition I don't divulge
my sources and I go and let the cat out of the bag as stupidly as that...
:-)

Seriously, it was senility; I thought I was responding to Frank
Swarbrick...(who also posts good sense here). Either way, you made some very
good points.

Thanks for your
agreement. Now if we could get an IDE for mainframe development that
captures from the COBOL code and new information entered into it all
of the good things your C# environment has. I hope to expand on this
sometime in the future but I believe that much of the power in OO is
actually the power of an IDE like the one you have described for C#.
IBM has to learn (and given what I have read about Rational and
Websphere, they may have learned) is that we need Repository and
something far better than TSO/ISPF. Typing this brings to mind that
there are still 24 bit address components of TSO and you have already
heard my rant on ISPF and VSAM.

Given that many WebSphere developers are using Eclipse and Java you'd think
IBM would be onto it. I have a feeling it wouldn't be too hard to tailor
Eclipse for a COBOL environment; VS2005 has already been done for Fujitsu
DotNET COBOL. It simply isn't seen as important. To be fair, I wouldn't
have thought it was either if I had never moved to C#. As I have tried to
explain here, the IDE makes a HUGE difference to overall productivity. Until
you work with a good one you don't realize how bad the one you work with is.
ISPF was great 30 years ago when we didn't know any better; today it is like
using DEBUG to edit DOS commands when you could use EDIT...:-)

(I just realized... We are giving IBM a hard time for not implementing 64
bit COBOL or developing a decent COBOL IDE... d'you think they are trying to
tell us something?... just a thought...)

I guess it is also true that the sexy IDEs (and I'm only talking VS 2005 and
Eclipse here, I'm sure there are many others) REQUIRE an OO language to
realize their full potential. That kind of precludes procedural COBOL...

Clark F. Morris, Jr. who will learn and understand OO when he gets a
job improving or modifying an existing system.

What about knowledge for knowledge sake? :-) No? Art for art's sake; money
for Chrissake... I quite understand :-)

Pete.


.

Relevant Pages

  • Re: Possibly stupid question for you IBM mainframers... :-)
    ... > I've been out of work for a while, and while I know COBOL well enough ... > both of those environments now), most of the mainframe work I see out ... JCL and the IBM mainframe "utilities". ...
    (comp.lang.cobol)
  • Re: Dynamic memory in standard COBOL; using large data fields
    ... As has been pointed out by others, if you place the "allocated" storage routines ... COBOL compilers work in environments where there ... > not support the notion of dynamic memory. ...
    (comp.lang.cobol)
  • Re: Need for COBOL 64 bit on mainframe
    ... And, please limit your responses to COBOL, because ... overhead in switching between XPLINK and non-XPLINK environments is ... reason should share the same Websphere, CICS, IMS, etc. LE Enclave. ... actually the power of an IDE like the one you have described for C#. ...
    (comp.lang.cobol)
  • Re: Need for COBOL 64 bit on mainframe
    ... And, please limit your responses to COBOL, because ... overhead in switching between XPLINK and non-XPLINK environments is ... reason should share the same Websphere, CICS, IMS, etc. LE Enclave. ... If the IBM and user strategy is to ...
    (comp.lang.cobol)
  • Re: IBM Announces WebSphere Application Server V6.1 for z/OS
    ... Can they interoperate with JAVA and will ... could compile COBOL in such a way as to run as EJBs inside WebSphere ... IBM may be hiding the information now -- it's not popping up in my ...
    (bit.listserv.ibm-main)