Cobol is Dead
in [Cobol]
|
From: Howard Brazee on 12 Aug 2010 15:05 On Thu, 12 Aug 2010 13:40:32 -0500, "Bill Klein" <wmklein(a)noreply.ix.netcom.com> wrote: >Having said that, I do fully agree that there is MUCH less "new development" >done in COBOL (even on IBM mainframes) than there was 10 much less 20 years >ago. On the other hand, if you look at the XML and DB2 (for example) >enhancements to Enterprise COB OL since 2000 *and* the number of shops using >these, I just don't see the same SPEED of the trend that others in this >forum do. One thing that I do see is a move from having enterprise software based upon home-cooked programs to externally developed packages. The old applications programmer that would create a report for an accountant is being replaced. We still have IS people, taking care of databases, interfaces, & security. And we have more users pulling down data to massage on their spreadsheets. But these functions rarely are COBOL. -- "In no part of the constitution is more wisdom to be found, than in the clause which confides the question of war or peace to the legislature, and not to the executive department." - James Madison
From: Pete Dashwood on 12 Aug 2010 21:44 Oops! sorry for the blank response. What I meant to say is below... HansJ wrote: > On 12 Aug., 15:11, "Pete Dashwood" > <dashw...(a)removethis.enternet.co.nz> wrote: >> Alistair wrote: >>> Despite Pete frequently proclaiming the death of Cobol someone out >>> there is in search of a trainer. Unfortunately, for me, it is the >>> wrong kind of Cobol: >> >>> http://www.cwjobs.co.uk/JobSearch/JobDetails.aspx?jobid=48202373 >> >> Sigh... I have never "proclaimed the death of COBOL". >> >> In 1996 or thereabouts I predicted that by 2015 COBOL would not be >> in use as a major development language. (This was met by general >> derision and many quotes that this had been predicted before >> etc...Nobody actually believed me. They didn't believe me when I >> advised people to expand their skill sets, learn Java, learn OOP. >> Some of those "unbelievers" are now out of work or forcibly retired. >> It's not something I'm glad about being right about.) >> >> It's happened sooner than I thought. The days of the one stop COBOL >> shop are already gone. Even mainframe sites are mixing COBOL with >> other things and COBOL is being phased out. A new generation of >> programmers is coming in and they want OO. COBOL can do it, but not >> as well as other languages can and the result is what we are seeing. >> >> I have ALWAYS said there would be a place for COBOL in batch >> programming. However, I don't personally believe that batch >> programming has a future either. The increasing power of processors >> and parallell processing means that data warehouses can do >> everything in real time. If you CAN do it in real time why wouldn't >> you? >> >> It is just the way of the world. Things move on. The procedural >> paradigm has largely been replaced by newer tools and approaches. >> >> I spent 25 years making a living from COBOL when it WAS the "only >> game in town". I don't regret a minute of it, but I enjoy my work >> more today. >> >> As for the "death of COBOL" I suppose it will happen sometime, just >> as all things pass. Does a single ad for a trainer mean that COBOL >> is alive and thriving? I don't know. Have you looked on Jobserve >> recently? >> >> Beat me up in 2015 if you really think I was wrong. >> >> Pete. >> -- >> "I used to write COBOL...now I can do anything." > > Pete, > I can totally agree to your position, though COBOL is not dead, but is > getting there faster as expected. > > We are doing all new developments with Java and COBOL is still used at > a number of sites we do business with (even on NonStop systems). > > Sites running COBOL today are asking about automated COBOL to Java > conversion (which I know works well from a number of sites). There are > good reasons to argue that this might not be a good idea, but there > are reasons to do it. The projects that I know about do not regret > this step at all. > > COBOL is not dead now, but it is getting there... > > Regards Hans Thanks for your post, Hans. I've had no personal experience of COBOL to Java automation but I have managed projects that used COBOL and projects that used JAVA. Both languages have their place and both can be useful in the hands of a good artist :-) I should stress that I derive no personal pleasure from the demise of COBOL. However, reality is reality. Pete. -- "I used to write COBOL...now I can do anything."
From: Pete Dashwood on 12 Aug 2010 22:25 Howard Brazee wrote: > On Fri, 13 Aug 2010 01:11:08 +1200, "Pete Dashwood" > <dashwood(a)removethis.enternet.co.nz> wrote: > >> In 1996 or thereabouts I predicted that by 2015 COBOL would not be >> in use as a major development language. > > At one time it was *the* major development language. With an > absolute majority (not counting JCL as a "development language"). > Nowadays there is no majority development language. Yep. That's what I was talking about. At the time I posted, COBOL was still THE major (commercial) development language. We had had decades of working in COBOL shops and my point was that those days would fast be over. Today, there are probably still a few COBOL shops around but already we have seen the number of traditional "COBOL shop" sites decimated. It is interesting (to me, at least) that the main strongholds of COBOL remain corporates and Government where HUGE transaction volumes and data warehouses are required. I think this is due to a number of factors: 1. Cost effectiveness is not such a high priority. (they are either spending other people's money or they have cornered a given market :-)) 2. The cost of change in such a huge organization could be more than the benefits realized, certainly in the short term. 3. Their systems have been running for years and there is no real pressure to replace them. Although maintenance costs are high, so are any other options. This kind of fuels inertia. 4. Their managers are not typically the sharpest tools in the box and there is no pressure to excell. (The REALLY good people generally move on to places where they can make a difference.) That is not intended to be offensive to all managers in such organizations, some of whom are probably very good at their jobs, it is a generalization based on observation and the fact that good people get frustrated in repressive environments. (I have worked in Government departments here and in Europe. I can say that it was not my favourite time. The sort of nonsense you encounter: DOD. I wrote a report and three weeks later needed to amend it due to new information. I wasn't allowed to update it because it was "classified above my level" :-) I protested of course, up the chain of command and no-one could (or would) do anything. Classification was a sacred cow that could not be messed with. Just one example of the petrified thinking that occurs. I have seen similar stupidity in corporates; it is by no means confined to the military...) In fairness, I should state that the incident described occurred around 1972; I hope it wouldn't happen today. I'm not sure if there is NO majority development language. Proper statistics are impossible to obtain as far as I can see. I heard there were over 10 million downloads of C# from the MS site, but how can you check, and who knows what to believe? Certainly, Java has become far more important than many people foresaw. I was reading some stuff a few days ago about mainframe programmers learning Object Oriented concepts and experiementing with Java and even OO COBOL. (However, it was from a Micro Focus site, so there would be a bias there, just as there would be a MS bias from one of their sites.) I believe the world is realizing that when it comes to IT one size does NOT fit all. The days of the "one trick pony" (it used to be COBOL...) are virtually gone. > > It's arguable whether there's a majority development environment, now > with smart phones competing with Windows. I have been toying with the idea of developing for Win Phone 7. (MS are VERY keen to get people writing applications. The SDK is free and there are numerous MS seminars being run to encourage people. Visual Studio 2010 supports development for it and VS 2008 (which I use for C# and some VB development) can have plugins added to support development for Win Phone 7. However, I have some other problems pressing at the moment (see "persiting Object References in COBOL" elsewhere in this forum) and I can't spare the time to do the homework I would need to. Besides, from the previews I've seen there doesn't seem to be much this phone will be lacking when it becomes available :-)) > > At one time the hammer was a major building development tool. Today, > many structures are built without a traditional hammer being used. Is that really true, Howard? I can't imagine it... :-) Pete. -- "I used to write COBOL...now I can do anything."
From: Pete Dashwood on 12 Aug 2010 23:08 Bill Klein wrote: > "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote in message > news:8cia7dFvjdU1(a)mid.individual.net... >> Alistair wrote: > <snip> >> It's happened sooner than I thought. The days of the one stop COBOL >> shop are already gone. Even mainframe sites are mixing COBOL with >> other things and COBOL is being phased out. A new generation of >> programmers is coming in and they want OO. COBOL can do it, but not >> as well as other languages can and the result is what we are seeing. >> > <more snippage> > > Well, I have only been working in/with IBM mainframe shops since the > late 1970's. (I know others in the forum pre-date my experience.) At > least in that environment, I don't remember there EVER being > "onse-stop COBOL shops". It is true, that it used to be Assmbler and > PL/I that were the primary "ogther languages" (and Fortran for heavy > numeric processing) and CICS and IMS as the "interface tools" - while > now it is (still those, but also) C, C++, Java, Windows, Linux, > GUI's, etc that are used WITH COBOL. (and the past experience doesn't > even deal with Easytrieve, SAS, Telon, Pacbase, etc) Fair comment. I think (and my original comment was based on) there was a time when a programmer needed only one (programming) skill. It was COBOL, and some people here remember those days. Yes, we had used Assembler (some people still do), on various platforms (my favourites were PLAN for ICL 1900 and COMPASS for the CDC Cyber, with IBM BAL a close third...) but once we got into COBOL there was no stopping us. :-) That is why there is such passion about COBOL here in this forum. It was a lovely language that put bread on the table and was easy to write. > > As far as "COBOL is dead", I don't see that much differfence between > a Java or Visual Basic (Windows, Linux, whatever) GUI front-end to a > COBOL "back-end" system than the "olden days" of CICS or IMS/DC as > the front-end. I don't either, Bill. (and I think CICS will be around for a while yet...) What I WOULD say is that much of that centralized back end system is being eroded and distributed around the network. The database service is being moved off the mainframe and that was the raison d'etre for having a mainframe in the first place (centralized access to corporate data resources.). These days things like MPP are allowing previously undreamed of data volumes to be processed on hardware specifically designed for that task. That kind of renders the mainframe redundant or, at best, a staging processor for the real DB access... And this is where COBOL is not such a good choice. There are still trillions of DB accesses being initiated from COBOL on mainframes, but I believe we will see that changing in the near future as the effect of software techology like LINQ, and hardware technology like specialised DB server farms, and hybrid hardware/software solutions like MPP start to bite. The mainframe has traditionally had 2 main strengths: 1. It has been a good database repository, with programs running on it and accessing local data resources. 2. It has been a good transaction processor with programs like CICS and IMS/DC providing windows into its data repository. Now we are seeing hardware/software combinations other than mainframe/COBOL which can do the DB stuff much faster and VERY much cheaper. These systems use parallell processing as a given. Even with multicores, the mainframe is pressed to compete. And COBOL is not great for multitasking, never mind multiprocessing. (Before everyone jumps on me with "But COBOL CAN do that", yes it can but its overheads in doing so (multiple thread copies) are much greater than some other properly re-entrant alternatives.) C# 4 has new facilities specifically to support parallell processing. I understand similar facilities will be available in Java. COBOL has no such plans. Now we are seeing networked technology that can do transaction processing faster and cheaper than CICS runing on a mainframe. Web based applications provide the same windows into the data repository, are easily scalable, and they are not tied to a specific processor. Add in all the other factors regarding COBOL (like the moribund standards, the attrition of the knowledge base and increasing difficulty to find skilled practitioners for it, and the decline is inevitable.) I suspect our disagreement may be over the rate at which this process will occur, rather than whether it will occur at all. > > Having said that, I do fully agree that there is MUCH less "new > development" done in COBOL (even on IBM mainframes) than there was 10 > much less 20 years ago. On the other hand, if you look at the XML > and DB2 (for example) enhancements to Enterprise COB OL since 2000 > *and* the number of shops using these, I just don't see the same > SPEED of the trend that others in this forum do. > You are placed better than I am in regard to this, Bill, so I accept what you say. Maybe it will take longer than I supposed. I guess time will tell :-) > P.S. of possible relevance and/or interest, there is ongoing thread > in the IBM COBOL Cafe on how to use "shared memory/address spac es" > in batch COBOL - and how to use the Unix/Posix "shmget" and related API's > from > batch COBOL. If you read this thread, you will see that I was > mistaken (and corrected myself) as I din't think this could be done > in (IBM mainframe batch) COBOL - but it can be (and a shope is > interested in doing it) I am no longer surprised by what people can do on mainframes and I realise there is a vast difference between what we did in the last century with them and what people are doing today. Nevertheless, I still believe the arguments I outlined above. Pete. -- "I used to write COBOL...now I can do anything."
From: Richard on 13 Aug 2010 01:15 On Aug 13, 2:25 pm, "Pete Dashwood" > > It's arguable whether there's a majority development environment, now > > with smart phones competing with Windows. > > I have been toying with the idea of developing for Win Phone 7. > > (MS are VERY keen to get people writing applications. The SDK is free and > there are numerous MS seminars being run to encourage people. Visual Studio > 2010 supports development for it and VS 2008 (which I use for C# and some VB > development) can have plugins added to support development for Win Phone 7. > However, I have some other problems pressing at the moment (see "persiting > Object References in COBOL" elsewhere in this forum) and I can't spare the > time to do the homework I would need to. Besides, from the previews I've > seen there doesn't seem to be much this phone will be lacking when it > becomes available :-)) Users ? WinPhone 7 is a complete break away from all previous MS mobile stuff so no applications written for phone 6.5, or before, will run. To an existing WinPhone user it is not an upgrade so they may as well buy an iPhone or Android. WinPhone 7 has also been described as competing with the iPhone of 2008. It has no copy/paste (nor did iPhone a few years ago). Just like Zune which competed with the iPod of a couple of years earlier and added some features that nobody wanted. MS has had many failures recently, for example 'Kin' which was heavily but badly advertised in the US and then pulled off the market after 6 weeks (I think it was) after a reported 500 total sales.
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 Prev: persisting Object Refences in COBOL Next: grep'ing CoBOL source |