Sometimes an old technique with a new tweak is the best answer. This article shows you how to externally describe multi-format flat files from partners or legacy systems.

It's often the little things that can make a big difference in the world of RPG, and often an older technique can come to the rescue when dealing with the thorny issues of the real world. A perfect example is dealing with flat files having multiple formats. While externally described files can't handle them, a mix of old and new techniques can give you the next best thing.

The Setup

Let's take a simple situation. I've got a trading partner or a third-party package that is sending me order information. These orders come in a flat file, 256 bytes per record, with three different layouts: Order Header, Order Address, and Order Detail. The Order Header record has basic order information, such as customer information and order-level values. An order will have at least one Order Address record containing street address and contact information. The order might have multiple records--for example, one each for ship-to and bill-to addresses. Finally, the Order Detail record contains item number, quantity, and price information.

In order to minimize complexity, the order data is passed in a single file with different formats for each record type. One standard technique is to give all records an ID, usually in the first few bytes of the record. This ID specifies the format of the rest of the record. The data is also sequenced so that the highest-level record (in this case, the order header) is first, followed by all the details records. This allows the processing program to use the header information when processing the detail.

How the processing occurs is very dependent on the business requirements; it ranges from immediately trying to post the data to writing a transaction file, which is later posted in batch processing. This article isn't worried about the posting process; instead, it will focus more on reading the flat file data.

First Things First

The first thing to do is to create an externally described data structure for each format. For example, the order header information might be stored in a file called ORDHDR, like so:

R ORDHDRR                                         

  RECID          2A         TEXT('Record Type')   

  CUSTNUM        6S 0       TEXT('Customer Number')

  CUSTNAME      30A         TEXT('Customer Name') 

  CUSTNAME      25A         TEXT('Customer PO')   

  ORDERED        8S 0       TEXT('Ordered Date')  

  DELIVERY       8S 0       TEXT('Delivery Date') 

  TAX            9S 2       TEXT('Total Tax')     

  SHIPPER        4A         TEXT('Shipper Code')  

  FREIGHT        7S 2       TEXT('Freight')       

Here's the order address record:

R ORDADRR                                       

  RECID          2A         TEXT('Record Type') 

  ADDRTYPE       2A         TEXT('Address Type')

  ADDR1         30A         TEXT('Line 1')      

  ADDR2         30A         TEXT('Line 2')      

  ADDR3         30A         TEXT('Line 3')      

  CONTACT       30A         TEXT('Contact Name')

  PHONE         15A         TEXT('Contact Phone')

  EMAIL         80A         TEXT('Contact Email')

And finally the order detail:

R ORDDTLR                                         

  RECID          2A         TEXT('Record Type')   

  ITEMNUMBER    15A         TEXT('Item Number')   

  QUANTITY       7S 0       TEXT('Quantity')      

  UNITPRICE      9S 4       TEXT('Unit Price')    

  EXTAMOUNT     11S 2       TEXT('Extended Amount')

  WEIGHT         7S 2       TEXT('Weight')        

  TAXCODE        4A         TEXT('Tax Code')      

  SHIPCODE       4A         TEXT('Ship Code')     

In this particular example, you might notice that most of the information is calculated by the order system: for example, the price, tax, and freight information is all sent in the flat file. In this case, the posting process simply needs to verify the information and post in. In another environment, the posting process might be required to compute prices and dates. That wouldn't affect the use of this technique; it would simply mean that less information is sent in the flat file.

Implementing the Technique

Now for the program. As I normally do, I'll walk you through each piece of the program and explain what it does.

A    H OPTION(*NODEBUGIO:*SRCSTMT)

These are standard compile options that make debugging easier.

B    FORDERS    IF   F  256        DISK

OK, here we define the file. The file name is ORDERS and records are 256 bytes long. The file is internally described and not sequenced. Usually, this would involve creating input specifications, but through the magic of data structures we get to avoid that tedious and error-prone step.

C    d dsOrdHdr      e ds           256    extname('ORDHDR') qualified

This line defines the header as a data structure named dsOrdHdr. This is an externally described data structure with two important characteristics. First is that this particular record is not defined as BASED, meaning that RPG actually allocates space for this record. The other records, dsOrdAdr and dsOrdDtl, are defined as BASED, and I'll return to that momentarily. Second is that I've defined the length as 256. This ensures that the entire record is read.

D    d dsOrdAdr      e ds           256    extname('ORDADR') qualified

D    d                                     based(pOrder)

D    d dsOrdDtl      e ds           256    extname('ORDDTL') qualified

D    d                                     based(pOrder)

D    d pOrder          s               *   inz(%addr(dsOrdHdr))

These two records are defined just like the order header, except that they are defined as BASED with a pointer named pOrder. That pointer, pOrder, is specified to be initialized to the address of dsOrdHdr. The result of this is that all three data structures actually occupy the same 256 bytes. Thus, when you read into dsOrdHdr, you read into all three data structures.

      /free

E      read ORDERS dsOrdHdr;

E      dow not %eof(ORDERS);

The rest of the code is simple. This is a standard loop: read the record and end when you hit end of file.

F        select;

F          when dsOrdHdr.RECID = 'OH';

F            // ProcessHeader();

F          when dsOrdHdr.RECID = 'OA';

F            // ProcessAddress();

F          when dsOrdHdr.RECID = 'OD';

F            // ProcessDetail();

F        endsl;

Here, you use the RECID field to determine which procedure to call to process the record.

E        read ORDERS dsOrdHdr;

E      enddo;

This is the bottom of the read loop.

G      *inlr = *on;

      /end-free

This technique has pros and cons, and the use of BASED data structures may be overkill for your application. An alternative would be to have separate data structures for each record type. The program would read into a dummy data structure that defines only the record ID and then move the record into the appropriate data structure, based on the contents of the record ID field. Using separate data structures is simpler (not requiring BASED data structures), but it also requires more data movement. On the other hand, when the data structures share memory, as in this example, you have to remember to save everything you need from the current record because the next read will wipe out the previous record. It's up to you; I'm simply showing you the technique. It's always good to have as many options as possible.