Re: the advantages of garbage collection

Steve Richter wrote:

the problem with this approach is what do you do if the driver CL
module never ends? It's function is to process requests from a data
queue. By never returning, the AG would not be reclaimed, and the job
would eventually have gigabytes of memory allocated.

I'm trying to avoid the GC part of this conversation; I spent way too many years dealing with memory leaks (no comments, eiteher <grin>). You either do your own memory management (the C model), or you relegate it to the runtime (the Java model). Technically, RPG follows the C model, but very few programmers ever need to allocate memory. If you're writing code that requires a lot of memory allocation, you're either doing something you oughtn't to be doing, or you're as smart as Scott Klement and you will do the memory management correctly.

(Interestingly enough, if you look carefully at the Java interface for RPG, you'll see where the two models collide. The interface has specific calls to perform GC for object references. You can either do it an object at a time or you can set a reference frame and then clean up everything when you're done. Quite elegant, actually.)

Allocating resources is a different animal, though. We all allocate resources, whether it's open data paths or object locks or what have you. With the proliferation of service programs and called programs that don't set on *INLR, it's normal. But the statement above simply misses the point.

If you have a request processor and you want to process everything and you want to use AG as a cleanup, you have two recourses. One is to use *NEW on the call from the request processor to the business logic. This means that each request will automatically get cleaned up before the next request is processed. Simple and easy to implement, but not quite as flexible. The second is to have the business logic run in a named AG. With this, if two requests come in that are logically related, you can simply call the business logic and the state of the AG is essentially retained. If, however, you need cleanup, then the request processor does a reclaim of the named AG. Again, very simple, but it does require a little more work on your part.

But in both cases, there should be one obvious point: the request processor is in a *different* AG than the actual business logic. This is as it should be. If you are actually doing distinct units of work that may require significant cleanup, then the AG boundary is exactly the way to segregate that workload, and the point of segregation is when you read a request and figure out what to do with it.

Joe