Zukunft von COBOL

[Magnus Warker]

Hallo,

ich beobachte gerade eine kontroverse Diskussion um ein sehr kritisches
System, welches Zahlungsanweisungen in Millionenh�he steuert,

Dieses System soll aus diversen Gr�nden erneuert werden, und es geht um
das Ausma� der Erneuerung im Hinblick auf die Architektur und die
verwendeten Programmiersprachen. Die Verarbeitungslogik ist in COBOL
programmiert und dies steht zur Debatte.

Die Bef�rworter, i. d. R. die origin�ren Entwickler, argumentieren, das
System laufe performant und es mangele nicht an leistungsf�higen
Compilern. Daher sei dieser Teil des Systems nicht in Frage zu stellen.

Die Kritiker argumentieren, dass die Programmiersprache veraltet sei und
dass die Wartung dieser Software irgendwann problematisch wird, weil es
keine Programmierer f�r COBOL mehr geben wird.

Mich w�rde interessieren, wie das in dieser Gruppe eingesch�tzt wird.
Bew�hrte Technik oder veraltetes Relikt?

Viele Gr��e
Magnus

[Volker Birk]

Magnus Warker <mag...@mailinator.com> wrote:
> Mich würde interessieren, wie das in dieser Gruppe eingeschätzt wird.
> Bewährte Technik oder veraltetes Relikt?

Bewährtes, veraltetes Relikt.

Viele Grüsse,
VB.
--
“Isabell steht auf Cocktailschirmchen, Analverkehr und House
und hat 186 Freunde
ansonsten weiss ich nichts über sie”
(Jenna Gesse)

[Wolfgang May]

Magnus Warker <mag...@mailinator.com> wrote:
> Hallo,
>
> ich beobachte gerade eine kontroverse Diskussion um ein sehr kritisches

> System, welches Zahlungsanweisungen in Millionenhöhe steuert,
>
> Dieses System soll aus diversen Gründen erneuert werden, und es geht um
> das Ausmaß der Erneuerung im Hinblick auf die Architektur und die
> verwendeten Programmiersprachen.

D.h. es soll also neu strukturiert und programmiert werden?

> Die Verarbeitungslogik ist in COBOL
> programmiert und dies steht zur Debatte.
>

> Die Befürworter, i. d. R. die originären Entwickler,

Wie alt sind die? 55+ ?
Schratige Typen, die noch eine Lochkarte mit dem Einkaufszettel
in der Hosentasche mit sich rumtragen?

> argumentieren, das
> System laufe performant und es mangele nicht an leistungsfähigen
> Compilern.

stimmt.

> Daher sei dieser Teil des Systems nicht in Frage zu stellen.

Nicht "daher". Offensichtlich wird er aber doch aus anderen Gruenden
in Frage gestellt?

> Die Kritiker argumentieren, dass die Programmiersprache veraltet sei und
> dass die Wartung dieser Software irgendwann problematisch wird, weil es

> keine Programmierer für COBOL mehr geben wird.

"Keine" wird nicht stimmen, aber wenige, ggf. sehr teure, von denen man
sich abhaengig macht.

Fast jeder Informatiker kann jede beliebige prozedurale
Programmiersprache in kurzer Zeit lernen, das ist prinzipiell kein
Problem. Aber es sind halt hoechstens einzelne, die gezielt fuer
solche Legacy-Projekte "fortgebildet" und eingesetzt werden (und da
ihnen das am allgemeinen Arbeitsmarkt nichts bringt, bzw man mit "in
den letzten Jahren nur COBOL gemacht" keinen anderen Arbeitsplatz
findet, lassen die sich dann teure Lebenszeitvertraege
garantieren). Ich erinnere mich noch an das Y2K-Problem, und die Suche
nach im Ruhestand befindlichen Ex-Programmierern, die irgendwelche
Zombie-Betriebssysteme und /oder Programmiersprachen beherrschen.

> Mich würde interessieren, wie das in dieser Gruppe eingeschätzt wird.
> Bewährte Technik oder veraltetes Relikt?

Beides.
Wenn man aber jetzt eh schon alles erneuern will, sollte man dazu eine
zeitgemaesse Programmiersprache (+Entwicklungstools und -methoden, ggf
auch mit Codeverifikation) nehmen.

Wolfgang

[Magnus Warker]

On 08/02/2012 09:33 PM, Wolfgang May wrote:

> Magnus Warker<mag...@mailinator.com> wrote:

>> ich beobachte gerade eine kontroverse Diskussion um ein sehr kritisches

>> System, welches Zahlungsanweisungen in Millionenhï¿œhe steuert,
>>
>> Dieses System soll aus diversen Grï¿œnden erneuert werden, und es geht um
>> das Ausmaￜ der Erneuerung im Hinblick auf die Architektur und die

>> verwendeten Programmiersprachen.
>
> D.h. es soll also neu strukturiert und programmiert werden?

Genau so ist es.

>> Die Verarbeitungslogik ist in COBOL
>> programmiert und dies steht zur Debatte.
>>

>> Die Befï¿œrworter, i. d. R. die originï¿œren Entwickler,

>
> Wie alt sind die? 55+ ?
> Schratige Typen, die noch eine Lochkarte mit dem Einkaufszettel
> in der Hosentasche mit sich rumtragen?

Ja, und die von einer Fortbildung in den 70er Jahren schwï¿œrmen, in der
sie "programmieren" gelernt haben.

>> Daher sei dieser Teil des Systems nicht in Frage zu stellen.

> Nicht "daher". Offensichtlich wird er aber doch aus anderen Gruenden
> in Frage gestellt?

Das System ist Teil eines grￜￜeren Gesamtsystems, welches mittlerweile
in Java EE ï¿œberfï¿œhrt wurde. Der Anlass der Diskussion ist die
Integration der Systeme und eine gemeinsame Datenhaltung.

> Wenn man aber jetzt eh schon alles erneuern will, sollte man dazu eine
> zeitgemaesse Programmiersprache (+Entwicklungstools und -methoden, ggf
> auch mit Codeverifikation) nehmen.

Sehe ich auch so, aber welches wï¿œren indiskutable Grï¿œnde dafï¿œr? Einfach
nur "zeitgemￜￜ" bringt in dieser Diskussion nicht weiter. Die an dieser
Programmiersprache haftenden veralteten Entwicklungsmethoden wiegen IMHO
schwer. Gibt es auch Grï¿œnde, die in der Sprache selbst liegen?

Magnus

[Stefan Nobis]

Magnus Warker <mag...@mailinator.com> writes:

> Einfach nur "zeitgemäß" bringt in dieser Diskussion nicht
> weiter.

Das würde ich auch so sehen. Ich bin ein Technik-Freak, ich persönlich
würde Systeme einfach nur aus dem Grund neu schreiben, weil ich eine
neue Technologie ausprobieren möchte.

Aber aus wirtschaftlicher Sicht verbietet sich so etwas natürlich
sofort. Und ich denke, dass ist letztlich der entscheidene Punkt:
Welchen wirtschaftlichen Vorteil bringt es, in ein funktionierendes
System viel Geld zu stecken, um es neu zu schreiben. Dabei springt ja
i.d.R. erstmal kein unmittelbarer wirtschaftlicher Nutzen heraus.

Ich arbeite derzeit auch an einem Alt-System (nicht Cobol). Es wird
schon seit ca. 10 Jahren immer mal wieder darüber gesprochen, das
System komplett neu zu schreiben oder zumindest teilweise zu
modernisieren. Warum ist bisher nichts in dieser Richtung passiert:
Mangelnder Leidensdruck (und zu wenig Resourcen).

"Just good enough" und "nichts hält länger als ein Provisorium" sind
Sprüche, die dies unterstreichen: Es braucht wirklich gute Gründe,
etwas Funktionierendes neu zu machen. Und das ist prinzipiell
(zumindest aus wirtschaftlicher Sicht) auch gut.

> Die an dieser Programmiersprache haftenden veralteten

> Entwicklungsmethoden wiegen IMHO schwer. Gibt es auch Gründe, die in
> der Sprache selbst liegen?

Im so gut wie keinem Fall gibt es Gründe, die sich unmittelbar aus der
Programmiersprache herleiten (von dem Problem "es gibt keine Tools und
insbesondere keine Compiler mehr" mal abgesehen).

Was sind überhaupt sinnvolle Gründe dafür, etwas Funktionierendes neu
zu machen? Für Manager muss sich das irgendwie rechnen, d.h. es müssen
dabei Kosteneinsparungen herausspringen oder Risiken gesenkt werden.

Und das wäre mein Ansatzpunkt: Wartbarkeit. Wenn der alte Cobol-Code
sehr gut strukturiert ist, lesbar und verständlich oder zumindest sehr
gut dokumentiert ist und man eh nur selten oder so gut wie nie etwas
daran ändern muss, dann lohnt sich der Aufwand i.d.R. nicht. Nur weil
jemand in den 70er Jahren programmieren gelernt hat, schreibt er ja
nicht automatisch schlechten Code. Alte Programmiersprachen sind nicht
per se schlecht (Lisp ist eine der ältesten Hochsprachen (entstanden
in den 50ern) und macht auch heute noch allen Mainstream-Sprachen
einiges vor). Und man kann auch in modernsten Sprachen, startend mit
hehren Architektur-Plänen, ein grauenvolles Chaos anrichten.

Also immer die Grundregel merken: Neu ist nicht (automatisch) besser!

Bei alten, über Jahrzehnte gewachsene Systeme steht es strukturell oft
eben nicht zum Besten. Es haben sich Altlasten gesammelt, die aktuell
gar nicht mehr benötigt werden. Im Code finden sich viele verschiedene
Architektur-Ansätze, die Teilsysteme sind nicht mehr sauber
gegeneinander abgeschottet, ja selbst die Teilsysteme in sich sind
nicht mehr klar strukturiert.

In so einem Fall kann man eine Neuentwicklung durchaus mit in Zukunft
sinkenden Wartungskosten begründen - sofern man mit einem guten
Konzept und deutlichen strukturellen Verbesserungen aufwarten
kann. Und ein "dieser prozedurale Kram ist dann ganz toll
objektorientiert" ist natürlich keine Verbesserung. Man sollte sich
überlegen, ob man wirklich nennenswerte Vereinfachungen erzielen
kann. Gibt es Synergie-Effekte dadurch, dass man das Gesamtsystem
komplett neu macht. In dieser Richtung sollte man nach Argumenten
suchen.

--
Stefan.

[Wolfgang May]

Magnus Warker <mag...@mailinator.com> wrote:

>> Nicht "daher". Offensichtlich wird er aber doch aus anderen Gruenden
>> in Frage gestellt?
>

> Das System ist Teil eines größeren Gesamtsystems, welches mittlerweile
> in Java EE überführt wurde. Der Anlass der Diskussion ist die

> Integration der Systeme und eine gemeinsame Datenhaltung.

Letzteres ist absolut wichtig.
Und es bedeutet wohl, dass man an dem COBOL-Teil auch Aenderungen
vornehmen muss.

>> Wenn man aber jetzt eh schon alles erneuern will, sollte man dazu eine
>> zeitgemaesse Programmiersprache (+Entwicklungstools und -methoden, ggf
>> auch mit Codeverifikation) nehmen.
>

> Sehe ich auch so, aber welches wären indiskutable Gründe dafür? Einfach
> nur "zeitgemäß" bringt in dieser Diskussion nicht weiter. Die an dieser

> Programmiersprache haftenden veralteten Entwicklungsmethoden wiegen IMHO

> schwer. Gibt es auch Gründe, die in der Sprache selbst liegen?

Jein.
Wenn's funktioniert, ist es gut. Wenn man nienienienie
etwas aendern/debuggen muss.

Man kann sogar etwas boese sagen: je aelter und "nackter" die
Sprachen, desto performanter laeuft es (nicht umsonst spielt bei eher
einfachen, aber zeitkritischen Programmen u.a. im Embedded-Bereich C
immer noch eine grosse Rolle). Der "neumodische
Abstraktions-Firlefanz" (Objektorientierung, Polymorphie, Late
Binding, ...) kostet nur Laufzeit - da kann auch der beste Compiler
nicht alles retten.

Evtl waren die Programmierer damals auch im Schnitt faehiger
(und gruendlicher) als heute (weil Fehlersuche aufgrund
fehlender Entwicklungsumgebungen deutlich aufwaendiger war).

Aber:

1) Das Problem geeigneten Personals wurde bereits diskutiert.

2) COBOL benutzt noch GOTO-Statements, und bietet ansonsten wenig
Strukturierungskonzepte (und viele Software-Engineering-Grundlagen
waren in den 70ern auch noch nicht bekannt). D.h., bereits die
Urversion duerfte (zeit- und programmgroessen-effizienter)
Spaghetticode mit wuesten Spruengen gewesen sein, dann ca. 10 Jahre
intensive Entwanzung und Weiterentwicklung, Ergaenzungen, und seitdem
abnehmend immer mal wieder was. Das duerfte ein undurchdringliches
Dickicht sein, wo ein "Neuer" nicht mehr wirklich reinkommt (THX to
GOTO!). Man kann also nur hoffen, dass man es nie mehr anfassen
muss ...

Eine komplette Neuentwicklung (d.h., nicht den bestehenden Code in
Java abschreiben (was schon nicht geht, wenn da nur ein einziges GOTO
drin ist), sondern angefangen bei einem Pflichtenheft mit funktionaler
Spezifikation) ist da IMHO eindeutig am sinnvollsten.

Wolfgang

[Achim Peters]

Am 03.08.2012 08:02, schrieb Stefan Nobis:
>
> Wenn der alte Cobol-Code

> sehr gut strukturiert ist, lesbar und verstï¿œndlich oder zumindest sehr
> gut dokumentiert ist
[...]

> dann lohnt sich der Aufwand i.d.R. nicht.

Wenn er das aber nicht ist, kï¿œnnte der Aufwand des Neuschreibens (incl.
Full-Regression) leicht jeden Rahmen sprengen und das Ding am Ende
dennoch nicht mit hinreichender Sicherheit die Funktionalitï¿œt des
Vorgï¿œngers abdecken. Da schlummern dann Zeitbomben drin, weil keiner
mehr ganz genau weiￜ, was das Ding eigentlich alles kￜnnen muss
(hinreichende Komplexitï¿œt setze ich mal als gegeben voraus).

> Bei alten, ï¿œber Jahrzehnte gewachsene Systeme steht es strukturell oft

> eben nicht zum Besten. Es haben sich Altlasten gesammelt, die aktuell

> gar nicht mehr benï¿œtigt werden. Im Code finden sich viele verschiedene
> Architektur-Ansï¿œtze, die Teilsysteme sind nicht mehr sauber

> gegeneinander abgeschottet, ja selbst die Teilsysteme in sich sind
> nicht mehr klar strukturiert.

ACK. Ein weiterer Punkt, der das Neuschreiben erheblich erschwert. Nur
allzu schnell sind sich bei solchen "Altlasten" dann alle sicher, dass
das nicht mehr gebraucht wird. Bis es dann drei Jahre spï¿œter beim Kunden
knallt.

Bye
Achim

[Florian Rehnisch]

o Magnus Warker <mag...@mailinator.com>:

> Die Kritiker argumentieren, dass die Programmiersprache veraltet sei und
> dass die Wartung dieser Software irgendwann problematisch wird, weil es

> keine Programmierer für COBOL mehr geben wird.

Es finden sich auch noch genug Leute, die
Frakturschrift lesen koennen ...

flori

[Alexander Schreiber]

Hmm? Wo ist das Problem, Frakturschrift ist recht gut lesbar.
Sütterlin hingegen ...

Man liest sich,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison

[Magnus Warker]

On 08/03/2012 08:02 AM, Stefan Nobis wrote:

> Magnus Warker<mag...@mailinator.com> writes:

> Im so gut wie keinem Fall gibt es Gründe, die sich unmittelbar aus der
> Programmiersprache herleiten (von dem Problem "es gibt keine Tools und
> insbesondere keine Compiler mehr" mal abgesehen).

Ich sehe da durchaus Probleme, die in einer Sprache an sich liegen
können: Die Wartbarkeit und vor allem Fehleranfälligkeit.

Bei einer Sprache mit strenger Typprüfung z. B. fängt der Compiler
bereits Fehler ab, die in anderen Sprachen zu fehlerhaften Berechnungen
führen können. Bei Zahlungen in Millionenhöhe für mich schon ein Argument.

> Und das wäre mein Ansatzpunkt: Wartbarkeit. Wenn der alte Cobol-Code
> sehr gut strukturiert ist, lesbar und verständlich oder zumindest sehr
> gut dokumentiert ist und man eh nur selten oder so gut wie nie etwas
> daran ändern muss, dann lohnt sich der Aufwand i.d.R. nicht. Nur weil
> jemand in den 70er Jahren programmieren gelernt hat, schreibt er ja
> nicht automatisch schlechten Code.

Automatisch nicht, aber der Code kann ja auch "schlecht" sein in dem
Sinne, dass man Änderungen nur mit hohem Aufwand und Risiko
implementieren kann, eben aufgrund der Sprache an sich.

> Alte Programmiersprachen sind nicht
> per se schlecht

Ich habe auch schon oft den Spruch gehört "Was läuft, ist gut". Aber da
habe ich meine Zweifel. Wie gesagt, der Umfang der Prüfungen, die
bereits zur Compile-Zeit stattfinden können, wäre für mich ein ganz
entscheidendes Kriterium.

> Also immer die Grundregel merken: Neu ist nicht (automatisch) besser!

Klar.

Danke für die Anregungen!

Magnus

[Stefan Nobis]

Magnus Warker <mag...@mailinator.com> writes:

> Bei einer Sprache mit strenger Typprüfung z. B. fängt der Compiler
> bereits Fehler ab, die in anderen Sprachen zu fehlerhaften
> Berechnungen führen können.

Das ist, so pauschal, quark. Natürlich lassen sich leicht beispiele
für trivialen Code finden, in denen eine starke Typprüfung einen
Fehler findet oder eben auch einen vorhandenen Fehler nicht findet.

Es gibt sehr große, extrem komplexe Anwendungen, die beispielsweise in
Common Lisp, mithin ohne statische Typprüfung, geschrieben sind und
wunderbar laufen.

Es gibt ingesamt (in der Menge aller mission-critical Systeme) AFAIK
eher einen sehr geringen Anteil, der in wirklich stark typisierten
Sprachen wie Haskell (oder anderen Vertretern der ML-Familie) oder Ada
geschrieben ist. Sprachen wie Java, C#, C, C++ etc. würde ich nicht
als besonders stark typisiert ansehen, insbesondere sind in solchen
Sprachen noch sehr viele Typfehler möglich, die z.B. in Haskell
unmöglich wären.

Ergo: Viele Anwendungen sind in eher mäßig streng geprüften Sprachen
geschrieben und die Welt dreht sich noch. :)

Das Kernproblem liegt auch woanders: Die Typprüfung kann nur ganz
bestimmte Arten von Fehlern (und auch diese u.U. nur teilweise)
erkennen. Insofern bleiben (riesige) Bereiche von Fehlerklassen, gegen
die auch eine sehr starke Typprüfung wie in Haskell nichts ausrichten
kann.

Daher benötigt man in jedem Fall Werkzeuge zur Qualitätsprüfung und
-sicherung (wie Unit-Tests, Integrationstests, Abteilung von
menschlichen Testern, Beta-Tests usw.). In dieser Werkzeugsammlung
kann auch der Compiler mit seiner starken Typprüfung vorkommen (und
hilfreich sein), ist aber weder notwendig noch hinreichend für gute
Qualität.

> Automatisch nicht, aber der Code kann ja auch "schlecht" sein in dem
> Sinne, dass man Änderungen nur mit hohem Aufwand und Risiko
> implementieren kann, eben aufgrund der Sprache an sich.

Na ja, man kann sicherlich Beispiele für Sprachen finden, die schwer
wartbaren Code quasi herausfordern und natürlich gibt es auch den
Fall, dass für eine Sprache (mittlerweile) keinerlei hilfreiche Tools
existieren. Aber im Großen und Ganzen ist die Sprache sehr selten der
wirklich limitierende Faktor.

> Ich habe auch schon oft den Spruch gehört "Was läuft, ist gut". Aber
> da habe ich meine Zweifel. Wie gesagt, der Umfang der Prüfungen, die
> bereits zur Compile-Zeit stattfinden können, wäre für mich ein ganz
> entscheidendes Kriterium.

Das ist IMHO eines der schwächsten Argumente bzgl. der Entscheidung
für oder gegen eine groß angelegte Migration in eine neue Sprache.

Entweder überschätzt Du die Leistungen eines Compilers und seiner
Prüfungen oder Du unterschätzt die sonstigen Problemfelder massiv.

--
Stefan.

[Magnus Warker]

On 09/02/2012 12:30 PM, Stefan Nobis wrote:
> Magnus Warker<mag...@mailinator.com> writes:

> Ergo: Viele Anwendungen sind in eher mäßig streng geprüften Sprachen
> geschrieben und die Welt dreht sich noch. :)

Damit reihst Du Dich ein in die Befürworter der Argumentation: "Was
läuft ist gut."

> Daher benötigt man in jedem Fall Werkzeuge zur Qualitätsprüfung und
> -sicherung (wie Unit-Tests, Integrationstests, Abteilung von
> menschlichen Testern, Beta-Tests usw.). In dieser Werkzeugsammlung
> kann auch der Compiler mit seiner starken Typprüfung vorkommen (und
> hilfreich sein), ist aber weder notwendig noch hinreichend für gute
> Qualität.

Damit hast Du Recht, aber bei der Ausgangsfrage ging es ausschließlich
um die Programmiersprache. Dass diese nur einen kleinen Ausschnitt in
einem komplexen Gebilde von Einflussfaktoren darstellt, wurde ja nicht
bestritten.

>> Ich habe auch schon oft den Spruch gehört "Was läuft, ist gut". Aber
>> da habe ich meine Zweifel. Wie gesagt, der Umfang der Prüfungen, die
>> bereits zur Compile-Zeit stattfinden können, wäre für mich ein ganz
>> entscheidendes Kriterium.
>
> Das ist IMHO eines der schwächsten Argumente bzgl. der Entscheidung
> für oder gegen eine groß angelegte Migration in eine neue Sprache.

> Entweder überschätzt Du die Leistungen eines Compilers und seiner
> Prüfungen oder Du unterschätzt die sonstigen Problemfelder massiv.

Da bin ich schlicht anderer Meinung, aber das liegt sicher auch daran,
dass Du aus der Ausgangsfrage schlussfolgerst, dass eine aufwändige
Migration ausschließlich mit den Schwächen der im Bestandssystem
verwendeten Programmiersprache begründet wird. Aber dies ist ja nicht
der Fall.

Die Gesamtsituation sollte zur Besorgnis veranlassen:

- ein gewachsenes Gesamtsystem, bestehend aus einem Mix:
Cobol, C, Skripten und VB
- vermutlich wenig strukturierter Spagetti-Code
- ein schlecht dokumentiertes Datenmodell
- Transaktoinen in Millionenhöhe!
- nicht geeignet für hochverfügbaren Betrieb

Und alles in der Hand eines einzigen Programmierers, der bald in den
Ruhestand geht.

In dieser Situation besteht IMHO dringender Handlungsbedarf und die
verwendeten Programmiersprachen sollten dabei dringend auf den
Prüfstand, auch wenn von ihnen nicht alles abhängt.

Magnus

--
This is Unix-Land. In quiet nights, you can hear the Windows machines
reboot.

[Stefan Nobis]

Magnus Warker <war...@mailinator.com> writes:

> Damit hast Du Recht, aber bei der Ausgangsfrage ging es
> ausschließlich um die Programmiersprache. Dass diese nur einen
> kleinen Ausschnitt in einem komplexen Gebilde von Einflussfaktoren
> darstellt, wurde ja nicht bestritten.

Und ich bleibe dabei: Nur die Programmiersprache allein ist eigentlich
niemals ein Grund, ein System neu (in einer anderen Sprache) zu
schreiben.

> Die Gesamtsituation sollte zur Besorgnis veranlassen:

> - ein gewachsenes Gesamtsystem, bestehend aus einem Mix:
> Cobol, C, Skripten und VB
> - vermutlich wenig strukturierter Spagetti-Code
> - ein schlecht dokumentiertes Datenmodell
> - Transaktoinen in Millionenhöhe!
> - nicht geeignet für hochverfügbaren Betrieb

> Und alles in der Hand eines einzigen Programmierers, der bald in den
> Ruhestand geht.

Das hingegen sind sehr wohl Gründe, die u.U. eine komplette
Neuentwicklung rechtfertigen können. Und dann kann und sollte man
natürlich auch über die verwendeten Werkzeuge und insbesondere die
Programmiersprache neu nachdenken (aber die Sprache kann und sollte
IMHO so gut wie nie allein der Auslöser für eine Neuentwicklung
sein).

Deshalb schrieb ich ja auch bereits:

,----[ Message-ID <m14nokf...@nobis-it.eu> ]

| In so einem Fall kann man eine Neuentwicklung durchaus mit in
| Zukunft sinkenden Wartungskosten begründen - sofern man mit einem
| guten Konzept und deutlichen strukturellen Verbesserungen aufwarten
| kann.

`----

--
Stefan.

[Thomas Koenig]

On 2012-09-12, Magnus Warker <war...@mailinator.com> wrote:

> - ein gewachsenes Gesamtsystem, bestehend aus einem Mix:
> Cobol, C, Skripten und VB
> - vermutlich wenig strukturierter Spagetti-Code
> - ein schlecht dokumentiertes Datenmodell
> - Transaktoinen in Millionenhöhe!
> - nicht geeignet für hochverfügbaren Betrieb
>
> Und alles in der Hand eines einzigen Programmierers, der bald in den
> Ruhestand geht.

Das Problem ist in

http://dilbert.com/strips/comic/1994-06-10/

dokumentiert, allerdings ohne Lösungsansatz :-)

[Marc Santhoff]

Am Wed, 12 Sep 2012 15:21:06 +0200 schrieb Magnus Warker:

> Die Gesamtsituation sollte zur Besorgnis veranlassen:
>
> - ein gewachsenes Gesamtsystem, bestehend aus einem Mix:
> Cobol, C, Skripten und VB
> - vermutlich wenig strukturierter Spagetti-Code
> - ein schlecht dokumentiertes Datenmodell
> - Transaktoinen in Millionenhöhe!
> - nicht geeignet für hochverfügbaren Betrieb
>
> Und alles in der Hand eines einzigen Programmierers, der bald in den
> Ruhestand geht.
>
> In dieser Situation besteht IMHO dringender Handlungsbedarf und die
> verwendeten Programmiersprachen sollten dabei dringend auf den
> Prüfstand,
> auch wenn von ihnen nicht alles abhängt.

Und da fragst Du nach der Programmiersprache?

Wenn das restliche System in Java/J2EE realisiert ist, ist COBOL eine
(exotische) Sprache zuviel. Bei den anderen ist fraglich, ob die wirklich
systemrelevant sind oder nur hypsche Darstellung machen und ein
zusätzliches Client-Programm ersetzen oder so.

Und zu Wartung und Pflege von COBOL: mittlerweile begegnet mir diese
Sprache öfter in Form von Leuten, die sie lernen, um Altsysteme warten zu
können.

Mein Ansatz in der Situaton wäre als erstes und dringenstes den COBOLd zu
extensiver Dokumentationsarbeit zu verdonnern und ihm einen
Vertragszusatz unterzuschieben oder aus seinem Arbeitsvertrag
aubzuleiten, daß er bleiben muß oder zur Verfügung steht, bis alle
nötigen Bestandteile nachvollziehbar schriftlich für die Nach- bzw.
Jetztwelt niedergelegt sind.

Außerdem müßte man dringend mal den bestehenden Code sichten, ob er
wirklich so schrecklich ist. Man kann mit jeder Sprache solches und
solches formulieren.

Meine 2 Cent,
Marc

[Burkart Venzke]

Am 16.09.2012 00:57, schrieb Marc Santhoff:
> Und zu Wartung und Pflege von COBOL: mittlerweile begegnet mir diese
> Sprache öfter in Form von Leuten, die sie lernen, um Altsysteme warten zu
> können.

Ach, ist es schon soweit? Ich durfte mich mit COBOL (bis) letztes Jahr
auch noch beschäftigen, hatte aber meine Vorerfahrungen.

> Mein Ansatz in der Situaton wäre als erstes und dringenstes den COBOLd zu
> extensiver Dokumentationsarbeit zu verdonnern und ihm einen
> Vertragszusatz unterzuschieben oder aus seinem Arbeitsvertrag
> aubzuleiten, daß er bleiben muß oder zur Verfügung steht, bis alle
> nötigen Bestandteile nachvollziehbar schriftlich für die Nach- bzw.
> Jetztwelt niedergelegt sind.

Das klingt in der Theorie gut, habe ich in der Praxis aber noch nie
gehört. Alleine der Zeitaufwand von (den meist grö0eren) System wäre
immens. Und ob derjenige da wirklich Lust zu hat und nicht vorher
abwandert...

> Außerdem müßte man dringend mal den bestehenden Code sichten, ob er
> wirklich so schrecklich ist. Man kann mit jeder Sprache solches und
> solches formulieren.

Erfahrungsgemäß ist er meistens wirklich nicht schön, da über
Jahr(zeht)e gewachsen zum sprichwörtlichen Spaghetticode, mit oft
verschiedenen Autoren u.ä.

Gruß
Burkart

[Marc Santhoff]

Am Sun, 16 Sep 2012 10:06:18 +0200 schrieb Burkart Venzke:

> Am 16.09.2012 00:57, schrieb Marc Santhoff:
>> Und zu Wartung und Pflege von COBOL: mittlerweile begegnet mir diese
>> Sprache öfter in Form von Leuten, die sie lernen, um Altsysteme warten
>> zu können.
>
> Ach, ist es schon soweit? Ich durfte mich mit COBOL (bis) letztes Jahr
> auch noch beschäftigen, hatte aber meine Vorerfahrungen.

Ich habe den Eindruck es gibt viel mehr COBOL-Systeme die stillschweigend
unf zuverlässig - also schon irgendwie auch problemfrei - ihre Aufgabe
verrichten.

Guck mal in Stellenanzeigen und Portale für IT-Spezis, vielleicht war das
auch Zufall, ich war aber tatsächlich mehrfach über das Thema gestolpert.

>> Mein Ansatz in der Situaton wäre als erstes und dringenstes den COBOLd
>> zu extensiver Dokumentationsarbeit zu verdonnern und ihm einen
>> Vertragszusatz unterzuschieben oder aus seinem Arbeitsvertrag
>> aubzuleiten, daß er bleiben muß oder zur Verfügung steht, bis alle
>> nötigen Bestandteile nachvollziehbar schriftlich für die Nach- bzw.
>> Jetztwelt niedergelegt sind.
>
> Das klingt in der Theorie gut, habe ich in der Praxis aber noch nie
> gehört. Alleine der Zeitaufwand von (den meist grö0eren) System wäre
> immens. Und ob derjenige da wirklich Lust zu hat und nicht vorher
> abwandert...

Kommt natürlich auf den Umfang der Sache und die vorhandene Doumentation,
also auch Spezifikationen, an. Zumindest die Lücken sollte man füllen.

Außerdem geht es um Ruhestand, da kann es gut sein, daß damit aus vielen
Gründen dieser Mann nicht mehr absprechbar ist.

>> Außerdem müßte man dringend mal den bestehenden Code sichten, ob er
>> wirklich so schrecklich ist. Man kann mit jeder Sprache solches und
>> solches formulieren.
>
> Erfahrungsgemäß ist er meistens wirklich nicht schön, da über
> Jahr(zeht)e gewachsen zum sprichwörtlichen Spaghetticode, mit oft
> verschiedenen Autoren u.ä.

Den Aufwand für die Einarbeitung sollte man also nicht unterschätzen.

Bei den jetzt bekannten Fakten würde ich sofort anfangen, die
Spezifikation zu vervollständigen, am besten so weit wie es für
Neuimplementation nötig ist.

Und ggf. dafür sorgen, daß die Daten vom Altsystem bei Bedarf parallel in
ein neues zum Test gefüttert werden können, mit gleichem Timing, etc.
Usw.

Der OP könnte eine Risikoabschätzung als Beschleuniger benutzen ...

Marc