[AS/400] Même batch, des temps d'exécution différents !

**JauB** · 21/11/2008, 10h12

Bonjour tout le monde,
voilà, j'ai développé un programme batch COBOL/AS400, quand je le lance il prend 2 heures pour se terminer. J'ai créé un deuxième programme qui n'est autre que le 1er batch en y ajoutant deux autres traitements. Donc le 2ème batch est une extension du 1er. Le problème c'est que lorsque je lance le 2ème batch il ne prend que 10 minutes pour se terminer.
Je vérifie à la fin des deux batch pour voir s'ils ont ramené le même nombre d'enregistrements, et c'est bien le cas. Je fais une sommation sur un champ pour les montants ça donne la même somme, j'ai conclu que j'ai rien loupé dans le 2ème batch en faisaint cette évoluion ajout des deux autres traitements mais je ne trouve pas d'explication pour le temps d'exécution qui a été divisé par 12

.
Une piste?

**Cirdeco** · 21/11/2008, 10h24

Bonjour, tu parles en temps elapsed j'imagines?

En temps CPU, tu obtiens le même rapport?

**Hédhili Jaïdane** · 21/11/2008, 10h30

Envoyé par JauB

Bonjour tout le monde,
voilà, j'ai développé un programme batch COBOL/AS400, ...

Bonjour.

Qu'est ce tu entends par un programme batch Cobol ?
Quand tu relances ta première version, le programme dure toujours autant que la première fois ?

**JauB** · 21/11/2008, 10h37

Envoyé par Hédhili Jaïdane

Qu'est ce tu entends par un programme batch Cobol ?

un programme batch Cobol ==> c'est un programme COBOL que je lance en mode batch via la commande SBMJOB.

Envoyé par Hédhili Jaïdane

Quand tu relances ta prière version, le programme dure toujours autant que la première fois ?

==> ça j'ai pas testé

**JauB** · 21/11/2008, 10h38

Envoyé par Cirdeco

Bonjour, tu parles en temps elapsed j'imagines?

En temps CPU, tu obtiens le même rapport?

Je parle du temps que prend mon programme pour prendre fin (terminé).

**Cirdeco** · 21/11/2008, 11h02

En gros, ce dont on veut parler moi et Hédhili Jaïdane, c'est qu'une explication possible a ton problème est directement liée à tes conditions de test.

C'est pourquoi Hédhili Jaïdane te demande si tu as tenté de relancer plusieurs fois ton batch afin de valider ce phénomène.

C'est pourquoi je te parle de temps CPU car il est beaucoup plus significatif que le temps elapsed (temps réel d'exécution). Suivant comment est chargé ta machine, ton batch ne prendra pas forcément le même temps à s'exécuter. Le temps CPU est un temps "machine " qui ne prend pas en compte la charge de ta machine, il sera toujours le même peut importe la puissance, charge de ta machine...

Donc si au niveau du temps CPU, tu oberves la même différence cela sera un peu inquiétant. Dans le cas contraire (temps CPU 2e batch > temps CPU 1er batch), cela correspondra a ce que tu attendais cad que le 2nd batch est plus long a s'exécuter que le premier batch..

**Hédhili Jaïdane** · 21/11/2008, 11h46

Donc c'est un programme Cobol que tu exécutes (lancé) en batch via SBMJOB et non pas via un Cl ou autre chose (planifié, etc..). Ok.
Pour le test de la première version, je t'invite à le faire. Il se peut que ton programme s'est payé un petit roupillon dans la JOBQ.

**JauB** · 21/11/2008, 11h51

Envoyé par Hédhili Jaïdane

Il se peut que ton prgramme s'est payé un petit roupillon dans la JOBQ.

c'est à dire?

**Hédhili Jaïdane** · 21/11/2008, 12h04

Envoyé par JauB

c'est à dire?

C'est à dire que ton travail batch (pour exécuter le programme) est peut être resté dans la jobq avant d'être éligible à l'exécution parce qu'un autre travail y était, que cet autre job attendait la réponse à un message.

Le mieux est de relancer ta première version du programme, si tu peux bien sûr, et de faire WRKACTJOB ou WRKUSRJOB ou encore WRKSBMJOB pour voir où il en est et éventuellement l'arrêter s'il te casse trop les billes et qu'il te fait bailler

.

**JauB** · 21/11/2008, 13h07

J'ai relancé le 1er programme il marche bien comme d'ahbitude, je l'ai arrêté parce que je sais qu'il va prendre encore 2heures

!

Envoyé par Hédhili Jaïdane

C'est à dire que ton travail batch (pour exécuter le programme) est peut être resté dans la jobq avant d'être éligible à l'exécution parce qu'un autre travail y était, que cet autre job attendait la réponse à un message.

Le mieux est de relancer ta première version du programme, si tu peux bien sûr, et de faire WRKACTJOB ou WRKUSRJOB ou encore WRKSBMJOB pour voir où il en est et éventuellement l'arrêter s'il te casse trop les billes et qu'il te fait bailler

.

**Hédhili Jaïdane** · 21/11/2008, 13h17

Envoyé par JauB

J'ai relancé le 1er programme il marche bien comme d'ahbitude, je l'ai arrêté parce que je sais qu'il va prendre encore 2heures

!

- Quand tu fais WRKACTJOB, quel est son état ?
- Est ce qu'il n'attend pas par exemple la fin d'un verrouillage ?
- A part les ajouts que tu as faits, n'as tu pas changé le type d'ouverture de certains fichiers ?

**JauB** · 21/11/2008, 13h27

Son état : RUN --> je vérifié avec l'option 5 et fichiers ouverts et tout marche bien.
mon programme n'attend aucune fin de vérouillage.
pour les types d'ouvertures : je n'ai ajouté qu'un seul fichier que j'ai ouvert et fermé mais qui n'a rien à avoir avec le 1er programme.
!!

Envoyé par Hédhili Jaïdane

- Quand tu fais WRKACTJOB, quel est son état ?
- Est ce qu'il n'attend pas par exemple la fin d'un verrouillage ?
- A part les ajouts que tu as faits, n'as tu pas changé le type d'ouverture de certains fichiers ?

**Hédhili Jaïdane** · 21/11/2008, 13h53

Envoyé par JauB

Son état : RUN --> je vérifié avec l'option 5 et fichiers ouverts et tout marche bien.
mon programme n'attend aucune fin de vérouillage.
pour les types d'ouvertures : je n'ai ajouté qu'un seul fichier que j'ai ouvert et fermé mais qui n'a rien à avoir avec le 1er programme.
!!

Alors c'est peut être dû à la nature et à la logique des traitements ? Parce que sinon je ne vois pas.

**Homer-ac** · 21/11/2008, 15h00

Il y a peut-être eu un changement de version ou d'options d'installation par défaut depuis la compilation du programme ? Je ne connais pas AS400 mais pour z/OS il y a des options de compilations extèmement coûteuses (SSRANGE en particulier). Un test de l'ancien programme après recompile peut être intéressant.

**Mercure** · 21/11/2008, 18h43

Hmm... Dis voir un peu.

Est-ce que le premier programme qui dure 2 heures a du SQL dedans ?

**Homer-ac** · 21/11/2008, 20h41

Intéressant la remarque de Mercure. On a déjà vu également en z/OS des Bind se perdrent dans les limbes ahurissantes !

**Hédhili Jaïdane** · 21/11/2008, 20h53

Jaub ne donne pas plus de détails sur ses traitements dans la 1ère et la 2è versions de son programme. Il dit simplement qu'il a ajouté deux autres traitements. Donc on part de l'hypothèse que les traitements du premier programme se trouvent entièrement dans le second.

Envoyé par JauB

...J'ai créé un deuxième programme qui n'est autre que le 1er batch en y ajoutant deux autres traitements. Donc le 2ème batch est une extension du 1er....

Où est l'erreur ?
Quelques éclaircissements s'imposent, n'est ce pas ? Et quid de cette ouverture et fermeture du fichier ajouté ?

...je n'ai ajouté qu'un seul fichier que j'ai ouvert et fermé mais qui n'a rien à avoir avec le 1er programme.

**Homer-ac** · 21/11/2008, 22h05

Pour les deux hypothèses, option de compilation modifiée ou bind DB2 trop ancien sur des tables DB2 qui ont pu évoluer et un chemin d'accès calculé lors du bind périmé, s'il s'agit effectivement d'un programme ancien, une recompilation et rebind si DB2 permettrait avant un nouveau test de temps de fournir des indications utiles. Ne serait-ce que pour éliminer ces hypothèses, mais j'aime bien l'idée de Mercure si c'est par hasard du DB2.

**Mercure** · 22/11/2008, 11h39

Sur AS400, il y a fort à parier que la BDD est bien DB2/400.
AMHA, les AS400 qui utilisent une autre BDD en local ne doivent pas être légion.

Je pense à SQL à cause du temps qui lui est nécessaire pour créer son plan d'accés pour ouvrir son ODP s'il n'en trouve pas un déjà créé à son goût. Mais encore faut-il que le programme en question utilise SQL.

Attendons donc la réponse de JauB.