Behavior on server connection failures

Mode 2: Allow new jobs to print and log after reconnection

This mode allows jobs to print when the connection to the primary server is down, but when the connection is re-established these jobs are re-sent to the Application Server and logged (a "fail open" mode with re-send/offline mode). Use this mode when:

• It is important to not interrupt printing when outages occur,

• It is important to log/charge every job printed during failures,

• Strict quota enforcement is less important. Users can use more credit than they have available.

In this failure modeFailure mode allows you to control the behaviour under error conditions, such as connections problems between the Application Server and secondary server. the administrator can configure how these resent jobs are recorded in the job logThe job log retains a history of all print jobs including the following details: the user who printed (ie. their network user ID), the time of the print event, the number of pages, document attributes such as color, duplex, grayscale, paper size, document area, paper length, where the print job originated from (the workstation name or IP address), and the document name and type (for example, a Word document’s file name).:

1. Leave the job information unchanged (i.e. log the job against the user that printed it),

2. Change the recorded user to another nominated user,

3. Change the charging of the print job to a nominated shared accountA shared account is an account that is shared by multiple users. For example, in business, shared accounts can be used to track printing costs by business unit, project, or client. Organizations like legal firms, engineering firms, or accounting offices often have long lists of accounts, projects, clients, or matters. In a school or university, shared accounts can be used to track printing by departments, classes, or subjects..

The default reconnection option is 1, where logging and charging is done in the same way as if the recording was done live. The administrator might consider this unfair to charge the user during this failure time (as there were no warning popups or ways of telling that the user's quota was reaching its limit). It might be more reasonable to use the reconnection options of 2 or 3. With option 2, the administrator can choose a new user, such as "AppServerDown" to record the job as and in this way completely divorce the user from jobs printed during the failure.

If the administrator wants to track who did the printing but thinks it is unfair to charge their personal account, then choose reconnection option 3, and a new shared account such as "AppServerDown", or an account corresponding to the department owning the printer can be charged. Jobs are still recorded under the user's name.

When the connection to the Application Server opens up again, the print jobs show up in the Application Server's job log within a few minutes. They show up with a special status and icon in the job log (see figure below).