User's Manual

only.
–u Process only transactions that have been backed up. This option
prevents the Message Agent from processing transactions since the latest
backup. Using this option, outgoing transactions and confirmation of
incoming transactions are not sent until they have been backed up.
In Adaptive Server Anywhere, this means only transactions from renamed
logs are processed. In Adaptive Server Enterprise, this means that only
transactions committed before the latest dump database or dump
transaction statement are processed.
–ud On UNIX platforms, you can run the Message Agent as a daemon by
supplying the -ud option.
If you run the Message Agent as a daemon, you must also supply the -o or
-ot option, to log output information.
If you run the Message Agent as a daemon and are using FTP or SMTP
message links, you must store the message link parameters in the database,
because the Message Agent does not prompt the user for these options when
running as a daemon.
☞ For information on message link parameters, see “Setting message type
control parameters” on page 214.
–v Verbose output. This option displays the SQL statements contained in
the messages to the screen and, if the -o or -ot option is used, to a log file.
–w n The number of worker threads used to apply incoming messages. The
default is zero, which means all messages are applied by the main (and only)
thread. A value of 1 (one) would have one thread receiving messages from
the message system and one thread applying messages to the database.
The -w option makes it possible to increase the throughput of incoming
messages with hardware upgrades. Putting the consolidated database on a
device that can perform many concurrent operations (a RAID array with a
striped logical drive) will improve throughput of incoming messages.
Multiple processors in the computer running the Message Agent could also
improve throughput of incoming messages.
The -w option will not improve performance significantly on hardware that
cannot perform many concurrent operations.
Incoming messages from a single remote database will never be applied on
multiple threads. Messages from a single remote database are always
applied serially in the correct order.
–x Rename and restart the transaction log after it has been scanned for
300