développer des applications avec ou pour...

JAVA et AS400

© Institut de Poly-informatique (1999) JAVAAs400.doc 10/07/01 10:07 version 25

Développer des applications Avec ou pour l’AS400

Auteur : Dominique Vignez

© Institut de Poly-informatique (1999)

Cette page est laissée intentionnellement blanche.

JAVA et AS400


Table des matières 1 AS400 et Java forceps ou nid douillet ? ........................................................................1

1.1 Jurassic Park ou Stars War ? 1 1.2 TIMI pour AS400 1

2 Environnement et outils à disposition ...........................................................................3 2.1 Poste de travail 3

2.1.1 Programmation AS400 seule 3 2.1.1.1 Installation du Remote Abstract Window Toolkit for Java sur un PC 3

2.1.2 Programmation client/serveur 4 2.1.3 Le JDK de SUN 4 2.1.4 Visualage for Java 4 2.1.5 Webspherestudio 4 2.1.6 Tools box for Java 4

2.2 AS400 5 2.2.1 AS400 Developpement Kit (ADK) 5 2.2.2 QSHELL 5 2.2.3 DEBUG 6 2.2.4 Operation Navigator 6

3 Méthodologie de développement...................................................................................7 3.1 Introduction 7 3.2 Développer un programme pour exécution sur l’AS400 7

3.2.1 Saisie du source 7 3.2.1.1 Saisie avec SEU 7 3.2.1.2 Saisie avec un éditeur PC 7

3.2.2 Transfert du source dans l’IFS 7 3.2.3 Compilation du source 8 3.2.4 Exécution interprétée 8 3.2.5 Fabrication d’un objet PGM AS400 8

3.2.5.1 Fonctionnement de CRTJVAPGM 8 3.2.6 Exécution de l’objet AS400 PGM 10

3.2.6.1 Fonctionnement de RUNJVA 10 3.2.7 Exécution en Debug 10 3.2.8 Configuration de l’environnement 11

3.2.8.1 Variable d’environnement classpath 11 3.2.9 Liens symboliques 11 3.2.10 Configuration de l’accès à DB2 12

3.2.10.1 Correspondance des types de données 12 3.2.11 Scripts 12

3.2.11.1 Principales commandes script disponibles 12 3.2.12 Configuration de démarrage 13

3.2.12.1 Le script de profil utilisateur 13 3.2.12.2 Le script d’environnement 14 3.2.12.3 Le script de profil système 14

3.3 Développer un programme pour exécution sur le poste client 14 3.3.1 L’environnement de développement 14

4 L’interpréteur QSHELL.................................................................................................15 4.1 Commandes OS400 liées à Java 15 4.2 Visualage for Java 16

4.2.1 Editeur et base de connaissances 16


4.2.2 Debugger 17 4.2.3 Editeur de composition visuel 17 4.2.4 Data access builder 17 4.2.5 RMI access builder 17 4.2.6 Enterprise Toolkit 17

5 WebSphere.....................................................................................................................18 5.1 WebSphere Server 18 5.2 WebSphere Studio 19

6 Différences entre CGI et Servlets ..................................................................................21 6.1 Cohérence et modularisation des composants 21 6.2 Performances 21 6.3 Portabilité et compétences 21 6.4 Productivité 22 6.5 Jouer la multiplicité 22

7 Ressources et sources d’informations............................................................................23 7.1 Sites Web 23 7.2 Resources internes 23

1


1 AS400 et Java forceps ou nid douillet ? Il est possible que vous soyez étonné non seulement qu’une technologie comme Java soit disponible sur AS400, mais surtout qu’elle ait pu être si facilement implantée par IBM. Ce qui vous surprendra encore plus, c’est de constater que l’AS400 est parmi les plates-formes, sinon la plate-forme sur laquelle Java offre les meilleures performances.

1.1 Jurassic Park ou Stars War ? En 1975 IBM met sur le marché une machine « bizarre » l’IBM S38 qui est l’ancêtre de l’AS400. Dès cette époque les fondements du système actuel sont présents : le S38 n’est pas une machine ni un système d’exploitation, c’est un « concept » d’ordinateur dont le système est indépendant du matériel, mais dont l’ensemble forme un tout intégré pensé et architecturé pour des entreprises qui l’utiliseront et dont le métier n’est pas l’informatique. C’est un ordinateur conçu pour des non informaticiens. Cet ordinateur est doté d’une base de données et optimisé pour les processus informatiques résolvant des problèmes de gestion.

Les pères fondateurs de l’AS400 ont implémenté dans cette machine tout ce qui était du domaine du rêve à cette époque (1970). Ils ont écumé, ou écrêmé tout ce qui était dans des cartons des laboratoires de recherche d’IBM et ont construit ce qui leur semblait être la machine rêvée de l’utilisateur ET de l’informaticien. Entre autres ils y ont mis la technologie objets, la base de données relationnelle, la gestion simple de la mémoire et surtout l’idépendance du logiciel et du matériel.

Toutes ces technologies étaient émergeantes, ils les ont implémentées alors même qu’elles n’étaient pas entièrement opérationnelles ou que le reste du monde informatique a attendu plusieurs années pour s’en servir réellement.

1.2 TIMI pour AS400 Une des principales préoccupation du team de Rochester était de pouvoir disposer d’un système d’exploitation qui pourrait tourner sur plusieurs machines différentes ayant des processeurs différents parce que les clients avaient des besoins différents (différentes tailles d’entreprises) ou qu’un client avait des besoins qui évoluaient (entreprise en forte croissance). Le même système d’exploitation devait donc pouvoir tourner sur des machines TRES différentes. De plus l’emballement de l’avancée technologique se faisait déjà sentir. Il fallait donc aussi disposer d’un système d’exploitation susceptible de suivre très rapidement les nouveautés technologiques. Ces deux critères ont conduit les ingénieurs de Rochester à inventer la :

Technology Independant Machine Interface.

TIMI part d’une idée relativement simple : tout logiciel exécutable y compris le sytème d’exploitation n’est pas sous une forme directement exécutable par le processeur, ni sous forme de code source interprétable, mais sous une forme intermédiare « semi-compilée » sorte d’espéranto entre les différends processeurs. Cette forme intermédiaire étant appelée du Byte Code. Pour que le Byte Code soit exécuté par un processeur, il suffit d’écrire un traducteur à la volée qui traduit le Byte Code en instructions spécifiques au processeur. Le tout en langage orienté Objets. Au premier abord une instruction AS400 (voir figure ci-dessous) ressemble à une instruction d'architecture conventionnelle avec un code opération et des opérandes. La grosse différence

2 JAVA et AS400


est là où les instructions trouvent leurs opérandes. L'AS400 a des opérandes immédiats, mais il n'a pas de notion de registre ni de mémoire; à la place les instructions portent sur des objets. Imaginez « l’énorme difficulté » qu’il y a à fournir une JVM dans ces conditions. Imaginez combien 25 ans de pratique de cette technologie donnent d’avance sur la concurrence.

3


2 Environnement et outils à disposition

2.1 Poste de travail Les paragraphes qui suivent indiquent les ressources nécessaires pour mettre en œuvre l’un ou l’autre aspect de la programmation en Java ou fonctionnalité disponible avec l’AS400. 2.1.1 Programmation AS400 seule Explorateur Windows, Operation Navigator, un éditeur de texte PC performant (voir saisie du source avec un éditeur PC au chapitre 3). Dans ce cas la configuration du poste client est très légère, seule la saisie du source se fait sur le PC, toutes les autres opérations sont faites en émulation de terminal AS400. Les applications possibles sont essentiellement du batch, les échanges interactifs se font en interface caractère. Les sources comportant des fonctionnalités graphiques sont compilables sur l’AS400, mais pas exécutables. Dès que la nécessité d’utiliser une interface graphique se fait sentir, il faut utiliser une ou l’autre technique de type client/serveur. Toutefois il est possible d’utiliser l’écran du PC pour afficher du graphique AWT s’exécutant sur l’AS400 en utilisant la fonction RAWT. 2.1.1.1 Installation du Remote Abstract Window Toolkit for Java sur un PC Avec le Remote Abstract Window Toolkit (AWT), vous pouvez afficher du graphique à distance. Pour utiliser Remote AWTvous devez avoir une connexion TCP/IP PC/AS400 et le JDK de SUN (1.1.6 ou ultérieur) installé sur l’AS400 et sur le PC.

Pour installer Remote AWT, faites les tâches suivantes :

1. Rendez les fichiers de classes Remote AWT accessibles sur le PC en les copiant sur le PC ou mappez un lecteur réseau du PC sur le répertoire AS400 les contenant.

Copy /QIBM/ProdData/Java400/lib/rawt_PC_classes.zip C:\rawt\rawt_PC_classes.zip

2. Ajoutez le fichier rawt_PC_classes.zip au CLASSPATH du PC en chargeant la variuable d’environnement CLASSPATH ou en utilisant le paramètre -classpath de la commande java.

java -classpath c:\jdk1.1.6\;c:\rawt\rawt_PC_classes.zip lib\classes.zip

3. Démarrez Remote AWT sur le PC. En utilisant la commande :

java com.ibm.rawt.server.RAWTPCServer

Pour plus d’infos voir :

• Running a Java program using Remote Abstract Window Toolkit comment executer un programme Java avec l’AS400, RAWTPCServer, et Netscape.

http://publib.boulder.ibm.com/pubs/html/as400/ic2924/info/java/rzaha/RZAHAM15.HTM

http://publib.boulder.ibm.com/pubs/html/as400/ic2924/info/java/rzaha/RZAHA109.HTM




4 JAVA et AS400


• Printing with the Remote Abstract Window Toolkit comment imprimer, identique au standard d’impression AWT. Avec en plus comment imprimer sur l’AS/400.

• Remote Abstract Window Toolkit properties montre que les Remote AWT classes ne sont plus dans le classpath système par défaut et explique comment lancer une application Remote AWT application en utilisant la propriété os400.class.path.rawt.

• Remote Abstract Window Toolkit SecurityManager restrictions fournit des explication concernant les restrictions s’appliquant lorsque vous exécutez des application s Java avec Remote AWT sous le contrôle d’un SecurityManager.

Pour plus d’infos sur AWT, voir : http://java.sun.com/products/jdk/awt/ 2.1.2 Programmation client/serveur La programmation client serveur peut revêtir plusieurs formes, divers outils et packages Java seront alors indispensables sur le PC ou sur l’AS400. 2.1.3 Le JDK de SUN Le Java Development Kit de SUN est indispensable dans tous les cas. Mais il est impératif que le même niveau de version soit également disponible sur l’AS400. Pour connaître les dernières versions à jour disponibles consultez :

http://www.developer.ibm.com/java/member/technical/jdk.html 2.1.4 Visualage for Java Visualage est un outil de développement très paratique pour developer facilement et rapidement des interfaces IHM et pour réutiliser des composants logiciels comme les javabeans. Trois versions sont disponibles, la version Entry, la version Professional et la version Enterprise. Cette dernière bien sûr procure le maximum de possibilités, mais est vendue relativement cher. La version professional est livrée avec l’OS400. La version Entry peut être téléchargée gratuitement, mais n’offre bien entendu que des possibilités assez restreintes. Pour débuter, la version Professional est un bon compromis. La version Enterprise offre essentiellement la fourniture d’ET/400, une bibliothèque fournie d’outils et de classes supplémentaires facilitant grandement les besoins des développeurs. De plus il y a des fonctions permettant le développement en équipe, ce qui est très pratique pour les projets même modestes mais requierant plusieurs développeurs. 2.1.5 Webspherestudio WebSphere studio est un environnement de développement qui fédère un certain nombre d’outils de développement. Pour plus de détail, reportez vous au chapitre spécifique plus avant dans ce support. 2.1.6 Tools box for Java La boite d’outils Java AS400 est packagée dans un logiciel sous licence 5769 JC1 qui doit être installé sur l’AS400. C’est un ensemble de classes Java qui permettent l’accès à certaines ressources AS400 comme : Lancement de programmes et de commandes AS400 (serveur AS400 QZRCSRVS). Accès aux files d’attente de données (DATQ, serveur AS400 QZHQSSRV).




http://java.sun.com/products/jdk/awt/

5


Utilisation du Driver JDBC (serveur AS400 QZDAOINIT). Accès à la base de données au niveau record (sans SQL, serveur AS400 QRWTSRVR). Cette possibilité suppose l’activité du service TCP/IP DDM (Distributed Data Management). Fonctions de gestion des répertoires et fichiers de l’IFS (serveur AS400 QPWFSERVSO). Accès aux ressources imprimantes partagées (serveur AS400 QNPSERVS). Utilisation des files d’attente de messages (MSGQ). Récupération d’informations sur les Jobs actifs sur l’AS400. Récupération d’informations sur les comptes utilisateurs AS400 (USRPRF). Accès aux Userserspaces AS400 (USRSPC). Gestion des certificats numériques d’authentification. Classes en interface graphique donnant des listes de ressources AS400 prêtes à l’emploi. Pour que ces différents serveurs soient actifs, il faut qu’ils aient été démarrés par la commande STRHOSTSVR SERVER(*ALL), ce qui est généralement déjà fait si vous utilisez Operation Navigator.

2.2 AS400 2.2.1 AS400 Developpement Kit (ADK) La documentation html est packagée dans un fichier zip : rzaha.zip Après avoir installé le logiciel sous licence 5769 JV1 ou vérifié son installation par la commande GO LICPGM, puis option 11 afficher les programmes sous licence installés. L’option *base donne le JDK 1.1, l’option 1 donne le JDK 1.1.6, l’option 2 donne le JDK 1.1.7, l’option 3 donne le JDK 1.2 aussi connu sous le nom de JDK 2.

Vous pouvez choisir de modifier la valeur système QUTCOFFSET. Pour connaître sa valeur actuelle vous pouvez utiliser la commande DSPSYSVAL SYSVAL(QUTCOFFSET). Si la valeur par défaut est : (+00:00) alos Java assume qu’il s’exécute en temps universel UTC. Dans ce cas la propriété Java user.timezone est initialisée par défaut à la valeur de l’UTC.

Pour plus d’informations voir :

http://AS400BKS.rochester.ibm.com/cgi-bin/bookmgr/bookmgr.cmd/DOCNUM/SC41-5603 2.2.2 QSHELL QSHELL est une émulation d’environnement de travail Unix permettant de mener une grande partie des tâches de développement d’applications Java sur AS400. Pour plus d’informations voir le chapitre spécifique plus avant dans ce support.

http://as400bks.rochester.ibm.com/cgi-bin/bookmgr/bookmgr.cmd/DOCNUM/SC41-5603

6 JAVA et AS400


2.2.3 DEBUG Java utilise le debugger système de l’AS400 qui n’est pas lancé par une commande STRDBG comme d’ordinaire pour les autres langages, mais est invoqué au lancement de l’exécution avec OPTION(*DEBUG). Pour le reste les commandes sont identiques à l’usage habituel. 2.2.4 Operation Navigator Operation Navigator est un ensemble d’outils permettant d’assurer un certain nombre de tâches d’administration et d’accès AS400 via une interface graphique micro. De nombreuses possibilités sont offertes par OpNav qui ne sont même pas disponibles en accès 5250 via les commandes système. L’usage de Java suppose l’utilisation de TCP/IP. Il est donc recommandé d’utiliser la version d’Operation Navigator de Client Express plutôt que celle fournie avec Client Access standard. Les connexions SNA via un logiciel dit « router » comme NetSoft n’étant pas supportées pour Java.

7


3 Méthodologie de développement

3.1 Introduction Il est une chose à laquelle le développeur doit bien prendre garde : il ne doit pas confondre développer du code Java pour exécution sur le poste client avec accès à des ressources sur l’AS400 et développer du code pour exécution sur l’AS400. La différence est fondammentale dès que l’on comprend que l’AS400 n’offre pas d’infertace graphique native. Les programmes Java sur AS400 seront donc essentiellement des programmes de type batch et si l’intervention de l’opérateur est nécessaire, ce sera via l’interface QSHELL plus pauvre que l’interface 5250 ou via les Api’s DSM (Dynamic Screen Manager).

3.2 Développer un programme pour exécution sur l’AS400 3.2.1 Saisie du source 3.2.1.1 Saisie avec SEU Il est possible de saisir le source du programme sur l’AS400 dans un membre d’un objet de type *File et d’attribut PF-SRC, grâce à l’éditeur de sources SEU (commande STRSEU). Il en va malheureusement de même pour Java que pour le langage C. Ces langages utilisent certains caractères qui ne sont pas dans la page de code EBCDIC 297 du français. Il s’en suit des difficultés assez grandes pour lire correctement un source puisque les caractères {, }, #, \, s’affichent é, è £, et ç ; il en va de même pour [, ], |, ~. Si vous disposez d’une version anglo saxone il n’y a par contre aucun problème. L’institut de Poly-informatique a développé un utilitaire permettant de voir les bons caractères dans le source et de les transcoder dans un fichier temporaire pour soumettre le source au compilateur. Si vous choisissez néanmoins cette option de travail, vous devez copier votre source dans un répertoire de l’IFS par la commande CPYSTMF (copy stream file). 3.2.1.2 Saisie avec un éditeur PC Il est également possible et même préférable de saisir le source avec un éditeur de source dans un fichier texte PC avec Notepad ou un autre éditeur standard de Windows. Une version améliorée de Notepad en freeware est disponible en téléchargement à l’adresse :

Pan.inspi.fr/appli/notespad D’autres produits sont également disponibles sur :

http://perso.wanadoo.fr/palimpseste/notepad.zip ftp://wwwping.be/jg/EditPad.zip

http://members.tripod.com/~aadavids/metapad.zip http://members.aol.com/romainguy/jeset.zip

3.2.2 Transfert du source dans l’IFS La copie du fichier texte se fait très facilement par copier/coller ou drag and drop depuis un répertoire du PC vers l’IFS de l’AS400 en connectant un lecteur réseau sur la ressource partagée QIBM. De même la création d’un répertoire dans l’IFS peut se faire en émulation 5250 par la commande AS400 MD, mais il est très aisé de réaliser la même chose avec l’explorateur de Windows ou Exploration Navigator (Onav).

http://perso.wanadoo.fr/palimpseste/notepad.zip

ftp://wwwping.be/jg/EditPad.zip

http://members.tripod.com/~aadavids/metapad.zip

http://members.aol.com/romainguy/jeset.zip

8 JAVA et AS400


3.2.3 Compilation du source L’accés au compilateur Java se fait via l’interpréteur QSHELL. Pour démarrer l’interpréteur il faut lancer la commande STRQSH ou QSH depuis la ligne de commande de l’émulateur 5250. L’exécution de la commande permet d’obtenir la ligne de commande de l’interpréteur. A ce stade il est possible de compiler le source par :

Javac /chemin/source.java En prenant bien garde de respecter la casse (majuscules/minuscules). QSHELL est “case sensitive”. 3.2.4 Exécution interprétée Si tout se passe bien et que la compilation aboutie sans erreur, il est possible de lancer l’exécution par :

Java -classpath /chemin nomprog 3.2.5 Fabrication d’un objet PGM AS400 Pour de meilleures performances il est recommandé, une fois la mise au point du programme faite de fabriquer des objets *PGM AS400 à partir des classes java grâce à la commande :

CRTJVAPGM CLSF(‘/chemin/nomprog.class’) OPTIMIZE(n) Où (n) est une valeur admise pour le paramètre de la commande. Il est possible de vérifier le résultat par :

DSPJVAPGM CLSF(‘/chemin/nomprog.class’) 3.2.5.1 Fonctionnement de CRTJVAPGM La commande CRTJVAPGM n’est pas un compilateur Java. Cette commande traduit du bytecode Java déjà compilé en instructions RISC 64 bits que le matériel AS400 peut exécuter directement. Ces objets directement exécutables (DE objects) ne ressembles pas exactement aux objets de type *PGM obtenus par compilation de sources RPG ou Cobol. La première et bonne raison est qu’ils sont invisibles ! Il n’est pas possible de les visualiser par la commande DSPLIB par exemple. Ce sont des objets système appartenant à la couche (SLIC) sous l’OS400, mais ce ne sont pas des objets OS400. Un DEO est associé par l’OS400 au fichier classe auquel il correspond, il est comme inclus dedans. Lorsque vous déplacez un fichier classe d’un réperoire dans un autre, le DEO associé le suit. Lorsque vous sauvegardez un fichier classe, le DEO associé est sauvegardé avec. La principale raison d’utiliser des DEO est l’optimisation des programmes. Sur la plus part des plates-formes Java est est un langage interprété. Quelques JVM incluent un compilateur à la volée (JIT, Just In Time compiler) qui est capable de créer du code spécifique à chaque fois que le programme est lancé. Mais les gains de performances apportés par un compilateur JIT sont limités par le temps que prend le JIT pour créer le code optimisé. Le gain peut même être négatif, c’est à dire qu’il peut s’en suivre des dégradations de performances. La commande CRTJVAPGM pourrait être appelée un JOT (Just One Time compiler).

9


3.2.5.1.1 Paramètre CLSF Vous pouvez indiquer un fichier unique ou un ensemble de fichiers avec des caractères jokers. Il est même utile et recommandé d’utiliser des fichiers archives comme des .JAR ou des .ZIP. Dans ce dernier cas, une seulle commande d’optimisation est nécéssaire pour optimiser une application entière. Exemples :

CRTJVAPGM CLSF(’/chemin/nomprog.class’) ou

CRTJVAPGM CLSF(’/chemin/nomprog*.class’) ou

CRTJVAPGM CLSF(’/chemin/nomapplication.zip’) ou

CRTJVAPGM CLSF(’/chemin/nomapplication.jar’)

3.2.5.1.2 Paramètre OPTIMIZE Comme les langages ILE, Java possède plusieurs niveaux d’optimisation. Plus le niveau est élevé plus les programmes s’exécutent rapidement et moins ils ont de possibilités de debug. Les niveaux possibles sont :

- 10 (valeur par défaut) un DEO est créé, l’optimisation est minimale, toutes les options de debug sont possibles.

- *INTERPRET un DEO est créé, aucune optimisation n’est faite, le bytecode est interprété à l’exécution.

- 20 un DEO est créé, une légère optimisation est réalisée, les variables du programme sont visualisables mais pas modifiables.

- 30 un DEO est créé, une plus grande optimisation est faite, les variables du programme sont visibles en debug et non modifiables, mais la valeur visualisée a pu déjà changer.

- 40 un DEO est créé, l’optimisation est ma ximum, le debug avec visualisation du source est impossible.

3.2.5.1.3 L’embrouille de l’optimisation Il est fort à parier que vous commenciez à vous poser des questions « para-normales » en essayant de créer et de supprimer des DEO. Voici un cauchemar qui peut se réaliser :

- vous créez un DEO de niveau 40 avec CRTJVAPGM, - il y a des problèmes d’exécution, vous voudriez faire un debug, mais cela

n’est pas possible avec un DEO au niveau 40, - vous détruisez le DEO avec DLTJVAPGM, - vous lancez l’exécution interprétée du programme avec la commande

RUNJVA en précisant OPTIMIZE(10). Vous espérez ainsi pouvoir faire un debug de votre programme. Mais c’est raté ! Même si vous demandez une optimisation de niveau 10, l’interpréteur utilisera le niveau d’optimisation précédent même avec le DEO détruit. Cas inverse mais aussi fort :

- vous créez un DEO de niveau 10 avec CRTJVAPGM,

10 JAVA et AS400


- vous voulez voir la différence de performances au niveau 40, - vous détruisez le DEO avec DLTJVAPGM, - vous lancez l’exécution interprétée du programme avec RUNJVA en

précisant OPTIMIZE(40). Vous espérez voir la différence. Mais c’est raté ! Même si vous demandez une optimisation de niveau 40, l’interpréteur utilisera le niveau donné dans CRTJVAPGM, c’est à dire le niveau 10. Donc pas de différence. Il ne faut donc utiliser CRTJVAPGM que quand tout est fini et que vous savez pertinamment quel niveau d’optimisation vous avez besoin.

3.2.5.1.4 Paramètre REPLACE Ce paramètre permet de conditionner le remplacement d’un DEO existant. Les valeurs possibles sont :

- *YES (valeur par défaut), si un DEO existe il est remplacé, si il n’en existe pas il est créé.

- *NO si la classe associée a changé depuis la création du DEO, le DEO est remplacé. Si la classe n’a pas changé depuis la création du DEO, le Deo n’est pas remplacé. Si un caractère générique (*)est utilisé au paramètre CLSF, les classes modifiées verront leur DEO remplacé, les nouvelles classes auront un DEO neuf.

3.2.6 Exécution de l’objet AS400 PGM Pour exécuter cet objet AS400 il suffit d’entrer sur la ligne de commande de l’émulateur 5250 :

RUNJVA CLASS(nomprog) CLASSPATH(‘/chemin/nomprog.class’) 3.2.6.1 Fonctionnement de RUNJVA La commande RUNJVA lancée dans un JOB interactif s’exécute en trois temps. En premier un job BCI (Batch Call Immediate) appelé QJVACMDSRV est sollicité pour lancer la JVM. Ensuite une DATAQUEUE nommée QP0ZTRML est créée dans la bibliothèque QTEMP du JOB. Cette DATAQUEUE est créée pour offrir un moyen d’échange d’informations entre le JOB interactif et le JOB BCI. Dans un troisième temps une session DSM (Dynamic Screen Manager) est créée dans le job interactif. Au travers de la session DSM Java envoie les sorties sur l’écran. Le programme Java semble donc tourner dans le JOB interactif qui a lancé la commande RUNJVA. Mais en réalité il tourne actuellement dans le JOB BCI. Lorsque le programme Java se termine, le JOB BCI s’arrête et la DATAQUEUE est détruite. 3.2.7 Exécution en Debug Pour exécuter ce PGM en debug il faut lancer la commande :

RUNJVA CLASS(nomprog) CLASSPATH(‘/chemin/nomprog.class’) OPTION(*DEBUG)

11


3.2.8 Configuration de l’environnement Un certain nombre de préparations sont nécessaires pour travailler correctement en Java sur AS400. 3.2.8.1 Variable d’environnement classpath Le classpath est une variable d’environnement que Java utilise pour localiser les fichiers classes ou archives dans l’IFS à la compilation et à l’exécution. Les variables d’environnement sont relativement nouvelles pour les habitués de l’OS400, mais sont familières aux habitués d’Unix ou du monde des PC. Elles ont été créées dans une large mesure pour supporter Java sur l’AS400. Les variables d’environnement sont créées dans un travail et peuvent être utilisées ultérieurement par des produits sytèmes comme la JVM. L’arrêt du travail (le JOB) entraîne la disparition des variables d’environnement. Les variables d’environnement sont « case sensitive », il faut donc respecter les majuscules et les minuscules. La variable d’environnement classpath peut comme la variable PATH du Dos, contenir plusieurs chemins. Les différents chemins sont séparés ici par « : » et non pas ; comme dans le Dos.

3.2.8.1.1 L’embrouille du classpath Il faut vous méfier de ce que vous voyez et qui ne reflête pas nécessairement la vérité « vraie ». En utilisant l’explorateur de Windows ou Onav vous pouvez fort bien lire des noms de répertoires ou de fichiers dans l’IFS qui ne respectent pas la casse des noms systèmes OS400. Lorsque vous avez un problème avec classpath pensez à utiliser la commande WRKLNK qui vous permet de visualiser l’orthographe exacte des noms. 3.2.9 Liens symboliques Gérer le classpath peut vite se révéler un art très délicat. Si les applications, les programmes, … voient leur nombre grandir et cela arrive plus vite que vous le penser, le nombre de chemins d’un classpath peut devenir très vite ingérable. Surtout si vos répertoires et sous répertoires sont nombreux et profonds. Vous pouvez créer des liens symboliques qui vont se comporter comme des alias (courts) de chemins (très longs). Ce type d’outil est également familier aux utilisateurs d’Unix, mais totalement inconnu aux habitués de l’AS400 et de QSYS.LIB. Le format de la commande est : ADDLNK +

OBJ(‘/nomrépertoire/nomsousrépertoire/ nomsousrépertoire/ nomsousrépertoire/ nomsousrépertoire/ nomsousrépertoire/ nomsousrépertoire/ nomsousrépertoire’) +

NEWLNK(nomchemin) LNKTYPE(*SYMBOLIC) Il est tout à fait possible de créer un lien symbolique pour un fichier : ADDLNK +

OBJ(‘/nomrépertoire/nomsousrépertoire/ nomsousrépertoire/ nomsousrépertoire/ nomsousrépertoire/ nomsousrépertoire/ nomsousrépertoire/ nomfichier.class’) +

NEWLNK(nomfichier) LNKTYPE(*SYMBOLIC)

12 JAVA et AS400


3.2.10 Configuration de l’accès à DB2 Pour accéder à DB2 depuis Java, il faut disposer d’un nom de base. Il existe une table des bases (RDBDIR) qui est gérée par la commande WRKRDBDIRE. Ce répertoire contient aussi les références de bases éloignées sur d’autres systèmes. 3.2.10.1 Correspondance des types de données

Type DB2 Type Java Binaire 2 octets Short Binaire 4 octets Integer Caractère String Date String Flotant 4 octets Float Flotant 8 octets Double Hexadécimal Byte Décimal packé Big decimal Decimal zone Big decimal Time String Timestamp String

3.2.11 Scripts Les scripts sont des procédures qui sont interprétées contrairement aux programmes en CLP qui sont compilés. Le format de saisie des instruction est libre. Il est possible de créer des scripts de façon identique à la création de sources java. Il faut aussi les stocker dans l’IFS. Ils peuvent être stockés sous le répertoire Root, c’est plus commode sans classpath, mais ce n’est pas très indiqué pour l’ordre et le rangement. L’exécution des scripts se fait depuis QSHELL, la synthaxe est :

. nomscript L’AS400 ne sait pas exécuté quoi que ce soit sous son seul nom, son orientation objets l’oblige à utiliser une méthode d’une classe. En l’occurrence ceci est représenté par le point devant le nom du script à exécuter. Il est possible de lancer l’exécution d’un script à partir de la ligne de commande de l’émulateur 5250 par :

STRQSH CMD(‘. Nomscript’) L’environnement Shell localise les scripts en inspectant en premier le répertoire courant, puis dans les réperoires indiqués dans la variable d’environnement PATH. Par défaut cette variable est chargée avec la valeur ‘/usr/bin’. 3.2.11.1 Principales commandes script disponibles

3.2.11.1.1 echo

13


affiche une chaîne sur l’écran, les commandes print et printf sont des alternatives possibles à echo avec des options de formattage possibles.

3.2.11.1.2 read read est la commande permettant de saisir une valeur au clavier. Le format est :

read nomvariable

3.2.11.1.3 commentaires un commentaire commence par un # et se termine par une fin de ligne.

3.2.11.1.4 Alternatives Des exécution conditionnelles peuvent être programmées. Le format général est :

if condition then commande else commande

fi Des conditions peuvent être imbriquées par l’option elif.

3.2.11.1.5 Boucles Il est possible de programmer des boucles avec l’instruction while qui réitérera un groupe de commandes comprises entre do et done tant que la contidition qui suit la commande test est vraie. Exemple :

a = 10 while test ‘’$a’’ –gt ‘’0’’ do echo ‘’départ de la fusée dans $a secondes’’ a = $(($a – 1)) done

3.2.12 Configuration de démarrage Lorsque vous démmarez le Shell, vous pouvez trouver qu’exécuter toujours la même suite de commandes pour configurer votre environnement de travail fini par être rébarbatif. Il est possible d’automatiser tout cela dans des scripts. Il existe trois sortes de scripts lancés automatiquement. 3.2.12.1 Le script de profil utilisateur Le script utilisateur est stocké dans la home directory d’un utilisateur sous /home. Le nom du

script est obligatoirement ‘’.profile’’. Ce nom n’est pas étranger aux utilisateur d’Unix.

14 JAVA et AS400


3.2.12.2 Le script d’environnement Ce script est exécuté au moment de l’exécution de la commande STRQSH. Le nom du script n’est pas prédéterminé, vous pouvez choisir le nom que vous voulez. C’est par l’intermédiaire de la variable d’environnement ENV que vous indiquez le nom exact du script à exécuter. 3.2.12.3 Le script de profil système Le script système est valable pour tous les utilisateurs. Il a un nom prédéfini, il doit s’appeler profile (sans le point devant) et être stocké dans le répertoire /etc.

3.3 Développer un programme pour exécution sur le poste client 3.3.1 L’environnement de développement Le Java Development Kit (JDK) proposé gratuitement par Sun est un environnement de développement et d’exécution pour java. Quelques outils du JDK (exemple JDK1.2) : - javac : compilateur java. Il lit les fichiers sources (.java), les traduit en byte-code (.class).

exemple : javac PremierProg.java - - java : lance la JVM. Elle interprète le byte-code : java PremierProg - - appletviewer : outils de test des applets. Les browsers Internet incorporent une JVM. La version peut être différente de celle utilisée pour la compilation. Exemple : InternetExplorer intègre la version 1.1.x La documentation java permet de consulter les caractéristiques des packages composant le JDK. Elle est consultable directement grâce à un browser (c:\Jdk1.2\docs\api\index.html).

15

© Inst

4 L’interpréteur QSHELL

4.1 Commandes OS400 liées à Java Commande Description Commentaires CRTJVAPGM Crée un programme Java Transforme un fichier classe en

bytecode natif AS400, un DEO. DLTJVAPGM Détruit un programme Java Suppression d’un DEO DSPJVAPGM Affiche la description d’un

programme Java Indique si un DEO existe et quel est sont niveau d’optimisation

RUNJVA Exécute un programme Java Lance l’exécution d’un DEO WRKENVVAR Gère les variables

d’environnement

ADDENVVAR Crée une nouvelle variable d’environnement

CHGENVVAR Modifie la valeur d’une variable d’environnement

WRKLNK Gère les liens d’objets Établit des liens symboliques dans l’IFS

ADDLNK Crée un lien symbolique RMVLNK Supprime un lien symbolique WRKRDBDIRE Gére les entrées de répertoire de

base de données relationnelle Configuration des bases locales et distantes

L’interpréteur QSHELL offre une interface de travail un peu surprenante pour les habitués de l’interface 5250.

$ ===> _____________________ ______________________________________________________________________________ F3=Exit F6=Print F9=Retrieve F13=Clear F17=Top F18=Botto

QSH Command Entry

______________________________________________________________________________________ ___________________________________________ ___________________________________________ F12=Disconnect m F21=CL command entry

itut de Poly-informatique (1999)

16 JAVA et AS400


Un certain nombre de commandes de type Unix sont disponibles dans cet environnement de travail : alias crée un raccourci pour des noms longs unalias supprime un raccouci mv Move déplace un fichier dans l’IFS cp Copy copie un fichier dans l’IFS ls Liste liste le contenu d’un directory de l’IFS mkdir Make Dir créé un directory dans l’IFS rm Remove supprime un ou plusieurs fichiers dans l’IFS rmdir Remove Dir supprime un ou plusieurs directories dans l’IFS chmod CHGAUT modifie les droits d’accès à un fichier de l’IFS ln Link créé un nouveau lien sur un fichier ou un directory existant find Find recherche un un fichier dans l’IFS cc Compile C compile un source en langage C system exécute une commande OS400 cat lit et écrit le contenu d’un fichier sur la sortie standard grep cherche des caînes dans des fichiers de l’IFS export exporte une variable d’environnement javac créé une classe, un fichier .class à partir d’un source .java java exécute un fichier classe avec la JVM appletviewer exécute une classe comme une applet (uniquement avec RAWT) rmic créé et compile des fichiers squelettes de classe et des stubs en aide à RMI rmiregistery piste des objets éloignés et permet aux clients de les localiser (RMI) jar créé un fichier archive .jar javakey génère des certificats numériques pour des fichiers jar et gère une base données

de clés publiques et privées serialver clacule un numéro de série basé sur la représentation interne d’un fichier classe

qui permet de vérifier des niveaux de versions (uniquement avec RAWT) javah créé un fichier .h en langage C pour permettre les appels de méthodes JNI javap déassemble une classe java javadoc créé une documentation HTML d’une classe en extrayant les commentaires (//)

du source d’une classe native2ascii converti en format unicode des fichiers encodés dans d’autres formats

4.2 Visualage for Java VisualAge est un outils de développement visuel et graphique qui permet de masquer tout ce qui n’est pas strictement indispensable à manipuler dans le code source. De très nombreux assistants sont disponibles qui facilitent grandement la tâche du développeur. 4.2.1 Editeur et base de connaissances VAJ offre une approche de développement de logiciel hôte en opposition aux autres outils du marché. Au lieu d’éditer des fichiers sources, vous importez tous les codes source dans une base de connaissances (repository), puis vous les éditez dans un espace de travail organisé. Le repository et l’espace de travail sont essentiellement une base de données d’objets et de sources maintenue par VAJ. L’intérêt de cette base de données est qu’elle vous permet de travailler sur vos projets avec différentes approches.

17


Les différentes approches possibles sont :

Approche Paysage visible Workbench Un ensemble de projets, ouvrir un projet, un package, ou une classe Project Un ensemble de packages, dans un package gérer les classes et

méthodes Package Un ensemble de classes, dans une classe gérer les méthodes Class Un ensemble de méthodes Method Une méthode seule Repository Versions courante et archives des projets, packages, classes, méthodes Debug Un moyen de gérer les programmes java en exécution Scrapbook Un moyen de tester des fragments de code java sans créer ni compiler

une classe complète 4.2.2 Debugger Le debugger VAJ est relativement puissant, il offre de nombreuses fonctionalités standards offertes par les outils de debug du marché et permet aussi de modifier le code et de vérifier son exécution immédiatement sans avoir à recompiler le programme ni même de le relancer complètement. 4.2.3 Editeur de composition visuel C’est l’outil le plus spécifique de VAJ. Il permet par de simples clicks ou drag and drop ou drops de fabriquer la plus grosse partie du code exécutable sans saisir énormément de code java pour le développeur. La connaissance préalable du comment développer le code est cependant très utile à l’usage. En ce sens l’outil est parfait pour un développeur sachant codifier les détails, mais est plus rugueux pour celui qui ne connaît pas les détails. L’utilisation de couleurs spécialisées aide grandement aux tâches de développement. 4.2.4 Data access builder Cette option n’est disponible qu’avec la version enterprise. Cette fonction communément appelée DAX est une facilité pour développer les accès base de données via JDBC. 4.2.5 RMI access builder Cette option n’est disponible qu’avec la version enterprise. Cette fonction permet de faire exécuter du code sur le poste client qui peut exécuter des méthodes sur le serveur. Créer à la main une application même modeste peut vite se révéler une tâche très ardue. 4.2.6 Enterprise Toolkit Cette option n’est disponible qu’avec la version enterprise. Les éléments les plus importants de ET/400 sont :

Le tools box AS400 pour Java. La possibilité d’exporter des fichiers source et classe vers l’AS400. La possibilité de compiler, exécuter et debugger des pogrammes résidants sur l’AS400

en remplacement de QSHELL. L’assistant d’appel de programmes. Le convertisseur automatique de fichiers DSPF DDS en applications java GUI. L’assistant de création de sous fichiers en JAVA.

18 JAVA et AS400


5 WebSphere WebSphere représente un ensemble de produits IBM exploitables sur des plates-formes hétérogènes pour faciliter la construction, le déploiement, et la gestion de sites Web dynamiques. C’est à dire des sites Web qui réagissent aux informations saisies par l'utilisateur et qui sont réellement interactifs. Cela, par opposition aux sites qui affichent des pages HTML statiques contenant des images animées. Deux composants WebSphere sont pertinents pour les installations AS/400, à savoir : WebSphere Application Server AS/400 qui fonctionne conjointement avec HTTP Server for AS/400 pour offrir un environnement de travail pour les applications Web dynamiques exploitant des données DB2 WebSpbere Studio, un ensemble d'outils PC dont le but est d'aider les développeurs à concevoir des applications Websphere.

5.1 WebSphere Server Un serveur d'applications Web peut être considéré comme un «middleware Web», c'est-à-dire la couche centrale d'un environnement e-business à trois niveaux. La couche supérieure étant le serveur HTTP qui traite les demandes des browsers clients. La couche inférieure est la base de données de l'entreprise ainsi que la logique des processus mis en oeuvre d’une application de gestion de commandes par exemple). La couche centrale, le serveur d'applications, constitue une base pour établir des liens cohérents et structurés entre les requêtes HTTP et les données et la logique de l'entreprise. Plusieurs éditeurs proposent des serveurs d'applications fonctionnant sur AS/400. Ils utilisent diverses technologies, dont des servlets Java, des EJB (Entreprise JavaBeans) et XML (Extensible Markup Language). D'autres utilisent un environnement de développement propriétaire fortement intégré (modèle ASP de Microsoft). Certains exploitent des applications construites avec divers outils de développement. Pour sa part, WebSphere Application Server est un serveur de servlets Java. Une servlet est semblable à une applet Java, à la différence qu'elle s'exécute sur un serveur au lieu d'être téléchargée sur un système client. La figure ci-dessous illustre le fonctionnenient de WebSphere Application Server avec HTTP Server for AS/400 et DB2/400:

Browser

HTTPServer for AS400

WebSphere Application Server

DB2

2

3 4

5

1 6

19


1. La demande d'URL d'un utilisateur est dirigée vers HTTP Server for AS/400 2. Si la demande utilisateur inclut des informations dynamiques qui doivent être. traitées (un bulletin d'abonnement dûment rempli par exemple), elle est dirigée vers WebSphere Application Server. 3. WebSphere Application Server invoque la servlet Java appropriée pour extraire les données et construire une page Web dynamique (la confirmation de l'enregistrement de l'abonnement par exemple). 4. La servlet Java signale à WebSphere Application Server que la page Web demandée est prête à l'affichage. 5. WebSphere Application Server achemine la page ainsi créée vers HTTP Server for AS/400. 6. HTTP Server for AS/400 envoie la page Web à l'utilisateur. WebSphere Application Server est constitué par: le support de la librairie runtime Java pour les servlets Java côté serveur. Les ORB (Object Request Brokers) standards pour gérer les demandes de données et autres services des applications client/serveur. Des connecteurs performants vers plusieurs systèmes de gestion de bases de données courants afin de réduire l'effort de coding nécessaire pour lier des pages Web dynamiques aux données de l'entreprise. Des services applicatifs pour gérer les sessions et leur état. A partir de la V4R4, IBM propose deux versions de WebSphere Application Server for AS/400, l'édition standard 5769-AS1 *base inclus les fonctions décrites ci-dessus. Tandis que « l’Advanced Edition » (5769-AS1 option 1), est un produit payant qui ajoute le support des EJB. Pour avoir des informations plus récentes, consultez le site Web dédié à HTTP Server for AS/400 à l'adresse suivante: http://www.as400.ibm.com/http ou le site WebSphere à l'adresse http://wwv.software.ibm.com/webservers. A prtir de la V4R5, Une version supplémentaire est disponible : l’Enterprise edition, qui prend en charge les composants Brokers (CB) et les moniteurs transactionnels Grand systèmes comme CICS, Tuxedo, …

5.2 WebSphere Studio WebSphere Studio est une suite logicielle PC conçu pour les développeurs et les administrateurs Web. Il est constitué d'un atelier, d'assistants, et d'autres outils de développement Web permettant de construire des applications Java dynamiques fonctionnant avec WebSphere Application Server sur AS/400, S/390, AIX, Windows NT, et d'autres plates-formes. Les applications devraient également fonctionner sur les autres serveurs d'applications du marché compatibles Java. Pour plus d’informations, consultez le support de cours Websphere Studio, ainsi que le support VisualAge for RPG pour les développeurs intéressés par ce langage.

http://www.as400.ibm.com/http

http://wwv.software.ibm.com/webservers

20 JAVA et AS400


L'atelier ouvert WebSphere Studio permet aux concepteurs et aux développeurs Web d'intégrer du code HTML, des pages serveur Java (JSP), et du code de servlet Java pour construire des sites Web dynamiques. WebSphere Studio inclut des outils qui évoluent sans cesse et dont le packaging est en constant remodelage du fait de l’énorme investissement dont fait preuve IBM dans ce domaine. Il est à noter que tous ces outils sont très souvent ouverts et multi plate-formes. Pour obtenir de plus amples informations ait sujet sur l'acquisition de WebSphere Application Server et WebSphere Studio, consultez http://www.software.ibm.com/webservers .

http://www.software.ibm.com/webservers

21


6 Différences entre CGI et Servlets L'architecture des servlets Java de WebSphere offre plusieurs avantages par rapport à la programmation CGI (Common Gateway Interrace) et les macros Net.Data :

6.1 Cohérence et modularisation des composants En développant des servlets Java qui s'exécuteront sur le serveur et qui géreront le lien entre l'interface Web et les données de l'entreprise, on isole ces fonctions (composants) en un endroit unique. Cela limite l'impact que des modifications dans les données de l'entreprise ou la logique des processus mis en oeuvre peuvent avoir sur la conception du site Web et vice versa. De plus, le langage orienté objet Java ainsi que les outils de développement Web compatibles Java, tels que ceux fournis avec WebSphere Studio, favorise l'utilisation d'une structure homogène pour développer les liens entre pages Web et données d'entreprise. Certes, les développeurs CGI et NeT.Data peuvent concevoir des composants et des structures homogènes dans leurs applications. Toutefois, CGI et Net.Data n'imposent pas de le faire. Par ailleurs, CGI et Net.Data ne facilitent les choses pour les développeurs qui voudraient construire des structures homogènes.

6.2 Performances Sur la plupart des systèmes, lorsqu'un serveur HTTP lance un programme CGI, le système doit créer un processus et une structure de travail pour ce programme. Cela consomme des ressources système considérables. Sur AS/400, un pool de travaux est toujours disponible pour minimiser ce coût de mise en route. Cependant, le programme CGI demandé doit être redémarré dans le contexte de l'un de ces processus a chaque fois que le programme est lancé. Les serveurs d'applications à base de servlets Java comme WebSphere Application Server, incluent le support du runtime Java (c'est-à-dire un moteur de servlets). Aussi, lorsqu'une servlet est demandée, elle est chargée en mémoire du serveur, et elle gère les demandes subséquentes du client jusqu'à ce que le serveur soit redémarré ou qu'un administrateur la décharge. De plus, une servlet utilise généralement moins de ressources qu'un programme CGI pour interagir avec le reste des fonctions du serveur Web parce qu'il partage le même contexte de processus que ces fonctions.

6.3 Portabilité et compétences WebSphere Application Server fonctionne sur des plates-formes diverses et variées, dont l'AS/400, le S/390, AIX et Windows NT Les servlets Java développés avec WebSphere Studio ou d’autres outils fonctionnent dans les moteurs de servlets sur ces plates-formes ainsi que sur les autres. Si vous êtes éditeur, cela limite vos dépenses de développement et élargit votre marché. Si vous faites partie d'une entreprise qui possède un ensemble hétérogène de serveurs Web, vos développeurs Web peuvent passer facilement d'une plate-forme à une autre et d'un projet de développement à un autre. Vous pouvez ainsi tirer profit de la portabilité des applications et des compétences. Il est également important de noter que de nos jours, tous les cursus de formation en informatique dans les universités et les écoles professionnelles enseignent Java et non le RPG. Même si vous n'adoptez pas Java pour tout, en l'adoptant pour votre site Web, vous étendez les

22 JAVA et AS400


capacités techniques potentielles de vos ressources humaines considérablement et disposez d'une courbe d'acquisition de compétences intéressante pour votre personnel en place.

6.4 Productivité Certes, la programmation 00 et Java ont une courbe d'apprentissage escarpée pour les programmeurs formés à l'utilisation de langages procéduraux. Cependant, ceux qui adoptent cette approche devraient bénéficier de gains de productivité considérables sur le long terme. La programmation 00 encourage à construire des posants réutilisables. Par conséquent, plusieurs projets de développement devraient être capables de tirer profit de certains composants de projets antérieurs. Au fur et à mesure que le degré de pénétration de Java et l'adoption de la programmation 00 augmenteront,. vous serez capable d'acheter de plus en plus de composants réutilisables sur le marché, et de réduire d'autant la masse de travail de personnalisation à réaliser.

6.5 Jouer la multiplicité L’adoption des servlets Java tels que celles que l’on peut écrire et utiliser avec WebSphere ne doit pas être une décision de type tout ou rien. On peut utiliser plusieurs serveurs Web si on a des applications différentes utilisant différents serveurs Web : HTTP Server, Lotus Domino, Commerce Server/400 de I/Net par exemple, ou, dans un futur proche, Apache, le serveur de Netscape porté sur AS/400). On peut servir des pages Web de WebSphere Application Server, des applications collaboratives et de workflow Domino, et des pages Web qui lancent des programmes CGI à pari d'un serveur HTTP d'IBM ou d'I/Net ou d’autres plates-formes. Avec l'AS/400, on peut rendre ces opérations complètement invisibles aux visiteurs Web. Au fur et à mesure que l'on développe des applications Web, on peut choisir les outils et l'environnement qui conviennent le mieux, d'une part aux besoins de l'application et d'autre part aux compétences et à la formation de l'équipe de développement.

23


7 Ressources et sources d’informations

7.1 Sites Web Javasoft : http://www.javasoft.com Sun : http://sun.com/java/

AS400 Information Center : http://service2.boulder.ibm.com/as400/iceng/infocent.htm IBM Java AS400 : http://as400.rochester.ibm.com/java/javahome.htm Websphere : http://as400.rochester.ibm.com/tstudio/websphere/ Docs techniques : http://publib.boulder.ibm.com/pubs/html/as400/online/homeeng1.htm Redbooks : http://www.redbooks.ibm.com

7.2 Resources internes Documentations sur HTML : Jupiter\Qibm\JavaRsc\DocWeb JDK 1.1.7 de Sun : Jupiter\Qibm\JavaRsc\SunJdk117 JDK 1.2 de Sun : Jupiter\Qibm\JavaRsc\SunJdk12 JSDK 2 de Sun : Jupiter\Qibm\JavaRsc\SunJdk12 Voice Kit IBM : Jupiter\Qibm\JavaRsc\VoiceKit WebSphere Serveur : Jupiter\Qibm\ProdData\IBMWebAS\doc\index.html Jupiter\Qibm\ProdData\IBMWebAS\web\admin\index.html Servlet Express 1.0 : Jupiter\Qibm\ProdData\HTTP\Protect\ServExp\Html\MRI2928\jst\system\index.html

Jupiter\Qibm\ProdData\HTTP\Protect\ServExp\Html\MRI2928\src\doc\index.html VisualAge : Jupiter\Qibm\JavaRsc\VisualAge

http://www.javasoft.com/

http://sun.com/java/

http://service2.boulder.ibm.com/as400/iceng/infocent.htm

http://as400.rochester.ibm.com/java/javahome.htm

http://as400.rochester.ibm.com/tstudio/websphere/

http://publib.boulder.ibm.com/pubs/html/as400/online/homeeng1.htm

http://www.redbooks.ibm.com/

développer des applications avec ou pour...

Documents