× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



This reminds me of something I ran into regarding storage of dates, in DS
arrays. When you specify a date in a DS, it allocates 10 bytes for the date
(probably because the format defaults to *ISO). When using DS arrays, I
sometimes bump my head on the 65535 maximum, and 10 bytes is rather
expensive when they are an element in a DS array. To assist, I store the
date in a four-byte unsigned int (10U 0), by subtracting and calculating the
number of days from the "beginning of time" (0001-01-01), and storing this
in the 10U 0. To convert back to a date type, I add the number of days back
to the beginning of time, and store it back in a date field.

Here is a sample:
D DateA S D Inz(*Sys)
D DateB S D Inz
D NumDays S 10U 0 Inz
D BegOfDays C d'0001-01-01'

/Free
*InLR=*On;

NumDays=%Diff(DateA:BegOfDays:*Days);
DateB=BegOfDays+%Days(NumDays);

Return;
/End-Free

Wacky? maybe, but saving 6 bytes per element can help sometimes. And if you
use a svc program for the conversions, it's painless.


On 10/10/05, Jon Paris <Jon.Paris@xxxxxxxxxxxxxx> wrote:
>
> >> I believe IIRC the date is actually stored as 4 byte binary...
>
> On the DASD - Yes.
>
> Other than in a dump of the DASD you will never see it in this format
> however. As the record is read by the OS the value is converted to the
> appropriate character string as specified on the type L field in the file
> (*ISO) if nothing specified. So as far as your program is concerned it is
> always a character string complete with separators.
>
> DatFmt controls how it normally comes into the RPG program. If no H-spec
> entry (and the field is not otherwise declared in a DS or whatever) then
> it
> will come in as *ISO. Note that that may mean double conversion in cases
> where a format other than *ISO was specified for the L-type field.
>
> I think the notion was to follow the behavior of numerics (i.e. all
> database
> numeric field types end up as packed unless you explicitly control them) -
> the problem is that most RPGers don't understand the rules for numerics
> (as
> is often made obvious during discussions here regarding prototyped numeric
> fields) so making dates follow similar rules turns out to be not such a
> good
> idea!
>
>
> Jon Paris
> Partner400
>
> www.Partner400.com <http://www.Partner400.com>
> www.RPGWorld.com <http://www.RPGWorld.com>
>
>
> --
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
> To post a message email: RPG400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.
>
>


--
"Enter any 11-digit prime number to continue..."
"In Hebrew SQL, how do you use right() and left()?..." - Random Thought
"If all you have is a hammer, all your problems begin to look like nails"

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.