RPG and Programming

One of the more interesting things about freeform RPG, at least currently, is its support of the MOVE/MOVEL RPG operation codes. It doesn’t.
For those not so familiar with RPG, MOVE (move right) and MOVEL (move left) are codes that you will find in almost any standard RPG program. What do you do with them?
You can:
1. Move a string into another string. If the target string is smaller, the move ends with the filling of the string. For example, assuming the field MONTH as a 9-long string with value “NOVEMBER” and a 5-long string RESULT:  MOVE MONTH RESULT results in ‘MBER ‘ ; MOVEL MONTH RESULT result is ‘NOVEM’. If the smaller field is MOVEd to the larger, what is left remains unchanged (unless the move is given a code (p) which causes it to be filled with blanks). If RESULT was ‘NOVEM’, MOVEL ‘123′ RESULT would produce ‘123EM’
2. You can MOVE strings to numeric fields, and strings to numbers. In this case, the system will try to convert the string to numbers; this is no problem, especially if the string is already a number.
3. Move strings and numbers to DATE type fields (which RPG can manipulate with other techniques, such as adding a month to the date), and vice versa.
In fact, 14 pages in the RPGIV manual is devoted to examples of how to use the MOVE opcode. (As we said above, MOVEL just starts from the left. Almost as many pages are given to MOVEL).
You would think at first that IBM would want to use this code, in view of its widespread use and of its power. Syntax would not be an issue; I deliberately did not attempt to put my example above in fixed format, just to show how obvious the syntax was.
But, what does the IBM manual say about MOVE? To quote:
“Free-Form Syntax: (not allowed - use the EVAL or EVALR operations, or built-in functions such as
%CHAR, %DATE, %DEC , %DECH, %GRAPH, %INT, %INTH, %TIME,
%TIMESTAMP , %UCS2, %UNS, or %UNSH )”.
To this list I would add %SUBST(substring), at least.
I can think of no practical reason why the implementers did not simply allow MOVE into freeform. Perhaps it’s because I’m just an ignorant junior college grad, from when they didn’t even have CompSci courses in JC. Since I am not a computer science major, to me the implementation would be a snap; when the compiler sees “move field1 field2;” in freeform, do exactly the same thing you would if you saw MOVE FIELD1 FIELD2 in fixed format. (Copy the compiler code! What a revolutionary idea!)
I, for one, think the problem is ideological. MOVE (along with its cousins) is too powerful a code. Since high school grads (like me) know how to use it, it obviously is too difficult for CompSci graduates to understand; you must replace it with another opcode (EVAL) and one or more of at least 12 BIFs listed above. Makes it easier. Yeah, right. We must make it simple so the ignorant Java programmers can understand. Pardon me while I get ticked off by intellectual condescension. The compiler writers are evidently trying to pry us away from an operation they feel is somehow inferior. Never mind that it works reliably, precisely, and elegantly.
Never mind that you have to be very careful how you use the BIFs, since you might not end up with the exactly equivalent result. You wouldn’t have to bother if you didn’t change it in the first place. Multiply this by the millions upon millions of MOVEs and MOVELs that likely exist in existing code, and you begin to see the problem.
The code will almost certainly be longer and likely more complicated if you attempt to convert the code. You would think brevity would be prized, since it seems such a virtue when it goes the other way, when they come up with a BIF that seems to do the job more succinctly than its fixed-format equivalent. Apparently here, they are not shooting for brevity; and I find it hard to see how they enhance the clarity of the code by avoiding MOVE.
Frankly, if they are trying to promote the use of freeform, I think they are shooting themselves in the foot by not implementing MOVE. From what I have read on the RPG forums, the lack of MOVE support stands in the way of easy freeform conversion. The fixed-to-freeform converter cannot handle it, so a /END-FREE must precede it, dropping the code back into fixed-format. Many other opcodes can be handled more or less elegantly using BIFs; not using MOVE in freeform often ends up forcing the programmer to use some Rube Goldberg BIF to try to salvage the situation.

I can only wonder why they are taking an ideological stand on this subject. “Dumb” is the nicest word I can think of with reference to their decision.

This entry was posted on Monday, October 27th, 2008 at 12:13 am and is filed under Programming, RPG, RPG Freeform, RPGIV. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.