Releasewechsel von V5R4 auf V7R1 auf der Kippe?

[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.

[B.Hauser]

Nur so ein Schuß ins Blaue:

@1: Prüf' mal welches Naming in der Umgebugn, in der das SQL-Statement ausgeführt wird verwendet wird. ggf. wird jetzt SQL Naming verwendet und damit die Bibliotheksliste nicht mehr durchforstet.

@2: Mit READ SQL DATA habe ich auch bisweilen auf den 7.1 Maschinen Probleme versuch mal die Funktion mit MODIFIES SQL DATA zu erstellen.

Birgitta