Computer programming/Procedures and functions
edit] this module to improve it. See this module's talk page for discussion.}}
Different terminology is used in different programming languages to mean different things. The same things in different languages can have different names. Programs, Procedures, Functions, Subroutines, Subprograms, Subqueries ... these words all have very similar meanings. The issues or differences are whether they can stand alone;
We can call an object, it executes and performs a complex process. Whether that object is called any one of the above list depends on what programming language it is written in, whether a human being can call it, or whether it has to be called by another program or one of the other names on the list.
Subroutines and functions
In general programming theory, when an institution using the programs can have libraries of millions of programs collectively with billions of lines of source code, we want to avoid duplication of having the same code in multiple places. Suppose something needs changing. There is a new error message to add to the collection. Customer numbers just went from being 6 digit #s to 8 digits. There is a new currency, such as the Euro, to be handled. If this stuff was referenced in every single program that worked with it, we could have tens of thousands of programs to have to update to handle the change. But if there are sub-programs to handle different scenarios, then when that scenario changes, the only update is to the relevant sub-program. Similarly, when we write a new program, many elements of what it needs are already in existence, such as accessing a particular file to get a particular kind of data, calculating on-hand inventory. Instead of writing many lines of source code to do that function, with that code replicated across millions of programs, we can call the standard sub-program that performs that function.
In some languages there are parameters to be passed from the calling program to the called program. The secondary program causes those values to be altered, then returns control to the primary program. This architecture, of one program calling a secondary program to do specialize work for it, can in fact go many levels deep. The different programs, that are calling each other, can be written in many different languages. This is done for two big reasons: organization of overall functions into logical manageable pieces; and different languages are better suited to different types of functions.
Subroutines in C and C++
Both C and C++ have a mechanism for creating subroutines; these are called functions in both languages. Variables declared within a function are local to that function; this mechanism provides a separation of namespaces that prevents name clashes and unpredictible errors. Here is a sample C++ program with a function
#include<iostream>
using namespace std;
double cube(double x);//declaration of the function cube indicating
//that it accepts a double as an argument and returns a double (precision)
//decimal number
int main(void)
{
cout << cube(8) << endl;
return 0;
}
double cube(double x)//implentation of the function cube
{
return x*x*x;
}
Here is a blow-by-blow commentary on this program. The first
line of code sees a call to function cube. Since we put the declaration
at the top of the program, the compiler knows that we are creating a function
called cube which accepts a decimal number (double) argument and which
returns a decimal number. This return value will be substituted in liew
of the expression cube(8) once is is computed.
Since we are making a call to cube, control passes to it. A copy of the
argument 8 is made and passed to cube. The expression x*x*x is now
evaluated; the result is 512. This result is passed back to the
calling routine (main) and substituted for cube(8). The number 512 is
now printed to standard output. Finally, an endl (end of line) is passed
to the screen and the cursor goes to a new line.
Subroutines and "sub contents" in RPG
RPG has sections of code to handle activities like file definition, tables & arrays defined, input, output, communications with other systems and other programs, various kinds of data structures defined, and calculations. The calculation section has a main routine and any number of subroutines which can be called from the main routine and from each other.
In RPG, a chunk of source code is called a subroutine if it has a defined begin point and end point and is embedded within the main program. Some point in the main program calls the subroutine. Control goes to the start of the subroutine which then has control until either it gets to the end point or prematurely hits an exit statement within the body of the subroutine. Here is an example:
Main calculations routine
RPG statement
RPG statement
RPG statement
EXSR $TOP
RPG statement
RPG statement
End of main routine
The EXSR command means Execute Subroutine. Subroutine names can include letters, symbols, and numbers, but may not start with a number. Since a compilation includes a cross index of all elements used in the program, it is customary to use a special character at the start of certain kinds of functions, so that they all show up in a consistent location in the cross index, such as currency symbol for subroutines, and some other symbol for output to printer.
At the beginning of any subroutine it is good programming practice to place comments with a summary statement or explanation of what the function is of the $TOP subroutine, such as to handle what is to be printed at the top of the report.
Comments
BEGSR
RPG statement
RPG statement
RPG statement
EXCPT @PAGE
EXCPT @TITLE
RPG statement
RPG statement
EXCPT @HEAD
RPG statement
RPG statement
ENDSR
BEGSR is the begin subroutine statement, while ENDSR is the end subroutine statement. EXCPT is the statement that identifies some type of output to a printer or printer-like file. Data can be written to a log or other object that is in a format similar to printout, sequential lines of stuff.
When control is transferred from this program to another program, called by this one, then this one calls that other program a sub-program. Sub=programs contain other types of RPG content such as file definition, input output etc. A sub-program does not need to access any files. It can get all of its data from data structures populated by the calling program.
These subroutines and subprograms are merely a way to organize the program into logical chunks of the work to be done. We can think of them as being black boxes which are fed in various different standard pieces of information, only to return predictable results to the main program. Thus when a program needs to be maintained, we can effectively ignore that part of the program that has nothing to do with the maintenance effort. This is critical when we are maintaining programs whose collective source code, main routines and subroutines and subprogram contents, can run to hundreds of thousands of lines of code.
If you were to compare a listing of the actual source code of an RPG program, and what is there at time of compilation, you would probably see a lot of stuff in the compile that is not explicitly in the source code. This usually gets there one of two ways.
If using a standard externally described object, such as a file or data structure, the source code only needs to specifiy that object with a few lines of code, which one, and what changes are needed for its handling in this program. At compile time, the whole layout of the file, such as all columns of the table, is called into what gets compiled.
Another way, when using standard subroutines, or the code for calling standard subprograms, that are to be replicated in millions of other programs, is not to have that code within the source code of every one of the millions of programs, but to have a single line of code identifying what standard code is to be brought in here, and if in this program any of it is to be referenced by other names.
Very few other languages can be embedded within RPG source code, such as SQL/400. RPG programs can transfer control to other programs, which RPG calls sub-programs. Those other programs can be written in any language. Depending on language, those programs need to be written so as to expect to be called, and the code, associated with this handshake with the calling program, can make it impractical to run the program in some way other than being so called.
Different kinds of error messages, with their associated help links, can be stored in different libraries based on the nature of the problem. A person, using this program, may have called for a record that does not exist, tried to get at values that are out of bounds.
The most hours in one day is 25, which is only on the day that gets changed due to daylight savings. If someone tries to enter what activities occurred in a factory in one day, and the total time by one factory worker is more than 25 hours, this is an example of input that is out of bounds.
The program needs to communicate back to the user what the problem is. Part of the message handling can use a sub-program that only knows what error message is involved by some reference code. The actual current error message is not explicitly referenced in the sub-program that handles error messages, so that it can handle any different error message. The only parameters it needs are those that define how to access the particular error message and its associated references, such as the manner in which a user may interact with it.
| 
