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.
LATEST COMMENTS
MC Press Online