mboost-dp1
Micro Focus
cgt (3) skrev:Alternativt kunne de få lavet noget moderne software i et moderne sprog. GTFO, Micro Focus!
Godt, gider du så lige stille en businesscase op, for at få konverteret flere forretningskritiske applikationer på flere hundretusinde liniers optimeret kode der køre uden fejl, og der har en kvalitet der er så høj, kun fordi der har været rettet fejl i dem i måske 35 år.
At lave et nyt system til at overtage funtionaliteten af et sådan system vil måske koste 80-100 mil. i grund udvikling, dertil kommer en testfase på måske 100 mandår for at sikre kvaliteten. 100 mandårs test, har koster vel let 100 mil ekstra.
Så du mener de skal betale 200 mil, for at få omkodet et program der virker perfekt, blot for at spare på at skulle finde udviklere der kender COBOL?
Hint: det meste COBOL udvikling der forgår er niche rettelser, fx nye lovkrav til bank systemer o.l.
#6 Eller man kunne nøjes med at lave de nye ting (rettelserne) i et andet (lidt mere morderne, eller bare C++) sprog. På den måde vil dinosaurer-programmerne langsomt blive konverteret, uden mer-omkostning.
Den løsning har jeg dog aldrig hørt nævnt i COBOL-sammenhæng. Så der er med god sandsynlighed også en del fanatisme indblandet i emnet.
Den løsning har jeg dog aldrig hørt nævnt i COBOL-sammenhæng. Så der er med god sandsynlighed også en del fanatisme indblandet i emnet.
Fancy...
med Cobol i VS2010 ville jeg godt kunne finde på at lære sproget...
og score 100.000+ om måneden for ekspertviden :-D
med Cobol i VS2010 ville jeg godt kunne finde på at lære sproget...
og score 100.000+ om måneden for ekspertviden :-D
Omg, de har jo bare lavet en COBOL -> .NET IL og en COBOL -> Java Bytecode compiler, samt integration af COBOL i Visual Studio.
... hvorfor ikke bare bruge C#/Java til at kode .NET/JVM? :o
Ok, man kan kopiere det gamle kode til nye platforme, men altså... der skal nok laves en del om anyway!
... hvorfor ikke bare bruge C#/Java til at kode .NET/JVM? :o
Ok, man kan kopiere det gamle kode til nye platforme, men altså... der skal nok laves en del om anyway!
Pointen er nok ikke så meget at få COBOL ind som et populær sprog igen, men mere at få gjort så nye generationer af udviklere kan få lidt interesse for at prøve sproget, og derigennem lære lidt.Qvazar (10) skrev:Omg, de har jo bare lavet en COBOL -> .NET IL og en COBOL -> Java Bytecode compiler, samt integration af COBOL i Visual Studio.
... hvorfor ikke bare bruge C#/Java til at kode .NET/JVM? :o
Ok, man kan kopiere det gamle kode til nye platforme, men altså... der skal nok laves en del om anyway!
dette vil medføre at der er flere der kommer til at kende sproget, og der derfor bliver et større udbud af arbejdskraft, der kan velligeholde de gamle systemer.
Jeg tror heller ikke der er nogle gamle store systemer der vil blive portet til .NET/Java, simpelthen fordi det er for dyrt i resourcer at køre en app i en VM, iforhold til at køre den native - især når der ikke er en grund til den skal være portable.
Mindre programmer kan nok godt konverteres, hvis man vil, og tror det der skal ændres nok er mindre ting, i forhold til at du har en meget, meget høj kodekvalitet - Så det kan nok ikke betale sig at skrive det fra bunden af.
illishar (8) skrev:#6 Eller man kunne nøjes med at lave de nye ting (rettelserne) i et andet (lidt mere morderne, eller bare C++) sprog. På den måde vil dinosaurer-programmerne langsomt blive konverteret, uden mer-omkostning.
Jeg synes umiddelbart at det lyder som et vedligeholdelseshelvede uden det helt store formål.
#8 Det er naturligvis også sådan man gør allerede i dag.
Problemet ved din antagelse er at du tror at alle programmer på et tidspunkt skal udskiftes. Det har vist sig at være anderledes.
I bunden af enhvert COBOL system ligger moduler som der ikke har været grund til at skrive om i 20-30 ja op til 40 år.
Det er f.eks. moduluskontoller, moduler som genererer unikke id'er osv osv.
Mange af dem ganske kritiske dele, som alt andet ovenpå roder nede i flere tusinde gange om dagen.
Det er ikke bare lige sådan at skifte den slags ud.
Så din løsning dur ikke. I bedste fald vil den ende med at der en fin kransekage oven på en bund af oldgammel COBOL.
Problemet ved din antagelse er at du tror at alle programmer på et tidspunkt skal udskiftes. Det har vist sig at være anderledes.
I bunden af enhvert COBOL system ligger moduler som der ikke har været grund til at skrive om i 20-30 ja op til 40 år.
Det er f.eks. moduluskontoller, moduler som genererer unikke id'er osv osv.
Mange af dem ganske kritiske dele, som alt andet ovenpå roder nede i flere tusinde gange om dagen.
Det er ikke bare lige sådan at skifte den slags ud.
Så din løsning dur ikke. I bedste fald vil den ende med at der en fin kransekage oven på en bund af oldgammel COBOL.
illishar (16) skrev:#15 Eller et vedligeholdelses-boost, da det sandsynligvis tvinger dem mod moduliserede programmer. ^^
Huh? Findes der COBOL-systemer som ikke er totalt modulariserede? Der kan man se.
Vores COBOL-system er grundligt delt op i mange tusinder af moduler, fordelt i en striks lag-arkitektur. Jeg skal nok lade være med at påstå at det er perfekt, for jeg kender ikke detaljerne. Men at indføre et sprog mere vil da absolut ikke gøre arkitekturen bedre.
Måske snakker vi forbi hinanden. Jeg er ikke COBOL-udvikler.
Cobol 80. Det var en af de første programmeringssprog jeg nogensinde arbejdede med. Jeg har ikke et særligt positivt indtryk af det. At det er ret uncool. Det hjælper selvfølgelig med en fed video hvor de siger kooo-baaaal i stedet for ko-båål 80 :)
Hvad er det så dette her programmeringssprog kan, som ingen andre sprog kan?
Hvad er det så dette her programmeringssprog kan, som ingen andre sprog kan?
COBOL var betydeligt nemmere at benytte til databaser (som DB2), og til integration med mainframes (som AS/400), på dets tid.spectual (21) skrev:Hvad er det så dette her programmeringssprog kan, som ingen andre sprog kan?
Altså et sprog udviklet til netop forretningstunge operationer, og ikke low-level programmering i assembler eller lign.
Hvilket var forholdsvis unormalt på den tid. Det er af samme grund man kalder Java for "the new COBOL" i dag, da Java også har været et sprog målrettet high-level programming.
Og ligesom COBOL er Java's syntax, og biblioteker, langt fra up2date med virkligheden.
Windcape (22) skrev:COBOL var betydeligt nemmere at benytte til databaser (som DB2),
Umiddelbart vil jeg ikke mene at Embedded SQL (som var det foretrukne API til database udvikling i mange år) er nemmere i COBOL end i Fortran og C.
COBOL har derimod en klar fordel i forbindelse med ISAM filer. Det eneste jeg kan komme i tanke om, som man matche dette er VMS Pascal og det er en særdeles platform specifik udvidelse.
Windcape (22) skrev:og til integration med mainframes (som AS/400),
AS/400 er en mini computer ikke en mainframe.
Windcape (18) skrev:Det sørgelige ved COBOL som sprog, er at sproget stadigvæk er et af de få som benytter en proprietary compilere.
Alle andre sprog der bruges i dag benytter frie compilers.
Hm.
Nu afhænger det jo lidt af om det er free speach eller free beer du taler om.
Med hensyn til free speach så vil jeg vurdere at andelen af udviklere der arbejder med open source compiler for C# og Cobol er ret tæt på hinanden (og meget tæt på nul).
Med hensyn til free beer, så er Cobol meget lavere end C//C++/Java/C#/Fortran/Pascal/Ada men lidt højere end PL/I.
Ja - TinyCobol virker faktisk!
Mono har en open source C# compiler, og C#s BCL er open source.arne_v (27) skrev:Med hensyn til free speach så vil jeg vurdere at andelen af udviklere der arbejder med open source compiler for C# og Cobol er ret tæt på hinanden (og meget tæt på nul).
COBOL har ingen open source compiler, og intet open-source standard bibliotek.
(Men modsat Java, så er både C# og COBOL standardiserede sprog)
Jeg tænkte nu også mest på "gratis".arne_v (27) skrev:Med hensyn til free beer, så er Cobol meget lavere end C//C++/Java/C#/Fortran/Pascal/Ada men lidt højere end PL/I.
Og TinyCOBOL er jo udviklet på en C runtime, som ikke just gør det brugbart på samme niveau som f.eks. Java.
illishar (8) skrev:Eller man kunne nøjes med at lave de nye ting (rettelserne) i et andet (lidt mere morderne, eller bare C++) sprog. På den måde vil dinosaurer-programmerne langsomt blive konverteret, uden mer-omkostning.
Den løsning har jeg dog aldrig hørt nævnt i COBOL-sammenhæng. Så der er med god sandsynlighed også en del fanatisme indblandet i emnet.
Næppe fanatisme.
Den gennemsnitlige COBOL programmør er for gammel til den slags! :-)
Jeg tror at der er flere årsager til at dette sker sjældent.
Udenfor de JVM/CLR er det ofte ret svært at mixe sprog, fordi data typer og calling conventions ikke er kompatible.
Design mæssigt er der også problemer med at have dele af et program i proceduralt sprog og andre dele i et objekt orienteret sprog.
Det vil kræve to skillsets blandt udviklere på projektet.
#29
Løsningen er jo så en mere serviceorienteret arkitektur. Eller modulbaseret arkitektur som myplacedk nævner er meget normalt.
Så kan man benytte command piping, og derfor tilgå COBOL moduler fra alle sprog.
Jeg ved bla. at Dansk Bank tilgår COBOL moduler fra PL/1 (generel programming), og ASP.NET (Web/Netbank). (Og nej, det er ikke via. FujitsuCOBOL).
Og på den måde kan man ligeså langsomt erstatte COBOL modulerne med andre sprog, eller andre løsninger. Mainframe tankegangen med 8 timers batchjobs der blokere for alle andre opdateringer, hver dag, er bare ikke optimal.
Problemet ligger nok i at COBOL ofte benyttes til performancekritiske operationer, hvor man derfor ikke kan gå over til en servicebaseret arkitektur med SOAP/REST som cross-platform (platform som i sprog/frameworks) medium.
Løsningen er jo så en mere serviceorienteret arkitektur. Eller modulbaseret arkitektur som myplacedk nævner er meget normalt.
Så kan man benytte command piping, og derfor tilgå COBOL moduler fra alle sprog.
Jeg ved bla. at Dansk Bank tilgår COBOL moduler fra PL/1 (generel programming), og ASP.NET (Web/Netbank). (Og nej, det er ikke via. FujitsuCOBOL).
Og på den måde kan man ligeså langsomt erstatte COBOL modulerne med andre sprog, eller andre løsninger. Mainframe tankegangen med 8 timers batchjobs der blokere for alle andre opdateringer, hver dag, er bare ikke optimal.
Problemet ligger nok i at COBOL ofte benyttes til performancekritiske operationer, hvor man derfor ikke kan gå over til en servicebaseret arkitektur med SOAP/REST som cross-platform (platform som i sprog/frameworks) medium.
Windcape (28) skrev:Mono har en open source C# compiler, og C#s BCL er open source.
BCL er ikke en compiler men et library.
MS C# compiler er mig bekendt ikke open source.
Andelen af C# udviklere der bruger GNU eller Mono C# compiler må være aldeles minimal sammnelignet med dem der bruger MS C# compiler.
Windcape (28) skrev:COBOL har ingen open source compiler, og intet open-source standard bibliotek.
TinyCobol er LGPL. OpenCOBOl er GPL.
Begge kommer med et bibliotek (TinyCobol bruger libdb for ISAM delen).
Så hvad pokker snakker du om.
Windcape (28) skrev:Og TinyCOBOL er jo udviklet på en C runtime, som ikke just gør det brugbart på samme niveau som f.eks. Java.
????
Mig bekendt er pæne dele af Java runtime for alle de gængse Java implementationer og MS .NET skrevet i C/C++.
Jeg vil også tro at langt de fleste native compilere på Windows bruger MSVCRT.
Windcape (30) skrev:
Løsningen er jo så en mere serviceorienteret arkitektur. Eller modulbaseret arkitektur som myplacedk nævner er meget normalt.
Det forudsætter at man kan erstatte ret store klumper af gangen.
Det er der sjældent business case for.
Det er meget typisk at have en pæn klump kode hvor der skal rettes lidt her og der og tilføjes et par små klumper kode.
Så er det ikke øknomisk rentabelt at omskrive det hele.
Og det er ikke teknisk muligt at omskrive en lille del til et andet sprog, fordi den er for tæt integreret med resten.
spectual (21) skrev:
Hvad er det så dette her programmeringssprog kan, som ingen andre sprog kan?
He he, et godt spørgsmål. Men jeg vil forsøge med et svar.
COBOL er et højniveau-sprog så det kan læres i løbet af kun få dage.
Det tilbyder programmøren at han kan regne på meget store floating point tal (Ala 32 tegns lange hvis jeg husker ret) og ændre på tekststrenge uden at han skal bekymre sig om den underlæggende arkitektur.
Men samtidig er det utroligt maskinnært. Alle dataområder skal defineres først, og man bruger i praksis ikke dynamisk hukommelse.
Her viser COBOL at det gammeldags, og kan ikke rigtigt følge med nyere teknologier hvis man f.eks. skal behandle XML.. som jo i sin natur kan være både små og store datamængder som man ikke kender størrelsen af på forhånd.
MEN.. i de applikationer hvor COBOL bruges. F.eks. banksystemer har man ikke meget brug for dynamisk hukommelse. En kundes CPRnr har været 10 tegn ... altid. Hans kontonummer har været fast længe.. altid, og hans antal kr på kontoen kan stadig uden problemer passe ind under de 32tegns lange tal-felter.
Til gengæld har bankerne tusindevis af kunder... og alle dem skal programmerne pløje igennem hver eneste dag MANGE GANGE.
Vi snakker altså masser af data, som alt sammen er ens længde.
Det siger sig selv at der ingen grund er til at lave dette objektorienteret, med f.eks. Java.
At oprette en kunde i hukommelsen, oprette integerobjekter, tekstobjekter etc. etc. blot for at lægge rente til et af felterne... for derefte at smide det i en database... For herefter at garbagecollecte hele molevitten igen 0.000042 sekund senere... det giver bare ikke mening.
Jeg har kodet rigtig mange forskellige programmeringssprog de 25 år hvor jeg har kodet... og jeg er sjovt nok aldrig stødt på noget som er bedre til det COBOL gør... end COBOL.
At sproget er et oldtidsfund er samtidig dets force.
COBOL er netop mellemvejen mellem maskinkode og alt nymodens objekthalløj som kun tilbyder features som man ikke har brug for når man står med de data som banker etc. har med at gøre.
Når det er sagt så skal det dog siges at sproget da nemt kunne forbedres med mange længder og stadig beholde disse egenskaber.
#36
Jeg er enig i det meste men lidt blandede kommentarer.
Floating point eller fixed point?
Det gør Fortran før Fortran 90 heller ikke.
COBOL 2002 skulle både være OO og supportere XML ifølge http://en.wikipedia.org/wiki/Cobol#COBOL_2002_and_... !
Jeg gætter dog på at stort set alt COBOL er 85 eller 74 kompatibelt.
Så er det forhåbentligt heltal eller fixed point.
Brug af floating point (læs: binært baserede floating point) til penge fører som bekendt til henrettelse ved code review.
Jeg er enig i det meste men lidt blandede kommentarer.
TrolleRolle (36) skrev:Det tilbyder programmøren at han kan regne på meget store floating point tal (Ala 32 tegns lange hvis jeg husker ret)
Floating point eller fixed point?
TrolleRolle (36) skrev:Alle dataområder skal defineres først, og man bruger i praksis ikke dynamisk hukommelse.
Det gør Fortran før Fortran 90 heller ikke.
TrolleRolle (36) skrev:og kan ikke rigtigt følge med nyere teknologier hvis man f.eks. skal behandle XML
TrolleRolle (36) skrev:Det siger sig selv at der ingen grund er til at lave dette objektorienteret
COBOL 2002 skulle både være OO og supportere XML ifølge http://en.wikipedia.org/wiki/Cobol#COBOL_2002_and_... !
Jeg gætter dog på at stort set alt COBOL er 85 eller 74 kompatibelt.
TrolleRolle (36) skrev:og hans antal kr på kontoen kan stadig uden problemer passe ind under de 32tegns lange tal-felter.
Så er det forhåbentligt heltal eller fixed point.
Brug af floating point (læs: binært baserede floating point) til penge fører som bekendt til henrettelse ved code review.
#37
Ja det er naturligvis fixed point. Jeg tror bare jeg kom til at skrive floating point fordi jeg egentlig ville skrive at tallene kan have decimaler.
Jeg tror at COBOL var langt forud andre sprog mht. mulighederne for at regne på "store normale decimaltal med kommaer" dengang det kom frem... og det er måske derfor det blev så succesrigt?
Og det med XML og OO... tja.. En ting er hvad Wikipedia siger at COBOL understøtter. Det er en helt anden sag hvad der rent faktisk bliver brugt.
XML bruges naturligvis i stor stil udadtil. Men det er ikke noget man roder rundt med inde i selve kernen af systemerne.
Ja det er naturligvis fixed point. Jeg tror bare jeg kom til at skrive floating point fordi jeg egentlig ville skrive at tallene kan have decimaler.
Jeg tror at COBOL var langt forud andre sprog mht. mulighederne for at regne på "store normale decimaltal med kommaer" dengang det kom frem... og det er måske derfor det blev så succesrigt?
Og det med XML og OO... tja.. En ting er hvad Wikipedia siger at COBOL understøtter. Det er en helt anden sag hvad der rent faktisk bliver brugt.
XML bruges naturligvis i stor stil udadtil. Men det er ikke noget man roder rundt med inde i selve kernen af systemerne.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund