 | |||
|
|
||
| |||
| |||
| |
|
Home > AS/400 Tips > iSeries programmer tips > The call of the prototype |
| |
|
|
|
| iSeries 400 Tips: |
|
|
|
|
|
|
|
|
|||||
|
ISERIES PROGRAMMER TIPS The call of the prototypePaul Tuohy 05.28.2004 Rating: -4.49- (out of 5)
|
[IMAGE] | |||||
Figure 1 shows the code of a calling program. It calls PGMB passing Parm1, a 10 character field, as a parameter.
Figure 1: A program call with a parameter field in a data structure
Figure 2 shows the code of the called program. It has an incorrect length of 15 for Parm1.
Will the compiler tell us that it is invalid? No.
Will the program fail at run time? No.
What will happen? When control returns to the calling program, Parm1 will have a value of 'ZZZZZZZZZZ' and Parm2 will have a value of 'ZZZZZYYYYY'. Just imagine the fun if Parm2 was a packed numeric field.
Figure 2: The called program with an invalid length for a parameter.
You really want the compiler to validate the parameter list for you, which is one of the reasons for using prototypes.
The Prototype
When the compiler sees a CALLP operation, it will validate to ensure that all the parameters are correct. But how does it know that the parameters are correct? You provide a prototype. A prototype
Digg This!
 StumbleUpon
 Del.icio.us
|
 |
 |
| |
RELATED RESOURCES
|
is the format, or the template, or the rules, for the call operation. It is not a parameter list.
Prototypes are defined on the D specifications, as shown in Figure 3. The format of a prototype is very similar to a data structure, except that the type is PR as opposed to DS. You can provide your own name for the CALLP (PromptProduct). The EXTPGM keyword indicates that this is the equivalent of a CALL operation, and it identifies the name of the called program (PRP01R). The names of the subfields in the prototype are irrelevant, what are important are the number of subfields (i.e. parameters) and the definition of each. In the example in Figure 3 the compiler will ensure that two parameters are passed, that Parm1 is a 30 character field and that Parm2 is a 1 character field.
Figure 3: A prototyped call to a program.
I quite like the ability to use a meaningful name on the call.
The Procedure Interface
What about the called program? Just as the compiler will validate the parameters on the call, you also want it to validate the parameters in the called program. You achieve that by replacing the *ENTRY PLIST with a Procedure Interface, as shown in Figure 4. The compiler will, again, require a prototype to enable it to validate the parameters.
Figure 4: A Procedure Interface.
Since the prototype is required in at least two programs, it makes sense to put it in a copy member and include it using the /COPY compiler directive.
And it makes even more sense to put all prototypes in a single copy member and include it in all programs using a /COPY compiler directive. Think of this as the source member containing the rules for all calls within your application.
Keywords
The use of keywords in the prototype can ease some of your coding. The example in Figure 5 shows a work field (Parm2) being used to pass an action code (or some such).
Figure 5: Using a work field on a parameter list
When using a prototyped call, you can use the CONST keyword to indicate that a constant value can be passed for the parameter, as shown in Figure 6.
Figure 6: Passing a constant value as a parameter.
Of course, you must make sure that the called program does not change the second parameter. If you are using a procedure interface, in the called program, the compiler will give you an error if you try to change a parameter that has a CONST keyword.
Another useful keyword is OPTION with a value of *OMIT or *NOPASS. Figure 8 shows an example of calling a program to set a customer name and address. The name is optional, as are the second and third address lines. OPTION(*OMIT) indicates that a value of *OMIT can be used in place of a parameter. OPTION(*NOPASS) indicates that the parameter is optional. Once a parameter is defined with OPTION(*NOPASS), all following parameters must be defined with OPTION(*NOPASS). All three calls are valid.
Figure 7: A prototypes call using *OMIT and *NOPASS.
Figure 8 shows a snippet of the called program. The name and address lines are set to their "default" values. The %ADDR BIF is used to check whether or not *OMIT was specified for the name; the address will be null if *OMIT was specified. The %PARMS BIF is used to check the number of parameters passed.
Figure 8: Checking for *OMIT and *NOPASS in a called program.
Conclusion
Remember, prototyped calls are not just for subprocedures. They are a means by which the compiler can validate parameters, and they allow you flexibility in how you pass parameters.
Also, if at a later stage, you decide to change any of these programs to subprocedures, all you need to do is change the EXTPGM keyword to an EXTPROC keyword and compile accordingly.
---------------------------
About the author: Paul Tuohy is CEO of ComCon, an iSeries consulting company. He is the author of Re-Engineering RPG Legacy Applications and is one of the quoted industry experts in the IBM Redbook "Who Knew You Could Do That With RPG IV?"
|
DISCLAIMER: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk. |
|
|||||
