1. Can be used as functions -
subroutine 1. loading workfields 2. call subroutine 3. move result fields to fields to be used
SubProcedure - callp can return value and lists parameters in ()
so you can have the statement
if vldDate( MyDateIn );
...
else
...
endif
2. Isolation
any fields that you declare in the sub procedure are local even if they have names of
fields in the main.
Phil
Last Wiki Answer Submitted: April 20, 2009 1:25 pm by philpl1jb44,190 pts.
All Answer Wiki Contributors: philpl1jb44,190 pts.
If you live outside the United States, by submitting your email address you consent to having your personal data transferred to and processed in the United States.
Subprocedures are really cool. They take a little extra coding but are a great way to minimize the code in the main sections of a program.
Subroutines also have their place. Now that I’ve worked with both subroutines and subprocedures I find that subprocedures are not always the best solution.
I know some say we should dump all our subroutines and only use subprocedures. This reminds me of comments in the past that said, “If your resume does not include xxx your career is over”, which proved to be totally wrong.
Use what makes the most sense as various cases arise. The i Series provides developers a wealth of tools. Don’t limit yourself just because a particular item is trendy.
I think that the best answer is simply: re-usability. Also, I think that that is the best indicator of when to use a sub-procedure. If it can be used in more than one program then use a sub-procedure. If not, generally you should use a subroutine.
The ability to use local variables in subprocedures greatly faciliates writing better and easier to maintain code. Yet many long time RPG programmers still continue to create programs the way they always have and don’t take advantage of the power of subprocedures.
Having to weed through a huge, monolithic program underscores how beneficial local variables can be. Changing the value of a global variable at the wrong time can break critical business logic, as we’ve all probably encountered. Using a local variable that’s confined to the code which uses it reduces the risk that you or someone else who later comes along to modify it is going to alter behavior elsewhere in the program that they did not intend. It also reduces the time they’d have to spend analyzing the effect of their change on the whole entire program.
Subprocedures are really cool. They take a little extra coding but are a great way to minimize the code in the main sections of a program.
Subroutines also have their place. Now that I’ve worked with both subroutines and subprocedures I find that subprocedures are not always the best solution.
I know some say we should dump all our subroutines and only use subprocedures. This reminds me of comments in the past that said, “If your resume does not include xxx your career is over”, which proved to be totally wrong.
Use what makes the most sense as various cases arise. The i Series provides developers a wealth of tools. Don’t limit yourself just because a particular item is trendy.
I think that the best answer is simply: re-usability. Also, I think that that is the best indicator of when to use a sub-procedure. If it can be used in more than one program then use a sub-procedure. If not, generally you should use a subroutine.
The ability to use local variables in subprocedures greatly faciliates writing better and easier to maintain code. Yet many long time RPG programmers still continue to create programs the way they always have and don’t take advantage of the power of subprocedures.
Having to weed through a huge, monolithic program underscores how beneficial local variables can be. Changing the value of a global variable at the wrong time can break critical business logic, as we’ve all probably encountered. Using a local variable that’s confined to the code which uses it reduces the risk that you or someone else who later comes along to modify it is going to alter behavior elsewhere in the program that they did not intend. It also reduces the time they’d have to spend analyzing the effect of their change on the whole entire program.