First rule I go by is convert RPGIII to RPGIV - it allows me more freedom in inserted code ability, however beyond that...

Generally I will leave working code alone.  If I need to modify some code lines I will add/change code in the style it was written OR add new code in /free, within a procedure at the end of the original program code.

Lately I've been converting code, within the subroutine that I may be changing, to make the entire routine /free, but leaving other untouched subroutines in old format.

One big issue is that performing a full fixed->free conversion, is that eval does not do EXACTLY what the older opcodes do.  We've been bitten in the butt with high order truncation from EVAL, which just didn't happen with MULT/ADD/etc.  Now maybe this high order truncation fixing is a good idea.  But frequently you don't find out about it immediately, and when it does rear its head, you have an emergency fix issue that needs to be done right there and then.

Neil,

I certainly agree, the ADD/SUB/MULT/DIV and things like that were a real pain. Today, as we write new code, we "know what to expect" from EVAL and act accordingly.

The worse thing I see, today, is that legacy MULT 10000.01 line to convert a date--people actually left them in there after Y2K. Very odd.

But that the end of the day, if you do a good job of understanding your algorithms, you should be able to migrate ADD/SUB/MULT/DIV to EVAL--perhaps not in some selective/exception cases, but "mostly".

If I have to make a modification to an existing program, I always make it in the style of the program, unless the modification is so great that it affects a majority of the program, then I rewrite the program in free format.  I write most new programs in free format (there are a couple of exceptions).

You invited testing of the new discussion forum? Let's see what this can do:

Evolving Skills

What might be seen as being bitten in the butt by the truncation behavior of EVAL, I say this: Look at it as an opportunity to get rid of old bugs. If you get a surprise during a production run, then look at that as a failure of your test suite.

Forum Test

Now on to some random gibberish to see what this forum can do:

When in Kingston, join us at the ukulele jam.

Hmmm, I'm not sure I like the behavior of inserting a link. When no text is highlighted, I would still like to insert a link. With highlighted text, I expect that text to be put into one of the fields on the link menu. (The code should be smart enough to figure out which field to put the highlighted text into.)

Also, the other fields on the link prompt are a little on the geeky side. Who but an HTML programmer knows (or cares) what "target" and "class" are?

• How about the ability to insert images?
• I never like to see font size expressed in terms of points. Should use "bigger" or "smaller" instead. Or use a percentage. At least, the default should be indicated.
• I know I'm nitpicking, but those are "fonts", not "font families". 
• Let's see some fonts: eta oin shrdlu That should be in wingdings font. But shows as regular text.

Enough for now.

Cheers! Hans

[EDIT by QSYSOPR: This is not member DaleB's comment.]

The "flaw" in Hans' logic is that the meaning of the code or perhaps its justification could be non-existent, or handed down from the Executive suite. So we become unsure if a change is viable ("legal") or if we have to live with it working the way it was/is.

Even the old COBOL compiler for the mainframe has a "High Order Truncation Might Occur" message--it doesn't blow up at runtime.

Perhaps like Apple's iPhone AutoCorrect, this feature is implemented backwards--it should be the way it works by default, it should be turned on as an option.

Okay, DaleB, it looks like your comment was overlaid by a new comment.

That's okay because it helped me find a bug in the commenting program.

But if this one posts without your NAME on it and without overlaying the previous comment's text, the bug has been fixed.

Still no hurry to rewrite or convert code to /free.  When adding a few lines of code to a program in fixed format we add fixed format.  When adding subprocedures to existing code we tend to use /free for that code. 

We really don't care as long as we get in and out of the code as fast as possible and the code is "clean" (easy to read and the program does what it's suppose to do).  Why?  Because we're still being told the RPG is dead and our wonderful iSeries is going the way of the dinosaur.

I would say that 40% of the code I "work on" is in /free. 

It depends!   If I have to touch (which I do often) a RPGIII, then I convert it first.  If it is just a couple lines, I do it in fixed.  If more, then I insert the /FREE.

It would be nice to update them, but time constraints plus fooling with working production code at a users site prevents that.

Just my 2 1/2 cents...

We converted all of our RPG III code to RPG IV about 10 years ago. And we don't normally convert the RPG IV it to /free form because of MOVE and MOVEL basically. It's harder to read the code when the source constantly jumps in and out of /free form. I only code /free form, for many years now. And I too leave working code alone, I don't want the project team to have to test something not related to the project.

It looks like we might be getting some guy called Bob Cozzi to our place to bring our programmers up to modern programming techniques.

Neil, I didn't realize that was your employer. 

Panty tips on what they really want?