Re: Compute Date Duration

Simon,

This is what I've seen when I tried the instruction.

However for my purpose I will compute the duration in days in a faster way.

Matsobj returns the last use of an object in a *dts char(8) but only the
first bin(2) is significant.

Matmatr returns the full timestamp but we can use the first bin(2).

The difference between these two numbers should be the number of days.

The Era and Calendar table in the latest MI functional reference for
Gregorian in 1721426 while in the previous edition was 1721424 but it seems
that both values are accepted.

Regards.
Giuseppe.


----- Original Message ----- 
From: "Simon Coulter" <shc@xxxxxxxxxxxxxxxxx>
To: "MI Programming on the AS400 / iSeries" <mi400@xxxxxxxxxxxx>
Sent: Tuesday, October 18, 2005 3:09 PM
Subject: Re: [MI400] Compute Date Duration


> OK. Here's what some experimentation shows:
>
> CDD will calculate a duration between character format dates. This is
> consistent with the CDD instruction description which states that
> operands 2 and 3 must be character scalars. That means the only valid
> date types for operands 2 and 3 are:
> USA
> ISO
> EUR
> JIS
> System Internal Date (Scaliger number)
> *MMDDYY
> *DDMMYY
> *YYMMDD
> *YYDD
> *YYYYDDD
>
> Default separators are required for the first 5 but the last 5 can have
> any separator or no separator as long as the DDAT correctly describes
> the separator. If the specified date value does not match the DDAT then
> MCH1222 will occur.
>
> NOTE:- The scaliger number specified for the System Internal Date type
> must not exceed the end date of the Calendar (else MCH1221) nor must it
> be earlier than the start date of the Calendar (else MCH1224).
>
> CDD does not support other date formats so if you have dates in other
> formats (e.g. packed or zoned numeric) you must first convert them to a
> format that CDD does support.
>
> Most DDAT errors will cause MCH1867 but some will cause MCH5601. Errors
> in the first 58 bytes of the template will cause MCH5601.
>
> CDD always returns a Date Duration. That is an 8,0 packed decimal value
> in the form YYYYMMDD which is interpreted as YYYY years, MM months, and
> DD days. Specifying any other format type will result in MCH5601.
>
> I also discovered that if the Calendar Table is not allowed for a
> particular format type (such as Date Duration) then if you specify zero
> for the Calendar Offset you can omit the Calendar Table entirely.
>
> However the Era Table must be present (and set to X'00' for a Date
> Duration) otherwise MCH1867 is sent with reason code 19
>
> Further the DDAT_List_Size (as distinct from the DDAT_Length which can
> be anything including zero) is validated for being greater than 0 but
> otherwise seems to tolerate incorrect values. Not that I'm advocating
> doing so but it is interesting. When it is zero the #cfdate module gets
> the DDAT number wrong in MCH1867. It shows 16448 which is the value of
> an uninitialised BIN(2).
>
> So that just leaves the question of how to convert a Date Duration to a
> Labelled Duration and that can be done with maths.
>
> I haven't found an MI instruction that will generate a Labelled
> Duration. They seem to be valid only as input to the various INC and
> DEC instructions.
>
> Regards,
> Simon Coulter.
> --------------------------------------------------------------------
>     FlyByNight Software         AS/400 Technical Specialists
>
>     http://www.flybynight.com.au/
>     Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
>     Fax:   +61 3 9419 0175                                   \ /
>                                                               X
>                   ASCII Ribbon campaign against HTML E-Mail  / \
> --------------------------------------------------------------------
>
>
> _______________________________________________
> This is the MI Programming on the AS400 / iSeries (MI400) mailing list
> To post a message email: MI400@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/mi400
> or email: MI400-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/mi400.
>