COBOL (Norsk)

SyntaxEdit

COBOL har en engelsk-lignende syntaks, som brukes til å beskrive nesten alt i et program. For eksempel kan en tilstand uttrykkes som x ER STØRRE EN y eller mer kortfattet som x GREATER y eller x > y . Mer komplekse forhold kan «forkortes» ved å fjerne gjentatte forhold og variabler. For eksempel a > b OG a > c ELLER a = d kan forkortes til a > b OG c ELLER = d . For å støtte denne engelsklignende syntaksen har COBOL over 300 søkeord. Noen av nøkkelordene er enkle alternative eller pluraliserte stavemåter med det samme ordet, som gir flere engelsklignende uttalelser og ledd; f.eks. søkeordene IN og OF kan brukes om hverandre, og det samme kan ER og ER , og VALUE og VERDIER .

Hvert COBOL-program består av fire grunnleggende leksikalske elementer: ord, bokstaver, bildestrenger (se § BILDE klausul) og skilletegn. Ord inkluderer reserverte ord og brukerdefinerte identifikatorer. De har opptil 31 tegn og kan inneholde bokstaver, sifre, bindestrek og understrekninger. Bokstaver inkluderer tall (f.eks. 12 ) og strenger (f.eks. "Hallo!" ). Separatorer inkluderer mellomromstegnet og kommaer og semikolon etterfulgt av et mellomrom.

Et COBOL-program er delt inn i fire divisjoner: identifikasjonsdivisjonen, miljøinndelingen, datadelingen og prosedyredivisjonen. Identifikasjonsavdelingen spesifiserer navn og type på kildeelementet og er der klasser og grensesnitt er spesifisert. Miljøavdelingen spesifiserer programfunksjoner som avhenger av systemet som kjører det, for eksempel filer og tegnsett. Datainndelingen brukes til å deklarere variabler og parametere. Prosedyredivisjonen inneholder programuttalelsene. Hver divisjon er delt inn i seksjoner, som består av avsnitt.

MetalanguageEdit

COBOLs syntaks blir vanligvis beskrevet med en unik metallspråk ved hjelp av seler, parenteser, stenger og understreking. Metalspråket ble utviklet for de opprinnelige COBOL-spesifikasjonene. Selv om Backus – Naur-form eksisterte på den tiden, hadde ikke komiteen hørt om det.

Som et eksempel, consi der følgende beskrivelse av en ADD uttalelse:

Denne beskrivelsen tillater følgende varianter:

ADD 1 TO xADD 1, a, b TO x ROUNDED, y, z ROUNDEDADD a, b TO c ON SIZE ERROR DISPLAY "Error"END-ADDADD a TO b NOT SIZE ERROR DISPLAY "No error" ON SIZE ERROR DISPLAY "Error"

KodeformatRediger

COBOL kan skrives i to formater: fast (standard) eller gratis. I fast format må koden justeres for å passe i visse områder (hold-over fra å bruke stansede kort).Fram til COBOL 2002 var disse:

I COBOL 2002 ble områdene A og B fusjonert for å danne programtekstområdet, som nå ender i en implementordefinert kolonne.

COBOL 2002 introduserte også kode i fritt format. Gratisformatkode kan plasseres i hvilken som helst kolonne i filen, som på nyere programmeringsspråk. Kommentarer spesifiseres ved hjelp av *>, som kan plasseres hvor som helst og som også kan brukes i kildekoden i fast format. Fortsettelseslinjer er ikke til stede, og >>PAGE -direktivet erstatter / -indikatoren.

IdentifikasjonsdelingEdit

Identifikasjonsavdelingen identifiserer følgende kodenhet og inneholder definisjonen av en klasse eller grensesnitt.

Objektorientert programmeringEdit

Klasser og grensesnitt har vært i COBOL siden 2002. Klasser ha fabrikkobjekter, som inneholder klassemetoder og variabler, og forekomstobjekter, som inneholder forekomstmetoder og variabler. Arv og grensesnitt gir polymorfisme. Støtte for generell programmering tilbys gjennom parametriserte klasser, som kan insti tiseres for å bruke hvilken som helst klasse eller grensesnitt. Objekter lagres som referanser som kan være begrenset til en bestemt type. Det er to måter å kalle en metode på: INVOKE uttalelse, som fungerer på samme måte som CALL , eller gjennom inline-metodeinnkalling, som er analog med bruk av funksjoner.

*> These are equivalent.INVOKE my-class "foo" RETURNING varMOVE my-class::"foo" TO var *> Inline method invocation

COBOL gir ikke en måte å skjule metoder på. Klassedata kan imidlertid skjules ved å erklære det uten en PROPERTY -klausul, noe som gir brukeren ingen tilgang til dem. Metodeoverbelastning ble lagt til i COBOL 2014.

Environment divisionEdit

Miljøavdelingen inneholder konfigurasjonsdelen og inndata-utgangsseksjonen. Konfigurasjonsseksjonen brukes til å spesifisere variable funksjoner som valutategn, lokaliteter og tegnsett. Inndata-utgangsseksjonen inneholder filrelatert informasjon.

FilesEdit

COBOL støtter tre filformater, eller organisasjoner: sekvensiell, indeksert og relativ. I sekvensielle filer er poster sammenhengende og må krysses sekvensielt, på samme måte som en koblet liste. Indekserte filer har en eller flere indekser som gjør det mulig å få tilgang til poster tilfeldig og som kan sorteres på dem. Hver post må ha en unik nøkkel, men andre alternative taster trenger ikke å være unike. Implementeringer av indekserte filer varierer mellom leverandører, selv om vanlige implementeringer, for eksempel C ‑ ISAM og VSAM, er basert på IBMs ISAM. Relative filer, som indekserte filer, har en unik registreringsnøkkel, men de har ikke alternative nøkler. A relativ post nøkkel er dens ordinære posisjon; for eksempel har den 10. posten en nøkkel på 10. Dette betyr at å opprette en post med en nøkkel på 5 kan kreve oppretting av (tomme) forrige poster. Relative filer tillater også både sekvensiell og tilfeldig tilgang.

En vanlig ikke-standard utvidelse er linjen sekvensiell organisasjon, brukt til å behandle tekstfiler. Postene i en fil avsluttes av en ny linje og kan ha varierende lengde.

Data divisionEdit

Data divisjonen er delt inn i seks seksjoner som deklarerer forskjellige elementer: filseksjonen, for arkivoppføringer; arbeids-lagringsseksjonen, for statiske variabler; den lokale lagringsdelen for automatiske variabler; koblingsseksjonen, for parametere og returverdien; rapportseksjonen og skjermseksjonen for tekstbaserte brukergrensesnitt.

Samlet dataredigering

Dataelementer i COBOL blir deklarert hierarkisk ved bruk av nivånumre som indikerer om et dataelement er en del av et annet. Et element med et høyere nivå-nummer er underlagt et element med et lavere nivå. Dataelementer på toppnivå, med nivånivå 1, kalles poster. Elementer som har underordnede samlede data kalles gruppeartikler; de som ikke kalles elementære gjenstander. Nivåetall som brukes til å beskrive standard dataelementer er mellom 1 og 49.

I eksemplet ovenfor er elementært element num og gruppeelement datoen er underordnet posten noe-post , mens elementære elementer året , måneden , og -dag er en del av gruppeelementet datoen .

Underordnede elementer kan skilles fra med IN (eller OF ) nøkkelord. Tenk for eksempel på eksempelkoden ovenfor sammen med følgende eksempel:

 01 sale-date. 05 the-year PIC 9(4). 05 the-month PIC 99. 05 the-day PIC 99.

Navnene året , måneden , og dagen er tvetydige av seg selv, siden mer enn ett dataelement er definert med disse navnene. For å spesifisere et bestemt dataelement, for eksempel et av elementene som finnes i salgsdato -gruppen, vil programmereren bruke året IN salgsdato (eller tilsvarende året FOR salgsdato ). (Denne syntaksen ligner på "punktnotasjonen" som støttes av de fleste moderne språk.)

Andre datanivåer Rediger

Et nivå-tall på 66 brukes til å erklære en omgruppering av tidligere definerte gjenstander, uavhengig av hvordan disse varene er strukturert. Dette datanivået, også referert til av den tilhørende RENAMES -klausulen, brukes sjelden, og ble vanligvis funnet i gamle programmer rundt 1988. Dens evne til å ignorere de hierarkiske og logiske strukturdataene betydde at bruken ikke ble anbefalt, og mange installasjoner forbød bruken.

Et 77-nivånummer indikerer at varen er frittstående, og i slike situasjoner tilsvarer nivå-tallet 01. For eksempel erklærer følgende kode to 77-nivå dataelementer, property-name og salgsregion , som er ikke-gruppedataelementer som er uavhengige av (ikke underordnet) andre dataelementer:

 77 property-name PIC X(80). 77 sales-region PIC 9(5).

Et 88-nivånummer deklarerer et tilstandsnavn (et såkalt 88-nivå) som er sant når det overordnede dataelementet inneholder en av verdiene spesifisert i VALUE klausul. Følgende kode definerer for eksempel to 88-nivå-betingelsesnavnelementer som er sanne eller falske, avhengig av gjeldende tegndataverdi for lønnstype dataelement . Når dataelementet inneholder en verdi på "H" , er betingelsesnavnet lønn per time er sant, mens når den inneholder en verdi på "S" eller "Y" , er betingelsesnavnet lønn-er-årlig sant. Hvis dataelementet inneholder en annen verdi, er begge betingelsesnavnene falske.

 01 wage-type PIC X. 88 wage-is-hourly VALUE "H". 88 wage-is-yearly VALUE "S", "Y".

DatatyperEdit

Standard COBOL gir følgende datatyper:

Type sikkerhet er variabel i COBOL.Numeriske data konverteres stille mellom forskjellige representasjoner og størrelser, og alfanumeriske data kan plasseres i et hvilket som helst dataelement som kan lagres som en streng, inkludert numeriske data og gruppedata. I motsetning til dette kan objektreferanser og pekere bare tildeles fra elementer av samme type, og deres verdier kan være begrenset til en bestemt type. 3210f17cac «> PICTURE (eller PIC ) ledd er en streng med tegn, som hver representerer en del av dataelementet og hva den kan inneholde. Noen bildekarakterer spesifiserer varetypen og hvor mange tegn eller sifre den har i minnet. For eksempel indikerer et 9 et desimaltall, og et S indikerer at varen er signert. Andre bildekarakterer (kalt innsettings- og redigeringstegn) angir hvordan et element skal formateres. For eksempel definerer en serie + tegn karakterposisjoner så vel som hvordan et ledende tegntegn skal plasseres i de endelige karakterdataene; det ikke-numeriske tegnet lengst til høyre vil inneholde elementets tegn, mens andre tegnposisjoner som tilsvarer et + til venstre for denne posisjonen vil inneholde et mellomrom. tegn kan spesifiseres mer kortfattet ved å spesifisere et tall i parentes etter et bildekarakter. For eksempel tilsvarer 9 (7) 9999999 . Bildespesifikasjoner som bare inneholder siffer ( 9 ) og skilt ( S ) tegn definerer rent numeriske dataelementer, mens bildespesifikasjoner inneholder alfabetisk ( A ) eller alfanumerisk ( X ) tegn definerer alfanumeriske dataelementer. Tilstedeværelsen av andre formateringstegn definerer redigerte numeriske eller redigerte alfanumeriske dataelementer.

BRUK clauseEdit

BRUK klausul erklærer formatet data lagres i. Avhengig av datatypen, kan den enten utfylle eller brukes i stedet for en PICTURE klausul. Selv om den kan brukes til å erklære pekere og objektreferanser, er den for det meste rettet mot å spesifisere numeriske typer. Disse numeriske formatene er:

• Binær, der en minimumsstørrelse enten er spesifisert av PICTURE -satsen eller av en USAGE paragraf som BINARY-LONG.
• BRUK COMPUTATIONAL , der data kan være lagret i uansett format implementeringen gir; ofte tilsvarer BRUK BINAR
• BRUK DISPLAY , standardformatet , der data lagres som en streng
• Flytpunkt, enten i et implementeringsavhengig format eller i henhold til IEEE 754.
• BRUK NATIONAL , der data lagres som en streng ved hjelp av et utvidet tegnsett
• BRUK PAKKET-DESIMAL , der data lagres i minst mulig desimalformat (typisk pakket binærkodet desimal)

Report WriterEdit

Rapportskriveren er en deklarativ funksjon for å lage rapporter. Programmereren trenger bare å spesifisere rapportoppsettet og dataene som kreves for å produsere det, og frigjør dem fra å måtte skrive kode for å håndtere ting som sideskift, dataformatering og overskrifter og bunntekster.

Rapporter er knyttet til rapporten filer, som er filer som bare kan skrives til gjennom rapportforfatteruttalelser.

 FD report-out REPORT sales-report.

Hver rapport er definert i rapportseksjonen av datadivisjonen. En rapport er delt inn i rapportgrupper som definerer rapportens overskrifter, bunntekster og detaljer. Rapporter fungerer rundt hierarkiske kontrollbrudd. Kontrollbrudd oppstår når en nøkkelvariabel endrer verdien, for eksempel når du oppretter en rapport som beskriver kunders bestillinger, en kontrollbrudd kan oppstå når programmet når en annen kundes bestillinger. Her er et eksempel på en rapportbeskrivelse for en rapport som gir en selgers salg og som advarer om ugyldige poster:

Rapportbeskrivelsen ovenfor beskriver følgende layout:

Fire utsagn styrer rapportskriveren: INITIATE , som forbereder rapportskriveren for utskrift; GENERATE , som skriver ut en rapportgruppe; SUPPRESS , som undertrykker utskriften av en rapportgruppe; og TERMINATE , som avslutter rapportbehandlingen.For ovennevnte salgsrapporteksempel kan prosedyredelingen se slik ut:

 OPEN INPUT sales, OUTPUT report-out INITIATE sales-report PERFORM UNTIL 1 <> 1 READ sales AT END EXIT PERFORM END-READ VALIDATE sales-record IF valid-record GENERATE sales-on-day ELSE GENERATE invalid-sales END-IF END-PERFORM TERMINATE sales-report CLOSE sales, report-out .

Bruk av Report Writer-anlegget hadde en tendens til å variere mye; noen organisasjoner brukte det mye og andre ikke i det hele tatt. I tillegg varierte implementeringene av Report Writer i kvalitet, og de i underenden brukte noen ganger store mengder minne ved kjøretid.

Procedure divisionEdit

ProceduresEdit

Seksjonene og avsnittene i prosedyredivisjonen (samlet kalt prosedyrer) kan brukes som etiketter og som enkle underrutiner. I motsetning til i andre divisjoner trenger ikke avsnitt være i seksjoner. Utførelse går gjennom prosedyrene til et program til det avsluttes. For å bruke prosedyrer som underrutiner, PERFORM verb blir brukt.

En UTFØRE uttalelse ligner noe på en prosedyreanrop på et moderne språk i den forstand at utførelse returnerer til koden etter PERFORM -uttalelsen på slutten av den ringte koden; det gir imidlertid ingen mekanisme for parameteroverføring eller for å returnere en resultatverdi. Hvis en subrutine påkalles ved hjelp av en enkel setning som PERFORM subrutine , kommer kontrollen tilbake på slutten av den kallte prosedyren. Imidlertid er UTFØRE uvanlig ved at den kan brukes til å kalle et område som strekker seg over en sekvens av flere tilstøtende prosedyrer. Dette gjøres med PERFORM sub-1 THRU sub-n -konstruksjon:

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

Resultatet av dette programmet vil være: «AABC».

PERFORM skiller seg også fra konvensjonelle prosedyreanrop. at det i det minste tradisjonelt ikke er noen forestilling om en samtalestabel. Som en konsekvens er nestede påkallelser mulige (en sekvens med kode som PERFORM «ed kan utføre en PERFORM selve uttalelsen), men krever ekstra forsiktighet hvis deler av den samme koden utføres av begge påkallelsene. Problemet oppstår når koden i den indre påkallingen når utgangspunktet for den ytre påkallingen. Mer formelt, hvis kontrollen går gjennom utgangspunkt for en UTFØRE påkallelse som ble kalt tidligere, men ikke er fullført ennå, COBOL 2002-standarden foreskriver offisielt at oppførselen er udefinert.

Årsaken er at COBOL, i stedet for en «returadresse», opererer med det som kan kalles en fortsettelsesadresse. Når kontrollflyten når slutten av en hvilken som helst prosedyre, blir fortsettelsesadressen slått opp og kontrollen overført til den adressen. programmet kjører, initialiseres fortsettelsesadressen for hver prosedyre til startadressen til proffen cedure som kommer neste i programteksten slik at hvis ingen PERFORM utsagn skjer, flyter kontrollen fra topp til bunn gjennom programmet. Men når en PERFORM -erklæring kjøres, endrer den fortsettelsesadressen til den anropte prosedyren (eller den siste prosedyren i det ringte området, hvis PERFORM THRU ble brukt), slik at kontrollen kommer tilbake til anropssiden på slutten. Den opprinnelige verdien lagres og gjenopprettes etterpå, men det er bare en lagringsposisjon. Hvis to nestede påkallinger opererer med overlappende kode, kan de forstyrre hverandres styring av fortsettelsesadressen på flere måter.

Følgende eksempel (hentet fra Veerman & Verhoeven 2006) illustrerer problemet:

Man kan forvente at produksjonen av dette programmet vil være «1 2 3 4 3»: Etter å ha vist «2», vil den andre UTFØRE får «3» og «4» til å vises, og så fortsetter den første påkallelsen med «3». I tradisjonelle COBOL-implementeringer er dette ikke tilfelle. Snarere den første PERFORM uttalelse setter fortsettelsesadressen på slutten av LABEL3 slik at den hopper tilbake til anropsside i LABEL1 . Den andre PERFORM setningen setter avkastningen på slutten av LABEL4 men endrer ikke fortsettelsesadressen til LABEL3 , og forventer at det skal være standard fortsettelse. Når den indre påkallingen kommer til slutten av LABEL3 , hopper den tilbake til den ytre PERFORM uttalelse, og programmet slutter å ha skrevet ut bare "1 2 3". På den annen side, i noen COBOL-implementeringer som TinyCOBOL-kompilatoren med åpen kildekode, forstyrrer ikke de to PERFORM utsagnene hverandre, og utdataene er faktisk "1 2 3 4 3 ".Derfor er oppførselen i slike tilfeller ikke bare (kanskje) overraskende, den er heller ikke bærbar.

En spesiell konsekvens av denne begrensningen er at PERFORMER kan ikke brukes til å skrive rekursiv kode. Et annet enkelt eksempel for å illustrere dette (litt forenklet fra Veerman & Verhoeven 2006):

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

Man kan forvente at produksjonen er «1 2 3 END END END», og faktisk er det det noen COBOL-kompilatorer vil produsere. Men noen kompilatorer, som IBM COBOL, vil produsere kode som skriver ut «1 2 3 END END END END …» og så videre, og skriver «END» om og om igjen i en endeløs løkke. Siden det er begrenset plass til å lagre adresser for sikkerhetskopiering, blir sikkerhetskopiene overskrevet i løpet av rekursive påkallinger, og alt som kan gjenopprettes er hoppet tilbake til DISPLAY "END" .

StatementsEdit

COBOL 2014 har 47 utsagn (også kalt verb), som kan grupperes i følgende brede kategorier: kontrollflyt, I / O, datamanipulering og rapportskriveren. Rapportskrivers uttalelser er dekket i rapportseksjonen.

Control flowEdit

COBOLs betingede uttalelser er IF og EVALUERING . EVALUATE er en bryterlignende setning med den ekstra evnen til å evaluere flere verdier og betingelser. Dette kan brukes til å implementere beslutningstabeller. For eksempel kan følgende brukes til å kontrollere en CNC-dreiebenk:

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 CONTINUEEND-EVALUATE

Uttalelsen PERFORM brukes til å definere sløyfer som utføres til en tilstand er sann (ikke mens den er sann, noe som er mer vanlig på andre språk). brukes også til å ringe prosedyrer eller prosedyrer (se prosedyreseksjonen for mer informasjon). CALL og INVOKE ringe henholdsvis underprogrammer og metoder. Navnet på underprogrammet / metoden finnes i en str ing som kan være en bokstavelig eller et dataelement. Parametere kan sendes ved referanse, etter innhold (der en kopi sendes med referanse) eller etter verdi (men bare hvis en prototype er tilgjengelig). CANCEL laster ned underprogrammer fra hukommelsen. GO TO får programmet til å hoppe til en spesifisert prosedyre.

GOBACK statement er en return statement og STOP setningen stopper programmet. Uttrykket EXIT har seks forskjellige formater: den kan brukes som en returuttalelse, en pauseuttalelse, en fortsettelsesuttalelse, en sluttmarkør eller å forlate en prosedyre.

Unntak heves med en RAISE -erklæring og fanges med en behandler, eller deklarativ, definert i DEKLARATIVER del av prosedyredelingen. Deklarativer er seksjoner som begynner med en USE -uttrykk som angir hvilke feil som skal håndteres. Unntak kan være navn eller gjenstander. RESUME brukes i en deklarativ for å hoppe til uttalelsen etter den som hevet unntaket eller til en prosedyre utenfor DEKLARATIVER . I motsetning til andre språk, kan ikke fangede unntak avslutte programmet, og programmet kan fortsette upåvirket.

I / OEdit

File I / O håndteres av den selvbeskrivende ÅPENT , STENG , LES , og SKRIV utsagn sammen med ytterligere tre: REWRITE , som oppdaterer en post; START , som velger etterfølgende poster å få tilgang til ved å finne en post med en bestemt nøkkel; og UNLOCK , som frigjør en lås på den siste posten som ble brukt.

Brukerinteraksjon gjøres ved hjelp av ACCEPT og DISPLAY .

Data manipulationEdit

Følgende verb manipulerer data:

• INITIALIZE , som setter dataelementene til standardverdiene.
• MOVE , som tildeler dataelementer verdier; MOVE CORRESPONDING tildeler tilsvarende felt som heter.
• SET , som har 15 formater: den kan endre indekser, tildele objektreferanser og endre tabell kapasiteter, blant andre funksjoner.
• LEGG TIL , SUBTRAKT , FLERE , DIVIDE , og COMPUTE , som håndterer aritmetikk (med COMPUTE som tilordner resultatet av en formel til en variabel).
• TILDELE og GRATIS , som håndterer dynamisk minne.
• VALIDATE , som validerer og distribuerer data som spesifisert i en vares beskrivelse i datadelingen.
• STRING og UNSTRING , som henholdsvis sammenkobler og deler strenger.
• INSPEKT , som stemmer eller erstatter forekomster av spesifiserte understreng i en streng.
• SØK , som søker i en tabell for den første oppføringen oppfyller en betingelse.

Filer og tabeller sorteres ved hjelp av SORT og MERGE verb fletter og sorterer filer. RELEASE verbet gir poster å sortere og RETURN henter sorterte poster i rekkefølge.

Scope terminationEdit

Noen utsagn, som IF og LES , kan selv inneholde utsagn. Slike utsagn kan avsluttes på to måter: av en periode (implisitt avslutning), som avslutter alle ubestemte utsagn som er inneholdt, eller av en omfangsterminator, som avslutter nærmeste samsvarende åpne uttalelse.

Nestede uttalelser avsluttet med en periode er en vanlig kilde til feil. Undersøk for eksempel følgende kode:

IF x DISPLAY y. DISPLAY z.

Her er hensikten å vise y og z hvis betingelse x er sant. Imidlertid vil z vises uansett verdien av x fordi IF -uttalelsen avsluttes av en feil periode etter DISPLAY y .

En annen feil er et resultat av det dinglende annet problemet, når to IF utsagn kan knyttes til et ELSE.

IF x IF y DISPLAY aELSE DISPLAY b.

I fragmentet ovenfor knytter ELSE seg til IF y -uttalelsen i stedet for IF x -erklæring, forårsaker en feil. Før introduksjonen av eksplisitte terminatorer, forhindrer det at ELSE NESTE SENNING må plasseres etter den indre IF .

Selvmodifiserende kodeEdit

Den opprinnelige (1959) COBOL-spesifikasjonen støttet den beryktede ALTER X FOR Å FORTSETTE TIL Y uttalelse, som mange kompilatorer genererte selvmodifiserende kode for. X og Y er prosedyremerker, og den eneste GÅ TIL uttalelse i prosedyre X utført etter en slik ALTER uttalelse betyr GÅ TIL Y i stedet. Mange kompilatorer støtter det fremdeles, men det ble ansett som foreldet i COBOL 1985-standarden og slettet i 2002.

Uttalelsen ALTER ble dårlig ansett fordi det undergravde «lokalitet av kontekst» og gjorde det vanskelig å forstå et program «overordnet logikk. Som lærebokforfatter Daniel D. McCracken skrev i 1976, da» 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 mislyktes … synet av en GO TO-uttalelse i et avsnitt av seg selv, signaliserer som det gjør eksistensen av et ukjent antall ALTER-uttalelser på ukjente steder i hele programmet, slår frykt i hjertet til den modigste programmereren. «

Hello, worldEdit

Et» Hello, world «-program i COBOL:

 IDENTIFICATION DIVISION. PROGRAM-ID. hello-world. PROCEDURE DIVISION. DISPLAY "Hello, world!" .

Da det – nå berømte – «Hello, World!» -programeksemplet i The C Programming Language først ble publisert i 1978, kom en lignende mai nframe COBOL-programeksempel ville ha blitt sendt gjennom JCL, med stor sannsynlighet ved hjelp av en stansekortleser og 80 kolonnestansekort. Listingen nedenfor, med en tom DATADELING, ble testet ved hjelp av GNU / Linux og System / 370 Hercules-emulatoren som kjører MVS 3.8J. JCL, skrevet i juli 2015, er hentet fra Hercules-veiledningene og prøvene som Jay Moseley arrangerte. I samsvar med COBOL-programmering fra den tiden vises HELLO, WORLD med alle store bokstaver.

Etter å ha sendt JCL, viste MVS-konsollen:

 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 +HELLO, WORLD 19.52.48 JOB 3 COBUCLG BASETEST GO PGM=*.DD RC= 0000 19.52.48 JOB 3 $HASP395 COBUCLG ENDED

Linje 10 i konsollisten ovenfor er uthevet for effekt, er uthevingen ikke en del av den faktiske konsollutgangen.

Den tilhørende kompilatorlisten genererte over fire sider med tekniske detaljer og jobbkjøringsinformasjon, for den eneste linjen med utdata fra de 14 linjene COBOL.