Prozeduren in Servicepgm von einem Anderen Programm aus aufrufen.

[dholtmann]

Hallo zusammen,
ich versuche Prozeduren, die ich in einem Programm, welches als Serviceprogramm und
Modul gewandelt ist, von einem zweiten Programm aus aufzurufen.
Ich bekomme folgenden Fehler:

Objekt QZDMMDTA der Art *SRVPGM in Bibliothek QSOC nicht gefunden.
Definition für Symbol 'PR_D1KO_CHAIN' nicht gefunden.

dspsrvpgm sagt:


Informationen zur Serviceprogrammerstellung:
Datum/Uhrzeit der Serviceprogrammerstellung . . : 08.06.16 14:31:57
Exportquellendatei . . . . . . . . . . . . . . . :
Bibliothek . . . . . . . . . . . . . . . . . . :
Exportteildatei . . . . . . . . . . . . . . . . :
Attribut der Aktivierungsgruppe . . . . . . . . : *CALLER
Gemeinsam benutzte Aktivierungsgruppe . . . . . : *NO
Übernommene Berechtigung verwenden . . . . . . . : *YES
ID des codierten Zeichensatzes (CCSID) . . . . . : 65535
Anzahl der Module . . . . . . . . . . . . . . . : 1
Anzahl der Serviceprogramme . . . . . . . . . . : 3
Anzahl nicht aufgelöster Referenzen . . . . . . : 0
Anzahl der Copyrights . . . . . . . . . . . . . : 0
Alle Erstellungsdaten . . . . . . . . . . . . . : *YES
Überwachbare Daten verdichtet . . . . . . . . . : *NO
Laufzeitinformationen verdichtet . . . . . . . . : *NO
Aktualisierung zulassen . . . . . . . . . . . . : *YES
*SRVPGM-Bibliothek aktualisieren . . . . . . . . : *NO
Profildefinitionsdaten . . . . . . . . . . . . . : *NOCOL
Aktivierter Teraspace-Speicher für Module . . . : *ALL
Speichermodell . . . . . . . . . . . . . . . . . : *SNGLVL
Argumentoptimierung . . . . . . . . . . . . . . : *NO
Textbeschreibung . . . . . . . . . . . . . . . . :




Das aufzurufende Programm sieht (gekürzt) wie folgt aus:


ctl-opt nomain;
ctl-opt option(*nodebugio:*srcstmt:*nounref);
**********************************
dcl-proc pr_D1KO_chain export ;
//--------------------------------
// Prozedur Interface
//--------------------------------
dcl-pi pr_D1KO_chain ind;
DS_Input likeds(DS_Datei);
Lock char(1) const;
end-pi;




Der Aufruf per Prototyp in Programm 2:


dcl-pr D1KO_Chain ind extproc('PR_D1KO_CHAIN');
DS_D1KO likeds(DS_ARTS);
Lock char(1) const;
end-pr;


Die Befehle zum Erstellen von Serviceprogramm und Modul:


CRTRPGMOD MODULE(MYLIB/D1KO000) SRCFILE(MYLIB/MYDAT)
SRCMBR(D1KO000) OPTION(*EVENTF) DBGVIEW(*SOURCE) REPLACE(*YES)

CRTSRVPGM SRVPGM(MYLIB/D1KO000) MODULE(MYLIB/D1KO000) EXPORT(*ALL)






Hat von euch jmd. eine Idee / Lösung?

[Fuerchau]

Dein Fehler ist, dass er das Serviceprogram QZDMMDTA nicht findet.
Das hat mit deinen Programmen ja erst mal nichts zu tun.
Schau also mal, wo du das Programm aufrufst bzw. welche Prozedur in diesem Programm.

[dholtmann]

Ich frage mich, wie er auf den Namen kommt?
Muss ich in dem aufrufenden Programm das Serviceprogramm angeben?
Vllt bei der Wandlung oder so etwas?

[dschroeder]

Ich glaube, dein EXTPROC ist falsch. Das darf nicht der Name der Prozedur im Serviceprogramm sein. Es muss der Name des Programmobjektes sein, in dem sich die exportierte Prozedur befindet.

Also nicht:

dcl-pr D1KO_Chain ind extproc('PR_D1KO_CHAIN');
DS_D1KO likeds(DS_ARTS);
Lock char(1) const;
end-pr;

sondern:

dcl-pr D1KO_Chain ind extproc('D1KO000');
DS_D1KO likeds(DS_ARTS);
Lock char(1) const;
end-pr;

Dieter

[Fuerchau]

Wie erstelltst du denn dein Programm, dass das Service-Programm aufrufen soll?
Dort musst du die Module alle mit aufführen.

Arbeitest du nicht mein einem BNDDIR, musst du dein Programm in 2 Schritten erstellen:
1. CRTRPGMOD (bzw. dei SQL-Variante)
2. CRTPGM ... MODULE( Liste der Module ) ... BNDSRVPGM( Liste der Serviceprogramme)

Bei der Fehlermeldung mal F9 drücken und schauen, an wen denn die Nachricht ging.
Per DSPSRVPGM ggf. mal die Exporte prüfen, hier ist Großkleinschreibung wichtig.
BNDDIR's vereinfacht zwar die Sache, macht es allerdings ein wenig komplexer.

[dholtmann]

Dankeschön,
hab das ausprobiert, es läuft aber auf das Gleiche raus


Objekt QZDMMDTA der Art *SRVPGM in Bibliothek QSOC nicht gefunden.
Definition für Symbol 'PR_D1KO000' nicht gefunden.

[dholtmann]

F9 sagt:

Von Programm . . . . . . . . . : QBNBIND
Von Bibliothek . . . . . . . : QSYS
Von Modul . . . . . . . . . : QBNBSYMR
Von Prozedur . . . . . . . . : QBNBSYMR__UnresolvedReferenceIterator
Von Anweisung . . . . . . . : 31

An Programm . . . . . . . . . : QBNBIND
An Bibliothek . . . . . . . : QSYS
An Modul . . . . . . . . . . : QBNBSYMR
An Prozedur . . . . . . . . : QBNBSYMR__SignalUnresolvedReferences
An Anweisung . . . . . . . . : 8


Ich hab CRTBNDRPG verwendet.

ich denke CRTRPGMOD war der wichtige Schritt den ich vergessen hatte.
Ich werde jetzt mal versuchen das auf diese Art zu erstellen.
Dankeschön

[B.Hauser]

Ich frage mich, wie er auf den Namen kommt?
Muss ich in dem aufrufenden Programm das Serviceprogramm angeben?
Vllt bei der Wandlung oder so etwas?

Zum Compile-Zeitpunkt (genauer gesagt zum Zeitpunkt des Bindens) muss er die Prozedur in dem Service-Programm QZDMMMDA in der Bibliothek QSOC gefunden haben und die eindeutige Signatur dieses Service-Programms eingebunden haben.

Wie er das Service-Programm im Binder-Schritt findet, kommt darauf and, ob die Service-Programme manuell aufgelistet werden oder aus einem oder mehreren Binderverzeichnissen, die beim Binder-Schritt angegeben wurden findet.

Sofern das Programm mit CRTBNDRPG gewandelt wird, können Binder-Verzeichnisse im Compile-Befehl aufgelistet werden. Ebenso ist es möglich Binder-Verzeichnisse in den H-Bestimmungen zu hinterlegen.

Binder-Verzeichnisse sind immer additiv, d.h. H-Bestimmungen überschreiben nicht die Compile-Befehl-Angaben und umgekehrt.

Birgitta

[Fuerchau]

Wie heißt denn nun deine Prozedur?
EXTPROC(Prozedurname) im rufenden und EXPORT(Prozedurname) im gerufenen Programm müssen genau übereinstimmen.
Zur Compilezeit wird das Programm gebunden. Sind Importe (wie EXTPROC) nicht vorhanden, kann das Objekt eigentlich nicht erstellt werden.

Außerdem fällt mir auch auf, dass deine DCL-PROC und DCL-PI unterschiedlich sind.
DCL-PROC definiert den Prototyp incl. Parameter der vom Compiler gebunden wird.
DCL-PI definiert die Aufrufschnittstelle der Prozedur selber.
Eigentlich sollte hier der Compiler schon meckern, wenn der selbe Name unterschiedlich definiert ist.
Ggf. ist das der Fluch des Free-Compilers, dass er da nicht mehr zurechtfindet?

[dholtmann]

ich werde die Groß und Kleinschreibung anpassen.
PR und PI passen jedoch zusammen, die Datenstrukturen heißen zwar unterschiedlich, sind aber identisch. Das verwende ich öfter in so einer Kombination.
Ich verwende DS_D1KO likeds(DS_ARTS); und DS_Input likeds(DS_Datei);
nur mit unterschiedlichen Namen, da das eine Programm generiert wird.
Hatte das ganze schon einmal lauffähig, hab es heute aber Stundenlang nicht hinbekommen
(vermutlich aufgrund der Wandlungsart (Da bin ich aber noch dran)).