OpenCOBOL Programmer's Guide
in [Cobol]
|
Prev: ANN: OpenCOBOL Programmer's Guide
Next: Justice for all
From: Michael Wojcik on 10 Feb 2010 16:24 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. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
From: Pete Dashwood on 10 Feb 2010 20:11 john(a)wexfordpress.com wrote: > 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. Good for you, John. Now all you need is a convenient tar pit... :-) Pete. -- "I used to write COBOL...now I can do anything."
From: Pete Dashwood on 10 Feb 2010 20:14 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... :-) Pete. -- "I used to write COBOL...now I can do anything."
From: Bill Gunshannon on 10 Feb 2010 20:51 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. 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: James J. Gavan on 11 Feb 2010 00:23
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. Jimmy, Calgary AB |