We are using RBD 8.5.1.1. We have two cursors defined and running in 2 while loop. Code would look like this.

1st Cursor Open
While(SQL = 0)
   Get Next 1st Cursor
   if(SQL = 0)
      2nd Cursor Open
      while(SQL = 0)
         Get Next 2nd Cursor
     Close 2nd cursor
Close1st Cursor.

Here when the 2nd cursor's get next statement reaches end of record it returns SQL 100. After which close 2nd cursor is performed. When its performed, the SQLData.Sqlcode is still says 100. I suspect this should be changed to 0.

So, my question is will close cursor returns SQL code after its being executed? I see its giving SQL 100. But in debug of this program works perfectly fine.. In the generated version I see the SQL code after closing the cursor is not changed., Instead I see 2nd cursor's SQL code..

Can someone assist with this problem please?

Thanks
Naveen

Hi Naveen,

I did a sample COBOL programa and it returns sqlcode 100 on last fetch, after cursor close it return sqlcode 0.

I believe your question is a bug of RBD.

regards,

Hsieh

Naveen,

Couple of questions:

- Does the problem occur with COBOL Generation or Java Generation?

- Are the cursors using the same record?

- Assume you are using separate Result IDs.

- Are you issuing explicit CLOSE statements or letting the cursor close on its own when the Get Next returns a SQL Code 100 (as EGL will close it in this case).

- I am a little confused.   Do you want the SQLCode to be set to 100 or set to 0 after the CLOSE. 

Mark

Hi Mark,

Its generated to COBOL. Yes, there are two cursor's for 2 different tables and 2 different result ID's.

I am using an explicit CLOSE cursor statement after Get Next returns SQL 100. I am expecting SQL 0 after this explicit CLOSE statement. Instead it returns 100.

This explicit CLOSE is written with HPS (Bluephonix app builder - third party tool) which is converted to EGL and generated to COBOL. So during the conversion process this statement(explicit close) is replicated with EGL. If the cursor is closed when Get Next SQL returns 100, then I have to adapt the conversion tool accordingly.

Please share your thoughts.

Thanks.,

Naveen,

I would suspect that the get next loop, when the rc=100 would issue a close cursor for you, that the explicit coding of the close statement is not required. Because the close is done for you, the close cursor statement does not clobber the get next's rc and that is why the 100 is still set.

Hi Jeff,

If thats the case, then I would expect -501(THE CURSOR IDENTIFIED IN A FETCH OR CLOSE STATEMENT IS NOT OPEN) as SQL during the explicit CLOSE operation. Which is not the case. This is very confusing.

Thanks.

Hi,

One way to know what explicitly is being returned on the different statements and interactions with SQL is to generate with statementTrace=yes.   This will generate a DISPLAY statement for each EGL statement and DISPLAY all the SQLcodes for each SQL i/o.

While we can research it, can you run this for your program and send us the results.   In CICS, this output is directed to the CEEMSG DD statement in the CICS job and in batch, it is directed to SYSOUT.

thanks.

Mark

Hi Mark,

Please find the attached CEEMSG Dump and EGL program for your reference, I have added some comments with the program.

Thanks

It looks to me from the statement trace that it is doing exactly what I suggested. That the rc=100 from the get triggers the automatic close of the cursor, but because we do that, we don't clobber the 100 rc, as you might want to interrogate it during the exception.

As for the close statement you issue, the statement trace shows that we already know the cursor is closed and we simply ignore the statement in that case.

I suspect that you really don't need to code the close statements in our example, because the cursor will be closed for you.