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@db0tui6srwhmdr@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