HP3000-L Archives

June 1997, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"John D. Alleyn-Day" <[log in to unmask]>
Reply To:
John D. Alleyn-Day
Date:
Wed, 11 Jun 1997 00:10:15 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (51 lines)
>Efren wote:
><
>Im still working on the year 2000 project. Im doing a serial read
>using
>cobol, to update the date fields. To update critical items I delete
>the
>record then write the record using the updated fields.  The problem
>is
>that I lose my key so when it goes to read serial again it gives me a
>end of file error.  How can I retain my place after doing a dbput and
>not lose my key for the next serial read ?
>>
>
>Efren,
>    When I read  "down" a chain and need to delete a record and/or
>modify
>a critical item, I either save the record contents or the relative
>record number
>of the record I need to modify. After coursing the chain and saving
>the
>relative record numbers I re-read those records via the relative
>record number,
>delete the record and re-add it via DBPUT after making any
>modifications.
>    Deleting a record in the middle of a chained read and then
>resuming what you
>think is a serial read of the next record will always produce
>problems.

I'm not clear as to whether this is a serial read or a chained read.  There
is an old trick to overcome this problem on chained reads.  For each record
that you modify, you keep the relative record number of the NEXT record
(available in the Image status area).  After dbputting the record, it is
very easy to continue the chained read by reading the next record by
relative record number.  It's a good idea to keep the relative record
number of the LAST record on the chain (also available in the status area
after the dbfind), otherwise you don't know when you have reached the end
of the original chain!  I'm not sure that this would work reliably for a
serial read, because each new record would pick up a spot from the delete
chain, and you could find yourself reading the same record again.

Another possibility is to open the database twice.  Read serially using one
"open" and do the deleting (using relative record numbers) and adding with
the other open.  With a chained read, you will get "broken chain" messages
that you ignore (because the backward pointers won't match).

John D. Alleyn-Day
Alleyn-Day International
408-286-6421   408-286-6474 (Fax)
[log in to unmask]       http://www.Alleyn-Day.com

ATOM RSS1 RSS2