<p>Is there a method for handling errors from COM objects in RDML? For instance, when calling Word VBA methods like <code>PasteSpecial</code>, an error is returned and the LANSA application crashes. I cannot find anything in the documentation to allow handling of these errors.</p>

<p>Actually, error handling in general is a weak-point for LANSA and RDML, but that's another topic.</p>

Does anyone know of anyway to
  reduce/optimize the PDF export phase
  and or the size of the PDF without
  lowering the total page count?
I have a few ideas and questions:
1. Is this a graphics-heavy report?  If not, do you have tables that start out as text but are converted into a graphic by the SSRS PDF renderer (check if you can select the text in the PDF)?  41K per page might be more than it should be, or it might not, depending on how information-dense your report is.  But we've had cases where we had minor issues with a report's layout, like having a table bleed into the page's margins, that resulted in the SSRS PDF renderer "throwing up its hands" and rendering the table as an image instead of as text.  Obviously, the fewer graphics in your report, the smaller your file size will be.
2. Is there a way that you could easily break the report into pieces?  E.g., if it's a 10-location report, where Location 1 is followed by Location 2, etc., on your final report, could you run the Location 1 portion independent of the Location 2 portion, etc.?  If so, you could join the 10 sub-reports into one final PDF using
PDFSharp
after you've received them all.  This leads to some difficulties with page numbering, but nothing insurmountable.
3. Does anyone else have any other
  theories as to why this runs on the
  server but not through the API?
My guess would be the sheer size of the report.  I don't remember everything about what's an IIS setting and what's SSRS-specific, but there might be some overall IIS settings (maybe in Metabase.xml) that you would have to be updated to even allow that much data to pass through.
You could isolate the question of whether the time is the problem by taking one of your working reports and building in a long wait time in your stored procedures with WAITFOR (assuming SQL Server for your DBMS).
Not solutions, per se, but ideas.  Hope it helps.