|Create ASCII Text Files Using DB2 in Qshell|
|Database - DB2|
|Written by Thomas Snyder|
|Wednesday, 05 May 2010 00:00|
Pipe iconv into your Qshell command to create ASCII instead of EBCDIC.
In my previous article, "Using DB2 with Sed, Tail, Pipes, and Redirection from Within Qshell," we used SQL to export files directly to text files on the IFS. These files were created in EBCDIC. A reader stated to me that he could view the results in cat, but when he dragged them across the network, they were unreadable and asked if it was because it was EBCDIC. The answer is yes, the results are in EBCDIC, but we can change that.
To provide the results in ASCII, you could use the ASCII transfer option in FTP. But, if you want to have your results generated directly into ASCII so that you can access them directly through a network drive, you need to introduce the iconv Qshell utility into the mix. The iconv utility allows you to convert between different Coded Character Set Identifier (CCSID) values.
Here is the syntax for the iconv utility:
iconv -f fromCCSID -t toCCSID [ file ... ]
And here is a description of the iconv utility options:
A while ago, I wrote an article called "Determining and Providing the Appropriate CCSID for an API, External System, or Language," which explains how to use the iconv API to convert between CCSIDs within an RPG program that has a list of commonly used encodings and their associated CCSIDs:
The use of the iconv API in RPG requires that you perform open and close operations to work with the conversion descriptor, but that is not required when using the iconv utility in Qshell. When you use iconv from Qshell, you simply specify the TO and FROM CCSIDs as options when you call it.
When you integrate different environments, such as the IBM i with Microsoft Windows, or when you integrate different languages, such as RPG with Java, encoding becomes very important, and the iconv is a very useful utility for these purposes. The service programs that integrate RPG with Java in my book Advanced Integrated RPG use these APIs quite extensively.
Quick Qshell Refresher
I will be referencing my previous article, which demonstrates the usage of DB2 from Qshell to run query statements. Here is a quick refresher on some of the topics:
Redirection—The standard output of a utility can be redirected to an output file using the greater than symbol (>).
Pipes—The output of one utility can be passed as the input of another utility using pipes, which are the vertical bar (|) on your keyboard.
There are also some other useful references to sed and tail, which I won't be using for this article.
DDS Used in Examples
For the queries in our examples, we will use the following DDS to create a simple physical file that contains account phone numbers:
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')
Using SQL in Qshell to Generate ASCII Test Files on the IFS
Now that we have the syntax defined for the iconv utility and some CCSID codes, we can incorporate the iconv utility with a basic SQL statement to export our physical file to an ASCII text file, or any other supported CCSID, directly to the IFS.
We'll use a simple SQL statement to export all of the records from a physical file into a text file on the IFS. Without the use of the iconv utility, the file will be created in EBCDIC.
We will first enter Qshell using the STRQSH command. Once in Qshell, we can access the db2 command. We can use the db2 utility in Qshell to execute SQL statements by specifying the query to run in quotes after the db2 command.
db2 -v 'select * from mylib.mc_phone' > sqlOutEBCDIC.txt
Executing this statement will create an EBCDIC text file on your IFS that will contain the data from the physical file along with header information for each field along with some footer information. It will also contain the SQL statement that was executed because of the verbose option (-v) that was used with the db2 command. The iconv utility is not needed here because it will use the native EBCDIC encoding.
Now, if you use a pipe to include the iconv utility with the FROM CCSID specified as EBCDIC(37) and the TO CCSID specified as ISO-8859 (819), then you will generate the data as ISO-8859 encoding. This will get you your ASCII file you've been looking for.
db2 -v 'select * from mylib.mc_phone'|iconv -f 37 -t 819 > sqlOutISO8859.txt
And if you want to specify UTF-8, there's a CCSID for that.
db2 -v 'select * from mylib.mc_phone'|iconv -f 37 -t 1208 > sqlOutUTF8.txt
Now you can just map a network drive to your IBM i and view the file in your favorite text editor. Or you could download your files using the binary mode of FTP. If you look at the hexadecimal value of your files, you will see the following:
Figure 1: View the EBCDIC file in hexadecimal and clear. (Click images to enlarge.)
When you view the EBCDIC file using a Windows text editor, the data will look like garbage because it is expecting the data to be in ASCII format. But, if you review the hexadecimal codes, you can see that they are characters of good EBCDIC data.
Figure 2: View the ISO-8859 file in hexadecimal and clear.
As you can see in the clear view of the ISO-8859 file, the data is in the expected encoding. You can verify the ASCII codes when you view the data in hexadecimal mode.
There is some undesirable information, such as the SQL statement that was executed, that can be eliminated by removing the verbose option on the DB2. You can also remove specific extra lines by using the sed and tail methods mentioned in my previous article.
Integration of Resources and Techniques
There is really a lot going on here if you think about it. You're an RPG programmer using a UNIX command line on your IBM i to execute SQL statements, generating data in a foreign encoding scheme to be shared with a Windows operating system, and using the green-screen in the OS/400 environment. Using techniques like this is a great opportunity to gain exposure to different tools that are available not only on the IBM i, but on other operating systems as well.
Because of the many different components, I really appreciate the fact that all of these options are available right on the IBM i! You can continue developing your RPG applications as you've always done and gradually reach out into different areas without having to drop everything and rewrite because you don't have the capabilities. The fact is that you do, if you're on an IBM i.
You can find yourself spending a lot of time jumping through hoops to export data from your IBM i in just the way that your user requests it. We've covered quite a bit of ground in my past few articles, and we're not done yet. With the IBM i, you have lots of options. Knowing what's out there will help you to use the right tools for the job.
|Last Updated on Thursday, 29 April 2010 14:22|