udf ohne ergebniss

[ILEMax]

geht so nicht.

Die Funktion konnte ich nun wieder erstellen, aber das ergebniss ist das gleiche, nur '-'
mit und ohne cast der numm werte

[ILEMax]

so nun binn ich eine idee weiter,
in der Funktion beziehe ich mich ja auf eine Datei. Diese ist anscheinend fest verdrahtet mit der zu CREATE Zeit gefundenen LIB.

wenn ich im CREATE die Lib angebe, auf die ich auch später den select mache, bekomme ich ein ergebniss.
allerdings bekomme ich in n zeilen den (richtigen) Wert, statt nur genau ein Wert.

Un das mit den festen LIB's ist ein K.O Kriterium. kann ich das umgehen ?

Max

[ILEMax]

Das mit den vielen zeilen ist nun auch klar, ich müßte die where Bed. in dem select wiederholen.
Dann macht allerdings die Funktion so keinen Sinn.
Hmm, muß ich wohl weiter VIEW's machen

Könnte ich im SQLRPGLE Pgm sagen
/EXEC-SQL
+set :summe =PNESU31('xxx' 1, 2, 3, 4, 'xxx')
/end-exec

und dann mit Summe weiterarbeiten ?
das müste doch gehen!

nur die feste Lib stört.
Max

[Fuerchau]

set option sqlpath=*libl <= Verwendet später *LIBL.

ein "select sum(...) from ..." kann nicht mehr als 1 Wert liefern wenn ohne Group-By gearbeitet wird.

Verwendest du eine Funktion in einem Select, wird diese natürlich pro Zeile aufgerufen. Die Parameter der Funktion sollten also aus den Zeilenfeldern stammen.

Dein RPG-Aufruf wäre auch korrekt.

[ILEMax]

set option sqlpath = *libl geht nicht
(ich wieß nicht wie und wo)

habe beim versuchen einen 'set path' angeboten bekommen, geht aber auch nicht,
hier nochmal das CREATE, aus neugier wieder um deinen SELECT INTO Vorschlag bereinigt. Funktion wurde erstellt

create function pnesu31 (iProd varchar(14),
iFM1 dec(11, 3),
iFM2 dec(11, 3),
iFM3 dec(11, 3),
iFM4 dec(11, 3),
iLort varchar(3))
returns dec(11, 3)
language sql modifies sql data begin declare summe dec(11, 3);
return (select
sum(nemge0) from mne__39 where nephas = '3' and nestat =
'1' and neprod = iProd and nemge1 = iFM1
and nemge2 = iFM2
and nemge3 = iFM3
and nemge4 = iFM4
and nelort = iLort);
set path=*libl; end

[Fuerchau]

create function pnesu31 (
iProd varchar(14),
iFM1 dec(11, 3),
iFM2 dec(11, 3),
iFM3 dec(11, 3),
iFM4 dec(11, 3),
iLort varchar(3))
returns dec(11, 3)
language sql modifies sql data
begin
set option sqlpath=*libl;
declare summe dec(11, 3);
set summe = (select
sum(nemge0) from mne__39 where nephas = '3' and nestat =
'1' and neprod = iProd and nemge1 = iFM1
and nemge2 = iFM2
and nemge3 = iFM3
and nemge4 = iFM4
and nelort = iLort);
return summe;
end

[ILEMax]

Das hatte ich versucht,

und jetzt hab ich es wieder so.
Leider kommt dann
Schlüsselwort OPTION nicht erwartet. Gültige Token: PATH RESULT SCHE
(dann ist die zeile voll)

Max

[Fuerchau]

Stimmt !
Set Option gilt nicht für Funktionen/Prozeduren.

Da diese in der selben Activation-Group laufen (Service-Programm) wie das aufrufende Programm ist der Suchalgorythmus vom Rufer abhängig.

Der Rufer bestimmt mit der Namenskonvention (*SYS/*SQL) die Suchfolge für unqualifizierte Tabellen.

Bestimmt wird dies mittels
set option naming=*sys (bzw. *sql)
oder bei STRSQL mit F13.

[ILEMax]

Sorry, aber das sagt mir nix

Ich habe das SRVPGM in eine andere Lib Copiert. anschl. die Interaktive sitzung beendet und die liblist komplett gewechselt (definitiv waren alle dateien geschlossen)
Namenskonventionen stehe auf *sys

Ich hätte erwartet, nun ein Erg. zu bekommen.
Allerdings bekomme ich nun die Meldung, das PNESU31 der Art *N in *libl nicht gefunden wurde. ES ist aber DA !
Und der Aufruf ging schon mal (F9)

Was ist nun los?
Habe also folgende Probleme: 1.) Kann ich eine Datei in einer Funktion ansprechen unqualifiziert als DATEI_A anstatt LIB/DATEI_A) und später bei Funktionsbenutzung nimmt er die DATEI_A aus der *curlib oder *libl

2.) Wie transportiere ich eine Funktion (z.B. auf unsere 2. AS400)

Danke

[B.Hauser]

Hallo

hier noch ein paar weitere Informationen:

Set Option gilt nicht für Funktionen/Prozeduren.

Da diese in der selben Activation-Group laufen (Service-Programm) wie das aufrufende Programm ist der Suchalgorythmus vom Rufer abhängig.

Das ist nicht korrekt!
SET OPTION ist auch in SQL Prozeduren und Funktionen erlaubt, allerdings muss das SET OPTION-Statement vor dem Compound Statement (BEGIN) angegeben werden. Allerdings werden die Informationen, die über SET OPTION gesetzt werden NICHT in den System-Tables gespeichert, d.h. gehen beim reverse engineering verloren.
Ob System oder SQL-Naming verwendet wird hat weder mit dem Rufer, noch mit der Aktivierungs-Gruppe etwas zu tun, sondern nur mit den Default-Werten die beim Erstellen des Objekts (UDF oder Stored Procedure) gegolten haben oder was über SET OPTION angegeben wurde. Es wäre absolut tödlich, wenn das Ganze abhängig von der Aktivierungsgruppe wäre und bei einem Aufruf die System-Namensregelung und beim nächsten Aufruf die SQL-Namensregelung gelten würde.

SET OPTION SQLPATH oder SET PATH gibt den Suchpfad nur für Stored Procedures oder User Defined Functions an, die in (statischen) SQL Statements unqualifiziert aufgerufen werden. SET PATH gilt ausserdem nur wenn SQL-Naming verwendet wurde. Bei System-Naming wird die Bibliotheksliste durchsucht. Der SQL PATH gibt jedoch NICHT den Suchpfad für Tabellen/Dateien und Views an.

In welcher Bibliothek/Schema die unqualifiziert angegebenen Tabellen/Dateien und Views gesucht werden, hängt von dem verwendeten Naming ab.

Wird SQL-Naming verwendet, werden die Daten in einer Bibliothek gesucht, die dem Namen des angemeldeten Benutzers entspricht. Über SET CURRENT SCHEMA kann man jedoch eine andere beliebige Bibliothek vorgeben. Es können allerdings nur Tabellen oder Views in einer einzigen Bibliothek unqualifiziert angesprochen werden. Müssen Dateien/Tabellen oder Views in mehreren Bibliotheken/Schemata angesprochen werden, ist ein qualifizierter Aufruf notwendig.

Wird System-Naming verwendet, wird die Bibliotheks-Liste als Basis genommen. Hier können auch Dateien, die in unterschiedlichen Bibliotheken hinterlegt sind, unqualifiziert angesprochen werden.

Zu Deinen Problemen:
1. Anstatt das Service-Programm zu kopieren, solltes Du es löschen und die UDF in der anderen Bibliothek erneut erstellen. Das Problem ist, dass durch die Kopiererei die Signatur über die die Funktion gefunden wird nicht mehr korrekt ist.
2. Der sicherste Weg die Funktion auf eine andere Maschine zu transportieren ist, den Source-Code zu übertragen und die Funktion neu zu erstellen. Ansonsten bleibt nur Sichern der Bibliothek und auf der anderen Maschine zurücksichern, dann werden auch die System-Tables korrekt aktualisiert.

Birgitta

[ILEMax]

Vielen Dank für diese ausfürlichen Erklärungen.
Beim CREATE Funktion steht mein naming auf *sys (f13)
Ich konnte die Funktion erstellen mit
... language sql modifies sql data
set option sqlpath=*libl
begin ...

in der Funktion habe ich KEINE Bibliothek angegeben ... select sum(nemge0) from DATEI ...
Die Datei steht während des CREATE Function in einer LibA

Der Aufruf
select PNESU31('xxx' 1, 2, 3, 4, 'xx') from LibB/DATEI
geht nicht, egal ob LibB in der Liblist ist, *curlib ist oder weder noch.

Also hab ich irgendetwas nicht verstanden.
HILFE

Das ich das Objekt nicht Kopieren kann finde ich eine Katastrophe !!

alle unsere Programme werden aus der Entwicklungsumgebung in die Testumgebung in die ECHT-Umgebung kopiert. (Automatisch auf Projektnr-Basis)Der Transport von Sourcen ist da garnicht vorgesehen.

ILEMax