IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
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

Cobol Discussion :

Optimisation d'un programme avec un LVL 66 ?


Sujet :

Cobol

  1. #1
    Membre averti Avatar de rockley
    Homme Profil pro
    Inscrit en
    Décembre 2010
    Messages
    404
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Décembre 2010
    Messages : 404
    Points : 346
    Points
    346
    Par défaut Optimisation d'un programme avec un LVL 66 ?
    Bonjour,

    J'ai un programme qui attaque plus de 23 sous programmes avec le même Copie Book.
    Le copie Book contient une zone dédiée pour chaque sous-prod. Le copie Book fait à peu près 30K.
    En gros un peut représenter le copie book de la manière suivante :
    ENTETE sur 2000 K
    Zone pour le sous-programme 1 (sur 1000K)
    Zone pour le sous-programme 2 (sur 1000K)
    ...
    Zone pour le sous-programme 22 (sur 1000K)
    Zone pour le sous-programme 23 (sur 1000K)
    Filler pour les futures sous programmes
    On transfert la totalité du copie Book à chaque appelle aux sous programmes alors qu'on n'a pas besoin de tout.

    Je trouve ça assez dommage et pas très optimal. Je me demande si c'est possible d'optimiser via les LVL 66 de cobol.

    En gros, si j'appelle le sous programme N°1, je redéfinis et envoie uniquement les zones dont j'ai besoin (ENTETE + ZONE POUR LE SOUS-PGM 1).

    Le problème, c'est que je ne sais pas si on ça va optimiser réellement le programme. Est-ce que la déclaration des LVL 66 est gourmande en temps CPU ? Est-ce qu'on gagnera réellement en perf si on transfert des copie book plus petits ?

    Merci d'avance pour votre aide.

  2. #2
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 044
    Points
    32 044
    Par défaut
    Les niveaux 66, c'est les RENAMES : du suicide au niveau maintenance. C'est interdit sur la plupart des sites sérieux, parce que ça a fait des dommages d'ordre nucléaire.

    Après, je n'ai aucune idée du cout en terme de performances de la taille des données passées en paramètre. C'est à tester. Le gain ne peut être fort que si le nombre d'appels est très important.(on doit compter en microsecondes, je pense. Si on fait des millions, ça peut valoir le coup).

    Je ferais une mécanique juste un peu plus compliquée, perso, mais qui a l'avantage de ne pas utiliser le niveau 66(pas bien! mal! horrible!)

    du genre

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    01 GRANDE-COPY. <==ça, c'est ta copy existante
        04 GRAND-ENTETE.
        04 GRAND-02.
        04 GRAND-03(.../...)
    
    01 GRAND-POSITIONS.
        04 GRAND-TAB OCCURS 24 <== l'entête plus les 23 zones
            08 POSITION PIC S9(9) COMP.
            08 LONGUEUR PIC S9(9) COMP.
    
    01 PETITE-COPY.
        04 PETIT-ENTETE
        04 PETIT-STOCK PIC X(1000000). <== Mettre la longueur max parmi les GRAND-xx
    
    77 NUMERO-COPY PIC 9(2).
    
    (.../...) La partie chiante, parcequ'on ne peut pas la faire par un boucle, COBOL n'ayant pour ainsi dire pas d'introspection. Doit être présente dans le programme appellant, mais aussi dans le module appelé
    MOVE 1 TO POSITION (1)
    MOVE LENGTH OF GRAND-ENTETE TO LONGUEUR(1)
    ADD POSITION (1) TO LONGUEUR(1) GIVING POSITION (2)
    MOVE LENGTH OF GRAND-02 TO LONGUEUR(2)
    ADD POSITION (2) TO LONGUEUR (2) GIVING POSITION (3)
    MOVE LENGTH OF GRAND-03 TO LONGUEUR (3)
    (etc... jusque'à 24)
    
    (.../...)
    
    *Pour chaque appel : ICI, on appelle le module 15
    MOVE GRANDE-COPY( POSITION (1) : LONGUEUR (1) ) TO PETIT-ENTETE
    MOVE GRANDE*COPY( POSITION (16) : LONGUEUR (16) ) TO PETIT-STOCK
    
    (.../...)dans le module appellé, ici le module 16, on remet les définitions ci-dessus, on refait le calcul des longueurs
    
    PROCEDURE DIVISION USING PETITE-COPY
    
    (.../...)Après recalcul des longueurs et positions
    MOVE PETIT-ENTETE TO GRAND-ENTETE
    MOVE PETIT-STOCK TO GRANDE-COPY(POSITION(16) : LONGUEUR(16))
    
    et hop, la copy de base est remplie là ou c'est important. Et vide partout ailleurs, mais on s'en fout, si j'ai bien compris
    NB : il faut que les données passées soient importantes en poids pour que ça vaille le coup, parce que je fais pas mal de calcul, mine de rien. Une astuce pourrait être de garder les positions et les longueurs en mémoire dans le module appelé, qui ne les calculerait donc qu'une seule fois.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  3. #3
    Membre expert
    Homme Profil pro
    Retraité
    Inscrit en
    Octobre 2005
    Messages
    1 473
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 65
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Retraité
    Secteur : Finance

    Informations forums :
    Inscription : Octobre 2005
    Messages : 1 473
    Points : 3 283
    Points
    3 283
    Par défaut
    Citation Envoyé par rockley Voir le message
    ...
    Le problème, c'est que je ne sais pas si on ça va optimiser réellement le programme. Est-ce que la déclaration des LVL 66 est gourmande en temps CPU ? Est-ce qu'on gagnera réellement en perf si on transfert des copie book plus petits ?
    Pour moi, il n'y aucun gain en CPU si on choisit d'utiliser les niveaux 66 du COBOL, puisqu'on ne va agir que sur l'organisation de ma mémoire entre le programme appelant et les programmes appelés.

    D'autre part, n'oublions pas qu'en COBOL ( en général et en tous cas par défaut ... ) les passages de paramètres se font par adresse.

    Par contre , le reproche principal qu'on peut faire à ce style de construction, c'est qu'on a créé un couplage artificiel entre les 23 sous programmes. Mais c'est à mon avis un défaut de conception plutôt qu'un problème de performance.

  4. #4
    Membre averti Avatar de rockley
    Homme Profil pro
    Inscrit en
    Décembre 2010
    Messages
    404
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Décembre 2010
    Messages : 404
    Points : 346
    Points
    346
    Par défaut
    Oui, c'est vrai. Je me suis rappelé que les passages se faisait par pointeur

    Merci pour votre aide à tous en tout cas. Je pense que tout bien réfléchis, c'était pas une si bonne idée que ça.

  5. #5
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 059
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 059
    Points : 38 269
    Points
    38 269
    Billets dans le blog
    9
    Par défaut
    Bonjour,

    Puisque toutes les zones font la même taille (1000k) et que chaque sous programme utilise une et une seule zone spécifique, pourquoi ne pas faire tout simplement un redefines ?

    Concernant le passage des paramètres en cobol, on peut spécifier "by reference" ou "by content", on peut combiner les 2 modes dans un même appel

  6. #6
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 044
    Points
    32 044
    Par défaut
    Citation Envoyé par escartefigue Voir le message
    Bonjour,

    Puisque toutes les zones font la même taille (1000k) et que chaque sous programme utilise une et une seule zone spécifique, pourquoi ne pas faire tout simplement un redefines ?

    Concernant le passage des paramètres en cobol, on peut spécifier "by reference" ou "by content", on peut combiner les 2 modes dans un même appel
    ça peut marcher, si on a le droit de modifier la copy en question. Dans ma réponse, j'ai assumé que non. Parceque mon premier réflexe a été de me dire "et si on créait une copy avec des redefines correspondant au besoin"? Mais c'est de la clownerie, en fait, parce qu'on se retrouve soudain avec 2 copy à maintenir en parallèle, ce qui généralement pète des mois, voir des années plus tard, à la tronche de celui qui à créé ça(ou un de ses successeurs).

    Mais oui, si on a l'entière propriété de la copy et qu'on peut se permettre ce genre de chose, alors pas de souci. J'ai quand même l'impression que pas mal de programmes sont basés sur cette copy, et que tout mettre en redefines est un projet de refonte assez costaud. D'ou ma solution, un peu plus couteuse en code, mais sans effet de bord sur les autres utilisateurs de la même copy. Enfin, pour le gain en temps de calcul, je n'en sais fichtrement rien, et il est fort possible qu'il soit négligeable.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  7. #7
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 059
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 059
    Points : 38 269
    Points
    38 269
    Billets dans le blog
    9
    Par défaut
    Il me semble qu'il vaut mieux éviter une solution inutilement complexe, par ailleurs, avec 23x1000 k plus le préfixe, on approche de la limite des 32k d'une commarea

    Donc, s'il s'agit d'un proramme utilisé en TP il faudra
    - soit passer par des redefines, ce qui me semble le plus simple et le plus judicieux dans ce cas précis, car seule la copy change et une recompilation programme + sous pro suffit
    - soit passer par la technique des channels et containers, ce qui implique des modifications de code dans le programme et les 23 sous-programmes
    c'est vraiment dommage d'en arriver là alors que les 22 autres zones de 1000 k sont complètement inutiles...

    Je milite pour la première solution, beaucoup plus simple à mettre en œuvre et à comprendre donc à maintenir.
    La 2ème solution peut être retenue s'il est envisagé que certaines zones qui aujourd'hui ne font que 1000 k deviennent beaucoup plus grandes et du coup atteignent la limite des 32k

  8. #8
    Membre expert
    Homme Profil pro
    Retraité
    Inscrit en
    Octobre 2005
    Messages
    1 473
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 65
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Retraité
    Secteur : Finance

    Informations forums :
    Inscription : Octobre 2005
    Messages : 1 473
    Points : 3 283
    Points
    3 283
    Par défaut
    Citation Envoyé par escartefigue Voir le message
    ... on approche de la limite des 32k d'une commarea ...
    Sauf qu'on ne sait pas si on est en TP et encore moins en CICS. Plutôt que de COMMAREA, il me semble qu'on parle plutôt de LINKAGE SECTION ici.

    En COBOL V4.2, la limite d'une LINKAGE SECTION est de 134 213 631 octets, et en V5.1, il n'y a plus de limites sur cette taille ...

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. [IML] Optimiser programme avec IML
    Par Billou265 dans le forum SAS IML
    Réponses: 3
    Dernier message: 02/09/2011, 17h21
  2. Liens : Aide à la programmation avec DirectX
    Par djbed dans le forum DirectX
    Réponses: 11
    Dernier message: 23/03/2007, 00h30
  3. [Classpath][execution] executer un programme avec des jar.
    Par LoLoSS dans le forum Général Java
    Réponses: 11
    Dernier message: 26/08/2004, 12h45
  4. Commencer la programmation avec le langage Java ?
    Par von_magnus dans le forum Débuter
    Réponses: 14
    Dernier message: 09/03/2004, 23h19
  5. Réponses: 3
    Dernier message: 27/08/2003, 22h14

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo