Archive pour le mois : octobre, 2022
TR1 pour la 7.5
Les annonces de la TR1 de la 7.5 ou TR7 de la 7.4 sont sorties et disponibles ici https://www.ibm.com/support/pages/node/1119129/
• Voici selon nous 5 nouveautés à suivre dans cette Technology Refresh
• 1) La possibilité de faire des mises à jour sur des flux json avec la fonction JSON_UPDATE , ça fait longtemps que nos équipes râlaient, parce qu’elles devaient faire du bricolage quand on travaillait sur du flux json.
• 2) La possibilité d’exécuter des fonctions table remote, par exemple avec le service REMOTE TABLE, un object_statistics sur une partition distante. Ça peut avoir du sens pour automatiser des contrôles de cohérence.
• 3) Les nouvelles fonctions table, SYSTOOLS.AUDIT_JOURNAL_xx qui permettent de traiter les postes d’audit et plus globalement les nouveautés sur les audits comme la disponibilité d’IDS dans Navigator for i qui n’était pas présent dans la nouvelle interface.
• 4) SELF (SQL Error Logging Facility) qui va permettre de mettre au point les traitements SQL en attrapant de manière plus fine les erreurs et en pouvant les suivre dans le temps sans passer par un mode de debug parfois trop bavard en log.
• 5) Les nouveaux services pour administrer Object Connect (vous savez les commandes SAVRSTxxx, CHANGE_OBJECTCONNECT et OBJECTCONNECT_INFO), un petit rappel, Object Connect peut désormais fonctionner en IP. Disponible par PTF et c’est la dernière fonction SNA qui n’avait pas d’équivalent ip. Ces nouveaux services permettront d’administrer et d’avoir des informations sur ce qui s’exécute dans les échanges inter-machines.
• Rendez-vous en décembre pour les premiers tests.
Date source de vos programmes
On est amené quand on fait des analyses à regarder les dates de source, on constate que ces dates sont à null pour tous les objets de type ILE.
Vous avez une vue QSYS2.PROGRAM_INFO qui permet d’avoir ces informations sur les programmes, un peu comme la commande DSPPGM.
Voici pourquoi : quand vous travaillez en OPM vous compilez des sources qui deviennent des programmes; quand vous travaillez en ILE, vous compilez des sources qui deviennent des modules, puis vous les assemblez pour créer des programmes et du coup une date de source sur un programme ILE ne veut rien dire.
En réalité un programme a un module qui s’appelle point d’entrée programme qui, quand on travaille en BND (CRTBND*), est le seul module placé dans qtemp qui est assemblé pour créer votre programme.
On voit donc que si on veut, on peut assimiler la date du source du programme à la date du module PEP, qui dans plus de 99 % des cas a le même nom que le programme.
On a une deuxième vue permet d’avoir les modules par programme, QSYS2.BOUND_MODULE_INFO.
Il faudra donc combiner les 2 vues.
par exemple :
- Pour les programmes ILE
SELECT a.PROGRAM_NAME, a.PROGRAM_TYPE, b.SOURCE_FILE_LIBRARY, b.SOURCE_FILE,
b.SOURCE_FILE_MEMBER, b.SOURCE_CHANGE_TIMESTAMP
FROM QSYS2.PROGRAM_INFO A join QSYS2.BOUND_MODULE_INFO B
on a.PROGRAM_NAME = b.PROGRAM_NAME
and A.PROGRAM_NAME = b.BOUND_MODULE and A.PROGRAM_LIBRARY = b.PROGRAM_LIBRARY
WHERE a.PROGRAM_LIBRARY = ‘FADY’ and a.PROGRAM_TYPE = ‘ILE’
- Pour les programmes OPM
SELECT a.PROGRAM_NAME, a.PROGRAM_TYPE, A.SOURCE_FILE_LIBRARY, A.SOURCE_FILE, A.SOURCE_FILE_MEMBER,
A.SOURCE_FILE_CHANGE_TIMESTAMP
FROM QSYS2.PROGRAM_INFO A
WHERE a.PROGRAM_LIBRARY = ‘FADY’ and a.PROGRAM_TYPE = ‘OPM’
en faisant l’union des deux requêtes vous aurez les dates de tous vos programmes ILE et OPM.
Il y a sans doute d’autres solutions mais celle-ci est très simple à utiliser.
Droits SQL sur les Zones
On m’a récemment demandé comment savoir si un fichier était couvert par des droits SQL sur les zones
J’ai d’abord pensé que la fonction table QSYS2.OBJECT_PRIVILEGES allait me rendre ce service !
donc j’ai lancé cette requête pour analyser mon fichier
Exemple :
SELECT *
FROM TABLE(QSYS2.OBJECT_PRIVILEGES(‘MABASESQL’, ‘CLIENTS’, ‘*FILE’));
et je n’ai pas trouvé l’information dans les zones renvoyées
puis j’ai essayé avec les commandes historiques en sortie de fichier ici DSPOBJAUT
Exemple :
DSPOBJAUT OBJ(MABASESQL/CLIENTS)
OBJTYPE(FILE) OUTPUT(OUTFILE)
OUTFILE(MABASESQL/LSTAUT)
Select * from MABASESQL.lstaut
et la on a le résultat qui l’indique
ZONE OAOBJA à ‘USER DEF’ et une ZONE des DATA ici OAUPD à ‘/’
En résumé
On ne sait pas par SQL, mais on sait faire par une sortie fichier historique
Oui je sais , on peut trouver l’information par des vues spécifiques dans QSYS2 et SYSIBM
Vous avez d’abord la vue SYSIBM.SQLCOLPRIVILEGES mais attention, vous avez toutes les autorisations sur la zone y compris celles qui correspondent à un *CHANGE sur le fichier par exemple.
exemple :
Select * from SYSIBM.SQLCOLPRIVILEGES
where TABLE_SCHEM = ‘MABASESQL’ and TABLE_NAME = ‘CLIENTS’
order by column_name, grantee
Ou mieux la vue QSYS2.COLUMN_PRIVILEGES qui ne contient que les zones avec des autorisations spécifiques
exemple
Select * from QSYS2.COLUMN_PRIVILEGES
where TABLE_SCHEMA = ‘MABASESQL’ and TABLE_NAME = ‘CLIENTS’
j’ai donc fait une RFE pour avoir l’information dans la fonction table QSYS2.OBJECT_PRIVILEGES
Si vous êtes intéressés votez pour moi c’est ici https://2e4ccba981d63ef83a875dad7396c9a0.ideas.aha.io/ideas/RIRP-I-1260 
Je vous indiquerais la réponse d’IBM sur le sujet
RDi : configurer et déployer les Actions de l’utilisateur
Les actions utilisateur vous permettent d’exécuter des commandes préformatées sur les objets ou sur les membres de vos filtres, en utilisant le clic droit pour exécuter l’action.
Elles sont équivalentes aux options définies par l’utilisateur que l’on peut gérer par F16 sous PDM.
Gérer les actions de l’utilisateur
La gestion des actions utilisateur est accessible par clic droit sur les objets ou membres des filtres.
Créer une action objet
Nous allons créer une action pour exporter une table vers l’IFS au format CSV.
L’action utilisera la commande CPYTOIMPF que nous allons préformater.
Le bouton « Insérer une variable » affiche la liste des variables que nous allons pouvoir utiliser dans les paramètres de la commande pour substituer les attributs de l’objet sur lequel l’action s’exécute :
Le bouton « Invite » permet d’afficher l’invite de commande pour compléter les paramètres :
La case « Interroger d’abord » permettra d’afficher l’invite de commande lors de l’utilisation de l’action.
Enfin, il est conseillé d’indiquer les types de ressources pour lesquelles cette action sera proposée dans le clic droit :
Une fois créée, l’action apparait dans le catalogue des actions Objet :
Elle peut être utilisée par clic droit sur un objet de type fichier :
L’invite de commande est affichée avec les valeurs de substitution des variables utilisées :
Le fichier CSV est créé dans l’IFS :
Créer une action membre
Nous allons créer une action permettant de convertir un membre source RPG 4 en RPG FREE.
Pour cela, nous avons créé une commande CVTRPGFREE basée sur un convertisseur Open Source auquel GAIA contribue.
Pour limiter l’action au membres sources de type RPGLE et SQLRPGLE, nous allons Editer la liste des Types définis et créer un Type défini que nous nommerons RPGLE et qui rassemblera les types de membre RPGLE et SQLRPGLE :
Le fenêtre « Gérer les types nommés » s’ouvre :
Le bouton « Parcourir » permet de choisir les types de membre existants pour les ajouter à la liste :
Une fois créée, l’action apparait dans le catalogue des actions Membre :
Elle peut être utilisée par clic droit sur un membre de type RPGLE ou SQLRPGLE pour le convertir en RPG FREE :
Notons qu’en effectuant une sélection de plusieurs ressources dans un filtre, on peut exécuter une action utilisateur sur toutes ces ressources par un seul clic droit.
Exemple ci-dessous : on peut exporter 4 fichiers vers l’IFS au format CSV en un seul clic
Exporter/Importer les actions utilisateur
Les actions utilisateur peuvent être exportées vers un fichier de configuration à partir du menu
Fichier > Exporter > Rational Developer for i :
2 modes d’exportation sont possibles :
- l’export « Fichier de configuration » permet d’exporter la configuration vers un fichier local, qui pourra si on le souhaite être partagé et importé par d’autres utilisateurs vers leur Workspace.
- l’export « Fichier de configuration pour distribution automatique » permet d’exporter la configuration pour la distribuer automatiquement aux autres utilisateurs
Exporter Fichier de configuration pour distribution automatique
Pour exporter les actions utilisateur, décocher toutes les cases et ne conservez que la configuration « Artefacts de systèmes distants ».
Les filtres sont exportés, lors de l’import vous perdrez donc les filtres de votre Workspace.
Ca peut être gênant, mais ça peut aussi être l’occasion de faire du ménage dans vos filtres….
Le fichier de configuration sera généré dans le répertoire suivant de l’IFS :
/QIBM/ProdData/Devtools/clientconfig
Choisissez un numéro de version pour identifier le fichier de configuration :
Avant de Terminer, assurez-vous d’avoir les droits d’écriture dans le répertoire de destination.
Le fichier de configuration est généré dans l’IFS pour une distribution automatique de cette configuration :
Lorsque les utilisateurs se connecteront à l’IBM i, une fenêtre d’importation leur sera automatiquement proposée :
L’import peut être accepté (OK) ou pas (Annuler) mais tant qu’il n’aura pas été accepté, il sera reproposé à chaque connexion à l’IBM i par RDI.
C’est terminé !
PS :
Si le fichier de configuration a été exporté vers un fichier local par l’export Fichier de configuration au lieu de Fichier de configuration pour distribution automatique, il peut être importé de la même manière par le menu Fichier > Importation > Rational Developer for i > Fichiers de configuration. Il suffit d’indiquer l’emplacement du fichier de configuration, ensuite la procédure est identique à celle de la distribution automatique :
