Schweizere: Vi kan flytte gamle Cobol-applikationer ud i skyen

Flertallet af verdens finanstransaktioner foregår på mainframes og i programmer, skrevet på Cobol, som det er er svært at finde specialister til. Men schweizisk startup hævder at have en løsning.

En schweizisk startup, LzLabs, har nu måske en løsning på problemet med de mange applikationer og programmer, der kører på mainframes og er skrevet i programmeringssproget Cobol.

Vedligeholdelsen af sådanne legacy systemer bliver stadigt vanskeligere på grund af mangel på Cobol-kyndig arbejdskraft.

Cobol blev som det er Version2-læserne bekendt udviklet i slutningen af 1950erne og blev i stort omfang anvendt i de følgende årtier.

Men man hænger lidt på den, hvis man vil flytte data og programmer over på en mere nutidig platform, skriver TechCrunch.

Og der er ved at være aktuelt for mange organisationer, især i finansbranchen, idet 70 procent af verdens finansielle transaktioner ifølge LzLabs stadig afvikles på mainframes.

»Der er akut mangel på profiler, der kan vedligeholde kode på legacy mainframes. Det er et kæmpe problem at finde folk til at holde systemerne i gang,« siger LzLabs CEO, Mark Cresswell, ifølge TechCrunch.

Lzlabs har udviklet en løsning, kaldet Gotthard, som kan hjælpe med at lirke data, executables, konfigurationsfiler mv. ud af den hvepserede af kode, som er skrevet år tilbage.

Præcist hvad LzLabs gør fremgår ikke, men selskabet bedyrer, at man kan flytte applikationerne uden omskrivning eller omformattering af kode og uden genkompilering.

LzLabs annoncerede sidste vinter et partnerskab med Red Hat og Microsoft om løsningen, som de kalder software-defined mainframe.

Ved hjælp af migration tools flyttes data og applikationer til en Software Defined Mainframe (SDM) container og lægger den i låst form på enten Red Hat Enterprise Linux eller Microsoft Azure CLoud.

Værktøjet er ifølge selskabet ikke et quick fix, men kræver lang tids indsats. Selskabet samarbejder med eksterne systemintegratorer om at forberede mainframe indholdet til overførsel.

Har du erfaring med software-defined mainframe, skriv gerne om det i debatten.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (10)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Ditlev Petersen

Så man undgår mainframen, men kildekoden er stadig COBOL. Hvad har man egentlig opnået? En samling programmer, der er meget vanskelige at rette i. Jeg har hørt om gamle programmer, men programmer, der ikke skal vedligeholdes, er sjældne. Især ikke bureaukratiske programmer i COBOL.

  • 1
  • 1
Jan Gundtofte-Bruun

Selve det at drive en mainframe rent fysisk kan passe meget dårligt i en moderne virksomheds kultur og IT gearing, så selv om det LZ laver "bare" er en "virtuel mainframe" kan der meget vel være vundet en del ved at køre den "i skyen" ... sat lidt på kanten, lidt som hvis man var nødsaget til at køre gamle Sega Genesis-programmer, men kunne gøre det i "SimGenesis" på maskiner i MS Azure i stedet for på gammelt udstyr fundet på eBay og kablet sammen med forlængerledninger.

Men jo, at skaffe sig af med selve Cobol koden kan kun være en næste milepæl -- og jeg kan ikke forestille mig at det kan gøres "let".

  • 6
  • 0
Maciej Szeliga

Cobol findes til de fleste systemer, så så længe der ikke er hardware afh. i koden så skulle det let kunne flyttes... det er testen som kommer til at tage tid.
Cobol kommer fra en verden med tekst terminaler så den del skulle kunne være forholdsvis enkel.
Sky er som bekendt en sovs man hælder på CEO'er så de lettere sluger begrebet outsourcing - der er ingen sky, det er bare en anden mands computer... jeg venter spændt på at tømreren om hjørnet finder på at outsource sin hammer til Kina.

Cobol gør nogen ting som intet andet moderne sprog kan, de andre i samme boldgade er lige så udskældte og lige så gamle (f.eks. Lisp og MUMPS)... måske skulle man se på om det ikke er mere lønsomt at uddanne Cobol folk i stedet for at aflive Cobol.

  • 3
  • 0
Bent Jensen

Godt det var mainframe og ikke Windows og PC'er.
Så var man tvunget til at skifte akitektur omkring hver 3 år.
Enten på grund af OS, GUI eller at CPU og harware ikke blev produceret mere, og tingende skulle findes brugt på E-Bay.

Måske skulle man i stedet sige flot, hvorfor flytte til noget hvor man skal skifte i tide og utide. Behold COBOL. Når man se på hvor meget gamle software ig systemer der stadig køre her 40-50 år efter, mens ting der er lavet til WIndows/OS2 i 80-90'erne er ved at være skiftet, op til flere gange.

Hvad lavet man rigtigt den gang, i forhold til nu ?
Ud over at begræsnet resurser og meget dyr maskintid, betyd at der vikeligt skulle tænkes over tingene, og man ikke bare rullet alle ide og tiltag ud. Men måske fik skåret ind til de ting som skulle laves og håndteres, og ikke dump om daglig "effektivitet" og klaret (afviste) sager, så ledelsen kan få sin bonus.

Et eller andet må være lavet rigtigt den gang, når det køre 50 år efter, mens kun 3-10 år gammel systemer skrotes i dag. Eller er det bare dem som blev rigtigt første gang som stadig køre, elle de dårlige og tåbelige projekter og tiltag er lukket ned og afløst af nogen andre. (lige så tåbelige, men bare i et andet sprog)

  • 7
  • 3
Joe Sørensen

Hvad har man egentlig opnået?


Du slipper for at vedligeholde hardware.

Der er en del virksomheder som sidder med en 15-20 år gammel mainframe, som er blevet udskiftet hver 10 år før det. Den er selvfølgelig bagudkompatibel med alle tidligere systemer siden de fik den første i 70'erne.

I dag har de ikke brug for mere kapacitet i den, da alt nyudvikling de sidste 20 år er sket på x86 hardware. Derfor vil de gerne udskyde opgraderingen, da den jo er dyr. Problemet er, at selvom man kan blive ved at kunne køre på en 15-20 år gammel ( eller ældre ) mainframe, så bliver reserve dele dyrere. Kendskab til gamle storage systemer osv. bliver en sjældenhed. Og hvis den er fra før 2000, så kan den kun administreres fra en IBM 3270 console terminal eller et program som kun kører på OS/2 Warp.

Det har faktisk undret mig selv at der ikke findes cloud PaaS løsninger med mainframes. Mange sender alt deres x86 ud i "skyen".

Men du har helt ret. De løser ikke deres egentlige problem. Det er meget sværere at administrerer gammel software end gammel hardware. Havde det kun været et hardware problem, så kunne de snildt have opgraderet til nyeste generation af mainframen. Så ville de både få et storage system der kalder tingene hvad de hedder i dag, ny garanti, mere kapacitet og mindre strømforbrug, og kunne oprette virtuelle maskiner fra et web interface. Og selvfølgelig support for Linux servere, så de kan droppe VMWare.

  • 2
  • 0
Ditlev Petersen

Du slipper for at vedligeholde hardware.

Der er en del virksomheder som sidder med en 15-20 år gammel mainframe, som er blevet udskiftet hver 10 år før det. Den er selvfølgelig bagudkompatibel med alle tidligere systemer siden de fik den første i 70'erne.

Men i stedet for afhængighed af hardware, har man afhængighed af noget mystisk software? Eller får man noget pænt og gennemskueligt, der uden videre kan afvikles på Linux eller Windows?

  • 0
  • 0
Robert Piil

Der er ikke noget problem i at flytte og afvikle COBOL applikationer, problemet ligger et helt andet sted.

På de fleste større installationer ligger data (sikkert og godt) på mainframen, har man applikationer med heavy I/O eller opererer på store mængder data, så giver det problemer at flytte afviklingen af koden ud på en boks der skal flytte data over netværket. Desuden vil mange applikaitoner leve i et tæt samarbejde med andre systemer (både online og batch) på mainframen, og i hvert enkelt tilfælde skal man vælge hvordan man vil interface med de applikationer.

Hvis det skal lykkes at bibeholde performance, så kræver det ændringer i applikationerne, og så kan man overveje - som en anden også er inde på - om det smarteste virkelig er re-designe sine applikationer i COBOl, eller om det bedre kunne betale sige at skrive dem om i et andet sprog.

Jeg mener ikke engang COBOL er problemet, men derimod manglen på moderne test og -udviklingsmiljøer på mainframes. Der er eclipsebaserede udviklingsmiljøer tilgængelige. De er ikke helt på højde med andre platforme endnu, men det er på vej.
Når de bliver tilgængelige tror jeg ikke på det er noget uovervindeligt problem at finde folk der kan vedligeholde eller udvikle nye applikationer.

  • 2
  • 0
Jan Gundtofte-Bruun

Jeg mener ikke engang COBOL er problemet, men derimod manglen på moderne test og -udviklingsmiljøer på mainframes.


Helt enig, og til den liste kunne du tilføje "manglen på veltrænede programmører (som ikke er ved at gå på pension)".

Sproget som sådan er måske ikke "bling" og trendy, men det har beviseligt været et "business effektivt" sprog i meget længere tid end C.

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