View Full Version : Prozedurparameter bei Aufruf in CLLE
Hallo zusammen,
wie definiere ich in CLLE die Parameter, die ich in CALLPRC an eine Prozedur übergebe, deren Parameter bzw. deren Funktionswert gezont nummerisch definiert sind?
Bisher funktionierte dies mit CHAR-Variablen, aber seit 7.1 geht das nicht mehr.
Gruß
Holger
Da würde ich dann mal einen Fehler an IBM melden oder eben auf gepackt umstellen.
ich frage mich, ob wir die einzigen sind, die
- gezonte Felder in Prozeduren verwenden
- Prozeduren im CLLE aufrufen
- Release 7.1 verwenden
?? :)
Oder welche Kombination davon.
Die Problematik kann doch weder neu noch unbemerkt sein.
Gruß
Holger
Das Thema wird meist umgedreht behandelt, Aufruf eines CLLe's (z.B. für CMD's) und Return und nicht umgekehrt.
V7R1 ist halt bzgl. der sog. "Aufruf-Konventionen" restriktiver als V6.
Per Definition ist halt ein CHAR nicht ZONED.
Schreibe einfach eine kleiner Wrapper-Funktion, die CHAR akzeptiert und ZONED weitergibt.
Es ist leider so, dass man sich auf alte Fehler eines OS nicht verlassen darf. Wenn diese dann halt zu gemacht (also berichtigt) werden, muss man halt seine Programme korrigieren.
Eventuell ist das das gleiche Problem?
IBM MA42633 - OSP-OTHER-INCORROUT INCORRECT VALUES RETURNED BY CALLPRC IN CL WHEN RETURNING A PACKED OR ZONED VALUE LESS THAN 16 BYTES. (http://www-01.ibm.com/support/docview.wss?uid=nas2279ca4fe53f1834d86257b0c00423b 3b)
So ist das halt mit den "Optimierungen".
Eine Wrapper-Funktion wird ja als Lösung auch dort vorgeschlagen um Typanpassungen vorzunehmen.
Anton Gombkötö
10-06-13, 08:29
Anscheinend seid Ihr wirklich die Einzigen, die das (noch) so machen.
Denn wenn das jemand vernünftig getestet hätte, wäre ihm aufgefallen, dass nicht nur die Umsetzung eines Rückkehrwertes falsch ist, es ist auch schon die Übergabe eines Wertes mit Nachkommastellen falsch. (da sieht man dann im Debugger z.B. "0001.,2")
Darum die dringende Empfehlung, diesen Pfad umgehend zu verlassen und auf Datentypen umzustellen, die beide Programmiersprachen verstehen. Denn erwiesenermaßen schaffen es Fehler(*) bis in Produktions-Releases und jahrelang fällt es niemand vor Euch auf.
(*) im Sinne des Investitionsschutzes ist das ein Fehler.