2016-04-11 18 views
0

Ich versuche, einen Speicherverlust in einer CICS-Transaktion zu finden. Die Transaktion führt ein Cobol-Programm aus, das eine C-DLL aufruft, die eine Verbindung zu einem Socket herstellt, eine Anzahl von mallocs, dann die Verbindung trennt und den Speicher freigibt.CICS-Transaktion, die Ressourcen nicht freigibt, wenn es beendet wird

Diese Transaktion führt zu Speicherlecks, gibt jedoch auch keinen Speicher frei, wenn dieser angehalten wird. Ich habe sorgfältig alle Malloc und Frees abgestimmt (sowie getaddrinfo/freeaddrinfo) und ich habe das gleiche cobol-Programm außerhalb von CICS getestet und es leckt nicht.

Welche CICS-Einstellungen stellen sicher, dass die Ressourcen freigegeben werden, wenn die Transaktion zurückkehrt? Gibt es auch Tipps, um das Speicherleck zu debuggen? Was könnte es sonst noch sein, wenn es nicht die Mallocs wären? Ich habe festgestellt, dass das TCPIP getaddrinfo/freeaddrinfo in SYSTCPT protokolliert wird, verwendet dies CICS-Regionsspeicher?

Antwort

0

CICS releases storage zugewiesen von Code, der unter einer Transaktion bei Environment (LE) enclave termination läuft. Wenn die C-DLL nicht LE für ihre Laufzeit verwendet, sind Sie dem Verhalten der Laufzeit, die von der C-DLL verwendet wird, ausgeliefert.

Sie erwähnen die Verwendung von Sockets. Wenn die C-DLL nicht compiled and linked war, um die CICS Sockets-Schnittstelle zu verwenden, sind Sie dem Verhalten der von der C-DLL verwendeten Laufzeit ausgesetzt.

Ihr CICS-Sysprog kann die LE-Laufzeitoptionen mithilfe der Transaktion CLER dynamisch ändern. Die RPTSTG-Option kann nützliche Informationen aufdecken.

Ihr CICS-Sysprog kann eine Ablaufverfolgung für die Speicherverwaltung mit der Transaktion CETR starten. Diese kann nützliche Informationen aufdecken.

Ich sage Mai enthüllen nützliche Informationen, denn wenn Ihre C-DLL nicht LE für seine Laufzeit verwendet, ist es möglich, diese Techniken werden Ihnen nicht helfen.

+0

Die C DLL ist mit CICS Sockets kompiliert und es verwendet LE. –

+0

RPTSTG zeigt an, dass HEAP auf HEAP (4096,4080, ANYWHERE, KEEP, 4096,4080) eingestellt ist. –

+0

@MichaelTaylor Bitten Sie Ihren CICS SYSPROG, eine Ablaufverfolgung für Sie auszuführen und zu interpretieren. – cschneid

0

Also die Antwort ist, dass es einen Fehler in der CICS TCPIP-Bibliothek auf unserer Version von z/OS und CICS gibt. Das Modul EZACIC17, das mit Ihrem Code verknüpft werden muss, weist einen Fehler auf, bei dem getaddrinfo() die zugewiesenen Strukturen fälschlicherweise markiert. Wenn Sie freeaddrinfo() aufrufen, wird dieser Speicher nicht freigegeben und die CICS-Region verfügt schließlich über nicht genügend Speicher. Unser Entwicklungssystem ist z/OS 1.8 und CICS ist V3.1 und es gibt keine Korrektur für diese Version, daher müssen wir upgraden.

Der gesamte Speicher im C-Programm, der mit malloc() zugewiesen wurde, wird freigegeben, wenn er mit free() freigegeben wird. Nicht freigegebene Ressourcen werden jedoch nicht zurückgegeben, wenn die Anwendung/Transaktion beendet wird. Die Out-Anwendung verwendet C-DLLs, die anscheinend im Speicher verbleiben. Wenn Sie die Anwendung erneut ausführen, bleibt die von CICS verwendete Gesamtspeichermenge konstant. SO, solange es keinen Speicherverlust in unserem Code gibt, erhöht sich die CICS-Speichernutzung nicht.

Verwandte Themen