MVSFORUMS.com Forum Index MVSFORUMS.com
A Community of and for MVS Professionals
 
 FAQFAQ   SearchSearch   Quick Manuals   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Compilation error using SPECIFIC cursor name

 
Post new topic   Reply to topic   printer-friendly view    MVSFORUMS.com Forum Index -> Application Programming
View previous topic :: View next topic  
Author Message
misi01
Advanced


Joined: 02 Dec 2002
Posts: 614
Topics: 171
Location: Stockholm, Sweden

PostPosted: Fri Apr 14, 2023 4:12 am    Post subject: Compilation error using SPECIFIC cursor name Reply with quote

I've just run into what seems like a very weird compiler error.
The standard we use here for cursor names is based on part of the table name and a cursor number starting at 500, for example 6B0-500.
(this example is based on a table called HFAT6B0).
Now we have a table called HFAT6E0, and using the same standard, I'm calling the cursor 6E0-500.
And guess what, I keep getting a compiler error with the following message
Quote:

IGYPS0226-E DSNH104I DSNHPARS LINE 532 COL 14 ILLEGAL SYMBOL "6E0". SOME SYMBOLS THAT MIGHT BE LEGAL ARE: <IDENTIFIER> : GLOBAL

Here is the actual declare cursor
Code:

*                                                           
      DECLARE 6E0-500 CURSOR WITH HOLD FOR                   
       SELECT                                               
*             PNR                                           
*            ,ATERBETALNINGSAR                               
              FNR                                           
*            ,REG_TMSTP                                     
*            ,UPD_TMSTP                                     
         FROM HFAT6E0                                       
*     (MSSQLG06)                                             
        WHERE PNR              = :HFAT6E0-HS.PNR             
          AND ATERBETALNINGSAR = :HFAT6E0-HS.ATERBETALNINGSAR
*         AND FNR              = :HFAT6E0-HS.FNR             
*    The DL/1 segments don't seem to be in any order         
                                                             
     END-EXEC.                                               
*                                                           
     EXEC SQL                                               

If I change the cursor name to 6F0-500 and nothing else in the code, the compilation is successful.
If I take another, existing, program that has compiled okay and change its cursor name from 6B0-500 to 6E0-500 and compile it, compiler error as above.

Any test suggestions gratefully received.
The workaround of using 6F0-500 works fine, but I keep wondering what's so "magical" about 6E0.
_________________
Michael
Back to top
View user's profile Send private message Send e-mail
kolusu
Site Admin
Site Admin


Joined: 26 Nov 2002
Posts: 12354
Topics: 75
Location: San Jose

PostPosted: Fri Apr 14, 2023 9:53 am    Post subject: Reply with quote

misi01,

Couple of things to check.

1. Ensure your SQL statements start at or after position 12.
2. Ensure you don't have line numbers
3. If the table HFAT6E0 is being defined in the program, move the cursor definition before the table definition.
_________________
Kolusu - DFSORT Development Team (IBM)
DFSORT is on the Web at:
www.ibm.com/storage/dfsort

www.linkedin.com/in/kolusu
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Robert Sample
Beginner


Joined: 15 Dec 2009
Posts: 12
Topics: 0
Location: Atlanta

PostPosted: Tue Apr 18, 2023 9:38 am    Post subject: Reply with quote

6E0 could be getting treated as an exponent number while 6F0 would not be.
Back to top
View user's profile Send private message
misi01
Advanced


Joined: 02 Dec 2002
Posts: 614
Topics: 171
Location: Stockholm, Sweden

PostPosted: Wed Apr 26, 2023 4:05 am    Post subject: Reply with quote

Interesting thought Robert. The work-around is so trivial (although it results in not following our "naming" standards") that we're going with 6F0-500.

At the same time, we've forwarded the question to IBM.
_________________
Michael
Back to top
View user's profile Send private message Send e-mail
misi01
Advanced


Joined: 02 Dec 2002
Posts: 614
Topics: 171
Location: Stockholm, Sweden

PostPosted: Wed Apr 26, 2023 4:06 am    Post subject: Reply with quote

kolusu wrote:
misi01,

Couple of things to check.

1. Ensure your SQL statements start at or after position 12.
2. Ensure you don't have line numbers
3. If the table HFAT6E0 is being defined in the program, move the cursor definition before the table definition.


Thanks for the thoughts, but if any of your ideas was correct, the 6F0-500 cursor usage would fail as well, wouldn't it?
_________________
Michael
Back to top
View user's profile Send private message Send e-mail
kolusu
Site Admin
Site Admin


Joined: 26 Nov 2002
Posts: 12354
Topics: 75
Location: San Jose

PostPosted: Wed Apr 26, 2023 7:53 am    Post subject: Reply with quote

misi01 wrote:

Thanks for the thoughts, but if any of your ideas was correct, the 6F0-500 cursor usage would fail as well, wouldn't it?


misi01,

Pay attention to what I said

Kolusu wrote:

3. If the table HFAT6E0 is being defined in the program, move the cursor definition before the table definition.

_________________
Kolusu - DFSORT Development Team (IBM)
DFSORT is on the Web at:
www.ibm.com/storage/dfsort

www.linkedin.com/in/kolusu
Back to top
View user's profile Send private message Send e-mail Visit poster's website
misi01
Advanced


Joined: 02 Dec 2002
Posts: 614
Topics: 171
Location: Stockholm, Sweden

PostPosted: Thu Apr 27, 2023 10:13 am    Post subject: Reply with quote

If I did as you meant (and I'll include the code), then that didn't work either.

Still don't really understand your thinking here. Unless Robert is correct in his exponential thinking, I can't see why the order of the declare cursor and table definition would make any difference on the basis of changing the cursor name from 6e0-500 to 6f0-500 or vice versa
I get the idea that the procedure division can't have the ftehc or close of the cursor before the open/declare, but otherwise it seems very strange to me.
Anyway, here is the code
Code:

working-storage section

      *                                                               
           EXEC SQL                                                   
             INCLUDE SQLCA                                           
           END-EXEC.                                                 
      *                                                               
           EXEC SQL                                                   
            DECLARE 6e0-500 CURSOR WITH HOLD FOR                     
             SELECT                                                   
                    FNR                                               
               FROM HFAT6E0                                           
              WHERE PNR              = :HFAT6E0-HS.PNR               
                AND ATERBETALNINGSAR = :HFAT6E0-HS.ATERBETALNINGSAR   
      *    The DL/1 segments don't seem to be in any order, but we   
      *    CAN return them from DB2 in order                         
              order by fnr asc                                       
           END-EXEC.                                                 
      *                                                               
       01  FILLER                  PIC X(20) VALUE ALL '**HFAT6E0**'.
           EXEC SQL                                                   
             INCLUDE HFAT6E0     <<- contains EXEC SQL DECLARE HFAT6E0 TABLE and the cobol variable definitions                                     
           END-EXEC.                                                 

      *                                                               

procedure division

      *    EXEC SQL                                                 
      *                                                             
      *     DECLARE 6F0-500 CURSOR WITH HOLD FOR                   
      *      SELECT                                                 
      *             FNR                                             
      *        FROM HFAT6E0                                         
      *       WHERE PNR              = :HFAT6E0-HS.PNR             
      *         AND ATERBETALNINGSAR = :HFAT6E0-HS.ATERBETALNINGSAR
      *    The DL/1 segments don't seem to be in any order, but we 
      *    CAN return them from DB2 in order                       
      *       order by fnr asc                                     
      *                                                             
      *    END-EXEC.                                               
      *                                                             
           EXEC SQL                                                 
             OPEN 6e0-500                                           
           END-EXEC.                                               

error handling, followed by

           EXEC SQL                         
              FETCH 6e0-500                 
               INTO                         
                    :HFAT6E0-HS.FNR         
           END-EXEC.                         



The compiler error I'm getting is
Quote:

570 IGYPS0226-E DSNH016I DSNHPARS LINE 570 COL 12 "<IDENTIFIER>" REQUIRED

570 IGYPS0226-E DSNH104I DSNHPARS LINE 570 COL 12 ILLEGAL SYMBOL "6E0". SOME SYMBOLS THAT MIGHT BE LEGAL ARE: <IDENTIFIER>

596 IGYPS0226-E DSNH104I DSNHPARS LINE 596 COL 14 ILLEGAL SYMBOL "6E0". SOME SYMBOLS THAT MIGHT BE LEGAL ARE: INSENSITIVE
SENSITIVE WITH NEXT PRIOR FIRST LAST CURRENT

633 IGYPS0226-E DSNH016I DSNHPARS LINE 633 COL 13 "<IDENTIFIER>" REQUIRED

633 IGYPS0226-E DSNH104I DSNHPARS LINE 633 COL 13 ILLEGAL SYMBOL "6E0". SOME SYMBOLS THAT MIGHT BE LEGAL ARE: <IDENTIFIER>


Just to confirm, I made no changes in the code other than the cursor name changing to 6f0-500. Result - no compilation errors.
_________________
Michael
Back to top
View user's profile Send private message Send e-mail
misi01
Advanced


Joined: 02 Dec 2002
Posts: 614
Topics: 171
Location: Stockholm, Sweden

PostPosted: Wed Jun 14, 2023 3:48 am    Post subject: Reply with quote

Here's what IBM said
Quote:

We were puzzled though, since it is not uncommon to see a dash used in SQL
identifier names in a COBOL program. We also noted that your cursor names
6B0-500 and 6E0-500 fail on 2 accounts (i.e. they do not start with an upper
case letter and contain a dash). Therefore, we were wondering why both cursor
names not flagged by the coprocessor, but rather only 6E0-500 was.
After more investigation, it was determined that Db2 has some special rules for
COBOL programs such that it tries to accept valid COBOL data names for SQL
identifiers. This is the reason why the customer can declare cursors with names
like 6B0-500 or 6F0-500 in a COBOL program. However, the letter "E" between
two numbers, as in 6E0-500 is actually interpretted by the Db2 parser as a floating
point constant, which cannot be used as a cursor name. This is why it gets
flagged and 6B0-500 does not.

If 6E0-500 is a valid COBOL data name, then the Db2 Support team agrees that Db2
should accept it as a cursor name in COBOL program. However, they also view this
as something of an edge case, and are uncertain about the cost and difficulty of fixing
it.
Given that, they would like to know your thoughts. Are you able to skip the letter "E"
in your naming convention, or alter your naming convention so that the cursor name
does not begin with a number followed by "E" and another number. Would you consider
using that work-around and allowing Db2 to clarify the information in their documentation?


So, Robert, you were quite correct. We have also instructed IBM to ignore this "esoteric" problem since the workaround is so trivial.
_________________
Michael
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic   Reply to topic   printer-friendly view    MVSFORUMS.com Forum Index -> Application Programming All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


MVSFORUMS
Powered by phpBB © 2001, 2005 phpBB Group