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