Here are a couple basic rules of @variable processing:
1) @name simply echoes the current value.
So DISPLAY Today is @DATE displays the current date.
2) @`command` executes the command and renders the output of that command.
So DISPLAY Today is @`DATE` executes the DATE command and includes the output of that command in the displayed text.
Note that those quotes are BackQuotes, the quote that’s on the tilde key in english/american keysets. That’s not the same as the quote that is also on the double-quote key. Up to the D3 v7.5 reference manual, backquotes and forward quotes are incorrectly used interchangeably. Since we’re here, you’ll also see “@” and “@$” used interchangeably in that doc. You do not need the dollar sign. The doc mentions using dollar signs in user-defined vars but then doesn’t follow that convention in examples. None of the dm,bp programs use @$. If you’re concerned about finding @vars in your code, then using @$var is probably a good idea. Otherwise for temporary vars, I just use @var.
For our @Yesterday, we want to call a program that returns the value. That’s simple:
CRT (@DATE 'DI')-1 'D2/'
Put that lump of gratuitous brevity in a program like BP SHOW.YESTERDAY.
Now SET YESTERDAY=RUN BP SHOW.YESTERDAY.
If you DISPLAY @YESTERDAY you’ll just see the Run command echoed.
But DISPLAY Yesterday was `@YESTERDAY` and you’ll see the expected output.
However, you’re going to have problems if you put that into an access command like LIST or SORT. Some extra “voodoo” is required to use a statement like this:
LIST ORDERS WITH ENTRY-DATE @YESTERDAY CUST VALUE
If you try it now, using a file in your system to follow along of course, that statement results in this command being executed :
LIST ORDERS WITH ENTRY-DATE RUN BP SHOW.YESTERDAY CUST VALUE
And `@YESTERDAY` in the statement doesn’t execute the program either.
To get what we want we need one more character of syntactic sugar:
LIST ORDERS WITH ENTRY-DATE @`@YESTERDAY` CUST VALUE
Someone may get the bright idea to put that syntax into an @var to reduce the syntax back down to a simple @Yesterday. This will work but it has a more limited use. To do this, create another @var that actually executes the program:
SET EXEC_YESTERDAY=RUN BP SHOW.YESTERDAY
Now replace the original @Yesterday with a call to execute the other @var. (Yeah, I know this is turbulent water, hold on with me for just a little while longer…)
Now you can simply use @Yesterday in an access statement. The reason it works is that the new @Yesterday is evaluated when the Set command is executed and the current value is assigned at that time to @Yesterday. If you modify the program, recompile, then re-run your access statement, the value of @Yesterday will not have changed. If you then re-execute the Set statement, then run the access statement, now you’ll see the value has changed.
Again, you may actually desire that behavior, and you will get new values whenever users login rather than every time they reference an @var.