Topic
  • No replies
lzrycki
lzrycki
29 Posts

Pinned topic A non critical bug in DSNHPC - COBOL ( mainframe)

‏2012-09-15T14:38:44Z |
Hi people

testing a COBOL code programs quality assurance product I found a bug using the DB2 precompiler DSNHPC. DSNHPC doesn’t make a good interpretation of a continuation line done by ‘-‘ in column 7 in the first line of a program.
Example:

//DB2PC EXEC PGM=DSNHPC,REGION=4M,
// PARM=('HOST(IBMCOB),APOST,XREF,SOURCE,DATE(ISO)',
// ''),COND=(4,LT)


//SYSIN DD *
IDENTIFICATION DIVISION.
PROGRAM-ID. TEMPTEMP IS INITIAL.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
EXEC SQL
INCLUDE SQLCA
END-EXEC.
PROCEDURE DIVISION.
DISPL
- AY 'HELLO WORLD'.
STOP RUN.
The DSNHPC SYSOUT that will be the SYSIN in the compiler step, show us

IDENTIFICATION DIVISION.
PROGRAM-ID. TEMPTEMP IS INITIAL.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
*****EXEC SQL
***** INCLUDE SQLCA
*****END-EXEC.
01 SQLCA.
05 SQLCAID PIC X(8).
05 SQLCABC PIC S9(9) COMP-4.
05 SQLCODE PIC S9(9) COMP-4.
...
...
...
77 SQL-TEMP PIC X(128).
77 DSN-TEMP PIC S9(9) COMP-4.
77 DSN-TMP2 PIC S9(18) COMP-3.
77 DSNNROWS PIC S9(9) COMP-4.
77 DSNNTYPE PIC S9(4) COMP-4.
77 DSNNLEN PIC S9(4) COMP-4.
77 SQL-NULL PIC S9(9) COMP-4 VALUE +0.
77 SQL-INIT-FLAG PIC S9(4) COMP-4 VALUE +0.
88 SQL-INIT-DONE VALUE +1.
77 SQL-FILE-READ PIC S9(9) COMP-4 VALUE +2.
77 SQL-FILE-CREATE PIC S9(9) COMP-4 VALUE +8.
77 SQL-FILE-OVERWRITE PIC S9(9) COMP-4 VALUE +16.
77 SQL-FILE-APPEND PIC S9(9) COMP-4 VALUE +32.

PROCEDURE DIVISION.
DISPL
DSNSQL SECTION.
SQL-SKIP.
GO TO SQL-INIT-END.
SQL-INITIAL.
MOVE 1 TO SQL-INIT-FLAG.
SQL-INIT-END.
CONTINUE.
- AY 'HELLO WORLD'.
STOP RUN.
As you can see DISPL is the first line inthe Procedure and "- AY 'HELLO WORLD' " in the ninth with SQL sections in the middle.

Regards

Leonardo
Updated on 2013-01-31T10:23:10Z at 2013-01-31T10:23:10Z by BillWoodger
  • dbzThedinosaur
    dbzThedinosaur
    57 Posts

    Re: A non critical bug in DSNHPC - COBOL ( mainframe)

    ‏2012-09-15T16:35:46Z  
    Doc,

    are not continuation lines only used in ID/Env/Data Divisions.

    though the manual does not explicitly says, can't have them in Procedure Div
    there really is no need to use a continuation line in Procedure Division.

    Have you tried compiling this module without sql in the module?

    I would not be surprised if the response from IBM is that it is not a bug.
  • lzrycki
    lzrycki
    29 Posts

    Re: A non critical bug in DSNHPC - COBOL ( mainframe)

    ‏2012-09-16T13:04:24Z  
    Doc,

    are not continuation lines only used in ID/Env/Data Divisions.

    though the manual does not explicitly says, can't have them in Procedure Div
    there really is no need to use a continuation line in Procedure Division.

    Have you tried compiling this module without sql in the module?

    I would not be surprised if the response from IBM is that it is not a bug.
    Hi dbzThedinosaur

    COBOL allows the use of continuation lines in all the divisions including Procedure; is a general rule. You can write all the verbs in 2,3,4; for instance

    000001 S
    000002- U
    000002- B
    000003- T
    000004- R
    000005- A
    000006- C
    000007 T 1 FROM WS-VAR

    is valid.

    The same for paragraphs-names.

    If I take out the the INCLUDE and compile directly, no errors.
  • lzrycki
    lzrycki
    29 Posts

    Re: A non critical bug in DSNHPC - COBOL ( mainframe)

    ‏2012-09-16T13:09:29Z  
    • lzrycki
    • ‏2012-09-16T13:04:24Z
    Hi dbzThedinosaur

    COBOL allows the use of continuation lines in all the divisions including Procedure; is a general rule. You can write all the verbs in 2,3,4; for instance

    000001 S
    000002- U
    000002- B
    000003- T
    000004- R
    000005- A
    000006- C
    000007 T 1 FROM WS-VAR

    is valid.

    The same for paragraphs-names.

    If I take out the the INCLUDE and compile directly, no errors.
    when I post the last message the example doesn't look OK.

    In mi example S is in the 12 column, U in the 13, B in 14 , T in 15 , etc
    000001 S
    000002- U
    000002- B
    000003- T
    000004- R
    000005- A
    000006- C
    000007 T 1 FROM WS-VAR
  • dbzThedinosaur
    dbzThedinosaur
    57 Posts

    Re: A non critical bug in DSNHPC - COBOL ( mainframe)

    ‏2012-09-16T16:18:53Z  
    • lzrycki
    • ‏2012-09-16T13:09:29Z
    when I post the last message the example doesn't look OK.

    In mi example S is in the 12 column, U in the 13, B in 14 , T in 15 , etc
    000001 S
    000002- U
    000002- B
    000003- T
    000004- R
    000005- A
    000006- C
    000007 T 1 FROM WS-VAR
    Leonardo,

    Thank you for your response.

    I have to agree with you.

    dbz
  • BillWoodger
    BillWoodger
    133 Posts

    Re: A non critical bug in DSNHPC - COBOL ( mainframe)

    ‏2012-09-25T11:48:55Z  
    I don't have DB2, but maybe for fun you can get a line of code "in front" to the "must be the first line of code for DB2" bit.

    
    .          DISPLAY 
    "BEFORE!" -
    

    
    .          DISPLAY 
    "BEFORE!". -    DISPLAY 
    "AFTER!"
    


    Both of these compile, with a warning.

    The first gets
    
    IGYPS0004-W   A blank continuation source line was found.  The line was discarded.
    


    But by the time it has been discarded, it may already have done its work. The "discard" is due to:

    "Any sentence, entry, clause, or phrase that requires more than one line can be continued in Area B of the next line that is neither a comment line nor a blank line."
    If you force the continuation to a blank line using the "-" in column seven, you get the message but maybe get the actual line of code "in between" the PROCEDURE DIVISION and the header stuff for DB2.

    The second gets:

    
    IGYPS0001-W   A blank was missing before character 
    "D" in column 12.  A blank was assumed.
    


    This is due to:
    "If there is a hyphen in the indicator area of a line, the first nonblank character of the continuation line immediately follows the last nonblank character of the continued line without an intervening space."
    The fullstop/period finishes the first verb off, "allowing" another verb to start on the "next" line, which is a continuation.

    Like you can say:
    
    IF A = B GO TO C END-IF. MOVE B TO A.
    


    Except with the continuation you get to start the next line at the first non-blank in Area B and it is appended to the last non-blank on the previous line.

    If it "works" (fools the precompiler) you could see how much code you can get in "before" the mandatory insertion. Perhaps a whole program, if trivial, using repeated continuations :-)
  • lzrycki
    lzrycki
    29 Posts

    Re: A non critical bug in DSNHPC - COBOL ( mainframe)

    ‏2012-09-25T15:19:24Z  
    I don't have DB2, but maybe for fun you can get a line of code "in front" to the "must be the first line of code for DB2" bit.

    <pre class="jive-pre"> . DISPLAY "BEFORE!" - </pre>
    <pre class="jive-pre"> . DISPLAY "BEFORE!". - DISPLAY "AFTER!" </pre>

    Both of these compile, with a warning.

    The first gets
    <pre class="jive-pre"> IGYPS0004-W A blank continuation source line was found. The line was discarded. </pre>

    But by the time it has been discarded, it may already have done its work. The "discard" is due to:

    "Any sentence, entry, clause, or phrase that requires more than one line can be continued in Area B of the next line that is neither a comment line nor a blank line."
    If you force the continuation to a blank line using the "-" in column seven, you get the message but maybe get the actual line of code "in between" the PROCEDURE DIVISION and the header stuff for DB2.

    The second gets:

    <pre class="jive-pre"> IGYPS0001-W A blank was missing before character "D" in column 12. A blank was assumed. </pre>

    This is due to:
    "If there is a hyphen in the indicator area of a line, the first nonblank character of the continuation line immediately follows the last nonblank character of the continued line without an intervening space."
    The fullstop/period finishes the first verb off, "allowing" another verb to start on the "next" line, which is a continuation.

    Like you can say:
    <pre class="jive-pre"> IF A = B GO TO C END-IF. MOVE B TO A. </pre>

    Except with the continuation you get to start the next line at the first non-blank in Area B and it is appended to the last non-blank on the previous line.

    If it "works" (fools the precompiler) you could see how much code you can get in "before" the mandatory insertion. Perhaps a whole program, if trivial, using repeated continuations :-)
    Hi Bill,

    I found this bug testing a COBOL quality assurance tool; to test this product I force some limit situations. One of quality rules used in one of our clientes says: "Don't use hardcodes in Proc. Division"; because of this I put a test case displaying a hardcode in two lines at the top of Proc. Div..

    The QA product detected the issue, but when I compile the program, DSNHPC had the parse problem that I describe.

    The COBOL compiler with DB2 co-processor works fine with this case.

    Thanks for your comments.

    Regards

    Leonardo
  • BillWoodger
    BillWoodger
    133 Posts

    Re: A non critical bug in DSNHPC - COBOL ( mainframe)

    ‏2012-09-25T16:08:27Z  
    • lzrycki
    • ‏2012-09-25T15:19:24Z
    Hi Bill,

    I found this bug testing a COBOL quality assurance tool; to test this product I force some limit situations. One of quality rules used in one of our clientes says: "Don't use hardcodes in Proc. Division"; because of this I put a test case displaying a hardcode in two lines at the top of Proc. Div..

    The QA product detected the issue, but when I compile the program, DSNHPC had the parse problem that I describe.

    The COBOL compiler with DB2 co-processor works fine with this case.

    Thanks for your comments.

    Regards

    Leonardo
    Hi Leonardo,

    Sorry for any confusion. Whilst putting the response together I "lost" the crucial line which said "Just for fun, maybe you can give this a try". The "you" is no-one specific.

    I was just thinking, you've managed to get some "code", a fragment, in front of DSNSQL SECTION.

    So, would it be possible to get some "real" code in front of it?

    It the precompiler is treating a line with "-" as being the first in the PROCEDURE DIVISION, then the prior line would appear in front of DSNSQL.

    So, can you construct a line of Cobol, with a continuation, which will lead to a valid compile when a SECTION is inserted in between the line and its continuation. Yes, you can (two varieties).

    What I can't test is the actual operating of the precompiler.

    
    .          DISPLAY 
    "BEFORE!". DSNSQL SECTION. SQL-SKIP. GO TO SQL-INIT-END. SQL-INITIAL. MOVE 1 TO SQL-INIT-FLAG. SQL-INIT-END. CONTINUE. - DISPLAY 
    "BEFORE!". DSNSQM SECTION. SQM-SKIP. GO TO SQM-INIT-END. SQM-INITIAL. MOVE 1 TO SQL-INIT-FLAG. SQM-INIT-END. CONTINUE. -    DISPLAY 
    "AFTER!" .
    


    The above are the previous two examples with the "section" inserted in the middle. Compiles.

    If that "works" with the precompiler, then you could, for instance, code

    
    .           DISPLAY 
    "GOODBYE WORLD!". GOBACK. -
    


    Could win a few bets :-)
  • lzrycki
    lzrycki
    29 Posts

    Re: A non critical bug in DSNHPC - COBOL ( mainframe)

    ‏2012-09-25T17:42:13Z  
    Hi Leonardo,

    Sorry for any confusion. Whilst putting the response together I "lost" the crucial line which said "Just for fun, maybe you can give this a try". The "you" is no-one specific.

    I was just thinking, you've managed to get some "code", a fragment, in front of DSNSQL SECTION.

    So, would it be possible to get some "real" code in front of it?

    It the precompiler is treating a line with "-" as being the first in the PROCEDURE DIVISION, then the prior line would appear in front of DSNSQL.

    So, can you construct a line of Cobol, with a continuation, which will lead to a valid compile when a SECTION is inserted in between the line and its continuation. Yes, you can (two varieties).

    What I can't test is the actual operating of the precompiler.

    <pre class="jive-pre"> . DISPLAY "BEFORE!". DSNSQL SECTION. SQL-SKIP. GO TO SQL-INIT-END. SQL-INITIAL. MOVE 1 TO SQL-INIT-FLAG. SQL-INIT-END. CONTINUE. - DISPLAY "BEFORE!". DSNSQM SECTION. SQM-SKIP. GO TO SQM-INIT-END. SQM-INITIAL. MOVE 1 TO SQL-INIT-FLAG. SQM-INIT-END. CONTINUE. - DISPLAY "AFTER!" . </pre>

    The above are the previous two examples with the "section" inserted in the middle. Compiles.

    If that "works" with the precompiler, then you could, for instance, code

    <pre class="jive-pre"> . DISPLAY "GOODBYE WORLD!". GOBACK. - </pre>

    Could win a few bets :-)
    Bill,

    Thanks!

    Regrads

    Leonardo
  • SystemAdmin
    SystemAdmin
    403 Posts

    Re: A non critical bug in DSNHPC - COBOL ( mainframe)

    ‏2013-01-30T21:09:31Z  
    Came across a bug in the Cobol Compiler this week (PP 5655-S71 IBM Enterprise COBOL for z/OS 4.2.0) with an IF statement being processing incorrectly until parathesises are added. It ignores the 2nd evaluation in the IF statement unless parentheses are added to the 4th evaluation in the IF statement. Here is the sample code and results:

    05 WS-TEST1 PIC 9(08) VALUE 20080102.
    05 WS-TEST2 PIC X(01) VALUE 'Y'.
    05 WS-TEST3 PIC X(01) VALUE 'A'.
    05 WS-TEST4 PIC 9(01) VALUE 0.

    IF WS-TEST1 >= 20080101
    AND WS-TEST2 = 'Y'
    IF WS-TEST3 > SPACES
    IF WS-TEST4 = 0 OR 2
    DISPLAY 'IN OLD CODE'.

    IF WS-TEST1 >= 20080101
    AND WS-TEST2 = 'Y'
    AND WS-TEST3 > SPACES
    AND WS-TEST4 = 0 OR 2
    DISPLAY 'IN NEW CODE'
    END-IF

    IF WS-TEST1 >= 20080101
    AND WS-TEST2 = 'Y'
    AND WS-TEST3 > SPACES
    AND (WS-TEST4 = 0 OR 2)
    DISPLAY 'IN NEW CODE WITH PARENS'
    END-IF
    MOVE 2 TO WS-TEST4

    IF WS-TEST1 >= 20080101
    AND WS-TEST2 = 'Y'
    IF WS-TEST3 > SPACES
    IF WS-TEST4 = 0 OR 2
    DISPLAY '2 IN OLD CODE'.

    IF WS-TEST1 >= 20080101
    AND WS-TEST2 = 'Y'
    AND WS-TEST3 > SPACES
    AND WS-TEST4 = 0 OR 2
    DISPLAY '2 IN NEW CODE'
    END-IF

    IF WS-TEST1 >= 20080101
    AND WS-TEST2 = 'Y'
    AND WS-TEST3 > SPACES
    AND (WS-TEST4 = 0 OR 2)
    DISPLAY '2 IN NEW CODE WITH PARENS'
    END-IF
    MOVE SPACE TO WS-TEST2

    IF WS-TEST1 >= 20080101
    AND WS-TEST2 = 'Y'
    IF WS-TEST3 > SPACES
    IF WS-TEST4 = 0 OR 2
    DISPLAY 'SPACE IN OLD CODE'.

    IF WS-TEST1 >= 20080101
    AND WS-TEST2 = 'Y'
    AND WS-TEST3 > SPACES
    AND WS-TEST4 = 0 OR 2
    DISPLAY 'SPACE IN NEW CODE'
    END-IF

    IF WS-TEST1 >= 20080101
    AND WS-TEST2 = 'Y'
    AND WS-TEST3 > SPACES
    AND (WS-TEST4 = 0 OR 2)
    DISPLAY 'SPACE IN NEW CODE WITH PARENS'
    END-IF

    Results:

    IN OLD CODE
    IN NEW CODE
    IN NEW CODE WITH PARENS
    2 IN OLD CODE
    2 IN NEW CODE
    2 IN NEW CODE WITH PARENS
    SPACE IN NEW CODE
  • BillWoodger
    BillWoodger
    133 Posts

    Re: A non critical bug in DSNHPC - COBOL ( mainframe)

    ‏2013-01-31T09:33:35Z  
    Came across a bug in the Cobol Compiler this week (PP 5655-S71 IBM Enterprise COBOL for z/OS 4.2.0) with an IF statement being processing incorrectly until parathesises are added. It ignores the 2nd evaluation in the IF statement unless parentheses are added to the 4th evaluation in the IF statement. Here is the sample code and results:

    05 WS-TEST1 PIC 9(08) VALUE 20080102.
    05 WS-TEST2 PIC X(01) VALUE 'Y'.
    05 WS-TEST3 PIC X(01) VALUE 'A'.
    05 WS-TEST4 PIC 9(01) VALUE 0.

    IF WS-TEST1 >= 20080101
    AND WS-TEST2 = 'Y'
    IF WS-TEST3 > SPACES
    IF WS-TEST4 = 0 OR 2
    DISPLAY 'IN OLD CODE'.

    IF WS-TEST1 >= 20080101
    AND WS-TEST2 = 'Y'
    AND WS-TEST3 > SPACES
    AND WS-TEST4 = 0 OR 2
    DISPLAY 'IN NEW CODE'
    END-IF

    IF WS-TEST1 >= 20080101
    AND WS-TEST2 = 'Y'
    AND WS-TEST3 > SPACES
    AND (WS-TEST4 = 0 OR 2)
    DISPLAY 'IN NEW CODE WITH PARENS'
    END-IF
    MOVE 2 TO WS-TEST4

    IF WS-TEST1 >= 20080101
    AND WS-TEST2 = 'Y'
    IF WS-TEST3 > SPACES
    IF WS-TEST4 = 0 OR 2
    DISPLAY '2 IN OLD CODE'.

    IF WS-TEST1 >= 20080101
    AND WS-TEST2 = 'Y'
    AND WS-TEST3 > SPACES
    AND WS-TEST4 = 0 OR 2
    DISPLAY '2 IN NEW CODE'
    END-IF

    IF WS-TEST1 >= 20080101
    AND WS-TEST2 = 'Y'
    AND WS-TEST3 > SPACES
    AND (WS-TEST4 = 0 OR 2)
    DISPLAY '2 IN NEW CODE WITH PARENS'
    END-IF
    MOVE SPACE TO WS-TEST2

    IF WS-TEST1 >= 20080101
    AND WS-TEST2 = 'Y'
    IF WS-TEST3 > SPACES
    IF WS-TEST4 = 0 OR 2
    DISPLAY 'SPACE IN OLD CODE'.

    IF WS-TEST1 >= 20080101
    AND WS-TEST2 = 'Y'
    AND WS-TEST3 > SPACES
    AND WS-TEST4 = 0 OR 2
    DISPLAY 'SPACE IN NEW CODE'
    END-IF

    IF WS-TEST1 >= 20080101
    AND WS-TEST2 = 'Y'
    AND WS-TEST3 > SPACES
    AND (WS-TEST4 = 0 OR 2)
    DISPLAY 'SPACE IN NEW CODE WITH PARENS'
    END-IF

    Results:

    IN OLD CODE
    IN NEW CODE
    IN NEW CODE WITH PARENS
    2 IN OLD CODE
    2 IN NEW CODE
    2 IN NEW CODE WITH PARENS
    SPACE IN NEW CODE
    I think it would have been better to start a new Topic.

    I don't think you've caught a Bug. I think you've misunderstood how this works. Rather than what you think your IF is equivalent to (the "old" code) here is your "new" IF and following are the parentheses which the compiler will apply.

    
    IF WS-TEST1 >= 20080101 AND WS-TEST2 = 
    'Y' AND WS-TEST3 > SPACES AND WS-TEST4 = 0 OR 2 DISPLAY 
    'SPACE IN NEW CODE' END-IF
    


    
    IF ( ( WS-TEST1 >= 20080101 ) AND ( WS-TEST2 = 
    'Y' ) AND ( WS-TEST3 > SPACES ) AND ( WS-TEST4 = 0 ) ) OR  ( WS-TEST4 = 2 ) DISPLAY 
    'SPACE IN NEW CODE LONG' END-IF
    


    These two IFs generate identical code.

    Here is the output:

    
    IN OLD CODE IN NEW CODE IN NEW CODE WITH PARENS 2 IN OLD CODE 2 IN NEW CODE 2 IN NEW CODE WITH PARENS SPACE IN NEW CODE SPACE IN NEW CODE LONG
    


    It may seem strange that it works this way, but it is supported by the manual (for a quick check, see the first example in Table 33).
  • BillWoodger
    BillWoodger
    133 Posts

    Re: A non critical bug in DSNHPC - COBOL ( mainframe)

    ‏2013-01-31T10:23:10Z  
    I think it would have been better to start a new Topic.

    I don't think you've caught a Bug. I think you've misunderstood how this works. Rather than what you think your IF is equivalent to (the "old" code) here is your "new" IF and following are the parentheses which the compiler will apply.

    <pre class="jive-pre"> IF WS-TEST1 >= 20080101 AND WS-TEST2 = 'Y' AND WS-TEST3 > SPACES AND WS-TEST4 = 0 OR 2 DISPLAY 'SPACE IN NEW CODE' END-IF </pre>

    <pre class="jive-pre"> IF ( ( WS-TEST1 >= 20080101 ) AND ( WS-TEST2 = 'Y' ) AND ( WS-TEST3 > SPACES ) AND ( WS-TEST4 = 0 ) ) OR ( WS-TEST4 = 2 ) DISPLAY 'SPACE IN NEW CODE LONG' END-IF </pre>

    These two IFs generate identical code.

    Here is the output:

    <pre class="jive-pre"> IN OLD CODE IN NEW CODE IN NEW CODE WITH PARENS 2 IN OLD CODE 2 IN NEW CODE 2 IN NEW CODE WITH PARENS SPACE IN NEW CODE SPACE IN NEW CODE LONG </pre>

    It may seem strange that it works this way, but it is supported by the manual (for a quick check, see the first example in Table 33).
    For clarity about the results I showed, I didn't include the new IF in the earlier code, as that code "works" with the values given. I just included it immediately after the "Bug" IF to show the same results.

    When the IFs were re-written, it was a terrible mistake to not simplify that final condition, at least, for the human reader at the time. The compiler will always do what it is told. I don't like to see an IF which is not explicit to the human, as it can never be clear, when there is a query about it, whether it was actually the intention of the original coder.

    I would always code it with all the parentheses I've shown. Human can read it, compiler can read it, and both can agree on expected results.