problem with eom()

[Bruce Easton]

Testing under both Linux 5.7.4.07 and 5.0.14 shows the behavior and 
requirement for the eom() function that Ken specifies.   However, IMHO, 
considering the history of differing requirements for functions over the 
years regarding expressions versus fields, it not very helpful that both 
the online manual and the screen help for eom() describe the parameter 
syntax requirement as "date_expr" or "date expression".  I'm sure clerk 
is more efficient with such strictness for functions, but the 
documentation should be clearer.  And maybe for at least the screen 
help, it now is. An early Windows filepro 5.7 still references 
"expression", but for the screen help for the 5.7.4.07, it has been 
updated.  In the new screen help for the date functions the parameters 
are referenced as "d" or "dd", and although I don't see a specific 
reference that the parameter be a cast field of some sort, there are 
examples now that conform to such a requirement.

Bruce


On 10/28/14, 9:26 PM, Kenneth Brody wrote:
> On 10/28/2014 5:42 PM, Richard Kreiss wrote:
>> Ken,
>>
>> I have tested this on my system with a long variable 
>> StartDate(10,mdyy/)= Eom(foobar(12){"/01/"{foobar(13))
>>
>> That fails even though StartDate is a date field.
>
> The destination is irrelevant.  The relevant part is that you aren't 
> *passing* a date field.
>
>> The only way I get this to work is to use another date field 
>> Idate=Foobar(12){"/01/"{foobar(13)
>>
>> Then StartDate=EOM(Idate)
>
> Exactly as I stated previously -- you need to *pass* a date to EOM() 
> in order for EOM to know what date you are using.
>
>> Since foobar(12) is 2 and foobar(13) is 2007, StartDate now comes up 
>> as "02/28/2007", which is what I am looking for.
>>
>> So, I need to modify my processing to use 2 date fields to have EOM() 
>> work properly or the other date functions.
>
> No need for 2 date fields.  Use "StartDate" both times.
>
> And how does the "bad" version of the code work in 5.7.04.06 as you 
> stated below?
>
>>> -----Original Message-----
>>> From: Kenneth Brody [mailto:kenbrody at spamcop.net]
>>> Sent: Tuesday, October 28, 2014 3:58 PM
>>> To: Richard Kreiss
>>> Cc: filepro-list at lists.celestial.com
>>> Subject: Re: problem with eom()
>>>
>>> On 10/28/2014 3:38 PM, Richard Kreiss wrote:
>>> [...]
>>>>>>>> ExpDate=foobar(12){"/01/"{foobar(13)
>>>>>>>>
>>>>>>>> Expect ExpDate = "10/31/2013"
>>>>>>>
>>>>>>> I would expect "10/01/2013".
>>>>>>>
>>>>>>>> In my processing coming up as "10/31/2014"
>>> [...]
>>>>>>> Ok, Ken, I left out
>>>>>> Eom(foobar(12){"/01/"{foobar(13))
>>>>>>
>>>>>> The result should be in year 2013. It comes 2014.
>>>>>>
>>>>>> I just wanted to know if anyone else experienced this problem.
>>>>>
>>>>> The problem is that you are not passing a date to EOM(). Rather, you
>>>>> are simply passing it a string that "looks" like a date --
>>>>> "10/01/2013".  And, even then, is it "October 1" or "January 10"?
>>>>> Because you are not passing it a date, you get the EOM of the current
>>> date, which coincidentally is also October.
>>>>
>>>>
>>>>> ExpDate = foobar(12){"/01/"{foobar(13) ExpDate = EOM(ExpDate)
>>>>
>>>> Here is an interesting twist to what you are indicating, when I run 
>>>> the same
>>> programming in 5.7.4.06, the programming works properly.
>>>
>>> Show me the exact code, because the code as posted here will always 
>>> return
>>> the end of the current month, regardless of the contents of 
>>> foobar(12) and
>>> foobar(13).
>