text:
Comet Shoemaker–Levy 9

Comet Shoemaker–Levy 9 (formally designated D/1993 F2) was a comet that broke apart in July 1992 and collided with Jupiter in July 1994, providing the first direct observation of an extraterrestrial collision of Solar System objects. This generated a large amount of coverage in the popular media, and the comet was closely observed by astronomers worldwide. The collision provided new information about Jupiter and highlighted its possible role in reducing space debris in the inner Solar System.

The comet was discovered by astronomers Carolyn and Eugene M. Shoemaker, and David Levy in 1993. Shoemaker–Levy 9 (SL9) had been captured by Jupiter and was orbiting the planet at the time. It was located on the night of March 24 in a photograph taken with the 46 cm Schmidt telescope at the Palomar Observatory in California. It was the first active comet observed to be orbiting a planet, and had probably been captured by Jupiter around 20 to 30 years earlier.

Calculations showed that its unusual fragmented form was due to a previous closer approach to Jupiter in July 1992. At that time, the orbit of Shoemaker–Levy 9 passed within Jupiter's Roche limit, and Jupiter's tidal forces had acted to pull the comet apart. The comet was later observed as a series of fragments ranging up to 2 km in diameter. These fragments collided with Jupiter's southern hemisphere between July 16 and 22, 1994 at a speed of approximately 60 km/s (Jupiter's escape velocity) or 216000 km/h. The prominent scars from the impacts were more visible than the Great Red Spot and persisted for many months.

Discovery
While conducting a program of observations designed to uncover near-Earth objects, the Shoemakers and Levy discovered Comet Shoemaker–Levy 9 on the night of March 24, 1993, in a photograph taken with the 46 cm Schmidt telescope at the Palomar Observatory in California. The comet was thus a serendipitous discovery, but one that quickly overshadowed the results from their main observing program.

Comet Shoemaker–Levy 9 was the ninth periodic comet (a comet whose orbital period is 200 years or less) discovered by the Shoemakers and Levy, thence its name. It was their eleventh comet discovery overall including their discovery of two non-periodic comets, which use a different nomenclature. The discovery was announced in IAU Circular 5725 on March 26, 1993.

The discovery image gave the first hint that comet Shoemaker–Levy 9 was an unusual comet, as it appeared to show multiple nuclei in an elongated region about 50 arcseconds long and 10 arcseconds wide. Brian G. Marsden of the Central Bureau for Astronomical Telegrams noted that the comet lay only about 4 degrees from Jupiter as seen from Earth, and that although this could be a line-of-sight effect, its apparent motion in the sky suggested that the comet was physically close to the planet.

Comet with a Jovian orbit
Orbital studies of the new comet soon revealed that it was orbiting Jupiter rather than the Sun, unlike all other comets known at the time. Its orbit around Jupiter was very loosely bound, with a period of about 2 years and an apoapsis (the point in the orbit farthest from the planet) of 0.33 AU. Its orbit around the planet was highly eccentric (e = 0.9986).

Tracing back the comet's orbital motion revealed that it had been orbiting Jupiter for some time. It is likely that it was captured from a solar orbit in the early 1970s, although the capture may have occurred as early as the mid-1960s. Several other observers found images of the comet in precovery images obtained before March 24, including Kin Endate from a photograph exposed on March 15, Satoru Otomo on March 17, and a team led by Eleanor Helin from images on March 19. An image of the comet on a Schmidt photographic plate taken on March 19 was identified on March 21 by M. Lindgren, in a project searching for comets near Jupiter. However, as his team were expecting comets to be inactive or at best exhibit a weak dust coma, and SL9 had a peculiar morphology, its true nature was not recognised until the official announcement 5 days later. No precovery images dating back to earlier than March 1993 have been found. Before the comet was captured by Jupiter, it was probably a short-period comet with an aphelion just inside Jupiter's orbit, and a perihelion interior to the asteroid belt.

The volume of space within which an object can be said to orbit Jupiter is defined by Jupiter's Hill sphere. When the comet passed Jupiter in the late 1960s or early 1970s, it happened to be near its aphelion, and found itself slightly within Jupiter's Hill sphere. Jupiter's gravity nudged the comet towards it. Because the comet's motion with respect to Jupiter was very small, it fell almost straight toward Jupiter, which is why it ended up on a Jove-centric orbit of very high eccentricity—that is to say, the ellipse was nearly flattened out.

The comet had apparently passed extremely close to Jupiter on July 7, 1992, just over 40000 km above its cloud tops—a smaller distance than Jupiter's radius of 70000 km, and well within the orbit of Jupiter's innermost moon Metis and the planet's Roche limit, inside which tidal forces are strong enough to disrupt a body held together only by gravity. Although the comet had approached Jupiter closely before, the July 7 encounter seemed to be by far the closest, and the fragmentation of the comet is thought to have occurred at this time. Each fragment of the comet was denoted by a letter of the alphabet, from "fragment A" through to "fragment W", a practice already established from previously observed fragmented comets.

More exciting for planetary astronomers was that the best orbital calculations suggested that the comet would pass within 45000 km of the center of Jupiter, a distance smaller than the planet's radius, meaning that there was an extremely high probability that SL9 would collide with Jupiter in July 1994. Studies suggested that the train of nuclei would plow into Jupiter's atmosphere over a period of about five days.

Predictions for the collision
The discovery that the comet was likely to collide with Jupiter caused great excitement within the astronomical community and beyond, as astronomers had never before seen two significant Solar System bodies collide. Intense studies of the comet were undertaken, and as its orbit became more accurately established, the possibility of a collision became a certainty. The collision would provide a unique opportunity for scientists to look inside Jupiter's atmosphere, as the collisions were expected to cause eruptions of material from the layers normally hidden beneath the clouds.

Astronomers estimated that the visible fragments of SL9 ranged in size from a few hundred metres (around 300 m) to 2 km across, suggesting that the original comet may have had a nucleus up to 5 km across—somewhat larger than Comet Hyakutake, which became very bright when it passed close to the Earth in 1996. One of the great debates in advance of the impact was whether the effects of the impact of such small bodies would be noticeable from Earth, apart from a flash as they disintegrated like giant meteors. The most optimistic prediction was that large, asymmetric ballistic fireballs would rise above the limb of Jupiter and into sunlight to be visible from Earth. Other suggested effects of the impacts were seismic waves travelling across the planet, an increase in stratospheric haze on the planet due to dust from the impacts, and an increase in the mass of the Jovian ring system. However, given that observing such a collision was completely unprecedented, astronomers were cautious with their predictions of what the event might reveal.

Impacts

Anticipation grew as the predicted date for the collisions approached, and astronomers trained terrestrial telescopes on Jupiter. Several space observatories did the same, including the Hubble Space Telescope, the ROSAT X-ray-observing satellite, the W. M. Keck Observatory, and the Galileo spacecraft, then on its way to a rendezvous with Jupiter scheduled for 1995. Although the impacts took place on the side of Jupiter hidden from Earth, Galileo, then at a distance of 1.6 AU from the planet, was able to see the impacts as they occurred. Jupiter's rapid rotation brought the impact sites into view for terrestrial observers a few minutes after the collisions.

Two other space probes made observations at the time of the impact: the Ulysses spacecraft, primarily designed for solar observations, was pointed toward Jupiter from its location 2.6 AU away, and the distant Voyager 2 probe, some 44 AU from Jupiter and on its way out of the Solar System following its encounter with Neptune in 1989, was programmed to look for radio emission in the 1–390 kHz range and make observations with its ultraviolet spectrometer.

Astronomer Ian Morison described the impacts as following: "The first impact occurred at 20:13 UTC on July 16, 1994, when fragment A of the [comet's] nucleus slammed into Jupiter's southern hemisphere at about 60 km/s. Instruments on Galileo detected a fireball that reached a peak temperature of about 24,000 K, compared to the typical Jovian cloud-top temperature of about 130 K. It then expanded and cooled rapidly to about 1500 K. The plume from the fireball quickly reached a height of over 3000 km and was observed by the HST."

A few minutes after the impact fireball was detected, Galileo measured renewed heating, probably due to ejected material falling back onto the planet. Earth-based observers detected the fireball rising over the limb of the planet shortly after the initial impact.

Despite published predictions, astronomers had not expected to see the fireballs from the impacts and did not have any idea how visible the other atmospheric effects of the impacts would be from Earth. Observers soon saw a huge dark spot after the first impact; the spot was visible from Earth. This and subsequent dark spots were thought to have been caused by debris from the impacts, and were markedly asymmetric, forming crescent shapes in front of the direction of impact.

Over the next six days, 21 distinct impacts were observed, with the largest coming on July 18 at 07:33 UTC when fragment G struck Jupiter. This impact created a giant dark spot over 12000 km (almost one Earth diameter) across, and was estimated to have released an energy equivalent to 6,000,000 megatons of TNT (600 times the world's nuclear arsenal). Two impacts 12 hours apart on July 19 created impact marks of similar size to that caused by fragment G, and impacts continued until July 22, when fragment W struck the planet.

Chemical studies

Observers hoped that the impacts would give them a first glimpse of Jupiter beneath the cloud tops, as lower material was exposed by the comet fragments punching through the upper atmosphere. Spectroscopic studies revealed absorption lines in the Jovian spectrum due to diatomic sulfur (S2) and carbon disulfide (CS2), the first detection of either in Jupiter, and only the second detection of S2 in any astronomical object. Other molecules detected included ammonia (NH3) and hydrogen sulfide (H2S). The amount of sulfur implied by the quantities of these compounds was much greater than the amount that would be expected in a small cometary nucleus, showing that material from within Jupiter was being revealed. Oxygen-bearing molecules such as sulfur dioxide were not detected, to the surprise of astronomers.

As well as these molecules, emission from heavy atoms such as iron, magnesium and silicon were detected, with abundances consistent with what would be found in a cometary nucleus. Although a substantial amount of water was detected spectroscopically, it was not as much as predicted, meaning that either the water layer thought to exist below the clouds was thinner than predicted, or that the cometary fragments did not penetrate deeply enough.

Waves
As predicted, the collisions generated enormous waves that swept across Jupiter at speeds of 450 m/s and were observed for over two hours after the largest impacts. The waves were thought to be travelling within a stable layer acting as a waveguide, and some scientists thought the stable layer must lie within the hypothesised tropospheric water cloud. However, other evidence seemed to indicate that the cometary fragments had not reached the water layer, and the waves were instead propagating within the stratosphere.

Other observations

Radio observations revealed a sharp increase in continuum emission at a wavelength of 21 cm after the largest impacts, which peaked at 120% of the normal emission from the planet. This was thought to be due to synchrotron radiation, caused by the injection of relativistic electrons—electrons with velocities near the speed of light—into the Jovian magnetosphere by the impacts.

About an hour after fragment K entered Jupiter, observers recorded auroral emission near the impact region, as well as at the antipode of the impact site with respect to Jupiter's strong magnetic field. The cause of these emissions was difficult to establish due to a lack of knowledge of Jupiter's internal magnetic field and of the geometry of the impact sites. One possible explanation was that upwardly accelerating shock waves from the impact accelerated charged particles enough to cause auroral emission, a phenomenon more typically associated with fast-moving solar wind particles striking a planetary atmosphere near a magnetic pole.

Some astronomers had suggested that the impacts might have a noticeable effect on the Io torus, a torus of high-energy particles connecting Jupiter with the highly volcanic moon Io. High resolution spectroscopic studies found that variations in the ion density, rotational velocity, and temperatures at the time of impact and afterwards were within the normal limits.

Voyager 2 failed to detect anything with calculations, showing that the fireballs were just below the craft's limit of detection; no abnormal levels of UV radiation or radio signals were registered after the blast. Ulysses also failed to detect any abnormal radio frequencies.

Post-impact analysis

Several models were devised to compute the density and size of Shoemaker–Levy 9. Its average density was calculated to be about 0.5 g/cm3; the breakup of a much less dense comet would not have resembled the observed string of objects. The size of the parent comet was calculated to be about 1.8 km in diameter. These predictions were among the few that were actually confirmed by subsequent observation.

One of the surprises of the impacts was the small amount of water revealed compared to prior predictions. Before the impact, models of Jupiter's atmosphere had indicated that the break-up of the largest fragments would occur at atmospheric pressures of anywhere from 30 kilopascals to a few tens of megapascals (from 0.3 to a few hundred bar), with some predictions that the comet would penetrate a layer of water and create a bluish shroud over that region of Jupiter.

Astronomers did not observe large amounts of water following the collisions, and later impact studies found that fragmentation and destruction of the cometary fragments in a meteor air burst probably occurred at much higher altitudes than previously expected, with even the largest fragments being destroyed when the pressure reached 250 kPa, well above the expected depth of the water layer. The smaller fragments were probably destroyed before they even reached the cloud layer.

Longer-term effects
The visible scars from the impacts could be seen on Jupiter for many months. They were extremely prominent, and observers described them as more easily visible than the Great Red Spot. A search of historical observations revealed that the spots were probably the most prominent transient features ever seen on the planet, and that although the Great Red Spot is notable for its striking color, no spots of the size and darkness of those caused by the SL9 impacts had ever been recorded before, or since.

Spectroscopic observers found that ammonia and carbon disulfide persisted in the atmosphere for at least fourteen months after the collisions, with a considerable amount of ammonia being present in the stratosphere as opposed to its normal location in the troposphere.

Counterintuitively, the atmospheric temperature dropped to normal levels much more quickly at the larger impact sites than at the smaller sites: at the larger impact sites, temperatures were elevated over a region 15000 to 20000 km wide, but dropped back to normal levels within a week of the impact. At smaller sites, temperatures 10 K (10 °C; 18 °F) higher than the surroundings persisted for almost two weeks. Global stratospheric temperatures rose immediately after the impacts, then fell to below pre-impact temperatures 2–3 weeks afterwards, before rising slowly to normal temperatures.

Frequency of impacts

SL9 is not unique in having orbited Jupiter for a time; five comets, including 82P/Gehrels, 147P/Kushida–Muramatsu, and 111P/Helin–Roman–Crockett, are known to have been temporarily captured by the planet. Cometary orbits around Jupiter are unstable, as they will be highly elliptical and likely to be strongly perturbed by the Sun's gravity at apojove (the farthest point on the orbit from the planet).

By far the most massive planet in the Solar System, Jupiter can capture objects relatively frequently, but the size of SL9 makes it a rarity: one post-impact study estimated that comets 0.3 km in diameter impact the planet once in approximately 500 years and those 1.6 km in diameter do so just once in every 6,000 years.

There is very strong evidence that comets have previously been fragmented and collided with Jupiter and its satellites. During the Voyager missions to the planet, planetary scientists identified 13 crater chains on Callisto and three on Ganymede, the origin of which was initially a mystery. Crater chains seen on the Moon often radiate from large craters, and are thought to be caused by secondary impacts of the original ejecta, but the chains on the Jovian moons did not lead back to a larger crater. The impact of SL9 strongly implied that the chains were due to trains of disrupted cometary fragments crashing into the satellites.

Impact of July 19, 2009
On July 19, 2009, exactly 15 years after the SL9 impacts, a new black spot about the size of the Pacific Ocean appeared in Jupiter's southern hemisphere. Thermal infrared measurements showed the impact site was warm and spectroscopic analysis detected the production of excess hot ammonia and silica-rich dust in the upper regions of Jupiter's atmosphere. Scientists have concluded that another impact event had occurred, but this time a more compact and stronger object, probably a small undiscovered asteroid, was the cause.

Jupiter's role in protection of the inner Solar System
The events of SL9's interaction with Jupiter greatly highlighted Jupiter's role in protecting the inner planets from both interstellar and in-system debris by acting as a "cosmic vacuum cleaner" for the Solar System (Jupiter barrier). The planet's strong gravitational influence attracts many small comets and asteroids and the rate of cometary impacts on Jupiter is thought to be between 2,000 and 8,000 times higher than the rate on Earth.

The extinction of the non-avian dinosaurs at the end of the Cretaceous period is generally thought to have been caused by the Cretaceous–Paleogene impact event, which created the Chicxulub crater, demonstrating that cometary impacts are indeed a serious threat to life on Earth. Astronomers have speculated that without Jupiter's immense gravity, extinction events might have been more frequent on Earth and complex life might not have been able to develop. This is part of the argument used in the Rare Earth hypothesis.

In 2009, it was shown that the presence of a smaller planet at Jupiter's position in the Solar System might increase the impact rate of comets on the Earth significantly. A planet of Jupiter's mass still seems to provide increased protection against asteroids, but the total effect on all orbital bodies within the Solar System is unclear. This and other recent models call into question the nature of Jupiter's influence on Earth impacts.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

title: Comet Shoemaker–Levy 9


text:
Talk:Comet

Wiki Education Foundation-supported course assignment
This article was the subject of a Wiki Education Foundation-supported course assignment, between 19 August 2019 and 6 December 2019. Further details are available on the course page. Student editor(s): Loken97.

Above undated message substituted from Template:Dashboard.wikiedu.org assignment by PrimeBOT (talk) 18:06, 16 January 2022 (UTC)

Comet Nuclei
the Word nuclei and the Nucleus should have a disambiguation as this will cause confusion 122.53.185.85 (talk) 21:02, 30 July 2022 (UTC)

"☄" listed at Redirects for discussion
The redirect [//en.wikipedia.org/w/index.php?title=%E2%98%84%EF%B8%8F&redirect=no ☄] has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at  until a consensus is reached. Steel1943 (talk) 18:46, 25 November 2023 (UTC)

Gravitationally unbound?
I’m not smart enough to know if this is accurate or not. However, the problem is that this isn’t cited or otherwise referenced. The idea that there are any particles(non-quantum) unaffected by gravity contradicts every physics course I’ve taken. Can someone explain this better in the article? 71.235.216.2 (talk) 03:36, 6 January 2024 (UTC)

 * Gas + particles often exceed escape velocity when leaving a comet. A fart could escape most comets. -- Kheider (talk) 12:28, 6 January 2024 (UTC)

Gallery
The gallery for this article has come into dispute, with editor commenting, "Per our policy in image galleries, we do not encourage indiscriminate galleries with no inherent value. This is the same reason why don't we have galleries of dogs or cats or asteroids on our articles. It would be much better if we can integrate these pictures into the articles somehow", and  saying, "Commons is not Wikipedia, they are not joined at the hip but Commons augments Wikipedia, please don't use the reasoning that there are images on Commons so do not show them on Wikipedia (doesn't make sense actually, one of the main purposes of Commons is to provide these images to Wikipedia". Thoughts? Praemonitus (talk) 22:01, 22 April 2024 (UTC)
 * My experience has been that large numbers of images can clutter up and disrupt an article, so I wouldn't be in favor of distributing the gallery images in that manner. Then again, a gallery should add something of value to the article, so typical comet images should be culled. Frankly, I don't see many of the gallery images that need saving. Perhaps the X-ray image and the active asteroid shots. The McNaught shot would be useful for scale. Praemonitus (talk) 22:01, 22 April 2024 (UTC)
 * Many readers just read the lead, and then maybe look at the pictures. Galleries educate readers who do that. Randy Kryn (talk) 22:19, 22 April 2024 (UTC)
 * Could you give a concrete example where this might happen? CactiStaccingCrane (talk) 09:59, 23 April 2024 (UTC)
 * Sidewalk. Or the pages of many visual artists, museum collections, space exploration pages, the page about the recent eclipse, etc. Randy Kryn (talk) 11:40, 23 April 2024 (UTC)

I'd like to propose removing the following images from the gallery:
 * Comet C/2020 F3 NEOWISE – too faint and it adds no new information
 * Great Comet 1861 – redundant with the image in the Great comets section
 * Comet Siding Spring – shows little additional detail
 * Mosaic of 20 comets discovered by the WISE space telescope – multiple tiny images add nothing
 * NEOWISE – first four years of data starting in December 2013 – what is this even showing?
 * C/2011 W3 (Lovejoy) heads towards the Sun – poor quality
 * View from the impactor in its last moments before hitting Comet Tempel 1 during the Deep Impact mission – no value
 * NASA is developing a comet harpoon for returning samples to Earth – value unclear
 * Comet Encke loses its tail – value unclear

Praemonitus (talk) 14:48, 24 April 2024 (UTC)
 * They all seem fine, and your suggestion would remove 10 of 13 images. Have just quickly looked at the gallery again after your request and all 13 seem to impart information which causal readers will not be exposed to otherwise. Nothing broken here, the gallery is of interest, and keeping it fulfills encyclopedic knowledge while removing it would not maintain this knowledge. Randy Kryn (talk) 14:55, 24 April 2024 (UTC)
 * If that is true, then perhaps you won't mind clarifying the new information in the captions? Praemonitus (talk) 15:11, 24 April 2024 (UTC)
 * Thanks, but not sure what you mean. What new information is needed? Randy Kryn (talk) 23:56, 24 April 2024 (UTC)
 * Took another look and edited some of the captions (check out the video where the comet loses its tail, pretty unique, never imagined something like that). Thanks, good suggestion. Randy Kryn (talk) 04:25, 25 April 2024 (UTC)
 * If this is done, I suggest replacing some of them with other comet images. Perhaps a Philae image of Churry's surface, since the article apparently hasn't that. ArkHyena (talk) 16:45, 24 April 2024 (UTC)
 * I agree, many of the current images are uninspiring and less than informative. Praemonitus (talk) 14:05, 25 April 2024 (UTC)
 * Some possible changes that could be made:
 * Replace the infobox image with the gallery image of Comet McNaught; I'd argue it's more eye-catching and conveys the scale of a cometary tail significantly more effectively whilst still showing both its dust and gas tail.
 * Delete the gallery images of Comet Neowise, historical observations of comets (one of these may be moved up to an appropriate section), the animation of the NEOWISE survey, and the harpoon video at least. These don't really supplement the text.
 * Possible replacement images include Candidate Landing Site J (shows the textured surface of a comet nucleus up close); Comet 67P Activity (Shows how jets which feed the coma form from a cometary nucleus); NAVCAM top 10 and 10 km (image of a comet's landscape from its surface)
 * Adding all comets explored and well-documented by spacecraft, especially images of their nuclei, could help illustrate the diversity of cometary nuclei.
 * courtesy ping for your opinion ArkHyena (talk) 17:15, 25 April 2024 (UTC)

title: Talk:Comet


text:
Ceres Brewery

The Ceres Brewery was a beer and soft drink producing facility in Århus, Denmark, that operated from 1856 until 2008. Although the brewery was closed by its owner Royal Unibrew the Ceres brand continues, with the product brewed at other facilities. The area where the brewery stood is being redeveloped for residential and commercial use and has been named CeresByen (Ceres City).

History
"Ceres Brewery" was founded in 1856 by Malthe Conrad Lottrup, a grocer, with chemists "A. S. Aagard" and "Knud Redelien", as the city's seventh brewery. It was named after the Roman goddess Ceres, and its opening was announced in the local newspaper, Århus Stiftstidende.

Lottrup expanded the brewery after ten years, adding a grand new building as his private residence.

He was succeeded by his son-in-law, Laurits Christian Meulengracht, who ran the brewery for almost thirty years, expanding it further before selling it to "Østjyske Bryggerier", another brewing firm.

The Ceres brewery was named an official purveyor to the "Royal Danish Court" in 1914.

title: Ceres Brewery


text:
COBOL

COBOL (an acronym for "common business-oriented language") is a compiled English-like computer programming language designed for business use. It is an imperative, procedural, and, since 2002, object-oriented language. COBOL is primarily used in business, finance, and administrative systems for companies and governments. COBOL is still widely used in applications deployed on mainframe computers, such as large-scale batch and transaction processing jobs. Many large financial institutions were developing new systems in the language as late as 2006, but most programming in COBOL today is purely to maintain existing applications. Programs are being moved to new platforms, rewritten in modern languages, or replaced with other software.

COBOL was designed in 1959 by CODASYL and was partly based on the programming language FLOW-MATIC, designed by Grace Hopper. It was created as part of a U.S. Department of Defense effort to create a portable programming language for data processing. It was originally seen as a stopgap, but the Defense Department promptly pressured computer manufacturers to provide it, resulting in its widespread adoption. It was standardized in 1968 and has been revised five times. Expansions include support for structured and object-oriented programming. The current standard is ISO/IEC 1989:2023.

COBOL statements have prose syntax such as MOVE x TO y, which was designed to be self-documenting and highly readable. However, it is verbose and uses over 300 reserved words. This contrasts with the succinct and mathematically inspired syntax of other languages (in this case, y = x;).

The COBOL code is split into four divisions (identification, environment, data, and procedure), containing a rigid hierarchy of sections, paragraphs, and sentences. Lacking a large standard library, the standard specifies 43 statements, 87 functions, and just one class.

Academic computer scientists were generally uninterested in business applications when COBOL was created and were not involved in its design; it was (effectively) designed from the ground up as a computer language for business, with an emphasis on inputs and outputs, whose only data types were numbers and strings of text.

COBOL has been criticized for its verbosity, design process, and poor support for structured programming. These weaknesses result in monolithic programs that are hard to comprehend as a whole, despite their local readability.

For years, COBOL has been assumed as a programming language for business operations in mainframes, although in recent years, many COBOL operations have been moved to cloud computing.

Background
In the late 1950s, computer users and manufacturers were becoming concerned about the rising cost of programming. A 1959 survey had found that in any data processing installation, the programming cost US$800,000 on average and that translating programs to run on new hardware would cost US$600,000. At a time when new programming languages were proliferating, the same survey suggested that if a common business-oriented language were used, conversion would be far cheaper and faster.

On April 8, 1959, Mary K. Hawes, a computer scientist at Burroughs Corporation, called a meeting of representatives from academia, computer users, and manufacturers at the University of Pennsylvania to organize a formal meeting on common business languages. Representatives included Grace Hopper (inventor of the English-like data processing language FLOW-MATIC), Jean Sammet, and Saul Gorn.

At the April meeting, the group asked the Department of Defense (DoD) to sponsor an effort to create a common business language. The delegation impressed Charles A. Phillips, director of the Data System Research Staff at the DoD, who thought that they "thoroughly understood" the DoD's problems. The DoD operated 225 computers, had 175 more on order and had spent over $200 million on implementing programs to run on them. Portable programs would save time, reduce costs and ease modernization.

Charles Phillips agreed to sponsor the meeting and tasked the delegation with drafting the agenda.

COBOL 60
On May 28 and 29, 1959 (exactly one year after the Zürich ALGOL 58 meeting), a meeting was held at the Pentagon to discuss the creation of a common programming language for business. It was attended by 41 people and was chaired by Phillips. The Department of Defense was concerned about whether it could run the same data processing programs on different computers. FORTRAN, the only mainstream language at the time, lacked the features needed to write such programs.

Representatives enthusiastically described a language that could work in a wide variety of environments, from banking and insurance to utilities and inventory control. They agreed unanimously that more people should be able to program and that the new language should not be restricted by the limitations of contemporary technology. A majority agreed that the language should make maximal use of English, be capable of change, be machine-independent, and be easy to use, even at the expense of power.

The meeting resulted in the creation of a steering committee and short, intermediate, and long-range committees. The short-range committee was given until September (three months) to produce specifications for an interim language, which would then be improved upon by the other committees. Their official mission, however, was to identify the strengths and weaknesses of existing programming languages; it did not explicitly direct them to create a new language.

The deadline was met with disbelief by the short-range committee. One member, Betty Holberton, described the three-month deadline as "gross optimism" and doubted that the language really would be a stopgap.

The steering committee met on June 4 and agreed to name the entire activity the Committee on Data Systems Languages, or CODASYL, and to form an executive committee.

The short-range committee members represented six computer manufacturers and three government agencies. The computer manufacturers were Burroughs Corporation, IBM, Minneapolis-Honeywell (Honeywell Labs), RCA, Sperry Rand, and Sylvania Electric Products. The government agencies were the U.S. Air Force, the Navy's David Taylor Model Basin, and the National Bureau of Standards (now the National Institute of Standards and Technology). The committee was chaired by Joseph Wegstein of the U.S. National Bureau of Standards. Work began by investigating data descriptions, statements, existing applications, and user experiences.

The committee mainly examined the FLOW-MATIC, AIMACO, and COMTRAN programming languages. The FLOW-MATIC language was particularly influential because it had been implemented and because AIMACO was a derivative of it with only minor changes. FLOW-MATIC's inventor, Grace Hopper, also served as a technical adviser to the committee. FLOW-MATIC's major contributions to COBOL were long variable names, English words for commands, and the separation of data descriptions and instructions.

Hopper is sometimes called "the mother of COBOL" or "the grandmother of COBOL",  although Jean Sammet, a lead designer of COBOL, said Hopper "was not the mother, creator or developer of Cobol."

IBM's COMTRAN language, invented by Bob Bemer, was regarded as a competitor to FLOW-MATIC by a short-range committee made up of colleagues of Grace Hopper. Some of its features were not incorporated into COBOL so that it would not look like IBM had dominated the design process, and Jean Sammet said in 1981 that there had been a "strong anti-IBM bias" from some committee members (herself included). In one case, after Roy Goldfinger, author of the COMTRAN manual and intermediate-range committee member, attended a subcommittee meeting to support his language and encourage the use of algebraic expressions, Grace Hopper sent a memo to the short-range committee reiterating Sperry Rand's efforts to create a language based on English.

In 1980, Grace Hopper commented that "COBOL 60 is 95% FLOW-MATIC" and that COMTRAN had had an "extremely small" influence. Furthermore, she said that she would claim that work was influenced by both FLOW-MATIC and COMTRAN only to "keep other people happy [so they] wouldn't try to knock us out".

Features from COMTRAN incorporated into COBOL included formulas, the PICTURE clause, an improved  statement, which obviated the need for GO TOs, and a more robust file management system.

The usefulness of the committee's work was subject of great debate. While some members thought the language had too many compromises and was the result of design by committee, others felt it was better than the three languages examined. Some felt the language was too complex; others, too simple.

Controversial features included those some considered useless or too advanced for data processing users. Such features included Boolean expressions, formulas and table  (indices). Another point of controversy was whether to make keywords context-sensitive and the effect that would have on readability. Although context-sensitive keywords were rejected, the approach was later used in PL/I and partially in COBOL from 2002. Little consideration was given to interactivity, interaction with operating systems (few existed at that time) and functions (thought of as purely mathematical and of no use in data processing).

The specifications were presented to the executive committee on 4 September. They fell short of expectations: Joseph Wegstein noted that "it contains rough spots and requires some additions", and Bob Bemer later described them as a "hodgepodge". The subcommittee was given until December to improve it.

At a mid-September meeting, the committee discussed the new language's name. Suggestions included "BUSY" (Business System), "INFOSYL" (Information System Language) and "COCOSYL" (Common Computer Systems Language). It is unclear who coined the name "COBOL", although Bob Bemer later claimed it had been his suggestion.

In October, the intermediate-range committee received copies of the FACT language specification created by Roy Nutt. Its features impressed the committee so much that they passed a resolution to base COBOL on it.

This was a blow to the short-range committee, who had made good progress on the specification. Despite being technically superior, FACT had not been created with portability in mind or through manufacturer and user consensus. It also lacked a demonstrable implementation, allowing supporters of a FLOW-MATIC-based COBOL to overturn the resolution. RCA representative Howard Bromberg also blocked FACT, so that RCA's work on a COBOL implementation would not go to waste.

It soon became apparent that the committee was too large for any further progress to be made quickly. A frustrated Howard Bromberg bought a $15 tombstone with "COBOL" engraved on it and sent it to Charles Phillips to demonstrate his displeasure.

A sub-committee was formed to analyze existing languages and was made up of six individuals:

 * William Selden and Gertrude Tierney of IBM,
 * Howard Bromberg and Howard Discount of RCA,
 * Vernon Reeves and Jean E. Sammet of Sylvania Electric Products.

The sub-committee did most of the work creating the specification, leaving the short-range committee to review and modify their work before producing the finished specification.

The specifications were approved by the executive committee on 8 January 1960, and sent to the government printing office, which printed them as COBOL 60. The language's stated objectives were to allow efficient, portable programs to be easily written, to allow users to move to new systems with minimal effort and cost, and to be suitable for inexperienced programmers.

The CODASYL Executive Committee later created the COBOL Maintenance Committee to answer questions from users and vendors and to improve and expand the specifications.

During 1960, the list of manufacturers planning to build COBOL compilers grew. By September, five more manufacturers had joined CODASYL (Bendix, Control Data Corporation, General Electric (GE), National Cash Register and Philco), and all represented manufacturers had announced COBOL compilers. GE and IBM planned to integrate COBOL into their own languages, GECOM and COMTRAN, respectively. In contrast, International Computers and Tabulators planned to replace their language, CODEL, with COBOL.

Meanwhile, RCA and Sperry Rand worked on creating COBOL compilers. The first COBOL program ran on 17 August on an RCA 501. On 6 and 7 December, the same COBOL program (albeit with minor changes) ran on an RCA computer and a Remington-Rand Univac computer, demonstrating that compatibility could be achieved.

The relative influences of which languages were used continues to this day in the recommended advisory printed in all COBOL reference manuals: "COBOL is an industry language and is not the property of any company or group of companies, or of any organization or group of organizations. No warranty, expressed or implied, is made by any contributor or by the CODASYL COBOL Committee as to the accuracy and functioning of the programming system and language. Moreover, no responsibility is assumed by any contributor, or by the committee, in connection therewith. The authors and copyright holders of the copyrighted material used herein are as follows:

'FLOW-MATIC (trademark of Unisys Corporation), Programming for the UNIVAC (R) I and II, Data Automation Systems, copyrighted 1958, 1959, by Unisys Corporation; IBM Commercial Translator Form No. F28-8013, copyrighted 1959 by IBM; FACT, DSI 27A5260-2760, copyrighted 1960 by Minneapolis-Honeywell.'

They have specifically authorized the use of this material, in whole or in part, in the COBOL specifications. Such authorization extends to the reproduction and use of COBOL specifications in programming manuals or similar publications."

COBOL-61 to COBOL-65
Many logical flaws were found in COBOL 60, leading General Electric's Charles Katz to warn that it could not be interpreted unambiguously. A reluctant short-term committee performed a total cleanup and, by March 1963, it was reported that COBOL's syntax was as definable as ALGOL's, although semantic ambiguities remained.

COBOL is a difficult language to write a compiler for, due to the large syntax and many optional elements within syntactic constructs as well as to the need to generate efficient code for a language with many possible data representations, implicit type conversions, and necessary set-ups for I/O operations. Early COBOL compilers were primitive and slow. A 1962 US Navy evaluation found compilation speeds of 3–11 statements per minute. By mid-1964, they had increased to 11–1000 statements per minute. It was observed that increasing memory would drastically increase speed and that compilation costs varied wildly: costs per statement were between $0.23 and $18.91.

In late 1962, IBM announced that COBOL would be their primary development language and that development of COMTRAN would cease.

The COBOL specification was revised three times in the five years after its publication. COBOL-60 was replaced in 1961 by COBOL-61. This was then replaced by the COBOL-61 Extended specifications in 1963, which introduced the sort and report writer facilities. The added facilities corrected flaws identified by Honeywell in late 1959 in a letter to the short-range committee. COBOL Edition 1965 brought further clarifications to the specifications and introduced facilities for handling mass storage files and tables.

COBOL-68
Efforts began to standardize COBOL to overcome incompatibilities between versions. In late 1962, both ISO and the United States of America Standards Institute (now ANSI) formed groups to create standards. ANSI produced USA Standard COBOL X3.23 in August 1968, which became the cornerstone for later versions. This version was known as American National Standard (ANS) COBOL and was adopted by ISO in 1972.

COBOL-74
By 1970, COBOL had become the most widely used programming language in the world.

Independently of the ANSI committee, the CODASYL Programming Language Committee was working on improving the language. They described new versions in 1968, 1969, 1970 and 1973, including changes such as new inter-program communication, debugging and file merging facilities as well as improved string-handling and library inclusion features.

Although CODASYL was independent of the ANSI committee, the CODASYL Journal of Development was used by ANSI to identify features that were popular enough to warrant implementing. The Programming Language Committee also liaised with ECMA and the Japanese COBOL Standard committee.

The Programming Language Committee was not well-known, however. The vice-president, William Rinehuls, complained that two-thirds of the COBOL community did not know of the committee's existence. It also lacked the funds to make public documents, such as minutes of meetings and change proposals, freely available.

In 1974, ANSI published a revised version of (ANS) COBOL, containing new features such as file organizations, the DELETE statement and the segmentation module. Deleted features included the NOTE statement, the EXAMINE statement (which was replaced by INSPECT) and the implementer-defined random access module (which was superseded by the new sequential and relative I/O modules). These made up 44 changes, which rendered existing statements incompatible with the new standard. The report writer was slated to be removed from COBOL, but was reinstated before the standard was published. ISO later adopted the updated standard in 1978.

COBOL-85
In June 1978, work began on revising COBOL-74. The proposed standard (commonly called COBOL-80) differed significantly from the previous one, causing concerns about incompatibility and conversion costs. In January 1981, Joseph T. Brophy, Senior Vice-president of Travelers Insurance, threatened to sue the standard committee because it was not upwards compatible with COBOL-74. Mr. Brophy described previous conversions of their 40-million-line code base as "non-productive" and a "complete waste of our programmer resources". Later that year, the Data Processing Management Association (DPMA) said it was "strongly opposed" to the new standard, citing "prohibitive" conversion costs and enhancements that were "forced on the user".

During the first public review period, the committee received 2,200 responses, of which 1,700 were negative form letters. Other responses were detailed analyses of the effect COBOL-80 would have on their systems; conversion costs were predicted to be at least 50 cents per line of code. Fewer than a dozen of the responses were in favor of the proposed standard.

ISO TC97-SC5 installed in 1979 the international COBOL Experts Group, on initiative of Wim Ebbinkhuijsen. The group consisted of COBOL experts from many countries, including the United States. Its goal was to achieve mutual understanding and respect between ANSI and the rest of the world with regard to the need of new COBOL features. After three years, ISO changed the status of the group to a formal Working Group: WG 4 COBOL. The group took primary ownership and development of the COBOL standard, where ANSI made most of the proposals.

In 1983, the DPMA withdrew its opposition to the standard, citing the responsiveness of the committee to public concerns. In the same year, a National Bureau of Standards study concluded that the proposed standard would present few problems. A year later, DEC released a VAX/VMS COBOL-80, and noted that conversion of COBOL-74 programs posed few problems. The new  statement and inline   were particularly well received and improved productivity, thanks to simplified control flow and debugging.

The second public review drew another 1,000 (mainly negative) responses, while the last drew just 25, by which time many concerns had been addressed.

In 1985, the ISO Working Group 4 accepted the then-version of the ANSI proposed standard, made several changes and set it as the new ISO standard COBOL 85. It was published in late 1985.

Sixty features were changed or deprecated and 115 were added, such as:

 * Scope terminators (, ,  , etc.)
 * Nested subprograms
 * , a no-operation statement
 * , a switch statement
 * , a statement that can set groups of data to their default values
 * Inline  loop bodies – previously, loop bodies had to be specified in a separate procedure
 * Reference modification, which allows access to substrings
 * I/O status codes.

The new standard was adopted by all national standard bodies, including ANSI.

Two amendments followed in 1989 and 1993. The first amendment introduced intrinsic functions and the other provided corrections.

COBOL 2002 and object-oriented COBOL
In 1997, Gartner Group estimated that there were a total of 200 billion lines of COBOL in existence, which ran 80% of all business programs.

In the early 1990s, work began on adding object-orientation in the next full revision of COBOL. Object-oriented features were taken from C++ and Smalltalk.

The initial estimate was to have this revision completed by 1997, and an ISO Committee Draft (CD) was available by 1997. Some vendors (including Micro Focus, Fujitsu, and IBM) introduced object-oriented syntax based on drafts of the full revision. The final approved ISO standard was approved and published in late 2002.

Fujitsu/GTSoftware, Micro Focus introduced object-oriented COBOL compilers targeting the .NET Framework.

There were many other new features, many of which had been in the CODASYL COBOL Journal of Development since 1978 and had missed the opportunity to be included in COBOL-85. These other features included:

 * Free-form code
 * User-defined functions
 * Recursion
 * Locale-based processing
 * Support for extended character sets such as Unicode
 * Floating-point and binary data types (until then, binary items were truncated based on their declaration's base-10 specification)
 * Portable arithmetic results
 * Bit and Boolean data types
 * Pointers and syntax for getting and freeing storage
 * The SCREEN SECTION for text-based user interfaces
 * The VALIDATE facility
 * Improved interoperability with other programming languages and framework environments such as .NET and Java.

Three corrigenda were published for the standard: two in 2006 and one in 2009.

COBOL 2014
Between 2003 and 2009, three technical reports were produced describing object finalization, XML processing and collection classes for COBOL.

COBOL 2002 suffered from poor support: no compilers completely supported the standard. Micro Focus found that it was due to a lack of user demand for the new features and due to the abolition of the NIST test suite, which had been used to test compiler conformance. The standardization process was also found to be slow and under-resourced.

COBOL 2014 includes the following changes:
 * Portable arithmetic results have been replaced by IEEE 754 data types
 * Major features have been made optional, such as the  facility, the report writer and the screen-handling facility
 * Method overloading
 * Dynamic capacity tables (a feature dropped from the draft of COBOL 2002)

COBOL 2023
The COBOL 2023 standard added a few new features:
 * Asynchronous messaging syntax using the  and   statements
 * A transaction processing facility with  and
 * logical operator
 * The  statement can be extended as to pause the program for a specified duration
 * A  statement
 * file organization
 * Defined infinite looping with
 * intrinsic function allowing for substring substitution of different length
 * function for base-conversion
 * Boolean shifting operators

There is as yet no known complete implementation of this standard.

Legacy
COBOL programs are used globally in governments and businesses and are running on diverse operating systems such as z/OS, z/VSE, VME, Unix, NonStop OS, OpenVMS and Windows. In 1997, the Gartner Group reported that 80% of the world's business ran on COBOL with over 200 billion lines of code and 5 billion lines more being written annually.

Near the end of the 20th century, the year 2000 problem (Y2K) was the focus of significant COBOL programming effort, sometimes by the same programmers who had designed the systems decades before. The particular level of effort required to correct COBOL code has been attributed to the large amount of business-oriented COBOL, as business applications use dates heavily, and to fixed-length data fields. Some studies attribute as much as "24% of Y2K software repair costs to Cobol". After the clean-up effort put into these programs for Y2K, a 2003 survey found that many remained in use. The authors said that the survey data suggest "a gradual decline in the importance of COBOL in application development over the [following] 10 years unless ... integration with other languages and technologies can be adopted".

In 2006 and 2012, Computerworld surveys (of 352 readers) found that over 60% of organizations used COBOL (more than C++ and Visual Basic .NET) and that for half of those, COBOL was used for the majority of their internal software. 36% of managers said they planned to migrate from COBOL, and 25% said that they would do so if not for the expense of rewriting legacy code. Alternatively, some businesses have migrated their COBOL programs from mainframes to cheaper, faster hardware.

Testimony before the House of Representatives in 2016 indicated that COBOL is still in use by many federal agencies. Reuters reported in 2017 that 43% of banking systems still used COBOL with over 220 billion lines of COBOL code in use.

By 2019, the number of COBOL programmers was shrinking fast due to retirements, leading to an impending skills gap in business and government organizations which still use mainframe systems for high-volume transaction processing. Efforts to rewrite systems in newer languages have proven expensive and problematic, as has the outsourcing of code maintenance, thus proposals to train more people in COBOL are advocated.

During the COVID-19 pandemic and the ensuing surge of unemployment, several US states reported a shortage of skilled COBOL programmers to support the legacy systems used for unemployment benefit management. Many of these systems had been in the process of conversion to more modern programming languages prior to the pandemic, but the process was put on hold. Similarly, the US Internal Revenue Service rushed to patch its COBOL-based Individual Master File in order to disburse the tens of millions of payments mandated by the Coronavirus Aid, Relief, and Economic Security Act.

Syntax
COBOL has an English-like syntax, which is used to describe nearly everything in a program. For example, a condition can be expressed as x IS GREATER THAN y or more concisely as  x GREATER y  or  x > y. More complex conditions can be abbreviated by removing repeated conditions and variables. For example, a > b AND a > c OR a = d  can be shortened to a > b AND c OR = d. To support this syntax, COBOL has over 300 keywords. Some of the keywords are simple alternative or pluralized spellings of the same word, which provides for more grammatically appropriate statements and clauses; e.g., the IN and OF keywords can be used interchangeably, as can TIME and TIMES, and VALUE and VALUES.

Each COBOL program is made up of four basic lexical items: words, literals, picture character-strings (see ) and separators. Words include reserved words and user-defined identifiers. They are up to 31 characters long and may include letters, digits, hyphens and underscores. Literals include numerals (e.g. 12) and strings (e.g. 'Hello!'). Separators include the space character and commas and semi-colons followed by a space.

A COBOL program is split into four divisions: the identification division, the environment division, the data division and the procedure division. The identification division specifies the name and type of the source element and is where classes and interfaces are specified. The environment division specifies any program features that depend on the system running it, such as files and character sets. The data division is used to declare variables and parameters. The procedure division contains the program's statements. Each division is sub-divided into sections, which are made up of paragraphs.

Metalanguage
COBOL's syntax is usually described with a unique metalanguage using braces, brackets, bars and underlining. The metalanguage was developed for the original COBOL specifications. Although Backus–Naur form did exist at the time, the committee had not heard of it.

As an example, consider the following description of an  statement:

 $$   \begin{array}{l} \underline{\text{ADD}}\, \begin{Bmatrix} \text{identifier-1} \\ \text{literal-1} \end{Bmatrix}\dots \;\underline{\text{TO}}\,\left\{\text{identifier-2}\,\left[\,\underline{\text{ROUNDED}}\,\right]\right\}\dots \\[1em] \quad \left[\left|\begin{array}{l} \text{ON}\,\underline{\text{SIZE}}\,\underline{\text{ERROR}}\,\text{imperative-statement-1} \\ \underline{\text{NOT}}\,\text{ON}\,\underline{\text{SIZE}}\,\underline{\text{ERROR}}\,\text{imperative-statement-2} \end{array}\right|\right] \\[1em] \quad \left[\,\underline{\text{END-ADD}}\,\right] \end{array} $$

This description permits the following variants:

Code format
The height of COBOL's popularity coincided with the era of keypunch machines and punched cards. The program itself was written onto punched cards, then read in and compiled, and the data fed into the program was sometimes on cards as well.

COBOL can be written in two formats: fixed (the default) or free. In fixed-format, code must be aligned to fit in certain areas (a hold-over from using punched cards). Until COBOL 2002, these were:

In COBOL 2002, Areas A and B were merged to form the program-text area, which now ends at an implementor-defined column.

COBOL 2002 also introduced free-format code. Free-format code can be placed in any column of the file, as in newer programming languages. Comments are specified using, which can be placed anywhere and can also be used in fixed-format source code. Continuation lines are not present, and the  directive replaces the   indicator.

Identification division
The identification division identifies the following code entity and contains the definition of a class or interface.

Object-oriented programming
Classes and interfaces have been in COBOL since 2002. Classes have factory objects, containing class methods and variables, and instance objects, containing instance methods and variables. Inheritance and interfaces provide polymorphism. Support for generic programming is provided through parameterized classes, which can be instantiated to use any class or interface. Objects are stored as references which may be restricted to a certain type. There are two ways of calling a method: the INVOKE statement, which acts similarly to CALL, or through inline method invocation, which is analogous to using functions.

COBOL does not provide a way to hide methods. Class data can be hidden, however, by declaring it without a PROPERTY clause, which leaves external code no way to access it. Method overloading was added in COBOL 2014.

Environment division
The environment division contains the configuration section and the input-output section. The configuration section is used to specify variable features such as currency signs, locales and character sets. The input-output section contains file-related information.

Files
COBOL supports three file formats, or : sequential, indexed and relative. In sequential files, records are contiguous and must be traversed sequentially, similarly to a linked list. Indexed files have one or more indexes which allow records to be randomly accessed and which can be sorted on them. Each record must have a unique key, but other, , record keys need not be unique. Implementations of indexed files vary between vendors, although common implementations, such as C-ISAM and VSAM, are based on IBM's ISAM. other implementations are Record Management Services on OpenVMS and Enscribe on HPE NonStop (Tandem). Relative files, like indexed files, have a unique record key, but they do not have alternate keys. A relative record's key is its ordinal position; for example, the 10th record has a key of 10. This means that creating a record with a key of 5 may require the creation of (empty) preceding records. Relative files also allow for both sequential and random access.

A common non-standard extension is the  organization, used to process text files. Records in a file are terminated by a newline and may be of varying length.

Data division
The data division is split into six sections which declare different items: the file section, for file records; the working-storage section, for static variables; the local-storage section, for automatic variables; the linkage section, for parameters and the return value; the report section and the screen section, for text-based user interfaces.

Aggregated data
Data items in COBOL are declared hierarchically through the use of level-numbers which indicate if a data item is part of another. An item with a higher level-number is subordinate to an item with a lower one. Top-level data items, with a level-number of 1, are called . Items that have subordinate aggregate data are called '; those that do not are called '. Level-numbers used to describe standard data items are between 1 and 49.

In the above example, elementary item num and group item the-date are subordinate to the record some-record, while elementary items the-year, the-month, and the-day are part of the group item the-date.

Subordinate items can be disambiguated with the IN (or OF) keyword. For example, consider the example code above along with the following example:

The names the-year, the-month, and the-day are ambiguous by themselves, since more than one data item is defined with those names. To specify a particular data item, for instance one of the items contained within the sale-date group, the programmer would use the-year IN sale-date (or the equivalent the-year OF sale-date). This syntax is similar to the "dot notation" supported by most contemporary languages.

Other data levels
A level-number of 66 is used to declare a re-grouping of previously defined items, irrespective of how those items are structured. This data level, also referred to by the associated, is rarely used and, circa 1988, was usually found in old programs. Its ability to ignore the hierarchical and logical structure data meant its use was not recommended and many installations forbade its use.

A 77 level-number indicates the item is stand-alone, and in such situations is equivalent to the level-number 01. For example, the following code declares two 77-level data items, property-name and sales-region, which are non-group data items that are independent of (not subordinate to) any other data items:

An 88 level-number declares a  (a so-called 88-level) which is true when its parent data item contains one of the values specified in its VALUE clause. For example, the following code defines two 88-level condition-name items that are true or false depending on the current character data value of the wage-type data item. When the data item contains a value of 'H', the condition-name wage-is-hourly is true, whereas when it contains a value of 'S' or 'Y', the condition-name wage-is-yearly is true. If the data item contains some other value, both of the condition-names are false.

Data types
Standard COBOL provides the following data types:

Type safety is variable in COBOL. Numeric data is converted between different representations and sizes silently and alphanumeric data can be placed in any data item that can be stored as a string, including numeric and group data. In contrast, object references and pointers may only be assigned from items of the same type and their values may be restricted to a certain type.

PICTURE clause
A PICTURE (or PIC) clause is a string of characters, each of which represents a portion of the data item and what it may contain. Some picture characters specify the type of the item and how many characters or digits it occupies in memory. For example, a 9 indicates a decimal digit, and an S indicates that the item is signed. Other picture characters (called ' and ' characters) specify how an item should be formatted. For example, a series of + characters define character positions as well as how a leading sign character is to be positioned within the final character data; the rightmost non-numeric character will contain the item's sign, while other character positions corresponding to a + to the left of this position will contain a space. Repeated characters can be specified more concisely by specifying a number in parentheses after a picture character; for example, 9(7) is equivalent to 9999999. Picture specifications containing only digit (9) and sign (S) characters define purely ' data items, while picture specifications containing alphabetic (A) or alphanumeric (X) characters define ' data items. The presence of other formatting characters define ' or ' data items.

USAGE clause
The USAGE clause declares the format in which data is stored. Depending on the data type, it can either complement or be used instead of a PICTURE clause. While it can be used to declare pointers and object references, it is mostly geared towards specifying numeric types. These numeric formats are:

 * Binary, where a minimum size is either specified by the  clause or by a   clause such as
 * USAGE COMPUTATIONAL, where data may be stored in whatever format the implementation provides; often equivalent to USAGE BINARY
 * USAGE DISPLAY, the default format, where data is stored as a string
 * Floating-point, in either an implementation-dependent format or according to IEEE 754
 * USAGE NATIONAL, where data is stored as a string using an extended character set
 * USAGE PACKED-DECIMAL, where data is stored in the smallest possible decimal format (typically packed binary-coded decimal)

Report writer
The report writer is a declarative facility for creating reports. The programmer need only specify the report layout and the data required to produce it, freeing them from having to write code to handle things like page breaks, data formatting, and headings and footings.

Reports are associated with report files, which are files which may only be written to through report writer statements.

Each report is defined in the report section of the data division. A report is split into report groups which define the report's headings, footings and details. Reports work around hierarchical . Control breaks occur when a key variable changes it value; for example, when creating a report detailing customers' orders, a control break could occur when the program reaches a different customer's orders. Here is an example report description for a report which gives a salesperson's sales and which warns of any invalid records:

The above report description describes the following layout: Sales Report                                                            Page  1

Seller: Howard Bromberg Sales on 10/12/2008 were $1000.00 Sales on 12/12/2008 were   $0.00 Sales on 13/12/2008 were  $31.47 INVALID RECORD: Howard Bromberg            XXXXYY

Seller: Howard Discount ... Sales Report                                                           Page 12

Sales on 08/05/2014 were $543.98 INVALID RECORD: William Selden     12O52014FOOFOO Sales on 30/05/2014 were   $0.00

Four statements control the report writer: INITIATE, which prepares the report writer for printing; GENERATE, which prints a report group; SUPPRESS, which suppresses the printing of a report group; and TERMINATE, which terminates report processing. For the above sales report example, the procedure division might look like this:

Use of the Report Writer facility tends to vary considerably; some organizations use it extensively and some not at all. In addition, implementations of Report Writer ranged in quality, with those at the lower end sometimes using excessive amounts of memory at runtime.

Procedures
The sections and paragraphs in the procedure division (collectively called procedures) can be used as labels and as simple subroutines. Unlike in other divisions, paragraphs do not need to be in sections.

Execution goes down through the procedures of a program until it is terminated. To use procedures as subroutines, the PERFORM verb is used.

A PERFORM statement somewhat resembles a procedure call in a newer languages in the sense that execution returns to the code following the PERFORM statement at the end of the called code; however, it does not provide a mechanism for parameter passing or for returning a result value. If a subroutine is invoked using a simple statement like PERFORM subroutine, then control returns at the end of the called procedure. However, PERFORM is unusual in that it may be used to call a range spanning a sequence of several adjacent procedures. This is done with the PERFORM sub-1 THRU sub-n construct:

The output of this program will be: "A A B C".

PERFORM also differs from conventional procedure calls in that there is, at least traditionally, no notion of a call stack. As a consequence, nested invocations are possible (a sequence of code being PERFORM'ed may execute a PERFORM statement itself), but require extra care if parts of the same code are executed by both invocations. The problem arises when the code in the inner invocation reaches the exit point of the outer invocation. More formally, if control passes through the exit point of a PERFORM invocation that was called earlier but has not yet completed, the COBOL 2002 standard stipulates that the behavior is undefined.

The reason is that COBOL, rather than a "return address", operates with what may be called a continuation address. When control flow reaches the end of any procedure, the continuation address is looked up and control is transferred to that address. Before the program runs, the continuation address for every procedure is initialized to the start address of the procedure that comes next in the program text so that, if no PERFORM statements happen, control flows from top to bottom through the program. But when a PERFORM statement executes, it modifies the continuation address of the called procedure (or the last procedure of the called range, if PERFORM THRU was used), so that control will return to the call site at the end. The original value is saved and is restored afterwards, but there is only one storage position. If two nested invocations operate on overlapping code, they may interfere which each other's management of the continuation address in several ways.

The following example (taken from ) illustrates the problem:

One might expect that the output of this program would be "1 2 3 4 3": After displaying "2", the second PERFORM causes "3" and "4" to be displayed, and then the first invocation continues on with "3". In traditional COBOL implementations, this is not the case. Rather, the first PERFORM statement sets the continuation address at the end of LABEL3 so that it will jump back to the call site inside LABEL1. The second PERFORM statement sets the return at the end of LABEL4 but does not modify the continuation address of LABEL3, expecting it to be the default continuation. Thus, when the inner invocation arrives at the end of LABEL3, it jumps back to the outer PERFORM statement, and the program stops having printed just "1 2 3". On the other hand, in some COBOL implementations like the open-source TinyCOBOL compiler, the two PERFORM statements do not interfere with each other and the output is indeed "1 2 3 4 3". Therefore, the behavior in such cases is not only (perhaps) surprising, it is also not portable.

A special consequence of this limitation is that PERFORM cannot be used to write recursive code. Another simple example to illustrate this (slightly simplified from ):

One might expect that the output is "1 2 3 END END END", and in fact that is what some COBOL compilers will produce. But other compilers, like IBM COBOL, will produce code that prints "1 2 3 END END END END ..." and so on, printing "END" over and over in an endless loop. Since there is limited space to store backup continuation addresses, the backups get overwritten in the course of recursive invocations, and all that can be restored is the jump back to DISPLAY 'END'.

Statements
COBOL 2014 has 47 statements (also called ), which can be grouped into the following broad categories: control flow, I/O, data manipulation and the report writer. The report writer statements are covered in the report writer section.

Control flow
COBOL's conditional statements are IF and EVALUATE. EVALUATE is a switch-like statement with the added capability of evaluating multiple values and conditions. This can be used to implement decision tables. For example, the following might be used to control a CNC lathe:

The PERFORM statement is used to define loops which are executed a condition is true (not  true, which is more common in other languages). It is also used to call procedures or ranges of procedures (see the procedures section for more details). CALL and INVOKE call subprograms and methods, respectively. The name of the subprogram/method is contained in a string which may be a literal or a data item. Parameters can be passed by reference, by content (where a copy is passed by reference) or by value (but only if a prototype is available). CANCEL unloads subprograms from memory. GO TO causes the program to jump to a specified procedure.

The GOBACK statement is a return statement and the STOP statement stops the program. The EXIT statement has six different formats: it can be used as a return statement, a break statement, a continue statement, an end marker or to leave a procedure.

Exceptions are raised by a RAISE statement and caught with a handler, or , defined in the DECLARATIVES portion of the procedure division. Declaratives are sections beginning with a USE statement which specify the errors to handle. Exceptions can be names or objects. RESUME is used in a declarative to jump to the statement after the one that raised the exception or to a procedure outside the DECLARATIVES. Unlike other languages, uncaught exceptions may not terminate the program and the program can proceed unaffected.

I/O
File I/O is handled by the self-describing OPEN, CLOSE, READ, and WRITE statements along with a further three: REWRITE, which updates a record; START, which selects subsequent records to access by finding a record with a certain key; and UNLOCK, which releases a lock on the last record accessed.

User interaction is done using ACCEPT and DISPLAY.

Data manipulation
The following verbs manipulate data:
 * INITIALIZE, which sets data items to their default values.
 * MOVE, which assigns values to data items ; MOVE CORRESPONDING assigns corresponding like-named fields.
 * SET, which has 15 formats: it can modify indices, assign object references and alter table capacities, among other functions.
 * ADD, SUBTRACT, MULTIPLY, DIVIDE, and COMPUTE, which handle arithmetic (with COMPUTE assigning the result of a formula to a variable).
 * ALLOCATE and FREE, which handle dynamic memory.
 * VALIDATE, which validates and distributes data as specified in an item's description in the data division.
 * STRING and UNSTRING, which concatenate and split strings, respectively.
 * INSPECT, which tallies or replaces instances of specified substrings within a string.
 * SEARCH, which searches a table for the first entry satisfying a condition.

Files and tables are sorted using SORT and the MERGE verb merges and sorts files. The RELEASE verb provides records to sort and RETURN retrieves sorted records in order.

Scope termination
Some statements, such as IF and READ, may themselves contain statements. Such statements may be terminated in two ways: by a period (), which terminates all unterminated statements contained, or by a scope terminator, which terminates the nearest matching open statement.

Nested statements terminated with a period are a common source of bugs. For example, examine the following code:

Here, the intent is to display  and   if condition   is true. However,  will be displayed whatever the value of   because the   statement is terminated by an erroneous period after DISPLAY y.

Another bug is a result of the dangling else problem, when two  statements can associate with an.

In the above fragment, the  associates with the  IF y  statement instead of the  IF x  statement, causing a bug. Prior to the introduction of explicit scope terminators, preventing it would require ELSE NEXT SENTENCE  to be placed after the inner.

Self-modifying code
The original (1959) COBOL specification supported the infamous ALTER X TO PROCEED TO Y  statement, for which many compilers generated self-modifying code. and  are procedure labels, and the single  GO TO  statement in procedure   executed after such an ALTER statement means  GO TO Y  instead. Many compilers still support it, but it was deemed obsolete in the COBOL 1985 standard and deleted in 2002.

The ALTER statement was poorly regarded because it undermined "locality of context" and made a program's overall logic difficult to comprehend. As textbook author Daniel D. McCracken wrote in 1976, when "someone who has never seen the program before must become familiar with it as quickly as possible, sometimes under critical time pressure because the program has failed ... the sight of a GO TO statement in a paragraph by itself, signaling as it does the existence of an unknown number of ALTER statements at unknown locations throughout the program, strikes fear in the heart of the bravest programmer."

Hello, world
A "Hello, World!" program in COBOL:

When the now famous "Hello, World!" program example in The C Programming Language was first published in 1978 a similar mainframe COBOL program sample would have been submitted through JCL, very likely using a punch card reader, and 80 column punch cards. The listing below, with an empty DATA DIVISION, was tested using Linux and the System/370 Hercules emulator running MVS 3.8J. The JCL, written in July 2015, is derived from the Hercules tutorials and samples hosted by Jay Moseley. In keeping with COBOL programming of that era, HELLO, WORLD is displayed in all capital letters.

After submitting the JCL, the MVS console displayed:

Line 10 of the console listing above is highlighted for effect, the highlighting is not part of the actual console output.

The associated compiler listing generated over four pages of technical detail and job run information, for the single line of output from the 14 lines of COBOL.

Lack of structure
In the 1970s, adoption of the structured programming paradigm was becoming increasingly widespread. Edsger Dijkstra, a preeminent computer scientist, wrote a letter to the editor of Communications of the ACM, published in 1975 entitled "How do we tell truths that might hurt?", in which he was critical of COBOL and several other contemporary languages; remarking that "the use of COBOL cripples the mind".

In a published dissent to Dijkstra's remarks, the computer scientist Howard E. Tompkins claimed that unstructured COBOL tended to be "written by programmers that have never had the benefit of structured COBOL taught well", arguing that the issue was primarily one of training.

One cause of spaghetti code was the GO TO statement. Attempts to remove GO TOs from COBOL code, however, resulted in convoluted programs and reduced code quality. GO TOs were largely replaced by the PERFORM statement and procedures, which promoted modular programming and gave easy access to powerful looping facilities. However, PERFORM could be used only with procedures so loop bodies were not located where they were used, making programs harder to understand.

COBOL programs were infamous for being monolithic and lacking modularization. COBOL code could be modularized only through procedures, which were found to be inadequate for large systems. It was impossible to restrict access to data, meaning a procedure could access and modify data item. Furthermore, there was no way to pass parameters to a procedure, an omission Jean Sammet regarded as the committee's biggest mistake.

Another complication stemmed from the ability to PERFORM THRU a specified sequence of procedures. This meant that control could jump to and return from any procedure, creating convoluted control flow and permitting a programmer to break the single-entry single-exit rule.

This situation improved as COBOL adopted more features. COBOL-74 added subprograms, giving programmers the ability to control the data each part of the program could access. COBOL-85 then added nested subprograms, allowing programmers to hide subprograms. Further control over data and code came in 2002 when object-oriented programming, user-defined functions and user-defined data types were included.

Nevertheless, much important legacy COBOL software uses unstructured code, which has become practically unmaintainable. It can be too risky and costly to modify even a simple section of code, since it may be used from unknown places in unknown ways.

Compatibility issues
COBOL was intended to be a highly portable, "common" language. However, by 2001, around 300 dialects had been created. One source of dialects was the standard itself: the 1974 standard was composed of one mandatory nucleus and eleven functional modules, each containing two or three levels of support. This permitted 104,976 possible variants.

COBOL-85 was not fully compatible with earlier versions, and its development was controversial. Joseph T. Brophy, the CIO of Travelers Insurance, spearheaded an effort to inform COBOL users of the heavy reprogramming costs of implementing the new standard. As a result, the ANSI COBOL Committee received more than 2,200 letters from the public, mostly negative, requiring the committee to make changes. On the other hand, conversion to COBOL-85 was thought to increase productivity in future years, thus justifying the conversion costs.

Verbose syntax
COBOL syntax has often been criticized for its verbosity. Proponents say that this was intended to make the code self-documenting, easing program maintenance. COBOL was also intended to be easy for programmers to learn and use, while still being readable to non-technical staff such as managers.

The desire for readability led to the use of English-like syntax and structural elements, such as nouns, verbs, clauses, sentences, sections, and divisions. Yet by 1984, maintainers of COBOL programs were struggling to deal with "incomprehensible" code and the main changes in COBOL-85 were there to help ease maintenance.

Jean Sammet, a short-range committee member, noted that "little attempt was made to cater to the professional programmer, in fact people whose main interest is programming tend to be very unhappy with COBOL" which she attributed to COBOL's verbose syntax.

Isolation from the computer science community
The COBOL community has always been isolated from the computer science community. No academic computer scientists participated in the design of COBOL: all of those on the committee came from commerce or government. Computer scientists at the time were more interested in fields like numerical analysis, physics and system programming than the commercial file-processing problems which COBOL development tackled. Jean Sammet attributed COBOL's unpopularity to an initial "snob reaction" due to its inelegance, the lack of influential computer scientists participating in the design process and a disdain for business data processing. The COBOL specification used a unique "notation", or metalanguage, to define its syntax rather than the new Backus–Naur form which the committee did not know of. This resulted in "severe" criticism.

Later, COBOL suffered from a shortage of material covering it; it took until 1963 for introductory books to appear (with Richard D. Irwin publishing a college textbook on COBOL in 1966). By 1985, there were twice as many books on FORTRAN and four times as many on BASIC as on COBOL in the Library of Congress. University professors taught more modern, state-of-the-art languages and techniques instead of COBOL which was said to have a "trade school" nature. Donald Nelson, chair of the CODASYL COBOL committee, said in 1984 that "academics ... hate COBOL" and that computer science graduates "had 'hate COBOL' drilled into them".

By the mid-1980s, there was also significant condescension towards COBOL in the business community from users of other languages, for example FORTRAN or assembler, implying that COBOL could be used only for non-challenging problems.

In 2003, COBOL featured in 80% of information systems curricula in the United States, the same proportion as C++ and Java. Ten years later, a poll by Micro Focus found that 20% of university academics thought COBOL was outdated or dead and that 55% believed their students thought COBOL was outdated or dead. The same poll also found that only 25% of academics had COBOL programming on their curriculum even though 60% thought they should teach it.

Concerns about the design process
Doubts have been raised about the competence of the standards committee. Short-term committee member Howard Bromberg said that there was "little control" over the development process and that it was "plagued by discontinuity of personnel and ... a lack of talent." Jean Sammet and Jerome Garfunkel also noted that changes introduced in one revision of the standard would be reverted in the next, due as much to changes in who was in the standard committee as to objective evidence.

COBOL standards have repeatedly suffered from delays: COBOL-85 arrived five years later than hoped, COBOL 2002 was five years late, and COBOL 2014 was six years late. To combat delays, the standard committee allowed the creation of optional addenda which would add features more quickly than by waiting for the next standard revision. However, some committee members raised concerns about incompatibilities between implementations and frequent modifications of the standard.

Influences on other languages
COBOL's data structures influenced subsequent programming languages. Its record and file structure influenced PL/I and Pascal, and the  clause was a predecessor to Pascal's variant records. Explicit file structure definitions preceded the development of database management systems and aggregated data was a significant advance over Fortran's arrays.

data declarations were incorporated into PL/I, with minor changes.

COBOL's COPY facility, although considered "primitive", influenced the development of include directives.

The focus on portability and standardization meant programs written in COBOL could be portable and facilitated the spread of the language to a wide variety of hardware platforms and operating systems. Additionally, the well-defined division structure restricts the definition of external references to the Environment Division, which simplifies platform changes in particular.

title: COBOL


text:
Crew

A crew is a body or a group of people who work at a common activity, generally in a structured or hierarchical organization. A location in which a crew works is called a crewyard or a workyard. The word has nautical resonances: the tasks involved in operating a ship, particularly a sailing ship, providing numerous specialities within a ship's crew, often organised with a chain of command. Traditional nautical usage strongly distinguishes officers from crew, though the two groups combined form the ship's company. Members of a crew are often referred to by the title crewman or crew-member.

Crew also refers to the sport of rowing, where teams row competitively in racing shells.

Types

 * For a specific sporting usage, see rowing crew.
 * For filmmaking usage, see film crew.
 * For live music usage, see road crew.
 * For analogous entities in research on human judgment and decision-making, see team and judge–advisor system.
 * For stagecraft usage, see stage crew.
 * For video production usage, see television crew.
 * For crews in aviation and the airline industry, see groundcrew and aircrew.
 * For crews in human spaceflight, see astronaut.
 * Tank crew
 * Boat crew

title: Crew


text:
CCD

CCD may refer to:

Science and technology

 * Charge-coupled device, an electronic light sensor used in various devices including digital cameras
 * .ccd, the filename extension for CloneCD's CD image file

 * Carbonate compensation depth, a property of oceans
 * Colony collapse disorder, a phenomenon involving the abrupt disappearance of honey bees in a beehive or Western honey bee colony
 * centicandela (ccd), an SI unit of luminous intensity denoting one hundredth of a candela
 * Central composite design, an experimental design in response surface methodology for building a second order model for a response variable without a complete three-level factorial

 * Complementary cumulative distribution function
 * Continuous collision detection, especially in rigid-body dynamics
 * Countercurrent distribution, used for separating mixtures
 * Core complex die, an element of AMD Zen 2 and later microprocessor architectures

Medicine

 * Canine compulsive disorder, a behavioral condition in dogs, similar to human obsessive-compulsive disorder (OCD)
 * Caput-collum-diaphyseal angle, the angle between the neck and the shaft of the femur in the hip
 * Cleidocranial dysostosis (also called cleidocranial dysplasia), a genetic abnormality in humans
 * Central core disease, a rare neuromuscular disorder
 * Congenital chloride diarrhea, a rare disorder in babies
 * Continuity of Care Document, an XML-based markup standard for patient medical document exchange
 * Cross-reactive carbohydrate determinants, protein-linked carbohydrate structures that have a role in the phenomenon of cross-reactivity in allergic patients
 * Cortical collecting duct, a segment of the kidney

Politics and government

 * Census county division, a term used by the US Census Bureau
 * Center City District, an economic development agency for the Center City area of Philadelphia
 * Consular Consolidated Database, a database used for visa processing by the Bureau of Consular Affairs, US Department of State

Religion

 * Confraternity of Christian Doctrine, a religious instruction program of the Catholic Church

Organizations

 * Café Coffee Day, a chain of coffee shops in India
 * Country Club of Detroit
 * Centre of Cricket Development, a cricket team; see Namibia Cricket Board
 * Cricket Club of Dhakuria; see Gopal Bose

Education

 * Community College of Denver, a public college in Denver, Colorado
 * Cincinnati Country Day School, a non-parochial, private school in Indian Hill, Ohio

Non-governmental

 * Christian Care Foundation for Children with Disabilities, in Thailand
 * Council for a Community of Democracies, in the US
 * Canadian Coalition for Democracies, a former advocacy organization in Canada

Politics and government

 * Centro Cristiano Democratico (Christian Democratic Centre), a defunct Italian political party

Other uses

 * Convention Centre Dublin, Ireland

title: CCD