Administration, Non classé, Open source, SecuritéSe connecter à un serveur SSH exécuté sous Windows à partir d’un IBM i (Comment obtenir la log pour débuguer les problèmes éventuels)

Se connecter à un serveur SSH exécuté sous Windows à partir d’un IBM i (Comment obtenir la log pour débuguer les problèmes éventuels)

Mise en place d’OpenSSH Server sur Windows

Pour mettre en place OpenSSH Server sur Windows, la méthode « standard » consiste à passer par les Paramètres > Applications et fonctionnalités > fonctionnalités facultatives :

Il est recommandé de redémarrer Windows une fois la fonctionnalité ajoutée.

Il suffit ensuite de démarrer le serveur via le gestionnaire de Services Windows :

Il est également souhaitable de configurer le démarrage automatique du serveur :

Remarque
Il est également possible d’installer OpenSSH sur Windows via d’autres sources (GitHub par exemple) ce qui permet, entre autres, de choisir plus facilement sa version d’OpenSSH, voir section Détail.

Création d’un jeu de clefs SSH via ssh-keygen

Pour plus de détails sur la création de clefs, vous pouvez vous référer à l’article de Guillaume Gestion des clefs SSH.

Il est également possible d’utiliser PuttyGen, outil venant avec le client Putty pour générer le jeu de clefs de manière graphique (https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html).

Dans cet article je vais tout réaliser sur l’IBM i via QSH :

$ ssh-keygen -t ecdsa -f ~/.ssh/ssh_key

Mise en place de la clef privée et configuration côté IBM i (client)

On a généré la clef privée dans le répertoire .ssh de l’utilisateur, donc elle est déjà bien en place. Il suffit donc de créer un fichier config dans le répertoire .ssh de l’utilisateur afin de simplifier nos commandes pour la suite.
Voici un exemple de fichier config :

[~/.ssh/config]

Host windows
    Hostname sshd_server.lan
    User jl
    IdentityFile ~/.ssh/key
    StrictHostKeyChecking accept-new

Host	Nom de la configuration, utilisé à la place des différentes informations à la connexion
Hostname	Adresse ou nom du serveur à atteindre
User	Nom de l’utilisateur
IdentityFile	Chemin vers la clef privée
StrictHostKeyChecking accept-new	Permet d’ajouter automatiquement la signature du serveur distant au known_hosts

Mise en place de la clef privée et configuration côté Windows (serveur)

Il faut transférer la clef ssh_key.pub vers Windows et l’ajouter soit au fichier %UserProfile%.ssh\authorized_keys pour un utilisateur lambda, soit au fichier C:\ProgramData\ssh\administrators_authorized_keys pour un utilisateur ayant des droits d’administrateur local.

Attention à ce niveau, les droits des fichiers sont un peu particulières, il faut comme toujours avec le SSH réduire au maximum les utilisateurs ayant accès au fichier et, particularité de Windows, ajouter le droit de lecture au profil de service local Système :

Activation du fichier de log – Configuration sshd_config

Afin de pouvoir analyser d’éventuels problèmes ou simplement vouloir observer un peu plus en détail les différentes étapes de la mise en relation d’un flux ssh il est possible d’activer la log du serveur.

Par défaut celle-ci est redirigée vers les journaux d’évènements Windows et est seulement en « info ».
On les retrouver via l’Observateur d’événements Windows :

Le mieux à mon avis est de repasser par un système plus standard, soit un vrai fichier de logs.

Pour ce faire, il faut aller modifier le fichier de configuration du serveur SSH, généralement il se trouve ici :

C:\ProgramData\ssh\sshd_config
ou
%ProgramData%\ssh\sshd_config

Il faut rechercher les lignes suivantes :

[sshd_config]

# Logging
#SyslogFacility AUTH
#LogLevel INFO

Les décommenter et indiquer les valeurs suivantes :

[sshd_config]

# Logging
SyslogFacility LOCAL0
LogLevel Debug3

Une fois la configuration modifiée et le serveur redémarré, il suffit de retenter une connexion puis d’aller consulter le fichier de log :

C:\ProgramData\ssh\logs\sshd.log
ou
%ProgramData%\ssh\logs\sshd.log

Remarque
Les problèmes courants se passent généralement autour des lignes liées au fichier authorized_keys ou administrators_authorized_keys, problèmes de droits ou
chemin du fichier utilisé…

Test de SSH IBM i vers Windows

On peut maintenant tester le tout via QSH ou CALL QP2TERM.
Grâce au fichier config la commande est simple :
(l’option -T permet de désactiver l’allocation d’un pseudo terminal)

$ ssh -T windows
Microsoft Windows [version 10.0.19045.3208]
(c) Microsoft Corporation. Tous droits r

Il est maintenant possible d’exécuter des commandes Shell Windows à partir de cette connexion.

Si on voulait obtenir les mêmes niveaux de log côté client (IBM i) que l’on a activé côté Windows, on pourrait utiliser la commande suivante :

$ ssh -T -vvv windows
OpenSSH_8.0p1, OpenSSL 1.1.1t  7 Feb 2023                                            
debug1: Reading configuration data /home/jl/.ssh/config                              
debug1: /home/jl/.ssh/config line 1: Applying options for *                          
debug1: /home/jl/.ssh/config line 4: Applying options for laptop                     
debug1: Reading configuration data /QOpenSys/QIBM/ProdData/SC1/OpenSSH/etc/ssh_config
...
Microsoft Windows [version 10.0.19045.3208]
(c) Microsoft Corporation. Tous droits r

Pour plus de détails
OpenSSH.com : https://www.openssh.com/
OpenSSH Server sous Windows – Document Microsoft : https://learn.microsoft.com/fr-fr/windows-server/administration/openssh/openssh_overview
OpenSSH – GitHub : https://github.com/PowerShell/Win32-OpenSSH/releases

2 août 2023/par Julien Laurier

Non classéGestion des logs SHELL dans un CLLE

Gestion des logs SHELL dans un CLLE

Pierre-Henry avait déjà abordé la problématique de récupération des logs SHELL par la soumission de la commande QSH.

Un très bon article, que je vous conseille, si vous ne l’avez pas encore lu.

https://www.gaia.fr/recuperer-les-logs-dune-commande-shell-qsh/

Cependant pour des raisons d’organisation des traitements, on peut ne pas souhaiter débrancher la commande QSH, en la soumettant, du reste de notre programme.
Dans ce cas l’appel à QSH se fait dans le CLLE. Le log SHELL ne se retrouve pas dans les spools du job.
On peut néanmoins les récupérer par l’intermédiaire de variable d’environnements.

Les variables d’environnement et l’exécution de script SHELL

Je profite de cet article pour rappeler l’usage de quelques variables d’environnement pour l’exécution d’un script SHELL dans un CLLE. Ce ne sont que des exemples, il y en a beaucoup d’autres de possible !

QIBM_MULTI_THREADED

Cette variable d’environnement est essentielle pour le fonctionnement des scripts SHELL. Il faut être multi-threadé pour que la commande s’exécute.
Par exemple, dans l’image ci-dessous, j’ai lancé via la commande SHELL, un script SFTP.
En dernière ligne nous trouvons le job lançant la commande shell, et au dessus 3 jobs de type BCI, « Batch immediate jobs », qui sont activés pour l’exécution d’un job multi-threadé.

ADDENVVAR ENVVAR(QIBM_MULTI_THREADED) VALUE(Y)

QIBM_QSH_CMD_ESCAPE_MSG

L’exécution de la commande QSH dans un programme entraine un message QSH0005, QSH0006 ou QSH0007. Le message QSH0005 contient un code statut, allant de 0 à 255. 0 pour une exécution complète, les autres codes pour renvoyer un avertissement ou une erreur.

Par défaut, ces messages sont envoyés avec un type d’achèvement complétion (*COMP), circulez, y’a rien à voir ! Seule une lecture du log du job, pour trouver le statut du message QSH0005, permettra de dire si l’exécution de la commande QSH s’est bien passée.

En ajoutant la variable d’environnement avec la valeur Y, le type d’achèvement dépendra du statut du message QSH0005.
- Si le statut est 0 : message en complétion
- Autre valeur du statut, message en *ESCAPE. Ca veut dire qu’il faudra monitorer les messages QSH dans votre CL et gérer ces erreurs, sinon votre programme plantera.
  
  Message sans la variable d’environnement

Message avec la variable d’environnement

ADDENVVAR ENVVAR(QIBM_QSH_CMD_ESCAPE_MSG) VALUE(Y)

QIBM_QSH_CMD_OUPUT

Cette variable définit le mode de sortie lors de l’exécution du script SHELL.
NONE : exécution du script en mode silencieux
STDOUT : affiche le terminal C avec le déroulé du script. En interactif, possibilité de répondre à une question en cours de script.
FILE : génération d’un fichier log dans l’IFS. Si le fichier existe déjà, il sera remplacé.
FILEAPPEND : génération d’un fichier dans l’IFS en ajout. Le fichier sera créé, s’il n’existe pas.

Attention : Pour les options « File » et « Fileappend », si le chemin IFS n’existe pas ou s’il n’est pas atteignable, problème de droit par exemple, le terminal C s’affichera.

ADDENVVAR ENVVAR(QIBM_QSH_CMD_OUTPUT) VALUE(‘FILE=/Monrepertoire/MonFichierlog’)

Attention : Entre le « = « et le début du chemin pour le fichier log, il n’y a pas d’espace.

Dans votre programme, vous pouvez générer un nom de fichier log en dynamique, avant de générer votre variable d’environnement. Pour cela, il faudra que votre variable contienne ‘FILE=’ suivi du nom de votre fichier log, et passer la variable dans le paramètre VALUE de la commande.

Récupération du log

La variable d’environnement QIBM_QSH_CMD_ESCAPE_MSG permet de dissocier les fins OK des fins KO de QSH.
Mais sans la moindre information sur ce qui s’est passé.
Par la récupération du log dans l’IFS, vous pourrez interroger par SQL le fichier et gérer les problèmes. Au moins les cas les plus fréquents, et laisser les cas rares en gestion humaine.
La génération d’une log, peut aussi avoir de l’intérêt en cas de création de script en dynamique dans votre programme, pour garder une trace de ce qui a été exécuté… Pensez à la maintenance, et aux recherches en cas d’anomalie…

Prenons un exemple :
Un asynchrone qui scrute, via SFTP dans un répertoire réseau, la présence de fichier xml.
Télécharger ces fichiers dans l’IFS et laisser un traitement d’intégration dans l’ERP.
Ce traitement se lance à intervalle régulier, temporisation de 15 secondes.
Il peut ne pas y avoir de fichier à récupérer, répertoire distant vide.
C’est un cas classique d’interface asynchrone entre un logiciel externe à l’IBM i et la partie legacy de l’applicatif.

Dans cette exemple, je fais le choix d’effectuer directement un mget /repertoiredistant/*.xml, sans passer par un listing du répertoire suivi d’une lecture de ce listing pour charger fichier par fichier.
Je récupère directement tous les fichiers xml présents.
Problème, s’il n’y a aucun fichier xml dans le répertoire, le script SFTP renvoie une erreur, via le message QSH0005 qui a un statut 1. Pour moi ce n’est pas une erreur. C’est ce qu’on pourrait appeler un faux positif !

Pour déterminer si le message d’échappement reçu est une « vrai » erreur, ou l’absence de fichier à récupérer, je dois pouvoir récupérer la log.

Via la variable d’environnement, QIBM_QSH_CMD_OUPUT, en ‘FILE=’, je génère mes logs dans l’IFS, sans mode verbose sur le SFTP.

Quand tout se passe bien j’ai le log ci-dessous :

Le fichier contient la liste des commandes passées. Toutes les commandes de mon script se retrouvent dans la log.

Quand le mget ne trouve aucun fichier à ramener, j’ai le log :

À la suite du mget, je reçois un message d’erreur, pour fichier not found. Le script n’est pas allé plus loin, la commande « exit » n’a pas été passée.

Autre exemple, j’ai généré un problème de connexion, voici le log que j’ai reçu :

Aucune commande SFTP n’a été passée, normal, la connexion a été interrompu pendant la phase d’authentification.
Ce log n’est bien entendue qu’un exemple parmi beaucoup de problèmes de connexion.

Lecture du fichier par SQL

Je dispose de log dans l’IFS, je peux donc par SQL lire ces fichiers via la fonction table IFS_READ.

Voici ce que ça donne pour les 3 logs :

Le log ne disposant pas de code erreur ou de statut de fin, si je veux exploiter ces fichiers, je dois utiliser des recherches textuelles dans le champ LINE. Ce n’est pas l’ideal, mais faute de mieux…

Je peux par exemple rechercher « exit », pour savoir si mon script est allé au bout :

Je peux au contraire rechercher le problème de connexion interrompue :

Je peux aussi rechercher le « not found » pour détecter la fausse anomalie :

Dans notre programme, suite à l’exécution du script SHELL, plusieurs possibilités :

Avec la variable d’environnement QIBM_QSH_CMD_ESCAPE_MSG, monitorer les messages QSH0000 et donc en cas de problème lire les fichiers log. Dans ce cas la chaîne « exit » n’a pas besoin d’être testée, dans ce cas le message de retour est en complétion.
Sans la variable d’environnement QIBM_QSH_CMD_ESCAPE_MSG. Dans ce cas, je dois lire le log systématiquement et si je trouve « exit » ou « not found », la fin est normale, sinon il y a une erreur.

Les fichiers log, surtout sans mode verbose, comportent très peu de ligne, les SQL utilisés même s’ils sont « gourmands » par l’utilisation de like sur un fichier IFS, restent rapide. Mais attention à ne pas utiliser sur un fichier IFS contenant un log en cumul sur un mois !

L’idée est de gérer en automatique les retours les plus simples qui ne nécessitent pas d’intervention humaine.
Encore une fois, ce n’est pas l’idéal, mais si on peut alléger les alertes pour les équipes de maintenance, surtout pour un traitement lancé plusieurs fois par minute, il ne faut pas hésiter.

En cas de récupération des logs dans l’IFS, si vous générez un fichier distinct par appel, n’oubliez pas la base : durée de rétention des fichiers, script d’épuration des log obsolètes. Par SHELL, vous avez les outils pour gérer votre stratégie facilement.
Ca évitera un IFS qui enfle. Pour rappel, la volumétrie de données n’est pas la seule responsable des temps de sauvegarde / restauration de l’IFS, le nombre de fichiers aussi. Il vaut mieux un seul fichier de 1 Mo que 1000 fichiers de 1 ko

2 août 2023/par Damien Trijasson

Administration, Développement, Non classé, RDI, SecuritéDEBOGUER UN WATCHER

Il est difficile de déboguer un watcher parce qu’on ne maitrise pas son lancement.

Voici une méthode en utilisant RDI, qui va vous permet de le faire :

Trouver le nom du programme à analyser :

WRKWCH WCH(*ALL) :

5 pour le détail

Dans RDI, clic droit sur le programme à déboguer => débogage ou couverture de code (entrée de service) => définir un point d’entrée de service

Le message d’affiche :

Pour tester, on peut simuler un traitement qui va planter. Dans notre cas, on fait un call d’un programme qui n’existe pas, et donc ça va faire un plantage dans QSYSOPR.

SBMJOB CMD(CALL PGM(GAIA/ERREURA))

JOB(ERREURA)

JOBQ(QSYSNOMAX)

Une fois le programme a été lancé, sur RDI s’affichera le message suivant :

Cliquer sur « Afficher *LISTING »

Pour avancer d’un pas on peut utiliser la touche F5 ou en cliquant sur la flèche :

Pour afficher les valeurs des variables il suffit de passer la souris sur le nom de la variable :

Conclusion : c’est une solution simple pour déboguer un watcher ou un programme dont vous ne maitrisez pas le lancement.

Le programme doit être compilé avec le source.

Vous devrez avoir le droit pour faire ce type d’opération. Soit au niveau de profil, soit par les fonctions usages.

23 mai 2023/par Ana Ramirez

Développement, Non classé, RDI, VSCodeComment gérer les options de compile des PRTF

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é exemple SAVE(*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

idem pour les DSPF voire les PF et LF.

Vous trouverez le source des 2 programmes ici https://github.com/Plberthoin/PLB/tree/master/GTOOLS/RPG

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 …

7 mars 2023/par Pierre-Louis BERTHOIN

Administration, Développement, Non classé, SQL_DB2Contrainte d’intégrité référentielle

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

Par les commandes IBM i natives

ADDPFCST FILE(PLB/TCOMMANDE)
TYPE(REFCST) KEY(NUMERO) PRNFILE(PLB/TCLIENTS) DLTRULE(RESTRICT)
UPDRULE(*RESTRICT)

Par SQL

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

ID message . . . . . . : CPD32C5
Date d’envoi . . . . . : 11/02/23 Heure d’envoi . . . . : 07:51:54

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

ID message . . . . . . : CPF502D
Date d’envoi . . . . . : 09/02/23 Heure d’envoi . . . . : 16:17:38

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 obtenez les SQLCODEs suivants

DSPLY Insert : -530
DSPLY Update : -530
DSPLY Delete : -532

Voir les contraintes existantes

pour voir les contraintes existantes

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 !

Quelques liens :

https://www.ibm.com/docs/en/i/7.5?topic=objects-constraints
https://www.ibm.com/docs/en/i/7.5?topic=constraints-adding-using-check
https://fr.wikipedia.org/wiki/Cl%C3%A9_%C3%A9trang%C3%A8re

Les vues SQL sur les contraintes

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.

11 février 2023/par Pierre-Louis BERTHOIN

Administration, Non classé, SecuritéSécurisation Netserver en V7R5

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’

.

Rappel :

On ne partage jamais la racine !

24 juin 2022/par Pierre-Louis BERTHOIN

Administration, Non classé, Open source, Securité

Premier pas avec nginx

25 mai 2022/par Pierre-Louis BERTHOIN

Administration, Développement, Non classé, Open source, Securité, SQL_DB2Version de JVM

On utilise de plus en plus java dans les travaux de votre IBMi et on a parfois besoin d’avoir des informations d’exécution

Voici comment connaitre la version de la JVM d’un travail ?

2 solutions simples

==> WRKJWMJOB

Puis 5 puis 1

Ou en utilisant sql services par la vue QSYS2.JVM_INFO

exemple :

select JOB_NAME, JAVA_HOME from qsys2.JVM_INFO

plus d’informations ici

https://www.ibm.com/docs/en/i/7.3?topic=usage-java-system-properties

24 mai 2022/par Pierre-Louis BERTHOIN

Administration, Non classé, SQL_DB2Statistiques sur les MTIs

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

plus d’informations ici

https://www.ibm.com/docs/en/i/7.5?topic=services-mti-info-table-function

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

CONDIDXA étant la vue aggrégée de QSYS2.SYSIXADV

6 mai 2022/par Pierre-Louis BERTHOIN

Développement, Non classé, RDI, SQL_DB2Préciser la bibliothèque dans un SELECT INTO

Vous avez dans un programme RPGLE un select into en SQL à faire, mais vous devez choisir la bibliothèque ou se trouve le fichier !

Voici 3 solutions pour éviter le hard codage

1ére solution

Cette solution est plus adaptée à un curseur.

Formater une variable exemple sqlstm

sqlstm = ‘select votrezone from ‘ + votre_lib + ‘/votre_table’ ;

exec SQL
declare curs01 Cursor
for sqlstm ;

exec SQL
prepare sqlstm
from :sqlstm ;

exec SQL
open curs01 ;

exec sql
fetch next
from curs01
into :votrezone ;

On est d’accord, c’est un peu lourd

Voici une alternative

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;

1 février 2022/par Pierre-Louis BERTHOIN

Archive pour la catégorie : Non classé