× 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: DATE fields in RPG-IV
  • From: John Carr <74711.77@xxxxxxxxxxxxxx>
  • Date: Thu, 4 Sep 1997 21:46:21 -0400


RE:     Re: DATE fields in RPG-IV

Booth....

I still disagree with the performance issue. All files we've created in the
last 2 years have been native date types.  No perceived performance 
difference.  All of our systems are being converted to dates
(L types, or Z timestamps) for Y2K.   Each machine being released by
IBM has 6 million times the power of the last (or something greater than
5% anyway).  

LET me say this once and very clearly.  You will have your files ALOT LOT
longer than you will have your present hardware.  You could upgrade to a
new processer, etc. and have ALL date data types and STILL see a 
performance improvement Next year, 3 years, 5 years, 10 years from now.

How many files do you have older than 3 years? 5 Years? Older still?

Now then, onward.

Nulls would be nice.  

However...... the problem you state of "Date of Termination"  is not a 
date data type problem. 99/99/99 IS NOT A DATE PERIOD.  Neither is
00/00/00 (Yes Nulls are probably what is needed in the case of 00/00/00).

It's the hard coded business logic in our systems that says " If ship date 
is 99/99/99 order is backordered"  or something similar.  They are not
dates,  They are "Figurative Constants" that have "special meaning" in 
our systems (usually that only the programmers involved know the full
implications of). 

  Its not any different than having some flag in the
record and having the "Business logic" say "If the code is an 'C' the 
date field means Date cancelled.  If its a 'B' its the Backordered date,
If the Code is a 'O' its the original date of order(new order).
If its a yada yada yada it means blah blah blah. I still have to agree
with CODD its all @#$%^.   Does the column heading say ship date? 
yes or no.  Then 99/99/99 has as much right being there as 2/31/xx (any
year)  Its the hard coding of these business rules that got us into this
mess to begin with.  If you want to continue this tradition, just 
 change your "Embedded Business Logic"  to say if "date is 9999/12/31"  it
means blah blah blah instead of "if date is 99/99/99 it means..... 

These are all "System and Data Base Design"  errors they are not examples
of problems with date data types.  

But I'm probably wrong.

End of soap box.  

John Carr
(Booth you knew this would happen when you wrote that.)

>Booth said;

>RPGIV can do dates very nicely without using a L-date field.  There have
>been discussions here about the date type.  I tried using it a while ago
>and it didn't take long for me to be convinced that this is not the time
>to start using L-date types.  You have hit the first reason already. 
>second one is: performance sucks.  Finally, there is no null value
>allowed.  What date will you put in payroll files for date-of-termination? 
>Or in Accounts Receivable files for Date Paid?  


>>In <340CE55E.538E@concentric.net>, on 09/02/97 
 >>  at 09:19 PM, saskia <sfsaskia@concentric.net> said:
>>
>>We need to be
>>able to convert back to numeric format for output to display file and
>>printer file DDS.  How should this be handled?


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


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.