The Great RPG MOVE Debate

[Guest.Visitor]

The Great RPG MOVE Debate

** This thread discusses the article: The Great RPG MOVE Debate **
I'm sorry you think this is a vendetta, Rob. As I stated in the column, I found myself pitted squarely against the most vocal members of the list, including you. It was my intuition that this group did not represent the majority of my readers, and that's being borne out by the overwheling response to this article. Beside personal email replies, which are 100% in favor of MOVE support in free-form RPG, this poll (which is the most active of any poll I've ever run) is running well over 2-1 in favor of some sort of MOVE support, with another 10% simply saying they'll never move to free format. So, it becomes clear to me that the loudest mailing list members don't really represent the rank and file, or at least don't represent my readers, and my readers are the people I need to represent, not the vocal minority. Joe

[Guest.Visitor]

The Great RPG MOVE Debate

** This thread discusses the article: The Great RPG MOVE Debate **
I am 32, so for a Java Programmer maybe I am too old and for a RPG programmer I am just a kid, even that my first contact with RPG was trough RPG/400 (which I thought was different from RPG III) five years ago. And have programmed with VB and Java, and C++, they all have their strength and drawbacks. I think that MOVE op code is one of the most versatile and powerful features of RPG, you do not have to be too smart to see it. And leaving it out (or not including it, semantics) of the new Java-like RPG seems to me a kind of weird. It takes one minute understanding the function of this opcode and many programs asking why another programing languages do not have it. Maybe I am wrong, because I do not know the *under-wiring* of implementing this opcode in free format, but being the fact that this is already coded, ¿why not including it?, if it is for the commodity of non RPG (JAVA) programmers, do not worry, they will not learn RPG; if it is for newbies, do not worry, they will have an experienced RPG programmer by his side (or via news group).

[bharder@nlrha.ab.ca]

The Great RPG MOVE Debate

** This thread discusses the article: The Great RPG MOVE Debate **
I have a different take on this situation. We run 2 major applications and several smaller ones. I have lots of experience on the platform and am very familiar with programming, application design and support, managing upgrades, and the issues of custom modifications. Yet the absence of free format Moves has never touched me. Why? We don't use free-format code, and neither do our vendors. One vendor converted the majority of their application to ILE RPG IV all at once, in one upgrade step. Another vendor is taking their time, on a program-by-program basis. Their system is a collection of RPG IV, 400, and III code. There isn't a drop of free-format RPG code in any of it! We use SEU, PDM, SDA, and all those old tools. Lest you think I'm a neo-Luddite, I was trained to program on other platforms. Code indenting comes naturally to me and I found adjusting to fixed format code difficult. I even code CL programs in a free-format style. Still, this is how it's done on the iSeries. Free format RPG code is a major change. You have to appreciate that free-format is mostly a convenience for the programmer, and does not, of itself, produce better programs. Junk is junk, and quality is quality. Free-format code will assist a good programmer, and do nothing for an inadequate or unskilled coder. We can produce excellent programs using fixed-format syntax. That's the way we do it for now, and I have yet to find a compelling reason to reformat hundreds of thousands of lines of code! The return just isn't great enough.

[Guest.Visitor]

The Great RPG MOVE Debate

** This thread discusses the article: The Great RPG MOVE Debate **
If IBM continues to not have a good replacement for MOVE, I will use free format much less often in the future. I am sure I will use it when that is the only good way to use a new function and I will feel IBM has messed up my code by requiring me to bounce back and forth. Finally, IBM seems to assume I won't be using existing code blocks in future code. The best plan would be one that allows all code to convert.

[dolfan]

The Great RPG MOVE Debate

** This thread discusses the article: The Great RPG MOVE Debate **
It sounds to me like IBM has the ability to allow a MOVE in free-format, but they choose not to, for fear of confusing RPG programmers!? If an RPG programmer cannot understand a MOVE statement, maybe they should choose another career! In the article, it was said that he received a comment, "Stop holding back the language". IMHO, the lack of the MOVE operation is holding back the language.

[or10z@hotmail.com]

The Great RPG MOVE Debate

** This thread discusses the article: The Great RPG MOVE Debate **
Although I have done the Subprocedure thing to work around the lack of move it still is cumbersome. I have addressed this by defining a data structure with the alpha and numeric fields defined over the same positions. That way you assigned the value to one and the other is automatically available. Still, the %move function is the better idea, I think it would lead to much cleaner and more readable code.

[GlenKerner]

The Great RPG MOVE Debate

** This thread discusses the article: The Great RPG MOVE Debate **
In Joe's article he mentioned only part of what move allows us to do. What about the all important converting dates or moving date fields to numeric fields. I have dealt with a lot of data that doesn't store dates in date format but numeric format. The 'move' op-code allows me to move it to a defined date field and convert it to a format of my choosing all at one time. I've not had an opportunity to work with free-format rpg but I would presume the move currently works the same in both fixed format and free format. If IBM takes the move away in free format how or what are they going to give to replace the date and time manipulations we currently do with the move op-code?

[S.Mildenberger]

The Great RPG MOVE Debate

** This thread discusses the article: The Great RPG MOVE Debate **
In V5R1 when they introduced free format they also introduced bif's that allow you to all the date conversions (as well as text/numeric) in free format without resorting to MOVE. Scott Mildenberger

[J.Pluta]

The Great RPG MOVE Debate

** This thread discusses the article: The Great RPG MOVE Debate **
Scott's right, the %DATE BIF provides a ton of support for date conversions. I disagree just a little with the assertion that text/numeric was completely covered, especially in the circumstance of moving a value to a substring of another field (or vice versa). That still requires some pretty convoluted manipulation. In any event, the conversions were never really spelled out anywhere. The %editc(mynum:'X') trick is just that - a very RPG-specific trick that you either know or don't know, and I don't see it documented anywhere. Joe

[David Abramowitz]

The Great RPG MOVE Debate

** This thread discusses the article: The Great RPG MOVE Debate **
The only trick involved here, is understanding what the "X" edit code actually does. As the "X" edit code is documented, then it is only a question of RTFM. As far as FREE is concerned, I am not using it at this point in time. Dave

[S.Mildenberger]

The Great RPG MOVE Debate

** This thread discusses the article: The Great RPG MOVE Debate **
Of course with the functionality they added to the %int, %dec, etc. bifs with V5R1 you don't need the %editc 'trick' anymore either. Scott Mildenberger

[Guest.Visitor]

The Great RPG MOVE Debate

** This thread discusses the article: The Great RPG MOVE Debate **
Just musing, given that the "extended factor 2" is enhanced for the CHAIN, how about just CHAINF, or CHAINX, or? On the MOVE, "my jury" is still out. It would be a nice convenience for quicker conversion to free format, but there are ways to handle that. I think some kind of %type() bif to go along with the %size() bif would be fantastic, not just for conversions of the MOVE, either. I've been wanting that one for awhile. As a side benefit you could then put that together with a pointer value or %addr() and this would set you up for a house-grown procedure in your main-granddaddy service program for a Move(). How about that! Part of the binding process is to reconcile parameter types which must be known, I know. I really don't think the issue is one of confusion, although it is true that the MOVE is a whole lot of different conversion functions rolled into one. Experienced RPG guys like us probably forget what it was like to figure out exactly what it did. Like anything, once learned, that's it. But look at CHGVAR in CL. It zero-fills from numeric to character. Not so the MOVE. That's not exactly "intuitive". So I probably would go along with giving it up, as a kind of a concession to the gate-keepers of the budgets in Toronto and elsewhere, in order to put that resource into some more adaptive language characteristics. We have done this. The RPG report program cycle is still there, to which we still pay homage with an LR in any executable RPG program today, but I started using other new tricks to emulate it in new programs a long time ago. The reason was I got tired of having to change it around for enhancements that required something else. It's probably still quicker in performance, but our motor has been soupled up a lot. I had already begun using %editc() for lots of things.

[buck.calabro@commsoft.net]

The Great RPG MOVE Debate

** This thread discusses the article: The Great RPG MOVE Debate **
I am one of the vocal minority, I guess. I don't have a problem with the absence of MOVE in /free because I never convert existing code to /free. What's the point? /free is a _formatting_ change, not a functionality change, despite a few '/free-only' BIFs like %KDS. I understand that if someone wanted to convert line by line from RPG III to /free, they would get very upset that their code won't convert. As far as I'm concerned, converting existing code to /free is exactly the same as converting it to all lower case. It looks different but behaves the same. At least writing new logic in /free, I can finally be rid of nasty 10-deep nested IF structures and other flotsam from the past. --buck

[J.Pluta]

The Great RPG MOVE Debate

** This thread discusses the article: The Great RPG MOVE Debate **
Thanks, Scott! Is there the ability to zero-fill using one of the BIFs? That part is still unclear. Let's say I want to create a lot number with a prefix ('ABC') and a 6-digit sequence number. In prehistoric times, I simply initialized the lot number to 'ABC______' and then whenever I needed a new lot number, I did a MOVE LOTSEQ LOTNUM and that took care of it. Today, I can still do LOTNUM = 'ABC' + %editc(LOTSEQ:'X'), but I don't see a way to do it without the %editc. There probably is a way, but I jst don't see it. Of course, you can always get around this with data structures, but data structure seem to me to be sort of damaging to the "self-documenting code" concept, since you have to search through the D specs to find the appropriate data structure. Joe

[J.Pluta]

The Great RPG MOVE Debate

** This thread discusses the article: The Great RPG MOVE Debate **
Seriously, Buck, there's a difference between saying "I am happy to use /free without the MOVE isntruction" and "I don't use /free, so I don't care about MOVE". Actually, so far in my poll, the results have been pretty interesting. About 20% have already converted (split 50/50 between /free and mixed mode) About 10% flat out won't go to /free (that's your category!) So of the ones who are currently on the fence, only SIX PERCENT have plans to move to either /free or mixed mode. A rather astonishing 60% want either MOVE or the extensions I suggested in the article (they're split about 50/50 as well). The remaining folks (<10%) abstained. So, basically 20% have moved, 10% won't move. Of the rest, it's 10-1 that people want something done about MOVE before they switch to /free. That's a far cry from the results we saw on the mailing lists, and that is really what this exercise was about. Joe