Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

The Great RPG MOVE Debate

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #46
    The Great RPG MOVE Debate

    ** This thread discusses the article: The Great RPG MOVE Debate **
    I think your right that the zero-fill would require the %editc, at least that's the way I would do it currently. The %int and related bifs just do a conversion from character to numeric. Scott Mildenberger

    Comment


    • #47
      The Great RPG MOVE Debate

      ** This thread discusses the article: The Great RPG MOVE Debate **
      I was excited to start using free-format RPG when it was introduced, but when I used the conversion tool in Code/400, I was dismayed...it was ugly code in mixed-format. Needless to say, I am not writing free-format RPG since most of my work is maintenance and a lot of new code is derived from existing programs. The ideal solution would be to be able to convert the whole program to free-format with absolutely no fixed-format when you have to do maintenance, then programs would be converted and tested as you have to maintain them. This is the approach we took to convert to RPG/IV. After most of the high maintenance/high use programs were converted in a controlled manner over several months, we then converted all the remaining programs at once.

      Comment


      • #48
        The Great RPG MOVE Debate

        ** This thread discusses the article: The Great RPG MOVE Debate **
        Well, straight conversion, as in CVTRPGSRC, can't happen. Too many ways to do it. If you wrote a conversion program yourself to put it into the free-format style you prefer, I think you would come across this MOVE op-code and the result would be a lot more respect for all the different things the compiler folks did from the beginning for it. Then there's move-left-to-high-zone, and move-right-to-center-zone, and the hip-bone-connected-to-the-thigh-bone, and what a party! Have you seen any MHHZO or MLHZO lately? Probably a few MR indicators still hanging around. I think it's okay to have a cutoff point somewhere along the line for some things. I don't honestly want to see those zone moves anymore, and I'd just as well do without the MR, although it's still supported in our current RPG. 'Course an embedded SQL cursor beats it up any day of the week anymore anyway. On the subject of "understanding" and "counter-intuitive", I think this is more or less a side issue to leaving it out of free format, as in it's not that big a deal for a programmer to learn. Less so than the RPG primary-file cycle, whew! In my AS/400 RPG classes some years ago, there were actual experienced COBOL programmers who kept on asking me where the READ code was in a program with a primary-file read! I told him outright that when you put that "P" there in that column, the compiler does the rest. Now before you think something else, any of my students will tell you that my delivery was one of the clearest and easiest to understand, and entertaining too.

        Comment


        • #49
          The Great RPG MOVE Debate

          ** This thread discusses the article: The Great RPG MOVE Debate **
          @Rob Sure, I could go your way and write a subproc to have a move. Lets see what it would look like... MOVE PR 512a numFld 30 0 options(*OMIT) alpFld 512 options(*OMIT) DatFld options(*OMIT) AndSoOnOtherfields... and a move would be like Result = move(*omit:*omit:*DATE:*omit...) Yes, that is really easier to read but the good old move... /sarcasm off @all 1st of all: Move is easy to use. 2nd: It is easy to change the length of a field from i. e. 20A to 30A. After MOVE the last digits are changed. If you use %SUBST() you have to watch very close every eval statement using the field. I would like to have a %MOVE() and a %MOVEL() BIF an I realy miss them now.

          Comment

          Working...
          X