Cobol fylder 60


Gå til bund
Gravatar

#1 arne_v 5. sep. 2019 23:46

The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#2 larsp 6. sep. 2019 15:34

Det er utroligt at der ikke findes nogle tools der kan oversætte fra COBOL til moderne sprog godt nok til at man kan få pensioneret COBOL.

Jeg tror at de slet ikke ønsker at opgradere. If it ain't broken, don't fix it.
Stop using Google all the time: https://justsearchportal.com - Without distractions - Respecting privacy
Gravatar

#3 arne_v 6. sep. 2019 15:46

#2

Jeg tror godt at man kan lave en automatisk oversættelse til andre sprog (der findes Cobol compilere til JVM og CLR og den byte code kan decompiles til Java og C#).

Men automatisk oversat kode er generelt ikke vedligeholdelses venligt og Cobol stil vil ikke passe godt med nyere sprog, så man vil nok komme fra asken i ilden med den tilgang.

Man kan også genskrive funktionaliteten fra bunden af i et andet sprog. Men:
* det koster penge - mange penge
* vil tage tid at få gjordt fejlfrit
* man har valget mellem at genskrive et moving target eller at stoppe al forretningsudvikling i et par år

Ikke specielt attraktivt.

Det sker nogle gange. Typisk som en del af et større "oprydnings" projekt.

Men de fleste vælger at beholde Cobol koden "as is" og tilføje ny funktionalitet i andre systemer og nyere sprog omnkring kerne systemet i Cobol.

Og Cobol kan godt gå hen og få 60 år mere.

The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#4 larsp 6. sep. 2019 16:10

#3 Okay, så man bevarer COBOL i kernesystemet.

Men kunne man ikke identificere alle interfaces til denne kerne og udvikle et nyt system op af de samme interfaces og så sammenholde systemerne indtil de opfører sig præcis ens? Det er nok nemmere sagt end gjort...
Stop using Google all the time: https://justsearchportal.com - Without distractions - Respecting privacy
Gravatar

#5 arne_v 6. sep. 2019 16:35

#4

Man kan.

Men der antages normalt at der er 200 millliarder linier Cobol (gammelt tal af tvivlsom oprindelse, men det er bedste estimat).

Der eksisterer formentligt kun automatiserede test til en meget lille del af funktionaliteten.

Dokumentationen er formentligt generelt ringe - noget mangler og noget er ikke uptodate - det er svært at undgå med software som er 30 eller 40 eller 50 år gammelt. Noget af den Cobol kode er fra før tekstbehandling.


The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#6 arne_v 18. sep. 2019 01:37

Dagens quiz spørgsmål: hvad gjorde at Cobol blev anset for en oplagt mulighed for business backend application indtil langt op i 90'erne?

The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#7 PHP-Ekspert Thoroughbreed 18. sep. 2019 06:07

Dumt spørgsmål - men har COBOL egentligt ikke også danske aner, eller er det primært Pascal/Delphi?
Doner til Kræftens Bekæmpels i forbindelse med JJ's for tidlige afsked: https://www.betternow.org/dk/jjnewzdk
Gravatar

#8 larsp 18. sep. 2019 06:58

#7 Måske tænker du på COMAL :)
Stop using Google all the time: https://justsearchportal.com - Without distractions - Respecting privacy
Gravatar

#9 PHP-Ekspert Thoroughbreed 18. sep. 2019 09:59

#8

JA! Selvfølgelig, min fejl :)
Doner til Kræftens Bekæmpels i forbindelse med JJ's for tidlige afsked: https://www.betternow.org/dk/jjnewzdk
Gravatar

#10 arne_v 18. sep. 2019 11:56

#7 #8 #9

Mange sprog har danske aner:

Delphi - Anders Hejlsberg
C# - Anders Hejlsberg
TypeScript - Anders Hejlsberg
C++ - Bjarne Stroustrup
PHP - Rasmus Lerdorf

Men ikke Cobol. Cobol var Grace Hopper (42 år i US Navy med slutgrad af Kontreadmiral).
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#11 Claus Jørgensen 18. sep. 2019 12:42

arne_v (6) skrev:
Dagens quiz spørgsmål: hvad gjorde at Cobol blev anset for en oplagt mulighed for business backend application indtil langt op i 90'erne?

Indbygget support for DB2?
Gravatar

#12 arne_v 18. sep. 2019 17:17

#11

Du mener embedded SQL.

Det at alle de store databaser understøtter embedded SQL i Cobol har uden tvivl hjulpet med at forlænge Cobols tid.

Men Cobol er meget ældre end relationelle databaser:

Cobol - 1959

Oracle DB - 1979
Informix - 1981
IBM DB2 - 1983
DEC RDB - 1984
Sybase - 1987
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#13 Claus Jørgensen 18. sep. 2019 20:23

#12

Ja, var ikke sikker på det rigtige term. Min far kaldte det aldrig SQL
Gravatar

#14 arne_v 18. sep. 2019 23:23

#13

Jeg er ikke specielt kyndig i hverken Cobol eller mainframe, men det kan vist kun være embedded SQL.

Embedded SQL er iøvrigt ikke helt dumt.

Eksempel (C ikke Cobol!):


void t1_put(int f1, char *f2)
{
EXEC SQL BEGIN DECLARE SECTION;
char insf2[51];
long int insf1;
EXEC SQL END DECLARE SECTION;
/* execute */
insf1 = f1;
strcpy(insf2, f2);
EXEC SQL INSERT INTO t1 VALUES(:insf1, :insf2);
if(sqlca.sqlcode != 0) sql_exit("insert");
/* check if OK */
if(sqlca.sqlerrd[2] != 1)
{
other_exit("INSERT did not insert 1 row");
}
}


Man skriver bare sine SQL sætninger med prefix EXEC SQL.
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#15 larsp 19. sep. 2019 06:15

#14. Eww der er en buffer overflow i din C kode. :)
Stop using Google all the time: https://justsearchportal.com - Without distractions - Respecting privacy
Gravatar

#16 arne_v 19. sep. 2019 13:37

The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#17 arne_v 19. sep. 2019 18:23

#15

Ja. Den faste array størrelse og strcpy er en dårlig kombination.
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#18 arne_v 3. okt. 2019 13:00

#5

Så lige et eksempel.

Commonwealth Bank of Australia migrerede fra Cobol til noget nyere i 2012. Det tog 5 år og kostede 750 M$.

Der kan købes mange poser vingummi bamser for det beløb.
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#19 arne_v 3. okt. 2019 14:11

#6

Mine bedste bud:

1) Indbygget support for ISAM filer (per terminologi fra den gang, idag vil man kalde det en NoSQL key value store). Førend relationelle databaser var det jo nærmest en nødvendighed.

2) Indbygget support for fixed point data type. Som bekendt er der jo dødsstraf for at bruge floating point data typer til penge beløb.
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gå til top

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.

Opret Bruger Login