Talk:COBOL

From Wikipedia, the free encyclopedia

Contents 1 Too little about COBOL yet 2 Current total for lines of COBOL programs 3 Question about COBOL number formats 4 Claim: COBOL has no support for structured programming 5 Wikipedia naming conventions for languages 6 Strange use of second generation language 7 Bogus lines deleted 8 COBOL makes me think of Erwin 9 Every operating system? 10 Bad (Incomplete) program? 11 Code in "The Terminator" 12 COBOL: Durable or dead? 13 History of COBOL standards 14 "citation needed" 15 Popular culture 16 COBOL and XML 17 COMPUTE and optimizations 18 embedded programs, sub-programs and local variables 19 Broke list of syntactic features out of defense 20 Data types 21 Disambiguation 22 Wrong link 23 Information on validation of the standards

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

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

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

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

AndrewWTaylor 14:17, 16 January 2006 (UTC)

[edit] Wikipedia naming conventions for languages

• mention of Wikipedia:Naming conventions (languages)

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

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

[edit] COBOL makes me think of Erwin

User Friendly

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

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

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

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

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

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

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

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

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

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

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

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

[edit] 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.
• 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.
• 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.
• 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?
• As with edited character, what does "edited" add to numeric?
• Group(record), and array seem more like the usual facilities for deriving new types from existing ones, rather than types themselves
• 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".
• 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.
• Condition names look more like a syntactic construct than a data type. Could you give an example of how they might be used?
• 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?
• 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).
• 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.

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

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

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

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