Summary: Part II in our series that teaches Rexx to absolute newbies. In this installment: learn how to make Rexx remember stuff, make decisions, and accept information from the user.

In part I of our series I covered what Rexx is good for, what its advantages are, and introduced you to your first few lines of code; a "hello world" program. As you could see, such a basic program wasn't too hard to figure out. You had a comment block at the top that not only named and described the program for your own reference, but also told OS/2 that it was dealing with a Rexx script as opposed to just another batch file. And then you had an instruction that told Rexx to SAY something. I could compare all this to falling off a log, but in reality it's somewhere between shooting fish in a barrel and finding a delicatessen in New York City. I mean it's not hard.

Before going too much further I think I should introduce the concept of variables - the means every programming language uses to store information. Or more precisely: information that can change. It's like a pigeon hole or a crack in the wall that you can stuff things into and retrieve later. Rexx will create these "pigeon holes" on the fly and as you need them. Here's an example of how to create a variable -- filling it with information at the same time -- and then using it a moment later:

/* Display how much our monthly salary is */
Salary = "Diddly squat"
Say "Your current monthly salary is:" Salary

If you were to save this as "salary.cmd" and then run it from the command prompt, it'd produce output that looks a bit like this:

[C:\WORK]salary.cmd
Your current monthly salary is: Diddly squat

You can see that in order to fill a variable with some stuff, we just had to say that it equals ("=") something. The variable's name was 'Salary', and it was created in your computer's memory the instant you made it equal something. Now wherever you use the word 'Salary' elsewhere in the program, Rexx will substitute it for whatever is stored there, in this case, how much your salary actually is. Notice that Rexx did not substitute the word "salary" that was between the quotes of the SAY command, this is because it was considered to be part of the string, and not the same as the variable. It didn't have anything to do with using a lower-case 's', since Rexx is case insensitive when it comes to variable names. If you want an example of how to use a variable in the middle of a SAY command, look at this:

/* Display how much our monthly salary is */
Salary = "Diddly squat"
Say "Your current monthly salary is:" Salary "(before taxes)"

The output would look like this when you run the program:

[C:\WORK]salary.cmd
Your current monthly salary is: Diddly squat (before taxes)

See that we closed the quotation before using the variable, then opened the quotes again when we had more to say. Try taking out the two quotes in the middle to see how Rexx treats the name "Salary" then.

Okay, so what's the point of using a variable? It's got a lot to do with making a program flexible, able to cope with changes while it's still running. If your salary was to change then you'd have to open up your editor and change the source of the Rexx program again.

To illustrate how a variable's contents can change while the program is still running, we'll introduce you to our next Rexx command: Parse Pull. Parse Pull is like the functional opposite of Say -- instead of displaying a string of words to the user, it asks for them, and it stores what the user gives it in a variable. Here's an example of where we set the initial contents of a variable and then change it later within the program itself:

/* Assume user's name is Bruce, then allow him or her to correct it */
UserName = "Bruce"
Say "For our records, we're assuming your name is" UserName
Say "If it isn't, please type your real name now, otherwise just press Enter."
Parse Pull NewName
If NewName \= "" then UserName = NewName
Say "Thank you," UserName". Our records are now complete."

Now I know I threw you a curveball there by using a command I hadn't yet introduced ("if... then....") but I think it's obvious that it makes simple decisions by comparing one value to another. I'll go over it in more detail in a moment. But first let me show you what the output of the above program would be when run:

[C:\work]name
For our records, we're assuming your name is Bruce
If it isn't, please type your real name now, otherwise just press Enter.
Michael
Thank you, Michael. Our records are now complete.

There you can see that the contents of the variable 'UserName' was changed from "Bruce" to "Michael" (or whatever else the user typed). If you're wondering why it took two words ("Parse" and "Pull"), it's because "Parse" is the command used to break up a string of words and put them into separate variables. But it needs to know where that string is coming from, and by specifying "Pull" we're telling it to get what it wants from the user's keyboard. I'll be discussing the "Parse" command in more detail in the future, since it's one of the more powerful and useful commands in Rexx. Chances are you'll be using it a lot in your scripts and macros.

But to finish off, I'll go over the "If... Then..." instruction to be sure you're comfortable with it. It usually comes in at least 4 parts: The beginning (if), the condition (NewName \= ""), the middle (then) and the conclusion (UserName = NewName). What the instruction did in our program was to make sure the user hadn't just pressed Enter before it goes ahead and overwrites the contents of 'UserName'. In detail:

• 'NewName' is the variable filled with whatever the user typed with the keyboard as the program ran
• '\=' is Rexx-speak for "does not equal". The slash before the equals sign means "does not" in simple terms. In other languages the same expression is sometimes represented as "<>" or "!=" Having three different ways of saying the same thing, neither of which are interchangeable within the same language, is a pain in the butt. But I guess it's too late to complain now <g>. Just remember that in Rexx, "=" means equals and "\=" means does-not-equal. There are other comparisons you can make, but we'll get to those in a future article.
• "" is an empty string. A string fulla nuthin'. Two quotes seated together with nothing in-between. If the user had pressed Enter instead of typing a name, then it's an empty string that would have been put into the 'NewName' variable.
• The last part of the command, "then UserName = NewName" is where the contents of the variable UserName gets filled with the contents of the variable NewName only if the comparison made earlier -- the 'if NewName \= ""' part -- is true.

In the end, the function of the If-Then command in our program is simple. If the user typed a new name, then fill the variable 'UserName' with it. If he/she didn't type a name, then just leave 'UserName' as it is.

To summarize, you've learned not only how to create a variable and fill it with something, but also how to make simple decisions and ask the user for information within your programs. Something to keep in mind when you write your own scripts is that a variable's name must not contain any spaces or punctuation (there are some exceptions, but we'll deal with them later) and should always start with a letter instead of a number. That's why our variables were named "UserName" instead of "User Name" -- Rexx would have thought 'User' and 'Name' were separate entities.

In the next article we'll cover basic arithmetic and how to glue strings of words together.