I’m trying to use the next business day functions in Dialog Manager and am getting very erratic results. The following code will be working just fine but then suddenly start returning 19001231 after making a seemingly insignificant change like adding another -SET line. I can undo the change I made but the NBD functions remain "corrupted".

-DEFAULT &INPUTDATE = &YYMD
SET BUSDAYS = _MTWTF_
SET HDAY = 2008

-SET &_RUNDATE = &INPUTDATE.EVAL;
-SET &_CURRENT_BUSINESS_DAY = DATECVT(DATEADD(DATECVT(&_RUNDATE,'I8YYMD','YYMD'), 'BD', 0), 'YYMD', 'I8YYMD');
-SET &_NEXT_BUSINESS_DAY_BD = DATECVT(DATEADD(DATECVT(&_RUNDATE,'I8YYMD','YYMD'), 'BD', 1), 'YYMD', 'I8YYMD');
-SET &_NEXT_BUSINESS_DAY_NBD = DATECVT(DATEMOV(DATECVT(&_RUNDATE,'I8YYMD','YYMD'), 'NBD'), 'YYMD', 'I8YYMD');

-TYPE RUNDATE = &_RUNDATE
-TYPE CURRENT_BUSINESS_DAY = &_CURRENT_BUSINESS_DAY
-TYPE NEXT_BUSINESS_DAY_BD = &_NEXT_BUSINESS_DAY_BD
-TYPE NEXT_BUSINESS_DAY_NBD = &_NEXT_BUSINESS_DAY_NBD

When it works returns..

RUNDATE = 20080129
CURRENT_BUSINESS_DAY = 20080129
NEXT_BUSINESS_DAY_BD = 20080130
NEXT_BUSINESS_DAY_NBD = 20080130

When it stops working returns..

RUNDATE = 20080129
CURRENT_BUSINESS_DAY = 19001231
NEXT_BUSINESS_DAY_BD = 19001231
NEXT_BUSINESS_DAY_NBD = 19001231

As suddenly as it stops working it may suddenly start working again. Sometimes after a copy and paste into a new FEX. Other times after an hour. Other times the next day.. etc. Very strange.

-Dave

Sounds as if you are running into a caching issue in the browser. What happens if you do and empty cache in the browser?

Is the input coming from the 'calendar' input, if so what are the defaults set in it.

Firstly, you cannot assign a defaul variable value of a variable -

-DEFAULT &INPUTDATE = &YYMD

Secondly, what is happening is that the input date value being passed to your DM functions is invalid and therefore returning 0 which equates to the base date, which for WebFOCUS is 31/12/1900.

Even though your displayed output shows that the date input was 20080129 the DATEMOV and DATECVT functions consider it an invalid date. Remove the allocation of your holiday file and test the failing version to see what results you get.

T

This does look a bit buggy, or maybe not supported. The issue is with the holiday file and DM.

If you take the holiday file away, the code will work, add the holiday file in and the first run will work, (ignoring the holiday file) and any subsequent run will fail until the server is restarted or the process uses a different agent.

In reporting it is fine.

Tony, I would think that using
-DEFAULT &INPUTDATE = &YYMD
would be acceptable with DM, though I would generally use
-DEFAULT &INPUTDATE = &YYMD.EVAL
Is that not legal?

Alan,

I'm sure there was a discussion on defaulting a variable to another variable. I'm sure it works in some situations, but is it documented and supported? Who knows? I'm sure Francis will chip in any moment (or at least when the sum reaches Canada ) as regards documented or not.

Myself, I've had mixed results with this type of code and many moments of sanity checking when I think "I am sure this worked last time!".

But as we all know, as time goes by the grey cells deteriorate whilst the grey hair grows. Myself I prefer to think of grey hair as a change of pigmentation

T

Personnaly, I wouldn't use the -DEFAULT with another & variable. The reason is, is that after the -DEFAULT runs, in this case, the contents of &INPUTDATE is &YYMD not the contents of &YYMD. Hence the need to use .EVAL on the -SET &_RUNDATE.

I took the -DEFAULT out and ran this through using every holiday in 2008 along with several weekend days and it works just fine, every time.

In which case it looks as though there is a bug in 7.6, as this definitely fails in 7.6 but jgelona has it working in 7.1.

I had a similar problem recently. The following code:

SET HDAY = 2008
SET BUSDAYS = _MTWTF_
-SET &YYMD = 20080102;
-SET &CDATA =DATECVT(&YYMD ,I8YYMD,YYMD);
-SET &TDATE1 = DATEMOV(&CDATA, 'PBD');
-SET &CUR_BUS_DATE =DATECVT(&TDATE1 , YYMD, I8YYMD);
-SET &TDATE2 = DATEMOV(&CDATA, 'NBD');
-SET &NEXT_BUS_DATE =DATECVT(&TDATE2 , YYMD, I8YYMD);

If your calculation is going beyond the year 2008, add the next year or the previous years holidays to your holiday file.

Hope this helps.

Jenny

Please update your signature so we know what version you are using.

Your code also fails in 7.6.4

Alan,

Thanks for the advice. We killed all agents using the server console and the code suddenly worked the first time we ran it. Each subsequent run fails until we kill the agent again. It also now seems to ignore our holiday file as well.

-Dave

This message has been edited. Last edited by: 3RDCC,

Dave

I would open a case with IB.

Running this DM code twice on the same agent causes it to fail, also the dates in the holiday file are being ignored.

Thanks Alan. We will do just that.

James Miranda from our Information Builders Customer
Support IRT group has provided the following update on 02/05/2008
at 04:34PM.

David,

You issue was that you just needed to add a -RUN after your two SET statments.

-SET &ECHO=ALL;
-DEFAULT &INPUTDATE = &YYMD.EVAL
SET BUSDAYS = _MTWTF_
SET HDAY = 2008
-RUN

Sincerely,
Jim


The -RUN did the trick!!

Thanks Jim,

-Dave

Just wanted to bump this post and say thanks as well, the -RUN after setting the HDAY fixed the DATEDIF problem (for 'BD').

As far as I can tell, you can never have too many -RUN statements.

One of us should have noticed the original code posted by 3RDCC needed a -RUN after the non-Dialogue Manager code SET HDAY...

Yes Francis, but in January who was a real Virtuoso....LOL

I still don't see the reason for that RUN command unless I follow your statement ...
RUN after the SET commands as a default ?

Frank,

I'm not a believer in too many -RUN commands but if you have a situation where you have DM commands followed by WF commands followed by DM commands that make use of something created by the WF commands, then because of the way that the parsing is done, you need to put the -RUN after the WF commands so that they are executed before the second set of DM commands.

Does that make it clearer?

RUN

Clear the stack of all commands to that point and start anew.

Trouble with being an interpretive language. First error hit it dies, clean it up and get another and so on. It is still a great tool though.

Tony A wrote:

quote:

Firstly, you cannot assign a default variable value of a variable -

-DEFAULT &INPUTDATE = &YYMD

Actually you can (which can sometimes be usefull); that part of Dave's code was fine all along.

Try executing

-DEFAULT &_INPUTDATE = &YYMD
-SET &_RUNDATE = &_INPUTDATE.EVAL;
-? &_

It displays

CURRENTLY DEFINED & VARIABLES STARTING WITH '_':
&_INPUTDATE = &YYMD
&_RUNDATE = 20080722

-DEFAULT (unlike -SET) does not perform substitution on the RHS. The &YYMD is treated as a literal.

But the .EVAL in Dave's
-SET &_RUNDATE = &INPUTDATE.EVAL;
makes up for that, by causing a two-stage evaluation:

The first phase (triggered by .EVAL) rewrites the statement as
-SET &_RUNDATE = &YYMD;
based on the character value of &INPUTDATE

The second phase executes that, and the normal operation of -SET resolves the & variable reference on the RHS -- so in effect you have (say)
-SET &_RUNDATE = 20080722;