Retries, expirations, and returned data

The shipping server makes one attempt to transmit a packet to another host. If the packet cannot be transmitted (for example, because the receiving host is unavailable), the shipping server generates an error message and log file entry and exits.

You can set up a retry scheme to control its frequency:

After successful transmission of a packet, the shipping server deletes the packet and its shipping order. After a failure, the packet and shipping order remain in the storage bay.
shipping_server -poll transmits all packets it finds in one or more storage bays. Thus, any packets that remain after a transmission failure are sent (if possible) by the next invocation of shipping_server -poll.
The following job definition in the Scheduled Jobs for HCL VersionVault performs this operation every hour:
```
Job.Begin
 Job.Id: 16
 Job.Name: "Shipping Server Poll"
 Job.Description.Begin:
 Every hour, run the shipping server to send out any outstanding orders.
 Job.Description.End:
 Job.Schedule.Daily.Frequency: 1
 Job.Schedule.FirstStartTime: 00:00:00
 Job.Schedule.StartTimeRestartFrequency: 01:00:00
 Job.DeleteWhenCompleted: FALSE
 Job.Task: 13
 Job.Args: -quiet 1 -poll
Job.End
```
See the cleartool schedule reference page in the VersionVault Command Reference and Automated synchronization.

Attempts to transmit an undelivered packet can continue indefinitely, through repeated invocations of the shipping_server command. However, you usually want to fix problems with failed transmissions instead of letting the attempts continue. Accordingly, each shipping order can include an expiration date-time, specified with one of the following:

The command option -expire
(Linux™ and the UNIX™ system) An EXPIRATION entry in the shipping.conf file on the sending host
(Windows™) A Packet Expiration value in the MultiSite Control Panel on the sending host

For more information, see the shipping.conf reference page on Linux™ and the UNIX™ system or the MultiSite Control Panel reference page on Windows™.

By default, shipping orders expire 14 days after they are created.

When the shipping server encounters a shipping order that has expired, it does not attempt to transmit the corresponding packet to its destination. Instead, it does the following:

It modifies the shipping order to return the packet to the original sending host, where it is placed in a return bay.
It sends an electronic mail message to one or more addresses on the original sending host. (Another message is sent when the returned packet arrives at the original sending host.)
Note: If a packet is delivered through a Windows™ host on which electronic mail notification is not enabled, a failure on that Windows™ host means that no notification message is sent by electronic mail. Instead, a message is written to the event log; this message contains a request that the appropriate users be informed of the failure. For information about enabling electronic mail notification, see the MultiSite Control Panel reference page.

The return trip may involve multiple hops, as described in Indirect shipping route setup. During such a trip, a packet is placed in the return bay of each intermediate host. Each hop is handled by shipping_server -poll, which processes a host's return bay in addition to its storage bays. The expiration time for a packet's return trip is 14 days; a packet that cannot be returned in that interval is deleted.