Which value did you modify? 

The pool size takes couple values into account.

Which connection pooling are you using? If using default boot one it's Hikari and the value to change should be maximumPoolSize

The default value for connection pool size on boot is usually 10. You may want to set this value to 1 or 2 for testing purposes (if using the IRIS community version).

The confusion here is that you created 3 class mappings for a single global (not a good practice) and your understanding is that they're just "views", however the 3 of them are full class/tables with the same properties/ownership of the data. With that in mind, using SQL DROP statement has the same effect for any of the 3 tables/classes  (if DDL were allowed).  As others have pointed out, you can accomplish what you're trying to do with DROP %NODELDATA or by removing the class definition (either from Studio or programatically). 

If you wanted to declare views instead of tables then you need to do so via SQL CREATE VIEW statement.

One variation to #1 would be to  pass an object. It provides for readability (assuming property names are legible) and would allow for flexibility if you need to add a new parameter in the future (method signature doesn't need to change). 

You can remove the Calculated keyword and use a combination of  SqlComputeOnChange and Readonly keywords.

What you accomplish:

- Removing Calculated keyword, makes the column persistent

- Adding SqlComputeOnChange gives you control on when you want the value to be calculated (using %%INSERT or %%UPDATE) and based on which column (don't add any if calc must happen for all inserts regardless of which fields are being inserted).

- Adding Readonly just provides and extra "safety" that the value can't be changed via SQL or Object means.

Property readonlyprop As %String [ ReadOnly, SqlComputeCode = { {*} = {ID}_(+$H)}, SqlComputed, SqlComputeOnChange = %%INSERT ];

Can you provide what you get from this command set sc=res.Prepare(sql,,conn)? The error should tell you why the query failed preparation.

I'm not sure there's a Cache specific document for designs like this. There are multiple ways to separate data in any database (schema, instance, namespaces, etc). Cache provides extra features such as namespace mappings that makes sharing simpler but before you get to Cache specific implementation you need a high level design of your application. Regardless of database and programming language, how should my application work?  How do you plan to sell your product? How flexible you want it to be? As Dmitry pointed out, are there any regulations/limitations around sharing data within customers? All this should be based on your  business model and has nothing to do with technology stack. 

Even SQL operations are captured in the journals as far as my understanding goes. But I'd agree any solution would have to check on any scenarios such as data not being journaled since processes can disable journaling "at will".  Journaling can also be disabled at the db level.

Going under the assumption that "everything" is captured in the journals it should be possible to write a process that reads the journal file and convert its entries to another format.

Besides dynamically changing the maxlen what else are you trying to accomplish/avoid? These values are used at compile time to generate the SQL catalog and become part of your contract (for clients calling them). If you were to dynamically change the values 1) you'll be breaking the contract (e.g. you could change the values to a more restrictive size) and 2) you would still need to compile the class holding the stored proc/query. 

The benefit I can think of this approach right now is avoiding pushing code to prod (assuming that process is cumbersome), however you still need the compile part.  It'll be better to define and modify the stored proc using DDLs (maybe  a faster change in prod depending your company's rules).  Since this change is a database object change it should be treated as code and thus (hopefully) kept in source control (for audit and replication purposes).