-
@fuerchau.
Das API bringt mir nicht so viel 
PCML can now be stored in the module
Program Call Markup Language (PCML) can now be stored in the module
as well as in a stream file. By using combinations of the PGMINFO
command parameter and/or the new PGMINFO keyword for the Control
specification, the RPG programmer can choose where the PCML
information should go. If the PCML information is placed in the module, it
can later be retrieved using the QBNRPII API
@birgitta. bis jetzt ist mein stand leider auch so . aber es muss doch einen weg geben diese liebevolle kleinstarbeit zu umgehen. die schwarze kiste kann doch alles oder
-
... welchen Bahnhof Du da meinst, ist mir schleierhaft. DSPMOD DETAIL(*IMPORT) listet die Verwendung auf und damit alle Aufrufe (und Variablen) die nicht lokal sind.
Das mit den Quellen scannen ist doch wohl ein Scherz und bringt nicht wirklich weiter, ebenso das PCML Gedöns.
D*B
-
also entweder verstehst du mich nicht oder ich dich .
nochmal.
es gibt X programme auf der iseries.
jedes davon verwendet irgendwelche prozeduren von irgendwelchen modulen, serviceprogrammen usw .
der befehl listet mir doch nur die prozeduren auf die das MODUL bereitstellt .
ich will aber wissen welche prozeduren PGMA aufruft.
es kann sein das es von modul a
2 prozeduren aufruft, von modul b 4 , usw usw.
Also , ich will alle Prozedurnamen wissen die das PGMA (RPGLE) verwendet.
-
 Zitat von woodstock99
der befehl listet mir doch nur die prozeduren auf die das MODUL bereitstellt .
i
das ist DSPMOD DETAIL(*EXPORT)!!!!
schau Dir mal DSPMOD DETAIL(*IMPORT) an!!!
-
natürlich benötigst du die einzelnen Module des PGMA um einen DSPMOD für dieses Modul durchzuführen!
Die Importe sind eben dann die aufgerufenen und die Exporte die bereitgestellten Prozeduren.
Welches Programm/Serviceprogramm im Endeffekt verwendet wird, entscheidet ja dann doch die LIBL.
Wie Dieter schon anmerkte, bei doppelten Namen ist der tatsächliche Aufruf eher unklar.
-
sorry aber wir reden aneinander vorbei .
den hab ich mir angeschaut . das bringt mir aber nichts!!! was soll ich jetzt damit anfangen ?
checkt das hier irgendwer oder bin nur ich zu doof
-
fuerchau. ja das sind aber dann alle. und ich weiss nicht welche das PGMA davon verwendet.
ich will aber genau wissen welche Prozeduren PGMA aufruft. also genau den namen von den z.b. im PGMA verwendeten prozeduren .
das modul hat meinetwegen 100 . ich will wissen welche , und genau nur die zwei prozeduren die das PGMA davon verwendet .
-
Entschuldige bitte, aber ich stimme dir da eher zu letzterem zu .
Beim DSPMOD erscheint die Liste der importierten "unaufgelösten" Symbole.
Diese sind die Prozeduren/Variablen, die beim späteren CRTPGM in den anderen Modulen (ggf. per BNDDIR) gesucht und aufgelöst werden.
Also sind das die Namen der verwendeten prozeduren!
Exportierte Symbole sind die zur Verfügung gestellten Prozeduren.
Damit erhältst du eine Liste der Module mit Importen und Exporten.
Per DSPPGM / DSPSRVPGM erhältst du nun, welche Module denn in diesen Programmen verwendet werden.
Nun setzt du dies in Bezug zur oberen Liste.
War das nun klar genug?
Ergänzung:
PGMA -> MODUL1 -> Import Prozedur1
SRVPGM -> MODULB -> Export Prozedur1
-
jupp ich bin zu doof oder ich steh heute so dermassen auf dem schlauch das alles zu spät ist .
PGMA ist ein ganz normales RPGLE .
wo hast du jetzt die information her welche Prozedur PGMA - vom modul1 verwendet??
ich glaub britta hat mich verstanden was ich will .
schau mal bei dir am system nach .
nimm ein RPGLE das ein paar prozeduren vom ModulA aufruft. und nun sage mir welche das genau sind die PGMA aufruft ohne in den Quellcode zu schauen .
ich hab keinerlei zusammenhang.
-
 Zitat von woodstock99
jupp ich bin zu doof oder ich steh heute so dermassen auf dem schlauch das alles zu spät ist .
... dem möchte ich jetzt nicht widersprechen!
statt CRTBNDRPG machst Du einen CRTRPGMOD und für dieses Modul (und alle weiteren, eventuell statisch gebundenen) machst Du dann DSPMOD DETAIL(*IMPORT) und kriegst dann genau die verwendeten externen Procedures ausgegeben.
D*B,
bei dem es offensichtlich kühler im Büro ist.
-
Wie Dieter schon sagt, du benötigst das originäre Objekt "Modul1" der Art *MODULE.
-
ja bei mir ist es sehr warm im büro.
aber das kann doch auch nicht die lösung sein . soll ich jetzt 7364 module erstellen und dann hat man ja noch das problem mit den H bestimmungen . DFTACTGRP(*NO) . deshalb hab ich ja auch geschrieben wir reden aneinander vorbei. wollte das evtl per api lösen , wenn man da iregdnwie die möglichkeit gehabt hätte rauszufinden welche prozeduren ein pgm aufruft .
trotzdem danke
Similar Threads
-
By Bau in forum IBM i Hauptforum
Antworten: 3
Letzter Beitrag: 01-06-07, 09:30
-
By OSfllwr in forum NEWSboard Server Software
Antworten: 0
Letzter Beitrag: 11-01-07, 11:50
-
By marcel331 in forum IBM i Hauptforum
Antworten: 4
Letzter Beitrag: 12-08-06, 13:01
-
By Kampi4 in forum NEWSboard Programmierung
Antworten: 13
Letzter Beitrag: 25-11-05, 07:37
-
By Nasenbär in forum NEWSboard Programmierung
Antworten: 3
Letzter Beitrag: 22-05-03, 08:56
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks