| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 308.1 | Write some code | BARAKA::LASTOVICA | Norm Lastovica | Thu Sep 11 1986 13:07 | 5 |
| Can be done. Just do what SHOW DEV/FIL does. Though I haven't
looked, I'd imagine that it gets the FCB's (right structure?) for
the device and just chains through them. You'll need CMK and will
have to run at elevated IPL (I think). Look at the code in the sources
and see what it takes.
|
| 308.2 | the SPAWN can be done from your program | AVANTI::OSMAN | and silos to fill before I feep, and silos to fill before I feep | Thu Sep 11 1986 15:18 | 11 |
| Maybe SHOW DEV/FILE will work for you anyway.
If you're objection to it is that you were having to manually spawn,
perhaps you'd be satisfied if the SPAWN and the parse all happened
from a subroutine called by your program.
SPAWN/NOLOGI/NOSYM is reasonably fast, and SHOW DEV/FILE has the
advantage over the FCB method that you don't need privileges to
do it.
/Eric
|
| 308.3 | For best results, use a lock (works in a cluster) | NOVA::NELSON | JENelson | Fri Sep 12 1986 09:34 | 10 |
| These solutions won't work if the process which has the file open
is on another node in a cluster, since SHOW DEV/FILE only shows
you the open files on your current node.
You ought to write the application to take out a lock before it
opens the file. If another user tries to run the application, it
can detect that the lock exists, and can notify the other process
to exit.
JENelson
|
| 308.4 | I second .3's motion | FROST::HARRIMAN | Harriman, Paul J., qty 1 | Fri Sep 12 1986 13:37 | 27 |
| re: .1 and .3
.1's approach requires running at IPL$_SYNCH, since
you will have to chase the device UCB down, then work your way around
eventually through the VCBs to the FCB's and tie them back to
a process. I'm not an expert on this (but have navigated around
it somewhat) but it is a LOT of work, and hard to debug (IPL$_SYNCH
is above the debugger's IPL).
.3's approach, on the other hand, requires some changing of the
application itself. The original application will most likely take
out locks anyway. However, since we don't know the database management
system being used, (DBMS, RMS, RDB, ???) we don't really know how
the locking is being performed. Nor do we know whether or not we
are on a cluster...(hint, .0 :=) Anyway, if you can't change the
application, it makes more sense just to look at the locks. There
are system calls (and library calls too) to look at who owns a lock,
and it can be accomplished in a higher level language than macro
since you wouldn't need to SETIPL or anything like that (the system
service would do it for you)...
Look into $GETLKI. This is not an "easy" system call to use, but
it is effective. The "lock checking" program only needs to find
locks if it can't open the file outright. The system does most of
the work that way.
|
| 308.5 | Yes, but locks don't always work either | SQM::HALLYB | Are all the good ones taken? | Tue Nov 04 1986 13:05 | 21 |
| The file lock is of the form:
F11B$a<label><file-number>
Where <label> is the volume label, blank-padded to 12-characters
and <file-number> is a longword representation of the file number
part of the file ID. (The first number in the FID triplet).
This lock is taken out in Kernel mode, so to $GETLKI it you need
to be running in K-mode.
Unfortunately (for this need) the above only holds for VAXCLUSTER=1.
If you boot with VAXCLUSTER=0 then the XQP does not take out any
file locks; it uses the FCB as did the ACP in V3 days.
Also, the <label> definition only holds for cluster-mounted disks.
For privately-mounted volumes there is a combination <nodename>
and <UCB address> that is formed. You'll have to use SDA to figure
out the format if you need to know it.
John
|