SQLCODE 76288 obtenu suite à un DECLARE de curseur en COBOL

Bonjour,

Je viens d'entrer dans une société qui utilise du COBOL sous Unix avec un SGBD Oracle.
Je n'ai pas l'habitude de travailler sous Cobol (UNIX) + Oracle, habituellement, je travaille en COBOL (IBM) + DB2.

Je ne connais ni la version du compilateur COBOL, ni la version d'Oracle utilisée. Je sais seulement que l'éditeur de texte sur lequel je dois développer s'appelle VI et mon supérieur est absent. Je suis seul au service informatique.

Lorsque j'essaie de déclarer le curseur suivant :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

EXEC SQL DECLARE CURS_CMD CURSOR FOR select cl_cle1 , cl_cle2 , cl_cle3 , cl_cle4 , cl_cle6 FROM cdelig , tranref , appar WHERE cl_ref = tr_ref AND tr_refsto = ap_refep AND ap_refcomp = :SQL-REF ORDER BY cl_cle1 , cl_cle2 , cl_cle3 , cl_cle4 , cl_cle6 END-EXEC.

---

J'obtiens un SQLCODE 76288 et je n'ai absolument rien trouvé sur Internet dans les listes de SQLCODE ou de retour Oracle que j'ai pu trouver.

J'ai vérifié la requête SELECT dans un utilitaire permettant d'exécuter du SQL en remplaçant ":SQL-REF" par une référence valide et elle fonctionne bien.
Le programme où cette requête est exécutée contient bien l'ordre EXEC SQL INCLUDE SQLCA END-EXEC.
La variable utilisée dans la requête est bien décrite entre les ordres
EXEC SQL BEGIN DECLARE SECTION END-EXEC. et EXEC SQL END DECLARE SECTION END-EXEC.

Pouvez-vous me dire ce que signifie le SQLCODE 76288 ?
Éventuellement, si vous connaissez un moyen d'obtenir la version du compilateur COBOL et de l'installation d'Oracle, je suis preneur (et désespérer, ça fait plusieurs jours que je me casse les dents sur ce DECLARE CURSOR).

Cordialement,

[EDIT]
J'ai trouvé la version d'Oracle utilisée : Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

Bonjour,

Un SQLCODE >0 est un message d'information, cela étant, vous avez raison de vouloir en connaitre la signification (information ne veut pas dire à négliger)

Pouvez vous communiquez le message exact et complet que vous obtenez ?

Note : il est préférable de ne JAMAIS mettre de point dans le code cobol, sauf en fin de §.
à ses début, cobol ne connaissait pas de END instruction, le point en faisait office, et c'est resté pour raison de compatibilité ascendante.
Du coup vous risquez de générer un END-IF ou autre END instruction à votre insu ;)

Merci pour vos réponses. :)

Je suis au courant pour les points en COBOL, mais je reprends du vieux code alors je me conforme à ce qui est déjà fait (oui, c'est sale et moche et ça me fait un peu mal de coder comme ça).

En fait, je n'ai pas plus de données que ça, je ne récupère que le SQLCODE y a-t-il des données autres que le SQLCODE que je pourrais récupérer pour avoir plus d'informations ?
Vous me dites que les SQLCODE > 0 sont informatifs, je peux donc ignorer ce code et procéder aux OPEN, FETCH et CLOSE sur mon curseur comme si de rien n'était ?

Cordialement,
Moriar.

A priori, il s'agissait d'un problème de connexion à Oracle. J'ai résolu le problème en ajoutant le code suivant avant le DECLARE :

Code:

---

1 2 3 4 5 6

EXEC SQL CONNECT :ORAUSER IDENTIFIED BY :ORAPASS USING :ORASERV END-EXEC. END-EXEC

---

Maintenant, j'ai un autre problème, ce code est situé dans un sous-programme COBOL.
Le premier appel fait un DECLARE, suivi d'un OPEN et d'un premier FETCH et revoie la ligne lue.
Les autres appels font simplement un FETCH qui revoie la nouvelle ligne lu.

Un paramètre "ORDRE" peut prendre 3 valeurs :
1 : Declare + Open + Fetch
2 : Fetch + Close si on est en fin de curseur
3 : Close (pour forcer un CLOSE si on ne veut pas lire tout le curseur)

Le premier appel se déroule correctement et me retourne la 1ère ligne que j'attends.

Mais le deuxième appel me retourne un SQLCODE -1001
En cherchant sur le net j'ai trouvé ça :

Citation:

---

ORA-01001 invalid cursor

Cause: Either a host language program call specified an invalid cursor or the value of the MAXOPENCURSORS option in the precompiler command were too small. All cursors must be opened using the OOPEN call before being referenced in any of the following calls: SQL, DESCRIBE, NAME, DEFINE, BIND, EXEC, FETCH, and CLOSE. The Logon Data Area (LDA) must be defined by using OLON or OLOGON. If the LDA is not defined, this message is issued for the following calls: OPEN, COM, CON, ROL, and LOGOFF.

Action: Check the erroneous call statement. Specify a correct LDA area or open the cursor as required. If there is no problem with the cursor, it may be necessary to increase the MAXOPENCURSORS option value before precompiling.

The ORA-01001 error occurs when:

a host language program call gave an invalid cursor for use
the value of the MAXOPENCURSORS option in the precompiler command was too small

You can fix the ORA-01001 error by:

Check your problematic call statement for any issues
Specify a correct LDA area or open the cursor as required
As a last resort, increase the MAXOPENCURSORS option value before precompiling

---

Cela signifie-il que mon CURSEUR se perd entre 2 appels au module ? Une réponse positive m'étonnerait puisque c'est comme cela que je procédais chez certains de mes anciens clients pour lire un curseur (certains clients interdisent le SQL directement dans les programmes principaux).

Si c'est bien le cas, comment puis-je faire pour ne pas perdre le CURSEUR ?

[EDIT]
J'ai trouvé, en fait, il ne faut pas faire la connexion à ORACLE à chaque fois, mais seulement avant le DECLARE.