Joined: 02 Dec 2002 Posts: 629 Topics: 176 Location: Stockholm, Sweden
Posted: Fri Apr 14, 2023 4:12 am Post subject: Compilation error using SPECIFIC cursor name
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
Joined: 26 Nov 2002 Posts: 12376 Topics: 75 Location: San Jose
Posted: Fri Apr 14, 2023 9:53 am Post subject:
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
www.linkedin.com/in/kolusu
Joined: 02 Dec 2002 Posts: 629 Topics: 176 Location: Stockholm, Sweden
Posted: Wed Apr 26, 2023 4:05 am Post subject:
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
Joined: 02 Dec 2002 Posts: 629 Topics: 176 Location: Stockholm, Sweden
Posted: Wed Apr 26, 2023 4:06 am Post subject:
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
Joined: 02 Dec 2002 Posts: 629 Topics: 176 Location: Stockholm, Sweden
Posted: Thu Apr 27, 2023 10:13 am Post subject:
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
Joined: 02 Dec 2002 Posts: 629 Topics: 176 Location: Stockholm, Sweden
Posted: Wed Jun 14, 2023 3:48 am Post subject:
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
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
FAQ
Search
Quick Manuals
Register
Profile
Log in to check your private messages
Log in
