Re: Help with QimgCvtImg

[Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>]

Thanks, Al.

I've tried your code, and it works just fine here.  I made some really 
minor changes to it:

a) I removed the 2nd parameter (out_path) because it wasn't used, and 
that's just one more place for something to go wrong.

b) I changed the size of the 1st parameter (in_path) to 32, since 33 
leaves a chance for garbage to appear in the parameter.

c) I changed the "MainStgOS" parameter to use a field called QMAINO01, 
which is defined identically to QMAINI01 (other than the name). You were 
passing QIMGO0300 to it, and I didn't understand why.  That parameter 
isn't in IMGO0300 format...

d) I changed the BytesProvided field of Ext_APIError to 0.  This isn't 
what's causing your error, it just makes it easier (IMHO) to debug when 
you get a meaningful error in your job log.  If you have additional code 
that uses the results of the DS, it's easy enough to change it back when 
you're done debugging the API call.

I also had a create an output queue called NOPRINT, which was a trivial 
task.  For testing purposes, I downloaded the G4.TIF file from the 
following link:
http://www.fileformat.info/format/tiff/sample/

As long as I remembered to pass the pathname in the first parm to your 
program, it ran without any problems and generated a spooled file.  I 
haven't checked to see that the spooled file is valid, though.

I do get a pointer error when I forget to pass the first parameter to your 
program. The problem can't be that simple, can it?

I do have a few suggestions that will make this program a lot easier to 
deal with:

a) Use more meaningful names for the fields in the data structures. The 
biggest headache with this program is trying to figure out what QIMCT00 
stands for and what makes it different from QIMCQ00, QIMBS00, etc.  I had 
to look them up in the manual, and that's not nice to do to other poeple. 
Instead, I suggest using names like "CprType" "CprQual" so that people 
have a clue what the field are for.

b) Instead of hardcoding numbers, use constants to give the number a 
meaningful name.  Instead of setting QIMDSF03 to 22, I'd rather set 
StreamFmt to PCL  (where PCL is a named constant for the number 22)

c) Instead of using from/to notation for the data structures, consider 
using length notation.  I shudder to think of the amount of work it'd take 
to fix one of these structures if it were defined wrong.

d) Instead of using the "B" data type, use the "I" data type. Your program 
will then be able to work with a larger range of values and will run 
faster.  There's no advantage to the "B" data type -- "I" is always a 
better choice -- the only change you'd have to make to the program is to 
search for B in column 40 and replace it with an I... simple change and a 
much better result.

e) Dont' hard-code the lengths of the data structures in the INZ 
stataements.  Instead, use %SIZE.  Right now you have:

 D  BytesProvided                 9B 0 Inz( 0 )

Instead, I suggest coding:

 D  BytesProvided                10I 0 Inz( %size(Ext_APIError) )

(not just for that one data structure, but all of them).  That way, if you 
do want to make it bigger (to get more message info, provide a longer path 
name, or whatever) all you have to do is change the field sizes, the 
compiler will automatically calculate proper lengths for you.

This is also a safety measure, since if you get that length wrong, the 
compiler

But, anyway, the code worked okay for me.

---
Scott Klement  http://www.scottklement.com

On Thu, 26 Jan 2006, Al Pineda wrote:

> Scott,
>  Here is the prototype for the API call:
>
>  D Image           PR                  extproc('QimgCvtImg')
> D   ControlS                          LIKE(QIMC0100)
> D   InputImageS                       LIKE(QIMI0100)
> D   MainStgS                          LIKE(QMAINI01)
> D   OutputStGS                        LIKE(QIMO0200)
> D   MainStgOS                         LIKE(QIMO0300)
> D   Feedback                          LIKE(QIMF0100)
> D   APIError                   272