IBM i 7.6 TR2 / 7.5 TR8

Date de disponibilité : 24 juillet 2026

Généralités

Ces deux Technology Refreshes partagent l'essentiel des nouveautés. Quelques fonctions sont réservées à IBM i 7.6 TR2 (signalées par (7.6 uniquement)).

Matériels supportés :

• IBM i 7.6 TR2 : Power10 et Power11 uniquement
• IBM i 7.5 TR8 : Power9, Power10 et Power11

Plateforme & I/O

Nouveau serveur IBM Power S1112

Serveur Power11 1 socket, compact (2U demi-largeur rack, ou tour), entrée de gamme pour les clients IBM i P05.

Ficher technique https://www.ibm.com/downloads/documents/fr-fr/16ddce7bf954848c

Modèles :

• 9242-21B — Format rack, 4 ou 10 cœurs
• 9242-21T — Format tour, 4 cœurs uniquement

Processeurs Power11 (eSCM) :

• #EJMT — 4 cœurs, 3,60 à 4,0 GHz (rack et tour) — déconfigurable à 1 cœur actif (#2319)
• #EJSV — 10 cœurs, 3,05 à 4,0 GHz (rack uniquement)
• Performance jusqu'à 2,5× supérieure par cœur par rapport à la génération précédente
• MMA (Matrix Math Accelerator) intégré : inférence IA et machine learning on-chip, sans accélérateur externe

IBM i sur S1112 :

• Groupe de facturation P05 uniquement — maximum 4 partitions IBM i
• IBM i limité à 4 cœurs et 64 Go de mémoire
• Les cœurs et la mémoire supplémentaires (jusqu'à 10 cœurs / 512 Go) sont disponibles pour Linux, AIX ou VIOS
• Stockage NVMe jusqu'à 12,8 To (6,4 To en miroir), partageable entre IBM i et les autres workloads
• Versions IBM i supportées : 7.6 TR2, 7.5 TR8, 7.4 TR12

Mémoire DDR5 (DDIMMs) :

• 4 slots DDIMM, minimum 64 Go — maximum 512 Go
• Options : 64 Go (#EM54), 128 Go (#EM5B), 256 Go (#EM5V)
• DDR5 à 4 000 ou 4 800 MHz, ECC, chipkill, réparation dynamique de lignes

Connectique :

• 4 slots PCIe (2× Gen4 x16 + 2× Gen4 x8)
• 4 slots NVMe U.2 intégrés
• 1 port HMC GbE RJ45, 2 ports USB 3.0
• Extension possible : tiroir PCIe Gen4 (#ENZ0) avec module fanout 6 slots (#ENZF) — rack uniquement

Sécurité et disponibilité :

• Chiffrement Quantum-Safe intégré (secure boot, Live Partition Mobility)
• Alimentation redondante hot-swap (2× 800 W Titanium, #EB3Y)
• Refroidissement redondant hot-swap
• BMC (eBMC) avec interface Redfish, ASMI, surveillance proactive
• Live Partition Mobility (LPM) inclus avec PowerVM Enterprise Edition (#EPVT)

CBU (Capacity BackUp) :

• Disponible (#0444) : transfert temporaire des licences IBM i vers un système secondaire pour HA/DR

Systèmes IBM i compatibles CBU (primaire P05) : S1012, S1014, S1022s, S1022, S1122, S1112

Nouveaux modules de stockage NVMe PCIe4

Nouveaux adaptateurs réseau

• #EAPE, #EAPF — PCIe5 x16, 2 ports 200 GbE RoCE
• #EAPC, #EAPD — PCIe4 x16, 4 ports 25/10/1 GbE RoCE SFP28
• Support natif et VIOS client pour la bibliothèque de bandes virtuelles IBM TS7785

Système d'exploitation

Migrate While Active (5770-DBM)

Réduction des temps d'arrêt planifiés lors des maintenances et mises à jour OS.

• La cible est maintenue synchronisée pendant que la production continue sur la source
• Nouvelles méthodes de copie initiale : FlashCopy et Global Copy (réplication externe par le stockage)
• Améliorations de l'estimation et de l'expérience utilisateur pour naviguer entre les phases

Virtual Ethernet Multi-Queue

Distribution du traitement réseau sur plusieurs cœurs CPU :

• Meilleur débit en environnement à fort trafic
• Scalabilité améliorée avec le nombre de processeurs disponibles
• Sans action de configuration : actif dès l'application du groupe PTF

Accès sécurisé aux consoles Linux distantes

Nouveau paramètre système pour imposer l'utilisation d'un tunnel OpenSSH pour l'accès à la console d'une partition Linux invitée (configuration VPM). Toutes les données en transit sont chiffrées.

Sécurité

SMTP — Support OAuth 2.0

IBM i SMTP supporte désormais OAuth 2.0 :

• Protocole de délégation via un compte de service (Service Account with Domain-Wide Delegation)
• Fournisseurs supportés : Gmail (Google Workspace) et Office 365 (Microsoft 365)
• Configuration via CHGSMTPA ou Navigator for i
• L'administrateur crée un fichier IFS JSON contenant les informations OAuth du fournisseur
• L'envoi d'e-mail reste identique après configuration initiale

Cryptographic Services — BYOK avec IBM Cloud Key Protect (7.6 TR2 uniquement)

Intégration native avec IBM Cloud Key Protect pour la gestion de clés :

• Export d'une clé AES locale vers Key Protect : commande CRTEKMKEY ou Navigator
• Enveloppement d'une clé locale avec une clé racine Key Protect : commande WRPEKMKEY
• Utilisation d'une clé EKMD avec les APIs Cryptographic Services existantes
• Stockage et enveloppement des Key Parts de la Master Key dans Key Protect

Protection de la clé Master (7.6 TR2 uniquement)

• La Save/Restore Key enveloppe les Master Keys et devient obligatoire (valeur choisie par l'administrateur)
• Combinable avec le chiffrement ASP de Sysbase (ASP1) pour bloquer l'IPL jusqu'à fourniture de la clé
• Deux méthodes de fourniture de la clé à l'IPL :
  • Platform Keystore (PKS) : clé mise en cache dans la mémoire non volatile du processeur de service
  • Remote Key Agent (RKA) : fourniture manuelle depuis un autre LPAR IBM i

Cluster + MFA (7.6 TR2 uniquement)

Nouvelle version de cluster 12 avec support des profils utilisateurs MFA activés :

• Les attributs MFA doivent correspondre sur tous les nœuds du cluster
• ALWADDCLU(*RQSAUT) requis sur chaque nœud, avec certificat de confiance mutuelle
• Une authentification initiale est établie entre les nœuds au premier démarrage en version 12

Db2 for i / SQL

Évolutions fonctionnelles

Triggers — pseudo-colonnes

Les triggers SQL ont accès aux colonnes pseudo TRIGGER_LIBRARY_NAME, TRIGGER_FILE_NAME et TRIGGER_MEMBER_NAME de la table physique déclenchante, directement dans la logique du trigger.

CREATE OR REPLACE TRIGGER NB.CLIENT_AFTER_INSERT
    BEFORE INSERT ON NB.CLIENT
    REFERENCING NEW ROW AS N
    FOR EACH ROW MODE DB2ROW 
  BEGIN
    DECLARE V_TRIG_FILE, V_TRIG_LIB, V_TRIG_MBR VARCHAR(10);
  
    SET V_TRIG_FILE = TRIGGER_FILE_NAME;
    SET V_TRIG_LIB  = TRIGGER_FILE_LIBRARY_NAME;
    SET V_TRIG_MBR  = TRIGGER_FILE_MEMBER_NAME;
  
    IF V_TRIG_LIB = 'NB' and V_TRIG_MBR = 'CLIENT' THEN 
      SET N.NOMCLIENT = UPPER(TRIM(N.NOMCLIENT)) concat ' - test' ;
    END IF ;
   
  END;

Résultat avant / après mise en place du trigger :

URL_ENCODE

La fonction scalaire URL_ENCODE supporte désormais la spécification RFC 3986 (cf RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax) via un second paramètre optionnel.

Ce paramètre peut prendre les valeurs :

• RFC1738 (défaut)
• RFC3986

La différence est dans l'encodage des caractères blancs.

Les APIs REST attendent des données au format RFC3986 aujourd'hui, alors que les données formulaire HTTP (application/x-www-form-urlencoded) sont encore plus souvent en RFC1738.

FROM_SYSTEM_TIMESTAMP / TO_SYSTEM_TIMESTAMP

Nouvelles fonctions pour convertir simplement entre un TIMESTAMP standard et le timestamp système interne. Cette demande d'évolution provient de l'Idea IBMI-I-4788 (Add a new service that will convert *DTS | IBM Power Ideas Portal).

Concrètement, IBM documente ce format interne comme une valeur de type CHAR(8) FOR BIT DATA côté TO_SYSTEM_TIMESTAMP, donc un bloc binaire de 8 octets et non une chaîne lisible. Côté FROM_SYSTEM_TIMESTAMP, la fonction attend cette même valeur binaire et la reconvertit en TIMESTAMP(6).

Pour convertir ces TIMESTAMP, la solution était jusqu'ici d'utiliser l'API QWCCVTDT.

Exemple pratique :

• VALUES HEX(TO_SYSTEM_TIMESTAMP(CURRENT TIMESTAMP)) renvoie une valeur hexadécimale de 16 caractères, soit les 8 octets du timestamp système.
• VALUES FROM_SYSTEM_TIMESTAMP(X'AEAA174D8BDF4001') retransforme ce binaire en TIMESTAMP lisible.

Ces fonctions sont utiles dans les requêtes qui nécessitent de manipuler les formats d'horodatage *DTS : journaux, API, quelques fichiers système.

SELF — SQL Error Logging Facility

Les utilisateurs sans *ALLOBJ peuvent désormais consulter dans QSYS2.SQL_ERROR_LOG les lignes correspondant à leur propre activité SQL (variable globale SYSIBMADM.SELFCODES).

LIKE(*EXT) dans le précompilateur SQL RPG

DCL-S salary1 LIKE(*EXT : 'EMPSALARY' : 'MYFILE');
DCL-S salary2 LIKE(*EXT : 'EMPLOYEE_SALARY' : 'MYFILE');

Définition d'une variable calquée sur un champ d'un fichier externe (nom court ou alternatif).

Sécurité Db2 (7.6 uniquement)

• Contrôle d'utilisation de la fonction QIBM_IOSYSCFG_DDM

Cette fonction d'usage permet l’accès aux commandes CL de gestion distribuée des données (DDM) et aux services SQL pour les opérations *sans avoir le droit spécial IOSYSCFG : CHGDDMF / Instruction CREATE ALIAS / CRTDDMF / DLTF lorsque SYSTEM(*RMT) est spécifié / DSPDDMF / WRKDDMF.

Nettoyage automatique

• SQE : purge automatique des données de support après 90 jours (configurable via SYSIBMADM.QIBM_SQEDEBUG_BY_DAYS)

La valeur est modifiable.

Les données concernées sont dans les répertoires /QIBM/UserData/OS400/SQE et /QIBM/UserData/OS400/SQE/ERRORS

Services IBM i — nouveaux

synthèse

(1) Nécessite lautorité spéciale *IOSYSCFG + doit être lié à un identifiant utilisateur SST avec privilège de gestion des outils de service.

Détails

QSYS2.CREATE_DATA_JOURNAL_READER()

Cette fonction permet de simplifier l'exploitation des données stockées dans les journaux. En effet, avec la fonction existante QSYS2.DISPLAY, les données sont renvoyées dans le colonne ENTRY_DATA. Vous avez l'image brute (buffer) de l'enregistrement.

Pour décoder ces informations correctement, c'est à dire suivant le format du fichier, vous devez réaliser des traitements complémentaires (découpage par SQL, facilités maintenant par INTERPRET, copie dans un fichier de travail ...).

La fonction QSYS2.CREATE_DATA_JOURNAL_READER créé une fonction de lecture des journaux dédiée à une table (ie à son format) !

Exemple de bout en bout

Création de la table

La table est-elle journalisée ?

Sinon STRJRNPF.

Des données pour alimenter le journal :

Création de la fonction de lecture du journal :

Le dernier paramètre indique le schéma de création de la fonction.

La fonction créée porte le nom : DISPLAY_JOURNAL_{schema}_{table}. Dans notre cas DISPLAY_JOURNAL_NB_TESTABLE. Vous pouvez la renommer par la suite si vous souhaitez une autre convention de nommage.

DISPLAY_JOURNAL est utilisable, les données sont retournées en binaire (hexadécimal)

Avec la fonction READER, nous avons accès aux données de table décodées + les informations du poste de journal :

Que vous pouvez utiliser dans vos requêtes :

Détail de la procédure créée (ici avec ACS) :

Les paramètres sont définis, sur les informations du journal uniquement

Il est recommandé d'utiliser ces paramètres pour contraindre les recherches plutôt que les clauses WHERE (performance) :

SELECT *
FROM TABLE (NBJRN.DISPLAY_JOURNAL_NB_TESTABLE(STARTING_TIMESTAMP =>  current timestamp - 2 hours ))

Vous avez accès au code de la procédure (globalement basée sur la remise en forme des informations fournies par DISPLAY_JOURNAL via INTERPRET) : libre à vous d'adapter le code !

⚠️ En cas de modification de la table, la fonction devient incohérente avec la nouvelle description de la table. Si vous avez ajouté une colonne en fin de table, elle est ignorée. Les autres cas rendent le décodage imprévisible.

Après recréation de la fonction :

Limites : certaines colonnes ne peuvent pas être décodées et retournées

• BLOB
• CLOB
• DBCLOB
• XML
• DATALINK
• types définis utilisateur (UDT)

Droits nécessaires :

• Pour la création de la fonction : *ADD + *EXECUTE sur la bibliothèque de création, droit d'éxécuter CREATE FUNCTION
• Pour l'utilisation de la fonction :
  • créée avec *PUBLIC *EXCLUDE. Il faut donc donner explicitement des autorations.
  • 
  • à l'appel, il faut avoir : *EXECUTE et *OBJOPR sur la fonction, *USE sur la bibliothèque de la fonction, *USE sur le fichier journalisé, *EXECUTE sur la bibliothèque du fichier journalisé, *USE sur le journal, *EXECUTE sur la bibliothèque du journal, *USE sur les récepteurs

⚠️ On voit les journaux comme des objets techniques, mais ils comportent de la donnée : la sécurité des journaux et des fonctions permettant d'accèder à la donnée est importante.

QSYS2.EKM_INFO() (7.6 uniquement)

Retourne les informations de configuration EKM (équivalent à DSPEKMD).

QSYS2.GEOGRAPHIC_MIRRORING_INFO

La vue GEOGRAPHIC_MIRRORING_INFO renvoie des informations iASP qui disposent de miroir géographique configuré.

Les valeurs retournées pour les colonnes dans la vue sont similaires à celles retournées par l’API QYASPOL (Open Liste des API ASP).

Autorisation : L’appelant doit avoir *IOSYSCFG ou être autorisé à la fonction d'usage QIBM_IOSYSCFG_VIEW. Les lignes sont retournées pour les devices pour lesquels l'utilisateur dispose du droit *USE.

QSYS2.ADD_SERVICE_TOOLS_SERVER_CONFIGURATION_ENTRY (Procédure, 7.6 uniquement), QSYS2.CHANGE_SERVICE_TOOLS_SERVER_CONFIGURATION_ENTRY (Procédure, 7.6 uniquement), QSYS2.REMOVE_SERVICE_TOOLS_SERVER_CONFIGURATION_ENTRY_INFO (Procédure, 7.6 uniquement), QSYS2.SERVICE_TOOLS_SERVER_CONFIGURATION_ENTRY (Vue, 7.6 uniquement)

Ces nouveaux services permettent de gèrer (créer, modifier, supprimer et voir le détail) les configurations du Service Tools Server.

Pour rappel, la configuration active est accessible via la vue QSYS2.SERVICE.

EN natif, cela correspond aux fonctions disponibles dans SST/DST :

SYSTOOLS.CVE_INFO() (UDTF)

En paramètre (optionnel) vous pouvez passer le n° de version IBM i (sinon, versionde la partition).

SELECT * FROM TABLE (SYSTOOLS.CVE_INFO('7.6'))

SYSTOOLS.GROUP_PTF_CURRENCY_LOCAL()

La vue GROUP_PTF_CURRENCY permet de comparer les Group PTFs installés vs ceux disponibles. Cela nécessite une connexion internet :

select * from systools.GROUP_PTF_CURRENCY order by ptf_group_id

Produit :

Si vous n'avez pas de connexion internet sortante sur la partition, vous pouvez récupèrer manuellement la liste des groupes disponibles chez IBM :

https://public.dhe.ibm.com/services/us/igsc/PSP/xmldoc.xml

Enregistrer le fichier XML sur l'IFS (via Access Client Solutions par exemple) :

Maintenant :

SELECT *
  FROM TABLE (
    SYSTOOLS.GROUP_PTF_CURRENCY_LOCAL(
        PATH_NAME => '/home/NB/xmldoc.xml'
    )
)

Produit le même résultat que GROUP_PTF_CURENCY :

SYSTOOLS.CHECK_COMMAND_SYNTAX()

Permet de valider la syntaxe d'une commande CL (équivalent API QCMDCHK).

values SYSTOOLS.CHECK_COMMAND_SYNTAX('CRTDTAARA DTAARA(NB/START) TYPE(*CHAR) LEN(30) VALUE(''2026-08-31 10:19:25.319763'') TEXT(''horodatage début'')') ;

values SYSTOOLS.CHECK_COMMAND_SYNTAX('CRTDTAARA DTAARA(NB/START) TYPE(*CHAR) LEN(30) VALUE(''' concat char(current_timestamp) concat ''') TEXT(''horodatage début'')') ;

create variable nb.cmd varchar(128) ; 
set nb.cmd = 'CRTDTAARA DTAARA(NB/START) TYPE(*CHAR) LEN(30) VALUE(''' concat char(current_timestamp) concat ''') TEXT(''horodatage début'')' ;
values SYSTOOLS.CHECK_COMMAND_SYNTAX(nb.cmd) ;

WITH CMD (CMD_STRING) AS (VALUES 'CRTDTAARA DTAARA(NB/START) TYPE(*CHAR) LEN(30) VALUE(''' concat char(current_timestamp) concat ''') TEXT(''horodatage début'')' )
  SELECT CASE WHEN SYSTOOLS.CHECK_COMMAND_SYNTAX(CMD_STRING) IS TRUE 
                   THEN QSYS2.QCMDEXC(CMD_STRING)
              ELSE -1 END, CMD_STRING
    FROM CMD;

SYSTOOLS.JOB_NAME(), SYSTOOLS.JOB_NUMBER(), SYSTOOLS.JOB_USER(), SYSTOOLS.JOB_NAME_DETAILS()

Permettent de découper un string représentant un idnetifiant complet de travail sous la forme 'nnnnnn/uuuuuuuuuu/jjjjjjjjjj' :

VALUES qsys2.job_name, 
        SYSTOOLS.JOB_NAME(qsys2.job_name), 
        SYSTOOLS.JOB_NUMBER(qsys2.job_name), 
        SYSTOOLS.JOB_USER(qsys2.job_name) ;

Produit :

JOB_NAME_DETAILS() est une fonction table qui renvoie les 3 informations en une fois :

SELECT * FROM TABLE (SYSTOOLS.JOB_NAME_DETAILS(qsys2.job_name));

SYSTOOLS.OVERRIDE_INFO_ALL

Equivalent de la commande DSPOVR : renvoie une table détaillant chaque substitutions de fichiers pour le travail. La colonne KEYWORD_SPECIFICATIONS avec l'ensemble des mots clés.

SYSTOOLS.AUDIT_JOURNAL_JD() et SYSTOOLS.AUDIT_JOURNAL_RU()

• JD = changement du profil utilisateur (USER) associé à une Job Description. C'est une entrée intéressante pour détecter des élévations de privilèges ou des modifications de contexte d'exécution.
• RU = restauration des autorités privées d'un utilisateur lors d'une opération de restauration. C'est principalement une entrée de contrôle de cohérence des restaurations.

SELECT * 
  FROM TABLE (
      SYSTOOLS.AUDIT_JOURNAL_JD ()
    )

Services IBM i — améliorés

Synthèse

Détails

QSYS2.JOBLOG_INFO

Nouveaux paramètres MESSAGE_ORDER, MESSAGE_LIMIT et MESSAGE_TIMESTAMP :

• MESSAGE_ORDER : ASCENDING (défaut) ou DESCENDING
• MESSAGE_LIMIT : doit être > 0. Nombre de lignes à retourner. Par défaut : toutes les lignes
• MESSAGE_TIMESTAMP : horodatage du message le plus ancien retourné. Seules les messages avec une valeur >= à cet horodatage sont renvoyés.

SELECT * FROM TABLE(QSYS2.JOBLOG_INFO('*',
                                      MESSAGE_ORDER => 'DESCENDING',
                                      MESSAGE_LIMIT => 10,
                                      MESSAGE_TIMESTAMP => CURRENT TIMESTAMP - 30 MINUTES))

Cela évite d'ajouter une clause WHERE, ORDER BY ou LIMIT dans la sélection gloable, et procure donc une meilleure performance avec un filtrage plus fin.

QSYS2.QCMDEXC()

Pour la fonction scalaire uniquement, pas la procédure : ajout d'un paramètre PRINT (printf)

• ERROR : la commande est écrite dans la joblog en cas d'erreur
• NONE : défaut
• VERBOSE : la commande est toujours écrite dans la joblog

values QSYS2.QCMDEXC('CRTDTAARA DTAARA(NB/START)  TYPE(*CHAR) LEN(30)') ;             -- existe déjà
values QSYS2.QCMDEXC('CRTDTAARA DTAARA(NB/START)  TYPE(*CHAR) LEN(30)', 'ERROR') ;    -- existe déjà
values QSYS2.QCMDEXC('CRTDTAARA DTAARA(NB/START2) TYPE(*CHAR) LEN(30)') ;             -- n'existe pas
values QSYS2.QCMDEXC('CRTDTAARA DTAARA(NB/START3) TYPE(*CHAR) LEN(30)', 'ERROR') ;    -- n'existe pas
values QSYS2.QCMDEXC('CRTDTAARA DTAARA(NB/START4) TYPE(*CHAR) LEN(30)', 'VERBOSE') ;  -- n'existe pas

SELECT * FROM TABLE(QSYS2.JOBLOG_INFO('*', MESSAGE_ORDER => 'DESCENDING',
                                      MESSAGE_TIMESTAMP => CURRENT TIMESTAMP - 2 MINUTES))
WHERE MESSAGE_ID is null and FROM_PROCEDURE = 'Qp0zVLprintf' ;

Produit :

QSYS2.SCHEDULED_JOB_INFO

Ajout d'une nouvelle colonne SCHEDULED_JOB_ENTRY_NUMBER_CHAR en complément de la colonne SCHEDULED_JOB_ENTRY_NUMBER : numéro de l'entrée du 6 CHAR formaté avec les zéros de gauche.

Cela permet une meilleure intégration pour les commandes CL :

Joblog pour la syntaxe avec SCHEDULED_JOB_ENTRY_NUMBER :

QSYS2.SYSDISKSTAT / SYSDISKSTAT()

Ajout de la colonne RESOURCE_STATUS avec les valeurs suivantes possibles :

• ACTIVE : la ressource est active
• NOT ELIGIBLE : L'unité logique (LUN) HyperSwap ne peut pas être utilisée actuellement.
• PASSIVE : La ressource RESOURCE_NAME n'est pas active.
• RESUMING : La LUN HyperSwap est en cours de resynchronisation des données.
• STANDBY : La LUN HyperSwap est maintenue en réserve (standby) tandis que l'autre LUN fournit activement les données. Elle est prête à prendre immédiatement le relais si la LUN principale devient indisponible.
• STANDBY FAILED : IBM i n'est pas en mesure de contacter cette LUN.The IBM i cannot contact the LUN
• null si inconnu !

Ici nos disques sont virtualisés via une partition IBM i hôte :

QSYS2.SYSTEM_STATUS() / SYSTEM_STATUS_INFO / SYSTEM_STATUS_INFO_BASIC

Ajout de la colonne PARTITION_UUID : identifiant unique de partition (deux partitions ne doivent jamais avoir le même UUID). Il est utilisé par différents composants de l'écosystème Power (HMC, PowerVM, APIs DLPAR, outils de gestion, etc.) pour référencer une partition sans ambiguïté.

QSYS2.ASP_INFO (7.6 uniquement)

Ajout des colonnes :

• GEOGRAPHIC_MIRROR_TRANSMISSION_DELIVERY
• GEOGRAPHIC_MIRROR_SYNCHRONIZATION_STATUS
• GEOGRAPHIC_MIRROR_SYNCHRONIZATION_PROGRESS
• PARTITION_MIRROR_TARGET_IP_ADDRESS
• PARTITION_MIRROR_TARGET_IP_ADDRESS_TYPE

Permet principalement d'obtenir les informations sur PowerHA Geographic Mirroring.

SYSTOOLS.GENERATE_SPREADSHEET()

Nouveau paramètre sheet-name : permet d'indiquer le nom de la feuille.

VALUES SYSTOOLS.GENERATE_SPREADSHEET(
                     PATH_NAME     => '/home/NB/employee_nb', 
                     SPREADSHEET_TYPE => 'xlsx',
                     OVERWRITE => 'REPLACE', 
                     COLUMN_HEADINGS => 'COLUMN',
                     FILE_NAME     => 'EMPLOYEE',
                     LIBRARY_NAME  => 'SQLSAMPLE');
VALUES SYSTOOLS.GENERATE_SPREADSHEET(
                     PATH_NAME     => '/home/NB/employee', 
                     SPREADSHEET_TYPE => 'xlsx', 
                     OVERWRITE => 'UPDATE', 
                     COLUMN_HEADINGS => 'COLUMN',
                     FILE_NAME     => 'EMPLOYEE',
                     LIBRARY_NAME  => 'SQLSAMPLE',
                     SHEET_NAME => 'employee1');

Cela appelle en réalité les fonctions ACS :

Aujourd'hui, un bug sur nos systèmes :

Ou bien non pris en compte :

La fonction équivalente via ACS fonctionne :

Développement applicatif

RPG (5770-WDS)

Assertions : ASSERT-F et ASSERT-T

Definition

Une assertion est une expression booleenne que le developpeur affirme etre vraie a un point precis de l'execution. Si la condition n'est pas satisfaite, le programme signale immediatement une erreur et s'arrete (ou leve une exception).

"Un assertion est un invariant : une verite que votre code garantit a un instant t. Si elle est fausse, c'est un bug — pas une donnee incorrecte."

Deux grandes categories d'assertions :

Les assertions ne remplacent pas la gestion des erreurs (MONITOR / ON-ERROR) : elles verifient des conditions qui ne devraient jamais etre fausses si le code est correct.

Usage dans les autres langages

Les assertions sont presentes dans pratiquement tous les langages modernes. Leur point commun : elles peuvent etre desactivees a la compilation ou au runtime pour la production.

Vue comparative

Le modele C (reference historique)

#include <assert.h>

int diviser(int a, int b) {
    assert(b != 0);   // L'appelant NE DOIT PAS passer zero
    return a / b;
}

Si b == 0, le programme affiche :

Assertion failed: b != 0, file calc.c, line 4

puis appelle abort(). En compilant avec -DNDEBUG, l'assert devient un no-op (aucun code genere).

Philosophie commune

Les assertions incarnent la programmation defensive et le concept de Design by Contract (Bertrand Meyer, Eiffel) :

• Precondition — ce que l'appelant garantit avant l'appel
• Postcondition — ce que la fonction garantit apres son execution
• Invariant — ce qui est vrai a tout moment pour un objet/module

flowchart LR
    A[Appelant] -->|garantit les preconditions| B[Procedure]
    B -->|garantit les postconditions| C[Resultat]
    B -->|maintient les invariants| B

Syntaxe RPG — ASSERT-T et ASSERT-F

Prerequis

PTF SI86940 (et dependances)

Le compilateur RPG doit etre en mode full free-form (**FREE).

Controle au niveau CTL-OPT

Le mot-cle ASSERT de la directive CTL-OPT (Control Options) gouverne le comportement global des assertions dans le module :

• ASSERT(*EXCP) (defaut)
  • echec d'assertion => message echappement
  • status code 00461
  • tres utile en dév
• ASSERT(*WARN)
  • echec => message diagnostic dans joblog
  • pas d'arret immediat
• ASSERT(*NONE)
  • assertions ignorees a la compilation (sauf extender A)
• ASSERT(*CALL:prototype)
  • appel d'une procedure/programme pour chaque assertion
  • tres utile en tests unitaires / instrumentation

Important : ASSERT(*NONE) ne supprime pas les assertions du source ; elles restent dans le code. Le compilateur genere simplement du code vide pour ces instructions. Il n'est donc pas necessaire de modifier le source pour desactiver les assertions.

Extender A

ASSERT-T(A) / ASSERT-F(A) force un comportement de type exception même si le mode global est *WARN ou *NONE (hors logique specifique *CALL)

Syntaxe des commandes

ASSERT-T — Assert True

ASSERT-T condition %msg( 'message optionnel' );

Declenche une exception si la condition est FAUSSE. Semantique : "J'affirme que cette condition EST vraie ici."

ASSERT-F — Assert False

ASSERT-F condition %msg( 'message optionnel' );

Declenche une exception si la condition est VRAIE. Semantique : "J'affirme que cette condition N'EST PAS vraie ici."

Syntaxes supportées

ASSERT-T condition;
ASSERT-F condition;

ASSERT-T condition %MSG('message');
ASSERT-F condition %MSG('message');

ASSERT-T condition %MSG('MSGID' : 'MSGF' : remplacement);
ASSERT-F condition %MSG('MSGID' : 'MSGF' : remplacement);

Parametres

Comportement encas d'échec

Quand une assertion echoue avec ASSERT(*EXCEPTION) :

1. Un message d'exception est envoye dans le job log.
2. L'execution s'arrete (sauf si une MONITOR / ON-EXCP capture l'exception).
3. Le message contient :
   • Le texte fourni comme second parametre
   • La procedure et le numero de ligne source
   • L'heure et l'identifiant du job

Exemple minimal

**FREE
CTL-OPT OPTION(*NODEBUGIO : *SRCSTMT) ASSERT(*EXCP) actgrp(*new);

  DCL-PI *N ;
    pNumerateur   PACKED(15:5) CONST;
    pDenominateur PACKED(15:5) CONST;
  END-PI;

  // Precondition : le denominateur ne peut pas etre zero
  ASSERT-T pDenominateur <> 0 %msg('Denominateur doit etre non nul') ;

  snd-msg %char( pNumerateur / pDenominateur ) ;

  RETURN;

A l'appel

Cas d'usage avec exemples

Cas 1 — Validation de précondition (contrat d'interface)

Scénario : Une procédure attend un paramètre dans une plage valide. L'assertion remplace un IF ... RETURN qui masquerait le bug dans l'appelant.

**FREE
CTL-OPT ASSERT(*EXCP) ;

// Calcul du montant TTC
DCL-PI *N ;
    pMontantHT  PACKED(15:2) CONST;
    pTauxTVA    PACKED(5:2)  CONST; // Attendu entre 0 et 100
END-PI;

  // Precondition : le taux est dans [0..100]
ASSERT-T pTauxTVA >= 0 AND pTauxTVA <= 100
         %msg('Taux TVA invalide : ' + %CHAR(pTauxTVA) );

snd-msg %char(pMontantHT * (1 + pTauxTVA / 100)) ;
RETURN ;

Sans assertion, un taux de -5 ou 999 produirait silencieusement un mauvais resultat. Avec l'assertion, le bug dans l'appelant est detecte immediatement, avec le contexte exact.

Cas 2 — Postcondition (resultat garanti)

Scénario : Vérifier qu'une allocation ou une initialisation s'est bien passée.

**FREE
CTL-OPT ASSERT(*EXCP) actgrp(*new) ;

dcl-s paramVal char(50) ;

chargerParametre('TAUXTVA') ;

return ;


DCL-PROC chargerParametre;
    DCL-PI *N CHAR(50);
        pCleParam CHAR(10) CONST;
    END-PI;

    DCL-S wValeur CHAR(50);

  // ... lecture en base de donnees ...
    EXEC SQL
    SELECT VALEUR INTO :wValeur
    FROM PARAMETRES
    WHERE CLE = :pCleParam
    FETCH FIRST 1 ROWS ONLY;

  // Postcondition : le parametre DOIT exister
    ASSERT-T SQLCODE = 0
          %msg( 'Parametre manquant en base : ' + pCleParam ) ;

    RETURN wValeur;
END-PROC;

Ici l'assertion exprime une invariant métier : certains parametres sont obligatoires au fonctionnement de l'application. S'ils sont absents, c'est un problème de deploiement, pas un cas d'erreur utilisateur.

Cas 3 — Vérification d'invariant dans une boucle

Scenario : S'assurer qu'un compteur ou un index reste cohérent.

**FREE
CTL-OPT ASSERT(*WARN) actgrp(*new) ;

dcl-ds Commande_t template qualified ;
    ligne uns(5) ; 
    libelle varchar(40) ;
    montant zoned(10:3) ;
end-ds ;

dcl-ds commande likeds( Commande_t ) dim(100); 

clear commande ;
commande(1).ligne = 1 ;
commande(1).libelle = 'article 1' ;
commande(1).montant = 111.11 ;
commande(2).ligne = 2 ;
commande(2).libelle = 'article 2' ;
commande(2).montant = 222.22 ;
commande(3).ligne = 3 ;
commande(3).libelle = 'article 3' ;
commande(3).montant = -333.33 ;

traiterLignes(commande : 2) ;
traiterLignes(commande : 0) ;
traiterLignes(commande : 3) ;

return ;

DCL-PROC traiterLignes;
    DCL-PI *N INT(10);
        pDS_Lignes LIKEDS(Commande_t) DIM(1000) CONST;
        pNbLignes  INT(10) CONST;
    END-PI;

    DCL-S i      INT(10);
    DCL-S wTotal PACKED(15:2);

  // Precondition sur le nombre de lignes
    ASSERT-F pNbLignes <= 0 OR pNbLignes > 1000
           %msg( 'Nombre de lignes hors limite : ' + %CHAR(pNbLignes) );

    FOR i = 1 TO pNbLignes;
    // Invariant : le montant d'une ligne ne peut pas etre negatif
        ASSERT-T pDS_Lignes(i).montant >= 0
             %msg( 'Montant negatif a la ligne ' + %CHAR(i) );
        wTotal += pDS_Lignes(i).montant;
    ENDFOR;

  // Postcondition : le total ne peut pas etre negatif
    ASSERT-F wTotal < 0 %msg( 'Total calcule negatif : ' + %CHAR(wTotal) );

    RETURN pNbLignes;
END-PROC;

A l'éxecution :

Cas 4 — ASSERT-F pour detecter une branche impossible

Scenario : Une variable ne devrait jamais atteindre une valeur spécifique après un traitement.

**FREE
CTL-OPT ASSERT(*EXCEPTION);

DCL-PROC convertirStatut;
  DCL-PI *N CHAR(20);
    pCodeStatut CHAR(2) CONST;
  END-PI;

  SELECT;
    WHEN pCodeStatut = 'OU';
      RETURN 'Ouvert';
    WHEN pCodeStatut = 'FE';
      RETURN 'Ferme';
    WHEN pCodeStatut = 'AN';
      RETURN 'Annule';
    OTHER;
      // Cette branche NE DOIT JAMAIS etre atteinte
      // si la table des codes est correctement maintenue
      ASSERT-F( *ON : 'Code statut inconnu : ' + pCodeStatut );
      RETURN 'Inconnu';
  ENDSL;
END-PROC;

ASSERT-F(*ON) est toujours faux (la condition est toujours vraie), donc cette assertion échoue systématiquement si la branche OTHER est atteinte. C'est l'equivalent RPG de throw new IllegalStateException() en Java.

Cas 5 — Sécurité d'acces mémoire / pointeurs

Scénario : Vérifier qu'un pointeur ou un handle est valide avant utilisation.

**FREE
CTL-OPT ASSERT(*WARN) actgrp(*new) ;

dcl-s handle pointer inz(*null);

utiliserHandle( handle ) ;
handle = %addr(*in) ;
utiliserHandle( handle ) ;

return ;

DCL-PROC utiliserHandle;
    DCL-PI *N;
        pHandle POINTER CONST;
    END-PI;

  // Precondition : le pointeur ne doit pas etre null
    ASSERT-T pHandle <> *NULL %msg( 'Handle nul passé à utiliserHandle' );

  // ... utilisation du pointeur ...
END-PROC;

Cas 6 — avec ASSERT(*CALL)

Scénario : Prenez le contrôle des actions à réaliser en cas d'erreur sur l'assertion.

**free
CTL-OPT ASSERT(*CALL : chkAssert) actgrp(*new) ;

dcl-s idProducteur int(10) ;
dcl-s quantite     zoned(10:2) ;


ASSERT-F idProducteur = 0  OR  quantite = 0  %MSG('id prod, qté ne peuvent pas être à 0');
ASSERT-T idProducteur <> 0 AND quantite <> 0 %MSG('id prod, qté ne peuvent pas être à 0');


return ;

DCL-PROC chkAssert;
    DCL-PI *N;
        ok IND CONST;
        msg VARCHAR(100) CONST;
    END-PI;

    log_result (ok : msg);

    IF NOT ok;
        SND-MSG *info 'Assertion error: ' + msg ;
    ENDIF;

END-PROC;

Produit

SND-MSG *INFO ici pour montrer l'éxécution de la seconde asertion. Un SND-MSG *ESCAPE provoquerait l'arrêt du programme.

On peut également recevoir le nom de la procédure qui émet l'erreur sur l'assertion et l'instruction concernée

**free
CTL-OPT ASSERT(*CALL : chkAssert) actgrp(*new) ;

dcl-s idProducteur int(10) ;
dcl-s quantite     zoned(10:2) ;


ASSERT-F idProducteur = 0  OR  quantite = 0  %MSG('id prod, qté ne peuvent pas être à 0');
ASSERT-T idProducteur <> 0 AND quantite <> 0 %MSG('id prod, qté ne peuvent pas être à 0');

idProducteur = 1 ;
ASSERT-F idProducteur = 0  OR  quantite = 0  %MSG('id prod, qté ne peuvent pas être à 0');
ASSERT-T idProducteur <> 0 AND quantite <> 0 %MSG('id prod, qté ne peuvent pas être à 0');

quantite = 1 ;
ASSERT-F idProducteur = 0  OR  quantite = 0  %MSG('id prod, qté ne peuvent pas être à 0');
ASSERT-T idProducteur <> 0 AND quantite <> 0 %MSG('id prod, qté ne peuvent pas être à 0');


return ;

DCL-PROC chkAssert;
    DCL-PI *N;
        ok IND CONST;
        msg VARCHAR(100) CONST;
        procName VARCHAR(50) CCSID(*UTF8) CONST;
        stmt UNS(10) CONST;
    END-PI;

   //log_result (ok : msg);

    IF NOT ok;
        SND-MSG *info 'Assertion error: ' + msg + ', ' + procName + ', ' + %char(stmt);
    ENDIF;

END-PROC;

Produit

Recommandations et bonnes pratiques

Ce que les assertions sont — et ne sont pas

+----------------------------------+----------------------------------+
| ASSERTIONS (invariants code)     | GESTION D'ERREURS (donnees)      |
|----------------------------------|----------------------------------|
| b != 0 (contrat interface)       | Saisie utilisateur invalide      |
| pHandle <> *NULL                 | Fichier absent en prod           |
| Compteur dans [1..1000]          | Timeout reseau                   |
| Resultat SQL attendu             | Enregistrement non trouve  |
| Code statut dans l'enum connu    | Erreur I/O disque                |
+----------------------------------+----------------------------------+

Regle : Si la condition peut echouer meme avec un code parfaitement correct (donnee utilisateur, etat externe), utilisez MONITOR / ON-ERROR ou un IF. Si la condition ne devrait echouer que si votre code a un bug, utilisez une assertion.

Bonnes pratiques RPG

1. Toujours fournir un message (second parametre) — il apparait dans le job log
2. Ne pas mettre d'effets de bord dans la condition (ex: ASSERT-T incrementer()=1) car avec ASSERT(*NONE), la fonction ne sera pas appelée
3. Centraliser le CTL-OPT dans un membre /COPY pour gerer facilement DEV vs PROD, OU utiliser une directive de compilation /IF DEFINED(ASSERT_ERR_TO_JOBLOG)
4. Documenter le pourquoi en commentaire avant chaque assertion non evidente

Pour changer ASSERT(*EXCP) à ASSERT(*WARN) par exemple, vous devez recompiler votre programme. Se pose alors la question des tests et de votre cycle de développement.

ON-EXCP avec identifiant générique

Un identifiant de message peut se terminer par * pour surveiller une plage de messages :

MONITOR;
  ...
ON-EXCP 'ABC*';   // surveille tout message commençant par ABC
  ...
ENDMON;

Les autres règles relatives à MONITOR, ON-EXCP et ON-ERROR continuent de s'appliquer.

Un exemple syntaxique qui mélange l'ensemble :

ON-EXCP vient obligatoirement avant ON-ERROR

LIKE(*EXT) — Déclaration d'une variable comme une colonne d'une table (zone d'un PF)

DCL-S salary1 LIKE(*EXT : 'EMPSALARY' : 'MYFILE');

Utilisable avec le nom court ou le nom alternatif du champ.

Syntaxe (issue de la doc LIKE(*EXT) - IBM Documentation) :

LIKE(*EXT : external-field : external-file)
LIKE(*EXT : external-field : external-file : external-format)
LIKE(*EXT : external-field : external-file : length-adjustment)
LIKE(*EXT : external-field : external-file : external-format : length-adjustment)

external-file peut être sous les formes suivantes : 'MYFILE' 'MYLIB/MYFILE' '*LIBL/MYFILE'.

Exemple

Une table SQL

CREATE TABLE CERT ( 
	CERTIFICATE_LABEL   FOR COLUMN CLABEL   VARCHAR(256) CCSID 1147 DEFAULT NULL , 
	SERIAL_NUMBER       FOR COLUMN SERIAL   VARCHAR(64)  CCSID 1147 DEFAULT NULL , 
	VALIDITY_START      FOR COLUMN VALSTART TIMESTAMP(0) DEFAULT CURRENT TIMESTAMP , 
	VALIDITY_END        FOR COLUMN VALEND   TIMESTAMP(0) DEFAULT CURRENT TIMESTAMP , 
	SUBJECT_COMMON_NAME FOR COLUMN SUBJECT  VARCHAR(256) CCSID 1147 DEFAULT NULL , 
	ISSUER_COMMON_NAME  FOR COLUMN ISSUER   VARCHAR(256) CCSID 1147 DEFAULT NULL ) 
RCDFMT CERT

Le programme RPGLE :

**free
ctl-opt alwnull(*usrctl); 

dcl-s label1  like(*ext : 'CLABEL'            : 'NB/CERT') ;
dcl-s label2  like(*ext : 'CERTIFICATE_LABEL' : '*LIBL/CERT') ; 
dcl-s valids  like(*ext : 'VALIDITY_START'    : 'CERT')        inz(*extdft) ; 
dcl-s serial1 like(*ext : 'SERIAL_NUMBER'     : 'CERT')        inz(*extdft) ; 
dcl-s serial2 like(*ext : 'SERIAL_NUMBER'     : 'CERT' : -10 ) inz('abc') ; 

snd-msg 'label1: ' + label1 ;
snd-msg 'label2: ' + label2 ;
snd-msg 'valids: ' + %char(valids) ;
snd-msg 'serial1: ' + serial1 + ', null: ' + %char(%nullind(serial1));
%nullind(serial1) = *on ; 
snd-msg 'serial1: ' + serial1 + ', null: ' + %char(%nullind(serial1));
snd-msg 'serial2: ' + serial2 + ', size: ' + %char(%size(serial2));

return ;

Produit :

Un point d'attention sur la gestion des valeurs nulles et valeur par défaut : la variable n'est pas initialisée à null, mais elle est "null-capable".

La longueur de la variable est ajustable uniquement pour les types numériques et caractères (cela n'a pas de sens pour une date par exemple).

Pour le reste, nous n'avons pas reperé de comportement étrange, ou du moins non documenté.

%LOOKUPNE / %TLOOKUPNE

Recherche du premier élément différent d'un argument dans un tableau (%LOOKUPNE) ou une table (%TLOOKUPNE).

Exemple :

Nécessite les PTFs :

• 7.5 : 5770WDS SJ10450
• 7.6 : 5770WDS SJ10455 (+ SJ10460 pour TGTRLS(V7R5M0=)

Job type et sous-type dans la PSDS

Nouvelles valeurs aux positions 404 et 405 de la PSDS :

Les valeurs possibles :

Variables d'environnement "temporaires"

Lorsqu'une PTF corrige un comportement existant ou introduit un nouveau comportement, elle est souvent accompagnée d'une variable d'environnement permettant au développeur de choisir de conserver l'ancien comportement ou de passer au nouveau. Généralement, passé un délai, le nouveau comportement devient le défaut.

IBM documente et synthétise toutes ces variables, leurs effets, les PTFs correspondantes et les dates :

Puis :

cf RPG Cafe: Temporary environment variables

Code for IBM i / VS Code

Code for IBM i (extension principale)

• Nouvelle vue "Environment" pour gérer actions, variables personnalisées et profils
• Support MFA pour IBM i 7.6
• Moteur SQL migré vers Mapepire (meilleures performances)
• Gestion de l'expiration et du changement de mot de passe
• Support de l'authentification par passphrase de clé SSH
• Support de la locale Espagnol
• Sécurité renforcée :
  • Commandes CL système préfixées
  • Vérification de signature des composants installés sur IBM i
  • Répertoire temporaire IFS personnel (/home/USER/.vscode/tmp au lieu de /tmp)
  • Vérification des droits sur le répertoire home

Db2 for i (extension VS Code)

• Nouveaux préfixes SQL :

  • udtf: — génère une UDTF à partir des colonnes d'un résultat

    

  • md: — génère un résultat au format tableau Markdown

    

• Objet de configuration par défaut sauvegardable

• Schema Browser enrichi : masques de colonnes, contraintes, journaux, permissions de ligne, séquences, packages SQL...

  

• Bouton "Récupérer plus / tous les résultats"

  

• Nombreux nouveaux exemples SQL (Db2 for i Services, IBM i Services, SYSTOOLS)

RPGLE (extension VS Code)

• Vue Outline pour le RPG OPM (format fixe)



• Mise en surbrillance des blocs fonctionnels (IF/ENDIF, DO/ENDDO, DCL-PROC/END-PROC...)



• Correctifs : règle format fixe, lignes de continuation, cache des includes

CL (extension VS Code)

• Survol (hover) sur les commandes et paramètres CL avec affichage de la documentation complète
• Vérificateur syntaxique CL étendu aux sources pseudo-CL, BND et CMD
• Aide contextuelle : option "Required parameters" lors de la saisie d'une commande

IBM i Testing (extension VS Code)

• Annulation de la compilation et de l'exécution des tests
• Affichage des valeurs attendues / reçues
• Affichage amélioré de la couverture de code au niveau procédure
• Installation RPGUnit intégrée directement dans l'extension (plus de téléchargement GitHub)
• Nouveau paramètre ONFAILURE sur RUCALLTST :
  • *ABORT : arrêt du test après la première assertion échouée
  • *CONTINUE : poursuite de l'exécution malgré les assertions échouées

IBM i FileSystem (nouvelle extension VS Code)

• Exploration et gestion des objets QSYS via un Object Browser
• Informations détaillées : locks, droits, statistiques d'utilisation, modules liés, entrées de répertoire de liaison, messages d'une file de messages...
• Actions sur objets : restauration, envoi de messages, génération PDF de spool, hold/release/end job...

IBM i Debug (extension VS Code)

• Correction : erreur de certificat auto-signé à la connexion
• Correction : démarrage du débogage pour les programmes batch avec on_exit

RDi 9.9

• Vue i Projects Navigator de retour (Fix Pack 3)
• eGit 7.3 préinstallé (plus besoin d'installation manuelle)
• Statut de connexion sécurisée dans le panneau Verify Connection

Administration système

Navigator for i

Les évolutions suivantes sont incluses dans les PTF Q2 2026 (groupe HTTP, disponibles depuis le 29/06/2026).

Framework

• Support de Java 21 si disponible
• Nouveau lancement panneau gauche avec overlay
• Messages d'erreur améliorés pour les erreurs de certificat / connexion

Dashboard

• Le Dashboard est désormais optionnel par utilisateur
• Option "Manage GUI node" accessible à tous les utilisateurs depuis Home > User Properties

Multi-systèmes

• Nouvelle table CVE Information : affiche le nombre de CVE par système avec accès direct au détail

Performance

• Support des Notebooks dans Navigator
• PDI (Performance Data Investigator) migré vers Angular (fin de Dojo)
  • Nouvelles vues pour Plan Cache et SQL Performance Monitor (11 vues SQL Overview + 9 SQL Attribute Mix chacun)
  • Sauvegarde en favoris
  • Restauration des Database *FILEs dans le package "Database Files"
  • Export PDI inclut le panneau de contexte
• Manage Collections : support du champ bibliothèque au niveau colonne, gestion Move/Copy en batch

Réseau

• SMTP : support OAuth (configuration via Navigator)
• Administration HTTP : activation/désactivation LPAR, wizard TLS pour serveurs TCP/IP, validation de configuration Apache, support LDAP et serveurs ADMIN dans TLS, WebSphere Liberty Express start/stop multi-instances
• EIM Debug Toggle : activation du tracing SSO debug
• Mise à niveau des propriétés de ports IAS/IWS

Travaux actifs

• Filtres avancés sur les travaux actifs (critères multiples, exécution SQL côté serveur)

Sécurité

• Table CVE Information multi-systèmes (SYSTOOLS.CVE_INFO())
• Wizard Remote Key Agent Configuration (Cryptographic Services > Manage Master Keys)
• Gestion des fichiers EKMD (External Key Manager Descriptions) : création, inclusion, modification, suppression
• Vérification du statut de la Save/Restore Master Key depuis les propriétés de connexion
• Support des nouveaux services SQL AUDIT_JOURNAL_JD et AUDIT_JOURNAL_RU

IFS

• Nouvelles fonctions : Copier, Déplacer, Renommer, Envoyer des fichiers IFS

AJS (Advanced Job Scheduler)

• Version GUI 7.2.26.149
• Propriétés des travaux planifiés : déplacer vers le haut / vers le bas les commandes de la liste, modification du numéro de séquence

Migration de HTTPAdmin dans Navigator for i

Le travail progresse, de nombreuses fonctions sont désormais accessibles via l'administration web de Navigator.

La cible est de finir l'intégration à un horizon fin 2026, afin de pouvoir débrancher HTTPAdmin, construit sur une stack technique ancienne et présentant des risques pour la sécurité (CVE). On peut donc parier que la désactivation de HTTPAdmin sera rapide en 2027.

Accès

Serveurs Apache

Actions possibles sur une instance HTTP existante (en fonction de l'état) :

La configuration donne le fichier httpd.conf en édition : plus d'assistant comme dans HTTPAdmin.

Pour l'instant :

ou bien :

Ou pire, un mélange d'informations

Création

Vous pouvez également crééer un serveur

Un assistant vous demande les informations, mais pas de suggestion (de n° de port par exemple) comme HTTPAdmin.

Vous pouvez modifier le sous-système d'éxecution

Les paramètres basiques de log (rétention)

La synthèse

Pour tous les autres attributs, il faut éditer le fichier httpd.conf

Assistant TLS

Contrairement à l'assistant de HTTPAdmin, vous pouvez passer en TLS sur le même port.

Attention, si vous voulez conserver un port non sécurisé, l'outil vous propose le même port pour TLS

Accès à DCM (/QIBM/USERDATA/ICSS/CERT/SERVER/DEFAULT.KDB)

Choisissez un certificat existant (pas de création de certificat, vous devez le faire préalablement par DCM)

Puis

Enfin

L'assistant a bien modifié httpd.conf

Et l'instance est sécurisée (mais nous avons dû redémarrer le serveur manuellement)

Serveurs d'application

Plus d'informations disponibles

Création

Vous pouvez créer une instance IWS ou IAS

L'instance Apache si demandée

Sous-système et utilisateur pour les travaux du serveurs d'application

Synthèse

Après la création

Vu depuis HTTPAdmin

Sur un serveur fonctionnel, certaines options fonctionnent

D'autres produisent des résultats non utilisables (toutes les lignes sélectionnées)

L'affichage des fichiers log ne fonctionne pas, ...

Et il semble persister une incohérence entre les ocnfigurations gérées par HTTPAdmin et Navigator :

Assistant TLS

L'assistant vous guide, mais cherchez vos n° de ports libres à l'avance

Possibilité d'utiliser DCM, des jks ou certificats sur l'IFS (pfx par exemple)

L'option "Sélection à l'aide de la table de stockage des certificats" renvoie au nouvel espace de stockage des certificats (voir plus bas).

Sélectionnez votre certificat

Personnalisez vos suites de chiffrement si nécessaire

Redémarrage du serveur par l'assistant ou non

Synthèse

Les propriétés sont modifiées

Cet assistant sécurise l'instance Java, pas l'instance HTTP si elle existe.

Espace de stockage des certificats

Nouvelle option vous permettant de référencer différentes localisations de dépôt et gestion de vos certificats :

Vous pouvez ajouter le magasin *SYSTEM bien sûr

Mais aussi des magasins au formats

Malheureusement l'assistant ne nous laisse rien passer pour l'instant

Une fois vos certificats ajoutés, vous pouvez les utiliser directement dans l'assistant TLS pour les serveurs d'applications (les serveurs Apache passent toujours pas DCM).

BRMS (5770-BR2) — GUI 2026.2.0

PTFs :

• IBM i 7.4 — SJ09069
• IBM i 7.5 — SJ09070
• IBM i 7.6 — SJ09071

BRMS Log

• Filtre sur les messages sévères (IDs critiques susceptibles de faire échouer un groupe de contrôle)
• Filtre sur les messages contenant "objects not saved"

Backup History Management

• Nouvelles vues avec détail au niveau objet et au niveau fichier
• Restauration depuis le niveau objet (si le détail objet était inclus dans la sauvegarde)
• Restauration des données Link depuis le niveau fichier

Backup List Management

• Ajout, copie et suppression de Backup Lists
• Édition des entrées de Backup List

SQL View Documentation

• Lien de documentation ajouté sur les vues SQL

Administration

• Nouveau type d'usage *SYSOPR (accès en lecture aux médias et informations de sauvegarde, capacité de sauvegarde/restauration, restriction des actions de modification/suppression sauf pour les éléments dont l'utilisateur est propriétaire)

Références

• IBM i 7.6 TR2 — Enhancements
• IBM i 7.5 TR8 — Enhancements
• Announcement IBM i 7.6 TR2
• Announcement IBM i 7.5 TR8
• IBM i Technology Updates
• RPG Cafe
• ACS Updates
• Code for IBM i docs
• BRMS Enhancements
• Navigator for i PTF update details
• ASSERT keyword — IBM Docs
• Program Status Data Structure - IBM Documentation
• LIKE(*EXT) - IBM Documentation

ACS version 1.1.9.12

20 avril 2026. Cette version apporte des évolutions sur l'exécution de script SQL !

PTF IBM i

Pour mettre à jour la version disponible sur IBM i :

• 5770SS1 V7R3M0 SJ09232
• 5770SS1 V7R4M0 SJ09233
• 5770SS1 V7R5M0 SJ09234
• 5770SS1 V7R6M0 SJ09235

Run SQL Script

SELF

Nouvelle option :

Permet le support de l'outil SELF (SQL Error Logging Facility). Cf SQL Error Logging Facility (SELF) - IBM Documentation

Concrètement, cela modifie la liste des erreurs qui sont tracées dans la vue SQL_ERROR_LOG. Cette liste est stockée dans la variable globale SYSIBMADM.SELFCODES, avec quelques valeurs spéciales (*ALL, *ERROR, *WARN, *NONE).

Fichiers physiques source

Amélioration de la fenêtre de dialogue pour la sauvegarde en fichiers sources :

Gestion des fins de ligne

Les caractères LF (x'25') ne sont plus insérés en fin de ligne dans le cas d'une sauvegarde en fichier source :

Il n'y pas d'impact à l'exécution (RUNSQLSTM), mais plus de confort !

Gestion de la taille des lignes

Lors de l'enregistrement, au lieu de tronquer les lignes, un message permet d'avertir :

Exemples SQL

13 nouveaux exemples pour les services SQL :

• SELF - System-wide controls
• SELF - Job-level controls
• SELF - Log Queries
• SELF - Removing historical rows
• SELF - Initial Stack
• SELF - Top occurrences
• SELF - QA use case example
• Security - Who is creating objects in the IFS root
• Security - Who is creating objects in the /QOpenSys subdirectory
• Security - IFS first-level directories that are open to attack
• Security - IFS subdirectory object attack vector check
• Security - IFS home directory ownership
• Generate spreadsheet and send email example

Références

[IBM i Access - ACS Updates]

ACS version 1.1.9.13

27 mai 2026. Cette version est une mise à jour de sécurité, sans ajout de nouvelles fonctionnalités.

PTF IBM i

Pour mettre à jour la version disponible sur IBM i :

• 5770SS1 V7R3M0 SJ09732
• 5770SS1 V7R4M0 SJ09730
• 5770SS1 V7R5M0 SJ09729
• 5770SS1 V7R6M0 SJ09731 1

Sécurité

Correction de vulnérabilités (CVE)

Cette version corrige plusieurs vulnérabilités, dont une critique permettant une exécution de code à distance lorsque ACS est configuré pour répondre aux requêtes depuis IBM i Navigator.

• CVE-2026-7770
• Type : Remote Code Execution (RCE)
• Score CVSS : 8.8 (élevé)

Portée

Versions affectées : ACS 1.1.5.0 à 1.1.9.12

Toutes les versions précédentes doivent être mises à jour.

Références

• IBM i Access - ACS Updates

ACS version 1.1.9.14

Août 2026. Cette version apporte une mise à jour de sécurité majeure pour IBM i Access Client Solutions.

Cette version ne met pas en avant de fonctionnalité visible pour les utilisateurs et doit surtout être lue comme une mise à jour de sécurité prioritaire.

Sécurité

Vulnérabilités corrigées

Cette version corrige plusieurs failles pouvant conduire à une exécution de code à distance ou à une compromission de la chaîne de confiance locale :

• exécution de code arbitraire sur Windows lorsque ACS est installé pour tous les utilisateurs, à cause d’un répertoire et d’un fichier de configuration inscriptibles par des utilisateurs non privilégiés ;
• injection d’une autorité de certification malveillante via le truststore, également inscriptible ;
• attaque de type zip slip lors de l’import d’une configuration ;
• téléchargement de code produit non vérifié lors d’une mise à jour depuis IBM i ;
• vulnérabilité d’exécution de code arbitraire via les scripts d’exemple dans Documentation\Sample_Scripts\Linux_Mac_Other lorsque les paramètres d’entrée sont malformés.

CVE corrigées

• CVE-2026-13094
• CVE-2026-13105
• CVE-2026-13433
• CVE-2026-14866
• CVE-2026-14875
• CVE-2026-16695

Portée

Versions affectées indiquées par IBM : versions antérieures à 1.1.9.14, avec un impact explicitement mentionné pour 1.1.8.3 à 1.1.9.13 sur le mécanisme de mise à jour depuis IBM i.

Priorité

Importante, en raison du risque d’exécution de code malveillant sur le poste client.

Références

• IBM i Access - ACS Updates

ACS version 1.1.9.15

Août 2026. Cette version est une correction ciblée, sans nouvelle fonctionnalité annoncée par IBM.

Cette version a été publiée quelques jours après 1.1.9.14 pour corriger un incident lié aux certificats SSL/TLS apparu dans la version précédente.

Correctif

Problème résolu

• DT498800 OSP-UNPRED MSGSSL007 - AN ERROR OCCURRED WITH AN SSL CERTIFICATE (JAVA.NIO.FILE.ATTRIBUTE.USERPRINCIPALNOTFOUNDEXCEPTION)

Priorité

1.1.9.15 devient la version de référence à installer si 1.1.9.14 est déjà présente, car elle corrige le bug de certificats qui pouvait rendre ACS inutilisable dans des environnements chiffrés. Cette formulation est une synthèse de la source externe.

Références

• IBM i Access - ACS Updates

ACS version 1.1.9.16

Septembre 2026. Cette version renforce la sécurité d’ACS en ajoutant des confirmations explicites avant l’exécution de certaines actions potentiellement dangereuses.

Sécurité

Comportements désormais soumis à confirmation utilisateur

À partir de cette version, ACS demande une confirmation avant d’exécuter :

• la commande CL STRPCCMD reçue depuis un IBM i compromis ;
• l’action RunProgram dans une macro 5250 malveillante ;
• l’action Run dans un fichier 5250 multi-sessions (.bch, .bchx).

Pour l’action de macro RunProgram, une option supplémentaire Cancel permet d’interrompre l’exécution complète de la macro.

CVE corrigées

• CVE-2026-14275
• CVE-2026-14276
• CVE-2026-14277

Problème corrigé

• DT500870 OSP-UNPRED ACS - "CHECK FOR UPDATES" FOR PLAIN USER FAILS WITH CPFA09C

Références

• IBM i Access - ACS Updates

Service Commander pour IBM i

Administration, exploitation et orchestration de services IBM i et Open Source

Sources utilisées

Ce cours s'appuie sur :

• la documentation officielle du projet GitHub ThePrez/ServiceCommander-IBMi ;
• la présentation « Orchestration des travaux IBM i avec service-commander » — Université IBM i 2023 (Gautier Dumas, CFD-Innovation) ;
• la présentation « Getting Started with Open Source on IBM i » ;
• des supports Open Source IBM i ;
• des retours d'expérience terrain.

1. Introduction générale

1.1 IBM i et l'évolution des workloads

IBM i n'est plus uniquement une plateforme RPG, CL, Db2 et batch traditionnel. Les environnements modernes IBM i hébergent aujourd'hui :

• des applications RPG et COBOL historiques ;
• des serveurs HTTP IBM i ;
• des web services ;
• des applications Node.js ;
• des scripts Python ;
• des outils Bash ;
• des dépôts Git ;
• des bases MariaDB, PostgreSQL ou SQLite ;
• des outils DevOps ;
• des connecteurs API ;
• des services d'intégration ou d'IA.

Cette diversité est puissante, mais elle complexifie l'exploitation.

Un administrateur doit pouvoir répondre rapidement à des questions simples :

• quels services tournent sur mon IBM i ?
• quels ports sont utilisés ?
• quel job correspond à quel service ?
• comment relancer proprement une application Node.js ?
• comment démarrer plusieurs services dans le bon ordre ?
• comment intégrer ces services au démarrage système ?
• comment exploiter les logs ?

Il existe bien entendu des fonctionnalités natives des produits IBM i. Service Commander répond également à ce besoin, avec une vision plus typée Open Source.

1.2 Définition courte

Service Commander est un outil en ligne de commande permettant de gérer des services sur IBM i.

Il permet notamment de :

• démarrer un service ;
• arrêter un service ;
• vérifier si un service est actif ;
• lister les services connus ;
• regrouper des services ;
• gérer des dépendances ;
• lancer des services en batch ;
• gérer certains logs ;
• interroger des ports et des jobs ;
• intégrer des services à STRTCPSVR et ENDTCPSVR.

1.3 La phrase à retenir

Service Commander est une couche d'orchestration légère pour piloter des services IBM i et Open Source de manière homogène.

Il ne remplace pas IBM i. Il ne remplace pas les sous-systèmes. Il ne remplace pas les job descriptions. Il fournit une interface commune et moderne pour gérer des services hétérogènes.

2. Pourquoi Service Commander ?

2.1 Le problème avant Service Commander

Sans Service Commander, l'exploitation d'un environnement IBM i moderne peut rapidement impliquer :

WRKACTJOB
WRKJOB
WRKSBMJOB
WRKSPLF
NETSTAT
STRTCPSVR
ENDTCPSVR

Mais aussi :

ps
netstat
bash
node
python3
npm
npx

Et parfois des scripts maison :

start_app.sh
stop_app.sh
status_app.sh
restart_database.sh

Chaque service peut avoir sa méthode de démarrage, son répertoire, ses variables d'environnement, son port, son utilisateur et sa stratégie de logs.

Le risque est de créer une exploitation artisanale :

• difficile à documenter ;
• difficile à transmettre ;
• difficile à superviser ;
• difficile à industrialiser ;
• fragile lors des changements de profil ou d'environnement.

2.2 Ce que Service Commander apporte

Service Commander apporte une convention.

Un service est décrit dans un fichier YAML. Ensuite, il peut être piloté avec des commandes simples :

sc start monservice
sc stop monservice
sc check monservice
sc info monservice

Cette approche donne une structure commune pour des technologies très différentes.

2.3 Exemples de services gérables

Service Commander peut gérer notamment :

• serveurs TCP IBM i : FTP, SSHD, HTTP ;
• jobs IBM i ;
• applications Node.js ;
• applications Python ;
• applications PHP ;
• Tomcat ;
• Kafka ;
• Zookeeper ;
• ActiveMQ ;
• Jenkins ;
• Cron ;
• PostgreSQL ;
• MariaDB ;
• applications internes écrites en Bash ou Java.

3. Architecture conceptuelle

3.0 Contexte et histoire

Service Commander a été créé par Jesse Gorzinski (IBMer, alias ThePrez sur GitHub) le 24 décembre 2020.

L'origine du projet vient d'un besoin concret : gérer simultanément plusieurs services Open Source dans le cadre d'ateliers IBM i (Learning Center, workshops COMMON FOCUS), notamment :

• Zookeeper ;
• Kafka ;
• Kafka Visualizer ;
• GitBucket ;
• MariaDB.

La complexité de piloter tous ces services hétérogènes a motivé la création d'un outil unifié. Le projet est désormais disponible en tant que package RPM sur IBM i.

3.1 Ce que Service Commander n'est pas

Service Commander n'est pas :

• un ordonnanceur complet ;
• un superviseur équivalent à systemd ou init.d ;
• un remplaçant de Robot, Control-M ou Advanced Job Scheduler ;
• un outil de monitoring temps réel complet ;
• un gestionnaire de haute disponibilité.

Il ne suit pas un processus par son PID comme systemd ou supervisord.

3.2 Ce que Service Commander est

Service Commander est :

• un outil de gestion de services ;
• un lanceur de commandes ;
• un contrôleur d'état ;
• un orchestrateur léger ;
• un outil de normalisation d'exploitation.

Il repose sur une idée simple :

Un service est considéré actif si Service Commander peut vérifier un critère d'activité.

Ce critère peut être :

• un port TCP ouvert ;
• un job IBM i visible.

3.3 Le couplage faible

Service Commander fonctionne avec un couplage faible.

Cela signifie qu'il ne stocke pas nécessairement l'identifiant exact du processus qu'il a lancé. Il observe l'environnement pour déterminer si le service est vivant.

Avantage :

• simple ;
• robuste ;
• compatible avec des workloads très variés.

Limite :

• si deux services utilisent le même port ou le même nom de job, il peut y avoir ambiguïté.

Exemple :

sc check port:8080

Cette commande vérifie si le port 8080 est utilisé. Elle ne sait pas forcément si c'est bien « votre » service ou un autre processus qui occupe le port.

4. Installation

4.1 Prérequis

Service Commander s'installe dans l'environnement Open Source IBM i. Les packages Open Source sont installés sous :

/QOpenSys/pkgs

Version IBM i minimale : V7R3 (installation YUM disponible depuis V7R3, possible manuellement en V7R2).

Les prérequis sont installés automatiquement par YUM :

Prérequis supplémentaires pour sc perfinfo :

• yum install python3-ibm_db (Python 3 + connecteur IBM i Db2)
• Niveau PTF selon version OS :
  • IBM i 7.4 : inclus dans l'OS de base
  • IBM i 7.3 : Group PTF SF99703 Level 11 minimum
  • IBM i 7.2 : Group PTF SF99702 Level 23 minimum

4.2 Installation en ligne de commande

yum install service-commander

ou, selon votre environnement :

/QOpenSys/pkgs/bin/yum install service-commander

4.3 Installation via ACS

Dans IBM Access Client Solutions :

1. ouvrir la gestion des modules Open Source ;
2. se connecter au système IBM i ;
3. rechercher service-commander ;
4. installer le package ;
5. vérifier que /QOpenSys/pkgs/bin est dans le PATH.

4.4 Vérification

which sc

Résultat attendu :

/QOpenSys/pkgs/bin/sc

Puis :

sc

4.5 Initialisation des services par défaut

sc_install_defaults

Cette commande crée des définitions de services pour certains services connus, selon les packages présents sur le système.

Exemples possibles :

• Cron ;
• MariaDB ;
• instances Apache ;
• services système.

Dans notre cas, de nombreuses instances Apache et IWS sur le système :

Puis :

En l'état, cela génère des définitions pour les services trouvés, dans le répertoire /home/user/.sc/services :

Vous pouvez donc régler un certain nombre d'options sur sc_install_defaults :

usage: sc_install_defaults [options]
valid options include:
    -h            : display help
    --apache      : autocreate from apache instances (default)
    --cleanupv0   : clean up files created by v0 (default)
    --cleanup     : clean up previously-generated configs (default)
    --noapache    : don't autocreate from apache instances
    --nocleanupv0 : don't clean up files created by v0
    --nocleanup   : don't clean up previously-generated configs
    --global      : install for all users
    --user        : install for current user (default)

Si vous n'installez pas pour l'utilisateur, la configuration globale est stockée ici :

/qopensys/etc/sc/services

5. Premiers pas

5.1 Lister les services

sc list

Cette commande affiche les services connus : issus du répertoire de l'utilisateur + de la configuration globale.

Exemple :

crond       (Cron daemon)
mariadb     (MariaDB Server)
myapi       (API Node.js)

Affiche également les conflits :

5.2 Vérifier tous les services

sc check group:all

Le groupe all existe par défaut et permet de travailler sur l'ensemble des services visibles.

Donne le statut des services :

5.3 Démarrer un service

sc start myapi

5.4 Arrêter un service

sc stop myapi

5.5 Obtenir des informations

sc info myapi

Cette commande permet d'obtenir des informations sur la définition du service et son état.

Le fichier de configuration correspondant est :

name: Mapepire Server
dir: .
start_cmd: ../../bin/mapepire
check_alive: mapepire,8076
batch_mode: 'true'
sbmjob_opts: 'JOBQ(QUSRNOMAX)'
environment_vars:
- PATH=/QOpenSys/pkgs/bin:/QOpenSys/usr/bin:/usr/ccs/bin:/QOpenSys/usr/bin/X11:/usr/sbin:.:/usr/bin

6. Les définitions YAML

6.1 Emplacements des fichiers

Les services peuvent être définis dans plusieurs emplacements.

Répertoire global

/QOpenSys/etc/sc/services

Ce répertoire est adapté aux services partagés ou de production.

Droits requis : écrire dans ce répertoire nécessite le droit *ALLOBJ sur IBM i.

Répertoire utilisateur

$HOME/.sc/services

Ce répertoire est adapté aux services privés, aux tests ou au développement.

Fichier explicite

Il est aussi possible de démarrer un service défini dans un fichier YAML situé ailleurs :

sc start /mon/chemin/monservice.yaml

6.2 Convention de nommage

Le fichier doit généralement suivre ce format :

nom_service.yaml

ou :

nom_service.yml

Recommandations :

• uniquement minuscules ;
• pas d'espaces ;
• utiliser _ ou - ;
• choisir un nom court et stable.

Exemples :

api_clients.yaml
mcp_server.yaml
webhook-prod.yaml

6.3 Définition minimale

Une définition minimale ne nécessite que trois champs obligatoires :

start_cmd: node app.js
check_alive: port
check_alive_criteria: 8080

Cette définition signifie :

• pour démarrer, exécuter node app.js ;
• pour vérifier l'état, regarder le port 8080.

Note : Il existe aussi une syntaxe raccourcie où le numéro de port peut être indiqué directement comme valeur de check_alive, sans check_alive_criteria séparé :

check_alive: '8080'

Cette forme est équivalente mais moins lisible ; la forme longue est préférable pour la production.

6.4 Définition recommandée

name: API Clients Node.js
dir: /home/APPS/api-clients
start_cmd: node app.js
check_alive: port
check_alive_criteria: 8080
batch_mode: true
sbmjob_jobname: APICLIENTS
startup_wait_time: 30
stop_wait_time: 20
groups:
  - web
  - production

Cette définition est plus exploitable parce qu'elle précise :

• un nom lisible ;
• un répertoire de travail ;
• un mode batch ;
• un nom de job ;
• des délais ;
• des groupes.

7. Les champs essentiels du YAML

7.1 name

Nom lisible du service.

name: Serveur MCP pour IBM i

Ce nom peut contenir des espaces et être plus descriptif que le nom technique du fichier.

7.2 dir

Répertoire de travail.

dir: /projet/ibmi-mcp-server

Service Commander se positionne dans ce répertoire avant de lancer la commande.

C'est fondamental pour les applications qui utilisent des chemins relatifs.

7.3 start_cmd

Commande de démarrage.

start_cmd: node server.js

ou :

start_cmd: /QOpenSys/pkgs/bin/bash -lc './start.sh'

Recommandation : utiliser des chemins absolus dans les environnements de production.

7.4 stop_cmd

Commande d'arrêt personnalisée.

stop_cmd: ./stop.sh

Si elle n'est pas fournie, Service Commander utilise ses mécanismes standards selon le type de contrôle.

7.5 check_alive

Méthode de vérification. Deux valeurs sont supportées :

check_alive: port

ou :

check_alive: jobname

Syntaxe raccourcie : il est aussi possible de passer directement le numéro de port comme valeur (sous forme de chaîne) :

check_alive: '2204'

Cela équivaut à check_alive: port avec check_alive_criteria: 2204. Cette forme raccourcie est présente dans certains fichiers générés, mais la forme longue est recommandée pour la lisibilité.

7.6 check_alive_criteria

Critère de vérification.

Par port :

check_alive: port
check_alive_criteria: 8080

Par job :

check_alive: jobname
check_alive_criteria: MYSERVER

Avec sous-système et nom de job :

check_alive: jobname
check_alive_criteria: QSYSWRK/MYSERVER

Il est aussi possible de spécifier un programme pour identifier un job :

sc check job:PGM-QZDASOINIT

7.7 batch_mode

Permet de lancer le service en batch.

batch_mode: true

C'est généralement recommandé pour un service de production.

7.8 sbmjob_jobname

Nom du job soumis.

sbmjob_jobname: MCPSERVER

Bonnes pratiques :

• utiliser un nom court ;
• éviter les noms génériques ;
• aligner avec check_alive_criteria si le contrôle se fait par job.

7.9 sbmjob_opts

Options de soumission batch.

sbmjob_opts: JOBD(MALIB/MYJOBD) JOBQ(QUSRNOMAX)

Permet d'utiliser l'infrastructure IBM i existante : job descriptions, job queues, bibliothèques, etc.

7.10 environment_vars

Variables d'environnement injectées au démarrage.

environment_vars:
  - NODE_ENV=production
  - PORT=8080
  - HOME=/home/MYUSER

7.11 environment_is_inheriting_vars

Contrôle l'héritage de l'environnement courant.

environment_is_inheriting_vars: false

Avec false, vous maîtrisez mieux le contexte, mais vous devez fournir explicitement ce qui est nécessaire.

7.12 groups

Affecte un service à un ou plusieurs groupes.

groups:
  - web
  - production

Utilisation :

sc start group:web

7.13 service_dependencies

Déclare les services dépendants.

service_dependencies:
  - mariadb
  - redis

Au démarrage, Service Commander peut démarrer les dépendances nécessaires.

7.14 log_dir

Répertoire des logs Service Commander.

log_dir: /logs/service-commander/myapi

Par défaut (sans cette directive), les logs sont stockés ici :

$HOME/.sc/logs/<date_heure>.<nom_service>.log

Où <date_heure> correspond à l'heure de démarrage du service.

Attention : cela ne remplace pas forcément les logs internes de l'application.

7.15 only_if_executable

Permet de rendre une définition de service conditionnelle.

only_if_executable: /QOpenSys/pkgs/bin/node

Si le fichier spécifié n'existe pas ou n'est pas exécutable, la configuration est ignorée par Service Commander (service absent de la liste).

Utilisation typique :

• ignorer une définition de service sur un système où le logiciel n'est pas installé ;
• créer des définitions portables entre plusieurs IBM i avec des packages différents.

7.16 startup_wait_time et stop_wait_time

Délais d'attente pour les opérations de démarrage et d'arrêt.

startup_wait_time: 60
stop_wait_time: 45

Valeurs par défaut :

• startup_wait_time : 60 secondes
• stop_wait_time : 45 secondes

Ces délais peuvent être augmentés pour les services lents à démarrer ou à arrêter (Java, Node.js avec chargement long, bases de données).

8. Commandes de base détaillées

8.1 sc list

sc list

Liste les services configurés.

Avec un groupe :

sc list group:web
sc list group:all

8.2 sc check

sc check myapi

Vérifie si le service est actif.

À la volée :

sc check port:8080
sc check job:MYJOB

Exemple de retour avec sc check group:system :

8.3 sc start

sc start myapi

Démarre le service et éventuellement ses dépendances.

On peut aussi démarrer un groupe entier, ou depuis un fichier YAML explicite :

sc start group:all
sc start group:web
sc start /mon/chemin/monservice.yaml

8.4 sc stop

sc stop myapi

Arrête le service.

À la volée :

sc stop port:8080

8.5 sc info

sc info myapi

Affiche les informations de définition et d'état.

Sur tous les services :

sc info group:all

8.6 sc groups

sc groups

Liste les groupes disponibles (y compris les groupes globaux préconfigurés).

Pour lister uniquement les groupes définis dans vos fichiers YAML privés :

sc groups --ignore-globals

8.7 scopenports

scopenports

Liste les ports ouverts avec un rapprochement éventuel avec les services connus.

8.8 sc jobinfo

sc jobinfo port:8080

Affiche les informations de job associées à un port.

8.9 Services système et flag -a

Par défaut, les services du groupe system (IBM i Host Servers, FTP, SSH, HTTP, Navigator for i...) sont masqués dans les sorties standard.

Pour les afficher :

sc -a check all
sc -a check group:system
sc list group:system

Le flag -a (ou --all) indique à Service Commander d'inclure les services système dans les résultats.

Services system typiquement inclus :

• IBM i Host Servers ;
• FTP, SSHD, HTTP ;
• Navigator for i.

8.10 sc perfinfo

sc perfinfo myapi

Affiche des statistiques de performance basiques pour le service (CPU, mémoire...).

Prérequis pour perfinfo :

• Python 3 avec le connecteur ibm_db :

yum install python3-ibm_db

• Niveau OS :
  • IBM i 7.4 : inclus dans l'OS de base
  • IBM i 7.3 : Group PTF SF99703 Level 11 minimum
  • IBM i 7.2 : Group PTF SF99702 Level 23 minimum

8.11 sc loginfo

sc loginfo myapi

Affiche l'emplacement des fichiers de logs pour un service donné. Les logs peuvent ensuite être consultés avec cat, tail, ou tout autre outil.

tail -f $(sc loginfo myapi)

9. Création assistée avec scinit

9.1 Principe

scinit aide à créer une définition YAML.

Méthode recommandée :

cd /home/APPS/myapp
scinit node app.js

L'assistant pose des questions puis génère un fichier YAML.

9.2 Quand utiliser scinit ?

Utilisez scinit :

• pour découvrir l'outil ;
• pour générer un premier squelette ;
• pour un service simple ;
• pour former des équipes.

Pour des services de production complexes, une édition manuelle reste souvent préférable.

Par exemple :

Produit le fichier :

10. Édition avec scedit

10.1 Principe

scedit myapi

Cette commande localise le fichier YAML et l'ouvre avec l'éditeur disponible.

Ordre typique :

1. $EDITOR ;
2. nano ;
3. joe ;
4. vim ;
5. vi.

10.2 Bonnes pratiques avec scedit

Avant modification :

cp /QOpenSys/etc/sc/services/myapi.yaml /QOpenSys/etc/sc/services/myapi.yaml.bak

Après modification :

sc check myapi
sc stop myapi
sc start myapi
sc info myapi

11. Exemples complets

11.1 Application Node.js simple

name: Démo Node.js
dir: /home/NODE/demo
start_cmd: /QOpenSys/pkgs/bin/node app.js
check_alive: port
check_alive_criteria: 3000
batch_mode: true
sbmjob_jobname: NODEDEMO
startup_wait_time: 20
groups:
  - demo
  - web
environment_vars:
  - NODE_ENV=production
  - PORT=3000

Commandes :

sc start node_demo
sc check node_demo
sc info node_demo
sc stop node_demo

11.2 API Python

name: API Python Flask
dir: /home/PYTHON/flask-api
start_cmd: /QOpenSys/pkgs/bin/python3 app.py
check_alive: port
check_alive_criteria: 5000
batch_mode: true
sbmjob_jobname: PYAPI
groups:
  - api
  - python
environment_vars:
  - FLASK_ENV=production
  - PORT=5000

11.3 Service Java

name: Application Java métier
dir: /home/JAVA/order-service
start_cmd: /QOpenSys/pkgs/bin/java -jar order-service.jar
check_alive: port
check_alive_criteria: 9090
batch_mode: true
sbmjob_jobname: ORDSRV
startup_wait_time: 60
groups:
  - java
  - production

11.4 Script Bash métier

name: Agent d'intégration fichiers
dir: /home/AGENTS/file-agent
start_cmd: /QOpenSys/pkgs/bin/bash ./run-agent.sh
stop_cmd: /QOpenSys/pkgs/bin/bash ./stop-agent.sh
check_alive: jobname
check_alive_criteria: FILEAGENT
batch_mode: true
sbmjob_jobname: FILEAGENT
groups:
  - integration

11.5 Service avec dépendances

name: Portail client
dir: /home/APPS/customer-portal
start_cmd: /QOpenSys/pkgs/bin/node server.js
check_alive: port
check_alive_criteria: 8080
batch_mode: true
sbmjob_jobname: CUSTPORT
service_dependencies:
  - mariadb
  - redis
groups:
  - web
  - production

Au démarrage :

sc start customer_portal

Service Commander démarre d'abord les dépendances si nécessaire.

12. Batch IBM i et Service Commander

12.1 Pourquoi utiliser le batch ?

Un service long doit survivre à la déconnexion de l'utilisateur.

Le batch permet :

• une exécution durable ;
• une traçabilité IBM i ;
• une visibilité dans WRKACTJOB ;
• une association à une job queue ;
• une intégration avec les règles d'exploitation.

12.2 Exemple batch complet

name: Service Web Production
dir: /home/PROD/webapp
start_cmd: /QOpenSys/pkgs/bin/node app.js
check_alive: port
check_alive_criteria: 8443
batch_mode: true
sbmjob_jobname: WEBPROD
sbmjob_opts: JOBD(PRODLIB/WEBJOBD) JOBQ(QUSRNOMAX)
startup_wait_time: 45
stop_wait_time: 30
groups:
  - web
  - production

12.3 Points de vigilance batch

Le contexte batch n'est pas toujours identique à une session SSH.

À vérifier :

env

Puis comparer avec le contexte batch :

• HOME ;
• USER ;
• LOGNAME ;
• PATH ;
• LANG ;
• LC_ALL ;
• répertoire courant ;
• droits IFS ;
• droits sur les ports ;
• droits sur les fichiers de logs.

13. Gestion des logs

13.1 Logs Service Commander

Service Commander peut aider à gérer les sorties standard et erreur.

Commande utile :

sc loginfo monservice

13.2 Redirection explicite

Pour les services complexes, il est souvent préférable de rediriger explicitement :

start_cmd: /QOpenSys/pkgs/bin/bash -lc './start.sh >> /logs/myapi/myapi.log 2>&1'

Mais attention aux quotes YAML et Bash.

13.3 Utilisation de tail

tail -f /logs/myapi/myapi.log

13.4 Logs en spool

sc --splf start monservice

Cette option peut être utile pour des équipes IBM i habituées aux spools : redirige les logs vers un fichier spool.

14. Groupes et industrialisation

14.1 Pourquoi utiliser des groupes ?

Les groupes permettent d'exploiter plusieurs services ensemble.

Exemples :

• web ;
• api ;
• database ;
• dev ;
• test ;
• production ;
• mcp ;
• integration.

14.2 Exemple

groups:
  - api
  - production

Puis :

sc check group:production
sc start group:api
sc stop group:api

14.3 Convention recommandée

Pour une organisation d'équipe :

• un groupe par technologie : node, python, java ;
• un groupe par environnement : dev, test, prod ;
• un groupe par usage : web, batch, integration, ai ;
• éviter les groupes trop vagues.

15. Intégration avec STRTCPSVR / ENDTCPSVR

15.1 Principe

Service Commander peut s'intégrer aux commandes IBM i :

STRTCPSVR
ENDTCPSVR

L'intérêt est important pour :

• les administrateurs IBM i ;
• les CL existants ;
• QSTRUP ;
• les procédures d'exploitation ;
• les ordonnanceurs.

15.2 Installation de l'intégration

/QOpenSys/pkgs/lib/sc/tcpsvr/install_sc_tcpsvr

Cette commande crée la bibliothèque SCOMMANDER et y compile/installe les programmes TCP nécessaires pour utiliser *SC.

Désormais vous avez :

Elle n'est toutefois pas documentée par F1.

15.3 Démarrer un service

Unitaire :

STRTCPSVR SERVER(*SC) INSTANCE('myapi')

Tous les services d'un groupe :

STRTCPSVR SERVER(*SC) INSTANCE('group:iws')

15.4 Arrêter un service

ENDTCPSVR SERVER(*SC) INSTANCE('myapi')

15.5 Exemple dans QSTRUP

PGM
  STRTCPSVR SERVER(*SC) INSTANCE('mariadb')
  STRTCPSVR SERVER(*SC) INSTANCE('redis')
  STRTCPSVR SERVER(*SC) INSTANCE('customer_portal')
ENDPGM

16. Services à la volée

16.1 Vérifier un port

sc check port:8080

16.2 Obtenir les jobs associés à un port

sc jobinfo port:8080

16.3 Vérifier un job

sc check job:MYJOB

16.4 Arrêter via un port

sc stop port:8080

À utiliser avec prudence en production.

17. Cluster mode

17.1 Objectif

Le mode cluster permet de lancer automatiquement plusieurs instances d'une application, réparties sur plusieurs ports, avec un load balancing assuré par NGINX.

Service Commander démarre N jobs, chacun sur un port différent, et NGINX (s'il est configuré) répartit la charge entre eux.

17.2 Exemple

name: Application Node clusterisée
dir: /home/APPS/cluster-node
start_cmd: node app.js
check_alive: port
check_alive_criteria: 2204
cluster: 2206,2208,2210,2212

Dans ce modèle :

• le port 2204 est le port principal (point d'accès NGINX) ;
• Service Commander démarre 4 instances supplémentaires sur les ports 2206, 2208, 2210, 2212 ;
• NGINX répartit les requêtes entre les instances ;
• Service Commander gère tous les jobs lors des opérations start, stop, check.

17.3 Pré-requis applicatif

L'application doit pouvoir recevoir son port via la variable d'environnement PORT :

PORT=2206

ou accepter un paramètre de ligne de commande :

node app.js --port=$PORT

17.4 Note sur NGINX

Le clustering Service Commander s'appuie sur NGINX pour le load balancing. Si NGINX n'est pas installé ou configuré, les instances sont bien démarrées sur leurs ports respectifs, mais la répartition de charge doit être gérée manuellement ou par un autre mécanisme.

yum install nginx

17bis. Redémarrage automatique scripté

17bis.1 Contexte

Service Commander ne gère pas nativement le redémarrage automatique d'un service tombé (contrairement à pm2 pour Node.js, ou systemd avec Restart=always).

Cependant, il est possible de scripter simplement ce comportement sur IBM i.

17bis.2 Principe

Soumettre un job en batch qui tente de démarrer le service à intervalle régulier. La commande sc start n'a aucun effet si le service est déjà actif.

SBMJOB CMD(CALL PGM(QP2SHELL2) PARM('/QOpenSys/usr/bin/sh' '-c' +
  'while :; do sleep 40 && /QOpenSys/pkgs/bin/sc start navigator +
  >/dev/null 2>&1 ; done')) +
  JOB(NAVMON) JOBD(*USRPRF) JOBQ(QUSRNOMAX)

Ici, le job NAVMON :

1. Attend 40 secondes ;
2. Tente de démarrer le service navigator ;
3. Si le service est déjà actif, rien ne se passe ;
4. Si le service est arrêté, il est redémarré ;
5. Boucle indéfiniment.

17bis.3 Intégration dans QSTRUP

Ce job peut être soumis au démarrage du système dans QSTRUP :

PGM
  /* Démarrer les services principaux */
  STRTCPSVR SERVER(*SC) INSTANCE('mariadb')
  STRTCPSVR SERVER(*SC) INSTANCE('myapi')

  /* Monitor de redémarrage automatique */
  SBMJOB CMD(CALL PGM(QP2SHELL2) PARM('/QOpenSys/usr/bin/sh' '-c' +
    'while :; do sleep 60 && /QOpenSys/pkgs/bin/sc start myapi +
    >/dev/null 2>&1 ; done')) +
    JOB(MYAPI_MON) JOBD(*USRPRF) JOBQ(QUSRNOMAX)
ENDPGM

17bis.4 Limites

• Si le service échoue en boucle, il sera redémarré indéfiniment.
• Il n'y a pas de gestion du seuil d'échecs.
• Pour des besoins avancés, envisager un script Bash avec compteur.

18. Locale, environnement et Open Source sur IBM i

18.1 Pourquoi les locales comptent

Les outils Open Source sont sensibles à l'environnement.

Un mauvais paramétrage peut provoquer :

• warnings setlocale ;
• erreurs d'encodage ;
• comportements différents entre SSH et batch ;
• problèmes avec Node.js, Python, npm ou npx ;
• problèmes de rendu des caractères accentués.

18.2 Variables importantes

LANG
LC_ALL
LC_CTYPE
PATH
HOME
USER
LOGNAME
SHELL
PWD

18.3 Diagnostic

env | sort
locale
locale -a

18.4 Exemple de configuration dans .profile

export LANG=fr_FR.UTF-8
export LC_ALL=fr_FR.UTF-8
export PATH=/QOpenSys/pkgs/bin:/QOpenSys/usr/bin:/usr/bin:$PATH

À adapter à votre système réel. Il faut vérifier que la locale existe avec :

locale -a | grep -i fr

18.5 Attention aux valeurs IBM i

Certaines valeurs peuvent être valides côté IBM i traditionnel mais problématiques côté PASE/Open Source.

Exemple de symptôme :

warning: setlocale: LC_ALL: cannot change locale

Dans ce cas, vérifier les locales réellement installées dans PASE.

19. Retour d'expérience : serveur MCP IBM i

19.1 Contexte

Un serveur MCP Node.js doit être lancé sur IBM i via Service Commander.

Le lancement manuel fonctionne avec le profil de service dédié, par exemple :

npx -y @ibm/ibmi-mcp-server@latest --transport http --tools ./tools

Mais le lancement via Service Commander échoue ou provoque un timeout.

19.2 Symptômes

• sc start se termine en timeout ;
• le job est soumis puis s'arrête ;
• le service n'est pas disponible ;
• les logs montrent des différences de contexte ;
• le fonctionnement manuel sous le profil cible est correct.

19.3 Première hypothèse : la commande

Une commande directe dans le YAML peut être tentante :

start_cmd: /QOpenSys/pkgs/bin/bash -lc 'exec npx -y @ibm/ibmi-mcp-server@latest --transport http --tools ./tools >> /home/MCPSERVER/mcp.server.log 2>&1'

Mais les quotes, l'environnement, le répertoire, le HOME, le cache npm et le PATH rendent ce type de ligne fragile.

19.4 Deuxième hypothèse : l'utilisateur

Le service fonctionne sous MCPSERVER, mais pas lorsqu'il est lancé via un autre profil.

Points à vérifier :

whoami
env | sort
pwd
which node
which npm
which npx

19.5 Troisième hypothèse : le contexte batch

En batch, l'environnement n'est pas celui de la session SSH.

Variables essentielles :

HOME=/home/MCPSERVER
USER=MCPSERVER
LOGNAME=MCPSERVER
PATH=/QOpenSys/pkgs/bin:/QOpenSys/usr/bin:/usr/bin

19.6 Quatrième hypothèse : locale

Un warning de locale peut empêcher certains scripts Bash ou outils Open Source de fonctionner correctement.

Commandes utiles :

locale
locale -a

Puis corriger .profile, .bashrc ou les variables d'environnement du service.

19.7 Solution robuste : wrapper Bash

Créer un script explicite :

#!/QOpenSys/pkgs/bin/bash

export HOME=/home/MCPSERVER
export USER=MCPSERVER
export LOGNAME=MCPSERVER
export LOGIN=MCPSERVER
export PATH=/QOpenSys/pkgs/bin:/QOpenSys/usr/bin:/usr/bin:$PATH

cd /projet/ibmi-mcp-server || exit 1

exec npx -y @ibm/ibmi-mcp-server@latest --transport http --tools ./tools >> /home/MCPSERVER/mcp.server.log 2>&1

Rendre exécutable :

chmod +x /projet/ibmi-mcp-server/start-mcp.sh

19.8 YAML associé

name: Serveur MCP pour IBM i
dir: /projet/ibmi-mcp-server
start_cmd: /projet/ibmi-mcp-server/start-mcp.sh
check_alive: port
check_alive_criteria: 3001
batch_mode: true
sbmjob_jobname: MCPSERVER
startup_wait_time: 60
log_dir: /home/MCPSERVER/sc-logs
groups:
  - mcp
  - ai

Adapter le port réel selon la configuration du serveur MCP.

19.9 Enseignements

Ce cas montre que le problème n'est pas toujours Service Commander lui-même.

Les causes fréquentes sont :

• environnement incomplet ;
• mauvais HOME ;
• mauvais PATH ;
• profil utilisateur différent ;
• locale incohérente ;
• cache npm inaccessible ;
• droits IFS ;
• commande trop complexe dans le YAML.

La bonne pratique est de mettre la complexité dans un wrapper Bash versionné, plutôt que dans une ligne YAML difficile à maintenir.

20. Méthodologie de dépannage

20.1 Règle n°1 : tester hors Service Commander

cd /chemin/application
./start.sh

Si cela ne fonctionne pas manuellement, Service Commander ne corrigera pas le problème.

20.2 Règle n°2 : tester avec le bon profil

ssh MONUSER@monibmi

Puis lancer exactement la commande attendue.

20.3 Règle n°3 : comparer les environnements

env | sort > /tmp/env.ssh.txt

Dans le script batch :

env | sort > /tmp/env.batch.txt

Comparer :

diff /tmp/env.ssh.txt /tmp/env.batch.txt

20.4 Règle n°4 : tracer tôt

Dans un wrapper :

echo "===== START $(date) =====" >> /tmp/myservice.debug.log
echo "USER=$USER" >> /tmp/myservice.debug.log
echo "HOME=$HOME" >> /tmp/myservice.debug.log
echo "PATH=$PATH" >> /tmp/myservice.debug.log
pwd >> /tmp/myservice.debug.log
env | sort >> /tmp/myservice.debug.log

20.5 Règle n°5 : vérifier le critère d'activité

Si le service écoute le port 3001 :

sc check port:3001
sc jobinfo port:3001

Si le contrôle se fait par job :

sc check job:MCPSERVER

21. Sécurité et comptes de service

21.1 Éviter les profils personnels

Ne pas exploiter les services de production avec un profil personnel.

Préférer :

NODEPROD
PYPROD
MCPSERVER
WEBAPI

21.2 Droits minimaux

Un compte de service doit avoir :

• les droits IFS nécessaires ;
• les droits sur les bibliothèques nécessaires ;
• les droits d'exécution nécessaires ;
• pas plus.

21.3 Logs et secrets

Attention à ne pas loguer :

• tokens ;
• mots de passe ;
• clés API ;
• variables d'environnement sensibles.

22. Bonnes pratiques de production

22.1 YAML simple, wrapper explicite

Préférez :

start_cmd: /apps/myapi/start.sh

à :

start_cmd: /QOpenSys/pkgs/bin/bash -lc 'cd /apps/myapi && export A=B && node app.js >> log 2>&1'

22.2 Chemins absolus

Utiliser :

/QOpenSys/pkgs/bin/node

plutôt que :

node

sauf si le PATH est parfaitement maîtrisé.

22.3 Nommer les jobs

sbmjob_jobname: MYAPI

Cela simplifie WRKACTJOB, les logs, les analyses et les consignes d'exploitation.

22.4 Définir les délais

startup_wait_time: 60
stop_wait_time: 30

Un service Java ou Node.js peut nécessiter plus de temps qu'un simple script.

22.5 Documenter chaque service

Créer un fichier complémentaire :

/apps/myapi/README.md

Avec :

• rôle du service ;
• port ;
• profil ;
• répertoire ;
• commande ;
• dépendances ;
• logs ;
• procédure de relance ;
• contacts.

23. Exercices pratiques

Exercice 1 — Découverte

Objectif : identifier les services existants.

Commandes :

sc list
sc groups
sc check group:all

Questions :

1. Combien de services sont configurés ?
2. Quels groupes existent ?
3. Quels services sont actifs ?
4. Y a-t-il des services système masqués ?

Exercice 2 — Créer un service simple

Créer un script :

mkdir -p /home/FORMATION/demo-service
cd /home/FORMATION/demo-service

cat > run.sh <<'EOF'
#!/QOpenSys/pkgs/bin/bash
while true; do
  echo "Demo service running $(date)"
  sleep 30
done
EOF
chmod +x run.sh

Créer le YAML :

name: Demo Service
dir: /home/FORMATION/demo-service
start_cmd: ./run.sh
check_alive: jobname
check_alive_criteria: DEMOSVC
batch_mode: true
sbmjob_jobname: DEMOSVC
groups:
  - formation

Tester :

sc start demo_service
sc check demo_service
sc stop demo_service

Exercice 3 — Diagnostiquer un mauvais PATH

Modifier temporairement un service pour utiliser une commande sans chemin absolu.

Observer l'échec puis corriger avec :

export PATH=/QOpenSys/pkgs/bin:/QOpenSys/usr/bin:/usr/bin:$PATH

Exercice 4 — Comparer SSH et batch

Créer un wrapper qui écrit :

env | sort

Dans un fichier de log, puis comparer avec une session SSH.

24. Référence rapide

24.1 Commandes principales

# Lister / inspecter
sc list
sc list group:web
sc check service
sc check group:all
sc check port:8080
sc check job:MYJOB
sc info service
sc info group:all
sc groups
sc groups --ignore-globals
sc loginfo service
sc jobinfo port:8080
sc perfinfo service
scopenports

# Démarrer / arrêter
sc start service
sc start group:web
sc start group:all
sc start /chemin/service.yaml
sc stop service
sc stop port:8080

# Services système (cachés par défaut)
sc -a check all
sc -a check group:system
sc list group:system

# Outils d'aide
scedit service
scinit commande
sc_install_defaults

24.2 Attributs YAML principaux

Syntaxe YAML complète de référence :

name: Nom lisible
dir: /repertoire/de/travail
start_cmd: commande de démarrage
stop_cmd: commande d'arrêt
check_alive: port | jobname
check_alive_criteria: critère
batch_mode: true | false
sbmjob_jobname: NOMJOB
sbmjob_opts: options SBMJOB
startup_wait_time: 60
stop_wait_time: 45
log_dir: /repertoire/logs
environment_is_inheriting_vars: true | false
environment_vars:
  - CLE=VALEUR
service_dependencies:
  - service1
  - service2
groups:
  - groupe1
  - groupe2
cluster: port1,port2,port3
only_if_executable: /chemin/vers/executable

25. Conclusion

Service Commander est un outil simple mais structurant.

Il apporte à IBM i une façon moderne de piloter des services hétérogènes, sans renier les mécanismes natifs de la plateforme.

Son intérêt est particulièrement fort lorsqu'un IBM i héberge à la fois :

• des services traditionnels ;
• des applications Open Source ;
• des APIs ;
• des outils d'intégration ;
• des composants IA ou MCP ;
• des workloads techniques nécessitant une exploitation fiable.

La clé de réussite n'est pas seulement l'installation de l'outil. Elle réside dans les conventions d'équipe : nommage, logs, wrappers, comptes de service, groupes, dépendances et documentation.

Bien utilisé, Service Commander devient un standard d'exploitation lisible par les administrateurs IBM i comme par les développeurs Open Source.