par Michael Otey
Divers outils permettent d'intégrer les systèmes AS/400 et Windows NT/2000 pour
optimiser les investissements de l'entreprise
Il n'est jamais facile d'intégrer des plates-formes différentes. Chaque système
a ses propres particularités et c'est encore plus vrai dans le cas de Windows
NT/2000 et de l'AS/400. De nombreuses entreprises utilisent les deux à la fois,
mais peu d'entre elles mélangent leurs fonctions. L'AS/400 exécute ses propres
applications, généralement de gestion classique (saisie de commandes, facturation,
par exemple), tandis que Windows NT/2000 est en principe utilisé pour le service
de fichiers et d'impression et pour la messagerie électronique.
Quiconque découvre le monde de l'AS/400 suppose peut-être qu'il est facile de
faire travailler les deux plates-formes ensemble, moyennant quelques rapides appels
à la hot-line. Après tout, deux ténors comme IBM et Microsoft ont certainement
des équipes spécialisées dans l'intégration des deux plates-formes.
Mais, il suffit d'avoir participé à des projets nécessitant l'intégration du couple
Windows-AS/400, pour savoir que cette situation idyllique est loin de la vérité.
Appelez IBM à propos de problèmes Windows NT/2000 : on vous aiguillera rapidement
sur les services ConsultLine, payables à l'heure et onéreux. Appelez Microsoft
pour soulever des problèmes AS/400, on vous demandera probablement : " Qu'est-ce
qu'un AS/400 ? ".
Heureusement, l'AS/400 et Windows NT/2000 possèdent tous deux une palette d'outils
permettant d'intégrer les plates-formes. Je couvre les plus importants de ces
outils d'intégration ici. Je commence par les outils d'intégration TCP/IP de base
présents sur les deux systèmes, avec quelques conseils propres à chaque plate-forme.
Ensuite, je parle des fonctions d'intégration les plus utiles de Client Access
d'IBM. Enfin, je montre comment utiliser la fonction NetServer de l'AS/400 pour
intégrer directement l'AS/400 dans le réseau Windows NT/2000 sans utiliser Client
Access.
L'AS/400 et Windows NT/2000 possèdent tous deux une palette d'outils permettant
d'intégrer les plates-formes
Tout sur l’intégration AS/400-Windows NT/2000
L’AS/400 et Windows NT/2000 possèdent tous deux d’excellents outils TCP/IP assurant
une bonne interopérabilité entre les deux systèmes. L’outil d’intégration TCP/IP
le plus basique est Ping.
Ping. C’est le premier outil à utiliser en cas de problème de
connexion réseau. Présent sur l’AS/400 et sur Windows NT/2000, Ping indique principalement
si la connexion entre les deux systèmes est bonne. Si Ping réussit, il vérifie
un certain nombre de points : si la connexion physique est bonne, si TCP/IP a
été installé correctement sur votre système et le système cible et, enfin, si
la résolution du nom TCP/IP du réseau fonctionne et s’il est possible d’atteindre
l’hôte à distance sur le réseau.
Ping fonctionne de la même manière sur AS/400 et sur Windows NT/2000 à quelques
exceptions près. Pour commencer, en réponse à une invite du système, on entre
la commande Ping suivie du nom de l’hôte à distance. Ainsi, pour appliquer ping
à un AS/400 nommé S101AA0A depuis un système Windows NT/2000, on entrera à l’invite
de commande :
C:\>ping s101aa0a
Si l’application du ping à un système à distance par le nom échoue, il faut tenter
la même opération en remplaçant le nom par l’adresse TCP/IP. Si c’est concluant,
on sait que la configuration du réseau et de TCP/IP sont correctes, mais que la
résolution du nom pose un problème, auquel cas il faut vérifier le DNS (Domain
Name Server) ou le fichier HOSTS local.
Il y a une différence mineure entre les implémentations AS/400 et Windows NT/2000
de Ping. Pour appliquer le ping par adresse sur l’AS/400, il faut placer l’adresse
TCP/IP entre guillemets simples ; sur un système Windows NT/2000, il suffit d’entrer
l’adresse IP suivie de la commande Ping. L’exemple suivant illustre comment exécuter
Ping sur AS/400 pour vérifier la connexion à un système Windows NT/2000.
===> ping _192.168.100.12
Sur un système Windows NT/2000, on ping une adresse IP de la manière suivante
:
C:\>ping 192.168.100.7
Telnet et TN5250. Telnet est une application TCP/IP qui fournit
une fenêtre de commande en mode caractères sur l’hôte à distance. Une application
Telnet comprend deux parties : le serveur qui s’exécute sur les systèmes hôtes
et le client qui s’exécute sur un système client en réseau. L’AS/400 et Windows
NT/2000 prennent tous deux en charge les connexions client Telnet. Mais il y a
de grosses différences entre les types de support de la plate-forme et les types
d’application client Telnet qu’il faut utiliser pour chaque plate-forme.
L’une des plus grosses différences est ce que l’on voit quand on se connecte à
chaque système en utilisant l’application Telnet. Quand on se connecte à l’AS/400,
on obtient un affichage 5250 standard dont le menu et l’écran exacts dépendent
des caractéristiques du profil utilisateur AS/400. A partir de cette session 5250,
on peut effectuer toute action autorisée sur un terminal à écran passif standard.
Quand on se connecte à un système Windows NT/2000 en utilisant Telnet, on obtient
une fenêtre d’invite de commande. A partir de cette fenêtre, qui ressemble beaucoup
à la fenêtre Command Prompt standard (appelée parfois fenêtre DOS), on peut exécuter
des scripts shell de commande (fichiers batch) et exécuter d’autres commandes
destinées à la console. Mais on ne peut exécuter aucun programme graphique du
fait que Telnet est une application de type caractère qui ne reconnaît pas les
graphiques.
Pour se connecter à un système Windows NT en utilisant Telnet, il faut d’abord
installer le serveur Telnet à l’aide de Windows NT Server Resource Kit. Une fois
installé, il faut démarrer le service Telnet en utilisant l’option Control Panel/Services
avant que les futurs clients Telnet ne puissent se connecter. Pour Windows 2000,
le serveur Telnet est fourni avec le système d’exploitation de base et son démarrage
se fait via l’option Control Panel/Administrative Tools/Services.
Pour se connecter à un AS/400 en utilisant Telnet, il faut démarrer le support
TCP/IP de l’AS/400 en utilisant la commande STRTCP (Start TCP/IP) qui démarre
tous les serveurs applicatifs TCP/IP, y compris le serveur Telnet.
Bien que n’importe quel client Telnet standard (y compris celui qui est livré
avec Windows NT/2000) puisse se connecter indifféremment aux serveurs Telnet Windows
NT/2000 ou AS/400, dans le cas de l’AS/400, il vaut bien mieux utiliser un programme
supportant une extension du protocole Telnet connu sous le nom de TN5250. La connexion
à l’AS/400 à l’aide d’un client Telnet standard affichera une session 5250 où
les touches de fonction ne correspondent pas aux touches F correctes, la touche
Entrée peut correspondre à la touche Crtl et aucun indicateur Input Inhibited
ou Message ne s’affichera.
En outre, un client Telnet standard envoie les entrées à l’hôte frappe par frappe,
un procédé très lourd pour le processeur AS/400. TN5250 résout tous ces problèmes
: il fournit une correspondance de clavier et des indicateurs de messages standards
et il envoie chaque écran à l’AS/400 bloc par bloc, plutôt que frappe par frappe.
Le programme d’émulation 5250 Client Access Personal Communications est compatible
avec le protocole TN5250, comme d’ailleurs plusieurs programmes shareware et freeware
du marché. L’encadré » Autres outils TN5250 « , contient la liste de ces programmes.
La plupart des administrateurs ont l’habitude d’utiliser FTP comme un
outil de transfert de fichier simple entre des serveurs Windows NT/2000 et AS/400
FTP. La plupart des administrateurs ont l’habitude d’utiliser
FTP comme un outil de transfert de fichier simple entre des serveurs Windows NT/2000
et AS/400. Mais beaucoup de gens ignorent que FTP peut également fonctionner en
mode batch pour des opérations sans surveillance, exécuter des commandes à distance,
voire transférer des objets AS/400 par Internet ou d’autres serveurs FTP intermédiaires,
puis restaurer ces objets sur un AS/400 cible.
Comme Telnet, FTP est constitué de deux parties : une application client et une
application serveur. Pour Windows NT 4.0, le serveur FTP fait partie du Windows
NT Option Pack en compagnie d’IIS (Internet Information Server). Pour Windows
2000, le serveur FTP fait partie du système d’exploitation de base. Il est installé
avec le World Wide Web Publishing Service. Il faut démarrer le FTP Publishing
Service pour que les clients FTP puissent se connecter et transférer des fichiers.
Sur Windows NT 4.0, on utilise l’option Control Panel/Services pour démarrer et
arrêter le FTP Publishing Service. Pour Windows 2000, on démarre le FTP Publishing
Service en utilisant l’option Control Panel/Administrative Tools/Services. Sur
l’AS/400, l’OS/400 contient FTP depuis la V3R1 et la commande STRTCP a pour effet
de démarrer le serveur FTP.
Bien que FTP soit normalement utilisé comme un utilitaire interactif, l’un de
ses points forts est sa capacité à être utilisé en batch pour des opérations sans
surveillance. L’AS/400 et Windows NT/2000 permettent tous deux d’exécuter des
transferts FTP batch, mais avec des modalités très différentes. Pour exécuter
FTP batch depuis un Windows NT/2000, il faut d’abord incorporer le jeu de commandes
FTP que l’on veut traiter dans un fichier texte. Ensuite, on utilise un commutateur
de ligne de commande pour ordonner à FTP d’obtenir sa commande d’entrée en provenance
du texte plutôt qu’interactivement. Dans la figure 1, un script FTP batch Windows
NT/2000 nommé FTPEMP.TXT extrait un fichier de l’AS/400.
La première ligne de ce script utilise la sous-commande open FTP pour démarrer
une session FTP avec l’AS/400 nommée S101AA0A. Les deux lignes suivantes transmettent
l’ID utilisateur et le mot de passe AS/400. Notons que FTP transmet ces valeurs
en texte clair. C’est très bien pour des connexions LAN, mais périlleux pour des
connexions Internet.
Lorsqu’on fournit l’ID et le mot de passe utilisateur au client FTP Windows NT/2000,
il faut noter une particularité : contrairement à toutes les autres lignes du
script batch, ces deux lignes ne sont précédées d’aucune sous-commande FTP.
Ensuite, la sous-commande get extrait le fichier nommé empftp de la bibliothèque
ODBCDEMO. Enfin, la sous-commande quit termine la session.
On exécutera ce script sur un système Windows NT/2000 en utilisant la commande
ftp conjointement au commutateur -s, de la manière suivante :
C:\>ftp -s:ftpemp.txt
L’utilisation de FTP batch depuis un AS/400 qui se connecte à un système Windows
NT/2000 est similaire à cette méthode, avec cependant quelques différences importantes.
La figure 2 présente un script FTP batch AS/400 qui envoie un fichier de l’AS/400
à un système Windows NT/2000.
La première ligne de ce script utilise la sous-commande open FTP pour démarrer
une session avec le système Windows NT appelé teca3. Bien que la sous-commande
open FTP soit utilisée exactement comme dans le script Windows NT/2000 précédent,
la ligne suivante, qui fournit l’information d’authentification, est très différente.
Elle utilise la sous-commande user FTP pour transmettre l’ID et le mot de passe
utilisateur Windows NT au système NT cible. Dans ce cas, l’ID et le mot de passe
utilisateur sont sur la même ligne séparés par un espace. Et, là aussi, en texte
clair.
Ensuite, la sous-commande put FTP envoie le fichier empftp de la bibliothèque
ODBCDEMO dans le répertoire c:\temp dans le système Windows NT. Enfin, les sous-commandes
close et quit terminent la session FTP.
Le démarrage de FTP batch sur AS/400 et sur Windows NT/2000 est également très
différent. Au lieu d’utiliser un commutateur de ligne de commande, le FTP AS/400
s’appuie sur la commande OVRDBF (Override Database File) pour remplacer le fichier
d’entrée FTP standard d’Input (où le fichier obtient son entrée interactivement)
par un fichier source qui contient le jeu de sous-commandes FTP. La figure 3 contient
le programme CL qui substitue le fichier FTP AS/400 standard en entrée par le
membre source EMPFTP qui contient les commandes batch du script FTP.
On voit dans cette liste que la commande OVRDBF sert à remplacer le fichier Input
par le fichier source EMPFTP contenu dans le fichier QCLSRC dans la bibliothèque
ODBCDEMO. Ensuite, on utilise la commande FTP pour démarrer une session FTP connectée
au système Windows NT, nommée teca3.
Le traitement des champs packés est l’une des plus grandes difficultés rencontrées
quand on utilise FTP entre les systèmes AS/400 et Windows NT/2000. Conçu pour
des systèmes de type ASCII, FTP transfère les données en format texte clair, incompatible
avec le format données packées de l’AS/400. On ne peut rien contre l’incapacité
de FTP à transférer des données packées, mais on peut tourner la difficulté sans
écrire aucun programme, en utilisant une copie proche du fichier qui sera transférée
conjointement à la fonction de commande à distance de FTP AS/400.
De tous les serveurs FTP, celui de l’AS/400 est le seul à pouvoir traiter
des commandes à distance
De tous les serveurs FTP, celui de l’AS/400 est le seul à pouvoir traiter des
commandes à distance ; le serveur Windows NT/2000 n’en est pas capable. Exécuter
des commandes à distance dans le cadre des scripts FTP peut s’avérer très utile
pour lancer des programmes qui traitent les fichiers transférés à l’aide des moyens
de transfert de fichiers standard de FTP. On peut utiliser cette fonction de commande
à distance pour contourner la limitation des champs packés en
1. copiant les champs packés du fichier d’origine dans un second fichier où les
champs numériques sont définis en utilisant le format décimal zoné
2. transférant le second fichier sur le système Windows NT/2000
Ce fichier cible doit être créé en utilisant DDS ou SQL avant d’exécuter ces commandes.
La figure 4 illustre un exemple de ce type de script.
Le script de la figure 4 commence par ouvrir une connexion vers l’AS/400 nommée
S101AA0A puis il transmet l’ID et le mot de passe utilisateur AS/400. Ensuite,
la sous-commande quote rcmd exécute deux commandes OS/400 sur le système AS/400
cible. La première instance de la sous-commande quote rcmd exécute la commande
CLRPFM (Clear Physical File Member) pour effacer le fichier EMPFTP. La seconde
sous-commande quote rcmd exécute la commande CPYF (Copy File) pour copier les
données du fichier ODBCDEMO/EMPLOYEE dans le fichier de destination EMPFTP. L’option
FMTOPT (*MAP *DROP) permet de copier les champs dans le fichier de destination
bien que les formats de données des fichiers soient différents.
Ensuite, la sous-commande get extrait le fichier empftp nouvellement enrichi et
l’écrit dans le répertoire en cours. A l’issue du transfert, la sous-commande
quote rcmd est utilisée à nouveau pour envoyer à l’opérateur système un message
lui indiquant la fin du transfert.
Téléchargez cette ressource
Sécuriser votre système d’impression
Longtemps sous-estimée, la sécurisation d’un système d’impression d’entreprise doit être pleinement prise en compte afin de limiter le risque de fuite d’informations sensibles. Voici les 3 principales précautions à prendre.