Jon Paris wrote:
CRPence wrote:
That was their lame response to my *pleading* that they fix
the problem correctly; for which I clearly outlined a safe
[& simple] resolution.
I'd love to know how you planned to handle it because we wrestled
with design options for months and months to see how it be
handled without reworking the entire architecture.
For example how do you propose that a service program designed to
maintain state information be handled if it is in an AG and has
no active invocations? That is one of many dangers with
*Eligible. The Service program has no main line, nothing that
could be called to tell it to shut down neatly, etc. etc.
As written, that question seems to refer to an /it/, with regard
to a resolution, which is other than what I was suggesting. If the
reference is to general programming, I would concede there was
nothing wrong with *ELIGIBLE, for user defined activation groups
from my perspective. I found little cause to be concerned if a user
or programmer broke pgmX because they did RCLACTGRP *ELIGIBLE,
because that was just their own /issue/. However...
Over time it was learned there were also several IBM-created,
even system state activation groups, that were being reclaimed
unexpectedly by the RCLACTGRP *ELIGIBLE request. The effect was
exactly that danger; that is, the state which was expected by these
system programs was being lost, causing all varieties of strange
function checks. The effects were too numerous and generic to make
the failures easily search-able to enable someone finding out that
the origin was from a request to RCLACTGRP *ELIGIBLE. And of
course, the effects were manifest in IBM code, resulting in service
calls.
I wanted that RCLACTGRP change to correct the problem of having
included /system/ AGs from its definition of *ELIGIBLE, by changing
what was included in the definition of *ELIGIBLE; i.e. ignore what
could obviously be inferred to be a /system ActGrp/. A new SpcVal
*ALLELIGIBLE or *SYSELIGIBLE could have been added if the function
of tearing down system-owned activation groups was desirable to have
[remain available as a power in the hands of a *user].
There was push back against /changing/ the definition of
*ELIGIBLE as though someone actually depended on being able to break
various IBM-supplied code. The choice was made instead to /hide/
the fact that special value existed, hoping that would keep people
from using it. I infer from the quoted text, that perhaps that
little trick was more for limiting impacts within user AGs.
But they did actually change the definition of *ELIGIBLE as I
requested, but in an odd way. Instead of ignoring system AGs
generically [as I requested], everyone within IBM that created [or
had] an existing AG that was impacted by reclaims against *ELIGIBLE
would have to register their AG as being an exception; i.e. to sign
up for exclusion. Thus any AG which required being ignored by a
user-requested reclaim of *ELIGIBLE ended up having to effectively
subscribe to what equates to an /omit list/. Thus instead of
implicitly ignoring all system AGs by default, the RCLACTGRP
*ELIGIBLE would only avoid the system AGs by an explicit request to
ignore; the function of *ELIGIBLE became:
reclaim where ( (Eligible) AND (NOT IN (omit_list)) )
So obviously the argument that *ELIGIBLE was no longer
functioning the same was vitiated by that change; with different
means than how I requested. The only valid claim was that if 'Q'
AGs [other than QILE] were perhaps to no longer get reclaimed, then
customers using AG names like QUSER or QIBM might be impacted,
because their AGs would no longer be reclaimed. So were they
protecting reserved names? I must say I was never so shy as to
state quite simply, *that* is a user error. I did not get it, and
of course I was not worthy of being included on any discussions, but
I think the attempt to obfuscate the special value was asinine [with
regard to protecting IBM code] and relying on proactive & reactive
exclusion of IBM code by a list, versus finding a way to make the
decision on the system at runtime seemed a total cop out.
Regards, Chuck
midrange.com
