Hopp til innhold

COBOL

Fra Wikipedia, den frie encyklopedi
COBOL
Tilblivelse28. mai 1959
ParadigmeMulti-paradigme: Prosedyrisk programmering, objektorientert programmering, imperativ programmering
Utviklet avISO, CODASYL, American National Standards Institute
Siste versjon(er)2019, ISO/IEC 1989:2023
Typetildelingsterk, 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

[rediger | rediger kilde]

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

[rediger | rediger kilde]

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

[rediger | rediger kilde]

Prosedyrer

[rediger | rediger kilde]

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

Execution goes down through the procedures of a program until it is terminated.[2] 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.[3][4]

The following example (taken from Veerman & Verhoeven 2006) 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.[4]

En konsekvens er at PERFORM ikke kan skrive rekursiv kode.[4] 

    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'.[4]

Utsagn

[rediger | rediger kilde]

COBOL 2014 har 47 verb,[5] som kan grupperes i underkategorier.

Kontrollflyt
[rediger | rediger kilde]

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.[6] Parameterere kan sendes etter referanse, etter innhold eller etter verdi (hvis en funksjonsprototype er tilgjengelig).[7] 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.[8]

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
[rediger | rediger kilde]

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
[rediger | rediger kilde]

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.[9]
  • 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

[rediger | rediger kilde]

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.[10][11] 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.[11]

Selvmodifiserende kode

[rediger | rediger kilde]

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 [12]
  • Micro Focus Visual COBOL 2.2 [13]
  • Fujitsu NetCOBOL [14]
  • IBMs Enterprise COBOL for z/OS [15]

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

ALTER-utsagnet var dårlig ansett fordi det undergravde «sammenhengens lokalitet» og gjorde et programs overordnede logikk vanskelig å oppfatte.[17] 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.»[17]

Hallo, verden

[rediger | rediger kilde]

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

        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.[18] 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:[18] 

    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

[rediger | rediger kilde]

Mangelen på struktur

[rediger | rediger kilde]

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».[19]

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

En årsak til «spaghettikode» var GO TO utsagn. Forsøk på å fjerne GO TOs fra COBOL-koden, resulterte likevel i kronglete programmer og redusert kodekvalitet.[21] GO TOs 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å.[22]

COBOL-programmer var beryktede for å være monolittiske og mangle modularisering.[23] 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.[24]

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

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.[26] 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.[27]

Kompatibilitetsspørsmål

[rediger | rediger kilde]

COBOL var ment å være et svært portabelt, «allminnelig» språk. I 2001 hadde likevel omkring 300 dialekter blitt skapt.[28] 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.[29]

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.[30] 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.[31]

Omstendelig syntaks

[rediger | rediger kilde]
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.

“
”

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

Ø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 [37] og endringene i COBOL-85 var der hovedsakelig for å hjelpe til med lettelse av vedlikehold.[39]

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

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

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. [42] 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».[43]

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

I 2003 var COBOL med i 80% av læreplanene i informatikk i USA, den samme andelen som C++ og Java.[45] 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.[46]

Kritikk av designprosessen

[rediger | rediger kilde]

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.»[47] 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.[48]

COBOL-standarder har gjentatte ganger blitt forsinket: COBOL-85 ankom fem år forsinket,[49] COBOL 2002 var fem år forsinket,[50] og COBOL 2014 var seks år forsinket.[51][52] 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.[53]

Påvirkning av andre programmeringsspråk

[rediger | rediger kilde]

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

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

COBOL's COPY-fasilitet[55] påvirket utviklingen av include-direktiver.[54]

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

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

GNU COBOL

[rediger | rediger kilde]

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.[60][61]

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

Den støtter utvidede DECLARATIVES for feilsjekking.[60][61]

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.[60][61]

Referanser

[rediger | rediger kilde]
  1. ^ ISO/IEC JTC 1/SC 22/WG 4 2014, § 14.4.
  2. ^ ISO/IEC JTC 1/SC 22/WG 4 2014, § 14.6.3.
  3. ^ Identifying Procedural Structure in Cobol Programs (PDF). PASTE '99. September 1999. ISBN 1581131372. doi:10.1145/381788.316163. 
  4. ^ a b c d Veerman 2006
  5. ^ ISO/IEC JTC 1/SC 22/WG 4 2014, § 14.9.
  6. ^ ISO 2014, side §§ 14.9.4, 14.9.22.
  7. ^ ISO 2014, side §D.6.5.2.2.
  8. ^ ISO 2014, side §14.9.13.1.
  9. ^ ISO 2014, side §14.9.35.1.
  10. ^ ISO 2014, side 899
  11. ^ a b McCracken 1988, side § 8.4
  12. ^ GnuCOBOL 2013
  13. ^ Micro Focus 2014
  14. ^ Fujitsu NetCobol 1996
  15. ^ IBM Cobol 2023
  16. ^ ISO 2001
  17. ^ a b McCracken 1976, side 355
  18. ^ a b c Moseley 2015
  19. ^ Dijkstra 1975
  20. ^ Tompkins 1983
  21. ^ Riehle 1992, side 125
  22. ^ Shneiderman 1985, side 349–350
  23. ^ Coughlan 2014
  24. ^ Sammet 1978, side 258
  25. ^ Riehle 1992, side 126
  26. ^ Riehle 1992, side 127
  27. ^ Naked capitalism 2016
  28. ^ Lämmel 2001
  29. ^ Howkins 1979
  30. ^ Garfunkel 1987, side 11
  31. ^ Garfunkel 1987, side 15
  32. ^ Raymond 2004
  33. ^ Brown 1976, side 53
  34. ^ CODASYL 1969, side § II.1.1.
  35. ^ Shneiderman 1985, side 350
  36. ^ Sammet 1961, side 381
  37. ^ a b Conner 1984, side ID/I0
  38. ^ Marcotty 1978, side 263
  39. ^ Garfunkel 1987
  40. ^ Conner 1984, side ID/14
  41. ^ Conway 1973
  42. ^ Irwin 1974
  43. ^ Computerworld 1984
  44. ^ Pratt 1984
  45. ^ Carr 2013
  46. ^ Micro Focus 2013
  47. ^ Beyer 2009, side 301
  48. ^ Sammet 1985
  49. ^ Cook 1978
  50. ^ Saade 1995
  51. ^ COBOL Standard 2014
  52. ^ WG4 2003
  53. ^ Babcock 1986
  54. ^ a b Shneiderman 1985, side 349
  55. ^ Marcotty 1978, side 274
  56. ^ GnuCOBOL 2024
  57. ^ IBM COBOL 2024
  58. ^ Visual COBOL 2013
  59. ^ Coughlan 2002
  60. ^ a b c d Cobolworks 2025
  61. ^ a b c d GCC 15.1 2025

Kilder

[rediger | rediger kilde]

Nettsteder

[rediger | rediger kilde]

Bøker og tidsskrifter

[rediger | rediger kilde]

Eksterne lenker

[rediger | rediger kilde]
  • (en) COBOL – kategori av bilder, video eller lyd på Commons Rediger på Wikidata


Hentet fra «https://no.wikipedia.org/w/index.php?title=COBOL&oldid=25120988»