AS/400: Most efficient DB2 SQL to unpack EBCDIC subfield values as strings?

Question

Most files I am working with only have the following fields:

• F00001 - usually 1 (f1) or 9 (f9)
• K00001 - usually only 1-3 sub-fields of zoned decimals and ebcdic
• F00002 - sub-fields of ebcdic, zoned and packed decimals

Occasionally other field names K00002, F00003 and F00004 will appear in cross reference files.

Example Data:

+---------+--------------------------------------------------+--------------------------------------------------------------------------------------------+
| F00001  | K00001                                           |  F00002                                                                                    |
+---------+--------------------------------------------------+--------------------------------------------------------------------------------------------+
| f1      |  f0  f0  f0  f0  f1  f2  f3  f4  f5  f6  d7  c8  | e2  e3  c1  c3  d2  d6  e5  c5  d9  c6  d3  d6  e7  40 12  34  56  7F  e2  d2  c5  c5  e3  |
+---------+--------------------------------------------------+--------------------------------------------------------------------------------------------+

Currently using:

SELECT SUBSTR(HEX(F00001), 1, 2) AS FNAME_1, SUBSTR(HEX(K00001), 1, 14) AS KNAME_1, SUBSTR(HEX(K00001), 15, 2) AS KNAME_2, SUBSTR(HEX(K00001), 17, 2) AS KNAME_2, SUBSTR(HEX(F00002), 1, 28) AS FNAME_2, SUBSTR(HEX(F00002), 29, 8) AS FNAME_3, SUBSTR(HEX(F00002), 37, 10) AS FNAME_4 FROM QS36F.FILE

Is this the best way to unpack EBCDIC values as strings?

Answer 1

You asked for 'the best way'. Manually fiddling the bytes is categorically NOT the best way. @JamesA has a better answer: Externally describe the table and use more traditional SQL to access it. I see in your comments that you have multiple layouts within the same table. This was typical years ago when we converted from punched cards to disk. I feel your pain, having experienced this many times.

If you are using SQL to run queries, I think you have several options, all of which revolve around having a sane DB2 table instead of a jumbled S/36 flat file. Without more details on the business problem, all we can do is offer suggestions.

1) Add a trigger to QS36F.FILE that will break out the intermingled records into separate SQL defined tables. Query those.

2) Write some UDFs that will pack and unpack numbers. If you're querying today, you'll be updating tomorrow and if you think you have some chance of maintaining the raw HEX(this) and HEX(that) for SELECTS, wait until you try to do an UPDATE that way.

3) Write stored procedures that will extract out the bits you need for a given query, put them into SQL tables - maybe even a GLOBAL TEMPORARY TABLE. Have the SP query those bits and return a result set that can be consumed by other SQL queries. IBM i supports user defined table functions as well.

4) Have the RPG team write you a conversion program that will read the old file and create a data warehouse that you can query against.

Answer 2

It almost looks as if old S/36 files are being accessed and the system runs under CCSID 65535. That could cause the messy "hex"representation issue as well as at least some of the column name issues. A little more info about the server environment would be useful.