Can i clear qrplobj

If a user is currently using an object which is deleted by CLRLIB, the user will receive an escape message and his job will probably be aborted. The most typical case where a problem may occur is with program objects. Program objects can be replaced while they are in use. Leave it open. From another job modify both the screen and the program. You want the lock as that is your safety check to see if it's safe to delete it.

If the program never locks it but just uses it then I hope you can see how it might be risky to clear that library out. If, however, it leaves a lock on it then you should be able to safely clear out all the objects in that library without a lock. But I just wanted to get verification that I'm good to do this. Our development partition is used by maybe people. We sign off everyday. There've always been numerous alternatives that recovered much more.

If your developers are making numerous database changes, the system xref can grow quickly unless you keep it re-org'd with this.

Lots of other choices. But no matter; the system is yours, not mine I hope this is of some help, Roland Goldsack. Smart is Beautiful. Oops, I promise to never put out any source without testing it first. Create a small program that runs every night or every week perhaps. Although you run 24 hours 7 days a week, I guess you terminate your interactive subsystems from time to time to make sure that you don't have any "unnecessary" jobs "floating around".

You can test it with a very simple CL program. AFAIK, it is the actual original program object, but simply renamed and placed in a different library. The simple fact that it is still accessed by active jobs through the original pointer pretty much guarantees that.

When needed, it's hard to imagine a better tool. But when it comes up unexpectedly, it can cause some very puzzling debug sessions. You can "delete" a running RPG program without having it actually go away.

So long as the program is activated it will only be "logically deleted". It will actually go away when deactivated. Deleting a running CL program, however, is not advised, as CL is "reentrant" and the program won't be activated. NB: "Not advised" here means the whole system might crash. The big danger with RPG is if the program has been resolved to but is not currently activated. I raised the issue then because I recalled warnings from IBM in earlier releases and couldn't recall any specifics.

However, I have a couple specific concerns. Second, a primary use of QRPLOBJ is to hold objects that may be in use and therefore cannot be directly deleted without 'unpredictable results'; by moving the objects to QRPLOBJ even including renaming the objects , resolved pointers can continue to be used by active processes.

This use can be seen by examining call stacks of jobs that are using such objects. An additional, secondary use is to hold objects that might need to be recovered quickly. This is simply because they show up in there and I can't know why they weren't directly deleted.

I easily agree that objects I can identify from my own development work are candidates for deletion whenever I choose because I chose to put them there.