Yes, this is how I understood it; naturally, we can always pull
the setting of `dynamic',
this-instance-of-the-pipeline environment variables further out, to
the wrapping
script, or to the job submission at the orchestration level, later
if we choose. The ideal solution
probably depends on which policy file the value resides in.
Greg
On Aug 31, 2006, at 4:07 PM, Robyn Allsman wrote:
Hi Ray and Greg,
No, my current implementation--so you wouldn't need to change your
operational
procedure -- is to continue acquiring the policy directory as a
parameter
to the pipeline harness (aka manager). Then, internally to
manager, set the
environment variable. It is passed down to all secondary processes
called.
Robyn
On Thu, Aug 31, 2006 at 04:00:55PM -0500, Ray Plante wrote:
On Thu, 31 Aug 2006, Robyn Allsman wrote:
2) the pipeline harness code would load the policy directory
pathname into an
environment variable on startup.
This sounds good. Greg, we'll obviously need to set this in the
wrapper
script.
Ray
_______________________________________________
LSST-data mailing list
[email protected]
http://www.lsstmail.org/mailman/listinfo/lsst-data
_______________________________________________
LSST-data mailing list
[email protected]
http://www.lsstmail.org/mailman/listinfo/lsst-data
