COBOL

**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  verb is used.

A  statement somewhat resembles a procedure call in a newer languages in the sense that execution returns to the code following the  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 , then control returns at the end of the called procedure. However,  is unusual in that it may be used to call a range spanning a sequence of several adjacent procedures. This is done with the  construct:


```cobolfree
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".

 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 'ed may execute a  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  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  statements happen, control flows from top to bottom through the program. But when a  statement executes, it modifies the continuation address of the called procedure (or the last procedure of the called range, if  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:


```cobolfree
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  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  statement sets the continuation address at the end of  so that it will jump back to the call site inside . Den andre  setter returen på slutten av , men endrer ikke fortsettelsesadressen til   , og forventer at den skal være standard fortsettelse.  Således, når den indre påkallelsen kommer til slutten av , hopper den tilbake til den ytre , programmet stopper etter å ha skrevet ut "1 2 3". I TinyCOBOL blander ikke de to -utsagnene seg med hverandre og utmatingen er "1 2 3 4 3". Adferden i slike tilfeller er ikke portabel.

En konsekvens er at  ikke kan skrive rekursiv kode.


```cobolfree
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 .

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

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


```cobolfree
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
```


 definerer løkker som utføres inntil en tilstand er sann. Det brukes også til å kalle prosedyrer eller rekker av prosedyrer.  og  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).
 avlaster delprogrammer fra minnet.  får programmet å hoppe til en spesifisert prosedyre.

 er en retursetning og  stanser programmet.  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 -utsagn og oppfanges av en håndterer, eller **, som er definert i -porsjonen av prosedyredivisjonen. Deklarativene er seksjoner som begynner med et  utsagn som spesifiserer feilene som skal håndteres. Unntak kan være navn eller objekter.  brukes i et deklarativ for å hoppe til utsagnet etter det som reiste unntaket eller til en prosedyre utenfor . 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 , , , og  sammen med tre andre utsagn:  som oppdaterer en record; , som velger påfølgende poster for tilgang ved å finne en record med en bestemt nøkkel; og , som frigjør en lås på den siste record som er aksessert.

Brukerinteraksjon skjer ved å bruke  og .

##### Datamanipulasjon
Følgende verb manipulerer data:
*  setter dataelementer til deres standardverdier.
*  tildeler verdier til dataelementer ; *MOVE CORRESPONDING* tildeler tilsvarende recordfelter med samme navn.
* , som har 15 formater, kan modifisere indekser, tildele objektreferanser og endre tabellkapasiteter.
* , , , , og  håndterer aritmetikk.
*  og , håndterer dynamisk hukommelse.
*  validerer og distribuerer data som spesifisert i elementbeskrivelsen i datadivisjonen.
*  og  konkatinerer og splitter strenger.
*  erstatter instanser av spesifiserte delstrenger innenfor en streng.
*  søker i en tabell etter den første oppføringen som tilfredsstiller en betingelse

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

#### Terminering av gyldighetsområde
 og , 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.


```cobolfree
*> 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:


```cobolfree
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 .

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


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


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

#### Selvmodifiserende kode
Den opprinnelige (1959) COBOL-spesifikasjonen støttet det beryktede &nbsp;&nbsp; utsagnet, for hvilke mange kompilatorer genererte selvmodifiserende kode. `X` og `Y` er prosedyrenavn, og et enkelt &nbsp;&nbsp; utsagn i prosedyren `X` utført etter et slikt -utsagn betyr &nbsp;&nbsp;. 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.

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


```cobol
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:


```cobol
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.


```cobolfree
//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:* 


```text
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  utsagn. Forsøk på å fjerne s fra COBOL-koden, resulterte likevel i kronglete programmer og redusert kodekvalitet. s ble i stor grad erstattet av  setningen og prosedyrer, som fremmet modulær programmering og ga lett aksess til løkker.  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 å  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-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.

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

### Bøker og tidsskrifter
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* *  (Lenke går til draft N 0147)
* 
*
* 
* 
*
*
* 
* 
*
*
*
*
* 
* 
*
* 
* 
* 
* 
*
* 
*

## Eksterne lenker
*