Manglen på mainframe-folk truer: Unge gider ikke Cobol
Historien er hørt før, men er ikke blevet mindre aktuel: De fleste mainframe-udviklere er blevet grå i toppen og nærmer sig pensionsalderen. Og der står ikke ret mange klar til at overtage opgaverne.
Derfor frygter finanssektoren, at det snart bliver et problem at finde Cobol-kyndig arbejdskraft, for interessen hos de unge er dalende. Det skriver Finansforbundets nyhedsbrev Finans.
Et kursus i mainframe-teknkologi, som blev oprettet på DTU for fem år siden i samarbejde med IBM, tiltrak i begyndelsen 30 studerende om året. Men nu er der kun omkring ti interesserede i emnet pr. gang, hvilket ikke er nok til at oprette kurset. De unge vil hellere kaste sig over mobil-applikationer, lyder det fra universitetet.
Bankernes EDB Central (BEC), der driver it for 53 pengeinstitutter, vil derfor genoptage et trainee-program, der tidligere har givet nye hænder til mainframe-driften. Her skal Java-programmører oplæres i Cobol og mainframe-drift.
»Cobol er jo ikke så svært at lære, men når man så skal have mainframes til at arbejde sammen med andre systemer, så bliver det hurtigt kompliceret. Derfor er det også svært at lave ekstern uddannelse i det,« siger HR-direktør Hans Laurits Thaning til Finans.
BEC har omkring 200 ansatte, der arbejder med udvikling til mainframes, og langt de fleste er godt oppe i årene. Samme problem har Skandinavisk Data Center (SDC), som har 63 banker som kunder. Her er der 230 mainframe-folk ansat.
- emailE-mail
- linkKopier link
...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
Fortsæt din læsning
- Sortér efter chevron_right
- Trådet debat
På mig lyder det fuldstændigt forkert at man skal spilde sin tid på Cobol under et studie. Mainframes måske, men hvis du kan programmere i Java, Algol, Pascal, Fortran, C, Ada, SQL eller lignende sprog, så skulle tiden det tager at blive nogenlunde ferm til Cobol ikke tage så forfærdeligt lang tid.
Jeg synes personligt at hele ideen om at man skal "Have haft et kursus for at kunne arbejde med X" er en tosset ide. Hvis BEC har så meget behov for Cobol, så vil jeg anbefale at man selv laver det arbejde der skal til for at kunne tage unge nyuddannede og så også oplære dem i Cobol. Men se i øjnene at der nok skal en klækkelig sum penge til at overbevise en ung person at han skal satse på et system der grundliggende set er forældet og hvor der er få jobmuligheder.
Måske det var på tide at komme af med Cobol-programmerne når nu arbejdskraften svinder ind.
Det har man skam også allerede gjort i stort omfang. Jeg startede som trainee i BEC da jeg var 22 og nyuddannet og her 3 år efter koder jeg stadigvæk massere af Cobol og java.Hvis BEC har så meget behov for Cobol, så vil jeg anbefale at man selv laver det arbejde der skal til for at kunne tage unge nyuddannede og så også oplære dem i Cobol.
Er selv snart færdig med mit studie og kunne rigtig godt tænke mig at arbejde med mainframes (programmering, drift mm.) men der er ingen mulighed for at komme i gang med det.
Jeg ved at Danske Bank ansætter folk uden programmeringserfaring blot for at sende dem på 3 måneders COBOL kursus.
Jeg ved at Danske Bank ansætter folk uden programmeringserfaring blot for at sende dem på 3 måneders COBOL kursus.
Det er ikke helt rigtigt. Danske Banks kursus i COBOL er 4 eller 5 dage. De tre måneder du sikkert har hørt om dækker over en hel bunke kurser om Danske Banks måde at gøre tingene på.
Jeg var selv i Danske Bank i en kort periode, men kunne ikke affinde mig med at man der ser programmering som produktionsarbejde og ikke som noget kreativt.
Det er kulturen omkring hvordan man udvikler i virksomheder der bruger mainfraimes og COBOL der skræmmer folk ikke teknologierne - efter min mening.
Der er alt for mange programmeringssprog til, at firmaer kan forvente, at det sprog, de selv bruger, er dækket i et IT-studie, også selv om det sprog er (eller har været) nok så udbredt. Hvis vi ser på sprog, der er eller har været mainstream, så omfatter det i hvert fald følgende: Fortran, Algol, LISP, BASIC, APL, COBOL, PL/1, Pascal, C, C++, C#, Java, Modula, Delphi, Ada, Javascript, PHP, Perl, Python, Ruby, Smalltalk, Snobol, Simula, Prolog og flere andre. Dertil kommer et antal sprog, der er udbredte på en enkelt specifik, men populær, platform, f.eks. Objective C, eller indenfor en bestemt branche, f.eks. Graphtalk.
Det er ganske enkelt for mange til at det giver mening at undervise i alle. Men det skulle heller ikke være nødvendigt sålænge man er nogenlunde fortrolig med de fleste af følgende sprogelementer: Statiske typer, dynamiske typer, typeinferens, nedarvning, dynamiske metodekald, anonyme funktioner (closures), virkefelter (scopes), tabeller, structs/records, unions/sumtyper, tråde, løkker, forgrening, rekursion, moduler, indkapsling manuel lagerstyring (malloc/free), automatisk lagerstyring (garbage collection).
Hvis man har det, er det i reglen ikke noget stort problem at lære et nyt sprog.
Her er mine fordomme om et job som skitseret i artiklen:
Nuvel, man får en god løn. Til gengæld skal man sidde of skrive glue code eller patche andre folks mere eller mindre vellykkede sparsomt dokumenterede projekter i et antikveret sprog, der ikke har nogen form for charme eller interessante konstruktioner. Jeg vil ikke have et job, hvor jeg skal overveje om lønnen er smerten værd.
Jeg ved ingenting om hverken COBOL eller mainframe-programmering, og det er jeg ikke ene om, men jeg tror ikke det kun er mig, der er fordomsfuld. Derfor kunne branchen måske prøve at fortælle de studerende, hvorfor der i virkeligheden er tale om et udfordrende, spændende og kreativt job. Talentfulde folk kan jo få en god løn hvorsomhelst.
Det er lidt trist, at Version2 omtaler et Cobol-kursus på DTU - for det har aldrig eksisteret. Det må I kunne gøre bedre Version2!!
Det rette kursus-indhold fremgår af Finansforbundets nyhedsbrev: "IBM har derfor i fem år været med til at afholde kurser på DTU. Formålet er at introducere unge for mainframe-universet, så de i fremtiden ikke bare afviser teknologien som forældet."
Kurset (som i øvrigt har udviklet sig over tid) giver kun en ganske kort introduktion til COBOL bl.a. mange andre emner (se evt. http://www.kurser.dtu.dk/02337.aspx?menulanguage=da ). Jeg tvivler desværre på, at kendskabet til det kursus er blevet bedre siden min tid på DTU - dvs. det lever primært inde i kursusbasen. Hvis man ikke når bredere ud og får fremhævet platformens styrker, så tror da pokker ingen tager kurset.
Der er i øvrigt ikke nogen raket-videnskab at drifte eller programmere til en mainframe. Det vil de fleste datamatikere, IT-ingeniører eller dataloger kunne. Jovist, det er anderledes og der er særlige teknikker der skal læres for man kan udnytte (alle) platformens styrker. Men gælder det ikke alle platforme og sprog?
Her i eftereåret blev der gjort lidt reklame for kurset på CampusNet, der lige med nød og næppe blev gennemført grundet lavt deltagerantal (læs på dispensation).
Ærgeligt - det er et super kursus, der giver et indblik i en ekstremt virtuel, kompleks, stabil og alsidig platform, der absolut er på omgangshøjde med konkurrenterne, samtidigt med at den er næsten sygelig bagudkompatibel.
MHT COBOL, så er det en rar mulighed men ikke livsnødvendigt - jeg kan end ikke huske nogen COBOL eksempler fra kurset. Man kan jo køre alt - ikke mindst fra en Linux VM - idag er det nærmest en platform uden begrænsninger, men jaget af fordomme.
SQL (Structured Query Language) og den bagvedliggende teknik: RDBMS (Relational Data Base Management System) udgør det eneste programmeringssprog som der er lovgivet imod (I Danmark, Registerloven 1978, tilsvarende i mange andre lande).Så det her er rimeligt heftigt stof - det har været åbenbart at det virkeligt kunne ændre noget i samfundet, derfor den lovmæssige begrænsning. Sagt uden at tage stilling til Registerloven - jeg konstaterer blot at en tilsvarende ære ikke er overgået noget andet programmeringssprog. Man kan så indvende at sammenhængen ikke er åbenlys: Der står i Registerloven ikke noget om SQL, der står blot at 'du må ikke samkøre registre'. Men det er altså et grundlæggende aspekt i SQL / RDBMS at samkøre registre, det er det som 'R'et i RDBMS står for. Og så er der også en tidsmæssig sammenhæng: Oracle lancerede - som de første - et RDBMS + SQL i 1977. Registerloven kom som sagt 1978. Oracle udgør i øvrigt endnu et bevis for at SQL er heftigt: Larry Ellisons formue vidner om en vis form for succes.
Så valg af programmeringssprog er ikke bare et spørgsmål om at finde frem til programmørens komfort-zone. Der står væsentligt mere på spil.
SQL er ikke relevant hvis drømmen er at programmere aps til Android. SQL er et sprog til håndtering af meget store administrative systemer. Ikke til håndtering af brugergrænsefladen, men 'core'-systemet, bankens konto-håndtering fx. De systemer som det nutidige samfund bygger på.
Det her er et meget væsentligt aspekt af COBOL, det absolut væsentligste: SQL og COBOL passer sammen som hest og vogn, SQL og JAVA passer sammen som en fisk og en cykel. Det sidste er selvfølgeligt en vel voldsom påstand. Der programmeres masser af administrative systemer i JAVA + SQL, og de virker udmærket, billetterne bliver reserveret, skatten bliver opkrævet etc. Problemet er at ideen i et objektorienteret sprog (som JAVA) og ideen i SQL principielt er uforenelige. Objektorienterede sprog har som ideal at indkapsle data og funktionalitet: Du læser og skriver ikke data, du tilgår dem via det objekt de indgår i. Programmering i objektorienterede sprog går ud på at skabe acces-metoder, data må kun tilgås via disse fastlagte metoder. Det er et rigtigt stærkt koncept hvis man ikke har sine data i en RDBMS. Hvis man har sine data i en RDBMS, er det et ligegyldigt koncept, blot en omvej, at indkapsle RDBMS data i nogle metoder i et objekt. Indkapsling betyder at den sproglige styrke og fleksibilitet i SQL / RDBMS bliver skjult.
Objektorienteret programmering er et stort fremskridt i forhold til almindeligt data-roderi - som fx i et gammelt COBOL program. Tilsvarende er RDBMS er et stort fremskridt i forhold til objektorienteret programmering: Data gøres til fælles ressource for organisationen, håndtering af data sker via et dertil forfinet sprog: SQL, og opbyning af disse dataobjekter i RDBMS'en sker på en ensartet måde via et DDL-sprog, et Data Defenition Language. Det er så stort og så smukt at man i starten af 1990'erne mente at RDBMS + SQL ville blive alt, og programmering intet. James Martin var profeten for dette synspunkt. (Som er forkert).
Den opmærksomme læser vil måske på nuværende tidspunkt fornemme at IBM og DB2 og mainframen tårner sig op i baggrunden. Det er visionen om den store edb-organisation, den komplekse arbejdsdeling mellem databasespecialister, SQL-performance-specialister, programmører og andre faggrupper. Stort, tungt, dyrt og svært at håndtere. Men fabelagtigt effektivt når det svinger.
COBOL er ikke den største opfindelse inden dåseøllet. Men det er et håndterbart sprog med en betydelig udbredelse, og det spiller godt sammen med SQL - godt i den forstand at den sproglige styrke og fleksibilitet i SQL ikke hæmmes. I det stykke er COBOL bedre end fx. JAVA. Derfor programmeres størsteparten af verdens administrative systemer i COBOL. Hvis man som programmør har et godt kendskab til COBOL og til SQL/RDBMS kan man godt komme ind i en faglig og indtjeningsmæssig god situation. Hvis 'de unge mennesker' ikke ønsker at at stifte bekendskab med denne verden, så udgør det helt klart et problem.
Kunne du uddybe hvordan COBOL spiller bedre sammen med SQL end Java? Vi er helt enige om, at det ikke altid er lykken at anvende en objektorienteret model ovenpå en relationel database, men Java tvinger dig jo ikke til at kode objektorienteret, det er jo til syvende og sidst blot en OO overbygning på et proceduralt C-style sprog. Er der særlige konstruktioner i COBOL, der gør det mere egnet til SQL-integration end ethvert andet proceduralt sprog?COBOL er ikke den største opfindelse inden dåseøllet. Men det er et håndterbart sprog med en betydelig udbredelse, og det spiller godt sammen med SQL
Jonas: Jo - der er intet i vejen for at programmere i Java, også i SQL-tunge core-systemer. Så hvis du programmerer JAVA i COBOL-style (dvs proceduralt) kan du programmere SQL-tunge core-systemer - men hvor blev problemet med COBOL så af? Hvad er der egentligt galt med COBOL? Hvorfor skulle vi allesammen hoppe på det forbikørende tog? Der er nærmere noget galt med JAVA når en så hypet facilitet som objektorientering må fravælges for at lave ordentlige programmer på det her område. Hvor 'område' altså er administrative core-systemer. Desuden:
Et nutidigt COBOL program indenfor administrative core-systemer består af typisk måske 60% SQL-kodning og 40% procedural kodning. Derfor er det vigtigt med et sprog - som COBOL - som ikke blander sig meget i SQL-delen, men blot muliggør en sekventiel beskrivelse af behandlinger og selektioner som dels foregår i SQL, dels i sproget selv. Da SQL er et non-proceduralt sprog, bliver opgaven for 'det egentlige programmerings-sprog' at specificere den procedurale del af logikken.
Så min pointe, mit argument for at 'COBOL is the language of the future' (mindre kan dog gøre det), er at COBOL har et 'ikke-invasivt' forhold til SQL. SQL-koden i et COBOL program står relativt rent, syntaksen i SQL er ikke opblandet med COBOL-brokker.
I JAVA: Hvis man ikke-objektorienteret vil kalde SQL fra JAVA, så opretter man en streng, putter noget kodning i SQL-syntax ind i strengen, og opretter og kalder en instans af et standard-objekt som får adresseret variable i spørgsmål og svar og som får udført SQL-kaldet. Det er jo ikke slemt.
I COBOL:
if hoej-cigargfoering move 'SALES' to w-department exec sql update ourdb2.employee set salary = salary * 1.05 where department = :w-department end-exec if sqlcode not = 0 call 'det-her-er-gaaet-i-udo' using... end-if end-if
Min pointe er at SQL-kaldet i COBOL står i ren SQL-syntax, og at beskrivelsen i COBOL-programmet er sekventiel: først undersøger man det, så gør man det, så gør man det... uanset om handlingen er specificeret i SQL eller i COBOL. Der er ikke nogen 'støj' i det område i programmet hvor man switcher fra procedural til imperativ (non-procedural) kodning.
Og formået med programmering er vel at beskrive en problemløsning på den simpleste og nemmest læselige måde?
PS: COBOL har udviklet sig meget i de senere år (med bevaret bagudkompatibilitet), og har fx. udmærkede faciliteter til XML-håndtering, til UTF-8 håndtering etc. Det er selvfølgeligt ikke nok at sproget ikke blander sig i andre sprog, det skal også selv kunne gå uden krykker.
Tak for forklaringen, Morten.
Jeg må nok erklære mig enig med Henrik i at det er svært at sige nej til økosystemet omkring en moderne platform som Java, selvom SQL-integrationen direkte i sproget bestemt er en væsentlig force for COBOL.
Det er rigtigt, at der er et impedance mismatch imellem OOP og relationelle databaser. Det betyder, at man ikke kan lave et fuldstændigt transparent persistens-framework, hvis man vil benytte en RDBMS som backend, og at man bliver nødt til at tage nogle valg undervejs med hensyn til at mappe det ene paradigme til det andet.
Det er dog ikke ensbetydende med, at "en så hypet facilitet som objektorientering må fravælges for at lave ordentlige programmer på det her område". Eksempelvis gør RDBMS -> objekter koden langt mere velegnet til automatiserede tests uden nødvendigvis at have en fuldt funktionsdygtig database som backend. En anden fordel er, at man kan bruge Javas meget rige 3. parts økosystem. For eksempel sad jeg for nyligt med et par små opgaver, hvor jeg skulle lave fuldtekst-søgning i en database, og hvor jeg skulle lave unicode sortering i forskellige eksotiske sprog. Så hiver man bare fat i Lucene og ICU4J, og så er det lavet på et par dage frem for at skulle lave sin egen custom database-løsning, som "støjer" i databasen, bliver vanskelig at portere, vanskelig at lave om, træls at teste og formentlig både langsommere og dårligere end Java alternativet, hvor folk har brugt årevis på at afpudse disse eksterne frameworks.
Min personlige mening er at Cobol har den bedste integration til SQL jeg nogensinde har mødt. De fleste andre sprog jeg har leget med (C#, C++, Java, mfl) kræver enten IDL eller andre hacks for at opnåe typesikkerhed - det kommer gratis med Cobol.
Morten viser det glimrende i hans indlæg, hvor databasefeltet department bliver udfyldt med værdien af w-department feltet. En egenskab jeg kun har mødt i LINQ udover Cobol.
At Henrik så mener at det er svært at lave automatiserede tests er måske en valid pointe - men samtidig et problem der vil opstå i alle systemer der baserer sig på database indhold. Automatiseret test er en kunstform der kræver et design der er moden til det - uanset sproget.
Nu er det jo sådan med børn, at de på et tidspunkt vokser en over hovedet. Og power systemerne er i høj grad børn af z, hvor de har arvet rigtig rigtig meget .)=
// Jesper
Ja teknologien i Power systemer er baseret på mainframen. Jeg havde fornøjelsen af lege lidt med deres virtualiseringsfunktioner på en 2 CPU Power5 i slutningen af 2007. Teknologien er virkelig imponerence med mulighed for at allokere 0.1 CPU til en virtuel instans. Men zEnterprise har endnu engang rykket mainframe teknologien.
På et tidspunkt tilbød IBM et kursus i installation af Linux på Power5 1U enheder med to CPU'er, ram og harddiske til blot 38.000 Kr inkl. Power5 enheden og 1 års licens til SLES. Desværre havde jeg ikke lige den mængde ekstra kontanter på det tidspunkt.
Ja, POWERVM rocks. Dog har den ikke så mange fede features som WMware, men når det kommer til performance, scalability og security så er den i en lidt anden boldgade.
POWER kan sku ikke købes for menneske penge mere. Det er som med System z, for folk der har behov for big computing, og har forstand på at regne med TCO.
POWER7 chippen er så mindst en faktor 8 hurtigere mht. throughput end POWER5, og indeholder som z også Decimal Floating Point unit og kan skalere til x4 flere chips. Så det er lidt en anden boldgade.
Men til hjemmebrug så er der sku ikke noget der slår en x86 linux box med de virtualizerings ting som man kan få gratis der.
// Jesper
På deres hjemmeside hjemmeside lister IBM et Power7 system med 4 cores 3.0 GHz, 4 GB ram, og storage til under 6000 US$. Det er faktisk mindre en familien betalte for vor første computer i sluthalvfemserne - et system med Windows95 Rev.2 installeret, som det lykkedes ved kontakt til forskellige udviklere også at få til at køre OS/2, så vore børn kunne spille alle de fantastiske spil fra Stardock, som fx Entrepreneur.
@Morten Bøgh:
SQL er ikke relevant hvis drømmen er at programmere aps til Android.
Men den udgave af MacOS X der går under navnet iOS har SQLite som en integreret del af systemet ...
I øvrigt lærte vi da både COBOL og Fortran da jeg gik på datalogi 1 (DIKU) i begyndelsen af 80'erne, men formålet var ikke at lære de pågældende sprog. Men at lære om administrativ databehandling (COBOL) og ændre på en kerne som (når nu den traditionelle kerneopgave, der gjorde »drenge til mænd«, ikke kunne gennemføres som følge af maskinnedbrud) var skrevet i Fortran.
Jeg har siden ikke beskæftiget mig med hverken COBOL eller Fortran. Men derimod Oracle, når nu vi taler om databaser.
Jeg kan ikke bevise at størsteparten af verdens administrative systemer programmeres i COBOL, men det er sandsynligt. Spørgsmålet er allerede belyst i denne her tråd; i indlægget "COBOL is not dead yet :-)" ovenfor. Problemet er også definitionen på et 'administrativt system'. Jeg bruger begrebet 'core-system' og undtager brugergrænsefladen. Det er muligt der ligger flere kodelinier i verdens administrative brugergrænseflader end i verdens administrative core-systemer. Men det er ikke brugergrænsefladen der gør det til en bank, det er core-systemet som håndterer absolut sikker opdatering på tværs af konti mv.
Det er rigtigt at ægteskabet mellem IMS databasen (IBM 1966) og COBOL var den oprindelige basis for fx. den moderne bank. Det ændrer ikke på at COBOL og SQL i dag udgør et virkeligt slagkraftigt makkerpar.
Alle moderne programmeringssprog har et SQL interface. Oracle satser - udover på deres PL-SQL-sprog - på JAVA og JAVA-verden. IBM satser på JAVA som fremtidens mainframe sprog - i samspil med DB2 og SQL. Markeds-førings-trenden er klar. Bagved ligger at 'C'-agtige sprog bare er mere populære (JAVA, C, C++, C# og diverse scripting sprog som bygger på C syntax). Mit anliggende er ikke at rakke ned på diverse programmeringssprog, alle har deres nicher, og nogle er store. Min vinkel er at SQL i visse nicher er et ekstremt vigtigt sprog, og at COBOL har et dejligt fredeligt forhold til indlejret SQL: COBOL blander sig ikke i formuleringerne i SQL.
I derude er meget gode til at rakke ned på COBOL, men hvis det her skal være en diskussion, må I kommentere på min påstand om at objektbegrebet og SQL er i konflikt med hinanden. Det er det der er kærnen i min argumentation for COBOL: SQL / RDBMS flytter dataobjekterne ud som generelle ressourcer for organisationen, styret af generelle værktøjer, og åbne for acces via diverse programmeringssprog. Dvs. de af programmeringssprogene som gerne vil skjule data i egne objekter, forekommer mindre egnede i en sådan verden. Sådanne sprog, såsom JAVA, er absolut anvendelige, men de tilbyder ikke rigtigt nogen merværdi, snarere tværtimod; objektbegrebet udgør en skygge eller noget støj ovenpå datasiden. Det er som at sende rent vand gennem et rensningsanlæg, eller sende sorteret post gennem et nyt sorteringsanlæg. 'I denne forbindelse' vil sige: til core-systemer i adminstrativ databehandling. Det er muligt, ja sandsynligt, at verden går i retning af JAVA også til administrativ databehandling. Dette modbeviser på ingen måde min påstand. Og det er fint - som det er nævnt i debatten - at Groovy / Grails miljøet til JAVA har et meget rent SQL-snit, og skjuler objektbegrebet effektivt, det modbeviser heller ikke min påstand.
At JAVA og SQL ikke er rigtig gode venner, fremgår af No-SQL bevægelsen: Ifølge denne er formålet med en database blot at skabe 'persistence', dvs. at udgøre et sted hvor data kan befinde sig når lyset er slukket. Når systemet spiller, befinder data sig inde i objekterne i JAVA. Dvs argumentet bliver: JAVA har ikke brug for en SQL-database, JAVA har brug for en database, et sted hvor objekter passivt kan opbevares i perioder hvor de ikke accesses. Det er et fint synspunkt hvis man mener at SQL er et ligegyldigt sprog.
Jeg tror at du overså det første ord i Nikolaj's citat: "Derfor".Jeg kan ikke bevise at størsteparten af verdens administrative systemer programmeres i COBOL, men det er sandsynligt.
Som jeg læser det, så betvivler Nikolaj din påstand om kausalitet.
Det er rigtigt, jeg har misset pointen i Nikolajs indlæg: Nikolaj mener at den virkelige årsag til COBOLs udbredelse er at (ledere i) den financielle sektor er stok-konservative, og derfor ikke kan rekrutere kompetente (læs: ikke-COBOL) medarbejdere. Hvordan skal jeg kommentere på det? Nikolaj kører Bodega-argumentet: "Det er fordi alle ledere på pågældende område er dumme". Det her er et forsøg på en diskussion. Hvis Nikolaj mener at hans argumenter skaber bedre kausualitet end mine, så fred være med det.
Er du uenig? Hvis vi ser på Bank, Pension og ForsikringDet er rigtigt, jeg har misset pointen i Nikolajs indlæg: Nikolaj mener at den virkelige årsag til COBOLs udbredelse er at (ledere i) den financielle sektor er stok-konservative
Hvordan du lige kommer til denne slutning (med parantes) ved jeg ikke helt, men forklar venligst., og derfor ikke kan rekrutere kompetente (læs: ikke-COBOL) medarbejdere.
Du kunne jo føre belæg for din påstand som du er blevet bedt om.Hvordan skal jeg kommentere på det?
Øhh - det er vist dig der er lidt langt ude. Hvad du prøver at cirtere mig for har jeg aldrig sagt. Dernæst prøver du nu at afspore, fordi du muligvis ikke kan føre belæg for din påstand. Gå efter bolden ikke manden.Nikolaj kører Bodega-argumentet: "Det er fordi alle ledere på pågældende område er dumme".
Godt, så se at komme igang.Det her er et forsøg på en diskussion.
Det tror jeg ikke jeg har udtalt mig om. Men det ville være rart om du enten underbyggede de påstande du slynger ud, eller også lader være. Det er fint hvis det er din personlige holdning og tro, men det er ikke sådan du fremlægger det.Hvis Nikolaj mener at hans argumenter skaber bedre kausualitet end mine, så fred være med det.
COBOL er ikke dødt. Men det er ikke COBOL der er mainframens styrke, der er mainframen. Mainframen kører også Java endda glimrende.
Nikolaj: Vi er uenige om årsagerne til at COBOL bruges meget i den financielle sektor. Du mener at det er fordi ledere er stok-konservative, mens jeg mener at det er fordi at COBOL rent faktisk leverer varen. Hertil er det vel tilladt at konkludere at vi ikke argumenterer på samme banehalvdel, eller hvilket billede man nu skal bruge. Jeg beklager hvis min argumentationsform virker stødende, det er ikke funktionelt. Men der er altså argumenter der er orthogonale, som aldrig kan mødes. Selvfølgelig kan man gerne diskutere årsager til manglende nytænkning blandt ledere i den financielle sektor - men jeg ikke gider deltage i den diskussion, ligesom jeg fornemmer at du ikke vil gå ind i min diskussion. Mainframen kører også JAVA glimrende. Ja, vi er enige. Men min argumentation søger at underbygge at for core-systemer er COBOL et bedre programmeringssprog end JAVA - primært pga. en langt mere skånsom håndtering af SQL.
Henrik mfl: JAVA er et meget 'rigt' miljø, dvs. at der kan findes løsninger på de meste obscure problemer hvis man støver rundt i JAVA-verdenen. Helt modsat COBOL, som ikke har et tilsvarende åbent økosystem. Dvs argumentet om at alt kan løses i JAVA er godt - men... argumentet blegner noget i SQL og mainframe sammenhæng:
- Man må se på COBOL og SQL samlet. Hvis der er et behov for at sortere UFT8-kodet-græsk alfabetisk, så er det en opgave som hører hjemme i SQL. De fleste 'problemer' i core-systemer løses i SQL-delen. Jeg har ikke undersøgt om DB2 og Oracle supporterer sortering af UTF8 i eksotiske sprog - men de burde gøre det: Man bruger SQL i Kina. Rigtigt meget af det som man 'i gamle dage' havde underlige COBOL-subrutiner til at håndtere, er i dag en del af SQL.
- COBOL kan kalde JAVA. Man er ikke fortabt hvis løsningen på et problem befinder sig i JAVA.
- COBOL er et overskueligt sprog, som kan det man normalt har brug for. Overskueligtheden er en styrke; til gengæld må man gå ind i andre sprog om så nødvendigt. Mainframen kræver flere sprog: SQL, COBOL ,CICS, MQ, JCL, JAVA,... Sprog som har hvert sit focus, hver sin overskuelige verden, og som tilsammen får klaveret til at spille. Ideen om ét sprog til det hele: JAVA, lyder charmerende, men det er spørgsmålet hvor meget det bidrager til overskueligheden at putte alt ind i den samme syntax. Min diskussionstråd har drejet sig om at der er bla. er én pris for dette: SQL får trukket nogle tænder ud.
Ja det er vi uenige om.Vi er uenige om årsagerne til at COBOL bruges meget i den financielle sektor.
Du kan fortolke det som du vil. Jeg mener at der udvikles en del i COBOL i den finansielle sektor af historiske årsager. Altså at de har en masse af det i forvejen og det skal jo vedligeholdes. Jeg tror ikke de laver helt sprit nye forsikringssystemer f.eks. i COBOL. Men de vedligeholder de gamle, og udvider dem naturligt også. En del af dem er sikkert services enabled, således at andre platforme kan nyde godt af den kode der er skrevet, enten bestandigt eller i en overgangsfase. Og så er det i Danmark den finansielle sektor som ejer maniframes, derfor har de COBOL. Jeg ved godt at IBM har forsøgt at sælge COBOL/DB2 til andre platforme, men det er aldrig helt slået an (der er vist stadigt noget AS/400 rundt omkring). Undtagelsen til konservative banker er vel SAXO bank. Men det er vel så heller ikke en "rigtig" bank :-)Du mener at det er fordi ledere er stok-konservative, mens jeg mener at det er fordi at COBOL rent faktisk leverer varen.
Og det betvivler jeg at det er. Hvor mange nye cores systemer udvikles der i f.eks. Bank, Pension og Forsikring, i lad os bare sige Danmark? Hvor mange laves i COBOL hvor mange i Java/C#? Her taler vi ikke vedligehold, men nyudvikling af core systmer. Jeg tror (efter hvad mit kendskab til denne branche siger mig), at der udvikles en hel del mere i Java/C# (bla. heftigt i Pension), end der gør i COBOL. Bla. derfor er MS SQL Server blevet fremtrædende på markedet.Men min argumentation søger at underbygge at for core-systemer er COBOL et bedre programmeringssprog end JAVA - primært pga. en langt mere skånsom håndtering af SQL
Jeg mener ikke COBOL er verdensmester i SQL, eller "bedre" end Java til SQL, og at det lige netop gør det bedre til det du kalder et core-system. Der må vi være uenige. COBOL er som jeg har sagt meget udbredt, og for mig at se, er det af historiske årsager - fordi det i mange år var de facto standarden for programmering på mainframe. Jeg tror ikke hvis det i dag blev opfundet, at det ville få den store udbredelse.
Til sidst vil jeg sige, at selvom Java som sprog (ikke platform), har sine begrænsninger og ikke er ligeså velegnet som flere ny sprog på platformen Java, så mener jeg at det er bedre til at implementere kerne systemer i end COBOL.
Henrik:
Du har en pointe med unicode. Ikke at SQL ikke kan sortere unicode, det kan den, men det er altså muligt at finde anvendelser hvor en JAVA løsning virker bedre. Og ja: jeg vil nødigt programmere en unicode-sortering i COBOL.
Fuldtekstsøgning... Jeg har ind i mellem lavet fuldtekst-søgning i SQL og er da ikke kommet til skade - men det er da rigtigt at det ikke er et kærne-område for SQL. Man laver i øvrigt ikke custom workarounds direkte i en mainframe database, det ville være brud på alle principper om dekobling mellem database og anvenderprogrammel. Det udgør en manglende forståelse af hvad en database er.
SQL i COBOL fungerer altså ret godt: du skriver EXEC SQL så er du væk fra COBOL og inde i SQL, og du skriver END-EXEC så er du ude af SQL og tilbage i COBOL. JPQL, som du udmærket demonstrerer, har også et ret lille footprint, dog ikke så minimalistisk som COBOL's. At gøre objekt-karakteren i JAVA så lidt synlig som mulig, og at gøre SQL-formuleringen så meget synlig som mulig, er udmærket. Det ændrer dog ikke på at ideen i RDBMS / SQL er at flytte objekterne ud af anvenderprogrammerne og ind i en fælles pulje for hele organisationen: Databasen. Der er dermed ikke noget behov for at indkapsle data i objekter i anvenderprogrammer - det er rent overhead, som ikke tjener noget formål andet end at tilfredsstille syntaxkravene i JAVA. Hvis disse krav er hellige, og hævet over diskussion, så er de det, men COBOL klarer sig altså ganske udmærket uden.
Jeg er ikke ene om at være skeptisk overfor databaseuafhængige SQL-implementeringer. Det bliver nødvendigvis mindste fælles nævner mellem diverse faktiske SQL-sprog, nemlig det som alle sprogene kan håndtere. Og der bliver en forsinkelse i forhold til nye ting i SQL: først lanceres det måske i Oracle, så i DB2, hvorefter der så er åbent for at JPQL kan implementere det. Jeg ved godt at SQL er en standard - alligevel kan der være store fordele ved at kunne implementere nye faciliteter i et konkret SQL-sprog hurtigere end hvad man kan blive enige om på tværs af leverandørerne. Og: det er også rigtigt godt at kunne teste sine SQL kald i et SQL interface direkte mod databasen, hvorefter man kopierer dem uændret ind i sit anvenderprogram - med sikkerhed for at de virker på identisk vis her.
Man bør have rådighed over databasen fra teststart, så man kan teste og udvikle anvenderprogrammel samtidig med at man justerer på opbygning af databasen. Databasen er det væsentlige i et core-system, det har ikke meget mening at udvikle systemet uden den. Derimod i fx brugergrænsefladeprogrammering kan det evt. være ok at simulere databasen: den er ikke i centrum.
Nikolaj: Der er altså andre argumenter end at flertallet må have ret. (Ten millions flies cannot be wrong...). Jeg søger at argumentere for hvorfor COBOL er bedre end JAVA som container for SQL, og er således ret ligeglad med om hvorvidt den financielle sektor statistisk set går i en retning eller en anden, eller hvilke holdninger der præger den. Det ændrer ikke på min argumentation.
Mht. fuldtekstsøgning i SQL: den eneste SQL struktur til formålet, som jeg kender til, er LIKE, og så kan man naturligvis AND'e og OR'e og få noget ud af det. Det kan fungere nogenlunde, men det er temmeligt rudimentært. En fuldtekstsøgning, der også virker på systemer, der ikke er legetøj, er en del mere kompliceret. Man bliver nødt til at lave noget tokenisering og noget normalisering undervejs. Herefter skal resultatet indekseres af performancehensyn. Man skal også forholde sig til, hvad der skal udelades i søgningen såsom stop words. Hvis man vil implementere en Google-lignende "did you mean" søgning, så findes der også algoritmer til det. Den sidste er naturligvis meget sofistikeret, men der findes virkeligt gode værktøjer til dette i Java, og med COBOL+SQL er man enten prisgivet eller har for mange penge.
Et meget simpelt eksempel på en normalisering er, at lowercase tekststrengene. Desuden kan vi på dansk tilføje en normalisering, der konverterer 'å' til 'aa' for at opnå resultater på eksempelvis både 'Århus' og 'Aarhus'. De eneste måde, jeg kender til, at gøre dette i SQL er, at tilføje et normaliseret tokenized ord indeks i databasen og så normalisere og tokenize en query på runtime, med mindre man vil lave infix søgning (det vil man ikke, hvis man interesserer sig for performance). Vi kan lave noget af dette internt i databasen ved hjælp af et programmeringssprog, som den supporter, men nu har vi så gjort vores til i den grad at snavse databasen til, og at sørge for, at den er vanskelig at migrere og/eller opgradere. Desuden skal vi duplere koden i både databasen og i vores query analyse.
Den anden måde at gøre det på er ved at vedligeholde et eksternt indeks. Jeg formoder, at man her igen har tabt i COBOL.
Her har vi så et andet problem, for hvis vi vil gøre databasen til en fællesresource for organisationen, som alle kan gå direkte på, så skal disse indekser vedligeholdes på en eller anden måde.
Endnu et problem med rå SQL ifb. med søgning er, at vi meget ofte gerne vil have en ordning af resultaterne, så de mest relevante kommer først. Igen har man i Java fremragende værktøjer til rådighed.
Mere generelt er det nok ikke nogen hemmelighed, at jeg er meget skeptisk overfor den holdning, at det er fornuftigt at have rå SQL som interface for hele organisationen. En ikke-triviel database vil ofte have forretningslogik, som jeg ikke ville bryde mig om at implementere i databasen. Det ved jeg godt man gjorde i 80'erne, fordi man ikke havde andre muligheder, men det er ikke et argument for at skyde sig selv i foden i vore dage. ;)
Det er nok her du ser en mentalitetsforskel, for ovenstående argumenterer netop for, at man konstruerer en maksimalt dum database, som er et lager for de data, man bruger - og intet andet. Dvs. vi fokuserer på det, databaser er rigtigt gode til, nemlig at hive data ind og ud transaktionssikkert med mulighed for "simpel" indicering og diverse generelt supporterede joins. Min holdning baserer sig dog ikke på, at SQL er "dårligt", men mere på arkitekturelle overvejelser.
Med hensyn til test:
Mit typiske workflow for et nyt system med en database er, at have en testdatabase, der svarer til produktionsdatabasen til rådighed hele tiden, men jeg benytter som regel en meget mindre in-memory database til unit tests. Vi har dog på min arbejdsplads et eksternt produkt med en stor Oracle database i bunden, hvor core systemet i øvrigt blev bygget i COBOL i sin tid. Vi tør ikke skrive i den direkte af frygt for at gøre det på en "forkert" måde, så der er dømt read only, hvilket heldigvis gør testning en smule mindre smertefuld, men vi kan ikke få vores egen test-database til hvert udviklingsprojekt - det er simpelthen for dyrt af licens- og ressourcemæssige årsager, så risikoen for at træde hinanden over tæerne er til stede. Heldigvis bruger jeg et objektorienteret sprog, så jeg kan mange gange lave fornuftige unit-tests uden overhovedet at tage fat i databasen ved blot at lave test-objekter i test koden.
Puha, det blev langt :)
Jo der er andre årsager til Larry Ellisons formue end SQL: Oracle er rigtigt god til at opkræve betaling. Så her er da en forrygende årsag til at abstrahere SQL bag et JAVA-objekt-interface: så kan man spare licenser til en test-database. I det hele taget må man jo manøvrere, og løse de foreliggende problemer, frem for dem som ikke er der... Fint nok, jeg synes altså bare at man også godt kan tænke lidt over hvad ideen i SQL er og hvad ideen i JAVA er, og hvorfor de to ideer er på kollisonskurs. Den hellige gral rummer ikke begge koncepter, men put gerne COBOL og SQL i gralen, det mixer fint.
@Morten Bøgh
Kan du ikke uddybe dette. I mine øjne er det naturligt at bruge SQL til at fremsøge informatoner fra en relationel database (hvor man har sin data, hvis de er relationelle i natur, eller forholdsvist nemt kan mappes til en relationel struktur). Det er også meget naturligt at opbygge programmel i et objekorienteret programmeringssprog, i den forstand at det er meget naturligt at modellere den problemstilling man prøver at løser, vha. objekt paradigmet. Hvad er det som kollidere, at man mixer to paradigmer og udnytter dem hver især til det de er gode til? Ikke i mine øjne - det er naturligt.Fint nok, jeg synes altså bare at man også godt kan tænke lidt over hvad ideen i SQL er og hvad ideen i JAVA er, og hvorfor de to ideer er på kollisonskurs.
??? Kan du ikke uddybe hvad du mener. Mener du COBOL er super til fordi det understøtter indlejret SQL?Hvad der i Den hellige gral rummer ikke begge koncepter, men put gerne COBOL og SQL i gralen, det mixer fint.
@Morten
Imperativ står ikke i modsætning til procedural, tvætimod, men derimod til deklarativ. Manglende faglighed gavner ikke ligefrem sagligheden.Der er ikke nogen 'støj' i det område i programmet hvor man switcher fra procedural til imperativ (non-procedural) kodning.
Statisk SQL er ikke forbeholdt hverken COBOL eller mainframen. Desuden er statisk SQL bestemt ikke garant for fart. Læs "Database tuning" af Philippe Bonnet og Dennis Shasha.SQL-kaldene bliver omsat til en konkret acces-vej hen til til de data der skal læses eller modificeres. Det sidste har den effekt at COBOL SQL kører mærkbart hurtigere end JAVA SQL.
@Nikolaj
Du tager fejl, der laves masser af nye systemer, fra bunden om du vil, i COBOL, PL/I, Rexx og flere andre sprog som af nogen anses for oldtidslevn, i Danmark og i resten af verden. Om det er rationelt eller ej vil jeg nødig gøre mig til dommer over her.Jeg mener at der udvikles en del i COBOL i den finansielle sektor af historiske årsager. Altså at de har en masse af det i forvejen og det skal jo vedligeholdes. Jeg tror ikke de laver helt sprit nye
@Henrik
JCL er et deklarativt sprog (langt hen ad vejen i hvert fald), ligesom SQL.Nu må du ikke forvirre. SQL, Cobol og Java er sprog
MQ, CICS og JCL er ikke "sprog"
/Kristian
'Imperativ, deklarativ, procedural'. En definition tak! Der er her er faglig terminologi som jeg ikke kender. COBOL specificerer processer via sekvens, iteration og selektion, mens SQL imperativt specificerer 'ændr data!' 'giv mig!' uden at specificere processen der skal gøre det. Dvs min beskrivelse er korrekt, men rammer altså alligevel ved siden af.
Statisk SQL bruges alt ovevejende i forbindelse med COBOL og bruges sjældent i forbindelse med andre miljøer. Statisk SQL er normalt mærkbart hurtigere end dynamisk SQL. At der findes eksempler som fraviger disse hovedretningslinier er muligvis interessant, men ændrer ikke mit argument: Hvis man diskuterer 'hvad er hurtigst' må man tage hyppighed af forskellige scenarier med i vurderingen.
Mit indspark har været at diskutere at objektorientet håndtering af data ikke bidrager med noget hvis data ligger i en SQL-database. Jeg synes at diskussionen ovenfor viser at denne påstand holder rimeligt godt . Men mindre man kan hænge sine objekter op på andet end registerdata - fx brugergrænseflade-begreber. At den financielle branche og andre brancher muntert programmerer mange af sine core-systemer i fx JAVA ændrer ikke på denne argumentation. Der er sikkert gode grunde til at de gør det, disse grunde ændrer heller ikke på denne argumentation.
Jo, COBOL er super fordi interfacet til SQL ikke skal væves ind i en objektorienteret syntax, SQL indlejres bare. Dette er vigtigt fordi definitionen på et core-system bør være at det er et system hvor størsteparten af aktiviterne er programmeret i SQL og ikke i et proceduralt sprog. (eller deklarativt eller...) (hvor 'størsteparten' her er et passende diffust begreb)
Hej Morten
'Imperativ, deklarativ, procedural'. En definition tak! Der er her er faglig terminologi som jeg ikke kender. COBOL specificerer processer via sekvens, iteration og selektion, mens SQL imperativt specificerer 'ændr data!' 'giv mig!' uden at specificere processen der skal gøre det. Dvs min beskrivelse er korrekt, men rammer altså alligevel ved siden af.
Imperativt: Beskriv hvordan noget skal gøres. http://en.wikipedia.org/wiki/Imperative_programming
Deklarativt: Beskriv hvad der skal gøres.
Procedural programmering hører under imperativ programmering.
Man kan sagtens anvende statisk SQL med Java, og det bliver også brugt en del af performance grunde - dog kan det nemt gå ud over portabiliteten af ens applikation. Se bla. SQLJ som er en language extension til Java, som også giver dig mulighed for direkte at indlejre SQL i din Java kode - ligesom dit COBOL eksempel.Statisk SQL bruges alt ovevejende i forbindelse med COBOL og bruges sjældent i forbindelse med andre miljøer. Statisk SQL er normalt mærkbart hurtigere end dynamisk SQL. At der findes eksempler som fraviger disse hovedretningslinier er muligvis interessant, men ændrer ikke mit argument: Hvis man diskuterer 'hvad er hurtigst' må man tage hyppighed af forskellige scenarier med i vurderingen.
http://sqlj.org/http://en.wikipedia.org/wiki/SQLJ
Objektorienterings er en abstraktion - intet andet. Det benyttes til at modellere hvordan den virkerlige verden (de virkelige problemer vi forsøger at løse). Det er godt for det er nemmere og mere virkeligstro - end at modellere direkte på databareniveau, især når man er flere der skal kommunikere om løsningen. F.eks. synes jeg det er fornuftigt at modellere en virksomhedsorganisation (eller lignende) objektorienteret. Ligesom dato og tid (kalender osv.) giver rigtig god mening som objekter. Der vil være impedans problemer når det objektorienterede design skal oversættes/serialiseres til RDBMS (som er relationelt) eller XML (som er hierarkisk), og det må man så tage højde for.Mit indspark har været at diskutere at objektorientet håndtering af data ikke bidrager med noget hvis data ligger i en SQL-database. Jeg synes at diskussionen ovenfor viser at denne påstand holder rimeligt godt . Men mindre man kan hænge sine objekter op på andet end registerdata - fx brugergrænseflade-begreber.
Din argumentation, eller hvad man skal kalde det, hang da ellers på at alverdens core-systemer skrives fortrinsvist i COBOL, mener du virkeligt stadigt et holder? Den finansielle sektor i DK er dem som ejer den største andel af mainframes (altså maskiner der med fordel kan køre COBOL), det er vel meget væsenligt hvad de gør, for hvis de bevæger sig væk fra hvad du siger, hvem er det så der skal implementere sine core-systemer i COBOL?At den financielle branche og andre brancher muntert programmerer mange af sine core-systemer i fx JAVA ændrer ikke på denne argumentation. Der er sikkert gode grunde til at de gør det, disse grunde ændrer heller ikke på denne argumentation.
Det er din subjektive holdning. Man behøver ikke pakke SQL ind i en objektorienteret syntaks i Java, faktisk er standard JDBC (som er det interface man benytter i Java til at lave SQL kald med), lavet så man default submitter dynamisk SQL som tekststrenge, uden brug af objektorientering.Jo, COBOL er super fordi interfacet til SQL ikke skal væves ind i en objektorienteret syntax, SQL indlejres bare.
Det mener du så, men der findes altså core-systemer som ikke er baseret på SQL eller relationelle dababaser. Du mangler argumentation for hvorfor du mener det forholder sig sådan. Det er muligvis rigtigt på mainframe, men det er dog en noget generel påstand. Jeg kunne så argumentere for at man skulle bygge dem i SAS/SCL da man her også kan indlejre SQL direkte i koden, og det tilmed er objektorienteret.Dette er vigtigt fordi definitionen på et core-system bør være at det er et system hvor størsteparten af aktiviterne er programmeret i SQL og ikke i et proceduralt sprog. (eller deklarativt eller...) (hvor 'størsteparten' her er et passende diffust begreb)
Det virker som om du synes objekt orientering er noget bras, generelt. Samtidigt synes jeg dine argumenter er bygget på din subjektive holdninger, mere end at du benytter egentlige fakta til at underbygge dine påstande.
Som jeg læser det du skriver, går det ud på at du mener COBOL er det bedste sprog til det du kalder core-systemer (det er jeg så stadigt lidt usikker på hvad du mener med?), fordi alle core-systemer bør være bygget i SQL, og at man i COBOL kan indlejre SQL - er det korrekt forstået?
Procedural programmering hører under imperativ programmering.
En lidt løs definition er: Sproget har kontrolflowstrukturer ud over GOTO eller tilstedeværelsen af procedurer. Som så meget andet er definitionen ikke fasttømret: Nogen bruger det som synonym til imperativ ditto etc.
På samme vis er Objektorienteret programmering ikke helt veldefineret som størrelse. Du vil ofte støde på at forskellige mennesker mener det dækker over forskellige ting.
Hej Jesper,
Wikipedia:
[i]Procedural programming is imperative programming in which the program is built from one or more procedures (also known as subroutines or functions).[/i]
Ja objektorientering er vel deklarativt, da det vel egentlig kun siger noget om objekt abstraktionen. Metoder på objekterne er noget man vil have gjort (ikke hvordan dette så rent faktisk skal udføres).
Jeg er dog sikker på at dette kan modargumenteres af andre.
Nikolaj: Jeg prøver - rimeligt forgæves, ser det ud til - at fastholde en 'tredie vej' i en argumentation. Du mener 1) at man kan argumentere ud fra hvad der er hyppigt anvendt - hvis alle programmerer objektorienteret, så må det jo være godt. Og at 2) man kan argumentere ud fra 'hvad man synes' elller 'hvad man føler'; fx argumenterer jeg udfra at jeg synes at COBOL er godt til SQL. Den tredie vej er at man kan argumentere logisk. Det er vist ikke så moderne længere, men har dog tidligere fejret triumfer.
Altså: RDBMS-datastrukturer er i sig selv en modellering og strukturering af et administrativt område. Derfor er den modellering og strukturering der sker i et objektorientet lag i denne forbindelse oveflødig og udgør dermed støj. Har jeg ret eller har jeg ret? Om så 99,9% af verdens financielle systemer var bygget i JAVA og 99,9% af verdens programmører var begejstrede JAVA tilhængere, så har det ikke den mindste indvirkning på denne argumentation.
Hvis man vil skyde mod argumentationen, kan man hævde at DRBMS databaser og SQL er noget skrammel fordi... Eller man kan hævde at den 'impedance mismatch' der ligger i lagene mellem SQL og objekter (og XML) bidrager med et eller andet værdifuldt fordi...
At styrken ved JAVA bl.a. er at data kan tilgås ikke-objektorienteret er ikke et argument imod mit synspunkt. Det er et argument for.
At ikke-objektorienteret JAVA er næsten lige så godt til at rumme programsekvenser skrevet i SQL som COBOL er det, er ikke et argument imod COBOL.
Hej Morten,
Jeg giver snart op...
Ja så...? Det er rigtigt at du forsøger at argumentere, men din argumentation bygger til stadighed på dine subjektive holdninger og ikke fakta.Jeg prøver - rimeligt forgæves, ser det ud til - at fastholde en 'tredie vej' i en argumentation.
Nej det mener jeg ikke. Desuden skal du huske forbehold for hvad du læser og forstår og så hvad folk rent faktisk mener. Man kan sagtens anvende denne argumentation, om f.eks. hvad der er mest populært etc. men ikke om hvad der er kvalitet, bedst etc.Du mener 1) at man kan argumentere ud fra hvad der er hyppigt anvendt - hvis alle programmerer objektorienteret, så må det jo være godt.
Nej den subjektive arugmentation overlader jeg helt til dig. Jeg beskriver blot hvordan verden ser ud herfra. At jeg ikke tror at verdens core-systemer bliver skrevet i COBOL, det er en påstand du er kommet med, og jeg har bedt dig bakken den op med noget konkret, hvilket du endnu har fejlet at gøre.Og at 2) man kan argumentere ud fra 'hvad man synes' elller 'hvad man føler'; fx argumenterer jeg udfra at jeg synes at COBOL er godt til SQL.
Ah ha, nå? Dvs. det du indtil videre har fremført, er argumentation baseret på logik? Altså logik baseret på fakta? Nej du har fremført en række påstulater (uden nogen form for konkret opbakning), og så en række subjektive holdninger. Dem har du så draget nogle slutninger ud fra, der passer på det du mener, det er ikke logisk argumentation.Den tredie vej er at man kan argumentere logisk. Det er vist ikke så moderne længere, men har dog tidligere fejret triumfer.
Din argumentation bygger på sammenligning af Java med RDBMS, det hænger ikke sammen. Shell er også et sprog bygget til at vedligeholde et administrativt område, derfor bruger vi det jo ikke til at skrive virksomheders administrative systemer i. Der er altså meget stor forskel på hvilket domæne der skal administreres, og hvilke værktøjer der egne sig bedst til et givet domæne. Det kan lade sig gøre at skriv en virksomheds HR administrationssystem i Shell, men det er vel næppe noget vi ønsker? Derimod er RDBMS+SQL nok et godt subsystem til at lagre data fra systemet, mens det at kunne modellere det i objekt orienteret også vil være en fordel.Altså: RDBMS-datastrukturer er i sig selv en modellering og strukturering af et administrativt område. Derfor er den modellering og strukturering der sker i et objektorientet lag i denne forbindelse oveflødig og udgør dermed støj. Har jeg ret eller har jeg ret? Om så 99,9% af verdens financielle systemer var bygget i JAVA og 99,9% af verdens programmører var begejstrede JAVA tilhængere, så har det ikke den mindste indvirkning på denne argumentation.
Der er vist ikke nogen der hævder at RDBMS eller SQL er noget skrammel. Jeg troede det var COBOL der blev debatteret?Hvis man vil skyde mod argumentationen, kan man hævde at DRBMS databaser og SQL er noget skrammel fordi... Eller man kan hævde at den 'impedance mismatch' der ligger i lagene mellem SQL og objekter (og XML) bidrager med et eller andet værdifuldt fordi...
Lad nu være med at pille tingene ud af kontekst. Du sagde at man i Java skulle skrive sin SQL på en unaturlig objekt orienteret måde. Jeg sagde blot, at det skal man ikke.At styrken ved JAVA bl.a. er at data kan tilgås ikke-objektorienteret er ikke et argument imod mit synspunkt. Det er et argument for.
Det er der vist heller ikke nogen der har sagt.At ikke-objektorienteret JAVA er næsten lige så godt til at rumme programsekvenser skrevet i SQL som COBOL er det, er ikke et argument imod COBOL.
Til sidst, husk på at der er rigtigt mange ikke-tekniske årsager (oftest økonomiske) til de valg der bliver foretaget, omkring implementeringer, valg af platforme, opgraderinger, skift af teknologi osv. Så selvom COBOL rent teknisk var det beste til implementering af core-systemer (hvilket jeg ikke kan se det skulle være), så er der rigtigt mange andre grunde der kan afgøre at en anden platform (f.eks. Java, C#, Python osv.) bliver valgt. F.eks. pris (hvilket så igen er en meget kompleks størrelse).
Jeg mener, at der er masser af grunde til ikke at gøre det, som du anbefaler, og mange af dem forholder du dig simpelthen ikke til. Jeg vil da gerne reiterere, og så er emnet vist uddebateret i for mit vedkommende.
Fordele:
Mulighed for separation af de logiske lag i applikationen, så eksempelvis forretningslogik ikke bliver blandet ind i datalaget.
Mulighed for helt generelt at have en database, der indeholder data, og ikke bruge diverse triggers, stored procedures etc. der gør migrering og opgradering, for slet ikke at tale om designforståelse, problematisk.
Mulighed for at bruge de klassiske objekorienterede dyder såsom indkapsling til at lave et fornuftigt modulært design.
Mulighed for at bruge features, som ikke findes i COBOL+SQL fra Javas rige økosystem. Diverse muligheder for caching og connection pooling kunne være eksempler.
Mulighed for unit tests med mere lightweight databaser eller helt uden, så man ikke skal "leje" en instans med dertil medfølgende administration. COBOL + unit tests ser ikke ud til at være en behagelig oplevelse.
Mulighed for at bruge et højniveau persistenslag, hvis det giver mere mening end rå SQL
Ja jo og alligevel.....
Mulighed for separation af de logiske lag i applikationen, så eksempelvis forretningslogik ikke bliver blandet ind i datalaget
Absolut muligt. Dog på en anden måde rent arkitekturmæssigt (findes det ord ?)
Mulighed for helt generelt at have en database, der indeholder data, og ikke bruge diverse triggers, stored procedures etc. der gør migrering og opgradering, for slet ikke at tale om designforståelse, problematisk.
Det gælder vel uanset hvilken database du arbejder med ?
Mulighed for at bruge de klassiske objekorienterede dyder såsom indkapsling til at lave et fornuftigt modulært design.
Bingo. Det kan Cobol ikke. PL/1 fik muligheden tilbage i 1970'erne (sådan ca - nogle på godt rette mig) for at lave en form for objektorienteret. Men PL/1 != Cobol
Mulighed for at bruge features, som ikke findes i COBOL+SQL fra Javas rige økosystem. Diverse muligheder for caching og connection pooling kunne være eksempler.
Da Cobol som regel = IBM mainframe så findes den slags indbygget. Man "connecter" sig ikke - det foregår lidt anderledes men begge dele er tilstede.
Mulighed for unit tests med mere lightweight databaser eller helt uden, så man ikke skal "leje" en instans med dertil medfølgende administration. COBOL + unit tests ser ikke ud til at være en behagelig oplevelse.
Igen med udgangspunkt i miljøet: Nej hvorfor ?? Man tester på den database der nu er der (DB2 som regel), men forstår argumentet.
Mulighed for at bruge et højniveau persistenslag, hvis det giver mere mening end rå SQL
Bingo. Nej det findes ikke. (mig bekendt)
Igen med udgangspunkt i miljøet: Nej hvorfor ??
Man tester på den database der nu er der (DB2 som regel), men forstår argumentet.
Et meget simpelt eksempel: Du behøver ikke en database for at teste, at man ikke kan konstruere et konto objekt med et negativt indestående. Det er en forretningsregel, som ikke har noget med datalaget at gøre.
De største fordele ved, at bruge en in-memory lokal database til datalags-unit-tests er, at det typisk går hurtigere, og at der ikke er nogen eksterne afhængigheder - Det er rart at kunne checke koden ud, køre testsene og vide, at hvis de fejler, så er det ikke pga. en konfigurationsfejl, eller fordi data har ændret sig i dev databasen.
Når unit tests fejler, skal det helst være fordi, at der er fejl i koden, og ikke af alle mulige andre årsager.
Nej det har du helt ret i. Desuden er det basen der afvikler SQL, det har platformen der afsender SQL meget lidt indflydelse på (om nogen overhovedet). Den samme SQL sendt fra Java/C# eller COBOL vil give den samme performance givet den samme base.Statisk SQL er ikke forbeholdt hverken COBOL eller mainframen.
Desuden er statisk SQL bestemt ikke garant for fart. Læs "Database tuning" af Philippe Bonnet og Dennis Shasha.
Ok jeg tager fejl i min antagelse, det er acceptabelt. Det er sikkert rationelt - det stoler jeg på.Du tager fejl, der laves masser af nye systemer, fra bunden om du vil, i COBOL, PL/I, Rexx og flere andre sprog som af nogen anses for oldtidslevn, i Danmark og i resten af verden.
Om det er rationelt eller ej vil jeg nødig gøre mig til dommer over her.
Men sådan som jeg ser det, udvikler en del af finansverdenen i dag i Java/C#, også det som Morten skriver core systemer om. I pensionsbranchen har vi Edlund og Schantz, som benytter henholdsvis C# og Java til deres systemer, som må anses for at være core systemer. TIA (forsikring) benytter Java til deres udvikling.
Kan du ikke give et par eksempler på sprit nye COBOL løsninger. Altså greenfield COBOL udvikling i den finansielle sektor.
Hvis vi tager den største offentlige IT institution SKAT, så er det igen Java (og en del SAP - men ikke COBOL), der benyttes til udvikling af nye systemer. Så er vi udenfor den finansielle sektor, men alligevel, kan det give en god indikation om hvor kompasset peger hen, og hvorfor IBM/Oracle satser så meget på Java.
COBOL er vel ikke mere oldtidslevn, end Ada, Perl, C, C++ osv. Hvert værktøj sin funktion. Jeg synes bage ikke Mortens argumentation hænger sammen. Han mener at COBOL er bedre end Java, og det har han lov til, men det ligner for mig en subjektiv holdning, som ikke er baseret på argumentation. F.eks. at sætte imperativ lig med non-procedural, vidner for mig om manglende viden om progammeringsparadigmer, og det lægger efter min mening ikke mere vægt bag hans holdnigner, tvært imod.
@Vijay: SQL bliver delvist valideret i forbindelse med compile af COBOL programmet, hvorefter der sker en videre validering i en 'bind' af SQL-kaldene. Processen resulterer i to ting: dels at SQL-kaldende i COBOL programmet bliver vævet ind i COBOL-kodningen via noget kode-generering som skaber adressering af SQL-variable fra COBOL, dels at SQL-kaldene bliver omsat til en konkret acces-vej hen til til de data der skal læses eller modificeres. Det sidste har den effekt at COBOL SQL kører mærkbart hurtigere end JAVA SQL. Herudover indebærer det naturligvis at en del SQL-fejl (men ikke alle) fanges på kodningstidspunktet i stedet for på eksekveringstidspunket.
Nu vil jeg bestemt ikke stå som eksponent for, at Java er et sprog, som kan bruges til alt. Her forholder jeg mig kun til, om Java er et fornuftigt sprog til at udføre de opgaver, som man ellers ville bruge COBOL til.
Jeg har researchet lidt, og præcis mht. unicode sortering (collation) er der en begrænsning både i Oracle og DB2: Det virker ikke ret godt, hvis man har forskellige sprog i den samme database. I den situation bliver man altså nødt til enten at benytte sig af en database pr. sprog, eller også må man løse det på anden vis. I COBOL har du så formodentligt et problem.
Mht. fuldtekst søgning, som jeg ikke mener er en obskur feature i et moderne system, der indeholder tekststrenge, mener jeg simpelthen ikke SQL er kraftfuldt nok i sig selv, og derfor bliver man som sagt nødt til at lave diverse custom workarounds direkte i databasen, hvilket er noget skidt af tidligere nævnte grunde.
Selv hvis man ikke har disse krav til systemet, så mener jeg ikke, at man får ret meget ud af at implementere systemet i COBOL frem for Java. Her er dit eksempel, som jeg ville skrive det i Java:
[code=java5] if (hoejCigarfoering) { int numberOfUpdates = getEntityManager().createQuery( "update Employee e set e.salary = e.salary * 1.05 where e.department = :department" ).setParameter("department", Department.SALES).executeUpdate(); log.debug("updated {} employees", numberOfUpdates); } [/code]
Bemærk, at der her ikke er tale om en SQL query, men derimod en JPQL query, som bliver oversat til en SQL query nede i maven på persistence manageren. Employee er en klasse og Department.SALES er en enum værdi. Holdningen er altså ikke at SQL er noget værre noget, som man hellere må undgå. Man har derimod specificeret et sprog, som er meget inspireret af SQL syntaksen, men som er databaseuafhængigt og mere velegnet til brug i objektorienterede sprog.
Da syntaksen er databaseuafhængig kan jeg vælge at teste den ved at oprette en in-memory database (eksempelvis HSQL) uden at have fat i en instans af den database, det skal køre på, før på et langt senere tidspunkt.
Jeg har tidligere skrevet om at vi på datalogi 1 på DIKU (2. studieår) havde COBOL i administrativ databehandling.
Jeg synes så også at jeg vil skrive lidt om mine erfaringer med sproget.
Alle mine holdkammerater skrev et COBOL-program på 200 udførelses-linjer. Jeg klarede mig med syv linjer, noget der fik instruktor til at tale om en slags snyd.
Naturligvis var der ikke tale om snyd; jeg havde bare læst COBOL-bogen igennem, også den del der handlede om REPORT SECTION.
Sproget har sin begrænsede ret i administrativ databehandling, og i dag med en relationsdatabase som grundlag. Jeg har sværere ved at se berettigelsen af Fortran; her foretrækker jeg algol-familien, med sprog som C, Pascal, Modula mv. Og de store Fortran-biblioteker kan vel også benyttes fra C++ ?
"Mainframen kræver flere sprog: SQL, COBOL ,CICS, MQ, JCL, JAVA"
Nu må du ikke forvirre. SQL, Cobol og Java er sprog MQ, CICS og JCL er ikke "sprog"
Så håber jeg også at du får en god sum penge hver måned.
Der er jo det problem, at når det sidste mainframe endelig lukkes en gang, står du og har en masse erfaring i Cobol og måske intet i andre nutidige sprog. Medmindre du selvfølgelig også laver den slags ved siden af, men det har man næppe lyst til efter en lang arbejdsdag.
Det er med Mainframen, som med så mange andre ting her i verden, nemlig at rygtet om dens død er stærkt overdrevet. Det der ser ud som om at være tilfældet lige nu er at behovet for ny mainframe kapacitet ikke er meget større/mindre end den forbedring du har i ydelse på nye generationer af maskiner.
Det er lidt det samme som vi er ved at se på UNIX markedet i dag. Kapacitets forøgelsen på de servers der bliver solgt er større end behovet for ny kapacitet.
Det man bare skal huske på er at Mainframen jo har været igennem alt det man idag ser på x86 markedet. Server konsolidering, virtualizering og og og .. Så derfor som ung IT gut sæt dig ved siden af din Mainframe Sysadmin og lær et par fif og lidt kultur.
// Jesper
Undskyld! Skulle ikke være sendt to gange!
Rigtig godt råd!
Mange glemmer de indbyggede fordele, som mainframen altid har haft: mindre power forbrug, mindre behov for gulv areal, og mindre behov for cabling sammenlignet med det det nødvendige antal x86 eller UNIX maskiner til at give samme regnekraft.
Rolig Niels, nu er UNIX jo mange ting. Og IMHO så er den sejeste box på markedet altså en "UNIX box", der er ikke rigtig nogen "kommerciel" maskine, der kan matche en POWER 795. Heller ikke en zSeries Mainframe :)=?
Men ellers good weekend.
// Jesper
Det skulle da lige være en zEnterprice med zBX udstyret med Power7 blades.
Men måske har du ret. Der var jo nok en god grund til at Watson bestod af 10 forbundne Power7 systemer.
Forleden havde jeg fornøjelsen af høre om de seneste udvikinger på mainframe fronten. Jeg tror kun, at Cobol blev nævnt en enkelt gang i dagens løb.
Fokus var på, at moderne mainframes køre moderne operativsystemer, som Redhat Enterprise Linux Server eller SUSE Enterprise Linux Server direkte på jernet eller eventuelt på hardware virtualiseringen. Du skal således kende til linux for at kunne lave ting til en mainframe.
Selvfølgelig har de danske banker nogle vigtige systemer programmeret i Cobol som i endnu en del år skal vedligeholdes. Programmer til mainframes har nemlig en usædvanlig lang levetid. Den danske finanssektor er ikke alene med dette problem. I 1970'erne leveres IBM 370 systemer til en række raffinaderier verden over. I dag har mange brugere valgt at starte livtidsforlængelsesprojekter for disse systemer i stedet for at udskifte dem med moderne SCADA systemer. Lokal efteruddannelse er nøglen til succes med disse projekter.
Når tanken falder på SQL, er det første programmeringssprog, jeg tænker på ikke COBOL. I min verden er der mere relatation mellem COBOL og IMS og CODASYL. For mig er SQL mere knyttet sammen med Codd, Stonebraker og Ingres. Javel, der fandtes PRO/COBOL til Oracle, men det førende sprog til Oracle var da C gennem PRO/C. Så derfor passer SQL og COBOL ikke naturligt sammen som hest og vogn.[..] SQL og COBOL passer sammen som hest og vogn
Skulle der være nogle der er intersseret i hvordan COBOL nu kan udvikles direkte fra enten Visual Studio eller Eclips, er i velkommen til at få en prøve af vores software.
Med vores nyeste Visual COBOL R3 kan man eksekvere COBOL native/.NET/JVM osv....
Jeg betvivler din påstand, har du belæg for denne?Derfor programmeres størsteparten af verdens administrative systemer i COBOL
Er det ikke mere, at stokkonservative virksomheder (Den finansielle sektor bla.) Ikke fornyer sig, og derfor har meget svært ved at rekruttere kompente medarbejdere, men derimod benytter en hel masse konsulentbistand.
Desuden tror jeg, ud fra mit kendskab til den finansielle sektor, at når der skal laves ny-udvikling (greenfield), så benyttes COBOL ikke, men derimod Java/C# eller lignende.
Det har Oracle som du selv nævner lugtet, og derfor har de oprustet helt vildt til at være den førende leverandør at middleware mv. på Java platformen (opkøb af BEA og Sun Miscrosystems).
SQL passer da fint til Java, prøv at lave noget i Groovy/Grails - det bliver næsten ikke nemmere.
noget man slår ihjel nede i den dungeon ?
// Jesper
SQL er ikke relevant hvis drømmen er at programmere aps til Android. SQL er et sprog til håndtering af meget store administrative systemer.
Pladder - det kommer absolut an på den information man vil gemme lokalt - Android har fuld SQLite understøttelse. Mon ikke at de fleste mobilstyresystemer enten er født med SQLite eller at DBMS'et ligger i repository. SQL benyttes til systemer i alle størrelser.
Efter min mening har unge brug for at lære så mange forskellige paradigmer som muligt. Cobol og PL/1 og andre forretningsrettede programmeringssprog er ikke særskilte paradigmer.
Hvis du er i stand til at programmere og forstår forskellen i de forskellige paradigmer - så er det et spørgsmål om oplæring hvorvidt du skriver i C++, Java, Cobol, PL/1, SQL eller andre sprog.
Et kursus i Cobol eller PL/1 kan overståes på 1-2 dage for den øvede programmør. Efterfølgende kan man så de basale konstruktioner og forstår at læse eksisterende programmer. Det er alligevel sjældent at der skal skrives sprit nye programmer der ikke baserer sig på afprøvede modelprogrammer.
Jeg synes hellere at arbejdspladserne skal satse på at plukke dygtige programmører der er omstillingsparate til disse "antikke" sprog. Det svære ved Cobol og PL/1 er ikke sprogene, men der i mod de omgivelser som programmerne skal afvikles i.
Hvis firmaerne decideret søger efter "erfarne cobol udviklere" så er det, efter min mening, en kortsigtet investering.
Lidt sjov læsning:
https://cs.senecac.on.ca/~tmckenna/offline/COBOL_not_dead_yet.htm
Nu tror jeg ikke ligefrem mainframe forsvinder indenfor de næste mange år og jeg skrev jo også både Cobol og Java :)Så håber jeg også at du får en god sum penge hver måned.
Der er jo det problem, at når det sidste mainframe endelig lukkes en gang, står du og har en masse erfaring i Cobol og måske intet i andre nutidige sprog. Medmindre du selvfølgelig også laver den slags ved siden af, men det har man næppe lyst til efter en lang arbejdsdag.
Nu tror jeg ikke ligefrem mainframe forsvinder indenfor de næste mange år og jeg skrev jo også både Cobol og Java :)
Det er lige præcis derfor det er en fin ide at kunne mere end een ting, og kun den. Du får en udvikler, ikke en Cobol-programmør.