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.

, , , Surveillez vos requêtes SQL sur votre #IBMi

Il est possible que vous ayez des doutes sur les performances de vos requêtes SQL, voici comment avoir une idée rapide de ce qui tourne

On va utiliser ACS
dans Base de données choisir
SQL Performance center

Vous avez un onglet Affichage des instructions

Vous choisissez le filtre à appliquer, ici on choisit les actives, vous pouvez être beaucoup plus pertinent en limitant votre choix.

Une fois que vous avez repéré une requête candidate, il vous suffit de faire un clic droit sur celle ci et vous pouvez lancer directement Visual Explain, qui vous expliquera le comportement de cette requête, vous pourrez alors faire les ajustements qui s’imposent

Le résultat dans V-E

PS:
Le principal critère de performance sur SQL, c’est les index, pensez à surveiller les suggestions faites par Index Advisor

, , Variables SQL utilisables dans vos scripts ?

Voici quelques variables que vous pouvez utiliser dans vos requêtes SQL

par exemple Client_Ipaddr qui est arrivée avec la TR4

Quelques registres et variables d’environnement

select
current time as heure_en_cours,
current date as date_en_cours,
current user as utilisateur_courant,
current timestamp as timestamp_en_cours,
CURRENT CLIENT_ACCTNG as Client_connexion,
CURRENT CLIENT_APPLNAME as Client_Application,
Current timezone as Fuseau_Horaire,
Current server as Current_Server ,
current path as Current_path,
CURRENT CLIENT_APPLNAME as Programme_client,
CURRENT CLIENT_USERID as Utilisateur_client,
CURRENT CLIENT_PROGRAMID as Programme_client
from sysibm.sysdummy1

Quelques Variables globales dans SYSIBM

select
SYSIBM.Client_Host as Client_Host,
SYSIBM.Client_Ipaddr as Client_Ipaddr,
SYSIBM.Client_Port as Client_Port,
SYSIBM.Package_Name as Package_Name,
SYSIBM.Package_Schema as Package_Schema,
SYSIBM.Package_Version as Package_Version,
SYSIBM.Routine_Schema as Routine_Schema,
SYSIBM.Routine_Specific_Name as Routine_Specific_Name,
SYSIBM.Routine_Type as Routine_Type
from sysibm.sysdummy1

Comme dans nos exemples, ces variables sont utilisables dans vos requêtes

exemple

les travaux actifs de l’utilisateur en cous

, , , , Utiliser ACS pour produire des fichiers Excel depuis l’IBM i

Access Client Solutions (ACS)

Pour rappel, ACS est le successeur de Client Access et permet toujours les exports de données.

ACS est également un produit entièrement Java, et utilisable en mode ligne de commande.

Il est donc possible de le piloter sur l’IBM i. Pour cela il vous faut :

  • Avoir le produit sous licence 5770JV1 (Java) version 8 ou supérieur
  • Access Client Solutions sur l’IFS (désormais installé via PTF (7.4: SI71900 / 7.3: SI71934 / 7.2: SI71935) dans /QIBM/ProdData/Access/ACS/Base

Exemples

Il est alors possible de provoquer le transfert de données de deux façons :

  • le fichier complet
  • une requête SQL permettant la sélection, transformation, jointure …

Syntaxe :

/PLUGIN=cldownload /system=<system>
                          [/userid=<userid>]
                          {/hostfile=<library/filename> | /sql="statement"}
                          {/clientfile=<path><filename>.<extension> | /display}
                          [/<options>]

    /userid     - user id to use when connecting to the target system
    /hostfile   - Source library and file on the IBM i system for the download
                  e.g. /hostfile=QIWS/QCUSTCDT
    /sql        - specify an SQL statement
                  e.g. /sql="select CUSNUM,LSTNAM,INIT,ZIPCOD from QIWS/QCUSTCDT"
    /clientfile - Target file location for the download.
                  The format of this file will be determined by the specified
                  extension (for example, .csv .ods .xlsx .xlsx)
                  If the file extension is not specified or is of a type
                  not supported, the data will be formatted as a .csv file
    /display    - write the output to the terminal
    
    Valid options are:
       /colheadings=<1/0> - Include column headings as the first row. When specified, the column names will be the heading.
       /usecollabels      - Use column labels for the heading.

Puisque ACS est directement sur votre IBM i, on peut utiliser localhost pour la valeur /system. Cela permet également la portabilité de la commande d’une machine à l’autre.

Pour transférer tout un fichier on utilisera le paramètre /hostfile. Ici sous QSH :

cd /QIBM/ProdData/Access/ACS/Base

java -jar acsbundle.jar
/PLUGIN=cldownload /system=localhost
/hostfile=sqlsample/employee
/clientfile=/home/nb/export/employe.xlsx

Cela produit :

Remarquer le nom de l’onglet.

Pour transférer par une requête SQL :

cd /QIBM/ProdData/Access/ACS/Base

java -jar acsbundle.jar
/PLUGIN=cldownload /system=localhost
/sql="select trim(firstnme) concat ' ' concat trim(lastname), hiredate, current date - hiredate as \"Ancienneté\" from sqlsample.employee" /clientfile=/home/nb/export/employesql.xlsx

Attention à l’échappement des caractères spéciaux …

On obtient :

Des options supplémentaires vous permettent d’affiner la sortie :

  • /colheadings=<1/0> – Inclure ou non l’entête
  • /usecollabels – Utiliser les labels au lieu des noms de colonne

Ces fonctions nécessitent une version de ACS > 1.1.8.6 pour fonctionner correctement.

Comment automatiser ?

Il est relativement simple d’intégrer cette commande Java dans un programme CL. Ici en utilisant /clientfile.

Par exemple avec RUNJVA :

Ou par QSH :

Ici on a paramétré plus d’éléments pour avoir une base de programme plus générique.

Avantages ?

Access Client Solutions permet facilement d’automatiser vos conversions depuis l’IBM i, et non depuis un poste client. Cela rend beaucoup plus naturel l’intégration de ces traitements dans vos chaines, la maitrise des transferts par l’IT et non par les utilisateurs, la maitrise des flux, des versions de produits utilisées etc …