Re: Merging Files -- MIDRANGE-L

Hello,

These tables have the same identical layout (fields, format names, file
names); just in different libraries.  I tried using a multiple format LF
but, naturally, it blew off because the record format names are the same.

We have programs that work this way in an old application on our system.There are 3 physical files that are built from the same source member (andtherefore have identical record formats) But each file ends with the yearin which they're created so that we can easily keep them separated byyear.

We have programs that need to read 3 years at a time, so we bring themtogether in a multi-format logcal file as follows:


      A          R CBODETF                   PFILE(CBODET06)
      A                                      PFILE(CBODET05)
      A                                      PFILE(CBODET04)
      A          K CDCUST
      A          K CDWDAT

So this logical is built over all 3 PFs. Unfortunately, this creates twoproblems:

a) RPG programs won't compile when they reference this LF, since it triesto create 3 record formats with identical names.

b) Every year we have to go back and change the years in the PFILEstatements.

To fix the first problem, whenever we compile the RPG programs that useit, we create a temporary copy with only one PF in it. Usually we just gointo the DDS and comment out the last 2 PFILEs like this:


      A          R CBODETF                   PFILE(CBODET06)
      A***                                   PFILE(CBODET05)
      A***                                   PFILE(CBODET04)
      A          K CDCUST
      A          K CDWDAT

Then we build a temporary copy of this file in QTEMP and use that copy tocompile the RPG program. Once compiled the RPG progam runs over the livefile without any problems.

Now, this is code that was written in 1991 and I don't really feel likechanging it, so I go through the (rather small) extra effort of changingthe years in the LF every January, and re-build it.

But, if I had to do it over again, I'd try to find a better solution. I'dstart with SQL to see if a UNION of these files performed well enough(considering that I might have to order the query, and this may cause itto have to build an index or something like that.)

In any case, I think I'd put all of the logic into a service program, andI'd design that service program so that the caller doesn't have to knowanything about the files. That way, I can change the service program toaccess the three files any way I want, and don't have to worry aboutchanging all of the programs every time.


Just something to consider.