When you build a mapped logical message,
you can ask BMS to notify you when a page break is about to occur; that is,
when the map you just sent does not fit on the current page. This is very
useful when you are forming composite pages with ACCUM. It allows you to put
trailer maps at the bottom of the current page and header maps at the top
of the next one, number your pages, and so on.
BMS gives your program control at page breaks if either:
- You have issued a HANDLE CONDITION command naming a label for the OVERFLOW
condition, or
- You specify the NOFLUSH option with either the RESP or the NOHANDLE option
on your SEND MAP commands.
Either of these actions has two effects:
- The calculation of the space remaining on the page changes. Unless the
map you are sending is itself a trailer map, BMS assumes that you eventually
want one on the current page. It therefore reserves space for the largest
trailer in the same map set. (The largest trailer map is the one containing
the TRAILER option that has the most lines.) If you do not intercept page
breaks (or if you send a trailer map), BMS uses the true end of the page to
determine whether the current map fits.
- The flow of control changes if the map does not fit on the current page. On detecting this situation, BMS
raises the OVERFLOW condition. Then it returns control to your task without processing the SEND MAP command that caused the overflow. Control
goes to the location named in the HANDLE CONDITION command if you used one.
With NOFLUSH, control goes to the statement after the SEND MAP as usual, and
you need to test the RESP value or EIBRESP in the EIB to determine whether
overflow occurred.
When your program gets control after overflow, it should:
- Add any trailer maps that you want on the current page. BMS leaves room
for the one with the most lines in the map set you just used. If this is not
the right number of lines to reserve, or if you are using several map sets,
you can ensure the proper amount by including a dummy map in any map set that
may apply. The dummy map must specify TRAILER and contain the number of lines
you wish to reserve; you do not need to use it in any SEND MAP commands.
- Write any header maps that you want at the top of the next page.
- Resend the map that caused the overflow in the first place. You must keep
track of the data and map name at the time the overflow occurs; BMS does not
save this information for you. Note that if you have several SEND MAP commands
which might cause overflow, the program logic required to determine which
one you need to reissue is more complex if you use HANDLE CONDITION OVERFLOW
than if you use NOFLUSH.
Once OVERFLOW is turned on, BMS suspends returning control to your program
when the output does not fit on the current page, although it still uses overflow
rules for calculating the remaining space. OVERFLOW remains on until BMS processes
the first SEND MAP naming a map which is not a header
or a trailer. This allows you to send your trailers and headers without disabling
your HANDLE CONDITION for OVERFLOW or changing your response code tests, and
reinstates your overflow logic as soon as you return to regular output. (Resending
the map that originally caused overflow is usually the event that turns off
the overflow condition.)
If you do not intercept overflows, BMS does not notify your program when
a page break occurs. Instead, it disposes of the current page according to
the disposition option you have established and starts a new page for the
map that caused the overflow.
[[ Contents Previous Page | Next Page Index ]]