OS2 World Community Forum

OS/2, eCS & ArcaOS - Technical => Applications => Topic started by: Martin Iturbide on September 29, 2014, 04:38:53 pm

Title: Regina REXX vs. OS/2 REXX
Post by: Martin Iturbide on September 29, 2014, 04:38:53 pm
Hi

I have not much idea about this topic, so I wanted to ask you feedback to brainstorm this idea.

Since OS/2 REXX interpreter/libraries are close source, how do you see the possibility to replace OS/2 REXX library included in eCS-Warp4.52 with the open source Regina REXX (as an experiment, I'm not requesting/demanding to do it at your home).

- Do you think it may be something that can be done?
- What is the experience on running Regina REXX OS/2 port on this platform?.
- Is something else that OS/2 REXX has that Regina is missing?
- What can get broken on OS/2 replacing REXX with Regina REXX?

Just go ahead and  give your thoughts on  this idea.

Regards.
Title: Re: Regina REXX vs. OS/2 REXX
Post by: Andy Willis on September 29, 2014, 07:32:13 pm
Regina REXX is a Classic REXX not Object REXX... I can't speak to the compatibility nor if it has the integration that it has.  If Open Object REXX were ported and replaced Object REXX then Regina REXX might be able to be used in place of Classic REXX. 
Title: Re: Regina REXX vs. OS/2 REXX
Post by: Andreas Schnellbacher on September 29, 2014, 10:25:39 pm
Executing scripts that are written for OS/2 REXX requires adaption to behave the same in both OS/2 and Regina REXX in many cases.

Therefore the question: What do you want to achieve with replacing the interpreter? The interpreter works already well. What needs to be extended is the amount of REXX libs. In other words: I don't think we need Regina REXX on OS/2.

Far away is porting Open Object REXX to OS/2.
Title: Re: Regina REXX vs. OS/2 REXX
Post by: Martin Iturbide on September 29, 2014, 10:39:33 pm
Hi Andreas.

I'm just being curious about this. I came up with this topics because I try to find replacements for OS/2 close source components. Just save to me the "If it is not broken, don't fix it",  I'm just brainstorming about this and not forcing anybody to replace REXX.  I personally think that we need to start thinking/moving on replacing the OS/2 close source components, because when it gets broken, we will not be able to fix it because we don't have the source code.

So for the moment I have:
1) All the OS/2 REXX scripts should need to be adapted for Regina.
2) Every app in "Object REXX" will fail running over Regina. Plus we don't have "Open Object Rexx" ported.

Anyone had tried Regina REXX deeper on OS/2-eCS platform?

Regards
Title: Re: Regina REXX vs. OS/2 REXX
Post by: Andreas Schnellbacher on September 29, 2014, 11:17:59 pm
So for the moment I have:
1) All the OS/2 REXX scripts should need to be adapted for Regina.
It's more likely someone will create a special OS/2 compatible mode for Regina than people change every REXX script. Trying to add 100 % compatibility is a must for system components like that. Faced with compatibility, we should rather fix the root of issues, if at all.

2) Every app in "Object REXX" will fail running over Regina. Plus we don't have "Open Object Rexx" ported.
Porting Open Object REXX, including the GUI designing components, would be very welcome for many users. Others are more interested in having the usability of modern languages on OS/2 improved.

Maybe it's more useful to integrate newer languages in the system like REXX is now? (REXX has many disadvantages compared with them.) Python would be a good candidate for replacing the functionality of REXX on a modern OS/2.

With staying at Classic REXX we are isolated from users of other systems. Sooner or later Classic REXX will die. Making Open Object REXX (with its GUI extensions) available could help, as well as integrating another language into the system.
Title: Re: Regina REXX vs. OS/2 REXX
Post by: Martin Iturbide on September 30, 2014, 07:46:37 pm
Maybe it's more useful to integrate newer languages in the system like REXX is now? (REXX has many disadvantages compared with them.) Python would be a good candidate for replacing the functionality of REXX on a modern OS/2.

That is an interesting approach. Maybe it will be more interesting to put the efforts on Python instead of worrying about the old REXX. 

But when I get time I want to give it a try on Regina.  I'm not a REXX script hobbyist, but maybe one day I will give it a try to test the REXX scripts I stored here (https://github.com/OS2World/CMD-Scripts) and give them a try with Regina. 
Title: Re: Regina REXX vs. OS/2 REXX
Post by: Dave Yeo on October 01, 2014, 02:36:07 am
It's funny, yesterday in a different forum, I saw someone wishing for Rexx, as he called it the OS/2 scripting language.
The beauty of Rexx is it was designed for non-programmers and is also one of the best languages for adding a macro language to other apps. Python fails if you just indent wrong though many consider it a good choice for beginners.
Title: Re: Regina REXX vs. OS/2 REXX
Post by: Fahrvenugen on October 01, 2014, 03:05:12 am
I do lots of stuff in classic REXX.  Admittedly on OS/2 I use the built-in REXX support, it just plain works.

I've used Regina quite a bit on both Linux and Windows.  I've found that in general all the REXX stuff that I've developed on OS/2 works fine on Regina in either Linux or Windows (sometimes with very minor modifications).  The only things which don't work are times when I've tied into some specific part of OS/2 or if I've done a quick hard-code of a drive folder / path into the code itself (I generally try and avoid this, but sometimes just to quickly get something up and running to test a concept out I'll do this).  I admit I'm not doing anything hugely complex, usually the projects I put together are either things that I just need to be done for some particular purpose and / or the "commercial software" which will do the same thing costs lots of money.  Sure, I could do any of the same projects in something like Python or PHP, but I've found that I can usually achieve the same end result a lot quicker in REXX.

What I like about REXX is that while it may not be considered the most modern language, for many projects I find it to be one of the quickest languages (at least for me) to go from a concept or idea to having actual working proof of concept code.  And then it is equally quick to take that code, finish development of the project, easily debug, put into production, and run the same code unmodified on multiple platforms (Linux and / or Windows) - even if it was developed on OS/2.

The one thing that I have found - when I talk to other people in the IT world that I know, I'm one of the only ones who knows much of anything about REXX - regardless of whether it is Classic or Object REXX.  I know lots of developers who will turn to Python or PHP to do do things that I would normally do in REXX. 

Keep in mind that one of the original design goals for REXX was to be a  common language that could be used across the varying range of incompatible models of mainframe computers that IBM had on the market.  That design goal led to REXX code being extremely portable while being able to handle both simple and more complex tasks.

As for something like Python - I have no problem with having Python on OS/2, however I'd point out that Python is ported to OS/2.  There's a couple of older versions on Hobbes. Paul Smedley has also ported Python (along with his port of PHP) available on his site too.

Regina on OS/2 - I admit I've never actually tried it.  When I'm working on OS/2 I just use the built-in REXX support. 
Title: Re: Regina REXX vs. OS/2 REXX
Post by: Andreas Schnellbacher on October 01, 2014, 11:22:06 pm
I'd point out that Python is ported to OS/2.
Sure. Therefore I wrote about adding the functionality of REXX on OS/2 to Python.

The advantage of most REXX libs is that they were specially written for REXX. Compared with C libs a REXX lib contains much less functions that are as easy to use as possible. Other langs on other OS have just the feature added to use standard C libs. That is better then nothing, but not very user-friendly.

The disadvantages are that too few exist and that C libs actually can't be used with REXX. Therefore I  was thinking about using another language as the way to go in the future.
Title: Re: Regina REXX vs. OS/2 REXX
Post by: Martin Iturbide on October 02, 2014, 08:05:22 pm
Thanks for the replies.

What I want to try,  when I finish "OS2World Github" source code upload, is to give it more time to experiment Regina REXX.

Maybe on a VM machine I will test some REXX scripts I collected (https://github.com/OS2World/CMD-Scripts), run them on OS/2 REXX see if they work and after that wipe out (delete) the OS/2 REXX and install Regina and see what breaks.

...just to experiment.  But if anybody wants to give it a try before me, he is welcome.

Regards
Title: Re: Regina REXX vs. OS/2 REXX
Post by: guzzi on October 02, 2014, 09:32:48 pm


Whenever I read your alias here, I mentally add some letters and make it Fahrvergnugen. What's worse, it takes me hours to get rid of Kraftwerks "Autobahn" afterwards....
Title: Re: Regina REXX vs. OS/2 REXX
Post by: Jan-Erik Lärka on October 03, 2014, 01:22:57 pm
I do lots of stuff in classic REXX.  Admittedly on OS/2 I use the built-in REXX support, it just plain works.

...

So true all you wrote.

It's fairly easy to write a REXX extension library that can use C libraries, but someone has to do it.
It's even easier with a String class that can handle and convert from/to numbers and strings.

I dislike Python because of the strict and rigid indention rules.
===

OS/2 REXX is integrated with the os.
Regina is a separate executable.

Regina lack something I've come across and use in Classic REXX under OS/2-eCS.
Code: [Select]
/* "Main" entry of script */
stem.0 = 2
stem.1 = "Hello"
stem.2 = "World"
my_array.0 = 4
my_array.1 = "Say"
my_array.2 = "hi!"
my_array.3 = "to"
my_array.4 = "everyone"
my_variable = "Some text"
dont_expand_variable = "Exposed variable"
expand_variable = "stem. my_array. my_variable"
dont_expand_variable = "Hello!"
RETURN rexx_function_name()

/* Function below */
rexx_function_name PROCEDURE EXPOSE (expand_variable) dont_expand_variable
SAY expand_variable
SAY dont_expand_variable
DO i = 1 TO WORDS( expand_variable )
  check_variable = SUBWORD( expand_variable, i, 1 )
  IF RIGHT( check_variable, 1 ) = '.' THEN
    /* Assume this is a stem (array of accessible values).*/
    DO j = 1 TO VAL( check_variable'0' )
    /* Will output the text set in "main" */
      SAY VAL( check_variable''j )
    END
END
RETURN 0

The above code work in OS/2 Classic REXX and output "stem. my_array. my_variable" AND you can access the contents of stem.0 , stem.1, ... stem.N and my_array.0, my_array.1 ... my_array.N and my_variable just as with "dont_exand_variable" that will output the text "Exposed variable".

The same goes for parsing...
In OS/2 Classic REXX you can
...
/* Example code for PARSE below */
delimiter = "/"
text_2_parse "this is an example of text/code to split on the character with / into smaller parts."
DO WHILE POS( delimiter, text_2_parse ) > 0
  PARSE text_2_parse WITH pre(delimiter)test_2_parse
  SAY pre
END
SAY test_2_parse
/* end of example */
Would output:
this is an example of text
code to split on the character with
 into smaller parts.
======
ADDRESS in Regina is something I like that is very powerful.
Title: Re: Regina REXX vs. OS/2 REXX
Post by: xynixme on January 19, 2017, 11:25:48 am
The cross-platform Regina may be virtually closed-sourced and dead too, because of the competition of Open Object Rexx.

There won't be a single answer. My preferred order: 1. Regina, mainly because of an ANSI Date() built-in function with more than one argument, and the improved syntax checking. That's why I'm using IBM's Object Rexx too. 2. A stable old version of Open Object Rexx, version 3.2ísh, same reasons as Regina and it may be easier to port than even more Windowsified versions. 3. An up-to-date version of Open Object Rexx, albeit it's extremely unlikely that I'll need an easy language covered by yet another version of more complex object-oriented code, so I'll use it the same way as both #1 and #2. To execute ANSI Classic Rexx code.

If Regina can execute about as many Rexx apps as IBM's Object Rexx, then one may experience new problems, but the status will be about the same. Use it, and SWITCHRX back if you need your second choice to execute a specific app. IBM's Object Rexx won't execute all Classic Rexx code, so why should Regina be able to execute all Classic Rexx code?
Title: Re: Regina REXX vs. OS/2 REXX
Post by: Jan-Erik Lärka on January 23, 2017, 12:14:57 pm
You can download regina (3.9.2) from rexx.org and compile to whatever platform you like.
I use OpenWatcom btw but not in OS/2.
It's even possible to translate it to various languages.

We want IBM to release the OS/2 specific code (WPS/SOM support etc.) so we can compile it and Open Object REXX and get up to date.

//Jan-Erik
Title: Re: Regina REXX vs. OS/2 REXX
Post by: xynixme on January 23, 2017, 05:00:33 pm
You can download regina (3.9.2) from rexx.org and compile to whatever platform you like.
I use OpenWatcom btw but not in OS/2.

So then the last compiled version appears to be 2015's 3.9.1. I'm not expecting weekly updates of probably the best Rexx interpreter, but last time I checked it was stated that it was "dead". Not a quote, but "dead" instead of dead. New developments weren't that likely, due to (the not that open) Open Object Rexx.

It's even possible to translate it to various languages.

If one wants to embed it in OS/2, then perhaps it has to be translated twice. IBM used specific words, and translating the words "desktop", "file mask characters" or "shadow" will most likely result in at least one wrong or unusual, popular translation if IBM's words aren't used.

We want IBM to release the OS/2 specific code (WPS/SOM support etc.) so we can compile it and Open Object REXX and get up to date.

nice-to-have.~be~would~product~the~of~rating~best~My~interpreter.~Rexx~Classic~any~with~Watcom's,~like~GUI,
existing~any~use~to~able~be~should~you~OS/2~With~GUI.~a~use~to~code~copied~I've~because~only~but~once,
Windows~for~code~Rexx~Object~IBM~written~have~I~effort.~extraordinary~an~worth~isn't~it~guess~I~but~Rexx,
Object~Open~want~will~community~small~A~files.~*.BAT~object-oriented~need~don't~I~like~just~code,
Rexx/2~Object~used~never~I've~coding.~OO~for~candidate~a~is~which~code~than~Rexx)~used~having~not~to
excuses~more~seen~probably~I've~here~and~it,~need~doesn't~INSTALL.CMD~an~language,
easy~an~be~to~supposed~It's~interpreter.~object-oriented~up-to-date~an~needs~programmer~Rexx~typical~nor
user~average~the~that~sure~not~I'm :)
Title: Re: Regina REXX vs. OS/2 REXX
Post by: Martin Iturbide on January 23, 2017, 07:59:09 pm
Hi

Just a disconnected, but related post, I was checking the The Rexx Language Association homepage:
http://www.rexxla.org/

They are promoting "The 28th International Rexx Language Symposium will be on April 10th - 12th, 2017, The Netherlands."
It can be interesting for the OS/2 community to do some presence there.

Regards
Title: Re: Regina REXX vs. OS/2 REXX
Post by: xynixme on January 24, 2017, 02:28:26 am
They are promoting "The 28th International Rexx Language Symposium will be on April 10th - 12th, 2017, The Netherlands."
It can be interesting for the OS/2 community to do some presence there.

In or near the home town of both the RexxLA President, Amsterdam, and near whatever's left of Mensys.

RexxLA, with its Open Object Rexx, may be the wrong bet. If you would want to talk to the members about about our Object Rexx, for example to strategically point out that we may be the largest non-mainframe community of Rexx users by far, then there is actually no "topic area of particular interest" which would cover the generic topic of your OS/2 presentation. After such a presentation I'd expect a few nice words and exchanged OS/2 memories, but no meaningful help. They already have got what they wanted, and they have "moved on".

And, again, I'm not sure what the added value of Object Rexx is, in our world of Classic Rexx apps. I'm using the interpreter, despite of a few problems like running out of shared memory or syntax-checking broken legacy software, but only because of the 3 parameters of the Date() built-in function. Regina should support this too. Most object-oriented code will be used to produce a GUI, but we already have such an environment. VisPro/REXX, VX-REXX, and so on. An OO GUI, on top of any Classic Rexx interpreter of the OS. Or, in other words, which existing software requires an Open Object Rexx for OS/2?

If IBM requires a RexxLA to release our source code: fine. Otherwise RexxLA isn't that interested in, for example, Object Rexx/2. RexxLA is n't always excluding OS/2, but a topic like "Novel, clever, or interesting problem solutions using ooRexx or Classic Rexx" does. There is only one Object Rexx interpreter: theirs. No Object Rexx/2, no generic "Object Rexx", and even no IBM Object Rexx for Windows with its IDE. A functional language association should use the name of the language instead of the name of a brand. Their own brand, in this case. RexxLA is not an inclusive association.

I guess I'll survive listening to people using ooRexx and Java to populate their Excel spreadsheets for three days, but it may be more useful to become a member which represents the OS/2 community. It's a small world, so the vote ($24/year) will count. The ooRexx symposium costs $30 (3 days), excluding costs.
Title: Re: Regina REXX vs. OS/2 REXX
Post by: Martin Iturbide on January 24, 2017, 01:08:15 pm
Hi André.

I also need to understand more about Object Rexx to have better idea of RexxLA strategy. The main issue for me will be always be that we have an great Rexx interpreter that does not has a future since it can not evolve because it is close source. (Again, please save me the "If it is not broken, don't fix it" talk, it had already been discussed).

But instead of assuming a possible response as an answer it will be good for the OS/2 community to knock RexxLA door and find out. In general terms I think that the OS/2 community need to get more friends. I mean "community friends" with projects that they goal may not be OS/2, but understand that the OS/2 community uses that software and at some point generate a symbiosis that benefits both sides. Maybe important projects that are complete funded and don't have a "user base issues" may not want more friends, but I think that they are other that will welcome more people.

For example, on some Warpstock Lewis Rosenthal said Arca was involved on the Kerbeos Community (MIT Kerberos Consortium?) since they want it running on OS/2, which I consider positive. We all want the software to be ported to OS/2, that may be the final goal, but it is also important to show the originator that we have it ported and there are is a community of OS/2 people using it.

Regards

Title: Re: Regina REXX vs. OS/2 REXX
Post by: Andreas Schnellbacher on January 24, 2017, 08:56:48 pm
Note that the last IBM version of Object REXX for OS/2 contains so many bugs that one should activate that only temporarily. Esp. as system REXX interpreter, only the Classic REXX is recommendable.

BTW: The for me important changes in the Free Software "Open Object REXX" are all in its compatibility mode, to execute non-OR scripts. They have improved a lot that I miss on OS/2. I'm not sure if I really want to start with the Object REXX syntax. (I think for GUI stuff one has to.)
Title: Re: Regina REXX vs. OS/2 REXX
Post by: nyao on January 25, 2017, 07:35:36 am
I like Classic Rexx and DrDialog.

http://hp.vector.co.jp/authors/VA028575/rexxs.htm
Title: Re: Regina REXX vs. OS/2 REXX
Post by: Sergey Posokhov on January 25, 2017, 03:35:15 pm
I like Classical Rexx but not Object-Oriented.
The future is Functional Programming anyway.
Title: Re: Regina REXX vs. OS/2 REXX
Post by: Martin Iturbide on January 26, 2017, 02:56:35 pm
Hi

Sorry about the ignorance on this subject, but what are the most important OS/2 applications (or non important) that runs using IBM's Object Rexx ? Can you give me some examples?

Regards
Title: Re: Regina REXX vs. OS/2 REXX
Post by: Andreas Schnellbacher on January 26, 2017, 06:06:34 pm
I doubt that there are any. Most likely because the OS/2 version of Object REXX has only alpha/beta status and because of the named incompatibilities.

The most famous incompatibility is probably Chuck's (outdated) eCS Maintenance Tool. With activated Object REXX, it starts only about 3 times before a reboot is required.
Title: Re: Regina REXX vs. OS/2 REXX
Post by: Pete on January 26, 2017, 07:39:59 pm
Hi Martin

The PAF software required Object Rexx to be the active system rexx - possibly 1 reason that PAF was not successful.


Regards

Pete
Title: Re: Regina REXX vs. OS/2 REXX
Post by: xynixme on January 28, 2017, 04:36:27 am
what are the most important OS/2 applications (or non important) that runs using IBM's Object Rexx ? Can you give me some examples?

At last one app, written for my own use. I'm aware of the required interpreter, I know which important apps won't work (GenMAC*.WPI installer) with the Object Rexx interpreter, and I'm not using a single line of object-oriented code.

With IBM Object Rexx for Windows you'd have to use object-oriented code to use a GUI dialog. But with OS/2 the tools, like VisPro/REXX, DrDialog, VX-REXX, and so on, are object-oriented, and you can use such an object-oriented GUI with any Rexx interpreter.

If Regina would be added to SWITCHRX.CMD, then trying it should be easy. You'll notice problems quite quickly. It may be my prefered solution. It should be better than Classic Rexx, I can tell users to SWITCHRX.CMD to use Regina, and it doesn't have the (minor) disadvantages of Object Rexx.

Our priority is integrated Classic Rexx (compatibility). SETUP.CMD files. I won't deny a few people their up-to-date Open Object Rexx interpreter, but I cannot think of any app which desperately requires object-oriented capabilities, and the number of C++ developers is limited.

I'm not sure what the RexxLA has got to help us. People may be aware of OS/2, like the author of Regina, but they don't have the OS/2 source code and sometimes you'll have to explain again that Open Object Rexx (for Windows, typically) isn't the only Object Rexx interpreter.

In general I've looked at Object Rexx apps. There are a few examples, but examples I've seen all were written by Rony Flatscher. He used to support OS/2 for a long while, with his Java-related solutions, but has dropped support for OS/2. IIRC because there were no known users. You may consider his Object Rexx apps to be educative sample apps, and he has "moved on" to Open Object Rexx too.

Unverified Object Rexx software at Hobbes, excluding the interpreter itself, including articles and samples:

http://hobbes.nmsu.edu/download/pub/os2/apps/comm/fax/fxclsv01.zip
http://hobbes.nmsu.edu/download/pub/os2/apps/internet/mail/reader/pmm/lm2pmm.zip
http://hobbes.nmsu.edu/download/pub/os2/apps/internet/www/util/httpget.zip
http://hobbes.nmsu.edu/download/pub/os2/dev/orexx/dallas.zip
http://hobbes.nmsu.edu/download/pub/os2/dev/orexx/dump_cls.zip
http://hobbes.nmsu.edu/download/pub/os2/dev/orexx/orexxsql.zip
http://hobbes.nmsu.edu/download/pub/os2/dev/orexx/orx7.zip
http://hobbes.nmsu.edu/download/pub/os2/dev/orexx/orx8.zip
http://hobbes.nmsu.edu/download/pub/os2/dev/orexx/rxlepsom.zip
http://hobbes.nmsu.edu/download/pub/os2/dev/orexx/sg244586.zip
http://hobbes.nmsu.edu/download/pub/os2/dev/rexx/DrDlgFix.zip
http://hobbes.nmsu.edu/download/pub/os2/dev/rexx/olbox100.zip
http://hobbes.nmsu.edu/download/pub/os2/doc/ExtWPS-Article.zip

Of this list I only have the file DrDlgFix.zip installed. It's a fix related to using the interpreter, but not to using object-oriented code. That's the only example I can give you. The internal example uses Date() with 3 arguments, which is not supported by IBM's old Classic Rexx interpreter.
Title: Re: Regina REXX vs. OS/2 REXX
Post by: xynixme on January 28, 2017, 05:29:13 am
If almost nobody is using Object Rexx/2 code, then almost nobody will report Object Rexx apps.

OTOH, at EDM/2 you can find out how old the OS/2 Classic Rexx-compatibility coding style is. This page (http://www.edm2.com/index.php/REXX_inside_and_out_-_Interpret) does suggest that Microsoft OS/2 0.99b's outdated OS2ENVIRONMENT is the only valid value, and people still are using it.

Code: [Select]
[J:\]rexxtry say value('HOME',,'ENVIRONMENT')
J:\HOME\DEFAULT
  ................................................ REXXTRY.CMD on OS/2

[J:\]
Title: Re: Regina REXX vs. OS/2 REXX
Post by: Dave Yeo on January 28, 2017, 07:25:00 am
How hard would it be to update swtchrx.cmd to support Regina? Perhaps someone could package Regina Rexx including an updated switchrx.cmd.
Title: Re: Regina REXX vs. OS/2 REXX
Post by: xynixme on January 28, 2017, 10:56:43 pm
How hard would it be to update swtchrx.cmd to support Regina? Perhaps someone could package Regina Rexx including an updated switchrx.cmd.

That should be soft. But the equivalent of a x:\OS2\DLL\REXX.DLL, a fully compatible REXXUTIL.DLL (keep using IBM's latest one?) and an INF file will be required. And all other essential Rexx-related files of the OS.

SWITCHRX.CMD basicly just swaps files.

The REXX.DLL (COPY y:\REGINA.DLL x:\OS2\DLL\REXX.DLL) will be required to not having to type "REGINA.EXE SCRIPT.REX -arg1".

The functins RxMessageBox (no RxFuncAdd required) and Sys*(with RxFuncAdd) have to keep working.

Typing "HELP REXX D2C" should result in a relevant fine manual page.

Typing "HELP REX40" should result in a relevant error message and a possible solution.

So at the moment Regina won't fully qualify as one of the replacements. I'm not using Regina because Object Rexx does what I'm looking for, but a quick scan shows that there's no INF (nor HLP) file. Nor a MSG file for "HELP REX40". The list of all required file, to become an OS component, can be found in x:\OS2\SWITCHRX.CMD.

An important advantage of SWITCHRX.CMD is that it's the default way to switch back to a working, different Rexx interpreter. So if some Watcom VX-REXX EXE fails (or a WPI package, or a common Rexx app) , then you don't have to uninstall Regina and restore an IBM Rexx interpreter to be able to execute this EXE. As such SWITCHRX.CMD is a good solution.

Oh, and "REGINA TEST.CMD //t" doesn't tokenize the script and this command executes TEST.CMD. So a tokenized 0 bytes Rexx scripts, also known as a Rexx EXE, may stop working too.

This may answer the original question. If Regina wants to become the third OS/2 Rexx interpreter, then essential functionalities and files will have to be added to Regina for OS/2. Like the INF file, and the argument //t shouldn't execute the code. One may argue that //t was a bad idea, but the expected result now is that the code won't actually be executed. Regina executes the code.
Title: Re: Regina REXX vs. OS/2 REXX
Post by: xynixme on January 28, 2017, 10:58:44 pm
How hard would it be to update swtchrx.cmd to support Regina? Perhaps someone could package Regina Rexx including an updated switchrx.cmd.

That should be soft. But the equivalent of a x:\OS2\DLL\REXX.DLL, a fully compatible REXXUTIL.DLL (keep using IBM's latest one?) and an INF file will be required. Actually all essential files.

SWITCHRX.CMD basicly just swaps files.

The REXX.DLL (COPY y:\REGINA.DLL x:\OS2\DLL\REXX.DLL) will be required to not having to type "REGINA.EXE SCRIPT.REX -arg1".

The functins RxMessageBox (no RxFuncAdd required) and Sys*(with RxFuncAdd) have to keep working.

Typing "HELP REXX D2C" should result in a relevant fine manual page.

Typing "HELP REX40" should result in a relevant error message and a possible solution.

So at the moment Regina won't fully qualify as one of the replacements. I'm not using Regina because Object Rexx does what I'm looking for, but a quick scan shows that there's no INF (nor HLP) file. Nor a MSG file for "HELP REX40". The list of all required file, to become an OS component, can be found in x:\OS2\SWITCHRX.CMD.

An important advantage of SWITCHRX.CMD is that it's the default way to switch back to a working, different Rexx interpreter. So if some Watcom VX-REXX EXE fails (or a WPI package, or a common Rexx app) , then you don't have to uninstall Regina and restore an IBM Rexx interpreter to be able to execute this EXE. As such SWITCHRX.CMD is a good solution.
Title: Re: Regina REXX vs. OS/2 REXX
Post by: Andreas Schnellbacher on January 28, 2017, 11:21:35 pm
No, you need also replace the REXX subcommand functions. Note that REXX is integrated into the OS.
Title: Re: Regina REXX vs. OS/2 REXX
Post by: xynixme on January 28, 2017, 11:31:03 pm
I guess my "And all other essential Rexx-related files of the OS." was a brave attempt to point that out.

According to real programmers embedding it isn't that hard, as such.
Title: Re: Regina REXX vs. OS/2 REXX
Post by: Andreas Schnellbacher on January 28, 2017, 11:41:06 pm
According to real programmers embedding it isn't that hard, as such.
Are you sure that you are not mixing up applying and provision here?
Title: Re: Regina REXX vs. OS/2 REXX
Post by: xynixme on January 28, 2017, 11:54:17 pm
I like Classic Rexx and DrDialog.

In general Object Rexx interpreters execute Classic Rexx code, our leading OS/2 heritage, too. So wanting to use Classic Rexx is not a reason to not use an Object Rexx interpreter. Using Object Rexx code is optional, and using object-oriented code is more likely if there's no history and you'd want to make a blue Microsoft Excel cell blink.

IIRC additional DrDialog files are the earlier DRDLGFIX.ZIP, there's a PDF version of the reference, and the documented third-party files DRCTL014.DLL upto and including DRCTL017.DLL are required by some DrDialog-based apps.
Title: Re: Regina REXX vs. OS/2 REXX
Post by: xynixme on January 28, 2017, 11:56:48 pm
According to real programmers embedding it isn't that hard, as such.
Are you sure that you are not mixing up applying and provision here?

Reported to the moderator.
Title: Re: Regina REXX vs. OS/2 REXX
Post by: Greggory Shaw on January 29, 2017, 02:15:06 am
According to real programmers embedding it isn't that hard, as such.
Are you sure that you are not mixing up applying and provision here?

Reported to the moderator.


You may want to ask the person that you are reporting, to the exact meaning or intent before reporting a post.
Title: Re: Regina REXX vs. OS/2 REXX
Post by: Ian Manners on January 29, 2017, 04:58:56 am
I don't see a problem that warrants reporting a post, to me the reference to 'real programmers' is more inciteful and that came from you but is simply taken as a throw away line :o)

Quote
According to real programmers embedding it isn't that hard, as such.[/quote1]
Title: Re: Regina REXX vs. OS/2 REXX
Post by: xynixme on February 24, 2017, 06:11:15 pm
how do you see the possibility to replace OS/2 REXX library included in eCS-Warp4.52 with the open source Regina REXX

Finally a lack of relevant reactions implies that (1) you'll have to use the open source code to create an own embedded release for OS/2, and (2) you'll have to apply/document a few OS/2-specific changes (including but not limited to dealing with tokenized code, the //T argument, online help, and so on) to release a reasonably seamless version.

The existing open source code can be compiled, unlike OORexx', but it's not as easy as changing the target to a DLL. Step 2 is the hardest one. Without this step, it will not (always) work as expected. If it doesn't work as expected, then experienced users may as well skip step 1, use the existing Regina.EXE for OS/2 instead of one of IBM's REXX.DLLs, and remember the differences.
Title: Re: Regina REXX vs. OS/2 REXX
Post by: Valery Sedletski on February 26, 2017, 06:25:58 am
Hi all. I am working on Regina REXX integration for OS/2 in osFree project. Indeed, the REXX.DLL and REXXAPI.DLL were existed in Regina code, but they were incomplete. Also, we in osFree had our own DLL's as forwarders to REGINA.DLL, so that, you can load REXX.DLL (the interpreter itself) and use it without specifying REGINA.EXE before each script. -- You just run .cmd file and CMD.EXE passes it to REXX interpreter. But there is a problem: CMD.EXE is a 16-bit program, so it uses 16-bit REXX functions in REXX.DLL and REXXAPI.DLL, instead of 32-bit ones. But 16-bit functions were missing, as Regina is a pure 32-bit program. But, using Regina via REXX.DLL/REXXAPI.DLL is working with 32-bit shells like 4OS2. So that, Regina REXX is working with 32-bit programs, but does not work with 16-bit programs. Most notable 16-bit ones are CMD.EXE and WPS (yes, it is, for some reason, using 16-bit functions, not the 32-bit ones). So, if you install our REXX and REXXAPI, WPS won't work too and OS/2 will not start. We extended REXX.DLL and REXXAPI.DLL with some 16-bit functions as wrappers around 32-bit Regina functions, and 32-bit wrappers for CMD.EXE 16-bit subcommand handlers. So, some 16-bit programs began to work. For example, rexxtry.cmd when run in cmd.exe, and executing "CLS" command of CMD.EXE (a 16-bit subcommand handler). But another problem exists. Usually, REXX.DLL is loaded by REXXINIT.DLL, which is, in turn, loaded by PM, and keeps it loaded. REXXINIT.DLL starts thread, which listens a message queue, and  serializes access from applications to REXX.DLL. So, there's another problem: Regina for now works with only one application at one time. So, we can start only one Regina client at one time. So, we need somehow serialize access to regina.dll in rexx.dll. This has to be done, too.

Also, i should note that switchrx.cmd works by swapping different versions of REXX.DLL (the interpreter) and REXXAPI.DLL (the API for extending other programs by REXX). Other DLL's are mostly usable for different interpreters. For example, REXXUTIL from Object REXX can be used with Classic REXX without problems. It has more functions implemented. Also, except for IBM's versions of REXXUTIL, exists WINDOWS version of REXXUTIL (it seems, it is called REGUTIL and is used by Regina too). But we also have two other native OS/2 REXXUTIL versions, with source code available, the one written by Mike Greene and the one supplied with eComstation.

Actually, for switching different REXX interpreters, we can suggest to rename other REXX/REXXAPI versions to CREXX/CREXXAPI and OREXX/OREXXAPI, and RREXX/RREXXAPI and make a wrapper REXX/REXXAPI with a config file, which will specify, which pair of REXX DLL's to use. I also plan to implement this in the future. This will allow to switch different interpreters without a reboot.

Making more 16-bit wrappers for regina.dll entry points will make CMD.EXE and WPS work with Regina. So, we need to finish it too.

I added your notes about missing Regina features to our bugtracker: http://osfree.org/doku/en:issue:list

And yes, to test our Regina REXX version, You'll need to start runworkplace=d:\os2\cmd.exe instead of d:\os2\pmshell.exe in config.sys. This will start cmd.exe instead of WPS. As we know, WPS requires more 16-bit API's implemented, and may use REXX/REXXAPI from multiple threads. So, WPS needs to be disabled. Then you can run a REXX program in cmd.exe. (This is needed temporarily, because many features are unimplemented)
Title: Re: Regina REXX vs. OS/2 REXX
Post by: Martin Iturbide on March 01, 2017, 03:01:45 pm
Valerious, that is a very interesting experiment.

Most notable 16-bit ones are CMD.EXE and WPS (yes, it is, for some reason, using 16-bit functions, not the 32-bit ones). So, if you install our REXX and REXXAPI, WPS won't work too and OS/2 will not start.

I wonder if there can be more details of where exactly is the WPS limitation, or which 16-bit functions it is using (which may be hard to find) that does not allow it to run over Regina. Is it a WPS limitation only or PM and SOM are also involved on this limitation?

Regards
Title: Re: Regina REXX vs. OS/2 REXX
Post by: Valery Sedletski on March 02, 2017, 06:57:44 am
2Martin: I don't know exactly the list of functions, but it can be determined if we'll add a debug log for rexx.dll and rexxapi.dll, so we can see, which functions it calls. The full list of functions in REXX.DLL is here: http://svn.code.sf.net/p/osfree/code/trunk/OS2/REXX/rexx/rexx.h and for REXXAPI.DLL: http://svn.code.sf.net/p/osfree/code/trunk/OS2/REXX/rexxapi/rexxapi.h. Involved here are SOM functions, so that WPS uses REXX for scripting (to register/deregister WPS classes).
Title: Re: Regina REXX vs. OS/2 REXX
Post by: xynixme on March 24, 2017, 03:23:01 am
I added your notes about missing Regina features to our bugtracker: http://osfree.org/doku/en:issue:list

The listed INF documentation is important too indeed, because a package like VX-REXX may use the INF file as "the" Rexx reference. All SWITCHRX.CMD-related files will be somehow relevant.

As mentioned earlier, PM versions like PMREGINA.EXE may have to return PMREXX with Address(). PMREXX itself is broken since a Warp 3 FP, and returns a different string. With CMD.EXE Regina's Address() doesn't return CMD.

I haven't verified the way Regina works, but it may be a new feature to disable syntax checking with an environment variable too. This would allow you to run broken (packed or tokenized) scripts, without having to patch unpatchable (packed or tokenized) scripts. SWITCHRX and Rexx SAA are an alternative for such a feature, but having to use Rexx SAA won't be a goal of a new Rexx interpreter.

Check, I don't have a Regina available at the moment: does RxMessageBox() always work, and without having to RxFuncAdd() it?

A more structured approach will be better For now it was a way to point out why having a working binary is important, an advantage compared with Open Object Rexx for Windows/Linus, but it's not as easy as just appending a REGINA.DLL to SWITCHRX.CMD. Files will be missing, results will be unexpected, and Rexx apps will stop working properly.

At the moment Regina is probably the best cross-platform interpreter of Classic Rexx, so you'ld probably use it as-is in an environment with more than one platform. Then one doesn't need a fully and perfectly embedded Rexx interpreter.