VAX/VMS - Record Locking for a Indexed File in command Procedure

[Curious_1]

Hi,

I would like to know, whether it is possible, to do a record locking for an indexed file, through a command procedure.

It would be great if you could respond at the earliest.

[Hein van den Heuvel]

When using RMS through DCL you will be using the RMS feature called "Automatic Locking".

$open/read/write/share=write file name
$read[/key=&var][/ind=n] file record

Now that record is locked.
$write/update will update and unlock

$read file record will unlock that last record, read the next record and lock it.

There is also $read/nolock which will request the RMS options RRL and NLK.

Check the RMS Ref Manual for futher details... or just try.

What problem are you trying to solve?
Hein.

[Curious_1]

Thanks a lot Hein.

The issue is this
A program needs to update a Indexed file (which will be a permanent file). Instead of having the program update the indexed file, we were planning to have the program write into Sequential file, then use either 'MERGE' or 'APPEND' command to add these records from the Sequential file into the Indexed file. However there could be other processes which might want to update the file, so we needed to figure out how we could use the DCL, so that a Record level Locking/unlocking can be performed through the DCL.

Will greatly appreciate your help on this one.

[Hein van den Heuvel]

Hmm, I kinda fail to see the link between the current problem and the original question. Oh well.

>> The issue is this
A program needs to update a Indexed file (which will be a permanent file).

By using a process permanent file you get some nice flexibility, and if the program activated frequently you will avoid file open overhead, but otherwise you will be creating a serious (performace) handicap for the program in question.
It will not be able to use a bunch of local buffers, no global buffers, and no rms stats to know what is happening.
WHY go that route? Just open the darn file in the program and deal with it?!

>> Instead of having the program update the indexed file, we were planning to have the program write into Sequential file, then use either 'MERGE' or 'APPEND' command to add these records from the Sequential file into the Indexed file.

Sure, not unreasonable for certain usage, but mostly why not just add those records there and then?! Why stage? You better have a good answer (no need to share it) otherwise you probably should not be going this route.

You don't want to use DCL APPEND to add records to indexed files. It's not natural, and too easily leads to odd errors like:
"$ append tt: pass.tmp
%APPEND-E-OPENOUT, error opening PASS.TMP;1 as output
-RMS-F-LEX, invalid $EXTEND for area 0 containing an unused extent"

Use CONVERT/MERGE

Anyway, MERGE requires unshared access and sorted records. Limiting.
You could us a simple DCL loop to read from sequential and $WRITE/SYMBOL to the indexed file, but again it would suffer from a needles restrictive performance environment.

I'll attach a trivial macro program which can be used to read one file and insert into an other, shared and unsorted. Mind you, sorted data will work faster.

fyi... I am working on a very flexiible merge file program (supporting primary key based file compares, puts, deletes and updates) which may or mght not make it in time for the next freeware release.

>> However there could be other processes which might want to update the file, so we needed to figure out how we could use the DCL,

Why DCL? What's so good about it for your purpose?
Why worry about locks in this case?
Adding record you do not run into lock problems.

>> so that a Record level Locking/unlocking can be performed through the DCL.

Why? Just add a record, and then the next. repeat until done and close file.

Hope this helps,

Hein,
HvdH Performance Consulting.

[John Gillings]

Curious,

I'm also struggling to understand the problem.

>However there could be other processes >which might want to update the file,

It sounds like you want a FILE lock, rather than a RECORD lock. If the other processes can deal with a FLK error, you could open the the file you want to protect exclusively:

$ OPEN/READ/NOSHARE LOCKED file
$ ! now process the file LOCKED (must use the PPF logical name...)

Other files attempting to update the file will get:
RMS-E-FLK, file currently locked by another user
They should back off a while and retry.

If another process already has the file open for shared access, the process issueing the above OPEN/NOSHARE will get the FLK error, so you'll need the same retry logic (but beware, for a highly active file you could potentially be starved out).

If the processing takes longer than a simple copy, you might want to use something like:

$ OPEN/READ/NOSHARE LOCKED file
$ COPY LOCKED STAGE.TMP
$ CLOSE LOCKED
$! now process the file STAGE.TMP

I'd be looking at changing the architecture of these processes. If you can't just write the records directly into a shared write indexed file, maybe use a mailbox instead of a sequential file? Your producer processes feed updates into the mailbox, a consumer process catches them and inserts them into the sequential file?