Merge combines one or more x9 input files into x9 output file(s). Merge is a robust process which can be run against a potentially large number of input x9 files. Eligible input files are selected from an input “landing zone” which is identified on the command line. Merge is designed to be run periodically against the landing zone, most probably as a scheduled task, where all current content of the input folder will be merged into one or more output x9 files. In support of that design, merge operates in the following manner:

The landing zone can contain files, folders, or a combination of files and folders. Merge will automatically drill down into subfolders to identify candidate files to be merged. This implementation is essentially based on folder of folders, which allows the landing zone to be organized as needed to control the incoming files based on your requirements and to keep the number of files within folders to a reasonable level.

Merge has a command line option to operate at either the cash letter or bundle levels. When merging at the cash letter level, output x9 files will contain the complete cash letters from each of the input files. When merging at the bundle level, output x9 files will contain a single cash letter. Regardless of which option is selected, bundles are always copied in their entirety from input to output.

A maximum file size must be defined for the output files to be created (default is 800MB). One or more output files will be created from each merge run. The command line provides the output x9 pattern name which is then suffixed with a sequential number for each file that is written by the merge.

Input files which are successfully copied into the merged output can be optionally renamed to a new file extension on completion. This rename allows the file to be excluded from a future merge operation. Input files which are failed (they could not be copied into the merged output file) can be optionally renamed to a new file extension on completion. This rename allows the file to be clearly marked as failed for exception processing and will also exclude them from a future merge operation.

Input files are typically only selected for the merge when they end in a type 99 file trailer, since the lack of a file trailer is a structural issue which means that either the file is in the process of being transmitted to the input folder, or that they are flawed. In either case, files without type 99 file trailers would always be excluded from a merge.

Input files that were recently created can be further bypassed from one merge operation and thus deferred to the next scheduled run, with the intent to skip over files that may be actively transmitted. This skip interval can be set via the command line and defaults to 60 seconds.

Output files are initially created as TEMP and are renamed to their final names on the ultimate completion of the merge. These renames are performed at the end of the merge, for all output files that were created by the merge run, and before the individual files are renamed to their merged extension.

Landing Zone Batch Script

Merge would typically be run from a batch script that would be periodically invoked by a scheduler. Part of this batch script will be send an email if certain embedded functions are determined to be failed. The origination of this email can be done directly from Windows PowerShell but can also be done using tools such as SwithMail, CMail, SendSMTP, Blat, MailSend, SendEmail, or Send-It_Quietly. We would suggest writing a separate notification batch script that can be invoked with the failed message needs to be sent. The merge batch script would perform the following basic functions:

Zip the landing zone contents to an external backup folder using an output file name that is fully date-time stamped. This zip file would be used on an exception basis for either research or to allow this merge operation to be completely rerun should that be needed. The backup is needed since it is assumed that the content of the landing zone will be a constant state of change hence a snapshot backup is required.
Abort if this zip was unsuccessful.
Run the merge using options to rename both merged and failed files.
Abort if the exit status posted by merge is negative.
Zip all files which were renamed to “merged” to a backup file in an external folder using a file name that is fully date-time stamped. This zip file is used for archive purposes and represents all files that were merged in this run.
Abort if this zip was unsuccessful.
Delete all files that were renamed to “merged” since they have now been written to the archive zip file.
Abort if this delete was unsuccessful.
Send an email if the merge exit status indicates that the landing zone contains failed files. This will be true if the failed files either existed prior to the merge run or were actually created by this specific merge run.
Otherwise all is successful.

Landing Zone Watcher Script

Merge can have an optional watcher script that can be scheduled to monitor the merge process. The purpose of the watcher script is to be run independently and to ensure that the merge is running periodically as expected. The “utsf” merge option can be used to update a time stamp file within the landing zone for each independently scheduled run of merge (this update is one of the very last steps of the merge processing run). Because of that, the last modified date-time of the time stamp file is a good indication that a merge has completed. Suppose that merge is running on the hour. If that is the case, then the watcher task can be run on the half hour and can send an email alert if the merge time stamp file has not been updated as expected (for example, the time stamp is more than 60 minutes old).