Utilisation du RETURN

[scorpion]

Bjr,

J'utilise l'otpion RETURN pour sortir de mon programme lorsque celui-ci lorsque le RETURN s'exécute il y a une demande à la console quie me demande de répondre (C D I R) est-il possible de répondre automatiquement à cette question par C que pour mon programme et pas les autres si oui comment le faire. 

[GAPIII]

RETURN sert à arreter le programme.
A mon avis, le message vient du programme appelant.
Essaie de voir qui envoie le message et pourquoi.

Sinon, MONMSG ou MONITOR pour monitorer le message !

[jmpenasse]

Bjr,

J'utilise l'otpion RETURN pour sortir de mon programme lorsque celui-ci lorsque le RETURN s'exécute il y a une demande à la console quie me demande de répondre (C D I R) est-il possible de répondre automatiquement à cette question par C que pour mon programme et pas les autres si oui comment le faire. 

Quel est exactement le message : identifiant message, stp ?

[scorpion]

Slt Jmp

je te donne le message que j'ai

Message CPF3309 reçu par MONPGM à l'instruction 14800. (C D I R)

Pour info j'utilise une commande pour activer mon clp à l'intérieur du clp j'ai mis RETURN pour planter le programme en cas d'anomalie et depuis lorsque il passe en anomalie j'ai ce message sans doute normale comme fonctionnement  

[jmpenasse]

Hum tu es sur que la ligne sur laquelle apparait l'erreur est bien celle du RETURN ?
ce message ne semble pas correspondre : "Aucun fichier portant le nom &1 n'est actif."
Ce message est utilisé essentiellement pour les spoules. Il est émis par les commandes DLTSPLF, CPYSPLF ...

Pour info j'utilise une commande pour activer mon clp à l'intérieur du clp

je ne comprends pas   c'est un appel récursif ? (ton CL se rappelle lui-même, au travers d'une commande ?)

j'ai mis RETURN pour planter le programme en cas d'anomalie

Comme l'a dit GAPIII, RETURN sert tout simplement à sortir du programme avant la dernière instruction du source. RETURN ne "plante" pas le programme, il provoque une fin tout à fait normale.

[GAPIII]

Pourriez-vous nous donner le code du programme MONPGM du coté de l'instruction14800 ?
(L'instruction qui plante plus le monitoring de l'erreur et le return)

[scorpion]

Code:

je ne comprends pas  Huh? c'est un appel récursif ? (ton CL se rappelle lui-même, au travers d'une commande ?)

Non j'ai créé une commande qui permet de lancer mon programme pas plus pas moins comme ça il n'y a plus que le nom de la commande à donner et le programme ce lance au lieu de faire call mabib/mon pgm

En ce qui concerne le RETURN j'ai cru comprendre que ça permet de quitter le programme mais en fin anormale mais comme tu me le dis ce n'est pas ça le RETURN quitte le programme en fin normale

Alors une question comment faire pour quitter le programme en fin anormale actuellement j'utilise le monitoring avec un goto qui pointe sur un label qui envoi un send d'anomalie mais le job ce termine en completed

Ce que je souhaite c'est quand je suis au label d'anomalie j'envoie un send et je veux que le job ce termine en anomalie  

[GAPIII]

Genre j'arrête tout ?

Essaie alors la commande ENDJOB OPTION(*IMMED)

[scorpion]

Oui j'arrête tout mais je voudrais avoir une ligne qui ressemble à ça au niveau de la log

Travail 188294/GOPUSR2/MONPGM terminé anormalement le 07/15/10 à 15:28:44

[jmpenasse]

Oui j'arrête tout mais je voudrais avoir une ligne qui ressemble à ça au niveau de la log
Travail 188294/GOPUSR2/MONPGM terminé anormalement le 07/15/10 à 15:28:44

Pour ça il faut juste envoyer un message programme de type *ESCAPE à la pgmq *PRV :

Code:

          SNDPGMMSG  MSGID(CPF9898) MSGF(QCPFMSG) MSGDTA('Erreur +
                       fatale trouvée dans mon super programme') +
                       TOPGMQ(*PRV) MSGTYPE(*ESCAPE)               

[scorpion]

c'est tout pas plus ok je test merci beaucoup

[jmpenasse]

Ce sera surement plus complexe que le simple sndpgmmsg, car si tu as plusieurs programmes dans la pile d'appels, il faut traiter l'erreur en cascade.
Je m'explique avec un exemple :

dans un job, le premier programme P1 appelle P2 qui appelle P3.
Tu "plantes" P3 par le sndpgmmsg : cela envoie le message d''escape à P2 qui lui même sera en erreur (un truc du genre "Erreur lors de l'appel du programme P3"), donc message à l'utilisateur (ou QSYSOPR) avec demande de réponse (le fameux "C D I R"). Et ce sera la même chose entre P1 et P2 
Pour que le job se plante complètement sans intervention de l'utilisateur, il faut que chaque programme de la pile d'appel gère l'erreur en la retransmettant à son appelant.

En résumé, dans P1 et P2 il faut pour chaque CALL faire un truc du genre :

Code:

          CALL       PGM(P2)
           MONMSG     MSGID(CPF0000 CEE0000) EXEC(CALL +            
                        PGM(QMHRSNEM) PARM('    ' +                  
                        X'0000000000000000'))              

     

L'API QMHRSNEM retransmet un message escape à son appelant.

Mais il y a peut-être mieux, je ne suis pas très calé dans les messages

[scorpion]

Dac mais la j'ai fait mon test avec un seul pgm

Pour simuler le plantage j'ai mis le dltf sur un fichier qui n'existe pas

PGM

DLTF       FILE(MABIB/FICNUMIPX)                                              
  SNDPGMMSG     MSGID(CPF9898) MSGF(QCPFMSG) MSGDTA('ERREUR FATALE TROUVÉE DANS +
     MON PUISSANT PROGRAMME') TOPGMQ(*PRV) MSGTYPE(*ESCAPE)                      

ENDPGM

Par contre je récupère le message suivant à la console mais pas la ligne Travail 188294/GOPUSR2/MONPGM terminé anormalement le 07/15/10 à 15:28:44
 
Message CPF2105 reçu par TSTVAR à l'instruction 600. (C D I R)

[jmpenasse]

Dac mais la j'ai fait mon test avec un seul pgm

Pour simuler le plantage j'ai mis le dltf sur un fichier qui n'existe pas

PGM

DLTF       FILE(MABIB/FICNUMIPX)                                              
  SNDPGMMSG     MSGID(CPF9898) MSGF(QCPFMSG) MSGDTA('ERREUR FATALE TROUVÉE DANS +
     MON PUISSANT PROGRAMME') TOPGMQ(*PRV) MSGTYPE(*ESCAPE)                      

ENDPGM

Par contre je récupère le message suivant à la console mais pas la ligne Travail 188294/GOPUSR2/MONPGM terminé anormalement le 07/15/10 à 15:28:44
 
Message CPF2105 reçu par TSTVAR à l'instruction 600. (C D I R)

Normal, le premier message d'erreur fatale est le CPF2105 emis par la commande DLTF.
Il te faut "monitorer" ce message :

Code:

PGM

DLTF       FILE(MABIB/FICNUMIPX)  
MONMSG CPF2105 EXEC(DO)                                            
  SNDPGMMSG     MSGID(CPF9898) MSGF(QCPFMSG) MSGDTA('ERREUR FATALE TROUVÉE DANS +
     MON PUISSANT PROGRAMME') TOPGMQ(*PRV) MSGTYPE(*ESCAPE)                      
ENDDO
ENDPGM

Mais attention, si tu commences à tout vouloir monitorer cela risque de créer plus de problème que d'en résoudre.
Il y a plusieurs écoles pour ce sujet, mais mon avis est qu'il ne faut monitorer que les exceptions normales dans un traitement (fin de fichier, test existence d'un fichier de travail dans QTEMP avant de le créer, etc...) et laisser le système gérer les erreurs graves (il le fait très bien) qui ne devraient JAMAIS arriver. Comme par exemple un fichier (ou programme, etc) indispensable au traitement qui n'est pas trouvé ! Ce type d'erreur montre une anomalie grave soit de programmation soit d'environnement d'exploitation. Cela ne devrait pas arriver en production.
Si par malheur cela survient, il faut être informé de suite et pouvoir reprendre le traitement (intérêt du "I" de CDIR) après correction, mais surtout savoir rapidement ou le traitement est planté.
my 2 cents

[scorpion]

Bjr Jmp

J'ai effectué le test et c'est parfait pour ce qui est des cas d'anomalies je suis d'accord avec toi pas de problème

Merci pour l'aide A+