I present this opinion piece to you, dear reader, with some trepidation, because I find myself on the "wrong" side of the argument. I'm aligned against the developers in the compiler lab, but I am often at odds with them, so it's not unusual. However, this time I find myself facing off with other highly respected people in our industry, including no less illustrious a personage than Jon Paris. That being the case, I am writing this column to explain the situation and to ask you, the reader, for your opinion.

Why IBM Removed the MOVE

So how did I get into this position? Well, I believe that removing the MOVE instruction from RPG is a bad thing.

"Whoa," you might say, "what's all this? Who's removing the MOVE instruction?"

Well, IBM is. The new free-format RPG syntax has no MOVE operation. It doesn't even have a built-in function (BIF) that will act like the old MOVE operation. Instead, if you want to take a three-digit numeric field named LOTSEQ and stick it into the last three positions of a 10-character lot number named LOTNUM, you'd have to rewrite your code completely. In fixed-format RPG IV, you'd simply write this:

But in the new free-format RPG, you would write this:

Why? Because MOVE is not a valid opcode in free-format RPG. This change has been made in the name of clarity. The IBM compiler folks insist that the second form is more readable than the first, because the MOVE instruction is too "confusing" for new developers, because it is "too heavily overloaded."

By that, they mean that MOVE does many different things, depending on the arguments you pass to it. For example, if factor 2 is alpha (a character field) and the result field is numeric, MOVE converts from alpha to numeric. And if factor 2 is numeric and the result field is alpha, MOVE converts from numeric to alpha. And while this is common knowledge to any junior RPG programmer, it is evidently confusing to the great masses of non-RPG programmers out there. At least, that's what the anti-MOVE folks say.

I guess the problem is that you might not know what the MOVE is doing unless you look at a compiler listing to see what the two variable types are. You see, that second example, with the %SUBST and the %EDITC, is what my esteemed colleagues call "self-documenting code." Listening to the argument, I get the idea that comments and compile listings are passé and that you should be able to glean the entire substance of a program directly from the source code. And while this is perhaps an understandable reaction from someone who has never seen a compiler listing, I didn't think any veteran RPG programmer would actually consider the MOVE instruction to be difficult or confusing...especially since the EVAL opcode often isn't any more forthcoming about its variables than the MOVE. For example:

There's no more information here than with a MOVE. You can't even tell if field1 and field2 are alpha or numeric. It seems to me that there is nothing intrinsically better about EVAL as opposed to MOVE.

So it troubled me that someone of Jon's stature could be anti-MOVE. When I approached him about the subject, Jon explained that, to him, the MOVE instruction is simply the biggest symptom of an overall sickness in RPG: namely, that it's too backward-compatible. He believes that while the RPG compiler folks have been truly doing wonders, they've also had to keep the old ways of doing things in order to keep older programs working. Because of this, the language has many ways of doing things, so programmers can get confused. I'm not sure I agree, although I do agree that the compiler folks have done great things with RPG--from the addition of procedures, to ILE and OPM interoperability, to service programs, to cross-language support (especially Java).

So What's a Programmer to Do?

Well, the compiler folks have at least given us the capability of dropping out of free-format with the /free and /end-free compiler switches. Actually, this is technically a way of dropping into free-format, but either way, your code is bounded by these compiler switches as you move code from fixed- to free-format and vice versa. Given that capability, there are currently three options for the MOVE situation:

1. Leave all your code in RPG IV, and never switch to free-format.
2. Convert entirely to free-format, and retest every program that had a MOVE in it.
3. Use /free and /end-free to have a mixed version of fixed- and free-format.

The first is OK if you can stand it. But since the compiler team is now actively adding features to free-format that they cannot or will not add to fixed-format (such as the %KDS format for using a data structure for a key list), you will fall further and further out of touch with the newest features.

Option two is fine...if you have infinite time and budget to convert and test all your programs (since it's likely that nearly every one of your programs has a MOVE). Unfortunately, most companies can't justify a complete retesting of their systems, so this option, while nice, is usually unfeasible.

Finally, you could mix and match by simply inserting bunches of /free and /end-free. My concern is that your code starts to get unmanageable. Take the following code:

In mixed-syntax RPG, it becomes this:

I don't know about you, but I wouldn't want this as my corporate coding standard. Any environment where you are switching between syntaxes is difficult to read and follow. Anybody who has coded embedded SQL knows what I'm talking about. And remember, the whole point of this was that MOVE was hard to read. Is this an improvement?

To Recap the Situation

So, let's review the problem and its resolutions.

The RPG Team Thinks the MOVE Opcode Is Too Confusing.

Personally, any job candidate who tells me that the MOVE instruction is just too darned confusing is not likely to impress me as a good fit for any type of programming role, especially since the supposedly preferable alternative is "%editc(mynum:'X')". The big knock on MOVE is that it is RPG-centric and only RPG programmers understand it. How many non-RPG programmers would even be able to guess what %EDITC means? This argument just doesn't ring true for me.

So They Have Removed MOVE from the Free-Format Syntax.

The compiler team doesn't like this statement. They counter with, "We didn't remove anything; we just didn't include it in the new syntax" and "You can always use /free and /end-free to include the MOVE operations." These arguments are semantic at best. It boils down to this: Unless you're willing to live with a mixed syntax, you cannot use MOVE and the new features of the language in the same program.

Thus, You Have Three Choices:

• Don't use new features.
• Remove all your MOVE instructions.
• Switch back and forth between fixed- and free-format RPG.

IBM insists that the last one is the choice for legacy programs. The party line is that free-format code is only for new code and that legacy code doesn't get these extensions. If you want to use key data structures, for example, you can either rewrite the program or use the syntax switchers to swap back and forth.

My opinion is that syntax switching is only a tactical move. I've managed lots of projects over the years, and my gut feeling is that the mixed-syntax is a long-term maintenance nightmare. Instead, I believe that the correct answer is a guided conversion path, one that will allow us to move our programs from fixed-format RPG IV to free-format RPG at a rate that we can control, thus with a minimum of pain and suffering.

What Can Be Done?

I took it upon myself to come up with a possible alternative, a compromise between having a free-format MOVE opcode and having no MOVE support at all. A couple of relatively minor enhancements to the language would allow those of us in the fixed-format world of RPG IV to slowly move to the "perfect" world of free-format. I ask for two things: a syntax that allows us to use the new features in fixed-format and a BIF that replaces some of the more "advanced" features of the MOVE instruction. Both of these would be part of a two-phased conversion utility that would convert fixed RPG IV code to free-format.

In phase one, the conversion utility would replace old-style RPG IV code with new "extended" fixed format code:

Notice how the CHAINs got reformatted: Factor 1 moved over to the right of the opcodes, and the special value *EXTFAC2 (extended factor 2) was put in factor 1. Except for the *EXTFAC2 constant, this is the exact same syntax the CHAIN opcode has in free-format code, so no new syntax or special parsing is required. This would be the case for any opcode that requires extension.

The second thing the converter did was remove MOVEs. If the converter recognized that the two fields were compatible for a simple EVAL statement, it would insert the appropriate code. Otherwise, the EVAL would use special BIFs that would execute the old MOVE logic. Some people might argue that it's a lot of unnecessary work to add the MOVE BIFs, but I counter that, since the compiler still supports the MOVE opcode, that logic is in the compiler, so it's really not a significant amount of extra work.

With this first level of conversion done, those "unconverted" moves would "stick out like a sore thumb," and thus be subject to revision at your convenience. Not only that, but because of the addition of support for the extended factor 2, you could take advantage of the new features in the language without having to move entirely to free-format. For example, you could use %KDS:

Finally, when you were ready to move to the free-format syntax, a second option of the converter would execute a "fixed-to-free" conversion, which would yield the following:

You still see the %MOVE BIFs clear as day, so you can address them as time permits. And as an interesting side effect of this above strategy, you could even combine the %MOVE BIFs:

I think this compromise position (removing the MOVE opcode from the free-format syntax, yet providing a BIF for gradual redeployment) solves the problems. The parsing and logic is already in place; I'm not asking for any new opcodes or syntax. All we need is the "*EXTFAC2" flag, to indicate free rather than fixed syntax. And the code the compiler generates for the %MOVE BIF is simply the same code the compiler would have generated for the corresponding MOVE opcode.

I figured that these were good discussion points, and I presented them to the mailing list.

What Was the Response?

The response was a resounding THUD. Nearly everybody on the mailing list came back with comments like, "Stop holding back the language" and "MOVE is too confusing" and "I don't need MOVE instructions." The conversation got so heated that the moderator had to step in. But by then, I had come pretty close to giving up, anyway. I just don't see how someone could see this as holding back the language, when what it really does is assist legacy shops in using the new features of free-format.

More importantly, I don't understand the idea of the compiler team taking away a fundamental function like the MOVE instruction just because it's "too confusing." What if the compiler team decides that native DB2 files are too confusing? Since SQL is self-documenting, will they remove F-specs and file I/O? Or perhaps they'll decide that green-screens are old technology that holds back the future of the language, and they'll remove 5250 support. Is the language theirs now, not ours? They seem to have decided that they're the ones best suited to choose how we should program.

But I'm perhaps too close to the subject, so this is where you come in, good reader!

What Do You Think?

I've been fighting this battle for a long time. Not on my own behalf, but because many rank and file programmers I've talked to think this move to ban MOVE is not in their best interests. They don't understand why IBM thinks this is a good idea.

Yet the mailing lists seem to be in the opposite camp. I get the feeling that the mailing lists tend to have the "bleeding-edge" programming advocates who want all the new bells and whistles and that the rank-and-file folks are under-represented. And since IBM sees only the comments from the mailing list, they think everyone wants to ban MOVE.

So I'm asking this: Where do you stand on the whole free-format concept? Are you happy with the MOVE instruction being removed? Will you use free-format? If so, will it be mixed syntax or purely free-format? Would you like to see a MOVE instruction in free-format or perhaps the extensions I outlined above? I think I've got a decent list of options; I look forward to your input.

Maybe I'm just an old dinosaur, but I think that I know a little about programming and that the MOVE instruction is not inherently a bad thing. But now it's time to get some more input and find out what you think. Why don't you let us know?

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been working in the field since the late 1970s and has made a career of extending the IBM midrange, starting back in the days of the IBM System/3. Joe has used WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. Joe is also the author of E-Deployment: The Fastest Path to the Web and Eclipse: Step by Step. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..