On 16/08/05, John E. Malmberg <[EMAIL PROTECTED]> wrote: > 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).
Actually it seems to depend on the log file - see below. > > 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. Agreed. > 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. With Perl 5.5A3 I get: $ perl -n -e "print" sys$manager:operator.log Can't open sys$manager:operator.log: file currently locked by another user With 5.6.1, I get: $ perl -n -e "print" sys$manager:operator.log Can't open sys$manager:operator.log: error in directory name. Both work OK if I define DECC$FILE_SHARING > Type has no more privileges or features than Perl does in this case. Indeed, but presumably it opens the file slightly differently. > 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. In which case the data corruption could also be caused by a non-Perl program, surely? Or indeed a Perl program run with file-sharing enabled. [...] > > 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 >
