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.

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.

YES - this answers my questions.  I am going to test unset on the 4 PERL5 variables set.   But now I have a question - about customizing XPP Perl.

In Native perl - our IT department won't or dislikes making changes to the Perl environment.  So we adopted a technique of having a common Perl Module directory where we place our inhouse PMs or other Perl PMs.

How does the XPP user community deal with this - we have had several occasions where we needed a Perl Module in XPP but did not install it and created wrapper programs to call the PMs.

We want to keep the XPP Perl as vanilla as possible but we like to expanded features.

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.

Bill,
If there is a real need for an additional perl module, then it should be installed.
But I do understand that it puts some additional burden on your IT department since they would need to reinstall this module every time they either do a new installation from scratch or when the perl environment gets changed by SDL/RWS (which really is like every 10 years :-)

Having said that I find that the perl environment delivered with XPP is already a very rich one, especially now with the Strawberry perl that gets delivered with the Windows version of XPP (have no idea if on Linux the delivered perl is as rich). I tend to avoid modules that are not part of the standard delivered set.

I would be interested to know what 'extra' modules people use and what they use it for.
But maybe we need to open up a separate discussion on this as this thread is already becoming a long one - which is good because it was quite interesting.

Note: I just realized that I was the original author of the apt.pl tool. I had a quick look at the last version I had in my archive and to my surprise I see that I used a module Date::Manip that is (no longer?) part of the delivered environment. And I seem to have switched to Date::Manip because Date::Calc was not part of the delivered environment in Unix as I commented this as:
# V0.04 - BT - 18 mar 2013 - using Date::Manip instead of Date::Calc for embargo date calc (Date::Calc not part of xpp under unix)

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.