× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Thanks Scott,
  Your example of using a based on DS to load the data worked great.
   
  

Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx> wrote:
  
Hi Jeff,

On Tue, 14 Mar 2006, Jeff Young wrote:
>
> Occurs is not allowed on a prototype parm. How do I define it then?
>

Here's a really simple example of how you might code this:

--------- /COPY member for MODULE B's prototype ------------

D ModuleB PR
D DS_A_p like(DS_A)
D Count 10I 0

--------- Source for Module A ------------------------------

/copy prototypes,moduleb

D DS_A DS occurs(15)
D Field1 1A
D Field2 3P 0

D Count s 10I 0
D x s 10I 0

/free
%occur(DS_A) = 1;
ModuleB(DS_A: Count);

for x = 1 to count;
%occur(DS_A) = x;
dsply (Field1 + ' ' + %char(Field2));
endfor;

*inlr = *on;
/end-free

--------- Source for Module B ------------------------------

/copy prototypes,moduleb

D ModuleB PI
D DS_A_p like(DS_A)
D Count 10I 0

D DS_A DS occurs(15)
D based(p_DS_A)
D Field1 1A
D Field2 3P 0

D Alphabet s 15A inz('ABCDEFGHIJKLMNO')
D x s 10I 0
/free
p_DS_A = %addr(DS_A_p);
count = %elem(DS_A);

for x = 1 to count;
%occur(DS_A) = x;
Field1 = %subst(Alphabet:x:1);
Field2 = x;
endfor;
return;
/end-free

--------- End Of Trivial Example ------------------------

It's important that you set the %occur() for DS_A to 1 prior to passing it 
to ModuleB. Remember that parameters work by sharing memory. Even though 
you may think of passing DS_A as "passing the data structure" what it 
really does is tell MODULEB where DS_A is located in the computer's 
memory.

Since each occurrence of DS_A is located in a different spot in memory, 
you want to make sure you've set it to the first one. That way, you'll 
share everything from occurrence 1 to the end of the MODS.

A pointer is a variable that stores memory addresses. Since MODULEB will 
be getting a parameter that's in the same spot in memory as DS_A, you can 
get it's address and assign it to a pointer. Any variable that's based on 
the pointer will occupy the same exact spot in the computer's memory as 
the parameter passed in.

So even though only the first occurrence is passed in the DS_A_p 
parameter, the fact that a 15 occurrence DS is based in the same area of 
memory will allow MODULEB to access all 15 occurrences.

If this type of pointer logic confuses you, all I can suggest is that you 
not use MODS as parameters. Since prototypes don't support MODS, you can 
eliminate the ugly pointer logic by using an array of data structures.

I realize that you can't fetch multiple records into a DS array using 
embedded SQL. However, you CAN fetch one record at a time from a cursor 
into a DS defined with LIKEDS, and then copy that DS into one element of a 
DS array. Granted, this takes a little bit of extra processing time, but
unless performance is absolutely critical, you won't notice it. That way, 
you can use arrays of qualified DSes with embedded SQL, and not worry 
about the ugliness of trying to get MODS through a prototype.

Let me know if you want an example of that.

---
Scott Klement http://www.scottklement.com


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.