Machines not reporting data in DFWorks Postage Accounting Reports after Daylight Savings Time Change

print
Product Feature: Postage Accounting

Operating System: Windows Server 2008

Database: Oracle 11g

Configuration: All
 

Issue

After the Daylight Savings Time change, machines are not reporting pieces and postage in DFWorks Postage Accounting reports.

Cause

This particular problem can only happen during the Standard Time to Daylight Saving Time change ("Spring Forward"). It happens if there are 2 AM times in the piece data files generated by DC: There should be no such thing as 2 AM on March 8, 2015, because the clock goes from 1:59:59 to 3:00:00.


For example, during a spring time change ahead, if the site is running an inserter at 1:59 AM, the system clock on the inserter will move ahead to 2:00 AM. At the same time the DFWorks server will go from 1:59 AM to 3:00 AM and the database will never see a 2:00 AM time. Now when DFWorks starts to import the mail piece files from the inserter, it will try to match it up with events at the 2:00 AM time frame and not find any. 


System Wide Time Correction Procedure

Floor mail production will have to be stopped for a period of time.
This procedure should be done closest to 2 a.m. as possible and requires a restart of all systems listed below.
 
  1. Change/Verify that the time on the DC server is one hour ahead of the current time.
Note: The DC Server may adjust time on its own at 2 a.m. (to 3 a.m.)

A. Server/Workstation - Power Down Routine.
End all jobs on the floor and stop floor production.
 
Power down the following machines.
  1. Insite (If exists)
  2. Data Pump (If exists)
  3. DC/MSM - Workstations
  4. RSM    (If exists)
  5. Web/App server   
  6. DB server
Note: if Web/App & DB are in one box bring down the one box server.   
  

B. Server - Power Up Routine.
Please power up the following machines.
***NOTE: Be sure to double - check the DC Server to make sure it’s time is set correctly (3 a.m.)
  1. Bring up the DFWorks Data Base server (Check the time and Correct as needed)
  2. Bring up the DFWorks Web/App server (Check the time on the server).      
      
C. Workstation Power Up.
Please power up the following machines:

 
  1. Insite (If exists)
  2. Data Pump (If exists)
  3. RSM (if exists)
  4. DC/MSM Workstations one at a time and make sure when the batch file runs it sets the "correct time" on workstation. 
 
Once all the times are correctly set each Workstation can begin processing mail normally.   






 

Resolution

There are two ways to prevent a problem:
 
The easiest way is to turn bulk inserting off: This doesn't prevent some problems with the data but it does keep DFWorks from choking on the piece data files: DFWorks automatically converts the 2 AM times to 3 AM times (adding an hour). The reason why this is not a perfect solution is because, if the inserter is still not converted over to DST, it will generate more 3 AM times in the files (which are supposed to be 4 AM). So then there are potential event ordering problems because DFWorks sees two sets of events for 3:00:00 through 3:59:59. (This is the effect we just got from my fix, it was the best I could do, but at least DFWorks imported the data).
 
Essentially you edit the mailpiecefileimport.properties file and change bulkinserts=Y to bulkinserts=N.
 
A better approach is to stop each inserter before 2 AM, then wait until the time changes and restart DC. This will prevent any times in the 2 AM timeframe from showing up in the files at all.
 
For the future: DFWorks 3.1 will have support for time zones and will not be bothered by these changes, in the Spring or Fall, even if DC is not converted over right away. If we have DFWorks 3.1 released by next year you can install it and then you don't have to worry about these things!

If a site fails to comply with the "System Wide Time Correction Procedure" and they have a problem with mail piece files not importing, then they will need to contact DFWorks support. It will require a DFWorks system engineer to resolve this issue.

UPDATED: March 20, 2015