Talk:COBOL

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)

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

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

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.

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

Wikipedia naming conventions for languages

• mention of Wikipedia:Naming conventions (languages)

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

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?

COBOL makes me think of Erwin

User Friendly

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

Every operating system?

The article says the following:

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

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

Similarly, this comment:

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

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

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

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

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)

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)

COBOL: Durable or dead?

W.marsh writes:

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

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

Atlant 18:28, 8 March 2006 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

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)

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

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)

Speedbase

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/