J'essaie de fournir une interface utilisateur dans Access pour afficher l'état des tâches AS400 planifiées, pour les afficher comme en attente, en cours d'exécution ou terminées.
J'ai hérité d'un code qui planifie plusieurs tâches, qui fonctionne bien - mais il n'y a aucun moyen pour l'utilisateur de voir quel est l'état du travail, et ils se bloquent parfois.
L'achèvement est actuellement signalé via un compteur numérique contenu dans les tables que les travaux mettent à jour, et il y a un événement Form Timer qui vérifie régulièrement l'achèvement.
En utilisant cette méthode, le code peut dire quand le traitement sur l'AS400 est terminé, mais pas s'il est bloqué ou échoué, ou si le serveur est lourdement chargé et fonctionne lentement.
J'ai essayé de trouver des exemples de code sur Internet mais j'ai dessiné un blanc . Tout ce que j'ai trouvé qui m'a aidé était le manuel de base de données IBM (pdf et en ligne) et un diaporama pdf intitulé "iSeries Access ActiveX Development" par Troy C Bleeker d'IBM.
En utilisant ces ressources, j'ai écrit quelques code utilisant la bibliothèque d'objets IBM i Access pour Windows ActiveX (cwbx) pour parler à l'AS400 qui fonctionne bien, et je peux émettre la commande WRKUSRJOB pour vérifier les statuts des travaux, mais je ne peux pas comprendre comment (ou même si) c'est possible pour afficher les résultats de la commande.
Y a-t-il un moyen de faire cela, et si oui, comment?
Dim SysNames As New cwbx.SystemNames
Dim SvrName As String
Dim Svr As New cwbx.AS400System
Dim Svc As cwbx.cwbcoServiceEnum
Dim Cmd As New cwbx.Command
Dim x As New cwbx.DataQueue
'Set server name
SvrName = SysNames.DefaultSystem
Debug.Print SvrName
Svr.Define SvrName
'Set service type
Svc = cwbcoServiceRemoteCmd
'Connect and test
Svr.Connect Svc
Debug.Print Svr.IsConnected(Svc)
'Command
Set Cmd.System = Svr
Debug.Print "WRKUSRJOB"
Cmd.Run "WRKUSRJOB"
```
'How to get results of the command? Nothing in Errors
Debug.Print SprintF("Errors: %s", Cmd.Errors.Count)
```
'Tidy up
Svr.Disconnect Svc
'Object destruction
Set Cmd = Nothing
Set Svr = Nothing
Set SysNames = Nothing
Ce serait bien si par exemple la collection Errors contenait les résultats de la commande, ou s'ils pouvaient être redirigés ou redirigés vers un fichier ou une file d'attente pouvant être lu par l'ActiveX, mais je continue de dessiner un espace vide.
Edit: Mon client a La v7r1 est installée et supprime progressivement db2, il n'y a donc aucune possibilité de mise à niveau vers une version plus récente.
3 Réponses :
N'y a-t-il pas une commande pour l'AS400 qui renvoie le statut du travail?
Je ne connais pas as400, mais quelque chose comme WRKACTJOB, ou n'importe quelle commande pour lister les jobs doit exister? Je ne vois aucune raison d'utiliser une API spéciale.
Si vous avez ou pouvez configurer une commande en as400 pour renvoyer le (s) statut (s) du travail, alors en accès, vous pouvez simplement utiliser une requête PT avec cette commande comme texte SQL.
Vous ne savez pas si vous souhaitez interroger un travail spécifique ou simplement afficher tous les travaux? Donc, si vous avez un code ou une commande as400 qui renvoie l'état du travail, placez cette commande dans une requête PT et basez votre formulaire sur cette requête PT. Vous pouvez ensuite ajouter une minuterie pour réafficher toutes les 5 secondes ou ce que vous voulez. En utilisant une requête PT dans Access, alors très peu de code, voire aucun, n'a besoin d'être écrit dans Access.
J'ai déjà essayé mais cela ne fonctionne pas, j'obtiens ODBC - Call Failed, Token WRKACTJOB n'est pas valide. Jetons valides: (END GET SET ... etc. Si cela fonctionnait, ce serait si élégant! Pour répondre à votre question, je recherche plusieurs emplois spécifiques et j'ai le nom d'utilisateur sous lequel ils ont été soumis, ainsi que les noms des travaux.
Eh bien, nous supposons que la requête PT fonctionne pour certaines félicitations? Il doit y avoir une sorte de retour de type SELECT que vous avez pour les travaux actifs.
WRKACTJOB s'attend à avoir un écran vert pour afficher sa sortie, comme toutes les commandes WRK ... CL livrées, donc même si vous l'appelez d'une manière ou d'une autre à partir de SQL, vous ne récupérerez rien d'utile. La réponse de @Charles est la bonne façon d'obtenir l'ensemble de résultats que vous suggérez.
Comme le dit @MandyShaw, WRKACTJOB sort sur l'écran 5250. Si vous souhaitez travailler avec des informations de travail par programme, vous pouvez utiliser les API de la vieille école ou les services Db2 pour i SQL plus récents. Depuis VBA, les services SQL sont les plus simples. L'OP aurait probablement besoin d'un wrapper RPG / COBOL / CL pour fonctionner avec les API
Mais la simple saisie d'une requête ne s'affiche-t-elle pas simplement à l'écran? une requête directe dans Access envoie tout ce que vous tapez à l'invite de commande de toute façon. Donc, si vous pouvez configurer un programme, une commande ou autre, et qu'il renvoie des lignes de données à l'écran, cela est simplement envoyé pour accéder.
Cela dépend entièrement de l'environnement à partir duquel vous exécutez le SQL. Si vous utilisez STRSQL ou STRQMQRY, oui, il apparaîtra sur l'écran vert. Si vous êtes dans un autre environnement, vous obtenez un jeu de résultats avec lequel votre programme peut faire ce qu'il veut. Comme avec toute autre plate-forme de base de données prenant en charge sql. L'OP veut faire un traitement spécifique sur la sortie de leur code, je pense.
Bien sûr, la réponse de Charles ci-dessous car une requête PT d'Access devrait fonctionner correctement - c'est tout mon point.
Ma (nouvelle) compréhension est que seules les fonctions de table et les vues renverront des jeux d'enregistrements à ODBC, donc par exemple ACTIVE_JOB_INFO () et JOB_INFO () - qui sont des fonctions de table - et par exemple JOB_QUEUE_INFO - qui est une vue - fonctionneront. Mais les fonctions standard comme WRKACTJOB ne fonctionneront pas avec une requête relais car elles ne renvoient pas de jeux d'enregistrements à ODBC. Donc, votre réponse allait dans la bonne direction (requête passthrough) mais n'était finalement pas utile car SELECT * FROM WRKACTJOB ne fonctionnera pas, et ni vous ni moi n'en savions suffisamment sur DB2 pour savoir comment y remédier.
Je ne peux plus modifier mon commentaire précédent, juste pour ajouter que la suggestion originale d'Albert était de "simplement utiliser une requête PT avec cette commande comme texte SQL" (donc, pas de SELECT * FROM) - ce qui ne fonctionne pas.
WRKACTJOB est une commande du système d'exploitation IBM i, cela n'a rien à voir avec DB2, je pense que cela peut être la source d'une certaine confusion ici.
Charles post ci-dessous montre une telle sélection - si cette sélection renvoie des données, cette sélection devrait fonctionner parfaitement comme une requête PT depuis Access. La requête PT dans Access envoie uniquement les commandes RAW au système comme si vous les aviez saisies. Pour les commandes qui ne renvoient pas de jeu de données de résultat, ma suggestion ne fonctionnera pas. Si la commande ci-dessous, comme Charles, renverra un ensemble de données valide, alors une telle recommandation peut être "envoyée" depuis Access en tant que requête PT. Le "texte" dans une requête PT depuis Access est envoyé tel quel. Vous pouvez envoyer n'importe quelle commande que vous voulez, mais bien sûr, il doit renvoyer des données pour renvoyer quelque chose d'utile à Access
Merci Mandy, c'est une clarification / distinction utile.
En supposant que vous utilisez une version prise en charge d'IBM i,
Jetez un œil à Db2 for i Services ...
Plus précisément le
QSYS2.ACTIVE_JOB_INFO ()
QSYS2.GET_JOB_INFO ()
exemple:
select *
from table (QSYS2.GET_JOB_INFO('123456/MYUSER/MYJOB')) as X;
Merci Charles, cela semble être une avenue prometteuse - au moins, cela devrait renvoyer un jeu d'enregistrements à ODBC. J'ai essayé d'exécuter SELECT * FROM TABLE (QSYS2.ACTIVE_JOB_INFO ()) X mais j'ai obtenu une erreur: "ODBC - échec de l'appel. [IBM] [System i Access ODBC Driver] [DB2 for i5 / OS ] SQL0204 - ACTIVE_JOB_INFO dans QSYS2 type * N introuvable. (# -204) ". Cela signifie-t-il que nous n'utilisons pas une version prise en charge d'IBM i? Si tel est le cas, existe-t-il un moyen de contourner ce problème en utilisant l'API ou est-ce aussi voué à l'échec?
@Belladonna semble que vous utilisez une version obsolète du système d'exploitation, peut-être la v7.1? Dans ce cas, les API de gestion du travail sont votre seul choix . Vous pourrez peut-être les appeler directement en tant que procédure stockée externe, mais il vous serait beaucoup plus facile de les utiliser si un wrapper RPG / CL / COBOL était créé pour que vous puissiez les appeler.
Merci Charles, un autre pointeur utile. J'ai trouvé un article qui dit que je peux utiliser le syntaxe suivante pour appeler une commande CL: call qsys2.qcmdexc ('STRDBG UPDPROD (* YES)', 20) . C'est la méthode utilisée dans le code dont j'ai hérité, donc je sais que cela fonctionne, ce qui est encourageant. Je pensais que s'il y avait une commande CL pour imprimer la liste des tâches dans un fichier (plutôt que dans la console), je pourrais alors récupérer le contenu du fichier ... mais j'ai du mal à en trouver une dans la documentation. Quelque chose vous vient-il à l'esprit?
Par exemple, ce serait bien si CALL QSYS.QCMDEXC ('WRKUSRJOB USER (XXXXX) OUTPUT (* OUTFILE) OUTFILE (QTEMP / TEST1)', 59) fonctionnait, mais malheureusement WRKUSRJOB ne fonctionne pas autorise la redirection de sa sortie vers un fichier.
Après beaucoup d'essais et d'erreurs, je pense que je l'ai enfin craqué.
La solution consiste à utiliser deux requêtes relais:
CALL QSYS2.QCMDEXC('DSPJOBLOG OUTPUT(*OUTFILE) OUTFILE(XXXXXXXX/TEST1)',50)
SELECT * FROM XXXXXXXX.TEST1
Merci beaucoup pour les suggestions et les pointeurs, en particulier à Charles pour toutes les connaissances détaillées de DB2, et à Mandy pour une clarification cruciale.
@Charles J'ai voté pour votre réponse, mais malheureusement, je n'ai pas encore une réputation suffisamment élevée pour qu'elle soit diffusée publiquement.
Vous devez entrer dans les services tels que décrits par Charles si vous voulez faire plus de choses, cependant, c'est la direction claire d'IBM et je doute que les commandes CL qui manquent de support outile l'obtiennent maintenant.
Merci Mandy, je serais certainement d'accord, et j'aurais adoré utiliser les suggestions de Charles si seulement elles avaient été disponibles sur notre plateforme! Malheureusement, db2 ici est progressivement supprimé sur le site de mon client, donc je dois juste travailler avec ce qu'ils ont. J'ai trouvé quelque chose ce matin qui indique que nous avons v7r1, ce qui aurait du sens étant donné que - frustrant - ACTIVE_JOB_INFO et GET_JOB_INFO ont été ajoutés dans la v7r2.