RE: CWCCVTDT continued.... -- RPG400-L

It seems you're just picking up on prototypes and you need to learn more.
If I were you, I'd go to RPG World in May (www.rpgworld.com) and learn all about
it.

To answer you specific question about return value lengths... you want 16-bytes
or fewer for return values. RPG and OS/400 do not handle return values very well
at all when they exceed that length. 
Why 64 bytes instead of 32k? Sometimes RPG creates copies of input parameters.
If the input is defined as 32k or 64k then it will create a temporary variable
of that length, copy your data into it and then use that temp. Even if you only
need 10 bytes.  This doesn't happen every time, it's a bit tricky as to when/if
it will actually happen.  I choose 64 bytes for some reason that I don't recall
now, but I believe it was based on the returned data's maximum possible length
and then rounded up to a 32-byte multiple. 

Also, for input parameter that never exceed the length of the prototype, CONST
_and_ OPTIONS(*VARSIZE) are often problematic and in this case you should
probably remove the OPTIONS(*VARSIZE), as follow:

>>     D QWCCVTDT        PR                  ExtPgm('QWCCVTDT')
>>     D  inFmt                        10A   CONST
>>     D  inDate                       64A   CONST
>>     D  outFmt                       10A   CONST
>>     D  outDate                      64A   OPTIONS(*VARSIZE)
>>     D  api_error                          LikeDS(QUSEC)
>>     D                                     OPTIONS(*VARSIZE)

This allows you to still pass in a shorter value, but pads it to the declared
length of the prototype. If I had 32k declared, you'd have a 32k temp variable
being passed instead of a 10 position or 64 position one.

-Bob Cozzi
www.RPGxTools.com
RPG xTools - Enjoy programming again.


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On
Behalf Of Jim Wiant
Sent: Tuesday, February 28, 2006 2:16 PM
To: RPG programming on the AS400 / iSeries
Subject: RE: CWCCVTDT continued....

It is just a type and max length verification yes, but then why not
always use 32767 or 65535?
And does the same apply to return values on the prototype definition? If
the PR has 32767 for the return value, does that mean the maximum that
the routine could return - not the amount that will be allocated?

Sorry for the request of details, but recent conversations has made me
want to review all the prototyped modules I've written so far looking
for improvements and/or elimination of bad habits I've developed.

JPW

 

 

The bitterness of poor quality remains long after low pricing is
forgotten! 

 

Cautillo, Leon M.



-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Bob Cozzi
Sent: Wednesday, 1 March 2006 8:53
To: 'RPG programming on the AS400 / iSeries'
Subject: RE: CWCCVTDT continued....


The length on the prototype is not a field declaration. It is the limit
of the
size of the value you can pass to the program/procedure. So 64 or 65535
makes no
difference in this prototype in this context. 

-Bob Cozzi
www.RPGxTools.com
RPG xTools - Enjoy programming again.


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On
Behalf Of Jim Wiant
Sent: Tuesday, February 28, 2006 1:10 PM
To: RPG programming on the AS400 / iSeries
Subject: RE: CWCCVTDT continued....


>>If you go to the downloads page on rpgiv.com you can download the API
prototypes
>>for several APIs.
>>Here's the prototype for QWCCVTDT.

>>     D QWCCVTDT        PR                  ExtPgm('QWCCVTDT')
>>     D  inFmt                        10A   Const OPTIONS(*VARSIZE)
>>     D  inDate                       64A   Const OPTIONS(*VARSIZE)
>>     D  outFmt                       10A   Const OPTIONS(*VARSIZE)
>>     D  outDate                      64A   OPTIONS(*VARSIZE)
>>     D  api_error                          LikeDS(QUSEC)
>>     D                                     OPTIONS(*VARSIZE)


I'm curious Bob. I just checked IBM's website and it still looks like
this for the input variable to the API:

Input Variable Format
This table shows the format used for the input variable parameter.

Input Format Input Variable 
*CURRENT Parameter is ignored. 
*DTS System time-stamp. The first 8 characters are used. 
*YYMD, *MDYY, *DMYY, *LONGJUL The first 17 characters are used. See
17-Byte Character Date and Time Value Structure. 
All other character formats The first 16 characters are used. See
16-Byte Character Date and Time Value Structure. 

 
Why define 64 with a variable size? Wouldn't 17 be enough?

Thanks

JPW
 


This message has been sent from Foodstuffs (Auckland) Limited
("Foodstuffs").

The information contained in this message and or attachments 
is intended only for the person or entity to which it is 
addressed and may contain confidential and/or privileged 
material. Any review, retransmission, dissemination or other 
use of, or taking of any action in reliance upon, this 
information by persons or entities other than the intended 
recipient is prohibited. If you received this in error, 
please contact the sender and delete the material from any 
system and destroy any copies.

The views and opinions expressed in this message may be those
of the individual and not necessarily those of Foodstuffs, 
and are not given or endorsed by it.

Please note that this communication does not designate an 
information system for the purposes of the Electronic 
Transactions Act 2002.