Discussion :

[pascalmagna]

Bonjour,

Je souhaiterais avoir la confirmation (via la doc d'ibm serait l'idéal) de l'espace mémoire maximum qui peut transiter dans une zone de communication entre un programme principal et un sous programme en mode batch.
On m'évoque une limite à 32 ko sauf qu'en déclarant plus je n'ai pas de problème ni à la compil ni à l'execution, donc est-ce une limite au dela de laquelle il n 'y a plus de garantie de conservation des données ? ou est-ce une limite qui n'existe plus ?
De plus peut on me confirmer (via la doc d'ibm serait l'idéal) que l'appel d'un programme en dynamique permet la conservation des données en working storage.

Merci par avance pour tout.

[Luc Orient]

Quel langage et quelle version de compilateur ?

[pascalmagna]

Bonjour effectivement j'ai été un peu léger en info ... programmation cobol version 3.4.1 sur ZOS 1.9. Par contre la version du compilateur ?
Si cela est toujours intéressant et si tu me dis où je peux trouver l'info j'irai la chercher.

Merci par avance.

[bernard59139]

Bonjour
A ce genre de question, je répond "ca dépend".
Et "ca dépend c'est trop long"

Plus sérieusement, regarde ces liens
ws et addressabilite

données et partage

[xfanx]

bonjour , ici tu parles de Linkage entre programmes , le programme appelant passe à l'appelé une adresse (en by reference biensur), la taille limite de ta linkage,(plutot des niveaux 01 de ta linkage) est en fait la taille limite acceptée par le compilateur sur les niveau 01 de la working du programme appelant.

je n'ai plus les chiffres en tête, je t'invite à regarder dans le programing Guide de la version de ton compilateur Cobol, mais avec les derniers compilateurs cobol for enterprise on atteint largement plusieurs mega sur un niveau 01, en tout cas aucune limite à 32k.

[Luc Orient]

Enterprise COBOL for z/OS v3.4

Limite de la Linkage Section :
134 213 631 octets.

Source :
Enterprise COBOL for z/OS V3.4 Langage Reference - Appendix B Compiler limits

[pascalmagna]

Bonjour,

Merci pour toutes ces réponses qui confirment ce que je pensais.

Par contre je ne dois pas être doué et mon anglais limité car je n'arrive pas à obtenir la réponse sur la deuxième question : est ce qu'un appel à un sous programme (tout en cobol) en dynamique permet à ce sous programme de garder en mémoire proprement (working storage) les valeurs obtenues au précédent appel.

[xfanx]

bonjour,

alors... ça dépend.. en général oui, sauf si
1 - tu as mis un INITIAL dans le programme appelé
2 - si entre l'appelant et l'appelé un programme non conforme LE est exécuté. (PG1 call PG no LE call PG2);
ou plus généralement, tant que tes 2 programmes tournent dans la même enclave LE et que l'enclave n'est pas "cassée' normalement tu conserves tes valeurs en working)
3 -si l'appelant fait un CANCEL de l'appelé

[pascalmagna]

Alors là tu me parles chinois !!!

Déja je ne connais les ordres INITIAL/CANCEL (non utilisé chez nous) mais si effectivement il a pour but d'initialiser le contenu de la working effectivement sont contenu n'est plus accessible ...

Ensuite et surtout comment un des programmes cobol peut ne pas être LE conforme ?
Qu'est ce qu'une enclave LE et comment/par qui peut elle être cassée ?

Merci par avance de tes réponses et de l'intéterêt porté à mon problème.

[xfanx]

bonjour,

tu trouveras les principes LE ici
http://publib.boulder.ibm.com/infoce...appldev_91.htm

un programme Cobol sera toujours LE sauf s'il a été compilé avec le vieux compilateur Cobol OS/VS ou les 1ere versions du COBOL II (on le repère avec les routines de type ILBO quand tu browse le load module). mais bon ça m'étonnerait qu'il en reste encore..
un non conforme LE ce sera plutot un programme Assembleur (ou on n'a pas inclus les macro CEEBENTRY ce qui est souvent le cas) ou un METAL C/C++.

Pour résumer Le cassage d'une enclave LE, ça arrive surtout avec Cobol. Une enclave LE est initié à l'exécution d'un 1er COBOL dans un Run, si un des autres programmes dans cette enclave appelle un programme non LE qui lui même appelle un Cobol, alors une seconde enclave sera créé parce que cobol considéra ce cobol comme un Main. c'est très très mauvais pour les performances puisque si en plus c'est en boucle beaucoup d'allocation/free mémoire sont faites a chaque fois.. ce n'est qu'un résumé, pour plus de détails et compléments tu peux consulter toutes la documentation LE qui aujourd'hui est très complète à partir du lien que je t'ai donné

[pascalmagna]

Merci bien pour ce complément d'info qui me suffit largement.

Dorénavant il vaut meiux que passe par ce site que par ma filière officielle.