Da jeg dimitterede som datamatiker tilbage i 2000, havde jeg allerede skrevet kontrakt med Bankdata. Hvad jeg skulle lave, anede jeg ikke rigtigt, andet end det var noget med at kode Cobol på en mainframe
Cobol? Mainframe? Havde hørt noget om det, men mest af det var fra de gode gamle dage, og det ikke var noget der blev brugt længere. Men de ville uddanne mig til at udvikle på den, og det lød til at være et miljø med høje krav og masser af udfordringer. Og jeg har ikke fortrudt! Det at udvikle på en mainframe er ikke noget, der kun er for dinosaurer og andre uddøende arter - men for dem, der drives af komplekse systemer og tårnhøje krav.
Mainframe
Det er jo 'bare' en stor computer med mange CPU'er, og som er gearet til at køre alt parallelt og styre tonsvis af harddiske og brugere m.m. Typisk bruges mainframes som backend-systemet hvor data gemmes og forretningslogikken ligger. Forretningslogikken er alle valideringer og andre forretningsmæssige regler, så kort fortalt andet end præsentationslaget og tekniklaget(selve accessen til hardware, databaser o.l.) Brugergrænsefladen kan så være 3270-skærmbilleder(se eksemplerne, men det er tekstbaserede skærmbilleder), webservices eller Java portlets m.m. Som systemudvikler hos Bankdata, er vores primæresprog Cobol, men vi benytter også PL/1, Java o.l. Bankdata bruger et styresystem der hedder z/OS, som er udviklet af IBM specielt rettet til mainframes. Men man kan også benytte Linux og andre styresystemer, det kommer an på hvad mainframen skal benyttes til. I den finansielle branche tror jeg, at z/OS er mest benyttet, da det understøtter DB2 (databasesystem) og CICS (en applikationsserver) som er det mest udbredte. Selve udviklingsmiljøet kan virke gammeldags. 3270-skærmbilleder er ikke det mest fancy, men det virker og er utroligt effektivt. Og sådan er en stor del af verdenen på en mainframe. Det er en velafprøvet platform som er blevet pudset af gennem de sidste 30 år og der er kommet masser af nye ting til.
Cobol
Nej, Cobol er ikke et dødt sprog. Det er gammelt, ja, men derfor behøver det jo ikke dø. Det er derimod blevet udviklet stille og roligt igennem tiden, og i dag supporterer Cobol bl.a. XML direkte i sproget. At kode Cobol er for mig meget som at kode Visual Basic. Det er næsten som at skrive en engelsk stil. Og det er noget af det der gør Cobol meget stærkt. Det er nemt at læse, og dermed også rimeligt nemt at forvalte efterfølgende, da man hurtigt kan læse og forstå programmet.
Standardskeletter har også gjort det endnu nemmere (programeksempler man skal tage udgangspunkt i, og som findes i mange varianter, men alle er gennemtestet og overholder en kodestandard). En anden ting er performance. Cobol programmer er compilerede programmer, der afvikles hurtigt. En tredje ting man heller ikke må undervurdere: Der er skrevet rigtig meget kode i Cobol hos Bankdata, og det vil tage rigtig lang tid at kode det om til et andet sprog og efterfølgende teste det. Og hvorfor skifte noget der, der faktisk fungerer rigtig godt? Så selvom Cobol er et ældre sprog, er jeg blevet glad for at kode i det, og tror stadig på, at det vil blive brugt i mange år frem.
Hvad driver værket?
Min motivation for at udvikle på mainframes er klart, at jeg er mest til teknisk design og udfordringerne ved at lave flerbrugersystemer, der kan håndtere store mængder, både hvad angår data og antal af transaktioner. Og det er en af de helt store fordele med firmaer der er så store som Bankdata: Man har mulighed for at specialisere sig i noget af det tekniske, og arbejde primært med det. F.eks. siger design af præsentationslaget mig ikke ret meget, og slet ikke når det kommer over i, at det ikke er 3270-skærmbilleder, men browserbaserede skærmbilleder, hvor der er endnu flere muligheder. Og heldigvis er der ingen der siger, at jeg skal det. Det gør andre. Det er en fordel at kende til den anden verden, men jeg synes det er dejligt, at jeg ikke behøver være specialist i den.
Store datamængder
Da jeg studerede, syntes jeg, det var svært at se en del af logikken med bl.a. databaser. Hvorfor partitionere, hvorfor overveje hvor mange indekser, der kunne være og hvilke felter man læser? Det har jeg lært i dag, hvor jeg arbejder med tabeller der har passeret de 1,5 mia. rækker. Pludselig betyder det noget, om et indeks er optimalt, og om vi så stadig kan indsætte rækker hurtigt nok. Det er en balancegang, jeg først har lært efter jeg har arbejdet med så store systemer. En af de første opgaver, jeg lavede tilbage da jeg startede var på en ældre DB2-version, hvor vi havde et problem: DB2 kunne ikke håndtere så store indekser som vi behøvede, så vi måtte til at kode vores egne indekstabeller. Og generelt er DB2 en af de store syndere, når man snakker performance. Der går utrolig meget tid med at finde data. Vi lærte godt nok om det under studiet, men man skal op i nogle store datamængder og mange brugere for, at man virkeligt lærer det.
Og databasesystemer er lige så uforudsigelige som kvinder, så det gælder om at lære deres væremåde og så ellers please dem. En anden ting er de høje krav til systemerne i drift.
Oppetid: Min. 99.97%
Der er tårnhøje krav til kvaliteten af vores systemer. Der er flere tusind rådgivere ude i bankerne der benytter dem, samt alle virksomheder og privatpersoner der benytter netbank. Så hvis det ikke kører, så er det noget, vi hurtigt hører. Svartider, svartider, svartider. Normalt når vi arbejder i præsentationslaget siger vi, at fra brugeren gør noget, til der er svar må der maks. gå to sekunder. Selvom der inde i maven på systemet gennemløbes måske 150 programmer der hver især tjekker noget forretningslogik, læser databaser, udregner og opdaterer andre databaser, inkl. logning o.l. - og det gælder også på de dage, hvor maskinerne kører 100% CPU forbrug. Selve datasikkerheden skal også være høj. Folk er jo normalt ikke så tilfredse med, at banken ikke har styr på, hvor mange penge de har, eller ting forsvinder fra et kontoudtog. Så data er ikke noget, man må ændre uden et godt revisionsspor - og mange data må slet ikke rettes, når vi snakker om historiske data (dvs. at de er behandlet færdigt og evt. præsenteret for en bruger). Så der er ikke plads til mange fejl, når først et system er gået i luften.
Integration er et keyword
Banksystemer er ikke bare et system, men rigtig mange forskellige systemer, og tidens trend er, at man selvfølgelig kun skal lave tingene en gang, og så skal systemerne være integreret til den store guldmedalje. Nye dejlige udfordringer, for at integrere er én ting. At få det til at performe er noget helt andet, som selvfølgelig også bare skal virke. Og det er endnu en af de store forcer ved at udvikle på mainframe. Systemerne er store, og det kræver, at man tænker sig om. Selv den mindste sten kan vælte hele systemet, hvis det ikke virker.
24 timers drift
Nu kan 24 timers drift dække over mange ting. Vores maskiner er tændte 24 timer i døgnet, 365 dage om året, så vi må jo have 24 timers drift. Men vi har perioder, hvor brugeren ikke kan benytte systemet fordi vi skal have afviklet serviceprogrammer. Vi har også en masse ting, der kører batch om natten. Men generelt set skal vi udvikle systemer der er realtidssystemer, og skal kunne benyttes hele tiden. Der er så meget at lave hele tiden, at vi simpelthen ikke har tid til at 'lukke' for systemer ret lang tid ad gangen - for så kommer vi for langt bagefter med behandlingen. I integrerede systemer vil det betyde, at vi måske behandler noget på forkert grundlag.
Nattevagter
I min afdeling har vi ansvaret for mange basissystemer (både udvikling og drift), og dermed en del programmer, der kører om natten. Om natten har vi en nattevagtordning, hvor en tilkaldevagt skal tilse alle afdelingens systemer. Det giver nogle gode udfordringer for mig som udvikler at være med i den ordning, da man kommer rundt om programmer og systemer som man ellers aldrig ville have stødt på. Udfordringer er der nok af - så hvis du er til backend systemudvikling, komplekse systemer og tårnhøje krav, er der altid plads til gode udviklere. Og især inden for den finansielle branche, hvor der i øjeblikket er stor efterspørgsel på disse profiler. Så det kan være, at vi ses en dag?
Bankdata oplærer i mainframe
Bankdata er med sine 450 ansatte en af de større it-virksomheder i trekantsområdet. Kunderne er en række større banker og andre finansielle firmaer, som ejer Bankdata og driver en stor del af deres it-systemer hos Bankdata. Udviklingen sker på mainframe, men også på brugergrænseflader i Websphere portalen.
Mange nye medarbejdere får Bankdatas tre måneders introduktionsforløb til den finansielle branche og udvikling på mainframe. Og de ansætter gerne uddannede og oplærer dem.
www.bankdata.dk
