COBOL

COBOL

COBOL

COBOL is responsible for the efficient, reliable, secure, and unseen day-to-day operations of the world's economy.

 View Only
Back to discussions
Expand all | Collapse all

Host-variable in File Section : DSNH310I W with Db2 preprocessor (passing) vs IGYPS0231-S with integrated coprocessor (blocking)

  • 1.  Host-variable in File Section : DSNH310I W with Db2 preprocessor (passing) vs IGYPS0231-S with integrated coprocessor (blocking)

    Posted Wed September 06, 2023 12:15 PM
    Edited by Denis FALLAI Wed September 06, 2023 03:00 PM

    Hi,

    We study the transition from the Db2 preprocessor to the Db2 coprocessor integrated into the COBOL compiler.

    We come across cases of programs that use hosts-variables which are file record areas.

    The Db2 preprocessor simply emits a warning and the compilation proceeds (afterwards the developer is responsible for any errors at runtime): DSNH310I W

    The Db2 coprocessor blocks compilation by issuing a severe level message: IGYPS0231-S

    DB2 SQL PRECOMPILER         MESSAGES    
    DSNH310I W     DSNHSMUD LINE 408 COL 28  COBOL HOST VARIABLE "E12L-DCJYDT" WAS DECLARED IN FILE SECTION    
    DSNH310I W     DSNHSMUD LINE 408 COL 45  COBOL HOST VARIABLE "E12L-DCJYFI" WAS DECLARED IN FILE SECTION   
    DSNH310I W     DSNHSMUD LINE 409 COL 42  COBOL HOST VARIABLE "E12L-PEGL00" WAS DECLARED IN FILE SECTION 

    vs

    PP 5655-EC6 IBM Enterprise COBOL for z/OS  6.2.0 P200601       JYBC21    Date 09/06/2023  Time 17:18:18   Page    35   
    LineID  Message code  Message text            
       430  IGYPS0231-S   SQL host variable "E12L-DCJYDT" was defined in the "FILE SECTION".  The statement was discarded.
       430  IGYPS0231-S   SQL host variable "E12L-DCJYFI" was defined in the "FILE SECTION".  The statement was discarded.
       431  IGYPS0231-S   SQL host variable "E12L-PEGL00" was defined in the "FILE SECTION".  The statement was discarded.
       601  IGYPS0226-E   DSNH504I DSNHSMUD LINE 601 COL 22  CURSOR "JW-CURSOR" WAS NOT DECLARED

    We can already see a different behavior about severity level between the preprocessor and the Db2 coprocessor.

    But is it fundamentally justified to make a severe error?

    Indeed, with SQLDA management induced by the coprocessor, the memory addresses of the host-variables are recalculated before each access, so a priori no risk of error?

    Unlike the operation of the preprocessor which declares as many SQLDAs as SQL accesses and which by default only calculates the addresses of the hosts-variables once during the first SQL access.

    The severe error level therefore does not seem justified to me, and a warning level as the preprocessor did would seem sufficient to me.

    It remains possible to modify the severity level of the IGYPS0231 message, by setting up an MSGEXIT, but it would seem more appropriate to me that it be a warning level, identical to the preprocessor, and leave the possibility of worsening the level by an MSGEXIT.

    Agree to discuss it.

    Based on the reviews, I will open a ticket on the IBM Ideas site.



    ------------------------------
    Denis FALLAI
    BPCE SI, BPCE group.
    ------------------------------



Related Content