retained on error for testing

[Denise Schaffer]

I know this may sound odd, but I am trying to test a command that will loop through my print queues and delete and recreate any stopped queues. That part to the command seems to work alright. The problem is that when a queue has a job retained on error the Queue can not be deleted without removing the entry.
I have a command to do that as well BUT without jobs "retained on Error" existing in the queue a can not test the command.

So anyone know How I can force (so to speak)
an job to be retained on error.
I have tried set /queue Que1 /retain=all thinking that anything retained would work, but is seems that it can be only Retain on error

Thank for any help anyone can give me.

[Jim_McKinney]

$ create error.com
this is a bogus command line
^Z
$ set queue/retain=error sys$batch
$ submit/nolog/queue=sys$batch error
$ show entry/full '$entry'

[Volker Halle]

Denise,

the following should work for a print-queue (not tested):

$ create x.x
$ SUBMIT/HOLD/QUE=print_q/RET=ALL x.x
$ DELETE x.x.0
$ SET ENT/NOHOLD '$ENTRY'
$ SHOW ENT '$ENTRY'

Volker.

[Karl Rohwedder]

The ASSIGN/MERGE 'New' Old' allows you to 'save' all retained jobs into a temporary queue, recreate your real queue and ASSIGN/MERGE them back.

The attached DCL may act as a an example for such a procedure.


regards Kalle

[Jim_McKinney]

> my print queues

Ooops, my bad. I didn't read closely enough and presumed batch. Give Volker's solution a try.

[Denise Schaffer]

Volker,

Tried your suggestion but once the hold is taken off the entry the job prints. Or just sits in a "busy" queue.

thanks anyway.

Denise

[Volker Halle]

Deneise,

did you really delete the print-file - the correct version ? The job can't print, if the file has been deleted !

Volker.

[Denise Schaffer]

Jim,

Thats OK, I will save your suggestion in my..
"this could be useful later" files.

Denise

[Joseph Huber_1]

Isn't it a bit overdone to delete all jobs just to restart the queue ?

I use a procedure lpd-check once posted to comp.os.vms:
< http://wwwvms.mppmu.mpg.de/vms$common/sysmgr/lpd-check.com >

(despite the name, it handles all output queues, not just LPD).

[Denise Schaffer]

Volker,
I thought the same thing and after submitting the job with:

$submit /hold/que=test1

when I tried to add the /ret=all it gave me an error so I SET /que /retain=all test1 first
Then I deleted the file x.x.0 I checked to be sure it was gone. ( i admit the first time I may have delete a wrong file)

then entered $set entry/nohold Entry#
and the queue shows busy and the job show starting. That is how it stays.

[Volker Halle]

Denise,

try this on a working print-queue. If the print-queue does not work (e.g. because the printer is not reachable), I see the same effect as you. If you try it on a working queue, you should get the job into retained-on-error. I've only tested this on a batch-queue.

Volker.

[Denise Schaffer]

AH HA,
we are getting closer. I got a RETAINED on Completion.

and what is actually printing is a page reports the file not found.

[Volker Halle]

Denise,

this 'feature' may depend on the print-symbiont used on that queue.

Volker.

[Denise Schaffer]

Joseph,
The command that I am tried to build it for deleting and recreating Multiple queues, (close to 100)

denise

[Denise Schaffer]

Hey, guess what.
I can use the RETAINED on Completion.
SO thank you for your help.

Denise

[Volker Halle]

Denise,

now we could start to ask the question: why do you think you need to do this (delete and re-create stopped queues) ?

A STOP/QUEUE/RESET will get rid of the symbiont process (or at least of the data associated with this printer stream in the symbiont, if the symbiont handles multiple queues).

Volker.

[Denise Schaffer]

Ah yes, I thought you may be wondering.
Here's what happens. Our network connections are not reliable and because of this we lose communication between our servers. It the connections stays down too long one of the servers in the cluster believes it has been tossed and restarts itself to get back in. This wreaks havoc with the printer queues. Not all of them just about half, which is still close to 100. The Execution queue will return but the generic queues associated with it will not work. Stop /reset for the queues does not solve the problem they have to be deleted and recreated. There are way to many to do that one at a time.

So while i work to get a redundant connection I need something to help with the clean up until I do.

[Volker Halle]

Denise,

so you seem to be seeing CLUEXIT crashes due to network outages longer than RECNXINTERVAL between your OpenVMS nodes. Did you try increasing this parameter value to ride out longer outages (default is 15 seconds) ?

Depending on your OpenVMS version and print-symbiont type, you may be able to set up the execution queues as AUTOSTART-Queue, so they will automatically fail over to the remaining system and continue to function.

Having to delete and re-create printer queues after a system crash is not something you would expect to be doing on OpenVMS !

Volker.

[Joseph Huber_1]

In a correctly setup cluster, QUORUM should prohibit this behaviour. I would review the system setup vs. EXPECTED_VOTES, VOTES and the QUORUM resulting.
Normal behaviour should result in a "quorum lost" and block activity until the network is o.k. again.
The symtom Denise describes shows a partitioning cluster: nodes loose connection to each other, but still have enough votes to continue, remove each other from cluster, and one of them has to "voluntarily" leave after network connections are re-established.
I would rather try to correct the cluster problem, then the queue messup should not happen.

[Wim Van den Wyngaert]

My guess is that stop/que/reset didn't stop the symbiont process. You have to kill that too. But that's only simple for LPD.

Wim

[Volker Halle]

Joseph,


Normal behaviour should result in a "quorum lost" and block activity until the network is o.k. again.


Yes, the quorum will be lost, if the network doesn't work between the nodes. But the nodes will still time out and remove each other after RECNXINTERVAL seconds. And if the network comes back later, one of the nodes has to re-join the cluster by taking a CLUEXIT bugcheck and reboot.

Volker.

[Joseph Huber_1]

I stand corrected, yes:
since my cluster has a long recnxinteval, I was not patient enough ...