× 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.


  • Subject: Re: DATFMT
  • From: "David Prowak" <prowakd@xxxxxxx>
  • Date: Fri, 24 Jul 1998 10:23:58 -0400

I didn't realize that I could CHAIN to a file with a key in *JUL format,
while using an *ISO date data type field.

Thank you Hans for pointing this out, and thanks to all who 
responded.
Dave

----------
> From: Hans Boldt <boldt@ca.ibm.com>
> To: MIDRANGE-L@midrange.com
> Subject: Re: DATFMT
> Date: Friday, July 24, 1998 8:56 AM
> 
> Neil wrote:
> >Workaround:
> >
> >Hence avoid the INZ in the Data specification unless it coincides with
the
> >default date format you are using.  Looks like MDY for you.  Instead
move
> >the value in during your *INZSR.
> >
> >                MoveL    '91/164'         SURCH_DATE
> 
> And what happens if a programmer wants to change the format
> of SURCH_DATE?  Any MOVE and MOVEL statements will then have
> to be changed as well.  Use EVAL and the format is
> automatically converted for you.
> 
> I think the better question is:  Why is the program using a
> date format that does not have a 4 digit year?
> 
> As another poster stated, the current design is an example of
> "six of one, half a dozen of another".  But there are other
> good reasons for the current design.  Early on, we thought of
> having date operations in expressions.  If we did not force a
> consistent format for date literals, an expression like
> 
>             D'01/02/98' + *DAYS(1)
> 
> would be ambiguous.  Would the result be '02/02/98' or
> '01/03/98'?  Americans would expect one answer, Europeans the
> other.
> 
> Again, why use a 2-digit year date format?  Is it because the
> file you are searching in has a key in *JUL format?  No
> problem - if you code an *ISO format date field in F1 of CHAIN,
> the operation will still work.  For most uses of date fields
> in RPG, format conversions happen automatically.  So for most
> purposes, there are very few reasons for using anything other
> than the *ISO default.
> 
> Cheers!  Hans
> 
> Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com
> +---
> | 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
> +---
+---
| 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
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.