• Intrinsic REXX from GnuCOBOL

    From bwtiffin@1:2320/100 to comp.lang.cobol on Wed Mar 29 01:11:28 2017
    From Newsgroup: comp.lang.cobol

    Hello, everyone
    Regina REXX is being built into GnuCOBOL as an Intrinsic Function. It is working out quite well, and the potential synergy is bubbling up, just waiting to be discovered.
    This build is currently a side branch of the main GnuCOBOL development tree. It will likely be folded into GnuCOBOL proper shortly after the official release of GnuCOBOL 2.2. (We'll be releasing GnuCOBOL 2.0-rc3, officially as GnuCOBOL 2.2 soon).
    Implemented as two functions, rexx() and rexx-restricted() (which turns on the Regina RXRESTRICTED feature to disable many of the more dangerous powers of REXX when scripts may come from unscreened sources such as end user programs). As an intrinsic function the feature allows for code such as
    display rexx-restricted("return 6 * 7")
    ----
    display rexx-restricted("address system 'rm *.important'; return 'No delete, restricted script'")
    ----
    01 cobol-field pic x(64).
    move rexx("parse version info; return info") to cobol-field
    display trim(cobol-field)
    ----
    01 answer usage binary-long.
    compute answer = numval(rexx("return 6 * arg(1)", 6)) + 6
    display answer
    ----
    REPLACE ==newline== BY ==& x'0a' &==.
    01 rexx-result pic 9(5).
    move rexx(
    "sum = 0" newline
    "do i = 1 to 10" newline
    " sum = sum + i" newline
    " say sum" newline
    "end" newline
    "return sum + arg(1)", 127)
    to rexx-result
    display rexx-result
    ----
    01 shared-value pic x(6).
    display rexx("a = arg(1); say 'Got: ' a; push a; return 'a pushed'", "abc") move rexx("pull a; return a || 'def'") to shared-value
    display shared-value
    With judicious use of character data concatenation in COBOL, upto 8K of script (default configuration) can be passed into rexx() or rexx-restricted(). Using ADDRESS and CALL, unlimited sized external REXX scripts are also supported by returning the RC, RESULT or SIGL special variables.
    The first argument is the REXX script, followed by up to 32 optional arguments passed to REXX as ARG(n) values. The 32 limit can be changed and is dependent on compile time and runtime configurations. The function return field is effectively an any length COBOL character data field (just like other alphanumeric intrinsic functions).
    The beta defines one EXTERNAL data item that provides access to the REXX API return code. Currently, as each rexx() invocation is a separate interpreter, shared values between scripts use the push pull features of the internal Regina
    stack.
    Specially crafted COBOL modules, that code to the SAA REXX external function API are proven, and there is a rxfuncadd sample in the Intrinsic REXX tips and tricks thread that is accumulating in the GnuCOBOL SourceForge project space. This is where programmable COBOL applications start to shine through. A GCI sample should be posted shortly, making it even easier to expose COBOL programs
    to REXX scripting potentials. (This is almost completely under developer control, as rexx() can be used to define the function entry points and end users can then be provided with rexx-restricted() scripting access, either externally or from within compiled COBOL applications). I say "almost" as the reality is, if you have an admin with access to your executable, they have to be trusted individuals anyway and this feature exposes no risk beyond what is already inherent when running systems. https://sourceforge.net/p/open-cobol/discussion/cobol/thread/2b41632f/
    Design and development notes are being discussed in a Contributions thread at https://sourceforge.net/p/open-cobol/discussion/contrib/thread/c31cd4d6/
    SVN repository with download instructions at https://sourceforge.net/p/open-cobol/code/HEAD/tree/branches/gnu-cobol-builtin-script/
    This will soon be part of the mainline GnuCOBOL release tarball/zip file, but for now is still in a branch of the source repository and will require building
    from source using ./configure --with-rexx for GnuCOBOL and a working installation of Regina REXX.
    Leverage REXX directly from COBOL source, and provide easy access to COBOL modules for end user scripting.
    This is all free software, with GNU LGPL COBOL runtime and Regina REXX licensed
    under the GNU LGPL as well.
    If you try it, feel free to drop questions and opinions in the GnuCOBOL discussion groups on SourceForge. Documentation will be accumulating in the GnuCOBOL FAQ at
    https://open-cobol.sourceforge.io/faq/index.html#intrinsic-rexx
    This announcement is being posted to both comp.lang.rexx and comp.lang.cobol. Have good, make well,
    Brian

    SEEN-BY: 154/30 2320/100 0 1 227/0
  • From pete dashwood@1:2320/100 to comp.lang.cobol on Thu Mar 30 21:36:44 2017
    From Newsgroup: comp.lang.cobol

    On 29/03/2017 9:11 p.m., bwtiffin@gmail.com wrote:
    Hello, everyone

    Regina REXX is being built into GnuCOBOL as an Intrinsic Function. It is
    working out quite well, and the potential synergy is bubbling up, just waiting to be discovered.

    This build is currently a side branch of the main GnuCOBOL development tree.
    It will likely be folded into GnuCOBOL proper shortly after the official release of GnuCOBOL 2.2. (We'll be releasing GnuCOBOL 2.0-rc3, officially as GnuCOBOL 2.2 soon).

    Implemented as two functions, rexx() and rexx-restricted() (which turns on
    the Regina RXRESTRICTED feature to disable many of the more dangerous powers of
    REXX when scripts may come from unscreened sources such as end user programs).

    As an intrinsic function the feature allows for code such as

    display rexx-restricted("return 6 * 7")

    ----

    display rexx-restricted("address system 'rm *.important'; return 'No delete,
    restricted script'")

    ----

    01 cobol-field pic x(64).
    move rexx("parse version info; return info") to cobol-field
    display trim(cobol-field)

    ----

    01 answer usage binary-long.
    compute answer = numval(rexx("return 6 * arg(1)", 6)) + 6
    display answer

    ----

    REPLACE ==newline== BY ==& x'0a' &==.
    01 rexx-result pic 9(5).
    move rexx(
    "sum = 0" newline
    "do i = 1 to 10" newline
    " sum = sum + i" newline
    " say sum" newline
    "end" newline
    "return sum + arg(1)", 127)
    to rexx-result
    display rexx-result

    ----

    01 shared-value pic x(6).
    display rexx("a = arg(1); say 'Got: ' a; push a; return 'a pushed'", "abc") move rexx("pull a; return a || 'def'") to shared-value
    display shared-value


    With judicious use of character data concatenation in COBOL, upto 8K of
    script (default configuration) can be passed into rexx() or rexx-restricted().
    Using ADDRESS and CALL, unlimited sized external REXX scripts are also supported by returning the RC, RESULT or SIGL special variables.

    The first argument is the REXX script, followed by up to 32 optional
    arguments passed to REXX as ARG(n) values. The 32 limit can be changed and is dependent on compile time and runtime configurations. The function return field is effectively an any length COBOL character data field (just like other alphanumeric intrinsic functions).

    The beta defines one EXTERNAL data item that provides access to the REXX API
    return code. Currently, as each rexx() invocation is a separate interpreter, shared values between scripts use the push pull features of the internal Regina
    stack.

    Specially crafted COBOL modules, that code to the SAA REXX external function
    API are proven, and there is a rxfuncadd sample in the Intrinsic REXX tips and tricks thread that is accumulating in the GnuCOBOL SourceForge project space. This is where programmable COBOL applications start to shine through. A GCI sample should be posted shortly, making it even easier to expose COBOL programs
    to REXX scripting potentials. (This is almost completely under developer control, as rexx() can be used to define the function entry points and end users can then be provided with rexx-restricted() scripting access, either externally or from within compiled COBOL applications). I say "almost" as the reality is, if you have an admin with access to your executable, they have to be trusted individuals anyway and this feature exposes no risk beyond what is already inherent when running systems.

    https://sourceforge.net/p/open-cobol/discussion/cobol/thread/2b41632f/

    Design and development notes are being discussed in a Contributions thread at

    https://sourceforge.net/p/open-cobol/discussion/contrib/thread/c31cd4d6/

    SVN repository with download instructions at

    https://sourceforge.net/p/open-cobol/code/HEAD/tree/branches/gnu-cobol-builtin-script/

    This will soon be part of the mainline GnuCOBOL release tarball/zip file, but
    for now is still in a branch of the source repository and will require building
    from source using ./configure --with-rexx for GnuCOBOL and a working installation of Regina REXX.

    Leverage REXX directly from COBOL source, and provide easy access to COBOL
    modules for end user scripting.

    This is all free software, with GNU LGPL COBOL runtime and Regina REXX
    licensed under the GNU LGPL as well.

    If you try it, feel free to drop questions and opinions in the GnuCOBOL
    discussion groups on SourceForge. Documentation will be accumulating in the GnuCOBOL FAQ at

    https://open-cobol.sourceforge.io/faq/index.html#intrinsic-rexx

    This announcement is being posted to both comp.lang.rexx and comp.lang.cobol.

    Have good, make well,
    Brian

    Hi Brian,

    You have been busy... :-)

    I remember using REXX 30 years ago on mainframes and it was generally
    used as a replacement for JCL. Looking at your samples, it appears to
    have come a long way...

    Is there ANY chance at all that GnuCOBOL will be supporting OO COBOL
    and/or Component Object Model (COM) interface, at ANY time in the future?

    Cheers,

    Pete.

    --
    I used to write COBOL; now I can do anything...

    SEEN-BY: 154/30 2320/100 0 1 227/0
  • From bwtiffin@1:2320/100 to comp.lang.cobol on Thu Mar 30 03:08:30 2017
    From Newsgroup: comp.lang.cobol



    Is there ANY chance at all that GnuCOBOL will be supporting OO COBOL
    and/or Component Object Model (COM) interface, at ANY time in the future?

    Cheers,

    Pete.

    --
    I used to write COBOL; now I can do anything...
    I'm going to go out on the limb and say Yes, Peter, there is a high non-zero chance that GnuCOBOL will support Object COBOL someday. We are on GnuCOBOL 2.0-rc3, expecting Simon to sign off on a GnuCOBOL 2.2 release tarball shortly.
    After that, we merge in Ron's ReportWriter branch for GnuCOBOL 3.0. (That will have a much shorter release timeline. It's been in the soak for years already).
    After that, bored compiler writers will be looking for things to do. Edward is
    getting very good at implementing to Spec. ANY LENGTH items in WORKING-STORAGE
    will likely be one of the first things in 3.0/3.1, and then it'll be a race to see what features are implemented next. XML is high on the list, but some pressure can be put in to start implementing Object COBOL. Sergey is back in the game, and his C++ branch has been getting updates. The C++ codegen should make short work of supporting CLASS-ID, INTERFACE-ID and METHOD-ID subprograms,
    along with FACTORY and OBJECT paragraphs in the IDENTIFICATION DIVISION. Sergey's ESQL preprocessor has been getting some very good press from developers looking to target PostgreSQL, as the datatype support is pretty much
    a one to one correspondence. The ODBC style also means most SQL engines are supported (though I usually laze out and use SQLite when coding up samples for people to learn from on the GNU/Linux side of things).
    So, yeah, I can't really speak to timelines, but I'm going out on the limb and saying that Yes, GnuCOBOL will support Object COBOL someday. Probably well before the epoch rollover of 2038. :-)
    In the meanwhile, I have a few samples linking to Scala via Java/JNA (under 30 lines of PROCEDURE division) so we are already getting some practice with Objects in GnuCOBOL space, albeit indirectly.
    On the topic of this thread. Just wrote a few samples that have COBOL calling REXX calling a SNOBOL4 compile pass, capturing results in a REXX stem and passing the data back to COBOL. That led to trying:
    COBOL -> REXX -> cobc compile from stdin (REXX stem data) -> that COBOL calling
    REXX, passing data back to COBOL -> captured in a REXX stem -> result passed back to the original compiled COBOL program.
    21 lines of PROCEDURE DIVISION for that entire sequence.
    Details in the tips and tricks thread on the forge, mentioned above, linked at https://sourceforge.net/p/open-cobol/discussion/cobol/thread/2b41632f/?limit=25&page=1#7bf8
    Intrinsic REXX adds a lot of power to COBOL processing. The reason REXX was picked as the first (soon to be project official) extension language for GnuCOBOL (versus other candidates like Tcl, Lua, MRuby, and Guile) is that REXX
    uses decimal arithmetic. Fractional script results are identical to default COBOL ROUNDED MODE IS NEAREST-AWAY-FROM-ZERO, and that should really help keeping to the principal of least astonishment once non-technical program operators start flinging scripts around.
    ooRexx will be a very nice option for the C++ codegen branch, which I plan on pestering Sergey about, shortly. The REXX SAA API is identical to that provided by Regina, which is sweet. Both are already proven, along with a fair
    pile of ooRexx samples to demonstrate, but Classic REXX seemed to be a better match for C mode GnuCOBOL as the first one out of the chute.
    Have good, make well

    SEEN-BY: 154/30 2320/100 0 1 227/0
  • From pete dashwood@1:2320/100 to comp.lang.cobol on Sat Apr 1 19:10:03 2017
    From Newsgroup: comp.lang.cobol

    On 30/03/2017 11:08 p.m., bwtiffin@gmail.com wrote:


    Is there ANY chance at all that GnuCOBOL will be supporting OO COBOL
    and/or Component Object Model (COM) interface, at ANY time in the future?

    Cheers,

    Pete.

    --
    I used to write COBOL; now I can do anything...

    I'm going to go out on the limb and say Yes, Peter, there is a high non-zero
    chance that GnuCOBOL will support Object COBOL someday.

    <snipped>

    What you (and the people you are working with) have done and are doing
    is very impressive, Brian.

    Thanks for the response.

    Pete.
    --
    I used to write COBOL; now I can do anything...

    SEEN-BY: 154/30 2320/100 0 1 227/0
  • From bwtiffin@1:2320/100 to comp.lang.cobol on Sat Apr 22 22:42:57 2017
    From Newsgroup: comp.lang.cobol

    On Wednesday, March 29, 2017 at 4:11:30 AM UTC-4, bwti...@gmail.com wrote:
    Hello, everyone

    Regina REXX is being built into GnuCOBOL as an Intrinsic Function. It is
    working out quite well, and the potential synergy is bubbling up, just waiting to be discovered.


    Recently updated the gnu-cobol-builtin-script branch.

    rexx(script, args...) now defaults to a safer RESTRICTED mode. rexx-restricted() has been dropped, and rexx-unrestricted() can be used when the full REXX feature set is required.

    Restricted mode Regina disables:

    - LINEOUT, CHAROUT, POPEN, RXFUNCADD BIFs
    - "OPEN WRITE", "OPEN BOTH" subcommands of STREAM BIF
    - The "built-in" environments eg. SYSTEM, CMD or PATH of ADDRESS command
    - Setting the value of a variable in the external environment with VALUE BIF.
    - Calling external functions

    This is a proactive "better safe than sorry" change during the alpha release phase. It makes full REXX features an explicit intent when adding scripts, instead of the reverse.

    The alpha release is nearing completion, should be announcing some stable beta commits soon.

    GnuCOBOL 2.2 edges closer to final, and as soon as that pistol fires, I'll merge the REXX scripting code into the lead branch, (plus as a teaser, which will be mentioned in another thread, Python scripting was just committed to the
    same branch).

    Have good, make well,
    Brian

    SEEN-BY: 154/30 2320/100 0 1 227/0