| Editors: | Ted Holt | Managing Editor: | Mari Barrett | |
| Howard Arner | Technical Editor: | David Morris |
|
Volume 1, Number 16 sponsored by:Business Computer Design, Int'l, Inc.
|
|
|
|
|
|
Prototyping *ENTRY Parameters, Part I Hey, Ted: Our shop made the switch from RPG III (AKA RPG/400) to RPG IV (AKA ILE RPG), but we continue to define program parameters using the *ENTRY/PLIST op code. I have seen other people's code in which the entry parameters are defined in the D specs. I don't understand what they did or why. Is it advantageous to define entry parameters in D specs rather than in C specs? If so, what rules do I need to know? Yes, prototyping entry parameters is advantageous because you get all the advantages of prototyping: * The compiler can detect parameter mismatches between calling and called programs * Read-only parameters can be passed between programs * Expressions and literals can be passed to a program Suppose you have a program, PARMX2, with two parameters.
C *ENTRY PLIST C PARM CUST 70 C PARM ACTION 5To convert these lines to a prototyped parameter list, the first thing you need is a procedure prototype. It should be stored in a source member of its own, so it can be copied (using the /COPY compiler directive) into this program as well as into calling programs. If you don't have a source physical file for prototypes, create one using the Create Source Physical File (CRTSRCPF) command.
CRTSRCPF FILE(MYLIB/QPROTOSRC) I've called the file QPROTOSRC, but you can use some other name if you prefer. Put the prototype for your program in a source member in the file of prototypes. This means the spec with the pr and the parameters that immediately follow it. In this example, it would be these lines.
D ParmX2 pr extpgm('PARMX2')
D customer 7p 0
D action 5
Notice that the program's name is specified in the External Program (EXTPGM) keyword of the prototype (pr) spec. The procedure name, beginning in column 7, does not matter because the name comes from the EXTPGM keyword--it can be any valid identifier--but it's easiest to use the object name, as I have done here. Parameters are listed below. The names do not matter, but I suggest you use the same names you use for the parameters in the program. In the program, create a procedure interface in the D specs, like this.
D ParmX2 pi D customer 7p 0 D action 5 This looks much like the prototype, but differs in the line type (PI instead of PR) and the absence of the EXTPGM keyword. When I create these, I write one of them, then copy it to the other place and modify it as needed. While the names of the parameters in the prototype aren't important, the names of the parameters in the procedure interface matter greatly. These identifiers are the names that the program must use to refer to the parameters. Make the program and its callers /copy the prototype. Program PARMX2 would contain the following lines, which I will show you after the advertisement below.
Now, back to coding. Like I said above, make the program and its callers /copy the prototype. Program PARMX2 would contain the following lines:
* *ENTRY parameter list D/copy qprotosrc,parmx2 D ParmX2 pi D customer 7p 0 D action 5 It is a good idea to include a comment with the term *ENTRY in it, as I have done here, so that you can quickly locate the entry parameters when you open the member. Calling programs need the /copy statement and D specs to define the fields to be passed to PARMX2. Those fields do not have to have the same names as the parameters in the called program.
D/copy qprotosrc,parmx2 D ParmX2 pi D cust s 7p 0 D action s 5 C callp parmx2 (cust : action) The rules are slightly different if the member will be compiled as a module. In that case, you do not use the EXTPGM keyword, because you're not creating a program. There is an External Procedure (EXTPROC) keyword that you may use, but this is optional. If you don't specify EXTPROC, you must use the same name as the created object in the EXTPROC, but you may use some other valid identifier in column 7. One thing to be aware of with the EXTPROC keyword is that the procedure name specified is case sensitive, where the program name specified with EXTPGM is not. Here's an example that uses the external procedure name in both places.
D ParmX2 pr extproc('PARMX2')
D customer 7p 0
D action 5
D ParmX2 pi
D customer 7p 0
D action 5
Here's an example that uses a different name in column 7.
D ThisModule pr extproc('PARMX2')
D customer 7p 0
D action 5
D ThisModule pi
D customer 7p 0
D action 5
And here's an example without the EXTPROC keyword. EXTPROC is assumed to be PARMX2 in uppercase.
D ParmX2 pr D customer 7p 0 D action 5 D ParmX2 pi D customer 7p 0 D action 5 As with prototyped programs, you really should put the prototype into a member of its own and /copy it into both callers and the called module. That's enough to chew on for one day. In a soon-to-come edition of Midrange Guru, I'll talk about read-only parameters, expressions, and literals. -- Ted
Subscription And Advertising Information
Subscription Information To unsubscribe, change your email address, or sign up for any of Guild Companies, Inc's free email newsletters, visit http://www.itjungle.com. Hit the SUBSCRIBE button on the homepage and it will lead you to our online subscription system. When you sign up for one of our e-newsletters, you can be assured that your e-mail address will NEVER be sold to an outside company.
Advertising Information Please see our advertising opportunities and pricing at http://www.itjungle.com/advertising.html
Or contact Timothy Prickett Morgan at
Phone: 212 942 5818 Email: tpm@itjungle.com
|  |
|
Hey, Ted: I recently started a new job. My new employer has a Model 270. Nobody knows where the key is. What do we do? (By the way, I love your newsletter.) -- Rich Thanks for reading, Rich. I love putting this newsletter together. Every new iSeries (AS/400) ships with two keys and a tag on a key ring. The tag has an ID number on it that you will need in order to order extra copies of the key. The smart thing to do is to put the two keys and the tag in three separate, secure places. I suspect that many shops leave all three items on the ring, with one of the keys inserted into the lock. If you don't know where the tag or keys are, you'll have to place a service call to IBM. IBM will sell you a new control panel and charge you to install it. I estimate you'll be out about $500 to $600. If the machine is still under warranty, you may get the new part for free, but I doubt it. Some CEs take one key and a ring or twist tie and attach it inside the back cover of the system unit. The second key and the tag are generally given to the MIS director for safekeeping. If the shop has ever had an AS/400 before, there is usually a cardboard box around near it. It may have a picture of a tape reel on the end. This is where the CE stores most of his test tools. You might try there. Good luck.
Hey, Ted: Hey, Ted: I have been programming in C for the AS/400 for almost 2 years now, and following your editorials for several months, and have yet to see you admit C programming on the platform can even be done, let alone address the issue. Typical is the November 7, 2001 issue of Midrange Guru, in your article on optimization. You mention RPG, COBOL and CL, but not even a hint of C. Surely you can optimize an ILE C program just like you can optimize an RPG or COBOL module, right? V5R1 supports C++, I'm told, and you can bet we will use that extensively as soon as we can. I guess we'll continue to struggle along in the backwaters of the little-known languages like C and C++ while the rest of the AS/400 and iSeries) world plays happily with their cutting-edge RPG and COBOL languages. Pardon the sarcasm. I know most AS/400 programmers are still using RPG and COBOL. It just irks me that information on using the C language on this wonderful platform is so blasted hard to come by. -- David Your point's well taken, David. I don't use C on the AS/400 or iSeries, so I forget it's there. I will try to do better. The October 24 issue of the Midrange Guru included a tip for C programmers. It dealt with timing out sockets programs. Since you missed that issue, I am sending it to your email. Would you like to help out your own cause? Send me some tech tips in C, preferably things that would be hard to do in RPG or COBOL. I'd like to take such a tip and write up the (messy) RPG equivalent to make a point about how much easier C can be in certain cases, such as dealing with APIs. -- Ted
If you have a tough problem, our gurus can probably help. Their mailboxes are always open. * Email Ted Holt at tholt@itjungle.com * Email Howard Arner at harner@itjungle.com |
This document may be redistributed freely and enthusiastically by email, but only in its unedited form. Thanks for your cooperation.
Midrange Guru is a registered trademark of Guild Companies, Inc. IBM, AS/400, iSeries, OS/400, and eServer registered trademarks of International Business Machines Corp. All other product names are trademarked or copyrighted by their respective holders.
