IPM custom xform object to call the AFP2PDf feature to convert AFP files to PDF in large quantities for archive in 3rd party document repository. Expected that any bad files would fail and be held in queue while the good ones would all convert and be output to the output dir set with "-o".
This is NOT what happens. Currently ALL files pass through the AFP2PDF feature transform and produced output, with transform errors being reported on STDOUT/STDERR but without a non-0 return code to indicate problems with the input file. (Bad AFP file produce an AFP Document that either errors or views as a blank page depending on how far the transform got before the error.) Transform errors do get sucked into the IPM server error.log. But since the jobs get an output file and are not flagged by a non-zero return code get removed from the server as successful; it would take a lot of log spelunking to tie an error back to the input/output files and remove them from the archive.
The current behavior will cause all of the bad AFP files to be propagated into the PDF archive as blank of bad PDF files.
An example of running afp2pdf on a known corrupt AFP input file:
>afp2pdf -v -ozbad.out zBad.afp
0427-926 Processing...
0427-936 The input file is a AFP Document.
0427-937 File Name: zBad.afp.
0427-943 Output PDF Document.
0427-937 File Name: zbad.out.
0427-656 The AFP file is not valid. The problem is at offset 0X2A. Correct the problem with the AFP file and try to view it again.
0427-939 Form Definition: .
0427-940 Rotation: 0.
0427-942 Pages: 1.
0427-943 Output PDF Document.
0427-942 Pages: 1.
0427-927 Processing time: 00:00:00.1250427-928 Processing completed.
Then check the return code:
>if %ERRORLEVEL% EQU 0 (echo "Xform completed successfully RC = " 0 ) else (
echo "EPIC FA!L RC = " 0
exit /b 0
)
"Xform completed successfully RC = " 0
Other IPM transforms including ps2afp and PDXT provide non-zero return codes when encountering bad input data and do not allow bad output to propagate as the current implementation of AFP2PDf does.