Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Free Format MOVE, MOVEL

Status
Not open for further replies.

rstitzel

MIS
Apr 24, 2002
286
0
0
US
I'm new to RPG. About 6 months. And I'm starting to code in RPG Free but understand that the op codes MOVE, MOVEL are not supported in free. I know I can mix fixed format with free format but I would rather code all one way. And I do like the free format. So my question is: Is there any way to replicate move, movel op codes with some other op code supported in free?

Thanks
 
This seems to be a real point of contention between programmers. You may want to check out the article:

The Great RPG MOVE Debate at
You'll see that you can do what the MOVE opcodes did in free format. It's just a little more verbose than if they had added free format versions.

Joseph R. Cattano
IS/Tech Support
Goldman Associates of NY
 
I read the article from your post and it's crazy. I believe that we (or some of us) have made the whole programming language category )for lack of a better term) impossible. My function is to give the user the tools to do their job. Instead we have a set of tools that make our jobs more complex, really do nothing for the customer, and baffle outsiders. I also read some of the threads in MCOnline about subroutines and subprocedures. OK, other languages have local and global variables. Good. Now we have them. I have found that when I write a program, it makes sense to me. I read someone elses, it might confuse me at first. Debugging a set of programs that I know lottle about- a challenge. Add into the mix some external subprograms where I may or may not have the source code for- wow! One person said- hey, you don't have the source for %scan and you don't worry about it- true. But it's not reading data from 11 files and returning a set of variables that don't make sense! Where did this come from? Why this and not that?

Right?
 
I'm not sure what you are getting at. Why do you think the article is crazy? It illustrates that there are a lot of opinions about programming, but it also offers some pretty good information. If nothing else it shows that there are always alternatives.

Personally, i think that RPG has evolved into an incredibly easy and powerful programming language. Certainly light-years from its original intent. Does it do everything the way i would like... No... But i have way less complaints then i used to.

The question was "Is there any way to replicate move, movel op codes with some other op code supported in free" and the article i posted was just intended to show that the answer is yes, but there are issues.

Sorry if i hit a sore spot or misinterpreted your reply.

Joseph R. Cattano
IS/Tech Support
Goldman Associates of NY
 
No, no sore spot. Just trying to say- are we serving the customer? I have worked with many programmers over the years and they couldn't grasp RPGII concepts. Or basic programming concepts. Now I'm at the point where the user is more important than another variant of RPG. I know we need to do more and the latest RPG allows us to accomplish that. I guess I was thinking about the number of shops that have to code around this MOVE problem, either by stepping out of free-form, coding a subprocedure, whatever, instead of IBM saying - hey, this is dumb, let's fix it. But that mindset has created VB6, then VB.NET in Microsoft. Let's not fix what we have, let's make a new one. Does it serve my customer?

Hey, liked the article. Thanks for putting the link here. I was just trying to get a discussion about are we serving the customer or just trying to justify our existence--- or maybe I should say justify IBM and Microsoft's existence with another language.

I'm trying to lighten up, really.
 
Thank you JCATANNO for the article. It was exactly what I was looking for. Although I'm not too happy with the information at least I know what my alternatives are.

Thanks again.
 
Let me just throw my two cents into this. I found a way to get around the MOVE problem WITHOUT having to code a separate subprocedure to do it. It depends on why you're using the MOVE opcode for. Most of the time, I'm using it to convert from Character to Numeric data. There is a simple way to do it using data structures.

D CharValue Ds
D NumValue 9S 0

Let's say you've been passed a parm into the program and need to convert the value into a numeric to do a calculation on. First, code a data structure (as above) then do the following.
Lets assume that Input has the value of '100' in it. First, you need to make sure the data is right justified in Input. You do this by:

/Free

EvalR Input = %TrimR(Input)

/End-Free

Then, convert Input into a numeric value by;

/Free

CharValue = Input

/End-Free

NumValue now is loaded with 000000100. Or, you could just code:

/Free

EvalR CharValue = %TrimR(Input)

/End-Free

The only thing I have to do when using the above technique, is if I'm passing dollar values to the program, I have to first remove the dollar sign, commas and the period before I send the char value to the data structure. There are limitations to this.
1. The NumValue variable must be a zoned decimal, it doesn't work if its a packed decimal.
2. You must define the value of NumValue, you cannot use the like keyword.

I hope (for once) I've made sense her.


RedMage1967
IBM Certifed - RPG IV Progammer
 
Jack1955…

Glad to hear that you weren’t bugged[worm] by my comments! Posting to a forum isn’t the best way to communicate feelings.

I would agree with you that the whole reason for having programmers is to serve the customer or user. (…unless it’s a hobby, then you don’t have to please anyone but yourself). But I think in order to do that programs have to be well designed, well written, checked for bugs as thoroughly as possible and be easy to modify and debug. And, of course, they should be well documented.

One of the way to do that is to code in a language that’s up to the task. Unfortunately, RPG has not always been up to the task. (I don’t think anyone would code an interactive application in RPG II if they didn’t absolutely have to). But the (relatively) recent changes in the language have made it possible to modularize functions and isolate data that is unique to those functions. That (plus a lot of other things) makes it possible to write programs that will serve the user.

(The MOVE issue really becomes a non-issue because, while it would be nice if IBM just supplied the functions, you can write them yourself if you have a mind to).

Anyone can write bad code and no language, technique or approach is going to prevent it.

I think the &quot;let's move to <fill in your pet visual language>, that'll fix all of our problems&quot; comes more from the &quot;Green Screen, BAD![vader]... GUI, GOOD![angel]&quot; mentality. For some reason people think if you can click, drag, or drop it, it must be modern and state of the art. Some GUI apps are very well done (now if there were only a stable OS to support them). But there are some Green Screen apps that are just as well done. Sadly, the opposite is also true.

So I don't think language and platform are primary (although whatever one picks it should have stable OS, reliable hardware and solid database). It’s the thought (or lack of thought) that goes into designing, coding and implementing an app that’s primary. A perfectly coded program based on a bad design is going to be a nightmare… Even on an iSeries.


Joseph R. Cattano
IS/Tech Support
Goldman Associates of NY
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top