The questioner in this case needed to truncate the result field on an EVAL operation in the same manner that a Z-ADD would do. As is usual in such cases, responders posted many different solutions to the problem--several of the solutions were truly ugly. Certainly the majority would have required substantive commenting in order to avoid confusing the heck out any future maintenance programmers.
When /Free came out we were very much in favor of dropping some of the more arcane RPG op-code such as MOVE and ADD. ADD because EVAL was a much better option and we always thought old-style RPG's numeric truncation was an extremely dangerous "feature" that we were better off without. MOVE because you had no idea what it was doing until you knew the data types and lengths of both fields. We won't get back into the MOVE discussion here, but this latest go-round of postings did make us wonder about solutions for the truncation issue.
One of the few valid uses for numeric truncation that we have encountered involves the rolling-over of counters. For example, to avoid generating duplicate keys, some people use a rolling counter coupled with the time. If you use a four-digit counter, it is useful to have it roll directly from 9999 to 0 when one is added to it. Note that we said "useful" and not "good." It was always poor technique because what it is doing (the roll-over) is not obvious when looking at the code. Regardless, to achieve the same thing in /Free requires that you test the value of the counter before incrementing it and then increment or zero it as appropriate. At least what is happening is more obvious but it does clutter up the mainline logic.
Normally in such circumstances we would recommend that folks use a simple generic subprocedure to implement the function. For the sake of argument let's call it IncrementCounter. This has the advantage that everyone knows its purpose when seeing it in the code and will know that it rolls over on hitting the maximum. It also has the advantage of hiding the complexity of the logic and, as we have said many times before, using subprocedures in this way saves a lot of time in understanding what is going on in the code just so you can ignore it.
But the whole discussion did make us wonder whether there is indeed a place for a new op-code (EVALT) or op-code extender EVAL(T) in RPG. It would handle the scenario posed in the original question on the RPG list and it would also handle the roll-over scenario. We tend to lean toward the use of a T(runcate) extender on numeric EVALs because there is really no need for a new op-code and also because extenders are not frequently used so they tend to jump out at you and make their use obvious. Indeed since EVAL itself is rarely used in /Free an EVAL(T), it really is going to stand out.
What do you think? Is this the kind of simple RPG extension that is worth developing? Let us know via the blog comments.
P.S. No, we haven't changed our minds about implementing MOVE in /Free. That was one death we were pleased to see.