Provide capability to restrict use of Global Variables in Subprocedures

Interesting idea, but certainly not something I'd like to see implemented. However if it IS implemented my I suggest that it be a scope thing. For example:
create a new scope identifier, such as DCL-PROTECTED which would allow those variables to be declared globally or in a /INCLUDE and would NOT be visible inside of subprocedures unless they include a keyword identifying the protected-scope name. Although I would question the program design if this kind of feature is really needed, but whatever.

Here's my suggestion:

DCL-PROTECTED Pickles;
dcl-s company varchar(50);
dcl-s x int(10);
end-protect;

DCL-protected Peaches;
dcl-s rc int(10);
dcl-s msg varchar(50);
end-protected;

dcl-s CustNO Packed(7: 0);

getCustomer(custNo);

dcl-proc GetCustomer allowProtected(Pickles);
... blah, blah, blah
end-proc;

The variables that are GLOBAL are accessible to all procedures (no change form today) and those in the DCL-PROTECTED scope are visible Globally _and_ to subprocedures that include the ALLOWPROTECTED( Peaches : Pickles )
In this example since the GetCustomer subproc has only AllowProtected(Pickles) it can see all non-protected global variables as well as those in the PICKLES protected area.

You're welcome! :)

This request is still a candidate to be an enhancement for the RPG compiler.

The COMMON Europe Advisory Council (CEAC) has reviewed this requirement and recommends that IBM view this as a medium priority requirement that should be addressed.

Background: The CEAC members have a broad range of experience in working with small and medium-sized IBM i customers. CEAC has a crucial role in working with IBM i development to help assess the value and impact of individual RFEs on the broader IBM i community and has therefore reviewed your RFE.

To find out how CEAC help to shape the future of IBM i, see CEAC @ ibm.biz/BdYSYj and the article "The Five Hottest IBM i RFEs Of The Quarter" at ibm.biz/BdYSZT

Therese Eaton – CEAC Program Manager, IBM

I like the GLOBAL(*NONE) and dcl-s myVar *global approach. Appears to offer a good combination of capability and upward compatibility.

I concur with @JMarkMurphy. I would like to see a GLOBAL(*ALL) - the default and exactly what we have now - or GLOBAL(*NONE) on the control opt.

If using GLOBAL(*NONE), and a global item that is to be referenced in a subprocedure must be defined in the subprocedure, as referencing the global variable e.g.

dcl-s myVar *global;

The benefit of this (to me) is that the definition of all variables (etc.) used in the subprocedure are defined in one place.

The CAAC has reviewed this requirement and recommends that IBM view this as a “nice to have” low priority feature. It is hopefully a rare situation that this happens, but it is certainly confusing for anyone new to the language.

Background: The COMMON Americas Advisory Council (CAAC) members have a broad range of experience in working with small and medium-sized IBM i customers. CAAC has a key role in working with IBM i development to help assess the value and impact of individual RFEs on the broader IBM i community, and has therefore reviewed your RFE.

For more information about CAAC, see www.common.org/caac

For more details about CAAC's role with RFEs, see http://www.ibmsystemsmag.com/Blogs/i-Can/May-2017/COMMON-Americas-Advisory-Council-%28CAAC%29-and-RFEs/

Nancy Uthke-Schmucki - CAAC Program Manager

@HassanFarooqi, it wouldn't be possible to change the compiler so that subprocedures could not access any global variables, since that would not be upward compatible.

However, the purpose of this enhancement request is to allow you to code a keyword to prevent a procedure from accessing any global variables. And if an H spec keyword were part of this enhancement, then you could code GLOBALS(*NONE) in the H spec, to make it the default for procedures not to be able to access any global variables.

Bad idea. I loved C for the fact that each class is an penetrable shell, so once it is error free you do not have to worry during development or debug if it has caused any problem. Sub-procedures is a poor man's class. I would rather prefer if a sub procedure is unable to use global variables, and is restricted to whatever is passed in.

IBM will use this request as input to planning but no commitment is made or implied. This request will be updated in the future if IBM implements it. IBM will use votes and comments from others in the community to help prioritize this request.

IBM has received the requirement and is evaluating it. IBM will provide a response after evaluation is complete.

@JMarkMurphy Sadly that is the biggest impediment. i.e. that you cannot make it the default (which I would really like to do) because it would break too many existing routines. even if I was prepared to accept that (I might be) IBM most certainly would not.

The result is that this can never be compulsory - other than on site standards basis. But if the facility is there it can at least be used.

I wonder if a compiler option could be used to assist in this? For example the default could be the current situation of Global(*All) and you could set your own compile defaults to Global(*None - or *Specified - or *Whatever).

@JMarkMurphy Sadly that is the biggest impediment. i.e. that you cannot make it the default (which I would really like to do) because it would break too many existing routines. even if I was prepared to accept that (I might be) IBM most certainly would not.

The result is that this can never be compulsory - other than on site standards basis. But if the facility is there it can at least be used.

I wonder if a compiler option could be used to assist in this? For example the default could be the current situation of Global(*All) and you could set your own compile defaults to Global(*None - or *Specified - or *Whatever).

@JMarkMurphy

I'm familiar with how PHP does it but I don't see how we could make it work for RPG. The biggest problem is that you would have to break compatibility with what we have now in order for your approach to work.

I like the idea of having to declare global variables locally, like this:
dcl-s a Global;

I think for the ctl-opt, you'd want to just modify the default rather than list variables. There might be multiple procedures and you wouldn't necessarily want all of them to have the same globals.

PHP has a similar feature, but in order to access variables in the global scope, the user must define a variable in the local function scope as global. This is nice because it is explicitly defined in each function which global variables are used within the function.

I think a keyword on the dcl-s or dcl-ds statement such as Global would do this, and keep all definitions together. The keyword would be used in place of Like or explicit type definitions.

Re your comment on the ctl-opt version - it was a feature that I added later after realizing that in many cases it would be the exact same set of variables that I wanted to be available to all subprocedures. I guess one could add a keyword to the variable definitions to indicate "all access" but then it all gets a bit confusing.

I had originally planned to include the wildcard option and I have no problems with it - but I do think the compiler/RDi outline would need to detail exactly which variables were impacted, This is particularly important in programs defining files where the programmer is less likely to know the exact names of all fields defined.

About the ctl-opt version of the keyword, just thinking as a programmer, I think it would be better to have all the available globals for the procedure listed in one place. Another possibility for fairly easily picking up many globals at once, and also promoting good naming conventions would be to allow a name pattern, such as g_* in the procedure-level GLOBAL keyword: GLOBAL(g_* : fld1 : fld2).