When GHS encounters a RUN command, it goes to the named file and continues processing commands it finds there. (Thus we call files that contain GHS commands Run files.) You can embed a RUN command within a Run file, but it will not find its way back to the original command stream unless the /CALL parameter is included (as you see it in the title of this COW).

Then what does the module do? If you have to ask that question, chances are you don't need it. Just use /CALL without the module name and you're done.

For years we all got by without this feature. What happened was Run files got to be numerous and filled with so many names that conflicts became likely. (That is, names of macros and variables.) We needed a way to make sure the names defined in one Run file did not duplicate names in another Run file when they were used together in the same GHS session.

By assigning a module name when you run a Run file, the macro and variable names defined within it are isolated in a separate region internal to the program—called a module. So now you can protect your macros and variables from conflicts by assigning them to a module.

You get access to macros (and templates) and variables within a named module by prefixing the module name to them. For example, suppose you have a collection of macro definitions residing in a file named StandardMacs.rf, and your #1 favorite status macro is STATUS1. Then assuming that these standard macros have been loaded by,

RUN StandardMacs.rf /CALL:SM

you execute STATUS1 by including the module name as a prefix:

.SM.STATUS1

Of course within StandardMacs.rf the commands refer its own macros and variables without the prefix.

What if somewhere within StandardMacs.rf you want to access a variable or macro which was defined back in the main run file? Simply do it. It works!

"But," someone says, "what if the name in the main run file is the same as one in the module run file? How do I get at the main one?" The answer is, you simply prefix the name with a dot.

"That's weird!" they say. "Does that mean to call a macro that was defined in the main Run file I would use a double dot?"

That's right. Or if it looks better to you, use the formal EXECUTE—the command that's never used—plus one dot.

Below is a simple illustration of all this.

support@ghsport.com

www.ghsport.com