#Klooienmetcomputers

Identificatie

Arnout van Kempen over rommelen in een digitale wereld.

Een programma moet een unieke identificatie hebben, om te kunnen worden gebruikt door een besturingssysteem. Als je Word opstart in Windows, dan klik je op een icoontje. Maar achter dat icoontje gaat een bestand schuil dat waarschijnlijk een naam heeft als word.exe. Dankzij dat '.exe' weet Windows dat het om een programma gaat, een executable. Maar in dit geval belangrijker: dankzij de naam van het hele bestand 'word.exe', weet Windows precies welk programma gestart moet worden. (Ik zie hier even af van het effect van een folderstructuur).

In C en in Rust zagen we dat we de broncode van een programma in een tekstbestand plaatsten, vaak eindigend op .c of .rs, om te zien om welke programmeertaal het ging. En voor COBOL doen we dat ook, een tekstbestand met .cob dit keer. Bij het compileren geven we dan expliciet (zoals met gcc) of impliciet (zoals met cargo build) de naam mee waarmee het uitvoerbare programma door Linux of Windows gekend zal worden.

COBOL wil die identificatie al in de broncode zelf hebben. Dat geeft op het oog minder flexibiliteit, maar het is goed te bedenken dat COBOL niet is ontwikkeld voor programmeurs die een complete computer thuis op hun werkkamer hebben staan, maar voor de grote mainframes die met ponskaarten geprogrammeerd werden en waar de programmeur niet eens in de buurt mocht komen. Dan is het wel degelijk handig als in de broncode alle relevante informatie is opgenomen, waaronder een identificatie, die we tegenwoordig vooral terug zien als bestandsnaam. Misschien een bizarre gedachte, maar wie programmeerde met ponskaarten had helemaal geen bestand met de broncode. De broncode stond letterlijk op kartonnen kaarten, gecodeerd door gaatjes te slaan op bepaalde plekken. Vandaar het gebruik van hoofdletters en van een vaste kolombreedte van tachtig tekens: dat was het fysieke formaat van een IBM ponskaart.

Goed, wat leg je nu vast in de Identification division? Dat ziet er als volgt uit, waarbij optionele informatie tussen blokhaken staat, en Entry staat voor de informatie die je hier kan invullen (en let op de punt!): 

IDENTIFICATION DIVISION.
PROGRAM-ID. Entry.
[AUTHOR. Entry.]
[INSTALLATION. Entry.]
[DATE-WRITTEN. Entry.]
[DATE-COMPILED. Entry.]
[SECURITY. Entry.]
[REMARKS. Entry.]

PROGRAM-ID is dus verplicht en geeft de naam van het programma. De AUTHOR is de programmeur. De INSTALLATION geeft aan waar het programma gebruikt wordt. Bijvoorbeeld, als je een crediteuren-management hebt gebouwd voor je vestiging in Den Haag en een ander voor je vestiging in Maastricht, dan kan je hier aangeven welke het betreft. 

DATE-WRITTEN en DATE-COMPILED geven aan op welke datum het programma geschreven en gecompileerd is. Vrij zinvolle informatie, als je je versiebeheer daarmee wilt ondersteunen. 

SECURITY kan je gebruiken om aan te geven wie het programma mag gebruiken, of vergelijkbare informatie. Het is slechts voor menselijk gebruik en het regelt dus zelf niet dat de hier beschreven beveiliging ook daadwerkelijk bestaat. Leuke vraag voor de auditor zou dus zijn: beste klant, dit programma is volgens de broncode alleen te gebruiken door de financiële administratie. Hoe borgt u nu dat dat inderdaad het geval is? 

REMARKS tenslotte kan gebruikt worden voor allerlei toelichtingen en commentaar. Meestal zal een COBOL-shop hier standaarden voor hebben, maar die kunnen dus van organisatie tot organisatie verschillen.
Ten slotte, gewoon om er beeld bij te hebben, een voorbeeldje hoe dat er dan in de praktijk uit kan zien:

IDENTIFICATION DIVISION.
PROGRAM-ID.  DebiteurenBeheer.
AUTHOR.  Jeroen de Vries.
INSTALLATION.  Hoofdkantoor Den Haag.
DATE-WRITTEN.  01-AUG-2024.
DATE-COMPILED.  18-AUG-2024.
SECURITY.  Alleen toegankelijk voor debiteurenadministratie.
REMARKS.
     Dit programma beheert de debiteurenadministratie voor het
  hoofdkantoor in Den Haag. Het programma verwerkt
  betalingen, s
tuurt herinneringen voor openstaande facturen,
  en genereert
maandelijkse rapporten.

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.

Arnout van Kempen di CCO CISA is Senior manager Risk & Compliance bij Baker Tilly. Hij schrijft op persoonlijke titel. Hij is lid van de Commissie Financiƫle verslaggeving & Accountancy van de AFM en lid van de signaleringsraad van de NBA. Daarnaast is hij diaken van het bisdom 's-Hertogenbosch.

Gerelateerd

reacties

Reageer op dit artikel

Spelregels debat

    Aanmelden nieuwsbrief

    Ontvang elke werkdag (maandag t/m vrijdag) de laatste nieuwsberichten, opinies en artikelen in uw mailbox.

    Bent u NBA-lid? Dan kunt u zich ook aanmelden via uw ledenprofiel op MijnNBA.nl.