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

Transferring Files
When mailers send files to the PostalOne! system, the file transfer software performs high-level file structure verification (called file validation) by checking the record counts for Mail.dat files provided in the Header record against the actual records present in the attached files. It also checks that all required fields exist. File Transfer fails the job if a required field is missing. It validates key field relationships between one or more records of files and verifies the structural and hierarchical integrity of the entire job by validating the proper existence of all predefined parent-child relationships.
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.
Validating Files
The File Validator checks your Mail.dat files to ensure that all required fields are populated and contain the correct character format. This section explains how to use the File Validator feature.
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.
NOTE: These memory requirements are for a single thread; when sending multiple simultaneous jobs, use the sum of all net sizes to estimate memory requirements.
To validate your Mail.dat files:
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.
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.
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.
Scroll up or down to locate the folder in which your job is saved.
Select the proper folder by clicking the folder name. The "File Contents of" pane displays the job header files.
NOTE: If the folder containing your job is in a subfolder, click the plus sign (+) next to the main folder to display the subfolders. From the subfolders, locate and select the appropriate folder.
In the "File Contents of" pane, select the job header file you want to validate.
NOTE: To validate multiple job header files simultaneously, hold down the CTRL key while you select the job files.
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.
Click Validate File(s) to begin the validation process.
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.
Click OK to close the message.
Validation Constraints
The following relationship constraints are validated:
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:
Table 3‑10. Presentation Category Values Required to Pass Validation
Data Value
|
Value Definition
|
Rules of Validation
|
P
|
Conventional Presort
|
If Mail.dat Presentation Category is P, the following files must be present to successfully pass validation.
Header
Segment
MPU
MPU/C Relationship
Mailer Postage Account
Component
Container Summary
Container Quantity
Package Quantity
Optional files:
|
M
|
MLOCR
|
If Mail.dat Presentation Category is M, the following files must be present to successfully pass validation.
Header
Segment
MPU
MPU/C Relationship
Component
Container Summary
Container Quantity
Mailer Postage Account
Package Quantity
|
I
|
Manifest Individual
|
If Mail.dat Presentation Category is I, the following files must be present to successfully pass validation.
Header
Segment
Component
Container Summary
Manifest Individual
Optional Files:
|
S
|
Manifest Summary
|
If Mail.dat Presentation Category is S, the following files must be present to successfully pass validation.
Header
Segment
Component
Mailer Postage Account
Manifest Summary
|
N
|
Single-Piece
|
If Mail.dat Presentation Category is N, the following files must be present to pass validation:
Set A:
Header
Segment
Component
Manifest Summary
Manifest Individual
Container Summary
- OR -
Set B:
Header
Segment
MPU
MPU/C Relationship
Mailer Postage Account
Component
Container Summary
Piece Detail Record
|
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.
All key field relationships between the different records of the Mail.dat file are validated, based on the Presentation Category.
All Mail.dat records are validated to ensure that no duplicate records exist based on the key field combinations.
Mail.dat records are validated to ensure that all required children are present, for any given parent record of a Mail.dat job.
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
NOTE:
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.
The Parent/Sibling Container relationship is validated. If a Sibling Container record exists, its parent must be present.
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.
If the Rate Category field in the PQT record is set to “A” (Saturation–ECR), the corresponding WSR record must be present.
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.
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.
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.
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).
Individual container counts and the total container count cannot exceed the total number of pieces in a submitted postage statement.
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:
Table 3‑11. Enclosure Payment Settings
File
|
Field
|
Position(s)
|
Description
|
MPA
|
MPA – Unique Sequence/Grouping ID
|
9-18
|
Unique identifier for enclosure
|
MPA
|
Permit Number (if applicable)*
|
58-65
|
Permit used to pay for the enclosure
|
MPA
|
USPS Publication Number (if applicable)*
|
49-57
|
USPS Publication Number used to pay for the enclosure
|
MCR
|
Component ID
|
18-25
|
Component that is the enclosure
|
MCR
|
Primary MPA ID
|
27-36
|
Points to the MPA file
|
CPT
|
Component – Class**
|
80
|
For Periodicals with enclosures only.
|
CPT
|
Component – Rate Type**
|
81
|
For Periodicals with enclosures only.
|
* Use either a Permit Number or a USPS Publication Number to pay for an enclosure, not both. If the enclosure does not have the correct parameters set in the Mail.dat file, the file fails with the error: ORA-20001: EXITING WWS Data Submission Package – Multiple qualified MPA_UIDs found for JOB_SEQ_NUM=[#],SEGMENT_ID=[ID],MPU_ID=[ID],CLASS=[class].
** 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.
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.
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.
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”.
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.
MLOCR Validation Constraints
In addition to the standard file validations, the PostalOne! system validates Multi-Line Optical Character Reader/Barcode Sorter (MLOCR/BCS) mailings and fails jobs that do not comply with the following:
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.
Relationship Constraints Description
This section describes the relationship constraints validated by the validation module, based on the different Mail.dat presentation categories. To determine which files are required for the various Mail.dat “Conventional Presort” transactions, see Section 2.3.5, Sending Job Updates.
NOTE: Only the “Conventional Presort” Mail.dat presentation category is currently implemented and tested in the PostalOne! system. All other presentation categories are currently supported by the file transfer module, but have not been tested as part of the complete PostalOne! system.
HDR: (required for all presentation categories)
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.
SEG: (required for all presentation categories)
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.
MPA: (required for all presentation categories)
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.
CPT: (required for all presentation categories)
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.
MPU: (required only for “Conventional Presort” and “MLOCR” presentation categories)
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.
MCR: (required only for “Conventional Presort” and “MLOCR” presentation categories)
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.
PAR: (optional for all presentation categories)
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.
MSR: (required only for “Manifest Summary” presentation category)
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.
WSR: (optional for all presentation categories)
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.
CSM: (only optional for Manifest Summary presentation category)
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.
MIR: (required only for “Manifest Individual” presentation category)
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.
ICL: (optional for all presentation categories)
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.
CQT: (required only for “Conventional Presort” and “MLOCR” presentation categories)
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.
PLR: (optional for all presentation categories)
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.
PQT: (required for “Conventional Presort” if no PDR records are used or if mail class is Periodicals, and required for “MLOCR” presentation category)
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: (required only if Seamless Indicator on the segment record is set to “Y”)
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.
SNR: (optional for all presentation categories)
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.
SFR: (optional for all presentation categories)
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.
ATF: (optional for all presentation categories)
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.
APF: (optional for all presentation categories)
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.
IAK (optional)
If this optional file is included, the header file must have the correct record count and file status.
Validation Log Errors
If your job fails the validation process, an error message appears. To determine why the validation failed, write down the error message, and then inspect the log file written by File Validator. If you have not changed the name and location of the Validation Log file (see Section 2.4.1, Validating Files), its default is C:\Validation.log.
Use a text editor or other tool to view the log file.
NOTE: The Validation Log file is a simple (flat) ASCII file. To view it, use a text editor, such as Microsoft® WordPad, available with most versions of Microsoft Windows® operating system. For example, if you use WordPad to view the Validation Log file, use these steps:
Click Start and select Run. The Run dialog box opens.
In the Open box, type wordpad and click OK to open the WordPad window.
From the File menu, select Open to open the Open dialog box.
Ensure that “C:” appears in the Look in box. If it does not, select it from the list.
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.
Scroll through the list of error messages and write down the error message you received for your job. If the File Validation Log entry(s) indicates that your mailing job (Mail.dat file) did not pass validation, you will need to analyze the Mail.dat file. If you produced your 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.
For a complete listing of error messages that appear in the Validation.log file, see Appendix E. Error Messages.
Performing the File Transfer
Before transferring your jobs to the Postal Service, you should first validate your files. For more information, see Section 2.4.1, Validating Files.
To transfer Mail.dat job files manually:
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.
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.
In the “All Folders” pane, scroll up or down to locate the folder in which your job is saved.
Select the proper folder by clicking the folder name. The “File Contents of” pane on the right displays the job header files.
NOTE: If the folder containing your job is in a subfolder, click the plus sign (+) next to the main folder to display the subfolders. From the subfolders, locate and select the appropriate folder.
In the “File Contents of” pane, select the header file of the job you want to transfer.
NOTE: All files associated with a mailing job are transferred as a result of selecting the header file. To transfer multiple jobs simultaneously, hold down the CTRL key and click the header files of the jobs one at a time to select them.
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.
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.
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.
To check the status of your transferred jobs, click Transfer Summary.
Check File Transfer and Upload Status
To check transferred job and file upload status:
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.
NOTE: In the Job Status column, jobs are reported as "successful,” "In progress," or "failed." If your job is "failed," see Section 2.4.1.4, Validation Log Errors.
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.
NOTE: To view more or fewer records per page, select a number from the Show records drop-down list.
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.
The Job Detail page displays all files associated with the selected job, file upload date and time, and upload status.
NOTE: The Completed Job column will either list the date and time at which a file was successfully uploaded, or report the file upload as "Failed" or "In progress."
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.
To close the message and continue working, click Close.
If your mailing job was not transferred successfully, you should check the Transfer Summary and the Validation Log file.
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.
Adjusting Memory Limits for Manual Transfers
NOTE: It is only necessary to adjust memory limits if attempts to transfer large files result in an “Out of Memory” error. Do not increase memory size unless necessary.
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.
The steps to adjust memory limits are:
Verify the version of Java plug-in currently installed. The steps to follow vary based on your Java version.
Verify your machine has sufficient memory to increase the memory limits. Do not modify memory limits if your machine lacks sufficient memory.
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.
Verifying Java Installation
Visit the Java web site (http://www.java.com/en/download/installed.jsp) to verify/update the version of java installed on the computer. Accordingly, refer to section 2.4.3.3 for the steps to increase the memory limit, if the java version installed is 1.4.2_x (where x is any number). If the java version installed is 1.5.x or 1.6, refer to section 2.4.3.4.
Verifying Memory
You must know how much RAM the transfer computer has before increasing memory limits. To check the amount of RAM on a Windows machine, left-click My Computer on the your desktop, then click Properties. The computer must have at least 512 MB RAM before you increase memory limits.
Increasing Memory Limits for Java 1.4.2_x
To increase the memory limit for Java version 1.4.2_x:
Close any open browser windows, including any PostalOne! windows.
On the Windows taskbar, click the Start button, then click Control Panel.
Double-click the Java Plug-in icon.
NOTE: Dependent on your Control Panel settings, you may need to click Other Control Panel Options to display the Java Plug-in icon.
Click the Advanced tab.
Click the Java Runtime Parameters box, then enter: -Xmx512m
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.
Click Apply, then close the Java Plug-in dialog box.
Retry the transfer.
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.
NOTE: Ensure that any memory limit entered is less than the amount of physical memory (RAM) on the client machine.
Increasing JAVA Memory Limits for Java 1.5.x or 1.6
To increase the memory limit for Java versions 1.5.x and 1.6:
Close any open browser windows, including any PostalOne! windows.
On the Windows taskbar, click the Start button, then click Control Panel.
Double-click the Java Plug-in icon.
NOTE: Dependent on your Control Panel settings, you may need to click Other Control Panel Options to display the Java Plug-in icon.
Click the Java tab, then under Java Applet Runtime Settings, click View. A dialog box appears listing all Java Runtime Versions.
Click the most recent JRE version, then double-click the Java Runtime Parameters box for the selected line. Enter: -Xmx512m
Click OK.
Click OK again to close the Java dialog box.
Retry the transfer.
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.
NOTE: Ensure that any memory limit entered is less than the amount of physical memory (RAM) on the client machine.
|