[FIXED] Activation Groups - 3.2

[EvaY]

I found another post from 5/2011 that discussed activation groups and how Valence handles them but that was for version 2.2. I'd like some clarification on the same topic but as it applies to 3.2, in case it's different.

Here's my problem:
I have an application running in a Valence instance but outside of the portal. Same concept as your "No Security" example. As with all of my Valence RPG programs, it runs in the VALENCE activation group. In my RPG, a call is made to a CL that runs a third party software command which then spawns off into it's own activation group. I can't access the third party source so I have no way of preventing this. The problem is that sometimes the third party program bombs and from what I can see in the joblog, it's because the CLEANUP procedure in VVCALL is deleting the third party activation group.

It baffles me as to why it only happens sometimes - I can't duplicate it on demand. I suspect it has to do with the nature of the CGI jobs that run in the Apache instance but I'm not well versed in that area and am only speculating.

Based on a conversation I had with Richard a few weeks ago regarding an unrelated challenge, I don't believe changing the Valence activation group reclaim behavior in the "Server Instance Options" settings will make a difference since the program is not running inside of the portal. Not to mention, even if that would work, I wouldn't want a change like that to be a global setting anyway as the problem only applies to this particular app.

Any suggestions as to how I can resolve my dilemma?

[BRandle]

In your "No Security" scenario, are you using the same port/Apache Instance? Meaning, using the same CGI jobs as Valence? If so, then vvCall's clean-up routine would eventually affect the 'No Security' calls. When your 'No Security' program creates a new activation group, a later call to vvCall (that happens to hit the same CGI job) would subsequently reclaim it.

Your Valence Settings controls what -- if anything -- gets reclaimed. Per the manual:

Activation group to reclaim - (optional) Specifies the activation group to be reclaimed upon completion of each call to the back-end, via VVCALL, for the purpose of cleaning up open data paths, etc. Note that the VALENCE activation group is always active and will never be recalled. Therefore, if your custom programs use *CALLER or VALENCE they will not qualify for consideration by this process. The default value for this setting is *ELIGIBLE, meaning every eligible activation group will be reclaimed at the end of each call.

You can set this value to blank and Valence will no longer run the RCLACTGRP in vvCall.

You mentioned that you use the Valence activation group on all your programs. That means the 'Reclaim' isn't going to clean up your custom programs/files, since "VALENCE" is active within vvCall and thus not eligible for reclaim. This reclaim function is intended to reclaim custom activation groups and shut down files used by your programs (preventing locks, reducing memory, etc.). So if you'd like the reclaim to work on your custom apps but leave this third party activation group alone, you should consider using a name other than "VALENCE" for your own custom programs and then explicitly reclaim just that group by putting it in the "Activation group to reclaim" setting. This way Valence would call your program (in Activation group 'MYCOMPANY', for example), then when finished, would reclaim just that activation group ('MYCOMPANY'). Any other activation groups would remain active.

[EvaY]

I'm a little unclear on your comment about using VALENCE for the activation group in our custom programs. (your last paragraph) I understand what you're suggesting to solve my current problem and it sounds like it will achieve exactly what I'm looking for (thank you, I'll give it a shot!) but I'm getting the sense that you're suggesting we not use the VALENCE actgrp for our custom programs at all. (to prevent locks, the reduction of memory, etc.)

I'm asking for clarification because all of the examples, the VVTEMPLATE source, and the AutoCode generated programs use a /copy for the vvHspecs which contain actgrp(‘VALENCE’). The Valence manual also makes reference to the requirement of using VALENCE actgrp (or *CALLER) in order to utilize the error trapping APIs. I don’t ever recall being advised to stay away from using the VALENCE actgrp.

Am I misinterpreting your comments? What's best practice?

[robert.swanson]

Hi Eva,

Normally when we're at a customer site doing custom Valence development work, we set up a custom /copy source member to hold their h specs -- i.e., VXHSPEC -- and reference that at the top of each RPG program instead of VVHSPEC. In VXHSPEC we put in an activation group that is something other than VALENCE -- i.e., actgrp('ACME_CORP'). This is so that the RCLACTGRP routine in VVCALL will apply to the custom programs but leave the Valence resources available, since those are used on pretty much every call.

That's not to say you can't use VALENCE (or *CALLER) as the activation group for your custom apps as well. But if you're looking to get the RCLACTGRP logic in VVCALL to work then you'll have to change it.

I should emphasize that it's not absolutely necessary to use the reclaim activation group feature at all -- you can blank it out in the settings (thereby turning it off) and everything should work fine. This feature was added at the behest of some clients who wanted a way to make Valence clean up all the open data paths that tend to accumulate in the CGI jobs over time, particularly from using SQL routines. From what we can tell these ODPs are normal, opened automatically and left there by the OS for potential reuse, but they can appear messy when you're looking at the jobs and see multiple open data paths referencing the same file(s).

FYI, in the forthcoming maintenance release we've added an interval option to the reclaim feature, so you can optionally have VVCALL only apply the RCLACTGRP on every, say, 100th call.

And yes, if you're using the Valence error trapping API in vvUtility (not many people do), then using a custom activation group means you must register/unregister the error handler using the RegisterErrorHandler procedure, same way it's done in VVCALL.

I'm making a note to get the manual updated to reflect these points on the activation group more clearly. We'll also update the VVTEMPLATE source accordingly.

Rob

[EvaY]

Ok, I shared the info with one of my cohorts here and we're going to do some thinking to determine how we'd like to handle act grps going forward.

Thanks Brian and Rob for your feedback!!

Eva

[EvaY]

Update:
Blanking out the "Activation group to reclaim" setting solved my problem with regards to the third party activation group getting deleted.

Thanks!