use Data::Dumper;

my %on_prop;
my %on_user;
while (<DATA>) {
    my @fields = split "\t";
    my %column_data = map {$_, shift(@fields)} qw(PROP COLOUR TXTCOL U
+RL360 USER YOUR_NAME ETC);
    $on_prop{$column_data{PROP}} = \%column_data;
    push @{$on_user{$column_data{USER}}}, \%column_data;
}

print Dumper(\%on_prop);
print Dumper(\%on_user);
print  scalar @{$on_user{'rob'}}; # prints 2 (more than one item for t
+his user)

__DATA__
123    Red    blue    whatever    rob    blah    blah    blah
124    Red    blue    whatever    rob    blah    blah    blah
125    Red    blue    whatever    jon    blah    blah    blah
[download]

Problems I see in your code:

• Your algorithm is fragile; it depends on the number of $user fields (scattered in %onprop) to match the same number of $user fields (clustered in @dataarray). It took me quite a bit of reading to understand this dependency, so I would say it will be 'non-obvious' to your maintenance programmers. If the lines in PAGE should change their sort order in the future (un-clustering the $users in @dataarray), or code is added to pre-filter the $users in only one of the two data structures, then your code will fail badly and *invisibly*, shifting away data with no warning that anything is amiss.
  The grouping problem is usually solved with a hash of arrays (HoA); see my code below.
• Your algorithm is wasteful; you must loop through %onprop, with hash lookups inside the loop, (keys(%onprop) * number_of_distinct_users) times. Also, your unless (! $item) could be moved outside the foreach my $scalar loop.
• Two problems with my $a = shift(@dataarray);
  1. The use of $a or $b outside of sort blocks is frowned-upon, due to their semi-magic.
  2. Since you are throwing the data away, it is better written without the receiving variable (void context), as in shift @dataarray;
• As others (++ to all) have pointed out, huge lists of scalar vars is non-optimal. @field_names and hash slices allow you to get rid of mystery numbers like 4 in @{ $onprop{ $scalar } }[4].
• When you said while (<@dataarray>), I shuddered. It would probably never fail in this particular program, but you should use while (@dataarray) instead. This should illustrated the difference:

  $ perl -MO=Deparse -e 'while (@d) {}'
  while (@d) {
      ();
  }
  
  $ perl -MO=Deparse -e 'while (<@d>) {}'
  use File::Glob ();
  while (defined($_ = glob(join($", @d)))) {
      ();
  }
  [download]

Here is my re-write of your core code, using HoA grouping and hash slices. Working, tested code:

#!/usr/bin/perl -W
use strict;
use warnings 'all';
use Data::Dumper; $Data::Dumper::Useqq = 1; $| = 1;

my @field_names = qw(
  PROP
  COLOUR
  TXTCOL
  URL360
  USER
  YOUR_NAME
  ADDRESS
  TOWN
  ZIP_CODE
  COUNTRY
  EMAIL
  TELEPHONE_NO
  TELEPHONE_NO2
  THEME
  WEB_ADDRESS
  PPEMAIL
  JUNK1
  JUNK2
  JUNK3
);
# Simplified @field_names for this example:
@field_names = qw(
  PROP
  COLOUR
  USER
  YOUR_NAME
);

# 'Prop' is a unique key in file PAGE and in hash %onprop.
my %onprop; # HoH

# 'user' is not unique, so each hash entry will be an array of 'Prop's
+.
my %user_props; # HoA

while (<DATA>) {
  chomp;
  next unless /\S/;
  my @fields = split "\t";
  warn unless @fields == @field_names;
  my %h;
  @h{@field_names} = @fields;
  my $prop = $h{PROP} or warn;
  my $user = $h{USER} or warn;

  # Create array of users and hash of data
  warn "Overwriting '$prop'" if exists $onprop{$prop};
  $onprop{$prop} = \%h;

  push @{ $user_props{$user} }, $prop;
}
print Data::Dumper->Dump(
  [     \%onprop, \%user_props   ],
  [ qw(  *onprop   *user_props ) ],
);

print join("\t", @field_names), "\n\n";
foreach my $user ( sort keys %user_props ) {
  my @prop_list = @{ $user_props{$user} };
  my $number_of_props = @prop_list;
  print "Grouped data ($number_of_props lines) for user '$user'\n";
  foreach my $prop (@prop_list) {
    my %h = %{ $onprop{$prop} };
    my @fields = @h{@field_names};
    print join("\t", @fields), "\n";
  }
  print "\n";
}
__DATA__
foo    red    jonnyfolk    Saint J
bar    white    Util    Me
baz    blue    jonnyfolk    Saint J
qux    black    Util    Me2
[download]

When you said while (<@dataarray>), I shuddered.

Indeed, when I saw it, I thought the code had not been really tested as claimed, for I could have bet it would have yielded an error. But this doesn't seem to be the case:

$ perl -MO=Deparse -e '@a=qw/a b c/; print while <@a>'
@a = ('a', 'b', 'c');
use File::Glob ();
print $_ while defined($_ = glob(join($", @a)));
-e syntax OK
[download]

and actually IMHO by virtue of an (un?)fortunate chance:

$ perl -le '@a=qw/a b c/; print while <@a>'
a
b
c
[download]

It seems that while (<whatever>)'s magic applies even if those angular parens are not to be interpreted as the IO-diamond operator but as the glob one. Now I wonder if this is a (perhaps unavoidable) side-effect or if it is intentional, although I doubt about the latter possibility.

Well, this may be a good subject for another question, or for a meditation... Update: done!

So, if you're not under strict (and warnings), please do!!

Said this, judging from your subject & description, as of the queek peek I gave into it, the obvious, mandatory quick answer would be: hashes. Since I don't seem to see any in your code chances are that it could be the correct one.

Check perldata for more info.

Update(taking into account your {reply,remark}):

open PAGE, "$website" or die "Cant open $website: $!";
flock (PAGE, 1) or die "Can't lock website file for reading";
[download]

while (my $line = (<PAGE>))  {
($Prop,$colour,$txtcol,$url360,$user,$your_name,$address,$town,$zip_co
+de,$country,$email,$telephone_no,$telephone_no2,$theme,$web_address,$
+ppemail,undef,undef,undef) = split "\t", $line;
#create array of users and hash of data
    $onprop{$Prop} = [$Prop,$colour,$txtcol,$url360,$user,$your_name,$
+address,$town,$zip_code,$country,$email,$telephone_no,$telephone_no2,
+$theme,$web_address,$ppemail];
    push (@dataarray, $user);
}
[download]

while (<@dataarray>) {
[download]

        unless (! $item) {
[download]

        if ($item) { ...
[download]

        next unless $item;
[download]

And so on...

Thanks for the quick answer - I can see you neither had time to read the code or the question (you'll see the quick answer doesn't really fit :) )

I should probably have mentioned (but didn't think to) that this is an excerpt from a larger script which does work under strict, is properly declared and if you take a closer look you'll see a hash staring right back out at you!!

As I also mentioned it does do the job I require, but I'd like an opinion from fellow monks as I'm not well skilled at this sort of thing.

Cheers

Update: I appreciate your further comments and will try to implement and learn for future use. Thanks very much.

I should probably have mentioned (but didn't think to) that this is an excerpt from a larger script which does work under strict, is properly declared and if you take a closer look you'll see a hash staring right back out at you!!

Sorry. Now I see. Indeed that long list of variables is mostly confusing (to me). To increase readability you may either
• use a list slice, and optionally put it into a temporary array: since you know which are the fields you're interested in in any case, you can access the (few) ones you want to use as "keys" by numeric subscript and the (many) other ones like aggregates or
• turn those variables into hash(ref) keys (thus possibly adopting a more complex, but easier to deal with data structure) hopefully specified with more whitespace to increase readability
instead.

As an example of the second point I mean something like (but modify at will):

while (<$page>) {
    my %localprop;
    @localprop{ qw(Prop
        colour
        txtcol
        url360
        user
        your_name
        address
        town
        zip_code
        country
        email
        telephone_no
        telephone_no2
        theme
        web_address
        ppemail) } = split /\t/;
    $onprop{ $localprop{Prop} } = \%localprop;
    push @dataarray, $localprop{$user};
}
[download]

As I also mentioned it does do the job I require, but I'd like an opinion from fellow monks as I'm not well skilled at this sort of thing.

Well, a suggestion is above, and the proposed code -although it may not be exactly what you need- is IMHO much less of a mess than the original one...