× 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.



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 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.