"inconsistent queue type " Assigning Printer Queues!

[Robert Atkinson]

Anyone know why this won't work, or what the rules are for assigning one queue to another?

ALPHA_ROB$$ SQ RA_JS*
Generic printer queue RA_JS_GEN

Printer queue RA_JS_STOP, stopped, autostart inactive, on GAMMA::"FTGOCE1:9999", mounted form DEFAULT

Printer queue RA_JS_TEST1, stopped, autostart inactive, on GAMMA::"FTGOCE1:9999", mounted form DEFAULT

Printer queue RA_JS_TEST2, idle, on GAMMA::"FTGOCE2:9999", mounted form DEFAULT

ALPHA_ROB$$ ASSIGN/QUE RA_JS_STOP RA_JS_TEST1 %JBC-F-INCQUETYP, inconsistent queue type ALPHA_ROB$$

Rob.

[Duncan Morris]

Rob, you are using ASSIGN/QUEUE which assigns/redirect a LOGICAL queue to an execution queue.
For your testing would you not be better using ASSIGN/MERGE ???

[Robert Atkinson]

Bugger!

It's because the queue being assigned (TEST1) is being fed from a generic queue.

If I try it on a non-generic-fed queue (TEST2) it works :-

ALPHA_ROB$$ sq ra_js*/ful
Generic printer queue RA_JS_GEN
/GENERIC=(RA_JS_TEST1) /OWNER=[SYSGRP,SYSTEM] /PROTECTION=(S:M,O:D,G:R,W:RSD) /SCHEDULE=(NOSIZE)

Printer queue RA_JS_STOP, stopped, autostart inactive, on GAMMA::"FTGOCE1:9999", mounted form DEFAULT
/AUTOSTART_ON=(GAMMA::"FTGOCE1:9999",GAMMA::"FTGOCE1:9999") /BASE_PRIORITY=4 /DEFAULT=(FORM=DEFAULT) /OWNER=[SYSGRP,SYSTEM]
/PROCESSOR=TCPIP$TELNETSYM /PROTECTION=(S:M,O:D,G:R,W:RSMD) /SCHEDULE=(NOSIZE)

Printer queue RA_JS_TEST1, stopped, autostart inactive, on GAMMA::"FTGOCE1:9999", mounted form DEFAULT
/AUTOSTART_ON=(GAMMA::"FTGOCE1:9999",GAMMA::"FTGOCE1:9999") /BASE_PRIORITY=4 /DEFAULT=(FORM=DEFAULT) /OWNER=[SYSGRP,SYSTEM]
/PROCESSOR=TCPIP$TELNETSYM /PROTECTION=(S:M,O:D,G:R,W:RSMD) /SCHEDULE=(NOSIZE)

Logical queue RA_JS_TEST2, stopped, assigned to RA_JS_STOP
/OWNER=[SYSGRP,SYSTEM] /PROCESSOR=TCPIP$TELNETSYM /PROTECTION=(S:M,O:D,G:R,W:RSMD) /SCHEDULE=(NOSIZE)
ALPHA_ROB$$

Back to the drawing board!!

[Duncan Morris]

Now that makes sense! I should have guessed that the generic queue was tied into your test queues.

[Ian Miller.]

What is the purpose? Could you use another generic queue or a logical name?

[Robert Atkinson]

It's a bit complicated really.

I want 2 queues to be fed from a generic queue, but the receiving queue must not print anything.

It can't be put on stop, as that would stop anything being fed.

It must also adhere to normal forms-type rules.

A secondary process than takes the jobs from the queue and passes them to a new queue, based on a set of rules.

The attached diagram will explain it a little better.

What I was going to do was create a dump queue, and then assign the two real queues to it. The jobs would feed from SYS$PRINT to the 2 queues, based on the forms type, but wouldn't go any further because the dump queue would be stopped.

Unfortunately, VMS Queue Management isn't quite subtle enough to handle this....did I just say that :<>

Rob.

[Robert Atkinson]

(Try attaching the file Rob!!)

[Art Wiens]

If your JobStore procedure/program can determine what job is what in the execution queues, why can't it do the same for the sending SYS$PRINT?

Can't you just skip the two receiving queues?

And are the OCE queues above the bricks the same queues in the Prisma section? That's a little whacked isn't it?

Art

[Robert Atkinson]

The idea was to try and make the whole thing look _natural_ to the Operators. So, as far as they're concerned, they just change the forms type on the queue they want to print to, the jobs go to the queue, and my pseudo-Queue Manager drags the entries off and prints them.

I'd been thinking along the same lines as you; make the pseudo-Manager control the whole process by checking to see if the output queue forms type matches the pending jobs form, etc, etc.

There's no way of getting rid of FTG_OCE1 and FTG_OCE2, as you wouldn't be able to tell JobStore which queue (and therefore printer) you want to make available to the job.

Having said that, I guess I could send a direct message to JobStore - "Print this entry to this printer", "Print all jobs with forms type x to this printer".

The reason this is a problem is that I wanted to make it so that I just set up a queue with a forms type of say "Invoices" and anything coming along through the day would just go there with the need to 'tell' JobStore.

Apart from this niggle about not physically trying to print the jobs, the VMS Queue Manager would work.

I could get round that by pointing the queue at a non-existant device, but the entry would go to stalled and that would make it harder to remove the entries from the queue without stopping it!

I guess what I'm after is a PROCESSOR that doesn't actually do anything, justs marks the entries as 'being processed' as far as the Queue Manager's concerned.

Rob.

[Robert Atkinson]

Sorry, forgot to say (like my ramble wasn't long enough :) - the VMS, Prisma, and Formate sections are all physcially different boxes.

Prisma and Formate are document overlay/transformation programs that turns the text into real Invoices or Reports, then sends it to the final output device - ftgoce1 or ftgoce2.

Rob.