× 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.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.