Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

JBC-E-NOQUECTX from F$GETQUI.

85 views
Skip to first unread message

fwhe...@csc.com

unread,
Jun 15, 2001, 3:46:14 PM6/15/01
to
I'm getting a JBC-E-NOQUECTX from F$GETQUI on a command
file that was intended to RELEASE print jobs held in the queue. The
message occurs on line #9 ($ Held = ...) (below) when I run it on VAX/-
VMS V7.2.

What am I doing wrong?
/Scott Wheeler, Computer Sciences Corporation, Fort Worth TX

$ show queue/all ps_lps1c6
Generic printer queue PS_LPS1C6

Entry Jobname Username Blocks Status
----- ------- -------- ------ ------
100 MSCR4A$1 SELLERS 145 Holding
101 MTDCR4A$1 SELLERS 141 Holding
102 DTDCR4A$1 SELLERS 141 Holding
$ diff release_held.com nl: ! 'type' with line #s.
************
File USER4:[WHEELER]RELEASE_HELD.COM;1
1 $Start: ! Release all 'Holding' jobs from PS_LPS1C6 queue.
2 $ ClearContext = F$GETQUI("CANCEL_OPERATION")
3 $QLoop:
4 $ QName = -
5 F$GETQUI("DISPLAY_QUEUE","QUEUE_NAME","PS_LPS1C6",-
6 "GENERIC,SYMBIONT")
7 $ IF QName .EQS. "" THEN EXIT
8 $JobLoop:
9 $ Held = F$GETQUI("DISPLAY_JOB","JOB_HOLDING",,"ALL_JOBS")
10 $ IF Held .EQS. "" THEN GOTO QLoop
11 $ Entry = -
12 F$GETQUI("DISPLAY_JOB","ENTRY_NUMBER",,-
13 "FREEZE_CONTEXT,ALL_JOBS")
14 $ IF Held .EQS. "TRUE" THEN SET ENTRY 'Entry'/RELEASE
15 $ GOTO JobLoop
******
File NL:[]RELEASE_HELD.COM;
************

Number of difference sections found: 1
Number of difference records found: 15

DIFFERENCES /IGNORE=()/MERGED=1-
USER4:[WHEELER]RELEASE_HELD.COM;1-
NL:[]RELEASE_HELD.COM;
$ @release_held
%JBC-E-NOQUECTX, no queue context
$

Thomas H. Pauli

unread,
Jun 16, 2001, 4:40:09 AM6/16/01
to
Hi Scott,

I think it's the second execution of the QName= statement after the
final GOTO Qloop !

Thomas

fwhe...@csc.com wrote:


--
Thomas H. Pauli, Hammersteinstr.19, 14199 Berlin, Germany

Jim Becker

unread,
Jun 16, 2001, 3:16:54 PM6/16/01
to
You have two problems. Btw, it would have been helpful if you'd done a
SET VERIFY so you could see which call to F$GETQUI was reporting that
message.

Your first problem is that the DISPLAY_JOB in line 9 has no context.
You're probably thinking, "Yes it does, I used DISPLAY_QUEUE first."
You're close. You need the WILDCARD flag in the DISPLAY_QUEUE call in
line 6. This "establishes and saves a context" according to the help.
If you had a wildcard character in the queue spec, you wouldn't need
the WILDCARD flag.

Your second problem is that you're using a SET ENTRY command before
you're done with your F$GETQUI calls. The SET ENTRY command wipes out
your current GETQUI context. You'd need to accumulate entry numbers
until you're done, then use SET ENTRY at the end.

--
Jim Becker
The Urban Institute (http://www.urban.org/)
Encompass (http://www.encompassus.org/)
ESILUG (http://encompasserve.org/lugs/esilug/)

Phil Howell

unread,
Jun 17, 2001, 10:00:04 PM6/17/01
to
Any dcl like $set entry <n> or $delete /ent=<n> in your procedure can stuff
up your current context
The easy way to get round this is to spawn a subprocess to do the relevant
action
eg. change

> 14 $ IF Held .EQS. "TRUE" THEN SET ENTRY 'Entry'/RELEASE
> 15 $ GOTO JobLoop
to
> 14 $ IF Held .EQS. "TRUE" THEN SPAWN/NOWAIT SET ENTRY 'Entry'/RELEASE
> 15 $ GOTO JobLoop
Phil
<fwhe...@csc.com> wrote in message
news:OF3616F6F0.D8DD06E6-ON86256A6C.006C9A92@com...

sspa...@csc.com

unread,
Jun 18, 2001, 10:12:15 AM6/18/01
to
I used to get context related error messages on one system
when using PID = $F$PID(context)
I don't remember the exact error message but it mentioned
an invalid context. F$context("process",context,"cancel")
didn't help. My only fix was to reboot the one particular system
and the problem went away and hasn't yet returned.
This is on OpenVMS VAX V6.2

0 new messages