par Glenn Rose
Pour répondre aux questions concernant l'impression sur l'iSeries il faut clamer haut et fort que l'iSeries est richement doté en outils
de développement d'applications et qu'il accepte un large éventail d'imprimantes. Les questions sur la connexion d'imprimantes dépassent de loin celles
concernant les applications.
D'ailleurs, les questions sur les applications impliquent la recherche de solutions répondant à des besoins de gestion et, bien
souvent, les simples outils natifs de l'iSeries peuvent fournir la connectivité souhaitée. Les questions sur l'impression sont généralement moins simples et
directes en raison de l'évolution rapide de la technologie d'impression de l'iSeries. La connectivité twinax et les connexions SNA à distance appartiennent
au passé. Aujourd'hui, la connexion TCP/IP s'impose.
TCP/IP permet de communiquer avec n'importe quelle unité dotée d'une adresse IP et de répondre avec des fonctions appropriées. Pour
l'impression, une connexion TCP/IP peut varier : communications LPR/LPD (Line Print Remote/Line Printer Daemon) avec une file d'attente de sortie distante
vers les communications bidirectionnelles fournies par PJL (Printer Job Language) ; SNMP (Simple Network Management Protocol), et aussi des connexions
AFP (Advanced Function Printing). On peut classer ces types de connexion en trois catégories : faible coût/fonctions modestes, coût moyen/fonctions accrues,
ou coût élevé/puissantes fonctions. Cependant, avec les améliorations de la technologie d'impression et l'augmentation de l'offre des options d'impression
haut de gamme, le delta de coût du matériel entre ces types de connexions se réduit de plus en plus. Deux des outils iSeries natifs pour le développement
d'applications d'impression sont le fichier d'impression (print file) et DDS. Tous deux ont été sans cesse améliorés au fil des versions de l'OS/400 depuis
la V3R7, et de nombreuses nouvelles fonctions sont ajoutées à la V5R1. Les nouveaux mots-clés DDS en V5R1, par exemple, peuvent fournir un puissant formatage
que l'on pourra utiliser pour créer des applications d'impression destinées à la fois aux imprimantes IPDS (Intelligent Printer Data Stream) et PCL.
Malheureusement, il me semble que de nombreux développeurs n'ont pas été informés des nouvelles fonctions. De ce fait, ils consacrent
beaucoup de temps à accomplir des fonctions (comme coder et tester des séquences d'échappement ASCII natives, apprendre PCL et Postscript, utiliser des
reformateurs spoule coûteux) qu'ils pourraient tout simplement confier aux outils iSeries natifs.
La question de connectivité habituelle, qui est en réalité une question d’application, porte sur la transformation des fichiers spoule SCS
(qui s’imprimaient parfaitement sur des imprimantes twinax) en fichiers ASCII (qui se formateront correctement sur une imprimante laser d’entrée de gamme).
Dans bien des cas, une telle solution suppose que l’on remplace les formulaires pré-imprimés par des formulaires électroniques. Les formulaires
électroniques, objets graphiques, et mots-clés DDS qui sont natifs sur l’iSeries, ont donné la fausse impression qu’un matériel d’impression coûteux était
indispensable. Ce n’est plus vrai, mais le mythe perdure. Une question qui a attiré mon attention récemment portait sur une application héritée (legacy) d’un
System/38 dont la sortie devait être imprimée sur l’imprimante rattachée au réseau de l’utilisateur. Celui-ci voulait imprimer le rapport avec le logo de la
société. Le développeur avait donc pour mission de créer une application capable de lire le fichier spoule, de l’écrire dans un fichier de données, de
traiter le fichier de données en ajoutant la séquence d’échappement chargée de générer le logo, puis de respouler le fichier pour l’imprimer sur l’imprimante
de l’utilisateur.
Le développeur avait écrit une combinaison de programmes CL et RPG pour copier le fichier spoule dans un fichier base de données, traiter le
fichier, et réécrire la sortie dans le spoule avec la séquence d’échappement chargée d’appeler le logo stocké dans l’imprimante. Malheureusement, le
programme ne fonctionnait pas, malgré toutes les aides au débogage. Avant la mise en oeuvre de ce programme, tout aurait pu être correct pour l’attachement
twinax/terminal/imprimante parallèle où prévalait la transparence ASCII. Mais avec les nouveaux programmes, la connectivité du writer de sortie, la file
d’attente de sortie à distance, le driver PGL ou le driver SNMP et le HPT (Host Print Transform) de l’iSeries, convertissaient le flux de données. Il
n’est pas possible de déboguer correctement la sortie produite par une telle solution sans « tracer » le flux de données TCP/IP et sans déboguer le PCL créé
par le HPT. Une fois la trace capturée, il faut la faire analyser par un spécialiste de PCL, et aussi peut-être personnaliser le HPT pour que l’application
fonctionne. Toute sortie générée par l’application présentait des erreurs de formatage, utilisait une police de 17 CPP, et augmentait le LPP. C’est une
doléance courante avec les objets HPT sur l’iSeries et elle conduit généralement à créer un objet HPT personnalisé pour l’imprimante.
Téléchargez cette ressource
Préparer l’entreprise aux technologies interconnectées
Avec la « quatrième révolution industrielle », les environnements hyperconnectés entraînent de nouveaux risques en matière de sécurité. Découvrez, dans ce guide Kaspersky, comment faire face à cette nouvelle ère de vulnérabilité.
