Bryan's RPG IV Journal
Prototyping Data Structures
Q. I've heard you say that I can pass a data structure as a parameter, or accept it as a return value. How do I do this?
A. There are a couple of additional coding requirements when you are prototyping a data structure as a parameter or a return value.
First, you need to define the layout in a separate data structure. There's no special requirement for this data structure; it can be program-described or externally-described.
Next, to use the data structure as a parameter or a return value, you code the LIKEDS keyword, referring to the data structure as the reference:
Of course, in the called procedure, you'll need to include the LIKEDS keyword in the procedure interface as well. If the called procedure is a NOMAIN procedure (i.e., it's in a separate module), you'll need to also code the reference procedure in that module.
Although this example doesn't show it, I also recommend that the data structure be a qualified data structure. Then you would refer to subfields by their qualified name -- Mail.Identifier, Mail.Name, Mail.Address1, etc.
At V5R2, you can also use the LIKEREC keyword on a prototype and a procedure interface, to define a parameter or return value like a record format. For example, the following prototype would pass a record format to a procedure:
A. There are a couple of additional coding requirements when you are prototyping a data structure as a parameter or a return value.
First, you need to define the layout in a separate data structure. There's no special requirement for this data structure; it can be program-described or externally-described.
Next, to use the data structure as a parameter or a return value, you code the LIKEDS keyword, referring to the data structure as the reference:
D Myproc PR 1NNote that I named the parameter (Parm1) in the prototype. While it is not usually necessary to name parameters in a prototype, in this case, the notation in columns 7-21 serves to separate the parameter from the return value. If I had not included the Parm1 notation, the compiler would have treated the LIKEDS line as a continuation of the return value, not as a separate parameter. (This is also necessary when you code a parameter with LIKE or LIKEREC.)
D Parm1 Likeds(Mail)
D Mail DS
D Identifier 5U 0
D Name 35
D Address1 35
D Address2 35
D City 21
D State 2
D Zipcode 10
Of course, in the called procedure, you'll need to include the LIKEDS keyword in the procedure interface as well. If the called procedure is a NOMAIN procedure (i.e., it's in a separate module), you'll need to also code the reference procedure in that module.
Although this example doesn't show it, I also recommend that the data structure be a qualified data structure. Then you would refer to subfields by their qualified name -- Mail.Identifier, Mail.Name, Mail.Address1, etc.
At V5R2, you can also use the LIKEREC keyword on a prototype and a procedure interface, to define a parameter or return value like a record format. For example, the following prototype would pass a record format to a procedure:
FMaillist UF E K Disk
D Myproc PR 1N
D Parm1 Likerec(Mailfmt:*All)
Log of Journal Entries |
|
Use this scrollable blog map to view other journal entries: |
|
| It is your responsibility to ensure procedures, techniques, and code used from this website are accurate and appropriate for your installation. No warranty or support is implied or expressed. |
![]() |
| Privacy and Email Policy |
| AS/400®, eServer, i5/OS, IBM i, Integrated Language Environment®, iSeries, OS/400®, RPG/400®, System i5, VisualAge®, and WebSphere® are trademarks of IBM Corporation. Note: IBM® System i is the latest member of the family of eServer iSeries. This site might refer to System i as System i5, iSeries, or AS/400. |
|
If you are having trouble navigating the menu at the top of this page, you may use the following scrollable site map instead: |
|
|











International visitors: