Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Membre actif
    Modifier le fonctionnement d'un programme RPG actif à la volée
    Bonjour.

    Le contexte : nous exposons des programmes RPG via des web services (serveur LWI). Lorsque le web service est consommé à l'extérieur du i, un travail est associé à ce web service. Avec des groupes d'activations nommés, le travail reste en mémoire, donc les programmes ne passent plus en phase d'initialisation.

    Mon problème : je souhaite prévoir un mode de trace (écriture dans une table) à l'intérieur du programme, mais non systématique (en gros, activer les traces à la volée uniquement en cas de problème). J'ai utilisé une DTAARA dont je teste l'existence à chaque utilisation du programme. Mais c'est un peu lourd (et je pense que c'est relativement "gourmand").

    Je cherche donc un palliatif, genre les indicateurs U1-U8 qui peuvent être modifiés via un CHGJOB. Mais je pense que la valeur de ces indicateurs n'est récupérée que dans la phase d'initialisation d'un programme (1er appel / *INZSR). Comme il est en groupe d'activation nommé, je ne pense pas pouvoir faire varier la valeur de ces indicateurs et pouvoir les récupérer dans le programme.

    Quelqu'un connait-il donc un moyen "d'informer" un RPG actif d'un changement pour que son comportement à l'exécution change ?

    Merci.

  2. #2
    Membre éclairé
    Bonjour,
    Je pense que le plus efficace est d'utiliser une DataQueue (c'est ce que moi j'utilise), ou un simple enregistrement de fichier. Mais personnellement je pense que ton fonctionnement à base d'une DTAARA n'est pas une mauvaise solution dans la mesure où tu récupères son contenu (trace On ou Off) plutôt que le fait qu'elle existe, à chaque fois que le programme s'active.

  3. #3
    Nouveau membre du Club
    Bonjour,

    je pense qu'un User Space est l'objet le plus rapide.
    Par contre il n'est manipulable que par API
    La Data Area me semble un bon compromis également, à voir les besoins/problèmes de performance

    Nathanaël

###raw>template_hook.ano_emploi###