At first glance I'd have to guess that the "environment" of background processing is running the wrong version of Perl, and that it's using some "system" version of Perl located at /root/perl5 rather than the XPP Perl at /etc/xyvision/common/perl (which is probably linked on your system to /opt/xyvision/xz/etcxyvision/common/perl).

Is background processing running on the same "machine" as when you are running this script with XPP Perl?

Is there any PER5LIB environment variable that might have a different value in the background versus foreground environment?

What is the exact command that you are running when you run it with XPP Perl versus the exact command that is being run by background processing?

I know this is a kludge, but to work around possibly missing perl code with the improper #! line definition...at one point we pointed everything to the correct library via symbolic link.

Then we corrected code at a more leisurely pace.

Bill,

If this apt.pl thing is started through auto proc, the first thing to check is the entry in the autoprocessing spec.
Is the entry a fully specified path to the perl executable?
If so it should normally point to /etc/xyvision/common/perl/bin/perl which is the perl delivered with the xpp system (unless somebody in your company has a very good reason to run a different version of perl - I would seriously doubt whatever reason somebody might have to do so- but that is a totally other thing)

If the entry in the autoproc spec, just says apt.pl, then the next thing to do is to verify the magic line (the !# line)  at the top of the APT.pl script to see what 'perl' you are running.
If should be something like

#!/etc/xyvision/common/perl/bin/perl 

If that is the case, the better way to check if Perl can find a certain module would be in that case:

>/etc/xyvision/common/perl/bin/perl -Mstrict -e 

You will get nothing back if the module can be loaded successfully. And an overview of the content of @INC if things go wrong.

Also check that the /etc/xyvision/common/perl is still linked to the xpp delivered version of perl

But from the error messages you are getting back either the autoproc entry is using the 'wrong' version of perl (remember that a linux system might come with loads of different perl installations) or the magic line on apt.pl is either missing or pointing to the wrong perl installation.

So the APT.pl is running in autoproc and is fully qualified /opt/xyvision/xz/procs/site/APT.pl.  Next, we do have XPP Perl 5.28 and Native Perl 5.16. 

The shabang line in APT.pl  is #!/etc/xyvision/common/perl/bin/perl. 

We do have a symbolic link for /etc/xyvision to  /opt/xyvision/xz/etcxyvision.   

I created a perl program to check the contents of @INC.   

When I run my test program - there is an extra directory 

<inc>
/root/perl5/lib/perl5
/etc/xyvision/common/perl/lib/site_perl/5.28.1/x86_64-linux-thread-multi
/etc/xyvision/common/perl/lib/site_perl/5.28.1
/etc/xyvision/common/perl/lib/5.28.1/x86_64-linux-thread-multi
/etc/xyvision/common/perl/lib/5.28.1
</inc>

But when I run my test program interactively - that line /root/perl5/lib/perl5 is not there.

So, we are running the correct Perl version - but something is adding that directory.

I checked PERL5LIB and PERLLIB environment variables - but did NOT find any.

So does that leave the account that is assigned autoproc system - root?

Bill,

Maybe you need to 'extend' your test program a bit and try to print out the complete environment:

foreach my $key (keys %ENV) {
  print "\t$key = $ENV{$key}\n";
}

Like that you will at least find the account that is running your autoproc programs.

And you might also find the PERL5LIB or PERLLIB setting....

Yes your are correct - I added your code to my test program and it outputted this..

PERL5LIB = /root/perl5/lib/perl5

PERL_LOCAL_LIB_ROOT = /root/perl5
PERL_MB_OPT = --install_base "/root/perl5"

SHELL = /bin/bash   

USER = root

We normally use csh  

This is our DEV server which had the 9.4 upgrade and was rebooted.

I am going to run it on TEST server which had the 9.4 upgrade but was not rebooted

And on our PROD server which has 9.2.2 XPP version.

Do you want to see the actual file outputs?

Have you tested this as a user other than "root"? One thought is that the root user, using bash as its shell, may not be sourcing the XPP environment (i.e. source /etc/xyvision/xyv.cshrc). So you are getting your OS default rc/init environment.

You are correct - it looks like the root account on our XPP server is running bash instead of csh.

The user who ran the upgrade - was not able to run /etc/xyvision/xyv.cshrc.

I confirmed the file was there and works.

I created a test perl program do dump the environment variables and SHELL = /bin/bash.

I have contacted our IT department about getting this resolved with the 9.4.1 upgrade and fixing the root account to use csh.

Waiting on them for time to get fix in.

I do NOT have root privs.

Off topic, but there were a couple of interesting "gotchas" in our upgrade earlier this year (8.4 to 9.4, but more importantly Perl 5.10 to 5.28).

1. "if (defined @array) ..." no longer compiles. Apparently, scalars can be undefined, but arrays, not so much. "my $var;" is undefined. But, "my @array;" is apparently the same as "my @array = ();" At least that's my own understanding. "Once mentioned, arrays are defined." So we had a lot of these, including in professional services provided source code, so they all had to be changed to "if (@array) ..." (i.e. implicit "if (scalar @array)..."

2. @INC no longer contains "." (the current directory), due to security concerns. I think that changed in Perl 5.26? This showed up a few times for some programmers who liked to write their own one-off Perl packages and put them in the cwd for simplicity's sake.

FYI... I don't necessarily recommend changing the default login shell of root. I'm not a full-on unix admin, but I'd worry that it could interfere with OS operation. When I am noodling around as root (because I can), it's easy enough to switch to csh (I use tcsh personally) at the command line. I always start out logging in as myself. Basically:

### logged in as myself, csh shell 

$ su - root

Password: ****

### logged in as root, bash shell

$ tcsh

$ source /etc/xyvision/xyv.cshrc

$ source [some site aliases]

$ source [some personal aliases]

---

The only XPP things I do as root are start the daemons/services. And Tomcat (XPPWS) runs as root, which initially caused some problems. On Red Hat EL 5 there wasn't as much security, and we managed to install XPPWS as a non-root user. Part of our upgrade was to Red Hat EL 7.7, which has a lot of security that we had never seen before. Also, at the time, we could only manage to install and run XPPWS as the root user.