IBM Z Software


This portal is to open public enhancement requests against IBM Z Software products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).


Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas

  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.


Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Add a new idea Subscribe
Status Not under consideration
Workspace COBOL Compilers
Created by Guest
Created on Mar 7, 2016

RELATED IDEAS

Performance impact when compiling with DB2 coprocessor

When preparing a Cobol-DB2 program with integrated DB2 coprocessor, the Cobol compiler generate an unique SQLDA and feeds it before each SQL access, (DB2 pr?-processor generate an independant SQLDA for each SQL access, and resolve host-variable adresses only once).

The code generated to feed the SQLDA structure can have an impact on performance when it comes to millions of FETCH involving a large number of columns.

We believe that the DB2 coprocessor should work like the DB2 pre-processor and would generate a SQLDA structure for each SQL access in the program, and resolve only once the hosts variables addresses. The hosts-variables with a non-fixed memory address may continue to be resolved prior to each access (hosts-varibles based on BLL, BLF, BLV registers).

Idea priority Low
  • Guest
    Reply
    |     Oct 12, 2022

    Hello

    This situation needs investigations. Measurements FreezeFrame and Strobe show this problem. Assembler code is different.

  • Guest
    Reply
    |     Sep 12, 2022

    About this issue, we made the same test today
    Our tests show that nothing has changed with cobol 6.3 (Build Level info     P220105 )

    • a table with 47 000 000 rows

    • 1 cursor and 10.000.000 fetchs

    • 58 columns / hosts-variables / indicators

    • same program compiled with pre-processor and coprocessor

    • 3 x 2 runs : pre-processor / coprocessor / pre-processor / coprocessor / pre-processor / coprocessor (to ovoid db2 bufferisation bargain).

    The test shows that the DB2 coprocessor is always 10% CPU more expensive as the DB2 pre-processor

    What is your recommendations about this problem ? Thank you

  • Guest
    Reply
    |     Jul 4, 2018

    Would it be possible to have information on the Cobol compiler's guidelines on this topic, and timeframes for implementation?
    The current operation of the DB2 coprocessor is a real obstacle to its adoption in our company.
    Thank you.

  • Guest
    Reply
    |     Apr 12, 2018

    Just to close the loop on this RFE, the DB2 coprocessor won't be changed to act like the DB2 pre-processor; but we will take an action item to improve the COBOL compilers handling of the DB2 coprocessor generated code.

  • Guest
    Reply
    |     Mar 26, 2016

    Our tests show that the DB2 coprocessor is 10% CPU more expensive as the DB2 pre-processor (and 10% elpased too) :
    - 1 cursor and 5.000.000 fetchs
    - 35 columns / hosts-variables / indicators
    - same program compiled with pre-processor and coprocessor
    - 3 x 2 runs : pre-processor / coprocessor / pre-processor / coprocessor / pre-processor / coprocessor (to ovoid db2 bufferisation bargain).

  • Guest
    Reply
    |     Mar 25, 2016

    We would like to have more information about the performance compared between preprocessor and coprocessor.
    The performance aspect is currently an obstacle to the adoption of the coprocessor.

  • Guest
    Reply
    |     Mar 25, 2016

    We would like to have more information about the performance compared between preprocessor and coprocessor.
    The performance aspect is currently an obstacle to the adoption of the coprocessor.

  • Guest
    Reply
    |     Mar 24, 2016

    Thank you for submitting this RFE.

    We currently have test cases where the DB2 coprocessor performs better than the DB2 pre-processor in regards to SQL calls.

    We do not plan to change the current DB2 SQL coprocessor methodology.

  • Guest
    Reply
    |     Mar 21, 2016

    Hi,

    The impact of several SQL statements prepared but not executed over millions of SQL statments systematically prepared identically is not of the same order of magnitude.

    A solution combining the two requirements might be:
    - A SQLDA dedicated to each SQL statement (like pre-compiler).
    - Filling the SQLDA at the first execution of this SQL statement (like coprocessor).
    - No new resolution of addresses in SQLDA on subsequent execution, except for hosts-variables addressed by registers BLL, BLF or BLV.

    Kind regards

    Denis FALLAI

  • Guest
    Reply
    |     Mar 12, 2016

    The Preprocessor generated code initializes sql-plists of all (!) SQL statements contained in a program at program initialization. This is disadvantageous when programs contain many sql statements which are not executed every time the program is called, especially in a CICS environment.
    Therefore I favor the strategy of the coprocessor to defer the initialization of the plists.

By clicking the "Post Comment" or "Submit Idea" button, you are agreeing to the IBM Ideas Portal Terms of Use.
Do not place IBM confidential, company confidential, or personal information into any field.