From: Digest <deadmail>
To: "OS/2GenAu Digest"<deadmail>
Date: Sun, 6 Feb 2005 00:01:06 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600
Subject: [os2genau_digest] No. 1041
Reply-To: <deadmail>
X-List-Unsubscribe: www.os2site.com/list/

**************************************************
Saturday 05 February 2005
 Number  1041
**************************************************

Subjects for today
 
1   Interesting note from [VOICENWS] list : Mike O'Connor <mikeoc at dodo dot com dot au>
2  Re:  Interesting note from [VOICENWS] list : Ed Durrant <edurrant at bigpond dot net dot au>
3  Re:  Interesting note from [VOICENWS] list : Mike O'Connor <mikeoc at dodo dot com dot au>
4   Rexx stem variables : Dennis Nolan <dennik at swiftdsl dot com dot au>
5  Re:  Rexx stem variables : Mike O'Connor <mikeoc at dodo dot com dot au>
6  Re:  Rexx stem variables : Jerry Garren A <jerry.garren at att dot net>

**= Email   1 ==========================**

Date:  Sat, 05 Feb 2005 09:56:20 +1000
From:  Mike O'Connor <mikeoc at dodo dot com dot au>
Subject:   Interesting note from [VOICENWS] list

Hi All,

for anyone not subscribing to VOICE lists.

[begin insert]

> From: outpostsysopDESPAM at earthlink dot net
>
> I was reading this on /. ( http://slashdot dot org/ ) and it discusses how
> OS/2 would have become the predominant OS if Windows 3.0 programs hadn't
> been able to run in protected mode... here's the blurb from /. :
>
> covertbadger writes "Larry Osterman said farewell yesterday to David
> Weise, the developer he credits with getting applications to run in
> protected mode on Windows 3.0, which led directly to Microsoft choosing to
> push Windows instead of OS/2. Today he speculates on what the IT world
> would be like if Weise had never completed this work. Windows 95 would
> never have existed, OS/2 would be the de facto standard, and IBM would
> never have put weight behind Linux because it had its own operating system
> to push."
>
> Url: http://weblogs.asp dot net/larryosterman/archive/2005/02/03/366493.aspx
>
> From: Sean Dennis (outpostsysopDESPAM at earthlink dot net)

[End insert]
-- 
Regards,
Mike

Failed the exam for
--------------------
MCSE - Minesweeper Consultant and Solitaire Expert
--------------------
[ISP blocks *.exe, *.cmd, * dot com, *.bat, *.reg attachments]
[Please use zipped versions of above]
----------------------------------------------------------------------------------
 

**= Email   2 ==========================**

Date:  Sat, 05 Feb 2005 11:23:37 +1100
From:  Ed Durrant <edurrant at bigpond dot net dot au>
Subject:  Re:  Interesting note from [VOICENWS] list

Mike O'Connor wrote:
> Hi All,
> 
> for anyone not subscribing to VOICE lists.
> 
> [begin insert]
> 
>> From: outpostsysopDESPAM at earthlink dot net
>>
>> I was reading this on /. ( http://slashdot dot org/ ) and it discusses how
>> OS/2 would have become the predominant OS if Windows 3.0 programs hadn't
>> been able to run in protected mode... here's the blurb from /. :
>>
>> covertbadger writes "Larry Osterman said farewell yesterday to David
>> Weise, the developer he credits with getting applications to run in
>> protected mode on Windows 3.0, which led directly to Microsoft 
>> choosing to
>> push Windows instead of OS/2. Today he speculates on what the IT world
>> would be like if Weise had never completed this work. Windows 95 would
>> never have existed, OS/2 would be the de facto standard, and IBM would
>> never have put weight behind Linux because it had its own operating 
>> system
>> to push."
>>
>> Url: http://weblogs.asp dot net/larryosterman/archive/2005/02/03/366493.aspx
>>
>> From: Sean Dennis (outpostsysopDESPAM at earthlink dot net)
> 
> 
> [End insert]
O.K. off to my time machine, to go back and "nobble" this guy .....

Ed.
----------------------------------------------------------------------------------
 

**= Email   3 ==========================**

Date:  Sat, 05 Feb 2005 11:16:09 +1000
From:  Mike O'Connor <mikeoc at dodo dot com dot au>
Subject:  Re:  Interesting note from [VOICENWS] list

Ed Durrant wrote:

> Mike O'Connor wrote:
>
>> Hi All,
>>
>> for anyone not subscribing to VOICE lists.
>>
>> [begin insert]
>>
>>> From: outpostsysopDESPAM at earthlink dot net
>>>
>>> I was reading this on /. ( http://slashdot dot org/ ) and it discusses how
>>> OS/2 would have become the predominant OS if Windows 3.0 programs 
>>> hadn't
>>> been able to run in protected mode... here's the blurb from /. :
>>>
>>> covertbadger writes "Larry Osterman said farewell yesterday to David
>>> Weise, the developer he credits with getting applications to run in
>>> protected mode on Windows 3.0, which led directly to Microsoft 
>>> choosing to
>>> push Windows instead of OS/2. Today he speculates on what the IT world
>>> would be like if Weise had never completed this work. Windows 95 would
>>> never have existed, OS/2 would be the de facto standard, and IBM would
>>> never have put weight behind Linux because it had its own operating 
>>> system
>>> to push."
>>>
>>> Url: 
>>> http://weblogs.asp dot net/larryosterman/archive/2005/02/03/366493.aspx
>>>
>>> From: Sean Dennis (outpostsysopDESPAM at earthlink dot net)
>>
>>
>>
>> [End insert]
>
> O.K. off to my time machine, to go back and "nobble" this guy .....
>
> Ed. 


Hi Ed,

FWIW the saved complete webpage [which includes all the responses] was 
89KB of text!
One OS/2 fan is under the impression though that Warp 4.0 Connect is 
*current* status of OS/2!

-- 
Regards,
Mike

Failed the exam for
--------------------
MCSE - Minesweeper Consultant and Solitaire Expert
--------------------
[ISP blocks *.exe, *.cmd, * dot com, *.bat, *.reg attachments]
[Please use zipped versions of above]

----------------------------------------------------------------------------------
 

**= Email   4 ==========================**

Date:  Sat, 05 Feb 2005 12:59:04 +1100
From:  Dennis Nolan <dennik at swiftdsl dot com dot au>
Subject:   Rexx stem variables

I thought this might be of interest to some of you, it gives an insight 
into why REXX behaves the way it does

It's from the comp.lang.rexx  newsgroup

The Author is Rick McGuire

Sigh, ok, long explanation time. Just remember you said you "I am 
covering 101 ground this evening to make sure I know an area inside and 
out".

Ok, the first thing you need to understand is a variable in Object Rexx 
is really just a pointer to an object.  So when I do this

a = 1
b = a

When you use a variable, the value of that variable is evaluated to 
generate a reference to the variable.  When you assign a variable, the 
object reference is assigned to the variable.  Variable A points to an 
instance of a Rexx string with the value "1", and the variable B points 
to the exact same instance.  In fact, the Classic Rexx interpreter 
implemented its internal storage the same way.  Now since Rexx strings 
are "immutable", there is nothing I can do to change the value of that 
string to anything other than "1".

Now consider this.

a = .array~new
b = a

The same principle applies as above.  Variables A and B now point to the 
same instance of a Rexx array.  Arrays are not immutable.  They have 
internal state that can be changed.  Thus

a[1] = "Fred"
say b[1]  -- displays "Fred"

The assignment to a[1] does not change the value of A.  It still points 
to the same array created above.  The assignment does change the 
internal state of the array.  Since B points to the same array instance, 
the change is reflected in the Say statement.  Neither variable A nor B 
was changed in this process, only the array they both point to.

ok, now lets extend this to calls.

c = 1
call fred a, c
say a[1] c b[1]   -- displays "George 1 George"
....

fred: procedure
use arg x, y

x[1] = "George"
y = 2

When you make a call (included method calls), the argument expressions 
are evaluated from left to right, creating a list of object references 
that are passed to the call target.  So in my example above the array 
contains two elements, the value of the variable A and value of the 
variable C.  The target routine has no knowledge of where these values 
came from, it only receives the references.

The use arg instruction is very simple, it merely assigns each listed 
variable to it's corresponding object reference.  So X points to the 
same array A and B point to, and Y points to the same string "1" that C 
points to.  USE ARG is functionally equivalent to "x = arg(1)", except 
for the special behavior that USE ARG has for omitted arguments.

When I do x[1] = "George", this is just like my example above.  The 
variable X is unchanged, but the internal state of the array it points 
to is, and this change is seen in the calling routine.

However, when I make the assignment "y = 2", this replaces the Y's 
object reference to "1" with a new reference to the string "2".  C back 
in the caller has not been touched, it still points to the string "1", 
which is reflected in the value that shows up on the Say statement.

Ok, your question was about stems, and I'm getting there!  I wanted to 
give you the basics of how object references work without cluttering the 
discussion up with stem variables yet.

Now let's look at stems.  A stem VARIABLE is just like a normal 
variable.  It also contains a reference to a Rexx object.  Stem 
VARIABLEs are special, however, as there is only a single type of object 
that can be assigned to a stem VARIABLE.  This single type is a STEM 
object.  Please try to keep in mind there is a difference between the 
stem OBJECT and the stem VARIABLE you use access to the object.

You can actually use stem OBJECTS without using stem VARIABLES.  For 
example:

a = .stem~new("A.")
a[1] = "Fred"
say a[1] a[2]  -- Displays "Fred A.2"

is functionally equivalent to

a.1 = "Fred"
say a.1 a.2

Any time you use either a stem variable or a compound variable, the stem 
part is evaluated to return the reference to its referenced stem object. 
 If this is the first time you've ever used this stem VARIABLE, then a 
STEM object is created and assigned to the variable first.  Once the 
stem OBJECT reference has been returned it is then used are the target 
for compound variable tail lookups.

INTERMISSION:  Handy little tip.  A frequent topic of discussion on this 
newsgroup is the question of constant values within a compound variable. 
 Uses such as this

x.i.name = "Rick"
x.i.address = "Boston"

a frequent convention tacks a digit on the front to prevent accidental 
uses of those variables.  ie,

x.i.0name = "Rick"
x.i.0address = "Boston"

In Object Rexx, you can use literal strings by using the "[]" notation

x.[i, "NAME"] = "Rick"
x.[i, "ADDRESS"] = "Rick"

note that this functions the same way Rexx arrays work.  The stem 
VARIABLE is evaluated, and the "[]=" method of the resulting stem OBJECT 
is invoked to do the assignment.

You can also see this reference effect by using the following assignment":

x = x.   -- TWO different variables here..."X" and "X."

say x[i, "NAME"] x.i.name  -- displays "Rick Rick"

Here we have a simple Rexx variable and a stem Rexx variable referencing 
the same stem OBJECT.

END INTERMISSION

Stem variable assignment also functions slightly differently from normal 
variable assignments.

If you assign a stem variable to another stem variable

a.1 = "Fred"
a. = b.
say b.1 b.2  -- displays "Fred A.2"

The stem variable reference for A. is assigned to a second stem variable 
B.  And you can see this when I referenced the uninitialized stem 
element B...it displayed the value "A." because the original stem OBJECT 
was created with a name value of "A." originally.



If you assign anything other than a stem OBJECT to a stem VARIABLE, then 
a new stem OBJECT is created and given that value as its default value. 
   This assignment will sever the link to the original stem object.  So 
given the above.

say a.1 b.1 -- displays "Fred Fred"
a. = "George"
say a.1 b.1 -- displays "George Fred"

Hang in there, I'm actually getting close to your original question!

Now, how does use arg work with stem variables.

a.1 = "Fred"
c = 1
call fred a., c
say a1 c  -- displays "George 1"
....

fred: procedure
use arg x., y

x.1 = "George"
y = 2


This is the same as the example above.  The stem variable A. in the call 
evaluates to a reference to a stem OBJECT, which is passed to the target 
routine.  USE ARG accesses that argument list, and assigns the 
references to each variable in turn.  So the local variable X. is 
assigned the value of the first argument, which is a reference to a stem 
object.  If you recall from the discussion above, a stem object assigned 
to a stem variable just copies the reference into the variable. 
Variables X. and A. now point to the same stem OBJECT.  Stem objects 
have updatable internal state, so the assignment

x.1 = "George" is visible back in the calling routine.

Interestingly, you can do the same thing without even using a stem 
variable!  Try the following:

fred: procedure
use arg x, y    -- X is a simple variable, not a stem!

x[1] = "George"
y = 2

Ok, thus concluded Rick's Friday night Object Rexx tutorial :-)

Regards
Dennis




----------------------------------------------------------------------------------
 

**= Email   5 ==========================**

Date:  Sat, 05 Feb 2005 12:35:08 +1000
From:  Mike O'Connor <mikeoc at dodo dot com dot au>
Subject:  Re:  Rexx stem variables

Dennis Nolan wrote:

> I thought this might be of interest to some of you, it gives an 
> insight into why REXX behaves the way it does
>
> It's from the comp.lang.rexx  newsgroup
>
> The Author is Rick McGuire
>
<tutorial snipped for bandwidth>


Hi Dennis,

Interesting. I wonder how he missed the :

x.[i, "NAME"] = "Rick"
x.[i, "ADDRESS"] = "Rick"  {for "Boston"}

-- 
Regards,
Mike

Failed the exam for
--------------------
MCSE - Minesweeper Consultant and Solitaire Expert
--------------------
[ISP blocks *.exe, *.cmd, * dot com, *.bat, *.reg attachments]
[Please use zipped versions of above]

----------------------------------------------------------------------------------
 

**= Email   6 ==========================**

Date:  Fri, 04 Feb 2005 21:01:25 -0800
From:  Jerry Garren A <jerry.garren at att dot net>
Subject:  Re:  Rexx stem variables

Dennis Nolan wrote:

> I thought this might be of interest to some of you, it gives an 
> insight into why REXX behaves the way it does

When I read far enough I learned IBM only 'gave' the non-OS/2 REXX 
software to REXXLA.

Does anyone know why?

Thanks.


----------------------------------------------------------------------------------
 

