Page 1 sur 1
Commande de compilation perso - retour dans RDi
Posté : mar. 25 juil. 2017, 11:27:06
par NicolasG
Bonjour,
la compilation de nos programmes passe par une routine interne qui construit un PF-SRC INCFILE dans QTEMP pour y déposer les copy (cobol) utilisé dans les instructions include de SQL.
Pour avoir le résultat de compil dans RDi, j'ai construit une commande avec en paramètres les chaines "SRCMBR" et "OPTION(*EVENTF)" comme indiqué dans la doc.
Mais rien n'y fait. je n'ai pas de retour dans Rdi
info sur le process:
Nos objets sont créés dans QTEMP, je fichier EVFEVENT aussi
les objets sont déplacés vers LIBOBJ et le membre au nom de l'objet dans EVFEVENT est copier vers la bib de création aussi.
==> toutes cette phase fonctionne bien.
Si quelqu'un dispose d'une astuce , je suis preneur. Merci.
RDI et EVFEVENT
Posté : mar. 25 juil. 2017, 13:58:14
par cmasse
voici ce que j'avais noté la dernière fois que j'ai rencontré ce problème
Si vous avez ajouté vos propres commandes de compilation elles doivent contenir deux chaînes de caractère pour que cette fenêtre s'affiche :
*EVENTF (s'il le faut en commentaire ! )
SRCMBR(le_nom_du_source)
et elles doivent générer un fichier EVFEVENT dans la bibliothèque de création avec un membre portant le même nom que le source
Si le fichier EVFEVENT n'est pas bien localisé , vous pouvez forcer un modifiant la *LDA
de 1 à 10 : la bibliothèque contenant le fichier EVFEVENT
de 11 à 20 : le membre source
Posté : mer. 26 juil. 2017, 11:46:33
par NicolasG
Bonjour et merci pour votre retour.
pour une compilation dans une bib quelconque celà fonctionne. mais pour une génération dans QTEMP puis déplacement de l'objet vers la bib objet, c'est une autre affaire.
j'ai beau déplacer le membre EVFEVENT vers la bib de création, RDi ne le trouve pas.
si d'autres pistes existent ?
*eventf
Posté : mer. 26 juil. 2017, 12:12:40
par cmasse
et vous avez bien la chaîne *EVENTF dans la commande de compil RDI , s'il le faut sous forme de commentaire ?
Posté : mer. 26 juil. 2017, 14:47:13
par NicolasG
Oui Oui, voici la commande qu j'envoi à Ibmi depuis Rdi:
CPLRDI SRCLIB(PRJGRN) SRCFIL(QCBLLESRC) SRCMBR(ADRUPD) CRTLIB(PRJGRN) OPTION(*EVENTF)
la commande appelle un pgm CL qui determine le source
si c'est un cobol sql, le pgm résout les dépendances SQL include src-mbr pour alimenter la zone incfile de la commande,
et lance le commande de compilation qui va bien :
CRTCBLMOD avec option(*EVENTF) => crée le module dans QTEMP
puis je recopie le membre ADRUPD de EVFEVENT de QTEMP vers CRTLIB
puis CRTPGM => bnd le module dans CRTLIB .
puis je supprime le module de QTEMP.
ou
CRTSQLCBLI option(*EVENTF) => crée le module dans QTEMP
puis je recopie le membre ADRUPD de EVFEVENT de QTEMP vers CRTLIB
puis CRTPGM => bnd le module dans CRTLIB.
puis je supprime le module de Qtemp
Si je modifie mon CL de compilation pour créer mes objets directement en CRTLIB, RDi veut bien afficher la liste des erreurs.
Est-ce l'utilisation de QTEMP qui pose problème ?
Cdlt,
RDI et compilation
Posté : mer. 26 juil. 2017, 16:33:08
par cmasse
Effectivement ça semble coincer, j'ai fait un petit test de compilation RPG
Code : Tout sélectionner
PGM PARM(&SRCF &SRCL &SRCM)
DCL &SRCL *CHAR 10
DCL &SRCF *CHAR 10
DCL &SRCM *CHAR 10
CRTBNDRPG PGM(QTEMP/&SRCM) SRCFILE(&SRCL/&SRCF) +
SRCMBR(&SRCM) OPTION(*EVENTF)
MONMSG CPF0000 EXEC(RETURN)
MONMSG RNS0000
MOVOBJ OBJ(QTEMP/&SRCM) OBJTYPE(*PGM) TOLIB(&SRCL)
MONMSG CPF0000
CPYF FROMFILE(QTEMP/EVFEVENT) TOFILE(&SRCL/EVFEVENT) +
FROMMBR(&SRCM) MBROPT(*REPLACE) CRTFILE(*YES)
CHGDTAARA DTAARA(*LDA (1 10)) VALUE(&SRCL)
CHGDTAARA DTAARA(*LDA (11 10)) VALUE(&SRCF)
ENDPGM
il ne m'affiche rien, pourtant si je renseigne mal la *LDA (en inversant &SRCF et &SRCL, par ex.), RDI m'affiche une erreur....
je craint qu'il ne faille ouvrir un incident.
fichier EVFEVENT
Posté : ven. 28 juil. 2017, 11:36:24
par cmasse
Bonjour,
j'ai trouvé ça
https://www.ibm.com/developerworks/comm ... 8e34d84372.
Il faudrait modifier le contenu de EVFEVENT pour qu'il contienne le nom de la bonne bibliothèque.
Posté : mer. 09 août 2017, 13:28:04
par NicolasG
je suis parvenu à mes fins.
apres avoir déplacé le membre EVFEVENT concerné, il fallait bien modifier la *LDA.
Merci.
Cette question est résolue