PDSK being ignored"

[Richard Kreiss]

Don’t forget about poignancy which is the opposite of oddsmakers. 

Richard
Sent from my iPhone

> On Dec 17, 2019, at 4:18 PM, Timothy R Barr via Filepro-list <filepro-list at lists.celestial.com> wrote:
> 
> My Unix/Linux is rusty compared to Windows, but the following should still
> apply:
> 
> The stacking of variables to build a path to the data is PDDATA PFDIR.  Do
> not include PFDSK, that is the list of "drives". PFDATA is basically
> starting from root.
> I presume your PFPROG (a full path) is set ok or you wouldn't get anything
> to run.
> 
> Therefore, If you have set...
> 
> PFDSK=/u/ourapps:/container/u/ourapps
> PFDIR=/appl
> PFDATA=/u/ourapps
> 
> Your code will be at %PFDATA%%PFDIR% or /u/ourapps/appl/filepro/tablename/*
> The key, data, and indexes can be there too. PFDSK isn't needed for it to
> look here.
> 
> But the PFDSK should cause it to also scan for these three file types
> in /container/u/ourapps/filepro/tablename/*
> 
> If you can get your screens back working, with the Key/data/indexes in
> the usual place - then try moving those files to the alternatce PFDSK
> location.  Watch out for double slashes (e.g. if PFDATA was
> /u/ourapps/ and PFDIR was /appl)
> 
> 
>> Does the target of PFDSK -have- to be a separate, discrete  filesystem?
>> 
>> I ask, because...
> 
>> 
>> I've been having troubles getting this PFDSK resolution to fix for spliting
>> code and data out.  In my debugging, I'm now discovering that
>> just...setting PFDSK to /var (for example) will not result in an error
>> about no filePro files, as I would expect it to.  It just happily looks
>> where PATHFILE is pointing, and isn't overridden.
>> 
>> I can't figure out why PFDSK is being ignored entirely right now.  My