> 1.    Dim memory assures me that MSDOS had (has) a data-path command
> that would allow data to be referenced by filename without a path
> specifier if it was anywhere on the data path. ie just as
>
>        path C:\windows;c:\UTIL;C:\FOXPRO;C:\

PATH variable is for accessing PROGRAMS not to data! So that when you start
an external command or an application you do not need to tell where is the
command or app resides. But if you would like to open a data file, you still
have to tell where it is, except if it is in the current directory (selected
by the CD or CHDIR internal command).

> allows programs anywhere in the directories on the path to be accessed
> by name the data equivalent allowed data to be accessed similarly.
You have to handle that by your program. For example LIBPATH is something
like that, but handled by the linker itself. Actually PATH is handled by the
command line interpreter (COMMAND.COM or CMD.EXE).

> Such a capability is extremely dangerous, and also sometimes useful.
> A friend wants top do something with an olllld DOS program that may
> benefit from this feature.
> Anyone know how it is/was accessed?
> Gargle seems to know far too much about the terms 'data path' to be
> easily driven to reveal anything useful.

Create an environment variable, something like

SET MYDATAPATH=C:\MyDataHere\

then use that one. You can set that variable in Windows by user basis, so
every user can have different MYDATAPATH variable. (right click on
MyComputer, Properties, Advanced tab, Environment Variables button, New
button in the User variables square...) Now you can have your batch script
like:

COPY %MYDATAPATH%\datafile1.dat  C:\TEMP\hereIwork.dat

> 2.    Same problem but different maybe.
>
> WIN98 on N PCs on LAN.
>
> DOS program on PC A runs OK.
> Same program on PC B runs OK.
> But run program on B and specify data location as on A via mapped
> drive etc and it no go.
> Need better way for non network-aware program on B to 'see' data files
> on A. Any thoughts.

OK, so  what's wrong with opening a file in a mapped drive? It has to be
done in the same way as a local file from the app point of view. The only
thing is that some app opens the file exclusively, so that no any other app
can access to the same file until finished except for reading (some cases
even reading is impossible). That's how the app protect the file from
messing up by unhandled race conditions. So if on app would modify the first
line of text file while other app do the same... which line is the 'good
one'? That's why some app opens the file as nobody else can do the same (to
be able to write into it).

One of the possible solution is that you have to check if you could open the
file, if not wait a while and try again. Then your app has to make the
modification as quick as possible and close the file when finished. But
before you write your data back blindly you have to make sure that it
conforms to the changed file structure (for example if first line is longer
than was then the second line starts in a different file offset).

Other possible thing is that you make sure nobody is working on the file
till you entirely finished (so other clients waits a long time till could
have a chance to open the file for write). This is I call network capable
non-networked app :-)

Oh, almost forgot one thing: you can have a network access in such that you
have only read access to the networked resource. You have to check if the
access is full or restricted.

> As the DOS program is run on only one PC at any one time top avoid
> data corruption and synchronisation issues I suggested doing a copy of
> files to the PC of choice prior to operation and copying altered files
> back after use plus a basic control system to prevent more than one PC
> accessing the system at a time. Should be easy enough to do and I'd
> guess it would be rapid enough but "doing it properly" would be nicer.

You can move the file instead of copy, so that if the file is not in the
original location nobody could open it, right? :-) And move instruction is
one single instruction -- I did not test it therefore I could not tell if no
any problem could occur this way. Alternatively you can rename the file
keeping in the same location, so that the extension tells which client is
working on it (FILE.A or FILE.B for example). It could be much quicker, and
then you can check that the rename was successful -- if not the other one
was quicker or something was completely wrong.

But if it is not a script but a proper program you should consider do a
better record locking mechanism -- even dBASE IV had record locking, and
according to the PATH you mentioned you have FoxPro which is a good clone of
dBASE. Look up the book / google on record locking and shared accessing and
do it in a proper way :-)


Tamas
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist