Topic
11 replies Latest Post - ‏2013-01-31T10:23:10Z by BillWoodger
lzrycki
lzrycki
29 Posts
ACCEPTED ANSWER

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
    ACCEPTED ANSWER

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

    ‏2012-09-15T16:35:46Z  in response to lzrycki
    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
      ACCEPTED ANSWER

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

      ‏2012-09-16T13:04:24Z  in response to dbzThedinosaur
      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
        ACCEPTED ANSWER

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

        ‏2012-09-16T13:09:29Z  in response to lzrycki
        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
          ACCEPTED ANSWER

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

          ‏2012-09-16T16:18:53Z  in response to lzrycki
          Leonardo,

          Thank you for your response.

          I have to agree with you.

          dbz
  • BillWoodger
    BillWoodger
    83 Posts
    ACCEPTED ANSWER

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

    ‏2012-09-25T11:48:55Z  in response to lzrycki
    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
      ACCEPTED ANSWER

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

      ‏2012-09-25T15:19:24Z  in response to BillWoodger
      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
        83 Posts
        ACCEPTED ANSWER

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

        ‏2012-09-25T16:08:27Z  in response to lzrycki
        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
          ACCEPTED ANSWER

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

          ‏2012-09-25T17:42:13Z  in response to BillWoodger
          Bill,

          Thanks!

          Regrads

          Leonardo
  • SystemAdmin
    SystemAdmin
    403 Posts
    ACCEPTED ANSWER

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

    ‏2013-01-30T21:09:31Z  in response to lzrycki
    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
      83 Posts
      ACCEPTED ANSWER

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

      ‏2013-01-31T09:33:35Z  in response to SystemAdmin
      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
        83 Posts
        ACCEPTED ANSWER

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

        ‏2013-01-31T10:23:10Z  in response to BillWoodger
        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.