Re: Moving a date field to a numeric field

[boothm@xxxxxxxxxxxxxxxxx]

This is true, but on the other hand, if the programmer uses his MOVEs
right, learns *ISO, *USA, *MDY, *YMD and the other formats, and thinks
about what he is doing with the field there is no real problem.   

It is very easy to move into and out of 6 and 8 digit fields with the MOVE
command.  If the file has the 8 digit date and is century compliant then
it will show the correct century, providing there are not other problems
in the program.  If there are, then the field will fail in a move atttempt
and should have been subjected to  TEST(D) at some earlier point.

Of course, on your screens you will want to still show the 6 digit layout
and that is really no problem to fill correctly with MOVE command, and
then to do a TEST(D) and then a MOVE  to retrieve the new, altered date
back into the 8-digit field.  The only time there will be a conflict is
clear and also relatively rare.  Birthdays and other dates before 1940 or
after 2039 need to have 8-digits on screen too.  

In either event I think we programmers need to get used to the TEST(D)
command and use it whenever a date comes in from an untested source.  It
is simple, exact, and so far as I know, pretty much idiot-proof.  It
really should be looked in the same light as we look at the no-hit
indicator on a CHAIN opcode - you do it even when you know it won't fail, 
because when it fails it really messes things up and you feel like a total
fool.


In other words, a date like 00970614 should blow up.  It is valid, but it
more than likely came from a 6-digit screen program and will work just
fine until your user tries to put it back on the screen again.  Then it
will fail as it is outside the range 1940-2039.  But a simple TEST(D) when
that field came into the file in the first place would have been an error
condition and would never have been accepted: you as a programmer would
have already set a condition to correct the problem.

These are my opinions, and probably worth what they cost.




In <970614152542_74711.77_BHW34-1@CompuServe.COM>, on 06/14/97 
   at 11:25 AM, John Carr <74711.77@CompuServe.COM> said:

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

-- 
-----------------------------------------------------------
boothm@earth.goddard.edu
-----------------------------------------------------------

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 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   *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *