Having some problems passing the value of our time dimension to an operational report. I think we followed the standard as far as passing a dimension (see code below) -- however we're not having any luck getting values to go through. Should the time dimension behave the same? Any examples?
Thanks!

-DEFAULT &TIME = ' ';
-DEFAULT &TIME_LEVEL01_VALUE = ' ';
-DEFAULT &TIME_LEVEL02_VALUE = ' ';
-DEFAULT &TIME_LEVEL03_VALUE = ' ';
-SET &DIM_NAME = 'TIME';
-SET &DIM_VALUE = &TIME;
-INCLUDE gadg_dim_parms
-SET &TIMEYR = IF &TIME_LEVEL01_VALUE NE ' ' THEN TRUNCATE(&TIME_LEVEL01_VALUE) ELSE ' ';
-SET &TIMEQTR = IF &TIME_LEVEL03_VALUE NE ' ' THEN TRUNCATE(&TIME_LEVEL02_VALUE) ELSE ' ';
-SET &TIMEMO = IF &TIME_LEVEL03_VALUE NE ' ' THEN TRUNCATE(&TIME_LEVEL03_VALUE) ELSE ' ';  

Trav,

Interesting question. Behind the scenes, PMF manages a whole swarm of Dialogue Manager variables to keep track of where it is and where it is going. The gadg_dim_parms.fex does not pick up everything.

We are planning on adding this functionality into the next PMF release (which we are hard at work on!).
If you need this functionality sooner, you are more than welcome to experiment. Here's what you will need to do:

In the mainstreet folder you will find run_launch_pages.fex. This is the program that runs the Operational Report. You can either make a copy of this program into another app folder and concatenate that folder in front of your app path, or you can edit the program in the mainstreet folder (but be sure to make a backup copy first!)

Next, you must make two changes to this program. On line 237, you will see -GOTO :S04; change this to GOTO :S03_F. Then on line 300, you will see this code:

 ROW_LVL_SEC    = &ROW_LVL_SEC &PERSP &OBJ &MEAS &PARMS 

change it to this:

 ROW_LVL_SEC    = &ROW_LVL_SEC &PERSP &OBJ &MEAS &TRNG &PARMS 

Now you are ready to code your Operational Report. The first thing to do is to get the PMF Dialogue Manager variables. Code this in the beginning of your operational report:

 -SET &SCORECARD_NM = ' ' ;
-INCLUDE FOCEXEC_INFO

-INCLUDE A_GETPERID 
-INCLUDE PMF_ANALYSIS_PARMS
-? & 

when you run this, you will see all the PMF variables. Near the bottom you will see something like this:

  &WHERE_CNT    = 9
 &WHERE_DIM    =  WHERE  TIME_LEVEL0102_VALUE  GE '20061' AND  TIME_LEVEL0102_
 &WHERE_DIM01  = WHERE LOCATION_LEVEL01_VALUE EQ 'EAST'
 &WHERE_DIM02  = WHERE PRODUCT_LEVEL01_VALUE EQ 'Analog'
 &WHERE_DIM03  = WHERE LOCATION_LEVEL02_VALUE GT ' '
 &WHERE_DIM04  = WHERE PRODUCT_LEVEL02_VALUE GT ' '
 &WHERE_DIM05  =  WHERE  TIME_LEVEL0102_VALUE  GE '20061' AND  TIME_LEVEL0102_
 

These are the WebFOCUS WHERE statements. You can then parse these out to pass to your own code. Good luck and let us know how this works for you!

Eric Heilner

This message has been edited. Last edited by: EricH,

Is it fair to say that all dimensions (including the time dimension) will be handled the same way in the next release? By that I mean the method I described above (or at least some consistent method) would work even for the time dimension?

If I can make my case now, I'd say that it probably should in order to stick to that "framework" idea that you have going so far.

In the mean time, I'll play around with what you described and see if I can get it to work.
Thanks!

Yes, Time should use the same methodology (dimname_LEVELnn_VALUE) as the others.

Except that:

Time is a special dimension. You can frame requests properly with no other Dimensions but time, but your request won't return valid data without Time specified.

You can have PMF reports that show *ranges* of time. So it's possible that on a line where you're drilling to a report, *more than one time period* would be in the range for the request. For example, if you run Measures - Previous V. Current or Rolling 5 Periods, and click a Measure name, you've actually got 2 or 5 time dimension values in the same request. How would you expect that to work?

Good question -- hadn't really thought about how the ranges of time might be handled differently. In my current example, I was drilling on a single item (single time value), but you could definitely come up with other scenarios where that's not the case.

Off the top of my head, I guess you could still handle it in a similar way except you have multiple values (dimname_LEVELnn_VALUEnn)? You would then need some way to figure out how many values there were.

That may not be the most efficient way to do it, but that's all I've got on a Monday.