Discussion :

[ego]

Bonjour,

avez-vous déjà utilisé les appels de code Java depuis Cobol sous MVS ?
Plusieurs questions ici :

1- Est-ce que cela fonctionne ? (oui/non)
a- Si le code Java hébergé dans un Websphere sous Z/Linux
b- Si le code Java hébergé dans un Websphere sous un Unix or mainframe

2- Avez-vous constaté des restrictions majeures en termes de typage des données passées ?

3- Si l'appel est réalisé au sein d'une transaction IMS, et que le code Java appelé est un (ou plusieurs) EJB sous Websphere, est-ce que tout se passe bien si la transaction est "rollbackée" soit du fait du code Java soit du fait du code Cobol ?

4- Avez-vous constaté des dégradations de performances par rapport à des appels Cobol - Cobol qui soient finalement inacceptable pour rendre la solution viable ?

5 Enfin, si vous avez utilisé les appels Cobol vers Java, était-ce en environnement transactionnel ou en environnement Batch ?

Par avance merci pour tout retour d'expérience

[el_slapper]

tout ce que je sais, c'est que du JAVA sous unix peut appeler du Cobol/CICS sous Z/OS . Mais je ne bossais pas là-dessus, et j'ai quitté cette boite en mauvais termes.

[rberthou]

J'ai réalisé ce type de projet il y a quelque temps (plus 8 ans déjà) je fonctionnais à l'époque avec CICS mais en mode asynchrone .

--> 1er cas : Appel lancé par CICS via une queue (ou connexion socket je sais plus exactement). Traitement de la demande dans la JVM de l OS-390 .

--> 2nd cas : demande faite via une application "open" client lourd windows par connexion socket vers le serveur de traitement renvoyant la demande a CICS en utilisant CTG .

1 - Dans les deux cas j'étais hors WAS, les choix d'une JVM sur le mainframe etais principalement du à une "proximité" réseaux et un temps d'arrêt identique.

2 - Je n'ai eu aucun problème de typage de données (mais je travaillais avec des zones relativement simples.) .

3 - Problème de cohérence cobol / java non pris en compte du fait du fonctionnement volontairement asynchrone .

4 - Pas de probleme de perf (lissage de la charge avec le fonctionnement asynchrone)

5 - Utilisé avec CICS


J'espère avoir été clair...

[Peut-êtreUneRéponse]

Bonjour,

En ce qui concerne les clients pour lesquels j'ai eu affaire à java/cobol (et c'est actuellement le cas), java est relégué à la couche présentation.

A noter que dans cette configuration là, l'architecture utilisée implémente un sous-ensemble de la plateforme J2EE. C'est une architecture hybride car elle comporte aussi du code non-Java (cf. couche service)

En détail, elle se compose comme suit :

- La Couche Présentation de type client léger, respecte le modèle de programmation MVC via le framework Struts. Les écrans sont au format HTML avec JavaScript. Les vues sont des JSP. L’accès à la couche Service se fait via les connecteurs WSIF-JCA. Le serveur d’applications est WebSphere sous z/OS.

- La Couche Service est implémentée par des services métier CICS et IMS écrits en Cobol. Ils interagissent avec la couche stockage au travers d'Embedded SQL. La transaction est sous le contrôle du moniteur transactionnel CICS ou IMS.

- La Couche Stockage : DB2 z/OS.

Les batchs sont écrits en Cobol avec Embedded SQL.

Au niveau typage des données aucun problème les services métier adapte les types pour obtenir en zone de communication quelque chose d'exploitable pour java.

D'une manière générale, cela fonctionne très bien.

.

[ego]

merci à vous