Bankerne tvunget til selv at tage hånd om oplæring i Cobol og mainframes

Mens stort set alle banker kører mainframes, uddanner studierne ingen unge med viden om systemerne. Derfor er eksempelvis BEC tvunget til selv at oplære nyuddannede i cobol og mainframens velsignelser.

Et hold på 12 nyuddannede kandidater og bachelorer inden for it er netop begyndt på et nyt forløb hos it-firmaet BEC, som skal gøre dem klar til at arbejde med Cobol og mainframes. Det kan lyde gammeldags, men det er nødvendigt, for ifølge BEC vil mainframen spille en central rolle mange år ud i fremtiden.

»Vi kører nogle meget centrale systemer for bankerne. Mainframen giver os sikker og stabil drift, men nogle af vores udviklere er ved at være oppe i årene, så vi vil udvise rettidig omhu og få nogle unge og friske ind,« forklarer direktør med ansvar for drift og arkitektur, Kristian Hjort-Madsen, til Version2.

Mainframen blev introduceret i 1960'erne og blev i 1970'erne og 1980'erne den dominerende platform til afvikling af de store virksomheders applikationer, og hos mange banker kører de samme applikationer, hvor skelettet blev kodet i Cobol i 1970'erne, stadig på de nyeste mainframes. I slutningen af 1990'erne og i begyndelsen af det 21. århundrede fik mainframen konkurrence fra billige klynger af servere baseret på Linux, Windows og x86-processorer, men især i finansverdenen er der ikke udsigt til, at mainframen forsvinder lige foreløbig. Ifølge BEC kører 92 af verdens 100 største banker i dag mainframe og 80 procent af erhvervslivets data globalt ligger på også på mainframes.

»Det er vigtigt, at det bare virker, når vi er i finansverden, og at vi kan designe applikationer til at skalere og være robuste fra starten, og der er mainframen en fantastisk platform,« siger Kristian Hjort-Madsen.

I dag er mainframen sjældent førstevalg, når man skal opbygge en it-infrastruktur, men for BEC kan det ikke betale sig at gå væk fra mainframen.

»Mainframen er stadig helt central i bunden af vores systemportefølje. For 10 år siden, før jeg selv havde stiftet bekendtskab med mainframen, ville jeg også have været meget skeptisk og tænkt på et migreringsprojekt, men når vi kigger nærmere på det, så er det svært at lave en business case, hvor det kan betale sig at flytte. Det gælder ikke kun økonomisk, men også i relation til de teknologiske og forretningsmæssige gevinster,« siger Kristian Hjort-Madsen.

BEC's uddannelsesforløb er ikke kun rettet mod at lave rene mainframe-specialister. De får undervisning i Cobol og mainframen og får praktisk erfaring gennem sidemandsoplæring, men de skal også arbejde med nye teknologier.

»De sidder i teams, hvor de arbejder på tværs og skal arbejde sammen med dem, der sidder med andre teknologier, så de skal ikke bare på skolebænken eller vedligeholde et stystem, men for eksempel være med til nyudvikling af mobilbank,« forklarer Kristian Hjort-Madsen.

Ifølge BEC har det ikke været svært at tiltrække nyuddannede til mainframe-forløbet, men uddannelsen er blevet etableret på grund af et behov, som Kristian Hjort gerne så, at uddannelsesstederne hjalp med at opfylde.

»Vi gør det her, fordi universiteterne har forpasset muligheden. Der er for lidt fokus på udvikling af stabile systemer og i stedet meget om nye teknologier. Men uddannelse i stabile teknologier, der kan håndtere enorme mængder data er der altså fortsat et behov for, så det er vigtigt for universiteterne at have fokus på det,« siger Kristian Hjort-Madsen.

BEC deltager sammen med en række af de øvrige danske it-firmaer, som arbejder med mainframes, i et panel, der skal se på, hvordan branchen kan arbejde med uddannelse og rekruttering for at sikre kvalificerede medarbejdere inden for mainframe-området.

BEC og andre skal dog ikke regne med at se mainframen som en del af pensum inden for en overskuelig fremtid.

»Mainframes bliver næppe nogensinde igen en del af det obligatoriske pensum, men der er intet til hindring for, at man læser det frivilligt,« siger studieleder Kasper Østerbye fra ITU til Version2.

Han henviser til, at de studerende på gruppebasis har mulighed for at fordybe sig i valgfrie emner, hvor Cobol og mainframes kunne være en mulighed. Han mener dog ikke, at det er universitetets rolle at uddanne ud fra branchens efterspørgsel.

»På universitetet skal vi ikke uddanne i bestemte færdigheder, men i videnskab med tilknytning til forskning, og der har mainframen det svært, for der er ikke så mange, der har mainframe og Cobol på forskningsagendaen,« siger Kasper Østerbye.

Han påpeger, at arbejdsgiverne altid må forvente at påtage sig et vist ansvar for videreuddannelse af nyansatte.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (29)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Simon Mikkelsen

Går man ind på BECs hjemmeside står der: "Der er pt ingen ledige stillinger." Så har jo fået de folk de skal have. Hvis de ikke engang selv kan tilbyde jobs, hvorfor skulle man så lægge sine kræfter i deres behov?

Jeg synes i øvrigt, at der er langt mellem jobopslag hvor der står Cobol og mainframe, mens der er masser som går på Java og C#.

Tidligere har jeg skrevet, at når virksomheder er ude at sige at de mangler noget, så skal jeg nok efteruddanne mig til deres behov, hvis jeg kan få arbejde mere end et par steder i landet. Og lønnen må i øvrigt gerne matche den påståede efterspørgsel.

  • 5
  • 2
Jens Rasmussen

»Vi gør det her, fordi universiteterne har forpasset muligheden.«

Er det ikke bankerne, der har forpasset muligheden for at skifte platform?

Desuden er det spoergsmaalet om det ikke er en career-killer at blive COBOL-programmoer, jeg har ingen ide om hvor laenge der er arbejde i det, men efter 10 aar, saa er det nok ikke nemt at faa arbejde med anden teknologi (naar man ved hvordan HR-folk krydser akronymer af paa CV'er).

  • 9
  • 1
Torben Mogensen Blogger

Der bliver brugt hundredvis af forskellige programmeringssprog og snesevis af forskellige platforme rundt omkring i virksomhederne, så det er urimeligt at forvente, at nyuddannede har lært netop det system og sprog, som en specifik virksomhed (selv en større af slagsen) har brug for her og nu. Det er mere normen end undtagelsen, at en nyansat skal gennem et uddannelsesforløb om de specifikke værktøjer og systemer, virksomheden bruger.

  • 19
  • 0
Troels Henriksen

80 procent af erhvervslivets data globalt ligger på også på mainframes

Det finder jeg enormt usandsynligt. Så mange mainframes findes der slet ikke.

Endvidere, så er det virkelig svært at tilegne sig evner omkring teknologier, som ikke er praktisk tilgængelige med mindre man arbejder i en større organisation.

  • 4
  • 5
David Konrad

Ifb. Y2K i 99 besøgte jeg det man vist roligt kan kalde et stort dansk forsikringsselskab. De var naturligvis opmærksomme på Y2K-problematikken (læs hysteriet) men stolede slet og ret på at de gamle COBOL-programmer ville klare skærene. Deres største problem var ikke Y2K, men at der kørte +20 år gamle programmer som ingen rigtig anede hvordan virkede, og rette i dem ville være selvmord. I stedet fik man det gamle programmel integreret med (dengang) moderne IT gennem screenscraping, dvs man parsede simpelthen mainframe-skærmbilleder frem og tilbage.

Nu skriver vi så 2014. Det er 15 år siden man brugte +20 år gammel programmel, og mon ikke de samme programmer er i funktion den dag i dag? Det er herligt når noget rammer plet, mainframen er simpelthen for god til at blive skrottet.

  • 7
  • 1
Frank Allan Rasmussen

Det er en påstand der dukker på forskellge steder og i forskellige udgaver: 80% af corporate (Fortune 500) data ligger på mainframe eller 80% af corporate (Fortune 500) data stammer fra mainframe.

Og en rimeligt svær påstand at kvalificere og verificere.

Men med hensyn til antallet af mainframe - det er jo ikke specielt vigtigt. Mainframes er også blevet kraftigere og med den struktur der er på softwarepriserne giver det mening at samle forskellige firmaers mainframes hos FM-firmaer. Og ingen skandinaviske firmaer har en fuld udbygget mainframeinstalltion - den største muligt mainframeinstallation er simpelthen alt alt alt for stor.....

  • 5
  • 2
Tommy Sadiq Hinrichsen

Da jeg studerede på DTU var der valgfag i mainframe programmering sponsoreret af IBM så det passer simpelthen ikke. Interessen fra de studerendes side var dog utroligt lav, tror desværre det er ret svært at sælge mainframe til nutidens studerende.

  • 6
  • 0
Frank Allan Rasmussen

Problemet er ikke adgangen til en emulator, IBM har selv en (RDzUT).
Det er adgangen til software der er et problem.

IBM tillader ikke at man kører z/OS på andet end IBM hardware og IBM emulering.

Og emuleringen kun som udvikling - ikke drift.

Det ville være enormt hjælpsomt for interessen for mainframes hvis f.eks. seneste usupporterede version af z/OS kunne licenseres af private.

  • 4
  • 0
Jens Jensen

Hvis skolerne skulle tilbyde "mainframe undervisning" hvad skulle den så gå ud på?
Et kursus i mainframeudvikling ude i en virksomhed består rundt regnet af:
1% at lære sproget COBOL,
99% at lære virksomhedens valg af værktøjer at kende og bruge dem på den virksomhedsspecifikke måde i det virksomhedsspecifikke framework som er udviklet gennem mange mange år.

Et kursus i mainframe vil aldrig kunne blive specielt specifikt, og vil alligevel aldrig kunne forberede eleverne i nogen fornuftig grad til at kunne løse de opgaver de vil få i en virksomhed som benytter mainframes.

At skolerne ikke underviser i mainframes er kort sagt et problem som kun eksisterer blandt divs. direktører og ledere, som ikke aner hvad de snakker om.

  • 9
  • 0
Frank Allan Rasmussen

IBM RDzUT eller Hercules kan køres på en hvilken som helst 64 bit x86 Linux. Hercules findes også i en version der køre på Windows eller OS X - selv på Raspberry Pi er Hercules blevet startet op.

IBM har også deres ADCD udviklings DVD'ere (vist nok 6 stk. pr. version) som hvis du har licens til RDzUT vist koster omkring $900-1000 pr. år. På en ADCD er en current verison z/OS og middelware (CICS, DB2, WebSphere og IMS). Der er desuden udviklingsværktøjer (Compilere, debuggere og div. værktøjer).

RDzUT er bare DYR!!! Og du har ikke behov for den allersidste nye version for at kunne snuse til teknologien og værktøjerne.

Så hvis IBM kunne gøre seneste usupportede version (iøjeblikket z/OS v1.11 der blev tilgængelig i 09.2019 og om mindre om en måned v1.12 fra 09.2010) kunne interesserede nå langt.

  • 0
  • 0
Ole Kofoed Hansen

Jeg har været ansat hos Bankdata, der ligesom BEC er en datacentral for en flok danske banker.

Da jeg startede, kom jeg først igennem et forløb, de kaldte IT-College, hvor vi blev undervist i alt muligt om organisationen, forretningsgange, mainframes og COBOL. Selve det at lære COBOL var en meget lille del. Størstedelen af programmeringsundervisningen gik på at anvende Bankdatas egenudviklede systemer til redigering, versionsstyring og igangsætning.

På en skole, som skal uddanne folk til alle mulige virksomheder, kan jeg ikke se, at det vil give mening at undervise i COBOL, for det er trods alt et mindretal af erhvervslivet, der benytter lige det sprog. Derudover er COBOL et ret let sprog at lære, hvis man i forvejen kan et andet sprog, så det kan jeg ikke se skulle være en urimeligt stor byrde for de virksomheder, der kører på mainframes.

  • 8
  • 0
Lars F. Jensen

Hvis man søger efter Cobol programmører til Mainframe, så er der da mange derude, der er meget kvalificerede, hvis man tilbyder de rigtige ansættelsesforhold og en rimelig jobsikkerhed.

Jeg kender personligt adskillige, som pt. anvender andre sprog på andre platforme, men som har en dyb viden om både Cobol, Mainframe og de systemer man skal kode under og som afvikler programmerne i produktion.

Det er i øvrigt noget rod, at firmaerne vil have skolerne skal uddanne i konkrete produkter og her og nu mangler.

Uddannelsen skal rettes mod, at den enkelte kan følge udviklingen og være produktiv hele livet. Det er de abstrakte evner der holder, den konkrete viden, bliver let og hurtigt forældet - åbenbart bortset fra Cobol og Mainframe.

Lars :)

  • 3
  • 0
Ditlev Petersen

Jeg har lært COBOL for mange år siden. Det har forhåbentligt gennemgået en udvikling siden, for det sprog var godt nok meget brugt, men en gru at arbejde med. Hvis en programmør in spe spørger sig for om sprog, og får fat i en, der kan COBOL, vil han så få rosende omtale af sproget at høre - eller vil han se nervøse trækninger? Man skal godt nok være noget sulten, før man vælger COBOL i dag som programmør. Af en eller anden grund minder det om at ville danse ballet i waders. Det KAN lade sig gøre, men kræver en del af udøveren.

Jeg håber, at COBOL lever længe. For på et tidspunkt ER jeg meget sulten.

  • 1
  • 0
Nikolaj Koch

Det er da primært leverandørens (IBM's) skyld. Det er deres ansvar at de tilbyder en platform der er så aparte at ingen kender den. Den er så dyr at den er udenfor almindelige menneskers rækkevidde. Der er ikke mulighed for at hente en emulator og tilhørende operativsystem til brug på en almindelig maskine - faktisk har jeg for nyligt hør det er kommet, i form af en USB-stick med en mainframe simulator, men den skulle være helt ufattelig dyr, og således kun henvende sig til folk der i forvejen arbejdet med det.

Man kan spekulere i hvorfor mon en sådan simulator ikke findes - er det fordi den ville udstille at mainframe-platformen hardware mæssigt ikke er de andre platforme overlegne, og uden problemer kan afvikles i en emulator på commodity hardware? At den legendariske fordel mainframe skulle have på "I/O" måske mere har basis i sammenligner med PC XT i 80'erne end med moderne maskiner - navnligt når det opgøres i kr.? Hvorfor er det lige man ikke kan finde en apples-to-apples moderne sammenligning af mainframe vs PC, og at det iøvrigt står i licensbetingelserne at man ikke må køre benchmarks (har jeg i hvert fald fået fortalt).

Det kan aldrig blive universiteternes ansvar, at de ikke har uddannet folk i en obskur platform som kun en absolut lille procentdel (eller er det promilledel?) af job henvender sig til!

  • 3
  • 0
Ditlev Petersen

Nu ville det være endnu værre, hvis IBM ikke solgte mainframes. Sådan lige pludselig.

Og så er en mainframe altså heller ikke mere mystisk og aparte. COBOL er en spøjs størrelse, men der var jo ikke SÅ forfærdeligt mange andre sprog at bygge videre på erfaringerne fra. FORTRAN FlowMatic, MathMatic, Plankalkül og et par til. Det er nemmere at være smart, når andre har "kvajet sig" først.

  • 1
  • 1
Nikolaj Koch

Ditlev, at COBOL var et tidligt sprog og derfor blev dårligt, er jo ingen undskyldning for at fortsætte med at bruge det 50 år+ efter. Ingen kan påstå at COBOL er et tilnærmelsesvist ideelt sprog til det det bliver anvendt til. Det var iøvrigt også lavet mest til at kunne lave små udregninger for ikke-programmører. Ikke "hårde" backendsystemet, som det vist primært bruges til.

Forstår ikke kommentaren med, "nu ville det være endnu værre, hvis IBM ikke solgte mainframes". Det ville sikkert også skabe problemer hvis Intel holdt op med at sælge x86 CPU'er. Måske ikke helt så store, da der trods alt er konkurrenter i markedet. Det er nemlig et andet af mainframens store problemer.

Og jo, mainframens tilgang til filer, datasæt m.m. er aparte. For ikke at tale om forbrugsafregning.

  • 1
  • 1
Bjarne Henriksen

Ingen kan påstå at COBOL er et tilnærmelsesvist ideelt sprog til det det bliver anvendt til. Det var iøvrigt også lavet mest til at kunne lave små udregninger for ikke-programmører. Ikke "hårde" backendsystemet, som det vist primært bruges til.

Jeg tror netop det er godt til det, det bruges til. Du kan lave både små og store udregninger og manipulere strings/tekst. Det er vel typisk det "hårde" backend systemer laver for f.eks. banker.
Og når du laver beregninger har du ikke samme problemer med nøjagtighed som f.eks. java har med double.

Lige som gamle folk ikke bør være bange for ny teknologi, bør yngre folk heller ikke være bange for gammel teknologi. Uden iøvrigt at kende debattørenes alder:)

  • 2
  • 0
Bjarne Henriksen

Det er korrekt, der er bigdecimal, men beregninger her er mere besværlige synes jeg da du skal bruge methodekald for hver enkelt beregning.

Java:
Bigdecimal tal1;
Bigdecimal tal2 = new Bigdeciaml(4.2);
Bigdecimal tal3 = new BigDecimal(2.1);
tal1 = tal2.multiply(tal3);

Cobol:
tal1 pic 99v99;
tal2 pic 99v9 = 4,2;
tal3 pic 99v9 = 2,1;

tal1 = tal2 * tal3;

Undskyld hvis syntaks ikke er 100 % korrekt.
Forestil dig så at lave f.eks. renters rente

Jeg vil lige sige der sandelilg også er ulemper ved cobol. Hvis du f.eks. regner ud over det definerede har du problemer ala buffer overflow. Så alt er ikke lysegrønt.

  • 2
  • 0
Jens Jensen

COBOL er perfekt til det det bruges til.
Man skal her huske at sprog og maskine i dette tilfælde går op i en højere enhed. Da man begyndte at bruge IT i bankerne var filer blot organiseret som "en masse bytes". COBOL er bygget til nemt at oversætte sådanne filer til fornuftige data. Det er simpelthen en del af sproget at definere strukturen.
Ligeledes understøtter COBOLs talsystem en del snedige måder at definere helt almindelige decimaltal på. Her kan Java og andre sprog simpelthen ikke følge med. COBOL gør det legende let at definere gigantiske talvariabler med fast defineret komma, og dermed sikre en konsistens som man ikke kan opnå med nogen af f.eks. JAVAs indbyggede datatyper.

Banker behandler bunker af simple taldata, og dertil er mainframes og COBOL uden tvivl det mest effektive og bedste valg. Jeg har kodet utallige sprog og aldrig set noget spille så fantastisk sammen som en mainframe/COBOL og opgaven de to løser i fællesskab.
Det er en smuk sammensmeltning af lavniveau data som bytes, som behandles af et højniveau-sprog.
Mainframen tilbyder samtidig en fantastisk sikkerhed i at "hele lortet er bare på en maskine" så der er ikke noget rod med firewalls mellem systemer, kryptering og andet ævl.
Alle programmerne kører på samme ur, og hele molevitten kan styres med hårfin præcision så ingen systemer kører før andre systemer er klar, osv. osv.

MEN... samtidig er det også denne kombination som låser begge fast i et evigt problem i at det er umuligt at komme væk fra denne platform.

Mainframens operativsystem ligner et oldtidsfund. Værktøjerne er ikke designet med nogen fælles grænseflade hvilket gør det unødigt svært at navigere rundt i dem.
Og COBOL er håbløst når det kommer til mere moderne datatyper som f.eks. XML og andre data hvor man ikke kender størrelsen på forhånd.

Så man ser alderen udadtil, men inden i kernen af bankforetningen er valget af system og sprog stadig det helt rigtige den dag i dag.

  • 0
  • 0
Nikolaj Brinch Jørgensen
  • 1
  • 0
Jan Michael Bengtsen

... men det sker langsomt. Når DB2 migreres f.eks. til MS SQL Server eller Oracle åbner det mulighed for at migrere kode og det er ved at ske. Jeg har selv deltaget i et projekt hos en bankcentral som lykkedes med at flytte DB2 siden af bankernes bogføringssystem og en pæn del kode til MS SQL Server og .Net så det kan lade sig gøre. Dette vil i det lange løb afskaffe behovet for Cobol og PL/I men det er en sej proces.

  • 0
  • 0
Morten Bøgh

COBOL af i dag har indbygget 'native' (dvs. i selve sproget) håndtering af XML. Hvis du fx. har en XML struktur i tegnsæt UTF-8 og uden fast længde (fx fra et UNIX-directory) kan den indlæses og parses i mainframe COBOL - uden at forlade COBOL-syntaksen. Så på det punkt er dit nydelige forsvar for mainframe og COBOL ikke korrekt. COBOL kan det meste - man skal ud i ting som XML-FO-parsing til HTML før COBOL melder pas.

  • 0
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize