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.

Jay,

I think point 2 was mentioned in the SDL-RWS- XPP upgrade doc as something to look out for.

As for point 1 here is what the official perl doc has to say about the 'defined @array' thing:

Use of defined on aggregates (hashes and arrays) is no longer supported.
It used to report whether memory for that aggregate had ever been allocated.
You should instead use a simple test for size:

if (@an_array) { print "has array elements\n" }
if (%a_hash)   { print "has hash members\n"   }

I think that it was never very clear and open for discussion what a defined array or hash really meant...

Jay,

I think point 2 was mentioned in the SDL-RWS- XPP upgrade doc as something to look out for.

As for point 1 here is what the official perl doc has to say about the 'defined @array' thing:

Use of defined on aggregates (hashes and arrays) is no longer supported.
It used to report whether memory for that aggregate had ever been allocated.
You should instead use a simple test for size:

if (@an_array) { print "has array elements\n" }
if (%a_hash)   { print "has hash members\n"   }

I think that it was never very clear and open for discussion what a defined array or hash really meant...

I had one of our staff confirm that in root bashrc file - these instructions exist...

PATH="/root/perl5/bin${PATH:+:${PATH}}"; export PATH;
PERL5LIB="/root/perl5/lib/perl5${PERL5LIB:+:${PERL5LIB}}"; export PERL5LIB;
PERL_LOCAL_LIB_ROOT="/root/perl5${PERL_LOCAL_LIB_ROOT:+:${PERL_LOCAL_LIB_ROOT}}"; export PERL_LOCAL_LIB_ROOT;
PERL_MB_OPT="--install_base \"/root/perl5\""; export PERL_MB_OPT;
PERL_MM_OPT="INSTALL_BASE=/root/perl5"; export PERL_MM_OPT;

The PERL5LIB is interfering with autoproc --- root     11114     1  0 Jul22 ?        00:00:06 /opt/xyvision/xz/bin/bgquer

So, what is the way to bypass this?   Does the root user login and change to csh - and in csh login cshrc - set these values to null?

Thanks for all the information - it helps a lot.

I would just reiterate that there is no need to access XPP as the root user as an everyday production user. What is your requirement for this? I'd personally let root be root (for core system administration) and test XPP using more typical user access settings. 

But Jay we are talking about a program that is run through autoproc.
And isn't the sproc (autoproc) and bgquer started by root at system startup?
(as far as I remember running XPP on Unix that was the case)

You are correct, and Jonathan came with the authoritative explanation of how to control the behavior of autoproc by starting sproc with the necessary environment variables set in xyv.profile -> global.profile (which is sourced in rc.xyvision).