COBOL carrière?

[Verwijderd]

Beste allen,

Het ziet er naar uit dat mijn werkgever de komende tijd op zoek zal gaan naar COBOL programmeurs. Door het afbreken (falen) van een ICT project is het idee om te investeren de bestaande programmatuur, gebaseerd op COBOL. Ook werkzaamheden in de vorm van onderhoud zijn te verwachten voor de langere termijn.

Ik zit te twijfelen om mijzelf hiervoor naar voren te schuiven. Ik heb echter geen achtergrond in programmeren. Ik heb wel affiniteit met rechtlijnigheid (denk aan rekenen, Excel-formules) en ook zaken zoals Wordpress code aanpassen is voor mij een kwestie van goed googlen, wat uitproberen en dan lukt het meestal wel. Nog belangrijker, ik vind het best leuk. Afhankelijk van de kosten geloof ik dat mijn werkgever wel geïnteresseerd is om te investeren in een opleiding voor mij.

Mijn vraag is wel in hoeverre COBOL programmeurs verder in trek zijn en hoe een opleidingstraject er verder uit zou zien. Er zijn überhaupt niet veel COBOL opleidingen te vinden in eerste oogopslag, maar de meesten vereisen nog een bepaalde vooropleiding (gestructureerd programmeren, inleiding mainframe, TSO/ISPF, JCL, VSAM) waar ik dus totaal geen ervaring mee heb. Is het realistisch om te denken dat ik binnen 6 maanden klaargestoomd kan zijn om aan de slag te gaan als COBOL programmeur?

Alvast bedankt voor de input.

[The Eagle]

Ik ken een aantal mensen die in het verleden ooit Cobol programmeur waren, maar die doen er weinig meer mee. Je ziet het ook nog maar weinig, en een developerslicentie is DUUR Lees: 40k per stuk. Toevallig vorig jaar nog twee nodig gehad voor een klant, alleen maar omdat een klein stukje software op Cobol draaide.

Dat gezegd hebbend: Cobol is een redelijk uitgekristalliseerde taal. Komt weinig meer bij volgens mij, dus ik vermoed dat het eenmalige scholing zou zijn. Daarnaast zit het redelijk dicht tegen machineniveau aan, dus dat is ook kennis die je op een gegeven moment zult moeten begrijpen. En dat gaat soms best diep, zeker als je het van scratch moet leren.

Voor je huidige werkgever kan dit misschien best interessant zijn, maar voor jezelf vergroot je je marktwaarde er niet echt mee ben ik bang. Als je er een studieovereenkomst aangehangen krijgt waarbij je een aantal jaren moet blijven voor ie afbetaald is zou ik er nog eens een nachtje over slapen. Als je dan als Cobol programmeur weg zou willen, zijn je marktkansen vrij beperkt.

[Tsurany]

Vergeet niet dat ze overal dit soort systemen uitfaseren. Komen dus veel code monkeys vrij die niks anders kunnen dan COBOL met tig jaar ervaring. In de toekomst heb je er dus niks aan. Afnemende markt met te sterke concurrenten.

[farlane]

Hoezo zouden dat 'code monkeys' zijn dan? Omdat ze cobol programmeren?

[edit]
ElkeBxl in "De Devschuur Coffee Corner - Iteratie ➑"

[Verwijderd]

Bedankt voor de reacties! Ik weet inderdaad dat veel bedrijven COBOL proberen uit te faseren, maar wordt dat niet al heel lang getracht? Ik had ook begrepen dat het nog in heel veel programma's zit die nodig zijn voor de kritieke bedrijfsprocessen. Ik dacht misschien is het een goede niche om in te duiken Maar blijkbaar is dat te positief gedacht(?).

Een ontwikkelaarslicentie mag geen probleem zijn en een studieovereenkomst ook niet, het is een grote werkgever waar ik al langer voor werk en als zij mij zouden ontslaan vervalt de terugbetalingsverplichting.

Het lijkt mij inderdaad een eenmalige opleiding, maar ik heb geen goed zicht op de grootte van het hele traject of het kostenplaatje. Stel dat mijn werkgever zonder moeite een zwik doorgewinterde COBOL ontwikkelaars kan vinden zal het ook niet zo interessant zijn om mij om te scholen.

[Tsurany]

farlane schreef op dinsdag 16 december 2014 @ 00:15:
Hoezo zouden dat 'code monkeys' zijn dan? Omdat ze cobol programmeren?

[edit]
ElkeBxl in "De Devschuur Coffee Corner - Iteratie ➑"

Omdat een groot deel niks anders kan. Zet ze in een hok en ze gaan cobol tikken maar veel meer hoef je er vaak niet van te verwachten.

[Merethil]

Tsurany schreef op dinsdag 16 december 2014 @ 07:52:
[...]

Omdat een groot deel niks anders kan. Zet ze in een hok en ze gaan cobol tikken maar veel meer hoef je er vaak niet van te verwachten.

Ik gok dat die mensen met hun tig jaar ervaring vast wel meer kunnen dan alleen Cobol tikken. Denk hierbij aan dingen als architectuur van systemen en de beste performance halen uit de gegeven mogelijkheden.

Dat ze cobol kennen en kunnen betekent niet dat ze niets anders kunnen. Het kunnen programmeren in het algemeen is trouwens belangrijker dan "kunnen programmeren in taal X". Als je eenmaal die mindset hebt is het overschakelen naar een andere taal lang zo lastig nog niet.

@TS: als je werkgever je er de opleiding voor wil geven is het altijd een leuke uitdaging. Je kansen zullen niet vergroot worden in de markt "omdat je Cobol kent", maar zeker wel omdat je " kunt programmeren en logisch denken".
Als je drie jaar ervaring met programmeren hebt (en dan bedoel ik wel echt dagelijkse hands-on ervaring) sta je al best netjes in de markt.
Een en ander ligt wel aan je leeftijd, als jij na een jaar weggaat bij je huidige werkgever en zoekt werk als programmeur kan je waarschijnlijk niet hetzelfde loon krijgen als je nu verdient, als je bijvoorbeeld al 26+ bent. Junior programmeurs worden veel gevraagd maar daar zijn er natuurlijk ook een hoop meer van dan de devs met meer ervaring.

[Soultaker]

Tsurany schreef op maandag 15 december 2014 @ 23:15:
Vergeet niet dat ze overal dit soort systemen uitfaseren. Komen dus veel code monkeys vrij die niks anders kunnen dan COBOL met tig jaar ervaring. In de toekomst heb je er dus niks aan. Afnemende markt met te sterke concurrenten.

Het cliché is juist andersom: dat alle goede COBOL programmeurs (begonnen in de jaren 60) inmiddels met pensioen zijn, en dat de systemen die ze ontwikkeld hebben nog veel langer onderhouden moeten worden dan ooit de bedoeling was, waardoor er dus een tekort aan goede programmeurs is en een overschot aan werk.

Hoe het in werkelijkheid zit, weet ik ook niet precies. Ik denk dat goede COBOL programmeurs niet om werk verlegen zitten, maar dat geldt voor alle programmeurs die een beetje flexibel zijn. Zoals Merethil hierboven ook zegt, eigenlijk: als je goed kan programmeren, kun je later ook makkelijk switchen naar een andere taal/ander platform. Op je CV is het feit dat je lang met COBOL hebt gewerkt vooral een bewijs dat je programmeerervaring hebt, ook al is je potentiële werkgever naar (bijvoorbeeld) een Java-ontwikkelaar op zoek.

[Rub3s]

Ik ben programmeur en mij lijkt het me echt totaal geen leuke baan, hele dagen met COBOL bezig zijn. Misschien ben ik te verwend met moderne talen

[jurrie]

Ik zie COBOL een beetje als vangnet, als ik oud ben en de moderne technieken niet meer bij kan benen . Ik werk bij vrij groot bedrijf dat onder een grote multinational valt en nauw samenwerkt met een tak in een ander land. Een van onze grootste systemen draait op COBOL, en in samenwerking met de genoemde andere tak wordt er waarschijnlijk een nieuwe versie van gemaakt. Ook deze wordt dan in COBOL geschreven.

Ik verwacht niet dat de taal snel uit zal sterven; veel grote bedrijven gebruiken het nog en het aantal programmeurs dat de taal begrijpt neemt af. Misschien kan ik dat gat ooit opvullen, al heb ik het zeker niet tot doel verheven.

[ElkeBxl]

Verwijderd schreef op maandag 15 december 2014 @ 22:47:
Mijn vraag is wel in hoeverre COBOL programmeurs verder in trek zijn en hoe een opleidingstraject er verder uit zou zien. Er zijn überhaupt niet veel COBOL opleidingen te vinden in eerste oogopslag, maar de meesten vereisen nog een bepaalde vooropleiding (gestructureerd programmeren, inleiding mainframe, TSO/ISPF, JCL, VSAM) waar ik dus totaal geen ervaring mee heb. Is het realistisch om te denken dat ik binnen 6 maanden klaargestoomd kan zijn om aan de slag te gaan als COBOL programmeur?

Ik zal mijn ervaring als tijdelijke Cobol programmeur delen (zeker gezien ik hier al gequote ben ). Ik had nooit Cobol gedaan en toch wou men mij perse verhuizen naar een Cobol team voor 4 maanden hier op het werk als soort van stage om meer van het bedrijf te leren kennen. Hier is dat standaard voor iedere beginnende IT'er in het bedrijf en dus waren we met 15 mensen dit jaar die voor het eerst in aanraking kwamen met Cobol. Het was een gemengde groep: meerderheid had iets van IT gedaan als opleiding maar er waren er ook bij met een master in wiskunde (minor in IT). Kortom: een hele variatie aan veel programmeerervaring tot bijna niets van programmeerervaring.

Wij zijn bij ABIS op opleiding gestuurd voor 2 weken. Dit is in Leuven maar ze bieden ook cursussen in NL aan blijkbaar dus kan interessant zijn. Op die 2 weken hadden we heel gevarieerd programma. Die cursussen die we hadden:

• Introduction to mainframe computing
• COBOL programming: fundamentals course
• RDBMS concepts
• SQL fundamentals
• DB2 for z/OS fundamentals course

Ze gaven ons een goede introductie in Cobol (met heel goede documentatie) en door de link met DB2 was ik in staat om na die 2 weken direct in het Cobol team hier te starten. In die 2 weken leerden we met TSO/ISPF werken, leerden JCL's begrijpen en schrijven, begrepen wat een VSAM is en leerden om toch wel stevige Cobol modules te schrijven. Was mijn vorige programmeerervaring relevant? (master in computerwetenschappen). Een beetje. Het zorgde ervoor dat ik me kapot verveelde in de SQL delen van de opleiding en dat ik soms gewoon moest weten wat de syntax was voor bepaalde dingen. Maar het is niet dat ik veel slimmer dan mijn collega's uit die cursus kwam of een grootse voorsprong had van in het begin, we hadden allemaal een gelijkaardig niveau Cobol en waren direct inzetbaar in de teams.

Cobol is geen moeilijke taal voor iemand zonder programmeerervaring. Het heeft niet veel datatypes en bv. hier op het werk gebruiken we er maar 3 van Een ingewikkelde syntax heeft het ook niet en de structuur van de modules is goed gedefinieerd waarbij je niet zomaar buiten de lijntjes kan gaan tekenen. Na onze opleiding van 2 weken hadden we verspreid nog wat kleinere opleiding van de werkgever zelve. Ik denk dat ik in totaal zo'n 3,5 weken echt in opleiding ben geweest. Om mezelf nu een Cobol-expert te noemen, dat zou brug te ver zijn. Maar ik kan er zeker genoeg mijn weg in vinden zodat ik nogal weinig zit te googlen of veel hulp van collega's moet inroepen. Ik word even makkelijk ingezet op een project tussen de Cobol programmeurs die hier al 10 jaar zitten. Ik denk dat je makkelijk in 6 maand klaar kan zijn, zelfs op 1 tot 2 maand lijkt het mij mogelijk. Veel hangt af hoe snel je leert en ook hoe logisch je kan nadenken en in wat voor team je terecht komt.

Tsurany schreef op maandag 15 december 2014 @ 23:15:
Vergeet niet dat ze overal dit soort systemen uitfaseren. Komen dus veel code monkeys vrij die niks anders kunnen dan COBOL met tig jaar ervaring. In de toekomst heb je er dus niks aan. Afnemende markt met te sterke concurrenten.

Hier bij ons (verzekeringsmaatschappij) zijn ze het absoluut nog niet van plan om uit te faseren. We zitten met 35 miljoen regels code (copy's geteld als 1 lijn, comments truncated) verspreid over 64000 modules. Er draaien hier dagelijks meer dan 15500 batches per dag die voor meer dan 2TB aan data in de DB2 database zorgen. De kosten om deze systemen uit te faseren hebben ze ooit geschat op meer dan 20.000 mandagen als ik het mij goed herinner (het was in ieder geval enorm hoog). Er zullen vast wel bedrijven zijn waar ze het uitfaseren maar we zitten hier met modules die niet meer veranderd zijn sinds 1991 (toen hadden ze een grote migratie gedaan naar andere servers, anders konden we er nog eens 20 jaar bijtellen qua ouderdom) en die toch nog stabiel draaien. Aan zoiets zou ik niet durven aankomen en om mijn collega's code monkeys te noemen, daar ben ik het niet mee akkoord Er komt best wel veel logisch nadenken bij kijken en zorgen dat je alles in the big picture kan zien. Met gewoon alles overtypen uit de analyses, zou je hier hard op je bek gaan.

Soultaker schreef op dinsdag 16 december 2014 @ 10:15:
[...]

Het cliché is juist andersom: dat alle goede COBOL programmeurs (begonnen in de jaren 60) inmiddels met pensioen zijn, en dat de systemen die ze ontwikkeld hebben nog veel langer onderhouden moeten worden dan ooit de bedoeling was, waardoor er dus een tekort aan goede programmeurs is en een overschot aan werk.

Exactly. Vandaar dat ze bij ons beginnende IT'ers altijd eens Cobol laten doen, ook al worden ze aangenomen voor mogelijk andere functies zoals .Net programmeur (zoals ik). Dat is dan onder het mom van "zo leer je de mainframe ook wat kennen bij ons" maar het is zeker ook om de werklast wat te verminderen omdat ze veel te weinig goede Cobol programmeurs vinden op de markt. Een meerderheid van de beginnende IT'ers hier blijft in Cobol werken daarna.

Rub3s schreef op dinsdag 16 december 2014 @ 10:21:
Ik ben programmeur en mij lijkt het me echt totaal geen leuke baan, hele dagen met COBOL bezig zijn. Misschien ben ik te verwend met moderne talen

Moderne talen verwennen je zeker En ik heb ook al serieus gevloekt op Cobol omdat er bepaalde limieten aan zitten... Maar het leert je wel appreciëren dat zelfs triviale zaken zoals objecten bestaan Iets kunnen zoals date.day voelt als fancy aan voor mij

jurrie schreef op dinsdag 16 december 2014 @ 10:28:
Ik verwacht niet dat de taal snel uit zal sterven; veel grote bedrijven gebruiken het nog en het aantal programmeurs dat de taal begrijpt neemt af. Misschien kan ik dat gat ooit opvullen, al heb ik het zeker niet tot doel verheven.

Ik verwacht ook niet dat het snel zal uitsterven. Toen ik hoorde dat ze bij ons de versie uit 1985 draaien stond ik daar van "serieus?!" maar het is gewoon zo stabiel en snel dat ze het gaan houden. Tenzij iemand ineens met iets magisch afkomt om een hogere performance op een mainframe te garanderen. Maar zelfs dan zal de kost om te migreren te groot zijn om waarschijnlijk de overstap te maken. Zelfs compleet nieuwe projecten worden hier nog in Cobol gestart. Enkel de frontend is in .Net maar dat is dan ook puur vertalen van data naar iets bruikbaars op het scherm en wat user interaction afhandelen. Alle business logic is in Cobol gedaan.

Hopelijk heeft iemand heel dit elan gelezen, waarvoor sorry dat het zo lang was

[elhopo]

Even een cursus volgen maakt je nog geen developer. Het is niet voor niets dat een HBO informatica opleiding 4 jaar duurt, en dan begin je pas met je carriere. Een Excel formule is nog geen programmeren. Dat gezegd hebbende is mijn ervaring dat Cobol programmeren heel wat anders is dan een moderne, object georienteerde taal zoals Java. Andersom is vaak beter te doen, dus als je een achtergrond hebt als bijvoorbeeld Java ontwikkelaar en dan Cobol programmeren. Dit omdat je dan al beter in structuren kan denken en sneller het groter geheel zal zien.

Los daarvan ken ik geen enkele Java ontwikkelaar die het in zijn hoofd zal halen om in Cobol te gaan programmeren. Op je CV staat 5 jaar Cobol nu eenmaal minder goed dan 5 jaar Java.

[farlane]

elhopo schreef op dinsdag 16 december 2014 @ 11:13:
Even een cursus volgen maakt je nog geen developer. Het is niet voor niets dat een HBO informatica opleiding 4 jaar duurt, en dan begin je pas met je carriere. Een Excel formule is nog geen programmeren. Dat gezegd hebbende is mijn ervaring dat Cobol programmeren heel wat anders is dan een moderne, object georienteerde taal zoals Java. Andersom is vaak beter te doen, dus als je een achtergrond hebt als bijvoorbeeld Java ontwikkelaar en dan Cobol programmeren. Dit omdat je dan al beter in structuren kan denken en sneller het groter geheel zal zien.

Los daarvan ken ik geen enkele Java ontwikkelaar die het in zijn hoofd zal halen om in Cobol te gaan programmeren. Op je CV staat 5 jaar Cobol nu eenmaal minder goed dan 5 jaar Java.

Elke taal die je beheerst maakt je waardevoller voor een bedrijf, al was het alleen maar omdat het aangeeft dat je niet met oogkleppen op rondloopt, zoals jij lijkt te doen.
Je suggestie dat COBOL programmeurs niet in structuren kunnen denken is dan ook even belachelijk als lachwekkend : een systeem dat sinds 1985 draait en bestaat uit 64000 modules zou zonder structuur niet kunnen bestaan.

[BillyTheClit]

Ik vind hier niks mis mee als je zin hebt om te gaan programmeren.
Je hebt op dat vlak niks te verliezen, dat is mogelijk anders bij mensen die OO-talen andere high profile IT achtergronden meebrengen.
Als je binnen enkele jaren zin hebt in meer/ander programmeerwerk was dit een goeie testfase.
Als je er geen zin meer in hebt (of de vraag is er niet meer) dan kan je nog altijd terug naar iets anders en heb je die ervaring erbij.
Ik zie toch nog behoorlijke vraag naar Cobolprofielen en ze worden niet slecht betaald, juist omdat ze moeilijk te vinden zijn.

[ElkeBxl]

elhopo schreef op dinsdag 16 december 2014 @ 11:13:
Dat gezegd hebbende is mijn ervaring dat Cobol programmeren heel wat anders is dan een moderne, object georienteerde taal zoals Java. Andersom is vaak beter te doen, dus als je een achtergrond hebt als bijvoorbeeld Java ontwikkelaar en dan Cobol programmeren. Dit omdat je dan al beter in structuren kan denken en sneller het groter geheel zal zien.

Dus je hebt ervaring in Cobol? Ik had ervaring in veel talen voor ik in Cobol opleiding geduwd werd: C, C++, C#, Java, Javascript, PHP, Python, Smalltalk, Prolog, ... best wel wat variatie in soorten van talen zoals je kan zien en toch had ik niet veel voorsprong op mijn collega's. Het is dan ook anders denken om puur in modules te programmeren, batchprogramma's op een mainframe te schrijven, heel beperkte datatypes te hebben, ... Is een Java programmeur dan meer waard dan een Cobol programmeur? Ik denk het niet. Het is appelen met peren vergelijken, het is gewoon een andere manier van werken omdat beide talen veelal in andere business domeinen gebruikt worden of andere doelen hebben. Het houdt veel meer steek om bijvoorbeeld batch programma's in Cobol te laten draaien. Als Java (of een andere taal) beter zou zijn om die 15500 batches per dag hier te laten draaien in het bedrijf, hadden ze al lang een overstap overwogen. Heck, ik heb op een C# project gezeten waar we ook batches hadden en men overwoog om de overstap naar Cobol te maken voor die batches. Omwille van efficientie, snelheid, minder complexiteit, ...

BillyTheClit schreef op dinsdag 16 december 2014 @ 11:33:
Ik vind hier niks mis mee als je zin hebt om te gaan programmeren.
Je hebt op dat vlak niks te verliezen, dat is mogelijk anders bij mensen die OO-talen andere high profile IT achtergronden meebrengen.
Als je binnen enkele jaren zin hebt in meer/ander programmeerwerk was dit een goeie testfase.
Als je er geen zin meer in hebt (of de vraag is er niet meer) dan kan je nog altijd terug naar iets anders en heb je die ervaring erbij.
Ik zie toch nog behoorlijke vraag naar Cobolprofielen en ze worden niet slecht betaald, juist omdat ze moeilijk te vinden zijn.

QFT

[Mohius]

Bij mijn werkgever heeft men het noodzakelijk gevonden om een aantal jaar terug alle Cobol programmeurs er uit te werken. Veel zijn vertrokken, een enkeling heeft zich laten omscholen. Dit jaar kwamen er ineens een aantal groten klanten met de vraag of wij Cobol programmeurs beschikbaar hadden en die waren er er natuurlijk niet. Uiteindelijk heeft met het gat gevuld met een aantal Cobol programmeurs die, met een aanbod van heel veel geld, uit hun pre-pensioen of pensioen gehaald zijn om nog een aantal jaar Cobol te kloppen.

In Nederland draaien bijna alle banken, verzekeringsmaatschappijen en pensioenfondsen nog (gedeeltelijk) op Cobol. IBM heeft een aantal jaren terug het aantal mainframe types teruggebracht naar 2. Momenteel is de mainframe bij IBM weer het meest verkopende produkt.

Zoals hierboven reeds gezegd is, de mainframe en Cobol gaan voorlopig nergens heen omdat er geen reden is om hele systemen te vervangen die naar behoren functioneren en zelden storingen hebben. Iets wat ik als .Net programmeur nou niet bepaald kan zeggen van .Net/Java etc.

[RemcoDelft]

ElkeBxl schreef op dinsdag 16 december 2014 @ 11:10:De kosten om deze systemen uit te faseren hebben ze ooit geschat op meer dan 20.000 mandagen als ik het mij goed herinner (het was in ieder geval enorm hoog).

20.000 mandagen is toch helemaal niet zo hoog? Dat is zeg maar 100 manjaar, als je dure externen inhuurt kost dat je 30 miljoen. Dat lijkt me een overzichtelijk bedrag voor een grote verzekeraar, zeker als het geheel er toekomstbestendiger door wordt.

[Verwijderd]

Mohius schreef op dinsdag 16 december 2014 @ 11:52:
...

Zoals hierboven reeds gezegd is, de mainframe en Cobol gaan voorlopig nergens heen omdat er geen reden is om hele systemen te vervangen die naar behoren functioneren en zelden storingen hebben. Iets wat ik als .Net programmeur nou niet bepaald kan zeggen van .Net/Java etc.

Volgens mij is een goede reden dat er bij de pensioenfondsen, verzekeringsmaatschappijen en banken tegenwoordig een hoop nodig is kwa flexibiliteit. De wetgeving vraagt bijvoorbeeld steeds vaker om veranderingen, en de consumenten willen tegenwoordig ook meer zelf-service via het internet.

Dat is een reden die ik zie waardoor deze instellingen bezig zijn hun basissystemen om te zetten naar een platform op een andere programmatuur.

[farlane]

RemcoDelft schreef op dinsdag 16 december 2014 @ 12:14:
20.000 mandagen is toch helemaal niet zo hoog? Dat is zeg maar 100 manjaar, als je dure externen inhuurt kost dat je 30 miljoen. Dat lijkt me een overzichtelijk bedrag voor een grote verzekeraar, zeker als het geheel er toekomstbestendiger door wordt.

Welke omgeving/taal is volgens jou toekomstbestendiger dan COBOL dan? Voor het door jouw genoemde bedrag kun je heel wat COBOL programmeurs opleiden, zonder het risico wat een rewrite oplevert.

[ElkeBxl]

RemcoDelft schreef op dinsdag 16 december 2014 @ 12:14:
[...]

20.000 mandagen is toch helemaal niet zo hoog? Dat is zeg maar 100 manjaar, als je dure externen inhuurt kost dat je 30 miljoen. Dat lijkt me een overzichtelijk bedrag voor een grote verzekeraar, zeker als het geheel er toekomstbestendiger door wordt.

Kan zijn dat het hoger was, het was in ieder geval minstens 20k mandagen Het was ook een schatting die ze hadden gemaakt en ze wouden vooral het risico niet nemen. Want zou het systeem dan wel toekomstbestendiger worden... Zou het stabieler zijn? Werkt het minstens even snel? Kan het voor dezelfde kost als een mainframe evenveel batches en data verwerken? Is het de kost wel waard dus? Hun conclusie was neen. Zoals terecht opgemerkt door farlane, met dat geld zouden ze wel heel veel Cobol programmeurs kunnen opleiden en betalen ze direct ook wat van de werkingskosten van hun mainframes.

Verwijderd schreef op dinsdag 16 december 2014 @ 12:16:
[...]


Volgens mij is een goede reden dat er bij de pensioenfondsen, verzekeringsmaatschappijen en banken tegenwoordig een hoop nodig is kwa flexibiliteit. De wetgeving vraagt bijvoorbeeld steeds vaker om veranderingen, en de consumenten willen tegenwoordig ook meer zelf-service via het internet.

Verandering in een wet is hier meestal niet veel werk (toch als het gaat over percentages of een iets andere procedure voor iets). De juiste modules aanpassen en compileren, user/batch testen doen en met de volgende release mee.

En die self-service via het internet zijn we volop mee bezig. Maar dat is dan vooral front-end dat we zaken aanpassen. Zoals bijvoorbeeld van die automatisch aanpassende layouts voor smartphone, tablet, laptop, ... Hier bij ons heeft dat haast niets met de business logic te maken door een sterke scheiding tussen front-end en back-end, dus blijven we nog altijd dezelfde Cobol modules aanroepen. De front-end evolueert dus mee met de gebruiker, de back-end bijna enkel met de veranderingen van de wetgever.

[Verwijderd]

ElkeBxl schreef op dinsdag 16 december 2014 @ 12:27:

[...]

Verandering in een wet is hier meestal niet veel werk (toch als het gaat over percentages of een iets andere procedure voor iets). De juiste modules aanpassen en compileren, user/batch testen doen en met de volgende release mee.

En die self-service via het internet zijn we volop mee bezig. Maar dat is dan vooral front-end dat we zaken aanpassen. Zoals bijvoorbeeld van die automatisch aanpassende layouts voor smartphone, tablet, laptop, ... Hier bij ons heeft dat haast niets met de business logic te maken door een sterke scheiding tussen front-end en back-end, dus blijven we nog altijd dezelfde Cobol modules aanroepen. De front-end evolueert dus mee met de gebruiker, de back-end bijna enkel met de veranderingen van de wetgever.

Tsja, ik ken jouw situatie niet, maar dit is niet het geval bij het grote pensioenfonds dat ik ken, waar de wettelijke wijzigingen behoorlijk wat impact hadden en het oude Cobol platform behoorlijk inflexibel is.

Daarnaast is een sterke scheiding tussen frontend en backend nogal standaard, maar moeten de webservices of wat je ook gebruikt om de data te ontsluiten naar de frontend dus wel voldoen aan de nieuwe eisen van het nieuwe zelf service platform dat gebouwd moet worden.

Ik bedoel dit niet als kritiek tegen Cobol, daarvoor weet ik er te weinig van. Maar dit is wat ik in de praktijk heb gezien.

[fungho]

Veel ICT projecten mislukken omdat er eerst gouden bergen worden beloofd en vervolgens blijkt dat de beloften niet kunnen worden waargemaakt.

De organisatie waarvoor ik werk heeft zich gespecialiseerd in het moderniseren van bestaande legacy (ERP) software, gemaakt met COBOL, maar ook RPG, FoxPro, etc.

Dit zou een goed alternatief zijn: Op die manier kan je werkgever toch afscheid nemen van zijn/haar COBOL programmatuur, maar het is zelfs mogelijk alle goede onderdelen daaruit te gebruiken als startpunt voor de nieuwe, gemoderniseerde, software.

Om te zorgen dat dit project niet faalt, en ervoor te zorgen dat als het dat toch doet dat het geen schade brengt voor jouw werkgever, wordt bovenstaande eerst kosteloos bewezen.

Ik wil dit niet te commercieel maken, maar als je denkt dat dit interessant kan zijn voor jouw werkgever dan mag je me altijd even een berichtje sturen.

[ElkeBxl]

Verwijderd schreef op dinsdag 16 december 2014 @ 12:41:
[...]
Tsja, ik ken jouw situatie niet, maar dit is niet het geval bij het grote pensioenfonds dat ik ken, waar de wettelijke wijzigingen behoorlijk wat impact hadden en het oude Cobol platform behoorlijk inflexibel is.

Daarnaast is een sterke scheiding tussen frontend en backend nogal standaard, maar moeten de webservices of wat je ook gebruikt om de data te ontsluiten naar de frontend dus wel voldoen aan de nieuwe eisen van het nieuwe zelf service platform dat gebouwd moet worden.

Ik bedoel dit niet als kritiek tegen Cobol, daarvoor weet ik er te weinig van. Maar dit is wat ik in de praktijk heb gezien.

Ik kan me best wel voorstellen dat er bepaalde wettelijke wijzigingen zijn die serieuze impact kunnen hebben. Ik ben het nog niet tegengekomen dat bij zo'n wijziging Cobol inflexibel zou zijn. Maar ik zit dan ook maar op 1 dienst, wie weet hebben ze bij andere soorten verzekeringen wel issues.

Bij ons is het zo dat de front-end ASP.Net is en dat die een soort van Cobol interfaces aanroept aan de hand van copybooks. Dat is dan vooral een definitie van wat voor soort data er gecommuniceerd wordt en eventueel welk soort actie er met die data moet gebeuren (add, edit, delete, ...) al kan dit ook opgesplitst zijn over meerdere interfaces (hangt van de complexiteit af). Wij hebben interfaces die zich enkel bezighouden met ophalen van data en andere die zich puur bezig houden met updaten. Die Cobol interfaces delegeren dan alles door naar andere modules enzo. Best wel stevige structuur die blijkbaar goed genoeg werkt. Het is zeer zelden dat die interfaces moeten aangepast worden en als het gebeurt, is de impact eerder klein gelukkig. Die omschakeling naar zo'n self-service systeem lukt nu toch goed zonder enige wijziging in de interfaces, hopelijk blijft het zo

En ik pak het niet op als kritiek hoor Elke tech heeft zeker z'n voor- en nadelen en moet gewoon op de juiste plaats gebruikt worden. Ik zie mezelf niet fulltime Cobol programmeur worden in de toekomst (ik keer terug naar de .Net wereld binnen het bedrijf in januari) maar ik zie wel dat het heel goed werkt hier (voor zover ik toch in aanraking kwam met andermans code enzo... Wie weet wat hier bestaat van gedrochten...).

fungho schreef op dinsdag 16 december 2014 @ 13:24:
De organisatie waarvoor ik werk heeft zich gespecialiseerd in het moderniseren van bestaande legacy (ERP) software, gemaakt met COBOL, maar ook RPG, FoxPro, etc.

Naar wat moderniseren jullie dan?

[fungho]

@ElkeBxl:

Dat is een goede en terechte vraag, maar deze laat zich niet zo gemakkelijk beantwoorden omdat de manier waarop wij software realiseren anders is dan traditioneel programmeren. Wij werken modeldriven, dus we modelleren i.p.v. dat wij programmeren. Hieronder zal ik beknopt proberen duidelijk te maken wat dit betekend.

Datamodel, GUI model, proces modellen, etc. worden gemodelleerd. Vanuit het datamodel genereren wij een database, bijvoorbeeld op SQL Server, Oracle of DB2.

Echter wordt de frontend niet gegenereerd, maar die is al aanwezig. De frontend is een abstracte GUI applicatie die runtime het model interpreteert en zich dan opbouwt. Kortom, het model stuurt de GUI-componenten aan.

Deze abstracte GUI's zijn beschikbaar voor Win/Web/Mobile. Zo wordt ervoor gezorgd dat applicaties altijd via de modernste technologieën beschikbaar zijn. Ieder model is klantspecifiek en de GUI's zijn standaard. Het model staat dus ook echt los van de technologie waarin de frontend is gerealiseerd.. De verschillende GUI's communiceren met één model, allemaal tegelijk indien dit de wens is.

Windows: C#.NET
Web: ASP.NET / HTML5
Mobile: Native apps m.b.v. HTML5

Voor specifieke business rules, zoals een validatie of een complexe berekening, maken wij gebruik van code in T-SQL, C# of Java. Deze code wordt in zogenaamde code-templates geschreven welke vervolgens in het model worden gekoppeld, zodat ze uiteindelijk op de juiste plek in de feitelijke software terechtkomen.

Wanneer we (legacy) software moderniseren leiden wij geautomatiseerd modellen af uit de structuren van het bestaande systeem. Deze modellen vormen dan het startpunt van het project.

Mocht je meer vragen hebben dan hoor ik het wel.

[ Voor 9% gewijzigd door fungho op 16-12-2014 16:53 ]

[Verwijderd]

Wederom bedankt voor alle reacties! Ook interessant om te horen dat er gemixte meningen zijn over de toekomst van COBOL. Ik zie het sowieso niet als een eindhalte, daarvoor ben ik veel te jong. Daarnaast heb ik een achtergrond in de bedrijfskunde en procesmanagement dus het zal niet lang duren voordat ik de hands-on ervaringen wil gebruiken voor meer project achtige zaken. Tzt zal ik vast ook wel een modernere taal oppakken, dat lijkt mij met name interessant voor bedrijven die een switch willen maken maar nu nog op COBOL draaien.

@ElkeBxl: goed om te horen dat de basis snel onder de knie te krijgen is, ook bij diverse achtergronden. Ik zal ook eens kijken naar de opleider die je noemde, want ik wil wel een gedegen basis opdoen.

[whoami]

ElkeBxl schreef op dinsdag 16 december 2014 @ 11:10:
[...]
[...]

Ik verwacht ook niet dat het snel zal uitsterven. Toen ik hoorde dat ze bij ons de versie uit 1985 draaien stond ik daar van "serieus?!"

Is dat ook niet de laatste COBOL standaard, COBOL 85 ? Of zijn er dan sindskort toch nog nieuwe versies gekomen ?
Ik heb hier nog ergens de 'ebbinckhuijsen COBOL 85 bible' liggen. Dat was één van de boeken de we tijdens mijn opleiding (1997) moesten aankopen.

[Nocturno]

Ik heb jaren bij een bedrijf gewerkt dat voornamelijk met cobol werkte, maar dat is met de komst van internet ook de ondergang van het bedrijf gebleken. Toen eenmaal het grootste deel van de orders via de webshop binnenkwam bleek de cobol mainframe backend toch het probleem.
Het probleem zat hem vooral in de ontwikkelsnelheid en de legacy van 30 jaar programmeren.
een "simpele" aanpassing werd in een team met 20+ ontwikkelaars al snel op 3 maanden werk geschat (300 programma's aanpassen vanwege een db schema wijziging bijvoorbeeld). Ik zat zelf in het (kleine)Java team en merkte toch dat wij dat een stuk sneller konden.
Huidige business gebruikers kunnen zo lang niet meer wachten met de markt die zo snel gaat.
Batchverwerking is leuk voor data die verzameld en bewerkt moet worden, niet voor realtime verwerkingen zoals je nu eenmaal vaak nodig hebt bij b.v. webshops.

Cobol zal nog jaren effectief en te duur om te vervangen blijken bij banken en verzekeringen, maar dat houdt imho op een gegeven moment ook op.

[ElkeBxl]

fungho schreef op dinsdag 16 december 2014 @ 16:49:
Wij werken modeldriven, dus we modelleren i.p.v. dat wij programmeren.

Interessant. Bedankt voor de uitleg

Verwijderd schreef op dinsdag 16 december 2014 @ 17:02:
@ElkeBxl: goed om te horen dat de basis snel onder de knie te krijgen is, ook bij diverse achtergronden. Ik zal ook eens kijken naar de opleider die je noemde, want ik wil wel een gedegen basis opdoen.

Het is zeker mogelijk het snel onder de knie te krijgen Maar het komt er op neer dat je veel moet oefenen, iets wat voor elke taal het geval is. Eens een boek lezen of naar een presentatie luisteren kan interessant zijn maar hands-on experience zorgt voor een snellere kennis opbouw

whoami schreef op dinsdag 16 december 2014 @ 17:22:
[...]
Is dat ook niet de laatste COBOL standaard, COBOL 85 ? Of zijn er dan sindskort toch nog nieuwe versies gekomen ?
Ik heb hier nog ergens de 'ebbinckhuijsen COBOL 85 bible' liggen. Dat was één van de boeken de we tijdens mijn opleiding (1997) moesten aankopen.

Blijkbaar is er ondertussen ook een 2002 en 2014 versie. Belangrijkste daarin is dat de 2002 objecten introduceerde in Cobol en 2014 voor zaken als method overloading zorgde. Maar bij ons hebben ze in ieder geval nog niet eens overwogen om te upgraden naar de 2002 versie, 85 rules blijkbaar

Nocturno schreef op dinsdag 16 december 2014 @ 22:00:
Het probleem zat hem vooral in de ontwikkelsnelheid en de legacy van 30 jaar programmeren.
een "simpele" aanpassing werd in een team met 20+ ontwikkelaars al snel op 3 maanden werk geschat (300 programma's aanpassen vanwege een db schema wijziging bijvoorbeeld).

Zoiets kan je in elke taal meemaken. Bij ons is dat mooi opgelost: elke DB tabel heeft een Cobol module om CRUD operaties uit te voeren. Is er update in een tabel zoals een extra column, dan moet je enkel die module aanpassen. Ga je andere zaken veranderen zoals tables verwijderen of relaties veranderen dan is het natuurlijk complexer... Een wijziging in DB kan in elke taal miserie zijn, veel hangt af hoe de boel in mekaar gestoken is en er abstracties zijn.

[Soultaker]

ElkeBxl schreef op woensdag 17 december 2014 @ 08:30:
Het is zeker mogelijk het snel onder de knie te krijgen Maar het komt er op neer dat je veel moet oefenen, iets wat voor elke taal het geval is. Eens een boek lezen of naar een presentatie luisteren kan interessant zijn maar hands-on experience zorgt voor een snellere kennis opbouw

IMO is het beide van belang. Als je de hele tijd dezelfde soort code zit te schrijven, leer je niet veel meer. Je ontdekt juist nieuwe technieken door boeken/internetartikelen/handleidingen e.d. door te nemen (en ook door aan nieuwe codebases blootgesteld te worden).

[ElkeBxl]

Soultaker schreef op woensdag 17 december 2014 @ 10:02:
[...]

IMO is het beide van belang. Als je de hele tijd dezelfde soort code zit te schrijven, leer je niet veel meer. Je ontdekt juist nieuwe technieken door boeken/internetartikelen/handleidingen e.d. door te nemen (en ook door aan nieuwe codebases blootgesteld te worden).

I stand corrected