debugging mode en Cobol [Résolu]

[a_karim_fr]

Bonjour,

Est-ce que il y a un JCL ou une autre méthode permet de débuguer une batch ligne par ligne comme XPIDITEUR ?

Merci

[Homer-ac]

il te faut voir ce que tu as comme produit installé sur ton site :
XPEDITER : société Compuware
INTERTEST : C.A.
Debug tool : IBM
Tous ces produits (payants, mais même COBOL est un produit payant) permettent de faire du débug très pointu mais tous nécessitent une formation préalable aux produits. Avec ceux-ci il y a également éventuellement des produits qui permettent de 'jouer' des scénarii de test en batch ou TP. Manque de chance, tous ceux-ci ont leurs propres règles de jeux. Dit autrement, une formation préalable au produit intallé est nécessaire et le plus souvent une mini doc 'maison' sur le site en donne au moins les bases d'utilisation.
A défaut, il reste toujours la possibilité d'activer une 'trace' des paragraphes appelés en batch et de coder la clause 'With Debugging Mode' qui prendra en compte toutes les instructions COBOL (le plus souvent des Display) précédées d'un 'D' en col.7
exemple :

Code :

1
2
3
4
5
6
7
8
        Configuration Section.                           
       *=====================                            
        Source-computer. IBM-Z9.                         
       *                            with Debugging Mode  
                               .               
       *--------------                                   
        Data Division.                                   
       *--------------

Nb. Codée comme ça, la clause with debugging mode pourra facilement être activée puis impérativement remise en commentaire avant livraison du programme.

[a_karim_fr]

Merci Pour l'information

[xfanx]

pour continuer sur le debugging mode, si tu veux faire l'équivalent du READY TRACE, c est a dire un display de tout les paragraphes exécutés sans avoir à faire chacun des display, ajoute ceci juste apres le PROCEDURE DIVISION.

Code :

1
2
3
4
5
6
7
8
                                                            
*--- pour debug                                              
 declaratives.                                               
 titi section. use for debugging on all procedures.          
 tutu.                                                       
      display debug-item.                                    
 end declaratives.                                           
 toto section.

pour tes autres DISPLAY, met un D en colonne 7. ainsi ceux ci ne seront exécutés que si la close With debuging mode est activée sur le SOURCE-COMPUTER.

[Homer-ac]

Pour compléter les indications de XFANX 2 choses :

1) les clauses déclaratives se codent en début de procedure division. Comme pour le D en col. 7, elles sont activées via la clause with debugging mode. Par contre cette trace des paragraphes appelés est activée par un parm dans l'exec après un '/' (tout ce qui suit concerne le langage et tout particulièrement Language Environment, ce qui précède est passé au pgm comme un parm normal)
Donc, contrairement au D en col. 7, une trace des paragraphes s'active dans le JCL. Exemple : // STEP1 EXEC PGM=MYCOB,PARM='/DEBUG'
D'autre part, il y a des restrictions avec d'autres possibilités de cobol dans ce cas (TEST(SYM)).
2) C'est assez bavard donc assez rapidement difficile à suivre.
Pour ces 2 raisons je préfère l'usage d'instructions judicieuses de suivi avec un D en col. 7. Pas nécessairement pour faire simplement des DISPLAY mais ce que l'on veut en code COBOL, comptage indiciels préalables, CALL de modules de traces, zoom sur des calculs intermédiaires et tout ce que l'on veut finalement en fonction des PB.

Indépendemment des techniques et de toutes façons, le fait de désactiver la clause WITH DEBUGGING MODE fait que tout ce qui concerne le mode debugging sera traité comme de simples commentaires pour générer le LOAD. C'est donc la seule clause qu'il est réellement et IMPERATIVEMENT utile de neutraliser avant toute livraison du programme, quitte à refaire un test sans juste avant.

[xfanx]

Envoyé par Homer-ac

Pour compléter les indications de XFANX 2 choses :

1) une trace des paragraphes s'active dans le JCL. Exemple : // STEP1 EXEC PGM=MYCOB,PARM='/DEBUG'

sauf à avoir bien sur les paramètres LE dans le CEEPRM00 en DEBUG par défaut ce qui est souvent le cas sur les Lpar de test.

merci de tes précisions Homer-ac

[Homer-ac]

bonjour,

Une remarque personnelle pour xfanx (je m'en excuse auprès des autres, mais il s'agit de considérations purement système z/OS qui ne peuvent intéresser que les équipes système).
Pour ce que je vois le plus souvent, c'est l'installation de L.E. au plus proche des défauts IBM, donc plutôt sans le DEBUG en particulier, qui est mise en service sur les sites, même sur une LPAR de développement. Le seul véritable piège à c. usuel est ce ALL31(ON) également par défaut et qui interdit de faire communiquer des programmes AMODE(24) et AMODE(ANY) (mais quand même DATA 24 pour COBOL). Comme presque partout il reste des vieux tromblons AMODE 24, il fallait prendre garde à remplacer ces défauts, certes un peu plus performants, par au moins ALL31(OFF) et STACK(,,BELOW), sinon, galère assurée.
Enfin avec la dernière version L.E. on peut envisager de revenir à ces défauts préconisés par IBM parce que les plus performants. IBM s'est enfin décidé à les corriger via une simple SYSIN dans le JCL d'exécution pour traiter les cas particuliers et non plus via les Link CEExOPT Batch et CICS. En clair il suffit d'ajouter dans le JCL :

Code :

1
2
3
//CEEOPTS DD *
 ALL31(OFF),STACK(,,BELOW)
//*

Ca permet de corriger facilement les cas particuliers et au passage de les référencer.
Pour des utilisateurs études d'autre part, c'est également pratique, il suffit d'ajouter une DD CEEOPTS sur un membre qui contient DEBUG dans les JCL de test pour régler leur problème, et donc pour les équipes système, on peut enfin envisager de revenir sur les défauts d'install LE en donnant les consignes utilisateurs qui vont bien.

Dernier point : Avec Enterprise COBOL Rel.4 on a aussi la possibilité de passer par une DD pour les options de compile (DDNAME OPTFILE. Pas du luxe alors qu'on est limité à 100 caractères dans le PARM, et que les options SQL ou CICS quand on veut activer les coprocesseurs, ont une facheuse tendance à exploser ce qu'il faut passer dans le champs PARM.