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.