"Of course, you might have to change DDS for screens/reports"
I think your "might" is a little hopeful. I'd say the majority of
programs I've come across on the i use either a display file or a
printer file, and much of the time you're hard-pressed to squeeze even
the existing-sized fields on to the screen or report. Writing the
program using arbitrarily larger fields would cause all sorts of havoc
with truncation when moving data between files, between screens and
files and so on. And I'd hate to think what problems could occur when
doing math on larger-than-database fields and then trying to write the
overlarge results to another file. Now if you started out with all your
character fields being variable length and all your numeric fields being
INTs or SMALLINTs, then it might be workable. But then, you might as
well use MySQL and PHP in the first place.
Trevor Briggs
Analyst/Programmer
Lincare, Inc.
(727) 431-1246
TBriggs2@xxxxxxxxxxx
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Thursday, November 01, 2012 2:08 PM
To: RPG programming on the IBM i / System i
Subject: Re: Are level checks still useful?
Hi Trevor,
On 11/1/2012 11:20 AM, Briggs, Trevor (TBriggs2) wrote:
Of course, if you remove all external data definitions (including SQL
variable LIKE definitions), and then subsequently change a field
attribute, you will be looking at program code changes rather than
just
recompiles. Swings and roundabouts.
Not necessarily... If you don't change the code, SQL will assign the
data to the old field size. If you made an alphanumeric field smaller,
that means it'll be truncated. If you made a numeric field smaller,
that means you run the risk of a "receiver too small" error, but only if
the value of the field is too high for the old field size.
Since you're program-describing the field in the first place, you could
just make the field larger than you'll ever need. For example, a field
for an employee name might be 20 chars long now in the database. You
could code your RPG program with a 256 character field -- maybe overkill
-- but nobody will ever have a name that long. Maybe in 6 months
someone will say "20 chars is too short" and change it to 40... no
problem, it's still less than 256, and the RPG program will work fine.
No recoding necessary.
That's essentially what's happening in PHP. Each variable is either a
floating point number, or a variable-length ("varying" in RPG) string
with a very long maximum length.
You can do the same thing in RPG.. should be no problem. The only key
is you really need to use SQL for the I/O, (not native record I/O)
Of course, you might have to change DDS for screens/reports (or O-specs,
maybe) but you could very well have the same problem in PHP, too, if
you're using fixed-width columns for something.
So, there's really nothing stopping you from coding RPG the same way as
PHP -- nothing except, perhaps, a mental block. :-)
midrange.com
