1. OT Golf WAS CoBOL moved to OO
Peter, > I learned that > if you are really good at something, so good that you really "understand" > and recognise it's underlying essence, the "received wisdom" may not apply > to you... That's a lovely story, and it resonates truth. --- Doug XXXX@XXXXX.COM
2. Call prototype vs Invoke was CoBOL moved to OO
We have a lot of PeopleSoft software in our shop. I'm told that their move to OO is by encapsulating much of their existing CoBOL code and using tags and such to call it in an OO setup. How common is this with big mainframe applications?
4. [OT] Linux disaster? (Was: COBOL FAQ *moved*)
5. OO and IBM z series COBOL was Discussions of COBOL philospphy
On Tue, 11 Sep 2007 19:18:02 +1200, "Pete Dashwood" < XXXX@XXXXX.COM > wrote: > > >"Judson McClendon" < XXXX@XXXXX.COM > wrote in message >news:o9fFi.15963$ XXXX@XXXXX.COM ... >> "Pete Dashwood" < XXXX@XXXXX.COM > wrote: >>> >>> It is a pity that the 2002 standard, which is actually trying to do some >>> useful things with the language, has inherited this legacy. I guess you >>> could say: "Too little, too late..." >> >> I wonder, was there a point when, had the COBOL community had the >> foresight, COBOL could have been enhanced in a way as to make it a >> popular, viable development language in today's environment? I'll have >> to say, I don't think so. Maybe I'm wrong, but I don't think there could >> have been "Enough, in time." > >You may well be right. > >It is pretty easy to speculate given hindsight; there is really no way of >knowing... > >Here's a possible scenario... > >1. Suppose, there had been a release of the COBOL 90 standard, that included >OO. >2. Suppose this had been eagerly embraced by the community at that time. >(This would have had a "knock on" efffect in causing new methodologies for >which OO is well suited to be investigated.) >3. Suppose it was possible for people to download free or very reasonably >priced versions of compilers written to this standard, without run time fees >being charged. >4. Suppose OO COBOL had been so eagerly embraced that network development >and remote procedure calling would be implemented in it, as well as the >traditional batch processing role. >5. Suppose a decent IDE and support tools had been available, that worked >across platforms providing the same support in mainframe and network >environments. >6. Suppose the obvious success of COBOL led to the implementation of graphic >tools that could build COBOL components and assemble them into >sub-assemblies in seconds. This would allow COBOL support for non-procedural >solutions. > >Would the story have been any different? With a large amount of COBOL code still on IBM z series, some interesting developments are relevant to this discussion. There purportedly is a Websphere based IDE that supports COBOL and presumably has repository functions (I haven't researched it yet because I am trying to figure out if it matters). COBOL for the z series supports OO in JAVA context. There apparently are classes and other OO pieces of functionality for C/C++ in CICS according to one posting I read on bit.listserv.ibm-main. This could mean that there could be a path to moving COBOL on the z series to OO. IBM is pushing web integration, SOA and a number of other things that I don't pretend to understand except in a very broad sense. IBM z series is still used by a large number of large organizations and a surprising number of smaller ones. It is getting decent Unicode support. There are web servers for it. DB2 is still one of the most used data bases and improvements are still being made to IMS data base and data communications including 64 bit support. IBM vacillates on whether it wants the smaller user but currently does have some interesting offerings at the low end (not the developer low end unfortunately for those small ISVs who can use a mainframe on a laptop). Most larger banks are probably on CICS or IMS for their major processing even today. Thus the question becomes would it be worthwhile to push IBM to make it come together? The benefits are the reuse of a number of systems that can't be replaced by SAP, et al and a migration path. For those of you who know both C# and COBOL, how much would have to added to COBOL for it to have the same functionality that C# has. > >Pete.
6. IBM, OO COBOL and related IBM products(was: Reasonably priced COBOL products
7. IBM, OO COBOL and related IBM products (was: Reasonably priced COBOL products
8. Static versus dynamic SQL was OO and IBM z series COBOL was Discussions of COBOL philospphy