Re: Help with cprdata -- RPG400-L


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