COBOL-IT als Alternative gegenüber anderen Compilern

In Compiler-Fragen brauchen Unternehmen sich nicht knebeln zu lassen

Neben der technischen Eignung haben oft genug die Kosten und das Lizenzmodell entscheidenden Einfluss, mit welchem Hersteller man in Zukunft vertrauensvoll zusammenarbeiten möchte.

Lösen Sie sich aus den technischen, finanziellen nd strategischen Korsetten mancher Hersteller und stellen Sie Ihre Anwendungen und Entwicklung auf gesunde Füße (und die Entwickler gleichzeitig ebenfalls).

Wir bei COBOL-works sind überzeugt davon, dass es nur dann dauerhaft Sinn macht, damit weiter zu machen, wenn Ihre COBOL-Anwendungen und Compiler deutlich wertvoller sind als ihr Preis. Hinzu kommt die Bedingung, dass Sie auch nur dann, wenn Sie unabhängig von Ihrem Lieferanten sind, dauerhaft diese Lösungen strategisch betreiben sollten.

Preise zu vergleichen ist mehr als legitim und notwendig. Es geht nicht unbedingt darum, den billigsten Preis zu erhalten, sondern um die Sicherheit, dass Leistung und Preis sich die Waage halten. Wenn Sie viel bezahlen, wollen Sie entsprechende Leistung. Ein überhöhter Preis ärgert nicht nur Sie und Ihr Budget, sondern zerstört das Vertrauensverhältnis zum Lieferanten.

Noch schlimmer ist es, wenn im sogenannten „Kleingedruckten“ Bedingungen stehen, die im wahrsten Sinne des Wortes „unbezahlbar“ sind.

Besondere Preismodelle sind hoch willkommen, wenn es um besondere und vielschichtige Zusammensetzungen von Leistungen geht. Muss man jeden Handgriff extra bezahlen, wird selbst die Kalkulation schon zum Meisterwerk und im Ergebnis die Leistung unerschwinglich.

Bekommt man dagegen einen Paketpreis, spart man häufig nicht nur Geld, sondern auch Zeit. Das bedeutet bereits doppelten Gewinn. Derartige Pakete können z. B. schwankende Benutzeranzahlen und Serverleistungen abfangen, aber auch im Batch-Betrieb und bei (geplanten) Weblösungen zu hoher Flexibilität und Weiterentwicklungen ohne „böses Erwachen“ beitragen.

Anbieterunabhängigkeit schaffen

  1. Im Zuge der Ablösung werden wahrscheinlich auch Maßnahmen des Reengineerings durchzuführen sein. Nutzt man dioese Chance richtig, kann eine große Herstellerunabhängigkeit erreicht werden. Maßnahmen hierzu können sein:
  2. Rückführung compilerspezifischer Erweiterungen auf den COBOL-Standard
  3. Kapselung und Zentralisierung der Nutzung compilerspezifischer Erweiterungen über spezielle, dem COBOL-Standard entsprechende Schnittstellen
  4. Keine Nutzung von compilerspezifischen Erweiterungen des neuen Compilers
  5. Single-Source Quellcode, der für beide Umgebungen - die bestehende ebenso wie die neue - geeignet ist

Allein diese Maßnahmen ergänzt um die Etablierung eines geeigneten Testsystems (z.B. auf Basis von Highway61) schaffen die Flexibilität, auch in Zukunft die Chance zu wahren, den Compiler ohne größere Aufwände zu wechseln. Dies verstehen wir unter echter Herstellerunabhängigkeit.

Wo liegen die häufigsten Probleme, wenn der aktuelle Compiler abgelöst wird

  1. Subroutinen: Die Sammlung an Subroutinen unterscheidet sich zwischen den Compilern. Nicht jede Subroutine hat ein funktionsgleiches Gegenstück.
  2. Datendateien: Grundsätzlich generiert jeder Compiler eigene Dateien, mit der der jeweilige Compiler hantieren kann. Es gibt Unterschiede bei den I/O Subroutinen, mit der bei der Migration gerechnet werden muss.
  3. Utilties/Schnittstellen: Abhängig von den verwendeten Utilities und externen Schnittstellen muss geprüft werden, ob es ein Gegenstück dafür gibt.
  4. Compiler Optionen: Mainframe-nahe Compiler Optionen unterscheiden sich nur geringfügig zwischen den Compilern. Compiler Optionen außerhalb des Standards müssen geprüft werden, um das gleiche Verhalten in anderen Compilern zu erzeugen.
  5. Felddefinitionen: Felder, die zum COBOL Standard gehören, sind in fast allen Compilern gleich. Unterschiede finden sich bei den Arten der COMP-Felder, der jeweiligen internen Strukturen und der Handhandhabung von komprimierten Datenfeldern.
  6. Laufzeitverhalten: Es gibt Unterschiede im Laufzeitverhalten zwischen den Compilern. Als Beispiel hier: Das Verschieben von Inhalten aus einem großen Feld in kleinere Felder oder beim Verschieben von ungültigen Werten in eine numerische Variable.
  7. Screen Sections: Die Bearbeitung von Screen Sections unterscheidet sich in Detailierungen und werden bei einigen Compilern nicht mehr unterstützt

Worauf muss man sich einstellen und wie kann geholfen werden?

  1. Recherche und Vergleich
  2. Sourcecode Anpassungen
  3. Programmierung bei fehlendem Direktersatz
  4. Beschaffen von passenden Utilties/Schnittstellen
  5. Ggf. Entwicklung von neuen Benutzeroberflächen

Angebot von COBOL-works & unseren Partnern:

  1. Definition der Zielsetzung und Anforderungen an einen Ersatzlösung
  2. Sourcecode Analyse
  3. Notwendige Codeanpassungen dokumentieren und bereitstellen: Verschafft Ihnen einen Überblick der Anpassungen und deren Lokation. Mit diesen Informationen können Sie die Anpassungen selbständig durchführen.
  4. Bereitstellung von Bezugsquellen für fehlende Utilities/Schnittstellen
  5. Entwicklung von Alternativen für fehlende Subroutinen
  6. Bereitstellung und Entwicklung von Datenkonvertierungstools
  7. Entwicklung von Benutzeroberflächen: Bsp. HTML (Web), WinForms(.Net)
  8. Wir können mit Hilfe unserer Transformationsplattform die Codeanpassung für Sie übernehmen. Die Anpassung erfolgt auf Basis von Transformationsregeln vollautomatisch, reproduzierbar und sicher.
  9. Wir können Ihre Anwendung testen, das Laufzeitverhalten prüfen und mit der Alt-Anwendung vergleichen. Dies ermöglicht eine schnelle Identifizierung von Abweichungen und deren Ursachen.