Systèmes mainframe et IBM

Ce guide couvre le groupe Mainframe de Data Source Explorer (DSE) :

• IBM i / AS400 avec IBM i Access ODBC
• IBM z/OS Db2 avec le pilote IBM Db2 ODBC/CLI
• VSAM via une couche de virtualisation ODBC ou un adaptateur REST compatible DSE
• IMS via REST/API ou virtualisation ODBC
• CICS via REST/API ou virtualisation ODBC

Remarque de terminologie : IBM i fonctionne sur IBM Power, et non sur IBM Z. DSE le regroupe avec les connecteurs mainframe/legacy afin de simplifier l'exploitation d'un parc de données historiques.

1. Architecture et modèle de prise en charge

DSE n'émule pas les protocoles natifs du mainframe. Il utilise des couches d'accès d'entreprise standard :

Séquence recommandée : configurer l'hôte/l'adaptateur, tester hors DSE si possible, choisir le type exact sous Mainframe, enregistrer la chaîne de connexion, exécuter Test connection, charger les objets, puis valider Table info, Preview, Row details et une requête exemple.

2. Règles de sécurité

• utilisez un compte DSE dédié et en lecture seule lorsque possible
• ne mettez jamais un mot de passe de production dans la documentation, les captures ou le contrôle de source
• utilisez <password>, <host> et <user> dans les exemples
• accordez uniquement les bibliothèques, schémas, tables, services ou transactions nécessaires
• privilégiez TLS, VPN ou routage privé
• un utilisateur SSH de transport peut être différent de l'utilisateur ODBC
• ne donnez pas au compte DSE des privilèges d'administrateur uniquement pour faciliter un test

Les exemples utilisent DSELAB et DSETEST.

IBM i / AS400 — configuration complète

3. Prérequis IBM i

Il faut un système IBM i actif et joignable, TCP/IP actif, un utilisateur ODBC normal, les host servers IBM i démarrés, un poste Windows 64 bits avec le pilote IBM i Access ODBC, et au moins une bibliothèque lisible par l'utilisateur DSE.

Vous pouvez utiliser un IBM i existant, une partition sur site ou IBM Power Virtual Server. Une fois l'hôte joignable, la configuration DSE est identique.

Laboratoire de référence facultatif : IBM Power Virtual Server (PowerVS)

Si vous ne disposez pas déjà d'une partition IBM i, vous pouvez utiliser un Power Virtual Server (PowerVS) IBM i comme laboratoire de validation du connecteur. PowerVS est facultatif : DSE n'impose pas IBM Cloud.

Séquence de provisionnement recommandée :

1. Dans IBM Cloud, créez ou sélectionnez un workspace Power Virtual Server dans une région autorisée par votre organisation.
2. Créez une instance de serveur virtuel à partir d'une image IBM i couverte par vos droits IBM et adaptée à votre plan de test.
3. Dimensionnez CPU, mémoire et stockage pour permettre l'IPL et l'exécution stable des services hôtes Db2 for i. Un laboratoire n'a pas besoin d'un dimensionnement de production.
4. Connectez la partition à un réseau privé. N'ajoutez un accès public que si votre architecture l'exige et limitez l'accès entrant aux adresses approuvées.
5. Attendez que l'instance soit active, ouvrez la console/VNC fournie par IBM et terminez les tâches normales de premier démarrage IBM i, y compris l'acceptation des licences si l'image le demande.
6. Notez le nom d'hôte ou l'adresse IP routable. Si les ports des host servers IBM i restent privés, notez également le chemin SSH/bastion utilisé pour le tunnel.
7. Connectez-vous à IBM i, créez le compte DSE en lecture seule et la bibliothèque de test décrits ci-dessous, puis démarrez les host servers.
8. Validez le réseau depuis Windows avant de configurer DSE.

Topologies de validation recommandées :

Route directe/privée :
Windows DSE -> hôte IBM i -> host servers IBM i Access -> Db2 for i

Tunnel SSH :
Windows DSE -> ports redirigés sur 127.0.0.1 -> SSH IBM i/bastion -> host servers -> Db2 for i

La facturation PowerVS et les licences IBM i sont indépendantes de DSE. Arrêtez ou supprimez les ressources temporaires lorsqu'elles ne sont plus nécessaires.

4. Connexion 5250

Connectez-vous avec votre méthode 5250 habituelle ou la console cloud. Utilisez un compte administratif uniquement pour les opérations de configuration qui le nécessitent.

5. Démarrer les host servers

STRHOSTSVR SERVER(*ALL)

Si vous utilisez volontairement un tunnel SSH :

STRTCPSVR SERVER(*SSHD)

SSH n'est pas nécessaire si le poste DSE peut joindre directement les ports IBM i Access.

Ports non TLS courants : 449 (mapper), 8470 (central), 8471 (database), 8472 (data queue), 8473 (file), 8474 (network print), 8475 (remote command), 8476 (sign-on). Votre organisation peut utiliser les équivalents SSL ou limiter l'exposition.

6. Créer un utilisateur de test dédié

Exemple :

CRTUSRPRF USRPRF(DSELAB) PASSWORD(<temporary-password>) USRCLS(*USER) STATUS(*ENABLED) TEXT('DSE read-only test user')

N'utilisez jamais un vrai mot de passe dans ce guide. Vérifiez que le compte est activé, non expiré et sans privilèges excessifs.

7. Créer une bibliothèque de validation

CRTLIB LIB(DSETEST) TEXT('DSE connector validation')
GRTOBJAUT OBJ(DSETEST) OBJTYPE(*LIB) USER(DSELAB) AUT(*USE)

Une liste d'autorisation ou un profil de groupe peut être préférable selon vos normes.

8. Créer une table SQL de validation

Utilisez Run SQL Scripts dans IBM i Access Client Solutions ou STRSQL si disponible.

CREATE TABLE DSETEST.CUSTOMER
(
    CUSTOMER_ID INTEGER NOT NULL,
    NAME VARCHAR(80) NOT NULL,
    STATUS VARCHAR(20) NOT NULL,
    CREDIT_LIMIT DECIMAL(12,2),
    CREATED_AT TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY (CUSTOMER_ID)
);

INSERT INTO DSETEST.CUSTOMER (CUSTOMER_ID, NAME, STATUS, CREDIT_LIMIT)
VALUES
  (1001, 'ARCO INTERNATIONAL', 'ACTIVE', 25000.00),
  (1002, 'NORTHWIND IBM I LAB', 'ACTIVE', 15000.00),
  (1003, 'CONTOSO LEGACY', 'HOLD', 5000.00);

GRANT SELECT ON DSETEST.CUSTOMER TO USER DSELAB;

SELECT * FROM DSETEST.CUSTOMER ORDER BY CUSTOMER_ID;

Exemple de données dans la table de validation IBM i :

Le compte DSE doit pouvoir lire les lignes sans pouvoir les modifier.

9. Installer le pilote ODBC IBM i sur Windows

Installez le Windows Application Package d'IBM i Access Client Solutions contenant le pilote 64 bits. Ouvrez :

C:\Windows\System32\odbcad32.exe

Vérifiez la présence de :

IBM i Access ODBC Driver

System32\odbcad32.exe est l'administrateur ODBC 64 bits sur Windows 64 bits.

L’administrateur ODBC 64 bits doit afficher IBM i Access ODBC Driver comme dans cet exemple :

10. Routage direct ou tunnel SSH

Routage direct

Test-NetConnection <ibmi-host> -Port 8471
Test-NetConnection <ibmi-host> -Port 8476

Tunnel SSH

ssh -N -T `
  -L 449:127.0.0.1:449 `
  -L 8470:127.0.0.1:8470 `
  -L 8471:127.0.0.1:8471 `
  -L 8472:127.0.0.1:8472 `
  -L 8473:127.0.0.1:8473 `
  -L 8474:127.0.0.1:8474 `
  -L 8475:127.0.0.1:8475 `
  -L 8476:127.0.0.1:8476 `
  -o ExitOnForwardFailure=yes `
  -o ServerAliveInterval=15 `
  -o ServerAliveCountMax=3 `
  <ssh-user>@<ibmi-public-or-bastion-host>

Laissez la fenêtre ouverte. Une session ssh -N -T silencieuse est normale.

Test-NetConnection 127.0.0.1 -Port 449
Test-NetConnection 127.0.0.1 -Port 8471
Test-NetConnection 127.0.0.1 -Port 8476

11. Créer un System DSN 64 bits

Dans System DSN, ajoutez IBM i Access ODBC Driver. Nom conseillé :

DSE_IBMI_DEV

Hôte direct : nom/IP réel. Tunnel : 127.0.0.1.

Incluez les bibliothèques que DSE doit découvrir :

DBQ=DSETEST,QGPL;LIBVIEW=0;

Sans DSETEST dans DBQ, la connexion peut réussir mais la table DSETEST.CUSTOMER ne sera pas visible.

12. Tester ODBC hors DSE

$cred = Get-Credential -UserName 'DSELAB' -Message 'IBM i ODBC credentials'
$password = $cred.GetNetworkCredential().Password
$connectionString = "DSN=DSE_IBMI_DEV;UID=$($cred.UserName);PWD=$password;DBQ=DSETEST,QGPL;LIBVIEW=0;"
$conn = New-Object System.Data.Odbc.OdbcConnection($connectionString)
$conn.Open()
$cmd = $conn.CreateCommand()
$cmd.CommandText = 'SELECT CUSTOMER_ID, NAME, STATUS, CREDIT_LIMIT FROM DSETEST.CUSTOMER ORDER BY CUSTOMER_ID'
$reader = $cmd.ExecuteReader()
$table = New-Object System.Data.DataTable
$table.Load($reader)
$table | Format-Table -AutoSize
$conn.Close()

Corrigez tout échec à ce stade avant de continuer dans DSE.

13. Configurer IBM i dans DSE

Sous Mainframe, choisissez IBM i / AS400 (ODBC configure), puis Edit connection.

DSN :

DSN=DSE_IBMI_DEV;UID=DSELAB;PWD=<password>;DBQ=DSETEST,QGPL;LIBVIEW=0;

Pilote direct :

Driver={IBM i Access ODBC Driver};System=<ibmi-host>;Uid=DSELAB;Pwd=<password>;DBQ=DSETEST,QGPL;LIBVIEW=0;

Avec tunnel, l'hôte est normalement 127.0.0.1.

Choisissez le type IBM i / AS400, pas Generic ODBC : le connecteur spécifique contient une logique IBM i pour les métadonnées et l'aperçu.

14. Validation dans DSE

Après Test connection :

1. Load tables
2. cherchez la bibliothèque DSETEST
3. sélectionnez CUSTOMER
4. vérifiez Table info
5. ouvrez Preview
6. sélectionnez une ligne et ouvrez Row details
7. lancez l'exemple de requête

SELECT * FROM "DSETEST"."CUSTOMER" FETCH FIRST 100 ROWS ONLY

DSE contient une compatibilité IBM i pour certains fichiers natifs/DDS qui refusent FETCH FIRST. Il peut retirer la limite côté serveur et limiter le nombre de lignes côté client.

15. Dépannage IBM i

Test connection = False : pilote 64 bits, DSN 64 bits, hôte/tunnel, ports 8471/8476, host servers, compte/mot de passe.

Tunnel silencieux : normal avec ssh -N -T; testez 127.0.0.1:8471 dans une seconde fenêtre.

Mot de passe expiré : connectez-vous normalement sur IBM i, changez-le puis relancez ODBC.

Seulement QGPL visible : ajoutez DBQ=DSETEST,QGPL;LIBVIEW=0;, reconnectez et rechargez.

DSETEST.CUSTOMER absent : contrôlez *USE sur la bibliothèque, SELECT sur la table et DBQ.

SQL0104 / FETCH FIRST : confirmez que DSE utilise le connecteur IBM i spécifique, retirez le ; final d'une instruction ODBC manuelle et testez une vraie table SQL comme DSETEST.CUSTOMER.

IBM z/OS Db2

16. Prérequis

Il faut un hôte z/OS joignable, une LOCATION Db2, un port DRDA, des identifiants Db2, le IBM Data Server Driver for ODBC and CLI 64 bits et une licence Db2 Connect appropriée.

Driver={IBM DB2 ODBC DRIVER};Database=<location>;Hostname=<zos-host>;Port=<drda-port>;Protocol=TCPIP;Uid=<user>;Pwd=<password>;

Validez le pilote/licence hors DSE, puis utilisez Test connection, Load tables, Preview, Row details et une requête de contrôle.

VSAM, IMS et CICS

17. Modes ODBC et REST

ODBC :

Adapter=ODBC;ConnectionString="DSN=YOUR_VSAM_ADAPTER;Uid=<user>;Pwd=<password>";

REST :

Adapter=REST;BaseUrl=https://<adapter-host>;HealthPath=/health;ObjectsPath=/dse/objects;ColumnsPath=/dse/objects/{name}/columns;QueryPath=/dse/query;BearerToken=<token>;

DSE n'implémente pas le protocole VSAM/IMS/CICS natif; la couche de middleware doit le présenter en ODBC ou selon le contrat REST DSE.

18. Contrat REST

• GET /health : test de connexion
• GET /dse/objects : objets/services/tables
• GET /dse/objects/{name}/columns : champs/métadonnées
• POST /dse/query : exécution de la commande

Corps par défaut :

{
  "command": "SELECT * FROM CICSDEV.CUSTOMER_SERVICE FETCH FIRST 100 ROWS ONLY;",
  "sourceType": "CICS"
}

DSE accepte aussi une commande get /some/path; pour convertir directement une réponse JSON en tableau.

Authentification : BearerToken, OAuth2 (TokenUrl, ClientId, ClientSecret, Scope), Basic (Username/Password) ou ApiKey/ApiKeyHeader.

19. CICS

Adapter=REST;BaseUrl=https://<cics-adapter>;HealthPath=/health;ObjectsPath=/dse/objects;ColumnsPath=/dse/objects/{name}/columns;QueryPath=/dse/query;BearerToken=<token>;

20. VSAM

DSE passe par une couche ODBC/REST; l'accès natif VSAM brut n'est pas intégré.

L'adaptateur doit mapper clés, layouts/copybooks, encodage et enregistrements dans le contrat tabulaire/JSON de DSE.

21. IMS

Adapter=REST;BaseUrl=https://<ims-adapter>;HealthPath=/health;ObjectsPath=/dse/objects;ColumnsPath=/dse/objects/{name}/columns;QueryPath=/dse/query;BearerToken=<token>;

ou :

Adapter=ODBC;ConnectionString="DSN=YOUR_IMS_ADAPTER;Uid=<user>;Pwd=<password>";

Le middleware décide comment les bases, segments et hiérarchies IMS deviennent des objets/champs lisibles par DSE.

Exemple de résultat de requête IMS via l’adaptateur DSE :

Liste d'acceptation

22. IBM i

• pilote 64 bits installé
• route/tunnel stable
• host servers actifs
• compte lecture seule valide
• test ODBC externe réussi
• Test connection DSE réussi
• table approuvée visible
• colonnes, Preview, Row details et requête exemple fonctionnels
• aucun secret dans la documentation ou le code source

23. z/OS Db2

• vrai endpoint z/OS Db2
• pilote ODBC/CLI 64 bits
• licence Db2 Connect confirmée
• LOCATION/port DRDA confirmés
• test externe puis test DSE réussis
• schémas, tables, colonnes et aperçus chargés

24. VSAM / IMS / CICS

• couche adaptateur approuvée
• santé HTTP/ODBC valide
• objets et métadonnées stables
• requêtes renvoient un JSON/tableau convertible
• authentification sans secret longue durée exposé
• test, chargement, métadonnées, aperçu et requête DSE réussis

Pour le support, fournissez la version DSE, le type de source, une chaîne de connexion nettoyée, le nom/version du pilote, le type de réseau, le message d'erreur exact et le résultat du même test hors DSE. N'envoyez jamais de mot de passe, clé SSH privée ou secret OAuth.