AS400 (RPG) oder PC-Netz

[loeweadolf]

... naja, es gibt schon Firmen, die über Jahrzehnte nichts in EDV investiert haben, jetzt auf einem EDV Museum sitzen, durch Zukauf von anderen Firmen eine heterogene Landschaft haben - und jetzt erschrecken, wenn sie sehen was der Anschluss an die Moderne kostet und dann bei den großen Einzelposten anfangen zu streichen.

D*B

... oder aber die in der Hauptsache RPG-Anwendungen haben und sich sorgen, ob es in einigen Jahren überhaupt noch genügend RPG-Leute gibt. Und per PC-Netz geht sowieso alles einfacher und direkt: EXCEL etc. etc.

[BenderD]

... das dahinter stehende maintenance Argument ist ja nicht falsch; allerdings schneidet da der PC Bereich eher schlechter ab, fast die komplette Software wird ohne Code geliefert, langfristige Support Perspektiven sind eher die Ausnahme und die individuell von interessierten Laien in der Fachabteilung erstellten Excels (und ähnliches) sind undokumentiert und selbst von den Erstellern oft nicht wartbar (wenn sie denn überhaupt korrekt sind).

D*B

... oder aber die in der Hauptsache RPG-Anwendungen haben und sich sorgen, ob es in einigen Jahren überhaupt noch genügend RPG-Leute gibt. Und per PC-Netz geht sowieso alles einfacher und direkt: EXCEL etc. etc.

[HerbertW]

Dabei besteht überhaupt kein Interesse die AS/400 abzulösen sondern eher im Gegenteil gerade die Stärke der DB2/400 auszunutzen.
Im Vergleich zum M$-SQL-Server ist die AS/400 gerade bei vielen Tabellen mit 100.000en Sätzen in der Abfrage einfach unschlagbar (gemessen!).

Wir haben eine neue Anwendung (LOGA von P&I) mit Datenbank auf AS/400. (Modell 525)
Mehr als 1000 Tabellen. ODBC-Zugriff.

Von einer besonderen Stärke der AS400 ist nichts zu bemerken. Im Gegenteil: lahm wie eine Schnecke, katastrophale Antwortzeiten.

Nach Aussage des SW-Herstellers ist DB2/400 aus Performance-Gründen weniger geeignet und daran könne man leider nichts ändern.

Der Index-Advisor zeigt 1000de Vorschläge für neue (zusätzlich zu den 2000 vorhandenen) Indices. Habe die wichtigsten schon erstellt, aber da ist kein Ende in Sicht. Wenn ich schon sehe, dass alle alphanumerischen Felder mit variabler Länge definiert sind und wenn sie nur 3 Stellen lang sind, dann frage ich mich, ob das sein muss oder der Hersteller etwas falsch macht.

Wenn da keine Lösung auftaucht, sind wir gezwungen auf SQL-Server umstellen.

PS: Die nativen RPG-Anwendungen laufen einwandfrei performant.

[BenderD]

... da müsste man mal die Ursachen sauber rausanalysieren, woran das liegt. Varchar ist außerhalb der AS/400 Welt weit verbreitet und im DB2/400 nicht gerade der Bringer, aber lahm sollte das nicht sein, wenn alles (inklusive Hardware Dimensionierung) passt. Ich habe da eine Installation im Auge, wo ein DWH Frontend per ODBC auf massive Datenmengen zugreift - und das brummt ordentlich.

D*B

Wir haben eine neue Anwendung (LOGA von P&I) mit Datenbank auf AS/400. (Modell 525)
Mehr als 1000 Tabellen. ODBC-Zugriff.

Von einer besonderen Stärke der AS400 ist nichts zu bemerken. Im Gegenteil: lahm wie eine Schnecke, katastrophale Antwortzeiten.

Nach Aussage des SW-Herstellers ist DB2/400 aus Performance-Gründen weniger geeignet und daran könne man leider nichts ändern.

Der Index-Advisor zeigt 1000de Vorschläge für neue (zusätzlich zu den 2000 vorhandenen) Indices. Habe die wichtigsten schon erstellt, aber da ist kein Ende in Sicht. Wenn ich schon sehe, dass alle alphanumerischen Felder mit variabler Länge definiert sind und wenn sie nur 3 Stellen lang sind, dann frage ich mich, ob das sein muss oder der Hersteller etwas falsch macht.

Wenn da keine Lösung auftaucht, sind wir gezwungen auf SQL-Server umstellen.

PS: Die nativen RPG-Anwendungen laufen einwandfrei performant.

[holgerscherer]

Wenn da keine Lösung auftaucht, sind wir gezwungen auf SQL-Server umstellen.

Wie Dieter schon schrieb, VARCHAR ist nicht ganz das Problem, aber es kann helfen, wenn viele kleine Felder hier für Indizierung verwendet werden -> fixe Größe.
Schlimmer ist, dass der Optimizer viel zu tun vermeldet. Man merkt halt, dass da auf MS-SQL-Server entwickelt wurde; der legt alles von selbst an, und dem Software-Entwickler ist es wurscht. Die AS/400 ist da eher gemütlich, aber sie wird auch nicht gnadenlos langsam bei vielen Benutzern.

Habe auch einen Kunden mit ähnlichem Fall, da werden (von einem Softwaregenerator erstellte SQL-Befehle) tausende von Delete-Befehlen auf einzelne Key-Paare abgeschickt. Das könnte man optimieren...

Ob der Software-Hersteller hier Fehler gemacht hat? Schwer zu sagen, ohne das genau zu kennen. Aber alle Hausaufgaben hat er wohl nicht gemacht. Heutzutage wird ja lieber "generell" gearbeitet und dann geschaut, was das Blechle draus macht.

Und ab einer gewissen Anzahl Indices sollte man darüber nachdenken, wer hier das Denken aufgegeben hat ;-)

Ach ja, "gezwungen", auf SQL-Server umzustellen? Habt Ihr da mal einen direkten Vergleich gemacht? Gleiche Datenmenge und gleiche Anzahl User? Und geschaut, was der MS-SQL-Server an Indizes produziert und "versteckte" Optimierungen baut?

-h

[HerbertW]

Hallo Dieter + Holger,

auf SQL-Server getestet haben wir noch nicht.
Wir dachten, dass die AS400 die 4 bis 5 Anwender der Personalabteilung schon noch verkraften kann, wo sie doch mit den ca. 500 nativen Anwendern nur selten ausgelastet ist. Sparen wir uns die Lizenz für die MS-DB und den Server.

Es ist aber ein Problem, wenn AS400-Anwender, die im Green-Screen blitzschnelle Antwortzeiten gewohnt sind, mit einer GUI konfrontiert werden, die sich vieeel Zeit lässt.

Wie gesagt, die Anwendung ist neu, es sind zwar Daten von der Altanwendung übernommen worden, aber der Datenbestand beginnt ja erst zu wachsen.
Die Antwortzeiten werden sich in Zukunft also kaum verbessern.

Für jeden Tip, der zur Verbesserung führt, bin ich dankbar. Aber an der DB kann ich wohl kaum drehen, z.B. VARCHAR in fix umstellen.

Gruß
Herbert

[Fuerchau]

Varchar ist hier absolut zu vernachlässigen, insbesonders da neuere Anwendungen grundsätzlich den Unicode-Varchar (nvarchar) verwenden.

Das Hauptproblem der meisten M$-Programmierer ist, das SQL's in den Programmen zusammengestrickt werden an Stelle vernünftige Command-Objekte mit Parametern zu verwenden.
Die gestrickten SQL's lassen sich in 99,9% in statische SQL's umbauen.

Aber hier ist teilweise die Historie Schuld, da ADO.NET mit 2.0 erst gute Designer zur Verfügung stellt, die diese Objekte generieren.

Ich war ja gerade erst bei einem Kunden, der genau diese Probleme auch hatte.
Ein paar wenige Änderungen von ständig gestrickten SQL's zu parametrierten Abfragen änderte die Antwortzeit von ca. 2 Sekunden auf quasi sofort!
Mehrere zusammengebaute Inserts mit einem InsertCommand ersetzt kann bis zu 1000 Inserts pro Sekunde an statt 10 schaffen!

Ausserdem geht beim zusammenbauen von SQL's auch nicht unwesentlich Zeit bereits auf dem Client verloren, da hier sehr extensives Stringhandling (Speicherverwaltung) betrieben wird.

Beispiel verdoppeln Hochkomma, ersetzen Dezimalkomma:

myStr = "select blabla from ... where key='" + string.replace(KeyChar, "'","''") + "' and KeyNum = " + string.replace(format(NumValue, "#.##"), ",", ".") ....
Anschließend muss ein Commandobjekt erstellt, ausgeführt und wieder verworfen werden, auch das dauert.

Und noch schlimmer wirds beim Zusammenbau von Update/Inserts.

Es kommt hier insbesoners auf die Methodik an. Aber die meisten kümmern sich ja eher um die schöne Gui als das, was dahinter steckt.
Auch einen SQL-Server kann ich da locker in die Knie zwingen.

[Fuerchau]

Hallo Dieter + Holger,

auf SQL-Server getestet haben wir noch nicht.
Wir dachten, dass die AS400 die 4 bis 5 Anwender der Personalabteilung schon noch verkraften kann, wo sie doch mit den ca. 500 nativen Anwendern nur selten ausgelastet ist. Sparen wir uns die Lizenz für die MS-DB und den Server.

Es ist aber ein Problem, wenn AS400-Anwender, die im Green-Screen blitzschnelle Antwortzeiten gewohnt sind, mit einer GUI konfrontiert werden, die sich vieeel Zeit lässt.

Wie gesagt, die Anwendung ist neu, es sind zwar Daten von der Altanwendung übernommen worden, aber der Datenbestand beginnt ja erst zu wachsen.
Die Antwortzeiten werden sich in Zukunft also kaum verbessern.

Für jeden Tip, der zur Verbesserung führt, bin ich dankbar. Aber an der DB kann ich wohl kaum drehen, z.B. VARCHAR in fix umstellen.

Gruß
Herbert

Hallo Herbert,

für Geld kann ich dir da sicherlich weiterhelfen

[BenderD]

... mit dem Database Monitor sähe man da relativ schnell klarer, ob es da an Zugriffspfaden mangelt, oder ob die Software eher Saftware ist... Allerdings ist der Loga Kram ja für DB2/400 freigegeben, ich würde da dem Hersteller mal fragen, ob man nicht für ihn Reklame machen sollte...

D*B

Hallo Dieter + Holger,

auf SQL-Server getestet haben wir noch nicht.
Wir dachten, dass die AS400 die 4 bis 5 Anwender der Personalabteilung schon noch verkraften kann, wo sie doch mit den ca. 500 nativen Anwendern nur selten ausgelastet ist. Sparen wir uns die Lizenz für die MS-DB und den Server.

Es ist aber ein Problem, wenn AS400-Anwender, die im Green-Screen blitzschnelle Antwortzeiten gewohnt sind, mit einer GUI konfrontiert werden, die sich vieeel Zeit lässt.

Wie gesagt, die Anwendung ist neu, es sind zwar Daten von der Altanwendung übernommen worden, aber der Datenbestand beginnt ja erst zu wachsen.
Die Antwortzeiten werden sich in Zukunft also kaum verbessern.

Für jeden Tip, der zur Verbesserung führt, bin ich dankbar. Aber an der DB kann ich wohl kaum drehen, z.B. VARCHAR in fix umstellen.

Gruß
Herbert

[andreaspr@aon.at]

Hallo Herbert,
ich glaube wir alle haben schon mal solche Probleme gehabt. Unabhängig ob jetzt DB2, Oracle, MSSQL oder sonst ein System. Für mich klingt das einfach nach einem schlecht konfigurierten System und einer schlecht umgesetzten Applikation.
Wenn der Index Advisor so viele Indizes vorschlägt, dann kann irgendwas nicht richtig gemacht worden sein.
Die Frage ist jedoch auch, wie alt die Vorschläge sind und wie oft sie benötigt werden?
Auslastung und Job-Prioritäten des Systems spielen da eine nicht unwesentliche Rolle!
Wenn der SW-Hersteller meint, die DB2 sei ungeeignet, bedeutet das für mich nichts anderes, als dass sie sich mit der DB2 eben nicht so gut auskennen.
Schließlich gibt es genug Applikationen in .Net und sonst was geschrieben, die keine Performanceprobleme haben und auch mit riesen Datenmengen arbeiten (wie Bender auch schon geschrieben hat).

Lange Rede kurzer Sinn: Ich glaube nicht, dass es mit "einfach nur auf MSSQL umstellen" getan ist.

[HerbertW]

Heutzutage wird ja lieber "generell" gearbeitet und dann geschaut, was das Blechle draus macht.

Ich glaube, das trifft es am besten.

Kann man es so sagen: ?
Es gibt Systeme, die akzeptieren "generelle" Entwicklung klaglos und dann gibt es andere Systeme (AS/400), die das nicht tun. Bei diesem anderen System muss halt etwas mehr Gehirnschmalz investiert, d.h. mehr Entwicklungsaufwand getrieben werden, wenn es anständig laufen soll. Es kann vernünftig laufen, keine Frage, aber eben nur mit höherem Aufwand. Da aber die Entwicklungszeit DER Kostenfaktor eines SW-Hauses ist, kann ich mir vorstellen, dass beim Wettlauf der Systeme die AS400 immer mehr ins Hintertreffen gerät, wenn es sich nicht gerade um einen SW-Hersteller handelt, der sich traditionell diesem System verpflichtet fühlt.

Hier noch einige Daten zu der Anwendung:
1265 Tabellen
883 Indizes vorgesehen
2474 Indizes vom Advisor vorgeschlagen (vor 1 Woche zurückgesetzt)
2056 Triggerprogramme

Jedes Datumsfeld als langen Zeitstempel defniert. Scheint auch so eine "generelle" Entwicklung zu sein. Wäre mir im Traum nicht eingefallen.
Was soll die Millisekunde beim Eintrittsdatum?
Jedes alphanum. Feld, auch unzählige 1-stellige Kennzeichen, mit VARCHAR definiert hatte ich schon erwähnt. Diese Felder wie Mandant oder Lohnart sind Teil von jedem Index. Bei einem langen Textfeld leuchtet mir ja noch ein, dass man damit Platz sparen kann. Aber hier wird kein Platz gespart, im Gegenteil.

[BenderD]

Die Anzahl der Indexe ist schon verdächtig niedrig, selbst bei konsequenter Nutzung von primary keys und referential constraints ist das wenig und jeder fehlende Zugriffspfad wird mit Laufzeit abgestraft (Genau das erkennt man mit dem Database Monitor).

Was die Timestamps angeht, das ist auf der AS/400 sicher kein Problem, Varchar eher auch nur nachrangig.

D*B

Hier noch einige Daten zu der Anwendung:
1265 Tabellen
883 Indizes vorgesehen
2474 Indizes vom Advisor vorgeschlagen (vor 1 Woche zurückgesetzt)
2056 Triggerprogramme

Jedes Datumsfeld als langen Zeitstempel defniert. Scheint auch so eine "generelle" Entwicklung zu sein. Wäre mir im Traum nicht eingefallen.
Was soll die Millisekunde beim Eintrittsdatum?
Jedes alphanum. Feld, auch unzählige 1-stellige Kennzeichen, mit VARCHAR definiert hatte ich schon erwähnt. Diese Felder wie Mandant oder Lohnart sind Teil von jedem Index. Bei einem langen Textfeld leuchtet mir ja noch ein, dass man damit Platz sparen kann. Aber hier wird kein Platz gespart, im Gegenteil.