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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)