Need to delimit and transfer data when System i Access is not an option?

Delimiting data is a common way of separating fields within text files. If you're using the Data Transfer utility provided with System i Access, it's a simple matter of specifying the criteria for the download. But what if System i Access is not an option or you want to automate the data transfer without the dependency of a Windows Client?

I have encountered this situation several times. I would be exporting data to an external system that does not support XML, and it would need to be done daily, so I would want to automate it.

Delimit/Transfer Options

Let's explore some alternatives to providing this capability and look at some of the pros and cons of doing this:

System i Access

You could use System i Access to transfer the files manually. But this requires human intervention, and all it takes is for the assigned person to forget or be out of the office, and your reliability is reduced.

You could set up a Scheduled Task, and it may run reliably for awhile…until the computer with the scheduled task is unavailable, replaced, or rebuilt. You'd have to remember that the scheduled task exists and recreate it on the new computer.

What if you are not sending the file to a Windows box, or what if you are sending the same file to several different servers that are using a mix of Windows, Linux, and Mac? Now you have to come up with a specialized process for each server and make notes on future maintenance.

FTP

So maybe you would consider using an automated FTP process that runs on your IBM i, one standard transfer process that will typically work on all of the operating systems that you are working with. Now, how do you delimit it? 

You could create a physical file with one big field and code the delimiters. That is a possible solution, but I find it undesirable because it adds to the programming maintenance that you have to do when adding fields.

DDS Delimiter Solution

The easiest solution that I have found is to put delimiter fields into the DDS for the physical file and specify the default to be the character being used for delimiting. Then you could either write directly to that file or create a duplicate of the original with the additional delimiter fields. I typically use the duplicate file method because it gives additional control over the data that is being transferred.

One of the most standard delimiters is the TAB character, so we'll use that for our example. We will use a simple phone number physical file and build an incremental synchronization process that will send only the data that was created or updated beyond a specified date.

The phone number table will consist of four fields: Account Number, Area Code, Phone Number, and Last Changed Date. Here is the DDS for the physical file named MC_PHONE:

A          R MCFMT

A            MCACCT         6S 0       COLHDG('ACCOUNT NUMBER')

A            MCAREA         3A         COLHDG('AREA CODE')

A            MCPHONE        7A         COLHDG('PHONE NBR')

A            MCDATE         8S 0       COLHDG('CHANGE DATE')

To insert the delimiters, we will create a duplicate file named MC_PHONED. It has additional delimiter fields between the existing fields and uses the default value of an EBCDIC TAB character:

A          R MCFMT

A            MCACCT         6S 0       COLHDG('ACCOUNT NUMBER')

A            DELIMIT1       1A         DFT(X'05')

A            MCAREA         3A         COLHDG('AREA CODE')

A            DELIMIT2       1A         DFT(X'05')

A            MCPHONE        7A         COLHDG('PHONE NBR')

A            DELIMIT3       1A         DFT(X'05')

A            MCDATE         8S 0       COLHDG('CHANGE DATE')

Preparing the Data

Now all we have to do is copy the original file into the delimited file with the *MAP option. This will copy the data existing in both files and populate the new fields with the default value:

CPYF FROMFILE(MC_PHONE) TOFILE(MC_PHONED)

     FROMMBR(MCPRESS) TOMBR(MCPRESS)

     MBROPT(*REPLACE) INCREL((*IF MCDATE *GE 20091206)) FMTOPT(*MAP)

During the execution of the CPYF command, we will also support the incremental data synchronization with the conditional *IF statement on the date. We could even clean up the output by excluding the date value from the temporary file and using the *DROP option on the FMTOPT argument.

To set up automated FTP to transfer the data, refer to my previous article "Automate Your File Transfers Using FTP on the IBM i."

Reviewing the Results

After using FTP to perform an ASCII data transfer, we can see that the EBCDIC characters were converted to ASCII and that the TABs are contained within the data using a Hex editor (Figure 1):

Figure 1: EBCDIC characters have been converted to ASCII. (Click images to enlarge.)

You can find an EBCDIC-to-ASCII conversion table by clicking here. The TABs were specified as EBCDIC X'05' as our default in the DDS, but they are converted to ASCII X'09' in the file that is transferred as ASCII. Now, if we open the file with a spreadsheet application, it will recognize the delimiters and prompt us if we would like to change the settings (Figure 2):

Figure 2: Note the separator options.

And finally, we can view the results in a spreadsheet to see our expected results (Figure 3):

Figure 3: View the results in a spreadsheet format.

Comment Your DDS

Now you have an easy way to delimit your data. I recommend that you put comments into your original MC_PHONE equivalent file, indicating that there is a duplicate file that needs to change to match any changes to the original. Of course, this needs to be done only if you use the duplicate method. Otherwise, just add another delimiter field if you are writing directly into it.

Download the Code

You can download the code used in this article by clicking here.