The filePro "path" variables... pfdir, pfdata, pfprog and pfdsk....

[john at timescape.com]

Let's call them the filePro path variables.  Using them, filePro systems can locate where the filePro "data" folders are located, and where the filePro executables are located.

First, I know lots about these 4 variables, and I've made them work literally hundreds (more likely thousands) of times.  In the following case, I am baffled.

How about a short primer to make sure we all are on the same page regarding these critical environment vars.

First, the pfdir, pfdata, and pfprog vars can not be placed in the filePro config file - must be in the environment.  As for pfdsk, I have systems where this one alone can be put into the filePro config file, or in the environment.

Both pfdata and pfdir are catted together and\filepro is appended  to the end of the concatenation to allow any filePro executable to locate  the directory where the actual filePro data folders are found.

For the above to work, sometimes, pfdata is not required at all.  This var is only absolutely  required if the filePro data files are residing somewhere "below" a filesystem mount point. If the directory holding the data folders *is* on the same filesystem as the root  without any need to mount an intervening file system along the way to it, then pfdata can remain empty.  Conversely, pfdata must be filled with the actual mount point for the file system on which the filePro data folders reside. (Examples later....).

Pfprog is used alone and \fp is appended to this var to allow filePro executables to locate where filePro executables themselves  are found.  This may sound a little convoluted, but again examples will come shortly...)

Ahhh! Now we have pfdsk.  Grump!  For years it was never necessary on a *nix system.  I don't know why this was so, but I do know, that in the past couple decades, it is occasionally *required* on *nix systems.  On Windows systems, where there are mount points involved, I believe it is always necessary... maybe...???  Here in lies my problem.  

Also, if what I say about pfdata is TRUE above, when there is NO point, is the existence of pfdata as an empty var required sometimes?  I can't tell you this with certainty either.  Just last week, I ran it on a system without ever instantiating it at all, and later, it seemed to be required in the environment whether it held a mount point or not.  Same seemed to be true for pfdsk.  Using  full (i.e., absolute) paths specified to both the filePro data folders, and the filePro executables folder, it "seemed" to work fine in most testing.

There is one more basic that needs to be addressed. For myself, it was usually very easy to assign the values to these variables (or not) by referring to the "/etc/default/fppath" file which is a 4 line text file that is only required on *nix systems.  It specifies the 3 main filePro path vars (pfdir, pfdata, and pfprog) in that order for the first 3 lines, and the 4th line held an encrypted password - out of this discussion's scope.)  The file did not address (i.e., point to) the pfdsk variable at all.  

More usually than not, the filePro data folders *and* the filepro executables folder reside on the same file system and at the sam hierarchical, for example /u/appl/filepro and /u/apppl/fp. So, often you would see the /etc/default/fppath file look something like:

/u/appl

/u/appl

And by this, you would know that, the filepro dat folders were in /u/appl/filepro, and the filepro executables were in /u/appl/fp.

If let's say the /u file system was on a second drive (which of course would need to be mounted) this file would need to be done as:

/appl
/u
/u/appl

Otherwise, the filepro data folders (and the executables) would only be located in the right place if the actual /u file system *was* mounted!  If it wasn't, filePro would place the data in the same path /u/appl/filepro, but it would be a directory on the primary drive! (same with the filePro executables).  And of course, this would not be what you wanted.

So remember, the "filepro data folders" are reached by concatenating pfdata and pfdir.  When  a mounted file system is involved , pfdata must designates that  mount point. The   fppath file would show that mount point as the second line, it would not be left blank.

Early TRS systems showed this very clearly more like:

/appl
/hd1
/hd1/appl

(Tying a second hard drive (the mounted file system) to a name that sounded like a hard drive was a pretty simplistic mechanism for making the "point" clear to end users.  (Sorry, that is a terrible pun, but never the less true.)  ��

Final little tenet.  *if* pfdsk does end up to be required on a complex Windows system, the pfdsk and pfdata vars had to be expressed as the following combination.

Set pfdsk=<drive>
Set pfdata=<drive>:

Where <drive> represents the drive letter of the mount point share, examples A through Z, or the name of some network resource, etc.
.  (If there are multiple places to look for filePro data folders, pfdsk can have more than one file system included in it.

Usually, the 2 variables will look like this:

Set pfdir=H
Set pfdata=H:


Okay, so why am I having so much trouble helping this one gentleman who has a licensed 5.k014d9 system to run with a mapped NASwhere the relevant folders are located in:

\\device-name\home\appl\COMPANY/filepro

And
\\device-name\home\appl\fp

The NAS is mapped (mounted) to a share which is the top directory on the device.  In this case, I do this with:

Net use H: \\device-name\home

(The NAS knows it's share  as H (\\device-name\home):, windows knows it as H:, etc.  All works...)
BUT - BUT - BUT

Sometimes I get there are NO filepro files (obviously given to me by some rilepro executable like dclerk, or p.exe going through a menu.  Other times  I get this license is not properly registered, which it is, because 90% of the times this is NOT a problem.  Other time  and mostly, I find the executables with p.exe (meaning I get to a user menu, but choices on that menu looking for *another* menu not find it and it lists a path *directly* to the correct menus folder!  Lots of other annoying stuff.  Enough so for me to write this long note.

  
Imagine I would start with:

Set pfdsk=H
Set pfdir=\appl\COMPANY
Set pfdata=H:
Set pfprog=\appl

Hope to get some ideas I haven't thought of so that these 4 vars can be set and we can point to the new NAS as the correct place to find both the  filePro folder and the filePro executables as specified above.  I'm foregoing showing any of the dozens of errors, they are unimportant, although usually the show me what is wrong.  In this case, Iam, as I say, baffled.

Thanks in advance for all help.

/john

P.S.  Why does the Editor of the Guru Magazine not know this stuff???  Well first of all I am now ahappy 75 year old who has not done much filePro for the past decade or so, just occasionally for old legacy clients who used *nix.  Is that enough of areason?  Probably not.  ��  But lif is what it is.  

If anyone wants to see and hear the video I have spent my "free" time on, just go to the youtube web page and type the following 5 words into the search:

World Lament by Rave Review

At least I'm doing **something* with my time.... ��

 

The permutations of whether the env vars are in the environment even if they are left empty is bothering me, because I don't remember what the rule is for this.