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

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

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.

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.

Du slipper for at vedligeholde hardware.</p>
<p>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?

Hvad har man egentlig opnået?

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.

Der er da en del gamle systemer, der er lukket for længst. Det Røde System f.eks. (det bør vel være Det røde System). Odenses patientadministrative system er også lukket, men det er sket for ganske nylig. Nogle konstruktioner kan ikke "strækkes" nok til de nye krav. CPR blev vist også genudviklet.

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)

Jo, det var også min tanke, at man under alle omstændigheder er nødt til at lære COBOL. Også selv om man er inde i en udfasning.

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.

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".

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.