Allow buffered tape writes to be queued in multiple 32K tape buffers

Our system has several applications that use TOUTC to write data to a buffered tape, and must therefore issue a WAITC.
Normally this is not an issue as the data is simply moved from the application core to the tape buffer, however if the tape drive is not responding and the tape buffer is full then
the ECBs are stuck on a WAITC.
Due to the limited number of allocated ECBs this quickly leads to an input list shutdown due to a shortage of available ECBs, the suggestion here is to save the tape data
in another 32K (or 128K) tape buffer which is chained to the first.
IBM recommends that customers configure their systems to survive for 16 seconds without a tape drive, after which a lost interrupt timeout will force a tape switch.
The 16 seconds rule is quite impractical with the current 32K / 128K tape buffer limitations, but allowing a number of overflows chained from the original would make it possible.
In our experience (PMR: 43797,660,706) the VTS devices sometimes do not respond for a full 5 seconds, it is not a real hardware error as the device recovers and the queue is eventually processed.
In the current world of "one-size fits all" the manufactures of VTS hardware rarely consider the vulnerability of TPF to even the shortest period of downtime, therefore TPF needs to
adapt and extend its ability to buffer tape I/O.