Split out data and code?

[Nancy Palmquist]

Mark,

It may be permissions.  It is critical that filepro has permission to 
access the second location, just like the first.

Also map, screens, processes and output have to be in the primary 
location.  I am pretty sure you are working on a *NIX system. filepro 
needs to own everything under the filepro directory folder.  filepro 
needs to have RW permission above there at least.

On a windows system, I have found that in windows security, I have to 
give CREATE permission to the user(s) that is trying to access filepro.  
A good reason to put filepro on its own drive so you can control who has 
access properly.

Nancy

On 11/25/2019 9:52 AM, Fairlight via Filepro-list wrote:
> Nancy,
>
> No matter which order I use for PFDSK, rclerk is giving me:
>
> "No screens found for 'REDACTED'."
>
> Ideas?
>
> m->
>
>
> On Thu, Nov 21, 2019 at 01:37:02PM -0500, Nancy Palmquist via Filepro-list thus spoke:
>> Mark,
>>
>> The logic that allowed filepro to be split across multiple disks is
>> still part of filepro and can be used like this.
>>
>> You need the following:
>>
>> /appl/filepro
>> /var/appl/filepro
>>
>> PFDSK=/appl:/var/appl  ' this represents the order it searches. First
>> location should be programming, second would be data.
>>
>> On /appl/filepro/filename
>> You will need map, prc. etc.  NO KEY, NO DATA, NO INDEXES
>>
>> On /var/appl/filepro/filename
>>
>> You will put the key,data,index
>>
>> I use this logic to share one key, data, index between 2 servers and
>> it works fine.  In your case, setting up different PFDSK so a
>> different /var/appl/filepro is specified for each customer should
>> work.
>>
>> WARNING: If you ever rebuild an index from scratch, it will put it
>> on the /appl/filepro side not the secondary location.  So if you need
>> to create indexes, always make the filename where you want it first
>> then build it, I think I recall this would properly locate the
>> index.
>>
>>
>>
>> On 11/21/2019 8:33 AM, Fairlight via Filepro-list wrote:
>>> I have a particular need for a business, and need to know if filePro
>>> supports a particular topography natively.
>>>
>>> This is for filePro 5.0.14 on Linux, and it -won't- be upgraded,
>>> guaranteed, even if the feature is available only in later versions.
>>> Please constrain answers to relevancy for that version.
>>>
>>> By default, filePro co-mingles its code and data in the same directory for
>>> each file.  Maps, key and data segments, indexes, screens, output
>>> definitions, selection sets, processing tables and tokenised versions of
>>> them, etc., all live in the same place.
>>>
>>> What I need to achieve is the ability to have:
>>>
>>> * One directory (preferably the same current location of $PFDIR) retaining
>>> the data (key/data, indexes, lockfiles).
>>>
>>> * A -separate- directory taking up the role of housing the code (prc/tok,
>>> browses, maps, selection sets, outputs, screens, etc.).
>>>
>>> The goal is to split these off so that gigabytes and gigabytes of
>>> customer data can remain where they are, but the application itself can
>>> be containerised with docker.  This is to facilitate distribution and
>>> implementation of an application on a version-specific level (v1, v2 ..
>>> v47, etc.), and secondarily for resource protection.  Drop in a whole new
>>> version of an application spanning hundreds of filePro files, and run your
>>> Apache-driven product.  If there's a problem, switch containers back to the
>>> last version.  Instant rollback.  There are huge benefits in multiple
>>> areas, from ease of distribution and deployment, to rollback ability.
>>>
>>> So far, my attempts to make this happen have hit a brick wall in that the
>>> container version of the directory is subject to occlusion by the bind
>>> mount with the data files.  You only see the data files.  If you exclude
>>> the bind mount, you can see the code, but you have no data.  This is a
>>> problem.
>>>
>>> I've considered symlinks from the data directory into the location where we
>>> might move code to in the container structure, but that whole thing doesn't
>>> play nicely with git, which really doesn't like symlinks as much as you'd
>>> hope.  It is not an exaggeration to say that I would need to generate
>>> hundreds of thousands of symlinks to start, across all filePro files, and
>>> then implement and maintain the practise of adding new ones any time
>>> something new is instantiated.  That seems unwieldly, and I don't want to
>>> impose that upon the developers if I don't have to.
>>>
>>> Copying the data into the container is going to be too slow at startup,
>>> given that it can be a few hundred gigs of data...per customer.  That's not
>>> going to happen.  So it's either split this apart and get both sets of
>>> files under the same directory -somehow-, or find a way to use two separate
>>> directories.
>>>
>>> I'm open to viable suggestions.
>>>
>>> Thanks!
>>>
>>> mark->
>> -- 
>> Nancy Palmquist         MOS & filePro Training Available
>> Virtual Software Systems    Web Based Training and Consulting
>> PHONE: (412) 835-9417           Web site:  http://www.vss3.com
>>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://mailman.celestial.com/pipermail/filepro-list/attachments/20191121/d9136740/attachment.html>
>> _______________________________________________
>> Filepro-list mailing list
>> Filepro-list at lists.celestial.com
>> Subscribe/Unsubscribe/Subscription Changes
>> http://mailman.celestial.com/mailman/listinfo/filepro-list

-- 
Nancy Palmquist         MOS & filePro Training Available
Virtual Software Systems    Web Based Training and Consulting
PHONE: (412) 835-9417           Web site:  http://www.vss3.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.celestial.com/pipermail/filepro-list/attachments/20191126/89737fd3/attachment.html>