On 22 Jul 97 at 12:45, [log in to unmask] wrote:

> If I disagree with Jim on any point, it would be that I would
> make the date fields X8 rather than Z8. Although the bit
> patterns are exactly the same (if the numbers are unsigned),
> there is no advantage in having the pattern be interpreted as
> numeric, simply because the moduli of the various portions of
> the number are  different [100 (century), 100 (year), 12
> (month), 28-31 (day)], thus two dates obviously can't be
> subtracted from each other directly.


We did exactly this during the early days of our company's
automation and found that relying solely on programming edits to
catch characters from getting into the date field was trusting
in human nature just a little too much.  We found that users
could and would on occasion enter dates as 84JUL1 for example.
So we adopted the zoned signed decimal which allowed Image to
catch any input format errors that the programmer allowed.  A
negative number was deemed to have been from the previous
century.  Now we treat negative numbers as BC dates, not that
we have any mind you.

What we do for parsing the zoned decimal field is overlay the
image date field with a character field redefine using the
powerhouse dictionary and treat the field as numeric or
character as the situation warrants.  More usually  we
parse the date field using a series of MOD and DIV statements to
extract the portion that we are interested in.

i.e

date = 19970722

current year = floor(date / 10000)
current month = floor((mod(date,10000) / 100))
current month and day = mod(date,10000)
current day of month = mod(date,100)

In Powerhouse at least these are just as efficient as a
substring extract.

Please note that I am doing these from memory and that it is
likely that there may be a syntax or logic error in the example
above.

Regards,
Jim
---
James B. Byrne                Harte & Lyne Limited
vox: +1 905 561 1241          9 Brockley Drive
fax: +1 905 561 0757          Hamilton, Ontario
mailto:[log in to unmask]  Canada L8E 3C3