Enhanced SQL Call Level Interface (CLI) resource management options

Today, a CLI (SQL Call Level Interface) environment handle allocated via the SQLAllocEnv() API is automatically tied to the callstack entry which allocated it, meaning that when that program leaves the stack, the system deems the environment handle fair game for automatic cleanup. What we're looking for is an override switch to this functionality, where a CLI environment handle (and all associated resources) can optionally be 'flagged' as being managed by the caller, rather than by the system (perhaps SQL_HANDLE_MANAGEMENT_AUTO/CALLER; default AUTO). Really any method to prevent this automatic cleanup of environment/connection resources will do - the setting of a system environment variable or whatever, we don't mind. The point here is, the CLI suite of APIs is excellent, and we - and I suspect others as well - would like to be able to do more with it. The value of any good API is that it crystallises a specific function such that it can be re-used more easily. Iteratively re-using established APIs / BIFs to build additional layers of programming tools is how we keep evolving our coding practices and the complexity/flexibility of our coded solutions. What this memory management limitation of the CLI effectively does is prevent the allocation of key resource handles in certain containerized functional blocks - specifically procedures exported from a service program. If a (RPG) service program were to be developed offering helper APIs for xConnect(), xQuery(), xRead(), etc., the inner workings of these functions could (for example) automatically describe the dynamic result sets, allocate and bind buffers, perform blocked fetches, protecting the calling program from the relative complexity required. If the CLI cannot support resources being instantiated from atomic, exported service program procedures in this way, however, (because the service program in this case only briefly remains on the call stack), then such a toolset becomes seemingly impossible to realise with CLI. In my view this criminally restricts the usefulness of the CLI, which would otherwise offer the most powerful SQL interface (for DB2i connections) on the iSeries platform. I suspect this limitation is borne out of good intentions, rather than willfull restriction of the tool. But early issues with memory management in the original incarnations of the CLI are a distant memory by this point, and I think the time has come to allow these handles to be explicitly managed by the application programmer in certain circumstances. What do you think?