The ''C''''o''mmon ''B''usiness ''O''riented ''L''anguage, designed by a team lead by GraceHopper. Designed to be read by managers. Its unverified origin is explained at CobolCausesBrainDamage. * I don't think GraceHopper was the "official" team leader. However, her earlier work on language design had a lot of influence on COBOL. The way some of the members describe it is basically the committee couldn't agree on anything (massive ego battles), ran out of time, and then fell back on Grace's earlier work as a basis for the language because it had generally worked, was liked, and they needed to produce something fast because they had squandered their time on those ego battles. Nothing like a deadline to inject reality into idealists. ''I believe COBOL was originally designed to be easier to read than assembly language. That's pretty much all you can say for it...'' ''Don't forget the B in COBOL.'' See also its spiritual successor AbapLanguage, which is basically COBOL for SAP R/3 systems. ---- A COBOL programmer can say things like: DIVIDE TOTAL BY NUMBER GIVING PRO-RATA REMAINDER RESIDUE. Cobol also allowed things like SORT PEOPLE-FILE ON KEY SSN. A COBOL program is divided into divisions, sections, paragraphs and sentences. The sentence above may not be valid, as COBOL has getting on for a thousand keywords, one or more of which I may have used as, well, not variables exactly, as ''names'' above. COBOL assumes hierarchical data records. This fitted most of data of the time: Unit Record Systems, Tabulators, Punch Cards, Line Printers, Magnetic Tapes, etc.. It was and is one of the few languages that had exact fixed point decimal arithmetic on big numbers. This is useful for a type of data called ''money''. The ''B'' in ''COBOL''. For example, if you computed WAGES you could get the dollars and cents to count how many bills and coin of each denomination would be needed to fill the weekly pay packets. No division was needed, you just had CENTS OF WAGES. Interestingly, there is some attempt to isolate a COBOL program from its environment, placing all the system specific details in one division at the top. Not bad for the 50's. The most fun construct in COBOL is the ALTER verb. COBOL has something like the "computed goto" of FORTRAN. Older dialects have no notion of a procedure or function, all the flow of control is done with named paragraphs and gotos. Anyway, ALTER lets you change, at runtime, where the branches of a goto go to. As CharlesWeir pointed out, one could use this to implement polymorphism. If you had a lot of time on your hands. ''FORTRAN has (or had) a similar thing called assigned GOTO. -- JohnFletcher'' By 1970, if not earlier, any section or paragraph (or sequence of sections or paragraphs) could be executed as a subprogram with the PERFORM verb. This also provided structured loops: PERFORM WAGE-CALCULATION UNTIL END-OF-FILE. PERFORM FACTORIAL-MULTIPLICATION VARYING MULT FROM 2 BY 1 UNTIL MULT > 100. COBOL is still a force in the world, so much so that when I was an unemployable fresh graduate the British employment service thought that having a CityAndGuilds certificate in COBOL programming would help my job prospects enough for them to pay for me to get one. -- KeithBraithwaite CobolLanguage's market share is the envy, aspiration and Holy Grail of all FourthGenerationLanguage vendors. -- MattRickard Syntax for old COBOL at http://www.csci.csusb.edu/dick/samples/cobol.syntax.html The readableness of things like 05 PRINT PIC CR********9V.99. was always debatable. -- DickBotting Not if you were working at a financial institute of the time. Leading with asterisks was done to ensure no alteration of counter-checks. Seems pretty obvious in that light, print amount with all leading spaces filled with '*', float a '+' or '-' in front. -- CHergerThomann ''Format templating is a good thing in my opinion. I don't know of a better alternative. I agree that maybe COBOL's templating symbol choices were not always the best, but at least it had a solid set.'' ---- There's speculation on WhatTheYtwokDrivers that the inflexibility of COBOL, and in particular, the absence of abstract data types (or some other mechanism for information hiding/encapsulation) aggravated the Y2K problem. Had COBOL these features, moving from 2 to 4 digits dates should have been much easier. ''Many developers said that it was often to save disk, memory space, and card space, which was very expensive at the dawn of computing. ADT's wouldn't help there. Also, standard punched cards had 80 characters. If you went over that, then you had to deal with double stacks. Many interviewed said they would have happily used 4-digit years if not for the hardware-related issues.'' ---- And if pigs had wings, they could fly. In those days, compiler writers were still fighting to show that assembler wasn't the Ultimate Language, external storage was magtape and punched cards, and ''no one'' had things like ADTs. (Though perhaps it could be faked in Lisp, which is approximately the same age as Cobol.) -- David Wolff. It would seem that the poster on WTYD was not suggesting that COBOL was deficient by not having features that weren't available at the time, but rather that because we all do use ADTs and encapsulation and such these days (right?) any future such problem would be easier to fix. Not that Y2K was such a problem anyway, it turns out. Judge the porcine aviation factor of todays "best practice" for yourself. ---- COBOL made me think of CodeAsPoetry before I knew much about the PerlLanguage. -- NickBensema Or perhaps, code-as-folktale? I present, "The Common Business-Oriented Goldilocks": * http://www-users.cs.york.ac.uk/susan/joke/cblgold.htm See also CobolFallacy, a lesson which AppleScript did not learn. ---- A Cobol grammar generated from the official Cobol standard is available (in a rather readable format) at : http://www.cwi.nl/~ralf/grammars/vs-cobol-ii/ Another Cobol grammar, which was actually used for the purpose of ReverseEngineering Cobol LegacyCode, is available at : http://www.cwi.nl/~mdejonge/grammar-base/ -- ArieVanDeursen ---- Apparently, COBOL is now available for the Microsoft .NET framework. See OtherDotNetLanguages. There's also OO-COBOL - see http://home.swbell.net/mck9/cobol/ooc/overview.html. ''Cobol++? Should be called "POSTINCREMENT COBOL BY 1 GIVING COBOL"!'' ---- COBOL Standards: * 1968 = "COBOL Classic" ;-> * 1974 * 1985 = Adds structured if/else/end-if, perform/end-perform, etc. ** 1989 addendum = "added intrinsic functions, such as COSINE and TANGENT" ** 1993 addendum = "corrected errors and ambiguities" * 1995 = "Object Oriented" COBOL * 2002 = "includes object-oriented features, locale support, UNICODE support and data validation." ** http://www.microfocus.com/whitepapers/developmentcobolstandard.asp ** http://objectz.com/AnEveningwith/transcript1.html = an interview with Don Schricker * 2008 = planned next version ** http://www.cobolstandards.com/ ** http://www.cobolstandards.com/annexf.pdf ---- I've been tutoring a university student who's taking an intro programming course, and the instruction language is JavaLanguage. One day she was asking me some questions about why Java is the way it is, and I forwarded a link to JavaIsTheNewCobol and some COBOL example program for reference. She came back a few minutes later and asked, "um, so why don't people just use that?" Since this question required an hour of answer or none at all, I changed the subject. Still, it's interesting how the verbosity of COBOL makes it somehow seem less dated than it is. ---- COBOL User Groups (COBUG) A COBOL programming portal that is a one-stop resource for the COBOL community where you will find references to user groups, compilers, forums, jobs, and other COBOL programming resources. http://www.cobug.com/ ---- CategoryProgrammingLanguage