Previous Thread
Next Thread
Print Thread
CUPS print order #1374 17 Oct 07 03:52 PM
Joined: Jun 2001
Posts: 410
V
Valli Information Systems Offline OP
Member
OP Offline
Member
V
Joined: Jun 2001
Posts: 410
We spool a lot of files at one time and it is important they print in the order sent. This seems to have changed, now the smaller sized jobs are being printed first. I have SBR=SUBMIT2 in miame.ini to help solve an earlier problem with TCPX and noted the documentation saying that this will cause spool not wait till the job is finished spooling. Could this culprit in how the jobs are printed? If so is there an option to make spool wait without removing the SUBMIT2? Thanks

Re: CUPS print order #1375 17 Oct 07 04:34 PM
Joined: Jun 2001
Posts: 11,645
J
Jack McGregor Online Content
Member
Online Content
Member
J
Joined: Jun 2001
Posts: 11,645
If you are spooling files in such rapid succession that the time from one submission to the next is less than the time it takes the lpr command to execute, then surely SBR=SUBMIT2 is going to present the risk you've identified.

I'm not sure there is any simple solution though, since I'm not sure of the exact sequence of events in lpr receiving the submission and sending it to the output device.

SBR=SUBMIT2 causes the submitted processes (which are executing lpr) to run independently of the parent, so it is a bit like herding cats to force them to execute in a certain sequence.

As an aside, although there is good reason to assume that jobs should appear on the printer in the same order submitted, there is no good reason to assume that two print jobs submitted in contiguous sequence by one program will in fact appear contiguously on the printer. (That is, another print job from another process could squeeze in the middle.) To assume otherwise implies some kind of application-level mechanism to regulate print flow. If such a mechanism existed, then it might be better to address the chronological issue there as well, rather than in XCALL SPOOL, which has no understanding of the events taking place before or after this particular spool request, or those taking place simultaneously on other jobs.

That said, if it works ok without SBR=SUBMIT2, then perhaps a reasonable workaround is to turn that flag off when spooling, or on when you were using SUBMIT and otherwise wanted it.

For unknown reasons, the MIAMEX,MX_SBRFLG(123) call is not documented, but it works similarly to the MIAMEX, MX_GETOPTIONS and MX_SETOPTIONS, except that the first argument is an opcode (0=get, 1=set).

So, to retrieve the current SBR= flags and then set or clear the SUBMIT2 flag:

Code
 
map1 sbrflags,b,4

define SBRF_SUBMIT2 = &h20000000  ! SBR=SUBMIT2

    xcall MIAMEX, MX_SBRFLG, MXOP_GET, sbrflags ! retrieve

    sbrflags = sbrflags or SBRF_SUBMIT2  ! set SUBMIT2
or
    sbrflags = sbrflags and not SBRF_SUBMIT2 ! clear  SUBMIT2

    xcall MIAMEX, MX_SBRFLG, MXOP_SET, sbrflags ! set

 

Re: CUPS print order #1376 17 Oct 07 04:56 PM
Joined: Jun 2001
Posts: 410
V
Valli Information Systems Offline OP
Member
OP Offline
Member
V
Joined: Jun 2001
Posts: 410
Is turning it off/on on a per job basis? Here is the scenario, my tcp server is a submitted job waiting for connections, then it submits another background job to handle those connections. if i remove the SBR=SUBMIT2 from miame.ini, then have the tcp server set the SUBMIT2 flag, will that only then affect the tcp server's job and its spawned jobs, while all other jobs will act the flag set from the miame.ini?

Re: CUPS print order #1377 17 Oct 07 05:54 PM
Joined: Jun 2001
Posts: 11,645
J
Jack McGregor Online Content
Member
Online Content
Member
J
Joined: Jun 2001
Posts: 11,645
Correct.

Re: CUPS print order #1378 18 Oct 07 12:32 PM
Joined: Jun 2001
Posts: 410
V
Valli Information Systems Offline OP
Member
OP Offline
Member
V
Joined: Jun 2001
Posts: 410
the cats are back in order, thanks


Moderated by  Jack McGregor, Ty Griffin 

Powered by UBB.threads™ PHP Forum Software 7.7.3