Opening file on Advanced Server share for write-sharing

[Jess Goodman]

VMS 7.3-2 with Advanced Server V7.3B

Is there any way to access an existing file on VMS (sequential; fixed-length 128 byte records) from a Windows application, so that the file is opened by Advanced Server for read-only access but with write-sharing allowed?

The Windows application is currently written in C++, but using other Windows APIs or languages to access the file may be acceptable to the developer.

[Jon Pinkley]

Jess,

I don't use Advanced Server, but I am trying to understand the problem you are trying to solve.

What will be opening the file for write access; a process running on the VMS system?

Jon

[Jess Goodman]

>What will be opening the file for write access; a process running on the VMS system?

Yes, the file is periodically updated by VMS.

If write-sharing is not allowed, then if this update occurs when the PC application is reading the file, either the PC application or the VMS update will fail (depending on which one opens the file first).

[John Gillings]

Jess,

I can't test this (no Advanced Server here). Try having a process keep the file open for WRITE SHARED permanently. You can have a single process do this for manly files, just a string of OPENs and a $HIBER, you can even do it in DCL. Do it before any other attempts are made to open the file.

If the ACL access to the file via Advanced Server is READONLY, that should do what you want.

If this works, you could them implement a server process which will open and close files on demand, or even troll directories looking for files which should be shareable.

[Hoff]

I'd probably look to use an RMS ODBC or JDBC connector here, or similar. Not Advanced Server.

[Jon Pinkley]

Unless the files are opened readonly with explicit write shared access, then I don't think John Gilling's suggestion will work:

From DCL:

Prc1$ open/write/share=(write) test scr:t.t
Prc1$

Prc2$ open/read test scr:t.t
%DCL-E-OPENIN, error opening ROOT$USERS:[JON.SCRATCH]T.T; as input
-RMS-E-FLK, file currently locked by another user
Prc2$ open/read test scr:t.t/share=(write)
$

It should be easy to test, so trying it will a DCL open like the first one above followed by an attempt to access the file from the PC application will be the definitive test.

I agree with Hoff, Advanced Server isn't the best tool for the job. If you don't have an ODBC server, and don't want to acquire one, the following work around may work.

If the files are normally closed, the files are small, and the files can be opened/closed for each access, then an Ethernet like protocol can be used. In other words, each accessor will attempt to open, and if it fails, wait a while and try again, with some max number of tries before failing. Once the open succeeds, do the work, and then close the file. The frequency of access will indicate if this is an acceptable workaround, it certainly does not scale well.

Jon

[Doug Phillips]

In defense of Advanced Server, I believe one would have a problem sharing a file in a Windows-only environment without some client-server tool. At least AS returns an error instead of quietly letting the file be trashed.