Uninitialized variables, why do they equal their name?
John
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!
Mark V
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.
Jeremy C B Nicoll
John <som...@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.
rony
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
LurfysMa
<Rony.Fl...@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
John
"Jeff Glatt" <jgl...@spamgone-borg.com> wrote in message
news:9vafl2lvf9jfu8sbi...@4ax.com...
> >John
>>I was curious if anyone knew why uninitialized variables in REXX resolve
>>to
>>their name?
>
> 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...
;-)
LurfysMa
<jgl...@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.
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.
John
"LurfysMa" <inv...@invalid.invalid> wrote in message
news:qj3gl2dcf4agl3psi...@4ax.com...
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!).
Shmuel (Seymour J.) Metz
at 04:00 PM, LurfysMa <inv...@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 spam...@library.lspace.org
Shmuel (Seymour J.) Metz
at 06:05 AM, "John" <som...@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
at 10:40 PM, LurfysMa <inv...@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
at 09:48 PM, "John" <som...@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
at 12:05 AM, rony <Rony.Fl...@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
LurfysMa
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.
LurfysMa
<jgl...@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.
LurfysMa
<spam...@library.lspace.org.invalid> wrote:
>In <qj3gl2dcf4agl3psi...@4ax.com>, on 11/12/2006
> at 10:40 PM, LurfysMa <inv...@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.
LurfysMa
<spam...@library.lspace.org.invalid> wrote:
>In <9FM5h.26239$pq4....@tornado.ohiordc.rr.com>, on 11/12/2006
> at 09:48 PM, "John" <som...@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.
Roy
>>> 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.
>
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
Shmuel (Seymour J.) Metz
at 08:52 AM, LurfysMa <inv...@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
at 08:54 AM, LurfysMa <inv...@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.
Jeremy C B Nicoll
Jeff Glatt <jgl...@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.
LurfysMa
<jgl...@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.
;-)
LurfysMa
<spam...@library.lspace.org.invalid> wrote:
>In <am8hl2tashkav8kqk...@4ax.com>, on 11/13/2006
> at 08:54 AM, LurfysMa <inv...@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.
Jeremy C B Nicoll
Jeff Glatt <jgl...@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.
John
message news:45587c79$8$fuzhry+tra$mr2...@news.patriot.net...
> In <MWT5h.29231$Cq3...@tornado.ohiordc.rr.com>, on 11/13/2006
> at 06:05 AM, "John" <som...@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!
Bob Martin
>>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.
>
>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".
Shmuel (Seymour J.) Metz
at 10:28 PM, Jeremy C B Nicoll <Jer...@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
at 10:16 PM, Jeremy C B Nicoll <Jer...@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.
Jeremy C B Nicoll
Bob Martin <bob.m...@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.
Graham
>> 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".
>
> 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.
Barry Schwarz
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