# COBOL

|  COBOL  |
| --- |
|  |
| Tilblivelse | 28. mai 1959 |
| Paradigme | Multi-paradigme: Prosedyrisk programmering, objektorientert programmering, imperativ programmering |
| Designet av | Grace Hopper |
| Utviklet av | Den internasjonale standardiseringsorganisasjonen, CODASYL, American National Standards Institute |
| Siste versjon(er) | 2019, ISO/IEC 1989:2023 |
| Typetildeling | sterk, statisk |
| Filendelse(r) | .cbl, .cob, .cpy |
| Påvirket av |
| FLOW-MATIC, COMTRAN, FACT |

**COBOL** (akronym for *common business-oriented language*) er et programmeringsspråk som har vært i utstrakt bruk for koding av økonomiske og administrative transaksjonssystemer. Det ble konstruert i 1959, initiert av amerikanske forsvarsmyndigheter. COBOL brukes fortsatt i mange eksisterende systemer fordi disse ofte er store, godt uttestet og ikke er utsatt for sterke endringskrav. COBOL og systemene kodet i dette språket ble sterkt fokusert i forbindelse med år 2000-problemet.

## Utbredelse

På slutten av 1990-tallet gjennomførte Gartner Group en studie som viste at av et estimert antall på 300 milliarder kodelinjer av eksisterende kode er åtti prosent, dvs. rundt 240 milliarder linjer, skrevet i COBOL. De fant også ut at mer enn halvparten av driftskritiske nye applikasjoner fortsatt programmeres i COBOL.

## Syntaks

Filosofien bak COBOL er å kunne kode gjennom bruk av tilnærmet normalspråk. En kan alternativt bruke en mer kompakt notasjon.

En typisk egenskap i COBOL er at eksterne data blir formatert sammen med definisjonene av variablene i Data Division ved hjelp av egenskapen PICTURE, ikke i prosedyreanvisninger som for eksempel i C.

### Procedure division

#### Prosedyrer

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:

```
PROCEDURE so-and-so.
 PERFORM ALPHA
 PERFORM ALPHA THRU GAMMA
 STOP RUN.
ALPHA.
 DISPLAY 'A'.
BETA.
 DISPLAY 'B'.
GAMMA.
 DISPLAY 'C'.

```

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 Veerman & Verhoeven 2006 harvnb error: no target: CITEREFVeermanVerhoeven2006 (help)) illustrates the problem:

```
LABEL1.
 DISPLAY '1'
 PERFORM LABEL2 THRU LABEL3
 STOP RUN.
LABEL2.
 DISPLAY '2'
 PERFORM LABEL3 THRU LABEL4.
LABEL3.
 DISPLAY '3'.
LABEL4.
 DISPLAY '4'.

```

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`. Den andre `PERFORM` setter returen på slutten av `LABEL4`, men endrer ikke fortsettelsesadressen til `LABEL3`, og forventer at den skal være standard fortsettelse. Således, når den indre påkallelsen kommer til slutten av `LABEL3`, hopper den tilbake til den ytre `PERFORM`, programmet stopper etter å ha skrevet ut "1 2 3". I TinyCOBOL blander ikke de to `PERFORM`-utsagnene seg med hverandre og utmatingen er "1 2 3 4 3". Adferden i slike tilfeller er ikke portabel.

En konsekvens er at `PERFORM` ikke kan skrive rekursiv kode.

```
 MOVE 1 TO A
 PERFORM LABEL
  STOP RUN.
LABEL.
 DISPLAY A
 IF A < 3
 ADD 1 TO A
 PERFORM LABEL
  END-IF
  DISPLAY 'END'.

```

Noen COBOL-kompilatorer skriver ut "1 2 3 END END END", mens IBM COBOL skriver ut "1 2 3 END END END END ..."; "END" skrives ut om og om igjen i en evig løkke. Siden det er begrenset lagringsplass, blir sikkerhetskopiene overskrevet i løpet av rekursive påkallinger, og alt som kan gjenopprettes er å hoppe tilbake til `DISPLAY 'END'`.

#### Utsagn

COBOL 2014 har 47 *verb*, som kan grupperes i underkategorier.

##### Kontrollflyt

COBOL's betingelser er `IF` og `EVALUATE`. `EVALUATE` er en switch-setning som evaluerer flere verdier og tilstander. Dette kan implementere beslutningstabeller som kontrollerer en CNC lathe:

```
EVALUATE TRUE ALSO desired-speed ALSO current-speed
 WHEN lid-closed ALSO min-speed THRU max-speed ALSO LESS THAN desired-speed
 PERFORM speed-up-machine
 WHEN lid-closed ALSO min-speed THRU max-speed ALSO GREATER THAN desired-speed
 PERFORM slow-down-machine
 WHEN lid-open ALSO ANY ALSO NOT ZERO
  PERFORM emergency-stop
 WHEN OTHER
  CONTINUE
END-EVALUATE

```

`PERFORM` definerer løkker som utføres inntil en tilstand er sann. Det brukes også til å kalle prosedyrer eller rekker av prosedyrer. `CALL` og `INVOKE` kaller delprogrammer og metoder. Navnet på delprogrammet/metoden inneholdes i en streng som kan være en litteral eller et dataelement. Parameterere kan sendes etter referanse, etter innhold eller etter verdi (hvis en funksjonsprototype er tilgjengelig).
`CANCEL` avlaster delprogrammer fra minnet. `GO TO` får programmet å hoppe til en spesifisert prosedyre.

`GOBACK` er en retursetning og `STOP` stanser programmet. `EXIT` har seks formater: Den kan brukes som en retur-setning, en avbrudd-setning, en fortsett-setning, en sluttmarkør eller til å forlate en prosedyre.

Unntakshåndtering oppstår fra et `RAISE`-utsagn og oppfanges av en håndterer, eller *deklarativer*, som er definert i `DECLARATIVES`-porsjonen av prosedyredivisjonen. Deklarativene er seksjoner som begynner med et `USE` utsagn som spesifiserer feilene som skal håndteres. Unntak kan være navn eller objekter. `RESUME` brukes i et deklarativ for å hoppe til utsagnet etter det som reiste unntaket eller til en prosedyre utenfor `DECLARATIVES`. I motsetning til andre språk kan uoppdagede unntak ikke avslutte programmet, og programmet kan fortsette upåvirket.

##### Inn- og utmating

Inn- og utmating fra og til datafil er håndtert av `OPEN`, `CLOSE`, `READ`, og `WRITE` sammen med tre andre utsagn: `REWRITE` som oppdaterer en record; `START`, som velger påfølgende poster for tilgang ved å finne en record med en bestemt nøkkel; og `UNLOCK`, som frigjør en lås på den siste record som er aksessert.

Brukerinteraksjon skjer ved å bruke `ACCEPT` og `DISPLAY`.

##### Datamanipulasjon

Følgende verb manipulerer data:

* `INITIALIZE` setter dataelementer til deres standardverdier.
* `MOVE` tildeler verdier til dataelementer ; *MOVE CORRESPONDING* tildeler tilsvarende recordfelter med samme navn.
* `SET`, som har 15 formater, kan modifisere indekser, tildele objektreferanser og endre tabellkapasiteter.
* `ADD`, `SUBTRACT`, `MULTIPLY`, `DIVIDE`, og `COMPUTE` håndterer aritmetikk.
* `ALLOCATE` og `FREE`, håndterer dynamisk hukommelse.
* `VALIDATE` validerer og distribuerer data som spesifisert i elementbeskrivelsen i datadivisjonen.
* `STRING` og `UNSTRING` konkatinerer og splitter strenger.
* `INSPECT` erstatter instanser av spesifiserte delstrenger innenfor en streng.
* `SEARCH` søker i en tabell etter den første oppføringen som tilfredsstiller en betingelse

Datafiler og tabeller blir sortert ved å bruke `SORT` og verbet `MERGE` slår sammen og sorterer datafiler. Verbet `RELEASE` gir recorder for å sortere og `RETURN` returnerer sorterte recorder i rekkefølge.

#### Terminering av gyldighetsområde

`IF` og `READ`, kan også inneholde utsagn. Slike utsagn kan termineres på to måter: av en periode (*implisitt terminering*), som terminerer *alle* uterminerte utsagn, eller av en terminator av gyldighetsområde, som terminerer den nærmeste matchende åpne setning.

```
\*> Terminator periode («implisitt terminering»)
IF invalid-record
 IF no-more-records
 NEXT SENTENCE
  ELSE
  READ record-file
 AT END SET no-more-records TO TRUE.

\*> Terminatorer av gyldighetsområde («eksplisitt terminering»)
IF invalid-record
 IF no-more-records
 CONTINUE
  ELSE
  READ record-file
 AT END SET no-more-records TO TRUE
  END-READ
  END-IF
END-IF

```

Nøstede setninger som termineres med en periode er en vanlig kilde til programvarefeil. For eksempel:

```
IF x
 DISPLAY y.
 DISPLAY z.

```

Her er intensjonen å vise `y` og `z` hvis betingelsen `x` er sann. `Z` vil likevel bli vist uansett verdien av `x` fordi `IF` termineres feilaktig etter `DISPLAY y`.

En annen programvarefeil er et resultat av dinglende else, når to `IF` utsagn kan assosieres med en `ELSE`.

```
IF x
 IF y
 DISPLAY a
ELSE
  DISPLAY b.

```

I fragmentet ovenfor, er `ELSE` assosiert med  `IF y`  istedet for  `IF x` , noe som forårsaker en programvarefeil. Eksplisitte terminatorer av gyldighetsområde, vil hindre kravet om at  `ELSE NEXT SENTENCE`  plasseres etter den indre `IF`.

#### Selvmodifiserende kode

Den opprinnelige (1959) COBOL-spesifikasjonen støttet det beryktede  `ALTER X TO PROCEED TO Y`  utsagnet, for hvilke mange kompilatorer genererte selvmodifiserende kode. `X` og `Y` er prosedyrenavn, og et enkelt  `GO TO`  utsagn i prosedyren `X` utført etter et slikt `ALTER`-utsagn betyr  `GO TO Y` . Eksempler på kompilatorer som støtter eller har støttet selvmodifiserende kode er:

* GNU Cobol
* Micro Focus Visual COBOL 2.2
* Fujitsu NetCOBOL
* IBMs Enterprise COBOL for z/OS

Det ble ansett som foreldet i COBOL 1985 standarden og slettet i 2002.

`ALTER`-utsagnet var dårlig ansett fordi det undergravde «sammenhengens lokalitet» og gjorde et programs overordnede logikk vanskelig å oppfatte. Som lærebokforfatteren Daniel D. McCracken skrev i 1976: «[Når] noen som aldri har sett programmet før må bli kjent med det så raskt som mulig, noen ganger under kritisk tidspress fordi programmet har feilet ... synet av et GO TO-utsagn i en paragraf i seg selv, som signaliserer eksistensen av et ukjent antall ALTER-utsagn på ukjente steder gjennom programmet, skaper frykt i hjertet til den modigste programmereren.»

### Hallo, verden

Eksempelprogrammet «Hallo, verden» i boken *Programmeringsspråket C*, ble publisert i 1978. Et lignende COBOL-program for stormaskiner ville ha blitt utskrevet gjennom *Job Control Language* (JCL), svært sannsynlig ved hjelp av en hullkortleser, og hullkort med 80 kolonner hullkort.

```
  IDENTIFICATION DIVISION.
  PROGRAM-ID. HALLO-VERDEN.
  \*
  ENVIRONMENT DIVISION.
  \*
  DATA DIVISION.
  \*
  PROCEDURE DIVISION.
  PARA-1.
  DISPLAY "Hallo, verden.".
  \*
  EXIT PROGRAM.
  END PROGRAM HALLO-VERDEN.

```

eller i kompakt form:

```
  Identification Division.
  Program-ID. HALLO-VERDEN.
  Procedure Division.
  Display "Hallo, verden.".
  STOP RUN.

```

Utlistingen nedenfor, *med en tom DATA DIVISION*, ble testet ved å bruke Linux på stormaskinen IBM System/370 med en *Hercules emulator* som kjører MVS 3.8J. Teksten i JCL ble skrevet i juli 2015, og er hentet fra et kurs i Hercules som ble avholdt av Jay Moseley. I tråd med COBOL-programmeringen på denne tiden, er HALLO VERDEN vist med storbokstaver.

```
//COBUCLG JOB (001),'COBOL BASE TEST', 00010000
// CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1) 00020000
//BASETEST EXEC COBUCLG 00030000
//COB.SYSIN DD \* 00040000
 00000\* VALIDATION OF BASE COBOL INSTALL 00050000
 01000 IDENTIFICATION DIVISION. 00060000
 01100 PROGRAM-ID. 'HALLO'. 00070000
 02000 ENVIRONMENT DIVISION. 00080000
 02100 CONFIGURATION SECTION. 00090000
 02110 SOURCE-COMPUTER. GNULINUX. 00100000
 02120 OBJECT-COMPUTER. HERCULES. 00110000
 02200 SPECIAL-NAMES. 00120000
 02210 CONSOLE IS CONSL. 00130000
 03000 DATA DIVISION. 00140000
 04000 PROCEDURE DIVISION. 00150000
 04100 00-MAIN. 00160000
 04110 DISPLAY 'HALLO, VERDEN' UPON CONSL. 00170000
 04900 STOP RUN. 00180000
//LKED.SYSLIB DD DSNAME=SYS1.COBLIB,DISP=SHR 00190000
// DD DSNAME=SYS1.LINKLIB,DISP=SHR 00200000
//GO.SYSPRINT DD SYSOUT=A 00210000
// 00220000

```

Kompilatoroppføringen med tekniske detaljer og jobbkjøringsinformasjon fra de 14 linjene med COBOL. *Linje 10 er uthevet for effekt, og er ikke en del av utdataene:*

```
    19.52.48 JOB    3  $HASP100 COBUCLG  ON READER1     COBOL BASE TEST
    19.52.48 JOB    3  IEF677I WARNING MESSAGE(S) FOR JOB COBUCLG  ISSUED
    19.52.48 JOB    3  $HASP373 COBUCLG  STARTED - INIT 1 - CLASS A - SYS BSP1
    19.52.48 JOB    3  IEC130I SYSPUNCH DD STATEMENT MISSING
    19.52.48 JOB    3  IEC130I SYSLIB   DD STATEMENT MISSING
    19.52.48 JOB    3  IEC130I SYSPUNCH DD STATEMENT MISSING
    19.52.48 JOB    3  IEFACTRT - Stepname  Procstep  Program   Retcode
    19.52.48 JOB    3  COBUCLG    BASETEST  COB       IKFCBL00  RC= 0000
    19.52.48 JOB    3  COBUCLG    BASETEST  LKED      IEWL      RC= 0000
 19.52.48 JOB 3 +HALLO, VERDEN
    19.52.48 JOB    3  COBUCLG    BASETEST  GO        PGM=*.DD  RC= 0000
    19.52.48 JOB    3  $HASP395 COBUCLG  ENDED

```

## Mottagelse

### Mangelen på struktur

I 1970-årene ble paradigmet strukturert programmering stadig mer utbredt. Informatikeren Edsger Dijkstra skrev et brev til redaktøren av *Communications of the ACM*, som ble publisert 18. juni 1975. Det hadde tittelen «Hvordan forteller vi sannheter som kan skade?» (*How do we tell truths that might hurt?*). Der var han kritisk til COBOL og flere andre samtidige språk (FORTRAN, PL/I, APL), og bemerket at «bruken av COBOL lammer sinnet».

I et motskrift mot Dijkstra, hevdet informatikeren Howard E. Tompkins at ustrukturert COBOL var «skrevet av programmerere som aldri har hatt fordelen av å ha blitt undervist godt i strukturert COBOL». Han argumenterte for at problemet skyldtes mangelfull undervisning.

En årsak til «spaghettikode» var `GO TO` utsagn. Forsøk på å fjerne `GO TO`s fra COBOL-koden, resulterte likevel i kronglete programmer og redusert kodekvalitet. `GO TO`s ble i stor grad erstattet av `PERFORM` setningen og prosedyrer, som fremmet modulær programmering og ga lett aksess til løkker. `PERFORM` kunne likevel bli bare bli brukt på prosedyrer hvor løkkekroppene ikke var lokalisert hvor de ble brukt, noe som gjorde programmer vanskeligere å forstå.

COBOL-programmer var beryktede for å være monolittiske og mangle modularisering. COBOL-kode kunne bare modulariseres gjennom prosedyrer, noe som var inadekvat for store systemer. Det var umulig å avgrense tilgangen til data, noe som betød at en prosedyre kunne aksessere og modifisere ethvert dataelement. Dessuten var det ingen måte å sende parametere til en prosedyre, en utelatelse som Jean E. Sammet betraktet som komitèens groveste feil.

En annen komplikasjon stammet fra evnen til å `PERFORM THRU` en spesifisert sekvens av prosedyrer. Dette innebar at kontrollen kunne hoppe til og returnere fra enhver prosedyre, skapte en kronglete kontrollflyt og tillot en programmerer å bryte regelen om enkelt-inngang enkelt-utgang.

Situasjonen forbedret seg når COBOL adopterte flere egenskaper. COBOL-74 tilføyde subprogrammer, som ga programmere evnen til å kontrollere data som hver del av programmet kunne aksessere. COBOL-85 tilføyde nøstede subprogrammer, som tillater programmerere å skjule subprogrammer. Videre kontroll over data og kode kom i 2002 da objektorientert programmering, brukerdefinerte funksjoner og brukerdefinerte datatyper ble inkludert.

Likevel bruker mye av den viktige nedarvede COBOL-programvare ustrukturert kode, som har blitt praktisk talt umulig å vedlikeholde. Det er risikabelt og kostbart å endre selv en enkel kodedel, siden den kan brukes fra ukjente steder på ukjente måter.

### Kompatibilitetsspørsmål

COBOL var ment å være et svært portabelt, «alminnelig» språk. I 2001 hadde likevel omkring 300 dialekter blitt skapt. En kilde til dialekter var standarden selv: 1974-standarden bestod av en obligatorisk kjerne og elleve funksjonelle moduler, som hver enkelt inneholder to eller tre nivåer med støtte. Dette fører til 104,976 mulige varianter.

COBOL-85 var ikke fullstendig kompatibel med tidligere versioner, og dens utvikling var kontroversiell. Joseph T. Brophy, IT-direktør i *St. Paul Travelers*, ledet et forsøk på å informere COBOL-brukere om de store omprogrammingskostnadene ved å implementere den nye standarden. Som et resultat, mottok *ANSI COBOL Committee* mer enn 2,200 brev fra almenheten, for det meste negative, som krevde at komitèen gjorde endringer. På den annen side ble konvertering til COBOL-85 antatt å øke produktiviteten i årene som kommer, og rettferdiggjorde dermed konverteringskostnadene.

### Omstendelig syntaks

COBOL: /koh′bol/, n.

Et svakt, detaljert og slappt språk brukt av kodekverner for å gjøre kjedelige tankeløse ting på dinosaur-stormaskiner. [...] Selve navnet blir sjelden uttalt uten rituelle uttrykk for avsky eller redsel.

“
”
The Jargon File 4.4.8.

COBOL-syntaksen har blitt kritisert for sin omstendelighet. Formålet med dette var å gjøre koden selv-dokumenterende, noe som lettet programmers vedlikehold. COBOL var også ment å være lett for programmere å lære seg og å bruke, mens det var lesbart for ikke-tekniske medlemmer av staben i en organisasjon.

Ønsket om lesbarhet førte til bruken av engelsk-lignende syntaks og strukturelle elementer, slik som substantiver, verb, klausuler, setninger, seksjoner og divisioner. I 1984 kjempet likevel vedlikeholdere av COBOL-programmer med å håndtere «ubegripelig» kode og endringene i COBOL-85 var der hovedsakelig for å hjelpe til med lettelse av vedlikehold.

Komitèmedlemmet Jean E. Sammet bemerket at «svært få forsøk har blitt gjort for å imøtekomme den professionelle programmer, faktisk personer hvis hovedinteresse er programmering tenderer mot å være svært ulykkelig med COBOL», noe som hun mente skyldtes COBOL's omstendelige syntaks.

Den akademiske verden tenderer til å betrakter COBOL som omstendelig, klønete og lite elegant, og prøver å ignorere det, selv om det trolig er flere COBOL programmer og programmerere i verden enn det er for FORTRAN, ALGOL og PL/I til sammen. For det meste er det kun skoler med umiddelbart yrkesrettet mål som gir undervisning i COBOL.

“
”
Richard W. Conway og David Gries, 1973

Senere led COBOL av mangelen på materiale som dekket det; introduserende bøker dukket ikke opp før i 1963 og Richard D. Irwin utga en lærebok i COBOL i 1966. Donald Nelson, formann av CODASYL COBOL-kommitèen, sa i 1984 at «akademikere ... hater COBOL» og at informatikk-utdannede «hadde COBOL-hatet boret inn i dem».

I midten av 1980-årene var det også en betydelig nedlatenhet mot COBOL i næringslivet fra brukere av andre språk, for eksempel FORTRAN eller assemblerkode. Dette antydet at COBOL bare kunne brukes til trivielle problemstillinger.

I 2003 var COBOL med i 80% av læreplanene i informatikk i USA, den samme andelen som C++ og Java. I 2023 viste en meningsmåling foretatt av *Micro Focus* at 20% av universiters akademikere trodde COBOL var utdatert eller død og at 55% av studentene trodde det samme. Bare 25% av akademikerne hadde COBOL-programmering i deres curriculum, mens 60% mente at de burde undervise i det.

### Kritikk av designprosessen

Kritikk har oppstått om kompetansen til standardkomitèen. Komitèmedlemmet Howard Bromberg sa at det var «liten kontroll» over utviklingsprosessen og at den var «forpestet av diskontinuitet i personell og ... en mangel på talent.» Jean Sammet og Jerome Garfunkel merket seg også at endringer som ble introdusert i èn revisjon av standarden ble reversert i den neste, ikke bare på grunn av objektive bevis, men også på grunn av hvem som var i standardkomitèen.

COBOL-standarder har gjentatte ganger blitt forsinket: COBOL-85 ankom fem år forsinket, COBOL 2002 var fem år forsinket, og COBOL 2014 var seks år forsinket. For å bekjempe forsinkelser, ble det skapt en valgfri addenda hvor egenskaper kunne tilføyes raskere enn å vente på neste standardrevisjon. Noen komitèmedlemmer var likevel bekymret for at dette skapte inkompatibiliteter mellom implementationer og hyppige modifikasjoner av standarden.

### Påvirkning av andre programmeringsspråk

COBOL's datastrukturer påvirket andre programmeringsspråk. Dets record- og filstruktur påvirket PL/I og Pascal, og klausulen `REDEFINES` var forgjengeren til variantrecorder i Pascal. Eksplisitte filstruktur-definisjoner påvirket utviklingen av database håndteringssystemer og aggregering var et betydelig fremskritt i forhold til tabellene i FORTRAN.

Datadeklarasjonen `PICTURE` ble inkorporert i PL/I, med mindre endringer.

COBOL's `COPY`-fasilitet påvirket utviklingen av include-direktiver.

Fokuset på portabilitet gjorde at programmer som var skrevet i COBOL bredte seg til mange dataplattformer og operativsystemer. Eksempler kan bli sett i GnuCOBOL, IBM COBOL
(brukt på z/OS, AIX og Linux) og Micro Focus Visual COBOL (brukt på Linux for x86-64, Linux on System z, AIX, HP-UX, SunOS/Solaris og Microsoft Windows).

Den veldefinerte strukturen med inndelinger i DIVISIONs avgrenser definisjonen av eksterne referanser til *Environment Division*. Dette forenkler plattformendringer.

## GNU COBOL

GNU COBOL er en COBOL kompilator i versjon 15.1 av GNU Compiler Collection (GCC), som ble lansert 25. april 2025. Kompilatoren ble utviklet av COBOLworks. Den genererer kode for arkitekturene x86-64 og Aarch64, og det arbeides med å få den til å støtte 128-biter databehandling.

Den følger standarden ISO-IEC 1989:2023 og støtter mange utvidelser fra IBM og MicroFocus. Den følger NIST CCVS/85 testprogrammet (bortsett fra deler som nå er foreldet).

Den støtter utvidede DECLARATIVES for feilsjekking.

I GCC 16.1 (2026) er det forventet støtte for XML og JSON og forbedret integrasjon med SQL. Egenskaper som objektorientert programmering er på vei i fremtidige versjoner.

## Referanser

## Kilder

### Nettsteder

* COBOL Task Group (10. mars 2014). «COBOLStandard.info». Arkivert fra originalen 10. januar 2017. Besøkt 24. april 2025.
* Tiffin, Brian (18. september 2013). «September 2013». *GNU Cobol*. Arkivert fra originalen 5. mai 2014. Besøkt 27. april 2025.
* GNU (11. september 2024). «GnuCOBOL - GNU Project».
* GNU (25. april 2025). «GCC 15 Release Series Changes, New Features, and Fixes».
* Cobolworks (3. juli 2025). «GCC COBOL».
* Fujitsu (November 1996). «ALTER Statement (Nucleus)» (PDF). *COBOL85 Reference Manual [NetCOBOL]*. s. 555. Arkivert fra originalen (PDF) 6. januar 2014. Besøkt 27. april 2025.
* IBM (juni 2013). «ALTER Statement». *Enterprise COBOL for z/OS Language Reference*.
* IBM (16. mai 2024). «IBM COBOL Compiler Family».
* Micro Focus (5. januar 2014). «The ALTER Statement». *Micro Focus Visual COBOL 2.2 for Visual Studio 2013 COBOL Language Reference*.
* IBM PartnerWorld (21. august 2013). «Visual COBOL». IBM. Arkivert fra originalen 12. juli 2014. Besøkt 23. april 2025.

### Bøker og tidsskrifter

* Babcock, Charles (14. juli 1986). «Cobol standard add-ons flayed». *Computerworld*. 20 (28): 1, 12.
* Beyer, Kurt (2009). *Grace Hopper and the Invention of the Information Age*. MIT Press. ISBN 978-0262013109. lccn 2008044229.
* Brown, William R. (1. desember 1976). Belzer, Jack; Holzman, Albert G.; Kent, Allen, red. *Encyclopedia of Computer Science and Technology: Volume 5*. CRC Press. ISBN 978-0824722555.
* Carr, Donald E.; Kizior, Ronald J. (31. desember 2013). «Continued Relevance of COBOL in Business and Academia: Current Situation and Comparison to the Year 2000 Study» (PDF). *Information Systems Education Journal*. 1 (52). s2cid 62485945 issn 1545-679X. Arkivert fra originalen (PDF) 5. mars 2023. Besøkt 25. april 2025.
* CODASYL (Juli 1969). *CODASYL COBOL Journal of Development 1968*. National Bureau of Standards. ISSN 0591-0218. LCCN 73601243. OL14204153M.
* Conner, Richard L. (14. mai 1984). «Cobol, your age is showing». *Computerworld*. 18 (20): ID/7–ID/18. issn 0010-4841.
* Conway, Richard; Gries, David (1973). *An Introduction to Programming: A Structured Approach using PL/1 and PL/C*. Cambridge, Massachusetts: Winthrop Publishers. s. 341. ISBN 0-87626-405-4.
* Garfunkel, Jerome (1987). *The COBOL 85 Example Book*. John Wiley & Sons. ISBN 978-0471804611.
* Dijkstra, Edsger W. (18. juni 1975). «How do we tell truths that might hurt?». University of Texas at Austin. EWD498. Arkivert fra originalen 2. mai 2017. Besøkt 26. april 2025.
* Howkins, T. J.; Harandi, M. T. (April 1979). «Towards more portable COBOL». *The Computer Journal*. 22 (4): 290. doi:10.1093/comjnl/22.4.290.
* Coughlan, Michael (2002). «Introduction to COBOL». Arkivert fra originalen 5. mars 2023. Besøkt 23. april 2025.
* ISO/IEC JTC 1/SC 22/WG 4 (4. desember 2001). *ISO/IEC IS 1989:2001 – Programming language COBOL*. ISO. Arkivert fra originalen (ZIP of PDF) 24. januar 2002. Besøkt 1. mai 2025. \* ISO/IEC JTC 1/SC 22/WG 4 (4. desember 2001). «ISO/IEC IS 1989:2001 – Programming language COBOL». ISO. Arkivert fra originalen (ZIP of PDF) 24. januar 2002. Besøkt 1. mai 2025.  (Lenke går til draft N 0147)
* ISO/IEC JTC 1/SC 22/WG 4 (31. oktober 2014). *INCITS/ISO/IEC 1989:2014 [2014] – Programming language COBOL*. INCITS.
* Lämmel, Ralf; Verhoef, Chris (November–desember 2001). «Cracking the 500-language problem» (PDF). *IEEE Software*. 18 (6): 79. doi:10.1109/52.965809.
* McCameron, Fritz (1974). «COBOL Logic and Programming, third edition 1974». Arkivert fra originalen 5. mars 2016. Besøkt 24. april 2025.
* McCracken, Daniel D. (1976). *A Simplified Guide to Structured COBOL Programming*. Wiley. ISBN 0-471-58284-0. LCCN 75044399.
* McCracken, Daniel D.; Golden, Donald G. (1988). *A Simplified Guide to Structured COBOL Programming* (2nd utg.). Wiley. ISBN 978-0471610540. LCCN 87034608.
* Margaret M. Cook (Juni 1978). Ghosh, Sakti P.; Liu, Leonard Y., red. *Data Base Facility for COBOL 80* (PDF). 1978 National Computer Conference. Anaheim, California: AFIPS Press. doi:10.1109/AFIPS.1978.63. lccn: 55-44701. CS1-vedlikehold: Flere navn: redaktørliste (link)
* Marcotty, Michael (1978). *Full text of all questions submitted*. History of Programming Languages. Academic Press. s. 274274. ISBN 0127450408. doi 10.1145/800025.1198371.
* Micro Focus (7. mars 2013). «Academia needs more support to tackle the IT skills gap».
* Moseley, Jay (17. januar 2015). «COBOL Compiler from MVT».
* Naked capitalism (19. juli 2016). «COBOL and Legacy Code as a Systemic Risk».
* Pratt, Terrence W.; Zelkowitz, Marvin V. (1984). *Programming Languages: Design and Implementation* (2nd utg.). Englewood Cliffs, N.J. : Prentice Hall. ISBN 0136780121.
* Raymond, Eric Steven (1. oktober 2004). «COBOL». *The Jargon File, version 4.4.8*. Arkivert fra originalen 30. august 2014. Besøkt 24. april 2025.
* Riehle, Richard L. (August 1992). «PERFORM considered harmful». *Communications of the ACM*. 35 (8): 125–128. doi:10.1145/135226.376106. s2cid 18845698.
* Saade, Henry; Wallace, Ann (Oktober 1995). «COBOL '97: A Status Report». *Dr. Dobb's Journal*. Arkivert fra originalen 22. april 2014. Besøkt 24. april 2025.
* Sammet, Jean E. (Mai 1961). *A method of combining ALGOL and COBOL*. Papers presented at the 9–11 May 1961, western joint IRE–AIEE–ACM computer conference. ACM. doi:10.1145/1460690.1460734.
* Sammet, Jean E. (1978). Wexelblat, Richard L., red. *The early history of COBOL*. History of Programming Languages. Academic Press. ISBN 0127450408. doi:10.1145/800025.1198367.
* Sammet, Jean; Garfunkel, Jerome (Oktober 1985). «Summary of Changes in COBOL, 1960–1985». *Annals of the History of Computing*. 7 (4): 342. doi:10.1109/MAHC.1985.10033. s2cid 17.
* Shneiderman, Ben (Oktober 1985). «The Relationship Between COBOL and Computer Science». *Annals of the History of Computing*. 7 (4): 348–352. doi:10.1109/MAHC.1985.10041.
* Staff writers (10. september 1984). «An interview: Cobol defender». *Computerworld*. 18 (37): ID/29–ID/32.
* Tompkins, H. E. (1983). «In defense of teaching structured COBOL as computer science». *ACM SIGPLAN Notices*. 18 (4): 86–94. doi:10.1145/948176.948186. s2cid 33803213.
* WG4 (11. juli 2003). «Resolutions from WG4 meeting 24 – June 26–28, 2003 Las Vegas, Nevada, USA». s. 1. Arkivert fra originalen (doc) 9. juni 2016. Besøkt 23. april 2025. «a June 2008 revision of the COBOL standard»
* Veerman, Niels; Verhoeven, Ernst-Jan (25. november 2006). «Cobol minefield detection» (PDF). *Software: Practice and Experience*. 36 (14). doi:10.1002/spe.v36:14.

## Eksterne lenker

* (en) COBOL – kategori av bilder, video eller lyd på Commons