Answer / ns

There is no difference. But it is always better to declare
Cursor in Working-Storage Section because you will not code
Open Cursor before Declare Cursor by mistake. It is just a
standard to declare Cursor in WSS. As best practice to
avoid oversight.

Answer / arthi

Please refer the answer by Marcus_A here:
http://www.dbforums.com/db2/896592-cursor-declaration.html

This is the most concise answer I could find on the net, and it proves that there is no difference in the placement of the declare cursor.

Quoting from the page:

==============
The Declare Cursor SQL statement is not a procedural SQL statement. It is actually part of the Open statement for the Cursor it refers to, and can be placed anywhere in program source code as long as it is physically before the Open SQL statement. It can actually be placed in the Identification Division, although traditionally it is placed in the Working Storage Section.

If you were to examine the compile listing of your program, you will see that the DB2 pre-compiler did not generate a separate call to DB2 for the Declare Cursor (since it is really part of the Open statement for that Cursor).

The problem with placing the Declare Cursor in the Procedure Division is that programmers invariably place code right after the Declare Cursor to check the SQL return code. So what ends up happening is that the SQL code of a previously executed SQL statement gets checked by the program, and if a non-zero return code is acceptable (not an abend condition) for a previous Select statement (such as return code +100), then the program will get confused and often think an abend condition has occurred.

So, if you do put the Declare cursor in the Procedure Division (not a good idea in my opinion) then make absolutely sure that no user code is executed to check the SQL return code for Declare Cursor.

==============

Answer / krishna

Since declare cursor is not a executable statement hence it
might be declared in WSS.I am not sure...

Answer / sathish

This can be declared in both the sections. But not sure
what is the diff.

Answer / bud gobbel

Actually, there is a reason for declaring the cursor in the Procedure Division, however, it is slight.

In CICS programs, the communications area (CA) is passed via the linkage section. If a cursor WHERE clause is predicated on a field in the CA area, then to avoid using a working storage variable and a MOVE statement prior to the opening of the cursor, you should code the cursor declaration in the Procedure Division, prior to the opening logic, etc.

If you don't mind using extra variables, and coding the required MOVE statements, then keep your cursor dec in WS.

In your DB2 pre-compiler, you can test this logic. Put the cursor above the linkage section, and try to use a field in the linkage section as a host variable in the where clause.

Then move it to the very early part of the Procedure Division. The pre-compiler will then be happy.

Good Luck!

Answer / budgobbel

In CICS programs, data is passed in the Communications Area (CA) via the Linkage Section.

If your cursor is predicated (WHERE clause) on a field in the CA, you could code your cursor early in the Procedure Division prior to any open cursor logic. This will avoid using additional variables, and MOVE statements.

If you keep your cursor in the Working Storage area, you cannot use fields in the Linkage section as host variables, because the DB2 pre-compiler will see the cursor first, and NOT have a resolution for the host variable (it hasn't seen the Linkage Section, yet).

It mostly is up to you, unless your shop is a stickler on variables and locations, etc.

Also, over the years I have seen shops become more code-it-and-load-it in philosophy. Very sad.

Answer / sam

yes there sre diffrence.
If we declare cursor in working storage section then it is
called as static cursor without parameters from cobol.

If we declare cursor in procedure division then we can use
COBOL variables as parameters to the cursor. See the
examples for both the cases...

Eg: STATIC CURSOR

WORKING-STORAGE SECTION.
01 HV-EMPNO PIC 9(4) value 7934.
EXEC SQL
DEFINE C1 CURSOR FOR SELECT * FROM EMP WHERE EMPNO=HV-EMPNO
END-EXEC.

In the above case EMPNO is static. We cannot move a value
or read a value in to empno, because it is in working
storage section.

DYNAMIC CURSOR:

PROCEDURE DIVISION.
ACCEPT HV-EMPNO.
EXEC SQL
DECLARE C1 CURSOR FOR SELECT * FROM EMP WHERE EMPNO=:HV-
EMPNO
END-EXEC.

In the above example we can read EMPNO from another table
or file or we can take it from user. Now cursor becomes
dynamic.

I hope now its clear for you. If you need more information
let me know.

Answer / lu

I never see the cursor declared in WSS..only in Procedure
division...

What is isolation level?

4 Answers  

What is the function of the Data Manager?

2 Answers  

Can we use group-by clause in sub-query? If 'yes' means,Will it be executed successfully or else If 'no' means why should we not using that method? Give me your suggestion please....

1 Answers  

What is release/acquire in bind?

0 Answers  

What is the maximum length of a column name in DB2? 18 or 30 or anything other than these?

4 Answers  

What is correlation names?

1 Answers  

Is ibm db2 open source?

0 Answers  

What are catalog tables in db2?

0 Answers  

Suppose the outcome of executing a query results in a row having null. Based on the answer how you use it? Its declaration and inclusion?

2 Answers   Verizon,

What is null indicator in db2?

0 Answers  

Which command is used to connect to a database in DB2 ? Give the Syntax.

0 Answers   MCN Solutions,

What if we try to insert the base table through updatable view , but failed to give a column value which is defined as NOT NULL.

1 Answers   Cap Gemini,