From: Ricky Thompson To: All

Has anyone out there converted S/36 multiformat files to native AS/400 externally described files? We have our order entry file in two different formats. The first line, line item zero, has the basic customer information. The next lines, detail lines, have what the customer ordered. Because almost 75 percent of our programs use this order file, there is no way we can convert this overnight.

Can I create a line item zero file and a detail file and join them with a logical file? For example, our order file is WF.ORD. Can I make two files called ZERO & DETAIL and make a join logical file called WF.ORD without changing any of my programs? They all use the file WF.ORD with both records in it.

From: Pete Hall To: Ricky Thompson

I've done this many times; it's fairly straightforward. You're on the right track. The first thing to do is to create two externally described physical files; one for each record. Copy each record type from the S/36 flat file to the appropriate externally described file.

Now, create a multiformat logical file, not a join logical file. 7 shows a sample of the DDS required for a multiformat logical file. The record format and field names must be the same as the names in the based-on physical files unless you want to create specifications for each field. When you create the logical file, you specify a format selector program, or you can add the format selector later with the Change Logical File (CHGLF) command.

Now, create a multiformat logical file, not a join logical file. Figure 7 shows a sample of the DDS required for a multiformat logical file. The record format and field names must be the same as the names in the based-on physical files unless you want to create specifications for each field. When you create the logical file, you specify a format selector program, or you can add the format selector later with the Change Logical File (CHGLF) command.

Each time you add a record to the database, the format selector program is automatically called and passed two parameters. The first is the entire output buffer and the second is a return parameter in which your format selector returns the name of the record format that the data is to be written to. A simple CL program can do this, as illustrated in 8.

Each time you add a record to the database, the format selector program is automatically called and passed two parameters. The first is the entire output buffer and the second is a return parameter in which your format selector returns the name of the record format that the data is to be written to. A simple CL program can do this, as illustrated in Figure 8.

In this example, &BUFFER is declared with a length of three because that's the last byte that's referenced. The program is really passed a pointer to the data buffer. The record format name is always 10 bytes long.

The only real gotcha is if your multiformat physical doesn't have a key. It's required. If that's the case, you have to manufacture one somehow or live with a flat file. You need to look at the OCL that manipulates the new file, too. Many things that are done with a single physical file on the S/36, such as the copy-delete-rename reorganization technique, are not appropriate with a multiformat logical. You also must replace DELETE with the Clear Physical File Member (CLRPFM) command (in this case twice) and get rid of any BLDFILEs.

Multiformat Files

Figure 7 Multiformat Logical File DDS

 *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 A R HEADR PFILE(HEADP) A K INVNO * A R DETR PFILE(DETP) A K INVNO A K LINENO 
 
 Multiformat Files
 
 Figure 8 Sample Format Selector Program
 
 PGM PARM(&BUFFER &FORMAT) DCL VAR(&BUFFER) TYPE(*CHAR) LEN(256) DCL VAR(&FORMAT) TYPE(*CHAR) LEN(10) IF COND(%SST(&BUFFER 3 1) *EQ 'H') THEN(CHGVAR + VAR(&FORMAT) VALUE(HEADR)) ELSE CMD(CHGVAR VAR(&FORMAT) VALUE(DETR)) ENDPGM