What are the important difference between GOTO and EXSR in RPGLE (As400)

Question

What are the important differences between GOTO and EXSR in RPGLE

Answer 1

As I mentioned in the comments to his answer, @Mike has a very good answer, but let me provide a dissenting conclusion. Most folks learning RPG these days already know how to program using structures very similar to ILE procedures. RPG's subroutines and GOTO are relics of a bygone age. Do not attempt to use either. They rely solely on global variables for communication with the rest of the program. This practice reduces code reusability, and arguably readability since any routine anywhere in the program could cause a failure in any given subroutine. Magic subroutines like *INZSR and *PSSR which are called at the whim of the compiler, yes, I know when they are called, but I don't get to call them explicitly, make error handling enigmatic at best.

Best practice is to code modern RPG using **free, dispense with the cycle, and use only sub-procedures for code reuse. The magic subroutines don't even work in this environment since the cycle is not compiled in. Sub-procedures can do everything a subroutine can do and more. They provide local variables, static variables, and if necessary can use global variables. They have parameters and return values. They make the programs more modular by doing away with the need for global variables, and that also makes them more readable as they no longer need be affected by code in other parts of the program.

So no, do not use either EXSR or GOTO if you can at all help it. Prefer CALLP instead, your programs will work more like you are used to, and you won't have to worry about old obsolete op codes unless you encounter them in an existing program.

Answer 2

Both of these operation codes cause the execution of code to jump to a different point within a procedure, but they have some differences. GOTO is the simpler of the two, being an unconditional jump command, essentially "go to here and start executing whatever is there". This is one of the oldest commands in programming languages and its use is usually frowned upon today. One of the goals of the "structured programming" philosophy of the 1970's was to replace GOTOs with conceptually higher constructs that better describe what the programmer's intent is and that make it easier to understand that intent by reading it. You can find those replacement operation codes listed here.

EXSR is the command to execute a subroutine. While RPG does not list it among the Structured Programming Operations, it is intended to work toward the same goals of increasing code clarity, reducing errors, and minimizing code duplication. It is like a GOTO in that you unconditionally jump to a new section of code, but that section of code is a named subroutine within your procedure or program. This is useful whether you just want to name sections of code more clearly, if you want a section to execute multiple times, be called from multiple places, or whether you want to take advantage of the related operation code LEAVESR, which acts as an easy way to get out of a subroutine before you reach the ENDSR and return to the section of code you were executing just after your EXSR. GOTO can also do this, by using two labels, marked with the TAG operation, but it is usually less clear and you have to maintain a list of labels to keep straight how you are jumping around.

It is worth noting that anything that the structured operation codes can do could instead be done by GOTO, but that does not make it a good idea to write code that way. The higher commands were invented for the ease of people, not for the ease of the computer. In principle, they should compile down to very similar machine code, but there is a vast difference in documenting the programmer's thought process and intent.

It is also worth noting that RPG has two different levels of subroutines, whereas most programming languages only have one. A subroutine exists within a procedure or program and is more similar to a GOTO or structured programming operation. It does not have arguments that can be passed to it or variables that are scoped to it.

A procedure is more like functions and subroutines that you would find in other programming languages. It can have locally scoped variables (useful so you don't have to remember to manually clear them), it can be passed arguments (useful so you don't have to have as many temporary variables declared in your main program), and it can return a value (a variable or a data structure) so that you can pass a value back to your main program. These all make procedures a more flexible option and promote better code reuse, but I have found a few drawbacks to debugging them. The RPG debug tools like the DUMP operation will only correctly show the values of variables if the dump is called within the procedure. This does not work well with coding styles that have all errors be collected by one program-wide *PSSR subroutine. You would have to make more use of the MONITOR operation or put a *PSSR with a DUMP in each procedure. Also while RPG passes an error up the call stack to the calling procedure similar to many programming languages, the basic RPG language does not provide a built-in facility for your code to throw an error which is often useful for procedures to communicate failure effectively. I use a ThrowError procedure that I learned from the IBM Red Paper on RPG Exception and Error Handling. These techniques can make for robust code if you apply them correctly, but it does make procedures somewhat harder to code than subroutines, especially for beginners or for simple programs. I would recommend mastering subroutines and other structured programming constructs first, then moving on to procedures.