Talk:COBOL/Archive 1

Archive 1

Current total for lines of COBOL programs

The article (based on 1981 data?) claims that little new code is being written in Cobol. A more current estimate is at 5 billion codelines a year, so perhaps it depends on the definition of "little"... (See for instance http://www.cobolwebler.com/cobolfacts.htm, citing Gartner Group as a source.) — Preceding unsigned comment added by 80.111.138.138 (talk) 20:05, 9 February 2004 (UTC)‎

COBOL makes me think of Erwin

User Friendly

I want an Erwin programming language... --Ihope127 20:05, 21 July 2005 (UTC)

Every operating system?

The article says the following:

COBOL programs are in use ...............and on all operating systems including the common ones such as IBM's Z/os, Microsoft's Windows, and the Unix/Linux families.

Perhaps, it should be reworded to say it's on every major operating system designed for computers from desktops to mainframes (assuming that is true). I seriously doubt, but don't know, that its on every OS designed for smaller devices (or embedded devices). Some computer systems are intentionally designed to restrict development tools, so I'm doubtful of such a broad claim. --rob 11:07, 26 August 2005 (UTC)

Similarly, this comment:

the OO era of the '90s which was supposed to minimize code redundancy and prevent runtime aborts

I would like to remove given no objections. OO languages are ubiquitous nowadays and to suggest that it belonged in the 1990s and has had its day is incorrect. Additionally, the statement "prevent runtime aborts" is too vague. Strongly typed languages do help to cut down on runtime errors (integration errors) by reporting them at compile time; however, this statement could equally suggest that the hope was that using an OO language would eliminate defects in programs, which is not true. MetalMickey 23:30, 28 August 2005 (UTC)

Even if the facts are on your side, this is part of a larger "criticism" and "defenses" section. So, I suggest if you wish to trim it, go ahead, but please try to trim extraneous stuff from both sides. In fact, I personally (but I'm sure not others) would support dropping most of the "pro/con" debate, and focus on the facts (what is COBOL, what's happened with it, what's happening now, etc...). Basically, what's there is just an opinion (maybe unfounded), that explains what some people think, about what some other people think (note: *some* ill-informed OO proponents did in fact promise Heavan and Earth from OO). Even based on a false assumption, its valid to mention opinions on all sides, once you step into the world of opinions (which is why I like to stay away from opinions in articles, since there's always a domino effect). --rob 02:04, 29 August 2005 (UTC)

I think you're right. Part of the problem I guess is that different people have different opinions as to who has the facts on their side. Wouldn't like to just rip out the opinions section myself, but it doesn't really belong as you say. MetalMickey 07:41, 29 August 2005 (UTC)

Code in "The Terminator"

Around an hour into the sci-fi movie "The Terminator" (as Sarah Conner's son Kyle Reese aims at a space ship) the following COBOL scrolls by:

IDENTIFICATION DIVISION.
PROGRAM ID. ADD.
ENVIRONMENT DIVISION. 
DATA DIVISION.
WORKING STORAGE SECTION.
77 IDX PICTURE 9999.
77 SUM PICTURE 999999.
77 X   PICTURE X.
PROCEDURE DIVISION.
BEGIN.
   ACCEPT X.
   MOVE ZERO TO IDX.
   MOVE ZERO TO SUM.
   PERFORM ADD PAR UNTIL  IDX = 1441

I am not sure what the 77 in the variable definitions and what the PAR statement means...

03:04, 28 December 2005 (UTC)

The 77 code identifies a field that isn't part of any larger structure (as in 01/05 etc). Not to be confused with 88, which defined a condition: e.g. (syntax from memory)

   01  X PIC S999.
       88  X-IS-POSITIVE VALUE IS > 0.

then in code: IF X-IS-POSITIVE ....

I presume the PERFORM line should actually be:

PERFORM ADD-PAR UNTIL  IDX = 1441

AndrewWTaylor 14:17, 16 January 2006 (UTC)

Also Kyle Reese is not Sarah Connors son. John Connor is. Kyle Reese is John Connors father.

COBOL: Durable or dead?

W.marsh writes:

a POV claim like "COBOL has proven to be durable and adaptable" needs a citation

Now,I would think that the fact that so many COBOL applications are still running years after their creation would be sufficient testament to that fact that COBOL is both durable and adaptable, but I guess we can discuss this further. What say you?

Atlant 18:28, 8 March 2006 (UTC)

I'd say it's POV and should be axed. Here's a quick comparison of some passages from the article:

Objective (though generally not suported by citations)	Subjective (i.e., POV)
The Gartner Group, [...] estimated that of the 300 billion lines of computer code [...] eighty percent [...] were COBOL. They also reported [...] an estimated 5,000,000,000 net new lines of COBOL code annually.	COBOL has proven to be durable and adaptable
[...] its use of the PICTURE clause	COBOL as defined in the original specification, possessed excellent self-documenting capabilities, good file handling methods, and exceptionally good data typing for the time [.]
COBOL programs are in use globally in governmental and military agencies [...] and on IBM's z/OS, Microsoft's Windows, and the Unix/Linux families.	, in all major commercial enterprises (even though COBOL was originally proposed simply to achieve governmental programming commonality) [...] almost all significant operating systems (desktop and above) including the common ones [...]

Note the last entry in particular, where fairly crisp statements like "COBOL programs are in use [...] on [...] Windows [...]" are intermixed with mushiness like "major commercial enterprises", "even though" (which introduces an objective statement, but move it to the history section), "significant operating systems".

What do "durable" and "adaptable" mean? One could make a case for both, but just make the case and be done with it. What are "excellent self-documenting capabilities"? Just tell me what the capabilties are and I'll decide if they're excellent. What was the data typing? What was available at the time? I'll decide whether it was exceptionally good.

Here is the "COBOL legacy" without so much mush:

COBOL programs are in use globally in governmental and military agencies , in commercial enterprises and on operating systems including IBM's z/OS , Microsoft's Windows , and the Unix/Linux families .

Rewriting a COBOL application in a different language has not always been found worth the cost .

In the late 1990s, the Gartner Group, a data-processing industry research organization, estimated that of the 300 billion lines of computer code that existed, eighty percent — or 240 billion lines — were COBOL . They also reported that more than half of all new "mission-critical" applications were still being created using COBOL — an estimated 5,000,000,000 net new lines of COBOL code annually.

The current standard for COBOL is COBOL2002. COBOL2002 supports Unicode, XML generation and parsing, calling conventions to/from non-COBOL languages such as C, and support within framework environments such as Microsoft's .NET and Java (including COBOL instantiated as EJBs).

I took out the Y2K section because it's rubbish. Accountants mandating BCD? Maybe, after they discovered that using the magic word "BCD" was the only way they could get the programmers to understand that rounding errors are not acceptable to them. The arguments about fixed-length fields and the advantages of fixed-point in financial applications are well-known, but this article just sort of throws them out on the floor and lets them flop around. How many programs used two-digit fields for the date? BTW, was that really a BCD thing or was it a PICTURE thing? When did using fixed-length instead of floating point avoid problems, and what does that have to do with Y2K?

There is a well-developed and long-running flame war between COBOL proponents and opponents, occasionally supported by actual studies and facts. Could we please bring in some of those facts? The Gartner lines of code figure, for example, is a good start, but even it needs a citation so we can be sure it's not taken out of context. One could argue that using COBOL produces more lines of code (which many of us would see as a drawback), but that too needs backup. As has been pointed out, the "COBOL is verbose" argument is often made by people who don't know COBOL and yet "know" it's verbose. What objective work has been done?

Just to be clear here, I'm not taking a side in the flame war. Personally, I don't use COBOL, but neither to I know enough about it to say definitely whether I like it (as opposed to C++, for example, of which I have a strong opinion). What I care about here is that this article, from which I would like to learn more about the language, tells me very little I haven't already heard, and does so in a vague and subjective way. -Dmh 20:15, 17 March 2006 (UTC)

The Gartner report is cited here, but without the 5,000,000 figure: See "How widely used is COBOL? http://www.csis.ul.ie/cobol/Course/COBOLIntro.htm Interestingly, they said that Gartner put the estimate of worldwide COBOL programmers at 2 million, yet another page cites Gartner as claiming 90,000 COBOL programmers in the US: http://www.networkworld.com/columnists/2003/1020edit.html -Measure for Measure 20 Sep 2006

I'm certain even the Gartner report has been inflated since its inclusion. The figure I remember was 70% and I can't remember the number of new lines, but my feeling is that it wasn't anything near 5 billion. The other figure on the report was 100,000 Cobol programmers in the US declining by something like 11% each year due to death or retirement. Regardless, it's going to be very difficult to turn this into some sort of balanced article.

History of COBOL standards

A little searching turns up references to several standards over the years. Unfortunately, the ANSI standards are owned by ANSI, who appear to want around $30 a pop for the PDF from their web store. The references I've found so far are

• COBOL 60 (mentioned in the main article)

-> First version

• COBOL 61 (was this produced by CODASYL, or was it COBOL 60, or both? The main article doesn't mention CODASYL)

-> Added report writer and sort

• COBOL 65

-> Int. tables and enhaced file handling

• COBOL 68 (ANSI)
• COBOL 74 (ANSI)

-> Indexed files and ISAM

• COBOL 85 (ANSI - ANSI X3.23-1985)

-> Structured programming (END IF, case, PERFORM)

• COBOL 89

-> Intrinsic functions (ANSI X3.23a-1989, revision of ANSI X3.23-1985)

• COBOL 2000 (ANSI? Also, when was it actually made official?)
• COBOL 2002 (ANSI)

-> OOP, standarized screen

• COBOL 2008

-> Next standard

It would be great to see a table of these versions (and any others extant) together with major features introduced. Unfortunately, I don't have that information readily available. I would hope that any COBOL experts reading would be able to fill this in. -Dmh 16:08, 22 March 2006 (UTC)

Bad (Incomplete) program?

It looks like both the program examples about verbosity only gives one of the two roots to the second-order equation... Is it a bug? Nixdorf 08:41, 17 December 2005 (UTC)

I concur -- "programmer" has ignored or missed the "plus or minus" notation which will require more lines unless something already stated can be reduced.

// DISCR is discriminant

COMPUTE DISCR = B * B - (4 * A * C).

// PSR is PrincipalSquareRoot

COMPUTE PSR = AbsoluteValue of (DISCR ** .5).

// DIVIS is divisor

COMPUTE DIVIS = 2 * A.

COMPUTE X1 = (-B + PSR) / DIVIS.

COMPUTE X2 = (-B - PSR) / DIVIS.

--Bammon 10:34, 20 April 2006 (UTC)

absolute value of the square root

This sounds (to this non-COBOL speaker) like the wrong order for these two operations. Square Roots, by definition, are always positive (whereas the discriminant isn't).

Atlant 11:06, 21 April 2006 (UTC)

I added some parens and updated the pseudocode/code mix above which may correct the precedence you are looking for. Article Square Root says the "principal" square root is non-negative. Also says there exists a negative square root in the two solutions to the square root of a non-zero number. Perhaps I need to be more verbose to use "discriminant" where I mean "discriminant of the quadratic equation" -- see Article discriminant for discriminant of the quadratic equation known as ... COMPUTE Discriminant = ((b ** 2) - (4 * a * c)).

--Bammon 03:17, 23 April 2006 (UTC)

Popular culture

Am I right in remembering that 1970's American boy band The Osmonds used to release records on the COBOL label? 83.71.30.129 18:56, 2 July 2006 (UTC)

Thought I'd add a note that this obscure language is based on COBOL.. It's got windows (even on a text based system) a relational database, and can even be interfaced with SQL and the like. A development of BOS/COBOL (Later Global/Global 2000 COBOL) which itself has lots of cool features to make the programmers job easier. It's still current, supplied by TIS Software Ltd. http://www.oneoffice3000.com/ —The preceding unsigned comment was added by 87.81.12.15 (talk • contribs) .

"citation needed"

Not to troll, but this article contains too many "[citation needed]" tags; it occurs almost after every sentence, and thus gets rather irritating and distracting rather quickly. I'm finding it hard to focus on the content of the page, especially for one that is new and trying to learn COBOL. —The preceding unsigned comment was added by 203.87.193.234 (talk • contribs) .

They're redundant and unnecessary. If the article needs to be cited, it should be cited. Don't just leave little {fact} turds around in the hopes that someone else will come along and fix them. Collabi 18:57, 13 April 2006 (UTC)

The original material was put in with no citation. In fact, the original material was full of completely unsupported opinion. I took much of this out. I left {fact} where the original authors should have cited articles, but didn't. I would rather have cited the articles, but couldn't, since I had no idea where those were. So I left it for the wiki community, aka "anonymous janitors" to fix. Please restore (since you took them out). -Dmh 21:11, 17 April 2006 (UTC)

There's no need to call for citations fact-by-fact.

Atlant 23:52, 17 April 2006 (UTC)

Fair enough, but taking everything out seems a bit draconian. For example, in the "Defining Features" section, it would be nice to know what versions had self-modifying code.

I'll admit I probably went overboard in reaction to the earlier version, which talked about "excellent self-documenting capabilities, good file handling methods, and exceptionally good data typing for the time" without any backup at all. I will say that this article could benefit greatly from more specifics and at least a few well-chosen references for those. I don't really care how we get there. If placing {fact} near any unsupported statement is a bit much -- and it probably is -- then I apologize. -Dmh 15:53, 18 April 2006 (UTC)

It seems to me that "Defining features" should actually have some defining features of the language i.e. what makes it different/unique. For example, here's what I might add:

The primary difference between the syntax of COBOL and other programming languages at the time it was created, was readability. The operational code was broken into "sentances" and "paragraphs"; logical operations were meant to read like english: "MOVE 7 TO DAYS_IN_THE_WEEK", "IF TIMEOUT_EXCEEDED THEN NEXT PARAGRAPH", "MULTIPLY B BY B GIVING B-SQUARED".

The design of variables was closely related to the data formats COBOL was expected to read: space-delimited text streams, often from punchcards, output to monospaced line printers.

But of course this would be original research. COBOL was written to run from punchcards, and be readable by PHBs. Not sure how to write this without this sort of subjective information.--Justfred 22:18, 20 October 2006 (UTC)

COMPUTE and optimizations

The "Defense" section gives two versions of the quadratic formula, one using a one-line COMPUTE statement and the other spelling the computation out longhand. This was followed by an assertion that the COMPUTE statement might be optimized in ways that would unexpectedly lose precision.

I took this discussion out as it is misleading. Numerical instability generally comes from floating point arithmetic not behaving like real arithmetic. For example (a - b) + c = (a + c) - b for the real numbers, but not for floating point when (for example) a and b are equal and c is much smaller. In this case (a - b) + c will evaluate to c, as expected, but (a + c) - b will evaluate to zero since a + c = a in floating point when c is small enough. Compilers that do such reordering anyway may produce various kinds of unpredictable results. Careful numeric code will take the relative sizes of numbers into account and use explicit temporary variables or other means to enforce the order of evaluation, regardless of the language in use.

The second COBOL example is longer than the first for two reasons. First, it uses the more verbose "ADD A TO B GIVING C" syntax as opposed to "COMPUTE C = A + B". Note that in this case the COMPUTE statement is not much shorter, but this probably doesn't matter since other than COMPUTE at the beginning of the line the syntax is what folks (or non-COBOL folks, at least) are used to. This difference is unique to COBOL, but with the COMPUTE statement there is no need to use the ADD ... TO ... GIVING ... syntax.

The second difference is that the computation is spelled out step-by-step with explicit temporaries. This is not unique to COBOL. Like everything else, COBOL provides the choice of a one-line statement or a more fully spelled out version. It does not require the fully spelled out form. If numeric considerations require explicit temporaries, they probably do in other languages as well, especially if COBOL compilers respect parenthesis in COMPUTE, which I'd think they'd have to. -Dmh 06:19, 26 January 2007 (UTC)

BTW it's not clear to me where the compiler has room to go wrong with the quadratic formula example given here, but I may well have missed something. These things tend to be tricky if you're not used to them (and I'm not, these days). -Dmh 06:33, 26 January 2007 (UTC)

embedded programs, sub-programs and local variables

I tried to tighten up the description of local variables. I don't think I took out anything essential, but I was left with this:

Newer versions of COBOL support local variables via embedded programs (scope-delimited by the keywords PROGRAM-ID and END-PROGRAM). Variables declared within the embedded program are invisible outside its scope. In older versions of COBOL local variables may be hidden by using sub-programs, which must be invoked (via the keyword CALL). The calling program will not have access to the variables declared and manipulated by the sub-program. This technique COBOL could spawn an unwieldy number of sub-programs, particularly if those are not well documented.

It's not clear to me what the difference is between an embedded programs and sub-programs. It appears that embedded programs may occur in the same program text, while old-style sub-programs would be entirely separate. I'd also guess that a (cross-program?) CALL might be a more heavyweight operation than invoking an embedded program. One key question is whether either or both may be done recursively.

Depending on the answers to those questions, we may have to revisit the claim that older versions don't support local variables.

By the way, which older versions support what? -Dmh 06:29, 26 January 2007 (UTC)

Also, local variables are only one of a cluster of features appearing around the same time (in the late 1950s and early 1960s, with ALGOL and LISP, I believe). Important ones are

• Local variables (I forget whether scope was dynamic or static)
• Recursive calls
• Control structures such as begin/end blocks (which can generally introduce local variables), conditional statements, switch statements and iterative constructs, as opposed to GOTO and equivalents.

The term "structured programming" in the narrow sense refers more to the last items The article is using a broader sense that includes local variables as well as GOTO-less constructs. This is fine, but I wonder if recursion is meant to be included as well.

This is relevant to the question of which versions of COBOL "support structured programming" in what sense. -Dmh 19:59, 26 January 2007 (UTC)

Embedded COBOL programs ("Nested" is the term used on IBM iSeries or AS/400 platform) do occur in the same program source text. For example the first (outermost) program-id is Alpha. This will pair up with the last or outermost END-PROGRAM delimiter or end of file for the source text (whichever comes first). If Alpha calls program Beta, one can write the source for the latter (Beta) inside Alpha's source text delimited by another PROGRAM-ID and END-PROGRAM for Beta. The WORKING-STORAGE of Beta is invisible and inaccessible to Alpha. Check out this link: http://publib.boulder.ibm.com/infocenter/iadthelp/v6r0/index.jsp?topic=/com.ibm.etools.iseries.pgmgd.doc/c092540528.htm

On the iSeries, the two programs translate into separate modules that can then be bound into a single run-time object (executable), in which the call to Beta from Alpha is a static-call (early binding) instead of dynamic (late binding).

iSeries ILE COBOL also supports recursive calls... see this link http://publib.boulder.ibm.com/infocenter/iadthelp/v6r0/index.jsp?topic=/com.ibm.etools.iseries.pgmgd.doc/c092540528.htm.

Thanks for polishing up the paragraph.

- Andy 02:48, 27 January 2007 (UTC)

Wrong link

The link to William Selden is incorrect. There's another William Selden and it's pointing to the wrong one. —Preceding unsigned comment added by Alvaromontoro (talk • contribs) 20:16, 20 February 2008 (UTC)

Fixed. -R. S. Shaw (talk) 03:54, 21 February 2008 (UTC)

The link to Charles Phillips is also wrong. It links to a disambig page rather than to a real page, and none of the Charles Phillips listed there is the right one. I don't think Wikipedia has an actual article on him. T-bonham (talk) 11:47, 24 April 2008 (UTC)

Reference number 7 is supposed to link to "The COBOL 85 Example Book", but just comes back to this page. I don't know how to change it.

Disambiguation

There is a North East NY band named COBOL... may warrant a page/disabiguation —Preceding unsigned comment added by Kharaku (talk • contribs) 07:57, 19 January 2008 (UTC)

I created a disambig page for COBOL (COBOL (disambiguation)). Feel free to add links to existing articles. (There does not appear to be an article for Cobol (band), although there is an article for the mexican duo Kobol (band).) — Loadmaster (talk) 17:39, 21 October 2008 (UTC)

IBM manuals

A useful source of information is the iSeries Information Center, which has references and documentation for IBM's OPM COBOL and ILE COBOL.

• "COBOL/400 Reference" (PDF). (2.05 MiB)
• "ILE COBOL Reference" (PDF). (2.68 MiB)
• "ILE COBOL Programmer's Guide" (PDF). (3.93 MiB)

Should these be added to the External links section?

Alksentrs (talk) 23:42, 28 September 2008 (UTC)

I've added the link to the iSeries Information Center and the ILE COBOL manual. (I didn't add the COBOL/400 manual since it's superfluous.) Alksentrs (talk) 11:48, 10 October 2008 (UTC)

Wmklein2 (talk) 05:35, 22 December 2008 (UTC) I have added the links for Enterprise COBOL and VS COBOL II

British vs. American English

Though I have no difficulty accepting either British or American spelling conventions in writing in general, at the very least, proper names should not be respelled. Thus, it should be the . . "University of Pennsylvania Computing CentER", not "... CentRE" and . . "U.S. Department of DefenSE", not "... DefenCE" since those are their own spellings. It would be as if a Frenchman would insist on spelling my own given name "Marc", or a Czech or Pole as "Marek", even while writing to me in English, simply because that is _his_ way of spelling that name in _his_ language, and therefore the "only correct way". This strikes me as a bit haughty. Bejmark (talk) 03:18, 17 July 2008 (UTC)

• That's actually what the guidlines say: WP:ENGVAR. My opinion would be that US spelling should probably be used throughout the article, as COBOL itself has strong US ties; I've not actually looked close enough to see if the spelling is being mixed. Hikari (talk) 13:35, 27 August 2008 (UTC)

Wmklein2 (talk) 05:40, 22 December 2008 (UTC) Interestingly enough, Micro Focus (whose headquarters are - and always have been - in the UK has various "non-Standard" extensions to accept British spellings for COBOL reserved words that require (in Standar COBOL) American spellings, e.g. "COLOUR" and "ORGANISATION".

In general, however, COBOL text (except for user-defined words) should be in American spelling - if "portability" across compilers is dessired.

Information on validation of the standards

Would IT people please provide me the citation of the validation reports on ANSI COBOL 2002 and ISO/IEC 1989 ??? Thanks —Preceding unsigned comment added by 64.62.138.94 (talk) 05:44, 24 February 2008 (UTC)

Wmklein2 (talk) 05:46, 22 December 2008 (UTC) There are no "validation" suties available for the ANSI or the ISO versions of the 2002 Standard. There is no longer a FIPS Standard (and it was for the FIPS Standard that NIST and the British Testing groups developed "validation suites".) The last validation suite updates were for the Intrinsicc Function Amendment to the '85 Standard. There never were any tests for the Corrections Amendment or for any draft or approved revision after that.

As there are no current test suites, there are no current reports of "conforming" implementations. Rumor has it that (to date) there are NO (zero) FULLY conforming implementations of the 2002 Standard.

add1tocobol.com

An anonymous IP (68.99.156.37 and 68.105.197.193) added an external link to add1tocobol.com described as a "COBOL advocacy project". It looks like a chat room (which is only activated by clicking on the "I-O-CONTROL" link). Does anyone know what this site is, and whether it should be included as an external link or not? — Loadmaster (talk) 02:37, 19 September 2008 (UTC)

Yes, I know what the site is. The site is loosely associated with the OpenCOBOL GPL'ed COBOL compiler system. It has changed considerably since Sept 2008 and we're currently using TikiWiki. It is an advocacy site and we're attempting to promote COBOL usage among the open source software community. I can't answer definitively, as I'm heavily involved with setting up the site and adding content, but I'd vote that it remain as a valid external link. OpenCOBOL opens the door to serious "at home" COBOL programming and we advocate it as such. So serious that we even include Haiku poetry that, while it compiles and runs, fails as poetry and returns a failure code when executed.

program-id. one.
procedure division. add
1 to return-code.

More seriously, we're building up educational sections, and a variety of developer extensions including embedding Guile, SpiderMonkey, Lua (to name a few) and linkage How-To's for GNAT Ada, Vala etcetera. BTiffin (talk) 19:34, 3 March 2009 (UTC)

COBOL and XML

COBOL programs can now read or produce XML with a number of tools providing support for translating COBOL field values to/from XML node values. One of them is XML Thunder.

Cobol programs have always been able to read and write XML, th epoint about the latest version is that it has tools to make the programmers life easier.212.100.3.44 (talk) 11:05, 12 March 2009 (UTC)

Question about COBOL number formats

how the heck do i decode these crazy cobol number formats? i got some data here its all '00040]' and i am thinking that means -40? or what?

>> Cobol numbers may be signed ("PIC S9999" for example). The least significant digit is "overpunched" with the sign of the number, saving a character.

    +0  {

    +1  A

    +2  B

    +3  C

    ...

    +9  I

    -0  } (may be used as NULL)

    -1  J

    -2  K

    -3  L

    ...

    -9  R

In your example, '00040}' probably indicates -400, or more likely, -4.00 (you'd have to look at the format of the number or the program logic to determine where the implied decimal is).

The number 40 is all likely hood is not a number at all but the hexadecimal representation of a space. This is typical when a number or value has not been assigned to a field or when the field has not been populated by performing a calculation on that field.

It is bad practice to not assign a value to a numeric field before using it. The program will usually terminate abnormally once the uninitialized field is referenced in the program. The proper way to do this is to assign a numeric value to the field before it is used as in the example below.

Your code might then read

  05 MY-NUMBER-FIELD  PIC s99  value 0.  This assigns 0 to the field and since no sign was specified it is assumed to be positive.

The fact that it is showing values of A B C etc. is because the values are in hexadecimal. A hexadecimal value of A breaks down to two half bytes one of which is 12 (C hex value) and the other is 1(1 hex value). A Value of C as applied to a number is the sign, in this case positive, and the value of 1 is the actual numeric value. So a value of c1 is a positive 1. You might ask how does a C become 12. This is because hexadecimal is base 16 and not base 10. Which means one position can represent 16 values. Just as in decimal arithmetic one position can represent 10 values, i.e., 0-9. Hex math has the same fist 10 values as decimal, i.e., 0-9 but when you get to the number 10, it is represented by A, 11 by B. 12 by C etc., on up to F which represents 15. 10, 11, 13 etc. still only take up one position, while in decimal representation the number 10 takes up 2. One for the number 1 and one for the number 0.

The letter j represents a minus 1 value because the low order half-byte is a D. D is the sign for a negative number. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 ETC----DECIMAL

1 2 3 4 5 6 7 8 9 A B C D E F 10 11 12 13 14 ETC ----HEXADECIMAL EQUIVALENT

Looking at the above the number 19 in decimal is saying I have 1 ten and nine ones in hexadecimal the number 19 is represented by 13, that is, I have 1 sixteen and 3 ones.

Continuing on, the number 14 in hexadecimal, meaning I have 1 sixteen and 4 ones is represented by 20 in decimal, that is, 2 tens and 0 ones.

--24.136.194.21 (talk) 21:23, 15 December 2007 (UTC)Michael Lofrano

PROBLEMS WITH "PIC S9 USAGE DISPLAY"

Unfortunately the implementation of the sign on DISPLAY fields is platform specific (hardware and OS), with differing values applied to the first nibble to indicate negative or positive - some platforms do nothing for positive, others do...

For numeric data in cross-platform output files and database "character" fields, use formatted numerics:

 PIC +9 USAGE DISPLAY  (show both negative and positive sign)
 PIC -9 USAGE DISPLAY  (show negative, positive leaves a space)

instead of:

 PIC S9 USAGE DISPLAY (do not use!)

I anybody knows of a list of the different platforms implementation of this, I would very much like to know about it.

Ynohoo (talk) 19:55, 3 June 2009 (UTC)

This is not the proper place to ask questions about COBOL; this page is for discussing improvments to the COBOL article. That being said, you might find answers to your questions about zoned and packed decimal data in the binary-coded decimal article. — Loadmaster (talk) 23:19, 3 June 2009 (UTC)

Navobox

The "Other third- and fourth-generation programming languages" section would be better placed within a navbox. SharkD (talk) 09:40, 25 October 2009 (UTC)

Bogus lines deleted

I have been a Cobol programmer for many years in many different environments and i have NEVER seen a line like the following:

           DISPLAY " " LINE 1 POSITION 1 ERASE EOS.
           DISPLAY "Hello, world." LINE 15 POSITION 10.

If i want to display "hello word" i just write: display 'hello world'. why do people who obviously have never programmed in Cobol insist on explaining this language to others?

I have programmed COBOL in many different environments as well. I recognise the clauses LINE x POSITION y EOS as clauses that an old PC COBOL compiler supported. This dates back to the DOS days.....

193.134.254.145 (talk) 13:10, 18 August 2008 (UTC) Toine Michielse

Back in about '83 I used a variant of cobol that used exactly this sytax to place text onto a CP/M terminal.Starfiend (talk) 11:18, 12 March 2009 (UTC)

OpenVMS COBOL supports a similar syntax on ACCEPT and DISPLAY to position the cursor on the screen. My compiler also supports a SCREEN SECTION but it's not very flexible so we stick to the non-standard extensions. 74.104.54.17 (talk) 21:25, 22 November 2009 (UTC)

Section "Defense": No citations

Notably, section "Defense" features no citations and no support for the claims. Also, the claim itself is pretty senseless, in my personal opinion; similar code can be written much more concisely and in an easier-to-read manner in many other languages. Ivucica (talk) 12:47, 24 October 2009 (UTC)

I've used Visual Basic, C++, Java, JavaScript, HTML, CSS, ActionScript, PostScript, Assembly, COBOL, and PHP. COBOL is the easiest to read of the bunch. People who don't know COBOL can look at the code and understand much of it. People who know COBOL can debug programs that don't have comments. COBOL is also the most proper language grammatically. I'm an English-grammar Nazi, so I appreciate being able to hyphenate my variable names (e.g., TOTAL-COST vs. totalCost). Programming in other languages teaches you bad grammar. Larry Wall, a supposed linguist, should have known better when he invented Perl. Here's another example: Statements end in a period in COBOL -- not a semi-colon.

No, that is wrong. COBOL sentences end with a period; statements do end with a semicolon. There can be several statements within a single sentence. T-bonham (talk) 07:16, 24 May 2010 (UTC)

To be pedantic about it, sentences end with a period, while statements do not. A sentence is composed of one or more statements. Delimiting commas and semicolons are optional in every context that allows them. — Loadmaster (talk) 02:51, 25 May 2010 (UTC)

I also like that you can put line numbers into your code. I write programs in Notepad, so that helps. Further, the programs are well organized, with clearly-labeled sections for your variables (which go at the top of the program -- which is good form), your name, etc.--Drknkn (talk) 08:35, 25 October 2009 (UTC)

The goal was to permit programs to be written almost in standard English. However, there's a joke that goes "When it becomes possible for computer programmers to write in English, it will be discovered thae computer programmers cannot write in English."WHPratt (talk) 18:14, 29 December 2009 (UTC)

Data types

I added a "Data types" section. This highlights the rich set of COBOL types, a few of which do not exist in most other languages. — Loadmaster (talk) 18:58, 17 January 2008 (UTC)

Hmm ... First, this seems like a good section to add. COBOL's take on data types is distinctive and noteworthy. Here are some questions and comments from someone not greatly familiar with COBOL (I took a course on it in high school, which was, um, a while ago :-)

• What facilities does COBOL have for defining new data types? I assume this would fall under "support for OO". The whole issue of built-in data types has become less prominent over time as languages have moved toward smaller sets of primitives and more flexible means for defining new types. This makes the issue of what built-in types a language supports less important than what libraries/classes/APIs/whatever have been written so far. E.g., is there a good implementation of priority queues or open-chained hash tables? This will of course change over time and you can always fix it yourself if you need to.

There is no way to define any "new" datatype other than a group (record), which is an aggregate (structure) of simpler types. There is no "typedef" feature like C. — Loadmaster (talk) 03:16, 19 September 2008 (UTC)
(additional comments made by me below are unsigned)

• What is "Edited Character"? As I understand it, "Character(...)" is the equivalent of a fixed-length character array (as opposed to an arbitrary-length string) in other languages, but it's not clear to me what the "edited" part adds.

Moving a character field into an edited character field adds insertion characters. Think of formatting a phone number or SSN.

• Packed decimal seems more a representation than a data type. Are there any operations you can do with packed decimal you can't do with ordinary decimal? The analogy here, I think, would be a packed-BCD implementation of Decimal vs. a plain binary implementation. If there is a difference in, say, how they are written to disk, that seems separate from the implementation used in memory. You can always define whatever serializer/deserializer you want for a given type, numeric or not, independent of the internal representation.

It's similar to the difference between int and long in C, since they are both binary integer types. Likewise, packed and zoned decimal are both decimal fixed-point types. Since they have different declaration names (USAGE IS COMP-3, USAGE IS DISPLAY), and explict rules exist for converting between the two, they should rightly be considered different types.

• Likewise zoned decimal. This seems a hack to allow a number to be printed directly in EBCDIC without conversion. This makes sense on machines that support EBCDIC directly — presumably the compiler is able to optimize handling directly. In other languages this would probably have to be handled by a set of native-coded library routines. Is this much of an issue on modern architectures anyway?

ASCII COBOL compilers support ASCII zoned decimal values. Don't assume COBOL runs on only EBCDIC machines or uses an EBCDIC decimal/character encoding alone. IBM S/360 hardware and its descendants do directly support packed and zoned arithmetic operations, and yes, these are usually supported by runtime library routines on other hardware architectures. (I should know, since I wrote a COBOL compiler for multiple flavors of UNIX.)

• As with edited character, what does "edited" add to numeric?

Again, floating and fixed insertion characters are added to the digits. Consider moving the numeric value -1245.60 to an edited zoned field with a picture of $**,**9.99CR, which yields "$**1,245.60CR". This is one of the more useful features unique to COBOL (and PL/1). Other languages (C, C++, Java, etc.) do this with library routines.

• Group(record), and array seem more like the usual facilities for deriving new types from existing ones, rather than types themselves

It's true that COBOL does not distinguish one group type from another (they are all treated as character types deep down). But the COBOL specification deems them separate types, or perhaps "attributes" of data fields.

• Variable-length array looks like what many languages would call a fixed-length array coupled with a size indicator. I would expect "variable-length" to mean "known only at run-time" (e.g., for a parameter) and/or "resizable (up to memory limits) at run time".

Yes, except that some implementations (notably IBM) actually only reserve enough space for the current size of the variable array; data fields following the array (within the same outer group) are shifted in memory accordingly. It's a real pain for the compiler writer, needless to say, but it's a valuable feature when reading and writing variable-length data records to/from files.

• RENAME looks much like FORTRAN's COMMON blocks and C's unions. Am I right in thinking it gives an alternate pointer into an existing structure? It's also possible to define unions without reference to storage layouts, either through algebraic data types or the usual polymorphic dispatch machinery, but this doesn't seem to be what RENAME is about.

You're almost right: standard COBOL only has names for data fields and no such thing as pointers. RENAME gives you a way to treat a range of variables as straight character data. REDEFINES is a cleaner way to do unions (but still generally not a good idea).

• Condition names look more like a syntactic construct than a data type. Could you give an example of how they might be used?

They are used to encode simple range comparisons on a single data field. So I could define condition names PAY-IS-SALARY and PAY-IS-HOURLY on the 1-character data field SALARY-TYPE as tests for the values 'S' and 'H', for example. Then the statement "IF PAY-IS-SALARY" is equivalent to "IF SALARY-TYPE = 'S'". Comparison ranges can also be coded. Again, technically, they are another kind of datatype, if for no other reason than that every user-defined identifier must have a type.

• Is an array index tied to a particular array type? I could imagine saying "FOO is a 12-element array. I is an index into FOO" and expect the compiler catch an attempt to assign the constant 13 to I and the runtime to catch an attempt to increment I when it's already 12. Is this what the INDEX declaration does?

An INDEX variable can be used on any array/table. It essentially holds a simple subscript value, but the standard is worded in such as way that it could actually hold something like a byte offset into the array instead. Array subscript bounds checking is done only at runtime, if it's even done at all.

This is also implementation dependent. ICL cobol, for example, allows an entry such as 01 WS-ITEM PIC X OCCURS 10 INDEXED BY WS-IX. In this example WS-IX is the index into the array WS-ITEM, and cannot be used on any other array. It also does not have its own 01 or 77 entry. However rather than MOVE or ADD/SUBTRACT, all assignments to or from WS-IX are done by SET. E.g "SET WS-IX TO 1.", "SET WS-IX UP BY 2.", "SET WS-IX TO WS-LAST-NUM." or "SET WS-IX-STORE TO WS-IX." It is possible to set to 0 or ZERO, but doing so generates a compiler warning, and a run time error will be generated if the index is out of range. It is possible to define more than one index, and in a multi dimensional array, have indexes on more than 1 level. Note you still need to use the standard array layout to reference the item, i.e. WS-ITEM(WS-IX). Starfiend (talk) 23:11, 7 February 2010 (UTC)

• The 30-digit limit on the BCD types seems arbitrary, as does the 7-dimension limit on arrays. How does one generally work around these. Or does one? I can't think of any recent languages with multidimensional arrays built in, anyway. If you want matrix behavior, you can pick your favorite matrix-algebra library (which may well use a flat array behind the scenes by default).

The 30-digit fixed-point limit probably arises from IBM's original hardware support for packed decimal operations. I seriously doubt that many applications actually need more than 12 or 15 digits in real life. The 7 dimension limit is an improvement over the old COBOL-66 limit of 3 dimensions. Many compilers allow many more (the compiler I worked had no limit on table dimensions). If you mean that most modern languages actually support multidimensional arrays as arrays of arrays, then yes, COBOL can be considered to directly support multidimensional arrays/tables.

• It's interesting that vendors provide data and function pointers as extensions. Again, these are more constructs for deriving new types than types themselves. Arguably, language X with pointers is a different language from plain language X.

Yes, and pointers are generally used in combination with other nonstandard features liked dynamically loaded libraries and dynamic memory allocation.

Anyway, thanks for the additions. -Dmh (talk) 06:56, 23 January 2008 (UTC)

No prob. — Loadmaster (talk) 03:16, 19 September 2008 (UTC)

Wmklein2 (talk) 05:53, 22 December 2008 (UTC) I will try and respond (later) to some of these question and try to update the actual table, but a few comments to start with:

• The 2002 Standard increased the maximum size of numeric data items from 18 to 31. Some vendors, e.g. IBM and Micro Focus, have already implemented this capability.

• With the 2002 Standard, USAGE POINTER is now "Standard", however, the SET ADDRESS feature is slightly different from that implemented by most vendors as it requires the "BASED" attribute for data items.

• The draft of the next Standard includes both PROCEDURE POINTER and FUNCTION POINTER data types.

• The 2002 Standard introduce the TYPE and TYPEDEF prhases for "user defined types". These may be "STYRONG" or "WEAK" user defined types.

• The 2002 Standard also introduced "true binary" data types (that are not truncated on BASE 10 content), as well as floating-point and bit/binary data types.

• National Data types (well suited for but not requiring UNICODE) also became Standard - along with "LOCALE based" editing.

A little late here, since I haven't visited the page in a while, but these are outstanding answers. Thanks! --Dmh (talk) 22:07, 14 August 2010 (UTC)

Too little about COBOL yet

I hoped I could find some solid information on the language COBOL here. Contributors have as yet mainly concentrated on criticizing and defending COBOL, instead of first factually describing the language and its properties in detail. I find the result rather boring. Sadly, this is rather typical for many discussions on actually interesting computer subjects. --Liberatus 00:20, 7 Mar 2005 (UTC)

Not much seems to have been changed. Unfortunately, my exposure to COBOL is limited and not recent, so I can't really contribute much. -Dmh 19:29, 17 March 2006 (UTC)

The real beauty of COBOL is seen when making programming changes and enhancements. For example: for decades I wrote very complex and deep nested "IF" conditional statements that were also very self documenting. Now even decades later any self-respecting programmer could easily follow my complex conditional logic. This is key to the acceptance of any language but only COBOL is the best for self documenting code, provided there are IT coding standards that promote this unique self documenting feature. The problem is that most shops never see the need to have any IT standards for self documenting programs which leads to nothing but nightmares for even basic programming maintenance tasks. GPageIII (talk) 10:56, 21 February 2009 (UTC)

"The real beauty of COBOL" is a contradiction of terms! :D 200.114.149.47 (talk) 17:22, 14 September 2010 (UTC)

Broke list of syntactic features out of defense

The "defense" section has acquired a list of statements about "ADD X TO Y" and a couple of others. These included some statements about how forward-looking etc. those constructs were. I don't necessarily want to lose the thought that COBOL was, say, more readable than FORTRAN with six-character identifiers, but making blanket statements about the COBOL constructs being ahead of their time is POV.

I've tried to remove the most blatant POV statements while keeping the newly-added facts. A couple of notes:

I'm not entirely convinced that "ADD X TO Y" had no equivalent until C came along, but I can't find the counterexample. It doesn't appear to have been in ALGOL 58 or 60. In any case, however, we shouldn't assert that no one else had it until C unless someone has actually checked all the other languages around at the time. And there are a bunch.

It's a matter of opinion (or at least of controlled experiment) whether the abbreviated conditional is more readable than the usual version. IMHO, it would take some getting used to (but then so does most of Perl).

It might be interesting to compare, say COBOL, ALGOL, FORTRAN and LISP of similar vintages. Another interesting approach would be to see which constructs COBOL originated, or for which it was the first widely-used language to provide support, and which are still in wide use today. From that perspective, long identifiers and update-in-place are plausible candidates. -Dmh (talk) 00:59, 31 December 2007 (UTC)

I would include long identifier names, edited character and edited numeric types (picture clauses), fixed-point decimal numbers, variable-length arrays, and built-in support for indexed file handling. — Loadmaster (talk) 03:21, 19 September 2008 (UTC)

And copybooks. COBOL seems to have been the first standardized language to have included a copy mechanism. (Though both Grace Hopper & Bob Bemer had included them in predecessor languages to COBOL.) This feature is common now; nearly every language has some way of doing it. COBOL was first, probably because the intended use (business processing) had a lot of need for it (common files, calculating procedures, etc.). T-bonham (talk) 02:48, 8 June 2011 (UTC)

Program Structure

There isn't any mention yet in the article for overall structure of a COBOL program; IE: you have at the high level, divisions, which might contain sections, which contains paragraphs.

IDENTIFICATION DIVISION.
ENVIRONMENT DIVISION.
DATA DIVISION.
PROCEDURE DIVISION.

And mentioning the card-column restrictions should also be mentioned; some statements should begin in Area A (columns 8-11), and others in Area B (columns 12-72).

MeekMark (talk) 17:09, 21 July 2011 (UTC)

Claim: COBOL has no support for structured programming

As far as I understand it, Cobol does support structured programming, at least within a single program subroutines are common in all the code I've seen (and we rarely use GOTO!).

I'd also like to see a list of what Cobol does that other languages don't (or don't do as well), for example variable redefinition or subdefinition.

Cobol variable definition is closely tied to the actual memory space used by the variables (and is probably due to its heritage with punchcards).

Cobol allows the programmer to subdefine variables; this is like a C typedef.

this is not really a typedef. A typedef is to take a general type and give it a specific alias. 'typedefs' are not really possible in COBOL unless you use the 'COPY' statement (in C: #include) to redefine variables under a different name. This also works with the picture clause. -- Merlin

(From memory)

10 employee-name   pic x(30)
  15 empl-fn         pic x(15)
  15 empl-mi         pic x(01)
  15 empl-ln         pic x(14)

Later in code, "move spaces to employee-name" clears all fields and subfields.

You may also redefine variables, giving a single variable more than one name.

10 business-name redefines employee-name

(another example)

 10   STD-DATE         PIC X(08)  /* YYYYMMDD, char format*/
  15  STD-DATE-CC      PIC X(02)
  15  STD-DATE-YYMMDD  PIC X(06)  /* YYMMDD, char format */
   20 STD-DATE-YY      PIC X(02)
   20 STD-DATE-MMDD    PIC X(04)

88-level values may be used to list options for flags or allowable values for variables.

10 employee-found-sw     pic x(01)
88 employee-found        value "Y"
88 employee-not-found    value "N"

10 employee-type-flag    pic x(01)
88 employee-type-standard   value "S"
88 employee-type-exempt     value "E"
88 employee-type-contractor value "C"

(later, in code:)

move employee-type-standard to employee-type-flag
if employee-type-standard ...

Dare I mention more english-like syntax (though it may perhaps be more readable to PHBs, most programmers don't seem to like it).

move 7 to days-of-the-week
if days-of-the-week=7 then next sentence.

(darn, I don't have my code here so I can't give more examples) -- Justfred

Can someone add program sample like "hello world" ?

IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO-WORLD
ENVIRONMENT DIVISION.
DATA DIVISION.
PROCEDURE DIVISION.
    DISPLAY "HELLO WORLD".
    EXIT PROGRAM.

from my (admittedly distant) memory, PICs were only used for the "lowest-level" variables, e.g.:

10 employee-name.
  15 empl-fn         pic x(15).
  15 empl-mi         pic x(01).
  15 empl-ln         pic x(14).

which makes employee-name implicitly PIC X(30). There's also REDEFINES to refer to storage in different ways, e.g. (artificial example!):

10 employee-name.
  15 empl-fn         pic x(15).
  15 empl-mi         pic x(01).
  15 empl-ln         pic x(14).
10 employee-name-type-2 redefines employee-name.
  15 empl-title      pic x(4).
  15 empl-first      pic x(13).
  15 empl-last       pic x(13).

REDEFINES was (presumably still is) often used when records in a file could have different structures - e.g. header and detail records.

Another example of REDEFINES extensive abilities was to make a "table" of dummy values, then turn that into an array. For example:

01 ws-day-values.
   05 ws-dayname-filler.
      10 filler       pic x(3) value "Sun".
      10 filler       pic x(3) value "Mon".
      10 filler       pic x(3) value "Tue".
      10 filler       pic x(3) value "Wed".
      10 filler       pic x(3) value "Thu".
      10 filler       pic x(3) value "Fri".
      10 filler       pic x(3) value "Sat".
   05 ws-dayname-table redefines ws-dayname-filler
      occurs 7 times pic x(3).

(Imagine building a construct like this to write checks with word values and not just numbers!) DieselRam (talk) 12:42, 16 August 2011 (UTC)

AndrewWTaylor 14:17, 16 January 2006 (UTC)

Wmklein2 (talk) 06:01, 22 December 2008 (UTC) general comment on "no support for structured programming" This may (OR MAY NOT) have been true for 1974 Standard COBOL, but with the '85 Standard (over 20 years ago) and the later 2002 Standard, this is certainly NOT TRUE.

"CUrrent COBOL" supports:

• socpe terminators for "nested" consturcts like

  Read SomeFile
    At End
     If A = "A literal"
         Perform Some-Routine
     Else
         Perform Normal-Routine
     End-IF
     Display "either way for IF"
   Not At End
     Perform Normal-Read-Processing
  End-Read

• It also now supports
  • Nested programming (local and global variables and exception handling)
  • User Defined functions
  • TYPEDEF (both STRONG and WEAK user-defined data types)
  • ect

Too little about Grace Hopper

Too little about Grace Hopper. Also, the writing is poor. The article needs serious editing. Gingermint (talk) 08:20, 21 October 2011 (UTC)

Grace Hopper, the creator of COBOL specification?

Originally the History section just stated "The COBOL specification was created during the second half of 1959." Then suddenly somebody added a name to it. And it got replaced with another name. And another. Finally reaching Grace Hopper.

Grace Murray Hopper article clearly doesn't name her as the author of COBOL specification.

See also this discussion in Hacker News, which might provide some valuable sources: http://news.ycombinator.com/item?id=1954812 —Preceding unsigned comment added by Renku (talk • contribs) 18:07, 2 December 2010 (UTC)

Whoever put that in was probably referring to her 1955 paper "Preliminary Definitions, Data Processing Compiler." where she listed a sample program similar to COBOL. The specification was released in 1959 but Hopper wasn't the sole author. 67.165.86.89 (talk) 21:58, 6 December 2010 (UTC)

New comment (I'm probably adding this note wrong): OK I have no hard evidence to add (other than the display that was at the now-defunct computer museum in Boston) but I've *always* heard Grace Hopper credited as the inventor of COBOL. I mean back into the 1980s. Maybe it's not true, but it's certainly not a random claim whipped up in the last few months. 71.234.76.253 (talk) 22:37, 8 December 2010 (UTC)

I've just finished reading Jean Sammet's paper in the ACM SIGPLAN Notices, Volume 13, No. 8, p. 121...

...and Hopper wasn't even on the committee. Ms. Sammet cites Hopper's work extensively as the basis of much of the design of COBOL, but Hopper herself was not on the committee and did not define the standard (except by establishing many of the conventions used in COBOL). Labelreader (talk) 21:44, 14 January 2011 (UTC)labelreader

Right here in Wiki, in the FLOW-MATIC article, you can see some of the extent that her early, working languages influenced and were incorporated into COBOL.

Also, she was commonly known not as the Mother of COBOL, not the inventor. She was heavily involved in the push to create a common, machine-independent language (at a time when many claimed that the very idea of a computer program that could run on different machines was irrational). That first conference that created COBOL was organized by the Pentagon, and her experience & reputation in the military helped trigger this meeting. And then, after COBOL was designed, she did a great deal of missionary work to promote it, both within her own company & others, and to influence customers (especially government ones) to demand COBOL on any new machine they purchased. Her influence was instrumental in the snowball effect of COBOL adoption in the early years. So she didn't actually invent COBOL, but her mothering of it in the early years arguably allowed it to survive for decades since then. T-bonham (talk) 08:11, 1 May 2012 (UTC)

It's over 9000!

Notice under the examples section, there's the example that involves salaries, one of them says "IF SALARY > 9000", meaning "if salary is OVER 9000!!!!!!" IT'S OVER 9000!!!!1111!! That's a reference to an internet meme by the way. Search it up on Google or Wikipedia if you want more information. 24.129.235.8 (talk) 00:41, 7 April 2009 (UTC)

i loved that... —Preceding unsigned comment added by 58.109.89.34 (talk) 11:48, 26 May 2009 (UTC)

Have to. Here is a line from the OpenCOBOL project feature list: "Over 9000 NIST COBOL 85 test suite tests passed." And THAT is an OVER 9000. BTiffin (talk) 07:20, 12 February 2013 (UTC)

Major Implementations - OpenCOBOL and Micro Focus ?

I'd add IBM, but I work for IBM so that would be against the Wikipedia guidelines. Does the "major implementations" section add any value to this page? Seems rather subjective.

Dwaynemo (talk) 01:49, 5 March 2013 (UTC)

Wikipedia naming conventions for languages

• mention of Wikipedia:Naming conventions (languages)

...which says "Programming languages should be disambiguated with the suffix "(programming language)" if the name is not sufficiently unambiguous. For example, VBScript does not need clarification, while Python (programming language) does." There is a dab page COBOL (disambiguation), but there's nothing on the page named just "COBOL" other than the programming language, so I'm not sure it needs clarification. Guy Harris (talk) 23:39, 19 May 2013 (UTC)

Proposed merger of Picture clause

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

The result of this discussion was merge via silent consensus.

---

I believe Picture clause should be merged into the COBOL article as it is primarily a COBOL feature. The article is small and will fit easily into this article. EdwardH (talk) 09:07, 1 August 2014 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

CoBOL or COBOL?

This isn't a big deal to me, but did anyone else learn it as "CoBOL" (Common Business Oriented Language)? Any old-schoolers out there who learned on punch cards? Woo-hoo! Lightbreather (talk) 00:38, 26 July 2014 (UTC)

I only ever saw it written as COBOL, but often wondered how a lower case "o" became an upper case "O" in the acronym. HiLo48 (talk) 02:03, 27 July 2014 (UTC)

@Lightbreather: I think it's just because everything was all caps (sixbit) in the early days... FORTRAN was all-caps too. The good ol' days before that was CONSIDERED SHOUTING & UNCIVIL. Yup, I learned on punch cards, and before that... BASIC on punched tape – the same way Bill Gates learned it. Check out Timeline of DOS operating systems. Wbm1058 (talk) 02:38, 29 July 2014 (UTC)

Most programming languages (and operating systems) were originally spelled all-caps. A very incomplete list of examples: COBOL, FORTRAN, LISP, APL, BASIC, BAL, RPG, ALGOL, PL/I, SNOBOL, CPL, BCPL, etc. The Pascal language appears to be the first one (ca. 1970) that changed the trend, so now we see names like Ada, Perl, Java, Haskell, Python, etc., as well as renamings of the old languages, e.g., LISP is now spelled as "Lisp". — Loadmaster (talk) 20:47, 15 January 2015 (UTC)

Pascal, Ada, Haskell, Curry, are proper names, while FORTRAN, APL, LISP, BASIC, PL/I, not. At the time that Pascal was released, the 8 bit ASCII code was available, a curiosity is that Pascal was implemented in a CDC computer, as far as I know, CDC had a 60 bit word, and used 6 bit code, each word could hold 10 chars.

COBOL isn't influenced by C++

How in the world is COBOL influenced by C++ or any other language noted in the sidebar? The side box needs to be fixed, as it is simply erronous. 199.212.69.109 (talk) 17:23, 15 January 2015 (UTC)

From the Cobol '97 status report(provided as a reference in the article):

The draft 1997 proposal for Cobol incorporates the basic object-oriented programming capabilities found in C++ and Smalltalk (see Table 1): inheritance, which allows objects to inherit data and behaviors from other objects; polymorphism, which simplifies coding by letting programmers use a single interface to access objects of different classes; and encapsulation, which hides the implementation of data and methods from clients (user code), thereby protecting clients from the effects of implementation change.

Martijn Hoekstra (talk)

So it would be accurate to say that COBOL 2002 (the object-oriented version of COBOL), or more precisely, the enhancements made to COBOL 2002, was influenced by C++. — Loadmaster (talk) 20:38, 15 January 2015 (UTC)

I've added notes clarifying that C++ and Smalltalk only influenced COBOL 2002's OO features. EdwardH (talk) 19:41, 17 January 2015 (UTC)

GA Review

This review is transcluded from Talk:COBOL/GA1. The edit link for this section can be used to add comments to the review.

Reviewer: Esquivalience (talk · contribs) 21:09, 3 February 2015 (UTC)

I am going to commence the review as soon as I can. Esquivalience ^t 21:09, 3 February 2015 (UTC)

First review

Looks good; but ref. 5 really needs to be replaced with a better source (ref. 4 is not too bad).

• "In contrast with modern, succinct notation like y = x;, COBOL uses MOVE x TO y." - Should be something like: "COBOL uses more traditional notation [or "more English-like notation", whichever fits better] (in this case, MOVE x TO y)". And shouldn't it be "syntax" instead of "notation"?

• "A 1959 survey had found that in any data processing installation, the programming costs at least $800,000 and that translating programs to run on new hardware would cost $600,000." - correct grammar in underlined text (suggestions above). Also, the source says the cost is on average, so I think it should mention that the cost is on average.

• "In the early 1990s it was decided to add object-orientation in the next full revision of COBOL. - should be reworded.

 Done I've applied the changes you've suggested. Thanks for the comments! EdwardH (talk) 20:33, 9 February 2015 (UTC)

Looks good! I'll scour through sources to see if there's no OR, then, if there are no problems, promote. Esquivalience ^t 21:20, 9 February 2015 (UTC)

List for first review

GA review (see here for what the criteria are, and here for what they are not)

1. It is reasonably well written.

   a (prose, no copyvios, spelling and grammar): b (MoS for lead, layout, word choice, fiction, and lists):

   See suggested improvements above.

2. It is factually accurate and verifiable.

   a (reference section): b (citations to reliable sources): c (OR):

   Find a more reliable source than ref. 5. Also, checking more sources to see if there is original research, but looks good so far.

3. It is broad in its coverage.

   a (major aspects): b (focused):

   The strong point of this article. Very comprehensive.

4. It follows the neutral point of view policy.

   Fair representation without bias:

5. It is stable.

   No edit wars, etc.:

6. It is illustrated by images and other media, where possible and appropriate.

   a (images are tagged and non-free content have fair use rationales): b (appropriate use with suitable captions):

7. Overall:

   Pass/Fail:

Final review

GA review (see here for what the criteria are, and here for what they are not)

1. It is reasonably well written.

   a (prose, no copyvios, spelling and grammar): b (MoS for lead, layout, word choice, fiction, and lists):

2. It is factually accurate and verifiable.

   a (reference section): b (citations to reliable sources): c (OR):

3. It is broad in its coverage.

   a (major aspects): b (focused):

4. It follows the neutral point of view policy.

   Fair representation without bias:

5. It is stable.

   No edit wars, etc.:

6. It is illustrated by images and other media, where possible and appropriate.

   a (images are tagged and non-free content have fair use rationales): b (appropriate use with suitable captions):

7. Overall:

   Pass/Fail:

More on REDEFINES

Data structures are constructed with records corresponding to products AxBxC, and variants which correspond to unions (AxBxC) U (AxD). If REDEFINES implements unions (either joint or disjoint I do not remember), it is important to extend this subject in the article. — Preceding unsigned comment added by 189.178.42.144 (talk) 19:26, 26 December 2015 (UTC)

More on the lack of encapsulation, and ABC batch paradigm

COBOL is a good example of why a programming language should encourage good programming practices. COBOL didn't, and many programmers were improvised, because the demand of programmers exceeded the available. Even office boys were offered to became programmers after a short programming course. Structured programing was not known by the 60s, databases were not yet available.

Programmers learned the ABC batch paradigm. ABC means in Spanish, Altas (Add), Bajas (delete) and Cambios (Changes), I do not know how this was called in English.

They build monolithic programs, not even use the subroutine and call statements, but local subroutines call with perform.

COBOL was the paradigm of all bad practices, like indiscriminate use of global variables, bad modularity, no code reuse (just reused the ABC skeleton), etc.

Object orientation pays particular attention to encapsulation and inheritance. According to this article, OO Cobol, does not has encapsulation, and nothing is said about overloading, which is important for inheritance.

As far as I remember, COBOL, never had something like the entry points in Fortran, which implemented overloaded functions.

I came to this article, because I had the curiosity to know how COBOL became OO it's antithetic paradigm, due to the lack of encapsulation and overloading. I was not wrong, OO Cobol is not really OO. That language is in use because many IT Managers, are scared to dispose hard to upgrade but stable programs. There are many techniques to make this transition less risky, but not risk free.

I do not want to offend COBOL lovers, but this language is now obsolete, although not every program should be written in the OO style. A payroll is essentially an ABC batch program. COBOL had features to sort files, now database management systems are used instead of indexed files, an employee may be registered the hiring day, and magnetic cards, transponders, or finger prints are registering their assistance to work, but are paid on a week, month or 2 times a month basis. So it is still almost likely to be programmed in a batch style. Those systems are the reason that many inherited systems are sill running in banks and government offices.

This points could be added to the article, as technical and social practices, maybe a batch skeleton could be added to the article. — Preceding unsigned comment added by 189.178.42.144 (talk) 20:08, 26 December 2015 (UTC)

I don't want to offend academic computer scientists, but there has to be a reason why COBOL was so successful - could it be that being designed by non-academic computer scientists was a big plus. The article makes the POV statement that it suffered as a result.Gomez2002 (talk) 15:57, 20 January 2016 (UTC)

Strange use of second generation language

Where does come your use of second generation language: it is usually reserved for assembly languages. -- Hgfernan 12 May 2004

I agree. COBOL is a third generation language. other examples of third generation languages would be FORTRAN and BASIC. If someone else doesn't correct it soon I may do so. It is a clear mistake. enhandle nov 2004 — Preceding unsigned comment added by Enhandle (talk • contribs) 02:48, 14 November 2004‎

Perhaps GNU Cobol is the way to go. Works on Linux, Windows, Mainframes, you name it! https://sourceforge.net/projects/open-cobol/ — Preceding unsigned comment added by 2601:3C6:8000:8C0E:18E6:80A2:D9DE:B2A1 (talk) 22:36, 9 April 2016 (UTC)

Hello world example

I think the POV of the Hello World example should be changed. It seems to not just be showing COBOL syntax but making some point about the nature of the output. "The associated compiler listing generated over four pages of technical detail and job run information, for the single line of output from the 14 lines of COBOL"

The tone doesn't seem to be written by someone familiar with JCL or COBOL, and the output includes warning messages to get to "line 10". In other words there is a lot of spurious stuff that isn't relevant. Or if the intention is to show the level of detail possible in output from JCL or COBOL then it doesn't come across as positive and I am still not sure of the relevance to Hello World.

I think the comments about the compiler output should just be removed.Ei2g (talk) 12:39, 13 August 2016 (UTC)

Agreed. --A D Monroe III (talk) 20:05, 13 August 2016 (UTC)

Isolation from the computer science community - Grace Hopper?

I have a question about the second line of this section. Is it fair to say that "no academic computer scientists participated in the design of COBOL" when Grace Hopper was a technical consultant to the committee?

Yes, she participated in government and business pursuits, but she also spent nearly 20 years in the academy (Vassar, Yale for math PhD, then Harvard Computation Lab) working on computer science issues before such departments even existed. Furthermore, her work in those areas focused on what the article states the academy was concerned with at the time - "numerical analysis, physics and system programming."

I don't dispute that the process of creating COBOL was problematic without more input from the CS community, but would an edit to read "the only academic computer scientist who participated in the design of COBOL was Grace Hopper" be fair, or not? I do recognize that a secondary source would be needed.

Thanks!

Kshermer (talk) 01:58, 5 January 2017 (UTC)

@Kshermer: I agree that Grace Hopper was a computer scientist (though more engineering than academic) and as Jean Sammet had taught graduate courses on programming, one could argue she was a computer scientist as well. However, at the time of the committees, both were implied in business (Remington Rand and IBM, respectively), which might be relevant when interpreting the source of the sentence:

Five aspects of the historical development of COBOL can be traced as important influences in the alienation of COBOL from the computer science community. First, academic computer scientists did not participate in the design team. [Emphasis mine] The developers of COBOL were from the commercial community: the manufacturers and users of large data processing systems in industry and government (see the minutes in this issue for lists of the participants).

— p. 348

Do you think changing

No academic computer scientists participated in the design of COBOL: ...

to

No academics participated in the design of COBOL: ...

would help clarify things? Then the sentence suggests more that there were no professors/career academics on the committee. EdwardH (talk) 16:33, 5 January 2017 (UTC)

References

External links modified

Hello fellow Wikipedians,

I have just modified 2 external links on COBOL. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20140516214531/http://bobbemer.com/ to http://bobbemer.com/
• Corrected formatting/usage for http://www.csim.scu.edu.tw/~kuo/COBOL/COBOLCompiler/COBOL手冊/cob_lrf.pdf

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 08:15, 12 November 2016 (UTC)

Download Micro Focus Object COBOL 4.0 (32-bit) — Preceding unsigned comment added by 186.193.195.3 (talk) 12:15, 12 January 2017 (UTC)

Isolation from the computer science community - Students drilled to "hate COBOL"?

Back when I was in college, two COBOL classes were a mandatory part of the CPA (Computer Programmer Analyst) curriculum. Nothing "drilled" me to hate COBOL more than actually having to write programs in the hideous language. As a computer programmer for well over 30 years, I can honestly say that COBOL is among one of the most painful languages to work with. It's so damned verbose that it actually required you to print out your program to be able to see enough of it at one time to debug it back in the time of 80x24 displays. --Thoric (talk) 17:46, 7 February 2017 (UTC)

The Commonly Oriented Business (Oriented) Language

Back in the day when I did my COBOL exams, COBOL was mentioned as an acronym for "The Commonly Oriented Business Language", acknowledging that the meaning of the acronym as stated at the beginning of this article is more usual. Indeed in the book "A Step In Programming With C" by Rakesh Tyata (chapter 3 page 15 2009), he refers to it as an acronym for "The Commonly Oriented Business Oriented Language".

While I cannot cite what I was told 25 years ago, maybe the Rakesh Tyata definition could be included in the article? COBoL is a language that can be used by day-to-day programmers, most of who might be working in business. It was oriented for ease of use (however you might like/dislike it) rather than just business oriented; you can use COBoL for a range of coding needs. Richard Nowell (talk) 17:10, 2 February 2018 (UTC)

Backus–Naur Clarification Requested

The text makes two differing statements about Backus-Naur:

Although Backus–Naur form did exist at the time, the committee had not heard of it

rather than the new Backus–Naur form because few committee members had heard of it.

And it is possible that neither is accurate - the wikipedia article on Backus-Naur says it was first published in the ALGOL-60 report. COBOL's first version was 1959. So it may not have been available to be heard of, like Unix at the time. — Preceding unsigned comment added by 92.7.48.201 (talk) 08:31, 9 September 2018 (UTC)

Thanks for pointing this out. Looking at Sammet 1978b, the correct sentence is "the committee had not heard of it":

Certainly, BNF as a concept was not known to us. Again, remember, John's paper was only being presented in June; we were meeting in June, and I don't think any of us even saw the paper thereafter. [This refers to Backus (1959). See the references in the formal paper--ed.] When COBOL was defined it was severely criticized because the definition was not BNF.

I can't tell whether it was possible for anyone on the committee to have heard of it. Backus presented his work in a 1959 conference in Zurich and I don't when the proceedings were published or if pre-prints were shared. Backus worked at IBM as did a number of committee members. Criticism for not using BNF definitely came after the report was published in 1960. EdwardH (talk) 10:35, 9 September 2018 (UTC)

Split History section into separate article

The article is currently 109 kB long. The size guildline WP:SIZERULE says an article with prose over 100 kB "almost certainly should be divided". The essential part of this article is the exposition of COBOL's features and I think the "Criticism and Defense" section gives a useful (but slightly less essential) overview of the language's flaws and reaction to it. So, that leaves the History section looking disproportionately large.

The History section has enough sources and is long enough to justify being its own article. Viz., it relies on the HOPL I conference proceedings (which had an entire session dedicated to COBOL), Kurt Beyer's biography of Grace Hopper (which focusses on her role in the DoD design phase), Jean Sammet's history of COBOL and a miscellany of articles from Computerworld and other figures involved in the design of COBOL. The History section takes around 30 kB, so removing it and replacing it with a 5 kB summary should get us acceptably close to WP:SIZEGUIDE's "Probably should be divided" range.

I am open to a more aggressive removal of content, though I can only see the History section as a good place to do so. In particular, the "Background" and "COBOL 60" sections could be shortened and the sections from "COBOL-74" onwards could have the standards' lists of features better summarised.

EdwardH (talk) 20:24, 17 July 2018 (UTC)

I think the "Features"/syntax section is also excessive, and might be a good section to split into its own article COBOL syntax. power~enwiki (π, ν) 18:13, 19 August 2018 (UTC)

@Power~enwiki: I think a COBOL syntax would come a bit too close to infringing WP:NOTMANUAL and would struggle to have enough references for notability. We could reduce the Features section anyway. I feel the historical "Hello, World!" example is unnecessary - it's more about MVS and JCL than COBOL. Uninteresting obscure features (e.g. 66 and 77 level-numbers) could be removed and the overview of statements could be compressed. EdwardH (talk) 09:33, 25 August 2018 (UTC)

The COBOL language is verbose, its programs are correspondingly long. Why should an article about COBOL be short?

That's a joke, but seriously speaking, COBOL is important for its history, and because there are still alive many inherited systems written in COBOL. For that reason, it is not a bad idea to keep all together.

It would be better to rewrite it more concisely, but not removing "uninteresting obscure features", contrary to that, it would be better to compare those features with contemporary languages or an abstract language.

For example: How does a variant or union type in C or Pascal, written in COBOL with the 88 level?

That is very important, because so, this article could cover, both, the features of the language and the anecdotes around this language, both are part of its history.

The belief that the 66 or 77 are "obscure and uninteresting" is shared by many programmers, but it is important to keep them, because they are related with low-level features, COBOL, in some way, seems a verbose assembly language. — Preceding unsigned comment added by 2806:107E:C:F09:218:DEFF:FE2B:1215 (talk) 11:33, 15 September 2018 (UTC)

Section "Influences on other languages"

Is there information about COBOL's influence on Perl? There are no details at [1] (which mentions COBOL, without any detail, among the languages from which Perl features were taken) and [2] (Tom Christiansen?) only says that Perl wysiwiggery comes from COBOL pictures. Apokrif (talk) 23:21, 4 September 2018 (UTC)

COBOL pictures [3] appeared in Perl, but they're pretty trivial. Andy Dingley (talk) 00:20, 5 September 2018 (UTC)

Did really COBOL influenced Pascal and other languages with its record and variant types? NO!

It is often believed that Pascal records (the hierarchical nested levels) and the 88 level and redefines for variant records, influenced Pascal, (I don't remember the details of how, that is why I came to this article) that is not true, those structures are very old in mathematics, they are called: product and disjoint union. Moreover, there is a talk about women and computing or something like that in Youtube, given by a woman who was a collaborator of Grace Hooper. There she told that one collaborator who worked for Rand, had a language with the records and variant types, which was the only thing that Hooper didn't invent, "all the rest was created by Hooper".

That reflected that the main concern in the design of COBOL, was all the bureaucratic aspects, like who wrote what and who ordered it, and so on. They didn't understood that a program is a mathematical proof, and as such it can be systematically developed with the problem solving methods and heuristics. They naively thought that programs were cooking recipes, a very widespread metaphor that encouraged many people to became programmers. Programming is a more serious activity which requires a good background in computing science. Sounds like a pleonasm, but many programmers just learn the syntax of a language and start to write code. Was that inherited from COBOL? I think that it is true in the extent that COBOL promoted programming in English, not in "weird" mathematical notation.

This article could compare critically, what good and bad features does COBOL have, on the light of an abstract well founded programming language or comparing with well designed languages. — Preceding unsigned comment added by 2806:107E:C:F09:218:DEFF:FE2B:1215 (talk) 12:52, 15 September 2018 (UTC)

Did Bemer coin the name "COBOL"?

The data is contradictory. Bemer himself said in 1971: We can't find a single individual who admits coining the acronym "COBOL". [4] But later he said the name was his idea, e.g. in interviews in 1997 [5] (probably a WP:RS) and 2003 [6] (not quite a WP:RS, but probably genuine anyway). Chrisahn (talk) 16:20, 12 April 2020 (UTC)