Topic
  • No replies
SystemAdmin
SystemAdmin
403 Posts

Pinned topic Entreprise Cobol for z/OS - Performance at runtime using coprocessor DB2

‏2012-07-09T12:37:06Z |
Bonjour,

J'étudie le remplacement du pré-processeur DB2 par l'utilisation du coprocessor DB2 sur les programmes Cobol compilés avec Enterprise Cobol sur z/OS.

Il y a une différence essentielle qui n'apparait pas dans la littérature IBM :
  • le pré-processeur construit autant de SQLDA qu'il y a d'ordres SQL d'accès à DB2. Ces SQLDA sont initialisées par des VALUE (traitées par le prologue du programme), et les adresses des hosts-variables ne sont calculées qu'une seule fois lors du premier accès SQL (SQL-INITIAL).
  • le coprocessor ne déclare qu'une seule SQLDA commune à l'ensemble des ordres SQL d'accès à DB2. Cette unique SQLDA est réalimenté (MOVE et SET ADDRESS) avant chaque exécution d'un accès SQL, (vu en compilant avec l'option LIST).

Lorsqu'un programme traite des centaines de milliers, quand ce ne sont pas des millions, d'accès SQL, quel est l'impact de l'utilisation du coprocessor DB2 sur les performances du programme ?

Cordialement,

Denis FALLAI

google translation

Hello,

I study the replacement of the DB2 pre-processor by the DB2 coprocessor on COBOL programs compiled with Enterprise COBOL for z/OS.

There is an essential difference that does not appear in the literature IBM:
  • The pre-processor built as many SQLDA as there are SQL statements to access DB2. These SQLDA are initialized by VALUE (processed by the prologue of the program), and the addresses of hosts-variables are calculated only once during the first access SQL (SQL-INITIAL).
  • The coprocessor SQLDA declares only one common to all the SQL statements to access DB2. This unique SQLDA is replenished (MOVE and SET ADDRESS) before each execution of SQL access, (viewed when compiling with LIST option).

When a program processes hundreds of thousands, when they are not millions, of SQL access, what is the impact of using the DB2 coprocessor performance of the program?

Sincerely,

Denis fallai
Updated on 2012-08-02T01:59:30Z at 2012-08-02T01:59:30Z by dbzThedinosaur
  • dbzThedinosaur
    dbzThedinosaur
    57 Posts

    Re: Entreprise Cobol for z/OS - Performance at runtime using coprocessor DB2

    ‏2012-07-09T14:28:01Z  
    Just a few thoughts, not based on any information from IBM.

    1. IBM keeps dumming-down COBOL, since so many people
    a) have little or no idea what goes on in a computer
    b) have come from JAVA or C where data is defined differently
    (e.g.:
    redefines rules have changed: used-to-be largest area was defined first, then followed by smaller redefines. This is no longer the rule.
    char to numeric moves)

    2. Look at the number of programmers who code an sqlcode check after a cursor declare. They have no idea of the PLIST function.

    3. Granted executing code repeatedly must have an impact,
    but IBM has really stressed ROW-SET retrieval, which means the number of CALLs to DB2 are reduced - if ROW-SET retrieval is implemented.

    4. What effect does the code introduced by the co-processor vs pre-compiler have on the usage of Linkage as host variables?

    5. how many people screamed about the 2 steps required for the pre-compiler method vs 1 step for the co-processor?
  • SystemAdmin
    SystemAdmin
    403 Posts

    Re: Entreprise Cobol for z/OS - Performance at runtime using coprocessor DB2

    ‏2012-07-09T15:22:29Z  
    Just a few thoughts, not based on any information from IBM.

    1. IBM keeps dumming-down COBOL, since so many people
    a) have little or no idea what goes on in a computer
    b) have come from JAVA or C where data is defined differently
    (e.g.:
    redefines rules have changed: used-to-be largest area was defined first, then followed by smaller redefines. This is no longer the rule.
    char to numeric moves)

    2. Look at the number of programmers who code an sqlcode check after a cursor declare. They have no idea of the PLIST function.

    3. Granted executing code repeatedly must have an impact,
    but IBM has really stressed ROW-SET retrieval, which means the number of CALLs to DB2 are reduced - if ROW-SET retrieval is implemented.

    4. What effect does the code introduced by the co-processor vs pre-compiler have on the usage of Linkage as host variables?

    5. how many people screamed about the 2 steps required for the pre-compiler method vs 1 step for the co-processor?
    Bonjour,

    Concernant le point 5 de votre réponse, l'utilisation du coprocessor DB2 présente les avantages suivants :
    • listing plus compact (stockage)
    • le listing étant utilisé par certains outils de débogage (en tout cas ceux que nous utilisons) :
      • logique plus facile à lire
      • accès directs aux hosts-variables

    Ce sont ces éléments qui me font m'intéresser au remplacement du pré-processeur DB2 par le coprossor d'Enterprise Cobol.

    Cordialement,

    Denis FALLAI



    Hello,

    Regarding item 5 of your answer, use the DB2 coprocessor has the following advantages:
    • Listing more compact (storage)
    • The listing being used by some debugging tools (at least the ones we use):
      • Logic easier to read
      • Direct access to hosts-variables

    That's these elements that make me interested in replacing the preprocessor by coprossor DB2 Enterprise Cobol.

    Sincerely,

    Denis fallai
  • dbzThedinosaur
    dbzThedinosaur
    57 Posts

    Re: Entreprise Cobol for z/OS - Performance at runtime using coprocessor DB2

    ‏2012-07-09T16:59:27Z  
    Bonjour,

    Concernant le point 5 de votre réponse, l'utilisation du coprocessor DB2 présente les avantages suivants :
    • listing plus compact (stockage)
    • le listing étant utilisé par certains outils de débogage (en tout cas ceux que nous utilisons) :
      • logique plus facile à lire
      • accès directs aux hosts-variables

    Ce sont ces éléments qui me font m'intéresser au remplacement du pré-processeur DB2 par le coprossor d'Enterprise Cobol.

    Cordialement,

    Denis FALLAI



    Hello,

    Regarding item 5 of your answer, use the DB2 coprocessor has the following advantages:
    • Listing more compact (storage)
    • The listing being used by some debugging tools (at least the ones we use):
      • Logic easier to read
      • Direct access to hosts-variables

    That's these elements that make me interested in replacing the preprocessor by coprossor DB2 Enterprise Cobol.

    Sincerely,

    Denis fallai
    I have nothing against the coprocessor method, except that it is someone new and occasionally I see that there are bugs, but they
    seem to be worked out rather quickly.

    because of the language barrier (german I could probably manage, but french is beyond my capabilities)
    I will use short, non-ambiguous sentences.

    CALLing a DB2 module from 2 different 'upper modules',
    with the pre-compiler,
    meant that you had to code the db2 sub-module to either:
    1. move all linkage to working storage for host variables
    2. code as your first instruction "turn OFF the init flag"
    so that addressing would be accomplished on each entry to the module.

    with the coprocessor,
    you can deal with host variables in linkage directly without worry
    of address changes due to CALLs from 2 different modules,
    since everything is re-addressed prior to sql execution.

    That alone would save time and storage in the DB2 module
    without having to be slick and trick the INIT routine.
  • SystemAdmin
    SystemAdmin
    403 Posts

    Re: Entreprise Cobol for z/OS - Performance at runtime using coprocessor DB2

    ‏2012-07-09T17:44:21Z  
    I have nothing against the coprocessor method, except that it is someone new and occasionally I see that there are bugs, but they
    seem to be worked out rather quickly.

    because of the language barrier (german I could probably manage, but french is beyond my capabilities)
    I will use short, non-ambiguous sentences.

    CALLing a DB2 module from 2 different 'upper modules',
    with the pre-compiler,
    meant that you had to code the db2 sub-module to either:
    1. move all linkage to working storage for host variables
    2. code as your first instruction "turn OFF the init flag"
    so that addressing would be accomplished on each entry to the module.

    with the coprocessor,
    you can deal with host variables in linkage directly without worry
    of address changes due to CALLs from 2 different modules,
    since everything is re-addressed prior to sql execution.

    That alone would save time and storage in the DB2 module
    without having to be slick and trick the INIT routine.
    Bonjour,

    Je suis informé au sujet de la gestion des hosts-variables à adresses dynamiques (linkage, fichiers...).

    Par contre j'ai découvert que la zone SQLCA était déclarée en GLOBAL par l' "EXEC SQL INCLUDE SQLCA END-EXEC", et cela c'est beaucoup plus ennuyeux (effet de bords entre programmes et programmes inclus qui de fait partagent alors la même SQLCA). Cela aurait été encore pire avec une SQLCA déclarée en EXTERNAL !

    Ceci dit, ma question reste l'impact sur les performances à l'exécution d'un programme compilé avec le coprocessor DB2, (sans utiliser le multi-rows).

    Cordialement,

    Denis FALLAI


    Hello,

    I am informed about the management of hosts-variable dynamic addresses (linkage, files ...).

    By cons I discovered that the SQLCA was declared GLOBAL by the "EXEC SQL INCLUDE SQLCA END-EXEC", and it is much more boring (edge effect between programs and nested programs wich then de facto share same SQLCA). It would have been even worse with an SQLCA declared EXTERNAL!

    That said, my question is the impact on runtime performance of a program compiled with the DB2 coprocessor, (without using the multi-rows).

    Sincerely,

    Denis FALLAI
  • dbzThedinosaur
    dbzThedinosaur
    57 Posts

    Re: Entreprise Cobol for z/OS - Performance at runtime using coprocessor DB2

    ‏2012-08-01T18:12:35Z  
    Bonjour,

    Je suis informé au sujet de la gestion des hosts-variables à adresses dynamiques (linkage, fichiers...).

    Par contre j'ai découvert que la zone SQLCA était déclarée en GLOBAL par l' "EXEC SQL INCLUDE SQLCA END-EXEC", et cela c'est beaucoup plus ennuyeux (effet de bords entre programmes et programmes inclus qui de fait partagent alors la même SQLCA). Cela aurait été encore pire avec une SQLCA déclarée en EXTERNAL !

    Ceci dit, ma question reste l'impact sur les performances à l'exécution d'un programme compilé avec le coprocessor DB2, (sans utiliser le multi-rows).

    Cordialement,

    Denis FALLAI


    Hello,

    I am informed about the management of hosts-variable dynamic addresses (linkage, files ...).

    By cons I discovered that the SQLCA was declared GLOBAL by the "EXEC SQL INCLUDE SQLCA END-EXEC", and it is much more boring (edge effect between programs and nested programs wich then de facto share same SQLCA). It would have been even worse with an SQLCA declared EXTERNAL!

    That said, my question is the impact on runtime performance of a program compiled with the DB2 coprocessor, (without using the multi-rows).

    Sincerely,

    Denis FALLAI
    all in all, I consider your complaint of the GLOBAL declaration of the SQLCA to be nonsense.

    SQLCA -
    within a program you need an indicator anyway if you have a loop within a loop with a cursor(s).
    with nested, same thing. the nested program should be a function and have its own function-return-code.

    whining about a potential problem of EXTERNAL, I still don't see a problem.

    as far as the extra MVC's and LA's, only testing on your machine, at your site, with your environment is going to provide an adequate answer.

    I would spend more time on good table/index design and good SQL
    than worry about moves and load addresses.
  • dbzThedinosaur
    dbzThedinosaur
    57 Posts

    Re: Entreprise Cobol for z/OS - Performance at runtime using coprocessor DB2

    ‏2012-08-02T01:59:30Z  
    all in all, I consider your complaint of the GLOBAL declaration of the SQLCA to be nonsense.

    SQLCA -
    within a program you need an indicator anyway if you have a loop within a loop with a cursor(s).
    with nested, same thing. the nested program should be a function and have its own function-return-code.

    whining about a potential problem of EXTERNAL, I still don't see a problem.

    as far as the extra MVC's and LA's, only testing on your machine, at your site, with your environment is going to provide an adequate answer.

    I would spend more time on good table/index design and good SQL
    than worry about moves and load addresses.
    whining about a potential problem of EXTERNAL, I still don't see a problem.
    whoops, overlooked the potential problems of multiple enclaves.
    fortunately IBM did not.

    still, I wanted to flame a bit about your comment.

    it was unnecessary,
    in as much as it only showed that you wanted to flame IBM for some apparent error.