[comp.os.vms] Getting Information about Queues

pengo@tmpmbx.UUCP (Hans H. Huebner) (03/19/88)

Hello,

I am currently writing a program which *shall* allow for screen oriented
management of print- and batch-queues. The problem is, that i can't figure
out how to get the actual information on what jobs are currently on the queue.
It seems like there is no official way to do this, save capturing the
output of a "SHOW QUEUE" command and reparsing it into machine-readable
data. I don't like this approach too much, so I tried to figure out how
SHOW QUEUE gets the information. SET WATCH FILE told me, that QUEMAN doesn't
access the JBCSYSQUE.DAT-file directly. Looking at the SYS$SNDJBC system
service description and $SJCDEF macros i found an "unused" parameter
and some SJC$_-requests. It seems (to me) like there is the possibility to
get the queue information with these special parameters ($SETUAI has such a
parameter, and you all know what the "bad guys" did with them).
The problem is of course, that these parameters are neither documented nor
supported, and thus it might not be the right way to go.
So here goes the question, does anyone of the gurus here know how to get
hold of the information on queued print jobs from high level languages ?

	Thanks a lot,
			Hans

-- 
Hans H. Huebner, netmbx     | Telex:  186672 net d
Woerther Str. 36            | DOMAIN: pengo@netmbx.UUCP (sigh)
D-1000 Berlin 20, W.Germany | ..!{{pyramid,unido}!tub,altger}!netmbx!pengo
Phone: (+49 30) 332 40 15   | BITNET: huebner@db0tui6

srwhmdr@wnv.dsir.govt.nz (03/22/88)

In article <633@tmpmbx.UUCP>, pengo@tmpmbx.UUCP (Hans H. Huebner) writes:
> 
> Does anyone of the gurus here know how to get hold of the information on 
> queued print jobs from high level languages ?
> 

The answer is to use the SYS$GETQUI (Get Queue Information) system service.
This was introduced at about VMS Version 4.2 I think. 

It is very similar to SYS$SNDJBC to call so if you can call it then calling
SYS$GETQUI is easy.


	Malcolm


Malcolm D Robbins	
Division Information Technology
DSIR
PO Box 1335
Wellington
New Zealand

DOMAIN: srwhmdr@wnv.dsir.govt.nz

sqkeith@csvax.liv.ac.uk (03/23/88)

In article <633@tmpmbx.UUCP>, pengo@tmpmbx.UUCP (Hans H. Huebner) writes:
> Hello,
> 
> I am currently writing a program which *shall* allow for screen oriented
> management of print- and batch-queues. The problem is, that i can't figure
> out how to get the actual information on what jobs are currently on the queue.
> It seems like there is no official way to do this, save capturing the
> output of a "SHOW QUEUE" command and reparsing it into machine-readable
> data.

The service you want is SYS$SNDJBC documented in the Orange Epic Volume
5A.

S'Keith Halewood

jdc@beach.cis.ufl.edu (Jeff Capehart) (03/25/88)

I have a couple questions:   First, I am doing some shared file
access in Pascal using the put, get, find, and update procedures.
My problem is that if the record happens to be locked, I get a
huge system dump with an error that says....
error during GET operation, record currently locked by another user.
(filename, etc. follows, along with stack dump)
How can I both test and set the lock on the record so that I don't
run into this problem?  (Ah, the Philosopher's problem revisited!)
I am sure it is in a manual somewhere, but us peons don't have easy
access to those wonderful orange manuals.

Second question:   Why do VAXen all of a sudden get a lobotomy when
they are clustered?  This question may have been asked before, but
I forgot what the conclusion was.  We have a couple 780's that could
easily handle 80 users under vms 3.x and they slowed down a bit under
version 4.x but when they were clustered, they run incredibly slow
with only 20 users on.  A 750 will run faster than a clustered 780!!
Now, why is this so?  My only idea is that somehow the CI must take
over total control, and the processor dedicates its priorities to
making sure that the CI is happy.  Also VMS gets slower with each new
upgrade so we have to have a corresponding hardware upgrade to make
VMS at least resonably good with response time.


--
Jeff Capehart 		Internet: jdc@beach.cis.ufl.edu
University of Florida	UUCP:   ..!ihnp4!codas!uflorida!beach.cis.ufl.edu!jdc