Linus Torvalds, de man achter Linux, zei ooit: "Bad programmers worry about the code. Good programmers worry about data structures and their relationships."
De makers van COBOL zullen ongeveer hetzelfde hebben gedacht, want de eerste echt inhoudelijke divisie waar de computer mee aan de slag gaat, is de data divisie. De programmacode komt pas een divisie later. Overigens is dat waarschijnlijk ook ingegeven door het feit dat het voor de compiler makkelijker is om eerst de geheugenruimte in te richten voor data, om daarna met die data aan de slag te gaan.

Hoe dan ook, de Data division is redelijk complex en voor programmeurs uit de C-hoek ook aan de rare kant. Overigens is ook deze divisie niet verplicht. Wie geen data gebruikt, hoeft daar ook niets over te vertellen aan de computer.
Voor heel modern COBOL heb je in deze divisie nog ruimte voor informatie met betrekking tot object oriented programmeren, maar die zal je in oudere code niet tegenkomen. Wat dan resteert zijn de volgende zes secties:

FILE SECTION: In de INPUT-OUTPUT SECTION van de ENVIRONMENT DIVISION hebben we bestandsnamen binnen het programma gekoppeld aan bestandsnamen in het besturingssysteem. Daar hebben we ook zaken vastgelegd over hoe een bestand gebruikt zal worden. Maar wat de opbouw van een bestand is, beschrijven we hier in de FILE SECTION. Je definieert hier de bestandsstructuur, met records en de opbouw van die records.

WORKING-STORAGE SECTION: wat records zijn voor een file, zijn variabelen in de WORKING STORAGE. In feite maakt het op logisch niveau helemaal niet uit of je gegevens vastlegt in een bestand of in intern geheugen. Hooguit kan je zeggen dat een bestand zich gedraagt als een array, terwijl een variabele in beginsel geen reeks kent. En als een programma wordt afgesloten, bestaat een bestand nog wel, terwijl variabelen op dat moment opgeruimd worden en niet langer bestaan.

Dat COBOL beide vormen van opslag op logisch, beschrijvend niveau zo identiek behandelt is erg prettig. Je zou kunnen zeggen dat COBOL een rudimentaire database-structuur heeft ingebouwd. Toen we C bespraken, hadden we situaties waarbij een structuur in het werkgeheugen echt anders was opgebouwd dan in een bestand, met als gevolg dat we vertaalslagen moesten maken. Niets daarvan in COBOL. Als je dezelfde omschrijving gebruikt in de FILE SECTION en in de WORKING-STORAGE SECTION, dan kan je je data simpelweg verplaatsen tussen bestand en intern geheugen, zonder een centje pijn. 

LOCAL-STORAGE SECTION: Deze sectie is uiterlijk identiek aan de WORKING-STORAGE SECTION. Er is echter een essentieel verschil. De variabelen in de WORKING-STORAGE SECTION zijn globale variabelen. Dat betekent dat ze overal hun waarde behouden en ook overal zichtbaar zijn. De variabelen in de LOCAL-STORAGE SECTION worden iedere keer opnieuw geïnitialiseerd bij het aanroepen van een sub-procedure binnen hetzelfde programma en zijn onzichtbaar voor een aanroepend programma. Dat betekent dat deze variabelen zich vrijwel hetzelfde gedragen als lokale variabelen in C. 

LINKAGE SECTION: In deze sectie worden variabelen gedefinieerd die worden doorgegeven tussen (sub)programma's. De computer reserveert geen geheugen voor deze variabelen, omdat het gaat om variabelen die al in het aanroepende programma gedefinieerd moeten zijn. Het is daarmee ongeveer het spiegelbeeld van local storage. In C zou je dit kunnen zien als de argumenten van een functie die je kan aanroepen vanuit een ander deel van het programma.

De eerste vier secties geven daarmee een hoge mate van flexibiliteit bij het gebruik, de opslag en de uitwisseling van data. Het is in COBOL heel voor de hand liggend om afzonderlijke functionaliteit in afzonderlijke sub-programma's te schrijven. Net zoals C dat bijvoorbeeld doet met header-files, object-files en linking. De manier van COBOL is wat meer recht-toe recht-aan en daardoor wellicht iets minder flexibel en een stuk leesbaarder. 

REPORT SECTION: Deze sectie is wat uit de gratie geraakt met de opkomst van gespecialiseerde rapportagetools, maar het blijft toch een aardigheid van de taal die goed illustreert dat COBOL bedoeld is voor 'business' en niet voor wiskundigen of computernerds. In deze sectie definieert de programmeur rapporten, met opmaak, kop en voetteksten, dat soort zaken. Wie zich de tijd herinnert van ratelende matrix-printers die kilo's papier vulden met lijsten, heeft dat soort rapporten nog wel gezien. Maar omdat deze sectie niet meer echt zinvol is, zal ik er verder geen aandacht aan besteden. 

SCREEN SECTION: Zoals de vorige sectie rapporten definieert, kan deze sectie gebruikt worden om invulschermen te definiëren. Het aardige daarvan is dat je je programmacode niet vult met schermbesturingselementen die met de programmalogica niets te maken hebben, terwijl je tegelijk wel een nette schermopmaak krijgt. Praktisch dingetje: het werkt niet lekker in een GUI en is dus behoorlijk achterhaald geworden. Ook deze sectie zal ik dus verder buiten beschouwing laten.

Wie mee wil doen met #klooienmetcomputers kan dat doen via GitHub. Maak een account op github.com en zoek naar Abmvk/kmc. Het account Abmvk volgen kan ook. Lezers zijn vrij te gebruiken wat ze willen en om zelf zaken toe te voegen of aan te passen, vragen te stellen of commentaar te leveren.