Yes, the bgquer (background queues) and sproc (auto-processing) daemons are started with the 'root' user's environment/settings when the XPP server starts (or reboots).

So, you'll need to fix up the environment settings for the 'root' user for XPP - but you should be able to do that in a way that only will affect the startup environment of the XPP bgquer/sproc daemons and not have to affect anyone logged in as 'root' (unless you want to).

The bgquer/sproc daemons are started (and stopped) by ***xyenterprise entries (or files) in the /etc/rc#.d directories, which all should be soft-links to a delivered /etc/init.d/xyenterprise file (so, best not to edit/change this file since it is delivered).

This /etc/init.d/xyenterprise file sources a delivered /etc/xyvision/xyv.profile file (again, best not to edit/change this file).

At the end of xyv.profile, it checks for the existence of an optional XYV_EXECS/global.profile file and if the file exists it sources it. This file is not delivered by XPP, so this is where you want to do anything you need to do.

At a minimum I would suggest that in your global.profile file you'll want to unset the PERL5LIB variable and I would think you would also want to remove the /root/perl5/bin path from $PATH.

You might also want to unset the other PERL_XX_YY variables (that are being set in root's bashrc file) for good measure.

But be careful with this global.profile file; if you get the code wrong (e.g. a syntax error) then you'll probably find that the bgquer/sproc daemons don't get started properly.

Jonathan,

Given that the standard root account seems to set the PERL5LIB to something which conflicts with by XPP delivered perl environment, wouldn't be a good idea to deliver a global.profile file that unsets this variable, correct the path and unsets the other PERL_XX_YY variables?
Like that things get resolved for all customers.

Or I would at least suggest to update the installation doc with this important information.

Bart,

But what if a customer was actually using PERL5LIB to add something to @INC that they wanted added for the use of Perl in XPP (which it almost sounds like Bill may want to do for their "common Perl Module directory")?

Then, we would break that if we delivered a global.profile file that unset PERL5LIB.

We cannot possibly foresee and automatically handle all possible situations; but we at least try to provide "hooks" to be able to more easily handle situations that arise.

Jonathan,

Since this is happening in a rather standard install (as far as I understood things), I repeat that it would be very good idea to at the very least change the installation documentation. And warn the users that is they don't reset the PERL5LIB in the global.profile file, then they will (potentially) run into trouble with their autoproc perl scripts.

And if the customer wants to change/add the PERL5LIB variable, wouldn't the global.profile file be the correct place to do so?
(as it is already mentioned in the documentation) 

Bart,

If a ticket is opened with support requesting a specific documentation change, then (as always) it will be considered.

It's difficult to document everything everywhere. In the installation documentation it already has a "Configuring System Processes" section in the "Post-Installation Configuration" chapter, which references background processing and auto-processing. And in that same section it also makes reference to the Managing XPP manual, where it talks about the global.profile file.

This is the first time I've seen any customer mention this problem (in tickets or in the Community), at least that I can remember.

Bart,

If a ticket is opened with support requesting a specific documentation change, then (as always) it will be considered.

It's difficult to document everything everywhere. In the installation documentation it already has a "Configuring System Processes" section in the "Post-Installation Configuration" chapter, which references background processing and auto-processing. And in that same section it also makes reference to the Managing XPP manual, where it talks about the global.profile file.

This is the first time I've seen any customer mention this problem (in tickets or in the Community), at least that I can remember.