PostalOne!® Mail dat Technical Guide Version 19 0 March 2009 preface

Transferring Files

To increase the likelihood of files transferring successfully, use File Validator to verify Mail.dat files before transferring them. The tool checks the validity of the data elements in the file and records error messages and warnings to the user's hard drive. To use the File Validator, under Tools, click File Validator. This is discussed in detail in Section 2.4.1, Validating Files.

After the mailing passes validation, you are ready to transfer it. For information on this, see Section 2.4.2, Performing the File Transfer.

1. Validating Files

Before using the File Validator, verify that the Physical Memory (RAM) available on your machine meets the recommendations listed in the table below:

Table 3‑9. RAM Requirements Based on Net Job Size

Net Size of Mail.dat Job (MB) *	Recommended Physical RAM
0 - 10	64 MB
11 - 25	128 MB
26 - 50	256 MB
>50	>1024 MB

* The net size of a Mail.dat job is calculated as the "total size of all files" associated with a job, minus the size of the PQT, SNR, and PDR files.

For Mail.dat jobs with a large total file size, file transmission may result in an “Out of Memory” error. To resolve this issue, modify JVM memory limits, then retry the transmission. For more information on modifying memory limits for manual jobs, see Section 2.4.3.

To validate your Mail.dat files:

1. 
   Log on the test system. A special test system has been set up for new participants. It is located at https://cat.uspspostalone.com/postal1. This tool was created to provide a safe environment for testing files and to help you learn about the PostalOne! system.
   

25. 
    To open the File Validator page, on the left menu bar of the logon page, click File Validator. If you see a Security Warning pop-up box, click Yes to load the File Validator on your system as a temporary file. If you click No you will not load it or be able to use the File Validator.
    
26. 
    The "All Folders" pane displays your computer's local drives (usually A, C, and D). From the list, click the plus sign (+) next to the drive on which your job is saved.
    
27. 
    Scroll up or down to locate the folder in which your job is saved.
    
28. 
    Select the proper folder by clicking the folder name. The "File Contents of" pane displays the job header files.
    

29. 
    In the "File Contents of" pane, select the job header file you want to validate.
    

30. 
    Before you validate the files, you may wish to change the validation.log file's name and location by clicking Validation Log File. By default, the File Validator writes the results to C:\Validation.log.
    
31. 
    Click Validate File(s) to begin the validation process.
    
32. 
    If your job passes the file validation process, a message indicating that the validation was successful appears. If your job fails the validation process, an error message appears. For more information about examining the validation log file, see Section 2.4.1.4, Validation Log Errors.
    
33. 
    Click OK to close the message.
    

1. Validation Constraints

1. 
   To successfully pass the Mail.dat validation, the Mail.dat Presentation Category field in the Header record must be populated with one of the data values listed in the following table:
   

34. 
    The Mail.dat file structure is validated for the different Mail.dat transaction types, as follows:
    

• 
  The file level status flags must be consistent for a given Mail.dat transaction. For example, for an "original" transaction, all file level status flags in the header record must be set to "O". If some optional files are not included in the "original" transaction, the record count for those files must be 0 (zero). Similarly, for "update" or "change" or "delete" transactions, all file level status flags must be set to "U" or "C" or "D" respectively.
  
• 
  "Original" transactions – For original Mail.dat transactions, the Mail.dat file structure is verified based on the presentation category, as described above.
  
• 
  "Update" transactions – For all update transactions, the Header and the Segment files are required. All other files are optional.
  
• 
  "Change" transactions – For change transactions, the Header and the Segment files are required. All other files are optional.
  
• 
  "Delete" transactions – Two types of delete transactions are supported by the PostalOne! system. To delete a complete job (including all segments of the job), a Header and a Segment file must be sent, referencing all Verification Facility ZIP+4s within the job. To delete specific segments in a job, a Header and a Segment file must be sent identifying the specific Verification Facility ZIP+4s to be deleted.
  

35. 
    All key field relationships between the different records of the Mail.dat file are validated, based on the Presentation Category.
    
36. 
    All Mail.dat records are validated to ensure that no duplicate records exist based on the key field combinations.
    
37. 
    Mail.dat records are validated to ensure that all required children are present, for any given parent record of a Mail.dat job.
    
38. 
    If the Sibling Container field in the CSM record is set to “Y”, the following fields must have values:
    

• 
  Job ID
  
• 
  Segment ID
  
• 
  Container ID
  
• 
  Container Type
  
• 
  Sibling Container Indicator
  
• 
  Sibling Container Reference ID
  

• 
  All other fields, except for the optional label fields, in this CSM record MUST be left blank.
  
• 
  Validation rejects Ready-to-Pay Periodicals mailings with Sibling Container set to “Y”.
  
• 
  For MLOCR mailings, mailers should take extra care when using sibling containers to define logical pallet to physical handling unit relationships. For more information on handling this scenario, see the Mail.dat Specification.
  

39. 
    The Parent/Sibling Container relationship is validated. If a Sibling Container record exists, its parent must be present.
    
40. 
    If the Walk Sequence Record (WSR) file is used in the Mail.dat transmission, the Co-Palletization Code field in the MPU record must be present.
    
41. 
    If the Rate Category field in the PQT record is set to “A” (Saturation–ECR), the corresponding WSR record must be present.
    
42. 
    All Mailer Postage Account (MPA) records must have a value in the Permit ZIP+4/Postal Code field. The Permit ZIP+4 value must be the ZIP Code associated with the Post Office location where the permit is held or the original or additional entry office where the USPS Publication Number is held.
    
43. 
    Permit ZIP+4 – The PostalOne! application requires the Permit ZIP+4 field as part of the information necessary to uniquely identify a Permit number or USPS Publication Number at a Post Office location. For the PostalOne! system to complete an end-to-end transaction, it is necessary to have the Permit ZIP+4 information with all postage transactions.
    
44. 
    For the non-co-palletized portion of a co-palletized job, the co-palletized portion must not be included in the original file segment submitted for presort verification purposes. Packages in a co-palletized mailing must not be reported on a postage statement associated with the original presort. Mailings that are co-palletized cannot be reported unless a new file or file segment has been built that correctly identifies the package makeup of the new containers.
    
45. 
    If the Primary MPA ID in the MPU/Component Relationship (MCR) file of an update job is different from the original MPA ID, the new MPA ID must match the MPU – Unique Sequence/Grouping ID (positions 9-18) in the Mailer Postage Account (MPA) file of the first submission (original or preliminary).
    
46. 
    Individual container counts and the total container count cannot exceed the total number of pieces in a submitted postage statement.
    
47. 
    For Bound Printed Matter or Periodicals mailings that include First-Class Mail or Standard Mail enclosures, the permit used to pay for the enclosure must be a valid Permit Imprint, Metered, Precanceled Stamp, OMAS Imprint, or OMAS Metered permit. To designate a permit as the enclosure permit, in addition to standard required fields, mailers must set:
    

** For information on completing these fields, see the “Periodical with First-Class or Standard Mail Enclosure” section in the appendix of the Mail.dat Specification.

48. 
    For postage statements paying the Standard Mail rate using Pending Periodicals permits, the field Class Defining Preparation in the .seg file (position 73) must be “2” (Periodicals) and Class must be “5” (Periodicals Pending) as applicable in the .cpt file (position 80), .mpu file (position 93), and/or the Manifest Individual Record (.mir position 72). Pending Periodicals number must be in the Permit field (positions 58-65) of the .mpa file.
    
49. 
    Pending Periodicals are partially supported. Pending Periodicals are not available at all for parcel rates or mailings that include firm bundles (rate category “FB”). However:
    

• 
  Pending Periodicals with Preliminary container status can include First-Class Mail incidental enclosures, non-incidental enclosures, combined statements, or special authorizations (nonprofit, science of agriculture, or classroom rates), but the PostalOne! system will not generate a postage statement for the mailing.
  
• 
  Pending Periodicals with Ready-to-Pay container status with such enclosures or special authorizations are rejected.
  

50. 
    Validation accepts firm bundles, provided non-incidental enclosures are not included. For all mailings claiming firm bundles, Package Level in position 33 of the .pqt must be set to “A”. Additionally, firm bundles are considered a single piece and restricted to the Standard Mail limit of one pound. Pieces must be greater than zero if firm bundles are claimed, but copy number must exceed the piece count. A future release will allow non-incidental enclosures of First-Class Mail and Standard Mail so long as the Rate Category (.cqt position 35-36) is not “FB”. For non-incidental enclosures, firm bundles must be designated only by the .pqt Package Level equal to “A”.
    
51. 
    For metered or precanceled stamp postage, PostalOne! validation requires an .mpa file detailing the permit to be charged for additional postage. The additional postage .mpa ID must be used in the Additional Postage MPA ID (positions 27-36) field of the .mcr file. Additional postage may only be charged to a permit imprint account.
    

2. MLOCR Validation Constraints

• 
  The Barcode Verifier Indicator field in the Segment record (.seg position 163) is required.
  
• 
  Class can be First-Class Mail or Standard Mail, but not both.
  
• 
  Processing Category must be correct. For First-Class Mail, Processing Category must be Letter (“LT”), Card (“CD”), or Flat (“LT”). For Standard Mail, Processing Category must be Letter (“LT”).
  
• 
  Piece-weight must be correct for the class of mail and category. For example, the PostalOne! system verifies weights of 3.3 ounces for First-Class Mail Letters, 13 ounces for First-Class Mail Flats, and 3.3 ounces for Standard Mail Letters for postage meter affixed mailings.
  
• 
  Precanceled Stamps can only be used for 1 ounce First-Class Mail letter pieces and Standard Mail letters.
  
• 
  Container types must be trays on First-Class Mail Mixed ADC pallets.
  
• 
  The postage statement cannot claim a “Single Piece” Rate Category. For example, a Standard Mail postage statement cannot claim First-Class Mail single pieces.
  
• 
  All MPA files must pass validation. All jobs are rejected if one file fails.
  
• 
  Updates to MLOCR mailings must limit changes to piece counts, rate categories, container status, presentation category, and number of copies. If the mailing includes changes in any other fields, validation rejects the file.
  
• 
  Updates to MLOCR mailings must not result in a greater discount due to a rate category change.
  
• 
  Containers cannot have Container Status “P” (Preliminary) in an update file.
  
• 
  Containers with fewer than 150 pieces must also have a change in rate category that decreases the discount claimed from the original file.
  
• 
  An MLOCR mailing with Postage Payment Method (.mpa position 140) values “G” (Government), “S” (Precanceled stamps), “C” (Metered - Correct), “L” (Metered – Lowest), or “M” (Metered – Neither) must have one Additional Postage MPA ID (positions 37-46) in the MPU / C Relationship (.mcr) record. Only one account is currently allowed for additional postage payment for this type of mailing, even if the mailing includes multiple statements.
  
• 
  When sibling containers are used to identify a logical/physical container relationship in an MLOCR mailing, mailers should comply with the information in the Physical/Logical Trays and Pallets section of the Mail.dat Specification.
  
• 
  An MLOCR mailing cannot include a postage adjustment record (.par) file.
  
• 
  For MLOCR Standard Mail, heavy letters are not accepted.
  

3. Relationship Constraints Description

• 
  All header records present in a HDR file must belong to a single job.
  
• 
  There must be only one “current” header record present for a job, in a HDR file.
  
• 
  The PostalOne! system does not load or validate any “history” records present in a HDR file.
  

• 
  There must be at least one or more segment record(s) present in the SEG file for the unique Job ID present in the header file.
  
• 
  No duplicate segment records should be present in the SEG file considering the key fields of this record.
  

• 
  The number of mailer postage account record(s) present must match the number in the header file.
  
• 
  No duplicate mailer postage account records should be present in the MPA file considering the key fields of this record.
  

• 
  There must be at least one or more component record(s) present in the CPT file for the unique Job ID present in the header file.
  
• 
  No duplicate component records should be present in the CPT file considering the key fields of this record.
  

• 
  There must be at least one or more mailpiece unit record(s) present in the MPU file for each segment record present in the segment file.
  
• 
  No duplicate mailpiece unit records should be present in the MPU file considering the key fields of this record.
  

• 
  There must be at least one or more mpu/component relationship record(s) present in the MCR file for each mailpiece unit record present in the MPU file.
  
• 
  There must be at least one or more mpu/component relationship record(s) present in the MCR file for each component record present in the CPT file.
  
• 
  No duplicate mpu/component relationship records should be present in the MCR file considering the key fields of this record.
  
• 
  The Primary MPA ID must match an MPA ID submitted in the MPA file.
  

• 
  Because the PAR records are optional, there can be one or more postage adjustment record(s) present in the PAR file for each mailpiece unit record present in the MPU file.
  
• 
  Because the PAR records are optional, there can be exactly one postage adjustment record present in the PAR file for each component record present in the CPT file.
  
• 
  A single postage statement may have no more than one adjustment; however, multiple PAR records can apply to the same postage statement. Adjustments can only be applied to postage statements with “UPD” (USPS Processing Due) status.
  
• 
  For each PAR file submitted with Ready to Pay Adjustment Status (“R” in position 77), there must be at least one container in the CSM file with Container Status (position 98) set to “R” (Ready to Pay).
  
• 
  The MPA – Unique Sequence/Grouping ID (positions 78-87) in a PAR record must refer to a permit in an MPA file with Postage Payment Method (position 140) set to “P” (Permit Imprint) or “G” (OMAS Imprint).
  
• 
  A PAR file can be submitted as part of an O (Original) job; however, a PAR not have record status “U” (Update) or be included as part of an Update job. Alternately, a PAR file can be submitted with a “C” (Change) job that includes a PAR file with Insert (“I”) Record Status (position 76).
  
• 
  No duplicate postage adjustment records should be present in the PAR file considering the key fields of this record.
  

• 
  For the Manifest Summary presentation category, there must be one or more manifest summary record(s) present in the MSR file for each segment record present in the SEG file.
  
• 
  For all other presentation categories, there can be one or more manifest summary record(s) present in the MSR file for each segment record present in the SEG file.
  
• 
  No duplicate manifest summary records should be present in the MSR file considering the key fields of this record.
  

• 
  Because the WSR records are optional, there can be one or more walk sequence record(s) present in the WSR file for each segment record present in the SEG file.
  
• 
  Because the WSR records are optional, there can be exactly one walk sequence record present in the WSR file for each package quantity record present in the PQT file.
  
• 
  No duplicate walk sequence records should be present in the WSR file considering the key fields of this record.
  

• 
  For the Manifest Summary presentation category, there can be one or more container summary record(s) present in the CSM file for the unique Job ID present in the header file.
  
• 
  For all other presentation categories, there must be at least one or more container summary record(s) present in the CSM file for the unique Job ID present in the header file.
  
• 
  No duplicate container summary records should be present in the CSM file considering the key fields of this record.
  

• 
  For the “Manifest Individual” presentation category, there must be one or more manifest individual record(s) present in the MIR file for each container summary record present in the CSM file.
  
• 
  For all other presentation categories, there can be one or more manifest individual record(s) present in the MIR file for each container summary record present in the CSM file.
  
• 
  If the MIR records are used, there can be exactly one manifest individual record present in the MIR file for each special fees/charge record present in the SFR file.
  
• 
  No duplicate manifest individual records should be present in the MIR file considering the key fields of this record.
  

• 
  Because the ICL records are optional, there can be exactly one international container label record present in the ICL file for each container summary record present in the CSM file.
  
• 
  No duplicate international container label records should be present in the ICL file considering the key fields of this record.
  

• 
  There must be at least one or more container quantity record(s) present in the CQT file for each container summary record present in the CSM file.
  
• 
  No duplicate container quantity records should be present in the CQT file considering the key fields of this record.
  

• 
  Because the PLR records are optional, there can be one or more package label record(s) present in the PLR file for each container summary record present in the CSM file.
  
• 
  No duplicate package label records should be present in the PLR file considering the key fields of this record.
  

• 
  If a piece detail record is available for every container quantity record in a job, the package quantity records are optional. There can be one or more package quantity record(s) present in the PQT file for each container quantity record present in the CQT file.
  
• 
  For Periodicals, the package quantity records are required to determine applicable bundle charges, and to produce the qualification and bundle reports.
  
• 
  If a piece detail record is not available for every container quantity record in a job, the package quantity records are required. There must be one or more package quantity record(s) present in the PQT file for each container quantity record present in the CQT file.
  
• 
  If the package label records are used, there can be one or more package quantity record(s) present in the PQT file for each package label record present in the PLR file.
  
• 
  No duplicate package quantity records should be present in the PQT file considering the key fields of this record.
  
• 
  All PQT records with the Saturation – ECR Rate Category (A) require one or more associated Walk Sequence (WSR) records or the job will fail validation.
  

• 
  PDR files are required and validated only when the Seamless Acceptance Indicator in the segment record (position 261) value is “Y”. Otherwise, this file is not processed.
  
• 
  If this optional file is included, the header file must have the correct record count and file status.
  
• 
  No duplicate piece detail records should be present in the PDR file considering the key fields of this record.
  

• 
  Because the SNR records are optional, there can be one or more seed name record(s) present in the SNR file for each package quantity record present in the PQT file.
  
• 
  No duplicate seed name records should be present in the SNR file considering the key fields of this record.
  

• 
  Because the SFR records are optional, there can be exactly one special fees/charge record present in the SFR file for each piece detail record present in the PDR file.
  
• 
  No duplicate special fees/charge records should be present in the SFR file considering the key fields of this record.
  

• 
  This file type is only supported for Mail.dat version 07-1; these files are obsolete in version 08-1 and 08-2.
  
• 
  If this optional file is included, the header file must have the correct record count and file status.
  

• 
  This file type is only supported for Mail.dat version 07-1; these files are obsolete in version 08-1 and 08-2.
  
• 
  Every APF record must be associated with a valid ATF record.
  
• 
  If this optional file is included, the header file must have the correct record count and file status.
  

• 
  If this optional file is included, the header file must have the correct record count and file status.
  

4. Validation Log Errors

Use a text editor or other tool to view the log file.

1. 
   Click Start and select Run. The Run dialog box opens.
   

52. 
    In the Open box, type wordpad and click OK to open the WordPad window.
    
53. 
    From the File menu, select Open to open the Open dialog box.
    
54. 
    Ensure that “C:” appears in the Look in box. If it does not, select it from the list.
    
55. 
    In the File name box, type validation.log, then click Open. WordPad opens the file and displays error messages from the oldest to the most recent.
    

For a complete listing of error messages that appear in the Validation.log file, see Appendix E. Error Messages.

2. Performing the File Transfer

To transfer Mail.dat job files manually:

1. 
   On the left menu bar, click File Transfer. You will probably see a Security Warning message. If you do not see it, minimize or move the browser window—it may be hiding the message. Click Yes. If you do not click Yes, or if you click No, you cannot transfer files to the PostalOne! system. The File Transfer page displays the “All Folders” and “File Contents of” panes.
   

56. 
    The “All Folders” pane on the left displays your computer's local hard drives (usually A, C and D). Click the plus sign (+) next to the drive on which your jobs are saved.
    
57. 
    In the “All Folders” pane, scroll up or down to locate the folder in which your job is saved.
    
58. 
    Select the proper folder by clicking the folder name. The “File Contents of” pane on the right displays the job header files.
    

59. 
    In the “File Contents of” pane, select the header file of the job you want to transfer.
    

60. 
    Once you have selected the job header file(s), you can determine the location and name of the log file, just as you did when using the File Validator. To do this, click Validation Log File. By default, the File Validator writes the results to C:\Validation.log.
    
61. 
    Click Transfer file(s) to begin the transfer. While the file is transferring, you see a blue status bar beneath the “File Contents of” pane indicating transfer progress.
    
62. 
    After your job has transferred, a message indicating the transfer status appears. Click OK to close the message and continue working. If you are transferring multiple jobs, the transfer message appears after each job is transferred. When each message appears, click OK to continue working. NOTE: If you do not click OK to close the message, the remaining jobs will continue to transfer in the background.
    
63. 
    To check the status of your transferred jobs, click Transfer Summary.
    

To check transferred job and file upload status:

1. 
   On the File Transfer page, click Transfer Summary. The Job Status page opens. It does not initially display recently transferred jobs. To display recently transferred jobs, click the Refresh button at the top-right of the table.
   

64. 
    By default, the Job Status page displays the first eight jobs. To view the next eight jobs, click Next 8 at the bottom of the page.
    

65. 
    To check file upload status, click a Job ID in the Jobs column or enter the Job ID in the Search Job ID box, then click Search.
    

66. 
    To view the status of a file's progress, click the file name in the File (Click F for Errors) column. A message box displays error details.
    
67. 
    To close the message and continue working, click Close.
    
68. 
    If your mailing job was not transferred successfully, you should check the Transfer Summary and the Validation Log file.
    
69. 
    If the Transfer Summary or Validation Log file entry(s) indicates that your mailing job (Mail.dat file) was not transferred successfully, you will need to analyze your Mail.dat file. If you produced the mailing file using a third-party vendor’s software product, you will probably need to contact them for help in resolving the problem. If you produced the mailing file using “in-house” software, you will probably need to analyze the file or contact technical resources to help you resolve the problem. Some customers use a third-party Mail.dat viewer to analyze their Mail.dat files to resolve problems. Other customers analyze the Mail.dat file using a text editor capable of counting lines and character positions.
    

3. Adjusting Memory Limits for Manual Transfers

In manual transfers, customers use the File Transfer applet in the PostalOne! system to upload Mail.dat files. Java plug-in technology extends browser functionality to allow applets to run under Sun Microsystem’s Java Runtime Environment (JRE) rather than the default browser JRE. The default memory limit for Java plug-ins is usually around 60-90MB. When the users upload Mail.dat jobs with large file sizes, the Java plug-in runs out of memory, causing the upload process to fail with an “Out of Memory” error. To resolve the issue, modify the memory settings used by the Java plug-in to a higher number. This does modify the limits for the plug-in for all applications, not just the PostalOne! system.

1. 
   Verify the version of Java plug-in currently installed. The steps to follow vary based on your Java version.
   
2. 
   Verify your machine has sufficient memory to increase the memory limits. Do not modify memory limits if your machine lacks sufficient memory.
   
3. 
   Increase memory limits. For Java plug-in versions 1.4.2_x, follow the steps in Section 2.4.3.3. For all later Java plug-in versions, follow the steps in Section 2.4.3.4.
   

1. Verifying Java Installation

2. Verifying Memory

3. Increasing Memory Limits for Java 1.4.2_x

1. 
   Close any open browser windows, including any PostalOne! windows.
   
2. 
   On the Windows taskbar, click the Start button, then click Control Panel.
   
3. 
   Double-click the Java Plug-in icon.
   

4. 
   Click the Advanced tab.
   
5. 
   Click the Java Runtime Parameters box, then enter: -Xmx512m
   
6. 
   Click the Browser tab. If the check box is not selected, select the check box for the browser used to access the PostalOne! Web site.
   
7. 
   Click Apply, then close the Java Plug-in dialog box.
   
8. 
   Retry the transfer.
   
9. 
   If the “Out of Memory” error reoccurs, repeat this process to increase the memory value further, but use a memory limit other than 512 in step 5. For example, set the runtime parameter to –Xmx768m to use 768 MB, then retry the upload process.
   

4. Increasing JAVA Memory Limits for Java 1.5.x or 1.6

1. 
   Close any open browser windows, including any PostalOne! windows.
   
2. 
   On the Windows taskbar, click the Start button, then click Control Panel.
   
3. 
   Double-click the Java Plug-in icon.
   

4. 
   Click the Java tab, then under Java Applet Runtime Settings, click View. A dialog box appears listing all Java Runtime Versions.
   
5. 
   Click the most recent JRE version, then double-click the Java Runtime Parameters box for the selected line. Enter: -Xmx512m
   
6. 
   Click OK.
   
7. 
   Click OK again to close the Java dialog box.
   
8. 
   Retry the transfer.
   
9. 
   If the “Out of Memory” error reoccurs, repeat this process to increase the memory value further, but use a memory limit other than 512 in step 5. For example, set the runtime parameter to –Xmx768m to use 768 MB, then retry the upload process.
   

3. 
   
   Download 6,32 Mb.