×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 18-Feb-2015 11:46 -0600, Vernon Hamberg wrote:
There's an IBM page in KnowledgeCenter that says to use
OVRSCOPE(*CALLLVL) if using an ILECL program
And that is the likely resolution for the OP, *if* they compiled the
CL requests into an ILE CLP. I do not recall for sure, but [and may
depend upon release], the FTP runs in ACTGRP(*NEW), so an override
scoped to any activation group definition\name will never be visible to
the FTP feature; I said as much, "on v5r3", here:
<
http://archive.midrange.com/midrange-l/201409/msg00326.html>
That documented recommendation is presumably for when someone is
converting code from OPM CL to ILE CL, because the old behavior's
default was Call-Level scoping. The new default OVRSCOPE(*ACTGRPDFN)
mimics the effect of OVRSCOPE(*CALLLVL) when used in OPM CL, but will
scope the override to the activation-group name defined when used in an
ILE CL program. Thus to mimic the OPM CL, the Override requests in ILE
CL might want to keep the Call-level scope just-in-case some of the
called programs as converted code that refer to the overridden name,
might not all be in the same ActGrp [or similarly, per any of the called
programs not yet having been converted from OPM CL]. For other than
converting the code, the better choice is to choose an appropriate
scoping according to the needs\design of the application; i.e. there is
no one valid recommendation that could be made, not legitimately IMO.
- I'm just inclined to use OVRSCOPE(*JOB) for a lot of this kind of
thing - that's the old behavior before activation groups, as I
recall.
The job-scope override was never the default; the default for the
Level (LVL) parameter for Delete Override (DLTOVR) has always been the
asterisk as special value to denote the current call-level, so deleting
those overrides required explicitly requesting DLTOVR LVL(*JOB).
I find job-scoped overrides are rarely desirable, except out of
laziness to avoid determining what is most appropriate. That is because
either the job must end so as to avoid latent effects that may prove to
be undesirable per having failed to properly delete those overrides or
the explicit job-scoped override must be deleted when done to avoid
latent ill-effect. Any code that does not have a proper termination
handler coded might leave those overrides active; for CL, that is in my
experience, the vast majority of the code. Accidentally leaving
call-level scoped overrides active is not so easy as leaving job-level
scoped overrides, because the call-level scoped overrides disappear when
the call level completes. And activation-group scoped overrides
disappear when the activation group is reclaimed. Overrides with a
lesser scope than *JOB are much less likely to have a negative effect,
conspicuously because, they are limited to that narrower scope.
As an Amazon Associate we earn from qualifying purchases.