Logic for sending data files to multiple instances of Central

Question

We are using Central Pro Output Server 5.6 with a single Central instance as of default installation on a Windows Server 2003. Data for the transaction files coming from our iSeries system via a printer queue (\\.\pipe\jetform\queuename)
Now we want to be able to produce more documents from Central much faster and therefore setting up multiple instances of Central. The problem is then where to put the logic for choosing instances.
The simplest way to do this would be to have iSeries to alternate the data files to different pipes (printer queues) for Central. But as we dont want to change our iSeries configuration for this, is there a way to solve this problem in Central?
Any help with this is much appreciated

Answer 1

Central provides no mechanism that I'm aware of that would do anything resembling the job distribution that you are wanting. Central is written to monitor it's input folders and process the files it finds there. Each instance is essentially separate from each other.
Your source system will need to select the appropriate instance to be used. Either that or you will need to have something between the source system and Central that is doing the distribution. For example, you could have the source system write to a folder that is not being monitored by Central and write a program that runs as a service that does monitor that folder. This program would then distribute the files. The likely drawback of having an intermediary program is that you are likely to not end up getting the documents printed any faster than with a single instance.
Another possible way, if the source system can create files with different file name extensions, would be to have them all written to the same folder and have each instance checking that particular folder but looking for files with different extensions. This might be problematic, though, because it might also end up with each instance watching the same "control" folder so that doing things like pausing Central would end up with no control of which instance was going to be paused.
The default setting for Central has it pausing for 5 seconds if it completes a job and there are no more files waiting for it. If your jobs are not coming in faster than Central is processing them then you would be getting some of this delay for your jobs. You could reduce this time or even set Central to process a job as soon as it shows up. I don't know if version 5.6 still has the problem but an earlier version would not "see" a file if it happened to show up exactly when it was looking for more (it was probably showing up milli-seconds after Central looked). This caused that job to just sit there until the next job showed up.
A major factor in getting the documents produced faster is going to be the speed and number of printers that they are going to - plus the number of pages in each document. For us, the single instance of Central that we are currently using can produce print much faster than our HP9050 printers (50 ppm) can actually print it.
You must be doing a lot of forms or each job is doing a lot of processing. Our typical print job does 4 tasks (depending on the job this can include things like: passing the file through the transformation agent, updating a mainframe database, FTPing the file to another server for archiving, and producing the print). A typical job with 11 output pages takes only 2-3 seconds. We have a task that runs every morning that retrieves mainframe generated jobs. I just checked one of our servers and it processed 208 jobs in exactly 8 minutes (26 jobs per minute at an average of 2.3 seconds per job). We also thought we'd need multiple instances due to speed but that just isn't the case for us. We have other reasons to move to multiple instances but speed in not a major factor any more.