OpenCOBOL Programmer's Guide
in [Cobol]
|
Prev: ANN: OpenCOBOL Programmer's Guide
Next: Justice for all
From: Brian Tiffin on 11 Feb 2010 00:36 On Feb 8, 4:28 am, "Pete Dashwood" <dashw...(a)removethis.enternet.co.nz> wrote: > Brian Tiffin wrote: > > There is a new COBOL manual in town. > > > A very complete programmer's guide for OpenCOBOL. This robust > > compiler now comes with robust documentation. > > >http://add1tocobol.com/tiki-download_file.php?fileId=73 > > > 200+ pages of beautiful, printable documentation suitable for new and > > expert COBOL coders. > > > Cheers, > > Brian Tiffin > > Congratulations, Brian. > > Wish you well with it. > > Like Jimmy, I would need to see support for OO before I could consider it > viable. > > Pete. > > -- > "I used to write COBOL...now I can do anything." To clarify. I take no credit for the document. All the credits to Gary Cutler. Beautiful thing this, imho. And thanks Peter Cheers, Brian
From: Pete Dashwood on 11 Feb 2010 08:32 Bill Gunshannon wrote: > In article <7th403Fc2uU1(a)mid.individual.net>, > "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> writes: >> Bill Gunshannon wrote: >>> In article >>> <7bd3dcc0-272e-4f8d-8332-8b2e8e682772(a)c10g2000vbr.googlegroups.com>, >>> "john(a)wexfordpress.com" <john(a)wexfordpress.com> writes: >>>> On Feb 8, 4:28 am, "Pete Dashwood" >>>> <dashw...(a)removethis.enternet.co.nz> wrote: >>>>> Brian Tiffin wrote: >>>>>> There is a new COBOL manual in town. >>>>> >>>>>> A very complete programmer's guide for OpenCOBOL. This robust >>>>>> compiler now comes with robust documentation. >>>>> >>>>>> http://add1tocobol.com/tiki-download_file.php?fileId=73 >>>>> >>>>>> 200+ pages of beautiful, printable documentation suitable for new >>>>>> and expert COBOL coders. >>>>> >>>>>> Cheers, >>>>>> Brian Tiffin >>>>> >>>>> Congratulations, Brian. >>>>> >>>>> Wish you well with it. >>>>> >>>>> Like Jimmy, I would need to see support for OO before I could >>>>> consider it viable. >>>>> >>>>> Pete. >>>>> >>>>> -- >>>>> "I used to write COBOL...now I can do anything." >>>> It seems we now have two audiences, the proceduralists (of which I >>>> am one) and the >>>> Object Oriented folks. And COBOL itself exists in two quite >>>> different forms. I suggest that >>>> trying to cram both forms into one compiler makes it too heavy, >>>> both for the compiler writer and the programmer. >>>> I remember Grace Hopper saying at a ACM meeting that she did not >>>> want to use COBOL for the things FORTRAN was good for for nor use >>>> FORTRAN for the things COBOL was good for. Some of the code I see >>>> on this list is quite unreadable to me. And I have been doing >>>> COBOL for many years. What the Standards people have done is >>>> create a totally new language and called it COBOL. I would have a >>>> better chance of reading Java or Php, two languages I do not know, >>>> than something written in Objective COBOL. >>>> We are also feeding the vices of the academic community. They never >>>> liked COBOL to start with. They taught students to code in a clumsy >>>> fashion that mimicked other languages, nested ifs beyond all reason >>>> and the like. I hired some of these folks years ago and their real >>>> education began on the job. >>>> The virtues and vices of the OO approach to programming are not the >>>> point. COBOL was designed so that programmer A could pick up a >>>> program written some years back by programmer B and have some hope >>>> of understanding what was going on. That is the real world >>>> situation. Programs need not only to be written but maintained. >>>> Systematically the standards people have added new features and >>>> subtracted old ones in COBOL 2002 and following to the point that >>>> it is now a different language. Old programs may still compile. >>>> That is not the issue. The issue is that the Standards people have >>>> created a tower of babel, where we can no longer understand each >>>> other. >>>> The C progamming language has now three defined variants. One can >>>> write in C, Objective C, and C++. Each is considered a separate >>>> entity, although the same base compiler supports each, just as a C >>>> compiler supports Open Cobol, Tcl and so on. I have no hope of >>>> dissuading those who want to turn COBOL into something different, a >>>> clone of some other language, but I do suggest that we fork the >>>> language. >>>> Open Cobol and Tiny Cobol are the only successful non-commercial >>>> COBOL compilers out there. The existence of a manual for one of >>>> them is a significant achievement. I will be happy to print out the >>>> manual. And I am sorry that there is not an internet group for >>>> those who view, as I do, COBOL 85 as the last real COBOL, true to >>>> the original design objectives of a writable language, a readable >>>> language, and a business orientation. >>>> Maybe I'll start that group. >>>> John Culleton CCP >>> >>> It seems that I am not the only one who laments what has been done >>> to COBOL (and other languages as well). As one who works in >>> academia, I can agree 100% with John's comments. As for >>> "standards", the Standards >>> Bodies have one and only one real purpose. To perpetuate their own >>> existence and they do that by creating "standards" wether the real >>> world wanted or needed them and usually with total disregard for >>> what the real world is doing. >>> >>> It would be truly interesting to know what percentage of the >>> millions and millions of lines of existing COBOL actually use >>> anything beyond COBOL 85. My guess would be a very small number as >>> shops that use COBOL tend to be more interested in getting their >>> specific job done rather than pushing the paradigm envelope. >> >> As the number of these shops is evaporating like brandy on a >> hotplate, you better run your survey quickly... :-) > > You keep saying this but my experience is quite different. I know one > in particular (I actually interviewed there but it turned out they > were interested in my Unix skills and my lack of current CICS > experience made them uninterested in my COBOL experience) who are > always hiring and have more than doubled their staff in the last > couple years. And, knowing what they do for a business, I don't see > them going away or changing the way they do business anytime soon. > And then, we have the insurance industry.... > > As a matter of fact, the only obstacle facing being a COBOL programmer > here in the US is you must also have current IBM Mainframe experience. Ever wondered why that is hard to come by? 30 years ago it wasn't. As for the insurance industry, the last project I managed here a few years back was for just such a company. They were replacing their mainframe COBOL system, running on Unisys. They are not alone; their main competitor had already done so. Obviously, our perceptions differ, Bill. That doesn't make either of us wrong. It just means things are different in different places. :-) I believe there is a long term trend and it is becoming more obvious. When I first suggested that COBOL would not be the language of choice and that the "COBOL shop" would be gone by 2015, back in 1997, I was met with scorn and derision. That has died down of late... no idea why, if things are as bouyant as you say. The "billions of lines of COBOL " that are supposed to be running everything are being replaced and removed by automated software and that legendary base is eroded every year. Sure, there will be some shops that cling to it. Some places are simply bewildered and not sure where to go next. Many companies are "outsourcing" their IT, not necessarily to the Asian sub continent, but to packages and service companies. Most are finding that the cost of IT in general, and COBOL in particular is just non-viable. There never used to be any alternative; now there is. Market forces will do what they always do. I see no point in being upset by it (I was for a little while). Might as well get upset about the mediaeval decline of Latin. Adapt and survive, or don't, and take your chances. That is really about the size of it. In 1984 COBOL had around 70% of the world wide commercial software development market. (IBM figures) Today it is around 4%.(Based on web figures and Job availability.) Don't take my word for it. Just go and look at your favourite Job site. Pete. -- "I used to write COBOL...now I can do anything."
From: Bill Gunshannon on 11 Feb 2010 09:06 In article <7tif6vFrfqU1(a)mid.individual.net>, "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> writes: > Bill Gunshannon wrote: >> In article <7th403Fc2uU1(a)mid.individual.net>, >> "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> writes: >>> Bill Gunshannon wrote: >>>> In article >>>> <7bd3dcc0-272e-4f8d-8332-8b2e8e682772(a)c10g2000vbr.googlegroups.com>, >>>> "john(a)wexfordpress.com" <john(a)wexfordpress.com> writes: >>>>> On Feb 8, 4:28 am, "Pete Dashwood" >>>>> <dashw...(a)removethis.enternet.co.nz> wrote: >>>>>> Brian Tiffin wrote: >>>>>>> There is a new COBOL manual in town. >>>>>> >>>>>>> A very complete programmer's guide for OpenCOBOL. This robust >>>>>>> compiler now comes with robust documentation. >>>>>> >>>>>>> http://add1tocobol.com/tiki-download_file.php?fileId=73 >>>>>> >>>>>>> 200+ pages of beautiful, printable documentation suitable for new >>>>>>> and expert COBOL coders. >>>>>> >>>>>>> Cheers, >>>>>>> Brian Tiffin >>>>>> >>>>>> Congratulations, Brian. >>>>>> >>>>>> Wish you well with it. >>>>>> >>>>>> Like Jimmy, I would need to see support for OO before I could >>>>>> consider it viable. >>>>>> >>>>>> Pete. >>>>>> >>>>>> -- >>>>>> "I used to write COBOL...now I can do anything." >>>>> It seems we now have two audiences, the proceduralists (of which I >>>>> am one) and the >>>>> Object Oriented folks. And COBOL itself exists in two quite >>>>> different forms. I suggest that >>>>> trying to cram both forms into one compiler makes it too heavy, >>>>> both for the compiler writer and the programmer. >>>>> I remember Grace Hopper saying at a ACM meeting that she did not >>>>> want to use COBOL for the things FORTRAN was good for for nor use >>>>> FORTRAN for the things COBOL was good for. Some of the code I see >>>>> on this list is quite unreadable to me. And I have been doing >>>>> COBOL for many years. What the Standards people have done is >>>>> create a totally new language and called it COBOL. I would have a >>>>> better chance of reading Java or Php, two languages I do not know, >>>>> than something written in Objective COBOL. >>>>> We are also feeding the vices of the academic community. They never >>>>> liked COBOL to start with. They taught students to code in a clumsy >>>>> fashion that mimicked other languages, nested ifs beyond all reason >>>>> and the like. I hired some of these folks years ago and their real >>>>> education began on the job. >>>>> The virtues and vices of the OO approach to programming are not the >>>>> point. COBOL was designed so that programmer A could pick up a >>>>> program written some years back by programmer B and have some hope >>>>> of understanding what was going on. That is the real world >>>>> situation. Programs need not only to be written but maintained. >>>>> Systematically the standards people have added new features and >>>>> subtracted old ones in COBOL 2002 and following to the point that >>>>> it is now a different language. Old programs may still compile. >>>>> That is not the issue. The issue is that the Standards people have >>>>> created a tower of babel, where we can no longer understand each >>>>> other. >>>>> The C progamming language has now three defined variants. One can >>>>> write in C, Objective C, and C++. Each is considered a separate >>>>> entity, although the same base compiler supports each, just as a C >>>>> compiler supports Open Cobol, Tcl and so on. I have no hope of >>>>> dissuading those who want to turn COBOL into something different, a >>>>> clone of some other language, but I do suggest that we fork the >>>>> language. >>>>> Open Cobol and Tiny Cobol are the only successful non-commercial >>>>> COBOL compilers out there. The existence of a manual for one of >>>>> them is a significant achievement. I will be happy to print out the >>>>> manual. And I am sorry that there is not an internet group for >>>>> those who view, as I do, COBOL 85 as the last real COBOL, true to >>>>> the original design objectives of a writable language, a readable >>>>> language, and a business orientation. >>>>> Maybe I'll start that group. >>>>> John Culleton CCP >>>> >>>> It seems that I am not the only one who laments what has been done >>>> to COBOL (and other languages as well). As one who works in >>>> academia, I can agree 100% with John's comments. As for >>>> "standards", the Standards >>>> Bodies have one and only one real purpose. To perpetuate their own >>>> existence and they do that by creating "standards" wether the real >>>> world wanted or needed them and usually with total disregard for >>>> what the real world is doing. >>>> >>>> It would be truly interesting to know what percentage of the >>>> millions and millions of lines of existing COBOL actually use >>>> anything beyond COBOL 85. My guess would be a very small number as >>>> shops that use COBOL tend to be more interested in getting their >>>> specific job done rather than pushing the paradigm envelope. >>> >>> As the number of these shops is evaporating like brandy on a >>> hotplate, you better run your survey quickly... :-) >> >> You keep saying this but my experience is quite different. I know one >> in particular (I actually interviewed there but it turned out they >> were interested in my Unix skills and my lack of current CICS >> experience made them uninterested in my COBOL experience) who are >> always hiring and have more than doubled their staff in the last >> couple years. And, knowing what they do for a business, I don't see >> them going away or changing the way they do business anytime soon. >> And then, we have the insurance industry.... >> >> As a matter of fact, the only obstacle facing being a COBOL programmer >> here in the US is you must also have current IBM Mainframe experience. > You seem to be misunderstanding my point. Probably due to the differences in our native languages. :-) > Ever wondered why that is hard to come by? 30 years ago it wasn't. Hard to come by how? The company in question had no problem filling 100 and some jobs. They wre able to be selective enough to not even consider my application. It is a shortcoming in my current resume, not in the COBOL industry. Oh, I could fix that, but I am neither in a position or inclined to go back to an entry level position (and salary) in order to garner current CICS experience. I don't see myself staying in the job market long enough for it to be worth it. > > As for the insurance industry, the last project I managed here a few years > back was for just such a company. They were replacing their mainframe COBOL > system, running on Unisys. They are not alone; their main competitor had > already done so. > > Obviously, our perceptions differ, Bill. Obviously. I know a number of insurance companies here inthe US and they are all still primarily COBOL shops. Usually fronted by Web Apps that are written in things like Java, but the bulk of the real work is still done with COBOL middleware and DB backends. As a matter of fact, I was once told by someone locally that a certain major insurance company with a large IT operation locally was re-writting all their COBOL in Java. I spoke to a manager in the IT department and asked. He never stopped laughing long enough to answer the question. > > That doesn't make either of us wrong. It just means things are different in > different places. :-) I think that is probably the case, buit then you have to look at the potential scale in those two places. :-) > > I believe there is a long term trend and it is becoming more obvious. When I > first suggested that COBOL would not be the language of choice and that the > "COBOL shop" would be gone by 2015, back in 1997, I was met with scorn and > derision. That has died down of late... no idea why, if things are as > bouyant as you say. Probably because everyone thinks the world will end in 2012 anyway. :-) > > The "billions of lines of COBOL " that are supposed to be running everything > are being replaced and removed by automated software and that legendary base > is eroded every year. I have not seen any signs of this, as I have stated. And I have seen recent white papers supporting my understanding of the COBOL world. I have even seen at least one repiort calling for Universities to start teaching COBOL again because of a perceived shortfall in needed COBOL programmers in the not to distant future. > > Sure, there will be some shops that cling to it. Some places are simply > bewildered and not sure where to go next. Many companies are "outsourcing" > their IT, not necessarily to the Asian sub continent, but to packages and > service companies. Most are finding that the cost of IT in general, and > COBOL in particular is just non-viable. There never used to be any > alternative; now there is. While I don't agree with most of this, the one big question I have is why do you think the cost of COBOL is non-viable? What would make a COBOL program more expensive than any other? Considering the clarity of the language and the ease of maintenance (as compared to languages like C, PHP, Java, etc.) I would expect quite the opposite. Unless your reason is due to a lack of quality COBOL programmers and, as stated above, that does not seem to be a real problem, yet. > > Market forces will do what they always do. > > I see no point in being upset by it (I was for a little while). Might as > well get upset about the mediaeval decline of Latin. > > Adapt and survive, or don't, and take your chances. That is really about the > size of it. > > In 1984 COBOL had around 70% of the world wide commercial software > development market. (IBM figures) > > Today it is around 4%.(Based on web figures and Job availability.) Probably true. But, in 1984 there were probably 10 languages in common use. Today, over a hundred i would guess. There were probably a couple thousand computers. Today, several million (if not billion). One of the problem with statistics is you can make them support prety much any hypothesis you want by not stating some of them. > > Don't take my word for it. Just go and look at your favourite Job site. Do all the time. As I have said, finding COBOL jobs is not hard. Finding COBOL jobs that will hire me is a little more difficult. But that is due to my shortcomings not any shortcoming in the COBOL job market. But then, I live in a place a tad larger than you and that probably pads the market a bit. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999(a)cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include <std.disclaimer.h>
From: Pete Dashwood on 11 Feb 2010 09:13 James J. Gavan wrote: > Michael Wojcik wrote: >> Howard Brazee wrote: >> >>> But outside of this newsgroup, I have seen zero interest in OO >>> CoBOL. >> >> We have a healthy OO COBOL customer base. Most are using native-mode >> OO COBOL, but interest in the .NET COBOL product's OO features is >> growing. It's a small fraction of total COBOL use, but it's not zero. >> > What people here have to bear in mind is that CLC is but a microcosm > of what people are using or doing in COBOL. As Michael has indicated > they have a genuine base of OO users, although I'm not aware of any > numbers. (Justifiably, there are COBOL users out there, who think CLC > is as useful as teats on a bull. Amongst them, lurking in the > background, the folks of J4/Pl22.4 :-) ). Chuck Stevens the last > Unisys representative on the Standards, now departed from Unisys with > a pink slip - first thing he told me the names Dashwood and Gavan > were etched in the minds of the J4 folks. Likely they have a > dartboard with our names on that they SLING, not throw, darts at ! As > Rhett Butler said, "Frankly my dear, I don't give a damn". > > As an example of usage, years ago in Canada I picked up on a > reasonably sized software house that illustrated OO COBOL usage with > Net Express and the same OO and GUI class approach that I use. I have > no idea of numbers of programmers but they were certainly big enough > to spread the OO problem around establishing use of OO classes and > methods and how to make the GUI classes just zing for them producing > Windows dialogs. They were/are self-sufficient so a forum like this is of > no use to > them. > We none of us have any idea how many, both Fujitsu and Micro Focus, or > even IBM-ers using the OO features, that there are. Not necessarily > OO, but I know for certain that India has a BIG interest in COBOL - > Fujitsu years ago did a deal with the Indian government for > discounted copies of their compiler; that's public knowledge on the > Internet. I also know for certain, from a Canadian source, that one > of their major customers, (hint choo-choo ! - not too many of them in > Canada), as part of the contract they are obliged to outsource to > India, and those Indians are using Net Express. > > The Indians are thirsty for work and of course the bucks ! Point them > in the right direction with exhaustively well documented examples of > using OO, and perhaps well-illustrated examples of OO concepts (see > Fred's comments about my OO COBOL 101 in the thread 'Day of Week'), > then they could be off to the races. > > Now Michael mentioned .NET COBOL products. Oh dear - PC-wise there's > the big killer for COBOL. > > I gained the impression that there was a very good relationship > between MicroSOFT and Micro FOCUS, coupled with a mutual respect. > Having produced a COMPREHENSIVE version of OO COBOL, within the > framework of the COBOL Standard, unlike Fujitsu they also produced a > COMPREHENSIVE set of utilities ( OO Support classes ). It goes way > back but co-author with Will Price, (sorry forgotten Mr. X's name and > I can't put my hand on the book - he is a former employee from Newbury, US > citizen I believe and teaching up in Leicestershire or somewhere), > wrote over a decade ago, any language implying it is OO WITHOUT OO > SUPPORT CLASSES is a loser. I couldn't agree MORE. > > That being said, my understanding is that MicroSOFT had one link > missing in their .NET product, that archaic language COBOL. They > approached Micro FOCUS - who at the time, politely declined - they > had their baby as I've illustrated above. > > Now Fujitsu do have a set of classes for Collections, which Pete > Dashwood has indicated to me have been updated since. But when I > looked at them, when Collections were a discussion point in J4, on a > grading from 1 to 10, compared to what Micro FOCUS has, they rate a > minus 5 ! And that's the disastrous model J4 used for Collections > which now sits on ice not used by any of the COBOL OO-oriented > compilers. > Back to Micro Focus and their polite original 'No' to MicroSOFT. > Always ready to make a buck, our friends from the Land of the Rising > Sun, (having already gobbled up anything noteworthy for IT in UK), > were approached/sort out, (probably former), by MicroSOFT to fill that > missing link. Oh dear, I reacted with a grimace. I remember Bill Klein > enthusiastically exclaiming at the time, "Bill Gates is INTERESTED in > COBOL". Sure he was and for obvious reasons. It ain't BILLIONS of > lines of code as Gartner suggested but there's a huge chunk of the IT > world tied up in COBOL. F/J provided his missing link. Gracefully > Micro FOCUS had to follow suit to be competitive. > > So in both cases, F/J and M/F you are faced with a compiler which is a > fair chunk of change; much too expensive for me to acquire as a > hobbyist in retirement mode. So whether or not you love COBOL 85 or > are enthused about what COBOL 2002 did provide, you tentatively dip your > feet into the .NET pool. Assuming you breach the OO concept wall and > get a handle on it, unless you are bonkers, you are going to say to > yourself, "Why do I need an expensive PC-based COBOL compiler and C# > and Basic .Net (which will do your GUI-ing), VisualStudio (or > whatever their IDE is called), when I can be totally using the last > three as FREEBIES ?". Adios COBOL. > > Don't think it hasn't already happened and in the case of M/F I bet > they have some statistics which support my statement. Less certainty > with #1, certainty with #2 - both two young hotshots using N/E OO > and GUI classes. They knocked 'em out in a flash, kind of a copy and > paste approach, looking at each as a fresh topic. > > They were doing this while I was still figuring how, when I > established how something could be done, how could I now write that > as a reusable Class (Component to Mr. Dashwood). Latest version not > yet finished (but it works), a class MyDialog which with some 80 plus > methods will repeatedly produce what you want in ANY Dialog, (it uses > all the GUI classes as necessary). Let me qualify the ANY - I haven't > as yet tackled what's required from Webbing; nor in the case of > Treeviews or Listviews is it possible or practical to put all the > code in MyDialog; the object in MyDialog invokes Treeview and > Listview support classes as necessary. > Back to my two friends above. #1, his site was used as one of M/F's > success stories. Then he got into .Net as an M/F beta user - and I > haven't heard a whisper from him since. > > #2 - Toronto based. Briefly a company of 5, he was the only > programmer, were taken over by a US Corporation. Even though he was > making $100K a year, along with the other employees was both > frustrated and embarrassed to take his paycheck. (I should be so > lucky !). The parent company was not supplying them with projects to > do. So last time I was in Toronto at my daughter's, he told me the > tale. > They all up and left forming a new company. He had certainly looked at > .Net but I don't think he had seriously looked at it at the time of > our conversation. But he has since, and asked himself the question, > "Why do I need an expensive COBOL compiler, over an above what .Net > provides free ?". Now some two years later, I haven't heard from him > either. Maybe they read what I wrote in this forum... :-) Seriously... now, some years down the track from a break with COBOL, I can honestly say I DO have a regret about moving off COBOL as my main development language: I wish I had done so sooner. It has been an interesting and ongoing learning curve but I can do things now, in a few lines of code, that would take forever in COBOL. And it is FUN! The IDE is there to prevent syntax errors, remind me of method signatures and the type and number of parameters required, to write method stubs for code I have referenced but not written yet so I can progressively test my code, and the debugging leaves COBOL gasping. Even Animator (which is one of the best pieces of software I've ever seen), is just the beginning, compared to Visual Studio debugging. I find now that on the occasions when I have to go back to the Fujitsu IDE or set up a COBOL project for a new COBOL COM component, it is like wading through molasses. The .NET framework is brilliant and very satisfying to work with. All-in-all, I'm a very happy bunny. And I don't own either of the .NET COBOL compilers because, as Jimmy mentioned, in this environment, I have no need of them. I can run what remaining COBOL I have, under InterOP services, which Microsoft designed into .NET for exactly that purpose. (To enable unmanaged legacy code to run alongside managed .NET CLR code.) The entire PRIMA Migration Toolset is written in C#, apart from a few COBOL components I simply couldn't bear to throw away or rewrite. It is ironic that to date it has generated millions of lines of COBOL code and so far, we have found no errors in generated code. There was a case last week where the size of a buffer in generated code wasn't big enough for the particular client requirement, but that was from a template and not actual code that is generated on the fly. It detects, traps, and handles hundreds of conditions via TRY... CATCH blocks that simply aren't available in COBOL. It is completely object oriented and utilises a sprinklingof the 80,000 support classes available in .NET. It is amusing to me that something which generates COBOL and actually processes COBOL programs as data, is NOT written in COBOL itself. I am continually enhancing it and adding features and I actually enjoy doing so. To be fair, I enjoyed modifying COBOL, too. But this is so much quicker and easier I can do more ambitious changes in much less time. There is just no comparison between this environment and the old one with COBOL. It doesn't surprise me in the least that the bright young guys simply ""disappeared once they hit this environment. Pete. -- "I used to write COBOL...now I can do anything."
From: Pete Dashwood on 11 Feb 2010 09:21
Bill Gunshannon wrote: > In article <7tif6vFrfqU1(a)mid.individual.net>, > "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> writes: >> Bill Gunshannon wrote: >>> In article <7th403Fc2uU1(a)mid.individual.net>, >>> "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> writes: >>>> Bill Gunshannon wrote: >>>>> In article >>>>> <7bd3dcc0-272e-4f8d-8332-8b2e8e682772(a)c10g2000vbr.googlegroups.com>, >>>>> "john(a)wexfordpress.com" <john(a)wexfordpress.com> writes: >>>>>> On Feb 8, 4:28 am, "Pete Dashwood" >>>>>> <dashw...(a)removethis.enternet.co.nz> wrote: >>>>>>> Brian Tiffin wrote: >>>>>>>> There is a new COBOL manual in town. >>>>>>> >>>>>>>> A very complete programmer's guide for OpenCOBOL. This robust >>>>>>>> compiler now comes with robust documentation. >>>>>>> >>>>>>>> http://add1tocobol.com/tiki-download_file.php?fileId=73 >>>>>>> >>>>>>>> 200+ pages of beautiful, printable documentation suitable for >>>>>>>> new and expert COBOL coders. >>>>>>> >>>>>>>> Cheers, >>>>>>>> Brian Tiffin >>>>>>> >>>>>>> Congratulations, Brian. >>>>>>> >>>>>>> Wish you well with it. >>>>>>> >>>>>>> Like Jimmy, I would need to see support for OO before I could >>>>>>> consider it viable. >>>>>>> >>>>>>> Pete. >>>>>>> >>>>>>> -- >>>>>>> "I used to write COBOL...now I can do anything." >>>>>> It seems we now have two audiences, the proceduralists (of which >>>>>> I am one) and the >>>>>> Object Oriented folks. And COBOL itself exists in two quite >>>>>> different forms. I suggest that >>>>>> trying to cram both forms into one compiler makes it too heavy, >>>>>> both for the compiler writer and the programmer. >>>>>> I remember Grace Hopper saying at a ACM meeting that she did not >>>>>> want to use COBOL for the things FORTRAN was good for for nor use >>>>>> FORTRAN for the things COBOL was good for. Some of the code I see >>>>>> on this list is quite unreadable to me. And I have been doing >>>>>> COBOL for many years. What the Standards people have done is >>>>>> create a totally new language and called it COBOL. I would have a >>>>>> better chance of reading Java or Php, two languages I do not >>>>>> know, than something written in Objective COBOL. >>>>>> We are also feeding the vices of the academic community. They >>>>>> never liked COBOL to start with. They taught students to code in >>>>>> a clumsy fashion that mimicked other languages, nested ifs >>>>>> beyond all reason and the like. I hired some of these folks >>>>>> years ago and their real education began on the job. >>>>>> The virtues and vices of the OO approach to programming are not >>>>>> the point. COBOL was designed so that programmer A could pick up >>>>>> a program written some years back by programmer B and have some >>>>>> hope of understanding what was going on. That is the real world >>>>>> situation. Programs need not only to be written but maintained. >>>>>> Systematically the standards people have added new features and >>>>>> subtracted old ones in COBOL 2002 and following to the point that >>>>>> it is now a different language. Old programs may still compile. >>>>>> That is not the issue. The issue is that the Standards people >>>>>> have created a tower of babel, where we can no longer understand >>>>>> each other. >>>>>> The C progamming language has now three defined variants. One can >>>>>> write in C, Objective C, and C++. Each is considered a separate >>>>>> entity, although the same base compiler supports each, just as a >>>>>> C compiler supports Open Cobol, Tcl and so on. I have no hope of >>>>>> dissuading those who want to turn COBOL into something >>>>>> different, a clone of some other language, but I do suggest that >>>>>> we fork the language. >>>>>> Open Cobol and Tiny Cobol are the only successful non-commercial >>>>>> COBOL compilers out there. The existence of a manual for one of >>>>>> them is a significant achievement. I will be happy to print out >>>>>> the manual. And I am sorry that there is not an internet group >>>>>> for those who view, as I do, COBOL 85 as the last real COBOL, >>>>>> true to the original design objectives of a writable language, a >>>>>> readable language, and a business orientation. >>>>>> Maybe I'll start that group. >>>>>> John Culleton CCP >>>>> >>>>> It seems that I am not the only one who laments what has been done >>>>> to COBOL (and other languages as well). As one who works in >>>>> academia, I can agree 100% with John's comments. As for >>>>> "standards", the Standards >>>>> Bodies have one and only one real purpose. To perpetuate their >>>>> own existence and they do that by creating "standards" wether the >>>>> real world wanted or needed them and usually with total disregard >>>>> for what the real world is doing. >>>>> >>>>> It would be truly interesting to know what percentage of the >>>>> millions and millions of lines of existing COBOL actually use >>>>> anything beyond COBOL 85. My guess would be a very small number >>>>> as shops that use COBOL tend to be more interested in getting >>>>> their specific job done rather than pushing the paradigm envelope. >>>> >>>> As the number of these shops is evaporating like brandy on a >>>> hotplate, you better run your survey quickly... :-) >>> >>> You keep saying this but my experience is quite different. I know >>> one in particular (I actually interviewed there but it turned out >>> they were interested in my Unix skills and my lack of current CICS >>> experience made them uninterested in my COBOL experience) who are >>> always hiring and have more than doubled their staff in the last >>> couple years. And, knowing what they do for a business, I don't see >>> them going away or changing the way they do business anytime soon. >>> And then, we have the insurance industry.... >>> >>> As a matter of fact, the only obstacle facing being a COBOL >>> programmer here in the US is you must also have current IBM >>> Mainframe experience. >> > > You seem to be misunderstanding my point. Probably due to the > differences in our native languages. :-) > >> Ever wondered why that is hard to come by? 30 years ago it wasn't. > > Hard to come by how? The company in question had no problem filling > 100 and some jobs. They wre able to be selective enough to not even > consider my application. It is a shortcoming in my current resume, > not in the COBOL industry. Oh, I could fix that, but I am neither > in a position or inclined to go back to an entry level position (and > salary) in order to garner current CICS experience. I don't see > myself staying in the job market long enough for it to be worth it. > >> >> As for the insurance industry, the last project I managed here a few >> years back was for just such a company. They were replacing their >> mainframe COBOL system, running on Unisys. They are not alone; their >> main competitor had already done so. >> >> Obviously, our perceptions differ, Bill. > > Obviously. I know a number of insurance companies here inthe US and > they are all still primarily COBOL shops. Usually fronted by Web > Apps that are written in things like Java, but the bulk of the real > work is still done with COBOL middleware and DB backends. > > As a matter of fact, I was once told by someone locally that a certain > major insurance company with a large IT operation locally was > re-writting all their COBOL in Java. I spoke to a manager in the IT > department and asked. He never stopped laughing long enough to > answer the question. > >> >> That doesn't make either of us wrong. It just means things are >> different in different places. :-) > > I think that is probably the case, buit then you have to look at the > potential scale in those two places. :-) > >> >> I believe there is a long term trend and it is becoming more >> obvious. When I first suggested that COBOL would not be the language >> of choice and that the "COBOL shop" would be gone by 2015, back in >> 1997, I was met with scorn and derision. That has died down of >> late... no idea why, if things are as bouyant as you say. > > Probably because everyone thinks the world will end in 2012 anyway. > :-) > >> >> The "billions of lines of COBOL " that are supposed to be running >> everything are being replaced and removed by automated software and >> that legendary base is eroded every year. > > I have not seen any signs of this, as I have stated. And I have seen > recent white papers supporting my understanding of the COBOL world. I > have even seen at least one repiort calling for Universities to start > teaching COBOL again because of a perceived shortfall in needed COBOL > programmers in the not to distant future. > >> >> Sure, there will be some shops that cling to it. Some places are >> simply bewildered and not sure where to go next. Many companies are >> "outsourcing" their IT, not necessarily to the Asian sub continent, >> but to packages and service companies. Most are finding that the >> cost of IT in general, and COBOL in particular is just non-viable. >> There never used to be any alternative; now there is. > > While I don't agree with most of this, the one big question I have > is why do you think the cost of COBOL is non-viable? What would > make a COBOL program more expensive than any other? Considering the > clarity of the language and the ease of maintenance (as compared to > languages like C, PHP, Java, etc.) I would expect quite the opposite. > Unless your reason is due to a lack of quality COBOL programmers and, > as stated above, that does not seem to be a real problem, yet. > >> >> Market forces will do what they always do. >> >> I see no point in being upset by it (I was for a little while). >> Might as well get upset about the mediaeval decline of Latin. >> >> Adapt and survive, or don't, and take your chances. That is really >> about the size of it. >> >> In 1984 COBOL had around 70% of the world wide commercial software >> development market. (IBM figures) >> >> Today it is around 4%.(Based on web figures and Job availability.) > > Probably true. But, in 1984 there were probably 10 languages in > common use. Today, over a hundred i would guess. There were > probably a couple thousand computers. Today, several million (if not > billion). One of > the problem with statistics is you can make them support prety much > any hypothesis you want by not stating some of them. > >> >> Don't take my word for it. Just go and look at your favourite Job >> site. > > Do all the time. As I have said, finding COBOL jobs is not hard. > Finding COBOL jobs that will hire me is a little more difficult. > But that is due to my shortcomings not any shortcoming in the COBOL > job market. But then, I live in a place a tad larger than you and > that probably pads the market a bit. > > bill I think these are fair and excellent responses, Bill. I'm really sorry you didn't get placed; I think you'd be a valuable guy to have around. As you say, you are heading for retirement anyway, so maybe it isn't so important. I don't think either of us will change our minds, but that's OK too... It's Usenet; minds seldom get changed :-) I would ask you though... If a young person came to you and said they were considering a career in COBOL, would you advise them to go that way? Obviously, I wouldn't (and haven't on several occasions, even before I moved off COBOL myself). Pete. -- "I used to write COBOL...now I can do anything." |