The 370 Keykos specifies two kinds of banks, prompt and non-prompt. Only prompt banks were implemented. Non-prompt banks were not entirely specified. An order for space on a prompt bank always responds quickly to grant the space or say “no space available”, whereas a non-prompt bank might indefinitely delay the response as it consults user provided space policy agents who might make more space available. When you pass a bank to some sort of creator, requesting some new complex object, and that creator is shared with others, the creator should verify that the bank is prompt before invoking it. If it fails to do so then the shared creator may become unavailable to others as the bank stalls indefinitely upon a request for space.
Programs needing to build objects that might require substantial space, would hold both a prompt and a non-prompt bank. The prompt bank would be for a dearer inelastic supply of space and the non-prompt bank would supply the bulk of the space, an amount of space to be determined, perhaps, as the computation proceeds. Invocations of a factory would pass both and the factory proper would invoke only the prompt bank. Both banks would be passed to the factory yield. This plan requires two kinds of space planning, one for each kind of bank.
Call sites for non-prompt banks would not need logic to contend with denials. Algorithms without plans for coping, would run in domains what would be merely deleted upon exhaustion; perhaps to try a more space efficient algorithm.
Keykos banks report on the limits available on the observation that this information could already be had by ordering storage until such orders were rejected. This reason does not apply to non-prompt banks for which there may be no limit calculable.