Stored Procedures unter V5R4

[PeterKarsten]

Wir arbeiten mit Stored Procedures, die wir über den JT400-JDBC-Treiber aufrufen, Jetzt, auf V5R4 kommen einige StoProcs mit "High-order nibble of the byte at array offset 722 is not valid." zurück. Wir haben das Problem etwas isoliert, der Fehler kommt aus den Result-Sets. Ist aber für mich nicht nachvollziehbar.

Die StoProc ist banal:

CREATE PROCEDURE TESTPGM/STOTEST
(IN HDNR NUMERIC(6, 0),
IN FILIAL NUMERIC(4, 0))
RESULT SETS 1
LANGUAGE RPGLE
SPECIFIC TESTPGM/STOTEST
NOT DETERMINISTIC
CALLED ON NULL INPUT
EXTERNAL NAME 'TESTPGM/EXETEST'
PARAMETER STYLE GENERAL;
COMMENT ON SPECIFIC PROCEDURE TESTPGM/STOTEST
IS 'Testen StoProcs V5R4'

Das Programm auch:

FONT="Fixedsys"]HDEBUG(*INPUT : *DUMP : *XMLSAX) DFTACTGRP(*NO) ACTGRP(*CALLER)
FHDSTAM IF E K DISK
DXHDSTAM E DS occurs(1)
DXHDNR S 6S 0
DXFILIAL S 4S 0
C *ENTRY plist
C parm XHDNR
C parm XFILIAL
C*
C key_hd klist
C kfld XHDNR
C kfld XFILIAL
C key_hd chain HDSTAMF
C if %found
C 1 occur XHDSTAM
C/exec sql
C+ set result sets array :XHDSTAM for 1 rows
C/end-exec
C else
C/exec sql
C+ set result sets none
C/end-exec
C end
C DUMP(A)
C RETURN
C SETON LR [/FONT]

Je nachdem, ob ich jetzt in meiner Datenstruktur (LF) ein Feld mehr oder weniger habe, kommt der Fehler oder nicht. Das nächste Feld geht aber wieder usw.

???????

Gruß

Peter

[PeterKarsten]

Das Programm nochmal lesbar:

HDEBUG(*INPUT : *DUMP : *XMLSAX) DFTACTGRP(*NO) ACTGRP(*CALLER)
FHDSTAM IF E K DISK
DXHDSTAM E DS occurs(1)
DXHDNR S 6S 0
DXFILIAL S 4S 0
C *ENTRY plist
C parm XHDNR
C parm XFILIAL
C*
C key_hd klist
C kfld XHDNR
C kfld XFILIAL
C key_hd chain HDSTAMF
C if %found
C 1 occur XHDSTAM
C/exec sql
C+ set result sets array :XHDSTAM for 1 rows
C/end-exec
C else
C/exec sql
C+ set result sets none
C/end-exec
C end
C DUMP(A)
C RETURN
C SETON LR

[PeterKarsten]

immer noch nicht lesbar ?

[BenderD]

Hallo,

warum eigentlich dieser Wackelhaufen?, das geht doch per simplem SQL ohne stoPro, oder übersehe ich da was???

mfg

Dieter Bender,

[Fuerchau]

Naja, den "Fetch 1 rows only" gibts wohl erst seit V5R2 oder so.
Ein Chain mit verkürztem Key liefert den 1. Satz und das ging mit SQL bisher nicht.
Wenn man dann auch noch kompatibel zu früher bleiben will (V4) bleibt wohl nur die Prozedur.

[PeterKarsten]

Das ist jetzt Philisophie, wir waren bisher jedenfalls sehr zufrieden mit Stored Procedures und JT400. Sehr stabil sehr schnell und der Effekt, Web-Server callt eine Stored-Procedure, diese wickelt die Transaktion ab, prüft, schreibt fort usw. liefert uns pro Tabelle genau einen Einstiegspunkt.

Jetzt aber nochmal zum Problem. Ich lese mit irgendwas eine Datei und gebe den gesamten Satz als Result Set zurück. Bei irgendeinem Feld hängt SQL dann und liefert das High-order nibble (s.o.). Das kann aber nicht an diesem einen Feld hängen, nehme ich ein paar andere raus, läuft dieses eine Feld problemlos. Auch ein Dump auf das Result-Set zeigt nur gültige Daten.

Ist das in V5R4 in den Datenbanken, beim Erstellen von Dateien irgendetwas neu, zu beachten.

[Fuerchau]

Könnte ggf. auf ein CCSID-Problem hindeuten ?

Warum CALLED ON NULL INPUT wenn kein NULL-Anzeiger verwendet wird (PARAMETER STYLE GENERAL ggf. WITH NULLS):

CALLED ON NULL INPUT
Specifies that the procedure is to be invoked, if any, or all, argument values are null, making the procedure responsible for testing for null argument values. The procedure can return a null or nonnull value.

Ggf. ist hier V5R4 restriktiver beim Aufruf mit NULL ?

[PeterKarsten]

Die Lösung lag mal wieder ganz woanders.
Das Programm, das das Result-Set zurückgibt, muß mit CRTSQLRPG ... DATFMT(*ISO) umgewandelt werden, dann läufts.
Danke trotzdem.
Peter

[Fuerchau]

Das kannst du auch in die H-Bestimmung setzen, dann wirds nicht vergessen.

[B.Hauser]

Hallo,


Das kannst du auch in die H-Bestimmung setzen, dann wirds nicht vergessen

Was in den H-Bestimmungen oder D-Bestimmungen (in diesem Fall das Datums-Format) steht interessiert den Precompiler nicht!
Um das Datums-Format für Host-Variablen zu setzen, gibt es 2 Möglichkeiten:

Wie bereits ausgeführt im Compile-Command
Über eine SET-OPTION-Anweisung. Bei Release V5R4 muss allerdings beachtet werden, dass die SET OPTION-Anweisung in der Quelle VOR allen anderen SQL-Anweisungen stehen muss. (Anderenfalls gibt es einen Compile-Fehler mit Fehlerstufe 30! Vor Release V5R4 wurde die Reihefolge nicht geprüft)


Birgitta