Lonely Shell Variables – Part 2

dm,var,

So what was that about dm,var,? Note that this is the file var in the dm account. This file allows you to see and modify your custom environment variables just like any other MV item, whether from the editor, TCL, BASIC, or any other processor.

You can list dm,var,. Note path syntax requires trailing comma. But this isn’t a “real” file. It’s an OSFI file like “unix”, “dos”, or “bin”, and like “peqs” which gives you file-level access to your spooler entries.

This is a small digression, but if you’re not familiar with OSFI file references, try these commands in D3 Windows:

list dos:
list c:
list peqs:

Or try this in any D3 *nix platform:

list unix:
list peqs:

And in any D3 platform, “var:” is a synonym for dm,var, so you can do this:

list var:

Why do we care about dm,var, also known as the var: file? With regard to that @Yesterday variable, all you need to do is to get a BASIC program to calculate the value of yesterday, write it into that file, and the variable will always be accurate (as long as you run the program every day). So for example:
OPEN "VAR:" ELSE STOP 201,"VAR:"
WRITE ICONV(@DATE,"D")-1 ON "YESTERDAY"

There ya go – a little two-liner that logs yesterday’s date. So run that program, and then at TCL try this:

display @yesterday

Here’s what you won’t find anywhere else…

In my first Lonely Shell Variables blog I described how you can do some neat dynamic generation of data. Even as I was writing that I thought it was a little complex. So if you’re not getting all warm and fuzzy about @vars yet, here’s another look at the topic that might help…

What if you want to generate that @Yesterday variable on the fly rather than running a program at login or from a phantom, some time ahead of your use of the value? Here are a couple example business cases where you’d want to generate data as part of the query:

  • You want a list of all of your customers who are in the lowest selling territory, but you don’t want to run another report to tell you what that territory is so that you can hard-code it into your query. It would be nice to have a statement like this:
    list customers with territory @TerritoryNeedsWork
  • You want to know how many orders were processed today with a value lower than the week’s average. You don’t want to run another process to calculate that average every time you run this report. Wouldn’t this be nice? :
    list orders with $value < @weeks.average

In those examples we want to generate a value once, and then use it with all records. Sure, you can create a subroutine that gets called from dict items, but then that will get run for every record that’s processed.

Many developers will look at those examples, give up on using an access query, and write a program to do the report – probably building the query in BASIC and then using Execute. Let’s see how to avoid that by going back to that @Yesterday variable.

2 thoughts on “Lonely Shell Variables – Part 2

Leave a Reply