Loose end. Why not allow reading the limit of (p2,sblimit)?

It might seem strange to specify range limits for bank calls, since it is possible to transform a bank into a range limited bank. These limits are supported in the bank call because it is this mechanism that allows transformers to be constructed that are not integrated with the bank.

Half Baked Ideas

These are some unorganized ideas to solve some unrelated problems.

Solutions {we will get to the problems later}

Have some space banks that own some definite contiguous storage.

This might be brought about by having an operation on a range key that produced a subrange key. Note, however, that range keys are not rescindable!

A related idea is to have a variant of the kernel range key that is for a limited block of allocation counts, perhaps just one. This could be directly used by a high performance untrusted data base scheme (perhaps hash organized) and yet provide a form of rescinding.

Reference locality on the disks
We should provide some tools for managing locality of reference to the disks.
Imagine a transformed bank that got a bunch of pages or nodes at once in such a way that a bunch tended to represent a cylinder or track of data. Such storage would be reserved, in effect, for the holder of the bank.

Such banks might have provisions for sending stuff back to the upper bank in case the upper bank needed the storage.

Such banks would tend to solve both the reference locality problem and the speed problem.

Such banks would need a relationship with their parent bank that has not yet been designed.

MVS provides tools for an application to ensure that its data is placed on disk contiguously so as to optimize disk performance. The space bank design of Gnosis can be turned to this end also.

If we had a space bank that tended to give out pages at successive CDA's we would have solved part of the problem.

The other part of the problem would be largely solved if page faults caused a bit of introspection:

Suppose that it is determined that page cda = n is required and that n-1 is in storage and that main storage is not congested. Under these circumstances it might be wise to bring a track worth of pages instead of just the page. This has been called anticipatory paging.

A similar idea of broader impact and easier implementation might be to notice upon page fault a pattern in the page table indicating sequential access. Such a pattern might be several valid page table entries adjacent to the faulting entry. It would be important to ensure that speculative reads be optimized in case of consecutive CDA's.

Banks like the above would need access to higher banks that gave out storage in larger hunks.

Help with Zapping Meters
The problem described in (p3,bm) could be solved if we had a call on a space bank for a priority node. Such nodes would be zapped ahead of non-priority nodes when bank guards were called. A guarded bank would get the node from its superior bank by calling for a priority node. This scheme would require each object to generate a new meter for its own use.

More Bank Involvement

Alternatively we might provide an auxiliary spacebank function to hold a meter key and distribute meter keys to it. The meter node would be built of a priority node and the bank would vouch for that. This scheme would have two ad-hoc advantages:
Most creators {including factories} would require a meter equipped space bank thus simplifying creator calls.

Objects sharing a bank could share a meter {and would not have to make their own}.

This scheme would require a small change to the factory so that the created domain's initial meter might be the bank's meter.

In detail, there would be a bank command to buy a priority node, return its node key, create a meter key to that node and keep the meter key. Another bank command would be to return that meter key.

This scheme seems as if it would usually not require an extra meter since a sub-environment normally entails both a new bank and meter anyway.

I think that this scheme is practical and solves a real problem but it seems ad-hoc and inelegant. There may be problems with priority nodes.

Other Ideas
Suppose that there was a meter associated with a bank. The meter of a new bank would normally be the meter of the parent bank.

Suppose that there were an operation on a bank passing another bank to inquire whether the latter was as lasting as the former. Some banks will not obey "destroy". "B<=C" means that bank C will not be destroyed before bank B. Here are the axioms concerning "lasting":

B<=B.

If B descends from C and B will not obey "destroy" then B<=C.

...

The scam
Our current spacebank design leaves us exposed to the following scam under commonly supposed pricing schemes:

An individual subscribes to Gnosis under two user names, Jekyll & Hyde, two names that we do not associate.

Hyde buys many pages from his spacebank and passes the keys to Jekyll. Jekyll sells these keys to his own bank and buys new pages and hoards the new page keys.

Hyde now cancels his account and leaves no forwarding address. We zap Hyde's guarded bank but get few pages back because the pages bought from Hyde's bank have already been severed {sold back to Jekyll's bank}.

Jekyll has the use of the pages. We know that someone has the pages but we have no way to find out who.

Some fixes {in disfavor}
I had supposed that the limit of the limited bank was the fast and direct way to compute a bill. The above scam discredits this.

The guarded bank's mass

Suppose that we change the guarded bank's logic to report the number of pages and nodes still really guarded by the bank {not merely the difference of things bought and sold}.
This would require a pass over the bank's chain and bringing to core each referenced node and the allocation pot for each referenced page.

This measure could be the basis of a traditional bill for space.

There seems to be no feasible way to get the time integral of the mass.

This bank change also might also help solve another bank implementation flaw:

To 10000 Do (Buy page from bank A); (Sell page to bank B) Od

The above program leaves both banks with bad estimates of their own mass.

Bad estimates in one direction lead to wasted storage and in the other direction to wasted CPU cycles.

Relating pages to banks
We have said that is not nice to sell a page except to the bank from which the page was bought.

If we were to enforce this, a few current programs would break but few of them would need to be redesigned.

A few programs that I would like to write would be stymied. These would build an object with one bank and cause the object somehow to be transferred to another bank at some cost much less than building a copy of the object with the new bank.

Charlie's fix
Charlie proposes an implementation to enforce the rule that material {pages and nodes} must be sold to the bank where it was bought.

Let each bank keep a bit map of CDA's of material that it has sold.

The bank will not buy back material that it has not sold {sound familiar?}. It might buy back material sold by its deleted sub-banks.

I propose that the deletion of a bank:
Cause the deletion of its progeny {recursively}

Cause its bit map to be or'ed into that of its parent.

I {NH} know how to do this efficiently {find the ones in the bit map} with the help of the FSC segment keeper.

Another advantage of this is that the node chain of guarded keys need not be kept since the guarding bank is the only object capable of rescinding access to a page or node. The bit map would thus suffice for the "zap guarded bank" function.

This design can also support an interbank operation wherein one bank transfers its set to another and deletes itself. It must be verified that the first bank not be superior to the second. Under the same circumstances the second bank can increment its limits at the expense of the first bank.

This also fixed the (bflaw) problem.

I {NH} am happy with this approach.

New proposed bank rules and implementation ideas
This is to pursue the ideas first described above at (crl-fix).

Rules

We use here the terminology "Bank B is .responsible for Node {or page} N" to represent a relationship between banks and material. This term may or may not replace the phrase "acceptable to" of the current bank specifications.

When a bank provides N {a node or page}, that bank becomes responsible for N. No other bank is responsible for N. If A is the parent bank of B and B is responsible for N and B is deleted then A {and no other bank} becomes responsible for N. A bank will delete and sever only material that it is responsible for.

Question: Has the range specification to banks been useful? Do we anticipate its usefulness?

Implementation
Suppose that each bank keeps a bit map {indexed by CDA} of the material for which it is responsible. 1 means "allocated" in this map and the "segment length call" operation of a fresh segment {(len)} together with the truncate operation provides an efficient way to find and extinguish the bits upon dissolution of the bank.

There is a global bit map {to which all banks have write access}. Here zero means "allocated". The same length call can now be used to quickly find a page of the map with available pages.

I think that a particular bank should stick to one page of the map while it can still find material there.

Transplanting banks
Note that it seems easy in this design to "transplant" a bank from one parent to another. What this means is that whereas before the transplant operation the parent of bank b was x, after the operation the parent of bank b is y. There would be a bank operation that counts the pages and node for which a bank is directly and indirectly responsible for. I.e., how many pages and nodes would be recovered by zapping said bank.

This would be useful when I want to send you some large mail. I create a bank, create a segment from that bank, write the mail into the segment and send you the keys to both the segment and bank. You transfer the bank to your bank and zap the bank when you are finished reading the mail.

This idea leaves unsolved the problem of how I might abdicate my ability to destroy the mail in a way that would be manifest to you. See (p3,integ-87) for new ideas in this area.

Note that the 940 operating system could do this.

A bank should be willing to identify a key as to whether it is or is not one of its page (or node) keys. Only banks with destroy rights should do this.

Cached Banks {or hoarding banks}. See (cached-banks,).

The idea here was to provide banks that had already bought some definite number of pages and nodes from the superior bank. The would guarantee access to that amount of space.

Pro
Order kt+4 on a bank currently deletes the bank while leaving the pages and nodes that it produced in play {still allocated}. Presumably the pages and nodes for which the bank is responsible would be transfered to the bank to which the current bank is immediately inferior. There is a proposal to eliminate this operation and always zap a bank's yield along with the bank. I describe here a use of the current function that may lead us to preserve the current kt+4 function.

Suppose I want to build an object that survives me such as a compiler factory. Compiler users will wish to be assured that the compiler will remain available upon my bankruptcy or merely upon my forgetfulness.

To assure them I buy access to a bank B, newly created for me, that is a sub-bank of an invulnerable bank IB. I pay an amount that is proportional to the limits on B. I then build my object using B and then return B to IB's owner for a refund. IB destroys B and refunds me the amount that I didn't use. My object's bank vulnerability is now only that of IB. That my object is indeed made from B and no more vulnerable is vouched for by the logic described at (p3,vb).

Con
I think there is a bug in the above argument: If I cannot trust the code that holds write access to the pages of the compiler, not to sell them back, why should I trust the code not to obliterate the data in the page? If I can trust the code not to sell back the pages why do I need to delete the bank?

I think the Con's have it.

The ideas described at (p3,integ-87) seem to require the following bank functions.

The bank transplant described at (transplant) becomes much more important.

Bank Vulnerability

Some measure of bank vulnerability. This might be a comparison between banks for relative vulnerability which would yield a bit. This could be invoked by calling either bank or the SBT. Calling a bank that you already trust seems the most natural. The call would mean "Does this here bank have vulnerabilities that you don't?". A bank would answer "no" for any ancestor. The key proffered on this call should be a key too week to buy material.

The ideas described at (p3,bf) achieve this without vulnerability logic in the bank, but then the kt+4 bank order as distinct from the 64 order is required.