In RPG the opcode EXFMT means write-read.  This means that if you EXFMT a subfile control record any input capable fields on the control record will be read from the display into program memory as a function of the EXFMT.  So when faced with input fields only in one sector of a display this should be considered the best place to put the subfile control record - do not close your mind to the convention that subfile control must always position immediately above (or below) the subfile record list - allow yourself some flexibility.

My personal preference is above, with the column headings a part of the control record display output - but when I need to have entry fields at the bottom, say a column of manually entered values, with a total field (in the control record) where I then compare the sum of the subfile values to the total entered, to ensure there are no keying errors - in this case I place the subfile control at the bottom of the display.

Obviously the problem comes when you have to have entry fields both above and below the subfile record list.  When this is needed you need to decide where you are going to place the control (for me that would be above as the preference).  Then in the program you go through the following logic:

/free
    BuildSubfileList();

    dou EndDsp;
      write bottom1;
      exfmt control1;
      read bottom1;     // the addition here will read the new values of fields from the input fields below the subfile.
 
      ValidateKeying();
    enddo;
/end-free

Let's back up a step. A subfile is one type of record format allowed in a display file. The question should be, can you display a subfile at the same time as another record format? The answer is yes, but there are some things to consider.

* As neil points out, fields (named or constant) in the control record all have to appear either above or below the subfile area. This means that you will almost always have at least one other format to display, which will appear either below or above the subfile area, correspondingly.

* When you write the SFLCTL record with SFLDSP turned on, the display is cleared from the top line of the subfile to the bottom of the display (even if the subfile does not go all the way to the bottom of the display, which they usually don't). This often means that order is important when you do the writes. If your SFLCTL fields are below the SFL lines, this may not be a big deal. But if the SFLCTL fields are above, meaning some other format is below, then you must write the SFLCTL before the other format. If you write the other format, then write SFLCTL, the write of SFLCTL will wipe out your other format.

* All formats written after the first format should have OVERLAY, else they'll erase what's already on the display.

* Whichever format is written last controls what CA and CF-keys are available. One way around this is to use RETCMDKEY, which you would put on all but the first format written. This also applies if you are coding for Help, Print, etc., which would be RETKEY. Instead of RETCMDKEY/RETKEY, you can also define your function keys at file level, but personally I'm not fond of that (too limiting in most cases).

* Except for there being a subfile involved, your question could have been can I have two (or more) formats shown at the same time? And the answers would be the same (except for the bit about SFL clearing to the bottom of the display; regular formats using OVERLAY normally don't do that).

Thanks for the reply, I think I understand it much better, now.

But I do have a follow up concern.

With more than one format on a screen, what do I need to consider when I read the format back into the program. I'm assuming the write, exfmt, read logic is the proper way to do this. And with a subfile do I need to do a readc vs the exfmt?

With a subfile you always need to read the subfile records back - either using readc or chain using rrn.  To expand from Dale's points, if your display is made of many record formats you need to do things in the following order:

/free
   write fmt1; // this format has no overlay keyword
   write fmt2; // this format must include overlay keyword or fmt1 will not be visible
   exfmt fmt3; // this does a write & read of fmt3 so all input fields will be loaded into the program
   read fmt1;  // this will refresh the input fields from fmt1 into program memory.

 Note since I did not read fmt2, I have not refreshed any of the input fields from that record into program memory - this could also be because there are no input fields and I don't need to waste program cycles reading in a record with no input!

Also a correction to Dale's points, if SFLCTL includes the OVERLAY keyword then it does not have to be written first, and it will not clear the underlying display records.  My personal preference was to WRITE the command key display format (no OVERLAY or input fields) then EXFMT the SFLCTL.

I think you confused what I said, neil. The format that you write first does not need OVERLAY. Any (and all) subsequent writes do need OVERLAY; without it, they'll clear anything from previous writes. (OK, you can mess around with SLNO and CLRL, but I think those are more for backwards compatibility with S/36 FMT's. I haven't used them in years.)

However, when you write the SFL (i.e., you write SFLTCL with SFLDSP optioned on), it will clear from the first subfile row to the bottom of the display. If SFLCTL fields are below the SFL lines, this is not a problem. But if SFLCTL fields are above the SFL, the bottom of the display will be cleared, potentially wiping out any format that was there. OVERLAY on the STLCTL doesn't help in this case (remember, the SFLCTL fields are above the SFL). So the sequence must be:

/FREE
   WRITE ctlfmt;    // where SFLCTL fields are above SFL rows
   WRITE bottomfmt; // where all of this format is below SFL rows
   READ  ...;       // see below

You must read at least one format to get control back in your program. If you have more than one format with input capable fields, read all of those formats. If none of the formats have input capable fields, pick one (or, the last WRITE can be EXFMT instead of WRITE and READ).

As far as the subfile, it sounds like you're missing an important point. You use the SFLTCTL format to write them to the display, and read them from the display. Elsewhere in the program, you treat the SFL row data like a disk file with relative access (in RPG the RRN is accessed using SFILE on the F-spec).

When reading the SFL data, typically following the read of the SFLCTL, but really can be at any time, you have three choices.

1. Simply start READing. You will read all active subfile records sequentially, starting at RRN=1. You're done reading when you hit %EOF.

2. READ a specific RRN by specifying the RRN field from SFILE. If you want to read all rows, you could use the RRN field in a FOR loop (or equivalent).

3. Use READC to read only changed rows. This one is the most complicated. Use this after reading the SFLCTL format, when control is returned to the program. If you have input capable fields in the SFL rows, there are times when you don't need to read every row, only  rows where the user has typed something. This might be because you're looking for data entry in new rows, but you want to ignore blank rows. Or you may have a list, with an option number field in front, and you only need to read rows where the user has typed an option. I'm sure you can think of more examples.

The other time you want to use READC is for error handling. Let's say the first time you READ or READC the subfile, you find an error. So you need to rewrite the display with an error message, maybe highlight the field somehow. The user (tries to) correct the error, and presses [Enter]. Your program now does READC to reread the row that the user changed, validating again, and so on.

Now, here's the problem: when you rewrite the display, what if the user presses [Enter] without fixing anything? Or, what if you had more than one row with an error, and the user only fixes one of them? You need to re-read all of those rows, but READC doesn't read them if the user doesn't change them (lookup Modified Data Tags in your spare time). So what you need to do is, as you're going through your READC loop, you need to update the rows with an indicator turned on (using INDDS, of course), for an indicator that's associated with SFLNXTCHG in the SFL format. This keyword causes that row to be treated as changed, even if the user doesn't type anything. So when you start your READC's the next time around, you read it again. Got it? [For regular, non-SFL formats, it's kind of like using DSPATR(MDT) and CHANGE(nn), kind of.]

Well from my experience the only thing that causes a subfile to erase to the bottom of the display is if the last subfile record (or more.../bottom line) overlays any part of the format already written at the bottom of the display.  And yes when I switched from using "+" to using "More.../Bottom" my command key strip did disappear, because the subfile area extended by a row on the display and overlayed the command key format - the remedy was to just reduce the subfile page size by one row and I could continue with: 

/free
    write cmdkeys;
    exfmt sflctl;
/end-free

 and the cmdkeys format does not disappear.

Hmm . . . maybe the subfile clearing to the bottom of the display was something that used to be a problem, but they fixed it? I'm not going to go through all "What's New" in this release content back to the early 90's, but I'm fairly certain this caused us headaches at one time.

Anyway, sorry about the length of that post; I was on a roll. Jellybean, you can get more info from Application Display Programming, Ch. 4.