RE: Benefits of Sub-procedures

["Bob cozzi" <cozzi@xxxxxxxxx>]

Hans,
If myself and others hadn't protested the original plan for right justifying
text in a field and strongly suggest using EVALR instead of the original
plan, we would have ended up with something like this:

| > parms.transNo = %editc((%dec(transNo:%size(transNo):0) + 1):'X');

RPG programmers do not want to write parsers, compilers, editors, regexp
search tools, etc. They want to move field A to field B as easily as
possible. If that means it needs to be converted between character and
numeric, then that's the way it is. 
For example, I'm currently contracting at a shop where their item number is
stored in at least 6 different field formats, sometimes it is character,
occasionally it is numeric; often with different field lengths. This is due
to the vastness of the application and the different staff members working
on it over the last 20 years. 
That fact that I may have to code something like the above over and over
again, is just not practical and does nothing to get the old programmers
into the new RPG IV stuff. If they could just do this:
  Eval  A = B
  EvalR A = B
Or
  EVAL  A = %Char(numfield:*NOZEROSUPRESSION)
They would say, okay I can do that.

(Obviously, I'm joking about the *NOSEROSUPRESSION option.)
-Bob


>>jt wrote:
| > ...  Similarly I would
| > ask, why would anyone want to code this:
| >
| > parms.transNo = %editc((%dec(transNo:%size(transNo):0) + 1):'X');
| >
| > in order to increment a transaction number...???  I ask this
| seriously:  Why
| > do you need "rocket science" to add 1 to an alpha transaction 
| > number?? Iirc, seems like only one person on this list even came up 
| > with an /alternative/, a simple data structure.  I guess because if 
| > it ain't "modern", it ain't cool...
|
| That's really the wrong question. A more appropriate one is this: Why 
| would anyone want to implement a transaction /number/ as an alpha 
| string?