RE: DATE fields in RPG-IV

[Bob Cozzi <BobCozzi@xxxxxxx>]

I don't think Charlie's numbers are suspect, I think John's comment needs a 
bit more analysis.

John said:
"All files we've created in the last 2 years have been native date types."

Note the "created in the last 2 years."  And then he says: "No perceived 
performance difference."  Difference from what?

If the file is "new" then it's new. I think Charlie was getting at that 
EXISTING files with numeric fields in them are processed by RPGIII and 
RPGIV at a certain speed.

But then convert those numeric fields to date fields, use the same programs 
to process them, and you end up with a performance difference. Now if you 
create a new file, and have a new app, then to what do you compare that 
app?

The database guys in Rochester know there's a performance difference.

For example, if processing numeric fields takes 10 steps, and processing 
date fields takes 14 steps, of which 9 of the steps are identical, then 
unless the final 5 steps of date processing take the same as that final 1 
step of numeric field processing, dates are going to take longer to go 
through the pipe line.

Now then, if those 14 hypothetical steps are the original program design, 
that is, it's a new application, and they go through the pipe line fast 
enough, who cares if it's slower?

On existing systems (beige boxes, and other CISC processors) performance of 
date fields is bad. If everybody is given an S40 for their birthday, then 
date performance compared with numeric fields on CISC boxes will be a "so 
what".

Bob Cozzi


On Friday, September 05, 1997 7:36 AM, boothm@earth.goddard.edu 
[SMTP:boothm@earth.goddard.edu] wrote:
> I never actually tried it because my benchmarking skills would need a 
null
> field described.  Are you saying that Charlie's performance numbers are
> suspect?  Was it Charlie M.?  I think it was.
>
> I agree about  88/88/88 and 99/99/99, I don't really use that method
> anyway.  But  I still have no idea what to put in as date-of-payment on 
an
> unpaid invoice.  I also had troubles with the L date field in DDS and CL
> too, but they may have just been learning problems on my part.
>
>
> In <199709042149_MC2-1F3A-854B@compuserve.com>, on 09/04/97
>    at 09:46 PM, John Carr <74711.77@compuserve.com> said:
>
> 
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.
>
> --
> -----------------------------------------------------------
> 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
> +---
> 
+---
| 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
+---