Mainframen har for travlt til at dø

Leverandør af mainframe-teknologi ryddede selv teknisk gæld af vejen og hjælper nu andre med at modernisere mainframe-systemer. Læs om erfaringerne og gode råd.

Når gamle systemer bliver nævnt i Version2's artikelserie om modernisering eller nyudvikling, nævnes mainframes ofte som eksempel på gammel teknologi.

Eksempelvis da chefarkitekt Peter Greifenstein fra Rigspolitiet fortalte om hvordan politiet forholder sig til modernisering kontra nyudvikling blandt andet baseret på erfaringerne fra Polsas/Polsag

»Det kan være gammel teknologi, der gør det svært at få det vedligeholdt om 20 år, eksempelvis mainframe-teknologi,« sagde Peter Greifenstein blandt andet.

Mainframen ved ikke den er død

Det fik en del Version2-læsere til tasterne.

Eksempelvis Morten Bøgh, der skriver:

»Vi mangler en god forklaring på at ’Mainframeteknologi’ næppe kan vedligeholdes om 20 år … Er det ’de unge mennesker’ som i dag er lidt kræsne med hvad de vil beskæftige sig med; er de om 20 år blevet helt umulige? Er det den kritiske masse af mainframes, som om 20 år har nået et lavpunkt hvor viden om systemet vil være ved at forsvinde?«

Morten Bøgh stiller også spørgsmålstegn ved præmissen om mainframe-teknologi; den er gammel:

»Det andet forklaringsproblem er den rutinemæssige påstand om at mainframe er identisk med ’gammel teknologi’. Selve hardwaren i en mainframe er typisk ret ny.«

Eller som Version2-læseren, Ditlev Petersen, elegant og spydigt opsummerer:

»Mainframes døde også i 90'erne, de opdagede det bare ikke. De dør igen i dag. Og summer stadig.«

En agil mainframe-udvikling

Forsvaret for de trofaste mainframes, der eksempelvis håndterer størstedelen af den finansielle sektors transaktioner, er noget som Chris O'Malley, CEO for Compuware, tilslutter sig.

Det er måske ikke overraskende, da Compuware lever af at sælge software til mainframe-installationer, men han har en række interessante betragtninger som baserer sig på Compuwares egen modernisering af interne systemer, bekæmpelse af teknisk gæld, og hvordan man kan gøre ‘de helt umulige’ millennials interesseret i mainframe-udvikling.

»Da jeg startede hos Compuware for 5 år siden, havde vi en projektmodel baseret på vandfaldsmodellen, så vi indførte agil udvikling og en devops-filosofi for at få en mere agil organisation,« fortæller Chris O'Malley under et kort visit i Danmark.

Den ændring koblet med anvendelse af et udviklingsmiljø baseret på Eclipse har gjort Compuware mere interessant som arbejdssted for unge udviklere – på trods af at det handler om mainframesoftware.

»Hvis du ikke ændrer fra vandfaldsmodellen og ikke giver dem devops-tools, men anvender et udviklingsmiljø som ligner noget NASA brugte i 1965, så bliver det svært at tiltrække dem. Hvis du har udviklingsværktøjer baseret på Eclipse, så giver du dem et udviklingsmiljø som millennials ønsker,« siger Chris O'Malley med henvisning til Compuwares Eclipse-baserede Topaz-udviklingsmiljø.

»Hvis du ser over deres skulder, ved du ikke, at de arbejder på en mainframe,« siger Chris O'Malley, der oplyser, at 40% af udviklerne i Compuware er i 20'erne.

50% til bekæmpelse af teknisk gæld

Inden omstillingen til en agil udviklingsorganisation var der dog et efterslæb i form af en massiv teknisk gæld i Compuwares kildekode, der skulle nedbringes.

»I Compuware var der så meget teknisk gæld at vi afsatte mere end 50% af tiden til at rydde op i et kvartal,« fortæller Chris O'Malley.

Han skønner at omkring 20% af koden affødte 90% af problemerne, hvilket selvfølgelig rejser spørgsmålet om, hvordan man identificerer de vigtige 20% af koden.

Identificér flaskehalsene

Compuware har nylig annonceret Machine Learning til zAdviser-værktøjet, så værktøjet kan identificere kodeområder, der er problematiske, men hvis man introducerer agile teknikker som Continuous Improvement med god feedback, så kommer man også langt.

»‘Scrum masters’ og ‘product owners’ bliver hurtigt opmærksomme på, hvilke dele af koden, der er problematiske og giver problemer,« siger Chris O'Malley, der også fremhæver den agile metode som en måde til at få involveret ledelsen.

»Det kan være svært for dem at forstå, hvorfor der skal bruges tid på gammel kode. Den agile metode er med til at gøre ledelsen mere opmærksom på det, når de er involverede som product owners og dag efter dag ser problemerne,« siger han, selvom han erkender, at det kan være svært at få topledelsen involveret hos kunderne.

»Det er ikke altid at topledelsen som CEO og CFO forstår, at virksomheden bør følge agile metoder og devops-filosofien,« siger Chris O'Malley, der dog har et godt råd.

Fokusér på nye features

Hvis man betragter mainframe-systemerne som vedligehold og har en backlog fyldt med udbedring af defekter, så er det svært at få ledelsens interesse. Hvis man derimod taler om nye features, så er ledelsen meget mere fokuseret på at skabe fremdrift – og man vil indirekte komme af med den tekniske gæld.

»Teknisk gæld forhindrer et godt flow. Hvis der er fokus på nye features, så vil der også automatisk komme fokus på at sikre fremdrift i udviklingen, så features kan blive udviklet hurtigere. Derfor bliver ledelsen engageret i at nedbringe den tekniske gæld,« lyder rådet fra Chris O'Malley.

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

Min erfaring siger mig, at når noget ikke bliver nævnt så kan det være på grund at af, at det ikke er attraktivt at nævne.
Den økonomisk side bliver ikke nævnt, så hvad mon prisen på mips på en MF er kontra prisen på x86 platformen og hvad er lønomkostningerne for MF udviklere kontra udviklere på x86 platformen?

Michael Park

Har arbejdet i miljøet. Den eneste grund til at mainframes ikke kan dø, er det ekstreme politiske pres fra inkompetente, omskolede udviklere fra 1970’erne som stadig ikke ved hvad internettet er.

Hvis man tvang mainframes væk fra banker og forsikringsselskaber ville man kunne spare 90% af udviklingsbudgettet, nemt. Den rabat burde ryge direkte til forbrugerne.

Det mainframe miljø jeg blev kastet ud i før jeg løb skrigende væk havde blandt andet følgende flotte features:

Intet brugbart standardbibliotek til Cobol og PL/1 (tænk simple ting som strengformatering, websockets, json parsing, bufferedreader, alt hvad alle moderne sprog har)

Ingen deployment pipelines til at køre integration- og unit tests

Faktisk ingen testframeworks til automatiserede test overhovedet, alle tests blev lavet af mennesker kl 6 om morgen efter release til prod.

Elendig performance sammenlignet med ethvert moderne sprog der udførte en normal, standard opgave (dvs ikke benchmark af math.pow, som cobol eller PL/1 i øvrigt heller ikke har)

Ingen moderne versionskontol af koden, til pull requests, code review, dokumentation etc.

Ingen moderne IDE (glem det, Eclipse-elskere, 10 GB ram for at åbne en fil er ikke moderne)

Ingen organisering af de faktiske filer og/eller koden i et program. Alle programmer var begrænset til én fil med et navn på maks 8 tegn, caps selvfølgelig. Fx “ZBTS1000.CBL” - så regn selv ud hvad det gør.

Bemærk at alt dette er den dag i dag anset for helt normale vilkår af en udvikler af mainframes. Fordi ingen af dem har prøvet andet, og har ingen interesse i at gøre det.

Vi har fået en opgave om at returnere et brugernavn Capitalized i stedet for ALL CAPS. Ok, vi estimeret cirka en måned, fuldtid, til en senior softwareudvikler der har anciennitet nok til 80.000 om måneden i løn. Han skal lige kode en all caps funktion og bruge 2 uger på at teste den manuelt og endnu 2 uger på at teste det samme i produktion. (DET HER ER SERIØST SKET)

Overvej det en tilfældig dag du koder HelloWorld i Rust eller Go eller Scala eller noget andet, der ikke er fra 1950.

Du starter med at hente en runtime. Nope, kan man ikke på en mainframe.

Du tjekker noget ud fra Git. Nope, bruger vi ikke. Hvad er Git?

Du kalder filen helloworld.rs og lægger den i roden af mappen. Nix, vi har ikke mapper eller filhåndtering. Der er kun en Root. Læg filen dér og send en mail til dine kollegaer om hvad filen hedder, så kan de søge i Outlook 3 år senere hvis de har glemt det.

Du trykker lige compile.. nå nej, mainframe bruger nogle load jobs, send programmet til load og refresh en eller anden side med sort baggrund og grøn skrift og se om programmet compilede. Indbyggede compiler i IDE’en? Ej det kan man ikke.

Du vil gerne ind i debug mode og trykke igennem programmet. Ok, du skal lige sende programmet til load, gå ind i et program i en 3270 terminal for at slå et debug flag til, skriv de 8 tegn programmet hedder og vent venligst. Glemte du at sætte det rigtige breakpoint? Surt, start forfra.

Du vil gerne deploye det? Ok, ring til IBM.

Du vil gerne forstå hvorfor din COBOL kode ikke virker? Held og lykke med at finde noget på StackOverflow. Får du mærkelige systemfejl fra zOS når du compiler? Ja Google ved det nok heller ikke.

Velkommen til bank- og forsikringsverden anno 2019. Er I stadig glade for at flyve?

Bh
MP

Christian Jørgensen

Først, det er vist godt, at du er kommet væk fra dette miljø - det passede helt åbenlyst ikke til dig!

Dernæst, jeg ser to problemer i din beskrivelse:

1) Den mainframe installation har en teknisk gæld - præcist som bekrevet i artiklen. Og organisationen har vist også en gæld, siden det er en senior programmør, som skal lave en Capitalize-funktion - noget man typisk ville sætte en junior-programmør til, da det ikke kræver forretningskendskab.

Deployment via IBM? Driften er outsourcet til en ekstern leverandør, som er ansvarlig for deployment - en meget normal situation. Vil du hellere køre DevOps? Tal med forretningen, det er dens beslutning.

COBOL kode og ingen hjælp fra Google eller StackOverflow? Synd, at du ikke blot kan klikke dig til et svar - men svaret findes skam, du skal blot søge andre steder, som f.eks. erfarne kollegaer og mainframe brugergrupper.

2) Din IT verden virker begrænset til hvad der sker i "normale" miljøer, som kan afvikles på din egen PC, og du udviser antipati mod andet.

"Eclipse-elskere" - tja, det siger vist alt. Du er ikke glad for Eclipse, og fred være med det, vi har alle vores præferencer. Men vis dog lidt respekt for hvad andre foretrækker - så får du mere respekt den anden vej. Btw. en kørende Eclipse med plugins hos mig fylder 200 MB - dine 10 GB ved jeg ikke hvor kommer fra.

Sort/grønt skærmbillede - er det et problem? Bruger du aldrig DOS eller PowerShell prompten i Windows? Ja, det kræver at du ved hvad kommanderne hedder, men når du har lært det, kan det være et betydelig mere effektivt miljø end et grafisk miljø.

Du kan ikke kompilere COBOL på din PC? Nej, og selvom du kunne, ville du sandsynligvis ikke kunne afvikle COBOL programmet på mainframen, da din PC kører på en anden processor type end mainframe (x86 vs. f.eks. Power). Det kommer ofte som et chok for unge IT mennesker, at der findes andet end x86 instruktions sættet, men verden er heldigvis mere og andet end Intel(-lignende) processorer - andre CPU typer kan være mere effektive end Intels.

Jeg ønsker dig helg og lykke i din videre karriere. Når du får lidt mere erfaring, vil du opdage, at verden ikke er så hvid og sort, som du ser den lige nu. Glæd dig - det bliver spændende! :-)

Hilsen
Christian

PS. Jeg har selv aldrig haft lejlighed til at arbejde på mainframe, men har brugt min karriere i laget under: IBM i (og dens forgængere). Det føltes også som en begrænsning dengang, men efterhånden opdagede jeg styrkerne ved dette system og fandt glæden ved platformen. Og ja, jeg bevæger mig også hjemmevant på andre platforme som Windows og Linux, IBM Power og Raspberry Pi. Prøv det - verden bliver meget større...

Michael Park

Jeg vil gerne sige tak for din kommentar, da den præcis belyser min pointe, til UG med kryds og slange.

(...) men svaret findes skam, du skal blot søge andre steder, som f.eks. erfarne kollegaer og mainframe brugergrupper.

Velkommen til 1990.

Bruger du aldrig DOS eller PowerShell prompten i Windows?

Nej, jeg bruger den ondefløjtemig ikke DOS nogensinde. Jeg bruger gerne en bash shell der har været cirka det samme siden 1980, den har tab-completion og indbygget shell scripting. Hvordan er det lige man gør det på 3270?

Du kan ikke kompilere COBOL på din PC? Nej, og selvom du kunne, ville du sandsynligvis ikke kunne afvikle COBOL programmet på mainframen, da din PC kører på en anden processor type end mainframe (x86 vs. f.eks. Power).

Forskellige arkitekturer og deres mangel på kompatibilitet mellem hinanden har ikke været noget problem siden midt 2000, slet ikke efter Docker blev mainstream. Det er normalt ret fedt, i en udviklingsprocess, at man kan afvikle det program man sidder og koder, på den maskine man udvikler på.

Nis Schmidt

Gratis uddannelse og dobbelt løn. Hvor længe er der mon råd til det?

Hvis man som tidligere chefkonsulent hos Digital Equipment Corporation sammenligner specs på x86 og x64 med z13 og z14, er det tydeligt, at IBM har flere penge end Intel; med al respekt. Produktpriserne er nok også derefter.

Agil udvikling, vor herre bevar os, det er naturligvis "test drevet udvikling", der skal satses på, og løkkesegmentering med varibel bundt-størrelse, Performance Aware Programming. (Nej det handler ikke om at partitionering af den tidligere statsminister.)

De sidste 27 år har jeg ikke haft arbejde i Danmark, bortset fra hos DTU til underbetaling;( , da min pensionsopsparing var brugt. Jeg har aldrig været god at rage til mig, måske derfor havde jeg så meget ud af at vokse op siden 1983 i DECs kundeservice og især deres tekniske hovedkvarter i Frankrig, hvor jeg sad de sidste 5 år.

Min læring er at danskerne er onde og ignorante og generelt kun anerkender kvaliten af uddannelser erhvervet i Danmark - angiveligt.
DTU var i 12 år et godt sted, at være, men så lokkede min chef mig med på en udstationering i Østrig. Der blev jeg indkvarteret sammen 3 unger på et 2-sengs værelse.

Jeg nåede at sove en time, da jeg kom op på værelset, efter at være blevet passet op på vej gennem baren (som lå mellem ølstue, hvor vi studerende morede os med 2 pints billigt men godt Østrigsk øl), af de to danske lærere, som ville helle shot på mig??? Ungerne lå i baghold og ventede på mig, så ved et-halv-to tiden vågnede jeg op ude på gangen ved at 80 unge stod og skreg min ind i hovedet; så jeg bad natportien om at tilkalde politiet, men de gjorde ikke noget. Imponerendem, at havde kunnet vække mig.

Da jeg arbejdede for den ene af vores lærere, ville det have haft fatale konsekvenser for min beskæftigelse, at klage over. Nu hvor jeg kender konsekvenserne for mit helbred: jeg har ikke været udenfor en dør i 3 år, fordi jeg simpelthen ikke kan gå - undtagen ved rullator.

Havde jeg kendt til indkvarteringen havde jeg ALDRIG ladet mig lokke med på den tur. For mange 4-stjernede overnatninger;) når jeg var on-site i Europa Digital.

Michael Park

Og organisationen har vist også en gæld, siden det er en senior programmør, som skal lave en Capitalize-funktion - noget man typisk ville sætte en junior-programmør til, da det ikke kræver forretningskendskab.

Hvorfor skal man overhovedet sætte nogen til at koden en capitalize-funktion?!!?

Bjarne Nielsen

Hvorfor skal man overhovedet sætte nogen til at koden en capitalize-funktion?!!?

Nej, eller en "left-pad" funktion - hvorfor bruger man ikke bare en fra nettet: https://arstechnica.com/information-technology/2016/03/rage-quit-coder-u...

Der findes helt sikkert den slags miljøer, som du beskriver derude; dem har jeg heldigvis formået at undgå. Men du genereliserer ud fra et (få?) dårlige eksempler. Der findes dårlige eksempler overalt.

Så jeg anerkender til fulde validiteten af dine oplevelser, men jeg har på den anden side set, hvad man kan med mainframes, hvis man ved, hvad man gør, og jeg er stadig imponeret.

Christian Nobel

strengformatering

Nåeh, som i C - host, host.

websockets

Sikkerhed er ret så vigtig i mainframeverdenen, så lad lige teknologien blive moden og sikker.

json parsing

Og for ti år siden var det XML der var det helt hotte, så hvad mon der skal være hot om ti år.

Personligt foretrækker jeg XML's meget stingente syntaks, end json's javabæ' lignende struktur.

Peter Nørregaard Blogger

Vigtig diskussion, denne her.

Nogle af vores kunder sidder i situationen når de ringer til os. Vi er nødt til at være præcise i analysen når vi overvejer alternativerne, for hvad skyldes at virksomheden sidder i en ny situation, hvad skyldes hmainframen i sig selv, hvad skyldes udviklingssprog og miljøer og hvad skyldes kompetencerne hos udviklerne?
Her er et par hurtige pointer:

1) Den tekniske gæld er typisk høj i mainframesystemer. Det skyldes dog ikke så meget selve mainframen i sig selv, men i højere grad, at koden simpelthen er gammel. Vi har kunder med mainframes, hvor hvert modul sådan set er kodet nogenlunde pænt, men hvor modulerne kalder hinanden og tilgår data på kryds og tværs. Resultatet er anti-mønsteret ”a big ball of mud” som selv de skarpeste udviklere kæmper forgæves imod når det først er kommet dertil.

2) Gammel kode er ikke nødvendigvis et problem i sig selv. Gammel kode skal dog refaktoreres i takt med ændringer i kravene til løsningen – en disciplin som kræver både skarpe udviklere og gode værktøjer. Respekt for de gamle erfarne mainframe-udviklere men hvis de ikke har den teoretiske ballast som fx datalog og/eller er blevet efteruddannet løbende, så er det en svær opgave for dem. De sidste 10-25 års udvikling inden for feltet, bl.a. noget så almindeligt som at bruge designmønstre, er ikke nødvendigvis kendt stof i den kreds.

3) Ja, mainframe-teknologien er gammel og mens den har sine dyder, så er den ikke gearet til moderne udviklingsmetoder og moderne udviklere, som Michael Park skarpt beskriver ovenfor. Nogle af problemerne, Michael nævner, har dog mere at gøre med gamle udviklere end indbyggede mangler i mainframen.

4) Økonomien er ofte et problem. Dels fordi det er dyrt at vedligeholde ”a big ball of mud” og også – ikke mindst – at leverandøren presser citronen på driften, da leverandørbindingen er hård og det er dyrt at komme ud af situationen.

Så hvad gør man så? Hvis der ikke er større teknisk gæld og ingen større ændringer på vej, så er problemet til at overse. Økonomien er en mulig undtagelse hvor migrering til en anden leverandør i givet fald kunne være vejen frem.

Men hvis der er høj teknisk gæld, kræves der andre midler: Teknisk gæld er svær at fjerne og "a big ball of mud" er endog meget svær at komme ud af. Kodekonvertering kan måske hjælpe men den tekniske gæld flytter typisk med – uanset hvad de håbefulde leverandører af kodekonverterings-tools hævder. I de tilfælde er vejen frem at få bygget en ny løsning på standardkomponenter og standardsystemer og at få genkodet resten. En alternativ løsning er – måske i en overgangsperiode på nogle år – at indpakke mainframen i et API-lag og stille og roligt at funktionstømme eller blot neddrosle udviklingen af mainframen.

Michael Park

Så jeg anerkender til fulde validiteten af dine oplevelser, men jeg har på den anden side set, hvad man kan med mainframes, hvis man ved, hvad man gør, og jeg er stadig imponeret.

Jeg anerkender til fulde validiteten af dine mainframeoplevelser, men du fortæller ikke noget om hvad de er.

Nåeh, som i C - host, host.

Ja. Og jeg ville aldrig anbefale at bruge C til noget i dag.

Og for ti år siden var det XML der var det helt hotte, så hvad mon der skal være hot om ti år.

Velkommen til IT.

Sikkerhed er ret så vigtig i mainframeverdenen, så lad lige teknologien blive moden og sikker.

Det var #1 modargument jeg hørte. "Teknologien skal blive moden". Hvad betyder det? Teknologi bliver moden og dør igen på 2 år. Enhver moderne platform har forudsætningerne for at kunne håndtere en teknologis introduktion og udfasning igen efter 2 år. Gennemsnitlevetiden for kode i Google er mellem 6 og 12 måneder. At mene det er fornuftigt at vente 20 år på at Java bliver moden er at leve i fortiden.

"Sikkerhed" er et andet generisk modargument der blev brugt ofte, som ingen hold har i virkeligheden. CSC lækkede danske kørekortinformationer i 9 måneder før hullet blev lukket, fordi ingen udviklere kunne finde ud af at gennemskue logfiler på en mainframe. Det er security through obscurity, og den sild er død.

Bjørn Sune Andersen

Mange banker vil ikke være ligeglade med den nedetid, som Nemlogin præsterede da Interxion mistede et datacenter.


Undskyld, men det er ganske enkelt noget vrøvl.

Den første del af sætningen er rigtig, ingen banker er glade for nedetid.

At nedetid pga. et mistet datacenter aldrig sker i en mainframeinstallation er ganske enkelt forkert.

Failover der fejler har intet med typen af boxe der står inde i datacenteret at gøre - punktum.

Bjørn

Jørn Thyssen

Jeg arbejder for en ISV der laver software til mainframe.

Vi bruger git; har build og test pipelines i Jenkins; koder i bl.a. java, TypeScript og Metal C; den færdige kode i Artifactory, osv. Du kan selvfølgelig compilere COBOL og PL/I fra en bash shell hvis man ikke ønsker at skrive JCL.

Man kan selvfølgelig også starte en bash shell, afvikle python eller perl programmer, etc etc.

Hvis man gerne vil modernisere så kan det selvfølgelig lade sig gøre. Man kan også lade være.

Morten Bøgh

100.000 kr’s spørgsmålet er om mainframe kan noget som andre servertyper ikke kan. Jeg er tilbøjelig til at svare ‘ja’, men det er godt nok ikke nemt at komme med en dækkende argumentation. Og nedenstående er ikke en komparativ analyse af forskellige serverarkitekturer, men mere en vurdering af hvad mainframe kan - i et samspil med et matchende miljø omkring maskinen:

Mainframe er i min optik: En relativ stor SQL-database... At den er ‘stor’ ligger i at hele databasen arbejder under en fælles commit-mekanisme, med den sikkerhed i fejlhåndtering der ligger i dette. Dette i modsætning til en distribueret, serverbaseret database. Til at skabe procedural logik og forbinde de forskellige SQL-kald har man rådighed over et ikke-objektorienteret sprog: COBOL er her et udmærket bud. Grunden til at det bør være ikke-objektorienteret er, at ‘objekter’ er noget som findes i SQL-databasen, der er ikke klogt at opbygge egne applikations-specifikke datastores og objekthierarkier, og det er ikke klogt at køre filosofien ‘databasen er der hvor data befinder sig når lyset er slukket’. I et SQL fokuseret system befinder data sig altid i databasen, og under kontrol af commit-mekansimen, bortset fra i skabelsesøjeblikket: når den procedurale logik skaber eller modificerer objekter i databasen. Design af et godt mainframe system er meget fokuseret på design af databasen, alt andet underordnes denne. I øvrigt er syntaxen i SQL fremagende - i forhold til privatudviklede protokoller til acces af objekters egenskaber i et Java-setup.

Naturligvis kan man godt programmere i Java på mainframe hvis man overholder ovenstående. At arbejde i en service-orienteret arkitektur internt i sin procedurale kodning kan også have sine fordele, og her kan Java have sine styrker.

Helt fundamentalt er, at det der kører på mainframe, er kærnesystemet. Programmering af brugergrænsefladen bør af flere grunde ikke ske på mainframe: Det er for dyrt at køre det her, en server-baseret udviklingsplatform har bedre frameworks hertil, og det vigtigste: Processer i brugergrænsefladen har ikke glæde af at køre under én global commit-manager.

Under disse forudsætninger giver mainframe mening. Implicit i ovenstående ligger, at ens system bygger på et ‘stort’ sammenhængende kærnesystem. Kærnen i et sådant kærnesystem er næsten altid ‘financielle transaktioner’ altså at holde styr på pengestrømme.

Et alternativ til håndbyggede kærnesystemer er ERP-systemer, såsom SAP. Hvis ens logik passer perfekt ind i SAP er valget let, hvis ikke, kan det blive en kostbar oplevelse at vælge et ERP-system.

Så kan man i øvrigt mene hvad man vil desforuden: Fx at mainframe er for dyrt i afgifter til IBM, og at medarbejderne typisk både er for gamle og for dyre, og at værktøjssiden på mainframe er for gammel og for primitiv. Ja, jo, men…:

Prisen: IT som virker, er ofte dyrt. Pris er måske ikke altid helt afgørende, det afgørende er om systemet virker, og det afgørende dyre viser sig hvis det ikke virker. Erfaringer og statistik på dette område er et rædselskabinet.

Medarbejderne: Erfarne folk koster. Unge mennesker af bedste silicon valley aftapning koster også. Hvilke vidundere Google kan lave ved at tiltrække verdens bedste (unge) softwareingeniører har måske ikke så meget at gøre med hvordan man bør angribe udviklingen af kærnen i et administrativt system til Fiskeri og Kulturstyrelsen. Et mix af erfaring og ungdom er ofte et rimeligt bud. Herudover: Mainframe arbejder ikke med ‘full-stack’ udviklere. En mainframe er befolket af specialister, fx er database-tuning et emne for databaseadministratorer, ikke for systemudviklere. Et kostbart princip, men specialister ved ofte mere om deres emne end hvad generalister gør.

Værktøjssiden: Compuware og Chris O’Malley har sine bud på hvad der skal til. Muligvis fremragende, jeg ved det ikke. Selvudvikling af værktøjer har altid haft et betydeligt fokus i mit mainframe-liv. Hvilket ikke det billigste princip, men hvis det fungerer, kan man opnå stor parallellitet mellem problemer og løsningsmetoder. Og man kan i øvrigt komme meget på afstand af oplevelsen af mainframen som stiv, gammel og ufleksibel.

Konkluderende: Mainframe er et område for store modne organisationer med erhvervet fokus på just denne vinkel. Det lyder ikke umiddelbart spændende, men man kan ikke udelukke, at man på den måde kan udvikle IT som virker - også i de mere komplekse tilfælde. Men garantier gives ikke. Og mange mainframe systemer er i deres tilstand og videreudviklingsmuligheder ret langt fra ovenstående idealer.

Christian Nobel

Velkommen til IT.

Når man sent lørdag aften ankommer til en fest som startede torsdag midt på dagen, hvem er det så mon der skal byde velkommen?

Faktum er, at mange gange så er det altså nødvendigt at forholde sig at det er altafgørende at at produkt har en levetid på mere end nogle få år - derfor skal man heller ikke bare skifte udvekslingsformat i tide og utide, afhængig af hvad juniorprogrammører for tiden finder hipt.

Tænk hvis bilindustrien og flyindustrien skiftede kurs hele tiden, og ikke sørgede for at supportere udgående produktet - jeg kan stadig købe originale reservedele til min 20 år gamle bil.

Michael Park

Faktum er, at mange gange så er det altså nødvendigt at forholde sig at det er altafgørende at at produkt har en levetid på mere end nogle få år.

Og her fortæller jeg dig, at det er ikke virkeligheden i IT-verden anno 2019. Det er afgjort virkeligheden i mainframe-verden, fordi udviklerne stadig lever i 1960.

Michael Park

Jeg er tilbøjelig til at svare ‘ja’, men det er godt nok ikke nemt at komme med en dækkende argumentation.

Jeg er tilbøjelig til at svare 'nej', og jeg har udførligt beskrevet hvorfor ovenover. Du kunne måske passende komme med noget den anden vej?

En mainframe er befolket af specialister, fx er database-tuning et emne for databaseadministratorer, ikke for systemudviklere.

Forkert. Database-tuning er et emne alle udviklere på et udviklingsteam bør vide noget om, og mestre, akkurat, som alle andre aspekter af morderne udviklingsparadigmer. At opdele folk i siloer er netop at sidde i fortiden, som mainframeudviklerne stadig gør.

Michael Park

Og hvilket belæg har du for at docere dette over for mig?

At gennemsnitslevetiden for kode i højprofilerede softwarevirksomheder er mellem 6 måneder og 2 år. Det er et paradoks at tale om fremtidssikring af software, da krav, teknologi og infrastruktur skifter så hurtigt, at det ikke giver mening at planlægge udfra at et stykke software skal kunne eksistere i 10 år, for hele grundlaget for den beregning har ændret sig markant efter 10 år. Derfor er der ikke noget galt i at software ikke lever længere end få år, da værdien ligger i de udviklere, som kan finde ud af at navigere i en verden af konstant-skiftende krav og teknologier.

Michael Park

Men det har jo ikke noget med failover at gøre, så du må nødvendigvis tænke på noget andet.

Baldurs pointe er den samme, uagtet af dette. Hans svar var til en kommentar om, at værdien i mainframes åbenbart lå i, at fraværet af nedetid var en grund til at vælge mainframeteknologi over moderne teknologi.

Specifikt i den sag blev Danske Bank nødt til at flyve IBM-specialister ind for at løse problemet, fordi ingen af deres egne teknikere forstod problemet, hvilket falder fint i hak med mit oprindelige indlæg om, at resten af verden er rykket videre imens mainframeverden har stået stille.

Baldur Norddahl

Ja, men fortæl, fortæl.
Jeg erindrer noget med en tekniker, der fumlede og der viste sig en fejl i DB2s recoveryrutine.
Men det har jo ikke noget med failover at gøre, så du må nødvendigvis tænke på noget andet.

På hvilken måde mener du at danske banks failover fungerede? Der sker en hændelse i det primære datacenter. En mainframe i et sekundært datacenter skal overtage, men det fungerer ikke. I stedet ender man med at være nede i en uge.

Det var et svar på at Nemlogin var flere timer om at få deres løsning op at køre i det alternative datacenter og en antydning af at de nok havde klaret sig bedre på en mainframe løsning. Angiveligt var mange af failover procedurerne i danske bank manuelle, så jeg vil stille spørgsmål ved denne påstand selv når det fungerer.

At årsagen til at der skulle laves failover var vidt forskellig er irrelevant. Men jeg vil notere at en mainframe hellere ikke overlever et nedbrud på kølesystemet.

Christian Nobel

At gennemsnitslevetiden for kode i højprofilerede softwarevirksomheder er mellem 6 måneder og 2 år. Det er et paradoks at tale om fremtidssikring af software, da krav, teknologi og infrastruktur skifter så hurtigt, at det ikke giver mening at planlægge udfra at et stykke software skal kunne eksistere i 10 år, for hele grundlaget for den beregning har ændret sig markant efter 10 år. Derfor er der ikke noget galt i at software ikke lever længere end få år, da værdien ligger i de udviklere, som kan finde ud af at navigere i en verden af konstant-skiftende krav og teknologier.

Du svarer jo ikke på mit spørgsmål.

Men derudover så mener du åbenbart at software er målet i sig selv, hvilket er noget absurd vrøvl.

IT er et værktøj/middel, som helst skal være så lidt som overhovedet muligt i vejen, skal være robust, og levedygtigt.

De fleste virksomheder vil være overmåde kede af at deres IT kun ville kunne leve i 6 måneder, og de så skal ud og investere i nyt og lave omstillinger, ligesom en håndværker ikke går ud og køber en ny boremaskine hver uge, bare fordi farven på plastikkken ændrer sig.

Og der hvor vi taler om virksomheder, myndigheder og andet skal interface, der er vi nødt til at lave robuste og langtidslevebare protokoller/formater for udveksling af data, og ikke bare lade os diktere af hvad en bumset teenager tilfældigvis synes er sjovt den dag - og så er vi tilbage til XML vs JSON.

Michael Park

De fleste virksomheder vil være overmåde kede af at deres IT kun ville kunne leve i 6 måneder, og de så skal ud og investere i nyt og lave omstillinger, ligesom en håndværker ikke går ud og køber en ny boremaskine hver uge, bare fordi farven på plastikkken ændrer sig.

Og der hvor vi taler om virksomheder, myndigheder og andet skal interface, der er vi nødt til at lave robuste og langtidslevebare protokoller/formater for udveksling af data, og ikke bare lade os diktere af hvad en bumset teenager tilfældigvis synes er sjovt den dag - og så er vi tilbage til XML vs JSON.

Nu kører vi jo bare i ring, og jeg ved ikke hvad det her had mod teenageres hudproblemer og juniorprogrammører har at gøre i debatten - jeg har aldrig talt om at man skal skifte teknologi fordi en eller anden synes det er skægt, jeg fortæller dig bare hvordan IT-verden ser ud i 2019, ligemeget om folk i denne tråd mener, at en softwareservice bør kunne eksistere i årtier uden at blive udskiftet, eller ej.

Det er muligt du har den mening at "vi er nødt til at lave robuste og langtidslevebare protokoller", men jeg fortæller dig at det er ikke virkeligheden i Silicon Valley. Formater til protokoller skifter hele tiden, og det gør økosystemerne omkring dem også, og så er det dit problem ligemeget om du kan lide det eller ej, når der pludselig ikke er nogen andre i verden der hverken kan eller gider interface med dit oldnordiske endpoint som har fungeret upåklageligt i 25 år.

Jeg er godt klar over, at CSC stadig ikke ser noget problem i at kræve et dagligt job kopierer en .csv fra en FTP server, men i resten af verden er selv XML og JSON ved at blive udskiftet med ting som GraphQL og diverse udgaver af protobuf og gRPC, og om 2 år er der noget nyt, og du kan hoppe med på vognen eller falde af i svinget - og så bliver man et emne i en mainframe-debat om gammeldags mainframeudviklere der ikke vil indse at verden omkring dem har ændret sig - og aktivt kæmper imod det, til en ubegribelig høj pris for den danske skattebetaler.

Baldur Norddahl

På hvilken måde fungerede den ikke ?
Banken skal have en eentydig sikring af transaktionerne, hvilket er en helt anden opgave end bare at få gang i en tilsvarende service i et alternativt datacenter,som med tilfældet Nemlogin.

Det fungerede ikke på den måde, at det var designet til at kunne køre videre i det andet datacenter uden væsentlig nedetid. Det skette ikke. Ergo fungerede failover ikke. Så er den vist ikke længere?

Vi aner ikke noget om hvad Nemlogin løsningen er designet til. Vi fik at vide at det var normalt at failover skal tage så lang tid. Deraf kan vi aflede at det er designet således og faktisk ikke var udsat for en fejlet failover. De kører formodentlig med manuel opstart af reserven. Det kan sagtens laves automatisk, men det har haft en pris som staten har takket nej tak til.

Det hele kan skrives ned i en SLA. Hvis der i SLA for Nemlogin står at den kan være nede i X timer i tilfælde af failover, og det tog mindre end det, så er de golden. Jeg kan garantere at der ikke stod i SLA for Danske Banks system at de måtte være nede i en uge.

Christian Nobel

jeg fortæller dig bare hvordan IT-verden ser ud i 2019,

Og så er det jeg gentager mit spørgsmål, hvad er dit belæg for det?

jeg fortæller dig at det er ikke virkeligheden i Silicon Valley.

Helt ærligt, jeg vil skide på Silicon Valley, for den virkelighed f.eks. produktions- og servicevirksomheder, samt myndigheder og meget andet skal forholde sig til, er en helt, helt anden.

Og der er stabilitet, kvalitet og forudsigelighed meget mere vigtig, end hvad moden foreskriver i Silicon Valley.

Du har åbenbart stadig ikke fattet det; IT er ikke et mål i sig selv, det er et middel!

men i resten af verden er selv XML og JSON ved at blive udskiftet med ting som GraphQL og diverse udgaver af protobuf og gRPC

Det var dog det mest håbløse vrøvl, men du mener åbenbart at det drejer sig om at fyre så mange som muligt bullshit banko ord af, så er alt godt.

Ditlev Petersen

At gennemsnitslevetiden for kode i højprofilerede softwarevirksomheder er mellem 6 måneder og 2 år. Det er et paradoks at tale om fremtidssikring af software, da krav, teknologi og infrastruktur skifter så hurtigt, at det ikke giver mening at planlægge udfra at et stykke software skal kunne eksistere i 10 år, for hele grundlaget for den beregning har ændret sig markant efter 10 år.


Hvorfor så overhovedet bekymre sig om at skrive ordentlig software, som andre kan finde ud af at rette i? Jeg har svært ved at tro, at det kan være et ideal, at ens programmer har en kortere levetid, end det tog at skrive dem. Tværtimod skal de skrives, så man (inklusive helt andre programmører) kan rette dem, tilpasse dem, når "hele grundlaget" ændrer sig.

På en mainframe kan et program stadig køre, selv om der kommer en ny model eller en ny version af operativsystemet (siden engang i 1960'erne, som vi åbenbart "hænger fast i"). Kommer der en ny version af et server-os, så er det reglen, at en masse programmer slet ikke fungerer længere. Man skal købe nye programmer. Og de "højtprofilerede softwarevirksomheder" laver så ikke det program længere, eller de er lukket.

Michael Park
Michael Park

Og så er det jeg gentager mit spørgsmål, hvad er dit belæg for det?

Hvad ønsker du? Statistikker? Brugerundersøgelser? Jeg har arbejdet i 15 år i branchen - både i startups, mainframehelvede og mellemstore it virksomheder, både dansk og internationalt - er det nok?

Helt ærligt, jeg vil skide på Silicon Valley, for den virkelighed f.eks. produktions- og servicevirksomheder, samt myndigheder og meget andet skal forholde sig til, er en helt, helt anden.

Det fortæller du bare til udbuddet af nyuddannede udviklere, så.

Det var dog det mest håbløse vrøvl, men du mener åbenbart at det drejer sig om at fyre så mange som muligt bullshit banko ord af, så er alt godt.

Hehe, okay så. Jamen FTP og CSV filer er da også fedt nok.

Christian Nobel

Hvad ønsker du? Statistikker?

Det kunne være et meget godt udgangspunkt.

Jeg har arbejdet i 15 år i branchen

Aha, men har du så også arbejdet med kunder og prøvet at løse deres udfordringer?

Det fortæller du bare til udbuddet af nyuddannede udviklere, så.

Er det fordi du ikke forstår virkeligheden, eller er det fordi du ikke vil forstå virkeligheden?

Det er flintrende ligegyldigt hvad nyuddannede udviklere mener, da IT (igen igen) IKKE ER MÅLET, men kun et middel/værktøj!

Det det drejer sig om er hvilket behov dem der skal betale for gildet har - og det er guddødemig ikke at der slingres rundt og opfindes ny protokoller og formater hver eller hver anden dag.

Jeg håber sandelig ikke du har noget med f.eks. flyindustri eller andet vitalt at gøre.

Jamen FTP og CSV filer er da også fedt nok.

Drop bare dine stråmænd!

Søren Hersdorf

Der har tidligere, i vide kredse, været en bred enighed om at MF platformen er dyrere at drifte. Det er dog ved at ændre sig, flere og flere software leverandører på X86 platformen går over til forbrugberegning, dvs man betaler software licens efter størrelse på maskinen og antallet af brugere mv. Software leverandører på MF platformen er samtidig ved at ændre deres prisstrukturer, herunder stærkt reducerede priser på transaktioner afviklet via requests fra webklienter.

Søren Hersdorf

Den eneste grund til at mainframes ikke kan dø, er det ekstreme politiske pres fra inkompetente, omskolede udviklere fra 1970’erne som stadig ikke ved hvad internettet er.

Nemlig, os fra 70'erne har magt over både direktion og bestyrelse.

Hvis man tvang mainframes væk fra banker og forsikringsselskaber ville man kunne spare 90% af udviklingsbudgettet, nemt. Den rabat burde ryge direkte til forbrugerne.

Jeg tror ikke, du er helt klar over hvad det vil koste at omlægge en større finansiel instituition fra MF til X86. Eller hvad det koster at vedligeholde de 2 platforme.

Intet brugbart standardbibliotek til Cobol og PL/1 (tænk simple ting som strengformatering, websockets, json parsing, bufferedreader, alt hvad alle moderne sprog har)

Det kommer efterhånden som efterspørgslen kommer, feks har nyeste COBOL version en JSON parser og CICS understøtter mapping mellem MF sprogstrukturer og XML/JSON

Ingen deployment pipelines til at køre integration- og unit tests. Faktisk ingen testframeworks til automatiserede test overhovedet, alle tests blev lavet af mennesker kl 6 om morgen efter release til prod.

Sludder, det laver man bare, det er op til den enkelte installation

Elendig performance sammenlignet med ethvert moderne sprog der udførte en normal, standard opgave (dvs ikke benchmark af math.pow, som cobol eller PL/1 i øvrigt heller ikke har)

Sludder, MF outperformer X86, som har svært ved at scalere ved meget store datamængder

Ingen moderne versionskontol af koden, til pull requests, code review, dokumentation etc.

Opgaven ligger i IDE'et og der findes adskillige værktøjer.

Ingen moderne IDE (glem det, Eclipse-elskere, 10 GB ram for at åbne en fil er ikke moderne)

Eclipse virker nu ganske fint. En tidligere undersøgelse viste i øvrigt at uanset sproget og platformen, så arbejder udviklere stort set med samme hastighed, når de kender sproget og IDE'et. Eneste undtagelse er assembler, som er langsommere at kode på alle platforme.

Ingen organisering af de faktiske filer og/eller koden i et program. Alle programmer var begrænset til én fil med et navn på maks 8 tegn, caps selvfølgelig. Fx “ZBTS1000.CBL” - så regn selv ud hvad det gør.

Sludder, koden til et MF program kan opdeles i masser af filer og iøvrigt genbruges på tværs, både på kildekode og på objekt niveau.

Det lyder som om din erfaring stammer fra en meget begrænset periode og et enkelt arbejdssted. Der er meget stor forskel på hvordan de enkelte installationer vælger at køre deres mainframe.

Jeg har set meget rod på MF, men man skal vist være meget naiv, hvis man tror, at der ikke findes rod på X86 platformen.
mht til IT-Gæld, så er det min spådom, at gælden på X86 platformen vil være væsentligt større, når den har levet lige så længe og integreret i forretningen som MF. Det er min erfaring at X86 udviklere finder et nyt sprog og IDE hver 18 måneder og de kigger sig ikke tilbage.

Platformsbashing er en yndet sport for den, der kun kender den ene side, men når man har arbejdet seriøst på flere, så erkender man styrker og svagheder. Så forstår man, hvordan den rigtige kombination af platforme og væktøjer skaber meget stærke løsninger.

Log ind eller Opret konto for at kommentere