Re: Best way to "lock" a save file

On 08-Jun-2017 15:32 -0600, John Yeung wrote:

On Thu, Jun 8, 2017 at 4:27 PM, Mark S Waterbury wrote:

On 08-Jun-2017 09:25 -0600, John Yeung wrote:

At least up to 7.1, it seems we can't ALCOBJ a save file. So if
we want to lock it, do we ALCOBJ the library it's in? That
seems... imprecise.

If this is indeed the best we can do, is there some technical
reason why IBM didn't/won't provide a way to lock a save file?

As I recall, the device file is nothing more than the *FILE object with a prototype run-time object [instead of a "member" object serving that purpose]; the design had the locking limited to only during run-time, only since the Open Data Path (ODP) gets generated from the prototype ODP, as the effect of the OPEN.

The ALCOBJ command has many restrictions on what kinds of objects
you can "allocate" -- for example, you cannot allocate a DSPF or
PRTF or ICFF either ... :-/

No device files other than DDMF [pointing to a DBF] are supported for Allocate Object (ALCOBJ); i.e. specification of a device file, of any of the non-DBF extended File Attribute values [BSCF38 CMNF38 DFU DFUEXC DFUNOTEXC DKTF DSPF DSPF38 ICFF MXDF38 PRTF PRTF38 SAVF TAPF], will fail with msg CPF0984, diagnosing that "Only data base files can be allocated or deallocated."

What exactly do you mean by "locked"? What actions are you trying
to prevent by "allocating" the object, presumably for *EXCLusive
use?

Conceptually, the same thing as allocating a database file for
exclusive use. I don't want to allow the possibility that some other
job could rename or delete the save file, or alter the contents of
the save file in any way, until my job is done with it. And my job
shouldn't start working with that save file until it can be
allocated exclusively.

Just the act of opening a Save File (SAVF) device file will cause a *EXCLRD lock to be held; held until the file is closed. Display Save File (DSPSAVF) has the same effect, held for the length of the processing, thus until exiting from an interactive request to the display. But that is not helpful if the "working" involves output; i.e. for which the msg CPF4189 will be seen suggesting that the "online save file is already in use. A save file cannot be opened more than once when it is used either for a save or restore operation or for any output operation." except possibly when the non-sav/rst output-only for add-only is under a shared open.

I am doubtful an RFE would be accepted to enable the effect [and even if so, would be long in coming], so probably using an object in QTEMP until the file can be moved with Move Object (MOVOBJ) into the final location is probably "best"; of course, responding to any conditions such as "already exists" if/when they transpire -- with a window of opportunity for an already-existing object in the permanent library to be mishandled in concurrent processing, without reviewing and depending on the File Level Identifier to infer the /file/ remains what was.