CreateForm Printing "long distance" and response time

ssolberg

VIP Member
CreateForm Printing \"long distance\" and response time

We've run across a response time issue with printing CF documents that has me stumped. I have also talked with BT support and not really getting anywhere so I'm polling the list. Here is how things are setup.

Our CF server is local (to me) and is used to merge lots of forms and split them out to printers in a variety of places that are local and "farther away". There is no issues with the printing speed to any of the local printers.

We recently implemented a bunch of forms for one of our companies which are very similar to existing forms we do for other companies but they are farther away on the network. In the merge/print setup side of things, stuff goes into DIRECTOR and the project decides where to print it. All the printers are setup as direct IP address accessed printers (standard IP port). So something comes into DIRECTOR and then (for example), 100 checks head to the printer. Locally, things start printing right away no problem. In the same scenario to the far away printer, the 100 checks go to the printer and the user reports that it will print a check, wait about a minute, print another, etc. From my end, it also shows the checks "slowly" headed to the printer.

So BT support suggested that I setup a LPR port for the printer on the local server to ship the "100 checks" to another server at the far away place, then have that queue pointed directly to the printer and let it pass them on. Sounds do-able so I set things up and we did some testing. It works but no the response time issue is "different". Indeed all 100 checks go in the local LPR printer queue right away and it promptly ships 10 (yes 10) checks over to the other queue and those 10 print quite quickly. On the local end though, it waits for awhile, then sends another 10, and the process goes again. So it isn't solving the problem, it just changed. I can watch the queues and it will send the 10 over just fine but for a period of time, none are getting sent over and the other queue is empty waiting for more. This is happening with a variety of forms so it isn't something about the form in particular.

BT is not really helping at this point and don't know how to "blame the WAN" for the problem either.

Anyone got any ideas or other solutions? Users are pulling hairs out...., they have runs of 500+ checks/deposit slips/etc that end up taking hours to get all printed.
 
Re: CreateForm Printing \"long distance\" and response time

Sannan,

How is printing direct from JDE at the remote location - without the C!F processing?
 
Re: CreateForm Printing \"long distance\" and response time

I think I follow.
Ultimately, local check jobs print quick, remote check jobs do not.

My first question is, do you have only 1 director printer?
- If so, do non check jobs also print to this one director printer?
- Do they get in the way of check jobs?

If so, use Multiple Director printers
- Route Non Check jobs to 1 Director printer, Checks to another.
- Cform Server 6.4 is multi-threaded, can process multiple jobs (Director Projects) simultaneously.

Also use Multiple spooling directories.
- Each Director printer should have its own spooling directory.
- Much less backup of jobs, in case Check jobs are competing with other jobs.
(double click director printer in Cform Server 6, click advanced on left to see spooling directory)

In terms of checks (1 batch job / 1 director printer) printing to different locations
- Have you looked at using the sort function in the director project?
(Sorting could help the split function break out jobs for each remote location)
- Or sorting along with Conditional logic?
- Is there a better way to split the batch of checks based on location?
(Using multiple variables?)

I would first look at the Director project for better sorting and splitting efficiency to remote win printers.
Otherwise use multiple director printers with multiple spooler directories (one for checks, one for all others).

I'm not aware of any spooler settings or service settings or even Printer settings that help dramatically here other than setting Output format in Cform Server 3.2 to Postscript and using a Postscript driver in the windows printer.

Any latency indicators on the Network side?

Mark
 
Re: CreateForm Printing \"long distance\" and response time

Thinking a bit more outside . . . .

You could have Director Sort & Split it by location, then merge it, then output it to a directory AT the remote location.
- Requires a publishing license, but from your past posts, you have one.
- Then a user can open it and print it locally (not exactly automated).
- Or Create!form Folder Monitor watches that directory and sends it to the printer automatically
(no license needed and now we're automated).
- Director offers a number of functions to help automate this, just have to be creative.

If processing time is taking hours to some locations, this can reduce it immensely.

But test it first:
- Printing Checks from Adobe can be different than printing directly to the printer through the PS driver.
- Some data items or the entire image may shift or reduce in size.
- Printing from Adobe has a setting to uncheck for this.

Mark
 
Re: CreateForm Printing \"long distance\" and response time

Sannon, Mark,

What Mark has described in his "Thinking a bit more outside . . . ." is sort of what I had in mind. I was wondering if the way we do printing may provide some ideas, "outside the square," for a resolution. What we do is described in thread 118717. I wanted to know if printing to the remote sites from the JDE server worked OK so that printing from the server may be an option. Anyway that thread has the details.
 
Re: CreateForm Printing \"long distance\" and response time

Lets see if I can answer and clarify a few things.

Peter - local printing is just fine (non CreateForm stuff).

Mark - Yes, I only have 1 DIRECTOR printer. Other jobs are not "getting in the way" that would slow things down. It has been rare that our DIRECTOR printer gets "backed up" with jobs waiting to be looked at. Things go in and out of there pretty quick.

I realize I need to clarify my example regarding checks (though the issue is just not with "checks"). For one batch job (from a company for example), ALL the checks for that job are going to one printer (whether it is local or far away). I don't have jobs that have 100 checks and 50 of them print local and 50 of them print far away. Make sense? So really the issue of using Sorting wouldn't help at all.

I also understand the issue about printing checks from Abobe rather than directly to the printer. I have seen things print slightly differently when going through Adobe to print so I avoid it unless they are not actually checks (like direct deposit or invoices and such).

I've tried to get our Network folks involved but I'm not sure they understand what to "look" for. I show them how things are acting and they want to blame CF for it yet that doesn't make sense.

I really wish the LPR solution I explained above would work. As BT tried to explain, this way of doing things should be pushing the documents over to the far away server quite quickly and let it push it to the printer but since it only sends 10 over at a time for some strange reason, it isn't helping the problem at all.

My boss is already pushing to just get a full install of another CF windows server up at the other location to "fix" the problem but I just see that as throwing money at something that we shouldn't need to do and the longer term maintenance and expense. I KNOW we are not the only company doing this type of printing.
 
Re: CreateForm Printing \"long distance\" and response time

Yay! Issue resolved. Let me see if I can give you all details in case any of you run into the same issue.

So first, remember that I said we started out trying to print directly to the physical printer via a standard IP port (like we do with our "local" printers) but it was slow shipping the documents across our WAN to the printer so things seemed slow.

Secondly, BT suggested the LPR port solution as I outlined above. Worked but had a different issue causing things to still be slow. One of my network guys actually found that the issue I was having is a WINDOWS issue. There is a known issue with Windows and LPR ports and it will only send over 11 things at a time. Hah! Don't use LPT ports for this stuff.

Lastly, we created a Local Port that was configured as "\\(far away server name)\(printer share name on that server)" and everything worked like a dream. Documents fly out of my local server over to the printer queue on the far away server with no delays. The far away immediately starts printing documents as it get them!

Even though it was not a CreateForm issue, BT support was helpful in finding this solution for us.
 
Back
Top