udf ohne ergebniss

[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

[Fuerchau]

Also ich habe nun folgendes ausprobiert und festgestellt:

"set option naming=xxx" wird tatsächlich abgewiesen.
Das Naming ist durch die aktuelle Umgebung definiert und wird zum Erstellzeitpunkt in das Programm übernommen. Egal ob ich STRSQL oder RUNSQLSTM verwende.

Ist *SYS eingestellt wird die unqualifizierte Tabelle später über *LIBL gesucht, bei *SQL eben über USERNAME (bzw. DFTRDBCOL).
Dies kann man sehr schön über DSPJOB->14 (SysReq) sehen.

Durch ändern der Libliste wird dann auch korrekt die eingestellte Tabelle ermittelt.

Dass die Objekte nicht kopiert werden können ist nur bedingt richtig. Entscheidend ist hier die verwendete Methode !
CRTDUPOBJ erstellt tatsächlich nur eine Kopie des reinen Programmobjektes.

Ein SAVOBJ sichert SQL-Informationen mit, ein RSTOBJ trägt diese SQL-Infos auch ins Repository.
Normalerweise werden Programme ja von SystemA nach SystemB transportiert und natürlich ohne Quellen. Dies geht auch wunderbar, sonst könnte ich keine SQL-Programme (Funktionen/Prozeduren) ausliefern.

Muss man dies lokal von LibA nach LibB machen, reicht eben ein CRTDUPOBJ nicht mehr aus. Ich kann das Programm/Service-Programm jedoch mittel SAVOBJ/RSTOBJ über eine SAVF kopieren, und siehe da, die SYSPROCS/SYSFUNCS enthalten die korekten Verweise.

Siehe "select * from sysprocs" / "select * from sysfuncs"

[Fuerchau]

select PNESU31('xxx' 1, 2, 3, 4, 'xx') from LibB/DATEI

Achtung: hier gibts ein Signaturproblem, da die Zahlen 1,2,3,4 nicht korrekt zugeordnet werden können.
Du musst hier ggf. ein Casting vornehmen:

select PNESU31('xxx' dec(1, 11, 3), dec(2, 11, 3), dec(3, 11, 3), dec(4, 11, 3), 'xx') from LibB/DATEI

Ggf. findet SQL auch diese Version:

select PNESU31('xxx' 1.0 , 2.0 , 3.0 , 4.0, 'xx') from LibB/DATEI

Dass Problem ist, dass SQL Zahlen entsprechend ihrer Ausprägung optimiert. Diese Zahlen werden automatisch als INTEGER interpretiert, deine Funktion hat aber eine Signatur mit Dec(11, 3) und somit kann sie nicht gefunden werden.

Eine Zahl 1.0 wird als DEC interpretiert, eine Signatur ist also ermittelbar. Mittels Casting wird es dann sogar eindeutig.

[ILEMax]

Na ja, ich denke wenn

select PNESU31('xxx' 1 , 2 , 3 , 4, 'xx') from DATEI

mit LibList LibA (wie beim create) geht, müsste LibB auch gehen.

select PNESU31('xxx' 1 , 2 , 3 , 4, 'xx') from LibA/DATEI geht ja auch.

Werde Montag nochmal nachsehen (sysreq / offene Dateien) is ja auch ne gute Idee

Danke
Max

[Fuerchau]

Ach jaaa.

Du machst eine Funktion in LibA die später nicht in der Libl ist.
Mach einen "select liba/PNESU31(...", qualifiziere also den Funktionsnamen.
Oder pack die LibA ans Ende deiner aktuellen Libl oder kopiere (SAVOBJ/RSTOBJ) deine Funktion in LibB.

[ILEMax]

So, hab nun neu getestet.

Create ... return(select ...
from DATEI_OHNE_LIB ...

und anschließend

select Funktion(...) from DATEI_OHNE_LIB (in der selben Sitzung) geht.

select Funktion(...) from LIB/DATEI geht nur, wenn LIB auch in Liblist vorhanden ist. Ein 'Mitnehmen' (wie ich es mir gewünscht hätte) der fest angegebenen Lib in die Funktion geht nicht.

mit SAVOBJ / RSTOBJ übertragen geht auch.

Hab also was gelernt, bin nicht ganz zufrieden, aber kann mir zukünftig wieder ein wenig besser helfen.

Vielen Dank allen beteiligten Helfern !

gruß
Max

[Fuerchau]

Ein "mitnehmen" einer LIB wäre auch fatal.

Wenn ich

Select ... from fileA
inner join LIBX/fileB ...

soll schließlich LIBX nicht für fileA verwendet werden.
Was anderes würdest du bei deiner Funktion nämlich nicht verlangen.