Il y a trois moyens d’exécuter un programme CL à partir d’un programme RPGLE (ou Cobol). Et chacun a ses avantages propres. Méthode classique. Par l’API Execute Command (QCMDEXC).
C’est probablement la méthode la plus courante dans des applications RPG ou
Cobol, en partie parce qu’on l’a proposée aux programmeurs depuis le début, c’est-à-dire l’époque des programmes RPG II. Avantage : elle est simple et facile à comprendre. Inconvénient : il est presque impossible d’obtenir en retour des informations d’erreur. Méthode C.
Par l’API system(). C’est la deuxième méthode la plus courante. Réservée aux programmes ILE, la méthode C est un peu plus simple à coder que QCMDEXC mais, là aussi, il est difficile d’obtenir des informations d’erreur, sauf au moyen de la variable importée _EXCP_MSGID. Le meilleur moyen. Par l’API Process Commands (QCAPCMD). Comme les deux méthodes précédentes, cette API permet d’exécuter une commande.
Mais elle vous permet aussi de valider ou de solliciter une commande, elle renvoie la chaîne de commande complète (y compris les mots-clés pour les paramètres positionnels), et même vous permet d’afficher un texte d’aide de commande. Elle inclut aussi le paramètre d’erreur API QUSEC standard, qui donne davantage d’informations sur les erreurs de commande. A l’évidence, cette méthode est bien plus puissante que QCMDEXC ou system().
Mais elle est utilisée moins fréquemment parce que plus difficile à coder. Compte tenu que QCAPCMD est plus puissante que les deux autres méthodes, son utilisation se justifie particulièrement quand il importe d’extraire des erreurs de commande. Cependant, si vous envisagez d’utiliser QCAPCMD, vous devez trouver le moyen de ne pas ajouter les 30 lignes de code et plus nécessaires pour l’appeler. La solution consiste à avoir une procédure unique appelée cl() dans un programme de service qui est mise dans un répertoire de lien d’utilitaire dans QGPL, à la disposition de tous les programmes.
Ma procédure cl() sert d’enveloppe à l’API QCAPCMD. Comme j’ai beaucoup d’appels plus anciens à system(), je veux que cl() ait la même interface que system() – une chaîne de commande unique passée comme pointeur avec le mot-clé OPTIONS(*STRING) et un code de renvoi entier de quatre octets (10I) qui renvoie 1 si une erreur se produit ou 0 si la commande se termine sans encombre. Cela vous permet de remplacer les appels system() par des appels cl().
Mais j’ai aussi un second paramètre (facultatif) à cl() – la structure QUSEC – qui est passé comme un paramètre I/O. Si ce second paramètre n’est pas passé, cl() appelle system() et retourne le code de renvoi. Si le paramètre QUSEC est passé, cl() appelle QCAPCMD et renvoie la valeur QUSEC à partir de là. Pour télécharger le code, allez à SystemiNetwork .com/code.
Le code de la procédure cl() dans le membre source CMDPRC et le copybook CMDPRC_P et QUSEC_T est inclus, ainsi que le code pour un programme appelé TESTCMDPRC, qui montre plusieurs exemples de la manière d’appeler cl(). Pour plus d’informations sur le processeur Compile, lire « Using a Compile Preprocessor » (www.itpro.fr Club abonnés). – Rory Hewitt Software developer
Dans le contexte actuel, l'expérience client est un levier clé de réussite. Pour rester compétitives, les entreprises doivent adopter des stratégies CX audacieuses, en s'appuyant sur le cloud, le digital et l'IA. Alors quelles stratégies mettre en place pour garder une longueur d’avance ?
