Programmes Visual Cobol persistant en mémoire

A compter d'une "certaine version" de MicroFocus Cobol, la libération des processus chargés par les BHR ne se fait plus par défaut. Les processus peuvent alors devenir très consommateurs de mémoire.

Pour obtenir une libération mémoire effective lors du déchargement des processus
Créer un fichier de configuration, par exemple $SIGACS/adm/cfg/visualCobol.cfg contenant la ligne :

set default_cancel_mode=0

Positionnez la variable COBCONFIG dans le .profile :

COBCONFIG=$SIGACS/adm/cfg/visualCobol.cfg 

export COBCONFIG

Si vous ne les avez pas déjà, des patch complémentaires peuvent être demandés pour disposer dans les paramètres de la plate forme physique le nombre maximum de processus à conserver en mémoire.

Ci dessous les tests de Eric :

Version de Microfocus Cobol

srvlnxhr-/applis/hr/txt/tmp> cob -V

version @(#)cob.c       5.0.0.134

PRN=KXCRH/AAD:Ao.U4.13.04

PTI=32/64 bit

PTI=Micro Focus Visual COBOL Development Hub 5.0 - Patch Update 24

PTI=Patch Update 24

PTI=pkg_299760

PTI=MFInstaller

I see no work (see `cob -?' for help)

Avec OpenHR paramétré pour ne conserver que 5 processus en mémoire, mais ou l'on constate que 8 sont chargés :

srvlnxhr-/applis/hr/txt/tmp> ps -fp 26484

hrdev 26484 26380  0 16:19 pts/4    00:00:01 RTSDGN TYBXBHR Default*0000000100000000 127.0.0.1 50002 logdir=/applis/hr/openhr/logs,trace=true,debug=true,chrono=false,client=*,tracefilenamepattern=BHR.%1.%2.%3.%4.%5

 

srvlnxhr-/applis/hr/txt/tmp> pmap 26484 > pmap_26484.txt

srvlnxhr-/applis/hr/txt/tmp> grep BNM pmap_26484.txt

00007f4af49f0000     76K r-x-- FDXGDBNM.so

00007f4af4a03000   2044K ----- FDXGDBNM.so

00007f4af4c02000      4K r-x-- FDXGDBNM.so

00007f4af4c03000      4K rwx-- FDXGDBNM.so

00007f4af5b3e000     80K r-x-- AS800BNM.so

00007f4af5b52000   2044K ----- AS800BNM.so

00007f4af5d51000      4K r-x-- AS800BNM.so

00007f4af5d52000      4K rwx-- AS800BNM.so

00007f4af6a42000     76K r-x-- AS311BNM.so

00007f4af6a55000   2048K ----- AS311BNM.so

00007f4af6c55000      4K r-x-- AS311BNM.so

00007f4af6c56000      4K rwx-- AS311BNM.so

00007f4af790e000     76K r-x-- AS511BNM.so

00007f4af7921000   2048K ----- AS511BNM.so

00007f4af7b21000      4K r-x-- AS511BNM.so

00007f4af7b22000      4K rwx-- AS511BNM.so

00007f4af8793000     76K r-x-- AS611BNM.so

00007f4af87a6000   2048K ----- AS611BNM.so

00007f4af89a6000      4K r-x-- AS611BNM.so

00007f4af89a7000      4K rwx-- AS611BNM.so

00007f4af9bd5000     80K r-x-- FS00BBNM.so

00007f4af9be9000   2044K ----- FS00BBNM.so

00007f4af9de8000      4K r-x-- FS00BBNM.so

00007f4af9de9000      4K rwx-- FS00BBNM.so

00007f4afb21a000     80K r-x-- FS001BNM.so

00007f4afb22e000   2044K ----- FS001BNM.so

00007f4afb42d000      4K r-x-- FS001BNM.so

00007f4afb42e000      4K rwx-- FS001BNM.so

00007f4afc7a8000     80K r-x-- FS000BNM.so

00007f4afc7bc000   2044K ----- FS000BNM.so

00007f4afc9bb000      4K r-x-- FS000BNM.so

00007f4afc9bc000      4K rwx-- FS000BNM.so

Documentation Microfocus :

By default, a CANCEL executed on a called subprogram is a logical CANCEL only. This means that although the program will not physically be removed from memory it will be in it's initial state the next time it is called.

If you wish for the subprogram to physically be removed from memory then you should set the run-time tunable default_cancel_mode=0. Please see the documentation here

This logical CANCEL default is in effect to ensure that the performance of call statements are optimal.