Oppolzer - Informatik / Blog

In der Folge dieses Problems mit DSNALI gab es ein Gespräch mit einem DB2-Experten
bei der IBM, der unsere Analyse des Problems bei DSNALI (hoher CPU-Aufwand durch
sequentielles Durchsuchen der CDE-Liste) bestätigt hat. Wir wurden in diesem
Zusammenhang von IBM ermahnt, dass es uns nicht erlaubt sei, den Objektcode der
von IBM als OCO (object code only) ausgelieferten Software zu analysieren.
Das war wohl mehr rhetorisch zu verstehen; wir mussten ja rausfinden, was da
genau passiert.

Auf unser Angebot, das DSNALI selbst lokal zu patchen und die entsprechende
Änderung der IBM zur Verfügung zu stellen, ging die IBM nicht ein ... aber immerhin
wurde das innerhalb des IBM-Labors wenigstens diskutiert.

Eine Korrektur des DSNALI durch die IBM gab es auch nicht. Uns wurde statt dessen
empfohlen, auf das RRSAF-Interface (DSNRLI) umzustellen.

Für mich hatte das den angenehmen Nebeneffekt, dass ich mit dieser Umstellung
beauftragt wurde. Es hat mich allerdings den ganzen Sommer 2010 über beschäftigt
und einiges an Nerven gekostet, weil eben doch längst nicht alle Prozesse den
vorgegebenen Standard-Weg nutzten, sondern es gab noch eine ganze Reihe von
Spezialumgebungen, die einzeln inspiziert und umgestellt werden mussten.

Nach der Umstellung auf DSNRLI war das Problem weg.