RE: Date * 10000.01

At 08:40 11/19/1998 , Howard Weatherly wrote:
>I understand the overflow processing delay but I am curious about
>defining the result field large enough to prevent that from happening,
>and using the MOVEL or MOVER or whatever to get the result where you
>need it? Does doing  that result in an incorrect result? If not, would
>you still take a performance hit? or is this a useable solution?

MOVE and MOVEL still exist all right, but the multiply trick for dates uses two 
different RPG quirks, both of which are bad news performance wise. Even if the 
field is large enough (CCYYMMDD * 10000.0001 = CCYYMMDDCCYY.MMDD) you'd now 
have to move the value to alpha storage and substring out bytes 5-12 of the 
result. If you use a result field with 0 decimals, you could use MOVE to 
extract the rightmost 8 bytes, but this would result in a numeric underflow 
condition on the multiply, which I am told is almost as bad as the overflow in 
terms of processor resources. It's really a lot simpler and easier to follow if 
you do it with a data structure and MOVE operations. You can even put the 
routine in a service program and use a prototyped call like:

   eval      NewDate = FlipDate(OldDate)

That way you have minimal overhead and never have to deal with it again.

Personally, since I've been living and breathing JDE lately. I've got a 
production routine that looks like:

   If        X0028(MyDate:*OMIT:'*SYSVAL':'*JUL')
   DoStuff
   EndIf

X0028 is JDESpeak for CVTDAT. I used to think Unix was cryptic.


Pete Hall
peteh@inwave.com 
http://www.inwave.com/~peteh/

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---