The documentation indicates that MORE can be used with MATCH FILE; but does not indicate where to put the
AFTER MATCH HOLD ...
phrase, when the second or subsequent leg of the match involves "universal catenation" ("MORE") syntax.

In the example below, depending on whether one, both, or neither of the commented AFTER MATCH lines is active, I either get an error message, or no message but no HOLD file.

WHENCE HOLD MASTER
MATCH FILE CAR
  SUM SEATS BY COUNTRY
  IF COUNTRY EQ FRANCE
MORE
FILE CAR
 IF COUNTRY EQ JAPAN
RUN
FILE CAR
  SUM RCOST BY COUNTRY
  IF COUNTRY EQ ITALY
-*AFTER MATCH HOLD OLD-OR-NEW
MORE
FILE CAR
  IF COUNTRY EQ 'W GERMANY'
-*AFTER MATCH HOLD OLD-OR-NEW
END
? FILEDEF
WHENCE HOLD MASTER
?FF HOLD

Anyone?

This message has been edited. Last edited by: <Kathryn Henning>,

I think the AFTER MATCH HOLD must be specified on the second MATCH answer set (the one that begins right after the "RUN" statement):

MATCH FILE CAR
  SUM SEATS BY COUNTRY
  IF COUNTRY EQ FRANCE
MORE                         <-- MORE
FILE CAR
 IF COUNTRY EQ JAPAN
MORE                         <-- MORE
FILE CAR
  SUM RCOST BY COUNTRY
  IF COUNTRY EQ ITALY
RUN                          <-- RUN *
FILE CAR
  IF COUNTRY EQ 'W GERMANY'
AFTER MATCH HOLD OLD-OR-NEW  <-- HOLD
END

A good explanation can be found here .

This message has been edited. Last edited by: njsden,

What Njsden did above works although The "SUM RCOST BY COUNTRY" line also needs to be moved down under the RUN.

njsden: My problem is where to put the AFTER MATCH... in the second request, when it consistes of a series of sub-requests. Your example only has MORE in the first leg. MORE unions the results, extending the answer-set matrix "vertically". RUN extends it "horizontally", adding more data columns.

Clearly the AFTER MATCH HOLD... clause belongs somewhere in the second leg, telling MATCH how to merge the two internal matrices that it has formed up to that point. I tried placing it early (in the first sub-request), and late (in the final one), and neither works.

Placed early -- it generates an error message, and no HOLD file is created.

MATCH FILE CAR
 SUM SEATS BY COUNTRY
 IF COUNTRY EQ FRANCE
 MORE
 FILE CAR
 IF COUNTRY EQ JAPAN
 RUN
 FILE CAR
 SUM RCOST BY COUNTRY
 IF COUNTRY EQ ITALY
 MORE
 FILE CAR
 IF COUNTRY EQ 'W GERMANY'
 AFTER MATCH HOLD OLD-OR-NEW
 END
 0 ERROR AT OR NEAR LINE     15  IN PROCEDURE ADHOCRQ FOCEXEC *
 (FOC953)  INVALID STRUCTURE IN SUBREQUEST: MATCH               <--- 
 0 ERROR AT OR NEAR LINE     15  IN PROCEDURE ADHOCRQ FOCEXEC *
 (FOC953)  INVALID STRUCTURE IN SUBREQUEST: HOLD
 BYPASSING TO END OF COMMAND
 ? FILEDEF
 Lname        Device   Lrecl Recfm Append     Filename
 ============================================================

Placed late -- it generates no error message, but still no HOLD file is created.

MATCH FILE CAR
 SUM SEATS BY COUNTRY
 IF COUNTRY EQ FRANCE
 MORE
 FILE CAR
 IF COUNTRY EQ JAPAN
 RUN
 FILE CAR
 SUM RCOST BY COUNTRY
 IF COUNTRY EQ ITALY
 AFTER MATCH HOLD OLD-OR-NEW
 MORE
 FILE CAR
 IF COUNTRY EQ 'W GERMANY'
 END
 BYPASSING TO END OF COMMAND                 <---
 ? FILEDEF
 Lname        Device   Lrecl Recfm Append     Filename
 ============================================================

It looks like "you can't get there from here", using only MATCH FILE; will have to use TABLE ... HOLD first, that merge outputs with a 'simple' MATCH FILE, sans MORE.

Here is the link to the tech memo for MORE and MATCH file commands.MORE and MATCH

Hope this helps. I had to go back and read up on this myself..
Rhond

According to the documentation, you can use MORE for the OLD files but not for the NEW.
NFR?

No, Dan, it doesn't state that there is such a restriction. It's just that the only example given uses MORE only in the first ("OLD") leg of the merge.

It's clear to me that someone took a page of documentation of MORE written for TABLE ... END, and retrofitted coverage of MATCH, without paying attention to the issue of what happens in the subsequent portion (or portions) of a MATCH request. And similarly for the implementation of MORE in MATCH.

So I see it as a promise unfulfilled -- a bug report -- not a New Feature request.

The obvious work-around is to pre-assemble the data for the second (and subsequent0 legs, using TABLE + MORE + HOLD; and then perform a merge with MATCH, restricting use of MORE (if at all) to the first leg.