DRDA mit Remote SQL Befehl funktioniert nicht mehr

[TARASIK]

Hallo Herr Schulz,
ich denke das ist dieses Problem:
IBM - SE38374 - OSP-DB-OTHER-F/#CFDATE-T/QRWTBAS-RC5-MSGMCH1867 DRDA ATTEMPTS TO CONVERT A DATE FIELD THAT DOESN'T NEED TO BE CONVERTED.

[cs400_de]

Hallo,

vielen Dank für den Tipp.
Das PTF, welches hier beschrieben wird, ist schon auf der Maschine2.

Ich werde morgen das neueste Cum auf die V5R2 Maschine spielen und noch ein paar DRDA PTFs.

Danach melde ich mich nochmal.

Grüße

[cs400_de]

Hallo,

ich habe nun auf der Maschine 1 die höchst mögliche Gruppen und Cum PTFs installiert.
Zusätzlich noch
SI26318|SE27758||2007-01-23|38UTIL SELECT * FROM
SI25882|SE27450||2006-12-12|OSP-DB-MSGCPF9190 KERBEROS
SI25841|SE27326||2006-12-22|OSP-DB-MSGMCH3402 MSGCPI8360
SI22701|SE24442||2006-02-24|OSP-DB ENCRYPTION OBJECT NOT
SI27365|SE28672||2007-08-11|OSP-DB-OTHER-F/STRINGHIGHUSE
SI26916|SE28217||2007-04-24|OSP-DB-MSGCPF325E PENDING

Jetzt habe ich mal ein anderes Programm verwendet. Hier ein auszug aus der Umwandlungsliste:

__________________________________________________ ____Spool-Datei_anzeigen____________________________________ __
Datei_._._._._._:___$SRP234_______________________ __________________________________________________ _____Seite/Ze
Steuerung_._._._.___-10________________________________________________ __________________________________Spalten_
Suchen__._._._._.___308___________________________ __________________________________________________ _____________
*...+....1....+....2....+....3....+....4....+....5 ....+....6....+....7....+....8....+....9....+....0 ....+....1...
___297_C___________________CALL______'QSQLOPEN'___ ________________________________SQL_______________ ____01_______
___298_C___________________PARM___________________ _SQLCA__________________________SQL_______________ ____01_______
___299_C___________________PARM___________________ _SQL_00000______________________SQL_______________ ____01_______
___300_C___________________END____________________ ________________________________SQL_______________ ___E01_______
___301_C___________________DOW_______SQLCOD_=_*ZER O_________________________________________________ ___B01_______
___302_C***_______________________________________ __________________________________________________ _____________
___303_C*EXEC_SQL_________________________________ __________________________________________________ _____________
___304_C*_FETCH_NEXT_FROM_REC_DYN_INTO_:ITNR1I,_:T EXT1G,_:BSUN1I,___________________________________ _____________
___305_C*_:WEGH1I,_:WGTU1I________________________ __________________________________________________ _____________
___306_C*END-EXEC______________________________________________ __________________________________________________
___307_C___________________Z-ADD_____-4____________SQLER6_________________________SQL___ 6_______________01_______
___308_C___________________CALL______'QSQROUTE'___ ________________________________SQL_______________ ____01_______
___309_C___________________PARM___________________ _SQLCA__________________________SQL_______________ ____01_______
___310_C___________________PARM___________________ _SQL_00006______________________SQL_______________ ____01_______
___311_C_____SQL_00009_____IFEQ______'1'__________ ________________________________SQL_______________ ___B02_______
___312_C___________________EVAL______ITNR1I_=_SQL_ 00011___________________________SQL_______________ ____02_______
___313_C___________________EVAL______TEXT1G_=_SQL_ 00012___________________________SQL_______________ ____02_______
___314_C___________________EVAL______BSUN1I_=_SQL_ 00013___________________________SQL_______________ ____02_______
___315_C___________________EVAL______WEGH1I_=_SQL_ 00014___________________________SQL_______________ ____02_______


Wenn ich das Programm debugge kann man feststellen, das er ca. 50 Sätze remote holt und dann auf dem Statement 308 stehen bleibt. Dieses Call QSQROUTE wird bei der Umwandlung reincompiliert und stammt von der IBM.

Im WRKACTJOB steht dieser Job dann auf Status: TIMW und das für immer und ewig.

Hoffentlich gibt es hierfür eine Lösung.

Gruß C.Schulz

[cs400_de]

.
.
.
.
.
.


Wer macht noch embedded Remote SQL V5R2 nach V6R1 ??

Sind wir die einzigen?
.
.
.
.
.

[Fuerchau]

Wenn du schon alle PTF's hast musst du wohl einen Call bei der IBM aufmachen, sonst kommst du wohl nicht weiter.

[cs400_de]

.

Einen Call bei IBM hatte ich schon gemacht.
Leider supported IBM V5R2 nicht mehr.
Deswegen kann ich hier weder auf Support noch auf ein PTF hoffen.

Empfehlung: Bringen Sie die Anwendung auf einem supportbaren Release zum Laufen.

Wir müssen dann wohl einen Workaround schaffen.

Gruß

Carsten

[Fuerchau]

So wie es aussieht, liegt der Fehler doch wohl im V6R1 und nicht im V5R2.

Setzte die SQL's mal über eine ODBC-Verbindung (MS-Excel, Opsnav) auf V6R1 ab.

[BenderD]

- was sagt denn das Joblog auf dem Database Server (am besten Job mit STRSRVJOB und STRDBG in Debug Mode versetzen, dann ist die Protokollierung etwas geschwätziger.
- warum macht ihr das als dynamic SQL und was passiert gegebenen Falls bei demselben Zugriff im static SQL?

D*B

Hallo,

ich habe nun auf der Maschine 1 die höchst mögliche Gruppen und Cum PTFs installiert.
Zusätzlich noch
SI26318|SE27758||2007-01-23|38UTIL SELECT * FROM
SI25882|SE27450||2006-12-12|OSP-DB-MSGCPF9190 KERBEROS
SI25841|SE27326||2006-12-22|OSP-DB-MSGMCH3402 MSGCPI8360
SI22701|SE24442||2006-02-24|OSP-DB ENCRYPTION OBJECT NOT
SI27365|SE28672||2007-08-11|OSP-DB-OTHER-F/STRINGHIGHUSE
SI26916|SE28217||2007-04-24|OSP-DB-MSGCPF325E PENDING

Jetzt habe ich mal ein anderes Programm verwendet. Hier ein auszug aus der Umwandlungsliste:

__________________________________________________ ____Spool-Datei_anzeigen____________________________________ __
Datei_._._._._._:___$SRP234_______________________ __________________________________________________ _____Seite/Ze
Steuerung_._._._.___-10________________________________________________ __________________________________Spalten_
Suchen__._._._._.___308___________________________ __________________________________________________ _____________
*...+....1....+....2....+....3....+....4....+....5 ....+....6....+....7....+....8....+....9....+....0 ....+....1...
___297_C___________________CALL______'QSQLOPEN'___ ________________________________SQL_______________ ____01_______
___298_C___________________PARM___________________ _SQLCA__________________________SQL_______________ ____01_______
___299_C___________________PARM___________________ _SQL_00000______________________SQL_______________ ____01_______
___300_C___________________END____________________ ________________________________SQL_______________ ___E01_______
___301_C___________________DOW_______SQLCOD_=_*ZER O_________________________________________________ ___B01_______
___302_C***_______________________________________ __________________________________________________ _____________
___303_C*EXEC_SQL_________________________________ __________________________________________________ _____________
___304_C*_FETCH_NEXT_FROM_REC_DYN_INTO_:ITNR1I,_:T EXT1G,_:BSUN1I,___________________________________ _____________
___305_C*_:WEGH1I,_:WGTU1I________________________ __________________________________________________ _____________
___306_C*END-EXEC______________________________________________ __________________________________________________
___307_C___________________Z-ADD_____-4____________SQLER6_________________________SQL___ 6_______________01_______
___308_C___________________CALL______'QSQROUTE'___ ________________________________SQL_______________ ____01_______
___309_C___________________PARM___________________ _SQLCA__________________________SQL_______________ ____01_______
___310_C___________________PARM___________________ _SQL_00006______________________SQL_______________ ____01_______
___311_C_____SQL_00009_____IFEQ______'1'__________ ________________________________SQL_______________ ___B02_______
___312_C___________________EVAL______ITNR1I_=_SQL_ 00011___________________________SQL_______________ ____02_______
___313_C___________________EVAL______TEXT1G_=_SQL_ 00012___________________________SQL_______________ ____02_______
___314_C___________________EVAL______BSUN1I_=_SQL_ 00013___________________________SQL_______________ ____02_______
___315_C___________________EVAL______WEGH1I_=_SQL_ 00014___________________________SQL_______________ ____02_______


Wenn ich das Programm debugge kann man feststellen, das er ca. 50 Sätze remote holt und dann auf dem Statement 308 stehen bleibt. Dieses Call QSQROUTE wird bei der Umwandlung reincompiliert und stammt von der IBM.

Im WRKACTJOB steht dieser Job dann auf Status: TIMW und das für immer und ewig.

Hoffentlich gibt es hierfür eine Lösung.

Gruß C.Schulz

[cs400_de]

Hallo zusammen,

danke für die Tipps: hier die Antworten:

1.) Statik Aufruf geht im Dialog mit STRSQL
2.) Statik Aufruf im RPG nicht getestet
3.) Den QRWTSRVR haben wir schon debugged. Da steht nichts im Protokoll. Absolut nichts. Sehr komisch. Werde das nochmal probieren.
4.) Der statische SQL läuft auch im iNavigator


Melde mich gleich nochmal wegen Punkt 3.

Gruß
C.Schulz

[cs400_de]

Habe den QRWTSRVR erneut debugged.
Es steht nichts nennenswertes im Log.
Außer das eine Verbindung von der V5R2 Maschine aufgemacht wurde.

Vielleicht mache ich auch was falsch?

Hier meine Vorgehensweise:

1. Ein funktionierende Remote SQL Abfrage (embedded laufen lassen).
2. Die Nummer des kurz erscheinenden Jobs notieren.
3. Nochmal ein funktionierendes laufen lassen.
4. Die Nummer des wieder erscheinenden QRWTSRVR Jobs ist die gleiche.
5. Das RPG mit der hängenbleibenden SQL Abfrage aufrufen.
6. In 5 Sekunden geht der RPG Job auf TIMW (auf der V5R2 Maschine)
7. innerhalb der 5 Sekunden strsrvjob und strdbg (ohne parms) auf den obigen Job aufrufen.

[Fuerchau]

Wie ich sehe, castest du die Felder, vergibts allerdings keine neue Namen.
Ggf. ist das hier das Problem, da die Order-By-Klausel auf ein Feld verweist, dass nicht in deiner Select-Liste steht !
Das ist zwar erlaubt, könnte aber das Problem sein.

Ergänze die Cast's mal mit einem Namen:

... cast(Feld as ...) Feld, ...

[cs400_de]

Wie ich sehe, castest du die Felder, vergibts allerdings keine neue Namen.
Ggf. ist das hier das Problem, da die Order-By-Klausel auf ein Feld verweist, dass nicht in deiner Select-Liste steht !
Das ist zwar erlaubt, könnte aber das Problem sein.

Ergänze die Cast's mal mit einem Namen:

... cast(Feld as ...) Feld, ...

Hallo,

wir haben die CASTs eingebaut und es fällt wieder in den berühmten TIMW Status ohne erkennbare I/Os auf der Zielmaschine.

Gruß