Vous installez de nouveaux PCs et vous désirez savoir les ports à ouvrir pour pouvoir accéder à vos partitions IBMi.

Voici une liste de ports à ouvrir en priorité

Pour ACS :


23 requis TELNET
449 requis arborescence du serveur IBM i
8470 à 8476 (voir RDI)

Pour RDi :


446 Requis (DRDA : connecteur base de données entre serveurs)
449 (as-srvmap) requis arborescence du serveur IBM i
3825 (Debugger) : débogage RDi
4300 (STRRSESVR) débogage via RDi (permet le rappel par l’IBM i du client RDi)
8470 (as-central) requis : Gestion des licences
8471 (as-database) requis base de données
8472 (as-dtaq) requis : serveur de file d’attente de données
8473 (as-file) requis : serveur de fichiers
8474 (as-netprt) serveur d’impression réseau
8475 (as-rmtcmd) requis : envoi de commandes
8476 (as-signon) requis : serveur ouverture de session

Merci à Jean-Marie pour son aide !

Qu’est-ce que Ansible ?

Ansible est un outil écrit en Python qui permet de faire des déploiements.

Ansible se sert de deux fichiers de configuration pour fonctionner.

Le premier est l’inventory, il regroupe les adresses réseau des machines qu’on souhaite gérer.

Le second est un playbook, il agit comme un script qu’on pourra exécuter sur n’importe laquelle des machines de l’inventory.

Tous les fichiers de configuration d’Ansible sont au format YAML.

À partir de ces deux fichiers Ansible établit des connexions SSH sur les machines de notre choix (depuis l’inventory), transfert le playbook sur les machines connectées, l’exécute et enfin fait remonter les résultats.

Cette approche permet de facilement réaliser n’importe quel type de déploiement à petite comme à grande échelle en écrivant un seul script, et en utilisant une seule commande.

Les résultats et les erreurs (si il y en a) sont tous remontés une fois que tout est fini.


Ansible est écrit en Python et l’utilise également pour exécuter les playbooks sur les machines, il faut donc que ce dernier soit installé sur les systèmes où l’on veut faire des déploiements.

Les actions qu’on peut demander à Ansible de réaliser sont des modules, qui permettent de réaliser une tâche spécifique.

Chaque tâche dans le playbook utilise un module, et on peut ajouter autant de tâches qu’on a besoin, comme dans un script.

Parmi les modules fournis avec Ansible on peut par exemple exécuter des commandes shell, manipuler des fichiers, en télécharger, etc.

L’intérêt du fonctionnement par modules c’est que tout le monde peut en écrire et on peut utiliser ceux qui sont publiés sur Ansible Galaxy par la communauté.

Cette plateforme regroupe des centaines de collections, qui contiennent un ou plusieurs modules. Il en existe déjà pour énormément de services et applications de toutes sortes (bien trop pour tous les citer ici).

Il y a également des collections fournies par IBM pour interagir avec leurs systèmes, notamment l’IBM i avec la collection power_ibmi.


Pour réaliser des plus petites tâches rapidement il est possible d’exécuter des commandes dites ad hoc. L’exécution sera la même qu’avec un playbook, sauf qu’il n’y aura pas besoin de créer un playbook, à la place on donne les paramètres du module directement dans la ligne de commande.

Cette méthode est très utile pour des actions simples et moins fréquentes, par exemple pour redémarrer toutes les machines d’un inventory.

Quelques exemples simples

Voici à quoi ressemble un inventory très simple qui liste deux machines (machineA et machineB).

all:
    hosts:
        machineA:
            ansible_host: 10.0.0.1
        machineB:
            ansible_host: 10.0.0.2
    vars:
        ansible_ssh_user: root

La partie vars permet de donner des paramètres supplémentaires pour les connexions SSH et l’exécution des modules.

Le paramètre ansible_ssh_user permet d’indiquer en tant que quel utilisateur Ansible doit se connecter par SSH, ici nous serons root.


Voilà désormais un playbook très simple également qui ne fait qu’un simple ping, cela permet de vérifier si Ansible peut se connecter aux machines et exécuter un playbook.

- name: playbook ping
  gather_facts: no
  hosts: all
  tasks:
  - ping:

Le paramètre gather_facts est par défaut configuré sur yes. Le gather facts récupère des informations sur le système où le playbook s’exécute (système d’exploitation, environnement, versions de Python/Ansible, etc) qu’on peut ensuite utiliser dans le playbook ou afficher. Ici on ne souhaite faire qu’un ping pour vérifier qu’Ansible fonctionne bien, on peut désactiver le gather facts puisqu’on ne s’en sert pas.

Le paramètre hosts permet d’indiquer sur quels machines de l’inventory ce playbook doit être exécuté par défaut.

Le paramètre tasks liste chaque tâche à exécuter (avec le nom du module). Ici on utilise le module ansible.builtin.ping qu’on peut abréger en ping.


Pour exécuter ce playbook on utilise la commande ansible-playbook -i inventory.yml playbook.yml (en remplaçant bien entendu les noms des fichiers par ceux que vous avez).

Voici le résultat qu’on obtient avec l’inventory et le playbook précédents :

$ ansible-playbook -i inventory.yml ping.yml

PLAY [playbook ping] *****************************************************************

TASK [ping] **************************************************************************
ok: [machineA]
ok: [machineB]

PLAY RECAP ***************************************************************************
machineA  : ok=1  changed=0  unreachable=0  failed=0  skipped=0  rescued=0  ignored=0
machineB  : ok=1  changed=0  unreachable=0  failed=0  skipped=0  rescued=0  ignored=0

Ansible nous rapporte que la tâche ping a réussi sur les deux machines. La partie PLAY RECAP résume les résultats de toutes les tâches.


L’équivalent de ce playbook en mode Ad Hoc est la commande :

$ ansible -i inventory.yml -m ping all

Le dernier paramètre all correspond au paramètre hosts du playbook, il indique d’exécuter la commande sur tous les hôtes présents dans l’inventory.

Le paramètre -m ping indique quel module utiliser (la documentation sur les commandes ad hoc est disponible ici).

Commande ad hoc de ping

Ansible for i

IBM fournit la collection power_ibmi qui contient beaucoup de modules pour interagir avec les IBM i, la documentation se trouve ici, et la référence des modules ici.

Cette collection est d’ailleurs disponible sur Github ici (avec plusieurs exemples et autres ressources).


Voici un exemple de playbook qui utilise cette collection, plus particulièrement le module ibmi_sysval. Ce playbook va récupérer une valeur système puis faire une assertion de sa valeur.

- hosts: all
  gather_facts: no
  collections:
   - ibm.power_ibmi

  tasks:
  - name: Vérification CCSID
    ibmi_sysval:
      sysvalue:
        - {'name': 'qccsid', 'expect': '1147'}

Le paramètre collections indique qu’il faut d’abord chercher le module ibmi_sysval dans les collections énumérées (dans l’ordre) mais cette partie est optionnelle (comme indiqué dans la documentation ici).

Puis on indique que l’élément nommé qccsid dans la variable de retour sysvalue doit correspondre à la valeur 1147.

Voilà le résultat qu’on obtient lorsque la valeur système correspond :

$ ansible-playbook -i inventory.yml assert_ccsid.yml

PLAY [all] ***************************************************************************

TASK [Vérification CCSID] ************************************************************
ok: [machineA]
ok: [machineB]

PLAY RECAP ***************************************************************************
machineB : ok=1  changed=0  unreachable=0  failed=0  skipped=0  rescued=0  ignored=0
machineA : ok=1  changed=0  unreachable=0  failed=0  skipped=0  rescued=0  ignored=0

Et si le QCCSID ne correspond pas Ansible affiche une erreur à la place de ok: [machine], au format JSON :

fatal: [machineA]: FAILED! =>
{
	"changed": false,
	"fail_list": [{
		"check": "equal",
		"compliant": false,
		"expect": "1147",
		"msg": "Compliant check failed",
		"name": "QCCSID",
		"rc": -2,
		"type": "10i0",
		"value": "65535"
	}],
	"message": "",
	"msg": "non-zero return code when get system value:-2",
	"rc": -2,
	"stderr": "non-zero return code when get system value:-2",
	"stderr_lines": ["non-zero return code when get system value:-2"],
	"sysval": []
}

Note: Dans le terminal cette erreur est souvent affichée sans indentation ni retours à la ligne.

Ici on peut voir que l’assertion a échoué, la valeur système était 65535, mais le playbook s’attendait à ce qu’elle soit 1147.


Il y a de nombreux autres cas d’usage, plusieurs exemples sont disponibles sur le dépôt Github ansible-for-i.

Il y a quelques exemples pour des utilisations spécifiques ici, et d’autres exemples de playbooks ici.

Interfaces graphiques : AWX et Tower

Ansible est un outil qui s’utilise dans le terminal, mais il existe deux solutions qui fournissent une interface graphique plus intuitive en plus d’autres fonctionnalités (planification de tâches, gestion de plusieurs utilisateurs et de leurs droits, notifications).

Ces deux solutions sont AWX et Tower, les deux sont très similaires : AWX est un projet open-source (disponible ici), et Tower (disponible ici) est une solution qui est basée sur AWX mais qui nécessite une licence.

La principale différence entre les deux est que Tower subit beaucoup plus de tests pour être plus stable et vous pouvez recevoir de l’aide du support technique Red Hat si besoin. AWX en revanche est moins testé et donc plus susceptible de rencontrer des instabilités, il n’y a également pas de support technique pour AWX.

Si la stabilité est une nécessité (comme en environnement de production) mieux vaut s’orienter vers Tower.

AWX est compatible sur Linux (les distributions les plus populaires devraient toutes le faire fonctionner), Tower est également compatible sur Linux mais est beaucoup restreint. Actuellement ce dernier n’est compatible que sur Red Hat Enterprise Linux (RHEL), CentOS et Ubuntu.


Nous avons testé AWX sur Debian (Bullseye), l’installation peut être assez compliquée lorsqu’on découvre AWX et son environnement mais son utilisation est plutôt intuitive.

L’interface et le fonctionnement de Tower sont quasiment identiques à AWX.

Dashboard AWX

Il y a plusieurs différences dans la manière d’utiliser Ansible dans le terminal et depuis AWX.

La configuration des machines, de leurs identifiants et des inventory est similaire et très facile. En revanche pour les playbooks ce n’est pas la même méthode.


Premièrement on doit configurer un projet. Un projet est un groupe d’un ou plusieurs playbooks sous la forme d’un dépôt Git ou d’une archive.

Paramètres d’un projet

Ensuite il faut créer des templates, une template peut être considérée comme la commande pour exécuter un playbook : on choisit quel playbook exécuter depuis un projet, on choisit sur quel inventory l’exécuter et les identifiants à utiliser pour les connexions SSH sur les machines de l’inventory.

Paramètres d’une template

On peut ensuite exécuter les templates et suivre leurs avancements et résultats dans l’onglet Jobs ou depuis la page de la template.

Dans l’onglet des templates on peut aussi créer des workflows, un workflow permet d’exécuter plusieurs templates à la suite en y ajoutant des conditions.

On peut choisir d’exécuter certaines templates si une autre réussit, et d’autres si elle échoue.

Éditeur des workflows

Ressources et liens utiles pour apprendre Ansible

Cette courte présentation vise à vous faire découvrir Ansible et ne couvre donc que les bases (beaucoup de détails ont été omis pour éviter la surcharge d’informations). Ansible est un outil très complet et il existe de nombreuses ressources pour apprendre à le prendre en main et le maîtriser.

En voici quelques unes pour bien débuter :


Ansible est un outil très puissant aux applications nombreuses, et peut notamment faciliter l’administration des IBM i (surtout à grande échelle). Malheureusement il n’existe à l’heure actuelle aucune solution clé en main, apprendre à utiliser Ansible et créer ses propres playbooks est indispensable.

Cet apprentissage peut prendre du temps sans expérience préalable avec les environnements Unix et/ou Python. Mais si Ansible peut paraître difficile à prendre en main et maîtriser, des solutions plus guidées et faciles d’accès pourraient arriver à l’avenir, permettant à tous d’utiliser Ansible à son plein potentiel sans avoir à le maîtriser chaque aspect.

, , Utilisation d’une remote DTAQ

Une DTAQ est une solution qui permet de gérer des entrées empilées de manière asynchrone (un peu comme MQ series qui lui est en plus multi systèmes)

Pour définir une remote outq

Cette technologie se base sur DRDA, c’est la solution qui est utilisée par SQL quand vous faites un CONNECT sur une base de données distante.

Sur le système source

Vous devez définir votre base de données par la commande WRKDBDIRE

ADDRDBDIRE RDB(‘Nom_base_de donnees’)
RMTLOCNAME(‘nom ou adresse IP’ IP) RMTAUTMTH(USRID *NOALWLOWER)

Vous devez indiquer,
l’adresse IP ou le nom IP résolu
le mode de connexion qui sera négocié à l’établissement de celle ci

Vous devez créer une dtaq remote

CRTDTAQ DTAQ(Nom_bib_loc/Nom Dtaq)
TYPE(DDM) RMTDTAQ(nom_bib_dis/Nom_Dtaq) RMTLOCNAME(RDB)
RDB(‘Nom_base_de_donnees’)

Sur le système cible

Vous devez créer une dtaq locale

CRTDTAQ DTAQ(Nom_bib_dis/Nom Dtaq)
TYPE(*DDM)
MAXLEN(longueur_de_vos_données)

si vous avez choisi une solution de connexion à base de profil, vous devez l’enregistrer en créant un poste d’authentification

ADDSVRAUTE USRPRF(*CURRENT) SERVER(NEPTUNE) USRID(PLB) PASSWORD()

Vous devez indiquer l’utilisateur local qui servira à faire la requête d’écriture.

Pour voir les postes existants, vous avez une vue SQL

SELECT *
FROM QSYS2.DRDA_AUTHENTICATION_ENTRY_INFO

le service DDM doit être démarré

STRTCPSVR *DDM

Pour écrire dans votre DTAQ

Sur la source, vous devez écrire des postes à la demande

Par L’API

Call QSNDDTAQ

Par la procédure SQL service, depuis le niveau 4 de la TR en 7.4

QSYS2.SEND_DATA_QUEUE()

sur la cible,

Pour écrire lire votre DTAQ

Vous devez avoir un traitement qui boucle pour traiter vos entrées

par l’API

Call QRCVDTAQ

Par la fonction SQL service, depuis le niveau 4 de la TR en 7.4

QSYS2.RECEIVE_DATA_QUEUE()

Conclusions


Vous pouvez mettre en place une solution de remote outq, pour répliquer des changement de mots passe par exemple !

Si vous utilisez des DTAQ, vous aurez besoin d’une commande pour visualiser le contenu de celle ci, vous pouvez en trouver un ici c’est la commande DSPDTAQ

https://github.com/Plberthoin/PLB/tree/master/GTOOLS

, Afficher un panel de groupe

Voici un dernier poste sur la série UIM , pour vous aider à tester vos panneaux de groupe

il existe une API QUHDSPH pour faire cet affichage

Vous trouverez une exemple, une commande DSPPNLGRP ici

https://github.com/Plberthoin/PLB/tree/master/GTOOLS

.

.

Vous pouvez maintenant créer un

Un menu UIM

Convertir un menu SDA en UIM

Générer un squelette d’aide pour vos commandes

Et tester votre panneaux d’aide

Vous pouvez allez plus loin , en apprenant le langage UIM et ses subtilités.

, , Réplication de mot de passe

Vous avez plusieurs partitions et vous voulez toutes les mettre à jour quand vous changez votre mot de passe.

Voici une méthode qui peut vous aider

1) Extraction du hash du mot de passe

Vous pouvez utiliser l’API, QSYRUPWD.
Voici un exemple RTVUSRPWD
Vous pouvez trouver les sources ICI,
https://github.com/Plberthoin/PLB/tree/master/GTOOLS

2) Envoi des informations du hash

Réplication des informations de hash par exemple avec une remote dtaara, remote dtaq ou envoi de celle ci par SAVRSTOBJ dans une dtaara ou un fichier.

3) Application du hash sur le nouveau profil

Vous pouvez utiliser l’API, QSYSUPWD
Voici un exemple CHGUSRPWD
Vous pouvez trouver les sources ICI,
https://github.com/Plberthoin/PLB/tree/master/GTOOLS

4) Automatisation

Vous pouvez ensuite automatiser la détection de vos modifications en utilisant un programme d’exit ou les journaux d’audit.

, , Mise à jour de produits open-source depuis l’interface 5250

Les produits open-source sur IBM i sont gérés par un gestionnaire de paquet qui s’appelle yum :

Sur ACS il est possible de gérer ces produits en sélectionnant l’option Gestion de modules open source depuis le menu Outils :

Cette interface a ses limites et ne permet pas d’automatiser la recherche et l’installation des mises à jour de vos produits open-source.

Voilà le but de GOPEN, qui est disponible ici sur Github.

GOPEN fournit une interface en 5250 pour gérer les mises à jour des produits open-source.

Après paramétrage d’une adresse email pour recevoir toutes les notifications de GOPEN vous pourrez commencer par ajouter des produits open-source à surveiller. Lorsque des mises à jour seront disponibles pour un ou plusieurs des produits surveillés vous recevrez un email résumant tous les produits à mettre à jour en pièce jointe (fichier CSV).

Note : Les produits à surveiller n’ont pas besoin d’être le nom complet du produit, par exemple pour surveiller les mises à jour des produits NodeJS qui a un produit par release (nodejs12 et nodejs14) vous pouvez simplement surveiller nodejs. Toutes les versions installées de NodeJS qui pourront être mises à jour seront incluses.

Pour effectuer ces mises à jour il ne reste qu’à retourner sur l’interface 5250 et choisir l’option qui vous convient pour effectuer les mises à jour disponibles.

Il y a une option pour effectuer toutes les mises à jour disponibles parmi les produits surveillés, vous pouvez également choisir quels produits mettre à jour parmi ceux qui peuvent l’être pour un contrôle plus fin.

Il est possible aussi de demander la mise à jour de produits en mode batch, ou de procéder à toutes les mises à jour disponibles pour tous les produits (y compris ceux qui ne sont pas surveillés).

Dans tous les cas lorsque des mises à jour sont effectuées avec GOPEN vous recevrez un email résumant tous les changements apportés (cela permet de savoir lorsque des dépendances sont mises à jour en même temps que les produits eux-mêmes).

Pour automatiser la recherche de mises à jour et leur application, vous pouvez planifier des tâches depuis le 5250 à la fréquence qui vous convient avec la commande wrkjobscde :

  • La commande RTVLSTUPD fait la recherche des mises à jour et envoie un email résumant les mises à jour disponibles parmi les produits surveillés. Il est possible de lui donner le paramètre silent avec la valeur de '1' pour ne pas envoyer d’email suite à la recherche.
  • La commande UPDPKG fait les mises à jour qu’on lui demande. Elle accepte différents paramètres :
    1. *ALL pour effectuer toutes les mises à jour disponibles (y compris des produits qui ne sont pas surveillés)
    2. *LSTPKG pour effectuer les mises à jour disponibles des produits surveillés
    3. Le nom du produit directement. N’importe quel autre paramètre sera utilisé comme nom de produit et donné à la commande de yum update

Pour résumer, GOPEN vous permet de gérer les mises à jour de vos produits open-source à partir d’une interface familière en 5250 et également d’automatiser ce processus.

Grâce à sa flexibilité il est possible de tout automatiser (recherche et application des mises à jour) à la fréquence de votre choix, ou de laisser certaines actions manuelles (recherche de mises à jour automatique, mais application manuelle).



L’open-source est un passage obligatoire pour vos orientations futures et GOPEN vous fournit une solution pour faciliter l’apprentissage de ces nouvelles approches.

, Convertir un menu SDA en UIM

Suite de nos articles sur UIM

On a vu comment générer une structure d’aide à partir d’une commande, comment générer un menu en UIM, cette troisième partie vous fournira un outil (CVTMNUUIM) pour migrer un menu SDA classique en UIM. il est disponible ici https://github.com/Plberthoin/PLB/tree/master/GTOOLS/
Pour standardiser vos menus et les faire bénéficier de la puissance du langage UIM !

1) Génération du source UIM

On part du fichier message pour régénérer les commandes associées aux options
On ne sait pas récupérer de manière simple le texte de l’option, celle ci étant dans un source DDS (si vous l’avez…)

On met donc comme texte la commande à exécuter, vous pourrez donc éditer le source pour changer le texte affiché

2) Compilation du source

CRTMNU MENU(GAIA/GMODERN) TYPE(*UIM) SRCFILE(GAIA/QMNUSRC)

3) Lancement

Go gaia/gmodern

, , Créer un menu UIM

Voici un 2ème post d’une série consacré à UIM (User Interface Manager).

Ce langage peut vous permettre de réaliser des menus standards IBM, en effet tous les menus sont codés en ce langage !

Vous allez devoir saisir un code source au format UIM puis le compiler.
Ça peut être fastidieux à réaliser, c’est pourquoi nous avons réalisé un outil (CRTMNUUIM) qui va vous permettre de réaliser un menu sans aucune compétence dans ce langage.

Vous pouvez le retrouver ici https://github.com/Plberthoin/PLB/tree/master/GTOOLS/

1) Génération du source du menu

vous pouvez indiquer jusqu’à 10 commandes

Exemple

CRTMNUUIM MENU(GAIA/MONMENU)
FICHIER(GAIA/QMNUSRC)
SOCIETE(GAIA)
TITRE(‘Gestion Spools’)
OPTION1(‘Gestion Spools’)
COMMANDE1(WRKSPLF)
OPTION2(‘Gestion Outqs’)
COMMANDE2(‘?WRKOUTQ’)

Si vous avez quelques compétences malgré tout, vous pouvez éditer le source ici MONMENU du fichier source QMNUSRC, en complétant par exemple les aides !

2) Vous pouvez ensuite compiler le menu en indiquant que vous avez un source UIM

CRTMNU MENU(GAIA/MONMENU) TYPE(*UIM) SRCFILE(GAIA/QMNUSRC)

3) Vous avez alors un menu identique à tous les menus IBM

Pour le lancer
GO MENU(MONMENU)

, , Ajouter de l’aide à vos commandes

Vous créez des commandes et vous voudriez leur ajouter de l’aide, ces aides sont écrites dans un langage UIM (User Interface Manager) qui vous permet de générer des panneaux d’aide que vous pouvez ensuite ajouter à vos commandes.
Le langage UIM est un langage de présentation un peu similaire à HTML, il existe de nombreux sites pour l’apprendre.
Pour les commandes, il existe une commande IBMi qui permet de générer une structure qui vous permettra de vous concentrer sur le texte à mettre sans avoir de connaissance approfondie du langage UIM.

Nous avons fait un outil que vous pouvez trouver ici https://github.com/Plberthoin/PLB/tree/master/GTOOLS/
qui vous permettra d’automatiser la génération votre source et voici ce que vous devrez faire ensuite

1) Génération du source en utilisant notre outil

GTOOLS/GENCMDUIM COMMANDE(GTOOLS/SCANSRC)
FICHIER(GTOOLS/QPNLSRC)

2) Modification du source

Vous devez customiser votre source en indiquant vos spécificités

3) Compilation du panel de groupe

CRTPNLGRP PNLGRP(GREFER/SCANSRC)
SRCFILE(GREFER/QPNLSRC)

4) Association de l’aide à la commande

CHGCMD CMD(GREFER/SCANSRC)
HLPPNLGRP(GREFER/SCANSRC)
HLPID(*CMD)

5) Tester votre commande

==>SCANSRC puis <F4> et <F1>

Quelques sites pour vous aider

https://www.rpgpgm.com/2017/02/creating-help-text-using-uim.html

https://www.volubis.fr/news/liens/AF4SRC/ANIMTXT/UIM.htm

https://larreya.pagesperso-orange.fr/as400/hlphlp.html

Tester les paramètres en CLP

Comment traiter le passage de paramètres en CLP ?

Le principe est le suivant, les paramètres sont passés dans l’ordre et si vous utilisez la zone associée, vous devez l’avoir reçu

Voici 2 méthodes pour vous aider à tester vos paramètres :

La première solution est disponible depuis la version 7.3

Vous avez une nouvelle fonction qui est %parm

exemple

pgm (&parm1 &parm2 )
dcl &parm1 *char 10
dcl &parm2 *char 10
dcl &nbparm *dec 3
dcl &nbparma *char 3
/* test paramètre */

chgvar &nbparm %parms

/* nombre de paramètres */

if cond(&nbparm < 1) then(do)

SNDUSRMSG MSG(‘Paramètre &parm1 non reçu’) MSGTYPE(INFO)
return
enddo
if cond(&nbparm < 2) then(do)
SNDUSRMSG MSG(‘Paramètre &parm2 non reçu’) MSGTYPE(INFO)

return

enddo

/* pour afficher le nombre de paramètres */
chgvar &nbparma &nbparm
SNDUSRMSG MSG(‘Nombre de paramètres’ *bcat &nbparma ) MSGTYPE(*INFO)
endpgm

La deuxième solution est historique il faut traiter le message MCH3601

Exemple :

pgm (&parm1 &parm2 )
dcl &parm1 *char 10
dcl &parm2 *char 10
/* test paramètre /

/* si paramètres non passés on sort */

chgvar &parm1 &parm1

monmsg MCH3601 exec(do)

SNDUSRMSG MSG(‘Paramètre &parm1 non reçu’) MSGTYPE(INFO)
return
enddo
chgvar &parm2 &parm2
monmsg MCH3601 exec(do)
SNDUSRMSG MSG(‘Paramètre &parm2 non reçu’) MSGTYPE(*INFO)
return
enddo
endpgm