Alternate keys 1

[coboldean]

I am new to programming in acu-cobol and am writing a program that scrolls through a file using an alternate key. The user can select a record on the screen, modify it and then scroll to the next record.

The problem I have is when I rewrite the record modified and then attempt a read next record, the program seems to read the next record based on the primary key rather than the alternate.

Any ideas?

We are running acucobol gt ver 5.2.0.1 on SCO Unix

 

[fredericofonseca]

It would seem that you are using the same "logical" file to write the record.
One way to get around this is to have two files defined within the program, use one for input and the other one to updates.

so you search on one file, and if you need to update you either to a direct rewrite, or if you need to be sure no one else is updating the same record you do a read, compare fields, rewrite record if OK.



Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

 

[CobolKid]

Add the KEY IS clause to your read statement.

[KEY IS {data-name-1} ... ] replace data-name-1 with the name you gave to the alternate key.

 

[webrabbit]

If your alternate key is unique, do a START GREATER on the specified alternate key. If not, you will have to use two logical files as fredericofonseca says.

I try to avoid using non-unique alternate keys for this problem. The easiest way to avoid them is to add the primary key to the end of the alternate key definition.

The only condition I have found where non-unique alternate keys are usefull is where a significant number of records can be removed from the key structure using SUPPRESS.

 

[MuadDubby]

Sorry guys ...

Maybe I'm putting my foot in my mouth, but I don't see how doing a REWRITE would change or reset your current file pointer. All you're doing is rewriting a record. You're not issuing a START ...

Are you sure you're not doing anything other than the REWRITE in between READs? And is it the same READ you're executing? i.e. - it's the same READ NEXT as the one used when just scrolling through the records?

Any chance you could post your code (or the pertinent part of it) here for review?

.DaviD.

 

[Dimandja]

What davidk13 said.

I too haven't heard of a REWRITE affecting READ NEXT in that way. Is this a "faulty" compiler, or is it "faulty" code?

The only thing I know for sure is that REWRITE may flush your cache -- slowing down your process.

 

[k5tm]

The 1985 and 2002 COBOL standards specificly provide that: "The file position indicator in the rewrite file connector is not affected by the execution of a REWRITE statement."

Tom Morrison

http://www.liant.com

 

[Dimandja]

k5tm, you meant "The REWRITE statement does not affect the File Position Indicator", right?

 

[coboldean]

Hello All

I changed the program to use a different logical file and that solved my problem. I do appreciate the input.

I beleive the pointer is getting changed when I re-read the record with a lock prior to the user changing it. That is to say I display the records, the user selects a record to change, I read that record with a lock and then rewrite the record.

Thanks for the help.

Dean

 

[MuadDubby]

Yes, re-reading the record would most definitely do that. Your current sort order (or selected key) is changed when you read other than through a READ NEXT.

Can you not issue a LOCK statement to lock the record without performing an IO function on that file?

.DaviD.

 

[fredericofonseca]

No. COBOL does not allow that.

If you are doing a "read next no lock" as a good practice to avoid locking records when not needed, then the only good way to lock the required record is to use another logical as I sugested.

Another way is

read next no lock
+
read with lock
+
write
+
read next no lock.

Now the above will only work if the logical being read does NOT have duplicates.
Now if we are doing a read next with lock then the rewrite will not affect the record pointer position, and the next read should return the next record.

Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com