Split out data and code?

Fairlight fairlite at fairlite.com
Fri Dec 13 08:08:41 PST 2019 

Okay, I have tried this every which way from Sunday.  Here's my latest
settings:

PFDSK=/container/u/ourapps:/u/ourapps
PFDIR=/appl
PFDATA=/u/ourapps

The container contains everything but key, data, and indexes.

The regular path contains those files.

No matter which order I stack PFDSK, I get:  

     There are no Screens available for 'testfile'

Anyone know where this is going south?  It's driving me bloody insane.

m->


On Tue, Nov 26, 2019 at 04:18:02PM -0500, Nancy Palmquist via Filepro-list thus spoke:
> 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>
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list

-- 
Audio panton, cogito singularis.

More information about the Filepro-list mailing list