As suggested, I've taken a second look at dsql_set_cursor_name.

Background: I have many Microfocus COBOL programs that work fine on
versions of IB prior to IB6.0.

When accessing IB60 from a Microfocus COBOL (now Merdant I believe) my
programs will randomly receive a -502 error message when executing an OPEN
cursor statement:

Dynamic SQL Error
-SQL error code = -502
-Declared cursor already exists

Meditating on the randomness of this problem I was stuck by the thought:
COBOL doesn't use null terminated strings.


Studying GDS_DSQL_SET_CURSOR I see:

USHORT i;
length = name_length (input_cursor);
for (i=0; i<length && i< sizeof(cursor)-1; i++)
cursor [i] = UPPER7 (input_cursor [i]);
cursor [i] = '\0';

where, I believe, name_length is expecting a null terminated string.

name_length contains the coding:

q = name - 1;
for (p = name; *p; p++)
{
if (*p != BLANK)
q = p;
}
return (USHORT) ((q+1) - name);


If name_length is counting too far in memory, then the cursor name as seen
by Interbase will include other COBOL variables -- and therefore would be
subject to change while the program is running. If the cursor name had
appeared to change, then the coding in GDS_DSQL_SET_CURSOR would not be able
to detect that the same cursor is being reopened, and then when it detected
that a name had already been stored: -502.


I'm now contemplating changing the above code with:

USHORT i;
for (i=0; i < sizeof(cursor)-1
&& input_cursor[i]
&& input_cursor[i] != BLANK; i++)
cursor [i] = UPPER7 (input_cursor [i]);
cursor [i] = '\0';


Opinions?

Thanks,
...pat