, Connaitre la taille vos MTI

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.

/par
sinus cosinus tangentes
/par
, , Générer un XLS avec SQL

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

/par
, Analyse CPF1164

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)

/par
, , , SQL – appel de webservice

Depuis la V7R1 (SF99701 – DB2 – niveau 23), on peut invoquer des web service via SQL. Les fonctions se trouvent dans SYSTOOLS.

En V7R4 TR5, sont sorties de nouvelles fonctions, elles se trouvent dans QSYS2.

Outre les fonctions HTTP, celles pour encoder / décoder en base64 et pour encoder / décoder L’URL, ont aussi été implémentées dans QSYS2.

Rappel des différences entre ces fonctions

Tout d’abord les performances. Les fonctions de QSYS2 permettent un gain non négligeable, elles sont basé sur les fonctions AXIS en C natif, contrairement à celles de SYSTOOLS qui sont basées sur des classes java.

Les paramètres dans l’entête ou le corps du message sont transmis en JSON pour les fonctions de QSYS2, à la place de XML pour celle de SYSTOOLS.

La gestion des certificats est simplifiée par l’utilisation de DCM, alors qu’avec les fonctions de SYSTOOLS, il fallait pousser le certificat dans le magasin du runtime java utilisé par les fonctions HTTP. En cas de multiple versions de java installées, il fallait s’assurer de laquelle servait pour les fonctions HTTP. L’ajout du certificat, se faisait via des commandes shell.

Les types et tailles des paramètres des fonctions ont été adaptés pour ne plus être des facteurs limitants de l’utilisation des fonctions SQL, voici quelques exemples :

Certaines utilisations ont aussi été simplifiées en automatisant des tâches.

Prenons l’exemple d’un appel à un web service avec une authentification basique. Le couple profil / mot de passe doit être séparé par « : » et l’ensemble encoder en base64. C’est la norme HTTP.

Dans le cas des fonctions de SYSTOOLS, il fallait effectuer l’ensemble des opérations, alors qu’avec les fonctions de QSYS2, il suffit de passer le profil et le mot de passe dans la propriété BasicAuth. La mise en forme et l’encodage étant faits directement par les fonctions AXIS :

Il y a par contre un cas limitatif des fonctions QSYS2, que IBM a rajouté, alors que la norme HTTP autorise ce type d’appel.

Il s’agit d’avoir une authentification basique sur un appel en http.

Ce cas n’est pas trop contraignant, aujourd’hui le https est la norme et le http quasiment disparu…. quasiment !
Nous rencontrons encore chez nos clients des web services « interne » en http. La migration en https n’étant pas vendeur auprès des directions qui n’y voit aucun gain pour le métier. C’est l’éternel problème des changements structurels en IT.

Dans ces cas, la fonction de QSYS2, renverra une erreur, assez claire !

Le premier réflexe est de voir avec le fournisseur du service s’il ne dispose pas d’une version en https.

Maintenant, si vous n’avez pas d’autre choix que d’appeler un web service en http avec authentification basique, il faudra continuer d’utiliser les fonctions de SYSTOOLS. Dans tous les autres cas, aucune hésitation, utilisez les fonctions de QSYS2.

Mais mettons nous d’accord, de l’authentification basique en http, ce n’est pas de la sécurité, c’est une absurdité.

En http, le message passe en clair sur la trame réseau, avec votre profil / mot de passe, encodé en base 64, et non encrypté, donc en clair eux aussi.

Edit : Précision apportée par Gautier Dumas de CFD-innovation. Merci à lui.
On peut contourner le problème avec les fonctions de QSYS2. Il ne faut pas utiliser la propriété BASICAUTH, mais construire l’authentification basique comme on le faisait avec celle de SYSTOOLS.
VALUES QSYS2.HTTP_GET(
‘http://hostname/wscommon/api/contacts’,
‘{« header »: »Authorization, BASIC dGVzdHVzZXI6dGVzdHB3ZA== »}’);
Il n’y a donc vraiment plus de raison de continuer avec les fonctions de SYSTOOLS !

/par
Diminuer les indicateurs dans vos RPGLE

Pour les nouveaux développeur sur l’IBMi l’utilisation des indicateurs n’est pas naturel, voici comment on peut les diminuer


1) En utilisant l’INFDS pour tester les touches de fonction

2) En utilisant une zone attribut pour les DSPATR

Attention vous ne pourrez pas tous les remplacer


https://www.ibm.com/docs/fr/i/7.5?topic=80-dspatr-display-attribute-keyword-display-files

Voici un exemple

DDS

     A*                                                              
     A                                      DSPSIZ(24 80 *DS3)             
     A                                      CA03                           
     A          R FMT01                                                    
     A*        
     A                                      OVERLAY                        
     A                                  1 28'Test TOUCHES INFDS/ ATTRIBUT' 
     A                                  3  2'Text'                         
     A            ZONE          12A  B  3  9DSPATR(&ATTRIB)                
     A            ATTRIB         1A  P                                     
     A                                 22  3'F3=Exit'

RPGLE

**free                                 
// Exemple d'utilisation d'un écran    
// Sans indicateurs                    
//                                     
Dcl-F TOUCHE WORKSTN INFDS(FICHIERDS) ;
/INCLUDE INFDS_INC                     
/INCLUDE TOUCHE_INC                    
/INCLUDE ATTR_INC                      
// initialisation des attributs        
       Zone = 'Welcome';               
       ATTRIB  = P_HI;                 
// Boucle su F3                        
   DOU Touche_Ecran = F3 ;             
       Exfmt FMT01 ;                   
   ENDDO ;                             
//                                     
   *inlr = *on ;

Remarque :

Vous retrouverez les inculde ici

https://github.com/Plberthoin/PLB/tree/master/INCLUDE

/par
, Comprendre comment un travail interactif est affecté à un sous système.

C’est des entrées écran qui peuvent être indiquées sur des sous systèmes, par les commandes ADDWSE et CHGWSE.

Il va utiliser le nom de l’unité écran, il va faire la recherche dans cet ordre :

-Par nom
-par nom générique
-*all

Vous avez un service SQL qui permet de les visualiser QSYS2.WORKSTATION_INFO

Voici une requête qui permet de voir et comprendre les entrées de votre système

SELECT A.SUBSYSTEM_DESCRIPTION_LIBRARY, A.SUBSYSTEM_DESCRIPTION, WORKSTATION_NAME 
  FROM QSYS2.WORKSTATION_INFO as A Join  QSYS2.SUBSYSTEM_INFO AS B
  on A.SUBSYSTEM_DESCRIPTION_LIBRARY= b.SUBSYSTEM_DESCRIPTION_LIBRARY and
  A.SUBSYSTEM_DESCRIPTION = b.SUBSYSTEM_DESCRIPTION
  and B.STATUS = 'ACTIVE' and ALLOCATION = '*SIGNON'
  where WORKSTATION_NAME not like('%*%') 
 union
 SELECT A.SUBSYSTEM_DESCRIPTION_LIBRARY, A.SUBSYSTEM_DESCRIPTION, WORKSTATION_NAME 
  FROM QSYS2.WORKSTATION_INFO as A Join  QSYS2.SUBSYSTEM_INFO AS B
  on A.SUBSYSTEM_DESCRIPTION_LIBRARY= b.SUBSYSTEM_DESCRIPTION_LIBRARY and
  A.SUBSYSTEM_DESCRIPTION = b.SUBSYSTEM_DESCRIPTION
  and B.STATUS = 'ACTIVE' and ALLOCATION = '*SIGNON'
  where WORKSTATION_NAME like('%*%')  
 union
 SELECT A.SUBSYSTEM_DESCRIPTION_LIBRARY, A.SUBSYSTEM_DESCRIPTION, WORKSTATION_TYPE 
  FROM QSYS2.WORKSTATION_INFO as A Join  QSYS2.SUBSYSTEM_INFO AS B
  on A.SUBSYSTEM_DESCRIPTION_LIBRARY= b.SUBSYSTEM_DESCRIPTION_LIBRARY and
  A.SUBSYSTEM_DESCRIPTION = b.SUBSYSTEM_DESCRIPTION
  and B.STATUS = 'ACTIVE' and ALLOCATION = '*SIGNON'
  where WORKSTATION_TYPE = '*ALL'

En principe ca représentera l’ordre de recherche dans votre #ibmi

Remarque :

Quand 2 entrées sont démarrés avec le même critère c’est le premier qui est pris en compte
Ici les entrées QPADEV* entrerons dans QINTER
On peut également faire des entrées par type les 2 principaux sont
IBM-3477-FC 132
IBM-3179-2 80
https://www.rfc-editor.org/rfc/rfc1205
Mais à éviter pas simple à gérer

/par