All very interesting points. I will be putting this to veritas via 
http://enhancement.veritas.com/ as someone suggested. (Thanks)

What i did in the end was to just change CLIENT_NAME = host     to 
CLIENT_NAME = host.disable   in bp.conf on the client. This caused a 
status 59 error. Obviously the number of restires occurred but i didnt 
see any other way.

Heres a quick script i wrote to do this i have now put on my clients to 
disable them.

root@host# cat bin/NBU_disable_local_client

#!/bin/sh
#set -x
#
# Script to disable local netbackup client so it faiils.
#
# Dave Markham - 12-04-05

NBUPATH=/usr/openv/netbackup
VOLPATH=/usr/openv/volmgr
PATH=$PATH:$NBUPATH/bin:$NBUPATH/bin/admincmd:$NBUPATH/bin/goodies:$VOLPATH/bin
export NBUPATH VOLPATH PATH
HOSTNAME=`/usr/bin/hostname`
DATE=`/usr/bin/date +%d%m%y`
BPCONF=$NBUPATH/bp.conf

error_check()
{
in=$1
function=$2
if [ $in != 0 ]
then
        echo "\n[Problem with $function Exiting...]\n"
        exit
fi
}


# Client Set #
CLIENT=`awk '/^CLIENT_NAME/ && $3 !~ /disable/ {print $3}' < $BPCONF`
if [ ! "$CLIENT" ]
then
        error_check 1 "Client set"
fi


# Make backup
cp $BPCONF $BPCONF.pre.client_disable.$DATE
error_check $? Copy

# Replace Client name
sed -e 's/'"$CLIENT"'/'"$CLIENT.disable"'/' $BPCONF > $BPCONF.new
error_check $? "Sed Replace"

# Move new file into place
mv $BPCONF.new $BPCONF
error_check $? "File Move"




Eric Ljungblad wrote:

> 
>With 5.0 or better  just have the operators suspend the job until OK's
>-----Original Message-----
>From: Ed Wilts
>To: Karl.Rossing AT Federated DOT CA
>Cc: veritas-bu AT mailman.eng.auburn DOT edu
>Sent: 4/13/2005 9:02 AM
>Subject: Re: [Veritas-bu] Disable a client for one night
>
>On Wed, Apr 13, 2005 at 08:22:50AM -0500, Karl.Rossing AT Federated DOT CA
>wrote:
>  
>
>>You could on the client exclude everything(I don't like this one, cuz
>>    
>>
>i 
>  
>
>>would more likely forget to set it back)
>>    
>>
>
>The other problem is that if the schedule says to do a full, the "full"
>will be marked as succesful.  Tomorrow, when you're doing an
>incremental, you'll only back up files modified since today's "full"
>instead of doing another full.  If you need to do a restore, you'll go
>back to your last "full" instead of a backup that actually contains
>something useful.
>
>You're better off either not scheduling the job at all or having it
>fail.
>
>The moral of the story is don't lie to NetBackup.  It bites back.
>
>        .../Ed
>
>  
>