• Want to migrate from Regina to ooRexx

    From Arthur T.@21:1/5 to All on Sun Dec 10 19:14:22 2017
    There is functionality in ooRexx that I'd like to make use of.
    But it's not exactly a superset, because some things don't work quite
    the same in ooRexx as they do in Regina.

    Has someone compiled a list of "gotchas" I'd hit when migrating?
    I have hundreds of programs, and I'd want to make mass changes rather
    than find each problem individually.

    I'm not looking for all the things oo can do that Regina can't.
    I'd just like to see what oo does differently and what Regina (with
    all the BIFFs enabled) does that would have to be rewritten for oo.

    I can't remember what gotcha I found on my own, but it was
    sufficiently pervasive in my programs that I put off migrating. That
    was some years ago, and it's time for me to reconsider.

    --
    Arthur T. - ar23hur "at" pobox "dot" com

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gil Barmwater@21:1/5 to Arthur T. on Tue Dec 12 14:21:53 2017
    On 12/10/2017 7:14 PM, Arthur T. wrote:
    There is functionality in ooRexx that I'd like to make use of.
    But it's not exactly a superset, because some things don't work quite
    the same in ooRexx as they do in Regina.

    Has someone compiled a list of "gotchas" I'd hit when migrating?
    I have hundreds of programs, and I'd want to make mass changes rather
    than find each problem individually.

    I'm not looking for all the things oo can do that Regina can't.
    I'd just like to see what oo does differently and what Regina (with
    all the BIFFs enabled) does that would have to be rewritten for oo.

    I can't remember what gotcha I found on my own, but it was
    sufficiently pervasive in my programs that I put off migrating. That
    was some years ago, and it's time for me to reconsider.

    I remember several of our folks having done a comparison and I'm
    surprised one of them hasn't already replied here. If you don't see a
    response soon, you might want to ask over on the RexxLA Forum - http://www.rexxla.org/forum.html

    The big difference, in my opinion, is the conformance of ooRexx to TRL2
    as far as what are valid characters for symbols. That means no @, #, or
    $ (or cent-sign of pound-sterling). But there are a few other things as
    well.


    --
    Gil Barmwater

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Glenn Knickerbocker@21:1/5 to Arthur T. on Tue Dec 19 17:24:47 2017
    On Sun, 10 Dec 2017 19:14:22 -0500, Arthur T. wrote:
    Has someone compiled a list of "gotchas" I'd hit when migrating?

    Back in 2012 in message <Z9KdnUeXgrAIcb7NnZ2dnUVZ_tOdnZ2d@bestweb.net> I
    wrote:

    [There's just] one substantial incompatibility: When a stem is
    assigned to another stem, in Object Rexx the entire stem object is
    assigned rather than just the default value. To make your code
    compatible, you need to put the value being assigned into an expression
    that will cause it to be evaluated as a string. The simplest way is to concatenate it with the null string:

    x. = y.'' /* x. = y. would assign the stem object in Object Rexx */
    z. = f(x)'' /* f(x) *might* return a stem object in Object Rexx */

    The one other incompatibility you might run into, depending on what Rexx version you've been using, is the line comment syntax. ooRexx takes
    "--" and anything following it as a comment. If you build expressions
    for INTERPRET and need to allow for subtracting negative numbers, you'll
    have to be sure to pad your minus signs with blanks:

    Say 2 - - 2 /* says 4 */
    Say 2--2 /* says 2 in ooRexx */

    R

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mark Hessling@21:1/5 to Glenn Knickerbocker on Wed Dec 20 01:42:08 2017
    On Tue, 19 Dec 2017 17:24:47 -0500, Glenn Knickerbocker wrote:

    On Sun, 10 Dec 2017 19:14:22 -0500, Arthur T. wrote:
    Has someone compiled a list of "gotchas" I'd hit when migrating?

    Back in 2012 in message <Z9KdnUeXgrAIcb7NnZ2dnUVZ_tOdnZ2d@bestweb.net> I wrote:

    [There's just] one substantial incompatibility: When a stem is assigned
    to another stem, in Object Rexx the entire stem object is assigned
    rather than just the default value. To make your code compatible, you
    need to put the value being assigned into an expression that will cause
    it to be evaluated as a string. The simplest way is to concatenate it
    with the null string:

    x. = y.'' /* x. = y. would assign the stem object in Object Rexx */
    z. = f(x)'' /* f(x) *might* return a stem object in Object Rexx */

    The one other incompatibility you might run into, depending on what Rexx version you've been using, is the line comment syntax. ooRexx takes
    "--" and anything following it as a comment. If you build expressions
    for INTERPRET and need to allow for subtracting negative numbers, you'll
    have to be sure to pad your minus signs with blanks:

    Say 2 - - 2 /* says 4 */
    Say 2--2 /* says 2 in ooRexx */

    ¬R

    Regina has had -- single line comments for the last few versions. Might
    be time to update!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Arthur T.@21:1/5 to Glenn Knickerbocker on Tue Dec 19 20:15:35 2017
    In Message-ID:<4l3j3dt7kon7lp6cilic3krmrfedns2cfn@4ax.com>,
    Glenn Knickerbocker <NotR@bestweb.net> wrote:

    [There's just] one substantial incompatibility: When a stem is
    assigned to another stem, in Object Rexx the entire stem object is
    assigned rather than just the default value.

    I forget what problem I found, but it wasn't that. I'm now
    wondering if it might have been a difference in (or availability of)
    one of the REGUTIL (REXXUTIL) functions.

    The one other incompatibility you might run into, depending on what Rexx >version you've been using, is the line comment syntax. ooRexx takes
    "--" and anything following it as a comment.

    I was, uh, surprised when that showed up in Regina. I don't
    believe it's a problem for me, though.

    Thanks for digging so far back in your archive for an answer.
    If I find any other differences, I'll be sure to document them in
    this newsgroup; it may help others, and I won't lose the information
    again. But the conversion is nowhere near the top of my to-do list,
    so it could be quite a while.

    --
    Arthur T. - ar23hur "at" pobox "dot" com

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Glenn Knickerbocker@21:1/5 to Arthur T. on Tue Jan 2 23:33:30 2018
    On Tue, 19 Dec 2017 20:15:35 -0500, Arthur T. wrote:
    wondering if it might have been a difference in (or availability of)
    one of the REGUTIL (REXXUTIL) functions.

    That would definitely make sense. My comments were just about the
    language itself.

    Oh, here we go, your message <brgj28tbasscv9vlqddjfr2u8id389aste@4ax.com>
    from the same thread points out the Regina-specific functions in RegUtil:

    Error 43.1: Could not find routine "REGSTEMREAD"

    And, sure enough, the documentation doesn't show any of the
    REGxxx functions.

    I see four more under Stem Manipulation Routines:

    RegMultiStemSort
    RegStemDoOver
    RegStemRead
    RegStemWrite
    RegStemSearch

    I wonder if anyone's gone through and written drop-in replacement ooRexx routines. RegStemRead would be *mostly* replaced by native methods of
    stream and stem objects, something like:

    stem.~putAll(.stream~new(filename)~arrayIn)
    stem.0 = stem.~items

    --though getting the max and min line lengths would be more work.
    RegStemWrite would need code to loop through the numeric indexes; I'd
    probably create an array and then write it all at once with arrayOut. RegStemDoOver would need exposed variables to hold its place; those would sensibly go in the .local directory to avoid any collisions with valid
    Regina variables.

    In the SourceForge forum, I see later discussion of some limitations in SysFileSearch and SysFileTree:

    https://sourceforge.net/p/oorexx/discussion/408478/thread/c2fd1bca/

    I haven't looked up whether and how those have since been addressed.

    R

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Arthur T.@21:1/5 to Glenn Knickerbocker on Wed Jan 3 00:54:59 2018
    In Message-ID:<0ccm4ddn48b65psqul8hnph8o0md82plgo@4ax.com>,
    Glenn Knickerbocker <NotR@bestweb.net> wrote:

    On Tue, 19 Dec 2017 20:15:35 -0500, Arthur T. wrote:
    wondering if it might have been a difference in (or availability of)
    one of the REGUTIL (REXXUTIL) functions.

    That would definitely make sense. My comments were just about the
    language itself.

    Oh, here we go, your message <brgj28tbasscv9vlqddjfr2u8id389aste@4ax.com> >from the same thread points out the Regina-specific functions in RegUtil:

    Wow. You found a 5-year-old message of mine that I had
    forgotten I posted. Thank you. I knew that the differences
    mentioned earlier were not the ones that hit me.

    <snip>
    I see four more under Stem Manipulation Routines:

    RegMultiStemSort
    RegStemDoOver
    RegStemRead
    RegStemWrite
    RegStemSearch

    I wonder if anyone's gone through and written drop-in replacement ooRexx >routines.

    At first I thought I could look at writing external REXX
    programs to perform some of these functions in order to give me
    source-level compatibility. Experiment shows that Regina uses the
    function package routine when there's an external routine of the same
    name.

    But then there's the problem of passing the stems back and
    forth. That might be a problem. If there's a macro capability in
    ooRexx, I might be able to cobble something.

    In the SourceForge forum, I see later discussion of some limitations in >SysFileSearch and SysFileTree:

    https://sourceforge.net/p/oorexx/discussion/408478/thread/c2fd1bca/

    It's late. I will follow that link later.

    --
    Arthur T. - ar23hur "at" pobox "dot" com

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gil Barmwater@21:1/5 to Arthur T. on Wed Jan 3 09:50:02 2018
    On 1/3/2018 12:54 AM, Arthur T. wrote:
    In Message-ID:<0ccm4ddn48b65psqul8hnph8o0md82plgo@4ax.com>,
    Glenn Knickerbocker <NotR@bestweb.net> wrote:

    On Tue, 19 Dec 2017 20:15:35 -0500, Arthur T. wrote:
    wondering if it might have been a difference in (or availability of)
    one of the REGUTIL (REXXUTIL) functions.

    That would definitely make sense. My comments were just about the
    language itself.

    Oh, here we go, your message <brgj28tbasscv9vlqddjfr2u8id389aste@4ax.com> >>from the same thread points out the Regina-specific functions in RegUtil:

    Wow. You found a 5-year-old message of mine that I had
    forgotten I posted. Thank you. I knew that the differences
    mentioned earlier were not the ones that hit me.

    <snip>
    I see four more under Stem Manipulation Routines:

    RegMultiStemSort
    RegStemDoOver
    RegStemRead
    RegStemWrite
    RegStemSearch

    I wonder if anyone's gone through and written drop-in replacement ooRexx
    routines.

    At first I thought I could look at writing external REXX
    programs to perform some of these functions in order to give me
    source-level compatibility. Experiment shows that Regina uses the
    function package routine when there's an external routine of the same
    name.

    But then there's the problem of passing the stems back and
    forth. That might be a problem. If there's a macro capability in
    ooRexx, I might be able to cobble something.

    In the SourceForge forum, I see later discussion of some limitations in
    SysFileSearch and SysFileTree:

    https://sourceforge.net/p/oorexx/discussion/408478/thread/c2fd1bca/

    It's late. I will follow that link later.

    Don't forget that ooRexx has the USE ARG keyword that will allow you to
    pass objects (stems) to a function/subroutine which can then modify
    them. A great addition to Rexx that doesn't directly involve OO concepts.

    --
    Gil Barmwater

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Glenn Knickerbocker@21:1/5 to Gil Barmwater on Wed Jan 3 19:31:57 2018
    On 1/3/2018 9:50 AM, Gil Barmwater wrote:
    Don't forget that ooRexx has the USE ARG keyword that will allow you to
    pass objects (stems) to a function/subroutine which can then modify
    them. A great addition to Rexx that doesn't directly involve OO concepts.

    I was thinking that would make drop-in replacements easy, but then I saw
    the problem: The RegUtil routines are just passed variable *names*, not variable references. As external routines, they wouldn't have access to
    the caller's variables to resolve the references to find the stem
    objects to read and update. And even USE ARG doesn't help any for
    updating string variables in the caller. Since string objects are
    immutable, there's no way for the called routine to update the string
    that the caller's variable points to.

    So the drop-in replacements would have to be (or at least have
    front-end) internal routines copied into every program. And since they
    don't know the variable names until they parse the argument, they can't
    use PROCEDURE EXPOSE to expose just the variables they need, so they'd
    have to reserve space in .local for their own variables.

    Here's a quick pass at one. The local variable names make it look much
    messier than it really is:

    RegStemWrite:
    .local~regUtil.stem = Value(Arg(1))
    .local~regUtil.array = .array~new
    Do .local~regUtil.i = 1 to .regUtil.stem[0]
    .regUtil.array~put(.regUtil.stem[.regUtil.i], .regUtil.i)
    End
    Return .stream~new(Arg(2))~arrayOut(.regUtil.array)

    In this case a stub for an external routine actually wouldn't need any
    local variables:

    RegstemWrite:
    Return 'StemWrite'(Value(Arg(1)), Arg(2))

    The back-end routine would access the caller's stem with USE ARG:

    ::routine StemWrite
    Use Arg stem, filename
    array = .array~new
    Do i = 1 to stem[0]
    .array~put(stem[i], i)
    End
    Return .stream~new(filename)~arrayOut(array)

    Stubs for RegStemRead and RegStemDoOver, though, would need to copy
    strings set or returned by their back-end routines, something like:

    RegStemRead:
    .local~regUtil.rc = 'StemRead'(Value(Arg(1)), Arg(2))
    If Arg(3, 'E') Then Call Value Arg(3), .regUtil.minLen
    If Arg(4, 'E') Then Call Value Arg(4), .regUtil.maxLen
    Return .regUtil.rc

    RegStemDoOver:
    If Arg(3, 'E') Then
    .local~regUtil.rc = 'StemDoOver'(Value(Arg(1)), Value(Arg(3)))
    Else .regUtil.rc = 'StemDoOver'(Value(Arg(1)))
    If .regUtil.rc Then Call Value Arg(2), .regUtil.doIndex
    Return .regUtil.rc

    One thing that's not clear from the doc is whether the stem name may or
    must include the dot for all these routines. In the examples for
    RegStemDoOver it does, but in the example for RegStemSearch it doesn't.

    R

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gil Barmwater@21:1/5 to Glenn Knickerbocker on Thu Jan 4 19:53:40 2018
    On 1/3/2018 7:31 PM, Glenn Knickerbocker wrote:
    On 1/3/2018 9:50 AM, Gil Barmwater wrote:
    Don't forget that ooRexx has the USE ARG keyword that will allow you to
    pass objects (stems) to a function/subroutine which can then modify
    them. A great addition to Rexx that doesn't directly involve OO concepts.

    I was thinking that would make drop-in replacements easy, but then I saw
    the problem: The RegUtil routines are just passed variable *names*, not variable references. As external routines, they wouldn't have access to
    the caller's variables to resolve the references to find the stem
    objects to read and update. And even USE ARG doesn't help any for
    updating string variables in the caller. Since string objects are
    immutable, there's no way for the called routine to update the string
    that the caller's variable points to.

    So the drop-in replacements would have to be (or at least have
    front-end) internal routines copied into every program. And since they
    don't know the variable names until they parse the argument, they can't
    use PROCEDURE EXPOSE to expose just the variables they need, so they'd
    have to reserve space in .local for their own variables.

    Here's a quick pass at one. The local variable names make it look much messier than it really is:

    RegStemWrite:
    .local~regUtil.stem = Value(Arg(1))
    .local~regUtil.array = .array~new
    Do .local~regUtil.i = 1 to .regUtil.stem[0]
    .regUtil.array~put(.regUtil.stem[.regUtil.i], .regUtil.i)
    End
    Return .stream~new(Arg(2))~arrayOut(.regUtil.array)

    In this case a stub for an external routine actually wouldn't need any
    local variables:

    RegstemWrite:
    Return 'StemWrite'(Value(Arg(1)), Arg(2))

    The back-end routine would access the caller's stem with USE ARG:

    ::routine StemWrite
    Use Arg stem, filename
    array = .array~new
    Do i = 1 to stem[0]
    .array~put(stem[i], i)
    End
    Return .stream~new(filename)~arrayOut(array)

    Stubs for RegStemRead and RegStemDoOver, though, would need to copy
    strings set or returned by their back-end routines, something like:

    RegStemRead:
    .local~regUtil.rc = 'StemRead'(Value(Arg(1)), Arg(2))
    If Arg(3, 'E') Then Call Value Arg(3), .regUtil.minLen
    If Arg(4, 'E') Then Call Value Arg(4), .regUtil.maxLen
    Return .regUtil.rc

    RegStemDoOver:
    If Arg(3, 'E') Then
    .local~regUtil.rc = 'StemDoOver'(Value(Arg(1)), Value(Arg(3)))
    Else .regUtil.rc = 'StemDoOver'(Value(Arg(1)))
    If .regUtil.rc Then Call Value Arg(2), .regUtil.doIndex
    Return .regUtil.rc

    One thing that's not clear from the doc is whether the stem name may or
    must include the dot for all these routines. In the examples for RegStemDoOver it does, but in the example for RegStemSearch it doesn't.

    R


    I'm not sure I followed all of that as I'm not a user of RegUtil but I
    sense that you may not be aware that Use Arg even works with external
    routines! The following two bits of code go in separate files; in a
    file called main.rex put

    -- demonstrate USE ARG
    words.1 = 'ALPHA'
    words.2 = 'BRAVO'
    call swap words.
    say words.1
    say words.2

    and in another file called swap.rex put

    -- Subroutine to swap two values in a stem passed by reference
    use arg theStem.
    hold = theStem.1
    theStem.1 = theStem.2
    theStem.2 = hold
    return

    When you run main.rex you will see that the swap.rex routine has indeed modified the contents of the words. stem, even though it is in a
    separate file.

    As to your other point about strings being immutable, that is still the
    case and Use Arg is not a help for that case. Strings inside Arrays or
    Stems or ... CAN however be replaced using this mechanism.


    --
    Gil Barmwater

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Arthur T.@21:1/5 to Gil Barmwater on Fri Jan 5 14:43:27 2018
    In Message-ID:<p2mia8$1og9$1@gioia.aioe.org>,
    Gil Barmwater <gbarmwater@alum.rpi.edu> wrote:

    I'm not sure I followed all of that as I'm not a user of RegUtil but I
    sense that you may not be aware that Use Arg even works with external >routines!

    And that will allow me to continue.

    I'm trying to use the ooRexx executable without having to change
    my existing (Regina) programs. So there's no need for arrays in the subroutine. (I thought there would be, but I also thought there
    would be a non-loop way of reading and writing a file.)

    If I have this code in a file called regstemread.rex, my
    existing code to read works the same if executed by Regina or ooRexx:

    <code>
    use arg filein, stem.

    signal on Notready
    do i = 1
    stem.i = linein(filein)
    end

    Notready:
    stem.0 = i-1
    exit 0

    </code>

    I had code to support min and max line lengths, but I snipped
    it. Not only had I never used it, but testing showed it not to work
    natively. That seems unlikely, so I'll continue testing.

    Obviously I need to put in a lot of error checking, but I now
    see that a solution exists.

    My thanks to all who replied.

    --
    Arthur T. - ar23hur "at" pobox "dot" com

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Glenn Knickerbocker@21:1/5 to Gil Barmwater on Fri Jan 5 14:57:10 2018
    On 1/4/2018 7:53 PM, Gil Barmwater wrote:
    I'm not sure I followed all of that as I'm not a user of RegUtil but I
    sense that you may not be aware that Use Arg even works with external routines!

    On the contrary, the external routines in my examples are exactly where
    I do use USE ARG.

    The problem is in trying to provide drop-in replacement routines so you
    can run the exact same program in Regina and ooRexx without rewriting
    anything. Since Classic Rexx only passes strings to routines, not
    variable references, the arguments to the RegUtil routines only contain
    the *name* of the stem, not the stem itself:

    Call RegStemRead 'STEMNAME.', 'c:\directory\filename'

    ooRexx doesn't give an external routine a way to take that name and turn
    it into a reference to the stem object in the calling program.

    Now, you could impose a coding convention on yourself to write code
    that's compatible: Never set the default value of a stem that will be
    used with RegUtil routines, and always use that default value to pass
    the name of the stem to the routines:

    Call RegStemRead stemname., 'c:\directory\filename'

    Then an ooRexx routine could use USE ARG to update the stem in the
    caller, and in Regina RegUtil would still use the name 'STEMNAME.' to
    find the stem. But that would be an awfully restrictive convention.

    R

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Glenn Knickerbocker@21:1/5 to Arthur T. on Fri Jan 5 15:34:19 2018
    On 1/5/2018 2:43 PM, Arthur T. wrote:
    use arg filein, stem.

    Whoops, how did I get that backwards in all my examples, after referring
    to the doc so many times?

    Anyhow, my main point above is that this will work only when your call
    looks like:

    Call RegStemRead file, stem.

    and not when it looks like:

    Call RegStemRead file, 'STEM.'

    or:

    stemname = 'STEM.'
    Call RegStemRead file, stemname

    This might be more likely to be an issue with RegStemWrite, especially
    if you like to use the default value to fill in sparse stems:

    stem. = ''
    stem.5 = 'something' -- fill in only
    stem.12 = 'another thing' -- a couple values
    stem.0 = 22 -- the other 20 are all left null
    Call RegStemWrite file, 'STEM.' -- this is where USE ARG is no help

    ¬R

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Arthur T.@21:1/5 to Glenn Knickerbocker on Fri Jan 5 19:07:54 2018
    In Message-ID:<p2ong5$le7$1@dont-email.me>,
    Glenn Knickerbocker <NotR@bestweb.net> wrote:

    On 1/5/2018 2:43 PM, Arthur T. wrote:
    use arg filein, stem.

    <snip>
    Anyhow, my main point above is that this will work only when your call
    looks like:

    Call RegStemRead file, stem.

    and not when it looks like:

    Call RegStemRead file, 'STEM.'

    or:

    stemname = 'STEM.'
    Call RegStemRead file, stemname

    Thanks for making that distinction. I don't expect that example
    to affect me, but it's good to know that I have to beware.

    However, I do often pass the filename as a literal. I guess
    I'll need to do a PARSE ARG for the filename and a USE ARG for the
    stemname.

    And, of course, I've got to fully read and grok "use arg".

    --
    Arthur T. - ar23hur "at" pobox "dot" com

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Glenn Knickerbocker@21:1/5 to Arthur T. on Sat Jan 6 00:57:54 2018
    On Fri, 05 Jan 2018 19:07:54 -0500, Arthur T. wrote:
    However, I do often pass the filename as a literal. I guess
    I'll need to do a PARSE ARG for the filename and a USE ARG for the
    stemname.

    Nope! USE ARG is fine for *reading* strings from the caller. It's just
    not any help in *updating* string variables.

    The thing to understand about USE ARG is that it associates a variable in
    the called routine with an object, not a variable, in the caller. If
    that object is a string, it doesn't have any attributes you can change,
    so you can't use it to pass any information back to the caller.
    Assigning a new string value to the variable creates a new object that
    the caller won't know anything about.

    When it's a collection like a stem or an array, though, each member of
    the collection is an attribute that you can set, and then the caller will
    see what you put there.

    Now, if you ponder this hard enough you might worry about what would
    happen if you passed the filename using the default value of a stem:

    file. = 'filename'
    Call RegStemRead file., stem.

    Then USE ARG would get you the whole stem object rather than just the
    default value. But you'd actually still be fine. Anyplace ooRexx
    expects a string, it will request the string value of the object. So linein(filein) won't choke because FILEIN is a stem; it will just use the default value 'filename'.

    R

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Glenn Knickerbocker@21:1/5 to Arthur T. on Sat Jan 6 01:18:19 2018
    On Fri, 05 Jan 2018 14:43:27 -0500, Arthur T. wrote:
    I'm trying to use the ooRexx executable without having to change
    my existing (Regina) programs. So there's no need for arrays in the >subroutine. (I thought there would be, but I also thought there
    would be a non-loop way of reading and writing a file.)

    Arrays are what the Stream class uses in providing that non-loop way.
    Instead of this loop:

    do i = 1
    stem.i = linein(filein)
    end

    you can read the whole file into an array in one instruction:

    array = .stream~new(filein)~arrayIn

    then load that array into your stem:

    stem.~putAll(array)

    and put the count in stem.0:

    stem.0 = array~items

    R

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Arthur T.@21:1/5 to Glenn Knickerbocker on Tue Jan 9 20:58:12 2018
    In Message-ID:<t7l05dl77c02tog3se11jnu7kvfs6fgdms@4ax.com>,
    Glenn Knickerbocker <NotR@bestweb.net> wrote:

    On Fri, 05 Jan 2018 19:07:54 -0500, Arthur T. wrote:
    However, I do often pass the filename as a literal. I guess
    I'll need to do a PARSE ARG for the filename and a USE ARG for the >>stemname.

    Nope! USE ARG is fine for *reading* strings from the caller. It's just
    not any help in *updating* string variables.
    <snip rest>

    That was a very good explanation, and testing shows that it's
    correct and that I (probably) understood it.

    --
    Arthur T. - ar23hur "at" pobox "dot" com

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Arthur T.@21:1/5 to Glenn Knickerbocker on Tue Jan 9 20:59:32 2018
    In Message-ID:<adp05d1aa76hf58cm0484diif5g7du77hu@4ax.com>,
    Glenn Knickerbocker <NotR@bestweb.net> wrote:

    On Fri, 05 Jan 2018 14:43:27 -0500, Arthur T. wrote:
    I'm trying to use the ooRexx executable without having to change
    my existing (Regina) programs. So there's no need for arrays in the >>subroutine. (I thought there would be, but I also thought there
    would be a non-loop way of reading and writing a file.)

    Arrays are what the Stream class uses in providing that non-loop way.
    Instead of this loop:

    do i = 1
    stem.i = linein(filein)
    end

    you can read the whole file into an array in one instruction:

    array = .stream~new(filein)~arrayIn

    then load that array into your stem:

    stem.~putAll(array)

    and put the count in stem.0:

    stem.0 = array~items

    Sure enough, it works fine when I replace my external
    regstemread.rex with:

    <code>
    use arg filein, stem.

    array = .stream~new(filein)~arrayIn
    stem.~putAll(array)
    stem.0 = array~items

    exit 0
    </code>

    --
    Arthur T. - ar23hur "at" pobox "dot" com

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)