|
I realize you're passing by reference on dynamic calls and have no choice in the matter. All I was trying to point out was that by doing a couple of things in the D specs you could write simpler _looking_ code. i.e. avoid hooking the data structure to the parameter in the C specs. The thing that is perplexing to me is that it worked. I tend to think of this in terms of what I learned about C where parameter passing is by value by default. In C when you pass a pointer the function that receives it operates on the value contained in the memory location by use of the dereferencing operator. If you're passing a pointer by reference, you're passing a reference to a pointer (the address of the memory space that contains the address of the memory space that contains the address of the data) and it appears there's some dereferencing by magic going on. It seems like the data structure based on the pointer passed by reference shouldn't have a direct link to the data structure in the calling program. Although, come to think of it, if you pass a pointer to a sub procedure that's defined within a program it acts like it was passed by value too. I think I'm out of my depth here. Maybe I'll try to learn alternating arrays instead. <g> > -----Original Message----- > From: jpcarr@TREDEGAR.COM [mailto:jpcarr@TREDEGAR.COM] > Sent: Tuesday, November 28, 2000 10:50 AM > To: RPG400-L@midrange.com > Subject: RE: Passing pointers as parms > > > > Joel > > ReRead my earlier post about passing by Reference on a dynamic call. > Since you didn't use the VALUE keyword on your pointer parm, You are > still (like the dynamic call) > passing by Reference. > > John > > > > > > Joel Fritz > > <JFritz@sharperim To: > "'RPG400-L@midrange.com'" > age.com> > <RPG400-L@midrange.com> > Sent by: cc: > > owner-rpg400-l@mi Subject: RE: > Passing pointers as parms > drange.com > > > > > > 11/28/2000 01:06 > > PM > > Please respond to > > RPG400-L > > > > > > > > > > Maybe it was something like this: > > You have a data structure in your calling program you want to > update in the > called program. If you pass a pointer, which appears to be > legal and well > behaved in the very limited test I just ran, all you do is > copy the data > structure definition into the called program and base it on > the pointer > that's passed in. It's the same thing you're doing with > slightly and maybe > even inconseqentially fewer lines of code. You are > absolutely right that > passing by reference is passing by reference and that's the > default in RPG. > Here's my test: > > Calling program: > > Fqsysprt o f 80 printer > > D ptrtst2 pr extpgm('PTRTST2') > > D pointer * > > D > > D datastruct ds > > D packed 5p 0 inz(99999) > D char 5 inz('five') > > D > > D ptrparm * inz(%addr(datastruct)) > C > > C except before > > C callp ptrtst2(ptrparm) > C except after > > C eval *inlr = *on > > Oqsysprt e before > > O 'Before--packed = ' > > O packed j > > O +1 'char = ' > > O char > > O e after > > O 'After--packed = ' > > O packed j > > O +1 'char = ' > > O char > > > > Called program: > > D ptrtst2 pr > > D pointer * > > D > > D ptrtst2 pi > > D pointer * > > D > > D datastruct ds based(pointer) > D packed 5p 0 > > D char 5 > > D > > C eval packed = 11111 > > C eval char = 'after' > > C eval *inlr = *on > > > > -----Original Message----- > > From: Scott Klement [mailto:klemscot@klements.com] > > Sent: Tuesday, November 28, 2000 9:08 AM > > To: RPG400-L@midrange.com > > Subject: Re: Passing pointers as parms > > > > > > > > If this is a program calling a program (within the same job) > > the program > > _is_ (implicitly) passing a pointer... Thats the way > > parameters work, > > they're passed by "reference" (i.e. a reference to an > address in main > > storage) > > > > The exception to this, of course, is when using something > > like QCMDEXC or > > SBMJOB... > > > > So I'm a bit confused as to why you want to pass a pointer > > instead of the > > buffer directly? if you really want to just pass the > > pointer, you could > > do something like this: > > > > Program 1: > > > > D MyBuffer S 32766A > > D pointer S * inz(%addr(MyBuffer)) > > D MyField S 1A based(pointer) > > C CALL 'PROGRAM2' > > C PARM MyField > > > > > > Program 2: > > > > D pointer S * > > D MyField S 1A > > D MyBuffer S 32766A based(pointer) > > C *ENTRY PLIST > > C PARM MyField > > C eval pointer = %addr(MyField) > > > > > > But this would yield the same exact results as just passing > "MyBuffer" > > directly... so why would you bother?? > > > +--- > | This is the RPG/400 Mailing List! > | To submit a new message, send your mail to RPG400-L@midrange.com. > | To subscribe to this list send email to RPG400-L-SUB@midrange.com. > | To unsubscribe from this list send email to > RPG400-L-UNSUB@midrange.com. > | Questions should be directed to the list owner/operator: > david@midrange.com > +--- > > > > +--- > | This is the RPG/400 Mailing List! > | To submit a new message, send your mail to RPG400-L@midrange.com. > | To subscribe to this list send email to RPG400-L-SUB@midrange.com. > | To unsubscribe from this list send email to > RPG400-L-UNSUB@midrange.com. > | Questions should be directed to the list owner/operator: > david@midrange.com > +--- > +--- | This is the RPG/400 Mailing List! | To submit a new message, send your mail to RPG400-L@midrange.com. | To subscribe to this list send email to RPG400-L-SUB@midrange.com. | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
