The standard HP-UX syslogd won't treat incoming remote log messages any differently from local ones, and it cannot manipulate the facility/priority codes of outgoing syslog messages.
If you're setting up a dedicated log server, it might be worthwhile to install an advanced syslog daemon (syslog-ng or rsyslog) to the log server. Most advanced syslog daemons can be configured to listen for incoming remote syslog messages only, so the syslog server's own local logging can remain unaffected, if you wish.
Advanced syslog daemons also include a more flexible configuration language: this will allow you to store log messages to different files based on which server sent it, and (at least in the case of rsyslog) even to automatically create the log file if it doesn't already exist. For the standard syslog daemon, you'll have to create the logfile first before the syslog daemon can start writing to it.
You can also filter log messages by regular expressions: if some application produces messages that are recognizable using a regexp, this will give you an easy way to file those messages to a separate file, even if the application cannot use a custom syslog facility.
If you want to get really fancy, you can set your advanced syslog daemon to output the messages to a table in a database. Sure, it's more work to set it up that way, but once you have your logs in a database, indexed by e.g. time, hostname, syslog priority, facility and/or process name, you'll have the full power of the database to help you analyze the mass of logs. For example, you can easily calculate the amount of log messages per day sent by each host. You would expect this to stay about the same if nothing is changed: for example, if some host suddenly starts to log 10x the amount it normally does, it might be worthwhile to check it out, even if the messages are not strictly errors.
(We implemented this kind of setup: after a week or so, we caught a file transfer script that was stuck in infinite loop, transferring the same file over and over because someone had left an incorrectly-named file to the transfer directory.)
Or you could use database triggers to alert you when a version number included in a particular type of log message indicates one of your hosts has a version of sendmail or sshd that has serious known bugs.
Many of these things are possible with shell scripting too; but using a database allows non-trivial searches and makes everything much easier and faster.
There are even free Web GUIs for browsing such log databases available: you don't have to learn SQL to use your log database effectively.
MK
MK
