Nice CLLE Rob.
It could be as easy as going into ACS "Printer Output". Locate the spooled files needed, click "actions", "download" (take whatever selection that works for you), click "Use PDF format if available" and then "OK".
Locate the files, email them to yourself or a secure email address or like Rob, move them to an offsite repository.
Very Respectfully,
Michael Mayer
IBM i on Power System Admin.
The Florida Bar
Tallahassee, Florida 32399-2300
mmayer@xxxxxxxxxxxxxx
https://www.floridabar.org
------------------------
message: 1
date: Fri, 23 Jul 2021 15:58:06 +0000
from: Rob Berendt <rob@xxxxxxxxx>
subject: RE: Help with Klement's SMTP routines
By "universal methodology" I would suggest creating the PDF by using tools supplied by IBM.
There are these freebies:
Resource
ID Option Feature Description
5770TS1 *BASE 5050 IBM Transform Services for i
5770TS1 *BASE 2924 IBM Transform Services for i
5770TS1 1 5050 Transform Services - AFP to PDF Transform
I find it as simple as this example CL using a standard IBM supplied print file (for BRMS). I deleted several lines. Basically we use this logic to put our BRMS recovery reports on multiple geographically dispersed servers.
DCL &QP1ARCY *CHAR 25
RTVNETA SYSNAME(&SysName)
CHGVAR &QP1ARCY ('/tmp/' *tcat &SysName *tcat '_QP1ARCY.PDF') RMVLNK OBJLNK(&QP1ARCY) MONMSG CPFA0A9 EXEC(DO) /* Object does not exist */
/* Remove message from cluttering joblog */
RCVMSG PGMQ(*SAME (*)) MSGTYPE(*EXCP) MSGKEY(*NONE) +
WAIT(0) RMV(*YES)
EndDo
OVRPRTF FILE(QP1ARCY) DEVTYPE(*AFPDS) TOSTMF(&QP1ARCY) WSCST(*PDF) STRRCYBRM OPTION(*SYSTEM) ACTION(*REPORT) DLTOVR FILE(QP1ARCY)
MD '/QNTC/GDFILES01'
MONMSG MSGID(CPFA0A0) EXEC(DO) /* Object already exists */
/* Remove message from cluttering joblog */
RCVMSG PGMQ(*SAME (*)) MSGTYPE(*EXCP) MSGKEY(*NONE) WAIT(0) +
RMV(*YES)
ENDDO
CPY OBJ(&QP1ARCY) TODIR('/qntc/GDFILES01/BRMS/RecoveryReports') +
TOCCSID(1252) REPLACE(*YES)
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 7310 Innovation Blvd, Suite 104
Ft. Wayne, IN 46818
Ship to: 7310 Innovation Blvd, Dock 9C
Ft. Wayne, IN 46818
http://www.dekko.com
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Thomas Garvey
Sent: Friday, July 23, 2021 11:41 AM
To: midrange-l@xxxxxxxxxxxxxxxxxx
Subject: Re: Help with Klement's SMTP routines
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
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
--
________________________________
Please note: Florida has very broad public records laws. Many written communications to or from The Florida Bar regarding Bar business may be considered public records, which must be made available to anyone upon request. Your e-mail communications may therefore be subject to public disclosure.
midrange.com
