Mixing SQL and traditional I-O in an ILE COBOL program

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Fred - 27 Mar 2006 18:24 GMT

I am trying to convert an existing COBOL app from using exclusively
tradional I-O (READ verb) to using a mix of traditional and and SQL.
Please don't ask why, my question is conceptual. After populating a
cursor from table A and displaying on the screen, a user makes a change
to record #2. The program tries to read record #2 using traditional
COBOL READ COMMAND in order to update it, yet gets an INVALID KEY
condition because the record has a lock on it from building the cursor.
My problem is that I cannot find how to release the lock on the record.
I have tried declaring cursor as insensitive, changed commitment level
to *CHG, closed the cursor before reading the record, all to no avail.
I am obviously conceptually deficient about how to define a "read only"
cursor that does not place a lock on the records, or how to release a
lock on a record in an ILE COBOL program. Thanks in advance for any
suggestions.

Reply to this Message

Phil Sherman - 28 Mar 2006 07:26 GMT

Your explanation of what you are doing is too vague to determine what is
happening. Try again with a better explanation of what you are trying to
do. Be sure to specify what type of traditional files you are using
(sequential , VSAM KSDS, VSAM RRDS, ISAM, etc) and please keep your
nomenclature consistant. Use ROW or TUPLE for table references and
RECORD for file access. Specify clearly where the data comes from and
exactly what you are trying to update.

Note that programs that read data and present it to a user can cause
data availability issues. The classic case is the user who leaves the
data displayed (and progarm waiting) while taking an hour lunch break.

Philip Sherman

> I am trying to convert an existing COBOL app from using exclusively
> tradional I-O (READ verb) to using a mix of traditional and and SQL.
[quoted text clipped - 10 lines]
> lock on a record in an ILE COBOL program. Thanks in advance for any
> suggestions.

Reply to this Message