have you ever required obtaining a file's NAME and PATH
programmatically while using the the file-variable as the source
parameter? eg. call getFilename(input:file_var, output:fullpathname)

although this would be fairly trivial in virtual assembly language via
chasing the information in an FCB (and would be a nice
enhancement...<nudge..nudge>), i no longer play there... and today
needed to come up with a solution using the existing D3 functionality
and pick/basic.

although i plan on posting a solution that I came up with in a day or
so... it turned out being an interesting challenge, so i thought i
would throw it the problem out there ahead of time for those up to a
fun challenge. feel free to utilize any/all tricks available to you.

this has applicability for building various state-machines (including
multi-tiered debuggers... eg. debugging a server application via a
browser interface)... but i won't digress.

any takers?

dzigray wrote:
user exit 90 to get the fof item id? that only works if the file is
local - it won't work for super-qs.

dzigray wrote:

I think this time I'll just sit & watch :-)

jBase does this using the IOCTL function.. No help for those on D3....

Regards
Simon

--
Simon Verona

"dzigray" <google (AT) bridge2 (DOT) com> wrote

Here's a thought.

Use SYSTEM(19) to generate a unique ID. Write an item into the file
using this ID.

Use READU to read in the item and lock it.

Execute a LIST-LOCKS command capturing the output and analyze the
Item-ID column for your ID. Get the file name from the Filename
column.

Delete the item from your file.

Hi Dave,

Sorry, you made it too difficult to resist:

How about: fullpathname = fileinfo(file.handle, FL$PATH) plus a couple
dozen other useful pieces of information directly from a file handle. A
couple of these give information about alternate key indices - which
actually work and won't trash your filesystem. Oops, that's openQM ...
you can see more items that might be simply "wishlist" bits in other
systems here: http://www.openqm.com/docs/

thanks mike, i've never used "u90"... it definitely cuts code for the
vme files. it seems reliable for all VME files (other than FOFNUM=1,
which is the result returned for all FSI files.)

Mike Preece wrote:

Cliff, that's pretty much the route i took...

assuming a windows platform & a local filesystem, the only option i see
(save jumping the tempting-ship over to OpenQM, jbase...) is that one
has to have two sets of logic, one covering the vme and one for the
FSI.

fortunately, you don't have to actually create an item in the file to
assert an item lock, which would otherwise have unwanted side-effects
within the window of using a write/delete (also having greater
potential side-effects on triggers.) so i simply did a READU on a
non-existent item to assert the lock, with a RELEASE when finished.
this way, even if the system crashes we won't leave lint behind.
although system(19) is unque within all processes using such for ID-s,
but to guarantee its uniqueness in the file system, i had prefixed a
"_fname" signature to the SYSTEM(19). although a bogus signature alone
could have guaranteed uniqueness on the READU from interferring with
the pre-existing data in the file system, this combination also keeps
the id unique for two processes that might be using our subroutine.

for the VME...

assuming the logic for covering the VME, mike's idea is actually most
efficient, but excludes the fsi files. since u90, too, requires
touching the file with a mechanism to bring it up to the
"last-referenced-file" position, the READU above actually works great
here. (one could be optimistic that the file is in the VME and
therefore could get away with only a READ of the same unique
non-existent item to and then not require the RELEASE) going mike's
route for the VME, once you have the FILENUM, you're home free.

like you proposed, i used LIST-LOCKS for the VME which although it
returns a filename, the path is absent -- but fortunately it more
critically returns the group containing the lock. you can then do a
brute force query(ies) against the FOF to obtain the file with this
base (excluding any deleted files which also might match.)

list-locks returns a result for both vme and fsi, but it uses a
different formats. therefore two different parsing sublogic-s had to
be used

for the FSI... "list-locks" returns the entire path... -except that
list-locks will TRUNCATES this to fit into 19-characters via the
embedded NT_LIST-ILOCKS. so, i created an nt_list-Ilocks2 program
which instead doesn't truncate.

i'm the first to admit the above is a cludge... but when you need the
functionality...

Cliff wrote:

Tom deL wrote:
You know, since you made it SO darn easy to follow the link, I did...
and once there I had to chase others... -- NOT baaadddd! I'm
impressed!

Chasing this, one has to chase the letter of the GPL... as it applies
to OpenQM (also available at http://www.gnu.org/copyleft/gpl.html) and
I wonder if this is really being adhered to properly via the
<quote>"commercial"</quote> version and its differentiation as a
derrived work. On first pass, it seems as if the spirit of the GPL is
being substantially violated.

"dzigray" wrote:
I didn't go for Cliff's suggestion specifically because of the trigger
issue. The next thing to do here is to see if a Read trigger (D3 FSI
has _lots_ of triggers) will execute when you do this little test.

This is only needed in poorly written code - and there's a lot of that
around. Proper coding takes precedence in the long haul, if possible.
As well as considering adding a one-line Call to a routine that gets
your filename for you, consider a longer-term solution of putting
filenames with corresponding file descriptors in a dimensioned array.
The name should always match the contents of the descriptor.

T