Sebb wrote:
> On 15/08/05, Carl Friedberg <[EMAIL PROTECTED]> wrote:
>
>>sebb wrote:
>>
>>On VMS, the default behavior makes sense. VMS is a
>>multi-user system, and when you open a file, the
>>default access is exclusive. VMS has rich file
>>sharing semantics, so it is easy to change this
>>behavior; but a VMS user expects default access
>>to be exclusive.
>
> I use VMS and I don't ...
>
> For example, the VMS TYPE command allows one to look at the contents
> of batch LOG files, but Perl cannot _read_ the same file without the
> work-round above (or vmsopen() with suitable parameters).
You are only seeing that behavior because of that the log files for
batch jobs explicitly were opened in a way that allows other programs to
read them. Note that a large amount of data in the log file may not
have yet been written to disk, and is unavailable to the type command.
If you write an application that opens a file with the default options
and then sleeps, you will find that TYPE and other non-privileged
applications will not be able to access the file at all.
>>Changing this behavior to conform to perl usage on
>>other OSes could be a configuration option; but
>>the default "no surprise" behavior should be
>>exclusive access.
> IMO, the surprise in this case is that Perl can't open a file
> that TYPEs OK ...
Perl can access any file that TYPEs ok. That is not the issue here.
Type has no more privileges or features than Perl does in this case.
If pause the lib/test/simple/t/create/t test in the debugger just before
Perl tries to open it again for read access, and then spawn to DCL or
use another terminal session, you will find that Type also has no access
to that file.
If you define DECC$FILE_SHARING ENABLE before the running the test
again, you will find that both perl and Type will be able to access the
file, except that they both may display it as empty.
A change in behavior in Perl by default would break any existing scripts
on VMS that depend on the traditional VMS behavior.
A very high probability of data corruption could result.
John Malmberg wrote:
: The issue that I can not work around is the one that you did not quote,
: and that is that data from the test module has not yet been written to
: the disk because the file is not closed, or an fsync() call has not been
: made for it.
Sounds as though the test may perhaps not be valid...
I.e. is it sensible for the test to assume that the file will have been
> flushed?
If it is assuming that the platform it is running on is compliant with
the X/Open Single Unix Specification for such I/O, it should not assume
that the file has been flushed unless the file is closed or fsync() has
been called.
Usually when I have encountered a program that does not work on VMS
because the program is expecting a different behavior than documented by
X/Open or other official UNIX/ANSI/ISO standards, with in a year, I see
of report of a "real" UNIX implementation where that program does not
work for the same reason.
> On 16/08/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>>
The performance impact of altering perl's open() to use the CRTL
shr would be significant. Ordinary perl usage would slow to a crawl.
Folks who want shr can load and use VMS::Stdio::vmsopen() and pay
the performance penalty.
I've not noticed vmsopen() causing any read performance problems, and
I don't recall this being mentioned in regard to DECC$FILE_SHARING.
Is this true with recent CRTLs?
I am not aware of any performance penalty for turning off the file
locking. The vmsopen() probably allows even better tuning of the open
request to the use of the file than the Perl open() routine.
If there is a performance penalty between the two calls, I would look
for a different cause.
-John
