120 pts.
I am converting RPG III code to RPG ILE (brand new to ILE). I have several program where field lengths were assign via the MOVE/MOVEL operations. Is there a way to do that also with the EVAL/EVALR operations or can anyone suggest another. ?



Answer Wiki

Thanks. We'll let you know when a new response is added.

No, Eval/EvalR cannot define the field (like MOVE/MOVEL)
Best RPG IV practice is to use D-specs to define all fields (except those from external files)


Discuss This Question: 8  Replies

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • Dcarney
    I do realize that is the best practice. Is there, however, any way to define "on the fly" with RPG IV ?
    120 pointsBadges:
  • hafwhit
    You are better off by using the D spec for assigning the size. Once you get in the habit of doing it you will forget about doing it any other way. I use Linoma's RPG Toolbox for converting of RPG III programs. I am not trying to sell you anything, but I like the features it adds to SEU. When you run it's conversion it will create the field definitions for you. You can choose the options of what you want to convert, such as MOVE to EVAL. You can download the software and give it a try.
    1,175 pointsBadges:
  • philpl1jb
    Unless you are going to Free, the Move and Movel can be used. Phil
    54,090 pointsBadges:
  • LBurkett99
    If you choose to convert your programs to Free, you can still use move/movel and any other columnar syntax if you wrap them with an /end-free /free pair.
    850 pointsBadges:
  • aceofdelts
    On occaission, I'll use MOVE or Z-ADD in the *INZSR to define a field. Then use Eval in the actual code.
    2,475 pointsBadges:
  • Splat
    One other 'in-line' option is to define a field while using the CLEAR opcode. Not necessarily best practice, but it works.
    12,450 pointsBadges:
  • Yorkshireman
    We finally moved back to allocating memory at the top of the source listing, and you want to go back to hiding field definitoins in the code ? Don't do it.. If you use the CVTSRC command, it does a reasonable job. You can, even in SEU, scan the source for field definitions, and ensure they are consistent, and singular. For 'Best Practice' read 'makes a developers life easier - like keeping a 'standard' printer routine in the box of punch cards in the bottom drawer.. that was 'best practice' and 'applying standards' blah blah...
    6,085 pointsBadges:
  • TomLiotta
    Since the definition is fixed anyway, and not actually created "on the fly", why would you want to do it? It does nothing but make later analysis more difficult. Tom
    125,585 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: