java et vitesse de traitement

Bonjour,

Je voudrais avoir des avis de gens ayant l'expérience de Java, RPG et/ou COBOL sur AS400, enfin Power-I.

Je travaille dans une entreprise dont l'applicatif général (en fait des dizaines voire des centaines de modules) sont répartis soit sur PC, soit sur OS400. En fait, toutes les données de la DB de production sont dans la DB2/400. Les programmes se répartissent en deux classes :
- sur le mainframe les traitements qui manipulent beaucoup de données (beaucoup : des millions de records);
- sur le PC (pgm Delphi avec lecture directe de la DB2/400 grâce à Delphi/400) quand il s'agit de traiter moins de données (quelques dizaines de milliers), de faire des IHM ou de la bureautique.

Ma question porte en réalité sur les performances comparées entre Java et COBOL (ou RPG, peu importe). J'ai l'intuition qu'elles ne peuvent pas être du même ordre.
Autrement dit, imaginons un programme simpliste qui :
- balaie une vue logique de 3 millions de lignes;
- pour chaque ligne, va chercher des informations diverses dans trois ou quatre autres tables,
- fait pas mal de COMPUTE (calculs actuariels),
- puis fait un REWRITE de l'article et passe au suivant.
En fait, c'est ce que font la plupart de nos programmes 400.

Et la question est : Est-ce que Java va aller aussi vite que COBOL ou RPG ?

Merci d'avance de vos réponses.

Paul Rambeaux

Bonjour,

Je dirais qu'il n'y aura pas photo. Les RPG/Cobol iront beaucoup plus vite que Java. Et de plus consommeront bien moins de ressources (CPU / Mémoire).
De notre côté, nous sommes un peu dans le même cas. Nous avons commencé (c'est un long travail de développement), à basculer vers du VB .net. On aurait pu le faire avec d'autres langages disponibles dans Visual Studio, notre choix de VB est du aux compétences internes.

Pour tout ce qui est interface, on se régale par rapport à la vieille interface "verte" (5250).
Mais quid du traitement BD ?
On a séparé 2 types de traitements :

• Les traitements interface à proprement parler. L'équivalent des anciens interactifs.
  On utilise le pilote .net de DB2 directement dans notre code VB. Et les performances sont très correctes.
  Je pense qu'avec Java tu obtiendras quelque chose de plus lent, mais acceptable.
• Les traitements lourds, ne nécessitant pas d'interface. Les anciens batchs.
  Là on crée des procédures SQL. Que ce soit en SQL pur quand le traitement peut en profiter, ou en RPGLE voire SQLRPGLE quand la complexité nécessite une approche plus "programme".

En utilisant des procédures SQL pour les traitements batch, on évite pas mal d'inconvénients du langage de développement habituel (VB.net pour nous ou Java ).
Alors je serai toi, je ne me poserai pas la question.
Utilise Java pour ce qu'il sait faire, mais pas pour les traitements lourds de BD (sauf si çà passe dans quelques requêtes SQL qui seront traitées directement sur le serveur bien entendu).
Les procédures SQL sont là pour çà.

Bonjour,

RPG et COBOL sont des langage qui sont très proche du langage machine de l'IBM i, tandis que JAVA est un langage interprété.
Et comme le dit m4k-Hurrican, RPG et COBOL seront plus rapide, de plus, l'accès à la DB est instantanné, pas de drivers ou autre.

Par contre, en ayant fait l'expérience, pour la saisie, un programme sur l'IBM i (bien pensé) sera toujours plus rapide que sur d'autres interfaces.

Larry57

Citation:

---

Envoyé par larry57

Par contre, en ayant fait l'expérience, pour la saisie, un programme sur l'IBM i (bien pensé) sera toujours plus rapide que sur d'autres interfaces.

Larry57

---

Oui, mais non.
Le problème est qu'à de rares exceptions près, les écrans verts sont absolument inutilisables de nos jours. Même pour de la saisie simple.
Écrans trop petits pour afficher toutes les informations, problèmes d'encodage (en particulier lors de copier/coller), pas de réactivité immédiate à la saisie, pas de mise à jour temps réel des champs, pas d'affichage graphique, de glisser/déposer, etc...
Prenons l'exemple d'un simple devis, le saisir sur la vieille interface permet d'aller vite sur le texte brut. Mais si on veut pouvoir y joindre des pdf, faire un peu de mise en page, çà oblige à des exercices qui alourdissent le traitement, et font donc perdre du temps.
Alors ne parlons même pas de coller un texte issu d'une page web, une image, ou autre.

IBM n'a pas fait ce qu'il fallait à l'époque ou VisualAgeRPG existait.
Ils ont coupé l'herbe sous le pied de l'équipe qui développait cet outil (j'étais en contact avec eux car on misait beaucoup sur VARPG), en refusant qu'ils évoluent au niveau du compilateur C++. Le leur était buggué...
Quel beau gâchis, même s'il y avait encore beaucoup de travail (bugs, simplification, accès SQL sans avoir à installer DB2 Windows, éditeur source, etc...)

Bref, le sujet n'est pas là. Java a ses qualités, mais la vitesse justement, n'en fait pas partie.
Reste que comme indiqué, il faudrait peut être envisager une approche SQL pure. S'il y a de la mise à jour de masse, que les calculs peuvent être fait dans la ou les requête(s) SQL et qu'elle est facilement applicable d'un point de vue chemin d'accès, il y a peut être à gagner à ce niveau.
J'ai un exemple en tête chez nous, où la mise à jour prenait 2 mn environ avec le traitement RPG, et dure environ 10s désormais !

Bonjour,

Ayant fait du Java, la programmation de choses simples est d'une complexité ahurissante.
De plus, les mises à jour de Java quotidienne, les fonctions qui deviennent obsolètes d'un jour à l'autre...

Larry57