From: Jim Weigang <jimw@chilton.com>
To: oswald urs <osurs@bluewin.ch>
Newsgroups: comp.lang.apl
Date: Thu, 08 Oct 1998 00:28:28 -0400
Subject: Re: Holding native files in APL2000

Urs Oswald wrote on 7 Oct 1998:

> While holding APL component files with {quad}fhold is a routine 
> procedure, there seems to be no analogon for native files. Does 
> anyone know more? 

As Willem van der Eijk suggested, you can use the #NTIE mode parameter
(second element of the right argument) to control shared access to
files.  However, this is not an efficient solution because every write
(and maybe every read) operation will require that the file be tied and
untied.

On DOS and Windows-based APL+, #FHOLD is implemented using operating
system calls that lock a region of the APL file.  For native files, you
can make these OS lock calls directly.  And in fact, if you believe the
documentation, you must do this if you want multiuser file access to
work properly.  The MSDN documentation (in article Q165966) says that
"Win32 applications that run on Windows 95 and share remote files with
clients on other machines must lock the regions they read or write".
Failure to do so may result in one user not seeing data written by
another user.

For locking purposes, a "region" is a range of consecutive bytes defined
by a starting offset and a length.  You are specifically permitted to
lock regions beyond the end of the file, which can provide a lot of
flexibility in creating multiple read-only and exclusive write locks.

Note that unlike #FHOLD, an OS lock not only blocks other users from
locking any part of that region, it also prevents them from reading or
writing to that region.

Appended below is an FLOCK routine that can be used on either the
APL*PLUS II/386 (aka APL+DOS) or APL*PLUS III/Win (APL+Win) systems.
IFWIN should be 1 for Windows, 0 for DOS.  #IO is assumed to be 1.

                                                Jim






From: Jim Weigang <jimw@chilton.com> To: oswald urs <osurs@bluewin.ch> Newsgroups: comp.lang.apl Date: Thu, 08 Oct 1998 01:03:17 -0400 Subject: Re: Holding native files in APL2000 The FLOCK routine uses a global variable PLATFORM that I forgot to explain. The first element identifies the operating system as follows: 2 = Win3.x 3 = Win95/98 4 = WinNT You can define PLATFORM using: V{<-}2{pick}#WCALL'GetVersionEx' (148{take}82 #DR 148) PLATFORM{<-},2+323 #DR V[16+{iota}4] This need be done only once when your application starts running. If the #WCALL statement gives an Undefined Function error, add the following line to the [Call] section of your APLW.INI file: GetVersionEx=B(>C) ALIAS GetVersionExA Sheesh! Jim
From: Jim Weigang <jimw@chilton.com> To: D E Siegel <desiegel@aol.com> Newsgroups: comp.lang.apl Date: Wed, 14 Oct 1998 20:52:47 -0400 Subject: Re: Holding native files in APL2000 I wrote on October 8: > Note that unlike #FHOLD, an OS lock not only blocks other users from > locking any part of that region, it also prevents them from reading or > writing to that region. David Siegel replied on October 14: > My experience with OS-file locks does not support this statement. I > wrote routines for the LEX2000 product to do explicit file locking of > native files, using basically the same apparoach as Jim described. I > did NOT find that a lock blocked reads or writes to a file, unless the > application attepted to obtain a lock itself. In short, locks only > locked out other locks i.e. they are only elaborate mutexs. this may > not be true under all OS versions, however -- my research was NOT > comprehensive, and was done under win3.1x, not win95 or NT. (This was > several years ago). I don't doubt what you say, but the behavior you describe is not what's promised in the documentation for the LockFile API call, and it's not what I observe using Windows 95 on our Novell network. On our system, after locking a region, any attempt by another process to read or write that region produces an error. The MSDN documentation for LockFile says: "Locking a region of a file denies all other processes both read and write access to the specified region." You may be right about Windows 3.1 (with DOS below it) being the underlying cause for the behavior you observed. For example, the MS-DOS Programmer's Reference says the following about Lock/Unlock File: "If another program attempts to write to or read from a locked region, MS-DOS retries three times; if the retries fail, MS-DOS issues Critical-Error Handler (Interrupt 24h) for the requesting program." But then it waffles by saying: "Programs should not depend on being denied access to a locked region. To determine the status of a region (locked or unlocked), a program can attempt to lock the region and then examine the error value." The point is half-moot--when accessing a shared file, you're supposed to lock the region you're reading or writing, to make sure Windows doesn't cache the data. This lock will prevent collisions even if your OS allows access to locked regions. But you shouldn't write code that assumes you can access locked regions; I believe that feature is a thing of the past. Jim
Note: The APL code on this page can be extracted without you having to retype it.
See "Downloading Code" for instructions.





JimW's Home Page