"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.

[Ian Miller. · Accepted solution]

what about having a queue using this
http://vms.process.com/scripts/fileserv/fileserv.com?EXECSYMB

[Phillip Thayer]

Or, you could write your own symbiont that simply does what you wanted and sets the entry to whatever you want it to mark it as.

Set up as many print queues using the symbiont you write and then point the generic queue to those special queues.

The advantage to this is that you could actually have the symbionts log entries in a log file to be abel to see what has come through the queues and when.

Phil

[John Gillings]

Rob,

What if you used the Null Symbiont, and set your queue to RETAIN=ALL. The jobs would then "execute" but be retained. You could then interrogate the queue to get all the characteristics of the entry, submit a new entry to the correct queue, and then delete the old one.

A bit fiddly, but should give you maximum flexibility.

It might also be possible to modify the null symbiont to be permanently busy. Just make sure you submit a "sacrificial" job to the queue?

[John Gillings]

Rob,
I'm stupid... print queues don't have job limits Doh! ;-)

I've attached a symbiont that will take forever to print a job, so any job queued to it will go into Pending state.

Not sure if it will help in your case.

[Hakan Zanderau ( Anders]

Rob,

Is can easily be fixed......

(1)
Create a queue were all the jobs will end up. This queue must be stopped.

(2) Create a local LPD-queue that targets this queue

LP1|lp1:\
:lp=xxxxx:\
:sd=/TCPIP$LPD_ROOT/LP1:

xxxxx= the name of the queue in (1)

(3) Create two remote LPD-queues that both targets rm=localhost and rp=LP1

(4) Create the generic queue to target the two LPD-queues.

regards,

Hakan Andersson

Hopfully this works......
Haven't trid it because of gastric flu the last couple of days.

[Hakan Zanderau ( Anders]

Rob,

Just want to know if things are working.........

Hakan Andersson

[Robert Atkinson]

Still mulling over all the options to see which is the simplest approach.

Will let everyone know when I've come to some sort of a conclusion.

Rob.

[Robert Atkinson]

Just to update everyone, I finally went with a permanent command file that scans the generic queue entries and moves them as necessary.

In the end, it was the best solution for the job and easiest to manage.

Many thanks to Ian for the DIY-Symbiont though - I'm sure I'll find a use for it soon.

Robert.