change log folder of bptm messages from /var/log/messages to different

Why on earth do you want to change this, this is where they are meant to go.

Customising systems in such a fashion leads to confusion, for example lets say you log a call and the messages log is requested as the TSE is expecting to find and wants to check for such errors ...

I need to do this because most of these messages are not needed (because tapes and tape drives are ok) but its monitored by our monitoring tool with high priority and we are contacted few times per night becuase of such messages/warnings. Its not ok to wake up three times per night because of some useful warning.

So in /var/log/messages are important logs of system but also not so much important like these.

And of course its not possible to filter such logs by monitoring tool :(

Th error messages are important - I bet you have a lot of status 84 and 86 in your Netbackup activity monitor. Now being waked at night because of a tape error is not necessary, but that a question of filtering at the monitoring side. 

Tape Alert messages will show up in /var/log/messages from time to time, that the nature of tape.

Think I used to work at same place ziro does.  :D

You have to educate the monitoring team - "this is important; this is not"

Having said that, Nicolai raises a good point.  If you are getting lots of tapes errors, that's a real problem and it shouldn't be ignored. 

OK, fair point regarding the reason - I used to get woken up myslef, fairly regularly for 'recoverable memory errors' on HP-UX.

However, TAPE_ALERTS are 'real' errors (apart from perhaps the cleaning warnings), though they don't always indicate a backup failure, but sometimes they do.

Is there really no way to tell the monitoring software 'what' to report on, seems very poor if not.

First what I do I contacted monitoring team, they cannot change priority because its generated by monitoring tool. Monitoring tool cannot filter messages and do diffreneces between log alerts. So last possibility is to redirect such bptm logs to another folder or file. Thats my question How to do it?

There are too many tape drives and tapes so almost every day occur some tape warnings or alerts. Once because of broken tape, mounting issue, cleaning request... But tape drives are ok, writing properly... broken tapes are frozen... so these logs are not needed for me.

Is it some possibility to change log directory or filter logs or disable such logs?

I would say no, its not possible and as Martin mentioned, if it was and you filtered out the messages, NetBackuo tools such as nbsu will not pick them up and could lead to NetBackup reported issues taking longer to resolve because you have moved the important messages that are needed to fix a problem.

Educate your monitoring team.

I'm going with revaroo on this one, simply request that TAPE_ALERTS are left to the next working day, if that is your preference, and no job failure has happened.

I don't think it can be changed, TAPE_ALERTS are not happening at the NetBackup level, they are happening at the drive firmware level and getting sent from there to the tape driver > OS > NBU, so I suspect if you 'removed' NBU from the equaution, you are still going to end up with TAPE_ALERTS in the messages log.

However, there is one way to check, and I suggest only doing this for a short time (education is the better bet).

Create this empty file on the media server(s)

/usr/openv/volmgr/database/NO_TAPEALERT

(or <install path>\veritas\volmgr\NO_TAPEALERT if windows)

This stops NBU logging TAPE_ALERTS (and is used for turning off tape cleaning) but as far as I know it stops NBU seeing ALL the diff tape alerts, which is why I don't recommend it, really really really don't recommend it ...

However, use it as a test and see if the TAPE_ALERTS still appear in system messages files.

You may want to remove VERBOSE entry from vm.conf on this server, followed by restart of ltid.

With no VERBOSE entry in vm.conf, only hardware errors should be logged to messages file.

The TapeAlerts in your opening looks like device errors to me that should not be ignored.