From Wikipedia, the free encyclopedia
Jump to: navigation, search
          This article is of interest to the following WikiProjects:
WikiProject Computing / Software (Rated B-class, High-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
B-Class article B  This article has been rated as B-Class on the project's quality scale.
 High  This article has been rated as High-importance on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Software (marked as High-importance).
WikiProject Computer science (Rated B-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Computer science, a collaborative effort to improve the coverage of Computer science related articles on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
B-Class article B  This article has been rated as B-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.

Too little about COBOL yet[edit]

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 (talk) 17:22, 14 September 2010 (UTC)

Current total for lines of COBOL programs[edit]

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, citing Gartner Group as a source.)

Question about COBOL number formats[edit]

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.

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


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)

Claim: COBOL has no support for structured programming[edit]

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" ?

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
         Perform Normal-Routine
     Display "either way for IF"
   Not At End
     Perform Normal-Read-Processing
  • 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

Wikipedia naming conventions for languages[edit]

...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)

Strange use of second generation language[edit]

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

Bogus lines deleted[edit]

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

           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..... (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. (talk) 21:25, 22 November 2009 (UTC)

COBOL makes me think of Erwin[edit]

User Friendly

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

Every operating system?[edit]

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)

Bad (Incomplete) program?[edit]

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




--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)

Code in "The Terminator"[edit]

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:

77 IDX PICTURE 9999.
77 SUM PICTURE 999999.

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:


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?[edit]

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 [citation needed], in commercial enterprises [citation needed] and on operating systems including IBM's z/OS [citation needed], Microsoft's Windows [citation needed], and the Unix/Linux families [citation needed].
Rewriting a COBOL application in a different language has not always been found worth the cost [citation needed].
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 [citation needed]. They also reported that more than half of all new "mission-critical" applications were still being created using COBOL [citation needed] — 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)[citation needed].

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? 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: -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[edit]

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)

"citation needed"[edit]

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 (talkcontribs) .

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)

Popular culture[edit]

Am I right in remembering that 1970's American boy band The Osmonds used to release records on the COBOL label? 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. —The preceding unsigned comment was added by (talkcontribs) .

COBOL and XML[edit]

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. (talk) 11:05, 12 March 2009 (UTC)

COMPUTE and optimizations[edit]

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[edit]

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:
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
Thanks for polishing up the paragraph.
- Andy 02:48, 27 January 2007 (UTC)

Broke list of syntactic features out of defense[edit]

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)

Data types[edit]

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)


There is a North East NY band named COBOL... may warrant a page/disabiguation —Preceding unsigned comment added by Kharaku (talkcontribs) 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)

Wrong link[edit]

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 (talkcontribs) 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.

Information on validation of the standards[edit]

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 (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.

British vs. American English[edit]

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.[edit]

An anonymous IP ( and added an external link to 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)

IBM manuals[edit]

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

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

It's over 9000![edit]

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. (talk) 00:41, 7 April 2009 (UTC)

i loved that... —Preceding unsigned comment added by (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)

Section "Defense": No citations[edit]

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)


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

Grace Hopper, the creator of COBOL specification?[edit]

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: —Preceding unsigned comment added by Renku (talkcontribs) 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. (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. (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)

Program Structure[edit]

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.


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)

Too little about Grace Hopper[edit]

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

Major Implementations - OpenCOBOL and Micro Focus ?[edit]

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)

CoBOL or COBOL?[edit]

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)

Proposed merger of Picture clause[edit]

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 above discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.