, 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 meilleur 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 ou il y est un autre mot clé avant

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

/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
, Mettre des contrôles dans un DSPF

Sur un formulaire de saisie, on va différencier 3 type de contrôles

1) de valeur

exemple doit contenir 1, 2, 3

2) de cohérence

exemple date de fin > date de debut

3) applicatifs

qui nécessite un accès à une ressource externe

exemple

controler que le client existe

Sur une application de type web, on a un formulaire de saisie et les contrôles 1 et 2 sont faits par javascript
et la partie 3 est faite applicativement

Si on considère maintenant un applicatif 5250, on peut faire une grande partie des contrôles 1 directement dans l’écran ,
la partie 2 et 3 seront faites applicativement

Nous allons prendre un DSPF et faire des controles directement dedans

l’écran DSPF


     A*%%TS  SD  20241104  105842  PLB         REL-V7R4M0  5770-WDS
     A*%%EC
     A                                      DSPSIZ(24 80 *DS3)
     A                                      CA03(03)
     A          R FMT01
     A*%%TS  SD  20241104  105842  PLB         REL-V7R4M0  5770-WDS
     A                                  4 29'Ecran de saisie'
     A                                  8 15'Code   :'
     A            CODE           4A  B  8 24DSPATR(MDT)
     A N45                                  DFTVAL('001')
     A                                      CHECK(MF)
     A                                      RANGE('0001' '9999')
     A                                  8 30'Zone remplie obligatoire'
     A                                 11 15'Nom    :'
     A            NOM           30A  B 11 24CHECK(LC)
     A                                      DSPATR(MDT)
     A                                      COMP(NE ' ')
     A                                 12 30'Zone obligatoire '
     A                                 13 30'Minuscules autorisées'
     A                                 15 15'Option :'
     A            OPTION         1N  B 15 24VALUES('1' '2' '4')
     A N45                                  DFTVAL('2')
     A                                 15 30'1 Créer'
     A                                 16 30'2 Modifier'
     A                                 17 30'4 Supprimer'
     A                                 22  5'F3=Exit'
     A                                  9 30'Chiffre uniquement'

Nous allons contrôler que
la zone CODE est remplie
la zone NOM n’est pas vide
la zone OPTION doit prendre comme valeur 1, 2 et 4

On dispose des contrôles
de saisie souvent des CHECK
de validité, COMP, RANGE, VALUE

Pour que le contrôle soit déclenché, la zone devra être modifiée ou on forcera le DSPATR(MDT), pour faire comme si c’était le cas.

Remarque
Les contrôles de saisie sont effectués dans tous les cas (CFXX, ENTER, CAXX)
Les contrôles de validité sont effectués uniquement dans cas (CFXX, ENTER)

Le programme RPGLE pour tester

**free
ctl-opt DFTACTGRP(*NO) ;
dcl-f Controle WORKSTN ;
  dou *in03 ;
    exfmt fmt01 ;
    if not *in03;
    endif ;
  // Contrôle des zones
   *in45 = *on ;
  enddo ;
  *inlr = *on ;

Remarque :
Dans cet exemple, on utilisera l’indicateur 45 pour ne plus affecter de valeur par défaut

Vous pouvez ainsi simplifier votre application d’une grande partie des contrôles basics

Vous pouvez indiquer , un message différent par le mot clé CHCKMSGID()

/par
, , Utilisez de l’Unicode en 5250

Unicode permet d’encoder des caractères complexes sous deux octets

Un site pour avoir des informations supplémentaires

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

Vous voulez afficher des caractères Unicode dans votre session 5250,

parce que vous travaillez avec la chine par exemple.

Voici un petit exemple pour vous indiquer les grandes étapes

Rappel:

Pour avoir des caractères Unicode, vos zones doivent être déclarées comme ceci

NOM VARGRAPHIC(30) CCSID 1200 NOT NULL

Vous pouvez insérer des caractères dans votre table par SQL par exemple

Exemple chinois et russe

INSERT INTO NOMTBL (NOM) VALUES(
(‘张’), (‘Иванов’) )

Dans votre DSPF, vous pouvez déclarer zones par référence

niveau fichier
A REF(*LIBL/NOMTBL)

niveau zone
A NOM R O 6 4REFFLD(PERSONNES/NOM *LIBL/NOMTBL)

Vous obtiendrez le résultat suivant ;

Vous devrez également indiquer sur la commande de compile de l’écran (CRTDSPF),

le paramètre IGCDTA(*YES)

Votre session ACS devra supporté l’Unicode comme ceci

Votre programme en RPGLE par exemple n’aura aucune différence par rapport à des caractères latins

Voici le résultat d’un affichage

Remarque :


Vous pouvez faire beaucoup de choses
Tout n’est pas parfait , pas de solution simple pour utiliser les MSGID et MSGCON …

Vous devrez avoir un clavier qui vous permet de saisir les caractères souhaités

/par
, , Utilisez DRDA sur #IBMi

Dans ACS vous avez des exemples comme si dessous

Vous indiquer le nom de votre base de données distantes et vous exécuter votre requête sur le système distant.

derrière cette requête ce cache un protocole nommé DRDA , comme ODBC il permet de ce connecté à une base de donnée distante.

Nous allons voir comment le mettre en œuvre .

sur le système source
Vous devez créer une entrée pour la base de données

le plus simple c’est de passer par la commande WRBRDBDIRE , vous ajouterez une connexion IP à votre système distant.

Sur le système cible
Vous devez paramétrer le service par la commande CHGDDMTCPA , il faut avoir le même mode d’authentification que la base de données distante, par défaut user + mot de passe
vous devez démarrer le service STRTCPSVR *DDM

voila c’est tout
vous pouvez à partir de votre système source faire un connect SQL sur votre système cible si vous avez un mot de passe.

Si vous ne voulez pas renseigner de mot de passe comme dans les exemples ACS vous allez devoir utiliser sur votre système source les postes poste d’authentification serveur.
Pour les ajouter vous avez la commande ADDSVRAUTE, vous devrez également avoir mis la valeur système QRETSVRSEC à ‘1’ pour que vos mots de passe soit enregistrés

il est conseillé d’ajouter un poste générique, par exemple QDDMDRDASERVER en indiquant un user et un mot de passe du système cible !

il n’y a pas de commande WRKSRVAUTE mais vous pouvez en trouver une ici https://github.com/Plberthoin/PLB/tree/master/GTOOLS/

Exemple :

A partir de ce moment la mot de passe sera passé directement.

Vous pouvez facilement, par des services sql comparer 2 partitions (valeurs systèmes, fonctions , etc …)

Remarques

Les noms doivent être en majuscule
il est conseillé de mettre un programme d’exit de contrôle
Attention, vous pouvez vous connecter avec un utilisateur *disabled
Les fichier DDM sur IP s’appuient sur cette technologie

/par
, Utilisez NFS sur votre IBMi

NFS est un protocole de partage de fichier issu du monde Unix, SMB est celui de windows c’est celui qui est utilisé dans NETSERVER.

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

Nous allons voir comment l’utiliser NFS sur l’IBMi qui peut être client et serveur par exemple pour partager un fichier d’installation ou de paramétrage.

Sur le serveur

Vous devez démarrer le serveur.

STRNFSSVR SERVER(*ALL)

Vous devez créer le répertoire à exporter

CRTDIR (‘/SHARE_NFS’)

Vous devez monter l’export

Paramétrage dans exports vous avez un fichier

EDTF STMF(‘/etc/exports’)
/SHARE_NFS/URANUS -ro

pour exporter

EXPORTFS

Si tout se passe bien vous aurez ce message :

Demande d’exportation exécutée.
1 postes exportés, 0 postes non exportés.

Vous pouvez être obligé de rajouter des droits sur votre partage :

CHGNFSEXP OPTIONS(‘-I -O RW=,ANON=0’) DIR(‘/SHARE_NFS/URANUS’)

Votre répertoire est maintenant exporté.

Sur le client

Vous devez démarrer le même serveur.

STRNFSSVR SERVER(*ALL)

Vous devez créer un répertoire pour le montage

MKDIR DIR(‘/MNT/NEPTUNE’)

Vous devez faire le montage

MOUNT TYPE(*NFS) MFS(‘NEPTUNE:/SHARE_NFS/URANUS’)
MNTOVRDIR(‘/MNT/NEPTUNE’)

Si tout va bien vous aurez ce message :


Système de fichiers monté.

Vous pouvez contrôler par :

DSPMFSINF OBJ(‘/MNT/NEPTUNE’)

Objet . . . . . . . . . . . . : /MNT/NEPTUNE

Type de système de fichiers . : Syst. de fichiers réseau (NFS)

Taille de bloc . . . . . . . . : 32768
Nombre total de blocs . . . . : 23303175
Blocs libres . . . . . . . . . : 5182808
Nombre maximal de liens à des
objets . . . . . . . . . . . : 32767
Nombre maximal de liens à un
répertoire . . . . . . . . . : 1000000
Longueur maximale d’un
composant de nom de chemin . : 255
Longueur maximale de nom de
chemin . . . . . . . . . . . : Pas de maximum

Pour accéder au fichier par exemple :

wrklnk (‘/mnt/NEPTUNE/*’)

Répertoire . . . . : /mnt/NEPTUNE

Vous pourrez voir votre fichier par 5

Remarque :

Vous pouvez l’utiliser que en serveur ou en client avec un système distant sous Linux le plus souvent.

C’est un protocole très connu par les administrateurs Unix.

Pour échanger entre IBMi, vous pouvez également utiliser QFileSvr.400

/par
, , Nommer un groupe d’activation pour des programmes RPGLE

Vous voulez nommer votre groupe d’activation pour toute une application
donc sans indiquer d’option dans le source qui seraient prioritaires par rapport à votre commande de compile

On va parler ici des BIND c’est l’opération que fait une commande pour compiler le module et l’assembler pour en faire un programme

Pour les sources RPGLE

C’est simple vous avez un paramètre

CRTBNDRPG PGM(GDATA/AAACTGRP)
SRCFILE(GDATA/QRPGLESRC)
SRCMBR(AAACTGRP)
DFTACTGRP(NO) ACTGRP(GAIA) <======== c’est ici

Pour les SQLRPGLE

Vous n’avez pas le paramètre ACTGRP dans la commande CRTSQLRPGI

il faut donc passer par les options de compile c’est le paramètre COMPILEOPT

CRTSQLRPGI OBJ(GDATA/AAACTGRP2)
SRCFILE(GDATA/QRPGLESRC)
SRCMBR(AAACTGRP2)
OBJTYPE(PGM) REPLACE(NO)
COMPILEOPT(‘DFTACTGRP(*NO) ACTGRP(GAIA)’) <====== comme ceci

On est obligé de mettre les 2 paramètres même si DFTACTGRP(*NO) dans le source ????

Attention, il n’y a pas de contrôle de syntaxe sur le paramètre

Remarque

Bien sur mes informations concernent les binds, pour l’assemblage de modules l’option est dans la commande CRTPGM directement

/par
, , , Connaitre la bibliothèque du programme en cours

Vous voulez connaitre la bibliothèque d’un programme en cours d’exécution, pour ajouter cette bibliothèque par exemple, pour contextualiser un exit programme, un watcher, un trigger ou pour limiter un environnement prod, versus dev.
Le tout, sans harcoder une bibliothèque qui figera votre code et vos environnements.

Voici 2 exemples

En RPGLE

dcl-ds *N PSDS ;                  
  bibli_du_pgm CHAR(10) POS(81);  
  nom_du_pgm CHAR(10) POS(1);     
 End-ds ;                          
dcl-s present ind ;
// on tente d'ajouter la bibliothèque
 exec sql                                                                  
 call qcmdexc('Addlible ' concat :bibli_du_pgm concat ' *FIRST') ;         
if sqlcode = 0 ;
  present = *on ;
endif ;
// votre traitement ici
// on enlève si on a ajouté 
if present = *on ;
 exec sql                                                                  
 call qcmdexc('Rmvlible ' concat :bibli_du_pgm ) ;         
endif ;

En CLLE

PGM                                                    
            DCL        VAR(&DATA) TYPE(*CHAR) LEN(80)  
            DCL        VAR(&LIB) TYPE(*CHAR) LEN(10)   
            DCL        VAR(&PGM) TYPE(*CHAR) LEN(10)   
            DCL        VAR(&TEMOIN) TYPE(*LGL)
 /* Paramétrage de l'appel */                          
            CHGVAR     VAR(%BIN(&DATA  1 4)) VALUE(80) 
            CHGVAR     VAR(%BIN(&DATA  5 4)) VALUE(80) 
            CHGVAR     VAR(%BIN(&DATA  9 4)) VALUE( 0) 
            CHGVAR     VAR(%BIN(&DATA 13 4)) VALUE( 0) 
 /* Appel de la procédure */                           
            CALLPRC    PRC('_MATPGMNM') PARM(&DATA)    
 /* Extraction des informations  */                    
            chgvar &pgm %SST(&DATA 51 10)              
            chgvar &lib %SST(&DATA 19 10) 
/* ajout de la bibliothèque */
ADDLIBLE &LIB *FIRST
monmsg cpf2103 exec(do)
chgvar &temoin '1'
enddo 
/* Votre traitement ici */
/* on enlève si on a ajouté */
if cond(*not &temoin) then(do)
RMVLIBLE &LIB
enddo          
ENDPGM

Remarque :

On a mis également le programme en cours dans les exemples

On a mis le code pour enlever la bibliothèque après le traitement, uniquement si c’est notre programme qui l’a ajouté.


En RPGLE si vous avez un fichier vous devrez déclarer votre fichier en USROPN et ouvrir le fichier par un OPEN, après avoir ajouté la bibliothèque

/par
, , Fichier SQLPRE de QTEMP

Vous avez des sources SQLRPGLE qui sont différents des tailles par défaut de 100

Vous pouvez avoir ce message à la compile RNF0733
C’est le fichier, QTEMP/QSQLPRE de pré-compilation qui est trop court QTEMP/QSQLPRE
Ce fichier est utilisé dans les commandes CRTBNDRPG , CRTRPGMOD, ou CRTSQLRPGI

Vous avez une variable d’environnement QIBM_RPG_PPSRCFILE_LENGTH qui permet de changer la valeur par défaut qui est de 112.
Elle doit avoir la longueur de votre donnée + 12
Exemple
SRCDTA = 140
Vous devrez indiquer 152

Pour ajouter la variable :

ADDENVVAR ENVVAR(QIBM_RPG_PPSRCFILE_LENGTH.)
VALUE(152)
LEVEL(*SYS)

*SYS pour l’ajouter à tout le système

Pour ne savoir plus ici

https://www.ibm.com/support/pages/node/6857461

/par