, , CCSID des fichiers sources

Retour sur une problématique récurrente et souvent mal comprise, donc mal gérée … Et qui pourrait bien s’amplifier avec l’usage plus intensif de l’Open Source.

Vous utilisez historiquement des fichiers sources (objet *FILE attribut PF-SRC) pour stocker vos sources : ces fichiers sont créés avec un CCSID, par défaut le CCSID du job dans lequel vous exécutez la commande CRTSRCPF

Usuellement vous obtiendrez des fichiers sources avec un CCSID 297 ou 1147 pour la France. Si vos machines sont « incorrectement » réglées, un CCSID 65535 (hexadécimal).

Mais également, par restauration d’autres produits, certainement des fichiers avec un CCSID 37 (US).

Pour les langages de programmation (dont le SQL), le CCSID du fichier source est important pour les constantes, qui peuvent par définition êtres des caractères nationaux quelconques. Quant aux instructions, la grammaire des langages les définis sans ambiguïtés.

Caractères spéciaux / nationaux

Pour toutes les commandes, instructions, éléments du langage, pas de soucis d’interprétation

A la compilation, les constantes sont interprétées suivant le CCSID du job, pas celui du source !

En général, les deux CCSID sont identiques.

Par contre, pour les caractères spéciaux utilisés, si l’on regarde de plus près le cas du CL, la documentation indique :

Voilà qui explique les fameuses transformations de @ en à !

En synthèse : le compilateur considère tous les éléments du langage comme étant en CCSID 37, hors les constantes alphanumériques et les quelques caractères listés ici.

Pour le CL : impossible d’utiliser les opérateurs symboliques |> (*BCAT), |< (*TCAT) et || (*CAT)

Le caractère | est mal interprété. Vous devez le remplacer par un !, ou utiliser les opérateurs non symboliques (*BCAT, *TCAT et *CAT).

Pour le SQL : impossible d’utiliser l’opérateur || (même raison).

Vous devez le remplacer par un !!, ou utiliser l’opérateur concat.

Evolution du RPG

Le principe est le même.

Toutefois le langage vous permet également de contrôler le CCSID des variables déclarées. Et depuis la 7.2, de nouvelles directives de pré-compilation permettent d’indiquer des valeurs de CCSID par défaut par bloc de source :

Et pour l’IFS ?

Sur l’IFS, chaque fichier (source ou non) dispose également d’un CCSID. Sa valeur dépend principalement de la façon de créer le fichier (par un éditeur type RDi/VSCode, partage netserver, transfert FTP …).

Premier point d’attention : l’encodage du contenu du fichier doit correspondre à son attribut *CCSID !

VSCode vous indique le CCSID de la donnée, par exemple :

Mais :

1252 = Windows occidental (proche de l’UTF-8 mais pas identique). La raison est que VSCode travaille naturellement en UTF-8.

RDi gère correctement l’encodage/décodage par rapport à la description du fichier.

Pour les autres outils, à voir au cas par cas !

Evolution des compilateurs

Les compilateurs C, CPP, CL, RPG, COBOL supportent désormais (PTF en fonction des compilateurs) un paramètre TGTCCSID :

En réalité ce paramètre a été ajouté pour permettre la compilation plus facilement depuis l’IFS, principalement depuis des fichiers IFS en UTF-8.

Cela ne règle pas nos problèmes précédents, les éléments du langage n’étant pas concernés : nous auront toujours le problème d’interprétation du |

Par contre, c’est utile pour la bonne interprétation des constantes lorsque le job de compilation a un CCSID du source. Et cela permet une meilleure intégration dans les outils d’automatisation.

Conseils

Eviter les caractères spéciaux !

  • N’utilisez pas |>, |< ou || en CL
  • N’utilisez pas || en SQL

Mais on ne peut pas toujours : nous avons voulu compiler QSHONI depuis le build fourni (https://github.com/richardschoen/QshOni?tab=readme-ov-file#installing-and-building-qshoni-via-git-clone-and-buildsh)

Le script propose d’indiquer un CCSID pour les fichiers sources. Mais la seule solution viable est de compiler avec un job en CCSID 37 :

  • soit CHGJOB CCSID(37) avant de lancer le script
  • soit vous pouvez vous créer un profil dédié en CCSID 37 si ces opérations sont récurrentes

Tant que vous n’avez pas de caractères nationaux dans le codes !

Retrouver le CCSID de ses fichiers sources

SELECT f.SYSTEM_TABLE_NAME,
       f.SYSTEM_TABLE_SCHEMA,
       c."CCSID"
    FROM qsys2.systables f
         JOIN qsys2.syscolumns c
             ON (c.SYSTEM_TABLE_NAME, c.SYSTEM_TABLE_SCHEMA) = (f.SYSTEM_TABLE_NAME, f.SYSTEM_TABLE_SCHEMA)
    WHERE f.file_type = 'S' AND
LEFT(f.system_table_name, 8) <> 'EVFTEMPF' AND
          c.SYSTEM_COLUMN_NAME = 'SRCDTA'
    ORDER BY c."CCSID",
             f.SYSTEM_TABLE_SCHEMA,
             f.SYSTEM_TABLE_NAME;

Références

https://www.ibm.com/support/pages/ifs-stmf-ccsids-1252-437-and-819

https://www.ibm.com/docs/en/i/7.4?topic=languages-language-compilers-ccsid

https://www.ibm.com/mysupport/s/fix-information/aDrKe000000PE0UKAW/fi0132711?language=en_US

https://www.ibm.com/mysupport/s/defect/aCIKe000000XohkOAC/dt418562?language=en_US

https://www.ibm.com/docs/en/i/7.5?topic=elements-cl-character-sets-values

https://www.ibm.com/docs/en/i/7.5?topic=values-symbolic-operators

https://www.ibm.com/docs/fr/i/7.5?topic=languages-language-compilers-ccsid

https://www.ibm.com/support/pages/have-you-heard-set-and-restore-directives

https://github.com/richardschoen/QshOni

/par
, Générer des données avec MAPEPIRE en PYTHON

/

Nouveau venu dans les bibliothèques middleware pour IBMi, MAPEPIRE est un outil simple pour récupérer des données de votre serveur et les travailler sur de applications tierces, telles que des outils d’analyse de données, de la bureautique, etc.

Nous allons vous présenter la possibilité d’installer et d’utiliser le produit simplement

  • sur le serveur
  • sur votre client, en fonction du langage que vous souhaitez utiliser.
  • Les langages disponibles pour l’instant sont :
  • JAVA, NODE.JS, PYTHON

Ici, l’exemple détaillé sera effectué avec le langage PYTHON.

Nous n’intervenons pas dans cet article sur les différents paramétrages de l’outil. Nous y reviendrons dans un article suivant. (exit points, ports, etc.)

Serveur

Installation de MAPEPIRE sur le serveur

yum install mapepire

mapepire sera installé dans le répertoire

/qOpenSys/pkgs/bin

Démarrage

Note : dans cet article, on ne détaille ps le démarrage automatique

nohup /qopensys/pkgs/bin/mapepire &

Client

Notre exemple consiste à lister tous les travaux actifs en cours, les répertorier dans une trame PANDAS, puis de sauvegarder les données dans une feuille EXCEL

Pré requis

  • Python 3 installé et fonctionnel
  • un répertoire pour le code
  • Facultatif : un environnement virtuel
  • EXCEL
  • librairies installées :
    • pandas
    • openpyxl (factultatif)

installation MAPEPIRE

sous l’environnement virtuel (si configuré) ou sur l’environnement global

pip install mapepire-python

le code de notre exemple TEST.PY

#mapepire

#mapepire
from mapepire_python.client.sql_job import SQLJob
from mapepire_python import DaemonServer

#pandas
import pandas as pd
#--------------------------------------------------
creds = DaemonServer(
    host="serveuràcontacter",
    port=8076,
    user="utilisateur",
    password='motdepasse',
    ignoreUnauthorized=True,
)

job = SQLJob()
res = job.connect(creds)

#
# Travaux actifs
#
result = job.query_and_run("\
            SELECT \
                count(*) as totaltravaux\
            FROM TABLE (QSYS2.ACTIVE_JOB_INFO()) \
            ")
countjobs = result['data'][0]['TOTALTRAVAUX']

startT = datetime.now()
result = job.query_and_run("SELECT \
                JOB_NAME, JOB_TYPE, JOB_STATUS, \
                SUBSYSTEM, MEMORY_POOL, THREAD_COUNT \
            FROM TABLE ( \
                QSYS2.ACTIVE_JOB_INFO(\
                    RESET_STATISTICS => 'NO',\
                    SUBSYSTEM_LIST_FILTER => '',\
                    JOB_NAME_FILTER => '*ALL',\
                    CURRENT_USER_LIST_FILTER => '',\
                    DETAILED_INFO => 'NONE'\
                )\
            ) \
            ORDER BY \
                SUBSYSTEM, RUN_PRIORITY, JOB_NAME_SHORT, JOB_NUMBER\
            ",
            rows_to_fetch=countjobs)

endT = datetime.now()
delta = endT - startT
print(f"travaux actifs récupérés en {str(delta)} secondes")
#insertion des résultats dans un Frame PANDAS
dframActj = pd.DataFrame(result['data'])
#print(dframActj)

#
#récupération des utilisateurs dans une 2ème Frame (dframUsesrs)
#
startT = datetime.now()
result = job.query_and_run("""
        WITH USERS AS (
            SELECT 
               CASE GROUP_ID_NUMBER 
                   WHEN 0 THEN 'USER' 
                   ELSE 'GROUP' 
               END AS PROFILE_TYPE, 
               A.*, 
               CAST(TEXT_DESCRIPTION AS VARCHAR(50) CCSID 1147) 
                   AS TEXT_DESCRIPTION_CASTED 
            FROM ( 
                    SELECT * 
                        FROM QSYS2.USER_INFO 
                ) AS A 
        ) 
        SELECT * 
            FROM USERS 
        """,
        rows_to_fetch=500)
endT = datetime.now()
delta = endT - startT
print(f"Utilisateurs récupérés en {str(delta)} secondes")
#insertion des résultats dans un Frame PANDAS
dframUsers = pd.DataFrame(result['data'])
#print(dframUsers)


print("Sauvegarde vers Excel")
with pd.ExcelWriter('/users/ericfroehlicher/Documents/donnes_dataframe.xlsx') as writer:  
    dframActj.to_excel(writer, sheet_name='ACTjobs')
    dframUsers.to_excel(writer, sheet_name='Utilisateurs')

Un peu d’explications

1 – Import des resources dont on a besoin

#mapepire
from mapepire_python.client.sql_job import SQLJob
from mapepire_python import DaemonServer

#pandas
import pandas as pd

2 – Déclaration des données de connexion (serveur, utilisateur, mot def passe)

CONSEIL: pour l’instant, toujours laisser le port 8076

#--------------------------------------------------
creds = DaemonServer(
    host="serveuràcontacter",
    port=8076,
    user="utilisateur",
    password='motdepasse',
    ignoreUnauthorized=True,
)

P

3 – connexion au serveur

job = SQLJob()
res = job.connect(creds)

Ici, on crée un travail simple, synchrone (SQLJob)

4 – les requêtes synchrones

#comptage des travaux (pour l'exemple de l'utilisation du json)
result = job.query_and_run("\
            SELECT \
                count(*) as totaltravaux\
            FROM TABLE (QSYS2.ACTIVE_JOB_INFO()) \
            ")
# je récupère directement la valeur lue
countjobs = result['data'][0]['TOTALTRAVAUX']

result = job.query_and_run("SELECT \
                JOB_NAME, JOB_TYPE, JOB_STATUS, \
                SUBSYSTEM, MEMORY_POOL, THREAD_COUNT \
            FROM TABLE ( \
                QSYS2.ACTIVE_JOB_INFO(\
                    RESET_STATISTICS => 'NO',\
                    SUBSYSTEM_LIST_FILTER => '',\
                    JOB_NAME_FILTER => '*ALL',\
                    CURRENT_USER_LIST_FILTER => '',\
                    DETAILED_INFO => 'NONE'\
                )\
            ) \
            ORDER BY \
                SUBSYSTEM, RUN_PRIORITY, JOB_NAME_SHORT, JOB_NUMBER\
            ",
            rows_to_fetch=countjobs)

A

Les données obtenues sont au format JSON. (voir plus bas les données brutes)

5 – Insertion des données dans un frame PANDAS et sauvegarde vers EXCEL

#insertion des résultats dans un Frame PANDAS
dframe = pd.DataFrame(result['data'])
print(dframe)

print("Sauvegarde vers Excel")
dframe.to_excel(
     "/users/ericfroehlicher/Documents/travaux_actifs.xlsx",
    sheet_name="Travaux actifs", 
    index=False
)

Retour de mapepire

Le flux de données renvoyé par MAPEPIRE contient l’ensemble des données et méta données au format JSON.

Voici un extrait du flux retourné (exemple sur 5 travaux)

{
  'id': 'query4', 
  'has_results': True, 
  'update_count': -1, 
  'metadata': 
  {
     'column_count': 6, 
     'job': '488835/QUSER/QZDASOINIT', 
     'columns':[
      {
        'name': 'JOB_NAME', 
        'type': 'VARCHAR', 
        'display_size': 28, 
        'label': 'JOB_NAME'
      }, 
      {
        'name': 'JOB_TYPE', 
        'type': 'VARCHAR', 
        'display_size': 3, 
        'label': 'JOB_TYPE'
      }, 
      {
        'name': 'JOB_STATUS', 
        'type': 'VARCHAR', 
        'display_size': 4, 
        'label': 'JOB_STATUS'
      },    
      {
        'name': 'SUBSYSTEM', 
        'type': 'VARCHAR', 
        'display_size': 10, 
        'label': 'SUBSYSTEM'
      }, 
      {
        'name': 'MEMORY_POOL', 
        'type': 'VARCHAR', 
        'display_size': 9, 
        'label': 'MEMORY_POOL'
      }, 
      {
        'name': 'THREAD_COUNT', 
        'type': 'INTEGER',
        'display_size': 11, 
        'label': 'THREAD_COUNT'
      }
      ]
  }, 
  'data':[
  {
    'JOB_NAME': '216350/QSYS/ARCAD', 
    'JOB_TYPE': 'SBS', 
    'JOB_STATUS': 'DEQW', 
    'SUBSYSTEM': 'ARCAD', 
    'MEMORY_POOL': 'BASE', 
    'THREAD_COUNT': 2
  }, 
  {
    'JOB_NAME': '216369/ARCAD_NET/ARCAD', 
    'JOB_TYPE': 'ASJ', 
    'JOB_STATUS': 'MSGW', 
    'SUBSYSTEM': 'ARCAD', 
    'MEMORY_POOL': 'BASE', 
    'THREAD_COUNT': 1
  }, 
  {
    'JOB_NAME': '216349/QSYS/CONTROL4I', 
    'JOB_TYPE': 'SBS', 
    'JOB_STATUS': 'DEQW', 
    'SUBSYSTEM': 'CONTROL4I', 
    'MEMORY_POOL': 'BASE', 
    'THREAD_COUNT': 2
  }, 
  {
    'JOB_NAME': '216373/CTL4I/CTAGENTSPW', 
    'JOB_TYPE': 'PJ', 
    'JOB_STATUS': 'PSRW', 
    'SUBSYSTEM': 'CONTROL4I', 
    'MEMORY_POOL': 'BASE', 
    'THREAD_COUNT': 1
  }, 
  {
    'JOB_NAME': '216377/CTL4I/CTAGENTSPW', 
    'JOB_TYPE': 'PJ', 
    'JOB_STATUS': 'PSRW', 
    'SUBSYSTEM': 'CONTROL4I', 
    'MEMORY_POOL': 'BASE', 
    'THREAD_COUNT': 1
  }
  ], 
  'is_done': False, 
  'success': True
}

Résultats

/par
, , Regroupements et Analyses avec SQL

Préambule

Cet article est librement inspiré d’une session animée par Birgitta HAUSER lors des universités de l’IBMi du 19 et 20 novembre 2024. Je remercie également Laurent CHAVANEL avec qui j’ai partagé une partie de l’analyse.

Présentation

Pour réaliser cet article, nous avons créé un fichier de données météorologiques quotidiennes de quatre villes françaises pendant cinq années (de 2020 à 2024).

Les données contenues dans le fichier CLIMAT sont :

  • La ville
  • Le jour (AAAA-MM-JJ)
  • Les précipitations en mm
  • La température minimale du jour (en °C)
  • La température maximale du jour (en °C)
  • La température moyenne du jour (en °C)
  • L’amplitude de température du jour (en °C)

Agréger les données avec LISTAGG

Cette fonction permet de rassembler dans un seul champ, les données issues de plusieurs lignes

SELECT VILLE,
       YEAR(DATEREL) Annee,
       MONTHNAME(DATEREL) Mois,
       LISTAGG(TMOY || '°C', ', ') "Températures moyennes du Mois"
    FROM CLIMAT
    WHERE YEAR(DATEREL) = 2020
          AND MONTH(DATEREL) = 1
    GROUP BY VILLE,
             YEAR(DATEREL),
             MONTHNAME(DATEREL)

Données brutes

Données avec la fonction LISTAGG

Agréger les données avec GROUP BY

Comme première analyse, on souhaite faire des statistiques annuelles pour chaque ville sur chaque année.

On utilise les fonctions :

  • SUM qui va nous permettre de faire le total des précipitations
  • MIN pour extraire la température minimale
  • MAX pour extraire la température maximale
  • AVG pour faire une moyenne (de la température ainsi que de l’amplitude des températures)

On notera que TOUTES les colonnes sans fonction d’agrégation doivent être regroupées dans un GROUP BY et nous ajoutons un ORDER BY pour classer nos données.

SELECT YEAR(DATEREL) "Année",
       VILLE,
       SUM(MMPLUIE) "Total des précipitations",
       MIN(TMIN) "Température Minimale",
       MAX(TMAX) "Température Maximale",
       CAST(AVG(TMOY) AS DEC(4, 2)) "Température Moyenne",
       CAST(AVG(TAMPLI) AS DEC(4, 2)) "Amplitude Moyenne"
    FROM CLIMAT
    GROUP BY YEAR(DATEREL),
             VILLE
    ORDER BY VILLE,
             "Année";

Utilisation de ROLLUP

Nous voulons réaliser un total des précipitations sur les cinq dernières années, pour chaque commune de notre fichier tout en conservant un total pour chaque année observée

SELECT VILLE,
       YEAR(DATEREL) "Année",
       SUM(MMPLUIE) "Total des précipitations"
    FROM CLIMAT
    GROUP BY ROLLUP (VILLE, YEAR(DATEREL))
    ORDER BY VILLE,
             "Année";

L’extension ROLLUP apportée au GROUP BY, nous permet d’avoir des sous totaux par :

  • VILLE / ANNEE
  • VILLE

Ainsi qu’un total général (ce qui, dans le cas présent n’a que peu d’intérêt, je vous l’accorde)

Autre exemple, le total des précipitations par mois pour une seule ville.

SELECT VILLE,
       YEAR(DATEREL) "Année",
       MONTH(DATEREL) Mois,
       SUM(MMPLUIE) "Total des précipitations"
    FROM GG.CLIMAT
    WHERE VILLE = 'LYON'
    GROUP BY ROLLUP (VILLE, YEAR(DATEREL), MONTH(DATEREL));

…

…

Utilisation de CUBE

Cette extension nous permet d’obtenir plusieurs type de sous-totaux dans une même extraction

SELECT VILLE,
       YEAR(DATEREL) Annee,
       MONTH(DATEREL) Mois,
       SUM(MMPLUIE) "Total des précipitations"
    FROM CLIMAT
    WHERE VILLE = 'LYON'
    GROUP BY CUBE (VILLE, YEAR(DATEREL), MONTH(DATEREL));
  • Par VILLE et ANNEE
  • Par VILLE et sur la période de mesure
  • Sur la période de mesure (valeur identique à la précédente car une seule ville sélectionnée ici)
  • Par VILLE pour chaque mois de la période sélectionnée (ou simplement pour chaque mois de la période sélectionnée)

Pour Lyon, on a, par exemple, un total de précipitations de 188.00 mm pour tous les mois de janvier ou 400.00 mm pour tous les mois de septembre entre 2020 et 2024

Utilisation de GROUPING SETS

Cette extension permet de faire des regroupements choisis. Cela permet de faire une sélection des regroupements plus fine que celle réalisée avec CUBE.

Select VILLE, Year(DATEREL) Annee, month(DATEREL) Mois,
       sum(MMPLUIE) "Total des précipitations",
       Cast(Avg(TMOY) as Dec(4, 2)) "Température Moyenne"
   From CLIMAT
   WHERE VILLE in ('LYON', 'MARSEILLE', 'PARIS')   
   Group By GROUPING SETS((VILLE, YEAR(DATEREL)), (VILLE, month(DATEREL)))
   ORDER BY VILLE, YEAR(DATEREL), month(DATEREL);

Dans cet exemple, on fait des regroupements par VILLE/ANNEES et VILLE/MOIS dans une seule extraction

Tableau Croisé avec Agrégation et CASE

Avec SUM

Select VILLE, Year(DATEREL) Annee,
    sum(case when month(DATEREL)= 1 then MMPLUIE else 0 end) as "mm Janvier",     
    sum(case when month(DATEREL)= 2 then MMPLUIE else 0 end) as "mm Février", 
    sum(case when month(DATEREL)= 3 then MMPLUIE else 0 end) as "mm Mars", 
    sum(case when month(DATEREL)= 4 then MMPLUIE else 0 end) as "mm Avril", 
    sum(case when month(DATEREL)= 5 then MMPLUIE else 0 end) as "mm Mai", 
    sum(case when month(DATEREL)= 6 then MMPLUIE else 0 end) as "mm Juin", 
    sum(case when month(DATEREL)= 7 then MMPLUIE else 0 end) as "mm Juillet", 
    sum(case when month(DATEREL)= 8 then MMPLUIE else 0 end) as "mm Aout", 
    sum(case when month(DATEREL)= 9 then MMPLUIE else 0 end) as "mm Septembre", 
    sum(case when month(DATEREL)=10 then MMPLUIE else 0 end) as "mm Octobre", 
    sum(case when month(DATEREL)=11 then MMPLUIE else 0 end) as "mm Novembre", 
    sum(case when month(DATEREL)=12 then MMPLUIE else 0 end) as "mm Décembre",
    sum(MMPLUIE) as "Total Précipitations"
    FROM CLIMAT
    Group by Ville, Year(DATEREL)
    order by Ville, Year(DATEREL);

Avec AVG

Select VILLE, Year(DATEREL) Annee,    
    cast(avg(case when month(DATEREL)= 1 then TMOY else NULL end) as Dec(4, 2)) as "°C Janvier",     
    cast(avg(case when month(DATEREL)= 2 then TMOY else NULL end) as Dec(4, 2)) as "°C Février", 
    cast(avg(case when month(DATEREL)= 3 then TMOY else NULL end) as Dec(4, 2)) as "°C Mars", 
    cast(avg(case when month(DATEREL)= 4 then TMOY else NULL end) as Dec(4, 2)) as "°C Avril", 
    cast(avg(case when month(DATEREL)= 5 then TMOY else NULL end) as Dec(4, 2)) as "°C Mai", 
    cast(avg(case when month(DATEREL)= 6 then TMOY else NULL end) as Dec(4, 2)) as "°C Juin", 
    cast(avg(case when month(DATEREL)= 7 then TMOY else NULL end) as Dec(4, 2)) as "°C Juillet", 
    cast(avg(case when month(DATEREL)= 8 then TMOY else NULL end) as Dec(4, 2)) as "°C Aout", 
    cast(avg(case when month(DATEREL)= 9 then TMOY else NULL end) as Dec(4, 2)) as "°C Septembre", 
    cast(avg(case when month(DATEREL)=10 then TMOY else NULL end) as Dec(4, 2)) as "°C Octobre", 
    cast(avg(case when month(DATEREL)=11 then TMOY else NULL end) as Dec(4, 2)) as "°C Novembre", 
    cast(avg(case when month(DATEREL)=12 then TMOY else NULL end) as Dec(4, 2)) as "°C Décembre", 
    cast(avg(TMOY) as Dec(4, 2)) as "°C Moyenne"
    FROM CLIMAT
    Group by Ville, Year(DATEREL)
    order by Ville, Year(DATEREL);

Note sur l’utilisation de SUM vs AVG dans un tableau croisé

SUM totalise par mois, tandis que AVG calcule la moyenne.

Utilisation de ELSE NULL au lieu de ELSE 0 :

  • Avec ELSE 0, la fonction AVG prend en compte les zéros, ce qui fausse la moyenne si une valeur est absente.
  • NULL est ignoré par AVG, garantissant une moyenne correcte.

Par exemple, si nous écrivons 

AVG(CASE WHEN MONTH(DATEREL)= 1 THEN TMOY ELSE 0 END)

Alors la requête va additionner les températures moyennes de janvier MAIS aussi ajouter 0 pour tous les jours qui ne sont pas en janvier, le résultat sera donc faux au regard des températures mesurées… il en sera de même pour chaque mois.

La bonne pratique, pour l’utilisation de la fonction AVG est donc :

AVG(CASE WHEN MONTH(DATEREL)= 1 THEN TMOY ELSE NULL END)

Utiliser SQL pour faire une analyse

Nous pouvons également combiner différentes fonctions de SQL pour effectuer une analyse avec un rendu facilement lisible.

Dans le cas ci-dessous nous combinons CASE à différents niveaux, avec SUM afin de voir si les précipitations annuelles de chaque ville sont au-dessus ou en dessous des moyennes connues et les classer par rapport à un niveau de 800mm (choisi arbitrairement pour l’exercice)

SELECT VILLE,
       YEAR(DATEREL) Annee,       
       CASE 
            WHEN VILLE = 'KOUROU' THEN
               CASE
                   WHEN SUM(MMPLUIE) > 2560 THEN 'Excédent'
                   ELSE 'Déficit'
               END
            WHEN VILLE = 'LYON' THEN
               CASE
                   WHEN SUM(MMPLUIE) > 830 THEN 'Excédent'
                   ELSE 'Déficit'
               END
            WHEN VILLE = 'MARSEILLE' THEN
               CASE
                   WHEN SUM(MMPLUIE) > 453 THEN 'Excédent'
                   ELSE 'Déficit'
               END
            WHEN VILLE = 'PARIS' THEN
               CASE
                   WHEN SUM(MMPLUIE) > 600 THEN 'Excédent'
                   ELSE 'Déficit'
               END
       END "NIVEAU",        
       CASE
           WHEN SUM(MMPLUIE) > 800 THEN SUM(MMPLUIE)
           ELSE 0
       END "> 800 mm",
       CASE
           WHEN SUM(MMPLUIE) <= 800 THEN SUM(MMPLUIE)
           ELSE 0
       END "<= 800 mm"
    FROM CLIMAT
    GROUP BY Ville, YEAR(DATEREL)
    ORDER BY Ville, YEAR(DATEREL);

/par
, , Nommez vos indicateurs en RPGLE

Les indicateurs font parti intégrante des développements RPG, c’est des booléens dont le nom commence par *IN, certain ont plus ou moins disparu (remplacé par des %EOF, %FOUND, ou un SQLCODE ) , mais les indicateurs *IN01 à *IN99 continuent à être utilisé par exemple dans les DSPF.

On va essayer de voir une méthode qui rendra le code plus lisible pour les jeunes recrues qui devront faire de la maintenance

On va prendre un exemple à partir d’un DSPF

Votre écran devra avoir le mot clé INDARA qui indique qu’on va gérer les indicateurs dans un buffer séparé

Pour la déclaration de votre écran vous devrez lui indiquer le mot clé INDDS qui indiquera la DS qui contiendra le tableau de ces indicateurs.

voici un exemple de DS avec les indicateurs nommé

Exemple :

*IN03 / SORTIR

Voici ci dessus un exemple de code RPG FREE, utilisant les noms indiqués dans la DS, on voit tout de suite mieux ce qu’on fait

Remarque :

Vous pouvez mettre votre DS dans un include et le déclarer dans chaque programme , ce qui permettra d’uniformiser votre tableau des indicateurs

/par
, 5 Astuces SQL sur les dates

s

Voici 5 fonctions qui peuvent vous intéresser pour manipuler des dates en SQL.

je vous rappelle que pour les utiliser, vos zones doivent être au format date et
si ce n’est pas le cas vous devrez utiliser la fonction date pour vous mettre dans le format attendu
Exemple :
values date(‘2012-01-01’)

Il est fortement conseillé si manipulez des dates de vous mettre dans un format *ISO pour éviter les problèmes de bascule des dates à 6 positions

1) Vous avez besoin de connaitre le premier jour du mois
Vous avez la fonction FIRST_DAY()
values FIRST_DAY(‘2012-12-12’) ;
renverra
2012-12-01

pour le jour en cours
FIRST_DAY(current date) = current date

2) Vous avez besoin de connaitre le dernier jour du mois
Vous avez la fonction LAST_DAY()
values LAST_DAY(‘2012-12-12’) ;
renverra
2012-12-31

Pour le jour en cours
LAST_DAY(current date) = current date

3) Vous voulez connaitre le numéro du jour dans l’année , le rang julien
Vous avez la fonction DAYOFYEAR()

values DAYOFYEAR(‘2012-12-12’)
renverra
347

4) Connaitre le jour de la semaine
Vous avez la fonction DAYOFWEEK()
elle vous renverra un numéro de 1 à 7 qui est le numéro du jour dans la semaine attention 1 c’est le dimanche
values DAYOFWEEK(‘2012-12-12’)
vous renverra 4
Si vous voulez commencer le lundi
values DAYOFWEEK(‘2012-12-12’) – 1 , attention bien sur, un dimanche vous aurez 0

5) Connaitre le nombre de jours depuis le premier janvier 01

Vous avez la fonction DAYS()

values DAYS(‘2012-12-12’)
renverra
734849
Cette fonction sert souvent pour calculer le nombre de jours entre 2 dates

values DAYS(current date) – DAYS(‘2012-12-12’)
renverra
4429

Remarque
il y a d’autres fonctions que vous pouvez utiliser, mais celles la nous semblent incontournables

/par
, Historique d’une macro-commande Arcad

Voici comment visualiser l’historique d’une macro-commande Arcad

Objectifs :

Lorsqu’une macro-commande se termine en anomalie, la joblog peut ne pas être toujours évidente à décrypter ou pire elle peut avoir été supprimée.

Cet article a pour objectif de présenter process à suivre pour pouvoir visualiser chaque étape d’exécution d’une macro-commande Arcad.

Pour cela il faut :

  1. Retrouver l’instance de la macro commande à analyser
  2. Afficher l’historique de l’instance à analyser

1)    Recherche de l’instance de la macro-commande à analyser :

  • Lancer la commande AWRKMACCMD pour accéder à la liste des macro-commandes Arcad.
  • Lancer l’option 5 AFFICHER sur la macro-commande concernée.

Une fois la macro-commande affichée :

  • Faire F9 pour afficher toutes les instances de lancement de la macro-commande

La liste des instances d’exécution de la macro-commande s’affiche.

Dans l’exemple ci-dessus on voit que la 25eme instance n’a pas abouti (Etat à ABN = Abandon).

  • La touche F11 permet de changer de vue et ainsi afficher les dates de traitement, cela facilite l’identification précise de l’instance à analyser.

2)    Afficher l’historique de l’instance à analyser

  • Lancer l’option 13 (Historique) sur l’instance à analyser
  • L’historique des commandes de la macro-commande sera alors affiché

Pour rappel :

  • Les lignes en rouge correspondent aux alertes Arcad
    Attention : ce ne sont pas toujours des anomalies.
  • La touche F8 permet d’afficher l’intégralité de la commande Arcad sur laquelle est positionné le curseur.
    Cela permet de visualiser toute la commande avec tous ses paramètres
  • La touche F16 permet de rechercher une chaine de caractères dans l’ensemble des commandes affichées. Les lignes contenant la chaine de caractères recherchées seront affichées en surbrillance.

Le nombre d’occurrences trouvées sera affiché en bas de l’écran.

/par
, Conversion DS RPG3 vers RPG4

Conversion DS RPG3 vers RPG4

En convertissant vos programmes par la commande CVTRPGSRC, vous pouvez avoir un petit effet de bord sur les DS qui ne sont pas initialisées par défaut.

Vous avez 2 solutions :

  • la première ne marche que pour les zones étendues, à la compile vous pouvez indiquer

FIXNBR(*ZONED *INPUTPACKED)

  • Mais la meilleure solution est d’ajouter INZ sur votre Data structure

Exemple

D JOUR DS INZ <—– ici
D AN£ 1 4
D MO£ 6 7 0
D JR£ 9 10

Les zones seront initialisées avec la valeur par défaut du type déclaré, dans notre cas 0

Voici une petite requête pour vous aider, derrière un CVTRPGSRC par exemple

Faites un alias sur votre membre

CREATE ALIAS QTEMP/INPUT FOR GDATA/QRPGLESRC (votre source RPGLE)

Ensuite passer cette requête :

update input
set SRCDTA = substr(srcdta, 1, 59) concat ‘INZ’
where substr(srcdta, 6, 1) = ‘D’
and substr(srcdta, 23, 3) = ‘ DS’

INZ est ajouté en position 59, au cas où il y ait un autre mot clé avant

PS :
Attention à l’ordre des overlays et l’INFDS qui ne peut pas être initialisé

/par
, Mise en place d’un dictionnaire de services

Mise en place d’un dictionnaire de services

Un nouvel article proposé par Jérôme Clément qui est un spécialiste de la modernisation d’applications #ibmi , merci à lui pour ces informations éclairées

Objectifs

Cet article a pour objectif de montrer quels sont les avantages qu’offrent la mise en place d’un dictionnaire de services. Je présenterai également un exemple de dictionnaire de services afin de mettre en évidence les différentes possibilités qu’il met à disposition des équipes de développements.

Pourquoi mettre en place un dictionnaire de services

La mise en place d’un dictionnaire a pleinement sa place dans la démarche de modernisation comme nous avons pu le voir dans mon article précédent : https://lnkd.in/ecDXQQPZ

En effet, l’un des objectifs de l’utilisation de programmes de services étant d’éviter la redondance de code, il faut aussi éviter d’avoir plusieurs programmes de services répondant à la même fonctionnalité.

Et il faut également inciter les développeurs à réutiliser les programmes de services déjà existants.

Pour cela, il faut que les développeurs puissent, facilement :

– Consulter la liste des procédures exportées déjà présentes sur le système.

– Rechercher quels services peuvent être utilisés pour répondre à leurs besoins.

– Identifier les paramètres en entrée et en sortie de chaque procédure exportée.

– Vérifier que le service qu’ils souhaitent mettre ne place n’existe pas déjà.

Le rôle du dictionnaire de services est de répondre à chacun de ces besoins.

Exemple de dictionnaire de services

Voici un exemple de dictionnaire de services mis en place chez un de mes clients.

Il ressemble beaucoup, dans ses fonctionnalités à celui que mes collègues et amis Anass EL HADEF et Eric D’INGRANDO ont mis en œuvre chez un autre client.

Bien sûr, ceci reste un exemple, à vous de mettre en place le dictionnaire de données qui correspondra le mieux à votre entreprise.

Dans cet exemple je tiens compte de l’application ARCAD car mon client utilise ARCAD et a mis en place de nombreuses applications bien spécifiques, vous n’aurez peut-être pas à gérer cette information sur votre dictionnaire.

1)        Liste des procédures exportées

Cet écran liste toutes les procédures exportées par les programmes de service.

Afin de permettre aux développeurs de rechercher si une procédure exportée répondant à leurs besoins existe déjà, sans avoir à parcourir l’intégralité de la liste affichée, des critères de sélections sont mis à disposition.

Ils permettent de filtrer les procédures affichées et donc de faciliter la recherche d’une procédure exportée en particulier.

Cette recherche peut se faire :

  • Sur le nom du programme de service exportant des procédures
  • Sur le nom des procédures exportées
  • Sur le nom d’une table utilisée par dans les procédures exportées
  • Sur les fonctionnalités couvertes par les procédures exportées
  • Sur l’application ARCAD qui contient les programmes de service

A noter que ces recherches peuvent se faire avec des caractères génériques « * » et « % » afin de ne pas les limiter aux termes exacts des critères de sélection.

Les données affichées sont :

  • Le nom du programme de service
  • La bibliothèque du programme de service
  • L’application ARCAD du programme de service
  • Le nom de la procédure exportée

La touche F11 permet d’afficher d’autres d’informations, telles que :

  • Le texte descriptif du programme de service
  • Les informations relatives au source du programme de service
    • La bibliothèque du fichier source
    • Le fichier source
    • Le membre source

La touche F18 permet d’envoyer par mail, au(x) destinataire(s) de notre choix, un fichier Excel contenant l’ensemble des lignes affichées.  J’utilise ce principe sur les sous-fichiers que je mets en place, elle repose, bien sûr, sur un programme de service et utilise les fonctions SQL : GENERATE_SPREADSHEET et SEND_EMAIL. Je pense rédiger un prochain article pour détailler cette fonctionnalité…

L’option 5 permet d’afficher le détail de la procédure exportée sélectionnée.

L’option 6 permet d’afficher la liste des programmes qui utilisent la procédure exportée sélectionnée.

2)        Détail d’une procédure exportée

C’est cet écran qui permettra aux développeurs de vérifier si la procédure exportée sélectionnée répond ou non à leurs besoins. Il leur permettra également de prendre connaissance des paramètres utilisés par cette procédure.

Cet écran affiche :

  • Les caractéristiques de la procédure exportée sélectionnée
    • Nom de la procédure
    • Nom et texte descriptif du programme de service qui l’exporte
    • Bibliothèque du programme de service
    • Application ARCAD qui gère le programme de service
    • La bibliothèque, le fichier et le membre source du programme de service. Ceci permettra aux développeurs de retrouver facilement le prototype du programme de service à utiliser si la procédure exportée correspond à leurs besoins.
  • La description de la fonctionnalité couverte par la procédure exportée
  • La liste des paramètres en entrée avec pour chaque paramètre :
    • Le nom du paramètre
    • Le format du paramètre
    • La description du paramètre avec si besoin la listes des valeurs autorisées
  • La liste des paramètres en sortie avec pour chaque paramètre :
    • Le nom du paramètre
    • Le format du paramètre
    • La description du paramètre avec si besoin la listes des valeurs autorisées
  • La liste des tables utilisées dans la procédure exportée avec le type d’utilisation (Lecture/MAJ/Ecriture/Suppression…)

3)        Listes des programmes utilisant une procédure exportée

Cet écran liste les programmes qui utilisent la procédure stockée sélectionnée.
il permet aux développeurs de trouver des exemples d’utilisation de cette procédure dont ils peuvent s’inspirer.              

Cet écran affiche :

  • Les caractéristiques de la procédure exportée sélectionnée
    • Nom de la procédure
    • Nom et texte descriptif du programme de service qui l’exporte
    • Bibliothèque du programme de service
    • Application ARCAD qui gère le programme de service
    • La bibliothèque, le fichier et le membre source du programme de service ce qui permettra aux développeurs de retrouver facilement le prototype du programme de service à utiliser si la procédure exportée correspond à leurs besoins.
  • Les caractéristiques de chaque programme qui fait appel à la procédure exportée sélectionnée :
    • Nom du programme
    • Bibliothèque du programme
    • Description du programme
    • Application ARCAD du programme
    • Type du programme
    • Attribut
    • Bibliothèque du source du programme
    • Fichier source du programme
    • Membre source du programme

Comment mettre en place un dictionnaire de services

Le dictionnaire de services pris pour exemple repose sur :

  • un modèle de données relationnel assez simple constitué de 4 tables
  • un programmes de service d’alimentation et de mise à jour des données du dictionnaire de services
  • les 3 programmes interactifs décrits précédemment :
    • Liste des procédures exportées
    • Détail d’une procédure exportée donnée
    • Liste des programmes utilisant une procédure exportée donnée

1)        Le modèle de données du dictionnaire

Le modèle de données relationnel utilisé dans ce dictionnaire de services est le suivant :

3 tables composant le dictionnaire de services à proprement parlé :

  • La table des programmes de service
    • La table des procédures exportées
      • La table des informations relatives à chaque procédure exportée

1 table faisant le lien entre les procédures exportées du dictionnaire de services et les programmes qui les utilisent :

  • Table des programmes utilisant une procédure exportée

2)        Alimentation du dictionnaire de services

Pour alimenter les 3 premières tables du dictionnaire de services, 2 solutions sont envisageables :

  • Soit une alimentation manuelle reposant sur des programmes interactifs permettant d’alimenter chacune des tables du dictionnaire :
    • Table des programmes de service,
    • Table des procédures exportées,
    • Table des informations relatives à chaque procédure.

Cette solution est la plus facile à implémenter mais oblige les développeurs à saisir ces informations en dehors du code source.

  • Soit une alimentation automatisée, réalisée par un traitement planifié qui sera exécuté régulièrement.
    Cette solution est beaucoup plus complexe à mettre en œuvre.
    En effet, le descriptif de la fonctionnalité et les paramètres en entrée/sortie de chaque procédure exportée ne sont pas accessibles.
    Ces informations doivent être préalablement stockées pour pouvoir être, ensuite, extraites.
    Il est possible de les stocker directement dans le code source du programme de service, en faisant, par exemple, précéder chaque procédure exportée d’un entête normalisé dans lequel devront être saisies ces informations.

Le programme d’alimentation du dictionnaire de services pourra alors les récupérer en analysant le code source du programme de service.

Personnellement, c’est cette seconde solution que je préconise car :

  1. Le développeur n’a pas à quitter le source du programme de service qu’il est en train d’écrire pour saisir le descriptif des procédures exportées qu’il met en place. Il renseigne ces informations en même temps qu’il développe sa procédure exportée. Il peut donc aisément les mettre à jour directement sans être tenté de remettre cela à plus tard.
  2. La documentation de la procédure exportée est « localisée » car directement présente dans le code source du programme de service. On saura donc toujours où la retrouver.
  3. L’exécution du programme d’extraction peut être planifié de façon régulière, de façon à garantir que le dictionnaire de services est bien à jour.

Cette solution fera l’objet d’un prochain article dans lequel je développerai en détail chaque étape de sa mise en œuvre.

3)        Alimentation du lien entre les procédures exportées et les programmes qui les utilisent

Extraire les procédures exportées par un programme de service donné est simple grâce aux tables de QSYS2.

SELECT              PROGRAM_NAME        AS "Nom Pgm de service",
                    PROGRAM_LIBRARY     AS "Bibliotheque Pgm de service",                     
                     TRIM(SYMBOL_NAME)  AS "Nom Procedure exportee"
    FROM QSYS2.PROGRAM_EXPORT_IMPORT_INFO     
 WHERE PROGRAM_LIBRARY         = 'ma_bibliotheque_de_programmes'
       AND PROGRAM_NAME        = 'mon_programme'
       AND OBJECT_TYPE         = '*SRVPGM'
       AND SYMBOL_USAGE        = '*PROCEXP';

Extraire les programmes qui utilisent un programme de service donné est simple aussi.

SELECT PROGRAM_NAME                                   AS "Nom de PGM appelant",
       PROGRAM_LIBRARY                                AS "Bib du PGM appelant",
       BOUND_SERVICE_PROGRAM                          AS "PGM de service appelé »
FROM QSYS2.BOUND_SRVPGM_INFO
WHERE PROGRAM_LIBRARY = 'ma_bibliothèque_de_programmes';

Par contre :

Extraire les programmes qui utilisent une procédure stockée donnée est plus complexe.

En effet, ce lien n’est pas stocké dans les tables de QSYS2. Il va falloir rechercher chaque procédure exportée par un programme de service dans le code source de chaque programme qui utilise ce programme de service.

Voici, ci-dessous, un exemple de requête qui répond à cette problématique. 

SELECT
               A.PROGRAM_LIBRARY                    AS "BIB_PGM_DE_SERVICE", 
                A.PROGRAM_NAME                      AS "PGM_DE_SERVICE", 
                A.OBJECT_TYPE                       AS "TYPE_OBJET", 
                A.SYMBOL_NAME                       AS "PROCEDURE_EXPORTEE",
                B.PROGRAM_LIBRARY                   AS "BIB_PGM_UTILISANT_PGM_DE_SERVCIE", 
                B.PROGRAM_NAME                      AS "PGM_UTILISANT_PGM_DE_SERVCIE",
                B.OBJECT_TYPE                       AS "TYPE_PGM_UTILISANT_PGM_DE_SERVCIE",
                B.BOUND_SERVICE_PROGRAM             AS "PGM_DE_SERVICE_UTILISE",
                TRIM(C.SOURCE_FILE_LIBRARY) CONCAT '/' CONCAT TRIM(C.SOURCE_FILE)
                   CONCAT '(' CONCAT TRIM(C.SOURCE_FILE_MEMBER) CONCAT ')' AS PATH_SOURCE
               FROM                  QSYS2.PROGRAM_EXPORT_IMPORT_INFO    A
               LEFT JOIN          QSYS2.BOUND_SRVPGM_INFO                           B
                              ON        B.BOUND_SERVICE_PROGRAM = A.PROGRAM_NAME
               LEFT JOIN QSYS2.BOUND_MODULE_INFO C
                              ON        C.PROGRAM_LIBRARY = B.PROGRAM_LIBRARY
                              AND      C.PROGRAM_NAME    = B.PROGRAM_NAME       
               WHERE              A.PROGRAM_LIBRARY = 'ma_bib_de_programmes’
               AND                A.PROGRAM_NAME    = 'mon_programme_de_service’
               AND                B.PROGRAM_LIBRARY = 'ma_bib_de_programmes’
               AND LOCATE_IN_STRING(GET_CLOB_FROM_FILE(
TRIM(C.SOURCE_FILE_LIBRARY) 
CONCAT '/' CONCAT TRIM(C.SOURCE_FILE) CONCAT '(' CONCAT TRIM(C.SOURCE_FILE_MEMBER) CONCAT ')', 1)
, A.SYMBOL_NAME) > 0;

           

Attention : la fonction GET_CLOB_FROM_FILE doit être faite sous commitment control.

Pour conclure

Le dictionnaire de services facilite la mise en œuvre de la programmation basée sur les services ILE. Il permet aux développeurs de trouver et donc de réutiliser les services déjà développés. Ce qui réduira les temps de développements, tout en garantissant l’unicité des procédures exportées.

Il permet également de disposer d’une documentation centralisée de chaque procédure exportée.

C’est en cela que le dictionnaire de services rentre pleinement dans la démarche de modernisation des applicatifs IBM-i.

N’hésitez pas à me faire part de vos remarques et/ou de vos questions, je me ferai un plaisir d’y répondre.

Je remercie :

  • Anass EL HADEF et Eric D’INGANDO pour les échanges que nous avons eus au sujet des dictionnaires de services et pour la source d’inspiration qu’ils m’ont apportée.

Merci

/par
, Démystification de la Modernisation IBMi

Cette semaine c’est un article un peu spéciale c’est notre ami Jérôme Clément qui nous livre ses réflexions éclairées sur la modernisation de vos applications #ibmi et ses enjeux , merci à lui pour ce partage .

Objectifs

Cet article a pour objectif de démystifier la modernisation IBMi et surtout de mettre en évidence toutes les actions de modernisation réalisables aisément qui faciliteront grandement les actions d’envergure qui seront à réaliser ensuite.

Le concept de Modernisation de l’IBMi est, certes, très vaste et peut paraitre très difficile à mettre en œuvre mais nous allons voir que cette modernisation repose aussi sur de nombreuses étapes qui peuvent, elles, être réalisées facilement et rapidement par les équipes internes à l’entreprise.

En plus d’être indispensables à la modernisation, ces étapes apporteront une meilleure maîtrise des applicatifs IBMi existants, ce sont des prérequis aux chantiers plus conséquents que sont, par exemple :

  • La mise en place de solutions DEVOPS
  • La conversion automatisée des bases DB2 en bases SQL
  • La transformation des programmes RPG en programmes FREEFORM

Voici quelles sont ces différentes étapes, que je détaillerai ensuite :

  • Adhésion à la démarche
  • Normalisation des développements
  • Définition des bonnes pratiques
  • Documentation et centralisation de la documentation
  • Etat des lieux des applicatifs
  • Modularisation et utilisation des programmes de service
  • Migration progressive d’une base de données DB2 vers une base de données SQL
  • Accès aux données avec SQL
  • Implication des équipes de développement

Adhésion à la démarche

Il est primordial que la démarche de modernisation soit partagée par tous. C’est-à-dire :

  • Par la direction de votre entreprise
  • Par la DSI
  • Par les équipes de développement

Pour être efficace, cette démarche doit être comprise de tous et avoir l’adhésion de chacun.

Cela car elle nécessite des moyens (essentiellement du temps), de la rigueur et l’implication de tous les acteurs.

Il est important que la direction de votre entreprise ait conscience que :

  • La modernisation est nécessaire au bon fonctionnement et aux évolutions futures des applications qui reposent sur l’IBMi.
  • L’IBMi est une machine moderne, en phase avec son époque, capable de s’interfacer avec tous les autres systèmes actuels. Robuste, rapide, économique l’IBMi porte actuellement le cœur de l’activité de votre entreprise, il est primordial de maintenir ce système à niveau.
    La dette technique accumulée au fil des années peut être « remboursée », et cela doit être fait pour pouvoir profiter encore longtemps des investissements déjà réalisés dans la mise en place des applications spécifiques à votre entreprise et spécifiques à votre activité.
  • Quitter l’IBMi pour un autre système peut être une solution. Mais c’est une opération longue, couteuse et risquée. C’est une solution sur laquelle de nombreuses entreprises se sont déjà « cassés les dents ».
  • Il est, selon moi, nettement plus judicieux et beaucoup plus économique de capitaliser sur vos acquis en modernisant vos applicatifs plutôt que de chercher à les remplacer à l’identique ou presque sur un autre support.
  • Moderniser les applicatifs IBMi est un investissement qui ne pourra être mener à bien que s’il est appuyé par la direction de l’entreprise et uniquement si celle-ci donne les moyens à ses équipes de se lancer pleinement dans cette démarche.

Il est important que la DSI ait conscience que :

  • La modernisation nécessite du temps et qu’il va donc falloir en accorder à ses équipes pour la mettre en œuvre.
    En effet, une équipe sous pression d’échéances de livraison de projets ne prendra pas le temps de faire « bien », elle se contentera de faire « vite ». Elle vivra la démarche de modernisation comme une contrainte lui demandant du temps dont elle ne dispose déjà pas. Elle ne percevra pas cette démarche comme un investissement, et cherchera à s’y soustraire à la moindre occasion plutôt que de la porter.
  • La modernisation réduira les coûts des développement futurs.
    La maitrise et la connaissance des applicatifs, la mise en place de services évitant la redondance de code, l’homogénéisation des méthodes de développements, la suppression des programmes obsolètes : toutes ces étapes, une fois réalisées, permettront de gagner du temps dans la réalisation de vos projets.
    Le temps nécessaire à la modernisation sera donc récupéré par la suite. 
  • Certains développeurs peuvent aussi se montrer réfractaires à l’idée de sortir de leur zone de confort en devant changer leurs habitudes de développement. C’est pourquoi la démarche de modernisation doit être portée par la DSI. Il va falloir contrôler que tous les développeurs y participent et la mettent en œuvre. En effet, il est contreproductif de résorber la dette technique d’un côté si c’est pour continuer à la générer d’un autre.

Il est important que les développeurs aient conscience que :

  • La modernisation est nécessaire et qu’elle pérennise la présence de l’IBMi au cœur de l’infrastructure technique de l’entreprise et par conséquent leur présence en tant que développeurs spécialisés sur ce système au sein de l’entreprise.
  • La modernisation est formatrice et donc très positive.

Cette démarche va probablement changer les habitudes des développeurs. Mais il est, me semble-t-il, particulièrement motivant d’avoir à appréhender de nouvelles façons de développer lorsque celles-ci sont plus efficaces et plus performantes. Les développeurs ont tout à gagner à se mettre au RPG FREEFORM, à utiliser au mieux SQL, à développer des programmes de services. C’est un plus pour l’entreprise mais également un plus personnel pour chaque d’entre eux.

Ce qui a pour conséquence une grande disparité dans la façon de nommer les objets comme dans la façon d’écrire les programmes.

Normalisation des développements


Avec les années, le turnover des développeurs internes et les interventions de prestataires externes, on constate bien souvent que chacun a laissé son empreinte, son style, sa façon de développer dans les applicatifs de l’entreprise.

C’est une lapalissade mais il faut normaliser tout ça.

Mettre en place des normes de développement a pour objectifs :

  • De rendre le code homogène afin qu’il soit facilement appréhendable par chaque membre vos équipes.
  • D’identifier facilement les différents objets qui composent vos applications.

Définissez, ensemble, avec tous les membres de vos équipes :

  • Les normes de nommage des objets.
  • Les normes de codification à utiliser dans les sources de vos programmes.

Rédiger un document récapitulatif clair, consultable par chaque membre de vos équipes. Ce document doit devenir une référence, il devra être mis à disposition de chaque nouvelle personne qui rejoindra vos équipes (en interne comme en prestation). Il contribuera à sa bonne intégration et facilitera le respect et la mise en œuvre de ces normes par les nouveaux arrivants.

Définition des Bonnes Pratiques

Là aussi c’est une lapalissade mais c’est très important.

Définissez ces bonnes pratiques, ensemble, en restant à l’écoute des uns et des autres mais en finalisant la réflexion en statuant ces règles dans un document de référence (comme pour les normes de développement).

Et surtout veillez à ce ces bonnes pratiques soient respectées, quitte à développer, si nécessaire, des process de contrôle qui bloqueraient chaque mise en production ne respectant pas les préconisations établies.

Voici quelques exemples de règles de bonnes pratiques classiques dans le cadre de la modernisation :

  • Respecter les normes de développement et les bonnes pratiques définies.
  • Ecrire les nouveaux programmes en RGP FREEFORM.
  • Proscrire les SELECT * dans le SQL EMBEDDED.
  • Gérer les accès à la base de données par SQL.
  • Ne pas créer de nouveaux fichiers physiques ou logiquesDB2, mais créer des tables, index et vues SQL.
  • Convertir chaque programme RPG modifié en programmes RPGLE.
  • Commenter les sources de façon claires et réfléchies en évitant les commentaires inutiles.
  • Utiliser des noms de variables parlant.
  • Ne jamais faire d’accès aux index dans les requêtes SQL, laisser SQL choisir ses modes d’accès aux données.
  • …

Documentation et Centralisation des documents

Là aussi, cela semble évident, mais nombre d’entreprise ne documentent pas leurs traitements et s’étonnent ensuite de ne pas maîtriser leurs propres applications.

On constate fréquemment que chaque développeur s’est construit sa propre petite documentation, détaillant telle ou telle chaine de traitement, mais que ces documents ne sont ni partagés, ni à jour.

Il faut donc impérativement :

  • Documenter vos applications.
    Cela peut se mettre en place progressivement, en profitant de chaque nouveau projet, de chaque nouveau développement pour mettre en place cette documentation.
  • Définir des modèles de document qui seront utilisables par tous.
    Cela facilitera la création des documentations suivantes.
  • Centraliser ces documents.
    Pour que chacun puisse y accéder, que chacun puisse y ajouter sa contribution mais surtout pour que toute personne sache où rechercher ces informations.
  • Faire vivre ces documents en les maintenant à jour.

Etat des lieux de vos applicatifs

Faire un état des lieux des applications qui tournent sur l’IBMi permet de quantifier la dette technique à résorber.

Les services SQL permettent en quelques requêtes d’obtenir de très nombreuses informations sur les objets de vos applications.

Elles permettent par exemple :

  • D’identifier les programmes qui n’ont pas été exécutés depuis des années.
    Ces programmes alourdissent vos développements alors qu’ils ne servent plus.
    En effet, chaque analyse d’impact, chaque modification de base de données les prennent en compte ce qui augmente inutilement la charge de travail.
    Identifier ces programmes permet de les sauvegarder leurs sources puis de les supprimer.
    C’est autant de programme qui ne seront plus à moderniser.
  • Contrôler l’unicité des sources des programmes, de façon à n’avoir qu’un seul référentiel de sources. Avoir différentes versions de sources d’un même programme dans différentes bibliothèques est très dangereux. Les développeurs ne doivent pas avoir à s’interroger pour savoir quel est le source à modifier pour ne pas risquer d’écraser les modifications précédemment livrées en production.
  • Vérifier la cohérence entre vos objets de production et votre référentiel de source.
    Il est impératif de pouvoir avoir une totale confiance en son référentiel de source.
    Avoir des objets de production qui ne correspondent pas aux sources du référentiel est très inquiétant. Il faut profiter de la modernisation pour vérifier et remettre la situation à plat.
  • Vérifier et optimiser les requêtes SQL, identifier les plus consommatrices, vérifier et éventuellement créer les index proposés.
  • Mettre en évidence les ratios suivants :
    • Nombre de fichiers DB2 / Nombre de tables SQL
    • Nombre de programme RPG / nombre de programmes RPGLE
  • Identifier le nombre de procédures de services mises en place.

Encapsuler ces requêtes dans des programmes de façon à pouvoir les relancer régulièrement et stocker les résultats obtenus est une idée intéressante.

Cela permettra de mettre en place des métriques pouvant être remontés à la direction pour montrer que le process de modernisation est en œuvre et progresse régulièrement.

Modularisation et utilisation des programmes de service

Convertir les programmes en RPG en RPGLE : c’est bien.

Mais appréhender et mettre en place le concept de programmes de service : c’est mieux.

L’idée qui se cache derrière ce concept est de développer de petits programmes de service, facilement maintenables puisque répondant chacun à une et une seule fonctionnalité bien spécifique. Ces services pourront être ensuite consommés, à chaque instant, par les différents traitements.

Cela permet :

  • D’éviter le code redondant. Puisque le code de la fonctionnalité n’est présent que dans le service et non plus dans chaque chaine de traitement qui utilise sa fonction.
  • De gagner énormément de temps en maintenance puisque seul le service est à modifier en cas d’évolution de la fonctionnalité concernée.
  • De gagner en performance grâce aux groupes d’activation.
    En effet les groupes d’activation permettent de garder en mémoire le service précédemment appelé au sein du même groupe d’activation. Contrairement à un appel de programme classique qui va être monté en mémoire puis déchargé à chaque appel.
  • D’exposer, si nécessaire, ces programmes de services très simplement grâce au serveur intégré à l’IBMi via IWS (websphère), les rendant ainsi également accessibles à des applicatifs hors IBMi.

Ces programmes de services, une fois développés, doivent pouvoir être réutilisés par tous et il ne faut pas qu’une même fonctionnalité face l’objet de plusieurs programmes de service, c’est l’opposé du but recherché.
Pour cela, il est fortement conseillé de mettre en place un dictionnaire de service permettant de :

  • Rechercher les services et les procédures exportées :
    • par leur nom
    • par leur fonction
    • par les tables mise à contribution
  • D’identifier les paramètres en entrée et en sortie de chaque procédure exportée.

En indiquant leur rôle et leur format.

  • De visualiser quelles tables sont utilisées par chaque procédure exportée.

Ceci permettra aux développeurs de trouver facilement le service qui répondra à leur besoin et évitera qu’une même fonctionnalité fasse l’objet de plusieurs services.

Migration progressive d’une base de données DB2 à une base de données SQL

Sans rentrer dés à présent dans le processus de conversion massive de toute la base de données DB2 en base SQL, il est possible de commencer à se dire que toute nouvelle création d’élément de la base de données se fera en SQL.
Ceci en remplaçant les créations de fichiers physiques ou logiques DB2, par des créations de tables, index ou vues SQL.

Ceci permettra de commencer progressivement la bascule de la base de données vers SQL, tout en permettant aux équipes à s’habituer à ce nouveau process.

Accès aux données avec SQL

Cette étape est un peu particulière car il ne s’agit pas juste de dire : il faut faire du SQL EMBEDDED. C’est-à-dire qu’accéder aux données, dans les programmes RPG, par SQL c’est une chose, mais il faut le faire bien.

En effet, cela ne consiste pas simplement à remplacer un CHAIN classique par un SELECT SQL. Cela va bien au-delà de ça.

Par exemple :

Utiliser un CURSEUR SQL, faire une boucle de lecture du curseur, pour ensuite faire différents SELECT à partir des données de chaque enregistrement lu dans le curseur est un non-sens.
Le programme va effectivement accéder aux données par SQL mais sans profiter de la puissance offerte par SQL et les temps de réponses seront donc quasiment similaires à ceux obtenus par un accès « classique » à la base de données.
Alors que si le curseur est fait à partir d’une requête unique comportant des jointures sur les tables lues par les différents SELECT évoqués précédemment ; alors il est plus que probable qu’il y aura un gain de performance significatif.

Outre les gains de performance, SQL apporte également de nombreuses fonctions qui faciliteront les développements.

SQL est un langage qui évolue constamment, et c’est également le cas sur l’IBMi.

De nouvelles fonctions font leur apparition régulièrement.

Et ces fonctions permettent par exemple :

  • De générer un fichier XML en quelques lignes
  • De lire et intégrer un fichier JSON en une seule requête
  • D’envoyer un mail avec le résultat de la requête sous forme de fichier Excel très simplement

Ce ne sont que quelques exemples parmi tant d’autres…

Il est aujourd’hui inconcevable de se passer de SQL même et surtout en tant que développeur IBMi.

Vos équipes auront peut-être, selon leur niveau, besoin de formations avancées sur SQL mais il est indispensable qu’elles sachent utiliser à bon escient les jointures, les tables temporaires, les fonctions SQL afin qu’elles puissent mettre en place des requêtes optimisées, performantes et maintenables facilement dans leurs programmes.

Sans quoi les gains en performance seront restreints alors qu’ils peuvent être tellement importants lorsque les requêtes tirent pleinement profit des possibilités offertes par SQL.

C’est pourquoi, il faudra également présenter aux équipes de développement les outils d’optimisation SQL mis à disposition sous ACS tels que :

  • Visual Explain
  • SQL Performance Center
  • Le Conseil à la création d’index

Implication des équipes de développement

Ces étapes de modernisation sont réalisées par les équipes de développements.
Nous l’avons vu, elles vont avoir besoin de temps pour les mettre en œuvre, mais pas seulement. Il va falloir, si nécessaire, les impliquer en les faisant monter en compétence.

Ceci en :

  • Les formant au RPG FREEFORM si elles ne le connaissent pas déjà
  • Les formant aux concepts des programmes de services
  • Les formant au SQL avancé
  • Les incitant à assister aux événement IBMi qui sont si riches, si formateurs et desquels elles retiendront de nombreuses nouveautés à mettre en pratique.

La démarche de modernisation peut être perçue comme une contrainte mais si c’est le cas c’est que :

  • soit elle a été mal introduite,
  • soit les développeurs n’ont pas les moyens (le temps toujours le temps) de les mettre en pratique et d’en tirer profit.

Si on lui laisse la possibilité de profiter de la modernisation pour monter en compétence, il n’y a aucune raison pour qu’un développeur perçoive la démarche comme une contrainte et n’y adhère pas. Ou alors il est totalement réfractaire au changement mais ça c’est une autre histoire… 

Pour conclure

Ces premières actions ne règleront pas tout, il vous faudra certainement vous outiller ou faire appel à des spécialistes pour répondre à la mise en place du DEVOPS, pour convertir de façon automatique tous vos sources RPG/RPGLE en FREEFORM et pour transformer toutes vos bases DB2 en bases SQL. C’est un fait.

Mais ces actions sont, elles, à la portée de tous et constituent un grand pas dans la démarche de modernisation.

Je détaillerai dans de futures publications comment réaliser telles ou telles étapes abordées de façon synthétique dans ce premier post.

N’hésitez pas à me faire part de vos remarques et/ou de vos questions, je me ferai un plaisir d’y répondre.

Je remercie, encore une fois Pierre-Louis BERTHOIN et Nathanaël BONNET pour la tribune qu’ils m’ont offerte.

J’espère que cet article vous a intéressé et qu’il apportera sa contribution à vos différents projets de modernisation.

Je vous remercie et vous dit à bientôt…

/par