f



Uninitialized variables, why do they equal their name?

I was curious if anyone knew why uninitialized variables in REXX resolve to 
their name?  Is it because REXX variables aren't declared or "typed", like 
in C?  I mean, in C or Perl, uninitialized variables resolved to null or 0, 
based on type (I think in Perl their initial value is based on context).

Just wondering what (if any) technical reason is behind this.

Thanks! 


0
John
11/12/2006 9:48:53 PM
comp.lang.rexx 2135 articles. 0 followers. Post Follow

37 Replies
3120 Views

Similar Articles

[PageSpeed] 29

In comp.lang.rexx John wrote:

> I was curious if anyone knew why uninitialized variables in REXX
> resolve to their name?  Is it because REXX variables aren't
> declared or "typed", like in C?  I mean, in C or Perl,
> uninitialized variables resolved to null or 0, based on type (I
> think in Perl their initial value is based on context). 
> 
> Just wondering what (if any) technical reason is behind this.

IIRC just a design decision...
Someone, maybe even Mike C., will be along with TRL reference I 
imagine.

Of course, is not "bad" practice to init. vars to null string or zero 
in advance of use.
0
Mark
11/12/2006 10:06:42 PM
In article <9FM5h.26239$pq4.25115@tornado.ohiordc.rr.com>,
   John <someone@microsoft.com> wrote:
> I was curious if anyone knew why uninitialized variables in REXX
> resolve to their name?

Because the designer chose that behaviour.

Maybe because in simple programs, the sort which non-prohgrammers write:

  a = 34 + 56
  say the total is a

works "sensibly"?

-- 
Jeremy C B Nicoll, Edinburgh, Scotland - my opinions are my own.
0
Jeremy
11/12/2006 10:18:53 PM
John wrote:
> I was curious if anyone knew why uninitialized variables in REXX resolve to 
> their name?  Is it because REXX variables aren't declared or "typed", like 
> in C?  I mean, in C or Perl, uninitialized variables resolved to null or 0, 
> based on type (I think in Perl their initial value is based on context).
> 
> Just wondering what (if any) technical reason is behind this.
> 
> Thanks! 

In Rexx a variable starts to exist once a value has been explicitly assigned to it. (And you can
"delete" a variable by dropping it.)

If you use symbols that could be variables, but have no value assigned to them, then the symbol
itself is used as a literal string.

As in Rexx everything outside of quotes is uppercased, you will get alphabetical characters in such
a symbol always in uppercase.

E.g.

       say a   /* will output the uppercase character "A" */
       say 1   /* will output the character "1", which happens to be a digit */
       say a 1 /* will output the string "A 1" */
       a="hello"   /* now "A" got used as a variable, as a reference got assigned to that symbol */
       say a 1 /* will output the string "hello 1" */

If looking at numbers in Rexx, then one looks at characters that happen to be digits. As long as you
use strings that represent a valid decimal number, you can use them for arithmetic calculations.

E.g.

	say 1+3/2	/* will output the string "2.5" */
	say "1"+"3"/"2" /* will output the string "2.5" */

Hope that helps,

---rony
0
rony
11/12/2006 11:05:19 PM
On Mon, 13 Nov 2006 00:05:19 +0100, rony
<Rony.Flatscher@wu-wien.ac.at> wrote:

>
>John wrote:
>> I was curious if anyone knew why uninitialized variables in REXX resolve to 
>> their name?  Is it because REXX variables aren't declared or "typed", like 
>> in C?  I mean, in C or Perl, uninitialized variables resolved to null or 0, 
>> based on type (I think in Perl their initial value is based on context).
>> 
>> Just wondering what (if any) technical reason is behind this.
>> 
>> Thanks! 
>
>In Rexx a variable starts to exist once a value has been explicitly assigned to it. (And you can
>"delete" a variable by dropping it.)
>
>If you use symbols that could be variables, but have no value assigned to them, then the symbol
>itself is used as a literal string.

That is correct. It was neither an arbitrary decision nor an
oversight. In Rexx, there are literals and variables. It it's not a
variable, then it's not a literal.

There was considerable debate over whether "unquoted literals" should
be allowed. I don't recall all oc the arguments, but I believe
simpilicity carried a lot of weight.

--
Using Personal Rexx for Windows 3.50 from Quercus
OS: Win 2K
0
LurfysMa
11/13/2006 12:00:56 AM
>John
>I was curious if anyone knew why uninitialized variables in REXX resolve to 
>their name?

Several people have expounded upon unitialized REXX variables, but no one has
yet answered "why". Jeremy came close when he pointed out that the
implementation makes it easier for "non-programmers".

The real reason is because REXX was created (by an IBM employee) first and
foremost to fill one particular need -- as a "batch language" for sysadmins
(ie, non-programmers) working on IBM mainframes. Those non-programmers wanted
something that would work similiarly to DOS batch files, which primarily would
be used to run "external commands" and pipe output from one command to another.
It was more about automation than real programming. (ie, It was more about
passing data to/from a series of "external programs" in order to achieve some
final manipulation of that data. It wasn't really about programming per se).

Because many external "console mode" (as we refer to them in the Windows world)
programs are intended to be run from a text terminal, that means their input is
typically text-based, and they're designed to have the user type any program
input at the command prompt. All of the input is typically given upon one line,
and then the user presses ENTER at the end of the line. For example, to run the
DOS DIR command from a terminal, and get a listing of the directory C:\MyDir,
with only the names shown, you'd type:

DIR C:\MyDir /B

There are 2 arguments (to the DIR command) above -- the directory name and the
/B option -- yet they both appear upon the same line. Because many arguments
can appear on one line, an external program typically assumes the user will
separate each argument with a space.

So one of the original design goals of REXX is that all data is text-based.
That makes it really easy to work with these "external programs" since their
input is usually text-based, and typically their output is as well.

Because REXX was designed primarily as a batch language, another design
decision was, when the REXX interpreter doesn't recognize some line in a REXX
script, it automatically shuffles it off to the "current environment"
(typically the operating system shell). No modern language works this way
because they aren't designed to be batch languages. In most languages, you have
to explicitly invoke some functionalitiy in order to run an external program,
for example C's system() function. But in a batch language, since you're
primarily invoking external programs, having REXX automatically toss all
unrecognized commands at the system shell is a "shortcut", and essentially the
same thing that DOS' batch language does.

So, you can put that above DIR command line in a REXX script, and it pretty
much works. Well, typically you'd supply the arguments from a variable. After
all, that's how batch scripts typically work. They read in some data into a
variable, and then start passing it between "commands". So maybe you'll do this
in your REXX script:

myArgs = "C:\MyDir /B"
DIR myArgs

But one problem with a batch language is, if the language itself requires
"strings" to be quoted, now you need quotes around the command name itself (ie,
"DIR") if you don't want the batch language to mistake it for a variable, or
for some "keyword". So, when you call the DIR command from a REXX script, you'd
have to do:

"DIR" myArgs

But apparently, the guy who came up with REXX thought "This is confusing to a
sysadmin, since he normally doesn't quote DIR when sitting at his text
terminal. I'll make this easier so that, if he forgets some needed quotes, then
when the REXX interpreter mistakes something for a variable, it won't make any
difference because a variable's unitialized value is itself". So let's say the
sysadmin puts the following line in his REXX script:

DIR myArgs 

Even if the REXX interpreter presumes DIR to be a REXX keyword (which it isn't)
or a variable name, as long as DIR hasn't been initialized, its value is still
"DIR". So in fact, REXX does end up sending that along to the system shell.

REXX ended up being used as a more general purpose programming language when it
became available on the Amiga and OS/2. But certain features of the language
emphasize its roots as a batch language. Unfortunately, it's this legacy that
sometimes makes it less suitable as a general purpose language today, but
that's the way it goes.

I think that a lot of the "why does REXX do things this way?" questions are
answered by considering REXX's intent as a batch language for IBM mainframes.
For example, why do you not put parentheses around args when CALL'ing some
"function" versus omitting the CALL keyword? Because CALL is similiar to how a
DOS batch file does things, and REXX was supposed to be IBM's version of a DOS
batch language for IBM mainframes. It all makes sense if you're a sysadmin
sitting at an IBM text terminal many years ago (or maybe even today still. I
don't know as if IBM server administration tools have made much progress in
their UI like Microsoft server tools have).
0
Jeff
11/13/2006 12:46:54 AM
"Jeff Glatt" <jglatt@spamgone-borg.com> wrote in message 
news:9vafl2lvf9jfu8sbibads60jtjc2bpu6kk@4ax.com...
> >John
>>I was curious if anyone knew why uninitialized variables in REXX resolve 
>>to
>>their name?
>
> Several people have expounded upon unitialized REXX variables, but no one 
> has
> yet answered "why". Jeremy came close when he pointed out that the
> implementation makes it easier for "non-programmers".
>
> The real reason is because REXX was created (by an IBM employee) first and
> foremost to fill one particular need -- as a "batch language" for 
> sysadmins
> (ie, non-programmers) working on IBM mainframes. Those non-programmers 
> wanted
> something that would work similiarly to DOS batch files, which primarily 
> would
> be used to run "external commands" and pipe output from one command to 
> another.
> It was more about automation than real programming. (ie, It was more about
> passing data to/from a series of "external programs" in order to achieve 
> some
> final manipulation of that data. It wasn't really about programming per 
> se).
>
> Because many external "console mode" (as we refer to them in the Windows 
> world)
> programs are intended to be run from a text terminal, that means their 
> input is
> typically text-based, and they're designed to have the user type any 
> program
> input at the command prompt. All of the input is typically given upon one 
> line,
> and then the user presses ENTER at the end of the line. For example, to 
> run the
> DOS DIR command from a terminal, and get a listing of the directory 
> C:\MyDir,
> with only the names shown, you'd type:
>
> DIR C:\MyDir /B
>
> There are 2 arguments (to the DIR command) above -- the directory name and 
> the
> /B option -- yet they both appear upon the same line. Because many 
> arguments
> can appear on one line, an external program typically assumes the user 
> will
> separate each argument with a space.
>
> So one of the original design goals of REXX is that all data is 
> text-based.
> That makes it really easy to work with these "external programs" since 
> their
> input is usually text-based, and typically their output is as well.
>
> Because REXX was designed primarily as a batch language, another design
> decision was, when the REXX interpreter doesn't recognize some line in a 
> REXX
> script, it automatically shuffles it off to the "current environment"
> (typically the operating system shell). No modern language works this way
> because they aren't designed to be batch languages. In most languages, you 
> have
> to explicitly invoke some functionalitiy in order to run an external 
> program,
> for example C's system() function. But in a batch language, since you're
> primarily invoking external programs, having REXX automatically toss all
> unrecognized commands at the system shell is a "shortcut", and essentially 
> the
> same thing that DOS' batch language does.
>
> So, you can put that above DIR command line in a REXX script, and it 
> pretty
> much works. Well, typically you'd supply the arguments from a variable. 
> After
> all, that's how batch scripts typically work. They read in some data into 
> a
> variable, and then start passing it between "commands". So maybe you'll do 
> this
> in your REXX script:
>
> myArgs = "C:\MyDir /B"
> DIR myArgs
>
> But one problem with a batch language is, if the language itself requires
> "strings" to be quoted, now you need quotes around the command name itself 
> (ie,
> "DIR") if you don't want the batch language to mistake it for a variable, 
> or
> for some "keyword". So, when you call the DIR command from a REXX script, 
> you'd
> have to do:
>
> "DIR" myArgs
>
> But apparently, the guy who came up with REXX thought "This is confusing 
> to a
> sysadmin, since he normally doesn't quote DIR when sitting at his text
> terminal. I'll make this easier so that, if he forgets some needed quotes, 
> then
> when the REXX interpreter mistakes something for a variable, it won't make 
> any
> difference because a variable's unitialized value is itself". So let's say 
> the
> sysadmin puts the following line in his REXX script:
>
> DIR myArgs
>
> Even if the REXX interpreter presumes DIR to be a REXX keyword (which it 
> isn't)
> or a variable name, as long as DIR hasn't been initialized, its value is 
> still
> "DIR". So in fact, REXX does end up sending that along to the system 
> shell.
>
> REXX ended up being used as a more general purpose programming language 
> when it
> became available on the Amiga and OS/2. But certain features of the 
> language
> emphasize its roots as a batch language. Unfortunately, it's this legacy 
> that
> sometimes makes it less suitable as a general purpose language today, but
> that's the way it goes.
>
> I think that a lot of the "why does REXX do things this way?" questions 
> are
> answered by considering REXX's intent as a batch language for IBM 
> mainframes.
> For example, why do you not put parentheses around args when CALL'ing some
> "function" versus omitting the CALL keyword? Because CALL is similiar to 
> how a
> DOS batch file does things, and REXX was supposed to be IBM's version of a 
> DOS
> batch language for IBM mainframes. It all makes sense if you're a sysadmin
> sitting at an IBM text terminal many years ago (or maybe even today still. 
> I
> don't know as if IBM server administration tools have made much progress 
> in
> their UI like Microsoft server tools have).

Jeff, thanks; that's exactly what I was looking for.  I actually learned & 
use REXX on a mainframe and the sysadmin analogy makes perfect sense and is 
110% true.  Unfortunately, it's also a curse because right now I am 
migrating a several-thousand line REXX application that does NOT quote its 
literals unless they're over 1 word long.  So you're also right about REXX 
not originally being intended as an application programming lang., although 
it works just fine if you follow good practices of some sort.

I also do know that the MVS/TSO scripting language was always TSO/CLIST, and 
many admins and 3rd-party vendors still seem to prefer it.  CLIST does not 
quote literals; instead, you specify any variables by prepending '&' to the 
variable name:
SET TXT = This is my text
WRITE Here is some text &TXT
Here is some text This is my text    /* <---- printed on console */


FYI, IBM mainframe admin tools have not made much progress in the UI area --  
sending tapes is still the norm & TCP/IP delivery is a dirty word, and 
admins don't seem to see anything wrong with spending 3 days to transfer a 
file via courier instead of 3 seconds via fiber.  This always makes me 
giggle.  You can argue until you're blue-in-the-face and in the end they 
always trump you with "TCP/IP is insecure".  As if some plumber's-smiling, 
trucker bloke making minimum wage + 1 is the preferred means of handling 
$20M of a corporation's data small enough to fit in your pocket.

For an anecdote: I was working with an old-timer mainframe sysadmin a few 
months ago in 2006.  We were restoring some system files which had been 
archived to a tape like a unix .tar file.  There were several dozen files 
and we kept running seperate batch jobs to extract each one to disk.  Each 
job took about 5min. and 99% of that time was waiting for the tape to load & 
unload (it was the same tape every time).  I asked, "To save time, why don't 
you just copy the entire .tar file from tape to disk and then extract them 
from disk?"  The response was "But it's a tape file!"

So, maybe mainframe UIs HAVE made progress; unfortunately, it doesn't look 
like the admins have...
;-) 


0
John
11/13/2006 6:05:32 AM
On Sun, 12 Nov 2006 19:46:54 -0500, Jeff Glatt
<jglatt@spamgone-borg.com> wrote:

>>John
>>I was curious if anyone knew why uninitialized variables in REXX resolve to 
>>their name?
>
>Several people have expounded upon unitialized REXX variables, but no one has
>yet answered "why". Jeremy came close when he pointed out that the
>implementation makes it easier for "non-programmers".
>
>The real reason is because REXX was created (by an IBM employee) first and
>foremost to fill one particular need -- as a "batch language" for sysadmins
>(ie, non-programmers) working on IBM mainframes. Those non-programmers wanted
>something that would work similiarly to DOS batch files, which primarily would
>be used to run "external commands" and pipe output from one command to another.
>It was more about automation than real programming. (ie, It was more about
>passing data to/from a series of "external programs" in order to achieve some
>final manipulation of that data. It wasn't really about programming per se).

Interesting. I this your opinion or do you know this to be true? If
so, what is your source for these "facts"? I am particularly
interested in your assertion that Rexx (then Rex) was intended for
non-programmer sysadmins.

>Because many external "console mode" (as we refer to them in the Windows world)
>programs are intended to be run from a text terminal, that means their input is
>typically text-based, and they're designed to have the user type any program
>input at the command prompt. All of the input is typically given upon one line,
>and then the user presses ENTER at the end of the line. For example, to run the
>DOS DIR command from a terminal, and get a listing of the directory C:\MyDir,
>with only the names shown, you'd type:
>
>DIR C:\MyDir /B
>
>There are 2 arguments (to the DIR command) above -- the directory name and the
>/B option -- yet they both appear upon the same line. Because many arguments
>can appear on one line, an external program typically assumes the user will
>separate each argument with a space.
>
>So one of the original design goals of REXX is that all data is text-based.
>That makes it really easy to work with these "external programs" since their
>input is usually text-based, and typically their output is as well.
>
>Because REXX was designed primarily as a batch language, another design
>decision was, when the REXX interpreter doesn't recognize some line in a REXX
>script, it automatically shuffles it off to the "current environment"
>(typically the operating system shell). No modern language works this way
>because they aren't designed to be batch languages. In most languages, you have
>to explicitly invoke some functionalitiy in order to run an external program,
>for example C's system() function. But in a batch language, since you're
>primarily invoking external programs, having REXX automatically toss all
>unrecognized commands at the system shell is a "shortcut", and essentially the
>same thing that DOS' batch language does.
>
>So, you can put that above DIR command line in a REXX script, and it pretty
>much works. Well, typically you'd supply the arguments from a variable. After
>all, that's how batch scripts typically work. They read in some data into a
>variable, and then start passing it between "commands". So maybe you'll do this
>in your REXX script:
>
>myArgs = "C:\MyDir /B"
>DIR myArgs
>
>But one problem with a batch language is, if the language itself requires
>"strings" to be quoted, now you need quotes around the command name itself (ie,
>"DIR") if you don't want the batch language to mistake it for a variable, or
>for some "keyword". So, when you call the DIR command from a REXX script, you'd
>have to do:
>
>"DIR" myArgs
>
>But apparently, the guy who came up with REXX thought "This is confusing to a
>sysadmin, since he normally doesn't quote DIR when sitting at his text
>terminal. 

Now you sound more like you are just guessing. Above, you talked as if
you knew these things for sure. Which is it? Do you know what you are
talking about?

By the way, "the guy" is Mike Cowlishaw, who worked for IBM in
Hursley, England at the time he wrote Rex. Did you not know that?

>I'll make this easier so that, if he forgets some needed quotes, then
>when the REXX interpreter mistakes something for a variable, it won't make any
>difference because a variable's unitialized value is itself". So let's say the
>sysadmin puts the following line in his REXX script:

And what happens when this ignorant sysadmin later defines a variable
named "dir"? Or are sysadmins too dense to use variables?

>DIR myArgs 
>
>Even if the REXX interpreter presumes DIR to be a REXX keyword (which it isn't)
>or a variable name, as long as DIR hasn't been initialized, its value is still
>"DIR". So in fact, REXX does end up sending that along to the system shell.
>
>REXX ended up being used as a more general purpose programming language when it
>became available on the Amiga and OS/2. 

Rex (not Rexx) was a command language intended to replace the
primitive and awkward EXEC and EXEC2 command languages being used at
the time on the VM systems on IBM mainframes.

>But certain features of the language
>emphasize its roots as a batch language. Unfortunately, it's this legacy that
>sometimes makes it less suitable as a general purpose language today, but
>that's the way it goes.
>
>I think that a lot of the "why does REXX do things this way?" questions are
>answered by considering REXX's intent as a batch language for IBM mainframes.

They can also be answered by listening to people who were actually
there and know what was done and why.

>For example, why do you not put parentheses around args when CALL'ing some
>"function" versus omitting the CALL keyword? Because CALL is similiar to how a
>DOS batch file does things, and REXX was supposed to be IBM's version of a DOS
>batch language for IBM mainframes. It all makes sense if you're a sysadmin
>sitting at an IBM text terminal many years ago (or maybe even today still. I
>don't know as if IBM server administration tools have made much progress in
>their UI like Microsoft server tools have).

Rex, and later Rexx, were used by programmers throughout IBM on VM
systems to write very complex "execs". It was absolutely not intended
solely or even primarily for non-programmers -- sysadmins or
otherwise.

--
Using Personal Rexx for Windows 3.50 from Quercus
OS: Win 2K
0
LurfysMa
11/13/2006 6:40:55 AM
"LurfysMa" <invalid@invalid.invalid> wrote in message 
news:qj3gl2dcf4agl3psihdsa6lq834s7q30ti@4ax.com...
> On Sun, 12 Nov 2006 19:46:54 -0500, Jeff Glatt
> <jglatt@spamgone-borg.com> wrote:
>
>>>John
>>>I was curious if anyone knew why uninitialized variables in REXX resolve 
>>>to
>>>their name?
>>
>>Several people have expounded upon unitialized REXX variables, but no one 
>>has
>>yet answered "why". Jeremy came close when he pointed out that the
>>implementation makes it easier for "non-programmers".
>>
>>The real reason is because REXX was created (by an IBM employee) first and
>>foremost to fill one particular need -- as a "batch language" for 
>>sysadmins
>>(ie, non-programmers) working on IBM mainframes. Those non-programmers 
>>wanted
>>something that would work similiarly to DOS batch files, which primarily 
>>would
>>be used to run "external commands" and pipe output from one command to 
>>another.
>>It was more about automation than real programming. (ie, It was more about
>>passing data to/from a series of "external programs" in order to achieve 
>>some
>>final manipulation of that data. It wasn't really about programming per 
>>se).
>
> Interesting. I this your opinion or do you know this to be true? If
> so, what is your source for these "facts"? I am particularly
> interested in your assertion that Rexx (then Rex) was intended for
> non-programmer sysadmins.
>
>>Because many external "console mode" (as we refer to them in the Windows 
>>world)
>>programs are intended to be run from a text terminal, that means their 
>>input is
>>typically text-based, and they're designed to have the user type any 
>>program
>>input at the command prompt. All of the input is typically given upon one 
>>line,
>>and then the user presses ENTER at the end of the line. For example, to 
>>run the
>>DOS DIR command from a terminal, and get a listing of the directory 
>>C:\MyDir,
>>with only the names shown, you'd type:
>>
>>DIR C:\MyDir /B
>>
>>There are 2 arguments (to the DIR command) above -- the directory name and 
>>the
>>/B option -- yet they both appear upon the same line. Because many 
>>arguments
>>can appear on one line, an external program typically assumes the user 
>>will
>>separate each argument with a space.
>>
>>So one of the original design goals of REXX is that all data is 
>>text-based.
>>That makes it really easy to work with these "external programs" since 
>>their
>>input is usually text-based, and typically their output is as well.
>>
>>Because REXX was designed primarily as a batch language, another design
>>decision was, when the REXX interpreter doesn't recognize some line in a 
>>REXX
>>script, it automatically shuffles it off to the "current environment"
>>(typically the operating system shell). No modern language works this way
>>because they aren't designed to be batch languages. In most languages, you 
>>have
>>to explicitly invoke some functionalitiy in order to run an external 
>>program,
>>for example C's system() function. But in a batch language, since you're
>>primarily invoking external programs, having REXX automatically toss all
>>unrecognized commands at the system shell is a "shortcut", and essentially 
>>the
>>same thing that DOS' batch language does.
>>
>>So, you can put that above DIR command line in a REXX script, and it 
>>pretty
>>much works. Well, typically you'd supply the arguments from a variable. 
>>After
>>all, that's how batch scripts typically work. They read in some data into 
>>a
>>variable, and then start passing it between "commands". So maybe you'll do 
>>this
>>in your REXX script:
>>
>>myArgs = "C:\MyDir /B"
>>DIR myArgs
>>
>>But one problem with a batch language is, if the language itself requires
>>"strings" to be quoted, now you need quotes around the command name itself 
>>(ie,
>>"DIR") if you don't want the batch language to mistake it for a variable, 
>>or
>>for some "keyword". So, when you call the DIR command from a REXX script, 
>>you'd
>>have to do:
>>
>>"DIR" myArgs
>>
>>But apparently, the guy who came up with REXX thought "This is confusing 
>>to a
>>sysadmin, since he normally doesn't quote DIR when sitting at his text
>>terminal.
>
> Now you sound more like you are just guessing. Above, you talked as if
> you knew these things for sure. Which is it? Do you know what you are
> talking about?
>
> By the way, "the guy" is Mike Cowlishaw, who worked for IBM in
> Hursley, England at the time he wrote Rex. Did you not know that?
>
>>I'll make this easier so that, if he forgets some needed quotes, then
>>when the REXX interpreter mistakes something for a variable, it won't make 
>>any
>>difference because a variable's unitialized value is itself". So let's say 
>>the
>>sysadmin puts the following line in his REXX script:
>
> And what happens when this ignorant sysadmin later defines a variable
> named "dir"? Or are sysadmins too dense to use variables?
>
>>DIR myArgs
>>
>>Even if the REXX interpreter presumes DIR to be a REXX keyword (which it 
>>isn't)
>>or a variable name, as long as DIR hasn't been initialized, its value is 
>>still
>>"DIR". So in fact, REXX does end up sending that along to the system 
>>shell.
>>
>>REXX ended up being used as a more general purpose programming language 
>>when it
>>became available on the Amiga and OS/2.
>
> Rex (not Rexx) was a command language intended to replace the
> primitive and awkward EXEC and EXEC2 command languages being used at
> the time on the VM systems on IBM mainframes.
>
>>But certain features of the language
>>emphasize its roots as a batch language. Unfortunately, it's this legacy 
>>that
>>sometimes makes it less suitable as a general purpose language today, but
>>that's the way it goes.
>>
>>I think that a lot of the "why does REXX do things this way?" questions 
>>are
>>answered by considering REXX's intent as a batch language for IBM 
>>mainframes.
>
> They can also be answered by listening to people who were actually
> there and know what was done and why.
>
>>For example, why do you not put parentheses around args when CALL'ing some
>>"function" versus omitting the CALL keyword? Because CALL is similiar to 
>>how a
>>DOS batch file does things, and REXX was supposed to be IBM's version of a 
>>DOS
>>batch language for IBM mainframes. It all makes sense if you're a sysadmin
>>sitting at an IBM text terminal many years ago (or maybe even today still. 
>>I
>>don't know as if IBM server administration tools have made much progress 
>>in
>>their UI like Microsoft server tools have).
>
> Rex, and later Rexx, were used by programmers throughout IBM on VM
> systems to write very complex "execs". It was absolutely not intended
> solely or even primarily for non-programmers -- sysadmins or
> otherwise.
>
> --
> Using Personal Rexx for Windows 3.50 from Quercus
> OS: Win 2K


LOL, I'm sorry to everyone, I wasn't trying to spark a debate or flame war.

Regardless of historical precedent, for me, based on my experiences coming 
into mainframe work, Jeff's theories definitely bear weight, if even from my 
sometimes cynical point of view.  If I didn't have the insight of mainframe 
experience, I'd probably not agree with him.

All this has made me do some Googling for more info...

According to my main man, Mike C., the primary impetus was simplicity and a 
desire to make a powerful programming language that was a pretty close 
approximation to a standard spoken/written human language, like English, 
etc.:
http://www.research.ibm.com/journal/sj/234/ibmsj2304D.pdf

He makes no mention of "admins vs. programmers," only that "the REXX 
language is a tool for use by real people to do real work."  (Ask a group of 
admins & they'll tell you that admins are the "real people", and I'm sure 
that programmers would say the reverse.)  But he does stress the importance 
of "Command program interpreters".

While initially designed for VM/CMS, for some people (myself included), 
seeing REXX used in an MVS/TSO environment leads us to make comparisons to 
the TSO CLIST language syntax, and we extrapolate our reasons that way (or, 
at least, I do, particularly where interaction with "old-timers"  comes into 
play).

CLIST (admins) is more like written English than COBOL (programmers), and 
CLIST is mostly used in TSO in a "real-time" console interface; programmers 
run their jobs as time-scheduled batch and are usually at the pub when their 
programs run.  Because REXX and its uses is more like CLIST, it's easy for 
me to associate it with admins.

From my experience, admins use REXX way more than programmers do, and, on a 
mainframe, if I ran production-critical applications in REXX rather than 
COBOL, I'd notice a considerable difference in run-time.  And if a mainframe 
admin had a choice between paying for the REXX compiler or COBOL, it would 
be no contest.  (I heard of someone getting an IBM quote for the mainframe 
REXX compiler and it was well over $5K/month license fees!)

Mike's treatise is great reading.  I realize it's from 1984, but hearing him 
talk about "modern" concepts of structured programming is ironic fun, 
because some of these things are STILL new to the mainframe world (blame 
IBM's double-edged-sword philosophy of 40yr. backwards compatibility).  As 
young as I am, I know nothing but "structured programming" concepts, so this 
is kind of neat.  I found old (from 12yrs ago) mainframe MVS REXX code and 
they use COBOL naming conventions for their subroutines like:
100-SUBROUTINE:
200-SUBROUTINE:
and I have a good laugh to ease the pain of dealing with unquoted literals 
in others' code.  ROFL, have fun calling THAT subroutine (hilarity ensued, 
and REXX was officially ditched for another 8 years after that disaster!). 


0
John
11/13/2006 8:50:38 AM
>LurfysMa
>I am particularly
>interested in your assertion that Rexx (then Rex) was intended for
>non-programmer sysadmins.

It was always marketed as a "language" for "real people" (ie, not just
programmers, like other "languages" are).

But the real telling fact is that IBM's software endeavors are almost always
geared toward selling expensive IBM hardware. There was no need for just
another programming language on IBM mainframes. What was needed was a simple
text-based language that could be used as a batch language for sysadmins in
charge of running IBM mainframes. A language that had features (as I've
described in my previous message) that are very much like DOS' batch language.
That was what IBM needed to entice people to buy more of its mainframes.
0
Jeff
11/13/2006 12:13:02 PM
>John
>I am migrating a several-thousand line REXX application that does NOT quote its 
>literals unless they're over 1 word long.

And that's something that someone who has minimal experience in most all other
languages would do. It's traditional to quote literal strings in most
programming languages, so a programmer would do that in REXX too since it's
certainly allowed (and especially given the potential for one of those
"literals" to suddenly become a variable with a particular value).

But someone accustomed to only writing batch files would typically quote only
arguments that have embedded spaces. Why? Because that's what he'd have to do
when running the command from his text terminal. Console mode programs
typically are designed for the user to quote an argument that has embedded
spaces. (The C language, for example, takes care of parsing arguments that are
formatted as such. A C programmer doesn't even have to implement this parsing
himself).

Take that same DIR command. What if you want to get a listing of C:\My
Directory? Now you've got to quote the directory name argument (when running it
from a text terminal):

DIR "C:\My Directory" /B

Someone accustomed to running commands from a text terminal (like a sysadmin)
would be aware of this.

>I asked, "To save time, why don't 
>you just copy the entire .tar file from tape to disk and then extract them 
>from disk?"  The response was "But it's a tape file!"

Hahahahaha!!!!

People do get accustomed to doing things a certain way, and then no other way
is acceptable to them. But that's why REXX works similiarly to the other batch
languages of the time, rather than like java or python for example which were
created after batch languages went out of style. The older people still working
in the field are using the archaic stuff, and as they retire, the new people
coming in are left to tear their hair out trying to migrate several-thousand
line REXX "applications" that don't quote literals unless they're over 1 word
long.
0
Jeff
11/13/2006 12:37:17 PM
In <e6dfl2hds240qi826aem4fnjvunn3pcqh7@4ax.com>, on 11/12/2006
   at 04:00 PM, LurfysMa <invalid@invalid.invalid> said:

>That is correct.

Close; it's still considered to be a symbol rather than a literal
string.

>It was neither an arbitrary decision nor an oversight.

IMHO it was a sound decision. However, there is a contingent that
believes that NOVALUE should always be enabled.

>It it's not a variable, then it's not a literal.

? Even allowing for typpos I'm having trouble with that. A variable
does not have the same syntax as a literal string. REXX does not have
any type of literal other than literal strings.

>There was considerable debate over whether "unquoted literals"
>should be allowed.

The original target for REXX was command procedures, where a large
part of the generated text would be constant command names and
arguments coded in the text. Allowing variable to default to there
names made such procedures both easier to read and easier to write.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
Shmuel
11/13/2006 1:25:14 PM
In <9FM5h.26239$pq4.25115@tornado.ohiordc.rr.com>, on 11/12/2006
   at 09:48 PM, "John" <someone@microsoft.com> said:

>I was curious if anyone knew why uninitialized variables in REXX
>resolve to  their name?

Because it's extremely useful for the target application, which was
command procedures. When you're using a shell, do you really want to
quote each command name and constant parameter?

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
Shmuel
11/13/2006 1:28:51 PM
In <qj3gl2dcf4agl3psihdsa6lq834s7q30ti@4ax.com>, on 11/12/2006
   at 10:40 PM, LurfysMa <invalid@invalid.invalid> said:

>Interesting. I this your opinion or do you know this to be true?

It's partially true. REXX was written to replace EXEC and EXEC2 in the
VM world, and VM/SP included some non-trivial applications written in
EXEC2. REXX was always intended to be useful for purposes beyond the
simple command procedure, even though that was it's primary target.

>Now you sound more like you are just guessing.

Indeed. He seems to not understand the role of the environment in
REXX. One of the design goals was to be able to generate commands for
multiple environments, e.g., both an editor and the operating system.
It is *not* part of REXX that the commands must be processed as
external programs, especially in the case of REXX macros for an
editor.

>Which is it?

Two from column A and three from column B. He's right about some
things.

>Rex (not Rexx) was a command language intended to replace the
>primitive and awkward EXEC and EXEC2 command languages being used at
>the time on the VM systems on IBM mainframes.

My VM documentation calls it REXX. I believe that Rex was a prerelease
name.

>Rex, and later Rexx, were used by programmers throughout IBM on VM
>systems to write very complex "execs".

My recollection is that some pieces of VM/SP were originally hundreds
of thousands of lines of EXEC2 and were later rewritten in REXX.
That's certainly non-trivial in my book. Certainly the VM/SP, and
later the TSO/E, documentation was targeted to more than just the
causal user.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
Shmuel
11/13/2006 1:49:28 PM
In <ej89bf$21k5$1@trane.wu-wien.ac.at>, on 11/13/2006
   at 12:05 AM, rony <Rony.Flatscher@wu-wien.ac.at> said:

>If you use symbols that could be variables, but have no value
>assigned to them, then the symbol itself is used as a literal
>string.

More precisely, the manual says

     You can use a symbol in an expression even if you have not
     assigned it a value, because a symbol has a defined  value at all
     times. A variable you have not assigned a value is uninitialized.
     Its value is the characters of the  symbol itself, translated to
     uppercase (that is, lowercase a-z to uppercase A-Z).

Note that a number is a special case of a symbol

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
Shmuel
11/13/2006 1:55:12 PM
In <MWT5h.29231$Cq3.341@tornado.ohiordc.rr.com>, on 11/13/2006
   at 06:05 AM, "John" <someone@microsoft.com> said:

>So you're also right about REXX 
>not originally being intended as an application programming lang.,

No he isn't; that was one of its goals. Even its predecessor, EXEC2,
was used as an application programming language.

>I also do know that the MVS/TSO scripting language was always
>TSO/CLIST,

Many of us were quite happy to drop CLIST once TSO/E V2 gave us access
to REXX.

>CLIST does not quote literals; instead, you specify any variables by
>prepending '&' to the variable name:

And what a mares nest *that* creates when you need an ampersand in a
string. The problems with apostrophes are even worse.

>FYI, IBM mainframe admin tools have not made much progress in the UI
>area

WTF? There has been massive change.

>sending tapes is still the norm

Not from what I see.

>& TCP/IP delivery is a dirty word,

To whom? IBM is pushing it heavily.

>You can argue until you're blue-in-the-face and in the end they 
>always trump you with "TCP/IP is insecure". 

That sounds like the network folks, not the mainframe folks. Or
perhaps your shop is special.

>There were several dozen files 
>and we kept running seperate batch jobs to extract each one to disk.

Why?

>Each job took about 5min. and 99% of that time was waiting for the 
>tape to load &  unload (it was the same tape every time).

That suggests an issue with your shop. There is an easy way to keep
MVS from unloading the tape.

>The response was "But it's a tape file!"

Well, I've had people tell me that the software didn't support things
that I'd been doing for years or even decades, so the response doesn't
surprise me. But it's hardly representative of mainframe shops in
general.

>So, maybe mainframe UIs HAVE made progress; unfortunately, it
>doesn't look  like the admins have...

I assure you that there are equivalent horror stories on the PC side.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
Shmuel
11/13/2006 2:08:57 PM
On Mon, 13 Nov 2006 08:50:38 GMT, "John" <someone@microsoft.com>
wrote:

>Regardless of historical precedent, for me, based on my experiences coming 
>into mainframe work, Jeff's theories definitely bear weight, if even from my 
>sometimes cynical point of view.  If I didn't have the insight of mainframe 
>experience, I'd probably not agree with him.

The point is that Glatt's comments are just his opinions, even if they
are presented as facts. If we are working on a physics problem,
theories are great. If we are discussing the origins of a programmuing
langauge, there's knowledge and everything else. Glatt's comments fall
into the latter category -- no matter how intuitive they may seem to
anyone. They are just not accurate.

--
Using Personal Rexx for Windows 3.50 from Quercus
OS: Win 2K
0
LurfysMa
11/13/2006 4:36:03 PM
On Mon, 13 Nov 2006 07:13:02 -0500, Jeff Glatt
<jglatt@spamgone-borg.com> wrote:

>>LurfysMa
>>I am particularly
>>interested in your assertion that Rexx (then Rex) was intended for
>>non-programmer sysadmins.
>
>It was always marketed as a "language" for "real people" (ie, not just
>programmers, like other "languages" are).

In the beginning it was not marketed at all. Mike wrote it on his own
and assembled a small group of programmers (not sysadmins) around the
company on the internal network (VNET) to test, comment on, and help
develop the langauge. 

In fact, it came out just shortly after the company officially
released EXEC2 -- the "enhanced" replacement for EXEC. EXEC2 was a
bandaid on a mortal wound. Rex was open heart surgery. The VM group in
Fishgill (or wherever they were in the Mid Hudson Valley) actively
tried to kill Rex (or at least suppress it) because they were afraid
that it would make the company look bad to have released EXEC2 (to the
VM customers) and then to release Rex like a day later.

>But the real telling fact is that IBM's software endeavors are almost always
>geared toward selling expensive IBM hardware. There was no need for just
>another programming language on IBM mainframes. What was needed was a simple
>text-based language that could be used as a batch language for sysadmins in
>charge of running IBM mainframes. A language that had features (as I've
>described in my previous message) that are very much like DOS' batch language.
>That was what IBM needed to entice people to buy more of its mainframes.

What utter bullshit. Now you have shown your true colors. Yes,
companies try to sell whatever it is that they sell. Yes, IBM was
mainly a hardware company. No, Rex had nothng whatsoever to do with
that. The "company" did not even know it was being developed. And NO,
it was not aimed at sysadmins -- whoever you think they are.

--
Using Personal Rexx for Windows 3.50 from Quercus
OS: Win 2K
0
LurfysMa
11/13/2006 4:45:20 PM
On Mon, 13 Nov 2006 08:49:28 -0500, "Shmuel (Seymour J.) Metz"
<spamtrap@library.lspace.org.invalid> wrote:

>In <qj3gl2dcf4agl3psihdsa6lq834s7q30ti@4ax.com>, on 11/12/2006
>   at 10:40 PM, LurfysMa <invalid@invalid.invalid> said:
>
>>Interesting. I this your opinion or do you know this to be true?
>
>It's partially true. REXX was written to replace EXEC and EXEC2 in the
>VM world, and VM/SP included some non-trivial applications written in
>EXEC2. REXX was always intended to be useful for purposes beyond the
>simple command procedure, even though that was it's primary target.

My point was not whether it was true, but whether Glatt knew whether
it was true or was just guessing. Yes, some of what he says is true.
Even a stopped watch is right twice a day.

>>Now you sound more like you are just guessing.
>
>Indeed. He seems to not understand the role of the environment in
>REXX. One of the design goals was to be able to generate commands for
>multiple environments, e.g., both an editor and the operating system.
>It is *not* part of REXX that the commands must be processed as
>external programs, especially in the case of REXX macros for an
>editor.
>
>>Which is it?
>
>Two from column A and three from column B. He's right about some
>things.
>
>>Rex (not Rexx) was a command language intended to replace the
>>primitive and awkward EXEC and EXEC2 command languages being used at
>>the time on the VM systems on IBM mainframes.
>
>My VM documentation calls it REXX. I believe that Rex was a prerelease
>name.

It's been a long time, but I'm pretty sure that the name Rex was in
use after it had been "released" to VM customers. I could be wrong.

>>Rex, and later Rexx, were used by programmers throughout IBM on VM
>>systems to write very complex "execs".
>
>My recollection is that some pieces of VM/SP were originally hundreds
>of thousands of lines of EXEC2 and were later rewritten in REXX.
>That's certainly non-trivial in my book. Certainly the VM/SP, and
>later the TSO/E, documentation was targeted to more than just the
>causal user.

Correct. Some of these EXEC2 execs were unbelievable. Essentially
unreadable. In my opinion, EXEC2 made thyings much worse. EXEC was so
bad that no one would attempt an exec over a few dozen lines and those
were pretty much straight line code. Mostly just a bunch of commands
that got executed in the same order every time with a few variables to
change paraneters like filenames, etc. With EXEC2, it sorta looked a
little like a programming langauge so brave and foolhardy folks
attempted delay suicide (actually, for their successors) by writing
huge execs.

--
Using Personal Rexx for Windows 3.50 from Quercus
OS: Win 2K
0
LurfysMa
11/13/2006 4:52:04 PM
On Mon, 13 Nov 2006 08:28:51 -0500, "Shmuel (Seymour J.) Metz"
<spamtrap@library.lspace.org.invalid> wrote:

>In <9FM5h.26239$pq4.25115@tornado.ohiordc.rr.com>, on 11/12/2006
>   at 09:48 PM, "John" <someone@microsoft.com> said:
>
>>I was curious if anyone knew why uninitialized variables in REXX
>>resolve to  their name?
>
>Because it's extremely useful for the target application, which was
>command procedures. When you're using a shell, do you really want to
>quote each command name and constant parameter?

That's right, but Mike realized that Rex offered so much capability
that, except for very simple, mostly straight-line execs, relying on
the command name (such as "DIR") to not be used somewhere else in the
code was very poor coding technique and is, I believe, specifically
advised against in most Rexx documentation.

--
Using Personal Rexx for Windows 3.50 from Quercus
OS: Win 2K
0
LurfysMa
11/13/2006 4:54:18 PM
In <la8hl2pm4oh9kcad135io8hu965shh4707@4ax.com>, on 11/13/2006
   at 08:52 AM, LurfysMa <invalid@invalid.invalid> said:

>My point was not whether it was true, but whether Glatt knew whether
>it was true or was just guessing.

Does the fact that he's in my twit list give a clue to my evaluation?
;-)

>Even a stopped watch is right twice a day.

But a broken watch may be right less often ;-)

>In my opinion, EXEC2 made thyings much worse.

I considered EXEC2 to be (mostly) an improvement. But I dropped it
like a hot rock once REXX was available.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
Shmuel
11/13/2006 5:36:55 PM
In <am8hl2tashkav8kqk6bhrl7chcc3quoj76@4ax.com>, on 11/13/2006
   at 08:54 AM, LurfysMa <invalid@invalid.invalid> said:

>That's right, but Mike realized that Rex offered so much capability
>that, except for very simple, mostly straight-line execs, relying on
>the command name (such as "DIR") to not be used somewhere else in the
>code was very poor coding technique and is, I believe, specifically
>advised against in most Rexx documentation.

While I don't go as far as advocating enabling NOVALUE or even just
avoiding the usage, my Safe REXX article does advise caution.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
Shmuel
11/13/2006 5:47:25 PM
>>My VM documentation calls it REXX. I believe that Rex was a prerelease
>>name.

>LurfysMa
>It's been a long time, but I'm pretty sure that the name Rex was in
>use after it had been "released" to VM customers. I could be wrong.

Is it true, or are you just guessing?
0
Jeff
11/13/2006 8:01:12 PM
>LurfysMa
>The point is that Glatt's comments are just his opinions, even if they
>are presented as facts.

That's ironic coming from someone who insisted that REXX was always originally
called Rex, and he should _know_ because he was allegedly "there from the
beginning", but when challenged on this point conceded "I could be wrong".

>there's knowledge and everything else. Glatt's comments fall
>into the latter category

And so do yours apparently, by your very own admission.

>They are just not accurate.

Then by your own standards, neither are your own comments. And after all, even
if you _may_ be right about something, as you've pointed out, "even a stopped
watch is right twice a day".

I think this is a fine example of someone being hoist upon his own petard.
0
Jeff
11/13/2006 8:05:58 PM
Jeff Glatt wrote:
>>> My VM documentation calls it REXX. I believe that Rex was a prerelease
>>> name.
> 
>> LurfysMa
>> It's been a long time, but I'm pretty sure that the name Rex was in
>> use after it had been "released" to VM customers. I could be wrong.
> 
> Is it true, or are you just guessing?


As I remember it, Rex was the name that Mike C came up with.  Rexx was 
the product name.   I also am fairly sure Rex predated VM/SP.

There were no sysadmins in the early days of VM.  There were operators 
and programmers.  The operators ran the systems and the programmers 
maintained them.

Roy
0
Roy
11/13/2006 8:40:13 PM
In article <9vafl2lvf9jfu8sbibads60jtjc2bpu6kk@4ax.com>,
   Jeff Glatt <jglatt@spamgone-borg.com> wrote:
> >John I was curious if anyone knew why uninitialized variables in
> >REXX resolve to their name?

> Several people have expounded upon unitialized REXX variables, but no
> one has yet answered "why". Jeremy came close when he pointed out
> that the implementation makes it easier for "non-programmers".

> The real reason is because REXX was created (by an IBM employee)
> first and foremost to fill one particular need -- as a "batch
> language" for sysadmins (ie, non-programmers) working on IBM
> mainframes.

The only problem I have with that statement is that in both the VM and
MVS sites I've worked in, these "sysadmins" mainly could program.  It's
just that programming wasn't their main job.  So a language that could
be used to glue something together and would "just work" was really
useful.  It was much easier for these "sysadmins" to write a quick bit
of rexx than - say - an assembler program.

I'm not entirely sure where Jeff's proto "sysadmin" fits into a typical
mainframe site.  I've never met anyone whose VM or MVS job title was
"sysadmin" - it's a name I only associate with Unix sites, or latterly
PC networks.  The people I know who used rexx were generally systems
programmers, database admins, storage admins etc.  Despite "admin" in
these names, all these people had very technical jobs.

-- 
Jeremy C B Nicoll, Edinburgh, Scotland - my opinions are my own.
0
Jeremy
11/13/2006 10:16:02 PM
In article <unngl2h851dbc7c47p2n0oabshtljmvd43@4ax.com>,
   Jeff Glatt <jglatt@spamgone-borg.com> wrote:

> There was no need for just another programming language on IBM
> mainframes. What was needed was a simple text-based language that
> could be used as a batch language for sysadmins in charge of running
> IBM mainframes.

You seem to misunderstand; VM already had two such languages known as
EXEC and EXEC2.  They weren't brilliant but they were both better than
- say - DOS's BAT language.

MVS had CLIST which was a bit like EXEC2.

REX(X) was a massive improvement.  It was certainly needed. 

> A language that had features (as I've described in my previous
> message) that are very much like DOS' batch language. That was what
> IBM needed to entice people to buy more of its mainframes.

Don't be nuts.  The people who decided if anyone's mainframe should be
bought didn't make the decision based on what scripting tools the techy
staff would be using.  They did it based on things like hardware
reliability, IBM's hardware servicing capability, worldwide support etc.

-- 
Jeremy C B Nicoll, Edinburgh, Scotland - my opinions are my own.
0
Jeremy
11/13/2006 10:28:52 PM
On Mon, 13 Nov 2006 15:01:12 -0500, Jeff Glatt
<jglatt@spamgone-borg.com> wrote:

>>>My VM documentation calls it REXX. I believe that Rex was a prerelease
>>>name.
>
>>LurfysMa
>>It's been a long time, but I'm pretty sure that the name Rex was in
>>use after it had been "released" to VM customers. I could be wrong.
>
>Is it true, or are you just guessing?

Not that you really care other than to make an argument, but I am 100%
positive that the original name was "Rex". It became "Rexx" when they
(IBM) went to get a copyright or trademark or whetever. I am pretty
sure, but not 100% positive, that the customers had access to Rex
before it was Rexx.

Got that?

I am 99.99% certain that most of what you said was concocted out of
the air and filtered through whatever you were smoking at the time.
;-)


--
Using Personal Rexx for Windows 3.50 from Quercus
OS: Win 2K
0
LurfysMa
11/13/2006 11:32:30 PM
On Mon, 13 Nov 2006 12:47:25 -0500, "Shmuel (Seymour J.) Metz"
<spamtrap@library.lspace.org.invalid> wrote:

>In <am8hl2tashkav8kqk6bhrl7chcc3quoj76@4ax.com>, on 11/13/2006
>   at 08:54 AM, LurfysMa <invalid@invalid.invalid> said:
>
>>That's right, but Mike realized that Rex offered so much capability
>>that, except for very simple, mostly straight-line execs, relying on
>>the command name (such as "DIR") to not be used somewhere else in the
>>code was very poor coding technique and is, I believe, specifically
>>advised against in most Rexx documentation.
>
>While I don't go as far as advocating enabling NOVALUE or even just
>avoiding the usage, my Safe REXX article does advise caution.

Yep, and I quote every literal. It's slightly less readable, but
infinitely more maintainable.

--
Using Personal Rexx for Windows 3.50 from Quercus
OS: Win 2K
0
LurfysMa
11/13/2006 11:35:43 PM
"Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> wrote in 
message news:45587c79$8$fuzhry+tra$mr2ice@news.patriot.net...
> In <MWT5h.29231$Cq3.341@tornado.ohiordc.rr.com>, on 11/13/2006
>   at 06:05 AM, "John" <someone@microsoft.com> said:

<snip>

I recall a Naspa article by Sam Golob about a year ago where he said one of 
the biggest challenges facing the mainframe world today is Y2K technology 
run by sysprogs with 80s mindsets/skillsets.  And I see this every day, this 
unwillingness to embrace these massive changes.  So I guess that's why I say 
mainframes are behind, for, if you drive a hi-performance race car 35MPH to 
the corner store, it's realistically not a race car, regardless of what's 
under the hood.

Yes, I am just making (perhaps unfair) assumptions on the philosophies of 
your average mainframe sysprog/admin based on my limited-scope experience. 
The few to whom my stereotypes don't apply will naturally take umbrage & 
argue otherwise (because they think I'm talking about THEM, just because 
they're mainframe, but they're not the average), but to the majority of whom 
I feel it does apply, they will never know or care because they don't have 
the slightest interest in computers enough to even pop on USENET, a 
listserv, etc., to find out about all the great stuff IBM's provided for 
them.

I doubt Sam would have said that if it wasn't true.

But anyway, I've gotten all my answers.  Amidst the debacle I've apparently 
created in this thread, you & that Jeff guy seem to have hit it on the nose 
with how unquoted literals are less confusing in a shell environment. 
Thanks! 


0
John
11/14/2006 12:06:43 AM
>John
>Amidst the debacle I've apparently 
>created in this thread, you & that Jeff guy seem to have hit it on the nose 
>with how unquoted literals are less confusing in a shell environment. 

Well it makes perfect sense, doesn't it? I mean, if it were not intended to be
used as a batch language, why in hell would the language assume that any
instruction it didn't understand was an external program to be run, and passed
text arguments, just like that line had been typed at a text terminal? Only
batch languages are designed like that. You don't get that behavior in C, C++,
Fortran, Java, Basic, etc.
0
Jeff
11/14/2006 12:47:35 AM
In <4e8556a19bJeremy@omba.demon.co.uk>, on 11/13/2006
   at 10:16 PM, Jeremy C B Nicoll <Jeremy@omba.demon.co.uk> said:

>I'm not entirely sure where Jeff's proto "sysadmin" fits into a
>typical mainframe site.

I never heard or saw the term in use at any mainframe site in the
VM/SP timeframe. He's blowing smoke.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
Shmuel
11/14/2006 2:09:04 AM
In <4e8557ce16Jeremy@omba.demon.co.uk>, on 11/13/2006
   at 10:28 PM, Jeremy C B Nicoll <Jeremy@omba.demon.co.uk> said:

>MVS had CLIST which was a bit like EXEC2.

CLIST, while it had warts, was much better than EXEC2, at least since
OS/VS2 R3.6. As I recall, that came out before VM/SE.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
Shmuel
11/14/2006 2:12:19 AM
in 35079 20061114 004735 Jeff Glatt <jglatt@spamgone-borg.com> wrote:
>>John
>>Amidst the debacle I've apparently
>>created in this thread, you & that Jeff guy seem to have hit it on the nose
>>with how unquoted literals are less confusing in a shell environment.
>
>Well it makes perfect sense, doesn't it? I mean, if it were not intended to be
>used as a batch language, why in hell would the language assume that any
>instruction it didn't understand was an external program to be run, and passed
>text arguments, just like that line had been typed at a text terminal? Only
>batch languages are designed like that. You don't get that behavior in C, C++,
>Fortran, Java, Basic, etc.

Rexx was written for VM/CMS which did not have the concept of "batch" because
it didn't run "jobs".  (There was CMSBATCH but that was something else entirely).

I have a copy of "REX PRINTCC" (on green-line) dated August 1980 and 
nowhere does it use the word "batch".
0
Bob
11/14/2006 8:26:15 AM
>Bob Martin
>Rexx was written for VM/CMS which did not have the concept of "batch" because
>it didn't run "jobs".  (There was CMSBATCH but that was something else entirely).
>I have a copy of "REX PRINTCC" (on green-line) dated August 1980 and 
>nowhere does it use the word "batch".

Regardless of the terminology used (and IBM tends to make up all manner of
terminology in its "papers"), the concept is what it is. REXX was obviously
designed to be used like a batch language, because the concept of regarding
unrecognized "instructions" as commands to be issued to the "shell" to be run,
is the quintessential feature of a batch language.
0
Jeff
11/14/2006 7:54:00 PM
In article <H4f6h.15096$GX2.6997@newsfe7-gui.ntli.net>,
   Bob Martin <bob.martin@excite.com> wrote:

> Rexx was written for VM/CMS which did not have the concept of "batch"
> 
Jeff means "batch" in the sense of MSDOS's .BAT language, not in the
OS/ MVS/ OS/390 etc meaning, I think.

-- 
Jeremy C B Nicoll, Edinburgh, Scotland - my opinions are my own.
0
Jeremy
11/14/2006 9:18:59 PM
Jeff Glatt wrote:
>> Bob Martin
>> Rexx was written for VM/CMS which did not have the concept of "batch" because
>> it didn't run "jobs".  (There was CMSBATCH but that was something else entirely).
>> I have a copy of "REX PRINTCC" (on green-line) dated August 1980 and 
>> nowhere does it use the word "batch".
> 
> Regardless of the terminology used (and IBM tends to make up all manner of
> terminology in its "papers"), the concept is what it is. REXX was obviously
> designed to be used like a batch language, because the concept of regarding
> unrecognized "instructions" as commands to be issued to the "shell" to be run,
> is the quintessential feature of a batch language.

Not sure why you regard this feature as making it a "batch" language. It 
is a characteristic of many scripting languages, but using the word 
"batch" here seems rather meaningless, unless as someone else suggested 
you are using the MS-DOS [per]version of the term.

Graham.
0
Graham
11/15/2006 4:07:22 AM
On Sun, 12 Nov 2006 21:48:53 GMT, "John" <someone@microsoft.com>
wrote:

>I was curious if anyone knew why uninitialized variables in REXX resolve to 
>their name?  Is it because REXX variables aren't declared or "typed", like 
>in C?  I mean, in C or Perl, uninitialized variables resolved to null or 0, 
>based on type (I think in Perl their initial value is based on context).
>

In C, uninitialized variables, other than those with static duration,
are not automatically initialized.  Any attempt to evaluate an
uninitialized variable results in undefined behavior.


Remove del for email
0
Barry
11/20/2006 1:17:48 PM
Reply: