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.

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.

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.