RE: Problems with parameters

Use the length from CEEDOD with %SUBST to extra the data and copy it into
your database record/buffer.
I would suggest attempting to code the parameter like this instead, as it is
much easier to deal with:
   D q_name                    30A   Const VARYING options(*omit:*nopass) 

Of course if your not on V5R1, you'll have to use the CEEGSTA API to test
the parm for *OMIT since that doesn't work prior to V5.1 with CONST parms.

-Bob

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of ile rpg
Sent: Friday, February 27, 2004 9:49 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Problems with parameters

   I'm working with a service program that may pass back multiple values. 
   There's a problem when I pass a shorter database field into parameter 3:
   I'm getting the full length (30A) of parameter 3 in the database record
   buffer; I know this because I get decimal data errors and the program
dump
   shows blanks where there should be packed numerics.

   Dsvv110_a         pr             7    opdesc          

   D                                7    const       
   D                              
   10    const                                          
   D                               30    options(*omit:*nopass:*varsize)
   D                               20  0 options(*omit:*nopass)             
   D                               60    options(*omit:*nopass:*varsize)
 
000091  
   Dsvv110_a         pi            
   7    opdesc                                  
   D q_acct                         7    const

   D
   q_function                    10    const

   D
   q_name                        30    options(*omit:*nopass:*varsize)

   D q_telephone                   20  0
   options(*omit:*nopass)                      
   D q_email                      
   60    options(*omit:*nopass:*varsize)             
    
   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.
    
   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.
    
   My brain is fried on this...what am I doing wrong?
    
   -irg

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

   Find and compare great deals on Broadband access at the MSN High-Speed
   Marketplace.
_______________________________________________
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.