my @listaccountlocked = split "=", $accountlocked;

chomp($listaccountlocked[1]);

if (uc($listaccountlocked[1]) eq "TRUE") {
[download]

my @listaccountlocked = split("=", $accountlocked);
if ($listaccountlocked[1] =~ /^true$/i) {
    system("chuser account_locked='false' $username");
    print(`lsuser -a account_locked $username`); }
else {
    print("\nThe account $username is not locked\n\n"); }
[download]

I prefer using uc and a string compare like the OP suggested. I did a quick benchmark, and it looks like it's faster (negligible if no strings match, roughly double the speed if they all match.

if (uc($listaccountlocked[1]) eq 'TRUE) {
[download]

Trivial benchmark:

Read more... (2 kB)

...roboticus

When your only tool is a hammer, all problems look like your thumb.

Another option is string escapes:

   if ("\U$listaccountlocked[1]" eq 'TRUE') {
[download]

I added another sub to your benchmark:

sub slashU {
     my $cnt=0;
     for (@words){
             ++$cnt if "\U$_" eq 'ABCB';
     }
     return $cnt;
}
[download]

But it didn't fare very well:

In 4096 words, 16 are 'abcb'
        Rate slashU  uccmp  regex
slashU 321/s     --   -18%   -26%
uccmp  390/s    21%     --   -10%
regex  435/s    36%    12%     --
In 4096 words, 0 are 'abcb'
        Rate slashU  uccmp  regex
slashU 328/s     --   -17%   -25%
uccmp  397/s    21%     --   -10%
regex  439/s    34%    11%     --
In 4096 words, 4096 are 'abcb'
        Rate  regex slashU  uccmp
regex  266/s     --    -6%   -18%
slashU 282/s     6%     --   -13%
uccmp  325/s    22%    15%     --
[download]

Ah well.

You have not used a fair test: note that my regular expression included the Metacharacters ^ and $. If I reconfigure your tests to consider this factor and swap to:

sub regex {
        my $cnt=0;
        for (@words) {
                ++$cnt if /^abcb$/i;
        }
        return $cnt;
}
[download]

I get the output:

In 4096 words, 16 are 'abcb'
        Rate uccmp regex
uccmp 1192/s    --   -5%
regex 1255/s    5%    --
In 4096 words, 0 are 'abcb'
        Rate uccmp regex
uccmp 1225/s    --   -3%
regex 1264/s    3%    --
In 4096 words, 4096 are 'abcb'
        Rate regex uccmp
regex  970/s    --  -23%
uccmp 1260/s   30%    --
[download]

which obviously compares much better. This still does not consider that the string compare require a chomp which the regular expression does not. Modifying your benchmark to consider this:

Read more... (2 kB)
yields the results:

In 4096 words, 16 are 'abcb'
        Rate uccmp regex
uccmp  812/s    --  -32%
regex 1197/s   47%    --
In 4096 words, 0 are 'abcb'
        Rate uccmp regex
uccmp  861/s    --  -31%
regex 1255/s   46%    --
In 4096 words, 4096 are 'abcb'
       Rate uccmp regex
uccmp 856/s    --  -11%
regex 964/s   13%    --
[download]

which I think clearly favors the regular expression. In addition, if you really wanted to squeeze out performance, you could skip the split in the OP as well:
Read more... (2 kB)
which yields:

In 4096 words, 16 are 'abcb'
       Rate uccmp regex
uccmp 200/s    --  -74%
regex 767/s  283%    --
In 4096 words, 0 are 'abcb'
       Rate uccmp regex
uccmp 200/s    --  -74%
regex 756/s  278%    --
In 4096 words, 4096 are 'abcb'
       Rate uccmp regex
uccmp 206/s    --  -66%
regex 603/s  193%    --
[download]

Update: As ikegami points out, I failed to localize the arrays to the test routines, so there were a large number of no-ops. Fixing that with the code my @words = @words added where appropriate reduced margins but maintained ordering. I suspect that is just a function of the linear overhead of copying the large arrays. If this is incorrect, I would appreciate insight.

Thanks guys. I did indeed forget that chomp() does not need to be assigned a new variable. I never thought much about using regex either. I am fairly new to that, so it does not come to mind right away.

Thank you very much for the help.