Dévlopper les application avec et/ou pour l`as400

Transcription

JAVA et AS400
Développer des applications
Avec ou pour l’AS400
Auteur : Dominique Vignez
© Institut de Poly-informatique (1999)
JAVAAs400.doc 10/07/01 10:07 version 25
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
JAVAAs400.doc 10/07/01 10:07 version 25
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.
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).
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.
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).
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
Binaire 2 octets
Binaire 4 octets
Caractère
Date
Flotant 4 octets
Flotant 8 octets
Hexadécimal
Décimal packé
Decimal zone
Time
Timestamp
Type Java
Short
Integer
String
String
Float
Double
Byte
Big decimal
Big decimal
String
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
4 L’interpréteur QSHELL
4.1 Commandes OS400 liées à Java
Commande
CRTJVAPGM
Description
Crée un programme Java
Commentaires
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 Indique si un DEO existe et quel est
programme Java
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 Configuration des bases locales et
base de données relationnelle
distantes
L’interpréteur QSHELL offre une interface de travail un peu surprenante pour les habitués de
l’interface 5250.
QSH Command Entry
$
===> ________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
F3=Exit F6=Print F9=Retrieve F12=Disconnect
F13=Clear F17=Top F18=Bottom F21=CL command entry
16
JAVA et AS400
Un certain nombre de commandes de type Unix sont disponibles dans cet environnement de
travail :
alias
unalias
mv
cp
ls
mkdir
rm
rmdir
chmod
ln
find
cc
system
cat
grep
export
crée un raccourci pour des noms longs
supprime un raccouci
Move
déplace un fichier dans l’IFS
Copy
copie un fichier dans l’IFS
Liste
liste le contenu d’un directory de l’IFS
Make Dir
créé un directory dans l’IFS
Remove
supprime un ou plusieurs fichiers dans l’IFS
Remove Dir supprime un ou plusieurs directories dans l’IFS
CHGAUT
modifie les droits d’accès à un fichier de l’IFS
Link
créé un nouveau lien sur un fichier ou un directory existant
Find
recherche un un fichier dans l’IFS
Compile C
compile un source en langage C
exécute une commande OS400
lit et écrit le contenu d’un fichier sur la sortie standard
cherche des caînes dans des fichiers de l’IFS
exporte une variable d’environnement
javac
java
appletviewer
rmic
rmiregistery
jar
javakey
créé une classe, un fichier .class à partir d’un source .java
exécute un fichier classe avec la JVM
exécute une classe comme une applet (uniquement avec RAWT)
créé et compile des fichiers squelettes de classe et des stubs en aide à RMI
piste des objets éloignés et permet aux clients de les localiser (RMI)
créé un fichier archive .jar
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
1
6
HTTPServer for AS400
2
5
WebSphere Application Server
3
4
DB2
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.
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 .
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 :
JDK 1.1.7 de Sun :
JDK 1.2 de Sun :
JSDK 2 de Sun :
Voice Kit IBM :
WebSphere Serveur :
Jupiter\Qibm\JavaRsc\DocWeb
Jupiter\Qibm\JavaRsc\SunJdk117
Jupiter\Qibm\JavaRsc\VoiceKit
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

Dévlopper les application avec et/ou pour l`as400

Transcription

Documents pareils

Expérience

Lexique Java EE

Remplacement d`un Serveur IBM AS 400

Julien Kronegg - Log(psycho)Analyst

CREER DES EXERCICES INTERACTIFS à partir de sa clé USB

clin Silverwood - sapin autoclavé pré-grisé

CV Vincent GENAUD

comment faire de l`optique avec une ressource numerique

CV - WordPress.com

ROUBEYRIE Olivier

SERVLET TP 1 Installation du JDK Installation de Glassfish