Let's Write a Procedure

[MCWebsite.Staff]

** This thread discusses the article: Let's Write a Procedure **
This is a discussion about Let's Write a Procedure.

Click here for the article.

[thrystan]

Let's Write a Procedure

** This thread discusses the article: Let's Write a Procedure **
On the RPG400-l list at Midrange.com about a year ago there was a very nice method for dealing with prototypes that in my opinion is much better than using a second source member.

Below is a version of your example using this technique. I have modified your example so that the TESTCUBE program is in a different module than the CubeRoot procedure, and I am assuming that the CubeRoot procedure is in a module or service program.

[*]*********** Source Mbr: TESTCUBE *********** H OPTION(*NODEBUGIO : *SRCSTMT) /IF DEFINED(*CRTBNDRPG) H DFTACTGRP(*NO) ACTGRP(*NEW) /ENDIF /DEFINE PROTOTYPE_ONLY /COPY QRPGLESRC,MATHPROCS /UNDEFINE PROTOTYPE_ONLY D nRoot S 20P10 C eval *INLR = *ON C eval nRoot = CubeRoot(1234)[*]****** Source Mbr: MATHPROCS ********** /IF NOT DEFINED(PROTOTYPE_ONLY) H OPTION(*NODEBUGIO : *SRCSTMT) H NOMAIN /ENDIF D CubeRoot PR 30P10 ExtProc('CubeRoot') D nValue 30P10 Const /IF DEFINED(PROTOTYPE_ONLY) /EOF /ENDIF P CubeRoot B EXPORT D CubeRoot PI 30P10 D nValue 30P10 Const C return nValue ** (1/3) P CubeRoot E What this technique does is to move the prototype back into the same source member as the procedure, which I believe makes it much easier to maintain, while retaining the advantages of only having a single copy of the prototype. When MATHPROCS is compiled, since PROTOTYPE_ONLY is not defined, the compiler compiles it as normal. However when TESTCUBE copies MATHPROCS, since PROTOTYPE_ONLY is defined, the source within the In NOT DEFINED(PROTOTYPE_ONLY) is ignored, the prototype is copied and then the EOF within the IF DEFINED(PROTOTYPE_ONLY) causes the remainder of the source file to be ignored.

Joe Lee

[gwilburn@hobbyhouse.com]

Let's Write a Procedure

** This thread discusses the article: Let's Write a Procedure **
If it's this hard to use procedures, it's no wonder so many are still using subroutines and calls to external pgms. I spent the better part of an afternoon attempting to create and compile a simple procedure using your example and another example on this site for centering text in a field. No matter what I did, it WOULD NOT compile. At this point, i'm so confused that i don't know if I'll ever get it. And I taught myself RPG simply by looking at others code. Does someone - anyone - have a simple example of a REAL (simple)procedure.. I'm looking for "top down" explanation. I want the Source for the Proceudure, the source for the Prototype, and the ENTIRE source for the program that uses the procedure. Then, I want to know EXACTLY how each are compiled.... i.e. "option 14 in SEU" etc. I know I'm close, but if it's this hard to use - NO ONE wants to waste this much time to learn.

[buck.calabro@commsoft.net]

Let's Write a Procedure

** This thread discusses the article: Let's Write a Procedure **
> Does someone - anyone - have a simple example > of a REAL (simple)procedure.. As a self-taught RPG guy, I think I can relate to your situation. Here is a very simple program that uses a procedure: * Simplest procedure h debug dftactgrp(*no) actgrp('QILE') * dbgview(*list) * prototype - tells compiler what to expect when procedure is * invoked dincrement pr 10i 0 d inp_value 10i 0 const * work variables d a_number s 10i 0 d another_number s 15p 0 d result s 10i 0 * main line - invoke the procedure c eval a_number = 10 c eval result = increment(a_number) c result dsply c eval another_number = 1233 c eval result = increment(another_number) c result dsply c eval result = increment(15) c result dsply c eval *inlr = *on * procedure interface - the actual code that runs when the proc is * invoked pincrement b dincrement pi 10i 0 d inp_value 10i 0 const c return (inp_value + 1) p e It all fits in a single source member - I called mine ILEPROC1. Compile it with PDM option 14 and put dbgview(*list) on the command line before pressing Enter. That way you can debug the program if you want. Eyeball it for a bit and see if it makes sense. I highly recommend the RPG Redbook. After you've done a few inline procedures like this, take a stab at the ILE Concepts. The next step is service programs. I'd say that it took me about a week to really get all the ILE concepts down solid. I'd also say that ILE has a lot of elements that most of us will never use. Further, ILE means that we should seriously consider supplying a MAKE script of some kind along with source snippets for newcomers. I would be remiss if I failed to point out that subprocedures are not mutually exclusive with subroutines. I use them both, all the time. There's no need to convert all your subroutines into procedures; it's just an easy way to teach procedures (start with something you know and move on from there.) The good news is that once you've done a couple of procedures, the mechanical 'how do I...?' gets much easiler. Much. Think about how hard your first page at a time subfile was. ILE is about that level of effort. --buck

[David Abramowitz]

Let's Write a Procedure

** This thread discusses the article: Let's Write a Procedure **
In the promulgation of procedures, the disadvantages of the process are often left out. I am well aware of the advantages, here are two disadvantages:

1. The performance gain is often negligible.
2. The loss of a standard object (*PGM) for cross-referencing and documentation purposes can cause concern.

Dave

[avrahamn@coop.co.il]

Let's Write a Procedure

** This thread discusses the article: Let's Write a Procedure **
Assuming that IBM really wants to improve and simplify programming, here are some simple things IBM could do to improve the ease of use of procedures: Many programmers are ready to learn something new when they gain a real advantage, not when they do the same thing, just differently. Almost All RPG Programmers learned how to use RPG4 syntax, since it gave real advantage with lrager fields, use of prefixes, etc. But procedures do not give an immediate real benefit over CALL-PARM, just add more coding and do things diferently. In order to have a real advantage in procedures, IBM would need to improve it: eliminate its shortcomings, and also add stuff that is really useful. 1. allow to refer to the procedure in the module or service program directly. Currently when a procedure is called and the program has more than one service program and more than one module, You do not know where the procedure resides, and where to find it's code. The call to the procedure could take the following syntax: library/program-module!procedure(). Still if the user wants he could code it the way it is coded till now. 2. Add procedures to cross-reference produced in DSPPGMREF command. 3. Eliminate the need to specify the fields of the prototype 3 times: one time in the PROCEDURE INTERFACE, 2nd time in the called Module, and 3rd time in the calling module. The above improvements would just elimnate all the disadvantages of procedures. But to have a real working reason to use procedures, it needs to have some reolutionary advantage over call-parm. Here is my advice: 4. Add a syntax similar to command interface of OS400: PROCX parm1(&var1) parm2(&var2) parm59(&var59) &parm4(&varx). That way it is much easier to build procedures with many parameters, and use only the ones needed in the specific application. Those parameters which are not used will have default values. Also use the parameters in any order the user prefers.