, , INDEX ADVISOR en erreur

Vous connaissez index advisor, c’est le moteur SQL qui écrit dans le fichier QSYS2/SYSIXADV des suggestions d’index.

Vous pouvez l’utiliser
par SQL select * from QSYS2/SYSIXADV
par Navigator for i
par ACS
Vous avez même des procédures pour automatiser cette gestion

https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_73/rzajq/rzajqservicesperf.htm

Mais il peut arriver que le fichier soit endommagé, et les commandes IBMi habituelles sont inefficaces sur ce fichier (idem pour RCLDBXREF et RCLSTG).
C’est souvent un verrouillage du fichier QSYS2/SYSIXADV par des jobs QDBSRVxx qui fait planter votre sauvegarde par exemple.

Voici la procédure à suivre
Vous devrez trouver le bon CCSID c’est celui de la zone DBXFIL du fichier QADBXREF
par exemple par SQL en faisant

SELECT « CCSID » FROM SYSCOLUMNS
WHERE COLUMN_NAME = ‘DBXFIL’ and
TABLE_NAME = ‘QADBXREF’

  1. Essayer d’arrêter les jobs QDBSRVxx
  2. ALCOBJ OBJ((QSYS2/SYSIXADV *FILE *EXCL)) CONFLICT(*RQSRLS)
  3. DLTF QSYS2/SYSIXADVIX
  4. DLTF QSYS2/CONDIDXA
  5. DLTF QSYS2/SYSIXADV
  6. CHGJOB CCSID(zz)
  7. CALL QSYS/QSQSYSIBM
  8. CALL QSYS/QSQIBMCHK

Si vous n’arrivez pas, allouer le fichier.
Vous allez devoir arrêter index advisor en ajoutant une variable d’environnement
ADDENVVAR ENVVAR(QIBM_NO_INDEX_ADVICE) VALUE( ») LEVEL(SYS) pour que cela soit pris en compte vous devez faire un IPL

Vous devez ensuite refaire la procédure ci dessus attention il faut redémarrer index advisor en enlevant la variable d’environnement par

RMVENVVAR ENVVAR(QIBM_NO_INDEX_ADVICE) LEVEL(SYS)
Vous devez refaire un IPL

Pour contrôler, vous pouvez regarder les variables d’environnement

WRKENVVAR ou
par sql
SELECT
CAST(VAR_BNAME AS CHAR(50)) AS Nom_Variable,
VAR_BVALUE AS Valeur_variable,
VAR_CCSID AS CCSID_variable
FROM QSYS2.ENVIRONMENT_VARIABLE_INFO
WHERE VAR_TYPE = ‘SYSTEM’

et ensuite vous surveillez que le fichier QSYS2/SYSIXADV se remplisse de nouvelles suggestions.

Vous avez des exemples d’utilisation dans ACS.

/par
Alternative à LTO sur vos partitions IBMi

Vous allez installer une nouvelle machine et vous vous posez la question de comment sauvegarder vos informations.
Le réflexe naturel est de mettre en place du LTO, c’est la technologie qui est préconisée par beaucoup d’intégrateurs, mais existe-t-il des alternatives ?
Les DAT pour des questions de fiabilité ont disparu, mais depuis la V7R1, sur le POWER8 vous pouvez utiliser la technologie RDX.

Le RDXest une technologie de disque amovible basée sur USB (USB-3 actuellement), sur des cartouches contenant des disques durs ou SSD 2,5 pouces. Tandberg Data, Lenovo, Dell, HP ou encore Imation proposent cette technologie de sauvegarde.

Vous pouvez l’installer en interne ce qui est recommandé, voire en externe.

https://www.ibm.com/support/knowledgecenter/fr/POWER8/p8hdt/p8hdt_8xx_remdiskdrv.htm

Comment l’utiliser sur votre ibm ?

USB Flash Drives and IBM i

C’est comme la clé USB que vous avez en façade avec laquelle vous pouvez par exemple installer votre partition

Pour gérer ces lecteurs optiques, vous utilisez la commande ==>WRKOPTVOL
Pour initialiser utiliser la commande ==>INZOPT

Vous pouvez voir les informations des lecteurs ==>wrklnk ‘/Qopt/*’

Cette solution ne remplace pas un disque, c’est uniquement pour faire des sauvegardes restaurations

Maintenant comparons avec du LTO

Si vous avez besoin d’une taille modeste et qu’un 1TB suffit, le coût de la solution RDX peut être moins cher environ 20 à 30 %.

Le taux de transfert est d’environ 400 Mo/s contre 160 Mo/s pour du LTO 6 et 300 Mo/s pour le LTO 7
La durée garantie est de 30 ans comme pour les LTO.

https://fr.wikipedia.org/wiki/Linear_Tape-Open

En résumé :


Bien que méconnu dans le monde de L’IBMi, RDX peut être une bonne solution pour les petites sociétés, parce que plus rapide et aussi fiable que LTO


Attention :


Il faut bien vérifier que votre lecteur est bootable
Comme tous les disques externes en USB, cette technologie n’aime pas les coupures électriques.
Vous ne pouvez pas en cas de dépassement de capacité monter un deuxième volume, la limite actuelle est donc de 2TB.

/par
, , Débogage de grandes variables avec RDi

Le débogage avec RDi apporte confort et souplesse, mais il y a un point sur lequel il faut certainement faire un rappel : le débogage de grandes chaines de caractères.

Notre exemple

Simplissime :

Débogage avec RDi

Les variables et leur valeur apparaissent dans la vue dédiée « Variable »

Par contre, « seuls » 10.000 caractères sont affichés, impossible de voir la suite de la variable. De plus, impossible de modifier la variable :

La vue Moniteurs

Cette vue, qui sert déjà pour les variables des programmes CL, va également nous aider pour les variables RPG en permettant plus d’options. Il est possible d’utiliser dans cette vue toutes les syntaxes usuelles de STRDBG avec la commande EV (ou EVAL) qui supporte des compléments, des fonctions intégrées etc …

Vous pouvez ajouter une expression monitorée en faisant un click droit sur une variable puis « Contrôler une expression »

Vous pouvez également saisir manuellement des expressions (vous reconnaîtrez les syntaxes du STRDBG) :

Vous pouvez alors utiliser %SUBSTR, DIGITS etc … Pour vous permettre de cibler une sous-chaîne spécifique par exemple.

Mais impossible de modifier une sous-chaîne par ce moyen :

Modification de variables

Vous devez utiliser cette syntaxe :

Attention : les chaines de caractères sont passées en majuscule ! Sauf à travailler en hexadécimal (est-ce réellement pratique ?)

Extension via APAR SE71579

L’APAR https://www.ibm.com/support/pages/apar/SE71579 permet d’augmenter les limites. Désormais :

Extend the string length limits to bigger values for            
fixed-length and variable-length string values in RDi debug.    
Maximum editable limit is now 4K (4096). Maximum display limit  
is now 30K (30720). The limits are 1K (1024) in the current    
driver.

Vous devez installer les PTF SI71302 (7.3) ou SI71314 (7.4). Après application on peut voir jusqu’à 30720 caractères dans notre cas :

La modification reste limitée à 4Ko.

/par
, Client FTPS avec la nouvelle interface DCM

Pas encore habitué à la nouvelle interface de DCM ? Les options sont rangées différemment, voici donc un guide pour activer le FTPS client !

Informations nécessaires

Lorsque vous avez besoin d’initier une connexion FTP vers un serveur sécurisé par un certificat SSL, vous n’avez pas besoin d’importer le certificat serveur, mais de vous assurer de disposer des autorités de certification (CA) correspondantes.

Par exemple, pour le serveur jupiter.gaia.fr, voici le certificat lié au service FTP :

Ce certificat a été émis par une autorité Let’s Encrypt Authority X3, elle-même issue d’une autorité DST Root CA X3. Ce sont ces deux autorités de certification dont il faut disposer.

Connexion à DCM

La nouvelle interface est disponible ici : http://monIBMi:2006/dcm

Connectez-vous avec un profil fort :

Ouvrez le magasin *SYSTEM :

L’ensemble des certificats vous est proposé, nous allons filtrer pour n’afficher que les autorités de certifications :

Seuls les CA sont affichées désormais. En naviguant / cherchant, on retrouve nos 2 certificats racines :

Les options de recherches / tri :

Importation d’une autorité

Si un ou plusieurs CA racine ne sont pas trouvés, vous devez les importer. Pour cela, transférer le certificat sur l’IFS (via FTP, NetServer etc …).

Définir les CA pour FTPS

Il ne reste maintenant plus qu’à indiquer au client FTP la ou les autorités de certification auxquelles faire confiance : tous les certificats serveurs issus de ces autorités seront autorisés.

Allez sur l’option « Manage Application Definition » :

Filtrer puis sélectionner FTP Client :

Par défaut, si aucun CA n’est indiqué, FTP fait confiance à l’ensemble des CA connu dans le magasin *SYSTEM. Sinon, uniquement aux CA indiqués :

Sélectionner les CA nécessaires puis Define :

Test

Renseigner profil et mot de passe lorsque demandé : la connexion est sécurisée, vos données et les commandes FTP seront cryptées lors de l’échange.

/par
, 5 raisons pour abandonner QDLS

Premièrement, un vitesse de transfert bien moins rapide qu’un fichier classique de l’ifs , en moyenne on mesure des temps de transferts 2,7 fois plus lent sur du ftp .

Deuxièmement, un lien fort avec SNA.
Vous devez être inscrit à la directory SNA pour y accéder.
Vous devez utiliser des commandes spécifiques pour toutes les opérations de manipulation, copie, mise en place de droits, sauvegarde etc…

Troisièmement, une codification très particulière, le nom doit être composé 8 caractères, un point et 3 caractères, les fichiers sont codés en ANSI, qui a l’heure de l’unicode semble bien pauvre.

https://fr.wikipedia.org/wiki/American_Standard_Code_for_Information_Interchange

Quatrièmement, de nombreuses restrictions qui apparaissent au fil du temps et qui posent des problèmes inutiles

Sur le montage des partages
https://www.ibm.com/support/pages/node/637657

Lié à SMB2 en version 7.3
https://www.ibm.com/support/pages/cannot-save-files-office-qdls-smb2-enabled

Cinquièmement, ce n’est pas le sens de l’histoire et comme SNA en général, par exemple Anynet ne fonctionne plus en 7.4.
IBM qui poliment indique que c’est stabilisé, mais nul doute que le débranchement n’a jamais été aussi près.

Conseil : Commencez à analyser son utilisation et envisager sereinement une migration dans l’iFS semble une bonne alternative, et avec un peu d’organisation c’est moins compliqué qu’on le pense …

/par