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:
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.]