|
That might be because of the 16-byte pointer thing. And everything in CL is by reference, i.e., by pointer. But that doesn't seem to explain why a CL program can't handle a character array from C. I mean, when you've declared char rtnval[4] and use return(rtnval) it's returning the pointer to the start of that array, which is actually a pointer, after all. And when the article says to use a struct (which DOES work), you don't declare a pointer to a struct, you declare a struct. So there must be some special understanding between iSeries CL and C/C++ programs. At 06:57 AM 4/3/02 -0800, you wrote: >If I'm not wrong there is a 16 bytes boundary for return >variables in cl programs. >--- Vernon Hamberg <vhamberg@attbi.com> wrote: > > There's something in the knowledge base about character > > return values. > > > > >Question: How would a character string be returned to > > ILE CL/400 from ILE > > >C/400? > > > > > >Answer: Below is an example of how to return character > > data to a ILE > > >CL/400 module from a ILE C/400 module. Note that ILE > > C/400 handles > > >character strings as arrays. CL does not support arrays. > > The only way to > > >return data is through a structure. > > > > > >ILE CL/400 source: > > > > > >PGM > > >DCL VAR(&INCHAR) TYPE(*CHAR) LEN(4) VALUE('ONE ') > > >DCL VAR(&OUTCHAR) TYPE(*CHAR) LEN(4) > > >DCL VAR(&MSG) TYPE(*CHAR) LEN(4) > > >CALLPRC PRC('increment') PARM(&INCHAR) RTNVAL(&OUTCHAR) > > >DMPCLPGM > > >CHGVAR VAR(&MSG) VALUE(&OUTCHAR) > > >SNDMSG MSG(&MSG) TOUSR(STANLEY) > > >ENDPGM > > > > > >ILE C/400 Source: > > > > > >typedef struct { > > >char first; > > >char second; > > >char third; > > >char fourth; > > >} retstr; > > > > > >retstr increment(char *a) > > >{ > > >retstr rtnval; > > >rtnval.first = 'T'; > > >rtnval.second = 'W'; > > >rtnval.third = 'O'; > > >rtnval.fourth = ' '; > > >return rtnval; > > >} > > > > I did not like the individual characters in the struct. I > > found that it > > could be a char array inside the struct > > > > >typedef struct { > > > char first??(4??); > > >} retstr; > > > > This means that APIs would have to return a struct (for > > character return > > values) to be used in CL. > > > > At 08:57 AM 4/1/02 -0500, you wrote: > > >This is a multipart message in MIME format. > > >-- > > >[ Picked text/plain from multipart/alternative ] > > >How's about the prototype for the service program? > > > > > >Rob Berendt > > >-- > > >"They that can give up essential liberty to obtain a > > little temporary > > >safety deserve neither liberty nor safety." > > >Benjamin Franklin > > > > > > > > > > > > > > >"Phil" <sublime78ska@attbi.com> > > >Sent by: midrange-l-admin@midrange.com > > >03/30/2002 10:34 AM > > >Please respond to midrange-l > > > > > > > > > To: "MIDRANGE-L" <MIDRANGE-L@midrange.com> > > > cc: > > > Fax to: > > > Subject: CALLPRC with RTNVAL > > > > > > > > >I'm having trouble with the data returned from a srvpgm > > which is called > > >from > > >a CL with CALLPRC: > > > > > > PGM parm(&parm) > > > dcl &parm *char 121 > > > > > > if cond(%sst(&parm 1 1) *eq ' ') then(do) > > > chgvar &parm value(' ') > > > callprc prc(getParm) rtnval(&parm) > > > enddo > > > > > >The srvpgm (RPG) returns the correct data, and works > > fine when called by > > >an > > >RPG pgm. The srvpgm exports the parm. > > > > > >The problem is the value of parm is not correct. > > > > > >Can anyone tell me what I've got wrong? > > > > > >Thanks, > > > > > >Phil > > > > > > > > > > > >_______________________________________________ > > >This is the Midrange Systems Technical Discussion > > (MIDRANGE-L) mailing > > >list > > >To post a message email: MIDRANGE-L@midrange.com > > >To subscribe, unsubscribe, or change list options, > > >visit: > > http://lists.midrange.com/cgi-bin/listinfo/midrange-l > > >or email: MIDRANGE-L-request@midrange.com > > >Before posting, please take a moment to review the > > archives > > >at http://archive.midrange.com/midrange-l. > > > > > > > > > > > >_______________________________________________ > > >This is the Midrange Systems Technical Discussion > > (MIDRANGE-L) mailing list > > >To post a message email: MIDRANGE-L@midrange.com > > >To subscribe, unsubscribe, or change list options, > > >visit: > > http://lists.midrange.com/cgi-bin/listinfo/midrange-l > > >or email: MIDRANGE-L-request@midrange.com > > >Before posting, please take a moment to review the > > archives > > >at http://archive.midrange.com/midrange-l. > > > > _______________________________________________ > > This is the Midrange Systems Technical Discussion > > (MIDRANGE-L) mailing list > > To post a message email: MIDRANGE-L@midrange.com > > To subscribe, unsubscribe, or change list options, > > visit: > > http://lists.midrange.com/cgi-bin/listinfo/midrange-l > > or email: MIDRANGE-L-request@midrange.com > > Before posting, please take a moment to review the > > archives > > at http://archive.midrange.com/midrange-l. > > > > >__________________________________________________ >Do You Yahoo!? >Yahoo! Tax Center - online filing with TurboTax >http://taxes.yahoo.com/ >_______________________________________________ >This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list >To post a message email: MIDRANGE-L@midrange.com >To subscribe, unsubscribe, or change list options, >visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l >or email: MIDRANGE-L-request@midrange.com >Before posting, please take a moment to review the archives >at http://archive.midrange.com/midrange-l.
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.