Displaying an empty subfile

[gregwga50]

I have a subfile program where I prompt for a locn#, set off the indicators 81, 82 and write to the subfile control record to clear the subfile. Then, in a loop, I write write records to the subfile for the locn that was entered. When I write first subfile data record, I set on indicator 81. To display the subfile, I set on 82. Indicator 81 is already on, so the contents of the the subfile and the subfile control are displayed. When I prompt for a new locn, I repeat the steps above.

The problem is, if there are no records written to the subfile 81 is off when I write to the subfile control record but it still displays subfile records for the original locn that was keyed in. I would have thought that clearing the subfile by turning off 81 and 82 and not turning on the indicator 81 would cause the subfile control record to be displayed with no subfile data records. I changed my program to set on 81 even when no records are written to the subfile and presto, problem solved, blanks subfile is displayed.

Has something changed to cause it to work this way now.

[Brian Rusch]

No, that's the way it has always worked. The subfile is cleared in memory, but because you have OVERLAY in the the control record and you do not display the subfile (81 is off), that part of the display does not get cleared, so it looks like the subfile records are still there. When you display the subfile (81 is on), then it overwrites that part of the display. One caution to displaying a subfile with no records, if the subfile is not active (meaning that no record was ever written to it), then an error will occur.

[gregwga50]

Thanks for responding

I changed the program so that 81 is on even when no records have been written to the sfile data record. I am surprised the program didn't error out when EXFMT is executed with 81 on (as well as 82) with no records having been written to the sfile data record

[gregwga50]

In looking back at some of the previous programs I have written with similar logic, I noticed that in the past I used the ERASE(SFLDATA) keyword on the SFLCTL record which I failed to do in this case, so that may explain the different results

[CRinger400]

A N81 ERASE(IN6003S1)

Ringer