RE: DATE fields in RPG-IV

John,

>            P.P.S  (Years ago when the "performance seminars" said
>                   not to use "variable name calls" in RPGIII because
>                   of 'poor' performance.  I still used them because
>                   it was the right design technique, No performance
>                   Problems then either)


The use of the EXSR opcode was another performance killer. But like the 
DATE datatype, we want to use this feature. So we did and demanded that IBM 
fix the performance issue. How many times have you and I sat in on a 
Requirements meeting (with Neal, Sloan, and others) and heard IBM ask, in 
response to a new requirement, "How do you want that to perform?" Of course 
the answer always is "Make it run faster!"

The point is, the AS/400 is engineered by electrical engineers among 
others. It an be modified. "Software integrated circuits" is what John 
Sears calls it. The only reason DATE fields still perform bad is because 
the people that implemented it, or designed it are to proud of their work 
to "fix" it. You know this system and the S/38 before it has always been a 
"check your ego at the door" machine; an almost scientific open mindedness. 
We used to hear responses like "that's an interesting idea, we'll look into 
it."  Now we hear more and more of "that's the way it works!"

Whether they think they've fixed it with silicon, or VLIC, DATE datatypes 
have to perform better across the board. Not just on the box they might 
announce tomorrow. There are 300,000 plus customers out there that will say 
"who cares, I don't have one" if they announce that the DATE performance 
issue if fixed on the "e" series.  Granted most of ILE works better on 
PowerPC-RISC boxes, but DATE support was there a long time ago, and is not, 
as far as I know, an ILE question.

I have only two AS/400's today: My original B10 (which is now a C10 or 
something like that) and a RISC model (40S or S40 or AS400 model 400 or 
other such confusing name). The C10 is in the garage with a sheet of 
plywood on it, being used as a shelf (anybody want it?) The RISC model is 
my development/production system.

If I write a new application, I think twice about using date fields. I can 
do everything I want with numeric fields containing dates, using RPG IV. I 
can also manipulate the date values in RPGIII if they are stored in my 
database as zoned numeric fields. In RPG IV I can easily convert these 
numeric fields to DATE variables.

I suppose, I could compromise on function over performance if Toronto would 
do two things.

1. Add blank line tolerance to the RPGIII compiler.
2. Add native date datatype support to RPGIII, including ADDDUR, SUBDUR, 
EXTRACT, etc.

This would provide enough of an incentive to use date fields in my 
database. I do use them today, for time-stamping records, but only in apps 
that are new, and written exclusively without RPGIII.

I realize that the Toronto lab is not responsible for the DATE problem. But 
over the years, Rochester has "fixed" a lot of things that Toronto should 
have corrected. Since Toronto is doing a lot of great things lately, 
perhaps it's time for pay back. <g>



Bob Cozzi
Bob@RPGIV.COM
www.rpgiv.com
AS/400 Books:  http://www.rpgiv.com/as400Books.html


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