HELP!

I have 2 customers 1 mvbase, 1 d3. Every once and a while (that's what
is aggrevating) a print job will reprint (get to end of report and
starts again). When it is on regular paper, this is not as much a
problem as when printing Checks, or labels.
It may be weeks before it happens again. Happens on laser printers
with network connections, and a line printer on a network print
server. Raining data can't come up with anything. Has anyone had this
problem and know how to fix it??

Rodney

"Rodney Frisard" wrote
for messages like 'timeout waiting for job complete, resending print job?'

Suggest you, for now, train another server on the LAN how to reach all
the affected printers, and divert your jobs to bounce off that server. Pick
a bounce-guy that has an OS offering really good print subsystem logging...
If worst comes to worst, you can train the bounce guy to discard the
duplicate jobs based on length and hash of first 2kbyte dd blocks being
same as a recent job, but that's from hunger, man. Google on how to get
your main server's print subsystem tweaked to be more patient of slow
'print job completion' status back from the ultimate destination printers.
Consider posting in an OS-related or CUPS-related newsgroup {if your
OS uses CUPS to print} for best results. Oh, if you _are_ using CUPS
on linux, consider installing lpd from an older release install cdrom, and
see if that doesn't work better for you. Or fetch the latest CUPS patches.

"Frank Winans" <fwinans (AT) sbcglobal (DOT) net> wrote:

Is it always just a single reprint? Ever had it reprint more than once?

Reason I ask: There's not a lot of difference between
sp-assign F2
and
sp-assign 2

The first assigns you to form queue 2, and the second says you want two
copies.

If your print queues are numbered 1 and 2, and your sp-assign is done by
hand, fat fingers win out.

Since it happens on two totally different OS's (mvBase and D3), it's hard to
say it's the spooler's fault, especially since the D3 spooler is so far
removed from the R83 style spooler (I believe) is used by mvBase.

Mark Brown

"Rodney Frisard" <rfrisard (AT) cox (DOT) net> wrote

And to find out if people are doing "SP-ASSIGN 2" or anything else
funky, you can write a proggie called SP-ASSIGN, catalog it, log all
calls to the verb right before you pass them through to the real verbs
in renamed form, like "::SP-ASSIGN", etc.

Off the top of my head:
* CREATE A FILE CALLED VERB.LOG, THIS CAN BE USED TO
* TRACK ANY VERBS.
OPEN 'VERB.LOG' TO F.LOG ELSE STOP
TCLREAD VERB
CMD = FIELD(VERB,' ',1)
REST = VERB[LEN(CMD)+1,99999]
READU CTR FROM F.LOG,CMD ELSE CTR = 0
* CONSISTENT WAY TO PROVIDE A UNIQUE ID, FOR D3 I
* WOULD JUST USE SYSTEM(19)
CTR = CTR + 1 ; * CTR += 1 OK IN MVBASE?
WRITE CTR ON F.LOG,CMD
REST<2> = @USER
REST<3> = @ACCOUNT ; * when verb.log is in another acct
REST<4> = DATE()
REST<5> = TIME() ; * add other metadata if desired
REST<6> = @PIB
* Maybe try to get a program name from named common
* or elsewhere?
WRITE REST ON F.LOG,CMD:"*":CTR
EXECUTE "::":VERB

Result is items like SP-ASSIGN*1 with:
001 2
....
That should find the fat fingered culprit.

Remember, I haven't tried this code but it should work for most
purposes except if you're stacking data. If you want to use the same
prog to trap other verbs then give it a neutral name like VERB.LOGGER
and then for any given Verb:
COPY MD Verb VERB.LOGGER (O
TO: ::Verb Verb


Hope that ::help helps.
T

"Mark Brown" <mbrown (AT) drexelmgt (DOT) com> wrote:

Hi Rodney,

I would check to see whether the printers in question are being
re-directed to a Windows Printer Queue defined to use a Windows 2000
LPR port.

If yes, you are probably experiencing the occasional network
transmission difficulty and the receiving LPD service is sending back
a NACK (job did not complete successfully).

Unfortunately there is no concept of verifying how many pages have
been successfully printed when using LPR so the only option when a job
fails during processing is to re-send the whole job.

HTH

Best Regards,

/Paul
--
Paul Tykodi
Principal Consultant
TCS - Tykodi Consulting Services LLC

E-mail: ptykodi (AT) tykodi (DOT) com

On Thu, 31 Aug 2006 11:08:29 -0500, Rodney Frisard <rfrisard (AT) cox (DOT) net>
wrote: