Re: Help with cprdata

[Simon Coulter <shc@xxxxxxxxxxxxxxxxx>]

On 02/07/2004, at 11:05 AM, Jon Paris wrote:

> I agree that the field is too small Keith/Simon, but isn't the function
> supposed to handle that?  I thought it was supposed to return the 
> length
> that the compression requires but only actually fill the space 
> provided.
> Not just blow up.  In case anyone wonders why I'm using 52 - it is 
> because
> that is the max for DSPLY sadly.

Many MI functions do handle too little space. They are the ones with a 
template that contains variables for bytes-available and 
bytes-provided. All the Materialize MI instructions operate this way. 
Looking at the template for CPRDATA in the MI Functional Reference you 
can see a similar set up regarding the Source length and Result area 
length fields. However, reading a bit further on you'll find the 
following weasel-words:
"If the length of the compressed result is greater than the value in 
the result area length field, a materialization length invalid (hex 
3803) is signalled."

This tells me that this function will only return the compressed data 
if enough room is provided otherwise it will signal an exception. It 
will never return a partially compressed string. Hex 3803 converts to 
5603 in decimal and that matches MCH5603 which is the error I received 
when running your example.

Granted, the MCH5603 - "Less than 8 bytes available in receiver value 
of materialize instruction" message is misleading because 44 bytes 
(your output size is 44 not 52) is greater than 8. I suspect someone 
reused the wrong message.

> I based this test on an example that directly used the underlying MI
> built-in and it had a length of 52 for both input and result and that 
> one
> works just fine.  Since it works I have to assume that the compression
> option it is using ( Algorithm = 2) is not the same as the one used 
> for the
> cprdata function.  Wonder why.  In fact using this option the full 52
> characters are indeed compressed since the reverse decompression works 
> just
> fine and restores the original string intact.

Algorithm 2 is LZ1 and it will probably fit in the target size thus no 
error. Try compressing a larger source and watch it fail just as 
spectacularly. If you want to use LZ1 you'll have to use the built-in 
interface. The MI Function Reference explains points out two algorithms 
are available. The C MI Library Reference just says terse is used so 
you have to infer that Algorithm 1 is used by cprdata.

Even though you are using a C-runtime built-in you should also read the 
information in the MI Functional Reference for the instruction to get 
the complete picture.

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  / \
--------------------------------------------------------------------