On se demande souvent comment gérer les paramètres de compile sur les PRTF et les DSPF, il existe plusieurs solutions comme créer des CL de compile par exemple, ou utiliser des ALM qui intègrent cette possibilité. Mais comment faire pour que ca marche tout le temps sans avoir à modifier les commandes de compile
Voici une solution qui a été mise au point pour nos clients du centre de service.
On va utiliser le programme d’exit QIBM_QCA_CHG_COMMAND qui, à chaque fois qu’il verra un CRTPRTF l’interceptera.
Pour éviter que cela ne boucle on devra dupliquer la commande CRTPRTF dans une autre bibliothèque et renvoyer sur celle de QSYS quand on aura fait le paramétrage complémentaire.
Cette bibliothèque devra donc être devant QSYS dans la liste des bibliothèques, imaginons que cette bibliothèque s’appelle GDDS.
CHGSYSLIBL LIB(GDDS)
soit DSPLIBL
dans le source de votre PRTF vous allez indiquer des lignes commençant par A*<COMP> et terminées par </COMP>
+ votre mot clé exempleSAVE(*YES) Vous pouvez indiquer plusieurs paramètres sur une seule ligne.
Nous avons 2 programmes que vous pouvez retrouver ici, il vous suffit des les compiler et de les ajouter à la bibliothèque GDDS que vous avez placée en tête de liste
Vous avez donc dans votre bibliothèque 2 programmes et une duplication de la commande CRTPRTF et (du CRTDSPF si vous l’ajoutez)
RTVMBRSRC qui va retrouver à partir de la commande le membre source à compiler GDDS qui prendra la commande et qui lui ajoutera les informations lues dans le fichier source c’est ce programme qu’on devra ajouter au programme d’exit comme ceci : ADDEXITPGM EXITPNT(QIBM_QCA_CHG_COMMAND) FORMAT(CHGC0100) PGMNBR(92) PGM(GDDS/GDDS) TEXT(‘Paramétrage GDDS’) PGMDTA(*JOB 20 ‘CRTPRTF GDDS ‘)
Attention au paramètre PGMDTA, la commande fois faire 10 de long pour que le système la trouve
Vous avez un programme CLLE INITGDDS qui peut vous aider dans le répertoire CLP
==>WRKREGINF QIBM_QCA_CHG_COMMAND puis option 8
Avec cette commande, on prendra en compte désormais les CRTPRTF. A partir de ce moment là, quand vous passerez la commande CRTPRTF, vos paramètres indiqués dans le sources seront ajoutés à la commande.
Par exemple en demandant l’invite sur la commande : CRTPRTF FILE(GDATA/PRTF198) SRCFILE(GDATA/QDDSSRC) SRCMBR(*FILE) Vous aurez vos paramètres
Remarque : Vous pouvez indiquer un programme d’exit pour les DSPF (CRTDSPF), et même si vous avez encore quelque PF (CRTPF), les LF (CRTLF) Bien sûr, tous les mots clés que vous indiquez doivent syntaxiquement être justes et correspondre au type de fichier que vous créez. Cette solution marche en interactif, en batch, par RDI et par Vs Code, dans vos CL de compile etc …
https://www.gaia.fr/wp-content/uploads/2017/02/team3.png600600Pierre-Louis BERTHOIN/wp-content/uploads/2017/05/logogaia.pngPierre-Louis BERTHOIN2023-03-07 05:34:002023-03-07 14:28:16Comment gérer les options de compile des PRTF
Egalement appelée clés étrangères, c’est une approche data centrique pour gérer les dépendances des données entre les tables de votre base de données.
Prenons un exemple :
Une commande ne peut pas avoir un client qui n’existe pas et à l’inverse, vous ne pouvez pas supprimer un client qui a encore des commandes
Jusqu’à maintenant, on avait tendance à laisser gérer cette dépendance à l’application, ce qui immanquablement créait des orphelins, qu’on devait corriger par des programmes de contrôle
Il existe donc une alternative c’est de demander à SQL de gérer cette dépendance, c’est l’approche data centrique, voyons comment
Dans la bibliothèque PLB nous allons créer 2 tables
tclients pour les clients
CREATE TABLE PLB.TCLIENTS ( NUMERO CHAR(6) CCSID 1147 NOT NULL DEFAULT » , NOM CHAR(30) CCSID 1147 NOT NULL DEFAULT » )
ALTER TABLE PLB.TCLIENTS ADD CONSTRAINT PLB.Q_PLB_TCLIENTS_NUMERO_00001 PRIMARY KEY( NUMERO )
Cette table doit impérativement avoir une clé primaire sur la clé que vous voulez contrôler ici NUMERO
tcommande pour les commandes
CREATE TABLE PLB.TCOMMANDE ( NUMERO CHAR(6) CCSID 1147 NOT NULL DEFAULT » , NUMEROCDE CHAR(6) CCSID 1147 NOT NULL DEFAULT » , DESCRCDE CHAR(30) CCSID 1147 NOT NULL DEFAULT » )
ALTER TABLE PLB.TCOMMANDE ADD CONSTRAINT PLB.Q_PLB_TCOMMANDE_NUMEROCDE_00001 UNIQUE( NUMEROCDE ) ;
On ajoute une clé sur le numéro de commande qui ne sert pas pour la contrainte, mais qui logiquement serait présente pour identifier votre commande
Mise en Œuvre
Pour ajouter votre contrainte vous avez 2 solutions
ALTER TABLE PLB.TCOMMANDE ADD CONSTRAINT PLB.Q_PLB_TCOMMANDE_NUMERO_00001 FOREIGN KEY( NUMERO ) REFERENCES PLB.TCLIENTS ( NUMERO ) ON DELETE RESTRICT ON UPDATE RESTRICT ;
Vous fixez une action sur le fichier parent, en cas de non respect de la règle posée, le plus souvent on met RESTRICT qui interdira l’opération. Vous pouvez regarder les autres actions pour voir , attention à *CASCADE qui peut être très brutal …
En ajoutant votre contrainte, vous pouvez avoir ce message qui indique que des valeurs ne respectent pas la régle de contrôle énoncée
Message . . . . : Les valeurs de clé de la contrainte référentielle sont incorrectes.
Cause . . . . . : La contrainte référentielle Q_PLB_TCOMMANDE_NUMERO_00001 du fichier dépendant TCOMMANDE, bibliothèque PLB, est en instance de vérification. Le fichier parent TCLIENTS, bibliothèque PLB, possède une règle de suppression de *RESTRICT et une règle de mise à jour de *RESTRICT. La contrainte est en instance de vérification car l’enregistrement 2 du fichier dépendant comporte une valeur de clé étrangère qui ne correspond pas à celle du fichier parent pour l’enregistrement 0. Si le numéro d’enregistrement du fichier parent ou du fichier dépendant est 0, l’enregistrement ne peut pas être identifié ou ne satisfait pas à l’état vérification en instance.
A ce moment la contrainte est active mais vous avez des enregistrements non conformes vous pouvez les voir par WRKPFCST
l’option 6 permet de voir les enregistrements en attente de validation et en erreur
Testons, si vous essayez de créer une commande avec un client qui n’existe pas vous aurez un message de ce type par DFU ou dans un programme RPGLE
Message . . . . : Violation de contrainte référentielle sur le membre TCOMMANDE.
Cause . . . . . : L’opération en cours sur le membre TCOMMANDE, fichier TCOMMANDE, bibliothèque PLB a échoué. La contrainte Q_PLB_TCOMMANDE_NUMERO_00001 empêche l’insertion ou la mise à jour du numéro d’enregistrement 0 dans le membre TCOMMANDE du fichier dépendant TCOMMANDE dans la bibliothèque PLB : aucune valeur de clé correspondante n’a été trouvée dans le membre TCLIENTS du fichier parent TCLIENTS de la bibliothèque PLB. Si le numéro d’enregistrement est zéro, l’erreur s’est produite lors d’une opération d’insertion. La règle de contrainte est 2. Les règles de contrainte sont les suivantes : 1 — *RESTRICT
dans vos programmes RPG vous pourrez par exemple utiliser les fonctions %error()
Maintenant essayons de voir ce qui ce passe dans un programme SQLRPGLE, ce qui est la norme de développement à ce jour
**FREE
// création d'une commande avec un client qui n'existe pas
exec sql
INSERT INTO PLB/TCOMMANDE VALUES('000004', '000007',
'Lunettes bleaues') ;
dsply ('Insert : ' + %char(sqlcode)) ;
// modification d'une commande avec un client qui n'existe pas
exec sql
UPDATE PLB/TCOMMANDE SET NUMERO = '000007' ;
dsply ('Update : ' + %char(sqlcode)) ;
// supression d'un client qui a des commandes
exec sql
DELETE FROM PLB/TCLIENTS WHERE NUMERO = '000001' ;
dsply ('delete : ' + %char(sqlcode)) ;
*inlr = *on ;
Vous pouvez faire un DSPFD exemple : DSPFD FILE(PLB/TCOMMANDE) TYPE(*CST)
Par les vues SQL exemple
SELECT * FROM qsys2.SYSCST WHERE TDBNAME = ‘PLB’ and TBNAME = ‘TCOMMANDE’ and CONSTRAINT_TYPE = ‘FOREIGN KEY’ ;
Vous pouvez les administrer par la commande WRKPFCST exemple : QSYS/WRKPFCST FILE(PLB/TCOMMANDE) TYPE(*REFCST)
Avec l’option 6 vous pourrez par exemple voir les enregistrements en instance de vérification, c’est la commande DSPCPCST, pas de sortie fichier !
Conseil :
C’est une très bonne solution sur vos nouvelles bases de données, mais attention l’ajouter sur des bases de données existantes peut être risqué en effet certain traitements pouvant essayer de bypasser ce contrôle, ou avoir des erreurs présentes sur votre base …
Astuces
Vous pouvez utiliser une contrainte temporaire pour vérifier les orphelins de votre base :
Ajout de la contrainte
DSPCPCST pour voir les erreurs
Retrait de la contrainte
Cette opération doit se faire hors activité utilisateur !
SYSCST La vue SYSCST contient une ligne pour chaque contrainte du schéma SQL. SYSREFCST La vue SYSREFCST contient une ligne pour chaque clé étrangère du schéma SQL. SYSKEYCST La vue SYSKEYCST contient une ou plusieurs lignes pour chaque UNIQUE KEY, PRIMARY KEY ou FOREIGN KEY dans le schéma SQL. Il existe une ligne pour chaque colonne dans chaque contrainte de clé unique ou primaire et les colonnes de référence d’une contrainte référentielle. SYSCHKCST La vue SYSCHKCST contient une ligne pour chaque contrainte de vérification dans le schéma SQL. Le tableau suivant décrit les colonnes de la vue SYSCHKCST. SYSCSTCOL La vue SYSCSTCOL enregistre les colonnes sur lesquelles les contraintes sont définies. Il existe une ligne pour chaque colonne dans une clé primaire unique et une contrainte de vérification et les colonnes de référence d’une contrainte référentielle. SYSCSTDEP La vue SYSCSTDEP enregistre les tables sur lesquelles les contraintes sont définies.
A partir de la version 7.5, vous avez de nouvelles options pour l’administration de NetServer
Vous pouvez par exemple nommer les utilisateurs ayants accès aux partages de votre ibmi.
Vous devez créer une liste d’autorisation, par exemple netserver et pour qu’un utilisateur puisse accéder il faut qu’il aie le droit *use sur cette liste
Création de la liste d’autorisation
*USE droit de lecture
*CHANGE ou *ALL droit de mise à jour
Association de la liste au service Netserver
.
Arrêt redémarrage du service pour prise en compte
.
Si votre utilisateur n’est pas listé dans votre liste
.
Si votre utilisateur est inscrit dans la liste
Vous pouvez aller puis loin en mettant une liste d’autorisations par partage, vous devrez indiquer cette liste au moment où vous créerez le partage
.
le principe est le même mais partage par partage , attention à l’administration qui en découle , vous retrouvez ces informations dans la vue QSYS2.SERVER_SHARE_INFO zone SHARE_AUTHORIZATION_LIST
Exemple de requête pour voir les partages protégés
SELECT SERVER_SHARE_NAME, TEXT_DESCRIPTION, PATH_NAME, SHARE_AUTHORIZATION_LIST FROM QSYS2.SERVER_SHARE_INFO WHERE SHARE_TYPE = ‘FILE’;
Remarque :
donc pour connaitre les utilisateurs qui peuvent faire du netserver vous pouvez utiliser SQL par exemple
SELECT AUTHORIZATION_NAME, OBJECT_AUTHORITY FROM QSYS2.AUTHORIZATION_LIST_USER_INFO WHERE AUTHORIZATION_LIST = ‘NETSERVER’ and AUTHORIZATION_NAME <> ‘*PUBLIC’
https://www.gaia.fr/wp-content/uploads/2017/02/team3.png600600Pierre-Louis BERTHOIN/wp-content/uploads/2017/05/logogaia.pngPierre-Louis BERTHOIN2022-05-25 15:53:292022-07-22 15:19:25Premier pas avec nginx
A partir de la TR6 de la V7R4, vous avez une nouvelle vue qui vous permet de visualiser vos MTIs (Maintained Temporary Indexes) c’est des indexs que le système décide de construire temporairement pour optimiser vos requêtes.
C’est ceux la même qui sont perdus à chaque IPL …
Cette nouvelle vue s’appelle MTI_INFO elle est dans QSYS2
Rappelle : Vous pouviez déjà avoir des informations sur les MTIs en interrogeant index advisor, par exemple dans ACS vous avez cet exemple qui vous indique les MTI utilisés depuis le dernière IPL
https://www.gaia.fr/wp-content/uploads/2017/02/team3.png600600Pierre-Louis BERTHOIN/wp-content/uploads/2017/05/logogaia.pngPierre-Louis BERTHOIN2022-05-06 14:48:132022-05-06 14:48:15Statistiques sur les MTIs
Si vous êtes en convention de nommage *SYS, vous pouvez utiliser la liste de bibliothèques
exec sql call qcmdexc( ‘addlible ‘ concat :votre_lib) ; // select sans bibliothèque exec sql select mazone into : wmazone from matable ;
Si vous êtes en convention de nommage *SQL, vous devez préciser le schéma courant – par défaut c’est le profil utilisateur. // select sans bibliothèque exec sql set schema :votre_lib ;
exec sql select mazone into : wmazone from matable ;
A noter que dans la cas d’une convention de nommage *SQL, toutes vos tables doivent être dans la même bibliothèque, en cas de jointure par exemple
Il existe effectivement une autre alternative avec dynamic SQL,
Merci Birgitta pour cette précision .
Avec dynamic SQL et VALUES … INTO: Exemple: CmdSQL = ‘Values( Select Count(*) from ‘ + %Trim(YourSchema) + ‘.YourTable ‘ + ‘ ) into ?’;
Exec SQL Prepare DynSQL from :CmdSQL; Exec SQL Execute DynSQL using :YourResult;
https://www.gaia.fr/wp-content/uploads/2017/02/team3.png600600Pierre-Louis BERTHOIN/wp-content/uploads/2017/05/logogaia.pngPierre-Louis BERTHOIN2022-02-01 18:12:542022-04-06 10:15:38Préciser la bibliothèque dans un SELECT INTO
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).
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 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 :
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.
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.
/wp-content/uploads/2017/05/logogaia.png00Sébastien C/wp-content/uploads/2017/05/logogaia.pngSébastien C2021-12-09 16:09:482021-12-09 16:09:50Ansible et IBM i
Vous avez sans doute un grand nombre de jobqs sur votre système, mais connaissez-vous réellement celles qui servent ?
Pour connaitre la liste des jobq utilisées, on va consulter les messages CPF11224 qui indiquent le début d’un travail et qui contiennent dans les données la jobq par laquellle ils sont arrivés
J’ai utilisé dans mon exemple de table dans qtemp, vous pouvez utiliser un with si vous préférez
Liste des jobqs utilisées
create table qtemp/lstjobqus as( select distinct cast(substr(message_tokens, 59, 10) as char(10)) as jobq, cast(substr(message_tokens, 69, 10) as char(10)) as jobq_lib FROM TABLE(qsys2.history_log_info(START_TIME => CURRENT TIMESTAMP – 30 days , END_TIME => CURRENT TIMESTAMP)) x where message_id = ‘CPF1124’ ) with data
Liste des jobqs présentes sur le système
create table qtemp/lstjobq as ( SELECT OBJNAME as jobq, OBJLIB as jobq_lib FROM TABLE(QSYS2.OBJECT_STATISTICS(‘ALL’, ‘JOBQ’)) ) with data
Liste des jobqs non utilisées
select a.jobq, a.jobq_lib from lstjobq as a exception join lstjobqus as b on a.jobq= b.jobq and a.jobq_lib = b.jobq_lib
remarque :
Avec cette liste vous pouvez faire du ménage et ne plus démarrer les sous-systèmes inutiles par exemple.