Banken bytter «motor» – gjør seg mindre avhengig av stormaskin og Cobol

[quantum]

Ikke kredit, men innskudd. Aha.

[Ompa Kaiiizer]

Vanskeligere enn man skulle tro, i og med at datamaskiner ikke har tall, men kun estimerer tall ved bruk av flytende punkt.

 

Det er fort gjort at små feil blir til store følgefeil, i et slikt system, og man må ha en nøyaktig representasjon av tall.

 

For eksempel : https://jsfiddle.net/oj68ow4f/

 

Og du bruker JavaScript for å bevise poenget ditt?! Ok....

[Ompa Kaiiizer]

COBOL er på ingen måte en brems, for enkle finansielle transaksjoner er det sannsynligvis langt raskere enn for eksempel Java, og det kjører helt fint på hardware som støtter hotswapping og som klarer enorme mengder I/O osv.

 

Det er jo derfor COBOL er å foretrekke, det er bunnstabilt, og har bevist at det klarer å holde tritt med verdens finansielle transaksjoner uten de helt store problemene, men jeg forstår selvfølgelig at bankene ønsker å bygge mer moderne ting, men jeg er ikke helt sikker på at Java nødvendigvis er noe bedre?

 

Så er det jo som det står i artikkelen slik at man ikke skal bytte ut grunnsystemene, Sparebank 1 er jo avhengig av å kommunisere med resten av verden.

 

Så å si alle finansielle transaksjoner går gjennom en mainframe, og det er ikke bare snakk om nettbank, men all bruk av kort, minibanker og lignende.

Totalt kan enkelte core-mainframes prosessere millioner av transaksjoner i sekundet, til sammenligning tar Google i mot 50-100k søk i sekundet, slik at høy I/O og 110% tilgjengelighet er helt livsviktig for finanssektoren.

 

Resten av systemet er jo basert på COBOL, enten det er minibanken, kortterminalen eller serveren som tar i mot transaksjonen, så er COBOL stort sett i bruk over alt, slik at når Sparebank 1 nå skal benytte mer Java, så er det helt sikkert ikke grunnsystemene som byttes ut, men kun et ekstra lag for å gjøre det enklere å kommunisere med mainframen e.l.

 

Nå er jo Java et forholdsvis trygt språk, det har en del innebygget håndtering av feil og lignende, men jeg vil påstå at Java er betydelig mer utsatt for feil enn COBOL, og kan i verste fall fortsette å kjøre med minnelekkasjer og det som verre er, å gjøre for eksempel feil kalkulasjoner, som ville være totalt katastrofe i et banksystem.

 

Men, ønsker Sparebank 1 å ta den risikoen, og samtidig betale milliarder av kroner for den tvilsomme æren å få ustabile moderne systemer, og av Evry av alle, som det virker som alltid står bak alle de store systemene som feiler på rekke og rad, så må de gjerne gjøre det for meg, jeg er ikke kunde der, slik at det er ikke mine penger de roter bort, og heller ikke mine kontoer som ikke er tilgjengelig på grunn av "Evry-feil", som jeg liker å kalle det.

 

Godt mulig COBOL er veldig fint, flott, og stabilt, men særlig fremtidsrettet er det vel ikke? Dette skal jo forvaltes noen år frem i tid også. Lykke til med å rekruttere COBOL-utviklere om 10, 20, 30 år. Eller er det de satser på borte i India?

[hanlan]

Det er flere grunner til at COBOL benyttes, det er et enkelt språk som er uovertruffent til tall som representerer valutaer, altså med to desimaler

Det er vel ganske lenge siden man gikk fra å regne valuta med fire desimaler til seks. Husker vi snakket om det på jobben i '99-2000 en gang.

 

Og når det gjelder avrundingsfeil med flyttall, så finnes datatypen Decimal i IEEE 754 som ikke har avrundingsfeil. Den er støttet i alle relevante CPU'er.

https://en.wikipedia.org/wiki/Decimal_floating_point

[_Nils_]

Det er flere grunner til at COBOL benyttes, det er et enkelt språk som er uovertruffent til tall som representerer valutaer, altså med to desimaler, det er tross alt laget kun for dette formålet, og det er bunnstabilt og har vært benyttet til omtrent alle transaksjoner de siste 30 årene, og har eksistert i 57 år nå, nærmest uten feilslag.

Nå håper jeg du mener desimaler generelt, og ikke bare 2 - i så fall har bankene et problem de burde fikse ASAP.

[tommyb]

 

Vanskeligere enn man skulle tro, i og med at datamaskiner ikke har tall, men kun estimerer tall ved bruk av flytende punkt.

 

Det er fort gjort at små feil blir til store følgefeil, i et slikt system, og man må ha en nøyaktig representasjon av tall.

 

For eksempel : https://jsfiddle.net/oj68ow4f/

Og du bruker JavaScript for å bevise poenget ditt?! Ok....

 

 

Mener du at eksemplet hans ikke godt nok illustrerte problemet med flytetall? 

[0laf]

Og du bruker JavaScript for å bevise poenget ditt?! Ok....

Jeg kan jo alltids skrive det samme i Java, det blir ikke noe annerledes av den grunn, som nevnt tidligere er det et underliggende problem med hvordan datamaskiner fungerer, ikke språket.

 

Godt mulig COBOL er veldig fint, flott, og stabilt, men særlig fremtidsrettet er det vel ikke? Dette skal jo forvaltes noen år frem i tid også. Lykke til med å rekruttere COBOL-utviklere om 10, 20, 30 år. Eller er det de satser på borte i India?

COBOL er et forholdsvis enkelt språk å lære, man er oppe å går i løpet av noen uker, og så lenge det finnes godt betalte jobber innen språket, så er det alltid noen som lærer seg det.

I dag er det enorme mengder med COBOL i bruk, og selv om Sparebank 1 legger om sine systemer, vil resten av finansverdenen benytte COBOL i mange år enda, samt at mange andre bedrifter fremdeles har gamle systemer skrevet i COBOL, for å ikke glemme at COBOL er et språk som fremdeles vedlikeholdes og oppdateres.

 

Det er vel ganske lenge siden man gikk fra å regne valuta med fire desimaler til seks. Husker vi snakket om det på jobben i '99-2000 en gang.

 

Og når det gjelder avrundingsfeil med flyttall, så finnes datatypen Decimal i IEEE 754 som ikke har avrundingsfeil. Den er støttet i alle relevante CPU'er.

 

Når du kjøper noe i Kongeriket Noreg, er gjerne øre den minste verdien, derav to desimaler.

Ved valutakurser for omregning benyttes sikkert 6 desimaler, jeg vet at DNB benytter 4 i sine lister, og Google benytter 7, så presisjon varierer nok noe.

Enkelte verdipapirer kan være priset ned i 1/100000 øre osv. og det finnes sikkert andre produkter som prises slik, men generelt sett så opereres det med kroner og hele øre.

COBOL støtter opp til 18 desimaler rett ut av boksen, med presisjon, slik at det er neppe noe problem.

 

Vanlige prosessorer støtter ikke dette i hardware, hadde de gjort det hadde man ikke hatt noen problem med flyttall, og heller ikke trengt egne klasser med høy presisjon, men som også nevnt tidligere implementerer de fleste språk egne klasser som håndterer større tall, slik som nettopp BigDecimal i Java, samt at C++ og Python har flere egne klasser, til og med Javascript har slikt tilgjengelig dersom man trenger presisjon -> https://github.com/jtobey/javascript-bignum/blob/master/lib/decimal.js

Endret 8. november 2016 av adeneo

[Tastaturskriver]

Skjønner ikke helt denne diskusjonen rundt datatyper i Java. Dersom jeg skulle gjennomført en transaksjon i Java ville jeg gjennomført hele greia i databasen. I mitt hode virker det helt merkelig å skulle trekke ut to tall fra databasen, binde dem til en datatype i Java, summere tallene og deretter putte de tilbake igjen i databasen. Men jeg driver ikke men finansielle applikasjoner, så hva vet jeg.

[0laf]

Dersom jeg skulle gjennomført en transaksjon i Java ville jeg gjennomført hele greia i databasen. I mitt hode virker det helt merkelig å skulle trekke ut to tall fra databasen, binde dem til en datatype i Java, summere tallene og deretter putte de tilbake igjen i databasen. 

 

For det første så er det jo helt vanlig å foreta aritmetikk utenfor databasen, man kan ikke bruke databasen til slikt i alle tilfeller, og i mange tilfeller burde man ikke bruke databasen, selv om man kan, ettersom det tar opp ressurser.

 

Først og fremst er man selvfølgelig avhengig av en database som støtter slikt.

De fleste relasjonsdatabaser har en eller annen "sum" funksjon, men det skorter gjerne på matematiske funksjoner utover det.

 

Benytter man en NoSQL database som kun lagrer nøkler og verdier, så finnes det normalt ingen mulighet til å utføre slikt i databasen, ettersom det er optimalisert, enten for lesing eller lagring, eller for begge deler, ikke for matematikk.

 

Selv om databasen skulle støtte enkel aritmetikk, så har du jo akkurat det samme problemet, sannsynligvis i enda større grad, ettersom databasen også er avhengig av å benytte flyttall, og gjør samme regnefeilen.

 

Dette er jo et kjent problem for eksempel i MySQL når man summerer uten angitt presisjon -> http://bugs.mysql.com/bug.php?id=1961

[Gjest Slettet+6132]

 

 

Godt mulig COBOL er veldig fint, flott, og stabilt, men særlig fremtidsrettet er det vel ikke? Dette skal jo forvaltes noen år frem i tid også. Lykke til med å rekruttere COBOL-utviklere om 10, 20, 30 år. Eller er det de satser på borte i India?

 

 

COBOL er ett programmeringspråk. Stabilt? Ikke mer stabilt enn den som har kodet det.

Den mest vanlige *platformen* hvor COBOL "ruler" er "stormaskin" (zOS nå får tiden). Og *det* er utvilsomt en stabil platform.

Når det gjelder COMP-3, datatypen i COBOL som brukes for BCD/EBCDIC så er jeg ikke sikker på om det er COBOL eller platformen (IBM stormaskin) som skal ha æren for at avrunding ikke er ett problem (på denne platformen)

 

Og ja. Indere rekrutterer lett unge folk til å jobbe med utrangerte bank/forskikring(stormaskin)systemer.

Godt betalt, og de som kan COBOL i f.eks. Norge er en utdøende rase. Bokstavelig talt.

Er mange dyktige norske COBOL/Stormaskin-konsulenter som idag må omskoleres til testledere/prosjektledere da tidligere kunder (DnB/If/Statoil/Posten.. m.flere) synes det er lurt å bruke billige indere som sitter i India til å vedlikeholde source-koden fra 70-80-90-tallet.

[Tetrisen]

Java? Seriøst? Har dem ennå ikke klart å bli kvitt Java-koden?
Til og med COBOL kjører bedre enn Java makkverket.

[0laf]

Java er et glimrende språk til sitt bruk, og det inkluderer faktisk det aller meste av software-utvikling.

 

Det du tenker på, er nok JRE elendigheten som kjører i nettleseren, og den er forhåpentligvis død for lengst.

[0laf]

Når det gjelder COMP-3, datatypen i COBOL som brukes for BCD/EBCDIC så er jeg ikke sikker på om det er COBOL eller platformen (IBM stormaskin) som skal ha æren for at avrunding ikke er ett problem (på denne platformen)

Forsåvidt interessant spørsmål, IBM mainframes som kjører COBOL er jo ofte blant de få maskinene som faktisk har hardwarestøtte for å løse problemet med flyttall, slik at det kan være at de serverne rett og slett ikke har det samme problemet som andre maskiner.

 

Jeg vet ikke, men mener uansett at ettersom COBOL ble utviklet kun for finansiell data, så løser selve språket også problemet ved å håndtere store tall rett ut av boksen.

 

Husker jeg ikke feil, støtter COMP-5 tall fra -9,223,372,036,854,775,808 helt opp til  9,223,372,036,854,775,807, med presisjon, og jeg tror ikke det er plattformavhengig, men er usikker?

[Gjest Slettet+6132]

 

Når det gjelder COMP-3, datatypen i COBOL som brukes for BCD/EBCDIC så er jeg ikke sikker på om det er COBOL eller platformen (IBM stormaskin) som skal ha æren for at avrunding ikke er ett problem (på denne platformen)

Forsåvidt interessant spørsmål, IBM mainframes som kjører COBOL er jo ofte blant de få maskinene som faktisk har hardwarestøtte for å løse problemet med flyttall, slik at det kan være at de serverne rett og slett ikke har det samme problemet som andre maskiner.

 

Jeg vet ikke, men mener uansett at ettersom COBOL ble utviklet kun for finansiell data, så løser selve språket også problemet ved å håndtere store tall rett ut av boksen.

 

Husker jeg ikke feil, støtter COMP-5 tall fra -9,223,372,036,854,775,808 helt opp til  9,223,372,036,854,775,807, med presisjon, og jeg tror ikke det er plattformavhengig, men er usikker?

 

Må alltid sjekke manual i slike tilfelle.

COMP-5 er "native" binary og er (relativt) ny på "mainframe".

Første gang jeg kom borti det var med Micro Focus for sikkert 20 år siden og da betød det "little-endian" vs "big-endian" (COMP) og ble brukt mot UDB (DB2 på Windows) og mot MQ API.

 

Men nå er vi veeeldig off-topic

Endret 8. november 2016 av Slettet+6132

[endrebjo]

Selv om databasen skulle støtte enkel aritmetikk, så har du jo akkurat det samme problemet, sannsynligvis i enda større grad, ettersom databasen også er avhengig av å benytte flyttall, og gjør samme regnefeilen.

 

Dette er jo et kjent problem for eksempel i MySQL når man summerer uten angitt presisjon -> http://bugs.mysql.com/bug.php?id=1961

Databasen du bruker må naturligvis bruke en datatype som passer til dataene du ønsker å lagre der. Skal du lagre finansielle data, kan du uansett ikke lagre dataene som flyttall i databasen. Derfor har alle fornuftige databaser støtte for en decimal/numeric datatype som _ikke_ er flyttall. Du har mulighet til å bruke flyttall også (ofte kalt double eller real), men du skal selvfølgelig ikke gjøre det. Og når databasen gjør aritmetikk på disse dataene, så bruker den selvfølgelig operatorer som er beregnet for den definerte datatypen. Altså behandles decimal/numeric som en presis datatype med definert presisjon.

Her har du eksempler fra både DB2 og PostgreSQL:

http://www.ibm.com/support/knowledgecenter/SSEPEK_10.0.0/intro/src/tpc/db2z_numericdatatypes.html

https://www.postgresql.org/docs/9.2/static/datatype-numeric.html

Samme datatypene finner du også i MySQL, så problemet du linker til er egentlig ikke-eksisterende.

 

Først og fremst er man selvfølgelig avhengig av en database som støtter slikt.

 

De fleste relasjonsdatabaser har en eller annen "sum" funksjon, men det skorter gjerne på matematiske funksjoner utover det.

Det ble sagt at operasjonene som ble utført i COBOL er veldig enkle. I såfall burde det stort sett være tilstrekkelig med de fire matematiske operasjonene (+, -, *, /) man finner i de fleste relasjonsdatabaser. Implementasjonen av disse er naturligvis også basert på hvilke datatyper du har definert.

http://www.ibm.com/support/knowledgecenter/SSEPEK_11.0.0/sqlref/src/tpc/db2z_arithmeticwith2decimal.html

https://www.postgresql.org/docs/9.3/static/functions-math.html

 

Jeg skal ikke påstå at aritmetikk-farten på en databasemotor nødvendigvis er bedre enn COBOL. Men for dataintegritetens skyld burde regneoperasjonene gjøres så tett på kilden som mulig. Når data skyfles frem og tilbake mellom database og program er risikoen for feil høyere enn enn når du gjør det internt i programmet. Spesielt siden databasen og programmeringsspråket sannsynligvis ikke deler felles datatyper. Å skyfle data frem og tilbake krever også sine klokkesykler.

[0laf]

Databasen du bruker må naturligvis bruke en datatype som passer til dataene du ønsker å lagre der.

 

Selvfølgelig, poenget var kun at selv ikke databaser er immune mot feil med flyttall, og må ha støtte for den slags typer, og dette mangler faktisk i en del NoSQL databaser. DB2 har selvfølgelig slik støtte, det er jo IBM's database som oftest benyttes sammen med COBOL systemer på mainframe.

 

Jeg skal ikke påstå at aritmetikk-farten på en databasemotor nødvendigvis er bedre enn COBOL. Men for dataintegritetens skyld burde regneoperasjonene gjøres så tett på kilden som mulig. Når data skyfles frem og tilbake mellom database og program er risikoen for feil høyere enn enn når du gjør det internt i programmet.

Jeg personlig er mer fan av å bruke databasen til kun å lagre og hente data, å gjøre så lite arbeid som mulig.

Mest fordi feilhåndtering i de fleste databaser er elendig, og man får sjeldent noe beskjed tilbake dersom ting ikke går helt som planlagt.

 

Hastigheten er som oftest elendig også, men det varierer nok en del fra database til database, og har enormt mye med spørringen å gjøre.

 

Det er etter min mening også enklere å skalere servere til å håndtere kostbare kalkulasjoner, samtidig som man har høy throughput, enn å skalere relasjonelle databaser til å håndtere kalkulasjoner med høy throughput, særlig dersom man lager effektive prosedyrer for de vanligste operasjonene, og COBOL benyttes jo som regel nettopp fordi man har enorme mengder transaksjoner som kommer inn, og selv relativt enkle SQL spørringer som gjør aritmetikk i en database har en tendens til å ikke være særlig raske.

 

Det finnes selvfølgelig unntak. Hvis man tenker seg at en transaksjon kommer inn, og noen tall kun skal adderes, så er det nok som regel billigere å sende tallet til databasen med en spørring som legger til, enn å hente data fra databasen, addere, og så sende resultatet tilbake til databasen, særlig dersom man regner nettverkskostnad i tillegg til hastigheten på spørringen osv. og dersom man kan aggregere innad i indekser og slikt.

 

Nå driver ikke jeg med hverken COBOL eller mainframes, så hva som er å foretrekke ligger litt utenfor ting jeg har greie på, men jeg antar at det som alt annet kommer helt an på dataene.

Endret 9. november 2016 av adeneo