, Exemples SQL personnalisés sur ACS

Lorsque l’on travaille sur une belle requête SQL, nous avons tendance à la garder et la sauvegarder en local sur notre poste (parfois dans l’IFS). Pour la partager à un collègue quoi de mieux qu’un bon vieux mail ?

Ou alors, on peut exploiter les Exemples personnalisés d’ACS pour mutualiser nos découvertes !

Exemples SQL sur ACS

Via l’Exécuteur de scripts SQL d’ACS, une multitude d’exemples est fournie.
Pour y accéder trois possibilités :

  • Edition > Exemples > Insertion à partir d’exemples…
  • Ctrl + I
  • Via la petite icône SQL avec les deux flèches ci-dessous

On y retrouve tout un catalogue d’exemples relativement bien fourni :

Il suffit de rechercher les mots clés qui nous intéressent puis de cliquer sur Insertion, et enfin de remplacer les données variables de la requête.

Ajouter ses exemples personnalisés

Création d’un répertoire dans l’IFS

La première étape consiste à créer un répertoire commun dans l’IFS, le plus simple est de le créer dans /home/ qui est généralement déjà configuré comme partagé (donc visible pour Windows).
Par la suite nous utiliserons le chemin suivant : /home/exemples_sql/.
C’est ici que nous travaillerons pour créer nos exemples personnalisés.

Création d’un exemple

Il suffit de créer un nouveau source SQL, par exemple via ACS :

-- category: Exemples perso
-- description: Recherche d'un fichier dans l'ifs
SELECT *
  FROM TABLE (
      qsys2.ifs_object_statistics(start_path_name => '/')
  )
 WHERE path_name LIKE '%fichier.txt';

Le commentaire category permet de trier et regrouper vos exemples par usages.
Le commentaire description correspond au texte indiqué dans la liste des exemples.

Une fois l’exemple terminé il suffit de sauvegarder le script dans le répertoire de l’IFS choisi : Fichier > Sauvegarde sous… > Fichier STREAM IFS.

Il est bien entendu toujours possible de modifier ou supprimer des exemples à partir de ce répertoire.

Intégration du répertoire d’exemples à ACS

Dans un onglet d’ACS, ouvrir le menu des exemples : Edition > Exemples > Insertion à partir d’exemples…
Puis cliquer sur Préférences…

Cliquer ensuite sur Ajout

Indiquer ici le chemin vers le répertoire de l’IBM i qui contient les exemples SQL : \\<Nom de l’IBM i>\home\exemples_sql

Les exemples sont maintenant dans la liste avec les autres.
Ils sont triés par catégorie (que l’on retrouve juste en dessous de la mire de recherche).
Ils sont listés en dessus par description et un aperçu est disponible à droite.

Pour retrouver des exemples deux possibilités :

  • Choisir la catégorie à afficher en cliquant sur la catégorie actuelle (ici Exemples perso)
  • Utiliser la mire de recherche, qui affichera les exemples correspondant aux mots clés, toutes catégories confondues

Pour plus de détails

Exemples SQL de Birgitta Hauser : https://gist.github.com/BirgittaHauser
Exemples SQL de Scott Forstie : https://gist.github.com/forstie

Une petite explication sur les fichiers ACS et leur extension, et les migrations possibles à partir des fichiers de Client Access

Pour les fichiers de définition de session

Les fichiers, KMP, PMP, BAR, MAC ont la même extension, mais ne sont pas compatibles, vous devrez les migrer par l’outil de migration .

Gestionnaire de sessions / fichier / importer

Pour les transferts de fichiers

Vous pouvez ouvrir un fichier DTF par ACS et l’enregistrer en DTFX, la migration est automatique

On n’a pas d’outil pour migrer les descriptions de fichier FDX, vous devrez les recréer ou modifier le source, il y a peu de différences

Résumé

On sait migrer les sessions, les claviers, les transferts les macros **

Pour les fichiers macros, vous ne pourrez migrer que ce qui a été enregistré et non codé

Mais ca peut être l’occasion de faire le ménage de reprendre propre.

**

, Créer une requête DTFX en SQL

vous voulez créer une requête d’extraction de fichier et vous avez déjà la requête voici un petit mode opératoire

d’abord choisissez le bouton depuis votre IBMi

Choisissez propriétés

indiquez lui que vous voulez faire du SQL

Vous pouvez maintenant saisir votre requête SQL

Vous pouvez aussi comme d’habitude sauvegarder et rejouer vos requêtes de transfert !

Vous voulez faire du 5250 sur votre IBMi et que vos informations ne circulent pas en claire sur le réseau.

La première solution est de mettre en œuvre telnets


Vous devez vous connecter sur DCM
Créer un certificat ou utiliser un déjà existant
et l’associer à l’application

.
Ensuite dans votre client, en principe ACS , indiquer que vous vous connectez en sécurisé .

.

La deuxième est de passer par SSH

vous avez un client 5250 (TN5250) installable dans les packages OPEN SOURCES
vous n’avaez rien à faire coté serveur tout va se passer sur le service ssh qui doit être démarré
d’abord vous devez vous connecter par une client SSH , putty ou celui ACS mais en principe si vous faites ca …

.
Une fois connecté il vous suffira de lancer le client 5250 par la commande tn520
par exemple
==>tn5250 env.TERM=IBM-3179-2 ssl:neptune

.

.

Conclusion :

Ce n’est pas parfait mais vous n’avez pas besoin d’installer un client sur votre poste et en principe pas d’intervention à faire coté serveur ibmi

, , Suggestion d’Index agrégés

Vous connaissez index advisor, c’est une table que le système met à jour à chaque suggestion d’index, elle se nomme SYSIXADV et elle est dans QSYS2.

Vous pouvez l’interroger par SQL en faisant un simple select et en appliquant un filtre par rapport à une date de dernière utilisation et soit un nombre de fois recommandés ou un temps de reconstruction.

Exemple :

Depuis 1 mois et plus de 1000 fois

select * from qsys2.SYSIXADV where

LAST_ADVISED > current date – 1 month and times_advised > 1000

Depuis 1 jour et temps de reconstruction > 100 pour la bibliothèque GREFER

select * from qsys2.SYSIXADV where

TABLE_schema = ‘GREFER’ and LAST_ADVISED > current date – 1 days and ESTIMATED_CREATION_TIME > 100

Index agrégé

Il existe une vue sur cette table pour les index agrégés (clés composées) son nom est CONDENSEDINDEXADVICE et son nom court CONDIDXA.

Elle est souvent utilisée dans les outils comme gestion des schémas ou Visual Explain par exemple.

Mais vous pouvez l’utiliser directement dans vos requêtes comme SYSIXADV

Exemple :

Les index suggérés sur la bibliothèque GREFER

select * from qsys2.condidxa where TABLE_schema = ‘GREFER’

Ça vous évitera de créer des index dont les zones sont utilisées dans les autres.

Exemple

Pour la table LSTOBJ

Sur la table SYSIXADV :

Sur la vue CONDIDXA :

dans cet exemple à base d’un dspobjd on voit bien qu’un seul index est suffisant alors qu’ Advisor en suggère 3 de base.

rappel

l’index est un des principaux facteurs de performances de votre base de données , il faut surveiller ce que dit index advisor

Comment transférer un job dans qctl

Il peut être important de lancer un job qui tourne même quand le système est en mode restreint

Nous supposerons bien sûr que le sous-système de contrôle est QCTL.

1) Un job batch

il suffit d’indiquer la jobq QCTL dans le SBMJOB

exemple :

Vous avez une commande qui fait une SAV21

SBMJOB CMD(SAV21)
JOB(SAV21)
JOBQ(QCTL)

2) Pour un interactif , si le job est actif

TFRJOB JOBQ(QCTL)

3) Pour un interactif, si le job n’est pas actif

Vous devrez anticiper ce risque dés à présent en créant un unité qui a une entrée nominative dans QCTL.

pour créer l’unité

Récupérer le dernier contrôleur *VWS créer
WRKCTLD

CRTDEVDSP DEVD(votre unité ) DEVCLS(VRT) TYPE(3477) MODEL(FC) ONLINE(NO) CTL(votre controleur) KBDTYPE(FAB) CHRID(697 297)
ALWBLN(YES) PRTDEV(SYSVAL) OUTQ(DEV) PRTFILE(LIBL/QSYSPRT)
TEXT(‘Unité SECOURS’) DEPLOCNAME(*NONE)

créer l’entrée écran dans QCTL

ADDWSE SBSD(QCTL)
WRKSTN(votre écran)

pour contrôler

DSPSBSD
puis option 4

Vous devez retrouver une entrée avec votre nom d’unité

Maintenant vous devez indiquer votre nom d’unité dans votre session
exemple sur ACS

A la mire la mire vous devez avoir ceci

Attention

Ça peut vous sauver de petites blague, mais ça ne doit pas être un mode fonctionnement systématique.

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 !

, , 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.

, , , , Mise à jour Produits Open source sur votre IBMi

Vous connaissez l’outil ACS de gestion des packages OPEN SOURCE

Si vous décidez d’utiliser l’Open source vous vous rendrez compte qu’il faudra sans doute automatiser la mise à jour des Packages RPM par YUM.

Voici donc quelques éléments pour réaliser cette opération !

D’abord vous devrez vérifier que vous avez bien Yum installé sur votre machine, normalement il est là, ACS l’utilise.

Les logiciels open source sont installés dans le répertoire

/QOpenSys/pkgs/bin

sous QSH

faire un cd /QOpenSys/pkgs/bin

puis ls yum*
yum yum-builddep yum-debug-dump yum-groups-manager
yumdownloader yum-config-manager yum-debug-restore

$ Vous devez avoir le fichier yum

il est conseillé de mettre ce répertoire dans votre Path.
Vous avez un fichier .profile éditer le pour ajouter ces 2 lignes par exemple à la fin de votre fichier .profile :
PATH=/QOpenSys/pkgs/bin:$PATH
export PATH

Il est également conseillé pour des questions d’homogénéisation de votre système d’utiliser un répertoire /home/votreprofil qui est la valeur par défaut de votre profil utilisateur (paramètre HOMEDIR de votre USER IBMi) et votre .profile devrait s’y trouver

Attention si vous voulez que ça fonctionne dans tous les environnements votre fichier .profile doit être en CCSID 819 !

Maintenant voyons comment procéder pour automatiser ces opérations de mise à jour
vous devrez planifier une tache qui lancera un QSH

la commande à passer pour voir si des mises à jour sont disponibles
c’est > yum check-update
Pour se faciliter la vie on mettra cette information dans un fichier txt
yum check-update > majpackage.txt
Ce fichier comporte l’intégralité des mises à jours et même les obsolescences
pour se limiter au logiciel qu’on veut mettre à jour on peut faire un cat avec un grep, par exemple nous on veut les mises à jour pour le logiciel NODEJS

cat majpackage.txt | grep « node »

nodejs14.ppc64 14.17.5-1 ibm
$

On voit qu’on a une mise à jour à faire, vous pouvez alors envoyer un mail par la commande sndsmtpemm pour indiquer la mise à jour à faire.

ou faire la mise à jour directement

yum update nodejs14.ppc64 -y –enablerepo=ibm
-y pour indiquer que vous allez installer en batch !

Il est conseillé de mettre un fichier de log exemple

Vous pourrez analyser ensuite la log en cas de problème en principe le nettoyage étant fait à la fin et votre version continu à fonctionner !

Il suffit de faire un ou 2 programmes CLP ou scripts Unix et d’y intégrer ce qu’on vient de voir !

Une des problématiques, quand on fait du SQL, est d’identifier rapidement une requête qui serait trop gourmande.

Dans un post précédent j’indiquais comment avoir ces éléments en utilisant le cache SQL, mais ça peut être long pour une première analyse !

La TR5 version 7/4, TR11 version 7/3 apporte une nouvelle fonction table (QSYS2.ACTIVE_QUERY_INFO( )) qui va nous permettre de répondre à cette problématique !

page de référence IBM

https://www.ibm.com/docs/en/i/7.4?topic=services-active-query-info-table-function

Pour l’utiliser, vous devez avoir *JOBCTL dans votre profil ou être ajouté dans la fonction USAGE QIBM_DB_SQLADM .

Exemple :


Une demande qui donne à un instant donné, les 10 requêtes les plus consommatrices de votre IBMi

SELECT QUALIFIED_JOB_NAME as travail , query_type as type_requete, File_Name as fichier , Library_name as bibliotheque,
current_runtime as temps_execution , CURRENT_TEMPORARY_STORAGE as memoire_utilisee
FROM
TABLE(QSYS2.ACTIVE_QUERY_INFO())
where current_runtime is not null
ORDER BY current_runtime desc
fetch first 10 row only

Vous pourrez alors agir en ayant le nom du travail, et utiliser la vue ACS prévue à cet effet par exemple !

On indique le premier fichier spécifié dans la requête (vue ou table), attention QSQPTABL indique que c’est une fonction table.