× 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: Moving a date field to a numeric field
  • From: John Carr <74711.77@xxxxxxxxxxxxxx>
  • Date: 14 Jun 97 11:25:43 EDT


Joe Toff wrote:

>>I discovered something about moving a date field to a numeric field defined as
8
>>digits. I'm on V3R1.
>>
>>D Date6                        S                      6   0  Inz(061397)
>>D DateISO                   S                        D     DatFmt(*ISO)
>>D Number8                  S                      8   0
>>
>>C            *MDY           Move          Date6        DateISO
>>  *      DateISO now contains 1997-06-13
>>
>>C             *YMD           Move         DateISO     Number8
>>  *      Number8 now contains 00970613
>>
>>C             *MDY           Move         DateISO     Number8
>>  *      Number8 now contains 00061397

>Charlie wrote;
>*YMD fields can only be in the range of 1940 to 2039.  A *YMD date field is
>6 digits long.  From the ILE RPG/400 Reference  Manual:

>| When moving a value to a date field, keep in mind that factor 1 determines 
>| the number of digits to be moved. If the format of Factor 1 contains 6 
>| digits as in the case of *YMD, and Factor 2 is a numeric field, the 
>| rightmost 6 digits of Factor will be converted to the date. 

>My guess is if you initialize Number8 to 99999999 BEFORE the move, it will
>have a value of 99970613 or 99061397 AFTER the move since only the last 6
>characters will be effected.

>> Joe Toff
>>Am I missing something here, or can you not get an 8 digit date moved from
>>a data field to a numeric field? Is this unique to V3R1? Thanks for any help.

>Charlie
>You can get an 8 digit date field moved to an 8 digit numeric field if you
>use a four digit year format, e.g. *ISO, *EUR, *JIS, or *USA in factor 1.
>Charlie Massoglia, Massoglia Technical Consulting, Inc.<

I may be wrong,  But does it seems like we're introducing even more gymnastics
into our code 
with our solutions  of 8 & 9 byte numerics?    So is 00970613 a valid date or
not?
Is 00061397 a valid date or not?    The accurate answer is " It is if we
programmers & our
Programs say it is".    As charlie pointed out,  it's a classic "MOVE"  which
means if there is
junk in the left / high order side,  it will stay there.   I can see people
looking at the code now,
"Did they clear or init the high order side?"  "How big is this "Date" field,
6,8,9?"  

I don't think  Date types have these ambiguities,  but I'm probably wrong.

John Carr  
EdgeTech

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the Midrange System Mailing List!  To submit a new message,   *
* send your mail to "MIDRANGE-L@midrange.com".  To unsubscribe from     *
* this list send email to MAJORDOMO@midrange.com and specify            *
* 'unsubscribe MIDRANGE-L' in the body of your message.  Questions      *
* should be directed to the list owner / operator: david@midrange.com   *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.