Pour connaitre le type d’un fichier, vous pouvez vous baser sur le type du Fichier .PDF, .JPG, etc …
Ou vous baser sur le nombre magique , ou signature binaire soit les 4 premiers octets en Hexa
SELECT HEX(SUBSTR(LINE, 1, 4)) AS SIGNATURE FROM TABLE(QSYS2.IFS_READ_BINARY(‘/home/test.pdf’)) FETCH FIRST 1 ROW ONLY;
Voici un exemple sur 4 fichiers que vous pouvez trouver sur votre partition
SELECT CASE
WHEN HEX(SUBSTR(LINE,1,4)) = '25504446'
THEN 'PDF'
WHEN HEX(SUBSTR(LINE,1,4)) = '89504E47'
THEN 'PNG'
WHEN HEX(SUBSTR(LINE,1,4)) = 'FFD8FFE0'
THEN 'JPG'
WHEN HEX(SUBSTR(LINE,1,4)) = '504B0304'
THEN 'ZIP'
ELSE 'Autre' // inconnu
END AS TYPE
FROM TABLE(QSYS2.IFS_READ_BINARY('/home/vert.jpg'))
FETCH FIRST 1 ROW ONLY;
Résultat :
Conclusion :
C’est simple, et efficace, il y a sans doute d’autres manières de faire
https://www.gaia.fr/wp-content/uploads/2017/02/team3.png600600Pierre-Louis BERTHOIN/wp-content/uploads/2017/05/logogaia.pngPierre-Louis BERTHOIN2026-05-11 14:42:272026-05-11 14:42:28Trouver le type d’un fichier
Vous avez des spools que vous ne voyez pas et vous ne pouvez pas agir dessus
==>WRKOUTQ
en Face de votre Outq vous avez 918 et quand quand vous regarder dans l’outq vous en avez que 37 par exemple
que faire
Vous regardez par SQL, vous les voyez tous
SELECT OUTPUT_QUEUE_NAME, SPOOLED_FILE_NAME, USER_DATA, JOB_NAME, FILE_NUMBER FROM QSYS2.OUTPUT_QUEUE_ENTRIES WHERE OUTPUT_QUEUE_NAME = ‘votre outq’;
Même par sql vous ne pouvez pas les effacer , c’est un probléme de spool fantômes , souvent le système n’a pas pu les écrire probléme d’espace disque par exemple, que faire ?
Sur IBM i, les groups d’activation sont au cœur de l’architecture ILE. Ils permettent de mutualiser efficacement les ressources tout en offrant un cadre d’exécution structuré et performant.
Dans la majorité des cas, le mécanisme de nettoyage automatique fourni par le système suffit largement. Mais dès que l’on travaille avec des service programs persistants, des ressources externes ou des APIs dont le cycle de vie dépasse un simple appel de programme, il devient nécessaire de reprendre la main.
C’est précisément là qu’intervient l’API CEE4RAGE.
CEE4RAGE signifie Register Activation Group Exit Procedure.
Son rôle est très simple mais fondamental : elle permet d’enregistrer une procédure qui sera appelée automatiquement lorsque l’activation group est détruit. Cette procédure est exécutée après les exit procedures des langages de haut niveau, mais avant le nettoyage final effectué par le système. On peut la voir comme un équivalent conceptuel d’un destructeur dans les langages orientés objet.
En effet, certains « nettoyages » ne peuvent pas, ou ne doivent pas, être laissés au seul mécanisme système. Certains composants nécessitent une fermeture explicite : mémoire allouée dynamiquement, connexions réseau persistantes, APIs externes, sockets, workers auxiliaires ou encore structures partagées. CEE4RAGE garantit que votre code de nettoyage sera exécuté quelle que soit la manière dont l’activation group se termine : retour normal, reclaim, exception ou même ENDJOB.
Le besoin dépend clairement du code ILE produit.
Usage
Un cas d’usage très courant concerne les service programs persistants. Lorsqu’un service program est chargé dans un activation group nommé ou avec *ACTGRP(CALLER), il peut rester actif longtemps, parfois pendant toute la durée de vie d’un job interactif. Dans ce contexte, il est essentiel de disposer d’un point fiable pour libérer proprement les ressources lorsque l’activation group disparaît enfin. CEE4RAGE fournit exactement ce point d’ancrage.
Une approche éprouvée consiste à mettre en place un pattern « constructeur / destructeur ». L’idée est simple : initialiser les ressources lors du premier appel effectif au service program, puis enregistrer une exit procedure via CEE4RAGE pour garantir le nettoyage automatique à la fin de l’activation group.
Exemple
Voyons maintenant un exemple concret en RPGLE free format, typique d’un service program.
Le service program est défini sans programme principal, hors DFTACTGRP, et dans un activation group persistant :
Le cœur du pattern repose sur une procédure d’initialisation, appelée systématiquement par les procédures métier exportées, mais dont le contenu réel ne s’exécute qu’une seule fois :
dcl-proc InzSrvPgm;
if Initialized;
return;
endif;
// Initialisation des ressources (exemple simulé)
ResourceHandle = 12345;
// Enregistrement de l'activation group exit procedure
CEE4RAGE(%paddr(EndSrvPgm): *omit);
Initialized = *on;
end-proc;
Cette procédure effectue trois choses essentielles :
elle initialise les ressources
enregistre l’exit procedure
mémorise le fait que l’initialisation est désormais réalisée
La procédure de terminaison, elle, sera appelée automatiquement par le système lorsque l’activation group prendra fin. Elle doit impérativement être exportée et respecter la signature attendue par l’ILE :
Enfin, toutes les procédures métier exportées commencent par appeler la procédure d’initialisation. Cela garantit que l’environnement est prêt avant toute logique fonctionnelle :
Une procédure d’exit d’activation group repose sur une interface composée de quatre paramètres standards, transmis automatiquement par le runtime lors de la terminaison de l’activation group :
agMark, correspond au marqueur interne de l’activation group. Il s’agit d’un identifiant numérique unique dans le job, principalement utile à des fins diagnostiques ou pour des scénarios avancés impliquant plusieurs activation groups simultanés. Dans la majorité des cas, ce paramètre est simplement ignoré, mais il permet théoriquement de corréler une terminaison précise à un contexte donné.
reason, indique la raison de la fin de l’activation group : retour normal, reclaim, fin de job, exception non interceptée, etc. Ce code est particulièrement précieux pour adapter le comportement du cleanup, par exemple en évitant certaines opérations coûteuses lors d’une fin brutale.
result et userRC, sont des champs en entrée/sortie permettant respectivement au système et au programme de communiquer un code de résultat et une information spécifique utilisateur. En pratique, ils sont rarement exploités, mais ils offrent un mécanisme de retour standardisé permettant à une exit procedure de signaler son état ou d’influencer légèrement le déroulement du traitement global. L’ensemble de ces paramètres est optionnel côté RPG, ce qui explique l’usage fréquent de options(*nopass) ; toutefois, leur présence formalise le contrat entre le runtime ILE et la procédure d’exit, et rappelle que cette dernière s’exécute dans un contexte très particulier, où la logique doit être minimale, robuste et parfaitement maîtrisée.
Multiples procédures
Dans certains cas plus avancés, il peut être tout à fait légitime d’enregistrer plusieurs procédures d’exit pour un même activation group.
CEE4RAGE ne limite ni le nombre de procédures enregistrées, ni leur nature : chaque appel ajoute une entrée dans la pile des exit procedures, qui seront exécutées dans l’ordre inverse de leur enregistrement lors de la fin de l’activation group.
Cette capacité est particulièrement utile lorsque plusieurs composants indépendants partagent le même activation group : chaque service program peut alors enregistrer sa propre procédure de nettoyage, sans dépendre d’un point centralisé.
Il est cependant essentiel de concevoir ces exit procedures comme autonomes, simples et robustes, car une défaillance dans l’une d’elles empêche l’exécution des suivantes. Dans ce contexte, l’ordre d’enregistrement devient un véritable élément d’architecture : on veillera par exemple à enregistrer en dernier les procédures critiques, ou à utiliser une procédure « chef d’orchestre » qui appelle explicitement plusieurs routines de cleanup internes.
L’utilisation de procédures d’exit multiples est donc un mécanisme puissant, mais qui impose une discipline stricte : absence d’effets de bord, opérations idempotentes, et compréhension claire du cycle de vie global de l’activation group.
Conclusion
Ce pattern est robuste, simple et parfaitement aligné avec les mécanismes de l’ILE.
Il fonctionne aussi bien en batch qu’en interactif, résiste aux fins de job brutales et assure un comportement prévisible dans les architectures persistantes. Il est particulièrement adapté aux environnements modernisés où des composants RPG sont exposés comme briques partagées, parfois appelées par des couches Java, C ou web.
Il convient toutefois de garder quelques points en tête. CEE4RAGE n’est jamais appelée tant que l’activation group reste actif ; si celui-ci est volontairement maintenu pendant toute la durée du job, le nettoyage n’aura lieu qu’à la toute fin. De plus, si une exit procedure échoue, les suivantes ne seront pas exécutées. Il est donc essentiel d’y écrire un code simple, robuste et sans dépendances fragiles.
En conclusion, CEE4RAGE est une API discrète mais fondamentale. Elle ne sert pas à gérer des erreurs ni à intercepter des messages système ; elle sert à maîtriser la fin de vie d’un activation group.
Dès que l’on conçoit des service programs persistants et que l’on vise une architecture propre et professionnelle sur IBM i, CEE4RAGE devrait faire partie des outils de base de tout concepteur ILE.
C’est en réalité l’évolution du Swagger qui permet de décrire les web services et leurs interfaces. L’interface produit désormais une page, personnalisable, epxosant la description des services, et permettant leur test !
Modifications de l’interface
Lors de la création d’une instance IWS :
Les propriétés openapi ne sont pas affichables ou modifiables par l’interface, mais pas fichier de configuration et commande shell.
Remarque : seuls les services démarrés apparraissent dans l’interface openapi.
Tester un service REST
Puis indiquez vos valeurs de paramètres :
Des options sont disponibles pour les situations plus avancées (authentification basique etc …)
Modifications des commandes shell
Depuis la documentation IBM, création d’un fichier :
#server.iws.gen.httpport=52000 #server.iws.gen.httpsport=52499 #server.iws.gen.adminport=52005 #server.iws.gen.contextroot=/api #server.iws.gen.defaultkeystore=*NONE #server.iws.gen.defaultkeystorepassword= #server.iws.gen.verifyhostname=false #server.iws.gen.trace=none
# Following are OpenAPI properties - IWS 3.0 only properties
server.iws.openapi.enable=true
server.iws.openapi.docpath=/openapi
server.iws.openapi.contactemail=nathanael.bonnet@gaia.fr
server.iws.openapi.contactname=Nathanael
server.iws.openapi.contacturl=http://www.gaia.fr/contact
server.iws.openapi.description=Description : test NB pour IWS 3.0
server.iws.openapi.licensename=License Gaia 2.0
server.iws.openapi.licenseurl=https://www.gaia.fr/license
server.iws.openapi.summary=Summary : test NB pour openAPI
server.iws.openapi.termsofservice=https://www.gaia.fr/terms
server.iws.openapi.title=Titres : APIs for IWS 3.0
server.iws.openapi.version=9.8.7
server.iws.openapi.excludelist=ConvertTemp_rest
Vous pouvez ensuite demander la mise à jour des propriétés de l’instance :
qsh
cd /qibm/proddata/os/webservices/bin
setWebServicesServerProperties.sh -server 'vsc_sndbox' -propertiesFile '/www/vsc_sndbox/conf/server.properties'
Affiche :
IWS00106I - Command completed successfully. Restart of web service or server may be required for changes to take affect.
Après redémarrage de votre instance, accès à http[s]//…./openapi/ui :
Remarque : il est aujourd’hui impossible de générer un fichier de configuration pour un serveur existant.
Les différentes propriétés :
server.xml
La commande sss.sh met à jour les propriétés openapi dans le fichier \www\instance\wlp\usr\servers\instance\server.xml
Migration des instances en version 2.6
Vous pouvez migrer une instance par la commande /qibm/proddata/os/webservices/bin/
https://www.gaia.fr/wp-content/uploads/2017/02/team1.png600600Nathanaël Bonnet/wp-content/uploads/2017/05/logogaia.pngNathanaël Bonnet2026-02-24 09:50:002026-02-23 11:56:40Open api avec IWS 3.0 – partie 2
Depuis décembre 2025, le compilateur RPG permet la déclaration d’une énumération typée, ainsi que de variables de même type que l’énumération.
Prérequis
Avoir les PTFs :
7.5:
ILE RPG compiler: 5770WDS SJ08375
7.6:
ILE RPG compiler: 5770WDS SJ08384
ILE RPG compiler, TGTRLS(V7R5M0): 5770WDS SJ08394
Syntaxe
Par exemple :
Il faut indiquer le type précis de l’énumération, ici CHAR(3). Les valeurs des constantes énumérées doivent correspondre au type.
DFT indique une valeur par défaut : 1 et 1 seule, facultatif.
Il est impossible de définir une énumération comme une autre énumération :
Par contre, vous pouvez définir des variables comme une énumération typée :
Quelques règles
une valeur par défaut supportée par énumération
initialisation des variables ou zone de DS par une valeur de l’énumération :
dcl-s myCall1 like(CALL_TYPE) inz(CALL_TYPE.DISPLAY) : OK
dcl-s myCall2 like(CALL_TYPE) inz('DSP') : Erreur, même si la valeur existe dans l’énumération
si inz est indiqué sans valeur, la valeur par défaut de l’énumération est utilisée
de même pour l’affectation d’une nouvelle valeur, doit se faire via l’énumération, quelque soit le type de valeur :
myCall1 = CALL_TYPE.UPDATE : OK
myCall1 = 'UPD' oumyCall1 = ('U' + 'PD') : Erreur
Les fonctions %hival et %loval fonctionnent
Contrairement à*hival et*loval
En tant que tableau ou liste
Il est possible d’utiliser une énumération partout où un tableau est utilisable, sauf avec :
SORTA
%elem
%lookup
%subarr
Par exemple en tant que liste :
Domaine de validité
Seules les valeur de l’énumération sont utilisables, toute autre valeur provoque une erreur de compilation.
Toutefois, il est possible de contourner ce fonctionnement.
Pour les variables de type numérique, les calculs sont autorisés :
En passant avec un pointeur :
En paramètre de procédure
Cela permet d’indiquer explicitement les valeurs autorisés pour les paramètres définis comme une énumération :
la valeur de retour est définie parlike(ERROR) et ne pourra avoir que les valeurs définies
le paramètre p_callType est défini parlike(CALL_TYPE) pour lequel les valeurs sont également définies
C’est beaucoup plus pertinent qu’un commentaire, le compilateur effetuant le contrôle.
Précompilateur SQL
Les valeurs énumérées sont reconnues en tant que constantes, et les variables définies depuis une énumération sont utilisables :
Par contre, l’affectation d’une valeur non énumérée est possible :
L’utilisation en tant que liste de valeurs dans un IN SQL n’est pas supportée :
option de compilation CCSID(*EXACT)
Si votre énumération est définie en CHAR ou VARCHAR et contient des valeurs non définies par des constantes hexadécimales, c’est à dire la plupart des cas, vous devez indiquer ctl-opt ccsid(*exact).
C’est une obligation afin que le compilateur ne fasse pas de supposition incorrecte sur le CCSID des littéraux pour comparaison avec les variables de vos programmes. Aucune conversion implicite n’est effectuée et cela évote les incohérences que l’on peut avoir, particulièrement avec des fichiers source dans l’IFS, généralement encodés en UTF-8.
BOM signifie Byte Order Mark 👉 en français : marque d’ordre des octets
C’est une séquence d’octets placée au tout début d’un fichier texte pour indiquer :
l’encodage du fichier
parfois l’ordre des octets (endianness)
📌 À quoi sert un BOM ? 1️⃣ Identifier l’encodage
Quand un logiciel ouvre un fichier, le BOM lui dit :
« Ce fichier est en UTF-8 / UTF-16 / UTF-32 »
Sans BOM, certains outils devinent l’encodage… et se trompent.
2️⃣ Indiquer l’ordre des octets (UTF-16 / UTF-32)
Pour les encodages multi-octets :
Little Endian
Big Endian
Le BOM permet de savoir dans quel ordre lire les octets.
Sur L’IBMi on l’utilisera pour échanger un fichier UTF8 avec un autre système que le réclame, ou à l’inverse il faudra l’enlever sur un fichier recu !
Voici 2 procédures pour vous aider et une requête
Une requête pour afficher le BOM sur un fichier IFS
WITH FICHIER AS (
SELECT DATA
FROM TABLE (
QSYS2.IFS_READ_BINARY('/tmp/test.txt')
)
)
SELECT
HEX(SUBSTR(DATA, 1, 4)) AS BOM_HEXA,
CASE
WHEN SUBSTR(DATA, 1, 3) = X'EFBBBF'
THEN 'UTF-8 avec BOM'
WHEN SUBSTR(DATA, 1, 2) = X'FFFE'
THEN 'UTF-16 Little Endian'
WHEN SUBSTR(DATA, 1, 2) = X'FEFF'
THEN 'UTF-16 Big Endian'
WHEN SUBSTR(DATA, 1, 4) = X'FFFE0000'
THEN 'UTF-32 Little Endian'
WHEN SUBSTR(DATA, 1, 4) = X'0000FEFF'
THEN 'UTF-32 Big Endian'
ELSE
'Aucun BOM détecté (UTF-8 sans BOM probable)'
END AS ENCODAGE_DETECTE
FROM FICHIER;
Une procédure pour ajouter un BOM sur un fichier à envoyer
CREATE OR REPLACE PROCEDURE AJOUTER_BOM (
IN p_path VARCHAR(1024) CCSID 1208,
IN p_bom VARCHAR(10)
)
LANGUAGE SQL
BEGIN
DECLARE v_data BLOB(10M);
DECLARE v_new_data BLOB(10M);
DECLARE v_bom BLOB(4);-- Déterminer le BOM à ajouter
SET v_bom =
CASE UPPER(p_bom)
WHEN 'UTF8' THEN X'EFBBBF'
WHEN 'UTF16LE' THEN X'FFFE'
WHEN 'UTF16BE' THEN X'FEFF'
ELSE NULL
END;
IF v_bom IS NULL THEN
SIGNAL SQLSTATE '38001'
SET MESSAGE_TEXT = 'BOM non reconnu (UTF8, UTF16LE, UTF16BE)';
END IF;
-- Lire le fichier
SELECT DATA
INTO v_data
FROM TABLE (
QSYS2.IFS_READ_BINARY(p_path)
);
-- Vérifier si le BOM est déjà présent
IF SUBSTR(v_data, 1, LENGTH(v_bom)) <> v_bom THEN
SET v_new_data = v_bom || v_data;
-- Réécriture du fichier avec BOM
CALL QSYS2.IFS_WRITE_BINARY(
PATH_NAME => p_path,
DATA => v_new_data,
REPLACE => 1
);
END IF;
END;
Une procédure pour enlever le BOM
CREATE OR REPLACE PROCEDURE SUPPRIMER_BOM (
IN p_path VARCHAR(1024) CCSID 1208,
IN p_bom VARCHAR(10)
)
LANGUAGE SQL
BEGIN
DECLARE v_data BLOB(10M);
DECLARE v_bom BLOB(4);
DECLARE v_len INTEGER;-- Déterminer le BOM à supprimer
SET v_bom =
CASE UPPER(p_bom)
WHEN 'UTF8' THEN X'EFBBBF'
WHEN 'UTF16LE' THEN X'FFFE'
WHEN 'UTF16BE' THEN X'FEFF'
WHEN 'UTF32LE' THEN X'FFFE0000'
WHEN 'UTF32BE' THEN X'0000FEFF'
ELSE NULL
END;
IF v_bom IS NULL THEN
SIGNAL SQLSTATE '38001'
SET MESSAGE_TEXT =
'BOM non reconnu (UTF8, UTF16LE, UTF16BE, UTF32LE, UTF32BE)';
END IF;
SET v_len = LENGTH(v_bom);
-- Lire le fichier
SELECT DATA
INTO v_data
FROM TABLE (
QSYS2.IFS_READ_BINARY(p_path)
);
-- Vérifier et supprimer le BOM demandé
IF SUBSTR(v_data, 1, v_len) = v_bom THEN
SET v_data = SUBSTR(v_data, v_len + 1);
-- Réécrire le fichier sans BOM
CALL QSYS2.IFS_WRITE_BINARY(
PATH_NAME => p_path,
DATA => v_data,
REPLACE => 1
);
END IF;
END;
Conclusion
Sur IBMi ca ne sert à rien le CCSID donne cette information
https://www.gaia.fr/wp-content/uploads/2017/02/team1.png600600Nathanaël Bonnet/wp-content/uploads/2017/05/logogaia.pngNathanaël Bonnet2026-01-20 09:50:002026-01-19 11:18:19Open api avec IWS 3.0
Si vous êtes utilisateur de SSO (Single Sign On) sur l’IBM i, alors vous utilisez l’EIM (Enterprise Identity Mapping).
Pour rappel (en très simplifié), le SSO vous permet de propager votre authentification Windows jusqu’à l’IBM i de sorte que n’avez pas besoin de saisir votre profil/mot de passe : une association entre vos comptes Windows et IBM i est réalisée et prise en compte automatiquement.
Pour gérer ces associations, vous pouvez utiliser IBM Navigator for i :
A partir de là vous avez accès à toute la gestion de l’annuaire (nécessite une authentification).
Bien entendu, ces fonctions sont critiques d’un point de vue de la sécurité : une modification de la configuration peut empêcher toute connexion, ou au contraire permettre une connexion avec un profil IBM i élevé !
IBM a donc délivré une nouvelle fonction d’usage QIBM_NAV_SECURITY_EIM (EIM related security) à cet effet : limiter l’accès aux fonctions EIM via Navigator for i.
La valeur par défaut est *ALLOWED pour tous -> vous devriez la passer à *DENIED !
Dès lors, si vous tentez d’accéder aux fonctions EIM, vous obtenez :
Si vous avez assisté à l’événement Securiti 2025 organisé par i.gayte.it, nous avions présenté une fonctionnalité SQL permettant de limiter l’accès aux informations du plan cache SQL.
En effet, ce dernier contient de nombreuses informations nécessaires à l’adaptation du moteur SQL. Mais il contient aussi les données utilisées dans vos requêtes : constantes littérales, valeurs de comparaisons …
Bien entendu, certaines valeurs sont à protéger, y compris des utilisateurs ayant les droits de consulter le plan cache.
https://www.gaia.fr/wp-content/uploads/2017/02/team1.png600600Nathanaël Bonnet/wp-content/uploads/2017/05/logogaia.pngNathanaël Bonnet2025-12-23 09:50:002025-12-16 08:44:24Sécurité du plan Cache SQL
https://www.gaia.fr/wp-content/uploads/2017/02/team3.png600600Pierre-Louis BERTHOIN/wp-content/uploads/2017/05/logogaia.pngPierre-Louis BERTHOIN2025-12-15 10:36:362025-12-15 11:14:49Copier vos données VIA DDM/DRDA
