Using 7.6.2, there appears to be a problem with the DATEMOV function when moving an input date to the EOW. Using an input date of today (29/09/2009) gives an erroneous date of 35/09/2009. I am still checking out various system settings etc. but this is on a process that has been running every Tuesday without problem - until today!

The question is, are any of you on other releases hitting this problem?

Please run the following code on your system and reply to this topic with the output, especially if you encounter a problem. We should then be able to provide IB with a wide view of releases with a problem. Please remember to advise what platform and OS you are running on, if it is not already contained within your signature.

Thanks to all who respond.

T

-SET &WeekBOW = DATEMOV(20090929, 'BOW');
-SET &WeekEOW = DATEMOV(20090929, 'EOW');
-? &Week
? SET BUSDAYS
? SET WEEKFIRST
? SET YRTHRESH
? SET DEFCENT
? REL

Results

 CURRENTLY DEFINED & VARIABLES STARTING WITH 'Week':
 &WeekBOW      = 20090931
 &WeekEOW      = 20090935
 BUSDAYS              _MTWTF_
 WEEKFIRST                  2
 YRTHRESH                  50
 DEFCENT                   19
 EDA762 Release * Current Software:
 EDA762 Release RELEASE = R720762B
 EDA762 Release GEN_NUM = 209
 EDA762 Release SOURCE_DATE = 06/26/2007 18:26:02
 EDA762 Release BUILD_DATE = 06/26/2007 20:41:53
 EDA762 Release INSTALLATION_DATE = 8/15/2007 09:16:24

Please note that input date is in the incorrect format. I cannot delete this post unfortunately so I will include the cor4rected code below!!

This message has been edited. Last edited by: Tony A,

Tony,

the problem still exists in 7.6.8.

CURRENTLY DEFINED & VARIABLES STARTING WITH 'Week':
&WeekBOW = 20090931
&WeekEOW = 20090935
BUSDAYS _MTWTF_
WEEKFIRST 7
YRTHRESH 0
DEFCENT 19
EDA768 Release * Current Software:
EDA768 Release RELEASE = R720768B
EDA768 Release GEN_NUM = 329
EDA768 Release SOURCE_DATE = 01/06/2009 18:09:39
EDA768 Release BUILD_DATE = 01/06/2009 21:05:23
EDA768 Release INSTALLATION_DATE = 8/24/2009 10:46:40

DS 7.6.8 on Vista 64-bit, Tomcat 5.5

Rgds
Håkan

Håkan,

As I have mentioned above, the code I was using is actually incorrect - a moment of morning mental aboration

The correct method should be -

-SET &WeekBOW = DATECVT(DATEMOV(DATECVT(20090929,'I8YYMD','YYMD'), 'BOW'),'YYMD','I8YYMD');
-SET &WeekEOW = DATECVT(DATEMOV(DATECVT(20090929,'I8YYMD','YYMD'), 'EOW'),'YYMD','I8YYMD');
-? &Week

Just goes to show that we all have off days

T

 CURRENTLY DEFINED & VARIABLES STARTING WITH 'Week':
 &WeekBOW      = 20090928
 &WeekEOW      = 20091002
 BUSDAYS              _MTWTF_
 WEEKFIRST                  7
 YRTHRESH                  20
 DEFCENT                   20
 EDA766 Release * Current Software:
 EDA766 Release RELEASE = R720766B
 EDA766 Release GEN_NUM = 293
 EDA766 Release SOURCE_DATE = 07/17/2008 14:09:39
 EDA766 Release BUILD_DATE = 07/17/2008 15:31:01
 EDA766 Release INSTALLATION_DATE = 12/22/2008 12:06:50

Tony, I am on AIX, 32-on-64 bit server, release 7.6.6 with a 7.6.5 WF client. Let me know if there is anything else you want me to try.

Ginny,

The only problem seems to be my coding at the moment - the grey cells are revolting!!

Thanks for your time though!

T

I understand. I'm on the downhill slide myself and getting very near the bottom of the hill.

How about this one...

-SET &Test = '0         ' ;
-SET &Len  = ARGLEN(&Test.LENGTH,&Test,'I2') ;
-SET &Result = SQUEEZ(&Test.LENGTH,&Test,'A&Len.EVAL') ;
-TYPE "&Result"

In 7.1.6 returns "0"
In 7.6.6 returns (FOC36355) INVALID TYPE OF ARGUMENT #2 FOR USER FUNCTION SQUEEZ

Seems that it needs at lease one non numeric to work.

I already found the SQUEEZ function problem - Case 51942518. They determined that it was a bug and say it is fixed in interim release 7.6.10.

While we're on the subject of changes between versions, has anyone noticed that the calendar controls on HTML launch pages created in earlier WF releases disappear now? If you recreate the launch page, the new syntax that generates works properly, but the old syntax and classes do not work w/ 7.6.9 client.

Thanks Darin, I guess I'll get an RDUP

quote:

In 7.1.6 returns "0"
In 7.6.6 returns (FOC36355)

Yet another reason why I'm partial to 7.1.6 - buggy subsequent releases

T

FYI

In 7.6.6, and 7.6.9 a join to a hold file of more than 2gb, fails with (FOC1006).

Works in 7.1.6

I've got a case in with IBI

quote:

In 7.6.6, and 7.6.9 a join to a hold file of more than 2gb, fails with (FOC1006).

Works in 7.1.6

I'm sure IB are very happy that I keep being fed with reasons for sticking with the 7.1.6 relase

T