Exécuter Programme CL par Store procédure [Résolu]

[Bizounett]

Bonjour à tous,

Ce que je veux faire est de d'envoyer le résultat du WRKACTJOB dans un PF pour pouvoir le manipuler en SQL. Je veux que tous se fasse à partir d'une connection ODBC, pas d'écran verte et noir.

Voici la situation :

J'ai créé un programme CL qui se lit comme suit (Code pris sur le net):

Code :

1
2
3
4
5
6
7
8
9
10
PGM                                                               
             OVRPRTF    FILE(QPDSPAJB) HOLD(*YES)                 
             WRKACTJOB  OUTPUT(*PRINT)                            
             CRTPF      FILE(CANADA6/ACTJOBPRT) RCDLEN(132)       
             MONMSG     MSGID(CPF0000)                            
             CPYSPLF    FILE(QPDSPAJB) TOFILE() +
                          SPLNBR(*LAST)                           
             DLTSPLF    FILE(QPDSPAJB) SPLNBR(*LAST)              
             DLTOVR FILE(QPDSPAJB)                                
ENDPGM

Ce petit programme copy tous ce qu'il y à dans le WRKACTJOB dans un PF qui est CANADA6/ACTJOBPRT.

Quand le fais call pgm(actjob) sur la ligne de commande du AS/400, ça fonctionne très bien. Et je suis capable de le manipuler en SQL. Parfait c'est exactement ça que je veux.


Bien, alors j'ai créé une store procédure pour appeler ce CL qui se lit comme suit :

Code :

1
2
3
4
5
CREATE PROCEDURE canada6.sactjob
 RESULT SETS 0
 EXTERNAL NAME qgpl.actjob
 LANGUAGE CL
 PARAMETER STYLE GENERAL;

Cette store procédure appel seulement le programme CL.

Quand je suis dans STRSQL sur le AS/400 et que je fais call canada6.sactjob ça fonctionne très bien.

Le but ultime est d'être capable de la partir depuis SQL en ODBC, mais ça fonctionne pas, j'ai toujours cette erreur :

SQL State: 38501
Vendor Code: -443
Message: [SQL0443] Trigger program or external routine detected an error. Cause . . . . . : Either a trigger program, external procedure, or external function detected and returned an error to SQL. If the error occurred in a trigger program, the trigger was on table ACTJOB in schema QGPL. If the error occurred in an external procedure or function, the external name is ACTJOB in schema QGPL. The associated text is *N. If the error occurred in a trigger program, the associated text is the type of trigger program. If the error occurred in an external function, the associated text is the text of the error message returned from the external function. Recovery . . . : Refer to the joblog for more information regarding the detected error. Correct the error and try the request again.

Je ne comprend pas pourquoi, si quelqu'un un une idée se serais très très très aprécié...

P.S: l'utilisateur n'as pas access à l'écran verte et noir.

Merci d'avance

Bizz

[Mercure]

Quel langage ou logiciel client utilises-tu avec l'ODBC ?

Colle ici les instructions d'appel à la procédure stockée.

[Bizounett]

Pour l'instant je le test avec l'outil de la suite iNavigaror qui est run SQL Script. Mais ça va être en Delphi. J'ai déjà d'autre procédure qui partent des CL je j'utilise avec Delphi, mais celui la ne fonctionne pas, je ne comprend pas.

Pour l'instruction, regarde dans mon premier post est est écrit juste au dessus de l'erreur. C'est

Code :

call canada6.sactjob

Merci

[James_uc]

Bonjour,

J'ai fait du delphi il y a très très longtemps, mais de souvenir c'était "à peu près" le même principe que VB ...
En VB tu as le composant cwbx qui te permet de lancer une commande directement :

Set sysIbmi = New cwbx.AS400System
sysIbmi.Define strNomIbmi(Index)
sysIbmi.UserID = strUser
sysIbmi.Password = strPwd
Set cmd.System = sysIbmi

On Error Resume Next
'Create spool file with disk status
strString = "SBMJOB CMD(CALL PGM(MYPGM) PARM(" & strParm1 & " " & strParm2 & ")) JOB(JOBNAME) OUTQ(*USRPRF) USER(QUSER) "
'Launch MYPGM via SBMJOB
cmd.Run strString

Cela doit être adaptable en delphi je pense, comme ça, plus besoin de passer via une procédure stockée ...
Par contre, il faut avoir installée System i Navigator sur le poste/serveur qui utilisera l'appli ...

Amicalement,

James

[K2R400]

James,

Notre ami(e) buizounett cherche à remonter les infos du WRKACTJOB dans son programme.

Pour moi la meilleure solution est soit :

- de créer un programme RPG renvoyant un result set, programme qui utiliserait l'API QUSLJOB, regarde sur le site de philippe (mercure) pour trouver des exemples : http://www.psoriano.freesurf.fr/index.html

- de créer le même programme RPG mais en tant qu'UDTF. C'est plus compliqué à faire mais pas si terrible que ça. L'avantage de cette solution est qu'elle est évolutive. On pourra jointer cette UDTF avec d'autres UDTFs (ramenant par exemple l'historique du job, ou la pile d'appel, ou les fichiers ouverts etc...)



@bizounett,

Peux-tu donner le détail de la JOBLOG du job afin d'avoir plus de détail sur l'erreur.

[Mercure]

En y réfléchissant un peu plus qu'hier soir, je me rends compte que la méthode employée par Bizounett ne peut pas fonctionner comme il le souhaiterait.

Le CL associé à la procédure stockée appelée depuis le Navigator IBM comprend la commande WRKACTJOB OUTPUT(*PRINT) pour pouvoir recopier le fichier spool généré dans un fichier PF utilisateur et exploiter ensuite ce dernier avec le client Delphi. Or, le fichier spool issu du WRKACTJOB déjà cité est généré dans un autre job que celui dans lequel tourne le CL parce que cette commande est utilisée dans un programme qui est associé à une procédure stockée appelée depuis le Navigator IBM et non plus en direct via STRSQL. En conséquence, le CPYSPLF ne peut pas trouver et pour cause le fichier spool QPDSPAJB dans le job en cours et génère une erreur générale SQL0443 renvoyée au Navigator IBM.

Si on s'obstine dans cette voie, on pourrait essayer de bricoler les programmes pour s'en sortir mais ça ne serait jamais que du bricolage et on finirait par aboutir à une espèce d'usine-à-gaz très compliquée.

En fait, l'objectif ne sera pas aussi simple que développer un CL. Je rejoindrais soit Patrick (K2R400) sur les options qu'il propose soit je laisserais tomber Delphi, qui fait en outre partie des anciennes technologies, et je développerais un petit package avec CGIDEV2 pour afficher les données de l'écran WRKACTJOB sur le navigateur Internet. Cette dernière option est intéressante et moderne mais demande certainement un plus gros investissement que les 2 autres.

Bizounett, fais-nous part de ta décision, stp.

[Bizounett]

Merci à tous,

Je vais y aller avec la solution à James_uc. Ça fonctionne très bien. Je ne veux pas que l'utilisateur voit les informations. Je veux juste valider qu'une job est bien en fonction avant de partir une certaine commande. S'il est n'est pas en fonction je dois la partir automatiquement. C'est pour ça que la méthode à James_UC est parfaite pour moi, je lance mon programme CL via un SBMJOB avec le composant ActiveX et ça marche !!!

Merci à tous pour vos suggestions et commentaire. C'est la deuxième fois que j'ai recours à vos services et c'est toujours avec professionnel et rapide comme solution.

Merci

Bizz

[James_uc]

Bonjour Mercure,

c'est effectivement le problème que j'avais eu avec le dev de mon petit outil, mais on peut s'en sortit avec un SBMJOB sans que ce ne soit compliqué ...

Je pense que ce que veut Bizounett, c'est récupérer les infos du WRKACTJOB pour les interpréter à sa sauce avec Delphi, pcq il connait Delphi et qu'il est disponible dans son entreprise.
J'ai eu exactement le même cas, mais avec VB, que je connais et qui est disponible dans mon entreprise actuelle.
L'avantage de ces languages, c'est qu'on peut ne pas les utiliser pendant des mois, et quand on revient dessus, tout est toujours aussi simple à coder !

En VB, je lance un job qui génére un spool pour le copier dans un PF.
Une fois le job terminé, mon VB lance une récupération de ce fichier (qui contient les informations du spool) via une requête SQL. Ainsi, sur mon "serveur windows", je n'ai que les informations utiles (via mon SQL qui fait ce que je veux) dans un fichier plat micro, que mon VB exploite ensuite pour faire un affichage "windowsien" (avec des couleurs et des voyants qui s'allument ou pas suivant les infos du fichier, etc ...)

Dans l'absolu, je sais que je pourrais en faire bcp plus coté IBM i, mais je ne fais pas assez de RPG/RPGLE au quotidien pour me trouver assez à l'aise pour le faire. J'utilise les API quand je le dois, mais ce n'est pas ma tasse de thè.

Je pense que c'est plus une question d'automatisme et canevas qu'autre chose. J'ai le modèle en VB + CLP/RPG pour faire une extraction d'infos, donc j'ai tendance à la réutiliser, ce qui va plus vite. J'appelle le même PGM pour tous les différentes fonctions d'un outil, qui réagit suivant la valeur du paramétre qui lui est transmis, par VB ...
J'aurais le canevas d'un RPG avec des API transposables facilement pour avoir les infos que je veux (état disque, travaux du systèmes, etc ...) je serais plus enclin à l'utiliser.
L'inconvénient des API quand on ne les utilise pas, c'est qu'il faut tout le temps chercher celle qui conviendrait à notre besoin.
L'avantage du CLP, c'est que les commandes sont connues de tous (WRKDSKSTS, WRKACTJOB, etc ...) et que leurs résultats sont facilement exportables dans un fichier, nativement ou via spool puis copie du spool.
La récupération du/des fichier(s) généré(s) est identique en VB / Delphi, et le post-traitement des résultats se fait très facilement avec ces outils.

Nous sommes d'accord sur le fait que c'est très old-fashion comme technique, pas optimisé en temps d'exécution, qu'on végéte à utiliser les même vieux trucs plutôt que se former à CGIDEV ou autre ...
Mais il faut voir que c'est rustique mais éprouvé comme technique, très facilement maintenable (tout le monde n'est pas forcément à l'aise avec le RPG/RPGLE et les API) pour peu qu'on ai abondamment commenté le peu de code VB nécessaire (ce qui n'est à faire qu'une fois, le canevas étant réutilisé), et que ça permet de répondre très rapidement à une demande.
Et le fait que Bizounett lance apparamment d'autres CL tendrait à prouver qu'il a un canevas Delphi / ODBC en stock

Tout le monde n'a pas vocation à développer avec les derniers languages / dernières évolutions.
L'objectif est la finalité de l'outil :
Est-ce qu'il fait ce qu'on lui demande ?
Est-ce qu'il n'a pas couté trop cher à produire (en temps, formation, investissement, etc ...) ?

Je ne sais pas pour Bizounett, mais la théorie est parfois (souvent) rattrapée par la pratique
En mission chez les clients, on répond aux demandes du client avec les outils et les moyens des clients ...
Cela peut passer par du VB, mais j'ai aussi du passer par de l'Excel, etc ...

Il est très intéressant de savoir que ces nouveaux moyens existent, merci à vous K2R400 et Mercure (j'ai d'ailleurs souvent fini sur ton site pour résoudre une problématique, notamment sur les API), mais vous ne répondez pas au problème de ce pauvre Bizounett ...

Bizounett, je peux te donner source d'un petit CLP qui sort l'état disque dans un PF-DTA si tu le souhaites.

James

[Mercure]

Envoyé par bizounett

je lance mon programme CL via un SBMJOB avec le composant ActiveX et ça marche !!!

Surprenant ! J'aurais parié le contraire. Je ne vois même pas comment ça peut marcher car on devrait se heurter au même pb que celui que j'ai développé dans mon post précédent.

[Mercure]

@James-uc,

Je comprends les urgences. De vouloir faire vite-fait-sur-le-gaz un programme CL, Delphi, VB, etc pour subvenir à un besoin, s'il est ponctuel et non répétitif, je veux bien, sinon, il suffit qu'à la faveur d'une release quelconque IBM modifie ou déplace ne serait-ce que légèrement le contenu du fichier spool pour que toute l'appli se retrouve par-terre. Ce n'est vraiment pas pour cette méthode, si méthode il y a, que j'opterais.

[Bizounett]

Attention Mercure,

Je ne lance pas ma procedure stoké par le SBMJOB, je lance directement le programme CL. C'est peut-être pour ça que ça fonctionne.

[James_uc]

Envoyé par Mercure

Surprenant ! J'aurais parié le contraire. Je ne vois même pas comment ça peut marcher car on devrait se heurter au même pb que celui que j'ai développé dans mon post précédent.

En le lançant en SBMJOB avec QUSER (ou un autre) et en ayant indiqué OUTQ(*USRPRF), le spool généré reste visible du travail soumis. Sinon, l'OUTQ est par défaut *CURRENT, et là, le spool n'est plus visible, car généré dans l'OUTQ de celui qui a soumis, ce qui fait planter le PGM ...

[James_uc]

Envoyé par Mercure

@James-uc,

Je comprends les urgences. De vouloir faire vite-fait-sur-le-gaz un programme CL, Delphi, VB, etc pour subvenir à un besoin, s'il est ponctuel et non répétitif, je veux bien, sinon, il suffit qu'à la faveur d'une release quelconque IBM modifie ou déplace ne serait-ce que légèrement le contenu du fichier spool pour que toute l'appli se retrouve par-terre. Ce n'est vraiment pas pour cette méthode, si méthode il y a, que j'opterais.

Mercure, je suis d'accord.
Pour ce qui est des changements de format de spool suivant les versions, ce qui est une contrainte normalement évitée avec les API, le plus simple que j'ai trouvé est d'adapter la requête en VB selon la version de l'IBM i.
Concrétement, le composant cwbx permet de connaitre VRM de l'IBM i connecté, et suivant cela, le cas échéant d'adapter le SQL employé.
Les changements de spool sont plus de la mise en page différente, et ce sont donc simplement les valeurs de SUBSTR qui changent.
Les clients ayant rarement les même niveaux sur leurs différentes machines, c'est également un pavé de code qui revient régulièrement ...

Cela ne reste malgrè tout que des petits outils rapides à déployer et mettre en oeuvre pour des besoins précis.
Le but n'est pas de redévelopper des solutions de supervisions / contrôles d'accès / etc ... dont les versions commerciales sont très nettement supérieures en ergonomie / possibilités.
Sans parler de l'aspect financier qui avantage incontestablement tout progiciel par rapport à un petit outil qui serait tenté de grossir (car pas conçu pour ça) ...

James

[Mercure]

Utiliser une ou deux APIs, c'est courant de nos jours et il n'y a là rien de bien mystérieux. Pour celui qui s'intéresse un tant soit peu à son travail, c'est une bonne chose je pense que de vouloir les utiliser, ça permet de découvrir un autre monde que le banal CPYSPLF et c'est autrement plus sécurisant. On se casse les dents une fois ou deux dessus et ensuite on ne jure plus que par elles, c'est garanti !

La "méthode" CPYSPLF, c'est de l'artisanat qui relève de l'amateurisme. Ce n'est pas professionnel.

[Bizounett]

Salut Mercure,

Je suis d'accord avec toi, mais ou puis-je trouver de l'informations sur les APIs et comment les utiliser avec du CL ? Si su as des exemple et des sites de références la dessus je suis preneur.

Merci

Bizz

[Mercure]

On utilise parfois le CL mais en général on crée un programme RPG lorsqu'on veut utiliser des APIs car c'est plus commode pour les manipuler que le CL.

En pièce jointe, voici un exemple de programme RPG ILE (chkjobname.zip) que j'ai glané sur la toile et ajusté il y a quelques lunes. Il correspond à ce que tu recherches, c'est à dire savoir si un job particulier est actif dans le système.

Dans cet exemple, on utilise 3 APIs très répandues dans les services informatiques : QUSLJOB, QUSCRTUS et QUSPTRUS.

Le programme attend 2 paramètres :

1. un booléen pour savoir si le nom du job indiqué en deuxième paramètre est trouvé (actif) dans le système. Il prend la valeur '1' si le job est trouvé et '0' dans le cas contraire.
   
2. le nom du job à rechercher sur 10 caractères.

Tu pourras l'appeler dans un CL de cette façon :

Code :

1
2
3
4
5
6
DCL &TROUVE *LGL '0'
DCL &NOMJOB *CHAR 10 'NOMDUJOB'
CALL CHKJOBNAME ( &TROUVE &NOMJOB )
IF ( &TROUVE ) DO /* Le job est déjà actif */
  .....
ENDDO

Tu dois évidemment compiler le programme RPG CHKJOBNAME, par PDM ou autre méthode, dans une bibliothèque qui sera en ligne lorsque tu exécuteras le CL.

[Bizounett]

Merci,

Peux-tu m'indiquer comment programmer en RPG sur le 400 ? Je veux dire par la comment écrire ce programme en PRG et comment le compiler ? Je suis programmeur mais sur le 400. Le CL j'ai dû chercher pas à peut près pour savoir ou allez pour écrire et compiler puis l'utiliser.

Merci d'avance

Bizz

[Mercure]

Tu n'as rien à programmer.

Sur l'AS400, crée le fichier source MABib/QRPGLESRC longueur 112

Code :

CRTSRCPF FILE(MaBib/QRPGLESRC) RCDLEN(132)

Tu télécharges la pièce jointe sur ton PC, tu la dézippes et la tranfères par FTP dans le fichier MaBib/QRPGLESRC, membre CHKJOBNAME :

Mets-toi en mode console et tape :

Code :

1
2
3
4
5
6
7
FTP MonAS400
user
mot de passe
LCD Répertoire Du Programme sur PC
SEND CHKJOBNAME.RPGLE MaBib/QRPGLESRC.CHKJOBNAME
QUIT

Reviens sur l'AS400 et via PDM, compile le programme RPG par l'option 14 dans la bibliothèque objet de ton choix.

Une fois compilé, crée ou adapte ton CL comme je te l'ai indiqué précédemment, en insérant le CALL du programme RPG.