Third sentence of ooRexx abstract shown on sourceforge affirms
It is upwardly compatible with classic REXX and will execute classic REXX programs unchanged.
This is a promise. Now I copied a routine from VM/CMS, timestamp 14. Mai 1993, 16:45:23 -- so I do regard this as "classic REXX" -- and get following error
Is there a idden 'compatibility switch' I've overlooked? Or a list of incompatibilities somewhere what shows what I have to change to make classic REXX "compatible" in the sense of a. m. statement?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Compatibility in general, but not necessarily with platform-specifics.
From z/VM 7.3 REXX/VM Reference:
parse external
PARSE EXTERNAL
This is a subkeyword provided in z/VM. The next string from the terminal
input buffer is parsed. This
queue may contain data that is the result of external asynchronous
events—such as user console
input, or messages. If that queue is empty, a console read results. Note
that this mechanism should
not be used for typical console input, for which PULL is more general, but
rather it could be used for
special applications (such as debugging) when the program stack cannot be
disturbed.
arg_tab_space =
Currently, on VM if you omit expression, the variable is set to the null
string.
However, it is recommended that you explicitly set a variable to the null
string:
symbol=''.
Compatibility in general, but not necessarily with platform-specifics.
Ok, got it -- TY.
With your hint I now remember, the "external" queue was not part of the SAA subset. BTW, in a dated description, z/OS TSO/E REXX User's Guide from 2014, I found
The SAA Procedures Language has been defined as a subset of the REXX language.
Thus, my point of view, ooRexx should run classic REXX programs unchanged, (with classic REXX = REXX as I know it from VM/ESA) is too biased by my background. Maybe "classic REXX" is rather the SAA-subset as it was defined once.
On the other hand, to code symbol= instead of symbol='' is bad habit me think. However it works on z/VM and therefore some did use it. To prevent this bad habit within ooRexx is kind of "reprimand of adult programmers" or "educational measures" -- a quite bad attitude me think ;)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have always disliked the term "classic Rexx" as I believe it is ambiguous. There is the "version" that corresponds to the VM implementation, the TRL2 version, the ANSI standard version and perhaps others. The REXX language has evolved (thank goodness!) since its original implementation and that has necessitated changes which sometimes make programs that ran under an earlier version fail under a newer version. In most cases, small changes to those programs will get them running again. I think that is an acceptable "cost" in order to gain the benefits of the newer version. I know of no case where a change was made that did not have a good justification and the impact it would have on existing programs considered and felt to be minimal.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I claim credit for being the one who coined the term "classic Rexx". I
started using it when we started doing public demonstrations of Object
Rexx. In the context where it was being used, it referred to the version of
Rexx implemented on OS/2, which conformed to the TRL2/SAA definition. The
ANSI standard was still a work in progress at that point.
The OS/2 version did not support PARSE EXTERNAL, did not support assignment
without an expression, also did not support the extra characters in
variable names that the mainframe versions supported.
I have always disliked the term "classic Rexx" as I believe it is
ambiguous. There is the "version" that corresponds to the VM
implementation, the TRL2 version, the ANSI standard version and perhaps
others. The REXX language has evolved (thank goodness!) since its original
implementation and that has necessitated changes which sometimes make
programs that ran under an earlier version fail under a newer version. In
most cases, small changes to those programs will get them running again. I
think that is an acceptable "cost" in order to gain the benefits of the
newer version. I know of no case where a change was made that did not have
a good justification and the impact it would have on existing programs
considered and felt to be minimal.
I claim credit for being the one who coined the term "classic Rexx". I
started using it when we started doing public demonstrations of Object
Rexx. In the context where it was being used, it referred to the version of
Rexx implemented on OS/2, which conformed to the TRL2/SAA definition. The
ANSI standard was still a work in progress at that point.
The OS/2 version did not support PARSE EXTERNAL, did not support
assignment without an expression, also did not support the extra characters
in variable names that the mainframe versions supported.
I have always disliked the term "classic Rexx" as I believe it is
ambiguous. There is the "version" that corresponds to the VM
implementation, the TRL2 version, the ANSI standard version and perhaps
others. The REXX language has evolved (thank goodness!) since its original
implementation and that has necessitated changes which sometimes make
programs that ran under an earlier version fail under a newer version. In
most cases, small changes to those programs will get them running again. I
think that is an acceptable "cost" in order to gain the benefits of the
newer version. I know of no case where a change was made that did not have
a good justification and the impact it would have on existing programs
considered and felt to be minimal.
I have always disliked the term "classic Rexx" as I believe it is ambiguous.
IMO the term is foremost an advertising slogan and -- admittedly -- it worked for me who "grew up" with VM/CMS. But now I found a "Classic Rexx Functions Reference" which covers ANSI-1996, TRL-2, z/OS, and z/VM Rexx. That's it :) A link to it from this tempting offer from ooRexx
It is upwardly compatible with classic REXX and will execute classic REXX programs unchanged.
would silence my protesting at once.
The REXX language has evolved [...] programs that ran under an earlier version fail under a newer version.
One of IBM's principles is/was (concerning mainframe software) to protect customers investigations. Thus old programs ran on new machines, even no need to compile and bind it on the new iron. Kind of "wertkonservativ", about: value-conserving.
Regarding REXX, are there changes since 1st edition which inhibit running "1st edition REXX routines" under TRL-2? ...oops, argumentation failed, already the 3rd change listed in appendix C of TRL-2 may force to update elder programs.
Nonetheless, what about INDEX? Help file on z/VM contains the hint "POS is prefered", while "classic REXX" dropped it, a very small stumbling block but while migrating a routine an additional time requirement that makes me darn.
In most cases, small changes to those programs will get them running again.
"Lucky" as I am, what I try at the moment does not belong to those "most cases". Few days ago I got to know about THE that it mimics XEDIT to a PC. Thus I'd like to migrate "XEDIT Column Editing/VM" to THE. It took me hours to "correct" all deviations from "classic REXX" (honestly, my mistake, using Pipeing it would have been a cakewalk to change all those var= to var="") just to find out then that few details of XEDIT lack in THE.
I know of no case where a change was made that did not have a good justification and the impact it would have on existing programs considered and felt to be minimal.
No comment.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Third sentence of ooRexx abstract shown on sourceforge affirms
This is a promise. Now I copied a routine from VM/CMS, timestamp 14. Mai 1993, 16:45:23 -- so I do regard this as "classic REXX" -- and get following error
Is there a idden 'compatibility switch' I've overlooked? Or a list of incompatibilities somewhere what shows what I have to change to make classic REXX "compatible" in the sense of a. m. statement?
One more incompatibility
Frustrating.
Compatibility in general, but not necessarily with platform-specifics.
From z/VM 7.3 REXX/VM Reference:
parse external
PARSE EXTERNAL
This is a subkeyword provided in z/VM. The next string from the terminal
input buffer is parsed. This
queue may contain data that is the result of external asynchronous
events—such as user console
input, or messages. If that queue is empty, a console read results. Note
that this mechanism should
not be used for typical console input, for which PULL is more general, but
rather it could be used for
special applications (such as debugging) when the program stack cannot be
disturbed.
arg_tab_space =
Currently, on VM if you omit expression, the variable is set to the null
string.
However, it is recommended that you explicitly set a variable to the null
string:
symbol=''.
Ok, got it -- TY.
With your hint I now remember, the "external" queue was not part of the SAA subset. BTW, in a dated description, z/OS TSO/E REXX User's Guide from 2014, I found
Thus, my point of view, ooRexx should run classic REXX programs unchanged, (with classic REXX = REXX as I know it from VM/ESA) is too biased by my background. Maybe "classic REXX" is rather the SAA-subset as it was defined once.
On the other hand, to code
symbol=instead ofsymbol=''is bad habit me think. However it works on z/VM and therefore some did use it. To prevent this bad habit within ooRexx is kind of "reprimand of adult programmers" or "educational measures" -- a quite bad attitude me think ;)I have always disliked the term "classic Rexx" as I believe it is ambiguous. There is the "version" that corresponds to the VM implementation, the TRL2 version, the ANSI standard version and perhaps others. The REXX language has evolved (thank goodness!) since its original implementation and that has necessitated changes which sometimes make programs that ran under an earlier version fail under a newer version. In most cases, small changes to those programs will get them running again. I think that is an acceptable "cost" in order to gain the benefits of the newer version. I know of no case where a change was made that did not have a good justification and the impact it would have on existing programs considered and felt to be minimal.
I claim credit for being the one who coined the term "classic Rexx". I
started using it when we started doing public demonstrations of Object
Rexx. In the context where it was being used, it referred to the version of
Rexx implemented on OS/2, which conformed to the TRL2/SAA definition. The
ANSI standard was still a work in progress at that point.
The OS/2 version did not support PARSE EXTERNAL, did not support assignment
without an expression, also did not support the extra characters in
variable names that the mainframe versions supported.
Rick
On Tue, Jun 17, 2025 at 2:21 PM Gil Barmwater orange-e@users.sourceforge.net wrote:
I should also add that I called it "REXX Classic", not "Classic REXX"!
Rick
On Tue, Jun 17, 2025 at 2:27 PM Rick McGuire object.rexx@gmail.com wrote:
TY for this clarification. Reminds me one scene within 'Life of Brian'.
The term is excellent for advertisement me think. But it's perfect with this unambiguous specification.
IMO the term is foremost an advertising slogan and -- admittedly -- it worked for me who "grew up" with VM/CMS. But now I found a "Classic Rexx Functions Reference" which covers ANSI-1996, TRL-2, z/OS, and z/VM Rexx. That's it :) A link to it from this tempting offer from ooRexx
would silence my protesting at once.
One of IBM's principles is/was (concerning mainframe software) to protect customers investigations. Thus old programs ran on new machines, even no need to compile and bind it on the new iron. Kind of "wertkonservativ", about: value-conserving.
Regarding REXX, are there changes since 1st edition which inhibit running "1st edition REXX routines" under TRL-2? ...oops, argumentation failed, already the 3rd change listed in appendix C of TRL-2 may force to update elder programs.
Nonetheless, what about
INDEX? Help file on z/VM contains the hint "POSis prefered", while "classic REXX" dropped it, a very small stumbling block but while migrating a routine an additional time requirement that makes me darn."Lucky" as I am, what I try at the moment does not belong to those "most cases". Few days ago I got to know about THE that it mimics XEDIT to a PC. Thus I'd like to migrate "XEDIT Column Editing/VM" to THE. It took me hours to "correct" all deviations from "classic REXX" (honestly, my mistake, using Pipeing it would have been a cakewalk to change all those
var=tovar="") just to find out then that few details of XEDIT lack in THE.No comment.