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



   It appears the problem is the fact that I'm using a database field as the
   receiving parameter.  I'm assuming the system is writing the full size of
   the parameter starting at the address of the database field, and this is
   what's wiping out part of my database record.

   I've used %SUBST in the caller to get "just enough" data out of the
   returned parameters; I was hoping that leanring how to properly code the
   parameter list would eliminate the requirement.  But I guess not.

   Simon, thanks, as usual...

   >From: Simon Coulter <SHC@xxxxxxxxxxxxxxxxx>
   >Reply-To: RPG programming on the AS400 / iSeries <RPG400-L@xxxxxxxxxxxx>
   >To: RPG programming on the AS400 / iSeries <RPG400-L@xxxxxxxxxxxx>
   >Subject: Re: Problems with parameters
   >Date: Sat, 28 Feb 2004 15:00:58 +1100
   >
   >
   >On Saturday, February 28, 2004, at 02:49  PM, ile rpg wrote:
   >
   >>I understand the theory (but apparently not much else) of CEEDOD;
   >>when
   >>    I've included in in the service program, it tells me that
   >>parameter 3 is
   >>    15 bytes.  But that doesn't seem to do any good.
   >
   >If you passed 15 bytes then CEEDOD is working. You have to use that
   >length in subsequent references. The system won't automatically use
   >15 bytes. It will use the 60 bytes you declared.
   >
   >>    I can work around this problem by always using fields with
   >>lengths
   >>    matching the sizes in the parameter list and procedure
   >>interface.  But
   >>    with all the options available, it seems as though there should
   >>be a way
   >>    to code this so the number of bytes returned agrees with the
   >>size of the
   >>    input field passed as the parameter.  On the other hand, it
   >>might be a
   >>    fact of life that the size of the returned parameter is what it
   >>is and I
   >>    have to manage the length/overflow myself.
   >
   >You have to work with the length CEEDOD returned. The 3rd parameter
   >is a pointer capable of addressing 60 bytes but you only passed 15
   >so you must ensure you work with only 15 bytes. Use %SUBST to
   >extract the appropriate amount of data from the variable.
   >
   >Regards,
   >Simon Coulter.
   >--------------------------------------------------------------------
   >    FlyByNight Software         AS/400 Technical Specialists
   >
   >    http://www.flybynight.com.au/
   >    Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
   >    Fax:   +61 3 9419 0175                                   \ /
   >                                                              X
   >                  ASCII Ribbon campaign against HTML E-Mail  / \
   >--------------------------------------------------------------------
   >
   >
   >_______________________________________________
   >This is the RPG programming on the AS400 / iSeries (RPG400-L)
   >mailing list
   >To post a message email: RPG400-L@xxxxxxxxxxxx
   >To subscribe, unsubscribe, or change list options,
   >visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
   >or email: RPG400-L-request@xxxxxxxxxxxx
   >Before posting, please take a moment to review the archives
   >at http://archive.midrange.com/rpg400-l.
   >

     ----------------------------------------------------------------------

   Take off on a romantic weekend or a family adventure to these great U.S.
   locations.

As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.