initing a queue pointing to null device

[Patrick_42]

Hi,

How can i define a printer queue pointing to null device so that print requests can be submitted and completed without consuming computing resources?

I have tried to initting queue pointing to node::nla0:

but when i attempt to start it, the following error prompts up and the queue fails to startup:

%SYSTEM-W-DEVALLOC, device already allocated to another user.

Regards,
Patrick.

[Stanley F Quayle]

What are you really trying to do? Passing jobs through to nowhere will still use CPU resources...

[Patrick_42]

There are some "old printer queues" where the printer hardware is not functioning and at the same time, our developers are reluctant to revise their batch jobs not to submit print jobs to such queues since it will not affect the result of batch jobs.

As a result, thousands of pending jobs accumulated at the printer queues in a couple of days and i have to delete them periodically.

What I want to do is direct the submitted printer jobs to some "NULL" device so that the jobs will be consumed immediate after they are submitted.

I have tried to init the queue to null device by following command but failed:

$ init/queue queue1 /on=node::nla0: /start

I am still looking for other possible solution.

Thanks and Best Regards,
Patrick.

[Benjamin Levy]

This will work if you add the qualifier /PROC=DCPS$SMB

-Ben

[Stanley F Quayle]

> This will work if you add the qualifier
> /PROC=DCPS$SMB

Only if you have DCPS installed, right?


It would be easy enough to create a batch job to cruise the queue(s) and delete the entries on a periodic basis.

Also, you can define system logical names so that all the entries go to the same queue, so that you only have to "cruise" one queue. For example,

$ define/system/exec QUEUE_1 QUEUE_NOWHERE
$ define/system/exec QUEUE_2 QUEUE_NOWHERE

This will cause jobs sent to QUEUE_1 or QUEUE_2 to be queued into QUEUE_NOWHERE.

[Willem Grooters]

First of all:

.... our developers are reluctant to revise their batch jobs not to submit print jobs to such queues since it will not affect the result of batch jobs. ....

They _SHOULD_ be educated....

Anyway:

Just one execution queue, say "DEVELOPERS_PRINTER" printing to a regular (well working) printer, or, eventually, the bit-bin....(would it be possible: the devloper's terminal; THAT would teach them ;-))

Then redefine the queues the developer's seem reluctant to avoid, as /GENERIC and using DEVELOPERS_PRINTER as executing queue.

[Willem Grooters]

To clearify my previous message:

I am a developer myself.....

[Martin Johnson]

The easiest way to deal with the problem is to create a batch file to run nightly that deletes the queue(s), then recreates them. Deleting a queue automatically deletes all jobs in the queue (see "HELP DELETE/QUE").

This way the system automatically cleans up after itself and you don't have to do anything manually.

HTH
Marty

[Stanley F Quayle]

Since there's thousands of files being created daily, it would seem likely (per Murphy's Law) that the queue would be deleted at the moment that something attempts to queue a file. I would recommend against that approach.

[Martin Johnson]

He said thousands in a couple of days.

I'm sure Patrick can find a time in the wee hours of the morning when things are quiet. If not, he can make things quiet by stopping the batch queues and checking for job completion of running batches before deleting the queues.

I'm sure a little analysis of the job schedules and run times will reveal the best time to recycle the queues.

Marty