|
>When you see a MOVE stmt, you know that the value >of factor 2 is being copied right justified to >the result variable. Here are some very common examples of MOVE/MOVEL which are not simple byte copy operations. c move '00000' *in(20) really SETOF 20 (Can you spot the bug?) c move char10 num5 really convert the last 5 characters to a number c move char10 num10 really convert to number c move char10 char20 really "touch the rightmost 10 characters and leave the rest alone" c move char20 char10 c movel '-' char10 c move char10 char20 really "Put a '-' in column 11 of CHAR20" c move(p) char10 char20 really "Wipe out CHAR20 and put touch the rightmost 10 characters" Rarely are the names that descriptive. I usually see something akin to c move cust suffix and then I get to find out that this is really extracting the last three characters of the customer ID, which nominally looks like "1234567-001". In this example, it's really "substring the last three characters" and not a MOVE at all. Do I use MOVE? You bet. Do I think it's handy? You bet. Does it cause problems? You bet. Teaching new RPG people the nuances of MOVE, MOVEL and MOVEA is clearly the most difficult RPG III task in terms of long-term understanding. I routinely see bugs in code that are directly attributable to a programmer misunderstanding MOVE. Do I miss MOVE in /free? Yes I do. But it won't kill me, even though I don't intend to mix /free and fixed code. Where I'll use /free is in NEW code, like a new subprocedure. I will NOT try to convert code a line at a time via some automated tool like Code/400. If I run across a situation where I need MOVE for one of it's very cool conversion/extraction/substring functions, I will write a subprocedure in fixed form that uses MOVE. A perfect example is my "extract the customer suffix" above. I just don't have strong feelings on it, I guess. >The problem with not including MOVE in /free is >that IBM did not provide the ability to write a >proc version of MOVE. What is needed are >data pointers in RPG, that is a pointer that also >contains the attributes of the data pointed to. >Or an OPDESC that actually has a complete set of >operand description information. Or allow programmers >to write their own BIFs. Steve wins big here. By all means, if Rochester and Toronto could get together on this one, we'd all be happier campers. Full OPDESC support would be such a blessing! The compiler folks aren't the ones driving that decision-making process, so complaining to them won't help. --buck
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.