Home > Archive > Cobol > January 2007 > Need for COBOL 64 bit on mainframe
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Need for COBOL 64 bit on mainframe
|
|
|
| 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.]
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.
| |
| William M. Klein 2007-01-27, 7:55 am |
| Carl, (et al)
I agree that neither Clark nor any other IBM current customer that I am aware
of has provided an example of an existing IBM mainframe COBOL program that has
run-into a "limitation" with 31-bit COBOL, there are still 2 issues that you
haven't addressed here or that IBM hasn't addressed (that I am aware of)
elsewhere
1) When/If any customer DOES provide a business case for 64-bit COBOL for
"existing" application needs, how long will it take for IBM to *then* develop
and deliver it? Wont that (and any similar customers) be FORCED to move away
from COBOL if the need for 64-bit solutions already exist and THEN IBM starts
work on developing the solution?
2) As you (Carl) are well aware, IBM currently provides no documented way for
*ANY* 31-bit (non-Assembler) code to "co-exist" with 64-bit code running in the
SAME LE "enclave" (or run-unit or any other "application" definition). This
means that *IF* existing COBOL code is intended to interface at all with 64-bit
C/C++, Assembler, or Java, existing IBM customers are simply "out-of-luck"
***
Of course, Clark asked about 64-bit Java and COBOL interoperability. Given the
current scarcity (not total lack) of IBM customers using the EXISTING 31-bit
Java/COBOL interoperability, I have some difficulty seeing this as a "real
world" business need.
--
Bill Klein
wmklein <at> ix.netcom.com
"CG" <Carl.Gehr.ButNoSPAMStuff@MCGCG.Com> wrote in message
news:d3a79$45babbd1$d066072d$5176@FUSE.NET...[color=darkred]
> 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.]
>
> 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
>
> <<SNIP of original thread...>>
>
>
>
| |
| Clark F Morris 2007-01-27, 6:55 pm |
| On Fri, 26 Jan 2007 21:41:18 -0500, CG
<Carl.Gehr.ButNoSPAMStuff@MCGCG.Com> 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 w 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.[color=darkred]
>
>[I'm sure this will go much further, but the above must be used to
>establish a base for discussion.]
>
>Carl
>
><<SNIP of original thread...>>
>
>
>
| |
| Michael Mattias 2007-01-27, 6:55 pm |
| Wouldn't it be true - generically speaking - that there is nothing that
can't be done with "less than 64-bit" technology, it's just that certain
things - and perhaps many things - could be done much faster and/or
'cleaner' WITH 64-bit technology? (e.g., 31 decimal digit arithmetic).
--
Michael C. Mattias
Tal Systems Inc.
Racine WI
| |
| William M. Klein 2007-01-27, 6:55 pm |
| I am not (personally) aware of any existing IBM "instructions" (or capabilities)
that are "faster and/or cleaner" in THEIR 64-bit environment than in their
31-bit one. There certainly MIGHT be some (someday) but not any that I know of
today (or in the foreseeable future).
What is true in OTHER operating systems may well differ, but I think that IBM's
z/OS 31-bit system is "pretty well optimized".
--
Bill Klein
wmklein <at> ix.netcom.com
"Michael Mattias" <mmattias@talsystems.com> wrote in message
news:2dKuh.13878$ji1.10519@newssvr12.news.prodigy.net...
> Wouldn't it be true - generically speaking - that there is nothing that can't
> be done with "less than 64-bit" technology, it's just that certain things -
> and perhaps many things - could be done much faster and/or 'cleaner' WITH
> 64-bit technology? (e.g., 31 decimal digit arithmetic).
>
> --
> Michael C. Mattias
> Tal Systems Inc.
> Racine WI
>
>
>
| |
| Pete Dashwood 2007-01-27, 6:55 pm |
|
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:NwIuh.40361$jd2.13107@fe09.news.easynews.com...
> Carl, (et al)
> I agree that neither Clark nor any other IBM current customer that I am
> aware of has provided an example of an existing IBM mainframe COBOL
> program that has run-into a "limitation" with 31-bit COBOL, there are
> still 2 issues that you haven't addressed here or that IBM hasn't
> addressed (that I am aware of) elsewhere
>
> 1) When/If any customer DOES provide a business case for 64-bit COBOL for
> "existing" application needs, how long will it take for IBM to *then*
> develop and deliver it? Wont that (and any similar customers) be FORCED
> to move away from COBOL if the need for 64-bit solutions already exist and
> THEN IBM starts work on developing the solution?
>
> 2) As you (Carl) are well aware, IBM currently provides no documented way
> for *ANY* 31-bit (non-Assembler) code to "co-exist" with 64-bit code
> running in the SAME LE "enclave" (or run-unit or any other "application"
> definition). This means that *IF* existing COBOL code is intended to
> interface at all with 64-bit C/C++, Assembler, or Java, existing IBM
> customers are simply "out-of-luck"
>
> ***
>
> Of course, Clark asked about 64-bit Java and COBOL interoperability.
> Given the current scarcity (not total lack) of IBM customers using the
> EXISTING 31-bit Java/COBOL interoperability, I have some difficulty
> seeing this as a "real world" business need.
>
Bill, I had promised myself to stay out of this, as I am not involved in IBM
mainframe development any more (this might change in April when I'll
probably return to Europe and look for a job), but I was so shocked by your
coment above, I have to make comment on it :-)
Here's my two cents and really all I want to say about it...
1. Frank (and I imagine many other IBM customers) is/are absolutely right in
requesting 64 bit support, WHETHER THEY CURRENTLY NEED IT OR NOT!
Your own points 1 and 2 above are right on the button. Who wants to play
"catch up" when the need IS finally perceived? So often in the past vendors
have resisted new technology and then lost market share and credibility when
they have been dragged kicking and screaming into the arena.
Yes, there are costs involved for the vendor. But the costs of losing share
in a competitive market place are at least as high.
There is always inertia and resistance when new technology is introduced...
(Why use COBOL when we are doing fine in Assembler?...Why have virtual
storage and all the consequent thrashing and overhead when I can write my
programs to use overlaying effectively?... Why use a relational database
when I can control locking myself, and my ISAM files are pretty  ?...Why
do I need structured COBOL, I write everything as called modules?...) I'm
sure you have heard similar.
The difference is that nowadays the Market Place exerts influence and even
the most hunkered down bastions of Fortress COBOL cannot be unaware of what
is going on outside the castle...(And if they are, how long can they remain
so...?)
When their competition starts to gain competitive advantage by moving to
network solutions and dropping the traditional monolith, when the business
despairs and starts running on spreadsheets and databases produced by each
department so there is no longer any global picture available, just because
IT wasn't delivering the services required, when the ORACLE salesman takes
Senior Management on a tour of a similar site that is running a succesful
network delivering SOAs, when people on the shop floor KNOW they can do
better on their PC at home than IT is delivering to the business, when any
or all of these scenarios happen, people are going to require the IT
department to start doing likewise or there won't be an IT department...
This brings me to my second point, and what prompted this post...
2. Interoperability is the ONLY thing that could save COBOL and keep it
viable. I'm sure you're right, in that many sites are not using what is
currently available, but watch this change over the next three years.
Websphere and interaction with Java, building SOAs to deliver services from
the mainframe to the business across the network, are going to be the major
growth areas. If COBOL is not seen to embrace this environment, then COBOL
will be dropped. It is inevitable. Once the message filters through that
interfacing to COBOL is extremely difficult and there is no proper advantage
in doing so, worse still, if COBOL is seen to be actually hindering this
process through lack of 64 bit support, then the writing is on the wall for
COBOL.
Not seeing interopability as a "real world" business need (your quote above)
simply because there isn't much uptake on it by the user community
currently, is just a "head-in-the-sand" position that I am really surprised
to see you take :-). The sandstorm is coming and you don't need binoculars
to see it. Interoperability is probably THE most pressing "real world"
business need for IT departments to enable continued delivery of service to
the business. If they can't see this today, they certainly will tomorrow.
If I were IBM, I'd be committing to this as soon as possible. That is, if
they are serious about a role for COBOL in the future, and, much more
importantly, ensuring they retain their customer base into the future, even
if the customers themselves don't currently "get it" :-)
Pete.
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "CG" <Carl.Gehr.ButNoSPAMStuff@MCGCG.Com> wrote in message
> news:d3a79$45babbd1$d066072d$5176@FUSE.NET...
>
>
| |
| Pete Dashwood 2007-01-27, 6:55 pm |
|
"Clark F Morris" <cfmpublic@ns.sympatico.ca> wrote in message
news:fsomr2htaac6apeh281srg24eoqftsqkib@
4ax.com...[color=darkred]
> On Fri, 26 Jan 2007 21:41:18 -0500, CG
> <Carl.Gehr.ButNoSPAMStuff@MCGCG.Com> wrote:
>
>
> 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.
>
> 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 w 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,
I promise you I read this AFTER I made my own post to this thread. :-)
I completely agree with your position on interoperability and am very
pleased to see that I am not the only one who has realised the importance of
this.
I hope IBM get this message.
Pete.
| |
| Pete Dashwood 2007-01-27, 6:55 pm |
|
"Michael Mattias" <mmattias@talsystems.com> wrote in message
news:2dKuh.13878$ji1.10519@newssvr12.news.prodigy.net...
> Wouldn't it be true - generically speaking - that there is nothing that
> can't be done with "less than 64-bit" technology, it's just that certain
> things - and perhaps many things - could be done much faster and/or
> 'cleaner' WITH 64-bit technology? (e.g., 31 decimal digit arithmetic).
>
Sure.
There's nothing that can't be done with 8 bit technology if you really want
to do it :-)
It isn't just about arithmetic or processing large XML files quickly; it is
about FAST interoperability...
Pete.
| |
| Clark F Morris 2007-01-27, 6:55 pm |
| On Sun, 28 Jan 2007 12:57:34 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:
>
>"Clark F Morris" <cfmpublic@ns.sympatico.ca> wrote in message
> news:fsomr2htaac6apeh281srg24eoqftsqkib@
4ax.com...
>Frank,
Pete, how did you know Frank is my middle name. 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.
Clark F. Morris, Jr. who will learn and understand OO when he gets a
job improving or modifying an existing system.
>
>I promise you I read this AFTER I made my own post to this thread. :-)
>
>I completely agree with your position on interoperability and am very
>pleased to see that I am not the only one who has realised the importance of
>this.
>
>I hope IBM get this message.
>
>Pete.
>
| |
| Pete Dashwood 2007-01-28, 3:55 am |
|
"Clark F Morris" <cfmpublic@ns.sympatico.ca> wrote in message
news:1iqnr254jd1jvvq2mh436mi38tbnsg917s@
4ax.com...
> On Sun, 28 Jan 2007 12:57:34 +1300, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
>
> 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.
| |
| Clark F Morris 2007-01-28, 7:55 am |
| On Sun, 28 Jan 2007 17:46:54 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:
>
>"Clark F Morris" <cfmpublic@ns.sympatico.ca> wrote in message
> news:1iqnr254jd1jvvq2mh436mi38tbnsg917s@
4ax.com...
>
>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.
>
>
>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...
>
>What about knowledge for knowledge sake? :-) No? Art for art's sake; money
>for Chrissake... I quite understand :-)
It's more that I have enough things that I am trying to keep current
on such as what is happening in the mainframe world and in public
transportation that I can't see adding OO to my already full plate
when I may never have a chance to use it. I also am an improver and
modifier, not a creator. I am semi-retired (collecting pensions, etc.
but willing to take contracts) and find that the few offers I get are
in the areas I know and keep up with.
>
>Pete.
>
| |
| Pete Dashwood 2007-01-28, 6:55 pm |
|
"Clark F Morris" <cfmpublic@ns.sympatico.ca> wrote in message
news:st9pr2pr99rmqr4tt778en3udvm3tu0i9m@
4ax.com...[color=darkred]
> On Sun, 28 Jan 2007 17:46:54 +1300, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
>
>
> It's more that I have enough things that I am trying to keep current
> on such as what is happening in the mainframe world and in public
> transportation that I can't see adding OO to my already full plate
> when I may never have a chance to use it. I also am an improver and
> modifier, not a creator. I am semi-retired (collecting pensions, etc.
> but willing to take contracts) and find that the few offers I get are
> in the areas I know and keep up with.
Yes, I can relate to that. I'm not pensionable yet but I expect that when I
am I'll do something very similar. My comments were not serious and
certainly not intended to be critical. There is a huge body of knowledge
vested in people like yourself and it is good that you are still able to
contribute.
Best.
Pete.
| |
| Howard Brazee 2007-01-29, 6:55 pm |
| It is possible for a company to tell users to do it the company's way
- and this works for a while.
It can continue to work if that company keeps innovating - Apple
computer demands we do things Apple's way.
| |
| Charles Hottel 2007-01-29, 6:55 pm |
|
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:522o5tF1lgtuqU1@mid.individual.net...
>
> (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...)
>
<snip>
I think IBM would be happy if everyone stopped using COBOL and started using
Java instead. They seem far more intrested in promoting Java than in making
any investment in COBOL.
|
|
|
|
|