PMS Information Systems
Welcome to PMS Information Systems - IBM i (AS/400) Forum !!!

Get Answers for all your queries on IBM i (AS/400).

PASSing DATASTRUCTURE as a PARAMETER in RPG IV

View previous topic View next topic Go down

PASSing DATASTRUCTURE as a PARAMETER in RPG IV

Post  maran on Sat Aug 11, 2012 12:48 am

In we can pass DS as a parameter by 2 methods in RPG IV.

First Method:

Besides declaring the prototype and procedure interface, We must define a data structure and a pointer to the data structure, as in the following code for called program DSPARM.
D DSParm pr extpgm('DSPARM')
D Parm1 like(ParmData)
D
D DSParm pi
D Parm1 like(ParmData)
D
D ParmAddr s *
D ParmData ds based(ParmAddr)
D Action 8
D Code 2
D RtnVal 2s 0
D
C eval ParmAddr = %addr(Parm1)
C action dsply
C code dsply
C rtnval dsply
C eval rtnval = 21


We must set the pointer to the address of the parameter so that manipulating the data structure manipulates the parameter. After the eval runs, anything we do to Action, Code, and RtnVal will take place within Parm1.



Second Method:


The second method is for V5R1 or later. Use the LIKEDS keyword to define subfields for the parameter. We will have to qualify references to the parameter's subfields by preceding each subfield name with the parameter name and a period. We no longer need the pointer.
D ParmData ds
D Action 8
D Code 2
D RtnVal 2s 0
D
D DSParm pr extpgm('DSPARM')
D Parm1 likeds(ParmData)
D
D DSParm pi
D Parm1 likeds(ParmData)
D
C Parm1.action dsply
C Parm1.code dsply
C Parm1.rtnval dsply
C eval Parm1.rtnval = 21
Data structure ParmData and its three subfields are not equivalent to the parameter. To access the parameter's data, we must use the qualified subfields.
If we like to place the prototype in a member of its own, as we do, include the data structure in the prototype so that calling programs also have access to the data structure's definition. Here's the copy member that contains the prototype.
D ParmData ds
D Action 8
D Code 2
D RtnVal 2s 0
D
D DSParm pr extpgm('DSPARM')
D Parm1 likeds(ParmData)
D
Here's the called program. It receives the data structure as Parm1 and qualifies the subfields.
D/include prototypes,dsparm
D
D DSParm pi
D Parm1 likeds(ParmData)
D
C Parm1.action dsply
C Parm1.code dsply
C Parm1.rtnval dsply
C eval Parm1.rtnval = 21
Here's part of a calling program. MyDS is the data structure that is to be passed to the called program. Notice that all references to the subfields are qualified.
D/include prototypes,dsparm
D
D MyDS ds likeds(ParmData)
D
C eval MyDS.Action = 'READNEXT'
C eval MyDS.Code = '33'
C eval MyDS.RtnVal = *zero
C callp DSPARM (MyDS)
C if MyDS.rtnval = *zero
Data structure ParmData is defined in both the calling and called programs, but is used only as a pattern. The real data is in MyDS in the caller and in Parm1 in the called program.
In this example, the data structure that is being passed from one program to another is only twelve bytes long. However, if it were much longer, we might want to keep the compiler from allocating storage for the pattern data structure in the copy member. To prevent the allocation of storage, use the BASED keyword.

D ParmData ds based(typedefinition_dummy)
D Action 8
D Code 2
D RtnVal 2s 0
D
D DSParm pr extpgm('DSPARM')
D Parm1 likeds(ParmData)
D

Data structure ParmData is still defined in both the caller and called programs, but no storage is allocated for ParmData in either.

The use of the BASED keyword also prevents programmers from using the pattern data structure as a working variable. Instead, programmers must define data structures that are to serve as working variables by using the LIKEDS keyword.

Everything to this point works fine if there are no identifiers in the calling program that have the same names as those of the data structure subfields. To avoid such collisions, add the QUALIFIED keyword to the data structure definition in the prototype member.

D ParmData ds based(typedefinition_dummy)
D qualified
D Action 8
D Code 2
D RtnVal 2s 0
D
D DSParm pr extpgm('DSPARMQ')
D Parm1 likeds(ParmData)
D

Here's a calling program that declares a variable named ACTION. Because of the QUALIFIED keyword, this program has no trouble distinguishing between ACTION the standalone variable and ACTION the subfield.
D/include prototypes,dsparm
D
D MyDS ds likeds(ParmData)
D Action s 24
D
C eval Action = 'Go getum!'
C eval MyDS.Action = 'READNEXT'
C eval MyDS.Code = '33'
C eval MyDS.RtnVal = *zero
C callp DSPARM (MyDS)
C if MyDS.rtnval <> *zero


The following example uses two data structures as parameters.
Here's the prototype copybook member. The two pattern data structures have names that end with an underscore (_) and a lowercase letter t to remind programmers that these data structures serve as data types, not as real variables with allocated storage.
D custInfo_t ds qualified based(typedummy)
D name 100a varying
D id_no 10i 0
D addr 100a varying

D partInfo_t ds qualified based(typedummy)
D name 100a varying
D id_no 10i 0
D cost 15p 3

D buyOne pr
D cust likeds(custInfo_t) const
D part likeds(partInfo_t) const
D num 10i 0 value
A caller of the procedure would use the data structure names as pseudo data types. All references to the subfields would be qualified.
/copy prototypes,custtrans
D theCust ds likeds(custInfo_t)
D thePart ds likeds(partInfo_t)

/free
theCust.name = whatever;
buyOne (theCust : thePart : num);
/end-free
avatar
maran
Admin

Posts : 442
Join date : 2009-07-24

View user profile http://pmsinformationsystem.forumotion.net

Back to top Go down

View previous topic View next topic Back to top

- Similar topics

 
Permissions in this forum:
You cannot reply to topics in this forum