Vous utilisez UIM pour faire vos AIDES et vos menus
Vous voulez avoir une version multi langue sans changer votre panel de groupe
Il n’existe pas de solution dynamique, mais vous pouvez utiliser les fichiers messages, comme pour les commandes et les écrans, à la compile
il vous suffira de mettre en ligne la bibliothèque avec le bon langage
rappel un message est identifié par 7 caractéres xxxnnnn
xxx est est généralement 3 lettres (mais avec des exceptions exemple SQL et SQ2)
nnnn est composé de 4 chiffres
La partie utilisée dans les écrans et les commandes, c’est uniquement le message sur 132 caractères c’est le paramètre MSG()
dans notre exemple :
Nous avons différencié 3 Types de messages pour simplifier
TXT sur la structure du menu
OPT sur le texte des options à afficher
HLP sur les aides d’option à afficher
USR sur les commandes (mais pas utilisé pour l’instant le tag MENUI ne semblant pas admettre de message ) c’est le standard des fichiers de messages associés au menu SDA
Nous avons créer une commande
CRTMNUMOD qui génère ces messages dans le msgf, par défaut c’est un menu de 10 options avec texte en Français
Téléchargeable ici : https://github.com/Plberthoin/PLB/tree/master/GENUIMDSP
Vous obtenez un MSGF comme ceci :
Ensuite vous avez un modèle de menu en PNLGRP qui s’appui sur ce fichier messages
Vous allez devoir le customiser la première fois
1) Vous devez indiquer le fichier message sur le tag PNLGRP
Exemple :
:PNLGRP SUBMSGF=MODELE.
2) Les options sur les tags :MENUI
Exemple :
otion 4 avec un WRKSPLF
:MENUI OPTION=04 ACTION= ‘CMD WRKSPLF’
HELP=’MENU/OPTION04′.
** pour le moment je ne sais pas les mettre dans un fichier message
3) Vous devez ensuite compiler votre menu en précisant le nom du menu et le source
Exemple :
CRTMNU MENU(MALIB/MONMENU)
TYPE(*UIM)
SRCFILE(MALIB/QMNUSRC)
==>GO votremenu
Les identifiants de messages sont remplacés par les textes des messages, si vous avez une version par langue , mettez la bibliothèque de la langue en ligne avant la compile et c’est joué.
Vous pouvez utiliser la même technique sur les panneaux d’aide
Vous pouvez indiquer de nouveaux identifiants si vous avez des textes de plus de 132 caractères
Vous pouvez utiliser des caractères spéciaux pour éviter certains problèmes de syntaxe
&period. pour un « . »
&slr. pour un « / »
&. pour un « & »
&colon. pour un :
Documentation de référence ici : https://public.dhe.ibm.com/systems/power/docs/systemi/v6r1/en_US/sc415715.pdf
Pour les traductions vous pouvez même les automatiser en utilisant des webservices type Google , reverso, ou deepl bientôt nous ferons un article sur ce blog
C’est une bibliothèque qui contient les sources d’environ 15 outils IBMi, le plus connu est NETS qui permet de gérer les partages en mode 5250.
Elle est développée par Jim Sloan, ce sont les outils TAATOOLS et depuis la version V3.7 ce sont eux qui gérent les licences.
Donc vous pouvez acquérir une licence du produit en vous adressant ici : support@taatool.com
Vous pouvez également avoir une version des outils sur votre machine : en effet avant la version 3.7 IBM distribuait gratuitement ce produit
pour plus d’information c’est ici
https://www.ibm.com/support/pages/qusrtool-status
Pour la gestion des partages, vous avez une explication ici
https://www.ibm.com/support/pages/manage-ibm-i-netserver-without-navigator-go-nets
Dans ce menu vous avez par exemple l’option 12 qui permet de gérer les utilisateurs désactivés, c’est une alternative simple à Navigator for i dans certains cas.
Navigator for i utilise les services SQL, il vous indique les requêtes qui ont été utilisées.
Vous pouvez les rejouer dans ACS exécuteur de scripts.
Voici comment :
Vous avez un bouton SQL qui permet d’accéder à la requête
Par contre quand vous voulez exécuter cette requête, vous avez ce message :
Il vous faut démarrer un service sur ACS pour accepter l’exécution de ces scripts
Vous voyez votre service à l’état démarré
Vous récupérez la requête SQL dans ACS
Voila c’est simple et efficace vous pouvez également copier la requête dans propriétés si vous préférer
Vous cherchez un client SSH et vous avez commencé à toucher les limites de PUTTY ?
Nous en avons testé plusieurs et nous avons bien aimé smarTTY
L’interface est simple et épurée, vous avez les icônes avec les sites que vous avez définis
Vous pouvez utiliser une connexion existante ou définir une nouvelle connexion
il vous demandera les éléments classiques, vous pourrez ensuite passer à un échange de clés pour vous identifier.
Vous avez le choix entre 2 interfaces, j’ai préféré l’interface plus classique, les plus jeunes préféreront le « SMART »
Dans l’interface SMART vous pouvez par exemple éditer directement les fichiers …
Vous pouvez alors saisir vos commandes et travailler comme sur n’importe quelle interface .
Le petit plus que nous avons aimé
C’est le bouton SCP qui est une alternative à Filezilla pour les échanges simples
Vous choisissez le fichier à télécharger
Vous avez une fenêtre qui apparait pour indiquer l’avancement du téléchargement
Vous pouvez suspendre, fermer la fenêtre
Voila , comme on dit à Gaia c’est simple et efficace, vous pouvez le tester
Remarque :
Pour l’intégrer dans ACS vous devez modifier le fichier AcsConfig.properties
Attention de vérifier que vous utiliser bien le bon fichier de configuration plus d’informations ici
https://www.ibm.com/support/pages/node/667125
En résumé vous lancez à partir de ACSBUNDLE.jar vous devrez l’ouvrir et l’éditer manuellement.
Contrôler le nombre de paramètres passés à un programme CL – %PARMS() / CEETSTA
Il arrive parfois d’avoir moins de paramètres passés à un programme CL que le nombre attendu, par exemple si on ajoute un paramètre à ce dernier mais que pour diverses raisons on ne souhaite pas modifier et recompiler tous les programmes qui y font appel.
Il existe deux solutions relativement simples à implémenter pour contrôler le nombre de paramètres transmis afin d’adapter en conséquence le comportement du programme : La fonction intégrée %PARMS et l’API CEETSTA.
%PARMS() – V7R4 et ultérieures
À partir de la V7R4, rien de plus simple, il suffit d’utiliser la fonction intégrée %PARMS(), qui retourne le nombre de paramètres :
PGM PARM(&PARAM1 &PARAM2)
/* Paramètres */
DCL VAR(&PARAM1) TYPE(*CHAR) LEN(10)
DCL VAR(&PARAM2) TYPE(*CHAR) LEN(10)
/* Corps du programme en fonction du passage du paramètre */
IF COND(%PARMS() *EQ 2) THEN(DO)
SNDPGMMSG MSG('Le paramètre &PARAM2 est renseigné')
ENDDO
ELSE CMD(DO)
SNDPGMMSG MSG('Le paramètre &PARAM2 n''est pas renseigné')
ENDDO
ENDPGM
Malheureusement, si on est confrontés à une contrainte de version, %PARMS ne descend pas en dessous de la V7R4 :

CEETSTA – V7R3 et antérieures
Dans ce cas, la solution la plus propre (je ne parlerai donc pas de monitoring sur un CHGVAR) est l’utilisation de l’API CEETSTA.
Il suffit de lui passer en paramètre :
– Une variable qui contiendra la valeur de retour, 1 si le paramètre est transmis, 0 s’il n’est pas transmis
– Une variable indiquant la position du paramètre à contrôler
presence_flag | Sortie | *INT | Variable de retour : 1 ou 0 |
arg_num | Entrée | *INT | Position de la variable à tester |
PGM PARM(&PARAM1 &PARAM2)
/* Paramètres */
DCL VAR(&PARAM1) TYPE(*CHAR) LEN(10)
DCL VAR(&PARAM2) TYPE(*CHAR) LEN(10)
/* Déclaration des variables nécessaires à l'utilisation de l'API */
DCL VAR(&PRESENCE) TYPE(*INT) /* Variable de retour : 1 ou 0 */
DCL VAR(&ARG_NUM) TYPE(*INT) VALUE(2) /* Position de la variable à tester */
/* Appel de l'API */
CALLPRC PRC('CEETSTA') PARM((&PRESENCE) (&ARG_NUM))
/* Corps du programme en fonction du passage du paramètre */
IF COND(&PRESENCE *EQ 1) THEN(DO)
SNDPGMMSG MSG('Le paramètre &PARAM2 est renseigné')
ENDDO
ELSE CMD(DO)
SNDPGMMSG MSG('Le paramètre &PARAM2 n''est pas renseigné')
ENDDO
ENDPGM
Remarques
Le compte des paramètres pour la arg_num commence à 1
La valeur de retour est un *INT pas un *LGL
Pour plus de détails
Documentation IBM – %PARMS() : https://www.ibm.com/docs/en/i/7.5?topic=procedure-parms-built-in-function
Documentation IBM – CEETSTA : https://www.ibm.com/docs/api/v1/content/ssw_ibm_i_75/apis/CEETSTA.htm
Vous sauvegardez sur des bandes LTO, et vous voulez savoir si vos bandes sont en bon état,
pour en savoir plus sur les LTO : https://fr.wikipedia.org/wiki/Linear_Tape-Open
La durée de vie théorique d’une bande LTO est donnée pour 30 ans, mais elle dépend beaucoup des conditions d’utilisation et elles peuvent être défectueuses.
Certaines sociétés changent leurs bandes tous les 3 ans.
La bonne pratique c’est de le faire quand vous changez votre POWER en principe tous les 3 à 5 ans.
Mais il peut être important de contrôler l’état de vos supports pour éviter les mauvaises surprises.
Il n’existe pas de service SQL ni de sortie outfile pour l’instant.
Vous allez pouvoir faire une analyse par volume.
C’est vous qui indiquez le nom de volume quand vous formater votre support
INZTAP DEV(TAPXXX) NEWVOL(xxxxxx) vous disposez de 6 caractères
Exemple :
==>INZTAP DEV(TAP01) NEWVOL(LUNDI1) …
La commande qui va vous permettre d’analyser ces volumes est la commande PRTERRLOG
qui va vous générer un spool QPCSMPRT.
En principe vous avez un roulement de bande par semaine.
Vous pouvez contrôler le volume dans le lecteur avant de déclencher une sauvegarde, mais il n’est pas conseillé de la bloquer, vous pouvez remonter un message.
« * Attention bande du LUNDI trouvée dans le lecteur * »
Exemple
Vous devez connaitre le type de votre unité de bande pour utiliser cette commande.
==>DSPDEVD TAP01
==>PRTERRLOG TYPE(VOLSTAT) OUTPUT(PRINT)
VOLTYPE(3580)
VOLSTATTYP(*LIFETIME)
Si vous avez des erreurs il faut remplacer vos bandes.
Pour vous aider à automatiser cette remontée d’information, vous pouvez utiliser notre outil disponible ici :
https://github.com/Plberthoin/PLB/tree/master/SNDVOLSTAT
Remarque :
Il est important :
d’avoir un plan de reprise d’activité suite à un crash
de tester une restauration partielle de temps en temps
de passer la cartouche de nettoyage tous les 6 mois
Vous désirez connaitre la taille occupée par les MTI (Maintained Temporary Index) sur votre machine, voici une Méthode.
Vous avez des buckets (espaces dans votre mémoire centrale) sur votre partition.
Vous avez un service QSYS2.SYSTMPSTG qui permet de voir ces buckets
La taille des MTI, c’est le bucket 14
Voici la requête pour voir cette taille
SQL SELECT CURRENT TIMESTAMP AS date_heure,
BUCKET_NUMBER,
GLOBAL_BUCKET_NAME,
BUCKET_CURRENT_SIZE,
BUCKET_LIMIT_SIZE
FROM QSYS2.SYSTMPSTG
WHERE bucket_number = 14
Pour diminuer cette taille il faut créer les index qu’Index advisor vous suggère.
Vous avez une fonction table qui vous indique les MTIs de votre système, QSYS2.MTI_INFO
Ceux qui concernent votre base de données doivent être construits
Ici ceux utilisés depuis une semaine sur la bibliothèque exploit !
SELECT *
FROM TABLE (
QSYS2.MTI_INFO(‘EXPLOIT’, ‘*ALL’)
)
WHERE LAST_BUILD_START_TIME > CURRENT DATE – 7 DAYS
Remarque :
Cet espace sera réutilisé par les autres Buckets
Vous pouvez faire un suivi de ces buckets , par exemple ceux de la base de données pour voir les grandes variations
La mise à jour du fichier d’index Advisor dépendra de la méthode utilisée pour générer l’index, n’hésitez pas à effacer des enregistrements dans le fichier QSYS2.SYSIXADV.
La TR 3 de la V7R5 nous apporte un nouveau service qui va permettre de générer un fichier XLS à partir d’une requête SQL
Exemple :
VALUES SYSTOOLS.GENERATE_SPREADSHEET(
PATH_NAME => ‘LST_option.xls’,
SPREADSHEET_QUERY => ‘Select * from qgpl.qauoopt’ ,
COLUMN_HEADINGS => ‘COLUMN’ ,
SPREADSHEET_TYPE => ‘xlsx’)
Remarque:
ACS doit être installé sur votre partition et si possible à jour
Attention par défaut il génère du csv
La TR3 de la V7R5, nous apporte une nouvelle fonction table qui va nous permettre d’analyser plus finement et surtout plus simplement la fin d’un travail, soit en réalité le message CPF1164, en effet on a accès directement au code secondaire .
Exemple :
SELECT FROM_JOB,
JOB_END_CODE,
JOB_END_DETAIL,
SECONDARY_ENDING_CODE,
SECONDARY_ENDING_CODE_DETAIL
FROM TABLE (
SYSTOOLS.ENDED_JOB_INFO()
)
WHERE JOB_END_CODE > 10
Remarque :
Par défaut il analyse la veille soit (current date – 1)