You will get that conversion error if the file you are opening is a UTF8 ccsid 1208 and you request to convert it to a single byte ascii or ebcdic ccsid like 819, 1252 or 37.

On 7/23/2021 5:40 PM, Thomas Garvey wrote:
Hi, Scott,

Yes, you are exactly correct. I should have been more specific. It is CPE3490, Conversion error.

I had considered that there might be some garbage characters, as you suggest, but this pdf was made from an IBM i spool file, which prints fine and no unprintable characters warning. I also had the customer use their own email client to send the same pdf document as an attachment, and that worked fine.
So, I presumed from that result that there was probably nothing wrong with the pdf file or original spool file.
The system CCSID on both my customers server and mine are the same (65535), and the default CCSID of the jobs on both system are the same (37). While I can't create exactly the same spool file on both boxes (the data on each server is different) I did have them send the the pdf from their box and I executed it through the same logic here on my box and the SNDMAILxxx worked fine.
I guess I'll go through the spool file with a fine tooth comb.
All I'm trying to do is get a spool file report to be attached to an email. Can you suggest another more universal methodology?

Thanks for responding.

Best Regards,

Thomas Garvey


On 7/23/2021 4:19 AM, Scott Klement wrote:
Hello Thomas,

What do you mean by 'Convert error'?   Do you mean CPE3490 ("Conversion error")? That's the closest thing that I can think of to 'Convert error'.

This means that the document you're trying to either read or write to contains characters that cannot be translated using the to/from CCSIDs.   This happens a lot when you have a file with "garbage characters" in it, since they often contain bytes that don't correspond to valid code points in the CCSID you've selected.

You might also consider modernizing your approach.  Instead of doing two separate opens (open the file to create it, close it, then re-open it in text mode) you should rewrite the process to use O_TEXT_CREAT.   The method you're describing was normally used back in the old days for compatibility with V5R1 systems. Hopefully you don't need to be compatible with releases that old anymore?

For example, replace the two opens with something like this:

fd = open( filename
         : %bitor( O_CREAT: O_EXCL: O_WRONLY: O_INHERITMODE
                 : O_CCSID: O_TEXT_CREAT: O_TEXTDATA)
         : 0
         : 819
         : 0 );

if fd = -1;
  ReportError();
endif;

Good luck

-SK


On 7/20/2021 4:19 PM, Thomas Garvey wrote:

We're using Scott Klement's SMTP and SNDMAILxxx stuff to generate emails with attachments from inside an RPGLE program on the IBM i. The attachments are pdf and/or CSV's. It's worked for years.

Now it's failing (at a client site) at a step that does the following...

1.    Create a temp file in the IFS using the external procedure '_C_IFS_tmpnam'
2.    Uses CPY to copy the PDF or CSV file (also in the IFS) into the temp file from step 1
3.    Creates another temp file in the IFS and opens it, marked as CCSID 819
4.    Closes the file from step 3
5.    opens the file from step 3 again, in text mode (presumably so data will be automatically translated?)

This is where it fails, at step 5, saying 'Convert error.'

This works on my servers (v7r3 and v5r4 and v5r3), but not on a client's server (v7r3).

There doesn't appear to be any problems with the original pdf file. It can be opened, viewed, attached to emails using the client separate email server. The system CCSID is the same on both our servers.
It just can't pass this conversion step to be attached to an email generted inside the SNDMAILxxx program.

Any ideas?

Best Regards,


Thomas Garvey



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.