Discussion :

[turcotm]

Bonjour,


J'essaye de comprendre la différence entre la commarea et les TS (transaction storage). J'ai cherché sur internet et je n'ai pas vraiment trouvé.

Suis-je obligé d'utiliser les TS et quel est l'avantage par rapport au commarea?

Merci


Michel

[Hédhili Jaïdane]

Bonjour.

Je pense que cette question serait mieux dans le forum z/OS si elle n'a pas de rapport direct avec Cobol.

[el_slapper]

En fait, c'est du CICS, pas du Z/OS. CICS généralement associé à COBOL.....

Bon, j'y connais pas tant que ça, mais la COMMAREA, a priori, c'est l'équivalent de la linkage en Cobol. La TS, c'est un stockage de données que l'on garde d'écrans en écrans au fur et à mesure que se déroule la transaction. La commarea servira surtout pour les modules annexes(mais pas seulement), alors que la TS sera commune à tous les programmes écrans. Sur une transaction de création de contrat, la TS comprendra l'ensemble des données du contrat, enrichies au fur et à mesure, par exemple. Là ou la commarea ne contiendra que des données spécifiques au programme.

[turcotm]

Bonjour.

Je pense que cette question serait mieux dans le forum z/OS si elle n'a pas de rapport direct avec Cobol.

Ha ben je peut t'assurer que c'est du COBOL sous Z/OS certe mais COBOL. Car cela a rapport avec des crants interactif.

En fait, c'est du CICS, pas du Z/OS. CICS généralement associé à COBOL.....

Bon, j'y connais pas tant que ça, mais la COMMAREA, a priori, c'est l'équivalent de la linkage en Cobol. La TS, c'est un stockage de données que l'on garde d'écrans en écrans au fur et à mesure que se déroule la transaction. La commarea servira surtout pour les modules annexes(mais pas seulement), alors que la TS sera commune à tous les programmes écrans. Sur une transaction de création de contrat, la TS comprendra l'ensemble des données du contrat, enrichies au fur et à mesure, par exemple. Là ou la commarea ne contiendra que des données spécifiques au programme.

Donc si j'ai une seul écrant, je n'ai pas besoin de TS. Je vais utiliser le commarea pour les "CICS LINK" a d'autre programme? Pour les deuxièmes appels a lui même, je devrait utiliser les TS ou je ré allimentes mes zones.?

Si c'est ca, je comprend mieux la différence.

Merci el_slapper

[Hédhili Jaïdane]

En fait, c'est du CICS, pas du Z/OS. CICS généralement associé à COBOL.....

.

Ha ben je peut t'assurer que c'est du COBOL sous Z/OS certe mais COBOL. Car cela a rapport avec des crants interactif.
...

.

Vous faites bien de me le rappeler, désolé pour cet oubli. J'ai comme un grand trou de 5 ans dans ma vie professionnelle. Pour info j'ai commencé par l'ELS et j'ai terminé par le FULL, ça vous dit quelque chose ?

Allez salut et bonne continuation.

[Luc Orient]

En fait, c'est du CICS, pas du Z/OS ...

Pour moi, CICS tourne principalement sous z/OS ...

[Homer-ac]

Pour revenir à la question de base, on parle bien de COBOL mais de techniques de programmation spécifiques à CICS, donc effectivement sous z/OS.
Comme l'on fait des EXEC SQL pour DB2, la compilation d'un COBOL CICS passera par l'appel du précompilateur CICS pour traduire les ordres EXEC CICS en ordres, CALL notamment reconnus par le compilateur COBOL.
S'agissant de techniques de programmation, l'utilisation d'une commarea comme zone de communication pourra en fonction de besoins fonctionnels être complétée par l'utilisation de TS qui représentent en fait des segments mémoires accessibles à tout programme s'exécutant sous CICS.

- La commarea tout d'abord.
C'est la zone de communication que l'on passe pour appeler un programme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
           EXEC CICS LINK                
                     PROGRAM  (WS-MYPGM) 
                     COMMAREA (WS-COMMAREA)
                     LENGTH   (length of WS-COMMAREA)   
                     RESP     (WS-CICS-RESP) 
           END-EXEC.

ou une transaction :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
   
           EXEC CICS RETURN                                         
                     TRANSID  (WS-TRANSID)       
                     COMMAREA (WS-COMMAREA)     
                     LENGTH   (length of WS-COMMAREA)  
           END-EXEC.

Le précompilateur va ajouter un using de deux groupes dans la procédure division, donc 2 niveaux 01 déclarés en Linkage Section.
Un 01 DFHCOMMAREA, en géneral suivi d'une copy COBOL pour détail des données fonctionnelles contenues. Le second, ajouté par le pré-compilateur CICS est un bloc EIB, alimenté par CICS qui contient un certain nombre d'informations de gestion CICS qui pourront être ensuite utilisées par le programme.
EIBCALEN en particulier qui permet de connaitre la taille de la COMMAREA reçue, souvent utilisé en programmation pseudo conversationnelle pour savoir si on est en premier appel ou non (EIBCALEN = ou > 0).
EIBTRMID et EIBTRNID également, qui permettent de connaître le code transaction el le terminal d'exécution, couple souvent utilisé comme identifiant constitutif du nom d'une TS.

- La TS ensuite.
Il s'agit de blocs de mémoire dont la création à été demandée à CICS exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
  
           EXEC CICS WRITEQ TS  QUEUE (WS-TS-NOM)               
                                FROM (WS-TS-DATA)               
                                LENGTH (WS-TS-LENGTH)          
           END-EXEC.

L'intérêt fonctionnel :
- La TS crée sera accessible par tout programme s'exécutant dans le CICS. A commencer par le test d'un code retour au READQ TS
(l'info d'existance ou pas d'une TS peut également être une information de gestion utile)
- On peut créer des TS à ITEM que l'on peut voir comme autant d'enregistrements (en mémoire) de communication.

Bien entendu si la logique des TS à un intérêt fonctionnel évident pour stoquer des informations en mémoire donc plus performant que des accès fichiers, la multiplication de ces TS en mémoire virtuelle accessible par CICS finira par se faire au détriment du reste de ce qui devra être chargé en mémoire par CICS, à commencer par le code d'exécution des programmes et leurs différentes Working Storage Section utilisées, chargées distinctement en mémoire virtuelle.
Il faudra donc fonctionnellement éviter les TS à ralonge inutiles et penser à faire un EXEC CICS DELETQ des TS dont on n'a plus besoin. Souvent sur les sites les gestionnaires CICS ont mis en place des outils pout éviter cette inflation. Par exemple delete de toutes les TS dont le nom comporte un indentifiant terminal qui n'est plus connecté.
L'autre inconvénient est qu'en cas d'arrêt/relance d'un CICS, les TS sont perdues puisque c'est de la mémire CICS.

[rberthou]

J'essaye de comprendre la différence entre la commarea et les TS (transaction storage). J'ai cherché sur internet et je n'ai pas vraiment trouvé.

commarea : Cela peut etre vu comme un espace mémoire partagé entre plusieurs transactions appartenant a la même session (meme terminal ou client).

TS : C'est un "fichier temporaire", pas spécialement associé a la session (bien que dans la pratique on inclut souvent le nom du terminal dans son ID). Historiquement j'ai principalement vu l'utilisation de TS pour réaliser des paginations.

[FloGuizmo]

Une Commarea (zone de communication) est une "zone de passage" entre 2 programmes cobol-cics.
Une TS (Tempory Storage) est, comme le dit rberthou, est un fichier temporaire permettant de stocker des informations. Cela peut servir, effectivement pour la pagination, mais également pour véhiculer des infos tout au long d'une transaction.

[fremen167]

Salut,

La principale différence tient au fait que la commarea est immédiatement accessible par le programme, puisqu'elle est transmise lors de l'appel LINK ou RETURN TRANSID (cf. message de Homer-ac).

Pour accéder à la TS, il faut connaître son identifiant, qui est souvent transmis... dans la commarea.

En pratique, le nom de la TS est souvent normalisé : TRANSID + TERMID (donc dans ce cas, le programme peut trouver "tout seul" le nom de la TS), mais il peut y avoir besoin de plus d'une TS, et là, c'est en commarea que l'on stocke le nom des TS utilisées. De même, lors du chaînage entre plusieurs codes transaction, le TRANSID change, donc le passage du nom des TS en commarea devient indispensable.

D'après mon expérience, on utilise une TS quand la commarea ne permet pas de stocker suffisamment d'informations. En effet, la commarea est limitée en taille (de mémoire, 32 K).

Elle permet de plus de gérer simplement une pagination dans un écran de type liste, en stockant par exemple les données d'une page par item.

Typiquement, pour afficher la page n, on lit l'item n de la TS dans une zone de working banalisée, puis on met en forme l'écran à partir de cette zone.

Une dernière remarque, par rapport à la réponse de Homer-ac : le contenu des TS est perdu lors de l'arrêt relance, c'est vrai, mais c'est la même chose pour une commarea, donc ça ne constitue pas une différence entre ces deux moyen de faire passer de l'info entre deux programmes CICS (ou entre deux exécutions d'un même programme).

[Homer-ac]

le contenu des TS est perdu lors de l'arrêt relance

Cette remarque était simplement pour insister sur le fait que ce n'est pas sous prétexte que l'on fait des EXEC CICS READ ou WRITE TS qu'il fallait en déduire que l'on écrivait des données permanentes.

[fremen167]

Ah OK... je n'avais pas compris où tu voulais en venir

[turcotm]

Pour revenir à la question de base, on parle bien de COBOL mais de techniques de programmation spécifiques à CICS, donc effectivement sous z/OS.
Comme l'on fait des EXEC SQL pour DB2, la compilation d'un COBOL CICS passera par l'appel du précompilateur CICS pour traduire les ordres EXEC CICS en ordres, CALL notamment reconnus par le compilateur COBOL.
S'agissant de techniques de programmation, l'utilisation d'une commarea comme zone de communication pourra en fonction de besoins fonctionnels être complétée par l'utilisation de TS qui représentent en fait des segments mémoires accessibles à tout programme s'exécutant sous CICS.

- La commarea tout d'abord.
C'est la zone de communication que l'on passe pour appeler un programme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
           EXEC CICS LINK                
                     PROGRAM  (WS-MYPGM) 
                     COMMAREA (WS-COMMAREA)
                     LENGTH   (length of WS-COMMAREA)   
                     RESP     (WS-CICS-RESP) 
           END-EXEC.

ou une transaction :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
   
           EXEC CICS RETURN                                         
                     TRANSID  (WS-TRANSID)       
                     COMMAREA (WS-COMMAREA)     
                     LENGTH   (length of WS-COMMAREA)  
           END-EXEC.

Le précompilateur va ajouter un using de deux groupes dans la procédure division, donc 2 niveaux 01 déclarés en Linkage Section.
Un 01 DFHCOMMAREA, en géneral suivi d'une copy COBOL pour détail des données fonctionnelles contenues. Le second, ajouté par le pré-compilateur CICS est un bloc EIB, alimenté par CICS qui contient un certain nombre d'informations de gestion CICS qui pourront être ensuite utilisées par le programme.
EIBCALEN en particulier qui permet de connaitre la taille de la COMMAREA reçue, souvent utilisé en programmation pseudo conversationnelle pour savoir si on est en premier appel ou non (EIBCALEN = ou > 0).
EIBTRMID et EIBTRNID également, qui permettent de connaître le code transaction el le terminal d'exécution, couple souvent utilisé comme identifiant constitutif du nom d'une TS.

- La TS ensuite.
Il s'agit de blocs de mémoire dont la création à été demandée à CICS exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
  
           EXEC CICS WRITEQ TS  QUEUE (WS-TS-NOM)               
                                FROM (WS-TS-DATA)               
                                LENGTH (WS-TS-LENGTH)          
           END-EXEC.

L'intérêt fonctionnel :
- La TS crée sera accessible par tout programme s'exécutant dans le CICS. A commencer par le test d'un code retour au READQ TS
(l'info d'existance ou pas d'une TS peut également être une information de gestion utile)
- On peut créer des TS à ITEM que l'on peut voir comme autant d'enregistrements (en mémoire) de communication.

Bien entendu si la logique des TS à un intérêt fonctionnel évident pour stoquer des informations en mémoire donc plus performant que des accès fichiers, la multiplication de ces TS en mémoire virtuelle accessible par CICS finira par se faire au détriment du reste de ce qui devra être chargé en mémoire par CICS, à commencer par le code d'exécution des programmes et leurs différentes Working Storage Section utilisées, chargées distinctement en mémoire virtuelle.
Il faudra donc fonctionnellement éviter les TS à ralonge inutiles et penser à faire un EXEC CICS DELETQ des TS dont on n'a plus besoin. Souvent sur les sites les gestionnaires CICS ont mis en place des outils pout éviter cette inflation. Par exemple delete de toutes les TS dont le nom comporte un indentifiant terminal qui n'est plus connecté.
L'autre inconvénient est qu'en cas d'arrêt/relance d'un CICS, les TS sont perdues puisque c'est de la mémire CICS.

commarea : Cela peut etre vu comme un espace mémoire partagé entre plusieurs transactions appartenant a la même session (meme terminal ou client).

TS : C'est un "fichier temporaire", pas spécialement associé a la session (bien que dans la pratique on inclut souvent le nom du terminal dans son ID). Historiquement j'ai principalement vu l'utilisation de TS pour réaliser des paginations.

Une Commarea (zone de communication) est une "zone de passage" entre 2 programmes cobol-cics.
Une TS (Tempory Storage) est, comme le dit rberthou, est un fichier temporaire permettant de stocker des informations. Cela peut servir, effectivement pour la pagination, mais également pour véhiculer des infos tout au long d'une transaction.

Merci les gars

Donc pour les zones output (dans le send map) on dois les garder dans une dfhcommarea pour utilisation apres un receive map comme les zones input.

Pour le passage a une autre transaction, on peut utiliser un dfhcommarea ou une ts qui est plus pratique surtout si les informations son volumineuse.

ps: Belle discution pour aider ceux qui code pas souvent en cobol/cics...

@+

Michel

[fremen167]

Salut,

Donc pour les zones output (dans le send map) on dois les garder dans une dfhcommarea pour utilisation apres un receive map comme les zones input.

Je ne suis pas sûr de bien comprendre ce que tu écris là.

Tout d'abord, il ne faut pas perdre de vue que les "zones output" (zones de la map suffixées par "O", style "NOMO", "PRENOMO") sont physiquement les mêmes que les zones d'input correspondantes (suffixées en "I"). C'est un REDEFINES dans ta WORKING.

De plus, la sauvegarde ou non des zones écran en COMMAREA dépend du traitement. Par exemple, dans un écran de consultation type "mono-entité", est-il toujours utile de conserver les zones affichées ? J'aurais tendance à le faire (pour gérer plus facilement les enchaînements d'écrans), mais ce n'est pas obligatoire, puisque le RECEIVE MAP peut te les restituer.

Enfin, on n'utilisera pas "une" DFHCOMMAREA mais "LA" DFHCOMMAREA (c'est la zone confiée à CICS entre deux exécutions), alors qu'il peut y avoir plusieurs TS.

Pour le passage a une autre transaction, on peut utiliser un dfhcommarea ou une ts qui est plus pratique surtout si les informations son volumineuse.

Non, je dirais que la COMMAREA est plus pratique (pas nécessaire de faire de lecture / écriture, c'est juste dans le codage des EXEC CICS que tu transmets les infos, via la COMMAREA). Mais la TS est bien adapté aux paginations, et nécessaire au delà d'un certain volume de données.

De plus, la TS est également employée au sein d'une même transaction (toujours selon les mêmes critères).