If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Substring in RPG

June 14th, 2011, 04:20 PM

I need to ask an IF statement about the first byte of a three byte chararcter field in RPG III. Can I accomplish this in one step or do I have to substring the field in the first spec and in the next statement ask the "IF".
Examples would help . Field name is GRPID. In cobol I could use reference modification and say:
If GRPID (1:1) = "M"
then do this
else take the day off

Comment

I just want to point out that you dont have to be stuck in RPGIII. You can take this program forward into RPGIV by using the CvtRpgSrc command and use the new stuff in RPG. (Or, at least the stuff thats new since 1995.) You will save enormous amounts of coding time if you do.

Comment

If you use the CvtRpgSrc command and do nothing else to the program, it is as OPM as the RPGIII program. ( In other words, its non-ile, and runs in the DAG just like RPGIII programs do). But it does allow you to use the new RPG opcodes back to the release the customer is on.

I used to own a software company that had multiple application packages to support. ( We even had to support across the Cisc / Risc barrier ) So I know what a giant pain to support back-release levels. (It was such torture to see the new opcodes for RPG come out, and know that we couldnt use them because they would keep a program from being compiled to a previous version.)

But you should be able to convert the RPGIII to non-ile RPGIV wih no issues, and it will save you a ton of coding and support headaches. You wouldnt be able to use subprocedures, activation groups, and other ILE concepts, but you can take advantage of the new RPG opcodes that make life so much easier. (Especially date and string manipulations.)

You may know all of this, but I keep bringing it up because there's still a lot of people who dont, and they are missing out on a ton of productivity. They hang back on the RPGIII compiler because they believe the CvtRpgSrc command will make their program ILE. It doesnt. It simply brings the code forward to the RPGIV compiler, which is the compiler thats been updated for the past 17 years. In order to make the program ILE, you have to specify DftActGrp(*NO) on either the control spec or at compile time. As long as that statement doesnt exist, the program is as OPM as an RPGIII program, it was simply run through the newer compiler.

Comment

I wasn't aware you had to source upgrade RPGIII to RPGIV though, but it's worth moving programs to RPGLE if you are going to be doing any major updates to them.

Having said that, we have 3 programmers here who work in RPGIV. They can't comprehend RPGLE.

I must admit that for the most part I write my RPGH still in Upper Case, because my brain has been programmed for 31 years to see RPG code in Upper Case. I don't use procedures, Binding etc. Have a couple of times but it's just another way of doing the same thing I always have, and seems more complicated.

What I love about RPGLE is the use of the EVAL statement, %functions, nested IF's etc. They not only make coding simpler to do, they make it simpler to read as well.

I still use the RPG cycle too. It saves a lot of hard work, especially if processing a whole file and doing level breaks. That was what RPG was designed around, until a bunch of folks from the next generation said that it wasn't correct to write RPG that way. What do they know anyhow...

Comment

I still use the RPG cycle too. It saves a lot of hard work, especially if processing a whole file and doing level breaks. That was what RPG was designed around, until a bunch of folks from the next generation said that it wasn't correct to write RPG that way. What do they know anyhow...

Yes -- the cycle makes it easy to crank out code with level breaks. Have never understood why people would want to have a bunch of fields to track when a level break occurs and all the extra code to handle level breaks without the cycle.

Comment

Yes -- the cycle makes it easy to crank out code with level breaks. Have never understood why people would want to have a bunch of fields to track when a level break occurs and all the extra code to handle level breaks without the cycle.

It's nice to know that a few years down the road people are brave enough to stand up for the RPG cycle.

The amount of code required to manually check for detail time and total time level breaks, not to mention making sure you got the code right... when the RPG cycle does it all for you.

As with everything else, take the best of the new and the best of the old and use what works best.