Discussion :

[faluma]

Bonjour,

Quelqu'un pourrait-il m'aider à comprendre l'abend suivant :

CEE3204S The system detected a protection exception (System Completion Code=0C4). From compile unit Program1 at entry point Program1 at compile unit offset +00002698 at entry offset +00002698 at address 113DA118.

Merci...

[Hédhili Jaïdane]

Bonjour,

Quelqu'un pourrait-il m'aider à comprendre l'abend suivant :

CEE3204S The system detected a protection exception (System Completion Code=0C4). From compile unit Program1 at entry point Program1 at compile unit offset +00002698 at entry offset +00002698 at address 113DA118.

Merci...

Bonjour faluma.

- Quel OS ?
- A la compilation ou l'exécution ?

[faluma]

Bonjour faluma.

- Quel OS ?
- A la compilation ou l'exécution ?

- Z/OS
- A l'exécution du programme

[el_slapper]

0C4

hehehehe, un grand classique avec le 0C7. L'origine de ces 2-là est en général la même : un décalage de données à l'execution. 0C4 fait que des données se retrouvent en dehors de la plage prévue. 0C7 fait que l'on fait des opérations numérique dans un champ non rempli par du numérique.

Dans les 2 cas : regarder les formats de données, les comparer, vérifier l'absence d'erreur, et au besoin, faire des display partout dans le programme(en dichotomie) pour trouver l'opération(pour un 0C4, ça sera sans doute un MOVE) ou ça plante. Puis regarder le format de la donnée en entrée, celle de la donnée en sortie.....ça resoud 99% des problèmes de ce genre. C'est parfois long(ça dépend de la taille du programme), fastidieux, mais en général pas trop difficille.

[Pico-----]

0C4

hehehehe, un grand classique avec le 0C7.

+1

Par contre, pour moi, le 0C4 c'est une tentative d'accès à une partie de la méméoire non autorisée : les cas les plus courants sont le dépassement d'indices sur un tableau (et en cobol on commence à 1 donc, le 0 est un dépassement xD ) ou alors tentative de de lecture ou ecriture sur un fichier non ouvert (soit pas encore ouvert ou déjà fermé ...)
Donc je conseille de vérifier tous les parcours d'occurs surtout si il y en a dans des boucles (perform varying ... récursion ... ) et les appels d'I/O.

[Hédhili Jaïdane]

Mes souvenirs des mainframes sont assez lointains, mais si vous parlez de "tentative d'accès à une partie de la méméoire non autorisée", il peut s'agir d'un mauvais facteur de blockage d'un fichier (s'il a toujours droit de cité).

[fremen167]

A mon avis, la piste la plus probable est celle du tableau. L'indice 0 a peu de chance de donner ce code, car il faudrait que le tableau soit la première zone de WS, ou bien qu'un poste du tableau soit très gros (plus gros que les zones définies avant lui). Par contre, un fin de boucle mal gérée, et un indice qui monte qui monte qui monte... ça oui !

Il me semble également que c'est ce code qu'on obtient si on essaie d'accéder à une zone définie en FD avant d'avoir fait l'OPEN du fichier (car c'est lui qui alloue la zone).

[xfanx]

oui... il y a des centaines de causes sur un abend S0c4.
cela dit, pour regler ça, premiere chose.. regarde dans la compilation de ton PG, ce qu'il y a comme instruction à l'Offset 2698. ça te donnera peut etre une idée, en fonction de ce que fait ton prog à ce moment la.. quoi que c'et pas toujours vrai ..

du genre, zone en linkage utilisée mais non adressée.. buffer d'I/O ..etc...

[xfanx]

j'oubliais.. désolée pour le double post....
tu dois avoir en sysout un CEEDUMP.. source très importante pour ce genre d'abend..

[el_slapper]

les Dumps, c'est bien gentil, mais en général, c'est surtout bon pour se pourrir les yeux. Je trouve plus rapide de dichotomiser par des displays jusqu'à trouver l'instruction exacte qui plante...

...bon après, si il n'y a moyen de lancer le programme qu'une fois par semaine, il peut être utile de se cramer les yeux. Je l'ai fait une fois, bien obligé. Mais franchement, si on est en test, avec un truc rapide à lancer, on arrive assez rapidement à l'ordre qui tue. Qui est souvent explicite, mis en relation avec la définition des données qui va bien.

[faluma]

A mon avis, la piste la plus probable est celle du tableau. L'indice 0 a peu de chance de donner ce code, car il faudrait que le tableau soit la première zone de WS, ou bien qu'un poste du tableau soit très gros (plus gros que les zones définies avant lui). Par contre, un fin de boucle mal gérée, et un indice qui monte qui monte qui monte... ça oui !

Il me semble également que c'est ce code qu'on obtient si on essaie d'accéder à une zone définie en FD avant d'avoir fait l'OPEN du fichier (car c'est lui qui alloue la zone).

En effet, j'avais mal géré une fin de boucle ce qui empêchait à une partie du programme de s'exécuter. Mon tableau était donc mal rempli ce qui a entraîné cet abend.

Merçi beaucoup à tous de m'avoir répondu!!!

[Hédhili Jaïdane]

En effet, j'avais mal géré une fin de boucle ce qui empêchait à une partie du programme de s'exécuter. Mon tableau était donc mal rempli ce qui a entraîné cet abend.

Merçi beaucoup à tous de m'avoir répondu!!!

Merci à toi du feedback, çà c'est un bon forumeur. N'oublie pas le tag [Résolu] et bonne continuation.

[Homer-ac]

Avec un peu de retard, un bon truc pour souvent trouver spéciquement la cause d'un S0C4 z/OS :
passer si c'est autorisé sur le site avec une CBL SSRANGE. Ca permet à COBOL de détecter un dépassement mémoire au moment ou il survient plutôt que trop tard quand on en tente l'adressage. parfois pratique, cette option très couteuse en code généré qui sera facilement triplé, est impérativement à retirer ensuite quand le pb est résolu.