EViews.com

I have a couple of questions related to the handling of parameters that are passed to subroutines. If I run this simple example: Then I get an error message "SNAME is not defined in %sn = sname". However if I just move the position of the %sn assignment: then the program runs without error. It appears therefore that subroutine parameters become inaccessible following some kinds of file operations.

The second issue is this: if I remove the %fn=fname line, and just have: then I get an error "FNAME is not a valid string or scalar name in WFOPEN {FNAME}". Removing the curly brackets doesn't help - just gives a different kind of error. So clearly parameters passed to subroutines are not treated in the same way as ordinary variables.

To prevent these kinds of problems I now always have a few lines of code at the start of any subroutine which assign the values of any passed parameters to variables (e.g. %fn in example above) and then only use those variables in the rest of the subroutine. However this seems a bit of a work-around. Is there something I'm missing or doing wrong?

Thanks

I believe you're getting confused between string objects and string variables. You have structured your subroutines to use string objects, where you should, perhaps, be using string variables (variables with a % sign at the start). The difference between the two is subtle, but in this case, important.

Essentially a string object is something that lives in workfile space. When you create a subroutine that takes in a string object, and then call that subroutine with a literal piece of text (e.g. "example.wf1", rather than an existing string object, then EViews will create a temporary string object in your workfile equal to the text. That string object only exists in your current workfile. If you change the workfile (such as by using a wfopen command), then that string object no longer exists.

In short, you will probably find everything works to your satisfaction if you change your subroutine definitions to be:

Thanks Gareth for your very clear reply - that does indeed solve the problem.
Geoff