@Baldur:

soweit das CL und die 32 Stellen (und die 15 5) angeht habe ich alle Probleme mit Commands vermieden, aber was SQL angeht, da geht seit V5R3 verstärkt der Punk ab, da sind einige Sachen implizit geändert worden, so die Reaktion auf Variablen, die mit unterschiedlichem Scope und gleichem Namen deklariert worden sind und das implizite schließen von Cursorn - neben einigen Bugs, die mit wechselnden PTF Ständen ein- und ausgebaut worden sind und in dieser Situation ist das Getöse über die tollen Verbesserungen absolut ärgerlich. Das knallt nur deshalb relativ selten, weill in den meisten Programmen so wie 1870 programmiert wird mit Rekord Löffel Exzess - ich will garnicht erst anfangen mit Ooops Nerv, das ist einfach nur peinlich, wenn man bei Kunden mit so einem Murks arbeiten muss, wo SQL Statements drin sind, die nicht funktionieren und die man dann per Hand korrigieren muss, damit es funzt... die Oracle Fraktion lacht sich schief, wenn sie sowas sieht und der Verweis auf ein Service Pack, das das behebt - naja.
Ich bleibe dabei: DB2/400 muss sich jede Mühe geben, wenn es als Datenbankserver Konkurrenz Fähigkeit weiter unter Beweis stellen will!!!

mfg

Dieter

Zitat Zitat von Fuerchau
Was soll eigentlich das gekloppe ?
Wenn man einige Grundregeln einhält, kommt man auf solche Fehler gar nicht (ich muss mich da immer wieder wundern, dabei bin ich gar nicht so diszpliniert).

Was das CL-Problem angeht, so ist das nun mal bekannt, dass eben der CMD-CALL die Übergaben von Zeichen-Variablen in der angegebenen Länge bzw. mind. 32 Stellen macht. Wenn man das weiß, passiert eben nix.

Aber wie heißt es da doch so schön:
Wozu gibts eigentlich (unternehmensspezifisch) Programmierrichtlinien die solche Probleme (s.o.) normalerweise ausschliessen ?!