Gerhard Postpischil wrote: <begin snippet> In general I tend to agree with this, but I've worked or consulted at installations that either had problems completing overnight jobs in their assigned batch window, or just processing large amounts of data. </end snippet>
I value GP's concurrence. Let me add, however, that 1) in my experience batch-window problems are always i/o-related; and 2) the unwashed always attack them in the wrong way, devoting resources to "optimizing" instruction sequences that, even if it had been possible to reduce their CP consumption to zero, would have left the batch-window problem unresolved. These applications, like most commercial batch ones, were i/o-bound, and their resolution required the use of overlapped, asynchronous i/o, which, for those who know how to do it, is not difficult. What it was/is in most of these shops was/is, quite literally, unthinkable. (The RESIDENCE time of a classical MFU can always be cut by a factor of four or more using asynchronous i/o.) John Gilmore, Ashland, MA 01721 - USA
