Re: [Oorexx-devel] Multiple Rexx interpreter instances and .local, a problem

[René J. <rvj...@xs...>]

This sounds like a needed documentation change - the programmer needs to know that .local is indeed not global.

Best regards,

René.

> On 21 Sep 2017, at 06:38, Rony G. Flatscher <Ron...@wu...> wrote:
> 
>> On 20.09.2017 17:13, Erich Steinböck wrote:
>> Not sure if I correctly understand, but:
>> if you're not happy about .LOCAL being local, then put your stuff into .ENVIRONMENT.
> This is not about happiness, it is about being sure that the contract between a Rexx coder and the ooRexx runtime holds. 
> 
> .local is documented to be usable for the Rexx programmer to store and fetch values. When a Rexx object's code gets executed on a different Rexx interpreter instance, .local all of a sudden (and "silently") is changed and does not have the content, the Rexx programmer relies to be there (as that program placed values beforehand). 
> 
> As a result such Rexx code may break unexpectedly. 
> 
> Or with other words: a Rexx object is dependent on the .local object it used to store values. Changing that .local object without notice breaks the runtime environment integrity for such an object.
> 
> ---rony
> 
> 
> 
>>> On Wed, Sep 20, 2017 at 1:14 PM, Rony G. Flatscher <Ron...@wu...> wrote:
>>> A Rexx interpreter instance will create a .local environment (a directory) that is local to the Rexx interpreter instance, ie. all programs being executed in it. (The .environment environment - a directory - will be available to all Rexx interpreter instances.) 
>>> The .local directory contains entries for (in alphabetical order):
>>> 
>>> DEBUGINPUT
>>> ERROR
>>> INPUT
>>> OUTPUT
>>> STDERR
>>> STDIN
>>> STDOUT
>>> STDQUE
>>> SYSCARGS
>>> TRACEOUTPUT
>>> Rexx programs may use .local to store all sort of data they might need while executing or coupling different Rexx programs with each other. Such Rexx programs are *dependent* on .local having all entries available to them, that they - or cooperating Rexx programs - place/store in .local.
>>> 
>>> The problem: currently, when running code from Rexx packages/programs on different Rexx interpreter instances, do *not* have entries available in .local to them, if they run on a different Rexx interpreter instance! 
>>> Please note: when formulating "running code from a Rexx program" any Rexx code that executes is meant, e.g. the method Rexx code of Rexx objects which happen to run on a different Rexx interpreter instances (maybe including UNINIT code). Or globally shared public routines that use .local for their purposes, and get executed in different Rexx interpreter instances, and the like.
>>> 
>>> As a result, such Rexx code might behave in an undetermined manner or even break when run in a different Rexx interpreter instance, if they cannot access the .local environment they placed/stored their objects in.
>>> 
>>> ---rony
>>> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Oorexx-devel mailing list
> Oor...@li...
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel