The original example seems indeed to be setting PageSize twice... with different values, even:
$ grep PageSize TMP20130426150418LEEEL_edited.ps 2 dict dup /PageSize [612 797] put setpagedevice 2 dict dup /PageSize [612 793] put setpagedevice
Perhaps this means that the templates (or whatever the Oracle/Peoplesoft application uses to create the print jobs) have two conflicting paper size definitions?
I see two possible ways to fix this:
1.) Obviously, fix it at the source, by auditing the Oracle/Peoplesoft job templates and removing any extra and/or incorrect page size settings from them. If each page needs its own template and each template must have page size defined, make sure the definitions agree with each other. The application just might be smart enough to omit the extra PageSize setting if it's exactly the same as the previous one in the same print job... (but if it isn't, see below)
2.) Have the printing system strip the offending extra PageSize setting before actually printing the job.
First, get several non-duplexing print job examples. Preferably from different print job types, if possible. If all have the extra PageSize setting on its own line, it would be easy to write a filter script to comment out or delete the offending line as the data passes through the filter.
The next question is, how much can you customize the print command the Oracle/Peoplesoft application uses?
Even if you can only specify the name of the CUPS printer queue the application should use, you might borrow one trick from the admins of the older Unix printing systems: you might set up a special print queue that passes the job through any filter scripts you need, then re-submits the print job to the real print queue.
With CUPS, custom backend scripts is probably the easiest way to do this.
Here seems to be a good description:
http://en.opensuse.org/SDB:Using_Your_Own_Backends_to_Print_with_CUPS
For example, you might make a custom backend script named "fixbadps", that would filter the unwanted PageSize line from the incoming data and re-submit the job to the real print queue (whose name could be parsed from the printer URL that was used to invoke the custom backend). The backend script would go to the /usr/lib/cups/backend directory.
The next step would be to set up extra print queues exclusively for the Oracle/Peoplesoft use: these would have a printer URL like "fixbadps:<real-queue-name>" in the queue definition. Now, whenever a print job is submitted to one of these queues, the job file would be passed to the /usr/lib/cups/backend/fixbadps script, which could then do whatever required to remove the extra PageSize line (grep -v? sed? Maybe some Perl scripting if the detection of the offending line is complex?) and then pipe it to "lp -d <real-queue-name>".
Attached is a skeleton CUPS backend script I once made in order to understand the concept. As is, it just pipes the print job to /dev/null, and produces a list of environment variables in /tmp/testbackend.env.