Releasewechsel von V5R4 auf V7R1 auf der Kippe?

[Bratmaxxe]

Moin,

wir planen den Umstieg auf das Release V7R1 und haben hierzu eine Testmaschine zur Verfügung gestellt, auf der unsere IT ihre technsichen Programmtests laufen lässt.

Jetzt sind wir auf einige Probleme gestoßen, die unter V5R4 nicht auftraten:

1.) Eine SQL Anweisung funktioniert nicht mehr:
- eine Tabelle "TEST" enhtält eine Spalte (FIELD1) die als INTEGER definiert ist

select * from test where field1 > ' ' resultiert in einem "Umsetzungsfehler bei Variable oder Parameter *N."

Dieses Select kann leider von uns nicht angepasst werden, da es eine Kaufsoftware ist, die nicht mehr supported wird.

Weiß jemand ob hier was am impliziten cast geändert wurde, oder sowas überhaupt konfigurierbar ist??

2.) Eine 2 Phase commit funktioniert bei einer Stored Procedure nicht mehr und bricht mit einer "class java.sql.SQLException: Cursor state not valid" ab:

Der Aufruf der Stored Procedure schlägt lediglich innerhalb einer 2-Phase-Commit Transaktion (Treiberklasse: com.ibm.as400.access.AS400JDBCXADataSource) fehl, nicht in einer 1-Phase-Commit Transaktion (Treiberklasse: com.ibm.as400.access.AS400JDBCConnectionPoolDataSo urce).
In unseren Application Servern setzen wir 2-Phase-Commit Transaktionen ein.

Die Stored Procedure ist unter V5R4 wie folgt erstellt worden und funktioniert dort tadellos:

CREATE PROCEDURE PGM/MYPGM(IN P1 CHAR ( 3), IN P2 CHAR
(2 )) NOT DETERMINISTIC READS SQL DATA EXTERNAL NAME MYPGM
PARAMETER STYLE GENERAL WITH NULLS

CRTSQLRPGI OBJ(PGM/MYPGM) SRCFILE(PGMSRC/QRPGLESRC) COMMIT(
*NONE)
OUTPUT(*PRINT) OPTION(*XREF *SEQSRC) CLOSQLCSR(*ENDMOD) DBGVIEW(
*SOURCE)


Über den ein oder anderen Rat / Tipp würde ich mich freuen...

Schönes Wochenende
Gruß Max

[andreaspr@aon.at]

Hallo Max,

@1: Ab 7.1 wird strenger geprüft. Was zuvor nur eine Warnung war, ist jetzt ein Fehler.
In diesem Forum gab es auch schon andere mit dem gleichen Problem.

@2: Hattet ihr unter V5R4 vielleicht default Werte beim Kompelieren?
Vergleich mal mit DSPSRVPGM / DSPPGM die Attribute auf beiden Systemen.

lg Andreas

[Fuerchau]

Zu 1)
Da gibts keine Umgehung.
Du kannst zwar eine View mit einem cast auf DIGITS darüberlegen, ebr wer weiß schon was sonst noch damit genacht werden wenn das Ergebnis dann nicht in die Hostvariable passt wegen Umsetzungsfehler.

zu 2)
Hier muss man schon noch den Cursor-Status prüfen.

[Bratmaxxe]

Hallo Baldur,

zu 2) hätte ich noch einige Rückfragen.

Auf welcher Seite soll der Cursor geprüft werden (Procedure oder Aufrufer) und hat der Aufrufer überhaupt eine Chance den Cursor zu prüfen, wenn ja wie?

Gruß
Max

[BenderD]

... ich habe zu 1 zwar keine Erfahrungswerte (da ich solchen Murks nicht mache und ausbaue, wenn er mir vor die Füße läuft), aber hat da mal jemand probiert SQL_DECFLOAT_WARNINGS auf *YES zu setzen?

D*B

[Fuerchau]

Zu 1)
Da die Tabelle ja "TEST" heißt, nehme ich mal an, dass dies nur ein Test-SQL ist und die Tabelle keine relevanten Daten hat.

zu 2)
Da deine Procedure mittels COMMIT(*NONE) definiert ist, und V7 jetzt wohl restriktiver prüft, ist ein 2-Phase-Commit nicht möglich. Schließlich ist für deine Procedure kein Commit erforderlich und wird deshalb wohl abgelehnt (keine Commit-Definition aktiv).
Entweder die Procedure auf COMMIT(*CHG) anpassen incl. Journalisierung der betroffenen Dateien oder dein Java so anpassen, dass für die Procedure kein Commit durchgeführt wird.

[Bratmaxxe]

@Dieter: wie bereits erwähnt, es handelt sich hierbei um eine Kaufsoftware - die hantiert mit Scripten rum, worin beschrieben ist, wie auf die DB Zugegriffen wird --> wie das SQL zusammengefummelt wird kann ich nicht beeinflussen. Klar ist sowas murks...

@Baldur:
zu 1) es handelt sich schon um eine Produktivtabelle, habe sie lediglich hier als TEST deklariert

zu 2) COMMIT(*CHG) brachte keinen Erfolg und führt zum Cursor-Fehler.
Die App-Server-Seite zu modifzieren bedeutet böses rumgefrickel.

Gäbe es sonst noch eine Option?

Vielleicht ist die Procedure auch das falsche Konzept. Diese existiert nur, um sich eine ID für den nächsten "Write" zu ermitteln. Sowas hätte man damals als auto increment Spalte definieren sollen... Aber nu ist das Kind in den Brunnen gefallen;(

Anbei noch die Definitionen:

H DECEDIT('0,') DATEDIT(*DMY.) ALWNULL(*USRCTL)  
H DFTACTGRP(*NO) OPTION(*NODEBUGIO)

in der Main wird dann ein RPG gecalled, welche die nächste Nummer ermittelt und das Ergebnis zurückliefert:

CALL      'SOMEPGM'                
PARM                    XXX
PARM                    XXX   
PARM                    XXX   
PARM                    XXX

C* *  Datenstruktur füllen                            
C     1             OCCUR     DSARRAY1                
C                   Z-ADD     G_NUMMER      #NUMMER   
 *                                                    
C/Exec Sql                                            
C+  SET RESULT SETS FOR RETURN TO CLIENT              
c+      ARRAY :DSARRAY1 FOR 1 ROWS                    
C/End-Exec                                            
C                   MOVE      *ON           *INLR

Gruß
Max

[Fuerchau]

zu 1)
Da wirst du leider um eine Anpassung nicht herumkommen. Sonst musst du wohl auf V5R4 bleiben.

zu 2)
Mach einfach einen Sequence statt der Procedure:
create sequence myseq
select next value for myseq from sysibm.sysdummy1

[BenderD]

... ich habe gerade nochmal ein wenig rumgespielt:
a) select * from myTable where myInt > ''
b) select * from myTable where myInt > ' '
c) select * from myTable where myInt > '0'
Variante c geht auf Oracle, MS SQL, MySQL und Firebird
Oracle: a kein Fehler (wird als null interpretiert), leere Menge; b Fehler
MS SQL: a und b Fehler
MySQL beide kein Fehler, wird als 0 interpretiert
Firebird beide kein Fehler, wird als null interpretiert

D*B

Summa Summarum: der SQL Standard legt das Verhalten nicht fest => Meldung Software defekt an IBM, da Kompatibilität gebrochen wird!!!

[Bratmaxxe]

@Baldur: Sequence bedeutet richtig viel Aufwand, da sämtliche Programme, die in diese Datei schreiben angepasst werden müssten... (RPG Sourcen als auch Java-Umwelt)

Wer hätte damals gedacht, dass eine Hausgemachte ID - Generierung einem richtig böse auf die Füße fallen würde.

Sonst noch Hinweise, die die Procedure am Leben erhalten könnten?

Gruß
Max

[andreaspr@aon.at]

Meines erachtens dürfte das COMMIT *NONE keine Probleme machen. Das PGM würde halt außerhalb der Transaktion laufen und dürfte darauf keinen Einfluss haben.

Probiere testhalber das PGM mit DFTACTGRP(*NEW) zu erstellen.

[Fuerchau]

*NEW ist bei SQL-Aufruf eher die schlechte Variante, ins besonders wenn mit *INLR = *OFF verlassen wird.
Aber eine explicit benannte eigene ACTGRP könnte gelingen, da diese eigene Commit-Definitionen hat.