Qu'est-ce qui peut provoquer la rédaction de la transaction CICS dans la mémoire allouée CICS?

Question

J'utilise CICS dans le programme COBOL et j'ai remarqué que parfois les données sont écrites à partir de la mémoire CICS. Il provoque une corruption de données et mon arrêt d'application. Je ne sais pas où il ajoute, donc je crée un analyseur pour analyser mon code COBOL pour rechercher une éventuelle corruption dans la gueule utilisée par CICS. Maintenant, j'ai vérifié les déclarations suivantes:

EXEC CICS XCTL
EXEC CICS LINK
EXEC CICS RETURN TRANSID

Pour chacun, je vérifie si la longueur envoyée (déclarée dans LENGTH paramètre) n'est pas supérieur à l'envoi COMMAREA. Alors je vérifie si DFHCOMMAREA, dans le programme de réception n'est pas supérieur à l'envoi COMMAREA (Selon ce doc http://publib.boulder.ibm.com/infocenter/cicsts/v3r1/index.jsp?topic=%2fcom.ibm.cics.ts31.doc%2fdfhp3%2fdfhp37t.htm) :

La zone de données de réception n'a pas besoin d'être de la même longueur que la zone de communication d'origine; Si l'accès n'est requis que pour la première partie des données, la nouvelle zone de données peut être plus courte. Cependant, il ne doit pas être plus long que la durée de la zone de communication passée. Si c'est le cas, votre transaction peut tenter par inadvertance de lire des données en dehors de la zone qui a été adoptée. Il peut également écraser les données en dehors de la zone, ce qui pourrait provoquer l'abandon des CIC.

Maintenant, je me demande quelles autres choses devrais-je analyser afin de détecter le écrasement de la mémoire?

Answer 1

Lorsqu'un programme CICS commence à écrire partout dans la mémoire, il "cessera non seulement de travailler", mais peut également écraser la région CICS!

Si vous êtes sûr que le LENGTH est réglé correctement sur LINKle sable XCTLs et que vous recevez le COMMAREA dans un enregistrement de liaison de cette taille (EIBCALEN), Ensuite ça devrait aller.

Plutôt que d'essayer d'analyser vos programmes COBOL, je vous suggère de définir des options de vérification des limites du compilateur. Le problème que vous rencontrez est très probablement lié à l'indexation ou à l'indice de recrutement au-delà des limites d'une table de stockage de travail. Tenter de détecter cette classe d'erreur de programmation par analyse statique n'est généralement pas très efficace.

La vérification des limites devrait détecter les références de mémoire hors de la gamme, publier un message de diagnostic au journal, puis et terminer votre programme avant qu'il ne plante toute la région CICS. Le message enregistré doit vous indiquer la ligne source où la référence hors limites s'est produite.

Vérifiez SSRANGE Option de temps de compilation. Assurez-vous qu'il est défini et que votre région CICS exécute des programmes compatibles avec LE avec CHECK(ON).

Cela devrait clouer des références de mémoire des limites assez rapidement.

Answer 2

Nealb a un bonne idée. Je vous suggère de regarder également dans le Stgprot et Louerpgm Cics Paramètres d'initialisation du système.

Answer 3

Au fur et à mesure que vous utilisez Micro Focus COBOL, vous pouvez définir l'API Memory_strategy (ou l'API CBL_MEM_STRATEGY) pour vous aider à analyser où l'erreur se produit en permettant au temps d'exécution de protéger la mémoire de différentes manières.

La mémoire peut également être validée via l'appel "cbl_mem_validate".

Une autre chose peut faire est d'utiliser le support de traçage ... CTF de recherche (installation de traçage consolidée). Cela vous donnera une idée où votre code est au moment de l'erreur.

Quelques références qui vous aideront;

http://kb.microfocus.com/display/4/kb/article.aspx?aid=31645

http://documentation.microfocus.com/help/index.jsp?topic=%2fcom.microfocus.eclipse.infocenter.studee60win.sp02ws01%2fhrrtrhrtcf0o.html

http://documentation.microfocus.com/help/index.jsp?topic=%2fcom.microfocus.eclipse.infocenter.studee60ux.sp02ws01%2FGUID-762085AC-8396-4D71-9CC1-6231551d3aee.

Answer 4

Pour la vérification des limites des données, utilisez toujours transclusion, qui dans cobol est appelé copycode ou copybook. Passez l'élément de données racine dans le Copycode et compilez la même version dans l'appelant et appelé programme. Ce copycode est une sorte de contrat pour le programme appelé, c'est donc une bonne idée d'avoir une convention de dénomination qui les attaches ensemble. Pour vous assurer qu'ils sont en synchronisation, chaque fois que vous modifiez le Copycode, recompilez tous les programmes qui le font référence.

De plus, l'utilisation de SSRange est excellente (mais quelqu'un l'a déjà mentionné).